상태 전이의 어색함은 버튼을 눌러 발견한다: Matt Pocock의 prototype 스킬 '로직 분기' 읽기

mattpocock/skills의 prototype

스킬은 질문이 "이 로직이나 상태 모델이 맞는지"일 때, HTML 파일을 단 하나만 만듭니다. 내용은 언제든지 누를 수 있는 버튼(프리 플레이)과 탭으로 전환하는 시나리오(가이드형 워크스루)로 구성됩니다. 로직 본체는 DOM에 건드리지 않는 순수한 모듈로 분리하여 작성하고, 검증이 끝나면 그대로 실제 코드에 옮깁니다.

저희는 Skillselion을 운영합니다. Claude Code, Codex, Cursor 등의 코딩 에이전트용 스킬을 모은 독립적인 디렉토리이며, Anthropic, OpenAI, Cursor, Matt Pocock 씨와 어떠한 제휴 관계도 없습니다. 이 글에서는 2026년 10월 14일자 upstream HEAD에 있는 skills/engineering/prototype/SKILL.md

과 로직 분기 절차를 설명한 LOGIC.md

을 읽었습니다. 두 파일 모두 최종 업데이트는 2026년 8월 19일입니다. 스킬을 실행하여 출력을 평가한 것은 아닙니다.

prototype 스킬은 얼마나 사용되고 있나요

skills.sh에서의 설치 수는 933,678개입니다(2026년 10월 14일자). 리포지토리의 GitHub 스타는 290,182개이며, 라이선스는 MIT입니다(GitHub API, 같은 날짜). 스타는 리포지토리 전체의 수량이며, 이 스킬 단체의 수가 아닙니다. 숫자의 추이는 Skillselion의 Matt Pocock 버전 prototype 스킬 페이지에서 확인할 수 있습니다.

두 개의 분기는 어떻게 선택되나요

SKILL.md는 처음에 어떤 질문에 답할지 결정하게 합니다.

"Does this logic / state model feel right?"

"What should this look like?"

전자가 로직 분기(LOGIC.md)이고, 후자가 UI 분기(UI.md)입니다. 파일 자체에는 "분기를 잘못하면 프로토타입 전체가 무용지물이 된다"고 쓰여 있으며, 사용자가 확인할 수 없을 때의 결정 방법도 지정되어 있습니다. 주변 코드가 백엔드 모듈이라면 로직을, 페이지나 컴포넌트라면 UI를 선택하고, 그 전제를 프로토타입 시작 부분에 작성합니다.

UI 분기에 대한 이야기는 prototype 스킬 두 개를 비교한 Skillselion의 가이드에 정리했으므로, 여기서는 로직 분기만 다룹니다.

로직 분기는 무엇을 만드나요

LOGIC.md 초반부 정의는 다음과 같습니다.

"A single, self-contained HTML file (a shareable demo) that lets anyone drive a state model by clicking buttons."

프레임워크도 번들러도 서버도 사용하지 않고, 모든 것을 인라인으로 작성합니다. 더블 클릭해서 열어도, 이메일로 보내도 망가지지 않는 것이 조건입니다. 읽는 사람이 개발자일 필요는 없습니다. 디자이너, PM, 업무 전문가에게 전달하는 전제이므로, 버튼이나 상태 표시는 코드 이름이 아닌 업무 용어로 작성합니다.

화면 구성도 위에서부터 순서대로 정해져 있습니다.

• 제목과 이 데모에서 무엇을 확인할 것인지 한 줄로
• 현재 상태. 원시 JSON이 아닌 레이블이 붙은 패널로, 클릭할 때마다 다시 그립니다.
• 프리 플레이 버튼. 액션 하나당 버튼 하나로, 어떤 순서로든 누를 수 있습니다.
• 가이드형 워크스루. 시나리오별로 탭을 나누고, 누르는 버튼을 순서대로 배열합니다. 시작 시에는 반드시 정해진 초기 상태로 돌아갑니다.

시나리오 선택도 구체적입니다.

"the happy path, a tricky edge case, an attempt at something that should be illegal."

정상 흐름(happy path), 까다로운 경계 케이스(tricky edge case), 원래는 할 수 없어야 하는 시도 세 가지입니다. 책상 위에서는 판단하기 어려운 경우일수록 실제로 눌러 확인해 볼 가치가 있습니다.

왜 로직을 순수한 모듈로 분리하는가

절차 2가 이 스킬에서 가장 실무에 유용한 부분이라고 저희는 읽었습니다. 로직 본체는 하나의 <script> 블록 안에 작은 순수 모듈로 작성합니다. 형태는 질문에 맞춰 네 가지 중 하나를 선택합니다.

• 순수한 reducer
  (state, action) => state

• 상태와 전이를 명시한 스테이트 머신

• 단순 데이터 타입에 대한 순수 함수들의 집합

• 내부 상태를 정말로 가질 경우에만, 메서드의 경계가 명확한 클래스나 모듈

제약은 한 줄입니다.

“순수하게 유지하세요: DOM도, document도, 그 안에 도달하는 버튼 핸들러도 없습니다.”

페이지가 모듈을 호출하고 역방향 의존성은 없습니다. 따라서 질문에 답이 나온 후에는 HTML 외부를 버리고 리듀서(reducer)나 스테이트 머신(state machine)만 실제 모듈로 옮길 수 있습니다.

예를 들어 주문 취소 가능 여부를 확인하려면 구조는 다음과 같습니다. 이는 설명을 위해 저희가 작성한 예시이며, 상위(upstream) 코드와는 다릅니다.

// 예: DOM을 참조하지 않는 순수 리듀서
function order(state, action) {
switch (action.type) {
...

“배송 완료된 것은 취소할 수 없다”라는 사양은 버튼을 누르는 사람이 직접 깨보려고 시도하며 확인할 수 있습니다.

양쪽 분기에 공통되는 6가지 규칙은 무엇인가요

SKILL.md의 6가지 규칙을 요약합니다.

• 처음부터 일회용임을 알 수 있는 이름으로 지정하고, 사용되는 곳 근처에 배치하기 - 시작하는 데 노력이 필요하지 않다. UI 프로토타입은 태스크 러너의 한 커맨드, 로직 데모는 더블 클릭으로 열리는 HTML
• 영구화하지 않는다. 상태는 메모리에 둔다. DB가 질문 대상이라면 “PROTOTYPE, wipe me”와 같은 이름의 스크래치 DB를 사용한다
• 다듬지 않는다. 테스트도, 실행하는 데 필요한 분량 이상의 에러 처리도, 추상화도 작성하지 않는다
• 조작할 때마다 관련 상태 전체를 표시한다
• 끝나면 기록한다. 검증된 판단을 실제 코드에 넣고, 프로토타입 자체는 main 외부의 일회용 브랜치에 커밋하며, 구현 이슈에서 그 브랜치를 추적할 수 있게 한다.

LOGIC.md의 안티패턴(anti-pattern) 항목에서는 규칙 4가 더욱 강한 표현으로 되어 있습니다.

"테스트가 필요한 프로토타입은 더 이상 프로토타입이 아니다."

규칙 6은 놓치기 쉬운 부분입니다. 프로토타입 자체는 일회용 브랜치에 **1차 자료(primary source)**로 남기고, main에는 검증된 판단만 넣습니다.

Emil Kowalski 버전의 동명 스킬과는 어떻게 다른가요

prototype이라는 이름의 스킬은 또 하나 있습니다. Emil Kowalski 버전 prototype 스킬 페이지(skills.sh에서 146,217 설치, 2026년 10월 14일 기준, GitHub 소스)입니다. 이쪽은 UI의 변형만 만들고 고정 디자인의 피커로 전환합니다. 프런트매터에 disable-model-invocation: true가 있어서, 이름을 지정하여 호출하지 않는 한 작동하지 않습니다. 로직을 확인하는 분기는 없습니다.

둘 다 name: prototype이므로, /prototype으로 동작하는 것은 그중 하나뿐입니다. 공식 문서에서는 같은 이름이라면 개인 스코프(~/.claude/skills/)가 프로젝트 스코프(.claude/skills/)보다 우선합니다. 팀의 누군가가 한쪽을 글로벌에 넣어두면, 같은 커맨드로 다른 스킬이 작동할 수 있습니다. 들어있는 쪽의 SKILL.md 프런트매터를 열어서 확인해 주세요. Emil Kowalski 씨의 다른 스킬은 Emil Kowalski 씨의 스킬 설명에서 소개하고 있습니다.

프로토타입 전후에 사용할 수 있는 스킬이 있나요

만들기 전에 어떤 충실도(fidelity)와 방법으로 시도할지 결정하고 싶다면, owl-listener/designer-skills의 prototype-strategy 스킬이 있습니다(skills.sh에서 1,955 설치, 2026년 10월 14일 기준, GitHub 소스).

상태 모델이 확정된 후에는 같은 리포지토리의 다음 스킬로 이어집니다.

프로토타입으로 검증한 리듀서를 TDD(Test-Driven Development)를 통해 실제 모듈로 다시 작성하는 흐름입니다. 리포지토리 전체의 위치는 Matt Pocock 씨의 스킬 전체 맵을 참고해 주세요. UI 모양을 비교하고 싶다면, 설치 수로 정렬된 프런트엔드 디자인 계열 스킬과 프런트엔드 디자인 카테고리 목록에서 찾아볼 수 있습니다.

최종 업데이트: 2026년 10월 14일

Discussion