누구나 쓸 수 있는 이력서 작성방법

안녕하세요.
오늘은 이력서 때문에 괴로워하는 모든 취준생들을 위해
제가 이력서를 정리했던 방법을 공유해보려고 합니다.

이력서와 포트폴리오는 나를 채용 담당자에게 설명하는 중요한 수단입니다.

이력서를 잘 작성하지 못한다면 서류 단계에서 신뢰를 얻기 어렵습니다.

하지만 누구나 알기 쉽게 구조화할 수 있고,
몇 가지만 알면 알잘딱 이력서와 포트폴리오를 만들 수있습니다

그런데 처음부터 문장을 잘 쓰려고 하면 오히려 어렵습니다.

이력서를 구조화하기 전에 먼저 해야 할 것은
“무엇을 가지고 구조화할 것인가?” 재료를 만드는 일입니다.

[1단계] 나의 경험을 글로 작성해보기

제가 생각하기에 가장 많이 하는 실수 중 하나는
이 단계를 건너뛰고 바로 이력서 문장을 작성하는 것입니다.

이력서는 새로운 경험을 만들어내는 문서가 아니라,
이미 존재하는 경험에서 채용에 필요한 정보만 골라 압축하는 문서입니다.

그런데 처음부터 한두 줄짜리 이력서 문장을 만들려고 하면
당시의 상황, 문제, 판단, 내가 실제로 한 행동이 빠지기 쉽습니다.

먼저 특정 경험, 프로젝트, 업무를 하나 떠올립니다.

이때 문장을 잘 쓰려고 하지 말고
당시 있었던 일을 최대한 순서대로 적어봅니다.

경험을 적은 뒤에는 아래 내용이 들어있는지 확인합니다.

어떤 상황이었는지 → 
무엇이 문제였는지 → 
나는 무엇을 보고 문제라고 판단했는지 → 
어떤 선택을 했는지 → 
실제로 무엇을 했는지 → 
그래서 무엇이 달라졌는지

정량적인 성과가 있다면 함께 적고, 없다면 억지로 만들 필요는 없습니다.

이 단계의 목적은 멋있는 이력서 문장을 만드는 것이 아니라
내 경험의 원본을 최대한 많이 확보하는 것입니다.

이렇게 경험의 원본을 충분히 만들어두면 이후 지원하는 JD에 따라 필요한 부분만 골라 이력서 문장으로 압축할 수 있습니다.

---

[2단계] 이력서에 들어갈 내용 판단하기

1단계에서 작성한 경험을 전부 이력서에 넣는 것은 아닙니다.
내가 하고 싶은 말을 넣는 것이 아니라, 채용 과정에서 평가받을 정보를 넣어야 합니다.
그러기 위해서는 먼저 내가 지원하려는 직무가 어떤 사람을 찾고 있는지 알아야 합니다.

방법은 간단합니다.
지원하려는 포지션의 JD를 여러 개 열어봅니다.
저는 아래 순서로 읽는 것을 추천합니다.

1. 자격요건 2. 우대사항 3. 주요업무

그리고 여러 공고에서 반복해서 등장하는 요구사항을 찾아봅니다.

예를 들어 제가 PM 포지션의 여러 JD를 살펴봤을 때 다음과 같은 요구가 반복적으로 등장했습니다.

1. PRD, 요구사항 정의서, 상세 기획
2. 기능 범위·백로그·우선순위 결정
3. 기획부터 출시·운영까지 경험
4. 개발·디자인·QA와 협업
5. VOC·데이터 기반 개선

회사마다 사용하는 단어는 조금씩 다릅니다.
어떤 회사는 문제 정의라고 쓰고,
어떤 회사는 고객 요구사항 발굴,
또 다른 회사는 VOC 기반 개선이라고 작성합니다.

따라서 단어만 보는 것이 아니라
“이 회사가 이 문장을 통해 지원자의 어떤 경험을 확인하려는가?”​를 생각해봐야 합니다.

여러 JD를 보다 보면 결국 반복되는 평가 기준이 보입니다.
그다음부터는 우리는이렇게 생각할 수 있습니다.

• “내가 했던 것 중 무엇을 이력서에 쓰지?” ❌
• “내 경험 중 이 역량을 가장 잘 증명할 수 있는 것은 무엇이지?” ✅ *를 찾는 것입니다.

---

이력서 마무리 까지는 AI를 사용하지 않는 것을 권장합니다.

경험을 떠올리고 정리하는 과정까지 AI에게 맡기면,
정작 내가 어떤 문제를 겪었고 어떤 판단을 했는지
제대로 돌아보지 못한 채 그럴듯한 문장만 남기 쉽습니다.
적어도 1단계까지는 직접 해보는 것을 추천합니다.

---

[3단계] JD와 내 경험의 교집합 찾기

이제 1단계에서 정리한 나의 경험과
2단계에서 정리한 채용시장에서 요구하는 역량을 연결해봅니다.

예를 들어 JD에서 아래와 같은 역량을 요구한다고 가정해보겠습니다.

- 사용자 문제 정의
- 데이터 기반 제품 개선
- 요구사항 구체화
- 유관 부서와의 협업
- 출시 이후 제품 운영

그렇다면 1단계에서 작성했던 경험을 하나씩 보면서 맞춰봅니다.

이렇게 정리하면 어떤 경험을 이력서 상단에 배치해야 하는지도 자연스럽게 보이기 시작합니다.

예를 들어 내가 가장 큰 규모의 프로젝트를 진행했더라도
지원하는 JD와 연결점이 적다면 반드시 가장 앞에 넣을 필요는 없습니다.

반대로 작은 프로젝트더라도
내가 직접 문제를 정의했고,판단의 근거가 있고, 실행 과정이 명확하고, JD가 원하는 역량을 잘 보여준다면

오히려 더 좋은 이력서 소재가 될 수 있습니다.

---

[4단계] 실제 이력서 만들기

개인적으로 이력서를 만드는 도구는 Figma 또는 Word를 추천합니다. (노션X)

원티드나 여러 채용 플랫폼에서 제공하는 이력서도 편리하지만,
대부분 정해진 항목과 순서가 있기 때문에 내가 강조하고 싶은 정보를 원하는 위치에 배치하기 어렵습니다.

반면 직접 만든 이력서는
“채용담당자가 나에 대해 무엇을 먼저 봤으면 하는가?” 를 기준으로 순서를 설계할 수 있습니다.

이력서는 꼭 정해진 순서대로 작성할 필요가 없습니다.
저의 경우 이런 형식으로 작성하였습니다.

이름 / 연락처
↓
3~4줄 정도의 자기소개
↓
경력
↓
주요 프로젝트

자기소개

자기소개에는 모든 경험을 설명하기보다
내가 어떤 방식으로 일하는 사람인지,
어떤 강점을 가진 지원자인지 빠르게 알 수 있도록 작성했습니다.

본인의 강점이 무엇인지 직접 떠올려보세요!

---

프로젝트

프로젝트 역시 무조건 최근 순서대로 넣지 않았습니다.

제가 지원하는 직무와 가장 연관성이 높고,
제가 가진 역량을 가장 잘 보여줄 수 있는 프로젝트를 먼저 배치했습니다.

예를 들어 최근 프로젝트라는 이유만으로 앞에 두는 것이 아니라,

• 지원하는 JD와 얼마나 가까운지
• 내가 직접 문제를 정의하고 판단한 경험인지
• 내가 자신 있게 설명할 수 있는 경험인지
• 결과까지 보여줄 수 있는 경험인지
  를 기준으로 순서를 정했습니다.

또한 직무마다 차이가 있겠지만 정리해둔 나의 경험을
문제, 가설, 역할, 성과 4가지로 나눠서 작성합니다.

---

강점이 아닌 정보는 뒤로 보내도 됩니다

저의 경우 학력이 제 지원 경쟁력을 가장 잘 보여주는 요소는 아니라고 판단했기 때문에 뒤쪽에 배치했습니다.

반대로 특정 직무에서 학력이나 전공이 중요한 경쟁력이 된다면 당연히 앞쪽에 둘 수도 있습니다.

---

직무 전환자라면 ‘왜 전환했는지’를 짧게 설명해도 좋습니다.

저처럼 개발자 → PM처럼 직무를 전환하는 경우라면
채용담당자 입장에서는 자연스럽게 이런 의문이 생길 수 있습니다.

_- 왜 직무를 바꾸려고 하지?

• 기존 경험과 PM은 어떻게 연결되지?
• 갑자기 완전히 다른 일을 하려는 건가?_

그래서 저는 이력서 마지막에 직무 전환 배경을 별도로 넣었습니다.