grill-me

grill-me 스킬 개요

grill-me가 하는 일

grill-me 스킬은 AI 어시스턴트를 계획안과 설계를 구조적으로 검토하는 리뷰어로 바꿔줍니다. 막연한 의견을 한 번에 내놓는 대신, grill-me는 한 번에 하나씩 질문하고, 의사결정 분기를 따라가며, 각 질문마다 권장 답변까지 제시합니다. 이 스킬의 핵심 용도는 “같이 브레인스토밍해줘”가 아니라, “내가 커밋하기 전에 숨어 있는 가정을 수면 위로 끌어내게 해줘”에 가깝습니다.

요구사항 기획에서 grill-me가 특히 잘 맞는 경우

grill-me for Requirements Planning은 기능 아이디어, 아키텍처 변경, 마이그레이션 계획, 전달 제안처럼 아직 해결되지 않은 의존성이 남아 있는 상황에 잘 맞습니다. 특히 프로덕트 매니저, 테크 리드, 창업자, 엔지니어처럼 흐릿한 계획을 실제로 의사결정 가능한 스펙으로 바꿔야 하는 사람에게 유용합니다. 위로보다는 압박 테스트가 필요한 경우라면, 이 스킬은 좋은 선택입니다.

일반 프롬프트 대신 grill-me를 써야 하는 이유

일반 프롬프트는 너무 이른 단계에서 답을 내리는 경우가 많습니다. 반면 grill-me skill은 계획이 분명해질 때까지 질문 모드를 유지하고, 사용자가 답할 필요 없이 소스에서 확인 가능한 질문이라면 코드베이스를 먼저 살펴보도록 명시돼 있습니다. 그래서 단순한 “내 아이디어 좀 리뷰해줘”류의 범용 프롬프트보다, 저장소 기반의 기획 검토에 훨씬 실무적으로 쓸 수 있습니다.

설치 전에 알아둘 중요한 한계

이 스킬은 매우 가볍습니다. 저장소에서 노출되는 것은 SKILL.md 하나뿐이고, 추가 규칙, 스크립트, 참고 자료는 없습니다. 덕분에 grill-me install 자체는 간단하지만, 그만큼 결과물의 품질은 초기 맥락을 얼마나 잘 주는지, 그리고 후속 질문에 얼마나 성실하게 답하는지에 크게 좌우됩니다. 이미 다듬어진 프레임워크나 내장 템플릿을 기대한다면, 이 스킬은 그 용도에 맞지 않습니다.

grill-me 스킬 사용 방법

grill-me install 후 어디부터 읽어야 하는가

grill-me install은 평소 쓰는 skills 워크플로우로 추가한 뒤, 가장 먼저 SKILL.md를 읽는 것이 좋습니다. 이 파일에 사실상 거의 모든 동작 방식이 들어 있기 때문입니다. 따로 살펴볼 보조 자료는 없으므로, 도입의 핵심은 상호작용 패턴을 이해하는 데 있습니다. 즉, 한 번에 한 질문씩, 분기별로 진행하고, 가능하면 코드베이스를 탐색하면서 답을 찾는 방식입니다.

grill-me가 잘 작동하려면 어떤 입력이 필요한가

좋은 grill-me usage는 막연한 주제가 아니라, 구체적인 기획 대상에서 시작합니다. 다음을 함께 주는 것이 좋습니다:

• 목표
• 현재 상태
• 제약 조건
• 의사결정 마감 시점
• 성공 기준
• 이미 알고 있는 미해결 사항

약한 시작 예시: “새 인증 시스템에 대해 Grill me 해줘.”

더 강한 시작 예시: “이 요구사항 계획에 grill-me를 적용해줘: 우리 B2B 앱의 인증을 6주 안에 session auth에서 OAuth로 마이그레이션하고, 엔터프라이즈 고객의 SSO는 유지하고, 다운타임은 피하고, 기존 admin impersonation도 보존해야 해. 가장 큰 미지수는 tenant mapping, rollback, support load야.”

이처럼 더 구체적인 프롬프트를 주면, 스킬이 바로 어떤 분기를 파고들어야 하는지 판단할 수 있습니다.

실무에서 쓰기 좋은 grill-me 사용 흐름

신뢰할 만한 grill-me guide는 보통 이렇게 진행됩니다:

1. 짧게 계획을 요약합니다.
2. 어시스턴트에게 grill-me를 사용하라고 지시합니다.
3. 한 번에 한 질문씩 하도록 둡니다.
4. 답변은 짧고 명확하게 하고, 의존성 때문에 막히는 경우가 아니라면 너무 앞서 나가지 않습니다.
5. 프로젝트가 저장소에 있다면, 뻔한 구현 질문을 하기 전에 관련 코드를 먼저 살펴보라고 알려줍니다.
6. 질문이 10~20개쯤 쌓이면, 확정된 결정사항, 남아 있는 리스크, 다음 액션을 요약해달라고 요청합니다.

이 방식이 Requirements Planning에 잘 맞는 이유는, 비공식적인 계획을 명시적인 의사결정 체인으로 바꿔주기 때문입니다.

출력 품질을 높이는 프롬프트 패턴

역할, 범위, 종료 조건을 함께 지정하는 프롬프트를 쓰는 것이 좋습니다.

“이 계획에 grill-me를 적용해줘. 한 번에 한 질문씩 해. 각 질문마다 네가 권장하는 답을 제시하고, 트레이드오프를 짧게 설명해줘. 코드베이스에서 답할 수 있는 질문이면 나에게 묻지 말고 코드를 먼저 확인해. 구현 요구사항을 쓸 만큼 충분한 명확성이 확보되면 멈춰.”

이 프롬프트는 스킬의 의도와 잘 맞고, 불필요하게 일반론으로 흐르는 대화를 줄여줍니다.

grill-me 스킬 FAQ

grill-me는 초보자에게도 괜찮은가?

그렇습니다. 단, 초보자라도 실제로 검증할 계획안은 이미 있어야 합니다. grill-me skill은 호출 자체는 쉽지만, 가정을 계속 파고드는 방식이라 다소 강하게 느껴질 수 있습니다. 설명이나 예시 중심의 도움을 원하는 초보자라면, 먼저 더 설명적인 스킬로 초안을 만든 뒤 grill-me로 검증하는 편이 더 잘 맞을 수 있습니다.

언제는 grill-me를 쓰지 않는 게 좋은가?

빠른 아이데이션, 폭넓은 창의적 선택지, 혹은 첫 턴부터 다듬어진 최종 문서가 필요하다면 grill-me는 건너뛰는 편이 낫습니다. 아직 실제 계획 자체가 없는 상태에서도 적합하지 않습니다. 입력이 그저 “뭔가 생각해보게 도와줘” 수준이라면, 이런 질문 공세형 스타일은 시기상조로 느껴질 수 있습니다.

그냥 “내 계획의 허점을 짚어줘”라고 하는 것과 무엇이 다른가?

차이는 운영 방식의 규율에 있습니다. grill-me usage는 한 번에 끝나는 비평이 아니라, 순차적인 질문과 의존성 해소를 중심으로 설계돼 있습니다. 또 근거가 코드베이스에 있으면 에이전트가 직접 확인하도록 유도합니다. 그 결과, 추상적인 반론은 줄고 실제 계획 수립에 도움이 되는 압박 검토가 더 많이 나오는 편입니다.

grill-me는 소프트웨어 프로젝트 밖에서도 쓸 수 있는가?

그렇습니다. 다만 결정이 여러 갈래로 나뉘고 의존성이 중요한 제품, 기술, 프로세스 기획에서 가장 강합니다. 비기술적 기획에서는 살펴볼 코드베이스가 없기 때문에, 사용자가 더 많은 맥락을 직접 제공해야 합니다.

grill-me 스킬을 더 잘 활용하는 방법

브레인스토밍 조각이 아니라 의사결정 가능한 입력을 주기

grill-me를 개선해 쓰려면, 파고들 수 있을 만큼 구조화된 입력을 줘야 합니다. 이해관계자, 제약 조건, 일정, 리스크, 이미 결정된 사항을 포함하세요. 품질이 가장 크게 좋아지는 지점은 대개 트레이드오프를 명시할 때입니다. 예를 들어 speed vs reliability, flexibility vs simplicity, cost vs migration risk처럼 우선순위 충돌을 분명히 적어두면 질문의 질이 올라갑니다.

자주 발생하는 실패 패턴을 경계하기

가장 흔한 실패는 입력이 얕아서 질문도 얕아지는 경우입니다. 또 하나는 답변을 너무 넓게 해서 대화가 끝없이 퍼지는 경우입니다. 세 번째는 저장소가 답할 수 있는 질문을 어시스턴트가 계속 사용자에게 묻도록 두는 상황입니다. grill-me for Requirements Planning을 쓸 때는 다음처럼 방향을 다시 잡아주는 것이 좋습니다. “구현 표면에 대한 질문을 하기 전에, 현재 동작은 코드베이스를 먼저 확인해.”

첫 번째 라운드 이후에는 다시 한 번 돌리기

초기 라운드가 끝나면, grill-me에게 발견 단계에서 갭 분석 단계로 전환하라고 요청하세요. 좋은 후속 질문은 다음과 같습니다:

• “아직 구체화가 부족한 결정은 무엇인가?”
• “가장 위험해 보이는 가정은 무엇인가?”
• “암묵적으로 전제됐지만 명시되지 않은 요구사항은 무엇인가?”
• “확정된 답변들을 requirements checklist로 바꿔줘.”

이렇게 하면 단순한 질문 루프보다 훨씬 실용적인 결과를 얻을 수 있습니다.

필요한 산출물에 맞게 grill-me를 조정하기

grill-me skill 결과를 개선하는 가장 좋은 방법은 마지막에 원하는 산출물을 처음부터 분명히 정하는 것입니다. 예를 들어 spec outline, ADR inputs, delivery risks, go/no-go recommendation 중 무엇이 필요한지 먼저 말하세요. 질문 방식 자체는 비슷하지만, 어떤 디테일이 중요한지는 최종 목표에 따라 달라집니다. 끝에 원하는 산출물을 미리 밝혀두면 질문이 더 선별적으로 바뀌고, 세션 결과도 실제로 실행에 옮기기 쉬워집니다.