‘무엇을 담당했는가’ 다음에 ‘어떻게 일했는가’를 보여 주세요
이력서에 “운영 업무 3년, 고객 문의 및 정산 담당”이라고 적었습니다. 사실에는 맞지만, 경력기술서를 쓰려니 같은 문장을 길게 늘리는 것밖에 떠오르지 않습니다. 매일 한 일은 많은데 특별한 수상이나 큰 매출 성과는 없습니다. 무엇을 더 써야 할까요?
경력기술서는 업무 이름을 늘어놓는 대신, 맡은 범위·판단·행동·결과를 근거와 함께 설명하는 문서로 생각하면 좋습니다. 읽는 사람이 “이 사람이 우리 업무에서도 어떤 역할을 맡을 수 있는가?”를 판단하도록 돕는 것이 목적입니다. 회사마다 이력서와 경력기술서를 구분하는 방식이 다르므로, 지정 양식과 공고의 요구가 항상 먼저입니다.
이 글은 경험을 고르는 것에서 시작해 한 건을 정리하고, 문장으로 압축하고, 제출 전에 확인하는 과정까지 다룹니다. 아래 사례와 수치는 모두 작성법을 설명하기 위한 가상 예시이며 실제 지원자의 실적이나 합격 사례가 아닙니다. 마지막의 경력 초안 작성 도구에서는 자신의 메모를 항목별로 정리하고 복사할 수 있습니다.
작성부터 시작하고 싶다면 경력 초안 작성 도구로 이동한 뒤, 막히는 질문을 본문에서 확인하세요.
![]()
AI 생성 연출 사진입니다. 실제 지원자의 개인정보나 채용 성과를 보여주는 자료가 아닙니다.
이력서·경력기술서·포트폴리오는 같은 내용을 다른 깊이로 보여줍니다
셋을 완전히 분리된 이야기로 만들 필요는 없습니다. 같은 경험을 이력서에서는 빠르게 훑을 수 있는 요약으로, 경력기술서에서는 역할과 해결 과정으로, 포트폴리오에서는 공개 가능한 결과물과 설명으로 보여줄 수 있습니다.
| 문서 | 읽는 사람이 먼저 확인할 것 | 같은 경험을 담는 방식 |
|---|---|---|
| 이력서 | 언제 어디서 어떤 역할을 했는가 | 회사·기간·직무와 핵심 경험의 짧은 요약 |
| 경력기술서 | 어떤 문제에서 무엇을 맡고 어떻게 처리했는가 | 업무 범위·행동·산출물·결과와 본인 기여 |
| 포트폴리오 | 실제로 무엇을 만들거나 바꾸었는가 | 공개 가능한 결과물, 과정, 선택 이유와 한계 |
모든 직무에 세 문서가 필요한 것은 아닙니다. 운영·사무처럼 결과물 공개가 어렵거나 비밀유지 의무가 있는 업무에서는 문서화한 설명만으로 역할을 보여줄 수 있습니다. 포트폴리오를 만들기 위해 회사 파일을 임의로 반출하지 마세요.
Harvard의 이력서 작성 안내는 지원하는 역할에 맞춘 구체적이고 사실 중심의 표현을 권합니다. 이를 국내 경력기술서에 적용할 때도 ‘미국식 이력서 형식’을 그대로 복제하기보다, 지원처가 판단할 정보가 무엇인지에 초점을 맞춥니다.
1단계: 공고를 ‘필요한 행동’으로 풀어 적습니다
처음부터 과거 회사의 업무를 전부 쓰면 선택이 어려워집니다. 공고에서 실제 맡을 일과 요구 역량을 나누고, 그에 대응하는 자신의 행동을 찾아보세요. “커뮤니케이션 역량” 같은 단어는 그대로 옮기기보다 누구와 어떤 기준을 맞추는 일인지 구체화합니다.
아래는 도구몽이 제안하는 공고–경험 대응표입니다. 채용사가 공식적으로 쓰는 점수표는 아닙니다.
| 공고의 표현 | 업무에서 필요할 행동 | 찾아볼 내 경험 | 확인할 자료 |
|---|---|---|---|
| 고객 문의 운영 | 문의 분류, 우선순위 설정, 반복 답변 정리 | 응대 기준·인수인계·예외 처리 | 공개 가능한 안내 문서의 존재, 당시 역할 기록 |
| 데이터 기반 개선 | 지표 정의, 누락 점검, 같은 기준으로 비교 | 집계표 정리·오류 원인 추적 | 지표 정의와 비교 기간을 설명할 메모 |
| 유관 부서 협업 | 요청 조건·담당자·완료 기준 합의 | 개발·영업·운영 간 조율 | 회의 결정 사항, 본인의 담당 범위 |
| 일정 관리 | 진행 상태 확인, 지연 원인 파악, 재조정 | 납기·행사·출시 일정 운영 | 계획과 변경 이력, 완료 범위 |
공고의 모든 표현에 맞는 경험을 억지로 만들 필요는 없습니다. 필수 업무와 직접 연결되는 경험부터 고르고, 연결이 약한 것은 지원 역량을 보완할 때만 넣습니다. 관련 경험이 적다면 신입의 경험을 고르는 방법부터 따라가도 좋습니다.
2단계: 문장보다 먼저 경험의 사실을 수집하세요
기억만으로 쓰면 팀이 한 일과 내가 한 일, 목표와 실제 결과가 섞이기 쉽습니다. 경험 하나를 골라 아래 경험 정리 카드를 채워 보세요. 모든 칸이 한 문단에 들어갈 필요는 없습니다. 빠진 정보와 확인할 대목을 찾는 과정입니다.
| 항목 | 자신에게 물어볼 질문 | 부족할 때 할 일 |
|---|---|---|
| 기간·배경 | 언제, 어떤 조직·서비스에서 했는가? | 입퇴사·프로젝트 기간과 운영 기간을 구분 |
| 업무 범위 | 어떤 대상·빈도·절차를 맡았는가? | 팀 전체 범위와 개인 담당을 따로 적음 |
| 문제·목표 | 무엇이 불편했고 무엇을 달성하려 했는가? | 당시 요청·기준을 확인하고 사후 해석과 구분 |
| 내 역할 | 결정·설계·실행·지원 중 어디를 맡았는가? | 협업 상대와 승인권자를 분리 |
| 행동 | 무엇을 어떤 기준과 방법으로 바꿨는가? | ‘개선’ 대신 실제 동작을 적음 |
| 산출물 | 무엇이 완성되거나 사용됐는가? | 표·문서·코드·절차·운영 기록을 떠올림 |
| 결과 | 어떤 변화가 어떤 기간·조건에서 확인됐는가? | 측정값·관찰·미확인을 구분 |
| 근거·공개 범위 | 내가 설명할 근거가 있으며 제출해도 되는가? | 비공개 원본은 첨부하지 않고 공개 가능한 수준 검토 |
모든 결과에 매출 숫자가 있어야 하는 것은 아닙니다. 운영이 중단되지 않도록 점검한 일, 기준을 정리해 인수인계를 가능하게 한 일도 설명할 수 있습니다. 다만 “문서를 만들었다”는 산출물과 “오류가 줄었다”는 효과는 다른 주장입니다. 후자는 비교 근거가 있어야 합니다.
도구몽이 정리한 작성 순서입니다. 채용사의 평가 모형이나 합격 확률을 예측하는 도식은 아닙니다.
3단계: 업무 설명을 문제·행동·결과로 바꿉니다
MIT의 경험 서술 안내는 프로젝트·맥락, 자신의 행동, 결과를 묶는 PAR 방식을 소개합니다. 이 글에서는 이를 업무의 상황 → 내가 한 행동 → 확인된 결과를 빠뜨리지 않는 질문으로 사용합니다. 모든 문장을 같은 공식에 끼워 넣으라는 뜻은 아닙니다.
가상의 운영 담당자 사례를 보겠습니다.
업무만 나열한 초안
고객 문의 응대, 정산 자료 관리, 부서 협업 및 운영 효율 개선.
이 문장에서는 업무 분야는 알 수 있지만 담당 범위와 행동이 보이지 않습니다. 무엇을 고쳤는지 확인할 수 없으니 ‘효율 개선’이라는 평가도 근거가 약합니다.
사실 메모로 풀어 쓴 중간 단계
접수 경로마다 문의 분류명이 달라 담당자를 다시 확인하는 일이 있었다. 나는 반복 문의를 유형별로 정리하고, 담당 부서와 이관 기준을 맞춰 안내 문서를 작성했다. 팀장은 기준을 승인했고, 동료들은 각 채널에 적용했다. 새 기준은 인수인계 자료로 사용됐다. 처리시간의 전후 수치는 측정하지 않았다.
제출용으로 정리한 문장
접수 경로별로 달랐던 문의 유형을 공통 항목으로 정리하고, 담당 부서와 이관 기준을 조율해 응대 안내서를 작성했다. 승인된 기준은 채널 운영과 신규 담당자 인수인계에 활용됐다.
측정하지 않은 처리시간 감소율을 넣지 않아도 행동·협업·산출물·적용 결과가 드러납니다. 이 문장은 해당 업무를 실제로 했고 적용 여부를 확인할 수 있는 사람만 자신의 경험으로 사용할 수 있습니다.
4단계: 숫자는 ‘크게’보다 ‘무엇을 센 것인지’가 중요합니다
숫자는 규모와 변화를 짧게 전달하는 데 유용합니다. 하지만 근거 없는 비율은 내용을 구체화하는 대신 신뢰를 떨어뜨립니다. UC Davis의 성과 문장 안내도 행동과 맥락, 결과가 연결되는 표현을 제안합니다. 숫자는 이 연결을 설명할 수 있을 때 사용하세요.
가령 두 비교 기간의 처리 건수가 같다고 가정하고, 누락 건수가 20건에서 12건으로 줄었다면 감소율은 (20 - 12) ÷ 20 × 100 = 40%입니다. 이것은 건수 감소율입니다. 누락률을 말하려면 각 기간의 전체 처리 건수도 알아야 합니다. 예를 들어 200건 중 20건은 10%, 200건 중 12건은 6%이며, 비율 차이는 4%포인트입니다. 40%와 4%포인트는 서로 다른 값을 설명합니다.
또 개선 전후의 계절·업무량·인원·집계 방식이 다르면 숫자의 해석도 달라집니다. 같은 시기에 시스템이 바뀌거나 동료가 충원됐다면 모든 개선을 자신의 조치 하나로 돌리기 어렵습니다. 비교 기간과 범위, 다른 변화가 무엇인지 질문받았을 때 설명할 수 있어야 합니다.
| 쓰고 싶은 표현 | 먼저 확인할 것 | 확인이 어려울 때 대안 |
|---|---|---|
| 처리시간 30% 단축 | 시작·종료 정의, 평균/중앙값, 비교 기간·표본 | 재작업을 줄이기 위해 바꾼 절차와 실제 적용 범위 |
| 오류율 50% 감소 | 오류 정의, 전체 건수, 전후 집계 기준 | 오류 유형을 정리하고 점검 항목에 반영한 내용 |
| 매출 증가에 기여 | 대상 매출, 기간, 다른 원인, 개인 담당 범위 | 캠페인에서 맡은 분석·제작·운영 범위와 팀 결과 구분 |
| 만족도 향상 | 설문 문항·응답자·응답률·측정 시점 | 확인 가능한 피드백과 그에 따라 수정한 부분 |
| 월 300건 담당 | 무엇을 1건으로 세는지, 기간, 개인/팀 구분 | 수치 확인 전에는 대상·빈도·업무 흐름을 서술 |
숫자가 기억나지 않는다면 추정치를 사실처럼 넣지 않습니다. 당시 확인 가능한 범위만 쓰거나 숫자를 빼세요. ‘성과를 강조하라’는 조언이 측정하지 않은 결과를 만들라는 뜻은 아닙니다.
5단계: 팀 성과에서 나의 역할을 분리합니다
팀이 신규 서비스를 출시했다고 해서 모든 참여자가 출시를 총괄한 것은 아닙니다. 반대로 큰 팀의 한 부분을 담당했다고 기여가 사소해지는 것도 아닙니다. 범위를 정확히 쓰면 어떤 전문성을 발휘했는지 더 잘 보입니다.
역할이 섞인 표현: “신규 서비스 개발을 주도해 출시를 성공시켰다.”
범위를 구분한 표현: “신규 서비스 출시 프로젝트에서 운영 시나리오와 오류 접수 기준을 작성했다. 개발 담당자와 예외 처리 조건을 조율하고, 출시 전 점검 결과를 정리해 수정 사항을 전달했다.”
두 번째 표현을 쓴 사람은 전체 개발을 책임지지 않아도 운영 관점의 설계와 협업을 보여줍니다. 설계·승인·구현·검증 중 무엇을 했는지 구분하세요. 참여 인원으로 나눠 만든 임의의 ‘기여도 25%’보다 담당 범위가 명확한 설명이 유용할 수 있습니다. 지원서가 기여율을 요구한다면 산정 근거를 별도로 설명할 수 있어야 합니다.
직무가 다르면 같은 틀 안에서도 강조점이 달라집니다
아래 세 사례는 서로 다른 역할의 가상 문장입니다. 직무 이름만 바꿔 복사하지 말고 자신이 실제로 한 행동과 확인된 결과로 다시 쓰세요.
운영·사무: 기준과 재현 가능한 절차
월별 정산 자료를 취합하며 거래처별 표기 차이를 공통 항목으로 정리했다. 누락 확인표와 검토 순서를 문서화하고, 담당자가 바뀔 때 같은 순서로 확인할 수 있도록 인수인계 자료에 반영했다.
여기서는 화려한 도구 이름보다 어떤 항목을 맞췄고 어떤 검토 절차를 남겼는지가 중요합니다. 시간이나 오류 감소를 측정하지 않았다면 효과를 확정해서 덧붙이지 않습니다.
개발·데이터: 문제 조건과 선택의 이유
중복 집계가 발생한 보고서의 입력 경로와 집계 기준을 대조해, 동일 항목이 두 경로에서 들어오는 조건을 확인했다. 중복 판정 규칙을 수정하고 경계 사례를 검증한 뒤 정기 보고서 생성 과정에 반영했다.
사용 기술은 문제 해결에 어떻게 쓰였는지 연결합니다. ‘Python·SQL 사용’만 나열하는 것보다 입력 조건·판정 기준·검증 범위를 설명하면 역량을 파악하기 쉽습니다. 성능 개선을 주장하려면 데이터 규모와 실행 조건까지 설명할 수 있어야 합니다.
협업·기획: 의사결정에 쓰인 근거
요청 부서별로 달랐던 기능 요구를 사용 상황과 필수 조건으로 나누어 정리했다. 충돌하는 조건과 미결 사항을 비교표로 만들어 회의에 공유하고, 합의된 범위를 일정과 검수 항목에 반영했다.
회의 횟수만으로 협업의 질을 설명하기는 어렵습니다. 무엇이 충돌했고 어떤 근거를 정리했으며 그 결과 어떤 결정이 가능해졌는지를 보여주는 편이 낫습니다.
경력이 길거나 직무를 바꿀 때는 경험의 선택이 더 중요합니다
경력이 길다면 모든 일을 같은 깊이로 쓰기보다, 최근의 관련 경험은 상세히, 오래되거나 관련이 낮은 경험은 짧게 정리할 수 있습니다. 회사 전체 기간과 프로젝트 기간을 구분하고, 같은 경험을 여러 프로젝트 이름으로 중복해서 부풀리지 않습니다. 페이지 수의 정답을 먼저 정하기보다 지원처의 제한과 읽는 데 필요한 정보를 기준으로 압축합니다.
직무를 바꾼다면 이전 직함을 새로운 직함처럼 바꾸지 말고 옮겨 쓸 수 있는 행동을 보여주세요. 고객 응대 경험은 문의 유형 분류와 원인 정리로, 행사 운영 경험은 일정·이해관계자·예외 관리로 설명할 수 있습니다. 다만 새 직무의 도구나 지식을 아직 학습 중이라면 실무 사용 경험과 구분합니다.
진행 중이거나 목표를 달성하지 못한 프로젝트도 선택할 수 있습니다. 완료한 범위, 확인된 결과, 중단·변경 사유에서 자신이 판단한 부분을 정확히 씁니다. ‘진행 중’이라는 상태를 숨기거나 예상 효과를 실현된 성과로 바꾸지 마세요. 지원 업무와 관계없는 실패담을 길게 쓰기보다는 그 경험에서 확인할 수 있는 역량이 있는지 먼저 판단합니다.
제출할 근거와 나만 확인할 근거를 나누세요
기억을 확인하려고 참고한 내부 보고서가 곧 제출 가능한 첨부파일은 아닙니다. 고객 정보, 미공개 지표, 단가, 사내 시스템 화면, 소스코드에는 공개 제한이 있을 수 있습니다. 회사 이름을 가렸다고 모든 비공개 정보가 사라지는 것도 아닙니다.
Berkeley의 이력서 안내는 고용주의 요구와 자신의 경험을 연결하는 설명을 강조합니다. 이때 결과물을 그대로 보여줄 수 없다면 공개 가능한 수준에서 맥락·역할·방법을 설명하고, 허용된 샘플이나 가상 자료가 있다면 실제 성과 증거와 구분해 표시하세요. 자신이 검토한 원본을 AI나 외부 서비스에 통째로 보내지 않는 판단도 필요합니다. 업무 자료를 AI에 넣기 전 확인할 기준을 함께 참고할 수 있습니다.
면접에서 설명할 근거는 스스로 정리하되 지원서에 비밀 정보를 싣지 않습니다. 공개 범위를 확신할 수 없다면 조직 지침이나 권한 있는 담당자에게 확인합니다. 경력기술서는 사실성과 정보 보호를 함께 지켜야 하는 문서입니다.
한 건의 완성형은 이 정도 정보로 시작할 수 있습니다
아래는 도구몽의 빈 작성 양식입니다. 회사의 지정 양식이 없을 때 메모 틀로 활용하고, 항목이 겹치면 합쳐도 됩니다. 개인정보와 비공개 원본은 옮겨 적지 마세요.
[경험 제목 / 기간]
지원 업무와의 연결:
업무 배경과 범위:
문제 또는 목표:
내 역할과 협업 범위:
직접 한 행동:
완성한 산출물과 확인된 결과:
제출 가능한 근거와 설명할 한계:
처음에는 사실 메모로 충분히 적은 뒤, 중복된 배경과 평가 표현을 덜어냅니다. 회사 소개가 길고 내 행동이 한 줄이면 비중을 바꾸세요. “탁월한 분석력”보다 어떤 기준으로 자료를 대조했는지, “원활한 협업”보다 무엇을 합의했는지를 남깁니다.
마지막 검토는 여섯 질문으로 하세요
- 관련성: 이 경험이 공고의 어떤 업무에 도움이 되는지 설명할 수 있나요?
- 역할: 팀 전체 결과와 직접 한 일을 구분했나요?
- 구체성: ‘관리·개선·지원’ 뒤에 대상과 방법이 있나요?
- 결과: 목표·산출물·확인된 효과·미확인을 구분했나요?
- 근거: 숫자의 단위·기간·분모·출처를 질문받아도 설명할 수 있나요?
- 공개 범위: 제출 내용에 고객 정보와 비공개 자료가 섞이지 않았나요?
검토를 마친 내용은 이력서 작업실의 경력·프로젝트·직접 만든 항목 중 목적에 맞는 곳에 정리할 수 있습니다. 이력서 PDF를 만들 수 있다는 것과 지원처가 요구한 별도 경력기술서 양식을 충족하는 것은 구분하세요. 내려받은 파일의 기간·줄바꿈·페이지 경계도 직접 확인합니다.
직접 한 건을 작성해 보세요
아래 도구는 문장을 대신 지어내거나 점수로 평가하지 않습니다. 입력한 사실을 항목별 초안으로 정리하고, 작성 중 빠뜨린 질문을 확인하도록 돕습니다. 먼저 가상 예시를 살펴본 뒤 자신의 경험 하나로 바꿔 보세요. 목표는 경력 전체를 한 번에 완성하는 것이 아니라, 근거를 설명할 수 있는 한 건을 만드는 것입니다.