이직을 생각하는 개발자들과 이야기를 나눠보면, 처음에는 대부분 “연봉 때문에”라고 운을 뗀다. 그런데 조금 더 깊이 들어가다 보면 금세 다른 이야기들이 나온다. 코드 리뷰가 없다, 배포를 내 마음대로 할 수 없다, 팀장이 기술 결정을 혼자 다 내린다, 반기마다 하는 일이 똑같다. 연봉은 그냥 방아쇠였을 뿐, 진짜 탈출 이유는 따로 있었던 것이다. 이직 결정이 단순히 숫자 협상이 아니라는 걸 알면서도, 막상 “그래서 어떤 기준으로 결정해야 하나요?”라는 질문 앞에서 막히는 개발자가 많다. 이 글은 그 질문에 대한 실용적인 답을 정리하려 한다.
연봉이 방아쇠인 이유: 불만족의 표면만 보지 않기
연봉이 이직의 가장 흔한 출발점인 건 사실이다. 시장 평균보다 낮다는 체감, 동료보다 내가 더 많이 하는 것 같다는 느낌, 연봉 협상 자리에서 “올해도 어려워요”를 반복해서 들은 경험. 이런 것들이 쌓이면 이직 사이트를 뒤지기 시작한다. 그러나 연봉만으로 회사를 옮긴 사람들 중 상당수는 1~2년 안에 다시 비슷한 불만을 느끼게 된다. 돈을 받긴 했는데 여전히 성장하는 느낌이 없고, 코드는 더 엉망이고, 회의는 더 많다.
연봉은 현재 상황을 참기 어렵게 만드는 요인이지, 그 자체가 이직의 ‘이유’인 경우는 생각보다 드물다. 연봉이 낮다고 느끼는 순간, 한 번 더 물어봐야 한다. “연봉만 맞으면 지금 회사에 계속 다닐 수 있나?” 이 질문에 선뜻 “예스”가 나오지 않는다면, 연봉 이외의 무언가가 더 근본적으로 작동하고 있는 것이다.
기술 성장 환경: 지금 나는 배우고 있는가
개발자가 이직을 결정할 때 실질적으로 가장 많이 언급하는 이유 중 하나는 ‘더 이상 배울 게 없다’는 느낌이다. 정확히는, 업무가 반복적이고 기술적 도전이 없으며, 코드베이스가 레거시 그 자체인 상황이다. 매일 같은 방식으로 같은 문제를 해결하는 게 1년, 2년, 3년째 이어지고 있다면, 그 사람이 성장하고 있을 가능성은 낮다.
다음 회사를 고를 때 확인해야 할 것들은 이런 것들이다.
- 코드 리뷰 문화가 실제로 존재하는가? 리뷰가 형식적 승인인가, 아니면 실질적 피드백인가?
- 기술 부채를 인식하고 줄이려는 노력이 있는가?
- 새로운 기술 도입 결정에 개발자가 참여할 수 있는가?
- 사이드 프로젝트, 컨퍼런스, 스터디에 대해 회사 분위기가 열려 있는가?
면접에서 “저는 성장할 수 있나요?”라고 직접 물어보는 것도 좋지만, 더 구체적으로 물어야 한다. “최근에 기술 스택을 바꾼 사례가 있나요?”, “개발팀 내에서 가장 최근에 도입한 새로운 관행이 뭔가요?”처럼 사실 기반 질문을 하면 진짜 문화를 가늠할 수 있다.
자율성과 결정권: 내 코드가 내 것인가
개발자가 가장 소진되는 환경 중 하나는 자신이 작성한 코드와 설계에 대한 결정권이 없는 경우다. 기획이 이미 다 정해진 상태로 내려오고, 개발자는 구현만 하면 되는 구조. 아키텍처 선택도 라이브러리 도입도 위에서 결정하고, 의견을 내도 반영되지 않는다. 이런 환경에서는 일 자체의 의미를 찾기 어렵다.
반대로, 자율성이 주어진 환경에서는 같은 연봉이라도 훨씬 오래, 더 즐겁게 일한다는 이야기를 자주 듣는다. 기술 결정에 참여할 수 있고, 코드 구조에 의견을 낼 수 있고, 마감 일정 협상에서도 목소리를 낼 수 있을 때, 개발자들은 자신을 ‘실행자’가 아닌 ‘설계자’로 느낀다. 이 차이는 월급 몇십만 원보다 훨씬 큰 동기 차이를 만든다.
다음 회사를 알아볼 때는 이렇게 물어볼 수 있다. “개발팀이 기술 의사결정에 어느 정도 관여하나요?”, “최근에 개발자 제안으로 실제로 반영된 변화가 있었나요?” 구체적인 사례를 요청하면 된다. 모호하게 “물론이죠”라고만 답하는 곳보다, 실제 사례를 바로 꺼내는 곳이 더 신뢰할 수 있다.
팀과 동료: 함께 일하는 사람이 성장에 미치는 영향
주변에 누가 있느냐는 개발자의 성장 속도에 결정적인 영향을 미친다. 잘 정리된 PR을 작성하는 동료, 코드 리뷰에서 날카롭고 건설적인 피드백을 주는 선배, 장애 상황에서 체계적으로 디버깅하는 팀원. 이런 사람들과 함께 일하면 본인이 의식하지 못해도 자연스럽게 수준이 올라간다. 반대로, 코드 품질에 무관심하고 “그냥 돌아가면 되지”가 팀 문화인 곳에서는 아무리 의욕 있는 사람도 수준이 정체되거나 낮아진다.
이직할 때 동료를 평가하는 건 어렵게 느껴지지만, 몇 가지 방법이 있다. 면접 전후에 해당 회사의 기술 블로그를 찾아보거나, GitHub 오픈소스 기여 이력이 있는 팀원을 검색해보거나, LinkedIn에서 팀원들의 경력 흐름을 확인하는 것이다. 또는 면접 과정에서 함께 일할 개발자를 직접 만날 기회를 요청할 수도 있다. “팀원 한 분과 짧게 이야기를 나눌 수 있을까요?”라고 요청하는 건 무례한 게 아니라 진지한 지원자라는 신호로 읽힌다.
반대로, 현재 팀이 마음에 들지 않아 이직을 고민하는 경우라면, ‘팀 전체’가 문제인지 ‘특정 인물’이 문제인지 구분하는 게 먼저다. 팀원 전체가 아니라 관리자 한 명 때문에 좋은 팀을 떠나는 건, 이직 후에 후회할 가능성이 있다.
커리어 경로: 지금 회사에서 3년 뒤가 보이는가
이직을 고민하게 만드는 또 다른 요인은 미래가 안 보인다는 것이다. 지금 직급에서 다음 단계로 가는 경로가 불분명하거나, 올라가도 하는 일이 크게 다르지 않거나, 승진이 연차 순서로만 이루어지는 환경. 이런 곳에서는 노력이 성과로 연결되는 느낌이 없다.
좋은 커리어 경로가 있다는 게 반드시 빠른 승진을 의미하지는 않는다. 기술 전문가 트랙(IC: Individual Contributor)이 존재하고, 관리자가 되지 않아도 시니어→스태프→프린시펄로 성장할 수 있는 구조가 있는 곳, 또는 도메인 전문성을 쌓아 특정 분야에서 팀의 핵심 인물이 될 수 있는 환경이 있는 곳이 개발자에게는 의미 있다.
이직 면접에서는 이렇게 물어볼 수 있다. “현재 팀에서 5년 이상 된 개발자가 있나요? 그분들은 어떤 역할을 맡고 있나요?” 이 질문 하나로 장기 근속이 가능한 환경인지, 빠른 소비 후 교체가 반복되는 구조인지 어느 정도 가늠할 수 있다.
이직을 결정하기 전에 스스로에게 물어볼 세 가지
이직 결정은 외부 환경만큼이나 자기 자신에 대한 이해에서 출발해야 한다. 막연한 불만족 상태에서 서두르면, 새 회사에서 비슷한 문제를 또 만나게 된다. 이직을 진지하게 고민하고 있다면, 아래 세 가지 질문에 솔직하게 답해보자.
- 지금 불만족의 원인이 명확한가? — “팀 문화가 안 맞는다”는 막연한 진단보다 “코드 리뷰 없이 PR이 그냥 머지되는 게 나는 수용하기 어렵다”처럼 구체적으로 쓸 수 있어야 한다. 구체적이어야 다음 회사에서 같은 문제를 피할 수 있다.
- 지금 회사에서 할 수 있는 변화의 여지는 다 써봤는가? — 팀 이동, 프로젝트 변경, 직접 대화 등 내부에서 해결할 여지가 남아 있다면 먼저 시도해보는 게 맞다. 그리고도 안 된다면, 이직 결정에 더 확신이 생긴다.
- 다음 회사에서 원하는 것이 구체적인가? — “좋은 회사에 가고 싶다”가 아니라, “코드 리뷰 문화가 정착된 팀, 기술 결정에 개발자가 참여하는 구조, 사이드 프로젝트에 우호적인 분위기”처럼 체크리스트가 있어야 한다. 이 리스트를 면접 질문으로 전환할 수 있을 때 준비가 된 것이다.
이직은 단순히 더 나은 연봉을 찾는 과정이 아니다. 지금 내가 어떤 환경에서 일하고 싶고, 어떤 방식으로 성장하고 싶고, 어떤 사람들과 함께하고 싶은지를 정리하는 과정이다. 그 답이 명확해질수록 이직 결정도, 이직 후 적응도 훨씬 수월해진다.
이직 결정의 기준을 혼자 정리하기 어렵다면, 누스쿨 커뮤니티에서 비슷한 고민을 한 선배 개발자들의 이야기를 들어보거나, 멘토링을 통해 본인의 상황에 맞는 조언을 받아볼 수 있다. 막연한 불만을 구체적인 방향으로 전환하는 데, 혼자보다 한 번의 대화가 더 빠를 때가 많다.
💬 댓글 0