개발자 경력기술서,
업무 목록에서 근거 문서로

기술 이름을 많이 적는다고 강한 경력기술서가 되지는 않습니다. 채용 담당자가 확인하려는 것은 어떤 문제에서 어느 범위까지 맡았고, 왜 그렇게 판단했으며, 무엇이 달라졌는지입니다.

1. 회사가 아니라 문제 단위로 정리합니다

“프론트엔드 개발 담당”처럼 역할만 적으면 지원자의 수준을 판단하기 어렵습니다. 프로젝트나 개선 과제를 기준으로 문제, 제약, 맡은 범위, 행동, 결과를 묶습니다. 여러 사람이 함께한 프로젝트라면 팀 성과와 내가 직접 한 일을 구분합니다.

2. 한 문장에 기술과 이유를 같이 둡니다

React, TypeScript, Next.js를 나열하는 대신 왜 그 기술이나 구조를 선택했는지를 설명합니다. 선택의 배경에는 사용자 수, 화면 복잡도, 배포 제약, 기존 코드, 팀 숙련도 같은 현실적인 조건이 들어갑니다.

3. 수치는 출처가 있을 때만 씁니다

매출, 전환율, 응답 시간처럼 확인 가능한 수치는 강한 근거입니다. 하지만 기억나지 않는 숫자를 그럴듯하게 만들면 면접에서 바로 무너집니다. 정확한 수치가 없다면 “배포 전후 오류 로그 비교”, “문의 유형 감소”, “수동 작업 단계 축소”처럼 실제 확인 방법을 적습니다.

4. 기술적 판단과 버린 대안을 남깁니다

숙련도는 사용한 도구보다 판단 과정에서 더 잘 드러납니다. 어떤 대안을 검토했고 무엇 때문에 선택하지 않았는지, 선택 후 어떤 문제가 생겨 조정했는지를 짧게 포함합니다. 모든 문장에 넣을 필요는 없고 대표 프로젝트 두세 곳에 집중하면 됩니다.

5. 공고마다 강조 순서를 바꿉니다

원본 경력은 하나로 관리하되 제출본의 순서는 공고에 맞춥니다. 성능 개선 역할에는 병목 분석과 측정 근거를 먼저, 플랫폼 역할에는 공통화·배포·운영 경험을 먼저 배치합니다. 사실은 바꾸지 않고 읽는 순서와 설명 깊이만 조정합니다.

제출 전 체크리스트

• 팀이 한 일과 내가 한 일이 구분되는가?
• 기술 이름 뒤에 선택 이유나 실제 사용 범위가 있는가?
• 숫자마다 출처나 확인 방법이 있는가?
• 프로젝트마다 문제와 결과가 연결되는가?
• 지원 공고의 핵심 요구와 관련된 경험이 앞에 있는가?