디자이너가 아니어도 만들 수 있는 포트폴리오 프레임
지난 글에서 이런 이야기를 했습니다.
포트폴리오가 필요 없는 직무는 없다.
이력서는 주장이고 포트폴리오는 증거다.
이렇게 얘기를 하면, 대부분의 분들이 공감을 합니다. 그런데 동시에 이렇게 얘기합니다.
"필요한 건 알겠는데, 막상 만들려고 하면 막막해요."
이해합니다. 막막한 게 당연합니다.
그런데 그 막막함의 원인을 들여다보면, 쓸 내용이 없어서인 경우는 별로 없습니다. 정리하는 방식을 모르기 때문입니다. 무엇을 어떤 순서로 어디까지 써야 하는지 기준이 없으니, 시작도 못하는 겁니다.
이 글에서는 그 방법을 알려드리고자 합니다. 직무와 상관없이 이 구조만 따라가면 포트폴리오를 완성할 수 있습니다.
가장 먼저 내려놓아야 할 것이 있습니다. '포트폴리오는 예뻐야 한다'는 생각입니다. 디자이너의 포트폴리오가 먼저 떠오르기 때문에 자연스럽게 그런 인상이 생깁니다.
깔끔한 레이아웃, 정돈된 목업, 시각적으로 완성된 결과물.
그걸 기준으로 삼으면 다른 직무의 사람들은 시작하기도 전에 포기하게 됩니다.
하지만 평가자가 포트폴리오에서 보고 싶은 건 디자인의 퀄리티가 아닙니다.
어떤 상황에서, 무엇을 문제라고 인식했고, 어떤 방식으로 접근했고, 그 결과 무엇이 달라졌는지. 즉 일한 방식을 보고 싶은 겁니다. 그러니 포트폴리오를 작품집이라고 생각하지 마세요. 내가 일하는 방식을 설명하는 문서라고 생각하면 됩니다.
그러면 훨씬 쉬워집니다.
직무가 다르면 다루는 내용은 달라집니다. 하지만 일을 설명하는 구조는 크게 다르지 않습니다. 어떤 직무든 아래 다섯 단계를 따라가면 포트폴리오 한 건을 만들 수 있습니다.
① 맥락 - 어떤 상황이었는가.
어떤 조직에서, 어떤 시점에, 어떤 조건 아래에서 이 일이 시작되었는지를 간결하게 설명합니다. 읽는 사람이 배경을 이해할 수 있을 정도면 충분합니다.
② 문제 정의 - 무엇을 해결해야 했는가.
'이런 업무를 맡았다'가 아니라 그 안에서 내가 발견하거나 부여받은 핵심 문제가 무엇이었는지를 짚습니다. 문제를 어떻게 정의하느냐가 그 사람의 시야를 보여줍니다.
③ 접근 방식 - 어떤 판단과 선택을 했는가.
문제를 풀기 위해 어떤 방법을 선택했고, 왜 그 방법을 선택했는지를 설명합니다. 여러 선택지 중 하나를 고른 이유, 우선순위를 정한 기준이 여기에 들어갑니다.
평가자가 가장 주의 깊게 보는 부분입니다.
④ 실행과 결과 - 무엇을 했고, 무엇이 달라졌는가.
실제로 어떤 행동을 했는지, 그 결과 수치나 상황이 어떻게 변했는지를 정리합니다. 정량 지표가 있으면 좋지만, 없더라도 이전과 이후의 변화를 구체적으로 서술하면 됩니다.
⑤ 회고 - 다시 한다면 무엇을 바꿀 것인가.
이 단계를 빼먹는 사람이 많습니다. 하지만 이 부분이 있는 포트폴리오와 없는 포트폴리오는 신뢰도가 다릅니다. 잘된 것과 아쉬운 것을 함께 쓸 수 있는 사람은 자기 일을 객관적으로 볼 줄 아는 사람이라는 인상을 줍니다.
이 다섯 단계가 포트폴리오의 뼈대입니다. 이제 이 구조가 실제 직무에서 어떻게 채워지는지 보겠습니다.
1. 마케터
① 맥락
월 광고비 3,000만 원 규모의 퍼포먼스 마케팅을 운영하고 있었습니다. 주요 채널은 메타와 구글이었고, 전환 단가는 업계 평균 수준이었습니다. 그런데 어느 시점부터 신규 유입은 유지되는데 전환율이 서서히 떨어지기 시작했습니다.
② 문제 정의
광고 유입 자체는 문제가 아니었습니다. 문제는 유입 이후였습니다. 랜딩 페이지에 도달한 사용자의 이탈률이 높아지고 있었고, 특히 모바일에서 이 현상이 두드러졌습니다. 광고의 메시지와 랜딩 페이지의 내용 사이에 기대 불일치가 있다고 판단했습니다.
③ 접근 방식
광고 소재별로 랜딩 페이지 체류 시간과 스크롤 깊이를 분석했습니다. 가장 전환율이 높은 소재와 가장 낮은 소재의 메시지 톤을 비교한 뒤, 랜딩 페이지의 첫 화면 카피를 광고 소재와 일치시키는 A/B 테스트를 설계했습니다. 동시에 모바일 환경에서의 CTA 버튼 위치를 상단으로 이동하는 실험도 병행했습니다.
④ 실행과 결과
2주간 A/B 테스트를 진행했고, 메시지를 일치시킨 버전에서 전환율이 18% 개선되었습니다. CTA 위치 변경은 유의미한 차이를 만들지 못했습니다. 이후 이 원칙을 전체 캠페인에 적용해 동일 예산 기준으로 월 전환 단가를 약 12% 낮출 수 있었습니다.
⑤ 회고
A/B 테스트를 소재 단위가 아니라 타겟 세그먼트 단위로 쪼개서 진행했다면 더 정밀한 인사이트를 얻었을 것입니다. 또한 테스트 기간이 2주로 짧아 계절성 변수를 충분히 통제하지 못한 점이 아쉬웠습니다.
2. 서비스 기획자
① 맥락
자사 앱의 유료 구독 전환율을 높이는 프로젝트에 참여하고 있었습니다. 무료 체험 기간은 7일이었고, 체험 종료 후 유료 전환율은 약 8%로 업계 평균 대비 낮은 수준이었습니다.
② 문제 정의
무료 체험 사용자의 행동 로그를 분석한 결과, 대부분의 이탈이 체험 3일차에서 발생하고 있었습니다. 핵심 기능을 한 번도 사용하지 않은 채 이탈하는 비율이 전체 이탈자의 62%였습니다. 문제는 전환 유도가 아니라 핵심 가치를 경험하기 전에 사용자가 떠나고 있다는 점이었습니다.
③ 접근 방식
체험 기간의 첫 3일 동안 핵심 기능 사용을 자연스럽게 유도하는 온보딩 플로우를 재설계하기로 했습니다. 기존에는 가입 직후 전체 기능을 한꺼번에 보여주는 방식이었는데, 이를 하루에 하나씩 핵심 기능을 안내하는 단계별 구조로 바꿨습니다. 온보딩 플로우의 구조와 기능 노출 순서는 제가 설계했고, 이를 기반으로 디자이너, 개발자와 협업해 구현했습니다. 사용자가 가장 먼저 가치를 느낄 수 있는 기능이 무엇인지를 우선순위의 기준으로 삼았습니다.
④ 실행과 결과
온보딩 플로우 변경 후 4주간 데이터를 관찰한 결과, 체험 3일차 이탈률이 38% 감소했고, 핵심 기능 사용률은 2.4배 상승했습니다. 유료 전환율은 8%에서 13%로 올랐습니다.
⑤ 회고
온보딩 개선에 집중하느라 체험 종료 시점의 전환 메시지는 거의 건드리지 못했습니다. 두 가지를 동시에 실험했다면 전환율 개선폭이 더 컸을 가능성이 있습니다. 또한 코호트별로 온보딩 경험이 실제 장기 리텐션에 어떤 영향을 미치는지까지 추적하지 못한 점이 한계였습니다.
3. 운영 담당자
① 맥락
이커머스 플랫폼의 CS 운영을 담당하고 있었습니다. 하루 평균 인입 건수는 약 400건이었고, 상담사 6명이 대응하고 있었습니다. 응답 시간은 평균 4시간이었는데, 고객 불만이 늘면서 응답 시간을 2시간 이내로 줄여야 한다는 목표가 내려왔습니다.
② 문제 정의
단순히 인력을 늘리는 것은 현실적으로 어려운 상황이었습니다. 그래서 인입되는 문의를 분류해봤습니다. 전체 문의의 약 45%가 배송 조회, 교환·반품 절차, 포인트 확인 등 반복적인 유형이었습니다. 상담사들이 매번 같은 내용을 수기로 응대하고 있었고, 이 부분에서 시간이 가장 많이 소요되고 있었습니다.
③ 접근 방식
반복 문의 상위 10개 유형을 정리하고, 각 유형별 표준 응대 템플릿을 만들었습니다. 동시에 고객이 자주 묻는 질문을 FAQ 페이지에 재구성하되, 기존의 카테고리 나열 방식이 아니라 고객의 상황별로 찾을 수 있는 구조로 바꿨습니다. 상담사들에게는 템플릿 사용 가이드와 함께, 템플릿만으로 해결되지 않는 건을 우선 처리하는 에스컬레이션 기준도 새로 정리했습니다.
④ 실행과 결과
템플릿 도입 후 반복 문의 응대 시간이 건당 평균 8분에서 3분으로 줄었습니다. FAQ 개편 후에는 반복 문의 인입 자체가 약 20% 감소했습니다. 건당 처리 시간이 줄면서 대기열이 해소되었고, 전체 평균 응답 시간은 4시간에서 1시간 40분으로 단축되었습니다. 결과적으로 추가 인력 없이 목표를 달성할 수 있었습니다.
⑤ 회고
템플릿이 효과적이었지만, 시간이 지나면서 상담사들이 템플릿에 지나치게 의존해 맥락에 맞지 않는 기계적 응대가 발생하는 경우가 있었습니다. 이 경험 이후 다른 프로젝트에서 프로세스를 표준화할 때는 효율 지표와 품질 지표를 처음부터 함께 설계하는 습관이 생겼습니다.
4. 영업 담당자
① 맥락
B2B SaaS 솔루션의 신규 영업을 담당하고 있었습니다. 주요 타겟은 직원 수 50~200명 규모의 중소기업이었고, 월 평균 15건의 미팅을 진행하고 있었습니다. 미팅 후 제안서 발송까지는 무난하게 진행되었지만, 제안 이후 계약 전환율이 약 12%로 낮은 상태가 지속되고 있었습니다.
② 문제 정의
제안서를 발송한 뒤 고객이 침묵하는 경우가 많았습니다. 후속 연락을 해보면 "내부 검토 중"이라는 답변이 반복되었고, 결국 흐지부지 사라지는 패턴이었습니다. 원인을 추적해보니, 제안서가 우리 솔루션의 기능 설명에 집중되어 있었고, 고객사 내부에서 의사결정자를 설득할 수 있는 언어로 쓰여 있지 않다는 점을 발견했습니다. 실무 담당자는 긍정적이어도, 그 사람이 상위 의사결정자에게 보고할 논리가 제안서 안에 없었던 겁니다.
③ 접근 방식
제안서 구조를 바꿨습니다. 기능 중심의 나열을 줄이고, 앞부분에 고객사가 현재 겪고 있는 문제와 그로 인한 비용 손실을 먼저 배치했습니다. 그 다음에 우리 솔루션이 그 문제를 어떻게 줄여주는지를 연결하고, 마지막에 도입 전후 예상 효과를 수치로 제시하는 구조로 재설계했습니다. 실무 담당자가 그대로 사내 보고에 쓸 수 있는 형태를 의도했습니다.
④ 실행과 결과
변경된 제안서를 적용한 이후 3개월간 30건의 제안을 발송했고, 계약 전환율이 기존 12%에서 23%로 상승했습니다. 특히 "내부 검토 중" 이후 연락이 끊기는 비율이 눈에 띄게 줄었고, 고객사 실무 담당자로부터 "보고서로 바로 활용했다"는 피드백을 여러 차례 받았습니다.
⑤ 회고
제안서 구조 변경이 효과적이었지만, 업종별로 문제의 언어가 다르다는 점을 충분히 반영하지 못했습니다. 이 경험 이후에는 제안서를 작성하기 전에 고객사의 업종과 내부 보고 구조를 먼저 파악하는 단계를 루틴으로 넣게 되었습니다. 제조업과 서비스업의 고객이 같은 기능에도 다른 가치를 느낀다는 걸 이때 배웠습니다.
5. HR 담당자
① 맥락
연간 약 40명 규모의 채용을 담당하고 있었습니다. 채용 과정 자체는 안정적으로 운영되고 있었지만, 입사 후 6개월 이내 퇴사율이 22%로 높은 상태였습니다. 경영진으로부터 조기 이탈률을 줄이라는 과제를 받았습니다.
② 문제 정의
퇴사자 인터뷰를 분석한 결과, 대부분의 이유가 "생각했던 것과 다르다"로 수렴했습니다. 업무 내용, 팀 분위기, 기대 역할에 대한 인식 차이가 핵심이었습니다. 채용 과정에서 직무와 조직에 대한 정보가 충분히 전달되지 않은 채 입사가 이루어지고 있었고, 입사 후 온보딩 과정도 행정 절차 중심으로만 구성되어 있었습니다.
③ 접근 방식
두 가지를 동시에 바꾸기로 했습니다. 첫째, 채용 단계에서 직무 소개 방식을 변경했습니다. 기존의 직무 기술서가 일반적인 역할 나열이었는데, 이를 "입사 후 3개월간 실제로 하게 될 일"을 구체적으로 서술하는 형태로 바꿨습니다. 둘째, 온보딩 프로그램을 재설계했습니다. 입사 첫 주에 팀 리더와 1:1 미팅, 둘째 주에 협업 부서 소개, 한 달 차에 역할 기대치 조율 미팅을 구조화했습니다.
④ 실행과 결과
변경된 채용 프로세스와 온보딩을 적용한 이후, 6개월 이내 퇴사율이 두 분기 연속 감소해 22%에서 11% 수준까지 내려왔습니다. 신규 입사자 대상 만족도 조사에서 "입사 전 기대와 실제 업무의 일치도" 항목이 5점 만점에 3.1에서 4.2로 상승했습니다.
⑤ 회고
온보딩 프로그램의 효과를 팀별로 분리해서 측정하지 못한 점이 아쉽습니다. 일부 팀은 리더의 참여도가 낮아 프로그램이 형식적으로 운영된 경우가 있었는데, 팀별 온보딩 실행도를 추적하는 지표를 함께 만들었어야 했습니다.
6. 교육 담당자
① 맥락
사내 직무 교육 프로그램을 기획·운영하고 있었습니다. 연간 약 12개 과정을 운영했고, 참여 인원은 과정당 평균 30명이었습니다. 교육 후 만족도 조사에서는 매번 4점 이상을 기록했지만, 현업 부서로부터 "교육이 실무에 도움이 안 된다"는 피드백이 반복적으로 들어오고 있었습니다.
② 문제 정의
만족도는 높은데 실무 적용도는 낮은 상황이었습니다. 교육 내용을 살펴보니, 대부분의 과정이 외부 강사의 일반적인 이론 강의로 구성되어 있었습니다. 수강생들은 "좋은 이야기를 들었다"고 느끼지만, 돌아가서 무엇을 바꿔야 하는지는 모르는 상태로 끝나고 있었습니다. 교육 내용 자체의 질은 문제가 아니었습니다. 문제는 교육이 끝나는 시점에서 모든 것이 끝나는 구조였습니다.
③ 접근 방식
교육 구조를 '강의 → 끝'에서 '사전 과제 → 강의 → 실습 → 현업 적용 → 공유'의 5단계로 바꿨습니다. 사전 과제로 각자 현재 업무에서 겪고 있는 문제를 하나씩 가져오게 하고, 강의 이후에는 그 문제에 대한 해결 방안을 설계하는 실습 시간을 넣었습니다. 교육 종료 2주 후에는 실제로 적용한 결과를 짧게 공유하는 세션을 추가했습니다.
④ 실행과 결과
변경된 구조를 3개 과정에 시범 적용한 결과, 교육 후 만족도는 비슷한 수준을 유지하면서 "실무 적용 가능성" 항목이 5점 만점에 2.8에서 4.1로 상승했습니다. 현업 부서 피드백에서도 "교육 이후 실제로 바뀐 것이 있다"는 응답이 처음으로 과반을 넘었습니다.
⑤ 회고
사후 공유 세션의 참여율이 과정마다 편차가 컸습니다. 자발적 참여에 의존했기 때문인데, 공유 세션을 교육 과정의 공식적인 일부로 포함시키고, 관리자가 함께 참여하는 구조였다면 적용률이 더 안정적으로 유지되었을 것입니다.
구조를 갖췄더라도 다음과 같이 작성하면 안 됩니다.
① What만 있고 How가 없는 기록 :
'매출을 올렸다'는 결과만 적지 마세요. 어떤 논리로 그 방법을 선택했는지 과정의 논리가 곧 실력입니다.
② 모든 것을 다 넣으려는 욕심 :
직무 역량과 가장 잘 연결되는 프로젝트 3~5개면 충분합니다. 양보다 밀도입니다.
③ 내 역할이 모호한 성과 :
우리 팀이 잘했다는 건 좋은 경험이지만, 평가자에게는 판단 근거가 되지 못합니다. 전체 프로젝트에서 내가 맡았던 구체적인 역할과 기여도를 명확히 구분하여 기술하세요.
구조를 알아도 실제로 쓰다 보면 멈추게 되는 순간들이 있습니다. 자주 나오는 고민 몇 가지에 대해 이야기하겠습니다.
① "기밀이라 공개할 수 없습니다."
가장 많이 듣는 말입니다. 하지만 포트폴리오에 회사 내부 데이터를 그대로 노출할 필요는 없습니다. 구체적인 수치를 비율로 바꾸거나, 회사명 대신 "직원 200명 규모의 B2B SaaS 기업"처럼 맥락만 전달해도 충분합니다. 핵심은 숫자 자체가 아니라 문제를 인식하고 해결한 과정이니까요.
② "눈에 띄는 성과가 없습니다."
포트폴리오가 반드시 대단한 성공 사례일 필요는 없습니다. 작은 개선도 됩니다. 응답 시간을 30분 줄인 것도, 반복 업무를 하나 자동화한 것도, 기존에 없던 매뉴얼을 하나 만든 것도 포트폴리오가 됩니다. 변화의 크기보다 변화를 만든 사고 과정이 중요합니다.
③ "혼자 한 일이 아닙니다."
당연합니다. 대부분의 일은 혼자 하지 않습니다. 중요한 건 전체에서 내가 어떤 역할을 했는지를 명확히 구분하는 것입니다. "이 프로젝트에서 나는 문제 정의와 데이터 분석을 담당했고, 디자인과 개발은 각각 다른 팀원이 맡았다"고 쓰면 됩니다. 솔직하게 범위를 밝히는 것이 오히려 신뢰를 높입니다.
④ "어떤 프로젝트를 골라야 할지 모르겠습니다."
가장 최근 것, 가장 고민을 많이 한 것, 가장 많이 배운 것 중에서 고르세요. 셋 중 하나만 해당해도 충분합니다. 화려한 결과를 낸 프로젝트보다 사고 과정이 풍부한 프로젝트가 포트폴리오로서 더 좋은 재료입니다.
처음부터 잘 쓰려고 하면 시작할 수 없습니다.
맥락, 문제 정의, 접근 방식, 실행과 결과, 회고.
이 다섯 가지를 채우는 것부터 시작하면 됩니다. 정리하다 보면 내가 어떤 방식으로 일해왔는지가 더 분명해집니다.
지금 하고 있는 일 중 하나를 골라서 이 구조로 한 번 정리해보세요.
그게 포트폴리오의 첫 페이지가 됩니다.