합격하는 이력서 규칙 (Resume Rules)
이 문서는 “서류 합격률을 높이는 이력서”를 만들기 위한 작성 규칙과 체크리스트다. (직군 공통 + 개발자 기준)
0) 원칙 (한 줄로)
- 채용공고의 문제를 내가 어떻게 해결했는지를, 숫자와 근거로, 한눈에 보여준다.
1) 한눈에 읽히는 구조
- 첫 화면(상단 1/3)에 합격 여부가 갈린다:
요약(3~5줄) → 핵심 스킬 → 대표 성과 2~3개.
- 섹션 순서 권장:
요약 → 경력 → 프로젝트(선택) → 스킬 → 학력/자격/기타.
- 경력 섹션은 회사별로
역할/제품 규모/담당 범위 → 기여 → 성과 → 기술 순으로 고정한다.
- 줄글보다 불릿 중심(문장 1줄, 최대 2줄)으로 쓴다.
2) 내용 규칙 (성과 중심)
- “무엇을 했다”보다 “무엇이 좋아졌는가”를 먼저 쓴다.
- 모든 핵심 불릿은 아래 포맷 중 하나로 작성한다.
문제 → 원인/가설 → 해결 → 결과(수치)행동(내가 한 일) → 영향(비즈니스/운영/고객) → 근거(지표/로그/비교)
- 성과는 가능한 한 수치화한다: 시간/비용/에러율/전환율/응답속도/장애건수/운영공수/사용자수/트래픽 등.
- “개선”이라고만 쓰지 말고 Before/After를 붙인다:
5초 → 0.3초, 주 3회 장애 → 월 0회.
- 팀 성과는 내 기여가 드러나게 쓴다:
내가 설계/구현/리딩한 범위를 명확히.
3) 개발자 이력서에 특히 중요한 것
- 프로젝트 설명에 규모/제약을 넣는다: 사용자 수, QPS, 데이터량, SLA, 레거시, 인력, 일정.
- “사용 기술 나열”이 아니라 왜 그 기술이 필요했는지(선택 이유/대안 비교/트레이드오프)를 1줄로라도 남긴다.
- 운영/장애 대응 경험은 강점이다:
모니터링, 알림, 재현, 롤백, 재발 방지(테스트/가드레일)까지 포함한다.
- 협업 신호를 넣는다:
요구사항 확정, 리뷰, 문서화, 배포/릴리즈, 타팀 조율.
4) “탈락하는 신호” 체크
- 성과/지표가 거의 없고, 기술만 나열되어 있다.
- 내가 한 일과 팀이 한 일이 구분되지 않는다.
- 문장이 길고 추상적이다(“안정화”, “최적화”, “고도화”만 반복).
- 공고와 무관한 내용이 상단을 차지한다.
7) 작성 템플릿(복붙용)
요약(3~5줄)
- (직무/연차) (핵심 강점 1~2개)
- (대표 성과 1)
- (대표 성과 2)
- (관심 도메인/선호 환경: 선택)
경력(회사명 / 직무 / 기간)
- 서비스/제품: (누구를 위한 무엇인지), (규모/제약 1줄)
- 핵심 성과:
- (문제 → 해결 → 결과 수치)
- (문제 → 해결 → 결과 수치)
- 주요 업무(선택):
- 기술: (핵심만 6~10개)