경력이 많다고 이력서가 좋은 것은 아니다

긴 경력은 자동으로 신뢰를 주지 않습니다. 오히려 너무 많은 경험을 한 줄로 압축해서 역량이 흐려지는 경우가 많습니다. 시니어 이력서에서 자주 보이는 문제와 고치는 방법을 정리했습니다.

왜 압축하면 손해인가

• "백엔드 개발, 아키텍처 설계, 팀 리딩"처럼 키워드만 나열하면 무엇을 얼마나 깊게 했는지 알 수 없습니다.
• 채용 담당자는 15년의 경험을 한 번에 읽지 않습니다. 최근 3~5년의 구체적인 한두 프로젝트에서 판단합니다.
• 오래된 경험은 기술 이름보다 문제의 크기와 결정의 근거로 보여야 가치가 살아납니다.

시니어 이력서가 답해야 할 질문

1. 이 사람은 어떤 문제를 주로 풀었는가?
2. 그 문제에서 무엇을 결정했는가?
3. 결정의 결과가 팀과 서비스에 어떤 변화를 주었는가?
4. 지금 우리 조직에서 어떤 역할을 할 수 있는가?

이 네 질문에 답이 보이지 않으면 연차가 아무리 길어도 서류 단계에서 멈춥니다.

고치는 방법

• 최근 경력에 비중을 둡니다. 최근 3~5년은 충분히 풀어 쓰고, 그 이전은 역할과 규모만 짧게 씁니다.
• 프로젝트 단위로 묶습니다. "담당 업무" 대신 "문제 → 결정 → 결과"의 세 줄 구조를 씁니다.
• 의사결정의 근거를 씁니다. 왜 그 기술을 골랐는지, 어떤 대안을 버렸는지가 시니어의 차이를 보여 줍니다.
• 리딩의 범위를 구체적으로 씁니다. 몇 명을, 어떤 방식으로, 어떤 결과를 이끌었는지 씁니다.

예시(재구성한 문장입니다)

• 약함: 백엔드 개발 및 팀 리딩

• 강함: 결제 시스템의 장애 빈도가 늘던 시기에 재처리 구조를 재설계. 4명의 팀에서 설계 리뷰 기준을 도입하고, 분기별 장애 건수를 낮춤

피해야 할 것

• 모든 경험을 같은 무게로 쓰는 것: 중요도가 없으면 읽는 사람도 중요한 것을 찾지 못합니다.
• 직함만 나열하는 것: 직함은 결과를 설명하지 않습니다.
• 오래된 기술을 전부 넣는 것: 지금 쓰지 않는 기술은 한 줄로 정리해도 충분합니다.

점검

• 최근 프로젝트 세 개가 문제, 결정, 결과로 읽히는가?
• 내가 직접 결정한 것과 팀이 한 것이 구분되는가?
• 지금 지원하는 자리에서 가장 필요한 경험이 맨 위에 있는가?

경력의 길이보다 어떤 판단을 반복해 왔는지가 시니어의 가치입니다. 그 판단이 보이도록 압축을 풀어 주세요.