[Chapter 4. 서류전형] 이력서/포트폴리오는 어떻게 만드나요?
포트폴리오에 프로젝트를 담을 때 "어디서부터 어디까지 써야 하는가"를 몰라서 막막한 경우가 많다. 결과만 적으면 너무 짧고, 전부 다 쓰려면 너무 길어진다. 좋은 프로젝트 소개는 읽는 사람이 "왜 했는지, 어떻게 했는지, 어떤 결과가 있는지"를 자연스럽게 이해할 수 있는 것이다.
프로젝트 소개의 첫 번째 요소는 배경과 문제 정의다. 이 프로젝트를 왜 시작하게 됐는지, 어떤 문제가 있었는지를 먼저 설명하는 것이 기본이다. 배경이 없으면 읽는 사람은 왜 이 프로젝트가 필요했는지 이해하지 못한 채 내용을 따라가게 된다.
문제 정의는 구체적일수록 좋다. "사용자 경험이 좋지 않았다"보다 "신규 가입 후 첫 구매까지의 전환율이 업계 평균 대비 절반 수준이었고, 원인이 온보딩 과정의 복잡성에 있다고 판단했다"처럼 데이터나 근거와 함께 쓰는 방향을 추천한다. 문제를 얼마나 명확하게 정의했는지가 이후 해결 방식의 설득력을 결정한다.
배경 설명은 짧게 담는 것이 좋다. 맥락 파악에 필요한 최소한의 정보만 포함하고, 핵심은 문제 정의에 집중하는 것이 효과적이다.
프로젝트에서 팀 전체가 한 것과 내가 직접 한 것을 구분해서 쓰는 것이 중요하다. "우리 팀이 이런 기능을 만들었다"보다 "나는 사용자 인터뷰 설계와 진행을 맡았고, 그 결과를 바탕으로 기능 우선순위를 제안했다"처럼 내 역할이 명확하게 보여야 한다.
접근 방식을 쓸 때는 어떤 판단과 선택의 과정이 있었는지를 포함하는 것이 훨씬 입체적인 이야기가 된다. 단순히 기능을 기획했다고 쓰는 것보다, 어떤 유저 문제를 해결하기 위해 왜 그 기능이 필요하다고 판단했는지를 담는 방향이 설득력이 훨씬 높다. 각 과정에서 겪은 갈등이나 선택의 이유까지 포함하면 더욱 좋다.
팀 프로젝트였더라도 내가 기여한 부분이 명확하다면 충분히 좋은 사례가 된다. 중요한 건 팀의 성과가 아니라 나의 판단과 행동이 보이는 것이다.
프로젝트 소개의 마무리는 결과다. 수치가 있다면 함께 담는 것이 가장 좋다. "전환율이 8% 개선됐다", "사용자 만족도 점수가 상승했다"처럼 프로젝트 전후의 변화를 보여주면 설득력이 크게 높아진다.
수치가 없는 경우라면 정성적인 변화나 후속 행동을 담는 것도 좋다. "이 프로젝트 이후 팀 내 사용자 인터뷰 프로세스가 표준화됐다", "다음 기획에서 동일한 접근 방식을 적용했다"처럼 프로젝트가 가져온 변화를 보여주는 방향을 추천한다.
결과 없이 과정만 담은 프로젝트 소개는 읽는 사람 입장에서 끝이 열린 느낌을 준다. 결과의 규모가 작더라도 어떤 형태로든 마무리를 짓는 것이 훨씬 완성도 있는 프로젝트 소개가 된다.
하나의 프로젝트는 배경과 문제 정의, 내 역할과 접근 방식, 결과와 변화 이 세 가지를 모두 담아야 완성된다. 결과만 나열하거나 과정만 길게 쓰는 것보다, 왜 했는지부터 어떤 변화가 있었는지까지의 흐름이 자연스럽게 이어지는 것이 가장 좋은 프로젝트 소개라고 생각한다.
* 전체 내용을 정리한 전자책은 아래에서 확인할 수 있습니다.
* 관련 실제 합격 포트폴리오를 확인하고 싶으시다면 아래에서 확인할 수 있습니다.