엔지니어링이 명세를 필요로 할 때 /writing-명세s-designs는 브레드보드 스케치와 셰이핑 문서을 만들어 팀이 한 스프린트 안에 올바른 것을 build하게 합니다. — Claude Skill
Claude Code용 Claude 스킬 · 제공: Refound · 실행: /writing-specs-designs (Claude 내)·업데이트: 2026년 6월 14일
Shape Up breadboard, 셰이핑 문서, fat-marker sketch를 작성합니다
- Ryan Singer Shape Up 방식: 브레드보딩, 굵은 마커 스케치, 10개 이하 움직이는 부분, 숨은 복잡도와 하지 않을 것
- 낮은 fidelity 화이트보드 협업 패턴(Christina Wodtke): 일부러 못 그려서 수정을 초대합니다
- 프로토타입 우선 분류(Noah Weiss, Tamar Yehoshua): 정적 목업을 건너뛰고 코드로 가야 할 때를 정합니다
- 0-to-1 소비자 흐름을 위한 Nikita Bier의 pixel-level rigor: 모든 탭은 기적입니다
- Tom Conrad permanence audit: 영구 레거시가 될 임시 shortcut을 표시합니다
대상
기능
PRD는 산문 8페이지지만 다이어그램이 없습니다. /writing-명세s-designs는 이를 10개 이하 움직이는 부분, 이름 붙은 어포던스, 연결이 있는 Ryan Singer breadboard로 바꿔 팀이 한 번에 '벽 속 전기'를 보게 합니다.
디자이너가 Figma 탐색 6개를 만들었고 아무도 고르지 못합니다. /writing-명세s-designs는 Noah Weiss의 prototype-first 규칙을 적용해 코드로 느껴볼 가치가 있는 2개를 고르고 3일짜리 버리는 빌드를 정의합니다.
모바일 앱 v1을 출시 중이고 모든 탭이 중요합니다. /writing-명세s-designs는 Nikita Bier의 pixel ownership 규칙을 적용해 핵심 흐름의 모든 탭을 제공 가치에 연결하고 이탈 방지 요소를 표시합니다.
PM이고 모든 개념을 디자이너에게 의존합니다. /writing-명세s-designs는 Ravi Mehta 방식의 Balsamiq 수준 sketch를 15분 안에 만들어 엔지니어링 대화를 열 수 있게 합니다.
CEO가 'collaboration 추가'를 승인했고 그게 전부입니다. /writing-명세s-designs는 문제, 투자 의지, 해결책 개요, 숨은 복잡도, 하지 않을 것, 6주 사이클에 확정할 수 있는 breadboard로 셰이핑 점검를 실행합니다.
작동 방식
기능 아이디어, 문제, 투자 의지(쓸 의향이 있는 시간)를 공유합니다
어포던스, 연결, 핵심 시스템 동작 등 움직이는 부분를 10개 이하로 식별합니다
UI 디테일을 피하고 흐름을 보여 주는 fat-marker sketch 또는 breadboard를 생성합니다
숨은 복잡도, 하지 않을 것, 임시 shortcut 위험(Tom Conrad audit)을 호출합니다
문제, 해결책 개요, breadboard, 위험, 피치용 요약가 포함된 셰이핑 문서을 받습니다
예시
기능: 분석 대시보드 차트에 인라인 댓글 추가 문제: 팀이 차트를 스크린샷으로 찍어 Slack에서 논의하며 맥락을 잃음 Appetite: 4주 사이클 제약: 고객 포털에 임베디드 차트에서도 작동해야 함
1. 차트 hover의 comment 어포던스 2. comment thread panel(slide-in) 3. workspace members @mention 4. 차트 state로 가는 deep link 5. email + in-app 알림 6. resolved state 7. embed permissions check 8. comment count badge
차트 hover -> [댓글 추가] 버튼 -> thread panel 열림 -> 입력 + @mention -> 게시 -> 알림 발송 -> 수신자가 deep link 클릭 -> 정확한 차트 state로 이동 -> inline reply -> resolve
- real-time collab(multi-cursor): NO-GO, 4주 안에 없음 - rich text formatting: NO-GO, plain text only - threaded replies: 모호함, 숨은 복잡도로 호출 - embed permissions: 숨은 복잡도, commit 전 스파이크
'기존 Slack식 @mention picker 사용' -> 괜찮음, 재사용 가능. '이메일 템플릿을 앱 코드에 하드코딩' -> 영구 레거시가 될 가능성 높음, 나중 리팩터링로 표시. 피치 준비: 예, 숨은 복잡도 2개는 1주 차 스파이크로 범위 설정.
개선되는 지표
지원 도구
사양 및 설계 작성을(를) 사용해 보시겠어요?
시작 방법을 선택하세요.
이 스킬을 컴퓨터에 로컬로 설치하고 실행합니다.
컴퓨터에서 터미널을 열고 이 명령을 붙여넣으세요:
이 명령은 스킬과 모든 파일을 컴퓨터에 다운로드합니다:
모든 프로젝트에서 사용하려면 끝에 -g를 추가하세요.
Claude Code를 시작한 다음 명령을 입력하세요:
명세와 설계 작성
7명의 제품 리더 프레임워크와 인사이트를 사용해 효과적인 명세와 설계 문서를 작성하도록 돕습니다.
돕는 방법
사용자가 명세와 설계 문서에 대해 도움을 요청하면:
- 충실도 수준을 판단합니다 - 개념적 정렬(낮은 충실도)이 필요한지, 상세 구현 가이드(높은 충실도)가 필요한지 묻습니다.
- 광택보다 프로토타이핑을 권합니다 - 가능하면 정적 문서보다 기능 프로토타입으로 밀어붙입니다.
- 움직이는 부분에 집중합니다 - 핵심 어포던스, 연결, 시스템 동작을 식별하도록 돕습니다.
- 장기적 영향을 고려합니다 - 임시 지름길이 종종 영구적인 설계 결정이 된다는 점을 상기시킵니다.
핵심 원칙
낮은 충실도 스케치는 협업을 이끕니다
Christina Wodtke: "제가 화이트보드에 정말 형편없이 그리면 누군가가 '아니요, 아니요, 그렇게 작동하지 않아요. 펜 주세요'라고 합니다. 공유된 비전에 정말 빠르게 도달하게 됩니다." '못 그리기'는 참여와 수정을 초대하고 정렬을 빠르게 합니다.
잘 다듬어진 명세는 과도하게 지정하지 않으면서 명확하게 합니다
Ryan Singer: "셰이핑 세션의 산출물은 엔지니어, 제품, 디자인이 모두 '무엇을 만들어야 하는지 정확히 알겠다'고 말하는 어떤 그림이나 다이어그램입니다." UI 세부사항을 처방하지 않으면서 팀이 '벽 안의 전기'를 볼 수 있는 세부 수준을 목표로 하세요.
제품을 느끼기 위해 프로토타입을 만듭니다
Tamar Yehoshua: "이게 작동할지 말로는 알 수 없습니다. 느껴봐야 합니다. 시도해 봐야 합니다. 목업은 느낌이 어떨지 알려 주지 않습니다." 정적 스크린샷이 아니라 실제 데이터가 있는 프로토타입으로 경험을 테스트하게 하세요.
정적 목업보다 코드 프로토타입입니다
Noah Weiss: "우리는 정적 목업의 디자인 탐색에 쓰던 사이클을 멈추고, '지저분하고 버려도 되는 것이라도 실제 소프트웨어에서 그 경로를 얼마나 빨리 프로토타이핑할 수 있을까?'라고 했습니다." 가능한 한 빨리 실제 소프트웨어 프로토타입으로 이동하세요.
제품은 픽셀 안에 삽니다
Nikita Bier: "계층, 픽셀, 흐름, 모든 것을 설계해야 합니다. 제품은 픽셀 안에서 살고 죽습니다." 0에서 1로 가는 제품에서는 세밀한 설계 디테일을 소유하세요. 모든 탭이 소중합니다.
모든 탭을 최적화합니다
Nikita Bier: "모바일 앱에서 모든 탭은 기적입니다. 사용자는 매우 빠르게 돌아서 다음 앱으로 떠납니다." 극도의 효율성으로 설계하세요. 각 상호작용은 즉각적인 가치를 제공해야 합니다.
굵은 마커 스케치를 사용합니다
Ryan Singer: "브레드보딩과 굵은 마커 스케치를 사용하세요. 이 버튼을 누르고, 여기로 가고, 이 계산이 실행되고, 그런 다음 이 답을 얻습니다." 굵은 마커는 색상이나 간격 같은 UI 세부사항에 빠지는 것을 막아 줍니다.
지름길은 영구화됩니다
Tom Conrad: "임시 설계 지름길은 여러 차례 기술적 재작성 이후에도 지속되는 영구적 제품 유산이 되는 경우가 많습니다." 초기 구현 세부사항이 장기 사용자 기대를 정의할 수 있음을 유념하세요.
PM은 스케치하는 법을 배워야 합니다
Ravi Mehta: "스케치하는 법을 배우고 Balsamiq를 배우세요. UI와 UX가 어떻게 작동하는지 개념 수준에서 생각할 수 있는 능력은 PM이 되는 데 중요한 부분입니다." 개념적 와이어프레임을 만들 수 있는 자립성을 키우세요.
사용자를 돕는 질문
- "팀 정렬(낮은 충실도 스케치)이 필요한가요, 구현 가이드(높은 충실도 명세)가 필요한가요?"
- "이것을 문서화하는 대신 프로토타입으로 만들 수 있나요?"
- "이 해결책에서 움직이는 부분을 10개 이하로 꼽으면 무엇인가요?"
- "이 설계를 이해관계자만이 아니라 실제 사용자와 테스트했나요?"
- "어떤 임시 지름길이 영구적 결정이 될 수 있나요?"
- "이 흐름의 모든 탭이 사용자에게 명확한 가치를 제공하나요?"
지적해야 할 흔한 실수
- 과도하게 지정된 와이어프레임 - 높은 충실도 목업은 협업을 늦출 수 있습니다. 굵은 마커 스케치로 시작하세요.
- 복잡한 상호작용에 정적 목업 사용 - 스크린샷이 아니라 실제 프로토타입으로 느낌을 테스트하세요.
- 픽셀 수준 세부사항 무시 - 소비자 제품에서는 모든 탭과 전환이 중요합니다.
- 아무도 읽지 않는 명세 - 엔지니어가 문서를 사용하지 않는다면 형식이나 충실도가 잘못된 것입니다.
- 지속되는 임시 결정 - 초기 지름길이 수십 년 지속될 수 있음을 인식하세요.
심층 자료
7명의 게스트에게서 얻은 10개 인사이트 전체는 references/guest-insights.md를 참고하세요.
관련 스킬
- PRD 작성
- 사용성 테스트
- 이해관계자 정렬
- 제품 출시
참조 문서
명세와 설계 작성 - 모든 게스트 인사이트
게스트 7명, 언급 10개
Christina Wodtke
Christina Wodtke
"제가 화이트보드에 정말 형편없이 그리면 누군가가 '아니요, 아니요, 그렇게 작동하지 않아요. 펜 주세요'라고 말하고 직접 그리기 시작합니다. 그러면 공유된 비전에 매우 빠르게 도달합니다. 디자이너들이 와이어프레임을 만드는 데 그렇게 많은 시간을 쓰는 것을 보는데, 저는 그것이 가장 형편없는 시간 사용이라고 생각합니다."
인사이트: 화이트보드의 낮은 충실도 그림은 높은 충실도 와이어프레임보다 팀 정렬에 더 빠르고 협업적입니다.
전술 조언:
- 다른 사람이 참여하고 비전을 고치도록 화이트보드에 일부러 '못 그리듯' 그리세요.
- 초기 설계 논의에서는 복잡한 시스템을 단순한 도형(사각형, 원)으로 표현하세요.
Timestamp: 00:42:38
Nikita Bier
Nikita Bier
"제품 개발자에게 모바일 앱의 모든 탭은 기적입니다. 사용자는 매우 빠르게 돌아서 다음 앱으로 이동하기 때문입니다. 당신이 얻는 모든 탭, 그 하나하나가 너무 희소해서 모든 것을 최적화해야 합니다."
인사이트: 모바일 설계에는 극도의 효율성이 필요합니다. 사용자 주의는 매우 분산되어 있고 모든 상호작용은 이탈 지점이 될 수 있습니다.
전술 조언:
- 사용자 흐름의 모든 탭이 즉각적인 가치를 제공하도록 최적화하세요.
- 사용자가 휴대폰과 상호작용하는 모습을 관찰해 앱 전환 빈도를 이해하세요.
Timestamp: 00:13:49
"계층, 픽셀, 흐름, 모든 것을 설계해야 합니다. 그것은 당신의 책임입니다. 제품은 픽셀 안에서 살고 죽습니다."
인사이트: 0에서 1로 가는 제품에서는 제품 리더가 성공을 좌우하는 세밀한 설계 디테일에 깊이 관여해야 합니다.
전술 조언:
- 정보 계층과 사용자 흐름을 별도 디자인 조직에 완전히 넘기지 말고 직접 소유하세요.
Timestamp: 00:01:10
Noah Weiss
Noah Weiss
"우리는 정적 목업이나 워크스루의 디자인 탐색에 너무 많은 사이클을 쓰는 것을 멈추고, '지저분하고 버려도 되더라도 실제 소프트웨어에서 이 경로를 얼마나 빨리 프로토타이핑할 수 있을까?'라고 말했습니다. 소프트웨어를 살아 보고 만지고 냄새 맡아야 합니다. 그냥 보기만 해서는 안 됩니다."
인사이트: 소프트웨어가 실제로 어떻게 느껴지는지 이해하려면 정적 디자인 목업보다 코드로 만든 높은 충실도 프로토타입을 우선하세요.
전술 조언:
- 가능한 한 빨리 정적 목업에서 실제 소프트웨어 프로토타입으로 이동하세요.
- 상호작용의 '느낌'을 일찍 테스트하려면 지저분하고 버려도 되는 코드를 사용하세요.
Timestamp: 01:22:38
Ravi Mehta
Ravi Mehta
"스케치하는 법을 배우고 Balsamiq를 배우라고 제안하겠습니다. UI와 UX가 어떻게 작동하는지 개념 수준에서 생각할 수 있는 능력은 제품 관리자가 되는 데 매우 중요한 부분이라고 생각합니다. 오늘 그 기술이 없다면, 그 기술을 연습할 훌륭한 자료가 많습니다."
인사이트: PM은 디자이너에게 전적으로 의존하지 않고 아이디어를 전달할 수 있도록 개념적 와이어프레임을 직접 만들 수 있어야 합니다.
전술 조언:
- Balsamiq 같은 낮은 충실도 도구를 사용해 제품 개념을 빠르게 반복하세요.
- 높은 충실도 시각 디자인보다 개념적 레이아웃과 사용자 흐름에 집중하세요.
Timestamp: 00:27:51
Ryan Singer
Ryan Singer
"셰이핑 세션의 산출물은 엔지니어, 제품, 디자인이 모두 그것을 보고 '이해했습니다. 무엇을 만들어야 하는지 정확히 압니다'라고 말하는 어떤 그림이나 다이어그램입니다."
인사이트: 잘 다듬어진 명세는 UI 세부사항을 과도하게 지정하지 않으면서 기술적, 기능적 명확성을 제공하는 낮은 충실도 다이어그램입니다.
전술 조언:
- 팀이 '벽 안의 전기', 즉 기술적 실현 가능성을 볼 수 있는 세부 수준을 목표로 하세요.
- 명세가 해결책의 '움직이는 부분'(보통 10개 이하)을 설명하도록 하세요.
Timestamp: 00:39:05
"셰이핑 세션에서는 너무 높은 충실도의 무언가로 협업할 수 없습니다. 그래서 협업할 방법도 필요합니다. 브레드보딩과 굵은 마커 스케치 같은 것입니다. 이것들은 아이디어를 아주 명확하고 자세하게 표현하도록 돕는 도구입니다. 이 버튼을 누르면 여기로 가고, 이 계산이 실행되고, 그다음 이 답을 얻습니다."
인사이트: 협업 세션에서 논리와 흐름을 빠르게 매핑하려면 브레드보딩 같은 낮은 충실도 도구를 사용하세요.
전술 조언:
- 색상이나 정확한 간격 같은 UI 세부사항에 빠지지 않도록 '굵은 마커 스케치'를 사용하세요.
- 시스템을 정의할 때 '어포던스'(버튼, 입력)와 '연결'(어디로 이어지는지)에 집중하세요.
Timestamp: 01:00:38
Tom Conrad
Tom Conrad
"이 이야기의 요점이 무엇인지 확실하진 않지만, 디자이너와 제품 사람으로서 우리는 모두 이런 일을 한다고 생각합니다. 나중에 돌아와 정리하겠다고 생각하며 지름길을 택합니다. 때로는 문자 그대로 30년 동안 그 작은 설계 디테일이 세 번의 구현 뒤에도 남아 이제 Apple 제품이 작동하는 방식의 일부가 됩니다."
인사이트: 임시 설계 지름길은 여러 차례 기술적 재작성 이후에도 남는 영구적인 제품 유산이 되는 경우가 많습니다.
전술 조언:
- '임시' UI/UX 결정이 수십 년 지속될 수 있음을 유념하세요.
- 초기 구현 세부사항이 장기 사용자 기대를 정의할 수 있음을 인식하세요.
Timestamp: 00:09:51
Tamar Yehoshua
Tamar Yehoshua
"그에게서 가장 많이 배운 것은 프로토타이핑의 힘이었습니다. 그는 훌륭한 제품 사상가였지만 항상 '이게 작동할지 말로는 알 수 없습니다. 느껴봐야 합니다. 시도해 봐야 합니다. 목업은 느낌이 어떨지 알려 주지 않습니다'라고 말했습니다."
인사이트: 높은 충실도 프로토타입은 정적 디자인으로는 할 수 없는 방식으로 제품의 '느낌'과 실행 가능성을 평가하는 데 필수입니다.
전술 조언:
- 사용자 경험을 진짜로 테스트하려면 실제 데이터를 사용하는 프로토타입을 요구하세요.
Timestamp: 00:30:17
"제대로 하고 있다면 더 빠를 것이고, 프로토타이핑을 가능하게 하는 엔지니어링 인프라가 필요합니다. 프로덕션에 절대 들어가지 않을 코드를 작성해 훨씬 더 빠르게 뽑아내고, 무엇이 작동하는지 본 다음 프로덕션 코드를 만듭니다."
인사이트: 프로토타이핑은 학습을 빠르게 하기 위해 코드를 의도적으로 '버리는' 별도의 빠른 단계여야 합니다.
전술 조언:
- 빠른 UI 실험을 가능하게 하는 추상화 계층을 기술 스택에 만드세요.
- 프로덕션 수준 코드보다 속도에 집중하는 '디자인 엔지니어'나 프로토타이퍼를 채용하세요.
Timestamp: 00:34:08