프로젝트의 경계를 목표로 정하기
회사에서 프로젝트라는 이름을 붙이지 않았더라도 일정한 문제를 해결하려고 수행한 업무 묶음이 있다면 경험으로 정리할 수 있습니다. 다만 반복 업무를 전부 별개의 프로젝트로 쪼개면 실제 역할이 오히려 보이지 않습니다. 같은 목표와 같은 판단 기준으로 이어진 작업은 하나로 묶고, 해결한 문제와 결과가 달라졌을 때 새로운 사례로 나누세요. 공식 명칭이 없는 경우 설명형 제목을 사용해도 됩니다.
기간은 사업 전체 기간과 자신의 참여 기간을 구분합니다. 오랜 사업의 마지막 단계에 참여했다면 전체 기간을 자신의 경험처럼 적지 않습니다. 진행 중인 업무는 현재까지 완료한 부분과 앞으로 할 일을 분리합니다. 종료 상태가 명확해지면 결과 문장에 계획과 성과가 섞이는 일을 줄일 수 있습니다. 원티드의 공개 이력서 예시는 프로젝트 정보를 배치하는 참고 자료로 볼 수 있습니다.
한 프로젝트에서 남길 장면 선택하기
프로젝트가 길다면 모든 활동을 순서대로 기록하기보다 중요한 결정이 있었던 장면을 고릅니다. 문제의 원인을 다시 정의한 순간, 두 대안 중 하나를 선택한 순간, 예외 상황 때문에 실행 방식을 바꾼 순간이 후보가 됩니다. 그 장면에서 본인이 무엇을 확인했고 어떤 행동을 했는지 설명할 수 있어야 합니다. 단순히 회의에 참석했다는 사실만으로는 판단의 내용이 드러나지 않습니다.
같은 프로젝트에서 여러 역량을 보여주고 싶다면 대표 판단을 중심으로 묶습니다. 예를 들어 요구사항 정리와 일정 조율은 범위를 합의한 하나의 흐름으로 설명할 수 있습니다. 반면 전혀 다른 고객 문제를 해결한 후속 작업이라면 별도 사례가 더 읽기 쉽습니다. 문서의 분량을 늘리기 위한 분할이 아니라 읽는 사람이 원인과 행동, 결과를 따라갈 수 있는 단위를 찾는 과정입니다.
가상 사례: 일상 운영에서 프로젝트 찾기
가상 사례의 운영 담당자는 매일 입점사의 상품 등록 문의를 받았습니다. 처음에는 고객 응대라는 한 줄로 적었지만 반복되는 오류 유형을 따로 정리한 경험이 있었습니다. 문의를 분류하고 등록 안내의 누락 항목을 찾아 담당 부서와 수정한 작업을 하나의 프로젝트로 묶을 수 있습니다. 프로젝트명은 상품 등록 안내의 예외 기준 정리이며 기간은 실제 검토와 반영에 참여한 기간입니다.
역할은 문의 분석과 안내 초안 작성, 행동은 오류 유형 비교와 담당자 검토, 결과는 수정 안내의 배포로 정리합니다. 매일 처리한 모든 문의 건수를 성과로 가져오지 않고 이 개선 작업과 관련된 근거만 남깁니다. 전체 문의가 줄었는지 확인하지 않았다면 그 효과는 적지 않습니다. 일상 업무 속에서도 문제를 발견하고 기준을 바꾼 행동을 찾을 수 있다는 가상 예시입니다.
배경과 행동의 분량 조절하기
배경이 길어지면 핵심 행동이 뒤로 밀립니다. 회사 조직과 서비스 구조를 모두 설명하기 전에 그 정보가 자신의 판단을 이해하는 데 필요한지 확인하세요. 필요한 맥락은 남기되 행사 일정이나 참여 부서 목록처럼 중요하지 않은 정보는 줄입니다. 반대로 복잡한 업무라는 말만 남기면 어떤 제약이 있었는지 알 수 없으므로 일정, 권한, 자료 부족 중 실제 영향을 준 조건을 명시합니다.
행동은 단계만 나열하지 말고 연결 이유를 적습니다. 문의를 모았다, 회의를 했다, 문서를 만들었다보다 문의의 중복 기준을 비교해 합의가 필요한 예외를 추렸다는 문장이 더 구체적입니다. 본인이 직접 판단하지 않은 단계는 팀의 결정이라고 구분합니다. 결과와 관계없는 활동을 줄이면 한 프로젝트 안에서도 무엇을 강조할지 명확해집니다.
종료와 인수인계를 결과에 포함하기
배포나 출시가 프로젝트의 유일한 종료 상태는 아닙니다. 검토 후 중단했거나 다른 팀으로 인수인계한 경우도 있습니다. 중단한 작업은 중단 이유와 완료한 검증을 적고, 인수인계한 작업은 넘긴 산출물과 이후 확인 범위를 설명합니다. 자신의 참여가 끝난 뒤 발생한 성과를 직접 확인하지 못했다면 사실인 것처럼 적지 않습니다.
운영으로 넘어간 프로젝트라면 이후 어떤 문제가 나타났고 누가 대응했는지 구분할 필요가 있습니다. 본인이 초기 검증까지만 했는지 지속 운영까지 맡았는지에 따라 역할 설명이 달라집니다. 인수인계 문서를 작성했다면 그 내용과 실제 사용 상황을 설명할 수 있습니다. 단순히 성공적으로 완료했다는 표현보다 종료 상태를 명확하게 적는 것이 다음 질문에도 답하기 쉽습니다.
여러 프로젝트를 묶은 문서 검토하기
문서를 완성한 뒤 프로젝트 제목만 읽어보세요. 모두 서비스 개선이라면 각 사례의 차이가 드러나지 않습니다. 해결한 문제나 핵심 변경을 제목에 넣으면 읽는 사람이 관심 있는 경험을 찾기 쉽습니다. 기간, 역할, 행동, 결과의 순서는 일관되게 유지하되 모든 프로젝트의 분량을 동일하게 만들 필요는 없습니다. 지원 직무와 직접 관련된 경험에 더 많은 설명을 배정합니다.
경력노트는 프로젝트 하나를 정리하는 도구입니다. 첫 경험을 만들고 편집한 뒤 텍스트로 저장하고 다음 경험을 입력하세요. 여러 파일을 합칠 때는 공통 업무 설명을 줄이고 사례별로 다른 판단을 남깁니다. 프로젝트 사이에 같은 수치가 반복된다면 실제로 별개의 성과인지 확인해야 합니다. 하나의 팀 결과를 여러 번 합산하거나 반복 강조하는 방식은 피합니다.
자주 묻는 질문
반복 운영 업무도 프로젝트가 되나요?
특정 문제를 발견하고 개선한 작업이라면 그 목표와 기간으로 묶을 수 있습니다. 일상 업무 전체를 임의로 여러 프로젝트로 쪼갤 필요는 없습니다.
프로젝트가 중단되었으면 빼야 하나요?
지원 직무와 관련된 판단과 검증을 설명할 수 있다면 포함할 수 있습니다. 중단 사실과 완료한 범위, 후속 결과의 확인 여부를 구분하세요.