
지난주 동기 모임에서 "아직도 거기 있어요?"라는 말을 들었습니다. 웃으며 넘겼는데, 집에 와서 6년치 손익계산서를 진짜로 펼쳐보게 되더라고요.
개발자 평균 재직기간이 글로벌 3.5년 안팎이라고 알려져 있고, 한국 IT는 그보다 더 짧다는 이야기가 자주 잡힙니다(원티드 2025 개발자 리포트 등에서 비슷한 흐름이 보입니다). 그 기준에서 보면 6년은 통계적 예외예요. "안주한 거 아니냐"는 시선이 따라붙는 자리이기도 합니다.
근데 감정으로 답하면 끝이 안 나더라고요. 그래서 자산과 부채로 나눠서 진짜 숫자를 쳐봤습니다.
한 회사 오래 다니는 개발자가 쌓은 자산 3가지
첫 번째는 도메인 지식이에요. 신규 입사자가 3개월 걸려야 파악할 수 있는 결제 모듈의 예외 처리 히스토리를, 저는 30분이면 설명할 수 있습니다. 6년차쯤 되면 "왜 이 코드가 이렇게 생겼는지"를 아는 사람이 사내에 손에 꼽는 경우가 많거든요.
두 번째는 신뢰 자본입니다. 결제 모듈 구조 변경 같은 큰 의사결정에 제 의견이 거의 매번 끼더라고요. 신입이 비슷한 의견을 내도 회의 분위기가 다르게 흐릅니다. 이게 결국 원하는 프로젝트를 골라서 끌고 갈 권한으로 이어지더라고요.
세 번째는 누적 보상이에요. 우리사주, 장기근속 인센티브, 베스팅된 RSU 같은 게 6년차쯤 되면 연봉 외 보상으로 묵직하게 쌓입니다. 1~2년차에 이직했으면 이 부분은 통째로 날아갔을 항목이지요.

개발자 이직 안 한 6년의 부채 — 잃어버린 1.5억과 좁아진 시야
여기서 멈추면 자기합리화입니다. 부채도 정직하게 적어야 손익계산서가 되는 거예요.
이직 사유로 "더 높은 연봉·커리어 기회"가 1위 자리에 거의 늘 잡힙니다. 같은 기간 두 번 이직하면서 점프당 평균 15~20% 정도의 연봉 상승을 받았다고 가정하면, 누적 1.5억 정도의 프리미엄을 더 챙겼을 거라는 계산이 나오더라고요. 1.5억이 어느 정도냐면, 사회초년생 연봉 3년치를 통째로 더 받았을 양이에요. 복리로 굴렸을 시점까지 따지면 격차는 더 벌어집니다.
두 번째 부채는 기술 스택 편중입니다. 사내 표준이 Spring + Oracle이다 보니 코틀린(Kotlin), Go 같은 최신 스택을 실무로 다룰 기회를 거의 못 받았어요. 사이드 프로젝트로 메꿔 보긴 했지만, "실서비스에서 굴려본 6년" 만큼의 무게는 안 나오는 것 같습니다.
세 번째 부채가 제일 무서워요. 시야가 좁아진다는 점이에요. "우리 회사는 원래 이렇게 한다"가 표준값으로 박혀버립니다. 외부 인터뷰 한 번 안 보면, 시장에서 통용되는 깊이인지 사내에서만 통하는 레거시 지식인지 스스로 구분을 못 하게 됩니다.

장기근속 정체를 피하려 시도한 헤지 세 가지
부채를 알면 헤지를 칠 수 있습니다. 6년 동안 제가 시도한 건 세 가지였습니다.
- 분기마다 외부 채용에 한 번씩 지원해봅니다. 합격을 노리는 게 아니라, 제 지식이 시장에서 통용되는 깊이인지 점검하는 용도예요.
- 사내에서 팀을 두 번 옮겼습니다. 결제 → 정산 → 데이터 순서였는데, 도메인 연속성은 유지하면서 기술과 사람을 바꿨어요. 절반의 이직 효과는 분명히 봤습니다.
- AI 시대에 값이 오를 자리에 베팅했습니다. 사내 RAG 파일럿에 자원했는데, LLM이 모방하기 어려운 게 결국 깊은 도메인 지식이라는 판단이었어요.
개인적으로는 이 세 가지가 없었다면 6년 잔류가 그냥 안주로 굳었을 거라고 봅니다. 잔류 자체가 자산이 되는 게 아니라, 잔류 안에서 무엇을 했느냐가 자산을 만드는 거예요.

한 회사 6년 손익계산, 결국 매년 갱신해야 하는 표
미국 Atlanta Fed Wage Growth Tracker 2025년 7월 데이터에서 장기근속자 임금상승률(4.1%)이 이직자(4.0%)를 앞질렀습니다. 2010년 9월 이후 처음 벌어진 역전이고, 한 번 튄 게 아니라 2025년 2월부터 6개월째 stayers가 앞서는 상태로 굳어지고 있어요. 한국 통계는 아니지만, "잡호핑 프리미엄"(이직으로 받는 연봉 점프 보너스)이 항상 답인 시대가 흔들리고 있다는 신호로 읽힙니다.
다만 잔류가 자산이 되려면 세 조건이 같이 굴러가야 한다고 봅니다. 회사가 성장하고 있고, 본인이 의사결정에 점점 더 깊이 들어가고 있고, 그 도메인이 시장에서도 통용되는가. 하나라도 빠지면 잔류는 자산이 아니라 부채로 빠르게 전환되는 경우가 많아요.
그래서 저는 스스로에게 매년 한 문장을 묻고 있습니다. "앞으로 6개월 안에 지금보다 더 높은 단계의 의사결정에 들어갈 수 있는가." Yes면 1년 더 잔류, No면 짐 싸는 겁니다. 손익계산서는 한 번 그리고 끝나는 게 아니라 매년 새로 그리는 표라는 게, 6년차에 도달해서 가장 또렷해진 결론이지요.
저는 그래서 7년차에도 이 자리에 있을 가능성이 큽니다. 이직이 답이 아니라서가 아니라, 올해의 손익계산서가 아직 잔류 쪽으로 한 칸 기울어 있어서예요. 다음 글에서는 이 매년 갱신표를 어떤 항목으로 채우는지, 제가 실제로 쓰는 양식을 풀어볼 생각입니다.

'개발 일지' 카테고리의 다른 글
| 6년차 개발자가 매번 검색하는 코드와 절대 안 까먹는 것들 (0) | 2026.07.12 |
|---|---|
| 샤워하다 해법이 떠오른다면, 당신은 퇴근에 실패한 겁니다 (0) | 2026.07.11 |
| 주니어 멘토링 1년, 가르치다 시니어 개발자가 더 배운 5가지 (0) | 2026.07.10 |
| Kotlin/Wasm 증분 컴파일로 바뀐 KMP 빌드, 6.8초의 일주일 (0) | 2026.06.18 |
| 안드로이드 17 정식 출시 D-1, 6년차가 베타 한 시즌을 돌아보며 (0) | 2026.06.15 |