Resume Guide · 개발자

개발자 이력서 잘 쓰는 법

개발자 이력서에서 담당자(그리고 함께 일할 개발 리드)가 보는 순서는 기술 스택 → 프로젝트의 깊이 → 문제 해결 경험입니다. '무엇을 만들 수 있는 사람인가'가 스택 목록에서, '얼마나 잘 만드는가'가 성과 숫자에서 읽혀요.

⚡ 내 개발자 이력서는 몇 점일까?

30초 무료 진단 — 회원가입 없이

채용 담당자가 보는 체크리스트

1
기술 스택은 카테고리로 구조화
Language / Backend / Frontend / DevOps / Database처럼 묶어서 정리하세요. 나열 순서는 지원 공고의 요구 스택이 앞에 오게.
2
프로젝트마다 성과 한 줄
'응답 시간 200ms → 100ms', '빌드 시간 7분 → 2분'처럼 개선 전후가 있는 프로젝트가 기억에 남습니다.
3
트러블슈팅을 본문에 녹이기
장애·병목을 어떻게 찾고 고쳤는지가 실력의 증거입니다. 별도 섹션보다 해당 프로젝트 불릿에 넣으세요.
4
역할과 기여도를 명확히
팀 프로젝트라면 '4인 팀에서 인프라·CI/CD 담당'처럼 내 파트를 특정하세요.
5
깃허브·포트폴리오 링크 정돈
링크는 인적사항에 한 번만, 저장소는 README가 정리된 것 위주로. 죽은 링크는 마이너스입니다.

채용 담당자는 공고에 쓴 그 단어로 이력서를 스캔합니다. 실제 첨삭에서 바뀐 문장들이에요.

배포를 자동으로 되게 만들었습니다

→ GitHub Actions 기반 CI/CD 파이프라인 구축

도구 이름과 파이프라인이라는 용어가 실제 구현 경험의 증거가 됩니다.

느린 부분을 찾아서 빠르게 고쳤습니다

→ 쿼리 최적화로 응답 시간 200ms → 100ms (50% 단축)

무엇으로(쿼리) 얼마나(50%) 개선했는지가 붙어야 성능 튜닝 경험으로 인정됩니다.

서버가 죽지 않게 관리했습니다

→ 모니터링·알림 구축으로 장애 감지 시간 단축

가용성 관리는 운영 역량의 표준 표현으로 쓰는 것이 좋습니다.

❌ 스택 부풀리기

한 번 튜토리얼 해본 것까지 다 쓰면 면접에서 무너집니다. 실무·프로젝트에서 써본 것만.

❌ 프로젝트 소개가 기능 나열로 끝남

'로그인·게시판 구현'은 누구나 씁니다. 왜 어렵게 만들었고 뭘 개선했는지가 차별점입니다.

❌ 신입인데 기술 용어만 가득

신입은 학습 과정과 문제 해결 태도가 함께 보여야 합니다. 부트캠프·팀 프로젝트의 역할을 구체적으로.

수치가 있는 이력서는 완성도 점수부터 다릅니다. 개발자 이력서에서 찾을 수 있는 숫자들:

Q. 신입 개발자는 프로젝트가 부족한데요?

개수보다 깊이입니다. 팀 프로젝트 1개라도 본인이 맡은 파트의 기술적 선택 이유와 개선 수치를 쓸 수 있으면 충분히 강합니다.

Q. 포트폴리오와 이력서의 역할 분담은?

이력서는 3초 스캔용 요약(스택·성과), 포트폴리오는 깊이 검증용입니다. 이력서에 모든 걸 담으려 하지 마세요.

Q. 사용 기술을 어디까지 써야 하나요?

질문받았을 때 설명할 수 있는 수준까지만. 공고의 필수 스택과 겹치는 것을 앞에 배치하는 것이 매칭에 유리합니다.

개발자 이력서, 위 기준으로 AI가 다시 써드려요

용어 승격 · 정량화 슬롯 · 채용공고 맞춤 — 첨삭 1건 5,900원.
먼저 무료 진단으로 내 점수부터 확인해보세요.