회사일만 열심히했는데, 뒤돌아 보니 남은것들..
작년 9월, 회사에서 정리해고가 시행되었고, 나 역시 그 대상에 포함되었다. 1년여 동안 팀원들과 야근을 해가며 프로젝트를 수행해왔던 터라, 막상 해고 대상이 되었다는 소식을 들었을 때 멍해졌다. 입으로는 "퇴사하고 싶다", "차라리 짤리고 싶다"는 말을 가볍게 내뱉곤 했지만, 실제로 내 일이 되자 눈물이 고였다. (다행히, 아직은 같은 회사에 다니고 있다)
1년 넘게 일한 회사였지만, 어쩔 수 없이 다시 이력서를 준비하기 시작했다. 돌이켜보면, 그동안 새롭게 맡았던 프로젝트가 많았기 때문에 이번 이직은 좀 더 수월하지 않을까 하는 근거 없는 자신감도 있었다. 다행히도 가고 싶었던 회사들에서 서류 통과 소식을 들을 수 있었고, 면접을 위해 이력서를 기반으로 기술 개념들을 다시 복습했다.
하지만 면접에서 받은 질문들은 내가 예상했던 수준과는 달랐다. 단순히 "A가 무엇인가요?" 같은 개념 설명이 아니라, "왜 그렇게 했나요?", "어떤 고민을 했나요?" 같은 본질적인 질문들이 이어졌다. 기술적인 개념을 묻는 데서 그치지 않고, 문제 해결 과정에서 내가 어떤 생각을 했고, 스스로 더 나은 방법을 찾아 개선해본 경험이 있는지를 확인하려 했다.
기술 면접에서 탈탈 털린 후, 나의 문제를 깨닫게 되었다. 나는 그동안 주어진 기획서를 그대로 구현하고, 일정에 맞춰 개발하는 것에만 집중했다. 사실 이것만으로도 나에겐 너무 벅찼다. 또다른 한편으로는 회사에서 개선해보고 싶은 것들이 너무 많이 있었는데, 도입해보려 했던 것들이 계속해서 좌절되다 보니 어느샌가 그냥 주어진 일만 하고 있었다.
이런 상황이 반복되다 보니 "뭔가라도 해야 할 것 같다."는 압박감에 여러 스터디에도 참여해봤다. 타입스크립트 스터디, 디자인 패턴 스터디 등 여러 가지를 시도해봤지만, 결국 책을 읽고 예제 코드를 작성하는 것에서 그쳤다. 실무에서 적용할 기회가 없으니 결국 다시 제자리로 돌아오곤 했다.
"회사 탓인가? 아니면 내 탓인가?"
"어디서부터 잘못된 걸까? 무엇을 바꿔야 할까?"
그러던 중, 우연히 본 유튜브 영상이 뼈를 때렸다.
이 영상에서는 이직과 커리어의 악순환에 대해 이야기하고 있었다.
"급한 마음으로 이직을 결심하고, 겉핥기식 학습을 하게 되면, 연봉은 올릴 수 있을지 몰라도 결국 비슷한 회사로 가게 된다.
그리고 연봉이 올랐다는 이유로 잘못된 효용감을 가지게 되고, 커리어의 악순환이 반복된다."
이 말이 마치 나를 저격하는 것 같았고, 이 악순환을 끊고 싶었다.
그러던 중 Product Engineer Camp(PEC)를 알게 되었다.
"단 0.1%라도 나에게 도움이 될 수 있지 않을까?"
하는 마음으로 망설임 없이 신청했다.
적어도 이번에는 책으로만 배우는 것이 아니라, 실제 적용하며 변화를 만들어보려 한다.
알고리즘 공부를 다시 시작하다
PEC 참여를 결정하고, 고민을 PEC 멘토님(경찬님)께 털어놨다. 그러자 멘토님이 말했다.
"PEC 시작 전에 알고리즘을 공부해보는 게 좋겠다."
그 말을 듣는 순간, 속으로 ‘또 알고리즘인가…’ 하는 생각이 들었다. 사실 알고리즘 공부에 대한 회의감이 컸다.
알고리즘은 성실함이 필요한데, 나는 그동안 꾸준히 하지 못했다. 대학 때도 알고리즘 수업을 재수강할 정도로 재미를 못 붙였고, 이제는 AI 시대인데 GPT에게 물어보면 되는 거 아닌가 싶었다. 그런데 경찬님은 오히려 그럴수록 알고리즘을 공부해야 한다고 했다.
"AI가 점점 발전하면서 앞으로 우리가 하는 많은 일이 AI로 대체될 거다. 그렇기 때문에 변하지 않는 걸 공부해야 한다. 알고리즘을 공부하면서 논리력과 사고력을 키우는 게 중요하다."
그제야 ‘단순히 문제를 푸는 게 아니라 문제를 해결하는 방식 자체를 고민해야 한다’는 생각이 들었다. 나는 여태 코드가 돌아가면 됐지, 왜 이 방식이 최적인지 깊게 생각해본 적은 없었다. 문제를 해결하는 능력은 AI가 쉽게 대체할 수 없는 영역이고, 그 핵심이 알고리즘이었다.
그래서 이번에는 제대로 해보기로 했다. 하지만 예전처럼 무작정 문제를 풀지는 않았다. 멘토링을 받으면서, 일단 내가 직접 학습 순서를 짜는 것부터 시작했다. 바로 문제 풀이로 들어가는 게 아니라, 개념을 먼저 확실히 이해하는 방식이었다.
예를 들어 스택을 공부할 때도 그냥 "스택은 LIFO 구조다" 하고 넘어가는 게 아니라, 직접 구현해보고, 내가 이해한 내용을 블로그에 정리하면서 개념을 내 것으로 만들었다. 이렇게 공부하니 알고리즘 문제를 푸는 게 막막하게 느껴지지는 않았다. 그동안은 개념을 대충 알고 문제를 풀다 보니 중간에 막히는 일이 많았는데, 이번에는 개념을 먼저 다지고 문제를 풀었더니 이해하는 속도도 빨라졌다.
물론 지금은 잠시 멈춰 있지만, 여유가 생기면 다시 이어갈 생각이다.(당장 다음주..?) 이전과 같은 겉핥기식 공부가 아니라, 한 단계씩 차근히 쌓아가는 방식으로.
Product Engineer vs. Project Engineer
PEC 6기에 참여하면서 ‘Product Engineer’라는 개념을 처음 접했다. PEC 시작 전에 경찬님이 "Product형 개발자인가? Project형 개발자인가?"라고 물었는데, 단 한 번도 생각해 본 적이 없는 주제라 머뭇거리며 이상한 답변을 했던 것 같다.
곱씹어 보니, 나는 지금까지 Project형 개발자로 일해왔다. 주어진 기획을 충실히 구현하고, 일정에 맞춰 프로젝트를 완수하는 데 집중했다. 프로젝트가 끝나면 거기서 역할이 끝났고, 이후 서비스가 어떻게 운영되는지, 사용자가 어떻게 반응하는지는 크게 신경 쓰지 않았다.
그런데 Product Engineer는 접근 방식이 달랐다. 단순히 개발을 수행하는 것이 아니라, 사용자 경험과 제품 개선을 고민하고 능동적으로 문제를 해결하는 개발자였다. "이 기능이 왜 필요한가?", "이걸 더 나은 방식으로 만들 수 없을까?", "비즈니스적으로 더 좋은 선택은 뭘까?" 같은 질문을 스스로 던지며, 개발 자체가 아니라 제품을 만든다는 관점에서 접근하는 역할이었다.
PEC를 진행하면서, 나는 단순히 프로젝트 단위의 개발이 아니라 제품 자체를 고민하는 시각이 필요하다는 것을 깨닫고 있다. 여전히 익숙한 방식에서 벗어나는 과정이 쉽지는 않지만, 기존과는 다른 사고방식을 가져야 한다는 점에서 고민의 깊이가 달라지고 있다.
이런 표현이 맞을지 모르겠지만... PEC 과정을 많은 사람이 알았으면 좋겠다. 또 한편으로는 너무 유명해지지 않았으면 하는, 마치 내가 발견한 숨은 맛집 같은 느낌이다. 그럼에도 불구하고, 연차가 쌓이는 것이 두려운 개발자들과 앞으로 어떤 방향으로 나아가야 할지 고민하는 분들께 꼭 추천하고 싶다.
참고로, 글 작성하는 시점기준으로 PEC 7기 추가 모집을 한다고 하니 고민하고 있다면, 얼른 신청 했으면 좋겠다!!
PEC에 대해 궁금하다면? 아래 링크 클릭!
