첫째, 직무명보다 동사를 표시합니다
“서비스 기획자”라는 제목만으로 하루의 업무를 알 수는 없습니다. 공고의 “담당 업무”에서 설계한다, 분석한다, 운영한다, 협업한다 같은 동사를 표시하세요. 다음으로 그 동사의 목적어를 적습니다. “고객 데이터를 분석한다”와 “신규 기능을 설계한다”는 같은 직무명 아래 있어도 준비할 경험이 다릅니다.
핵심 업무는 세 개만 먼저 고릅니다. 공고 전체를 완벽하게 해석하려다 시간을 다 쓰기보다, 반복해서 등장하거나 문단 앞부분에 놓인 일을 우선 읽으세요. 각 업무 옆에는 “내가 직접 해본 일”, “함께한 일”, “해보지 않은 일” 중 하나를 표시합니다.
“사용자 피드백 분석 및 제품 개선안 도출” → 사용자 의견을 어떻게 모았는가? 직접 분석한 범위는 어디까지인가? 개선안이 실제로 적용되었는가?
둘째, 필수와 우대를 섞지 않습니다
필수 요건은 업무 수행의 최소 조건으로 제시된 항목이고, 우대 사항은 있으면 유리한 경험입니다. 두 목록을 한 덩어리로 읽으면 작은 공백에도 지원을 포기하거나, 반대로 핵심 공백을 놓칠 수 있습니다.
항목마다 단순히 “있다/없다”보다 근거의 강도를 적어 보세요. 직접 수행한 프로젝트가 있는지, 협업으로 참여했는지, 학습만 했는지를 구분합니다. 같은 도구 이름을 이력서에 써도 실제 책임 범위가 다르면 면접에서 답하기 어렵습니다.
- 필수: 없으면 해당 업무를 수행하기 어려운 조건인가?
- 우대: 업무에 도움이 되지만 다른 근거로 보완 가능한가?
- 모호한 표현: “능숙함”이나 “탁월함”의 수준을 어떤 사례로 증명할 수 있나?
셋째, 지원 판단을 질문으로 바꿉니다
공고와 경력이 얼마나 “일치”하는지 점수 하나로 판단하지 마세요. 대신 업무별로 내가 설명할 수 있는 사례를 하나씩 연결합니다. 사례가 없으면 표현의 문제인지 실제 경험의 공백인지 먼저 구분합니다.
예를 들어 “데이터 기반 의사결정” 경험이 부족하다면, 데이터를 직접 분석한 적은 없지만 정성 피드백으로 우선순위를 정한 사례가 있을 수 있습니다. 그런 경우 이력서에서 사실을 정확히 설명하고, 요구 수준은 채용 담당자에게 확인하는 편이 낫습니다.
지원 전에 남길 한 장 메모
- 이 역할의 핵심 업무 세 가지는 무엇인가?
- 각 업무와 연결되는 내 경험의 증거는 무엇인가?
- 필수 요건 중 설명하기 어려운 항목은 무엇인가?
- 지원한다면 어떤 경험을 이력서 첫 부분에 배치할 것인가?
- 면접에서 회사에 확인할 질문은 무엇인가?
이 메모를 만든 뒤 지원 현황 도구에 공고 링크와 다음 할 일을 저장해 보세요. 지원 여부를 아직 결정하지 않았다면 단계는 “관심”으로 두고, 다음 행동을 “핵심 업무 3개 비교하기”처럼 구체적으로 남길 수 있습니다.