콘텐츠로 이동
CS Study

Product Discovery & UX Flow

Product Discovery & UX Flow

섹션 제목: “Product Discovery & UX Flow”

분류: Layer 13 - Product Engineering & Growth Systems

핵심 질문

섹션 제목: “핵심 질문”

Product Engineer가 기획과 디자인까지 맡는다는 것은 “아이디어를 많이 내는 사람”이 된다는 뜻이 아니다. 사용자의 문제를 구현 가능한 흐름으로 줄이고, 그 흐름이 실제 행동 변화로 이어졌는지 검증할 수 있게 만드는 역할을 맡는다는 뜻이다.

이 문서는 기능을 만들기 전에 Product Engineer가 확인해야 하는 discovery 질문, UX flow, 상태 설계, 구현 단위를 연결한다.

1. 한 줄 정의

섹션 제목: “1. 한 줄 정의”

Product Discovery & UX Flow는 사용자 문제를 발견하고, 핵심 행동까지의 흐름을 설계하며, 그 흐름을 화면·API·상태·이벤트로 구현 가능한 단위로 바꾸는 Product Engineering 역량이다.

2. 왜 중요한가

섹션 제목: “2. 왜 중요한가”

프론트엔드 경험이 길면 화면을 빠르게 만들 수 있다. 플랫폼 경험이 있으면 배포와 운영 안정성도 고려할 수 있다. 하지만 Product Engineer에게는 그 사이에 한 층이 더 필요하다. “이 기능이 실제로 어떤 사용자 문제를 줄이는가”와 “그 변화가 어떤 행동으로 관찰되는가”를 설계 초기에 묻는 층이다.

Discovery가 약하면 다음 문제가 반복된다.

  • 요구사항은 구현했지만 사용자가 핵심 행동까지 도달하지 못한다.
  • 화면은 예쁘지만 onboarding, empty state, error recovery가 끊긴다.
  • 이벤트는 쌓이지만 어떤 흐름의 어느 단계가 문제인지 알 수 없다.
  • PM, 디자이너, 엔지니어가 같은 단어를 쓰지만 서로 다른 성공 기준을 상상한다.

Product Engineer는 이를 피하기 위해 문제 정의, 사용자 흐름, 구현 경계, 측정 이벤트를 한 장의 설계로 묶는다.

2.5. 선행 방식의 한계 — 왜 Discovery와 UX Flow가 등장했는가

섹션 제목: “2.5. 선행 방식의 한계 — 왜 Discovery와 UX Flow가 등장했는가”

전통적인 기능 구현 방식은 “요구사항 문서가 내려오면 화면과 API를 만든다”에 가깝다. 이 방식은 할 일이 명확하고 빠르지만, 문제 정의가 틀렸거나 UX 흐름이 끊긴 경우를 코드 작성 후에야 발견한다. 그러면 엔지니어는 이미 만든 화면을 고치고, 이벤트를 나중에 덧붙이고, 출시 후 지표가 흔들려도 원인을 설명하지 못한다.

Product Discovery는 이 한계를 줄이기 위해 등장한 앞단의 학습 루프다. Nielsen Norman Group은 discovery phase를 사용자의 문제, 니즈, 맥락을 이해하고 무엇을 만들지 결정하기 전의 탐색 활동으로 설명한다. Product Engineer에게 중요한 점은 리서치 자체가 아니라, discovery 결과를 구현 가능한 UX 흐름과 측정 가능한 이벤트로 번역하는 것이다.

따라서 이 문서의 lineage는 분명하다. 요구사항 전달 중심 개발의 한계는 “무엇을 만들지”는 알려주지만 “왜 이 흐름이어야 하는지”와 “성공을 어떻게 관찰할지”를 충분히 알려주지 못한다. Product Discovery & UX Flow는 그 빈틈을 사용자 문제, 핵심 행동, 상태 전이, 이벤트 설계로 메운다.

3. PE가 보는 Discovery 산출물

섹션 제목: “3. PE가 보는 Discovery 산출물”

Product Engineer에게 discovery 산출물은 긴 리서치 보고서보다 다음 네 가지가 더 중요하다.

산출물PE가 확인할 질문구현으로 이어지는 형태
Problem statement사용자가 지금 어떤 비용을 치르고 있는가해결해야 할 friction, 제외할 범위
Target user segment누구의 문제를 먼저 풀 것인가권한, plan, workspace, cohort 조건
Desired behavior어떤 행동이 늘거나 줄어야 하는가activation event, conversion event
UX flow사용자가 어떤 순서로 행동하는가route, state, API, error/empty/success 상태

좋은 discovery는 “사용자가 불편해한다”에서 멈추지 않는다. 예를 들어 “팀 관리자가 신규 멤버를 초대하지 못한다”는 문제는 다음처럼 구현 가능한 문장으로 바뀐다.

  • 대상: 유료 workspace의 admin
  • 현재 friction: 초대 권한과 billing seat 증가 비용을 초대 직전에 이해하지 못함
  • 원하는 행동: admin이 초대 링크를 만들고 첫 멤버가 가입을 완료함
  • 핵심 이벤트: invite_created, invite_accepted
  • 실패 상태: seat limit, expired invite, permission denied, email delivery failed

4. UX Flow를 구현 단위로 바꾸기

섹션 제목: “4. UX Flow를 구현 단위로 바꾸기”

UX Flow는 화면 순서도가 아니라 제품 상태의 흐름이다. 다음 네 층을 함께 봐야 한다.

UX Flow를 구현 단위로 번역하는 네 층

사용자 의도

사용자가 지금 하려는 일과 성공이라고 느끼는 순간

예: 멤버를 초대하고 팀 설정이 끝났다고 느낀다

상태 전이

화면, 서버 도메인, 권한 상태가 어떤 순서로 바뀌는지

예: draft invite -> sent invite -> accepted membership

실패 복구

권한 없음, 네트워크 실패, 결제 한도, 중복 요청을 어떻게 회복하는지

예: seat limit이면 결제 안내, expired이면 재발송

관찰 이벤트

흐름의 시작, 전환, 이탈, 완료를 어떤 이벤트로 기록하는지

예: invite_modal_opened, invite_created, invite_error_seen

이 네 층을 함께 쓰면 기획과 구현 사이의 번역 손실이 줄어든다. 디자인은 상태를 보여주고, API는 상태 전이를 보장하며, analytics는 흐름의 품질을 확인한다.

5. Activation UX를 먼저 본다

섹션 제목: “5. Activation UX를 먼저 본다”

Product Engineer는 UX Flow를 설계할 때 “첫 성공 경험”을 먼저 찾아야 한다. Activation은 사용자가 제품의 핵심 가치를 처음 경험한 상태다. 기능마다 activation event가 다르다.

제품/기능activation에 가까운 행동단순 vanity event
협업 도구첫 팀원이 초대되어 문서에 댓글을 남김회원가입 완료
개발자 도구첫 API key로 성공 응답을 받음대시보드 방문
분석 도구첫 이벤트가 수집되고 차트가 저장됨SDK 설치 페이지 조회
결제 기능구독 상태와 entitlement가 실제 기능 접근을 바꿈결제 버튼 클릭

Vanity event는 사용자가 “가치를 경험했다”는 증거가 약하다. Activation event는 사용자의 목표와 제품의 핵심 가치가 만나는 지점이어야 한다.

퀴즈

새 온보딩 화면의 성공 지표로 page_view만 두면 왜 부족한가?

힌트: 사용자가 화면을 봤다는 사실과 가치를 경험했다는 사실은 다르다.

정답 보기

page_view는 노출 지표일 뿐 핵심 행동 완료를 말해주지 않는다. Product Engineer는 온보딩이 의도한 activation 행동, 예를 들어 첫 프로젝트 생성, 첫 팀원 초대, 첫 API 호출 성공 같은 이벤트를 함께 정의해야 한다.

6. 구현 전 30분 Discovery Review

섹션 제목: “6. 구현 전 30분 Discovery Review”

실제 업무에서는 모든 기능에 긴 리서치를 붙일 수 없다. 대신 구현 전 30분만 써도 큰 실패를 줄일 수 있다.

시나리오

초대 기능을 개선해야 한다

PM은 초대 전환율이 낮다고 말하고, 디자인은 초대 모달 개선안을 가져왔다. 백엔드는 seat limit과 권한 처리가 복잡하다고 말한다.

바로 UI를 만들기 전에 어떤 문제, 사용자 구간, 상태 전이, 측정 이벤트를 확인할 것인가?

권장 순서는 다음과 같다.

  1. 대상 사용자를 좁힌다. 예: 첫 workspace를 만든 admin, 유료 plan의 admin, enterprise SSO 사용자.
  2. 현재 흐름의 이탈 지점을 찾는다. 예: modal open 후 email 입력 전, submit 후 error, invite sent 후 accepted 전.
  3. 핵심 행동을 정한다. 예: invite_accepted를 activation proxy로 둔다.
  4. 상태와 실패 케이스를 적는다. 예: permission denied, seat limit, expired token, duplicate email.
  5. 이벤트와 속성을 정한다. 예: invite_created에 workspace_id, role, seat_limit_state, source를 붙인다. 단, 개인정보는 넣지 않는다.
  6. 출시 후 판단 기준을 정한다. 예: invite accepted rate 증가, support ticket 감소, error rate 악화 없음.

7. PE용 UX Flow 템플릿

섹션 제목: “7. PE용 UX Flow 템플릿”

새 기능을 만들 때 다음 블록을 이슈나 RFC에 붙이면 충분한 출발점이 된다.

## Problem


- Who:
- Current friction:
- Desired behavior:
- Non-goals:


## UX Flow


1. Entry point:
2. Main path:
3. Empty state:
4. Error states:
5. Success state:


## Product State


- Domain objects:
- Permissions:
- Billing/entitlement impact:
- Idempotency or concurrency concerns:


## Measurement


- Activation/conversion event:
- Supporting events:
- Guardrail metrics:
- Privacy constraints:

이 템플릿의 목적은 문서를 늘리는 것이 아니다. 제품 문제, UX, 서버 상태, 이벤트를 같은 회의에서 함께 보게 만드는 것이다.

8. 흔한 실패 패턴

섹션 제목: “8. 흔한 실패 패턴”

Discovery 없이 구현할 때 생기는 실패

요구사항 복붙

기능 목록은 구현했지만 사용자가 왜 이 흐름을 거쳐야 하는지 설명하지 못한다.

대응: 문제 문장과 desired behavior를 먼저 쓴다.

Happy path 중심 UX

성공 상태만 디자인하고 empty/error/retry/permission 상태가 나중에 붙는다.

대응: UX Flow에 실패 복구를 필수 항목으로 둔다.

늦은 이벤트 설계

출시 직전에 클릭 이벤트만 붙여 funnel과 cohort 분석이 불가능해진다.

대응: UX Flow 단계마다 시작, 실패, 완료 이벤트를 먼저 둔다.

역할 경계 착각

기획과 디자인을 모두 혼자 결정해야 한다고 생각해 협업 신호를 놓친다.

대응: PE는 결정 독점자가 아니라 문제-UX-코드-데이터 번역자라고 본다.

9. 실무 체크리스트

섹션 제목: “9. 실무 체크리스트”

Product Discovery & UX Flow 구현 전 체크

  • 사용자 문제를 한 문장으로 설명할 수 있다
  • 대상 사용자 segment와 제외할 segment를 구분했다
  • 사용자의 첫 성공 경험을 activation event 후보로 정의했다
  • UX Flow에 entry, empty, error, success 상태가 포함되어 있다
  • 서버 도메인 상태와 권한, 결제 영향이 흐름에 반영되어 있다
  • 핵심 이벤트와 속성이 tracking plan 초안으로 정리되어 있다
  • PII나 동의가 필요한 데이터가 이벤트에 들어가지 않는지 확인했다
  • 출시 후 의사결정 기준과 guardrail metric을 정했다

10. 다음 문서로 이어지는 연결

섹션 제목: “10. 다음 문서로 이어지는 연결”

이 문서가 “무엇을 만들고 어떤 흐름이어야 하는가”를 다룬다면, 다음 문서들은 그 흐름을 어떻게 측정하고 검증할지를 다룬다.

  • Product Analytics & Tracking Plan: UX Flow의 각 단계를 event taxonomy와 tracking plan으로 바꾼다.
  • Funnel, Cohort & Retention Metrics: 흐름의 이탈과 재방문을 분석한다.
  • Experimentation & Feature Flags: 흐름 변경을 실험하고 안전하게 출시한다.
  • Product Domain Modeling: UX Flow 뒤의 account, workspace, membership, entitlement 상태를 모델링한다.

추가 학습 키워드

섹션 제목: “추가 학습 키워드”
  • Product discovery
  • Problem statement
  • User journey
  • UX flow
  • Activation event
  • Empty state
  • Error recovery
  • Guardrail metric
  • Tracking plan

참고 소스

섹션 제목: “참고 소스”