1장. 목표와 원칙
설계하며 설명한다
패러다임의 역전: 보이는 것부터 시작하기
이 장의 핵심은 단 한 문장으로 요약된다. 설계하며 설명한다.
말로 길게 설명한 뒤 설계를 시작하는 것이 아니라, 설계 과정 자체가 설명이 되게 한다는 뜻이다. 이 원칙은 기획의 리듬, 산출물의 형식, 회의 운영, 심지어 팀 언어까지 바꾼다. 문장보다 화면, 문서보다 인터랙션, 주장보다 데모. 프로토타입 중심 기획의 출발점이다.
전통적인 기획 프로세스는 텍스트로 시작한다. 요구사항 정의서를 작성하고, 기능 명세를 나열하고, 화면 설계서를 그린다. 순서가 명확해 보이지만 실제로는 비효율적이다. 텍스트로 설명한 내용이 화면으로 구현되면 전혀 다른 모습이 되는 경우가 빈번하다. "상품 목록을 그리드 형태로 배치한다"는 문장은 수십 가지 방식으로 해석될 수 있다. 열 개수는? 카드 크기는? 정렬 옵션 위치는? 페이지네이션 방식은?
"설계하며 설명한다"는 이 순서를 뒤집는다. 먼저 화면을 만들고, 그 안에 설명을 넣는다. Figma Community에서 템플릿을 가져와 v0로 수정하면 몇 분 안에 실제 화면이 만들어진다. 이 화면을 보며 "여기에 정렬 옵션이 필요하다", "카드에 할인율을 표시해야 한다"고 구체적으로 논의할 수 있다. 추상적인 개념이 아닌 구체적인 화면을 기반으로 대화가 진행된다.
왜 "설계하며 설명한다"인가
이 접근법이 가져오는 네 가지 핵심 가치가 있다.
첫째, 오해의 비용을 줄인다. 텍스트 설계서는 읽는 사람마다 머릿속 화면이 다르다. 클릭, 전환, 빈 상태를 화면으로 보기만 해도 불필요한 토론이 절반으로 줄어든다. 모든 이해관계자가 동일한 화면을 보고 있다는 확신이 있다. 개발자는 구현해야 할 레이아웃을 정확히 알고, 디자이너는 스타일 가이드를 명확히 이해하며, 경영진은 최종 결과물을 미리 볼 수 있다.
둘째, 결정의 속도를 높인다. "여기서 버튼을 누르면 이렇게 바뀝니다"라는 30초 데모는 30분 논쟁을 대체한다. 프로토타입은 자연스럽게 논의를 구체화한다. "사용성을 개선해야 한다"는 막연한 목표보다 "결제 단계를 5개에서 3개로 줄인다"는 구체적 목표가 실행력이 있다.
셋째, 바로 검증 가능하다. 사용 시나리오를 프로토타입으로 돌려보면, 해피패스와 엣지케이스가 즉시 드러난다. "사용자는 이렇게 행동할 것이다"는 가정을 프로토타입으로 만들어 테스트한다. 실제 사용자에게 보여주고 클릭하게 하면 가정이 맞는지 바로 확인할 수 있다.
넷째, 변경에 강하다. 텍스트를 다시 쓰는 대신, 상태와 컴포넌트를 바꿔 재연결하면 된다. Figma의 버전 히스토리가 자동으로 모든 변경사항을 기록하기 때문에 과감하게 수정할 수 있다. 마음에 들지 않으면 언제든 이전 버전으로 돌아갈 수 있다.
장의 목표(Outcome)
이 장에서 달성하고자 하는 네 가지 구체적 목표:
합의 가능한 설계 단위를 정의한다. 페이지, 상태, 뷰포트, 플로우라는 네 가지 기준으로 산출물을 체계화한다.
회의 대신 데모가 기본이 되도록, 리뷰 리듬과 로그 방식을 정한다. 데일리 10분, 주간 30분의 리듬을 확립한다.
문서화의 최소 단위(NOTE 주석)를 표준화한다. 기능, 상태, 데이터, 이벤트 네 가지 유형으로 체계화한다.
변경을 두려워하지 않는 버전 체계를 정한다. CHANGE LOG를 통해 모든 결정을 추적 가능하게 만든다.
핵심 원칙 7
실무에서 지켜야 할 일곱 가지 원칙 제안:
원칙 1) 화면이 우선, 문장은 보조 설명이 길어진다면 화면이 부족하다는 신호다. 직관적인 UI는 긴 설명이 필요 없다. 문장은 화면 옆 NOTE 주석으로 최소·결정적 문장만 남긴다.
원칙 2) 상태 4종은 기본 모든 주요 컴포넌트와 화면은 Idle/Loading/Empty/Error를 갖춘다. "빈 데이터일 때 무엇을 제안할 것인가?"를 먼저 결정하면 UX 품질이 달라진다. 빈 상태는 온보딩 기회다. 그냥 "없음"이 아니라 "다음 행동"을 제시해야 한다.
원칙 3) 반응형 최소 2뷰 모바일·데스크탑 두 뷰는 필수. 같은 정보라도 우선순위와 배치가 달라진다. 모바일에서 필터·정렬·내비는 접힘(Accordion/Drawer) 기본을 의식한다.
원칙 4) 라벨 길이 규율 한국어 버튼/라벨은 10자 이내, 테이블 칼럼은 최소폭 160px, 2줄 허용 시 줄바꿈 테스트를 한다. 플레이스홀더는 예시가 아닌 지시문으로 쓴다. (예: "주문 번호를 입력하세요")
원칙 5) 데이터는 실제처럼 더미 데이터라도 경곗값(아주 길거나, 비어 있거나, 특수문자 포함)을 넣는다. 긴 카테고리명, 숫자 12자리, 이모지 포함 등 경곗값으로 깨짐을 먼저 확인한다. 필수/선택, 포맷(YYYY-MM-DD, 010-0000-0000) 등 검증 규칙을 NOTE에 함께 적는다.
원칙 6) 결정은 로그로 남긴다 데모 후 나온 합의는 프레임 상단 CHANGE LOG에 "날짜/결정/근거/작성자" 4열로 남긴다. 다음 사람이 읽어도 맥락이 복원되어야 한다. "왜 원스텝 체크아웃 대신 멀티스텝을 선택했는가", "필터를 왼쪽에 배치한 이유는 무엇인가" 같은 결정의 근거를 명확히 기록한다.
원칙 7) 짧게, 자주 완벽보다 신속이 우선이다. 80% 완성도의 프로토타입을 오늘 보여주는 것이 100% 완성도를 다음 주에 보여주는 것보다 낫다. 데일리 10분으로 변경 하이라이트를 공유하고, 주간 30분으로 핵심 플로우를 실연한다.
합의 가능한 설계 단위 정의
프로토타입 중심 기획의 최소 단위는 "페이지 × 상태 × 뷰포트 × 플로우"다.
페이지(Page): 홈, 카테고리, PDP, 장바구니, 결제 등 명명 가능한 화면
상태(State): Idle/Loading/Empty/Error + 권한(로그인 필요/권한 없음)
뷰포트(Viewport): 모바일(예: 390×844), 데스크톱(예: 1440×900) 기준 프레임
플로우(Flow): 사용자가 과업을 마칠 때까지의 경로. 해피패스와 예외분기를 포함
이 네 가지 조합으로 산출물을 묶으면, "무엇이 빠졌는가?"를 쉽게 점검할 수 있다. 예를 들어 "장바구니(모바일) Empty 상태가 있는가?"처럼 질문이 구체화된다.
NOTE 주석: 문서화의 새로운 정의
기존 문서화는 별도 작업이었다. 화면을 설계한 후 워드나 PPT를 열어 설명을 작성했다. 화면이 수정되면 문서도 수정해야 했지만, 대부분 누락되거나 지연됐다. 결과적으로 문서와 설계가 일치하지 않는 상황이 발생하고, 나중에 별도의 시간을 내서 문서 동기화 작업을 진행했다.
새로운 방식에서 문서화는 설계 안에 포함된다. Figma의 NOTE 컴포넌트(Figma 에서 제공하는 기능이 아닌 별도의 컴포넌트를 만드는 것이다. - 유료버전을 사용한다면 Annotation도 좋은 기능이다.)를 활용해 각 UI 요소에 직접 주석을 단다. NOTE는 화면 옆에 붙는 짧은 합의 문장이다. 네 가지 유형을 기본으로 둔다:
1. NOTE/기능설명: "누가 무엇을 왜 하도록 돕는가?"
예: "첫 구매자가 할인 혜택을 쉽게 이해하고 바로 담도록 돕는 요약 섹션"
2. NOTE/상태: 빈/오류/권한 상황과 행동
예: "Empty: 조건=장바구니 0건. 노출=온보딩 카드+'추천 상품' 4개. CTA='상품 보러가기'"
3. NOTE/데이터: 필드/타입/길이/검증 규칙
예: "전화번호: string, 하이픈 자동 삽입, 10~11자, 잘못된 형식 시 필드 하단 경고"
4. NOTE/이벤트: 클릭/전송/포커스의 결과
예: "바로구매: 결제 요약 오버레이 → 동의 체크 시 '주문 확인' 단계로 이동. 실패 시 오류 토스트 2초"
색상으로 중요도를 구분하는 규칙도 정한다. 빨간색은 필수 구현 사항, 노란색은 주의 필요 항목, 파란색은 참고 정보, 회색은 선택 사항이다. 개발자는 빨간색 NOTE부터 확인하고, PM은 노란색 NOTE에 집중한다.
원칙: NOTE는 짧고 단단해야 한다. 논문처럼 길게 쓰지 않는다. "보기 좋다/분위기가 맞다" 같은 추상 표현은 배제한다.
도구 체인의 유기적 연결
GPT, v0, Figma는 각각 독립적인 도구지만, 이 방법론에서는 하나의 워크플로우로 연결된다.
GPT 활용은 구조화된 프롬프트로 시작한다. "온라인 쇼핑몰의 장바구니 기능에 필요한 유스케이스를 10개 도출해 줘"라고 요청하면, GPT는 체계적인 목록을 생성한다. 이를 다시 "각 유스케이스별 수용 기준을 Given-When-Then 형식으로 작성해 줘"로 구체화한다.
v0는 자연어를 UI로 변환하는 다리 역할을 한다. "상품 카드 그리드, 4열, 이미지 상단, 제목과 가격 하단, 호버 시 장바구니 버튼 표시"라고 입력하면 즉시 React 컴포넌트가 생성된다. v0를 쓸 때마다 "상태 4종 필수, 모바일·데스크톱 2뷰, 한국어 라벨 10자"를 반복 지시한다.
Figma는 최종 정제와 문서화 공간이다. v0에서 생성한 화면을 가져와 디자인 시스템에 맞게 조정한다. Variants 기능으로 다양한 상태를 한 번에 표현하고, Auto Layout으로 반응형 동작을 정의한다.
리뷰·데모 운영법
데일리 10분 (권장 어젠다)
어제와 달라진 프레임 1~2개를 실행으로 보여준다
열린 질문 1~2개만 던진다 (예: "정렬 기본값을 인기순으로 바꿀까요?")
합의된 결정은 바로 CHANGE LOG에 기록한다
주간 30분 (권장 구성)
10분: 핵심 플로우 데모(FO 1개, BO 1개)
10분: 리스크·엣지케이스 점검(권한, 빈 상태, 긴 라벨)
10분: 다음 주 범위 확정(MoSCoW 라이트)
하지 말아야 할 것
프로토타입을 정지 화면으로만 보여주기
"추후 정리"라는 메모 남기기 (지연은 곧 오해)
결정 없이 의견만 수집하고 끝내기
버전·변경 이력 운영
버전 태깅: v0.1, v0.2처럼 모든 산출물(프로토타입 링크/NOTE/요약 프레임)에 동일 버전 명시
CHANGE LOG 프레임: 날짜/결정/근거/작성자. 최근 5개는 상단, 나머지는 99_Archive로 이동
스냅샷: 주요 화면 묶음은 주간 단위로 PDF 10~15p 추출(의사결정자용 - Figma에서 바로 PDF로 추출 가능하다.)
리버전 룰: 중요한 결정이 뒤집히면 CHANGE LOG에 이전 근거 vs 새 근거를 나란히 기록
안티패턴과 극복 방안
안티패턴 1: "텍스트로 다 써놓고 Figma는 나중에" → "먼저 화면으로 보여주고, 필요한 문장만 NOTE로 붙인다"
안티패턴 2: "예쁜데 쓰기 어렵다" → "라벨 길이·반응형·상태 4종을 통과한 뒤 미감을 올린다"
안티패턴 3: "회의는 길고 결정은 없다" → "데모 1개 + 결정 1~3개 + CHANGE LOG 기록이 없는 회의는 실패"
안티패턴 4: "플레이스홀더가 예시문" → "플레이스홀더는 지시문 (예: '도로명 주소 입력')"
안티패턴 5: "상태·권한 정의 없음" → "모든 리스트·폼은 Idle/Loading/Empty/Error + 권한 상태를 갖는다"
팀 합의 지표와 성과 측정
정량적 개선 지표
합의 리드타임: 요구 제기 → 결정까지 평균 소요일 (목표: 1일)
: 결정이 늦어진다는 의미는 문서로만은 전체 그림이 그려지지 않기 때문이다.
되돌림 비율: 리뷰 후 동일 항목 재결정 비율 (목표: 10%)
: 재결정이 많아진다는 의미는 문서에서 실제 화면으로 이동했을 때 인식 차이가 클 때이다.
상태 커버리지: 핵심 화면의 4상태 구현율 (목표: 100%)
문서 작성 시간: 별도 문서 작업 시간 (목표: 70% 감소)
: 별도의 동기화 시간을 갖지 않는다.
개발 문의: 개발팀의 기획 관련 질문 수 (목표: 60% 감소)
: 문서일 때는 페이지와 항목 하나하나 질문이 필요하지만, 프로토타입은 질문보다는 의견이 많을 수 있다.
정성적 변화
팀의 사기 향상: 만들고 있는 것을 눈으로 볼 수 있다는 강력한 동기부여
이해관계자 신뢰도 증가: 진행 상황을 투명하게 볼 수 있음
커뮤니케이션 품질 개선: 추상적 논의에서 구체적 논의로 전환
예상되는 저항에 대한 대응
"프로토타입은 개발이 아니다"는 비판이 있을 수 있다. 맞다. 하지만 프로토타입의 목적은 개발 대체가 아니라 커뮤니케이션 개선이다.
"문서가 없으면 인수인계가 어렵다"는 우려도 있다. 하지만 Figma 파일 자체가 살아있는 문서다. NOTE와 CHANGE LOG를 함께 보면 기존 문서보다 이해하기 쉽다.
"경영진은 여전히 PPT를 원한다"는 현실적 문제도 있다. 프로토타입 캡처와 핵심 메시지만 담은 간략한 PPT를 만든다. 주요 화면 캡처, 핵심 기능 리스트, 일정 계획이 포함된 10-15페이지 요약본을 제공한다.
"디자이너와 역할이 겹친다"는 갈등도 발생할 수 있다. 기획자가 만드는 것은 기능 프로토타입이고, 디자이너가 만드는 것은 비주얼 목업이다. 오히려 기획자의 프로토타입이 디자이너의 작업을 명확하게 만든다.
"설계하며 설명한다"를 지탱하는 습관들
규칙을 프롬프트에 박는다: v0를 쓸 때마다 핵심 원칙을 반복 지시
라벨 테스트를 먼저 한다: 경곗값으로 깨짐을 먼저 확인
초안은 틀려도 된다: 초안의 목적은 빠른 합의. 완벽함은 2-3회 차에서
빈 상태는 온보딩 기회다: "없음"이 아니라 "다음 행동" 제시
권한은 초기에 판정한다: 로그인 필요/권한 없음 화면을 기본 포함
결론
이제부터 설계하며 설명한다.
설명은 화면 옆 NOTE로 간결하게 남긴다
모든 주요 화면은 상태 4종과 2뷰를 갖춘다
회의는 데모로 시작해 결정으로 끝낸다
변경은 CHANGE LOG에 기록해 다음 사람에게 빚을 남기지 않는다
"설계하며 설명한다"는 단순한 방법론이 아니라 사고방식의 전환이다. 추상에서 구체로, 텍스트에서 비주얼로, 순차에서 반복으로. 이 전환을 받아들이면 기획은 더 이상 지루한 문서 작업이 아니라 창의적인 설계 활동이 된다. 문서 더미 속에서 길을 잃는 대신, 실제 화면을 보며 함께 만들어가는 것이 다음 시대 기획의 모습일 것이다.
