신입 기획자 포트폴리오, 한 프로젝트를 케이스 스터디로 푸는 법

26살 최진주 씨는 노트북 앞에 앉아 포트폴리오 페이지를 열었습니다.

서비스 기획자로 지원할 회사들을 정리하던 중, 캡스톤 프로젝트를 포트폴리오 첫 페이지에 올리려던 참이었습니다.

화면을 보다가 손이 멈췄습니다. 서비스 흐름도 두 장과 한 줄짜리 설명이 거기 있었습니다.

대학생을 위한 중고거래 앱

1년 동안 시장 조사부터 사용자 인터뷰, MVP 운영까지 다 했는데, 포트폴리오에는 결과물 다이어그램만 떡하니 들어가 있었습니다.

"기획서를 잘 만들었구나" 같은 인상은 줄지 모르지만, 최진주 씨가 그 1년 동안 무엇을 결정했고 왜 그렇게 결정했는지는 한 글자도 안 보였습니다.

최진주 씨처럼 막막한 신입 기획자가 많습니다. 그런데 추가해야 할 정보는 사실 정해져 있습니다.

어떤 정보를 어떻게 추가해야 하는지, 최진주 씨와 함께 풀어보겠습니다.

결과물만 보여주는 포트폴리오의 함정

신입 기획자 포트폴리오에서 가장 자주 보는 구성은 이런 형태입니다.

• 프로젝트명 — 대학생 중고거래 앱

• 역할 — 서비스 기획, 시장 조사

• 기간 — 1년 (4인 캡스톤)

• 도구 — Figma, Notion, Miro

• 산출물 — 서비스 흐름도, IA, 기능 명세, MVP 와이어프레임

이걸 채용 담당자나 PM 리드가 본다고 상상해 보겠습니다. 어떻게 읽힐까요?

"기획서 깔끔하게 잘 정리했네."

여기서 끝납니다.

이 사람이 어떤 시장 인사이트를 발견했는지, 왜 이 기능을 넣고 무엇을 뺐는지, 어떤 안을 검토하다 버렸는지는 한 줄도 안 보입니다.

기획의 "결과물 형태"는 있지만 그 결과물을 만든 "의사결정의 흐름"이 안 보이는 것입니다.

기획자 포트폴리오의 진짜 가치는 "무엇을 기획했는가"가 아닙니다. "왜 이 기획인가"에 있습니다.

문서만으로는 "기획서를 만들 줄 안다"는 것밖에 안 보입니다. 그런데 채용 측이 기획자에게 진짜 보고 싶은 것은 시장과 사용자를 보고 결정하는 사람인가, 이것입니다.

특히 기획자는 결정 과정에서 "무엇을 안 하기로 했는가"가 핵심입니다. 좋은 기획서는 모든 기능을 다 담은 것이 아니라, 빼야 할 것을 정확히 뺀 결과입니다.

그래서 한 프로젝트를 풀어쓸 때는 케이스 스터디 형식으로 갑니다. 케이스 스터디는 세 박자로 구성됩니다.

문제 — 과정 — 결과

이 세 가지를 채우면 포트폴리오에 사람이 보이기 시작합니다.

최진주 씨의 대학생 중고거래 앱을 가지고 한 박자씩 풀어보겠습니다.

문제: 무엇을 누구를 위해 풀려고 했는가

가장 많이 빼먹는 부분이 바로 여기입니다. "어떤 시장에서, 누구의 어떤 페인을 풀려고 했나"라는 질문입니다.

최진주 씨도 처음에는 이렇게 적었습니다.

[Before]

대학생이 안전하고 편리하게 중고거래를 할 수 있도록 모바일 앱을 기획했습니다.

이 문장에서 채용 측이 얻을 수 있는 정보는 두 가지입니다. 타겟이 대학생이라는 것, 그리고 중고거래 앱이라는 것.

최진주 씨가 어떤 시장 맥락에서 어떤 페인을 발견했는지는 한 글자도 안 보입니다. 그냥 "대학생 중고거래는 불편하다"는 일반론에서 시작한 것처럼 보입니다.

그래서 최진주 씨에게 물어봤습니다. "당근마켓이나 번개장터가 이미 있는데 왜 굳이 대학생 앱이었어요?" 답이 이렇게 나왔습니다.

처음엔 저도 그런 의문이 있었어요. 그래서 시장 조사부터 했어요. 대학생 30명 설문, 자취생 위주 인터뷰 10명을 진행했죠. 그런데 거기서 발견된 게 흥미로웠어요.

학생들은 당근마켓을 쓰긴 하는데, 진짜 답답해하는 부분이 따로 있더라고요. '판매자가 학생인지 알 수가 없다', '거래 장소 잡기가 너무 번거롭다', '값을 깎으려는 어른들 상대하기 힘들다'. 결국 학생끼리, 같은 학교 안에서만 거래하고 싶은데 그게 안 되니까 거래 자체를 포기한 경우가 많았어요.

이 인사이트가 그대로 포트폴리오에 들어가야 합니다.

[After]

기존 중고거래 앱(당근마켓, 번개장터)은 이미 사용 중이었지만, 대학생 30명 설문과 자취생 10명 인터뷰 결과 세 가지 페인이 반복적으로 나왔습니다. 판매자 신원 불확실, 거래 장소 조율의 번거로움, 세대 차이에서 오는 거래 피로감. 결국 학생들은 "같은 학교 학생끼리 거래"를 원했지만, 기존 앱은 그 단위로 거래를 묶어주지 못해 학생들이 거래 자체를 포기하는 경우가 많았습니다. 이 페인을 푸는 것이 캡스톤의 목표였습니다.

After 버전이 더 길지만, 정보 밀도가 훨씬 높습니다.

어떤 시장 안에서, 누구의 어떤 페인을, 왜 기존 서비스가 못 풀고 있는지가 다 들어가 있습니다.

문제 정의에 들어가야 할 질문 세 가지를 정리하면 이렇습니다.

• 시장 맥락 — 이 영역에 이미 어떤 서비스가 있나

• 사용자 페인 — 기존 서비스로 안 풀리는 페인이 무엇인가 (가설이 아니라 리서치로 확인된)

• 진입 근거 — 왜 지금, 왜 이 방식으로 푸는 것이 의미 있나

특히 기획자 케이스 스터디에서는 첫 번째 — 시장 맥락 위에서 페인을 정의한다는 점이 결정적입니다.

기존 서비스를 인지하지 못한 채 "이런 게 필요해 보여서 만들었다"라고 하면, 채용 측은 "이 사람은 시장을 보지 않는구나"로 읽습니다.

과정: 무엇을 넣고 무엇을 뺐는가

여기가 케이스 스터디의 핵심입니다.

가장 빼먹기 쉬운 부분이기도 하고, 기획자에게는 가장 가치 있는 부분이기도 합니다.

대부분의 신입 기획자 포트폴리오는 "어떤 기능을 넣었는가"까지만 적습니다.

[Before]

학생 인증, 학교별 거래방, 캠퍼스 픽업 포인트, 채팅 결제 시스템 등 핵심 기능을 정의했습니다.

이 문장은 채용 측이 "기능 명세를 짰구나" 정도까지만 알게 해 줍니다.

그런데 정작 PM 리드가 궁금한 것은 그게 아닙니다.

"이 사람은 무엇을 안 하기로 했고, 왜 그렇게 결정했을까", 이것이 핵심입니다.

최진주 씨의 대학생 중고거래 앱에서 가장 큰 기획 결정은 "MVP를 단일학교에 특화할 것인가, 다대학 연결로 갈 것인가"였습니다.

처음 컨셉은 다대학 연결이었습니다. 전국 대학생 누구나 가입해서 거래할 수 있는 형태였습니다. 시장이 크고, 사용자 확보가 빠를 것이라는 가설이었습니다.

그런데 사용자 인터뷰에서 두 가지 인사이트가 나왔습니다.

• "다른 학교 학생이랑 거래하면 결국 당근마켓이랑 뭐가 다르지?" — 다대학 연결은 차별점을 흐리는 결정이었습니다

• "픽업하러 다른 학교까지 가야 하면 안 할 것 같아요" — 거리는 거래 의향을 결정짓는 요소였습니다

이 인사이트를 받고 최진주 씨는 MVP 범위를 줄였습니다.

[After]

초기 컨셉은 전국 대학생 대상의 다대학 연결 플랫폼이었습니다. 시장 크기와 빠른 사용자 확보가 근거였습니다.

그런데 인터뷰에서 두 가지가 발견됐습니다. 첫째, 학생들은 "다른 학교 학생과의 거래"에 효익을 느끼지 못했습니다. "그러면 당근마켓이랑 뭐가 다른가?"라는 반응이 10명 중 7명이었습니다. 둘째, 거래 의향은 거리에 크게 영향을 받았고, 학교 간 이동은 사실상 거래 포기 사유였습니다.

두 인사이트를 받고 MVP를 단일학교 특화로 좁혔습니다. 시장은 작아지지만 차별점이 명확해졌습니다. 캠퍼스 픽업 포인트, 강의실 직거래, 학생증 기반 인증 같은 단일학교에서만 가능한 기능을 핵심 차별점으로 정했습니다. 다대학 확장은 "한 학교에서 성공 모델을 검증한 다음, 학교 단위로 복제"하는 방식으로 미뤘습니다.

이 문단에 어떤 정보가 들어 있는지 보십시오.

• 처음 가설을 세웠다 → 이 사람은 가설부터 시작한다

• 가설을 사용자에게 검증했다 → 이 사람은 자기 생각을 시장에 부딪힌다

• 인사이트를 받고 범위를 줄였다 → 이 사람은 "안 하기"를 결정할 줄 안다

• 확장 경로를 함께 그렸다 → 이 사람은 단기와 장기를 함께 본다

같은 "대학생 중고거래 앱"이라는 결과물도, 풀어 쓰는 방식에 따라 채용 측 머릿속에 그려지는 그림이 완전히 달라집니다.

과정 부분에 꼭 들어가야 할 것 세 가지입니다.

• 초기 가설 — 어떤 가설로 시작했나

• 인사이트와 범위 결정 — 무엇을 발견하고 어떻게 범위를 좁혔나

• 트레이드오프와 확장 경로 — 무엇을 포기했고 그것을 언제 다시 다룰 것인가

특히 마지막 "확장 경로"는 기획자 포트폴리오에서 강력합니다.

신입 기획자가 흔히 빠지는 함정은 "지금 못한 것"을 한계로만 표현하는 것입니다. 그런데 채용 측은 "지금은 안 하기로 했고, 언제 어떻게 다시 다룰지 알고 있다"는 흐름을 훨씬 신뢰합니다.

"전국 확장은 단일학교 검증 후 복제 방식으로 미뤘다"는 흐름이, "전국 서비스가 목표였지만 시간이 부족해 단일학교만 했다"는 글보다 훨씬 입체적입니다.

결과: 가설이 어떻게 검증됐는가

마지막 박자는 결과입니다. "완성했습니다"에서 멈추는 경우가 많은데, 결과는 그 너머가 있어야 합니다.

[Before]

MVP 프로토타입을 완성했고 캡스톤 발표회에서 발표했습니다.

이 문장은 정보가 거의 없습니다. "끝까지 갔다"는 사실 외에는 아무것도 안 보입니다.

기획자의 결과 서술에는 두 가지가 함께 들어가야 합니다. 검증된 가설과 다음에 검증할 가설입니다.

정량 결과 — 숫자로 잡히는 것

• 베타 사용자 수, 거래 성사율

• 픽업 만족도, 재거래율

• 가입 전환율, 평균 거래 완료 시간

정성 결과 — 숫자가 어려운 것

• 사용자 인용 ("캠퍼스 픽업이 결정적이었다")

• 캡스톤 발표회의 평가나 산업체 멘토 피드백

• 안 하기로 했던 결정에 대한 사후 평가

최진주 씨의 캡스톤에 적용해 보겠습니다.

[After]

한 학교 학생 50명을 대상으로 4주간 MVP 베타를 운영했습니다. 거래 성사율 68%(기존 당근마켓 동일 카테고리 평균 41%), 픽업 만족도 4.3/5점, 첫 거래 후 재거래 시도율 52%였습니다.

인터뷰에서 가장 많이 나온 표현은 "픽업 포인트가 결정적이었다"였습니다. 단일학교 특화 결정의 핵심 가설 — "거리가 짧으면 거래가 성사된다" — 이 검증됐다는 신호로 봤습니다.

캡스톤 발표회에서는 다대학 컨셉을 포기한 결정 과정에 대한 질문이 가장 많았고, 이 부분이 기획의 핵심 차별점이 되었습니다.

정량과 정성이 함께 있습니다.

그리고 "단일학교 특화 가설"이 처음부터 끝까지 일관된 주제로 흐르고 있습니다. 문제에서 던진 질문에 결과가 정확히 답하고 있는 셈입니다.

결과가 약할 때를 위한 팁도 하나 적어 두겠습니다.

신입 기획자 프로젝트는 베타 운영 규모가 작거나 학기 안에 끝나는 경우가 많습니다. 그럴 땐 솔직하게 적되, "여기까지 갔고, 다음에 무엇을 검증할지 알고 있다"까지 함께 적습니다.

베타는 한 학교 50명, 4주 규모에서 그쳤습니다. 다음 단계로는 다른 학교 1곳을 추가해 "학교 단위 복제 모델"이 실제로 작동하는지를 검증할 계획이었습니다.

이 한 줄이 있으면 "데이터 규모가 작다"가 아니라 "현재 위치를 알고 다음 가설을 그릴 줄 아는 사람이다"로 읽힙니다.

채용 측은 기획자 케이스 스터디에서 무엇을 보는가

마지막으로 한 번 시점을 뒤집어 보겠습니다.

PM 리드나 채용 담당자가 신입 기획자 포트폴리오의 케이스 스터디를 읽을 때, 머릿속에 던지는 질문은 이런 식입니다.

• 이 사람은 시장과 사용자를 둘 다 보는가 → 문제 정의에서 드러남

• 무엇을 안 하기로 했는지 명확한가 → 과정 서술에서 드러남

• 시행착오를 의사결정으로 다루는가 → 가설 전환과 범위 결정에서 드러남

• 가설을 검증할 줄 아는가 → 정량·정성 결과에서 드러남

• 자기 위치를 객관적으로 알고 다음을 그리는가 → 한계와 다음 단계에서 드러남

이 다섯 가지가 케이스 스터디 한 편에 다 들어 있으면, 신입이라도 "이 사람은 일할 줄 안다"는 인상이 만들어집니다.

회사 명함이 없어도, 정규직 경력이 없어도 가능한 인상입니다.

기획서의 깔끔함보다 기획서를 만들어 가는 의사결정의 흐름이 보일 때, 포트폴리오는 비로소 내가 어떻게 일했는지가 보이는 자리가 됩니다.

처음에 최진주 씨가 적었던 한 줄과 케이스 스터디 한 편이 어떻게 달라졌는지 마지막으로 정리해 보겠습니다.

[Before]

캡스톤 프로젝트: 대학생 중고거래 앱 역할: 서비스 기획, 시장 조사 기간: 1년, 4인 팀 도구: Figma, Notion, Miro

[After — 케이스 스터디 한 편의 구조]

프로젝트명: 대학생 중고거래 앱 (4인 캡스톤, 1년)

문제 — 대학생 30명 설문 + 자취생 10명 인터뷰 결과, 기존 중고거래 앱의 페인은 "판매자 신원 불확실 + 거래 장소 조율 부담 + 세대 차이로 인한 거래 피로감". 학생들은 "같은 학교 학생끼리 거래"를 원했지만 기존 앱이 그 단위를 제공하지 못해 거래 포기.

과정 — 초기 컨셉은 다대학 연결. 인터뷰에서 "다른 학교 학생이랑 거래하면 당근마켓이랑 뭐가 다른가" 반응과 거리 부담 발견. MVP를 단일학교 특화로 좁히고 캠퍼스 픽업 포인트·강의실 직거래·학생증 인증을 핵심 차별점으로 정의. 다대학 확장은 "학교 단위 복제" 모델로 후속 단계로 미룸.

결과 — 한 학교 50명 4주 베타. 거래 성사율 68%(시장 평균 41%), 픽업 만족도 4.3/5, 재거래 시도율 52%. "픽업 포인트가 결정적이었다" 인용 다수.

역할: 리드 기획자 (시장 조사, 사용자 리서치, MVP 정의) 도구: Figma, Notion, Miro 링크: 서비스 기획 문서 · MVP 프로토타입 · 베타 운영 보고서

같은 프로젝트인데도, 위의 네 줄과 아래 한 편은 채용 측에게 다른 메시지를 줍니다.

위는 "도구를 안다"고 말하지만, 아래는 "무엇을 안 할지 결정할 줄 안다"고 말합니다.

한 페이지에 들어갈 케이스 스터디는 보통 이 정도 분량이면 충분합니다.

너무 길면 채용 측이 다 안 읽고, 너무 짧으면 사람이 안 보입니다. 문제-과정-결과의 세 박자가 다 있는 한 페이지면, 한 프로젝트는 충분히 보입니다.

이번 글에서는 기획자 관점에서 한 프로젝트를 케이스 스터디 한 편으로 푸는 법을 다뤘습니다.

개발자 버전이 궁금하시면 이 시리즈 1편을, 디자이너 버전이 궁금하시면 2편을 참고해 주세요. 세 직무 모두 "내가 어떻게 일했는지가 보이는 포트폴리오"라는 같은 메시지를 다른 각도에서 풀어낸 글입니다.

여러 프로젝트를 어떻게 선별하고 한 페이지에 배치할지는 다음 시리즈의 주제가 될 것입니다. 한 프로젝트의 케이스 스터디가 한 편의 글이라면, 여러 프로젝트의 배치는 한 권의 책 구성에 가까운 작업입니다.