첫 문장을 쓰기 전에 문서의 질문 정하기
경력기술서를 읽는 사람이 확인할 질문을 먼저 적습니다. 어떤 환경에서 일했는가, 무엇을 직접 맡았는가, 어떤 선택을 했는가, 그 뒤 무엇이 달라졌는가입니다. 회사 소개를 길게 쓰고 업무명을 나열하면 이 질문에 대한 답이 뒤로 밀립니다. 회사와 서비스의 맥락은 경험을 이해하는 데 필요한 만큼만 남기세요. 예를 들어 기업 고객을 대상으로 한 주문 서비스라는 설명은 유용하지만, 회사의 설립 배경을 여러 문단으로 옮길 필요는 없습니다.
이력서가 근무 기간과 직무를 찾기 쉽게 보여준다면 경력기술서는 그 이력의 내용을 펼쳐 보이는 역할을 합니다. 두 파일을 반드시 따로 내야 하는 것은 아닙니다. 지원 공고가 지정한 문서와 입력 항목을 먼저 확인하고, 한 문서로 제출할 때는 요약 다음에 대표 프로젝트를 배치합니다. 토스의 공식 합류 안내처럼 기업이 자체적인 작성 권고를 제공하기도 하므로 모든 회사에 같은 구성이 통한다고 단정하지 마세요.
경험을 고르는 세 가지 기준
첫째는 관련성입니다. 지원할 업무에서 다루는 문제와 닮은 경험을 고릅니다. 둘째는 설명 가능성입니다. 직접 했던 판단과 행동을 구체적으로 떠올릴 수 있어야 합니다. 셋째는 근거입니다. 수치가 없더라도 실제 배포한 기능, 합의한 지침, 검증한 결과처럼 확인할 수 있는 변화가 있어야 합니다. 규모가 큰 사업에 잠깐 참여한 경험보다 작은 문제를 처음부터 끝까지 책임진 경험이 더 설명하기 쉬울 수 있습니다.
후보 경험을 다섯 개 정도 메모한 뒤 각 경험 옆에 담당 범위와 증거 위치를 적어보세요. 가장 최근이라는 이유만으로 대표 사례를 정하지 않습니다. 오래된 경험을 앞에 놓아야 한다면 지원 직무와의 관련성을 요약에서 설명하고, 근무 기간은 따로 명확하게 유지합니다. 아직 진행 중인 프로젝트는 목표와 완료된 부분을 나누고 예상 성과를 확정 성과처럼 쓰지 않습니다.
가상 사례: 고객 문의 운영 경험을 풀어쓰기
수정 전 문장은 고객 문의 대응 및 운영 업무 수행입니다. 무엇을 했다는 뜻인지는 알지만 문제의 난도와 개인의 판단은 보이지 않습니다. 가상 사례의 담당자는 문의가 여러 유형으로 중복 분류되어 답변 기준을 찾기 어렵다는 문제를 발견했습니다. 담당자의 책임은 문의 유형 분석과 지침 초안 작성이었고 최종 정책 결정은 팀장이 맡았습니다. 이 경계를 먼저 정리하면 주도라는 말을 과하게 쓰지 않아도 역할이 드러납니다.
수정 문장은 다음처럼 구성할 수 있습니다. 중복 분류된 문의의 공통 원인을 분석하고 담당자 검토를 거쳐 분류 기준과 예외 처리 지침을 통합했습니다. 이후 운영팀이 같은 문서에서 응대 기준을 확인하도록 정리했습니다. 실제 처리 시간의 변화는 측정하지 않았습니다. 마지막 문장은 약점을 강조하려는 것이 아니라 결과의 범위를 분명히 하는 장치입니다. 없는 숫자를 더하는 대신 문서가 실제 사용되었는지 확인하는 편이 정확합니다.
프로젝트 한 묶음의 작성 순서
프로젝트명과 기간을 먼저 쓰고 문제를 두세 문장으로 정리합니다. 다음에는 팀의 목표와 자신의 책임을 분리합니다. 행동은 분석했다, 설계했다, 검토했다처럼 실제 수행한 동사로 시작하되 무엇을 기준으로 판단했는지 덧붙입니다. 결과에는 관찰한 변화와 측정 조건을 함께 씁니다. 마지막에는 사용한 도구를 적어 도구 목록이 문제 해결의 맥락과 연결되게 만듭니다.
여러 프로젝트에서 같은 업무 설명을 반복할 필요는 없습니다. 공통 업무는 경력 요약에 두고 각 프로젝트에는 다른 결정과 결과를 남기세요. 운영 경험이라면 한 사례는 기준 정리, 다른 사례는 장애 대응, 또 다른 사례는 협업 방식 개선으로 나눌 수 있습니다. 업무 전체를 빠짐없이 기록하는 원본과 실제 지원용 문서를 분리하면 다음 지원 때도 사실을 다시 찾는 수고를 줄일 수 있습니다.
수치와 팀 성과를 정확히 다루기
매출이 늘었다고 쓸 때는 무엇과 무엇을 비교했는지 설명해야 합니다. 같은 기간의 다른 변화가 있었는지, 본인의 작업만으로 생긴 결과인지도 확인합니다. 팀 전체의 결과라면 팀 성과라고 표시하고 본인이 맡은 행동을 바로 이어 씁니다. 정확한 기여 비율을 계산한 근거가 없다면 임의의 퍼센트를 붙이지 마세요. 담당 기능, 의사 결정 범위, 산출물로 역할을 구분하는 방법이 더 구체적일 수 있습니다.
수치를 공개할 수 없다면 승인된 범위 안에서 상대 변화나 업무 규모를 표현할 수 있는지 확인합니다. 공개 가능 여부가 불분명한 자료는 경력기술서에 붙이지 않습니다. 다만 비공개라는 이유로 행동까지 모두 추상적으로 만들 필요는 없습니다. 고객명을 숨기고도 어떤 기준을 비교했으며 어떤 절차를 바꾸었는지는 설명할 수 있습니다. 내용의 진실성과 정보 공개 범위를 함께 점검하세요.
제출 전에 소리 내어 검토하기
문서의 각 문장을 보고 왜 그렇게 했는지 한 번 더 말해봅니다. 문서에는 그럴듯하게 적었지만 이유를 설명하기 어렵다면 기억과 기록을 확인해야 합니다. 동료에게 검토를 부탁할 때는 합격할 것 같은지보다 담당 범위가 이해되는지, 어떤 행동이 결과와 연결되는지를 물어보세요. 문서의 목적에 맞는 질문이 수정 방향을 더 분명하게 만들어줍니다.
경력노트에는 대표 프로젝트 하나를 입력해 구조를 만든 다음 자신의 문체로 편집할 수 있습니다. 결과물은 완성된 지원서가 아니라 확인할 수 있는 초안입니다. 기간과 수치, 비공개 정보, 공고의 분량 요건을 확인하고 파일을 저장하세요. 다른 프로젝트를 만들기 전에 현재 내용을 내려받아 두면 새 초안 생성 과정에서 이전 편집 내용을 잃는 일을 줄일 수 있습니다.
자주 묻는 질문
경력기술서는 몇 장이 적당한가요?
모든 기업에 적용되는 정답은 없습니다. 공고의 제한을 우선하고, 대표 경험을 충분히 설명하면서 반복되는 업무 소개를 줄이세요. 장수보다 역할과 근거가 쉽게 보이는지 확인하는 편이 유용합니다.
수치가 없는 업무도 적을 수 있나요?
네. 실제 채택된 절차, 배포한 기능, 확인된 오류 원인처럼 관찰 가능한 결과를 적을 수 있습니다. 처리 시간이 줄었다는 추정을 측정한 수치처럼 쓰지는 마세요.