실무엔 없던 ‘문제-가설-검증’, 경력기술서엔?
모든 회사가 ‘문제-가설-검증’ 방식으로 일하진 않으니까요
경력기술서나 포트폴리오를 문제 정의-가설 수립-액션 및 검증-결과 순서로 작성해 주세요
요즘 채용공고에서 많이 보이는 문장이다. 이 문장은 토스에서 시작된 후 여러 IT 기업들이 채용 공고에 많이 포함하게 된 문구이다. 구직자 입장에서는 반갑기도 하지만, 의문도 생길 수 있다. 반가운 이유는 경력기술서의 작성 방향성이 명확히 정해진다는 점이고, 의문이 드는 이유는 모든 회사가 실제로 저런 순서와 방식으로 일을 하지는 않기 때문이다.
토스의 Product Manager 채용공고그렇다면, 실제로 저런 방식으로 일하지 않는 회사를 다녔더라도 경력기술서를 이런 흐름에 맞춰 재구성할 수 있을까? 충분히 가능하다고 본다.
이해를 돕기 위해 예시로 FAQ 개선 프로젝트를 들어보겠다.
- 이 프로젝트는 고객센터 문의 중 반복되는 질문을 줄이는 것이 목적이었다.
- FAQ에 이미 있는 답변인데도 고객센터 문의가 많이 들어오고 있었다. 사용자가 FAQ에서 필요한 정보를 찾지 못하는 것이 문제였다.
- 그래서 우리는 FAQ 접근성을 높이고 콘텐츠를 정비해, 고객이 원하는 답을 더 쉽게 찾을 수 있도록 하기로 했다.
- 이를 위해 FAQ 진입 경로를 개선하고, 자주 묻는 질문을 위주로 FAQ 카테고리를 재정비하는 등의 작업을 진행했다.
이 프로젝트를 문제 정의-가설 수립-액션 및 검증-결과의 형식으로 풀어서 재구성해보도록 하자.
1. 문제 정의: 프로젝트의 시작점 찾기
경력기술서에서 ‘문제 정의’를 작성하는 것은, 프로젝트를 왜 시작하게 되었는지를 설명하는 부분이다. 사실 모든 프로젝트에는 ‘문제 정의’가 있을 수밖에 없다. 비록 회사에서 임원이 “이 기능 좀 고치자”라고 탑다운 방식으로 지시했다고 해도, 왜 이런 지시가 나왔는지, 그 배경이 된 사업적 필요나 문제 상황이 있을 것이다.
FAQ 개선 프로젝트에서는 고객센터 문의가 계속해서 증가하고, 그중 40%가 FAQ에 이미 있는 답변을 반복적으로 문의하는 문제 상황이 있었다. 고객센터의 효율성을 높이고, 사용자들이 필요한 정보를 쉽게 찾을 수 있도록 FAQ의 가시성을 개선하여 고객 문의를 줄이는 것이 이 프로젝트의 목표였다.
따라서 문제 정의를 작성할 때는, 사업적 배경, 유저의 문제, 또는 서비스 개선 필요성을 배경으로 하여 시작해 보는 것이 좋다. 예를 들어, “고객 문의가 증가하여 상담팀의 효율성이 떨어지고 있었고, 이에 따라 FAQ 기능을 개선해 사용자들이 자주 묻는 질문을 쉽게 찾을 수 있도록 개선 프로젝트를 시작하게 되었다”와 같은 식으로 작성할 수 있다.
2. 가설 수립: 기준을 설정하고 채택하는 과정
가설 수립 단계는 문제를 해결하기 위해 가능한 여러 가지 추론을 세우고, 그중 실현 가능성이 높은 가설을 선택하는 과정이다. 예를 들어 “FAQ 페이지가 눈에 띄지 않아서, 사용자들이 FAQ를 찾지 못할 것이다”라는 가설을 세울 수 있다. 이때 가설을 세운 기준과 채택한 이유를 간단히 덧붙일 수도 있다.
FAQ 프로젝트에서 우리는 다음과 같은 가설을 세울 수 있었다.
- 가설 1: FAQ 페이지가 눈에 띄지 않아, 사용자가 정보를 찾기 어렵다.
- 가설 2: 고객센터 문의 페이지에 FAQ를 먼저 보여주면 문의량이 줄어들 것이다.
- 가설 3: 검색 기능이 FAQ 항목을 잘 반영하지 못해 원하는 답변을 찾지 못한다.
여러 가지 가설 중 몇 가지를 채택할 때는 목표에 부합하는가, 검증 가능성과 실현 가능성이 높은가, 그리고 비용 대비 효과가 충분한가 등 다양한 기준을 적용해 선택하게 된다. 아래는 가설을 채택할 때 고려할 수 있는 기준들이다. 이러한 기준까지 설명해 준다면 설득력이 더 높아질 것이다.
데이터 기반의 명확한 근거 유무
목표와의 적합성
검증 가능성과 측정 가능성
실행 가능성과 리소스
비용 대비 효과
리스크와 실패 가능성
빠르게 검증할 수 있는지 여부
위의 세 가지 중에서 가설 1과 가설 2를 우선적으로 선택했다. 이 가설들은 확실한 데이터(FAQ 접근율 10%)와 사용자 피드백(문의량 증가)이 뒷받침되었고, 가시성 개선이라는 비교적 쉬운 방법으로 가설을 검증할 수 있었기 때문이다.
3. 액션 및 검증: 다양한 검증 방법과 선택 기준
‘액션’은 문제 해결을 위한 구체적인 조치를 의미하며, ‘검증’은 그 조치가 효과가 있는지를 평가하는 단계이다. 이때 액션 및 검증 단계에서는 A/B 테스트, 전후 데이터 비교, 사용자 피드백 수집 등의 방법들이 있다.
이 프로젝트에서 액션은 크게 두 가지였다.
1) FAQ 진입 경로 추가: 메인 화면과 설정 메뉴, 고객센터 문의 페이지에 FAQ 바로가기 버튼을 추가
2) FAQ 콘텐츠 재정비: 자주 묻는 질문 카테고리를 재정리하고, 자주 검색하는 질문을 중심으로 내용을 정리
검증 방법으로는 Google Analytics를 통해 FAQ 진입률을 추적하고, 고객센터 문의 데이터를 전후 비교해 FAQ 기능 개선의 효과를 측정했다.
따라서 경력기술서에는 실행한 구체적인 조치와 그 결과를 검증한 방식을 명시하고, 가능하다면 이를 선택한 기준까지 설명해 주는 것이 좋다. 예를 들어 “비용과 시간제한으로 인해 전후 비교 방식을 선택했고, 개선 후 데이터를 분석하여 성공 여부를 확인했다”와 같은 식으로 작성할 수 있다.
4. 결과 분석: 개선 성과를 수치화하고 추가 개선점 도출
결과 분석 단계에서는 액션과 검증을 통해 도출한 성과를 수치화하는 것이 중요하다.
FAQ 진입 경로 개선 후 진입률이 기존 10%에서 30%로 증가했고, FAQ에 이미 답변이 있는 질문이 고객센터 문의에서 차지하는 비율이 30% 감소했다.
이처럼 결과가 가시적인 수치로 증명되면 효과적인 개선 성과로 나타낼 수 있다. 만약, 결과를 정량적으로 수치화하기 어려울 때에는 정성적인 측면을 보완하여 성과를 표현할 수도 있다. 예를 들면,
1) 정성적 피드백: 사용자 인터뷰, 설문조사, 팀원 및 관련 부서 피드백을 통해 구체적인 개선점과 긍정적 반응을 수집하여 기재할 수 있다.
2) 업무 효율성 개선 언급: 프로젝트 결과로 고객센터나 업무 시스템 내 프로세스가 개선되어 특정 업무에 드는 시간이 단축된 점을 설명할 수 있다.
3) 레슨 런: 얻게 된 핵심 인사이트와 학습 포인트를 요약하여 성과를 대신할 수 있다.
만약 결과가 가설과 다르게 나왔다면, 이로 인해 발생한 추가 개선점이나 새로운 가설을 간략히 언급하는 것도 좋다.
채용 공고에서 요구하는 “문제 정의-가설 수립-액션 및 검증-결과” 방식은 모든 회사가 일하는 방식과 다를 수 있지만, 자신의 경험을 이 형식으로 재구성하는 과정은 분명 도움이 된다. 프로젝트 경험을 체계화함으로써, 기획자로서 문제를 정의하고 개선을 이끄는 과정을 명확히 정리해 볼 수 있기 때문이다.
이 방식으로 경력기술서를 작성하면, 단순한 경험 나열이 아니라 목표와 성과가 뚜렷한 프로젝트 흐름을 보여줄 수 있다는 것이 큰 장점이다. 또한, 그 과정에서 실제 업무 경험을 스스로 돌아보고, 다음 프로젝트에서는 어떤 부분을 더 보완해야 할지 파악할 수 있는 기회가 될 것이다.
