7장. 프로덕트 와이어프레임과 목업

말로 설명하던 기능을, 모두가 같은 화면으로 보기

PM의 머릿속에는 늘 화면이 있습니다. 문제는 그 화면이 본인 머릿속에만 있다는 점입니다. 회의실에서는 "여기서 사용자가 설정을 바꾸고", "그다음 확인 모달이 뜨고", "마지막에 성공 상태가 보여요"라고 설명합니다. 듣는 사람은 고개를 끄덕이지만, 각자 떠올린 화면은 조금씩 다릅니다. 엔지니어는 구현 순서를 떠올리고, 디자이너는 레이아웃을 상상하고, 영업팀은 데모 장면을 생각합니다. 모두 이해한 것 같지만, 사실은 조금씩 다른 제품을 보고 있는 셈입니다.

Claude Design이 PM에게 주는 가장 큰 변화는 바로 이 지점입니다. Anthropic은 공식 소개에서 PM이 기능 흐름을 와이어프레임과 목업으로 빠르게 그려 공유하고, 이후 Claude Code나 디자이너에게 자연스럽게 넘길 수 있다고 설명합니다.¹ 즉, PRD가 더 이상 문장으로만 머무르지 않습니다. 팀이 함께 볼 수 있는 화면이 됩니다.

이 장에서는 PM이 Claude Design으로 기능 아이디어를 어떻게 와이어프레임으로 풀고, 그것을 언제 목업으로 끌어올리며, 어디까지 만들면 충분한지 알아보겠습니다. 핵심은 예쁜 화면을 만드는 것이 아닙니다. 팀이 더 빨리, 더 정확하게 같은 결정을 내리도록 돕는 것입니다.

와이어프레임과 목업은 무엇이 다른가

먼저 용어부터 가볍게 정리해봅시다. 와이어프레임은 구조를 보는 그림입니다. 어떤 정보가 어디에 있고, 사용자가 어떤 순서로 움직이며, 어떤 버튼을 눌렀을 때 다음 단계로 넘어가는지를 보여줍니다. 색상이나 세련된 시각 스타일은 중요하지 않습니다. 뼈대를 보는 단계라고 생각하면 쉽습니다.

반면 목업은 훨씬 더 실제 제품처럼 보이는 시안입니다. 색상, 타이포그래피, 카드 모양, 버튼 스타일, 브랜드 느낌이 들어갑니다. 팀이 "이 기능이 어떤 인상을 주는지"까지 판단할 수 있게 해주는 단계입니다.

Claude Design에서는 이 차이를 꽤 실용적으로 다룰 수 있습니다. 프로토타입을 만들 때 거친 와이어프레임 스타일로 시작할 수도 있고, 더 다듬어진 하이파이 스타일로 시작할 수도 있습니다. 게다가 결과물이 단순 스크린샷이 아니라 편집 가능한 HTML 기반 산출물이라는 점이 중요합니다.³ 즉, PM이 빠르게 구조를 보고 고친 뒤, 필요한 경우 그 상태를 목업 수준까지 끌어올릴 수 있습니다.

실무에서는 보통 이렇게 생각하면 편합니다. 아직 문제 정의와 흐름이 흔들리고 있다면 와이어프레임으로 갑니다. 반대로 기능 구조는 어느 정도 맞고, 이제 이해관계자 설득이나 사용자 반응 확인이 필요하다면 목업으로 넘어갑니다.

PM이 화면을 만들 때 먼저 정리해야 할 세 가지

Claude Design에 프롬프트를 던지기 전에, PM은 디자이너처럼 미적 결정을 내릴 필요가 없습니다. 대신 제품 책임자답게 세 가지를 또렷하게 정리해야 합니다.

첫째는 사용자입니다. 누가 이 기능을 쓰는지 흐리면 화면도 흐려집니다. "관리자", "팀 리드", "처음 가입한 신규 사용자"처럼 실제 사용자를 분명히 잡아야 합니다.

둘째는 진입점입니다. 사용자가 어디서 이 기능에 들어오는지 정해야 합니다. 대시보드의 배너에서 시작하는지, 설정 페이지의 탭에서 시작하는지, 이메일 링크를 눌러 들어오는지에 따라 첫 화면이 달라집니다.

셋째는 성공 상태입니다. 이 기능이 끝났을 때 사용자는 무엇을 얻게 되는가를 정해야 합니다. 설정이 저장되는지, 승인 요청이 제출되는지, 첫 리포트가 생성되는지 말입니다. 시작점과 끝점이 정해지면 중간 화면은 훨씬 쉽게 채워집니다.⁴

이 세 가지가 빠진 프롬프트는 대체로 그럴듯하지만 공허한 화면을 만듭니다. 반대로 이 세 가지가 분명하면, 생각보다 놀랄 만큼 실무적인 초안이 나옵니다.

가장 실용적인 시작법: 한 기능을 네 장면으로 자르기

PM에게 가장 추천하는 방식은 기능을 거대한 덩어리로 설명하지 않고, 네 장면으로 자르는 것입니다. 공식 UX 가이드도 Claude Design이 개별 화면뿐 아니라 전체 사용자 흐름을 문맥 속에서 프로토타이핑하는 데 강하다고 설명합니다.²

네 장면은 보통 다음 순서면 충분합니다.

• 진입 화면: 사용자가 기능을 시작하기 직전 무엇을 보고 있는가

• 설정 화면: 무엇을 입력하거나 선택하는가

• 검토 화면: 제출 전에 무엇을 확인하고 수정할 수 있는가

• 성공 화면: 완료 후 다음 행동은 무엇인가

이 구조가 좋은 이유는 단순합니다. 팀이 가장 많이 궁금해하는 질문이 여기에 다 들어 있기 때문입니다. "어디서 시작하지?", "무엇을 넣지?", "실수하면 되돌릴 수 있나?", "끝나고 나면 뭐가 달라지지?"

예를 들어 PM이 "승인 워크플로"를 만들고 싶다고 해봅시다. 막연하게 "승인 UI를 만들어줘"라고 하면 보통 예쁜 테이블 하나가 나옵니다. 하지만 네 장면으로 자르면 훨씬 구체적이 됩니다. 대기 중인 요청 목록, 요청 상세와 코멘트 입력, 승인 전 최종 확인, 승인 완료 후 다음 작업 제안. 이 정도만 정리해도 팀은 갑자기 같은 영화를 보기 시작합니다.

첫 번째 초안은 '예쁘게'가 아니라 '결정 가능하게'

PM이 AI 디자인 도구를 쓸 때 가장 흔한 실수는 첫 결과물부터 완성본처럼 만들려는 것입니다. 하지만 첫 초안의 목적은 감탄이 아니라 판단입니다.

그래서 처음에는 와이어프레임 톤으로 요청하는 편이 좋습니다. 예를 들어 이렇게 말할 수 있습니다.

"우리 SaaS의 신규 알림 센터 기능을 데스크톱 기준 4개 화면의 와이어프레임으로 만들어줘. 사용자는 팀 관리자이고, 대시보드 우측 상단 종 아이콘에서 진입해. 화면은 1) 알림 목록 진입 상태 2) 필터 및 우선순위 설정 3) 개별 알림 상세 확인 4) 처리 완료 후 빈 상태 순서로 구성해줘. 구조와 정보 우선순위가 잘 보이게 하고, 장식은 최소화해줘."

이 프롬프트의 장점은 화려한 수식이 없다는 점입니다. 대신 사용자, 진입점, 화면 수, 각 화면의 역할이 분명합니다. GitHub의 Claude Design PM 툴킷도 기능 흐름용 프롬프트에서 제품, 사용자, 기능 설명, 진입점, 종료점, 그리고 화면별 요구사항을 구체적으로 적을수록 결과가 좋아진다고 권합니다.⁴

첫 초안이 나오면, 그다음 질문은 늘 같습니다. "이 흐름으로 정말 결정할 수 있는가?" 버튼 색은 나중 문제입니다. 지금 필요한 것은 빠진 상태가 없는지, 정보 순서가 맞는지, 사용자가 헤매지 않는지입니다.

구조 수정은 채팅으로, 작은 수정은 화면 위에서

Claude Design의 편집 방식은 PM에게 꽤 잘 맞습니다. 구조를 바꾸는 큰 수정은 채팅으로 하고, 특정 요소만 손보는 작은 수정은 캔버스 위에서 처리하면 됩니다. Anthropic은 대화, 인라인 코멘트, 직접 편집, 커스텀 슬라이더를 함께 쓰는 방식을 기본 흐름으로 제시합니다.¹

이 원칙을 익히면 수정 속도가 확 달라집니다.

전체 흐름을 바꾸고 싶을 때는 채팅이 낫습니다. 예를 들면 "2단계와 3단계를 합쳐서 한 화면으로 줄여줘", "성공 화면 전에 확인 모달을 하나 추가해줘" 같은 요청입니다.

반대로 특정 문구, 카드, 버튼처럼 한 요소만 고치고 싶다면 인라인 코멘트나 직접 편집이 더 빠릅니다. "이 경고 문구를 더 짧게", "이 CTA를 보조 버튼으로", "이 카드 간격을 조금 좁게" 같은 요청은 화면 위에서 바로 손보는 쪽이 덜 번거롭습니다.²³

재미있는 점은, PM이 꼭 디자인 용어를 몰라도 된다는 것입니다. "이 부분이 너무 무겁다", "여기서 시선이 갈라진다", "이 버튼이 주인공 같지 않다"처럼 비교적 일상적인 표현도 꽤 잘 통합니다. 중요한 것은 정확한 픽셀 값보다 의사결정의 방향입니다.

좋은 PM은 상태를 빼먹지 않는다

많은 기능 시안이 멋져 보여도 실무에서 바로 무너지는 이유는, 행복한 경로만 있기 때문입니다. 사용자는 늘 매끈하게 성공하지 않습니다. 빈 상태, 로딩 상태, 에러 상태, 권한 부족 상태 같은 현실이 반드시 들어옵니다.

PM이 와이어프레임 단계에서 꼭 챙겨야 할 상태는 보통 네 가지입니다.

• 빈 상태: 아직 데이터가 없을 때 무엇을 보여줄 것인가

• 로딩 상태: 기다리는 동안 사용자는 무엇을 이해해야 하는가

• 에러 상태: 실패했을 때 어디서 다시 시도하는가

• 성공 상태: 완료 후 다음 행동은 무엇인가

이 네 가지를 초기에 넣어두면 엔지니어와 디자이너가 나중에 "아, 이 경우를 안 그렸네" 하며 다시 돌아오는 일을 크게 줄일 수 있습니다. Claude Design의 공식 UX 가이드는 실제 핸드오프 전, 빈 상태와 에러 상태, 로딩 상태, 다양한 데이터 양에서의 동작까지 확인해보라고 조언합니다.²

PM다운 와이어프레임은 예쁜 흐름이 아니라, 제품이 실제로 굴러가는 흐름입니다.

리뷰용으로는 한 개보다 세 개가 낫다

회의에서 가장 위험한 문장은 "일단 하나 만들어봤어요"입니다. 하나만 있으면 사람들은 그것을 평가하는 척하면서 사실상 고르기 어렵습니다. 반대로 두세 개 방향이 있으면 비교가 시작됩니다. 비교가 시작되면 토론이 추상에서 구체로 내려옵니다.

Claude Design의 제품 워크플로 자료도 이해관계자 정렬을 위해 2~3개의 대안을 나란히 만들어 보는 방식을 추천합니다.² PM에게 이 방법이 특히 좋은 이유는, 취향 논쟁을 구조 논의로 바꿔주기 때문입니다.

예를 들어 사용자 프로필 페이지를 만든다고 해봅시다. 카드형 레이아웃, 좌측 사이드바형, 상단 탭형 세 가지를 빠르게 뽑아놓으면 팀은 "예뻐 보이는 쪽"보다 "우리 사용자에게 어떤 구조가 더 빨리 이해되는가"를 이야기하게 됩니다.

이때 프롬프트는 이렇게 바꿔보면 좋습니다. "같은 기능 흐름을 유지하되, 레이아웃 방향이 다른 세 가지 와이어프레임을 보여줘. 하나는 사이드바 중심, 하나는 단계형 위저드, 하나는 한 화면 요약형으로."

좋은 PM은 답을 혼자 정하는 사람이 아니라, 비교 가능한 선택지를 만들어 팀의 판단 비용을 줄여주는 사람입니다.

언제 와이어프레임에서 목업으로 넘어갈까

와이어프레임이 끝났다고 바로 목업으로 가야 하는 것은 아닙니다. 목업은 설득력이 강한 만큼, 잘못된 확신도 함께 키울 수 있습니다. 구조가 틀린 상태에서 예쁘게 만들면, 사람들은 구조보다 겉모습을 먼저 칭찬하기 때문입니다.

그래서 보통 다음 질문에 "예"라고 답할 수 있을 때 목업으로 넘어가면 좋습니다.

• 사용자의 시작점과 종료점이 분명한가

• 화면 순서가 팀에게 납득되는가

• 빠진 상태가 없는가

• 구현 난이도에 대한 큰 오해가 없는가

이 단계가 지나면 비로소 목업의 차례입니다. 여기서 6장에서 다룬 디자인 시스템 연결이 빛을 발합니다. 코드베이스와 디자인 파일이 연결돼 있다면, Claude Design은 실제 팀의 컴포넌트와 스타일 패턴을 반영한 더 현실적인 시안을 만들 수 있습니다.² 같은 흐름이라도 브랜드 컬러와 실제 버튼, 카드, 모달 스타일이 들어가면 이해관계자의 반응이 달라집니다. 갑자기 "아이디어"가 아니라 "곧 나올 기능"처럼 보이기 때문입니다.

다만 기억할 점이 있습니다. 목업은 약속서가 아니라 대화 도구입니다. 너무 빨리 확정본 취급을 하지 않는 것이 좋습니다.

PM을 위한 추천 프롬프트 구조

막상 시작하려면 어떤 식으로 써야 할지 막막할 수 있습니다. 그럴 때는 아래 흐름대로 쓰면 안정적입니다.

먼저 제품과 사용자를 한 문장으로 정의합니다. 그다음 기능이 실제로 무슨 일을 하는지 적습니다. 이어서 진입점과 성공 상태를 씁니다. 마지막으로 화면별 역할을 짧게 나눕니다.

예시는 이렇습니다.

"우리 제품은 원격 팀을 위한 프로젝트 관리 SaaS야. 사용자는 팀 리드이고, 새 기능은 작업 승인 요청을 한곳에서 검토하고 처리하는 승인 센터야. 사용자는 사이드바의 'Approvals' 메뉴에서 진입하고, 성공 상태는 요청을 승인하거나 반려한 뒤 다음 대기 항목으로 자연스럽게 이동하는 거야. 이 기능을 데스크톱 기준 4개 화면 와이어프레임으로 만들어줘. 1) 대기 요청 목록 2) 요청 상세와 코멘트 입력 3) 승인 전 확인 4) 처리 완료 및 다음 액션. 정보 구조가 분명해야 하고, 로딩·빈 상태·에러 상태도 함께 고려해줘. 먼저 구조 중심으로 만들고, 장식은 최소화해줘."

이 정도면 충분히 강력합니다. 좋은 프롬프트는 시인처럼 쓰는 것이 아니라 기획자처럼 쓰는 것이 포인트입니다.

어디까지 만들면 충분한가

PM이 만든 와이어프레임과 목업의 목표는 디자이너를 완전히 대체하는 것이 아닙니다. 더 빠르게 논의하고, 더 적게 오해하고, 더 일찍 검증하는 것입니다. 여기까지 오면 충분하다는 기준을 가져야 합니다.

팀 리뷰에서 기능 흐름이 설명 없이도 이해되고, 엔지니어가 대략적인 구현 범위를 판단할 수 있으며, 디자이너가 "좋아, 이제 이걸 발전시키면 되겠네"라고 말할 수 있다면 이미 성공입니다. 그다음부터는 정교화의 영역입니다.

Anthropic이 Claude Design을 설명할 때 반복해서 강조하는 것도 비슷합니다. PM은 기능 흐름을 빠르게 시각화하고, 그 결과물을 팀과 공유하거나 다음 단계로 넘길 수 있습니다.¹ 다시 말해, Claude Design이 PM에게 주는 진짜 힘은 미적 완성도가 아니라 전달력입니다.

회의실 화이트보드에 네모 네 개를 그리며 설명하던 시간이, 이제는 팀이 함께 클릭해보는 화면으로 바뀝니다. 말뿐이던 기능 아이디어가 비로소 제품의 얼굴을 갖게 되는 순간입니다.

참고

¹Introducing Claude Design by Anthropic Labs

²Using Claude Design for prototypes and UX | Claude

³Claude Design Tutorial: Generate Decks, Wireframes & Prototypes

⁴claude-design-pm-toolkit/03_feature_flow.md at main · aakashg/claude-design-pm-toolkit · GitHub