'Grill'이라는 단어를 들으면 맛있는 바비큐가 먼저 떠오르시죠? 하지만 영어권에서는 누군가를 '깐깐하게 심문하다, 꼬치꼬치 캐묻다'라는 의미로도 자주 쓰입니다.

AI에게 다짜고짜 코드나 결과물을 내놓으라고 하는 대신 /grill-me 스킬을 호출하면, AI가 바로 구현에 들어가는 대신 깐깐한 시니어 사수처럼 내 기획의 빈틈과 예외 상황을 하나씩 짚으며 집요하게 질문하기 시작합니다.

그런데 여기서 재미있는 점이 있습니다. AI가 무작정 질문만 던지고 답을 기다리는 것은 아닙니다. 각 질문마다 자신이 생각하는 추천 답변도 함께 제시하기 때문에, 사용자는 백지상태에서 답을 쥐어짤 필요 없이 "이 방향이 맞아", "우리 서비스에서는 이렇게 해야 해"라고 쉽게 결정할 수 있습니다.

또한, 기존 코드베이스나 구조를 살펴보면 답이 나오는 내용은 굳이 묻지 않고 알아서 파악합니다. 즉, Grill의 핵심은 무작정 질문을 쏟아내는 것이 아니라 정말 결정이 필요한 엣지 케이스만 사람에게 물어보며 구현 전 계획을 다듬어가는 것입니다.

특정 기능부터 큰 설계까지, 구현 전에 계획의 빈틈을 빠르게 검증하고 싶을 때 유용합니다. 별도의 문서나 프로젝트 컨텍스트를 남기지 않고, 대화 안에서 계획의 빈틈을 검증할 수 있습니다.

[다크모드 토글 버튼 구현]

• 🚨 바로 구현 요청 시: 시스템 테마나 초기 렌더링 시 테마 결정 방식이 명확하지 않아, 페이지 진입 순간 의도하지 않은 테마가 잠깐 노출되는 문제가 생길 수 있습니다. SSR 환경에서는 테마 초기값과 클라이언트 상태가 어긋나 하이드레이션(Hydration)* 관련 문제가 발생할 수도 있습니다.
• 🎯 /grill-me 적용 시: AI가 먼저 OS 설정(시스템 테마) 연동 여부 및 깜빡임 방지 대책을 묻고 탄탄한 설계를 논의합니다.

[토스트(Toast) 알림 구현]

• 🚨 바로 구현 요청 시: 토스트의 최대 노출 개수, 표시 시간, 긴 메시지 처리, 중복 알림 처리 등의 정책이 정의되지 않은 채 구현될 수 있습니다.
• 🎯 /grill-me 적용 시: 최대 노출 개수, 메시지 길이에 따른 표시 시간, 중복 알림 처리, 사용자의 상호작용에 따른 자동 닫힘 여부 등을 먼저 질문하고 합의할 수 있습니다.

[검색창 자동완성 UI 구현]

• 🚨 바로 구현 요청 시: 타이핑마다 API 요청이 발생하는 구현이 만들어질 수 있고, 키보드만으로 결과 목록을 탐색하거나 선택할 수 있는 방법이 빠질 수 있습니다.
• 🎯 /grill-me 적용 시: API 호출 낭비를 막기 위한 디바운스(Debounce)* 적용 여부뿐 아니라, 키보드 탐색, 결과가 없을 때의 상태, 로딩 상태, 검색 결과 선택 방식 등을 차례로 확인하며 구현 전에 합의할 수 있습니다.

위의 훌륭한 시나리오들처럼 기획을 바싹 구워내려면 한 가지 꼭 명심해야 할 점이 있습니다. 저 역시 이번 실험을 처음 시작할 때는 아무 생각 없이 아주 짧은 한 줄을 입력해 보았는데요.

"/grill-me 다크모드 토글 버튼 만들어줘."

그런데 웬걸, 엔터를 친 순간 어마어마한 질문 지옥이 열렸습니다.

어떠한 상세 명세도 없이 단순히 명령 프롬프트를 내렸더니, AI는 요구사항이 명확해질 때까지 기초적인 질문부터 압박해 들어왔습니다. 1라운드에서 무려 5가지의 질문이 날아왔고, 열심히 대답했더니 2라운드에서 7개의 꼬리 질문이 추가됐습니다. 그걸 또 방어했더니 3라운드에서 4개의 질문을 더 받으며 총 16개의 질문 세례를 받아야 했죠.

/grill-me는 빈틈을 찾는 도구이기 때문에, 초기 단서가 너무 없으면 'UI 형태'부터 '상태 관리', '저장 방식', '접근성'까지 A to Z를 전부 물어보며 질문 폭탄을 던집니다. 즉, /grill-me를 쓸 때도 막연한 명령보다는, "최소한의 기본적인 요구사항(명세)은 갖춰서 던져야, 정말 중요한 기획의 빈틈에만 집중해서 바싹 구워준다" 는 것입니다.

만약, 이미 작업 중인 코드베이스가 있고, 이번 논의에서 정한 용어와 의사결정 기준을 앞으로도 계속 유지해야 한다면 /grill-with-docs가 더 적합합니다.

이 스킬은 /grilling 세션을 통해 집요하게 질문하며 계획을 검증하고, 동시에 /domain-modeling을 활용해 프로젝트의 용어와 의사결정을 정리합니다. 질문을 통해 기획을 검증하는 동시에, 합의된 프로젝트 용어나 아키텍처 결정(ADR)*을 CONTEXT.md 문서에 기록합니다. 이는 다음에 AI가 작업을 이어갈 때도 프로젝트의 결정사항과 용어를 참고할 수 있는 근거로 남습니다.

즉 grill-with-docs의 가치는 AI의 기억력을 마법처럼 늘리는 것이 아니라, AI가 다시 참고할 수 있는 외부화된 프로젝트 컨텍스트를 만드는 것입니다

'디자인 토큰 네이밍'이나 '폴더 구조 분리 기준' 같은 중요 룰을 논의할 때 사용하면, 며칠 뒤 AI가 예전 버릇처럼 엉뚱한 이름의 파일을 맘대로 만들어내는 대참사를 막을 수 있습니다. 문서화가 필수적인 규모 있는 작업에 찰떡이죠.

👍 진짜 시니어 사수와 일하는 기분: 제가 놓쳤거나 꼼꼼히 세우지 못했던 기획의 구멍을 찾아냅니다. 결과적으로 구현 이후에 뒤늦게 코드를 뒤엎는다든지, 요구사항을 수정하는 일을 줄이는 데 도움이 됐어요.

👍 길을 잃지 않는 프로젝트의 나침반: /grill-with-docs는 기능이 복잡해질수록 진가를 발휘합니다. 프로젝트의 룰과 컨텍스트가 차곡차곡 쌓이면서, AI가 이후 작업에서 참고할 수 있는 프로젝트의 공통 맥락이 만들어집니다.

🤔 주의할 점(한계): 당장 5분 안에 코드를 뽑아내야 하는 급박한 상황에서는 꼬리물기식 역질문이 다소 번거롭게 느껴질 수 있습니다. 또한, 역질문에 제대로 대답하려면 실무자 본인도 명확한 기획 의도와 도메인 지식을 쥐고 있어야 해요. 무작정 "알아서 예쁘게 잘 짜줘"라는 마인드로는 이 깐깐한 스킬을 100% 활용하기 어렵습니다. 또한 Grill이 던지는 질문 자체가 항상 정답을 의미하는 것은 아닙니다. AI가 제시하는 선택지와 추천안 역시 하나의 제안일 뿐이므로, 최종적인 제품 정책과 기술적 결정은 사람이 판단해야 합니다.