3년 차와 6년 차 개발자의 이력서는 무엇이 달라야 할까?

같은 "개발자 이력서"라도 3년 차와 6년 차에게 기대하는 것은 다릅니다. 연차가 절대적인 기준은 아니지만, 읽는 사람은 연차에 맞는 역할이 보이는지 를 함께 살펴봅니다.

3년 차에게 기대하는 것

• 주어진 문제를 안정적으로 구현하고 마무리하는 힘
• 막혔을 때 원인을 좁혀 가는 디버깅 방식
• 팀의 코드·협업 방식에 빠르게 적응하는 모습
• 배운 것을 다음 일에 연결하는 성장 속도

3년 차 이력서에서는 "맡은 기능을 끝까지 책임졌다" 가 보이는 것이 중요합니다. 그리고 어려운 문제를 만났을 때 어떻게 접근했는지가 드러나면 좋습니다. 화려한 구조 설계 경험이 없어도 괜찮습니다.

6년 차에게 기대하는 것

• 문제를 정의하는 힘: 무엇이 진짜 문제인지 가려내기
• 선택지 사이의 판단: 왜 이 방법인지, 무엇을 포기했는지
• 내 코드를 넘어서는 영향력: 다른 사람의 일이 쉬워지게 만든 것
• 운영과 장애까지 이어지는 책임

6년 차 이력서에서 기능 목록만 있다면 "연차에 비해 역할이 확장되지 않았다"고 읽힙니다. 내가 정한 기준, 내가 바꾼 방식, 내가 이끈 개선 중 최소 하나는 있어야 합니다.

같은 경험을 연차별로 쓰면

예시(재구성한 문장입니다) — 배포 자동화 경험

• 3년 차 표현: CI/CD 파이프라인 구성 및 배포 자동화 적용으로 배포 시간 단축

• 6년 차 표현: 팀마다 달랐던 배포 방식을 하나의 기준으로 정리하고 파이프라인을 설계. 새 팀원이 첫 주 안에 배포할 수 있도록 문서화하고 장애 시 되돌리는 절차를 표준화

사실 자체는 비슷할 수 있습니다. 차이는 범위(나 → 팀), 판단(왜 이렇게 정했는가), 지속성(남은 것) 입니다.

연차가 곧 직급은 아니다

연차는 하나의 참고일 뿐입니다. 3년 차에 6년 차 역할을 해낸 사람도 있고, 반대의 경우도 있습니다. 중요한 것은 지금 맡은 역할이 이력서에서 연차와 자연스럽게 이어지는지입니다. 맡은 역할이 아직 작다면, 그 안에서 내가 주도적으로 개선한 한 가지를 찾아 구체적으로 적는 것이 가장 좋은 전략입니다.

점검

• 연차가 올라갈수록 문장의 주어가 "기능"에서 "문제·팀·기준"으로 바뀌고 있는가
• 결과가 "구현했다"에서 "바꿨다/정했다/이끌었다"로 확장되고 있는가
• 내가 없어도 남아 있는 것(문서, 기준, 구조)을 한 가지라도 설명할 수 있는가