UX/UI 기획에서 방법론을 이야기하면 여전히 문제 정의, 페르소나, IA 같은 단어가 먼저 떠오릅니다. 하지만 실제 실무에서는 이런 용어보다 더 자주 등장하는 질문이 있습니다.
“이 기능을 왜 지금 결정해야 하는가?”
그리고 그 질문은 곧 다른 질문으로 이어집니다.
“이 결정을 하지 않으면, 다음 단계에서 무엇이 막히는가?”
기획 업무를 하다 보면, 어느 순간부터 문서와 화면은 계속 늘어나는데도 프로젝트가 앞으로 나아가지 않는 느낌을 받을 때가 있습니다. 기능 정의서는 꽤 두껍고, 화면도 어느 정도 완성되어 있는데, 회의에서는 계속 비슷한 질문이 반복됩니다.
“이 기능, 꼭 지금 들어가야 하나요?”
“이건 왜 이렇게 설계된 거죠?”
이런 상황은 대부분 기획자의 역량 부족 때문이 아닙니다. 바로 ‘결정 단위’ 중심의 UX가 아닌 기획을 정리하는 기준 자체가 ‘산출물 중심’으로 잡혀 있기 때문입니다.
실무에서 사용하는 “Problem–Decision–Artifact” 방법론
최근 실무에서 점점 중요해지고 있는 접근은 기능이나 화면이 아니라 ‘의사결정 단위’를 중심으로 기획을 정리하는 방식입니다.
이 글에서는 실제 기획 프로젝트에서 반복적으로 검증된 ‘Problem–Decision–Artifact’ 프레임을 중심으로, 이 방법론이 왜 실무에서 유효한지 구체적으로 살펴보도록 하겠습니다.
실무에서 기획이 흔들리는 지점은 ‘문제가 아니라 결정’이다
회의에서 가장 자주 반복되는 말 중 하나는 “이건 나중에 결정하자”입니다. 처음에는 합리적으로 들리지만, 이 말이 누적되기 시작하면 프로젝트는 점점 정체됩니다.
기능 정의서, 정책 문서, 화면 시안은 계속 추가되지만, 어떤 선택이 내려졌는지는 누구도 명확히 말하지 못하게 됩니다.
예를 들어 커머스 서비스에서 ‘비회원 주문’을 논의한다고 가정해보겠습니다.
문서에는 “비회원 주문도 고려한다”, “로그인 장벽을 낮춘다”라는 문장이 들어가 있지만, 정작 비회원이 어디까지 접근 가능한지는 정리되어 있지 않습니다.
이 상태에서는 화면을 아무리 그려도, 개발 단계에서 다시 질문이 돌아올 수밖에 없습니다.
• 배송 조회는 로그인 없이 가능한가요?
• 결제 실패 후 재시도 시 로그인은 언제 요구되나요?
이 질문들은 화면이 없어서 생기는 문제가 아닙니다. 비회원에게 어디까지 권한을 줄 것인지에 대한 결정이 문서에 존재하지 않기 때문에 발생하는 것입니다.
이 시점에서 기획자가 내려야 할 결정은 기능 구현 여부가 아닙니다.
• 배송 조회는 주문 완료 직후 링크를 통해서만 접근 가능하게 한다
• 비회원 주문 내역은 재접근을 허용하지 않는다
이처럼 결정이 먼저 문장으로 명시되면, 화면과 개발 방식은 그 다음 문제로 자연스럽게 이어지게 됩니다.
실무에서 기획이 흔들리는 이유는 문제를 몰라서가 아닙니다. 대부분의 경우 문제는 이미 공유되어 있습니다.
흔들리는 이유는 “지금 이 시점에 무엇을 결정해야 하는지”가 문서 어디에도 명시되어 있지 않기 때문입니다.
“Problem–Decision–Artifact” 구조란 무엇인가
이 접근에서 기획 문서는 세 가지 층위로 나뉩니다.
2️⃣ Decision: 지금 내려야 하는 선택과 그 기준
3️⃣ Artifact: 그 결정을 반영한 결과물 (화면, 정책, 플로우 등)
이 세 레이어를 구분하는 이유는, 많은 기획 문서가 결정이 내려지지 않은 상태에서 바로 결과물(Artifact)부터 만들어지기 때문입니다. ‘Problem’과 ‘Decision’을 분리해 명시하지 않으면, 화면은 많아지지만 왜 그런 화면이 나왔는지는 설명할 수 없게 됩니다.
예를 들면, “주문 완료 후 재구매율이 낮다”라는 문제 상황에서, 흔히 바로 떠올리는 해결책은 다음과 같습니다.
- 추천 상품 배너를 추가한다
- 쿠폰을 노출한다
- 재구매 CTA 버튼을 강화한다
하지만 ‘Problem–Decision–Artifact 구조’에서는 먼저 결정해야 할 질문을 분리합니다.
• 재구매 유도 시점은 언제가 적절한가? (주문 직후 / 배송 완료 후)
• 모든 사용자에게 동일한 방식으로 노출할 것인가?
이 질문들을 기반으로 다음과 같은 ‘Decision’이 내려질 수 있습니다.
• 재구매 CTA는 홈이 아니라 주문 상세 화면 하단에 배치한다
이 결정이 내려진 이후에야, 홈 화면 구성이나 주문 상세 UI 같은 Artifact가 의미를 갖게 됩니다.
이 구조와 기존 방식과의 가장 큰 차이는 Artifact(산출물)가 중심이 아니라는 점입니다.
화면은 항상 마지막에 옵니다. 그리고 화면이 존재하려면, 그 전에 반드시 “어떤 결정을 했는가”가 명시되어 있어야 합니다.
‘Decision’을 명확히 쓰는 것이 왜 중요한가
실무에서 좋은 기획 문서는 설명이 많은 문서가 아닙니다. 바로 결정이 드러나는 문서입니다.
다음 문장은 얼핏 좋아 보이지만, 실제로는 아무 결정도 담고 있지 않는 내용입니다.
“사용자가 쉽게 접근할 수 있도록 한다”
“불필요한 단계를 줄인다”
이 문장은 모두 동의할 수 있는 내용이지만, 반대하거나 질문할 수 있는 지점이 없습니다. 반면 아래 문장은 분명한 결정을 담고 있습니다.
“비회원 사용자는 주문 내역에 접근할 수 없다”
“홈 화면에서는 결제 관련 정보는 노출하지 않는다”
이 문장들은 곧바로 많은 논쟁을 불러오게 되지만, 바로 그 점이 중요한 포인트가 됩니다. 실무에서 결정이란 항상 누군가에게 불편함을 만들기 마련입니다.
논쟁이 불가능한 문장은 대부분 아무것도 결정하지 않은 문장입니다.
‘Decision’ 중심으로 IA와 Flow를 다시 바라보기
이 프레임에서 IA와 User Flow는 ‘구조 설계물’이 아니라 결정의 결과입니다.
예를 들어 “주문 내역은 홈에 노출하지 않는다”라는 결정이 내려지면, 홈 IA는 자연스럽게 단순해집니다.
반대로 이 결정이 빠진 상태에서 IA를 그리면, 홈에는 점점 더 많은 메뉴가 쌓이게 됩니다.(관련 내용 글 참고: 실제 기획 프로젝트 경험 이후 검증된 Practical UX/Product 사고 프레임).
User Flow도 마찬가지입니다. 흔히 Happy Path를 먼저 그리지만, 실무에서는 다음 질문이 훨씬 중요합니다.
“어디에서 로그인을 요구할 것인가?”
“어느 단계에서 사용자의 행동을 제한할 것인가?”
그리고 이 질문들에 대해, 실무에서는 다음과 같은 답이 필요합니다.
• 장바구니 담기까지는 비회원도 허용한다
• 결제 버튼 클릭 시점에서만 로그인을 요구한다
이 질문에 대한 답이 바로 ‘Decision’이며, 이 결정이 내려지면 User Flow는 다음과 같이 달라집니다.
1️⃣ 홈 → 상품 → 장바구니 → 로그인 요청 → 결제
2️⃣ 홈 → 마이페이지 진입 → 즉시 로그인 요청
즉, Flow는 ‘이상적인 사용자 경로’를 그리는 도구가 아니라 사용자의 행동 제한에 대한 결정이 시각적으로 정리된 결과물이 되는 것입니다.
‘Artifact’는 설득 수단이 아니라 기록물이다
“Problem–Decision–Artifact” 프레임에서 화면의 역할은 분명합니다.
화면은 설득을 위한 도구가 아니라, 이미 내려진 결정의 기록물입니다. 그래서 화면만 떼어놓고 보면 화려하지 않을 수도 있습니다.
하지만 결정이 명확한 화면은 설명 없이도 따라오는 수많은 질문을 견딜 수 있습니다.
회의에서 “왜 이 기능이 없나요?”라는 질문이 나왔을 때, 다음과 같은 답변이 가능하다면 해당 기획은 이미 제대로 작동하고 있다고 볼 수 있습니다.
✅ 해당 기능은 사용자 요청 빈도가 낮아 후순위로 분류했다
✅ MVP 범위에서는 핵심 구매 흐름만 검증하기로 했다
이 답변의 핵심은 화면 설명이 아닙니다. 언제, 어떤 기준으로 제외했는지가 명확히 기록되어 있다는 점입니다.
이 경우 화면은 설득 자료가 아니라, 이미 내려진 결정이 반영된 결과물로 기능하게 됩니다.
이 프레임 방식이 효과적인 상황
Problem–Decision–Artifact 구조는 특히 다음과 같은 상황에서 효과적일 수 있습니다.
1. 요구사항이 계속 추가되는 프로젝트
예를 들어 커머스 서비스에서 “리뷰 작성 기능을 추가해달라”는 요청이 들어왔을 때, 바로 화면을 그리기보다 “이 요청이 어떤 기존 결정에 영향을 주는가?”를 먼저 확인하게 됩니다.
그 결과, MVP 범위에서 제외하기로 했던 결정과 충돌한다면 해당 요청은 즉시 반영되지 않습니다.
2. 이해관계자가 많은 서비스
디자이너는 사용성을, 개발자는 구현 난이도를, 마케터는 노출 효과를 각각 주장하는 상황에서 Decision이 문서에 명시되어 있으면 논의의 초점이 달라집니다.
“누구 말이 맞느냐”가 아니라, “이 결정을 지금 바꿔야 할 이유가 충분한가”로 논쟁이 이동하게 됩니다.
3. 산출물은 많은데 팀이 점점 혼란스러워질 때
화면, 플로우, 정책 문서가 계속 늘어나는데도 방향성이 흐려지는 경우가 있습니다.
이 프레임을 적용하면 회의의 질문이 “이걸 더 만들까요?”가 아니라 “지금 우리가 내려야 할 결정이 무엇인가요?”로 바뀌게 됩니다.
그 순간부터 문서는 늘어나지 않고, 오히려 알기 쉽게 정리되기 시작합니다.
이 접근은 새로운 방법론이라기보다, 기획을 정리하는 관점의 이동에 가깝습니다. 하지만 이 관점 하나만으로도 회의는 훨씬 짧아지고, 문서는 명확해질 수 있습니다.
기획의 성장은 ‘결정 책임’을 인식하는 순간 시작된다
좋은 화면을 만드는 일과, 제대로 기획하는 일은 전혀 다른 역량입니다.
기획은 언제나 불완전한 정보 속에서 선택을 내려야 하는 과정이며, 그 선택을 숨기지 않고 드러내는 것이 기획자의 역할입니다.
방법론이 그 선택을 대신해주지는 않습니다. 다만 어디에서 결정을 내려야 하는지를 명확하게 드러내 줄 뿐입니다.
결정을 미루거나 흐리게 만들지 않고, 왜 지금 이 선택을 했는지 설명할 수 있을 때 기획은 비로소 화면을 넘어 하나의 사고 체계로 작동하게 됩니다.
그리고 그 순간부터, 기획자는 더 이상 “정리하는 사람”이 아니라 결정에 책임지는 사람으로 성장하기 시작합니다.
— Lane
[함께 읽으면 좋은 글]
실제 기획 프로젝트 경험 이후 검증된 Practical UX/Product 사고 프레임
