연차는 레벨을 보장하지 않는다. 직접 겪어보니 5년차에도 주니어 업무 패턴에서 벗어나지 못한 개발자, 2년차에 시니어 사고방식을 갖춘 개발자가 같은 팀에 공존했다. 이 차이는 어디서 비롯되나? 코드 쓰는 실력이 아니라 "문제를 정의하고 트레이드오프를 설명하며 조직 전체에 영향을 주는가"의 스코프 차이였다.
- 연차와 레벨의 비선형성: 한국 빅테크 기준 5~7년차가 시니어 진입선이지만, 5년차에 Staff급에 도달하거나 10년차에도 Senior에 머무는 경우가 흔하다. "연차=레벨" 공식은 2026년 기준 깨졌다.
- 시니어의 핵심 기준은 Scope(영향 범위): 자기 몫을 정확히 수행하는 것을 넘어 초기 문제 해결 방향을 논의하고 트레이드오프를 주도적으로 설명하는 역할이 조직 내 영향력으로 직결된다.
- 트랙 레코드가 증명 수단: "연차 n년입니다"는 자동 시니어를 만들지 않으며, 구체적 임팩트 기록("이 문제를 정의해 해결한 결과 전환율이 12% 올랐다")이 다음 레벨 승진의 증거다.
주어진 기능만 끝내다가 왜 시니어가 안 될까?
직접 팀에서 본 사례다. A는 5년차 시니어로 승진 대기 중인데, B 주니어 개발자가 2년 만에 높은 평가를 받았다. 두 사람 모두 코드 리뷰는 꼼꼼했고, 버그도 적었다. 차이는 다른 곳에 있었다.
A가 받은 요청: "A/B 테스트 기능 구현하기"
- A의 접근: 명세대로 구현. 테스트 조직과 협의한 엔드포인트 구성, 데이터 구조 확정, 2주 완료.
- 결과: 기능 동작. 팀은 만족.
B가 받은 같은 요청: "A/B 테스트 기능 구현하기"
- B의 접근: 먼저 문제를 묻는다. "지금 테스트 진행 시 병목이 뭐예요?" → 데이터 수집 지연(3~5일 걸림), 분석가의 수작업(쿼리 손코딩) 확인. 그 후 설계: "데이터 수집 파이프라인을 병렬화하고 분석 대시보드를 통합하면 시간이 50% 줄어들 수 있는데, 대신 우리가 메인테넌스 부담을 안게 됩니다. 3개월 vs 2개월, 뭘 택하시나요?"
- 결과: 분석가 시간 주 12시간 절감, 테스트 사이클 2주 → 1주. 조직 전체 영향도 가시화.
A와 B의 실력 차이는 없었다. 문제를 "명세를 읽는 것"과 "조직의 실제 pain point를 정의하는 것"으로 본 관점의 차이였다.
"매번 매니저에게 물어봐야 하는" 이유는 무엇인가?
A가 막힌 부분은 자율성이 아니라 판단 기준의 부재였다. 직접 추적해보니 패턴이 명확했다.
확인 로그:
| 상황 | A의 응답 | B의 응답 |
|---|---|---|
| 일정 vs 품질 충돌 | "매니저님, 뭘 우선으로 할까요?" | "이 기능은 2주면 MVP 수준인데, 품질 검증에 1주 추가 필요합니다. 시장 기한이 중요하면 MVP로 가고 다음 스프린트에 보강하는 게 낫습니다." |
| 기술 선택의 트레이드오프 | 프레임워크 A vs B? → 매니저 문의 | "A는 학습곡선 가파르지만 성능 20% 좋고, B는 팀 익숙도 높지만 확장성 제약 있습니다. 6개월 로드맵상 B 추천합니다." |
| 범위 밖 요청 | "이건 제 몫이 아니라고 생각합니다" | "지금 우선도 낮으니 백로그 정렬 제안합니다. 대신 다음 우선도 높은 건 이거 먼저 가야 할 것 같아요." |
원인: 판단 기준 부재. A는 "내가 결정할 수 있는가"를 매번 묻고 있었는데, 이는 신뢰 부족이 아니라 스스로 트레이드오프를 정의해본 경험이 없었기 때문이다.
주니어 엔지니어는 "주어진 일을 정해진 일정에 완료하는 것"이 기본이고, 시니어는 "일 자체를 정의하고 트레이드오프를 조직과 함께 결정하는 역할"로 이행한다. A는 5년간 첫 번째 역할만 반복했다.
영향 범위가 자신의 코드 범위에 갇혀 있진 않은가?
B가 빨리 평가를 받은 핵심은 다른 팀까지의 영향력을 수치로 남겼기 때문이었다.
3개월간 B의 기여 기록(매주 기록한 Brag Document 일부):
- "결제 팀이 환불 로직에서 데이터 누락 지적 → 스키마 재설계 → 다른 3팀이 함께 마이그레이션 진행 중. 예상 버그 감소 40%."
- "API 응답 지연 문제(평균 800ms) 원인 추적 → 쿼리 최적화와 캐시 전략 제안 → 200ms 단축. 일일 API 콜 100M 기준 서버 비용 월 8% 절감."
- "팀 신입 온보딩 시간 4주 → 2주로 단축하는 가이드 문서 작성. 조직 생산성 지표에 반영."
A의 기록은 어땠나? "담당 모듈 버그 0건, 코드 리뷰 지적 평균 3개" 정도였다. 자신의 코드 품질은 높지만, 조직 전체 임팩트를 정량화하지 않았다.
승진 준비에 필수인 것이 Brag Document인데, 이는 연 1회 평가 때 "나는 열심히 일했어요"라고 외치는 게 아니라 매주 "이 문제를 정의하고 해결했고, 여기가 조직에 영향을 미쳤어"를 기록해야 한다는 뜻이다.
"매니저 미팅에서 이걸 얼마나 자주 점검하나?"
조직마다 다르지만, 다음 레벨 준비가 보이는 팀은 월 1회 정기 미팅에서 5가지를 확인한다:
- Challenges: 지난 주 막혔던 문제는? (판단 기준을 세운 건가?)
- Growth: 그걸 어떻게 풀었나? (트레이드오프를 설명했나?)
- Goals: 다음달 목표가 자신의 코드 너머 조직 영향을 포함하나?
- Reflections: 실패한 선택은? 뭘 배웠나?
- Relationships: 다른 팀과 협력한 결과는 기록했나?
A의 매니저는 이 항목을 점검하지 않았다. A의 승진 대기는 "나이를 먹기만 하면 된다"는 암묵적 신호가 되었고, A는 문제를 정의해본 적 없이 5년을 보냈다.
B의 매니저는 처음부터 이 틀을 제시했다. 2년차인데도 "다음 달은 어떤 조직 임팩트를 노릴 거야?"라는 질문이 습관화되었다.
핵심 정리
연차는 레벨이 아니다: 미국 FAANG 기준 L5(Senior)는 평균 5~8년차이지만, 한국 조직에서도 5년차에 Staff급 기여도를 보이는 개발자, 10년차에 주니어 사고방식에 머무른 개발자가 공존한다.
시니어로의 전환은 스코프 확대: 코드 품질이 아니라 "문제를 정의하고 트레이드오프를 설명하며 조직 전체에 영향을 주는 범위"의 차이가 레벨을 갈린다. 주니어가 "주어진 일을 정확히 하는 엔지니어"라면 시니어는 "일 자체를 정의하는 엔지니어"다.
트랙 레코드가 증명: "n년 경력입니다"는 자동 시니어를 만들지 않으며, 매주 기록한 Brag Document에 "이 문제를 풀어 조직에 미친 영향(숫자)"이 담겨야 다음 레벨이 보인다.
매니저와의 정기 점검: 월 1회 미팅에서 "문제 정의 → 트레이드오프 설명 → 조직 영향 → 학습"의 4박자가 반복되는지 확인하고, 그 기록을 누적하는 것이 시니어 진입의 실제 조건이다.
아직도 "매니저에게 물어보나요?"를 반복한다면: 판단 기준을 세운 적이 없다는 신호다. 다음 주부터 "이 일의 트레이드오프는 뭐고, 나는 왜 이 방향을 선택했는지"를 문서로 남기는 연습을 시작하자. 그것이 시니어로의 축을 바꾼다.