개발자 경력기술서 작성법, 업무 나열이 서류에서 떨어지는 이유

by 그릿 | GROWTH_ESSAY | 2026-10-07

개발자 경력기술서는 그 회사에서 내가 바꾼 것을 적는 문서입니다. 프로젝트마다 문제 하나, 그때 내린 판단 하나, 달라진 결과 하나를 남기면 됩니다. 담당 업무 목록은 한 줄 요약으로 충분합니다.

업무를 빠짐없이 적었는데 왜 연락이 없을까요?

200명 넘는 개발자의 서류를 함께 고치면서 3년차, 5년차 경력기술서에서 같은 모양을 자주 만났습니다. "주문 API 개발 및 유지보수", "관리자 페이지 기능 개발", "배치 작업 운영".

틀린 말은 하나도 없습니다. 같은 팀 동료 누구의 서류에 붙여도 똑같이 맞는 문장이라는 점이 문제입니다.

서류를 보는 현업 개발자는 이 사람이 자기 팀에 와서 무엇을 바꿀지 궁금해합니다. 업무 목록은 그 질문에 답하지 못합니다. 연차가 쌓일수록 목록은 길어지고, 길어질수록 정작 잘한 일은 그 안에 묻힙니다.

한 줄을 어떻게 고쳐야 읽힐까요?

4년차 멘티 한 분이 "정산 배치 운영"이라고만 적어 왔습니다. 대화를 이어 가니 이야기가 나왔습니다. 새벽 배치가 자주 실패해서 출근하자마자 손으로 다시 돌리던 일. 실패 원인이 외부 API 타임아웃이라는 걸 로그에서 찾아낸 일. 재시도와 실패 알림을 붙인 뒤로 아침 수동 작업이 사라진 일.

정작 본인은 그 일을 경력이라고 생각하지 않았습니다. 매일 하던 잡일이었으니까요.

이 세 줄이 들어가자 한 줄짜리 업무가 면접 질문 거리로 바뀌었습니다. 면접관의 첫 질문은 "타임아웃 원인을 어떻게 좁혔나요?"였다고 합니다.

문제, 판단, 결과. 프로젝트마다 이 순서 하나만 지키면 됩니다.

성과 숫자가 없으면 어떻게 하나요?

수치를 못 쓰겠다는 고민도 자주 듣습니다. 회사가 지표를 공개하지 않거나, 애초에 재본 적이 없는 경우입니다.

숫자를 지어내면 면접 꼬리 질문 두 번에 무너집니다. 그럴 때는 전과 후를 씁니다. "배포 전날마다 수동 점검표를 돌리던 과정을 테스트 자동화로 옮겼다." 퍼센트가 없어도 무엇이 달라졌는지 보입니다.

재볼 수 있는 숫자라면 지금이라도 잽니다. 응답 시간 로그, 쿼리 실행 계획, 장애 기록은 대개 아직 남아 있습니다.

내일 경력기술서를 고친다면 어디부터 볼까요?

"개발", "운영", "유지보수"로 끝나는 줄에 표시를 해 보십시오. 표시한 줄마다 "그래서 뭐가 달라졌지?"를 묻습니다. 답이 나오면 그 답을 문장 맨 앞으로 올립니다. 답이 안 나오면 줄이거나 지웁니다.

그다음 최근 프로젝트 하나를 면접관이 되어 읽어 봅니다. 꼬리 질문이 하나도 떠오르지 않는다면 내 판단이 아직 문장에 없는 겁니다.

경력기술서가 막힌다면 어떤 경험을 맨 앞에 세울지부터 정하면 풀립니다. 그 방향을 함께 잡아 보고 싶다면 https://teamgrit.co/direction 에서 점검해 보세요.