결론부터 말하면, 이미 있는 저장소에서 변경 요청은 받았지만 용어·범위·설계 결정이 흐린 상태라면 코드를 고치기 전에 /grill-with-docs를 직접 호출하는 흐름이 맞습니다. 이 스킬은 계획과 설계를 한 번에 한 질문씩 인터뷰하고, 합의된 용어와 중요한 결정을 프로젝트 문서에 남기는 데 초점이 있습니다.
반대로 저장소 없이 아이디어만 다듬거나 문서 산출물이 필요 없다면 /grill-me로 시작합니다. 설치 과정은 여기서 반복하지 않습니다. 아직 저장소별 설정을 마치지 않았다면 Matt Pocock Skills 설치와 첫 저장소 설정을 먼저 확인하세요.
먼저 결론: 저장소 작업 전 요구사항을 문서로 남기고 싶을 때 /grill-with-docs를 호출하기
/grill-with-docs는 자동 구현이나 테스트 완료를 약속하는 명령이 아닙니다. 공식 설명상 목적은 프로젝트 초기에 계획·설계·도메인 용어를 인터뷰로 구체화하고 문서화하는 일입니다.
따라서 “이 기능을 추가해 달라”는 요청이 있지만 대상 사용자, 용어의 뜻, 데이터 경계, 되돌리기 어려운 선택이 불명확할 때 호출합니다. 한 번의 세션에서 정리할 수 있는 저장소 변경이라면, 구현 전에 인터뷰 결과를 검수하고 다음 개발 작업으로 넘기는 순서가 적절합니다.
grill-with-docs와 grill-me의 차이: 저장소와 문서화 필요성으로 선택하기
| 상황 | 우선 흐름 | 판단 이유 |
|---|---|---|
| 기존 저장소의 변경 요청, 용어·결정을 남겨야 함 | /grill-with-docs |
인터뷰에 프로젝트 문서화가 결합됨 |
| 저장소 없는 아이디어·개인 계획 | /grill-me |
비코드 용도의 인터뷰 흐름 |
| 한 세션으로 닫기 어려운 큰 계획 | /wayfinder 검토 |
짧은 저장소 변경 인터뷰보다 장기 계획 분기가 적합할 수 있음 |
| 요구사항이 이미 명확하고 문서 갱신도 불필요함 | 일반 작업 | 불필요하게 인터뷰 단계를 늘리지 않음 |
실행 전 조건: 대상 저장소·설정·에이전트 호환성 확인하기
먼저 대상 저장소의 작업 디렉터리를 열고, 해당 저장소에서 /setup-matt-pocock-skills를 실행해 이슈 트래커·라벨·문서 저장 위치 같은 기본 설정을 마쳤는지 확인합니다. 이 설정은 저장소별 초기 단계이며, /grill-with-docs의 인터뷰를 대신하지는 않습니다.
또한 이 스킬은 현재 grilling과 domain-modeling 스킬을 호출하는 얇은 래퍼 구조입니다. 2026년 10월 기준 메타데이터에는 disable-model-invocation: true가 표시되므로, 에이전트가 알아서 실행한다고 기대하지 말고 사용자가 직접 호출해야 합니다. 플러그인 설치와 편집 가능한 파일 설치를 같은 에이전트에 중복 적용하지 않았는지도 확인하세요.
실제 활용 흐름: 모호한 변경 요청을 한 질문씩 구체화하기
- 낮은 위험의 변경 요청 하나를 고릅니다. 한 세션에서 논의 범위를 닫을 수 있어야 합니다.
- 저장소와 설정 상태를 확인합니다. 작업 디렉터리, 쓰기 권한, 문서 저장 위치가 대상 저장소 기준인지 봅니다.
/grill-with-docs를 직접 호출합니다. 답변은 한 질문에 하나씩, 추측 대신 현재 알고 있는 요구와 미정 사항을 구분해 제공합니다.- 인터뷰가 끝나면 문서를 읽습니다. 생성 또는 갱신된 GLOSSARY.md와 ADR, 남은 질문을 확인합니다.
- 미해결 항목을 판단합니다. 구현 결과를 바꿀 질문이 남았다면 코딩으로 넘어가기보다 그 질문부터 해결합니다.
문서가 생겼다는 사실만으로 합의가 완료된 것은 아닙니다. 특히 코드와 문서에서 같은 단어가 다른 의미로 쓰이지 않는지, 선택의 근거가 실제 요구와 맞는지를 사람이 확인해야 합니다.
인터뷰 중 남는 두 가지 기록: GLOSSARY.md의 용어와 ADR의 결정
GLOSSARY.md는 팀과 에이전트가 같은 단어를 같은 뜻으로 쓰도록 하는 공유 언어의 기록입니다. 예를 들어 “예약”, “확정”, “취소”가 화면 문구인지 상태값인지, 서로 어떤 관계인지가 혼동된다면 합의된 정의가 여기에 남아야 합니다.
ADR(Architecture Decision Record)은 되돌리는 비용이 큰 결정과 그 이유를 남기는 기록입니다. 검수할 때는 선택 결과만 보지 말고, 왜 그 선택을 했는지와 어떤 대안을 배제했는지 읽어야 합니다. 모든 대화가 즉시 GLOSSARY.md나 ADR을 만든다고 단정할 수는 없으며, 공식 흐름은 문서가 필요해지는 시점에 갱신하는 방식입니다.
합성 예시로 검수하기: 기능 요청에서 합의된 용어·결정·미해결 항목 확인하기
합성 예시: “관리자가 예약을 취소할 수 있게 해 달라”는 요청을 받았다고 가정해 보겠습니다. 인터뷰에서는 누가 관리자인지, 취소 가능한 상태는 무엇인지, 이미 확정된 예약을 취소할 때 어떤 처리가 필요한지처럼 구현 결과를 바꾸는 질문을 한 번에 하나씩 좁힙니다.
- GLOSSARY.md 확인: ‘예약’, ‘확정’, ‘취소’의 정의가 기존 코드·문서의 상태 이름과 일치하는가
- ADR 확인: 확정 뒤 취소를 허용하거나 제한한 결정, 그 근거와 되돌릴 때의 영향이 적혔는가
- 미해결 항목 확인: 알림, 권한, 예외 처리처럼 아직 답하지 못한 질문이 구현 전에 남아 있는가
셋 중 마지막 항목이 남았다면 “인터뷰가 끝났다”는 것과 “개발을 시작해도 된다”는 것을 구분하는 편이 안전합니다.
작동하지 않을 때: 의존 스킬·Skill 도구·중복 설치·문서 경로 점검하기
명령이 기대대로 진행되지 않으면 다음 순서로 좁힙니다.
- 의존 스킬: 현재
grilling과domain-modeling호출 구조를 지원하는 설치 상태인지 확인합니다. - 에이전트: 2026년 9월 공개 이슈에는 Codex처럼 Skill 도구가 없는 환경에서 SKILL.md의 호출 지시를 그대로 수행하지 못할 수 있다는 문제가 보고됐습니다. Claude Code·Codex·Copilot·Gemini CLI의 동작을 동일하다고 가정하지 마세요.
- 중복 설치: 플러그인 경로와 파일 설치 경로를 한 에이전트에 함께 적용하지 않았는지 봅니다.
- 문서 위치와 권한: 설정된 문서 경로가 실제 대상 저장소인지, 에이전트에 기록 권한이 있는지 확인합니다.
언제 /grill-with-docs 대신 다른 흐름을 선택할까: /grill-me·/wayfinder·일반 작업 분기
저장소와 문서 갱신이 필요한 한 세션짜리 변경이라면 /grill-with-docs를 선택하고, 저장소 밖의 아이디어 정리라면 /grill-me를 선택합니다. 범위가 커서 한 번의 인터뷰로 닫기 어렵다면 /wayfinder를 검토할 수 있습니다. 이미 요구·용어·결정이 문서화됐고 작은 수정만 남았다면 일반 작업으로 넘어가는 편이 더 짧습니다.
실행 뒤의 최종 기준은 간단합니다. GLOSSARY.md의 용어가 코드·기존 문서와 일치하고, ADR에 결정 근거가 남아 있으며, 구현 방향을 바꿀 미해결 질문이 없다면 다음 개발 단계로 넘길 수 있습니다.
Leave a Reply