개발자 자소서 쓰는 법 — 기술 나열 대신 판단을 보여주는 방법
개발자 자소서에서 읽는 사람은 기술 스택 목록이 아니라 '왜 그 선택을 했는가'를 봅니다. 프로젝트 경험을 판단 중심으로 다시 쓰는 법.
읽는 사람이 실제로 보는 것
- 문제를 어떻게 정의했고 여러 방법 중 왜 그것을 골랐는지 (기술 이름보다 선택 이유)
- 혼자 한 부분과 팀이 한 부분을 구분해서 쓰는지
- 결과를 측정했는지 — 응답 속도, 에러율, 배포 횟수처럼 숫자로 말할 수 있는지
- 실패하거나 되돌린 결정이 있는지, 그때 무엇을 배웠는지
- 코드 밖의 일 — 문서화, 코드 리뷰, 온보딩 — 에 관심이 있는지
개발자 자소서에서 유독 자주 나오는 실패
왜 문제인가 — 이력서의 스킬란과 같은 정보라 자소서에서는 아무것도 추가하지 못합니다.
이렇게 바꾼다 — 스택 중 하나를 골라 '왜 그걸 썼고 다른 선택지는 무엇이었나'를 씁니다. 하나의 선택 이유가 열 개의 기술 이름보다 많은 것을 말합니다.
왜 문제인가 — 면접에서 '어떻게 측정했나요'가 첫 질문이 됩니다. 답이 없으면 그 뒤 모든 주장이 흔들립니다.
이렇게 바꾼다 — 측정 전후 수치와 측정 방법을 씁니다. 수치가 없으면 '측정하지 않았다'고 쓰는 편이 낫고, 그 자체가 다음에 무엇을 할지에 대한 답이 됩니다.
왜 문제인가 — 읽는 사람은 지원자 개인을 뽑는 것이라 '우리'의 성과에서 지원자 몫을 추정해야 합니다. 추정이 필요하면 보수적으로 추정합니다.
이렇게 바꾼다 — '나는 X를 맡았고, Y는 팀원이 했다'처럼 경계를 분명히 씁니다. 몫이 작아 보여도 명확한 쪽이 신뢰를 얻습니다.
근거로 쓸 수 있는 경험의 모양
형용사 대신 이런 형태의 사실이 있어야 합니다. 규모가 작아도 구조가 같으면 근거가 됩니다.
- API 응답 p95를 1.8초에서 400ms로 줄였다 — N+1 쿼리 제거와 인덱스 추가, 측정은 APM 대시보드
- 배포 실패율이 높아 롤백 절차를 문서화하고 체크리스트로 만들어 배포 사고를 월 3건에서 0건으로
- 레거시 모듈을 다시 쓰자는 제안을 했다가 범위가 커서 철회하고, 대신 경계에 테스트를 먼저 깔았다
- 오픈소스에 낸 PR이 리뷰에서 두 번 반려됐고, 반려 사유를 반영해 병합됐다
지원동기에서 언급하면 좋은 것
회사 칭찬이 아니라 조사한 흔적입니다. 아래 중 하나만 구체적으로 써도 "회사 이름만 바꾸면 어디에나 낼 수 있는 글"에서 벗어납니다.
- 그 회사의 기술 블로그에서 다룬 문제 (예: 특정 마이그레이션, 장애 회고)
- 공개된 API 문서나 SDK를 직접 써 보고 발견한 점
- 채용 공고에 적힌 기술적 과제와 내 경험의 연결
- 그 회사 제품을 실제로 쓰면서 겪은 기술적 불편과 개선 아이디어
쓴 자소서를 바로 점검하기
위 기준으로 자소서를 읽고 점수와 함께 "지금 바로 걸리는 것 3가지"를 짚어 줍니다. 그다음 같은 글로 면접 예상 질문을 뽑아 방어가 약한 문장을 미리 찾을 수 있습니다. 전부 무료, 가입 없음.
자주 묻는 질문
- 개발자 자소서에 기술 스택을 아예 안 써도 되나요?
- 써도 되지만 나열로 끝내면 안 됩니다. 이력서에 이미 있는 정보라 자소서에서는 그중 하나를 골라 '왜 그 선택이었나'를 쓰는 편이 훨씬 강합니다. 선택 이유가 곧 지원자의 판단력을 보여줍니다.
- 측정한 숫자가 없는 프로젝트는 어떻게 쓰나요?
- '측정하지 않았다'고 솔직하게 쓰고, 다시 한다면 무엇을 측정할지를 덧붙이는 편이 지어낸 숫자보다 낫습니다. 면접에서 수치의 근거를 물었을 때 답할 수 없는 숫자는 없는 것보다 나쁩니다.
- 부트캠프·학교 프로젝트만 있어도 괜찮나요?
- 괜찮습니다. 읽는 사람이 보는 것은 규모가 아니라 그 안에서의 판단입니다. 왜 그 구조를 택했는지, 무엇이 안 됐고 어떻게 바꿨는지가 있으면 작은 프로젝트도 충분한 근거가 됩니다.