첫 이력서 작성 체크리스트 30개: 신입 취준 시작 전 한 번에 점검
2026-05-04
처음 이력서를 쓸 때 '잘 쓴 건지' 비교군이 없어서 막막한 분들을 위해. 기본 정보부터 공고 키워드 매칭까지 30개 항목으로 혼자 자가 점검하는 법을 정리했습니다.
핵심 요약
- 이 체크리스트는 편집용 워크시트이지 채용 기준이 아니다. 지원처 지침을 먼저 따른 뒤 사용한다.
- 분량·파일 형식·필수 항목은 지원처 지침이 최우선이다. 별도 지침이 없을 때만 신입·인턴 이력서 1~2페이지와 일관된 글꼴을 편집 출발점으로 삼는다.
- 경험 항목에는 내가 한 행동과 뒷받침할 수 있는 결과를 쓸 수 있다. 수치는 측정 방법을 설명할 수 있을 때만 넣는다.
- 지원할 공고에서 핵심 업무·자격 요건을 뽑고, 실제로 해본 일에 해당하는 항목이 이력서 어디에서 확인되는지 대조한다.
- 총 체크 개수에는 평가 의미가 없다. 체크되지 않은 개별 항목은 현재 공고에 맞는 수정 대상을 고르는 데만 쓴다.
- 상황·내 행동·바뀐 것·규모는 경험 문장을 검토하기 위한 선택형 질문이다. 기록으로 뒷받침되는 항목만 쓴다.
이력서를 처음 쓸 때 "무엇부터 채워야 하지?"와 함께 "이게 맞는 건지 어떻게 알지?"라는 질문이 생길 수 있습니다.
주변에 이력서를 비교해볼 사람도 없고, 잘 쓴 건지 기준도 모르니 채우다 멈추다를 반복하게 됩니다.
이 글은 그 막막함을 30개 항목으로 나눠, 처음 이력서를 쓰는 분이 혼자서도 차근차근 점검할 수 있도록 정리했습니다.
체크리스트를 편집 기준으로 쓰기
첫 이력서는 반복해서 적용할 검토 방식이 없으면 판단하기 어려울 수 있습니다. 체크리스트는 질문을 항목별로 보이게 하지만, 고용주의 선발 판단을 대신하지 않습니다.
직무별 차이도 있습니다. 개발자 공고와 마케터 공고는 서로 다른 근거를 요구할 수 있고, 같은 직무명이어도 공고마다 내용이 다릅니다. 현재 지원처가 공개한 지침과 업무를 기준으로 삼으세요.
항목 하나씩 읽고 본인의 이력서에 해당하면 체크. 체크 안 된 항목이 수정 포인트입니다. 감당할 수 있는 수정 범위를 고른 뒤 같은 체크리스트로 다시 점검하세요.
30개 체크리스트
A. 기본 정보
- [ ] 이름이 선명하게, 페이지 최상단에 있다
- [ ] 연락처(전화·이메일)가 현재 사용 중인 것으로 기재되어 있다
- [ ] 이메일 주소가 지원처 지침에 맞고 연락용으로 식별하기 쉽다
- [ ] 링크드인·GitHub·포트폴리오 URL이 있다면 최신 상태인지 확인했다
- [ ] 불필요한 개인정보(주민번호, 나이, 사진)를 제거했다 (직무·기업 요구사항 확인 후 결정)
B. 이력서 포맷·가독성
- [ ] 지원처의 분량·파일 형식 지침을 확인했다 (별도 지침이 없으면 신입·인턴 1~2페이지를 출발점으로 검토)
- [ ] 제출 파일에서 글꼴과 크기가 읽기 쉽게 일관되어 있다
- [ ] 여백이 너무 좁지 않아 읽기 편하다
- [ ] PDF로 변환했을 때 레이아웃이 깨지지 않는다
- [ ] 맞춤법 오류가 없다 (제출 전 맞춤법 검사기 1회 필수)
C. 요약(Summary) 또는 목표
- [ ] 상단 요약을 넣었다면 역할과 근거가 간결하게 읽힌다 (지원처 양식에 따라 생략 가능)
- [ ] 요약이 "열정 있는 지원자입니다" 같은 추상 표현 대신 구체적 역할·기여를 담고 있다
- [ ] 요약에 공고 문구를 썼다면 각 단어가 이력서의 실제 근거를 정확히 설명한다
D. 경험 항목 (프로젝트·인턴·아르바이트·학내 활동)
- [ ] 각 경험 항목에 기간·조직명·역할이 명시되어 있다
- [ ] 내가 한 행동을 설명하고, 근거가 있을 때만 결과를 포함했다
- [ ] 실제 측정 근거가 있는 결과에는 수치를 포함했다 (예시는 가상이며 측정 방법을 설명할 수 있어야 함)
- [ ] 팀 프로젝트라면 본인의 구체적 기여가 명확하다 ("팀으로 개발함" → "백엔드 API 설계·구현 담당")
- [ ] 지원처 지침이 없다면 경험 항목을 최신 순서로 정렬하는 방식을 검토했다
E. 기술·스킬
- [ ] 기술 스택이 직무와 관련 있는 것만 포함되어 있다
- [ ] 숙련도 표현이 과장되지 않았다 ("능숙" → "실무 경험 있음" 등 정직하게)
- [ ] 언어·프레임워크·툴이 카테고리별로 정리되어 있다
- [ ] 이력서에 적힌 기술 중 면접에서 질문받았을 때 대답할 수 없는 항목은 없다
F. 교육·자격·수료
- [ ] 학교명·전공·졸업(예정)년도가 있다
- [ ] 관련 자격증·수료 과정이 직무와 연결되어 기재되어 있다
- [ ] 관련 없는 자격증은 지면을 낭비하지 않도록 제거 또는 최소화했다
G. 공고(JD) 키워드 매칭
- [ ] 공고에서 내 근거와 관련된 업무와 자격 요건을 골랐다
- [ ] 그 키워드가 이력서 어딘가에 반영되어 있다 (정확한 단어 또는 동의어)
- [ ] 공고의 "자격 요건"을 보고 이력서에서 해당 항목이 읽히는지 확인했다
H. 최종 제출 전 점검
- [ ] 필요하다면 버전마다 같은 짧은 시간으로 타인에게 보여주고 무엇이 먼저 보였는지 기록했다
- [ ] 제출 파일명이 "이력서.pdf" 가 아닌 "이름_직무_이력서.pdf" 형식이다
- [ ] 첨부 파일이 실제로 열리는지 본인 기기에서 확인했다
총개수는 이력서 수준을 진단하거나 결과를 예측하지 않습니다. 체크되지 않은 항목을 지원처 요구·근거 정확성·가독성으로 나누고, 현재 공고에 맞춰 다음 수정 대상을 고르세요.
체크리스트 다음에 해볼 다른 점검
자가 점검에 다른 편집 방법을 더할 수 있습니다. 아래 세 가지는 추가 관찰을 얻는 방법이며 진단이나 채용 테스트가 아닙니다.
1. 30초 요약 테스트
가족이든 친구든 한 명에게 이력서를 30초만 보여주고 덮은 다음, "무엇이 먼저 보였어?"라고 물어보세요. 30초는 같은 조건으로 버전을 비교하기 위한 임의의 시간입니다. 채용 담당자가 실제로 30초만 읽는다는 뜻은 아닙니다.
돌아온 답이 내가 의도한 인상과 다르면 상단 배치와 내용 근거를 함께 확인합니다. 먼저 상단 요약과 첫 경험 항목의 순서를 바꿔 다시 테스트하고, 그래도 흐리다면 문장 자체를 구체화합니다.
2. 소리 내어 읽기
이력서를 처음부터 끝까지 소리 내어 읽고 이해하기 어렵게 느껴지는 문장을 표시하세요. 그 문장의 길이·구조·근거를 다시 확인합니다. 낭독 결과만으로 좋은 문장과 나쁜 문장을 확정하지는 않습니다.
3. 공고 옆에 놓고 한 줄씩 대보기
지원할 공고를 왼쪽에, 이력서를 오른쪽에 놓고 공고의 요구사항 한 줄마다 이력서에서 대응되는 문장을 찾아 표시합니다.
대응 문장을 못 찾은 줄은 세 가지 중 하나입니다. 실제로 해본 일을 빠뜨렸거나, 다른 경험으로 전환 가능한 역량을 설명해야 하거나, 아직 근거가 없는 요구사항입니다. 어느 경우인지 표시한 뒤 사실만 보완하세요.
AI 출력은 검토가 필요한 제안으로만 다루세요. 공고·내 기록·개인정보 처리 조건·경험의 사실과 대조하고, 역할이나 결과를 부풀리는 문장은 버립니다.
경험 문장을 살펴보는 선택형 질문
담당 업무만 적힌 문장에 맥락을 더하고 싶다면 아래 질문을 한 가지 점검 방식으로 쓸 수 있습니다.
아래 네 항목 중 관련 있고 근거가 있는 것이 무엇인지 묻습니다. 모든 항목을 채울 필요는 없으며, 칸을 채운다고 문장이 자동으로 더 좋아지는 것도 아닙니다.
[상황] + [내가 한 행동] + [바뀐 것] + [크기]
| 고치기 전 | 고친 뒤 | |---|---| | 학과 홍보 활동 담당 | 학과 인스타그램을 주 3회 운영해 6개월간 팔로워 500→1,200명 | | 카페 아르바이트 | 주문 동선을 재배치해 피크타임 평균 대기 시간 단축 | | 팀 프로젝트에서 개발 참여 | 회원가입·인증 API 설계·구현, 4인 팀에서 백엔드 단독 담당 | | 데이터 분석 스터디 진행 | 12주 스터디 운영, 매주 발표 자료 작성 및 참여율 10명 중 8명 유지 | | 봉사활동 다수 참여 | 지역 도서관 주말 봉사 14회(총 56시간), 아동 독서 프로그램 보조 |
오른쪽 문장이 자동으로 더 좋은 버전은 아닙니다. 기록으로 뒷받침되고 지원 역할과 관련된 내용만 사용하세요.
성과 수치가 없을 때 쓸 수 있는 사실 맥락
모든 경험에 측정된 결과가 있는 것은 아닙니다. 아래 항목은 관련 있고 기록이 있을 때 사실 맥락을 더하는 예시입니다.
- 빈도·기간: "주 3회", "6개월간", "14회". 활동을 설명하지만 성과를 뜻하지는 않습니다.
- 범위·규모: "4인 팀", "회원 200명 커뮤니티", "3개 학과 공동". 일의 크기를 보여줍니다.
- 전후 비교: "수기로 정리하던 출결을 스프레드시트 양식으로 전환". 숫자가 없어도 변화의 방향은 남습니다.
세 가지 중 하나도 붙지 않는 항목은 지원 역할과의 관련성, 지원처 지침, 다른 경험과의 중복을 보고 유지 여부를 다시 검토하세요.
여기서 하지 말아야 할 두 가지
- 추정치를 확정치처럼 쓰기. "30% 개선"이라고 적으려면 출처와 측정 방법을 남기세요. 근거가 없다면 다른 효과 표현으로 바꾸지 말고 수치를 뺍니다.
- 팀 성과를 내 성과로 옮기기. "팀 매출 2억 달성"만으로는 내 기여가 드러나지 않습니다. 내가 맡은 부분만 쓰고 팀 전체 수치는 맥락으로 명확히 구분합니다.
여러 곳에 지원할 때 고칠 것과 고정할 것
지원처가 늘어나면 "회사마다 이력서를 새로 써야 하나"라는 질문이 나옵니다. 전부 새로 쓸 필요는 없습니다. 바뀌는 층과 고정되는 층을 나눠 두면 매번 사실 문장을 새로 만드는 일을 피할 수 있습니다.
사실을 유지하는 층
- 경험 항목의 본문: 실제로 한 일이므로 회사가 바뀌어도 사실은 그대로입니다
- 학력·자격·연락처
- 근거 있는 결과와 측정 메모
공고마다 바꾸는 층
- 간결한 상단 요약의 문구: 내 근거를 정확히 설명하는 범위에서만 공고 용어 사용
- 경험 항목의 순서: 지원처 양식이 허용하면 관련 근거를 앞에 둘지 검토
- 기술 항목의 나열 순서: 공고에 언급된 스택을 앞으로
- 파일명:
이름_직무_이력서.pdf
이렇게 나누면 사실 문장이 의도치 않게 바뀌는 일을 줄일 수 있습니다. 지원 기록에는 날짜·회사·제출 파일명을 남겨두세요.
마무리
첫 이력서에서는 제출 전에 무엇을 검토할지 정하는 일이 한 가지 과제가 될 수 있습니다.
30개 체크리스트는 편집 질문을 항목으로 나눈 워크시트입니다. 점검이 끝나면 원할 때 같은 시간으로 훑어보기·소리 내어 읽기·공고 대조를 더하고, 감당할 수 있는 수정 범위를 골라 다시 돌릴 수 있습니다.
차근차근 하나씩 점검해보세요.
점검 사이클을 어떻게 도는지 궁금하다면: 이력서 피드백을 제대로 받는 5가지 방법
이 글은 AI 보조 도구를 활용해 작성했으며, platformholder가 사실 확인과 편집을 진행했습니다.