"지금 회사에서 더 배울 게 있나?"

이 생각이 처음 든 건 입사 1년 6개월쯤이었다. 당시 맡은 프로젝트에서 같은 패턴의 페이지를 반복적으로 만들고 있었다. 리스트 페이지, 상세 페이지, 폼 페이지. 레이아웃만 조금 다르고 구조는 거의 같았다. 3개월 전에 했던 작업을 복붙해서 약간 고치면 되는 수준.

그 자체가 나쁜 건 아니다. 이런 작업을 빠르고 정확하게 하는 것도 실력이니까. 근데 문제는 아침에 출근할 때 설레는 느낌이 사라졌다는 거다. 뭔가 새로운 걸 해보고 싶은데, 팀의 프로덕트 특성상 새로운 기술을 도입할 기회가 별로 없었다.

이직을 고민하게 된 진짜 이유#

사실 "배울 게 없다"는 건 핑계에 가깝다. 어디서든 배울 건 있다. 진짜 이유는 좀 더 복잡했다.

팀 구조가 바뀌었다. 입사할 때 같이 일하던 시니어가 퇴사했다. 그 분한테 코드 리뷰를 받으면서 많이 배웠는데, 그 분이 나간 뒤로 리뷰의 질이 확 떨어졌다. 내 코드에 "LGTM"만 달리는 날이 많아졌다. 피드백이 없으니 성장하고 있는 건지 아닌 건지 감이 안 왔다.

연봉도 솔직히 불만이었다. 연봉 인상 시기에 5% 올랐는데, 비슷한 경력의 다른 회사 공고를 보니까 지금보다 20~30%는 더 주는 곳이 있었다. 물론 공고에 적힌 숫자가 실제 오퍼 금액은 아니다. 근데 격차가 꽤 크다는 건 부정할 수 없었다.

그리고 하나 더. 동기들이 슬슬 이직하기 시작했다. 같이 입사한 4명 중 2명이 1년 반 정도에 나갔다. 한 명은 스타트업으로, 한 명은 대기업 계열사로. 그 소식을 들을 때마다 "나도 움직여야 하나?"라는 생각이 들었다. 남들이 가니까 나도 가야 할 것 같은 묘한 조급함. 돌이켜보면 이게 가장 위험한 이유였다.

준비를 시작하다#

이직을 결심한 건 아니었지만 "일단 시장을 보자"는 마음으로 준비를 시작했다.

이력서부터 손봤다. 근데 막상 쓰려고 하니까 뭘 써야 할지 모르겠더라. "React로 프론트엔드 개발했습니다"는 아무 의미가 없다. 구체적으로 뭘 했는지, 그래서 어떤 결과가 있었는지를 써야 한다. 예를 들면 "결제 플로우 리뉴얼을 담당해서 전환율을 1.2% 개선했다"는 식으로.

문제는 내가 그 숫자를 모른다는 거다. 당시에는 그냥 시킨 대로 만들었지, 비즈니스 임팩트까지 추적하지 않았다. 이때 깨달았다. 이직을 위해서가 아니라, 평소에 내 작업의 결과를 숫자로 알고 있어야 한다는 걸. 그 뒤로는 배포할 때마다 관련 지표를 한 번씩 확인하는 습관을 들였다.

포트폴리오도 고민했다. 사이드 프로젝트를 새로 하기에는 시간이 부족했고, 기존 깃허브를 보니 1년 전에 멈춘 투두앱 하나. 참담했다. 근데 채용담당자한테 나중에 들은 건, 사이드 프로젝트보다 실무에서 뭘 했는지를 더 본다고. 회사 코드를 공개할 수는 없지만, 기술 블로그에 경험을 정리하는 게 더 효과적이라고 했다.

코딩 테스트라는 벽#

서류가 통과되고 코딩 테스트 일정이 잡혔을 때, 현실을 직시했다. 알고리즘을 1년 넘게 안 풀었다. 실무에서는 배열 sort 함수 쓰면 되는 걸 직접 구현할 일이 없으니까.

퇴근 후 하루에 1~2문제씩 풀기 시작했다. 처음에는 쉬운 문제도 막혔다. BFS를 써야 하는 건 아는데 구현이 안 나왔다. 한 문제에 2시간을 쓰다가 포기하고 풀이를 보는 일이 반복됐다. 자괴감이 좀 들었다. 매일 코딩을 하는 사람인데 코딩 테스트를 못 풀다니.

2주 정도 지나니까 감이 돌아왔다. 완전히 처음 배우는 게 아니라 예전에 알던 걸 다시 꺼내는 거라서. 패턴이 보이기 시작하면 속도가 붙는다.

면접에서 멘탈이 흔들린 순간#

기술 면접에서 예상 못한 질문을 받았다. "본인이 작성한 코드 중에서 가장 후회되는 코드가 있나요?"

순간 멘붕이 왔다. 면접 준비하면서 "가장 잘한 프로젝트"는 준비했는데, "가장 후회되는 코드"는 생각 안 해봤다. 몇 초 동안 머리가 하얘졌다가, 솔직하게 말했다. 첫 프로젝트에서 전역 상태 관리를 남발해서 나중에 리팩토링하느라 고생한 얘기를. Redux에 모든 상태를 넣었던 건데, 컴포넌트 로컬 상태로 충분한 것까지 전역으로 올려서 불필요한 리렌더링이 발생했다고.

면접관이 고개를 끄덕이면서 "그 경험 이후에 상태 관리에 대한 기준이 바뀌었나요?"라고 물었다. 그때부터 대화가 자연스럽게 흘러갔다. 면접이 끝나고 나서 생각해보니, 그 질문은 기술력을 보려는 게 아니라 "실수에서 배울 수 있는 사람인가"를 보려는 거였다.

오퍼를 받고 나서의 고민#

두 군데에서 오퍼를 받았다. 하나는 연봉이 높고 하나는 기술 스택이 더 맞았다. 둘 다 지금보다 나은 조건이었는데, 막상 퇴사를 결정하려니 발이 안 떨어졌다.

현재 팀이 나쁘지 않았기 때문이다. 사람들이 좋았다. 편하게 질문할 수 있는 분위기, 야근을 강요하지 않는 문화, 점심에 같이 밥 먹으면서 웃고 떠들 수 있는 동료들. 이런 건 공고에 안 나온다. 가봐야 안다. 새 회사가 좋은 환경일 거라는 보장이 없다.

며칠을 고민하다가 결국 이직했다. 결정적인 이유는 "2년 뒤에 지금 결정을 후회하지 않을까"를 생각했을 때, 안 가는 걸 더 후회할 것 같았다. 성장할 수 있는 환경으로 옮기는 것. 지금 아니면 경력이 더 쌓인 뒤에는 오히려 움직이기 어려울 수 있다.

이직하고 나서 느낀 것#

새 회사에 와서 한 달쯤 됐을 때, 전 회사 동료한테 연락이 왔다. "나도 이직 고민 중인데 어떻게 준비했어?" 그 질문을 받는 내가 신기했다.

이직이 정답인지는 아직도 모르겠다. 새 회사에서도 적응하느라 힘든 시기가 있었고, "전 회사가 나았나"라는 생각이 드는 순간도 있었다. 근데 분명한 건, 이직을 준비하는 과정에서 스스로를 객관적으로 돌아보게 됐다는 거다. 내가 뭘 잘하는지, 뭘 모르는지, 어디로 가고 싶은지. 결과적으로 이직을 하지 않았더라도 그 시간은 낭비가 아니었을 거다.

한 가지, 이직 타이밍에 대해. "최소 2년은 다녀야 한다"는 말이 있는데 너무 맹신하지 않는 게 좋다. 1년이든 3년이든 중요한 건 그 기간 동안 뭘 했는지이고, 다음 직장에서 그 경험을 어떻게 설명할 수 있는지다. 다만 6개월 미만은 좀 짧다. 무엇을 했는지 설명하기에는 시간이 부족하니까.

퇴사를 말하는 순간#

퇴사 의사를 밝히는 건 생각보다 어려웠다. 팀 리드와 1:1 시간에 말했다. "다른 곳에서 오퍼를 받았고, 이직하려고 합니다." 리드가 잠깐 멈추더니 "이유가 뭔지 물어봐도 될까?"라고 했다. 솔직하게 말했다. 성장 환경, 연봉, 새로운 도전. 리드가 고개를 끄덕이면서 "이해한다. 카운터 오퍼를 줄 수 있는지 확인해볼게"라고 했다.

카운터 오퍼가 나왔다. 연봉 15% 인상에 팀 이동까지 제안. 솔직히 흔들렸다. 이미 적응한 곳에서 더 나은 조건으로 일할 수 있다는 건 매력적이었다. 근데 주변 경험담을 들어보면 카운터 오퍼를 받고 남은 경우 대부분 6개월 안에 또 이직을 고민하더라. 근본적인 이유가 해결되지 않으면 조건만 바꿔봐야 같은 고민이 반복된다.

결국 원래 계획대로 이직했다. 퇴사까지 인수인계 기간 한 달. 그 한 달이 묘한 시간이었다. 떠나는 사람이니까 새 프로젝트에 투입되지 않고, 기존 작업 정리와 문서화만 했다. 팀원들한테 "잘 가"라는 말을 들을 때마다 이상한 감정이 올라왔다.

지금 이직을 고민하는 분에게#

한 가지만 말하고 싶다. 이직 준비는 이직을 결정한 후에 시작하는 게 아니라, 평소에 해놓는 거다. 이력서에 쓸 만한 경험을 의식적으로 쌓고, 작업 결과를 수치로 기록하고, 기술 블로그든 뭐든 내 이름으로 된 결과물을 만들어놓으면 나중에 훨씬 수월하다. 나는 이걸 이직 준비하면서 뒤늦게 깨닫고 후회했다.

그리고 면접은 연습이 필요하다. 코딩 테스트도, 기술 면접도, 인성 면접도. 준비 없이 들어가면 아무리 실력이 있어도 제대로 보여주지 못한다. 나는 첫 면접에서 긴장해서 아는 것도 제대로 못 말했다. 두 번째부터 좀 나아졌고, 세 번째에는 편하게 대화할 수 있었다.

이 글을 쓰면서 전 회사가 좀 그립다. 그 회사가 싫어서 나온 게 아니니까. 결국 이직이라는 건 "더 나은 곳으로 가는 것"이 아니라 "다른 곳에서 새로운 걸 경험하는 것"에 가까운 것 같다.