생산적 사고 (Productive Thinking)은(는) 무엇을 하나요?
Tim Hurson의 생산적 사고 모델을 사용하여 구조화된 설계 세션을 진행하고, 선택적으로 RFC로 작성합니다.
입력
$ARGUMENTS
- 입력이
rfc로 시작하면 RFC 모드로 실행됩니다. 그 뒤의 내용은 선택적 제목 또는 출력 경로입니다. - 그 외의 경우 인터랙티브 모드로 실행되며, 입력을 문제 설명으로 취급합니다. 입력이 비어 있으면, 다른 작업을 수행하기 전에 사용자에게 한두 문장으로 문제를 설명하도록 요청하세요.
진행 방법
- 모든 것을 코드에 기반하세요. 각 단계 전에 관련 파일, 스키마, 설정, 문서를 검색하고 읽은 후, 이에 의존할 때는 경로를 인용하세요. 이 세션이 화이트보드 채팅보다 가치 있는 이유는 결론이 시스템이 실제로 하는 일에 기반하기 때문입니다. 따라서 가정하지 말고 확인하세요. 여러 파일에 걸친 광범위한 검토가 필요한 경우 Explore 하위 에이전트에 위임하여 세션 컨텍스트가 논의에 집중되도록 하세요.
- 사용자의 부담을 최소화하세요. 턴당 최대 5개의 질문을 하고, 발견한 내용을 바탕으로 직접 제안 답변을 함께 제시하여 사용자가 빈칸에서 시작하는 대신 "네, 대부분 맞는데, 하지만…" 식으로 답할 수 있게 하세요.
- 턴당 한 단계씩 진행하세요. 각 단계를
Step 2 of 6 — What's success?와 같은 헤더로 시작하고, 단계를 수행한 후 멈추고 기다리세요. 사용자가 준비되었을 때만 다음 단계로 넘어가고, 사용자가 단계를 건너뛰거나, 다시 방문하거나, 사이를 이동할 수 있게 하세요. - 실행 노트 파일을 유지하세요. 각 단계 후에 합의된 결과를
<rfc-dir>/<slug>.notes.md에 추가하세요(<rfc-dir>은 RFC 모드 3단계에 설명된 대로 선택). 긴 세션은 나중에 압축하거나 재개할 수 있습니다. 노트 파일은 RFC 모드나 새 세션이 결정 사항을 잃지 않고 이어받을 수 있게 합니다. 처음 생성할 때 사용자에게 위치를 알려주세요.
6단계
1. 지금 무슨 일이 일어나고 있나? (What's going on?)
목표: 현재 현실과 목표 미래에 대한 공유된 이해. 영향을 받는 영역의 기존 구현, 호출 지점, 데이터 모델 및 최근 git 히스토리를 탐색하세요. 다루어야 할 내용: 문제점이나 병목 지점(오류, 메트릭 또는 코드와 같은 증거 포함), 영향을 받는 모듈 및 서비스, 영향을 받는 사람, 그리고 "해결된" 상태가 어떤 모습인지.
2. 성공이란 무엇인가? (DRIVE)
목표: 모든 옵션이 평가될 기준. 1단계에서 초안을 제안하고 사용자가 수정하게 하세요.
- Do: 솔루션이 반드시 해야 하는 것
- Restrictions: 하드 제약 조건(하위 호환성, 성능 예산, 스택, 규정 준수)
- Investment: 팀이 기꺼이 투자할 시간, 인력, 복잡성
- Values: 동점을 깨는 엔지니어링 원칙(단순성, 테스트 용이성 등)
- Essential outcomes: 타협할 수 없는 결과, 가능한 경우 측정 가능해야 함
또한 명시적인 비목표도 포함하세요.
3. 질문은 무엇인가? (What's the question?)
문제를 다르게 구성하는 2~3개의 "어떻게 하면…(How might we…)" 질문을 제안하세요. 예를 들어 하나는 좁은 범위의 질문이고 다른 하나는 1단계의 가정에 도전하는 질문입니다. 사용자가 하나를 선택하거나 다시 작성합니다. 선택된 질문은 세션의 나머지 부분에 대한 문제 설명이 됩니다.
4. 답변 생성 (Generate answers)
코드베이스에 기반한 진정으로 구별되는 2~3가지 접근 방식을 제안하세요. 하나의 아이디어의 변형이 아니어야 합니다. 각각에 대해: 간단한 스케치, 건드리는 파일이나 모듈, 주요 위험. 이 단계에서는 판단을 보류하고 사용자의 자신의 아이디어를 초대하세요.
5. 해결책 구체화 (Forge the solution)
각 접근 방식을 DRIVE에 대해 평가하고(작은 표가 좋습니다), 하나를 추천하고, 수용하는 트레이드오프를 명명하세요. 그런 다음 견고하게 만드세요: 실패 모드, 엣지 케이스, 마이그레이션 문제, 미해결 질문. 다른 옵션이 탈락한 이유를 기록하세요. 이것이 "대안 검토(Alternatives considered)"가 됩니다.
6. 자원 정렬 (Align resources)
개별 티켓이 아닌 제공 형태에 동의하세요: 단계 또는 마일스톤과 각각이 입증 가능하게 만드는 것, 가장 먼저 증명해야 할 가장 위험한 부분, 기능 플래그 및 마이그레이션 전략, 테스트 전략, 롤아웃 및 롤백, 그리고 모니터링할 항목. 상세한 티켓 분류는 RFC를 기반으로 작동하는 /task-breakdown에서 나중에 수행됩니다. RFC 생성을 제안하는 것으로 마무리하세요.
RFC 모드
- 세션 찾기: 지금까지의 대화와 노트 파일(있는 경우)을 사용하세요. 세션이 전혀 없으면 그렇게 말하고 새 세션을 시작할 것을 제안하세요: 문제 설명을 요청하고 1단계를 시작하세요.
- 누락된 단계가 있으면, 어떤 단계인지 나열하고 지금 채울 것인지 아니면 해당 섹션을 TBD로 표시하여 RFC 초안을 작성할 것인지 물어보세요. 사용자가 결정하지 않은 사항을 임의로 만들지 마세요.
- 출력 위치를 선택하세요. RFC, 노트 및 작업 파일은 개발자의 로컬 작업 문서입니다: 기본적으로 추적되지 않음(un-tracked), 코드와 함께 커밋되지 않음. 이 파일들을 위한 기존의 로컬 git 무시 폴더가 있는지 확인하고(
.gitignore및.git/info/exclude확인), 그 명명 규칙을 따르세요. 없으면.rfcs/YYYY-MM-DD-<slug>.md를 제안하고.rfcs/를.git/info/exclude에 추가하세요. 이는 리포지토리의.gitignore를 변경하지 않고 로컬에서 무시합니다. 팀이 RFC를 커밋하는 경우에만docs/rfcs/와 같은 추적 폴더를 사용하세요. - templates/rfc.md를 사용하여 RFC를 작성하고, 세션에서 각 섹션을 채우고 코드베이스 주장을 파일 경로에 연결하세요.
- 사용자에게 경로를 알리고, TBD 섹션과 미해결 질문을 나열하세요.
- 다음 단계를 제안하세요:
/task-breakdown <rfc-path>를 통해 RFC를 팀이 바로 착수할 수 있는 1스토리 포인트 티켓으로 변환합니다.