실제 기획 프로젝트 경험 이후 검증된 Practical UX/Product 사고 프레임

이 글은 웹 디자이너에서 기획자로 전환하던 시점으로 작성된 뉴스레터 내용을, 이후 실제 기획 업무를 경험한 뒤 실전 UX·Product 사고 프레임으로 다시 분석하고 재구성한 기록입니다.

당시에는 보이지 않았던 첫 기획 프로젝트 문제의 본질이, 실무 경험 이후에야 명확하게 드러났습니다.

많은 기획 포트폴리오는 ‘왜 이 서비스를 만들어야 하는지’ 설명하지 않은 채, 완성된 화면으로 모든 질문에 답하려고 하는 경향이 많습니다.

개인 기획 프로젝트를 시작할 때, 많은 사람들이 가장 먼저 여는 툴은 아마도 Figma일 것입니다. 문제를 정의하기도 전에 레이아웃을 잡고, 버튼을 놓고, 색을 고릅니다.

저 역시 그랬고, 그 결과 첫 기획 프로젝트는 완성도와 별개로 설득력 없는 포트폴리오가 되었습니다.

이 글은 그 실패 경험을 바탕으로, 지금도 실무에서 그대로 적용 가능한 기획 사고 프레임을 정리했습니다.

문제 정의 없이 시작한 기획은 왜 항상 화면으로 도망치는가

개인 기획 프로젝트의 출발점은 대개 비슷합니다.

“내가 불편하니까”
“내가 사용자니까”
“이미 써본 서비스라 이해하고 있으니까”

이 감정은 기획의 출발점이 될 수는 있지만, 기획 그 자체가 될 수는 없습니다. 그리고 이런 전제는 기획을 빠르게 시작하게 하면서, 동시에 문제 정의 과정을 통째로 생략하게 만듭니다.

문제를 말로 정리하지 않아도, 화면을 그리면 뭔가 진척된 느낌이 듭니다. 그래서 당시 저는 이 불편함을 언어로 정리하기보다, 바로 화면으로 옮겼습니다.

레이아웃을 잡고, 버튼을 배치하고, 컬러를 입히면 ‘무언가 만들고 있다’는 느낌이 들면서, 기획자는 그 결과물인 화면들의 나열을 보며 즉각적인 성취감을 받게 됩니다.

하지만 이 단계에서는 빠진 것이 있습니다.
“이 불편함이 정말 문제인가?”,
그리고 “누구의 문제인가?”라는 질문입니다.

실무에서 돌아보니, 문제 정의는 단순한 설명이 아니라 기획의 모든 판단을 고정하는 기준점이었습니다. 문제 정의가 없으면, 이후에 나오는 모든 화면과 기능은 설명할 수 없는 선택의 집합이 되어 버립니다.

당시 내가 만든 화면들은 그럴 듯 했지만, “왜 이 기능이 필요한가?”라는 질문 앞에서는 아무 말도 하지 못했던게 그 이유입니다.

하지만 실제 기획에서는 이 단계가 가장 위험합니다. 문제 정의 없이 만들어진 화면은, 질문을 받는 순간 무력해지기 마련입니다.

“이 기능이 왜 필요하죠?”
“이걸 누가 언제 쓰나요?”

이 질문에 답하지 못한다면, 그 화면은 기획 결과물이 아니라 정리된 디자인 조각에 가깝게 되어버릴 뿐입니다.

데스크 리서치는 ‘자료 조사’가 아니라 ‘가설을 걸러내는 과정’이다

많은 기획 포트폴리오에서 경쟁 서비스 분석은 이렇게 진행됩니다.

• 잘 만들어진 서비스들을 나열한다
• 눈에 띄는 기능을 모은다
• 서비스 화면에 배치한다

이 방식의 문제는, 기능이 왜 존재하는지를 전혀 설명하지 못한다는 것입니다. 실무 경험 이후에 알게 된 것은, 데스크 리서치의 목적은 “좋은 기능을 찾는 것”이 아니라

“내가 세운 가설이 맞는지,
아니면 틀렸는지를 확인하는 것”

이라는 점이었습니다.

예를 들어, 어떤 서비스가 첫 화면에 검색 기능을 크게 배치했다면 그건 단순한 UI 선택이 아니라 “사용자는 목적을 가지고 들어온다”는 강한 가설을 전제로 한 결정일 것입니다.

이 질문을 기준으로 서비스를 보면, 기능은 참고 대상이 아니라 가설의 결과물로 보이기 시작합니다. 단순히 따라 할 기능이 아닌, 내 서비스에는 적용하면 안 될 선택들이 더 명확해집니다.

개인 기획 프로젝트에서 데스크 리서치의 결과물은 ‘기능 목록’이 아니라, 해당 서비스에서 채택하지 않은 이유의 정리가 되어야 합니다.

사용자 페르소나는 ‘상상 캐릭터’가 아니라 판단 기준을 만드는 도구다

많은 페르소나는 나이, 직업, 취미로 채워져 있습니다.

하지만 실제 기획 과정에서 이런 정보는 기획 판단에 거의 도움이 되지 않기 때문에 대부분 사용되지 않습니다. 대신 실무에서 효과적이었던 것은 상황 기반 페르소나였습니다.

다시 말해, “이 사용자가 어떤 상황에서 이 서비스를 열었는가”에 대한 정의입니다.

이런 질문으로 정의된 페르소나는 화면 설계에서 매우 강력한 기준이 됩니다.

예를 들어, “급한 상황의 사용자”라면 설정 화면이나 상세 옵션은 깊이 숨겨져야 합니다.

반대로, “탐색 목적의 사용자”라면 첫 화면에서 정보의 밀도가 높아도 문제가 되지 않습니다.

페르소나는 상상 속 인물이 아니라, 버릴 기능과 남길 기능을 구분하기 위한 기준표로 활용되어야 합니다.

이렇게 정리된 페르소나는 IA와 User Flow를 설계할 때 명확한 기준이 됩니다. 메뉴를 늘릴지 줄일지, 기능을 숨길지 드러낼지 판단할 때 “이 페르소나라면 이 화면에서 멈출까?”라는 질문이 가능해지기 때문입니다.

IA와 User Flow는 ‘구조 설계’가 아니라 ‘버리는 결정’이다

IA를 메뉴 트리로만 이해하면, 기획 구조는 점점 복잡해지기만 할 뿐입니다.

“이 기능도 필요할 것 같고, 저 기능도 빠지면 안 될 것 같아서” 결국 모든 것을 담으려 하게 됩니다. 실제 기획에서 더 중요했던 질문은 다음과 같았습니다.

이 질문을 하지 않으면, IA는 확장만 되고 집중력은 사라지게 됩니다.

User Flow도 마찬가지입니다. 초기에는 Happy Path만 그렸습니다.

Happy Path란, 사용자의 감정을 기반으로 문제없이 끝까지 도달하는 이상적인 경로를 말합니다. 하지만 실무에서는 그보다 더 중요한 것이 있었습니다.

Happy Path보다 끊기는 지점을 기준으로 설계하지 않으면, User Flow는 실제 사용을 설명하지 못합니다. 사용자가 어디서 망설이고, 어디서 포기하는지를 먼저 정의하지 않으면 Flow는 보기 좋은 다이어그램에 그칠 수 밖에 없습니다.

‘버리는 결정’ 해석 시, 주의해야 할 점

여기서 IA와 User Flow를 ‘버리는 결정‘으로 표현한 진짜 의미에 대한 자세한 해석이 필요합니다.

결론부터 말하면:

❌ “IA는 구조가 아니다”라는 뜻은 절대 아닙니다
✅ “IA는 구조이되, 그 구조를 만들기 위해 반드시 ‘버리는 결정’이 필요하다”는 의미입니다

1. IA는 구조가 맞다

IA는 반드시 “전체 구조”를 표현해야 합니다. 이건 전제입니다.

2. “IA는 버리는 결정이다”라고 말하는 이유는?

여기서 말하는 “버린다”는 건:

구조를 없앤다 ❌
문서를 생략한다 ❌

가 아니라,

✅ “사용자에게 지금 이 순간 보여주지 않을 구조를 결정한다”
✅ “앞에 두지 않고, 뒤로 보내는 구조적 선택”을 의미합니다.

즉, IA 문서에는 존재하지만, 화면에는 노출되지 않는 구조를 만드는 결정입니다.

3. “제거”와 “숨김”은 IA에서 아주 중요한 설계 요소이다

흔한 오해로 IA는 메뉴에 보이는 구조나 네비게이션 트리를 의미하는 것이라고 생각하기 쉽습니다. 하지만 실제 기획 실무에서는 더 깊은 의미를 내포하고 있습니다.

이 모든 걸 어떻게 배치할지 정하는 게 실질적인 IA의 정의입니다.

4. ‘제거’와 ‘숨김’의 구체적인 의미는?

커머스 서비스의 홈 화면을 예로 들어보겠습니다.

홈(Home)
├─ 상품 검색(Product Search)
├─ 카테고리 탐색(Category Navigation)
├─ 주문 내역(Order History)
├─ 배송 조회(Delivery Tracking)
├─ 쿠폰 관리(Coupon Management)
├─ 리뷰 작성(Write a Review)
└─ 계정 설정(Account Settings)

홈(Home)
├─ 상품 탐색(Product Navigation)
└─ 검색(Search)

마이페이지(My Page):(2 depth)
├─ 주문 내역(Order History)
├─ 배송 조회(Delivery Tracking)
└─ 쿠폰(Coupons)

설정(Settings):(3 depth)
├─ 계정 정보(Account Information)
├─ 알림(Notifications)
└─ 결제 수단(Payment Method)

IA에서 노출을 조절하게 된다면 IA 문서에는 모두 존재하지만 홈에는 일부만 노출되는 형태로 보여지게 됩니다.

기획 단계에서는 ‘지금 당장 필요하지 않은 선택지’를 구분하고, ‘의사결정을 방해하는 정보 밀도’를 분석하여 설계에 반영해야 합니다.

“지금 당장 필요하지 않은 선택지”

예를 들어, ‘배송 조회/쿠폰 관리/계정 설정’ 이러한 기능들은 ‘구매 이후’에만 의미가 있으며, 첫 방문자의 목표와 직접적으로 연결되지는 않습니다. 그래서 홈에서 숨깁니다.

이것이 바로 “버리는 결정”입니다. 구조를 지우는 게 아니라, 노출을 미루는 결정입니다.

“의사결정을 방해하는 정보 밀도”

홈 화면은 사용자가:

“이 서비스에서 뭘 하면 되는지”
“첫 행동이 뭔지”

를 3초 안에 이해해야 하는 공간입니다. 그런데 만약 여기에서 ‘주문 내역/설정/리뷰 작성’ 같은 항목이 보이면 사용자는 ‘선택 피로’를 먼저 느낍니다.

다시 말해, “숨긴다는 것”은 의사결정을 방해하는 정보 밀도를 분석해서 인지 부하를 줄이는 설계를 하는 것입니다.

5. User Flow에서도 같은 논리다

User Flow는:

“이 기능을 쓸 수 있는가?” ❌
“이 기능에 언제 도달하게 할 것인가?” ⭕

예를 들어, “아직 도달하지 않은 사용자 상태”를 기준으로 리뷰 작성은 좋은 예시가 될 수 있습니다.

리뷰는 중요한 기능이지만, 구매 전에는 의미가 없으며, 첫 방문 사용자에게 바로 노출할 필요는 없습니다. 그래서 이 기능을 제거하는 것이 아닌, 구매 후 노출될 수 있도록 유저 플로우(User Flow)를 뒤로 미루는 결정을 하게 됩니다.

👉 User Flow를 구매 이후로 ‘이동’

즉, Flow 상에서는 “구매 완료 → 일정 조건 충족 → 리뷰 유도” 이렇게 뒤로 미루는 흐름을 설계합니다. 이 역시 “버리는 것처럼 보이지만, 사실은 ‘적절한 타이밍으로 이동시키는 것’”입니다.

6. 왜 굳이 ‘버린다’는 강한 표현을 쓰는가

‘숨긴다’, ‘버린다’고 표현하는 이유는 하나입니다. 대부분의 기획 초보자는 “구조를 만드는 일”에는 익숙하지만 “구조를 줄이는 일”에는 극도로 소극적이기 때문입니다.

실제로는 IA 문서에는 모두 존재하고, 개발 구조에도 모두 포함, 접근 경로도 명확합니다. 하지만, 첫 화면이라는 ‘노출 맥락’에서는 사라지게 되는 부분들을 결정해야 합니다.

이러한 것들이 기획에서 가장 어렵고, 그래서 가장 중요한 결정이기 때문에 기획자 입장에서는 의도적으로 강하게 “버린다 / 숨긴다”고 표현하는 겁니다.

결론적으로, IA는 구조를 그리는 문서임이 확실합니다. 하지만, 기획에서 더 어려운 일은 구조를 추가하는 것이 아니라, 어떤 구조를 지금 이 화면에서 보이지 않게 할지를 결정하는 일입니다.

‘홈에서 무엇을 제거할 것인가’, ‘어떤 기능을 몇 단계 뒤로 미룰 것인가’에 대한 판단이 없으면 IA는 결국 복잡해지고, 사용자는 길을 잃게 됩니다.

홈 화면에서 기능을 숨긴다는 말은, 그 기능이 중요하지 않다는 뜻이 아닙니다. 오히려 중요한 기능일수록, 사용자가 그 기능을 필요로 하는 순간에만 등장하도록 배치하는 것이 IA의 진정한 역할이라고 판단됩니다.

와이어프레임과 컴포넌트는 결과물이지 증거가 아니다

당시에 저는 컴포넌트 정리와 와이어프레임 완성도를 기획의 성과라고 생각했습니다. 하지만 실무에서 보니, 화면은 의사결정의 결과일 뿐이었습니다.

화면 퀄리티가 높아도 포트폴리오가 약해지는 이유는 단순합니다. 화면은 의사결정의 근거를 말해주지 않기 때문입니다.

중요한 것은 다음 질문에 답할 수 있는가입니다.

이 질문에 답하지 못하면, 아무리 정교한 화면도 기획으로 설득력을 갖기 어렵습니다.

다른 의미로 기획자는 단순히 화면을 만드는 사람이 아니라, 화면이 그렇게 될 수밖에 없는 이유를 설명하는 사람이기도 합니다.

개인 기획 포트폴리오에서 가장 중요한 것은 ‘완성도’가 아니다

개인 프로젝트에서는 종종 “실제 서비스처럼 보이게 만드는 것”에 집착하게 됩니다.

하지만 실무 관점에서 더 신뢰를 주는 것은 완성도가 아니라 사고(thinking)의 흔적입니다.

이런 요소들은 실패처럼 보이지만, 오히려 기획자로서의 사고 방식을 가장 잘 드러낼 수 있습니다.

그렇기 때문에 이 첫 실패 프로젝트는 결과적으로 단순히 “첫 기획이 망했다”는 이야기가 아닌, “다음 기획에서는 무엇을 먼저 해야 하는지”를 명확히 알려준 기준점이 되었습니다.

디자이너의 사고방식으로, 또는 다른 잘못된 방식으로 기획을 접근했을 때 어떤 지점에서 반드시 한계에 부딪히는지를 보여주는 사례들의 모음과 해결을 위한 사고 프레임의 제시라고 볼 수 있습니다.

실무 경험 이후에 돌아보니, 기획은 화면을 잘 만드는 일이 아니라 보이지 않는 선택을 설명하는 일이었습니다. 무엇을 추가했는지가 아니라, 무엇을 제거했고 왜 제거했는지를 말할 수 있을 때 기획은 비로소 설득력을 갖게 됩니다.

실전 UX·Product 사고 프레임에 초점을 맞춘 이 글이 개인 기획 프로젝트를 준비하는 사람들에게 “화면을 그리기 전에 반드시 멈춰야 할 지점”을 한 번 더 생각하게 만드는 기준점이 되기를 바랍니다.

— Lane