1~3년 차 이직은 꽤 미묘한 단계예요.
내가 처음 업계에 들어왔을 때 사수 분이 해준 말이 있는데, 지금 생각해도 맞는 말이에요: "1~3년 차를 뽑을 때 면접관이 사는 건 네 경험이 아니라 네 성장 가능성이야. 이직하려는데 이력서가 신입 때랑 똑같아 보이면, 왜 2년 치 연봉을 더 줘야 하겠어?"
좀 직설적인 표현이긴 한데, 논리는 맞아요. 1~3년 차는 '내가 실제 업무 환경에서 문제를 해결할 수 있다'는 걸 증명하는 단계예요. '내가 무엇을 배웠는지'를 증명하는 단계가 아니에요.
이 단계에서 가장 자주 보이는 문제들을 하나씩 뜯어볼게요.
문제 1: 이력서가 여전히 "일 배정받은 대로 함" 수준
이게 1~3년 차 이력서에서 가장 보편적인 문제예요. 대충 이런 식이에요:
제품 요구에 따라 백엔드 API 개발.
코드 리뷰에 참여하고, 온라인 버그 수정.
기술 문서 작성.
이 세 줄은 본질적으로 한 명의 개발자 직무 기술서지, 개인 이력서가 아니에요. 옆자리 동료가 와서 프로젝트 이름만 바꾸면 그대로 쓸 수 있는 내용이에요.
1~3년 차 단계가 되면, 면접관은 기본적으로 개발 능력은 있다고 가정해요. 이제는 "코드 칠 줄 압니다"를 증명할 필요가 없어요. 대신 이걸 보고 싶어 해요:
- 혼자서 문제를 해결할 수 있는가? 매번 누가 시켜줘야 움직이는 건 아닌지.
- 주어진 일 이상으로 능동적으로 움직인 적이 있는가? 스스로 문제를 발견했는지? 무언가 프로세스를 개선했는지?
- 자기가 맡은 일을 전체적인 맥락에서 이해하고 있는가? 아니면 자기가 맡은 좁은 영역만 아는 건지.
어떻게 고칠까요:
백엔드 API 개발을 독립 수행, 주문 생성·결제 콜백·환불 처리 3가지 핵심 플로우 커버, RESTful API 총 20개+ 개발.
코드 리뷰에서 잠재적 동시성 문제 3건 발견 및 수정을 주도, 해당 API로 인한 P0 장애 0건.
API 문서 작성 및 Swagger 도입 추진, 프론트엔드 연동 작업 시간 약 30% 단축.
똑같이 개발 업무를 썼는데, "독립""주도""P0 0건""30% 단축"이 들어가니 전달되는 시그널이 완전히 달라져요.
문제 2: 프로젝트 서술에 내 포지셔닝이 없음
13년 차면 한 프로젝트도 꽤 해봤을 텐데, 많은 사람들이 프로젝트마다 56줄씩 쓰고, 줄마다 "무엇을 했는지"만 적어요. 끝까지 읽어도 이 사람이 프로젝트에서 도대체 어떤 역할이었는지 모르겠는 거예요.
프로젝트 A: 요구사항 논의 참여, 백엔드 코드 작성, 유닛 테스트 작성, 배포, 문서 작성, 버그 수정.
프로젝트 B: 위와 동일.
면접관이 읽고 드는 고민: 그래서 이 사람은 풀스택인가? 아니면 비즈니스 로직 중심의 백엔드인가? 아니면 그냥 잡무 담당이었나?
해결 방법: 프로젝트마다 내 역할 포지셔닝을 명확히 쓰세요.
프로젝트: XX 플랫폼 주문 시스템 재구축 (2025.03 - 2025.08)
포지션: 백엔드 핵심 개발, 주문 체인 설계 및 구현 담당. 프론트엔드·QA·PM 포함 총 6인 협업
- 주문 상태 머신 독립 설계, 8가지 주문 상태와 15가지 상태 전이 시나리오 커버
- 동시성 환경에서 멱등 처리 및 재고 차감 구현, 온라인 재무 사고 0건
- QA 협업으로 전 체인 부하 테스트, 핵심 API TPS 2000+
프로젝트 시작에 한두 줄로基调를 깔아주세요: 어떤 프로젝트, 몇 명, 내 역할. 면접관이 읽으면서 머릿속에 그림이 그려져요.
문제 3: 기술만 보고 비즈니스를 안 봄
이건 1~3년 차 입장에선 좀 억울할 수 있어요. "겨우 2년 일했는데 비즈니스 이해는 내가 고민할 영역 아닌가요?"
하지만 현실은: 기술 수준이 비슷한 두 사람 중에, 한 명은 비즈니스 맥락을 말하고, 다른 한 명은 기술 구현만 말한다면, 후자는 주니어로 보여요.
예를 들어, 두 사람이 같은 프로젝트를 쓴다면:
A 방식 (기술만):
Redis 캐시로 핫 데이터를 캐싱해 DB 부하 감소. 메시지 큐 도입으로 주문 타임아웃 비동기 처리.
B 방식 (기술 + 비즈니스 이해):
라이브 커머스 시나리오에서 주문 순간 동시 접속이 5000+ QPS에 달해 DB 커넥션 풀이 포화, 주문 타임아웃 발생.
Redis 상품 재고 캐싱 + 블룸 필터로 무효 요청 차단 + RocketMQ로 주문 타임아웃 취소 비동기 처리 설계.
최적화 후 주문 API 응답 시간 2초 → 300ms, 단일 라이브 방송 10만 명+ 사용자 주문 처리 가능.
두 방식의 기술 솔루션은 완전히 같을 수 있어요. 하지만 B 방식은 중요한 시그널 하나를 더 보내줘요: 이 사람은 코드만 칠 줄 아는 게 아니라, 맥락을 이해하고 '왜' 이렇게 해야 하는지 알고 있다.
1~3년 차 이직에서 면접관이 원하는 게 바로 이 "맥락을 이해하는" 사람이에요.
문제 4: 프로젝트가 너무 많고 포인트가 없음
13년 차면 보통 한 36개 프로젝트를 경험해요. 하지만 이력서에는 가장 역량을 잘 보여주는 2~3개만 남기세요.
프로젝트 선정 기준:
- 가장 최근 프로젝트 우선 (최근 1~2년)
- 내 역할이 가장 핵심적이었던 프로젝트 우선 (주도 또는 깊이 참여)
- 가장 난이도가 높았던 프로젝트 우선 (단순 심부름만 한 건 제외)
1~2개월만 참여했거나, 관여도가 낮았거나, 너무 오래된 프로젝트(인턴 시절 등)는 전부 빼세요.
면접관이 이력서에서 찾는 5가지 시그널
위 조정을 다 하고 나서, 내 이력서가 이 시그널들을 보내고 있는지 확인해 보세요:
- 10초 안에 어떤 방향, 어떤 레벨인지 판단 가능 → 첫 화면에 명확한 포지셔닝
- 독립적으로 문제를 해결할 능력이 보임 → "주도""독립 완성""0에서 1까지" 사례 있음
- "시킨 일만 하는" 범위를 벗어난 능동성이 보임 → 최적화, 개선, 능동적 추진 사례 있음
- 프로젝트 맥락을 이해하고 있음 → 기술 방안 + 비즈니스 배경 모두 있음
- 기술 방향과 발전 가능성이 판단됨 → 프로젝트 선택에 방향성이 있고, 이것저것 얕게 건드리지 않음
마지막으로 한마디
1~3년 차 이직 이력서에서 가장 무서운 건 "잘 못 썼다"가 아니에요. 갓 입사한 지 반 년 된 신입처럼 보이는 것이에요. 전부 작업 서술뿐이고, 개인적 판단도 없고, 성과 수치화도 안 되어 있는 거요.
내 이력서가 어느 수준인지 확신이 서지 않는다면, DeepResume에 올려서 진단을 받아보세요. 성과 수치화, 키워드 커버리지, ATS 호환성 등 여러 기준으로 구체적인 점수와 수정 제안을 해주니까, 내가 "지원해도 될 만큼"까지 얼마나 남았는지 가늠할 수 있어요.