이직을 고민할 때 확인할 것 — 지금 자리에서 남은 것이 있는가

불만 목록으로는 판단이 안 된다

이직을 고민할 때 대개 불만부터 떠오른다. 급여, 사람, 업무, 문화. 그런데 이 목록만으로는 판단이 어렵다. 옮기면 해결되는 것과 어디서나 겪는 것이 섞여 있기 때문이다.

먼저 나눠본다.

| 유형 | 예 | 이직으로 해결? |

|---|---|---|

| 구조적 | 급여 수준, 기술 스택, 도메인 | 대체로 해결됨 |

| 관계적 | 특정 인물과의 갈등 | 부분적 (새 조직에도 사람은 있다) |

| 보편적 | 반복 업무, 일정 압박 | 대개 어디든 있음 |

구조적 항목이 주된 이유라면 이직이 유효한 수단이다. 보편적 항목만 있다면 옮겨도 같은 상황이 반복될 가능성이 높다.

성장 곡선으로 보기

더 실용적인 기준은 지금 자리에서 배울 것이 남았는가이다.

• 최근 6개월에 새로 익힌 것이 있는가
• 앞으로 1년 안에 맡을 수 있는 새 영역이 보이는가
• 지금 하는 일을 다른 사람이 대체할 수 있는가 (역으로, 내가 대체 불가능한 영역에 갇혀 있지는 않은가)

첫 두 항목이 모두 아니라면, 자리를 옮기는 것이 성장 측면에서 합리적이다.

옮기기 전에 해볼 것

같은 조직 안에서 시도할 수 있는 것이 남아 있는 경우가 있다.

• 다른 팀·프로젝트로의 이동 요청
• 지금 없는 역할을 제안 (문서화, 인프라 개선, 온보딩 정비)
• 관심 영역의 작은 개선을 스스로 시작

이런 시도는 실패해도 손해가 적고, 성공하면 이직 비용 없이 상황이 바뀐다. 또 시도 자체가 다음 이직에서의 이야깃거리가 된다.

준비 순서

이직을 결정했다면 순서가 있다.

1. 기록 정리 (1주)

지금까지 한 일을 먼저 정리한다. 시간이 지나면 세부가 사라진다.

```

프로젝트 / 역할 / 규모 / 사용 기술 / 결과(가능하면 수치)

```

2. 이력서·포트폴리오 (2~3주)

정리한 기록을 바탕으로 작성한다. 저장소 정리도 이 단계에서.

3. 지원과 면접 (1~3개월)

재직 중 진행하는 것이 협상력 면에서 유리하다.

이력서에서 자주 빠지는 것

• 규모 정보 — "결제 시스템 개발"보다 "일 거래 N건 규모의 결제 모듈 개발"
• 역할 구분 — 팀 성과와 자기 기여를 나누어 서술
• 결과 — 무엇을 만들었는지뿐 아니라 무엇이 달라졌는지
• 판단 근거 — 왜 그 기술·설계를 택했는지

마지막 항목이 면접에서 가장 많이 파고드는 지점이다. 이력서에 한 줄이라도 있으면 대화가 그쪽으로 흐른다.

잦은 이동에 대해

짧은 재직이 반복되면 설명을 요구받는다. 문제는 이동 자체가 아니라 패턴이 반복될 것으로 보이는가이다.

각 이동에 납득 가능한 이유가 있고 그것을 설명할 수 있으면 대개 넘어간다. 반대로 "안 맞아서"만 반복되면 다음도 같을 것으로 읽힌다.

결정 전에 확인할 것

옮길 곳에 대해 확인할 항목:

• 실제로 맡을 업무 (공고 문구가 아니라 구체적 내용)
• 팀 구성과 규모
• 코드 리뷰·배포 주기 등 실제 개발 문화
• 지금 자리에서 아쉬웠던 항목이 그곳에서는 어떤지

면접은 평가받는 자리이자 확인하는 자리다. 질문 기회를 형식적으로 넘기면 확인 없이 결정하게 된다.

최종 수정 2026-08-28