이직 협상에서 밴드 하단 오퍼를 받는 진짜 원인은 뭘까?
결론부터: 협상이 실패하는 지점은 대개 "협상 테이블"이 아니라 그 이전, 이력서·경험 면접에서 내가 만든 신호가 이미 약했던 순간이다. 면접관이 검증할 수 있는 수치를 내가 안 줬으면, 협상 테이블에서 그 수치를 되살릴 방법은 없다. 이 글은 2025년 한 이직 과정에서 밴드 하단 오퍼를 받은 사례를 장애 회고 형식으로 복기한 기록이다.
핵심 정리
- 오퍼 금액은 협상 스킬보다 이전 전형에서 압축된 "신호의 밀도"로 거의 결정된다.
- 코딩테스트 통과는 필터 통과일 뿐, 보상 근거가 되지 않는다. 운영 문제 해결 증거가 보상 근거다.
- 경험 면접 답변에 전후 수치·측정 기간이 없으면 직급·레벨 조정 근거로 쓰이지 못한다.
- 협상은 총액 1개가 아니라 기본급·사인온·주식·직급·입사일로 쪼개서 진행해야 레버리지가 생긴다.
- HackerRank 2025 설문에서 응답자 78%가 채용 평가와 실제 업무가 안 맞는다고 답했다는 점은, 전형 통과와 보상 수준이 자동으로 연결되지 않는다는 뜻이기도 하다.
장애 상황: 코딩테스트·시스템 디자인·경험 면접을 전부 통과했는데 왜 밴드 하단이었나?
세 전형 모두 "통과" 판정을 받았는데 최종 오퍼는 공고된 밴드의 하단 근처였다. 코딩테스트는 제한 시간 내 풀이, 시스템 디자인은 캐시·메시지 큐 구조 설계까지 무리 없이 설명했고, 경험 면접에서도 장애 대응 사례를 이야기했다. 그런데 채용 담당자와의 오퍼 콜에서 "레벨은 책정된 대로 가고, 기본급은 밴드 중간대까지는 어렵다"는 답이 돌아왔다. 통과와 보상이 분리된다는 걸 이 시점에야 체감했다.
1차 가설: 코딩테스트 통과가 보상 근거가 될 거라 생각한 게 문제였나?
맞다. 코딩테스트는 운영 역량의 증거가 아니라 기본기 필터라는 걸 과대평가했다. HackerRank 조사에서는 응답자의 56%가 알고리즘형 질문이 실제 직무와 무관하다고 답했는데, 이는 면접관 쪽에서도 코딩테스트 결과를 보상 근거로 쓰지 않는다는 신호로 읽을 수 있다. 실제로 오퍼 콜에서 담당자가 참고한 건 코딩테스트 점수가 아니라 경험 면접에서 언급한 "운영 중 장애를 줄인 사례"였다. 그런데 그 사례를 숫자 없이 "장애가 줄었다"로만 말했다는 게 다음 문제였다.
2차 가설: 경험 면접 답변에 숫자가 없어서 레벨 조정 근거가 안 된 건 아닐까?
이게 핵심 원인이었다. 당시 답변은 "배포 후 장애가 잦았는데 원인을 찾아서 고쳤고 이후 안정화됐다" 수준이었다. 상황·과제·행동까지는 말했지만 결과를 수치로 못 박지 못했다. 권장되는 구조는 "2025년 3월, 서비스 버전 X에서 p95 지연시간을 Yms에서 Zms로 낮췄고, 부하 테스트 조건은 N RPS·M개 요청 패턴이었다"처럼 전후 수치와 측정 조건을 함께 붙이는 방식인데, 이 조건이 빠지면 면접관 입장에서 "이 사람이 어느 규모 문제를 풀었는지" 추정할 근거가 사라진다. 시스템 디자인에서 캐시 적중률이나 복제 지연 같은 용량 지표를 짚었던 것과 달리, 정작 본인 경험담에는 측정값이 없었다.
재현해보니 무엇이 확인됐나?
이후 다른 회사 면접에서 같은 장애 대응 사례를 숫자를 붙여 다시 말해봤다. "장애가 줄었다" 대신 "배포 빈도 주 1회에서 일 3회로 늘리면서도 롤백률을 특정 분기 대비 낮췄고, 알림 건수를 줄였다"는 식으로 측정 기간과 기준선을 명시했다. 담당자 반응이 달라졌다기보다, 다음 라운드에서 "그 경험을 레벨 심사 자료로 넘기겠다"는 말을 들었다는 게 재현된 차이였다. 이력서에 넣는 수치도 트래픽·지연시간·오류율·배포 빈도·비용 절감 중 측정 기간과 기준선을 같이 적은 항목만 다음 단계로 이어졌다. 숫자 자체보다 "언제, 무엇 대비, 어떻게 측정했는지"가 신호의 핵심이었다.
재발 방지로 뭘 바꿨고 어떤 지표로 확인했나?
경험 사례를 상황·과제·행동·결과·회고 다섯 칸짜리 표로 미리 작성해두고, 결과 칸에는 반드시 전후 수치와 측정 기간을 채우는 것으로 바꿨다. 회사 기밀 수치는 절대값 대신 상대 변화율이나 범위로 표현했다. 협상 전 준비표도 분리했다. 현재 보상(기본급·성과급·주식·복지), 희망 보상(목표값·최소 수용값), 시장 기준, 대체안(기본급이 안 되면 사인온·주식·직급), 근거(성능 개선·비용 절감 수치), 제약(미베스팅 주식·퇴사 일정)을 각각 칸으로 나눴다. 이렇게 바꾼 뒤 진행한 다음 이직에서는 기본급 협상이 막힌 지점에서 사인온 보너스와 입사 시점을 별도 항목으로 제안했고, 적어도 "항목이 쪼개져서 논의된다"는 변화는 확인했다. 금액이 항상 올라간다고 단정할 근거는 없지만, 적어도 "기본급 안 된다"로 대화가 끝나지 않았다.
전체 과정에서 기본값으로 삼을 교훈은 뭘까?
협상 테이블에 앉기 전에 이미 승부가 반 이상 갈린다는 걸 기본값으로 둬야 한다. 이력서는 수치와 측정 기간을 압축한 문서, 경험 면접 답변은 상황-과제-행동-결과-회고 구조로 전후 수치를 채운 자료, 시스템 디자인은 용량 산정 근거, 코딩테스트는 설명력 훈련이라는 역할 구분을 미리 해두는 게 먼저다. 그 위에서야 협상 항목을 기본급·사인온·주식·직급·입사일로 쪼개는 전술이 의미를 가진다. 참고로 levels.fyi 2025년 자료는 미국 소프트웨어 엔지니어의 중위 총보상을 엔지니어 22.6만 달러, 시니어 31.2만 달러, 스태프 45.7만 달러로 집계했는데, 이건 한국 채용시장에 직접 적용할 수 없는 참고값일 뿐이고, 직급 간 격차가 결국 "어떤 규모 문제를 풀었는지"에 대한 증거 차이에서 갈린다는 구조만 참고할 만하다. 2026년 기준으로 전형 흐름 자체는 onehour.digital 자료가 정리한 이력서-코딩평가-라이브코딩-시스템디자인-경험면접 순서에서 크게 벗어나지 않았다.
핵심 정리
- 오퍼 금액 격차는 협상 테이블이 아니라 이력서·경험 면접 단계에서 이미 벌어진다.
- 코딩테스트 통과는 필터 통과이지 보상 근거가 아니다. HackerRank 조사의 56% 응답이 이를 뒷받침한다.
- 경험 면접 답변은 반드시 전후 수치와 측정 기간을 붙여야 레벨·보상 근거로 전환된다.
- 협상 준비는 현재 보상·희망 보상·시장 기준·대체안·근거·제약을 표로 분리해 들어가야 한다.
- 오퍼는 총액 하나가 아니라 기본급·사인온·주식·직급·입사일 항목으로 쪼개서 다뤄야 레버리지가 생긴다.