포트폴리오 정리, 리서치 프로세스 공개할까 말까

23 Dec, 2025
- 리서치

포트폴리오 정리, 리서치 프로세스 공개할까 말까

9년 차의 포트폴리오

주말이다. 노트북을 켰다. 포트폴리오 파일 이름: “Portfolio_Final_v23.pdf” 23번째 버전이다.

9년 차가 됐다. UX 기획자로. 포트폴리오를 다시 정리하기로 했다. 이직 때문이 아니다. 그냥, 정리가 필요했다.

파일을 열었다. 첫 페이지. ”○○○ | UX Planner | 9 Years” 경력 요약, 주요 프로젝트, 사용 툴. 깔끔하다. 전문적이다. 그런데.

뭔가 비어있다.

프로젝트 1: “커머스 앱 리뉴얼”

유저 인터뷰 32명
전환율 23% 증가
만족도 4.2 → 4.7

숫자는 좋다. 결과도 좋다. 근데 이게 다인가.

32명을 어떻게 모집했는지. 인터뷰 질문을 몇 번이나 수정했는지. 녹취록을 밤새 들으며 패턴을 찾던 과정. 기획팀과 3시간 논쟁하며 설득하던 순간.

그건 없다. 포트폴리오에.

결과만 보여주는 게 맞나

월요일 아침이다. 후배가 물었다. “선배님, 포폴 검토 부탁드려요.”

받아봤다. 25살, 2년 차. 페이지마다 화려하다. 피그마 목업, 유저플로우, 와이어프레임.

“여기 이 기능, 어떻게 도출했어?” “아, 벤치마킹이요.” “유저 리서치는?” “시간이 없어서요. 그래도 결과는 좋았어요.”

결과는 좋았다. MAU 15% 증가, 체류시간 2분 증가. 수치로는 성공이다.

근데 왜 증가했는지는 모른다. 어느 유저군이 반응했는지도. 다음엔 어떻게 개선할지도.

“포폴에 프로세스 넣어봐.” “네? 그럼 결과 공간이 줄어서…” “결과만으론 부족해.”

말하고 나서 생각했다. 나도 결과 위주잖아. 포트폴리오.

화요일이다. 점심시간. UX팀 회의실에서 선배랑 얘기했다. 12년 차, 우리 회사 UX팀장.

“팀장님, 포트폴리오 어떻게 만드세요?” “왜? 이직하게?” “아뇨. 그냥 정리하려고요.”

팀장님이 웃었다. “나도 고민이야. 프로세스 공개하면…” “보안 문제요?” “그것도 있고. 근데 더 큰 건.”

팀장님이 화면을 켰다. “리서치 프로세스 보여주면 다들 따라해.” “그게 문제예요?” “문제가 아니라, 오해가 생겨.”

“프로세스만 따라하면 같은 결과 나올 거라고 생각해.” “실제론 다르죠.” “맞아. 맥락이 다르니까.”

리서치 케이스, 어디까지 보여줄까

수요일 저녁이다. 집에서. 리서치 케이스를 다시 봤다.

작년 프로젝트: “금융 앱 온보딩 개선” 리서치 기간: 6주 인터뷰 대상: 40대~60대 20명 프로세스: 사전 설문 → 인터뷰 → 사용성 테스트

결과:

온보딩 완료율 34% → 67%
고객센터 문의 52% 감소
앱 삭제율 41% 감소

숫자는 완벽하다. 발표 자료에도 넣었다. 임원 보고에도.

근데 과정은.

1차 인터뷰: 질문지 3번 수정

“얼마나 자주 사용하세요?” → 너무 포괄적
“어려운 점이 뭔가요?” → 유도 질문
“이 화면에서 무엇을 하시겠어요?” → 구체적

2차 인터뷰: 장소 실패

회의실 환경 → 부담스러워함
카페로 변경 → 편안한 대화

3차 테스트: 프로토타입 문제

고해상도 목업 → 완성본인 줄 알고 평가
저해상도로 재작업 → “아직 만드는 중이구나” 인식

이런 시행착오. 포트폴리오에 넣을까.

남편한테 물었다. “이런 거 보여주는 게 나아?” “뭐가?” “실패한 거. 수정한 거.”

남편은 개발자다. 같은 회사. “당연하지. 개발도 그래.” “처음부터 잘 짠 코드 없어.” “리팩토링 과정이 더 중요해.”

“근데 면접관은 결과를 보고 싶어하잖아.” “면접관 수준에 따라 다르지.” “좋은 면접관은 과정을 물어봐.”

맞는 말이다. 작년에 후배 면접 봤다. 포트폴리오 화려했다. 결과 완벽했다.

“이 기능, 왜 이렇게 기획했어요?” ”…벤치마킹이요.” “다른 앱이랑 뭐가 달라요?” ”…비슷한데, 우리 서비스에 맞게?”

탈락이었다. 결과만 있고, 사고 과정이 없었다.

보안과 투명성 사이

목요일이다. 출근길. 보안 가이드 메일이 왔다. “외부 공개 시 프로젝트명, 수치 비공개”

이해한다. 대기업이니까. 경쟁사가 볼 수도 있고. 내부 전략이 노출될 수도.

근데 그럼 뭘 보여주나.

”○○ 서비스 개선”

유저 리서치 진행
핵심 페인포인트 도출
개선안 적용
긍정적 결과 확인

이게 뭔가. 누구나 쓸 수 있는 문장. 구체성이 없다.

점심시간이다. UX 커뮤니티 슬랙을 봤다. 누가 물었다. “리서치 케이스 공유할 때 어떻게 하세요?”

댓글 40개.

“프로젝트명 가명 처리” “수치는 비율로만” “스크린샷 블러 처리” “프로세스 중심으로 작성”

모두 비슷하다. 보안 때문에 가린다.

그런데 한 댓글이 눈에 띄었다. “프로세스 공개하면 오히려 경쟁력 아닐까요?” “어차피 같은 방법 써도 결과는 다르니까.”

맞다. 리서치 방법론은 공개됐다. 심층 인터뷰, 설문, 사용성 테스트. 구글에 검색하면 다 나온다.

근데 실제로 잘하는 사람은 적다.

왜? 방법을 아는 것과 적용하는 건 다르니까. 질문 하나 던지는 타이밍. 침묵을 견디는 인내. 예상 밖 답변에 대응하는 순발력.

이건 경험이다. 노하우다. 프로세스 공개한다고 복사되지 않는다.

오후 3시다. 회의. 서비스 기획팀과 협업 미팅.

기획자가 물었다. “이번 기능, 리서치 필요해요?” “당연하죠. 유저 니즈 확인해야죠.” “근데 시간이… 2주밖에 없어요.”

또 시작이다. “2주면 빠른 리서치 가능해요.” “어떻게요?”

화이트보드에 그렸다.

1주차:

1~2일: 리서치 설계
3~~4일: 인터뷰 (8~~10명)
5일: 분석

2주차:

1~2일: 인사이트 도출
3~4일: 기획 반영
5일: 검증 테스트

“이렇게요. 해본 적 있어요.” “오, 이거 문서로 있어요?” ”…아뇨. 그냥 제 방식이에요.”

회의 끝나고 생각했다. 이런 걸 정리해야 하나. “빠른 리서치 프로세스”

공개하면 도움될 사람 있을 거다. 초보 기획자, 리서처. 시간 부족하다는 핑계 대는 팀.

근데 공개하면 내 경쟁력은?

아, 맞다. 이미 답했잖아. 방법 아는 것과 실행은 다르다.

과정의 가치

금요일 저녁이다. 퇴근 후. 카페에서 포트폴리오를 다시 열었다.

새 섹션을 만들었다. “Research Process & Learnings”

프로젝트 이름: 가명 처리 수치: 비율로만 표기 하지만 과정은 구체적으로.

금융 앱 온보딩 개선 케이스

배경:

타겟: 금융 앱 처음 쓰는 40~60대
문제: 온보딩 중단율 66%
목표: 완료율 50% 이상

리서치 설계:

왜 중단하는가? (Why)
어디서 막히는가? (Where)
무엇이 어려운가? (What)

1차 시도와 실패:

온라인 설문 100명 → 표면적 답변만
“어려워요”, “복잡해요” → 구체성 없음
학습: 정량보다 정성이 필요

2차 인터뷰 설계:

대면 인터뷰 20명
장소: 카페 (편안한 환경)
방식: 실제 앱 사용하며 Think Aloud

인터뷰 중 발견:

“이 버튼 누르면 돈 나가요?” (불안)
“다음 화면 뭐 나올지 무서워” (예측 불가)
“글씨 작아서 안경 써도 안 보여” (접근성)

핵심 인사이트:

문제는 ‘어려움’이 아니라 ‘불안’
설명 추가가 아니라 ‘신뢰’ 구축 필요
단계별 ‘예측 가능성’ 제공

개선 방향:

각 단계마다 “다음엔 이런 화면이 나와요” 미리 알림
“이 과정에서 결제는 발생하지 않아요” 명시
글자 크기 2단계 증가, 대비 강화

결과:

완료율 2배 증가
고객센터 문의 절반 감소

교훈:

표면적 불편이 아닌 근본 감정 파악
정량 데이터는 ‘What’, 정성은 ‘Why’
가설 검증보다 발견이 더 중요

이렇게 쓰니까 다르다. 단순 결과가 아니라, 사고 과정.

누군가 이걸 보면. “아, 이렇게 접근하는구나.” “실패해도 괜찮구나.” “과정에서 배우는구나.”

주말이다. 토요일 오전. UX 스터디 모임에 갔다. 주니어 기획자 5명, 나.

한 명이 물었다. “선배님, 리서치 어떻게 배우셨어요?” “학교에서? 책에서?”

웃었다. “실패하면서.”

“처음엔 질문지 만들 때 유도 질문 가득했어.” “인터뷰 시간 30분 계획했는데 10분 만에 끝났어.” “녹취록 듣다가 내 질문이 답을 강요했다는 걸 알았어.”

“그런 거 포트폴리오에 써요?” “쓰려고. 이제.”

“왜요? 실패한 건데.” “실패가 배움이니까.” “과정이 없으면 결과도 의미 없어.”

다들 고개를 끄덕였다. 한 명이 말했다. “저도 그렇게 써볼래요.” “결과만 쓰니까 제가 뭘 했는지도 모르겠더라고요.”

맞다. 그거다. 결과만 나열하면 나조차 기억 못 한다. 3년 전 프로젝트, 숫자는 기억나는데 과정은 흐릿하다.

과정을 기록해야 한다. 나를 위해서라도.

공개의 기준

일요일이다. 집에서. 포트폴리오 거의 완성됐다.

남편이 물었다. “다 된 거야?” “응. 근데 고민이야.”

“뭐?” “이거 블로그에 올릴까.” “포트폴리오를?”

“아니. 리서치 프로세스.” “케이스 스터디 형식으로.” “보안 문제 없게 각색해서.”

남편이 생각하더니. “올려.” “왜?”

“첫째, 너한테 도움돼.” “글 쓰면서 정리되잖아.” “둘째, 남한테 도움돼.” “검색하는 사람들 있을 거야.”

“셋째는?” “없어. 둘이면 충분하지.”

웃었다. 그래, 충분하다.

공개 기준을 정했다.

공개 O:

리서치 방법론
프로세스 설계
시행착오와 학습
질문 설계 팁
분석 프레임워크

공개 X:

구체적 프로젝트명
실제 수치 (비율로 변환)
회사 내부 전략
개인정보 관련
경쟁 민감 정보

이 기준이면 괜찮다. 방법론은 공유하되, 맥락은 보호.

저녁이다. 포트폴리오 최종 버전. “Portfolio_2024_Final.pdf”

목차를 봤다.

Career Summary
Core Projects
Research Process & Insights ← 새로 추가
Methodology & Tools
Growth & Learnings ← 새로 추가

섹션 3, 5가 새로 생겼다. 예전엔 없었다. 결과만 있었다.

이제는 과정이 있다. 실패도 있다. 배움도 있다.

더 진짜 같다. 나답다.

9년 차의 깨달음

월요일 아침이다. 출근했다. 컴퓨터를 켰다.

메일이 와있다. 작년에 강연 들었던 주니어에게서.

“선배님, 포트폴리오 조언 구합니다. 결과만 쓰니까 공허해요. 과정을 넣고 싶은데 어떻게 해야 할까요?”

답장을 썼다.

“실패한 것부터 써보세요. 처음 계획했던 것. 실제로 어떻게 바뀌었는지. 왜 바꿨는지.

결과가 좋았던 이유. 운이었는지, 실력이었는지. 다음엔 무엇을 다르게 할지.

이게 진짜 포트폴리오예요. 숫자가 아니라 사고방식을 보여주는 것.”

보내고 나서 생각했다. 나도 이제야 알았다.

9년 차가 되어서야.

포트폴리오는 이력서가 아니다. 성과 자랑이 아니다.

사고방식을 보여주는 거다. 문제를 어떻게 바라보는지. 해결을 어떻게 접근하는지. 실패를 어떻게 배움으로 바꾸는지.

그게 진짜 경쟁력이다.

점심시간이다. 후배가 다시 왔다. “선배님, 포트폴리오 수정했어요.”

봤다. 달라졌다. 프로세스가 추가됐다. 시행착오가 있다. 학습이 보인다.

“훨씬 좋아졌네.” “그죠? 근데 분량이 너무 길어졌어요.” “괜찮아. 읽을 사람은 읽어.”

“안 읽을 사람은요?” “그 회사 안 가면 돼.”

후배가 웃었다. “그것도 맞네요.”

맞다. 결과만 보는 회사. 숫자만 중요한 회사. 그런 곳엔 안 가면 된다.

과정을 이해하는 곳. 사고방식을 평가하는 곳. 그런 곳이 좋은 회사다.

저녁이다. 퇴근 전. 블로그에 글을 쓰기 시작했다.

제목: “UX 리서치 케이스 스터디: 금융 앱 온보딩 개선” 부제: “결과가 아닌 과정, 성공이 아닌 배움”

서론을 썼다.

“이 글은 완벽한 케이스가 아닙니다. 시행착오를 거친 과정입니다. 실패도 포함돼있습니다.

하지만 그게 현실이고, 그게 리서치입니다.”

쓰면서 후련했다. 더 이상 결과만 포장하지 않아도 된다. 과정을 보여줘도 된다.

9년이 걸렸다. 이걸 깨닫는 데.

공개할까 말까 고민했는데, 결국 과정 자체가 답이었다.