이 단계에서 하는 것: 프로덕트 디자이너 서브에이전트를 설정하고, 앞에서 작성한 PRD와 회사 디자인 시스템을 바탕으로 화면기획서(
docs/화면기획서.md)를 만든다. 이어서 클릭하며 화면 이동을 확인할 수 있는 프로토타입을 만든다. 다음 단계로 넘길 것: 화면 목록·요소·상태·이동 흐름과 디자인 시스템 토큰을 정리한 화면기획서. 프로토타입은 화면 흐름을 확인하는 데 사용한다.
PRD에 만들 기능을 정리했다면, 이제 기능을 어떤 화면으로 보여줄지 설계한다. 이번 단계에서는 AI를 프로덕트 디자이너 서브에이전트로 설정한다. 색상과 간격은 임의로 정하지 않고 docs/가이드/디자인시스템.pdf에 정의된 토큰을 사용한다. 다음 단계에서도 같은 화면기획서와 디자인 시스템을 기준으로 구현한다.
디자인 시스템이 미리 준비된 이유: 여러 제품에서 색상·간격·컴포넌트 규칙을 공통으로 쓰기 위해서다. 킥오프 회의록에서 오대표가 "우리 디자인 시스템 그대로"라고 한 것도 이 규칙을 따르라는 뜻이다. 프로덕트 디자이너는 디자인 시스템의 토큰과 컴포넌트를 사용해 머니노트의 화면을 설계하고 화면기획서에 기록한다.
회사에 디자인 시스템이 없다면 디자이너가 화면을 설계하면서 필요한 토큰도 함께 정의할 수 있다.
docs/PRD.md가 만들어졌고, 완료 기준이 적혀 있다.docs/가이드/디자인시스템.pdf가 프로젝트에 들어 있다(색·타이포·간격 토큰과 컴포넌트 규칙이 정의돼 있다).먼저 서브에이전트의 책임과 작업 기준을 정한 뒤, 화면기획서 작성을 요청한다.
① 정의 — 서브에이전트 생성
'프로덕트 디자이너' 서브에이전트를 만들어줘. docs/PRD.md와 docs/가이드/디자인시스템.pdf를 기준으로 화면기획서의 화면·요소·상태·이동 흐름을 설계하고 관리한다. 화면 흐름을 확인하는 HTML 프로토타입도 만든다. 프로토타입은 따로 요청할 때 만든다. 색상과 간격은 임의로 정하지 않고 디자인 시스템의 토큰 이름으로 지정한다."프로토타입도 만든다"가 들어 있는 이유: 이 한 줄이 없으면 AI가 역할 파일에 "화면기획서 외의 파일은 만들지 않는다"를 스스로 적고, 뒤 단계의 프로토타입 요청을 거절한다. 뒤의 "따로 요청할 때 만든다"가 없으면 반대로 화면기획서를 쓰는 길에 프로토타입까지 만들어 버린다. 역할의 범위는 정의할 때 다 적는다.
서브에이전트를 만든 뒤에는 Claude Code를 한 번 다시 띄운다(/exit 뒤 claude). 새로 만든 서브에이전트는 다음 세션부터 보인다. 다시 띄우지 않으면 범용 에이전트가 조용히 대신 일한다.
② 실행 — 화면기획서 만들기
프로덕트 디자이너 서브에이전트로 docs/PRD.md와 docs/가이드/디자인시스템.pdf를 바탕으로 화면기획서를 docs/화면기획서.md에 작성해줘.PRD에 없는 화면 결정은 네가 정하고 '디자이너 결정' 절에 이유와 함께 모아 적어. 질문은 PRD를 바꿔야 하는 것만 남겨.카드 정보 입력은 결제사 창이 받으니 그리지 않는다.결정을 디자이너에게 맡기는 이유: 화면을 몇 개로 쪼개는지, 저장 뒤 어디로 가는지, 삭제를 다시 묻는지는 PRD에 없다. 이걸 사람이 프롬프트에 다 적으면 화면기획을 사람이 하고 AI는 받아 적는 꼴이 된다. 디자이너가 먼저 정하게 하고, 사람은 다음 단계에서 그 결정 목록을 읽고 틀린 것만 고친다. "질문은 PRD를 바꿔야 하는 것만"이라고 못 박지 않으면 디자이너는 질문을 열 개 넘게 남기고 멈춘다.
이렇게 나오면 성공: docs/화면기획서.md에 화면 목록, 화면별 요소·상태, 이동 흐름, 그리고 '디자이너 결정' 절이 정리된다. 화면은 로그인·회원가입·거래 내역 목록·수입·지출 입력·월별 통계·프리미엄 결제 여섯 개 안팎으로 나온다. 하나가 합쳐지거나 갈려도 틀린 것이 아니다 — 다음 단계에서 사람이 판단한다. 월별 통계 화면에는 무료 사용자를 위한 결제 이동 버튼이 적혀 있다. 카드 정보 입력 화면은 결제사가 제공하므로 우리 화면기획서에 포함되지 않는다. 색상과 간격은 임의의 HEX·px 대신 디자인 시스템 문서의 토큰 이름(예: primary-600, income-600, expense-600, space-4)으로 적혀 있다. 코드에서는 이 이름이 bg-primary-600, p-4 같은 클래스가 된다 — 디자인 시스템 문서가 그렇게 1:1로 정해 두었다.
질문이 남는 것이 정상이다. 문서 끝에 "디자인 시스템 요청"(로딩 표시·비밀번호 입력·내비게이션 컴포넌트가 없다 등)이 여럿 남는다. 이건 디자인 시스템 담당 몫이라 여기서 답하지 않는다. PRD를 바꿔야 하는 질문(예: 남은 돈이 음수일 때 부호를 붙일지 — 디자인 시스템의 금액 규칙과 PRD가 어긋난다)이 남으면 개발 리더로서 한 줄로 답한다. 그 밖의 화면 결정을 질문으로 올렸으면 "그건 네가 정해서 디자이너 결정 절에 적어줘" 라고 한 번만 답한다.
문서를 열어 '디자이너 결정' 절부터 읽는다. 저장 뒤 어디로 가는지, 삭제를 다시 묻는지, AI 추천을 언제 요청하는지 같은 것이 이유와 함께 적혀 있다. 문서를 쓴 것은 AI지만 맞는지 판정하는 것은 사람이다. 동의하지 않는 결정만 고유명사로 한 줄 고친다 — 이를테면 디자이너가 삭제할 때 다시 묻기로 했는데 바로 지우게 하고 싶다면 "삭제할 때 다시 묻게 했는데, 묻지 말고 바로 지우는 걸로 바꿔줘"처럼. 동의한다면 보낼 것이 없다. 결정을 하나하나 다 뜯어고치면 화면기획을 사람이 하는 셈이다 — 뒤 단계에 영향을 주는 것(화면이 합쳐졌거나 범위 밖 화면이 생겼다, 월별 통계에 결제로 가는 버튼이 빠졌다)만 고친다.
이어서 상태가 빠지지 않았는지 확인한다.
docs/화면기획서.md를 열어서, 화면별로 빈 상태·로딩·에러가 모두 정의됐는지,그리고 로그인 후 목록 → 입력 → 통계로 이어지는 흐름으로 되어있는지 확인하고, 그렇지 않으면 그렇게 수정해.이렇게 나오면 성공: 각 화면에 빈 상태·로딩·에러가 빠짐없이 정의돼 있다.
화면기획서에서 이동 경로를 검토한 뒤에는 프로토타입을 직접 클릭하며 흐름을 확인한다. 브라우저에서 열 수 있는 프로토타입을 만들어 버튼이나 링크를 눌렀을 때 의도한 화면으로 이동하는지 살펴본다. 팀 회의에서도 이 결과물을 보며 화면 흐름을 논의할 수 있다.
프로덕트 디자이너 서브에이전트로, docs/화면기획서.md대로 눌러 볼 수 있는 프로토타입을prototype/ 폴더에 정적 HTML로 만들어줘.- 화면마다 파일 하나씩, 화면 흐름대로 링크로 연결. 빈 상태·에러 화면도 눌러 볼 수 있게.- 흐름만 눈으로 확인하고 버릴 거야. 프레임워크 없이 HTML/CSS로, 데이터는 가짜로, 최소한으로 빠르게. 반응형·애니메이션·세밀한 스타일은 하지 마.다 되면 어느 파일을 열면 되는지 알려줘.이렇게 나오면 성공: prototype/ 폴더에 화면별 HTML이 생기고, 첫 파일을 브라우저로 열면 링크를 눌러 화면 사이를 오갈 수 있다.
[사람 검증] 처음 사용하는 사람의 입장에서 프로토타입을 클릭해 본다. 로그인 화면 파일부터 연다. 로그인 → 목록 → 입력 → 다시 목록 → 통계 순서로 이동할 수 있는가? 수입은 녹색, 지출은 빨강으로 구분되는가? 거래가 없을 때 다음 행동을 안내하는가? 문제가 보이면 앱 코드를 작성하기 전에 화면기획서를 수정한다.
[주의] 이 프로토타입은 버리는 것이다. 실제 앱은 아키텍처를 정한 뒤 그 구조 위에 만든다. 프로토타입 코드를 그대로 가져다 쓰지 않는다.
[실무] 프로덕트 디자이너는 Figma에서 화면을 연결한 프로토타입을 만들어 사용자 테스트에 활용하기도 한다. 이 실습에서는 같은 목적으로 HTML 프로토타입을 만든다. Claude Code에 Figma의 Dev Mode MCP를 연결하면 완성된 디자인을 AI가 읽고 구현할 때 참고할 수 있다. 이 연결은 읽기 전용이므로 AI가 Figma 파일을 직접 수정하지는 않는다.
docs/화면기획서.md를 작성했다.docs/PRD.md나 디자인 시스템 문서가 안 보이면 이전 단계로 돌아가 파일을 확인한다.다음 단계에서는 솔루션 아키텍트 서브에이전트에게 기술 아키텍처 설계를 맡긴다.