프로토타입: 폐기 가능한 코드로 디자인 질문에 답하기

프로토타입은 "일단 대충 작성하는 것"이 아닙니다.

/prototype의 첫 번째 정의는 중요합니다.

프로토타입은 질문에 답하기 위해 작성된 폐기 가능한 코드입니다.

이 문장은 프로토타입을 "게으른 구현"과 구분합니다. 프로토타입은 프로덕션 코드의 전신이 아니며, 나중에 공식 버전으로 수정될 반제품도 아닙니다. 처음부터 폐기 가능한 것으로 표시되어야 합니다.

따라서 /prototype의 핵심은 빠르게 작성하는 것이 아니라 먼저 명확히 하는 것입니다.

이 프로토타입은 어떤 질문에 답해야 하는가?

두 가지 분기

Matt는 프로토타입을 두 가지 유형으로 나누며, 출력은 완전히 다릅니다.

이것은 매우 실용적입니다. 많은 팀이 "프로토타입을 만들자"고 말하지만, 인터페이스 모양을 검증하고 싶은 것인지, 상태 흐름을 검증하고 싶은 것인지 명확히 하지 않습니다. 둘 다 다른 것을 필요로 합니다.

Logic prototype: 상태를 터미널에 펼치기

질문이 "이 상태 머신이 올바른가", "이 비즈니스 규칙이 실행될 수 있는가"라면, 프로토타입은 매우 작은 명령줄 프로그램이어야 합니다.

특징:

• 메모리 내 상태이며 실제 데이터베이스에 의존하지 않습니다.
• 하나의 명령으로 시작합니다.
• 각 작업 후 관련 전체 상태를 출력합니다.
• 종이로 추론하기 어려운 분기를 다룹니다.
• 테스트를 작성하지 않고, 예외 처리를 하지 않으며, 프레임워크로 추상화하지 않습니다.

예시: 구독 상태 흐름을 설계해야 합니다.

프로덕션 코드를 직접 수정하지 마세요. 먼저 subscription-prototype.ts를 작성하여 사용자가 터미널에서 선택할 수 있도록 하세요.

1. start trial
2. pay
3. cancel
4. expire
5. refund
6. print state

각 단계를 누를 때마다 현재 권한, 시험판 할당량, 유료 상태, 다음 갱신을 출력합니다. 일부 상태 조합을 전혀 생각하지 않았다는 것을 빠르게 알게 될 것입니다.

이러한 유형의 프로토타입의 가치는 다음과 같습니다. 추상 규칙을 조작 가능한 객체로 만듭니다.

UI prototype: 라우트 내에 여러 급진적인 솔루션 배치

질문이 "인터페이스를 어떻게 디자인해야 하는가"라면, 프로토타입은 동일한 솔루션을 세 번 미세 조정하는 것이 아니라, 충분히 다른 여러 UI 세트를 생성해야 합니다.

/prototype의 UI 분기는 다음을 요구합니다.

• 하나의 라우트 내에 여러 변형을 배치합니다.
• URL 검색 매개변수 또는 하단 플로팅 전환 막대를 사용하여 전환합니다.
• 솔루션 간에 명확한 차이가 있어야 합니다.
• 프로토타입 코드는 미래의 실제 페이지에 가깝지만, 명확하게 프로토타입임을 나타내는 명명 규칙을 사용합니다.
• 너무 일찍 실제 데이터 및 지속성 연결을 하지 않습니다.

이것은 일반적인 AI UI 생성과 다릅니다. AI가 한 번에 "최적의 솔루션"을 제공하도록 하는 것이 아니라, 실제 브라우저를 사용하여 여러 방향을 비교하도록 합니다.

예를 들어, 대시보드의 빈 상태에 대해 AI에게 문구만 수정하도록 하지 마세요. 다음과 같이 만들 수 있습니다.

• A: 표 형식, 높은 밀도, 다음 작업 강조
• B: 작업 중심, 왼쪽 체크리스트 + 오른쪽 미리보기
• C: 안내식, 주요 CTA 및 이전 예시 강조

그런 다음 채팅에서 세 개의 스크린샷을 보고 상상하는 대신, 동일한 라우트에서 전환합니다.

모든 프로토타입은 삭제 가능해야 합니다.

/prototype의 일반 규칙 중에서 가장 중요한 것은 "삭제 가능성"입니다.

• 파일 이름이나 경로에 프로토타입임을 명시합니다.
• 기본적으로 프로덕션 데이터베이스에 연결하지 않습니다.
• 과도한 일반 추상화를 작성하지 않습니다.
• 과도한 오류 처리를 하지 않습니다.
• 완료 후 삭제하거나 배운 내용을 공식 코드로 흡수합니다.

프로토타입을 삭제할 수 없다면, 이미 프로덕션 코드 부채가 된 것입니다.

이것은 AI 프로그래밍에서 특히 중요합니다. AI는 프로토타입을 "작동하는 것처럼 보이게" 만드는 데 능숙하며, 그러면 인간은 삭제하기를 꺼리고 결국 아무도 건드리지 않는 임시 코드 더미가 프로젝트에 남게 됩니다.

프로토타입 완료 후 무엇을 남겨야 하는가

프로토타입 코드는 보존할 가치가 없지만, 답변은 보존할 가치가 있습니다.

Matt는 다음 사항을 영구적인 위치에 기록할 것을 권장합니다.

• 프로토타입이 답해야 했던 질문
• 관찰된 결론
• 선택한 방향
• 포기한 방향
• 필요한 경우 ADR, 이슈, PRD 또는 커밋 메시지로 전환

즉, /prototype의 산출물은 코드가 아니라 결정입니다.

사용하지 말아야 할 때

다음 시나리오에서는 /prototype을 사용하지 마세요.

• 요구 사항이 명확하며 구현만 필요합니다.
• 버그가 재현되었으며 /diagnose를 사용해야 합니다.
• 리팩토링 방향이 명확하며 /tdd로 보호하면서 구현해야 합니다.
• UI가 사소한 개선일 뿐이며 여러 솔루션을 만들 가치가 없습니다.
• 삭제하거나 흡수할 시간이 없습니다.

프로토타입의 비용은 작성하는 데 있는 것이 아니라 마무리하는 데 있습니다. 마무리가 없다면 시작하지 마세요.

유용한 프롬프트

이렇게 호출할 수 있습니다.

/prototype

이 체크아웃 상태 머신이 합리적인지 검증하고 싶습니다. logic 분기를 사용해 주세요.
폐기 가능한 터미널 프로토타입만 만들고 실제 DB는 연결하지 마세요.
각 작업 후 전체 상태를 출력해 주세요.

또는:

/prototype

프로젝트 상세 페이지의 3가지 정보 아키텍처를 비교하고 싶습니다. UI 분기를 사용해 주세요.
기존 라우트 시스템 내의 prototype 라우트에 배치하고 하단 전환 막대를 제공해 주세요.
프로덕션 컴포넌트는 수정하지 마세요.

여기서 가장 중요한 것은 "답해야 할 질문"을 명확히 하는 것입니다. 이 질문이 명확하면 프로토타입이 길을 잃기 쉽지 않습니다.

Grill Me와의 관계

/grill-me는 질문을 통해 결정을 수렴하는 데 적합하며, /prototype은 체험을 통해 결정을 수렴하는 데 적합합니다.

어떤 질문은 질문만으로 해결될 수 있습니다. 예를 들어 "익명 댓글은 검토해야 하는가?"입니다. 어떤 질문은 직접 만져봐야 합니다. 예를 들어 "이 드래그 앤 드롭 정렬 상태 머신이 실제로 사용하기 어려울까?"입니다. 후자는 프로토타입을 사용해야 합니다.

따라서 저는 이를 워크플로우의 분기점으로 배치할 것입니다.

아이디어가 모호함
  ↓
/grill-me
  ↓
여전히 체험 또는 검증이 필요한 경우
  ↓
/prototype
  ↓
결론을 보존하고 프로토타입 삭제
  ↓
/to-prd 또는 /tdd

참고 자료

다음 글: Improve Codebase Architecture: shallow 모듈을 deep 모듈로 리팩토링.