먼저 답하면: 경력기술서는 경력을 검증 가능한 단위로 풀어 쓰는 문서다
이력서가 전체 경력을 빠르게 파악하게 하는 요약이라면 경력기술서는 지원 직무와 관련된 경험을 더 구체적으로 확인하게 하는 문서예요. 핵심은 업무 목록을 길게 늘리는 것이 아니라 문제와 역할, 행동과 결과의 연결을 보여주는 데 있습니다.
회사마다 요구하는 양식과 항목은 달라요. 별도의 경력기술서를 요구하지 않거나 지원 시스템 안에 상세 경력을 입력하게 하는 경우도 있으니 먼저 공고와 제출 화면을 확인하세요.
회사보다 프로젝트 또는 업무 묶음을 기본 단위로 삼는다
회사 이름 아래에 담당 업무만 나열하면 어떤 문제를 어느 범위까지 해결했는지 알기 어려워요. 다음 단위 중 내 일을 가장 잘 설명하는 것을 선택하세요.
- 시작과 끝이 분명한 프로젝트
- 지속적으로 운영한 제품이나 시스템
- 고객군·채널·지역별로 책임진 업무 묶음
- 직무가 바뀐 시점이나 조직 이동
모든 직무를 억지로 프로젝트 형태에 맞출 필요는 없습니다. 반복 운영이 중심인 직무라면 운영 범위와 개선 사례를 나누는 편이 더 자연스러워요.
각 단위에는 다음 정보를 필요한 만큼 넣습니다.
- 이름과 기간: 무엇을 언제 했는가
- 배경과 목표: 왜 이 일이 필요했는가
- 내 역할: 팀 안에서 어디까지 책임졌는가
- 행동과 판단: 무엇을 어떻게 했고 왜 그렇게 선택했는가
- 결과와 근거: 무엇이 달라졌고 어떻게 확인했는가
- 사용한 역량: 지원 직무와 연결되는 기술·도구·협업 방식
팀 성과와 내 역할을 분리한다
팀 프로젝트의 최종 성과를 적을 수는 있지만 그 결과 전체를 혼자 만든 것처럼 보이면 신뢰가 떨어져요. 팀 결과와 내 기여를 한 문장 안에서 구분하세요.
아래 예시는 구조를 설명하기 위해 만든 문장이에요.
- 수정 전:
결제 전환율을 개선했습니다. - 수정 후:
결제 개편 프로젝트에서 오류 로그 분류와 재시도 정책 설계를 맡았고, 팀이 확인한 결제 이탈 감소에 기여했습니다.
내 역할을 선명하게 만드는 표현은 다음과 같아요.
- 전체 과정 중 내가 맡은 단계
- 내가 결정할 수 있었던 범위
- 함께 일한 조직과 합의한 기준
- 직접 만든 산출물이나 변경 사항
- 결과를 확인할 때 사용한 지표와 기간
참여, 기여, 지원만 반복하지 말고 그 뒤에 구체적인 행동을 붙이세요.
성과 수치가 없을 때도 근거는 찾을 수 있다
매출이나 전환율처럼 대표 지표가 모든 업무에 있는 것은 아니에요. 수치가 없다고 임의의 비율을 만들거나 팀 지표를 가져오지 마세요. 다음 순서로 확인 가능한 근거를 찾아보세요.
- 직접 결과: 매출, 비용, 처리량, 소요 시간, 오류 건수
- 전후 변화: 수기에서 자동화, 분산된 절차의 통합, 승인 단계 축소
- 업무 규모: 고객 수, 프로젝트 수, 데이터 범위, 예산, 이해관계자
- 품질과 안정성: 누락 방지, 재작업 감소, 검수 기준 수립
- 채택과 재사용: 다른 팀이 사용, 표준 절차로 채택, 후속 프로젝트에 적용
- 판단의 근거: 조사·실험·사용자 피드백을 의사결정에 반영
수치가 있다면 기준과 기간을 함께 적고 내가 직접 확인하지 못한 추정치는 추정이라고 밝혀야 합니다. 숫자가 없어도 변화의 전과 후를 사실로 설명할 수 있다면 충분히 구체적일 수 있어요.
직무별 경력기술서 예시: 업무 나열을 경력 문장으로 바꾸기
다음 예시는 실제 합격 사례가 아니라 편집 구조를 보여주기 위한 가상 문장이에요.
개발
- 수정 전:
API 개발 및 서버 운영 - 수정 후:
주문 API의 간헐적 타임아웃을 재현하고 쿼리와 캐시 정책을 조정했으며, 변경 전후의 응답 시간과 오류 로그를 비교해 배포 기준을 만들었습니다.
기획·PM
- 수정 전:
신규 기능 기획 및 출시 - 수정 후:
고객 문의와 이탈 구간을 기준으로 문제를 정의하고, 디자인·개발과 범위를 조정해 결제 복구 흐름을 출시했습니다.
마케팅
- 수정 전:
콘텐츠 마케팅 운영 - 수정 후:
유입 검색어와 전환 페이지를 연결해 콘텐츠 우선순위를 정하고, 발행 후 유입과 가입 전환을 주 단위로 검토했습니다.
운영·CS
- 수정 전:
고객 문의 대응 - 수정 후:
반복 문의를 유형별로 분류하고 안내 문구와 에스컬레이션 기준을 정리해 팀의 응답 절차를 표준화했습니다.
경력 공백과 잦은 이동은 필요한 범위만 설명한다
경력 공백이 있다고 해서 건강이나 가족 사정 같은 민감한 정보를 자세히 공개할 필요는 없어요. 공고나 양식에서 설명을 요구하거나 경력 흐름을 이해하는 데 필요할 때만 기간과 사실을 간결하게 적고 원한다면 그 기간의 학습과 프로젝트, 돌봄과 회복 등 관련 활동을 덧붙이세요.
이직이 여러 번 있었다면 이동 사유를 길게 변명하기보다 경력 전체에서 이어지는 역량과 선택의 기준을 요약하는 편이 좋아요. 다만 실제 이유를 숨기기 위해 일관된 서사를 만들어내서는 안 됩니다. 근무 기간은 이력서와 LinkedIn 및 증빙 자료와 일치해야 해요.
직무마다 결과를 확인하는 방식이 다르다
- 개발: 기술 선택의 이유, 장애·성능·안정성 변화, 운영 규모
- 데이터: 분석 질문, 데이터 범위, 검증 방법, 의사결정에 반영된 방식
- 기획·PM: 문제 정의, 우선순위 근거, 출시 범위, 사용자·사업 변화
- 디자인: 사용자 문제, 탐색 과정, 협업 범위, 사용성 변화
- 마케팅: 채널과 타깃, 실험 설계, 예산 범위, 유입·전환 변화
- 영업·사업개발: 담당 시장, 파이프라인, 협상 역할, 계약·관계 변화
- 운영·CS: 처리 범위, 반복 문제, 절차 개선, 품질과 응답 변화
같은 경력기술서를 모든 회사에 그대로 내기보다 공고가 먼저 확인하려는 역량에 맞춰 프로젝트의 순서와 상세도를 조정하세요. 사실 자체를 바꾸는 것이 아니라 같은 원본에서 관련 근거를 골라 보여주는 작업이에요.
한 번 정리한 경력은 다음 지원에도 재사용한다
지원할 때마다 기억을 처음부터 복원하면 프로젝트명과 기간 및 수치가 문서마다 달라지기 쉬워요. 프로젝트가 끝났을 때 다음 원본 정보를 저장해 두세요.
- 기간과 참여 조직
- 해결하려던 문제
- 내 역할과 의사결정 범위
- 실제 행동과 사용한 도구
- 확인된 결과와 근거 자료
- 공개할 수 있는 링크와 비공개 정보의 경계
이 원본을 승인된 사실로 유지하고 회사별 경력기술서와 이력서 및 자소서에는 필요한 부분만 골라 쓰면 최신본을 잃지 않으면서도 맞춤 지원이 가능해집니다.
프로젝트의 상세 근거를 짧은 지원 서류로 압축할 때는 읽히는 이력서 작성법을 기준으로 순서를 정하세요. 자소서에서는 같은 사실 중 문항이 요구하는 행동만 골라야 합니다.
제출 전 체크리스트
- 공고가 경력기술서를 요구하는지와 별도 양식이 있는지 확인했는가
- 각 프로젝트의 기간과 내 역할이 분명한가
- 팀 결과와 개인 기여가 구분되어 있는가
- 수치의 기준과 기간을 설명할 수 있는가
- 수치가 없는 업무도 전후 변화나 규모로 구체화했는가
- 지원 직무와 가까운 프로젝트가 먼저 보이는가
- 이력서·자소서·LinkedIn의 이름과 날짜가 일치하는가
- 공개할 필요 없는 고객·회사·개인정보를 제거했는가
정리
경력기술서는 업무 목록이 아니라 문제와 역할, 행동과 결과를 검증 가능한 단위로 연결하는 문서예요. 프로젝트나 업무 묶음으로 나누고 팀 성과와 내 기여를 구분하며 숫자가 없으면 전후 변화와 규모, 품질과 채택 같은 사실을 찾아보세요.
작성 기준과 참고 자료
경력기술서의 형식과 평가 기준은 기업과 직무 및 채용 시스템마다 다릅니다. 이 글보다 공고와 공식 양식을 우선하고 작성한 사실은 면접과 증빙 과정에서도 일관되게 설명할 수 있어야 합니다.