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

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

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

화면을 보다가 손이 멈췄습니다. 정성껏 만든 최종 화면 스크린샷 다섯 장과 한 줄짜리 설명이 거기 있었습니다.

신입생을 위한 동아리 매칭 앱

1년 동안 사용자 인터뷰부터 와이어프레임, 사용자 테스트까지 다 했는데, 포트폴리오에는 결과물 화면만 떡하니 들어가 있었습니다.

화면이 예쁘다는 칭찬은 받겠지만, 김진주 씨가 그 1년 동안 무엇을 고민했고 어떤 결정을 했는지는 한 글자도 안 보였습니다.

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

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

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

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

• 프로젝트명 — 신입생 동아리 매칭 앱

• 역할 — UX/UI 디자인, 사용자 리서치

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

• 도구 — Figma, Notion

• 화면 — 메인, 매칭, 동아리 상세, 신청 흐름 (스크린샷 5장)

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

"예쁘게 잘 만들었네."

여기서 끝납니다.

이 사람이 어떤 사용자 인사이트를 발견했는지, 왜 이런 화면 구성을 골랐는지, 어떤 안을 시도하다 버렸는지는 한 줄도 안 보입니다.

화면의 "겉모습"은 있지만 그 화면을 만든 "사고의 흐름"이 안 보이는 것입니다.

디자이너 포트폴리오의 진짜 가치는 "어떻게 생겼는가"가 아닙니다. "왜 이 디자인인가"에 있습니다.

화면만으로는 "이걸 만들 줄 안다"는 것밖에 안 보입니다. 그런데 채용 측이 디자이너에게 진짜 보고 싶은 것은 사용자를 보고 결정하는 사람인가, 이것입니다.

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

문제 — 과정 — 결과

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

김진주 씨의 동아리 매칭 앱을 가지고 한 박자씩 풀어보겠습니다.

문제: 누구의 어떤 페인을 풀려고 했는가

가장 많이 빼먹는 부분이 바로 여기입니다. "누가 무엇 때문에 불편했나"라는 질문입니다.

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

[Before]

신입생이 본인에게 맞는 동아리를 쉽게 찾을 수 있도록 매칭 앱을 디자인했습니다.

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

김진주 씨가 어떤 사용자 페인을 발견했는지는 한 글자도 안 보입니다. 그냥 "동아리 찾기가 어렵다"는 일반론에서 시작한 것처럼 보입니다.

그래서 김진주 씨에게 물어봤습니다. "왜 매칭 앱이었어요? 신입생이 동아리 정보가 부족한가요?" 답이 이렇게 나왔습니다.

"처음엔 저도 그렇게 생각했어요. 정보 부족 문제일 줄 알고 시작했거든요. 그런데 신입생 8명 인터뷰해 보니 정보 부족이 진짜 페인이 아니더라고요.

학교 동아리 페이지에 정보는 다 있어요. 동아리 수도 너무 많지 않아요. 그런데 정작 망설이는 이유는 따로 있었어요. '이 동아리 분위기가 실제로 어떤지' 알 수 없어서였어요. 화면에 보이는 동아리 소개는 다 똑같이 '친목과 성장' 이런 식이라, 진짜 어떤지 모르겠다는 거예요."

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

[After]

학교 동아리 페이지는 이미 있었고, 정보 양도 부족하지 않았습니다. 그런데 신입생 8명 인터뷰 결과, 가입을 망설이는 진짜 이유는 정보 부족이 아니라 "실제 분위기를 가늠할 수 없다"는 것이었습니다. 모든 동아리가 비슷한 톤의 소개 문구를 쓰다 보니, 정작 본인에게 맞는지 판단할 단서가 없는 것입니다. 이 페인을 푸는 것이 캡스톤의 목표였습니다.

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

누구의 페인인지, 무엇이 진짜 페인인지, 왜 그게 진짜 페인인지가 다 들어가 있습니다.

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

• 사용자 — 누구를 위한 프로젝트인가

• 페인 — 이 사용자의 진짜 페인은 무엇인가 (가설이 아니라 리서치로 확인된)

• 기존의 한계 — 기존 서비스가 왜 이 페인을 못 풀고 있나

특히 디자이너 케이스 스터디에서는 두 번째 — 리서치로 발견한 진짜 페인이 결정적입니다.

처음 가정한 페인과 리서치 후 발견한 페인이 다르면, 그 차이 자체가 디자이너의 사고력을 보여주는 단서가 됩니다.

과정: 왜 이 디자인 결정을 했는가

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

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

대부분의 신입 디자이너 포트폴리오는 "어떤 화면을 디자인했는가"까지만 적습니다.

[Before]

추천 알고리즘 기반의 매칭 시스템을 설계했습니다. 사용자가 10개의 질문에 답하면 맞춤형 동아리를 추천해 줍니다.

이 문장은 채용 측이 "기능을 설계했구나" 정도까지만 알게 해 줍니다.

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

"이 사람은 어떤 사용자 인사이트를 근거로 그 결정을 했을까", 이것이 핵심입니다.

김진주 씨의 동아리 매칭 앱에서 가장 큰 디자인 결정은 "추천형으로 갈 것인가, 탐색형으로 갈 것인가"였습니다.

처음 컨셉은 추천형이었습니다. 10개 질문에 답하면 맞춤 동아리를 추천해 주는 형태였습니다.

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

• "또 테스트요?" — 신입생들은 이미 MBTI, 적성검사 같은 추천형 콘텐츠에 피로감이 있었습니다

• "왜 이 동아리만 추천하지?" — 추천 결과를 신뢰하지 않고 오히려 의심하는 반응이 많았습니다

이 인사이트를 받고 김진주 씨는 컨셉을 바꿨습니다.

[After]

처음에는 10개 질문 기반의 추천형 매칭으로 설계했습니다. 그런데 신입생 인터뷰에서 두 가지 인사이트가 나왔습니다.

첫째, 신입생들은 이미 MBTI나 적성검사 같은 추천형 콘텐츠에 피로감이 컸습니다. "또 테스트요?"라는 반응이 8명 중 5명에서 나왔습니다.

둘째, 추천 결과 자체를 신뢰하지 않았습니다. "왜 이 동아리만 추천하지?"라는 의심이 자율감을 떨어뜨렸습니다. 추천이 강하게 작동할수록 오히려 가입률이 떨어질 가능성이 있었습니다.

그래서 컨셉을 "가벼운 필터(3개 질문, 건너뛰기 가능) + 탐색형 리스트 + 각 동아리 카드의 '현재 멤버 한마디'"로 바꿨습니다. 신입생이 직접 보고 결정하되, "이 동아리 분위기"라는 핵심 페인을 풀어주는 형태입니다. 자율감을 지키면서도 진짜 갈증인 정보를 채워주는 구조입니다.

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

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

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

• 인사이트를 받고 방향을 바꿨다 → 이 사람은 인사이트를 행동으로 옮긴다

• 트레이드오프를 인지하고 결정했다 → 이 사람은 맥락 위에서 디자인한다

같은 "동아리 매칭 앱 디자인"이라는 결과물도, 풀어 쓰는 방식에 따라 채용 측 머릿속에 그려지는 그림이 완전히 달라집니다.

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

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

• 인사이트와 전환 — 사용자에게서 무엇을 발견하고 어떻게 방향을 바꿨나

• 트레이드오프 — 무엇을 얻고 무엇을 포기했나

특히 두 번째 "인사이트와 전환"은 신입 디자이너 포트폴리오에서 강력합니다.

신입은 "처음부터 잘했다"는 인상을 주고 싶어 시행착오를 숨기는 경향이 있습니다. 그런데 채용 측은 오히려 그 전환 지점에서 사고력을 확인합니다.

"추천형으로 시작했는데 인터뷰에서 발견된 페인이 다르다는 것을 깨닫고 탐색형으로 방향을 바꿨다"는 흐름이, 처음부터 탐색형이었다고 쓴 글보다 훨씬 입체적입니다.

결과: 어떻게 작동했는가

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

[Before]

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

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

좋은 결과 서술에는 두 종류가 들어갑니다.

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

• 사용자 테스트 참여자 N명

• 가입까지의 클릭 수 (기존 학교 페이지 N회 → 프로토타입 N회)

• 페이지 이탈률, 완료율 등

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

• 테스트 참여자의 인용 ("선배 한마디 보고 결정했어요")

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

• 학과 교수의 정성적 코멘트

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

[After]

신입생 12명 대상 사용자 테스트에서, 동아리 1개 선택까지의 클릭 수가 기존 학교 페이지 평균 11회에서 프로토타입 4회로 줄었습니다. 가입 의향을 표시한 비율은 12명 중 9명이었습니다.

인터뷰에서 가장 많이 나온 표현은 "선배 한마디 카드 보고 결정했다"였습니다. 처음 인터뷰에서 발견한 페인 — "실제 분위기를 알 수 없다" — 을 정확히 풀어줬다는 신호로 봤습니다.

캡스톤 발표회에서는 추천형에서 탐색형으로 전환한 과정에 대한 질문이 가장 많았고, 이 부분이 디자인의 핵심 차별점이 되었습니다.

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

그리고 "사용자 페인"이 처음부터 끝까지 일관된 주제로 흐르고 있습니다. 문제에서 던진 질문에 결과가 정확히 답하고 있는 셈입니다.

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

신입 디자이너 프로젝트는 사용자 테스트 규모가 작거나 학기 안에 끝나는 경우가 많습니다. 그럴 땐 솔직하게 적되, "여기까지 갔고, 다음에 무엇을 할지 알고 있다"까지 함께 적습니다.

사용자 테스트는 학과 신입생 12명 규모에서 그쳤습니다. 다음 단계로는 학기 단위로 실제 동아리 가입 시즌에 운영하면서 가입 전환율을 측정할 계획이었습니다.

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

디자인 리드는 케이스 스터디에서 무엇을 보는가

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

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

• 이 사람은 사용자를 보고 결정하는가 → 문제 정의에서 드러남

• 디자인 결정에 근거가 있는가 → 과정 서술에서 드러남

• 시행착오와 어떻게 대화하는가 → 가설 전환 부분에서 드러남

• 결과를 검증할 줄 아는가 → 사용자 테스트 정량·정성 결과에서 드러남

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

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

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

화면의 화려함보다 화면을 만들어 가는 사고의 흐름이 보일 때, 포트폴리오는 비로소 내가 어떻게 일했는지가 보이는 자리가 됩니다.

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

[Before]

캡스톤 프로젝트: 신입생 동아리 매칭 앱 역할: UX/UI 디자인, 사용자 리서치 기간: 1년, 4인 팀 도구: Figma, Notion

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

프로젝트명: 신입생 동아리 매칭 앱 (4인 캡스톤, 1년)

문제 — 신입생 8명 인터뷰 결과, 가입 망설임의 진짜 이유는 정보 부족이 아니라 "실제 동아리 분위기를 가늠할 수 없다"는 것.

과정 — 초기 컨셉은 10문항 추천형. 인터뷰에서 "또 테스트요?" 피로감과 추천 결과 불신 발견. 컨셉을 가벼운 필터(건너뛰기 가능) + 탐색형 리스트 + "현재 멤버 한마디" 카드로 전환.

결과 — 사용자 테스트 12명. 동아리 선택까지 클릭 수 11회 → 4회 단축. 가입 의향 9/12. "선배 한마디 보고 결정했다" 인용 다수.

역할: 리드 디자이너 (리서치 + 메인 플로우 설계) 도구: Figma, Notion 링크: 프로토타입 · 케이스 스터디 풀버전

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

위는 "도구를 안다"고 말하지만, 아래는 "사용자를 보고 결정한다"고 말합니다.

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

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

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

개발자 버전이 궁금하시면 이 시리즈 1편을, 기획자 버전이 궁금하시면 곧 발행될 3편을 참고해 주세요.

여러 프로젝트를 어떻게 선별하고 한 페이지에 배치할지는 다음 시리즈의 주제가 될 것입니다.