AI 코딩 도구를 쓰다 보면 익숙한 패턴이 하나 있습니다. 한 줄 요청을 던지면 에이전트가 곧장 코드를 쏟아냅니다. 빠르지만, 정작 내 머릿속 계획에 뚫린 구멍은 그대로 남습니다. 데이터를 어디에 둘지, 경계 조건을 어떻게 처리할지 정하지 않은 채 구현부터 시작된 코드는 결국 다시 갈아엎게 됩니다

요즘 개발자들 사이에서 화제인 ‘Grill Me(그릴 미)’는 이 순서를 뒤집습니다. 만들기 전에 AI가 나를 먼저 취조합니다. 직역하면 “나를 닦달해 줘”인데, 정말 딱 그 역할만 하는 도구입니다. 흥미로운 건 이 스킬의 본문이 사실상 네 줄밖에 안 된다는 점입니다

‘Grill Me’가 뭔가 — 네 줄짜리 스킬

Grill Me는 TypeScript 교육으로 잘 알려진 개발자 Matt Pocock(맷 포콕)이 공개한 AI 스킬(skill) 입니다. 공개 직후 Hacker News를 비롯한 여러 채널에서 빠르게 퍼지며 바이럴을 탔습니다

여기서 스킬이란 Claude Code 같은 AI 코딩 에이전트에게 “이런 상황에서는 이렇게 행동하라”는 지침을 담아두는 짧은 마크다운 파일입니다. 파일 맨 위 front matter에 이름과 트리거 설명을 적고, 그 아래 본문에 실제 행동 지침을 적습니다. Grill Me가 유독 주목받은 건 그 본문이 거의 다음이 전부이기 때문입니다

---
name: grill-me
description: Interview the user relentlessly about a plan or design
  until reaching shared understanding, resolving each branch of the
  decision tree. Use when user wants to stress-test a plan, get grilled
  on their design, or mentions "grill me".
---

Interview me relentlessly about every aspect of this plan until we reach
a shared understanding. Walk down each branch of the design tree,
resolving dependencies between decisions one-by-one. For each question,
provide your recommended answer.

Ask the questions one at a time.

If a question can be answered by exploring the codebase, explore the
codebase instead.

이게 파일 전체입니다. 한국어로 옮기면 핵심은 네 가지입니다

  • 내 계획의 모든 측면을 집요하게 인터뷰할 것
  • 설계 트리의 가지를 따라 의존 관계를 하나씩 해결할 것
  • 질문은 한 번에 하나씩 던지고, 매번 추천 답안을 함께 제시할 것
  • 코드를 보면 답이 나오는 질문은 묻지 말고 직접 확인할 것

별도 도구 호출이나 복잡한 분기 로직이 없습니다. 그냥 평범한 영어 문장 몇 개를 에이전트에게 읽혀서 역할을 바꾸는 게 전부입니다. 그래서 설치 없이도 이 텍스트를 그대로 채팅에 붙여 넣어 흉내 낼 수 있습니다

동작 방식 — AI가 나를 거꾸로 면접한다

Grill Me를 켜면 AI의 입장이 뒤집힙니다. 평소엔 내가 질문하고 AI가 답했다면, 이제 AI가 면접관이 되어 나에게 질문을 던지기 시작합니다

Grill Me의 작동 흐름 — 질문 하나, 답변, 그리고 반복 그림 1. 계획을 입력하면 AI가 질문 하나에 추천 답안을 동봉해 던지고, 내가 답하거나 피드백을 주면 다음 가지로 넘어갑니다. 남은 가지가 없을 때까지 반복합니다

흐름을 지배하는 규칙은 세 가지입니다. 질문은 한 번에 하나씩만 나옵니다. 질문마다 AI가 자기 나름의 추천 답안을 함께 답니다. 내가 답하거나 피드백을 주면 그 결정에 딸린 다음 가지로 이동합니다

추천 답안을 같이 주는 게 체감상 가장 큰 차이입니다. 답이 뻔한 질문이라면 길게 설명할 필요 없이 “응, 그걸로”만 해도 넘어갑니다. 실제 대화는 대략 이런 모양입니다

AI: 댓글 데이터는 어디에 저장하실 건가요?
    추천: 이미 쓰는 Postgres에 comments 테이블을 추가. 별도 스토어를
    들이는 것보다 운영이 단순하고, 글-댓글 조인도 한 DB 안에서 끝납니다.

나: 응, 그걸로.

AI: 그러면 댓글의 부모를 post_id 하나로 둘까요, 아니면 대댓글까지
    감안해 parent_comment_id도 둘까요?
    추천: 지금은 1단계 댓글만 받기로 했으니 post_id만. 트리 구조는
    나중에 컬럼 추가로 확장. 미리 넣으면 안 쓰는 인덱스만 늘어납니다.

나: 대댓글도 곧 필요할 것 같아. parent_comment_id 같이 두자.

AI: 알겠습니다. 그러면 삭제된 부모 댓글의 자식은 어떻게 처리할까요?
    ...

만든 사람 말로는 이런 취조 한 세션이 보통 45분쯤 이어진다고 합니다. 끝나고 나면 내 아이디어와 까다로운 결정들에 대한 답이 가득 담긴, 맥락이 풍부한 대화록이 남습니다. 이 대화록 자체가 다음 단계의 입력이 됩니다

왜 이렇게 설계됐나 — 세 문장의 트레이드오프

네 줄짜리 스킬이지만 각 지침에는 분명한 의도가 있습니다

“한 번에 하나씩” 은 인지 부하를 묶어두기 위한 장치입니다. 질문 열 개를 한꺼번에 받으면 사람은 가장 쉬운 것부터 답하고 어려운 결정은 미룹니다. 하나씩 강제하면 의존 관계를 순서대로 풀 수 있습니다. 앞 결정이 정해져야 뒤 질문의 선택지가 좁혀지기 때문입니다. 댓글을 어디 저장할지 정해야 대댓글 스키마 질문이 의미를 갖는 식입니다

“매번 추천 답안” 은 빈 종이 공포를 없애기 위한 장치입니다. 열린 질문만 계속 받으면 대화가 느려지고, 결정이 어려운 곳에서 멈춰버립니다. 추천안이 있으면 동의는 한 단어로 끝나고, 이견이 있을 때만 에너지를 씁니다. 다만 이 장치에는 대가가 따르는데, 마지막 섹션에서 따로 다룹니다

“코드로 답이 나오면 직접 확인” 은 사용자의 시간을 아끼기 위한 장치입니다. “이 프로젝트는 무슨 테스트 러너를 쓰나요?” 같은 질문은 package.json을 열면 1초에 답이 나옵니다. 이런 걸 사람에게 물으면 면접이 사무적인 받아쓰기로 전락합니다. 그래서 답할 수 있는 건 에이전트가 직접 코드베이스를 뒤져 채우고, 사람에게는 코드만으로 알 수 없는 의도와 판단만 묻습니다

사실은 ‘AI판 러버덕’

개발자라면 러버덕 디버깅(rubber duck debugging) 을 들어봤을 겁니다. 책상 위 고무 오리에게 내 코드와 계획을 소리 내어 설명하다 보면, 누가 답을 주지 않아도 스스로 허점을 발견하게 된다는 오래된 방법입니다

Grill Me는 그 오리를 말대꾸하는 오리로 바꿔놓은 셈입니다. 혼자 떠드는 게 아니라, 끈질기게 되묻는 상대와 함께 빈틈을 메워갑니다. 차이는 분명합니다. 고무 오리는 내가 설명을 멈추는 순간 같이 멈추지만, Grill Me는 내가 얼버무리고 넘어가려는 지점을 정확히 다시 파고듭니다

설치와 실행 — 명령어 한 줄

스킬은 GitHub에 공개돼 있고, 터미널 명령 한 줄로 전역 설치할 수 있습니다

npx skills add mattpocock/skills --skill=grill-me -y -g

-g는 전역(global) 설치라 어느 프로젝트에서든 쓸 수 있게 해주고, -y는 확인 프롬프트를 건너뜁니다. 맷 포콕의 스킬 모음 전체를 한 번에 받고 싶다면 이렇게 씁니다

npx skills@latest add mattpocock/skills

설치한 뒤에는 계획을 설명하고 “grill me”라고 말하면 됩니다. front matter의 description에 적힌 트리거 문구(“mentions grill me”)가 이 호출을 잡아줍니다. 앞서 봤듯 스킬 본문이 그대로 노출돼 있으니, 설치가 번거롭다면 그 텍스트를 직접 .claude/skills/grill-me/SKILL.md로 만들어도 똑같이 동작합니다

제대로 켜졌는지는 첫 몇 턴으로 바로 확인됩니다. 질문이 한 번에 하나씩만 오는지, 각 질문에 추천 답안이 붙는지, 그리고 “테스트 러너가 뭐냐” 같은 코드로 답할 수 있는 질문 대신 의도를 묻는 질문이 오는지를 보면 됩니다. 만약 AI가 질문 목록을 한꺼번에 쏟아내거나 곧장 코드를 짜기 시작하면 스킬이 안 걸린 겁니다

언제 쓰면 좋은가

만든 사람이 권하는 활용 시점은 이렇습니다

  • PRD(제품 요구사항 정의서)를 작성하기 전
  • AI 에이전트에게 기능 구현을 통째로 맡기기 전
  • 데이터 모델이나 API 구조를 확정하기 전
  • 여러 설계 결정이 서로 얽혀 어디부터 풀지 모를 때
  • AI가 무작정 동의하지 말고 반박해 주길 원할 때

코딩 밖에서도 쓸 수 있습니다. 맷 포콕 본인은 “다음에 어떤 강의를 만들까” 같은 결정도 이 스킬로 AI와 토론한다고 합니다. 계획·기획·아이디어 정리라면 분야를 크게 가리지 않습니다. 결국 “결정을 내리기 전에 누군가 옆에서 캐물어주면 좋겠다” 싶은 모든 상황이 대상입니다

만든 사람도 지금은 다르게 쓴다 — 워크플로 속 위치

흥미로운 업데이트가 하나 있습니다. 맷 포콕은 최근 코딩 작업에서는 Grill Me 대신 domain-model이나 grill-with-docs 같은 다른 스킬을 권한다고 밝혔습니다

AI 계획 워크플로 속 grill-me의 위치 그림 2. 코딩 작업의 권장 흐름은 domain-model → to-prd → to-issues → tdd. grill-me는 코드 정합성 점검 없이 계획만 가볍게 압박하고 싶을 때의 대안으로 빠집니다

이유는 Grill Me의 설계 범위에 있습니다. Grill Me는 순수하게 “계획을 캐묻는” 데만 집중하는 가벼운 도구입니다. 코드를 직접 뒤져 답할 수 있는 질문은 스스로 해결하지만, 그 계획이 내 코드베이스의 용어·구조·과거 결정과 잘 맞물리는지까지 끌어와 검증하지는 않습니다. 실제 코딩에서는 바로 그 정합성이 중요하기 때문에, 추천 워크플로가 다음처럼 정리됐습니다

domain-model  →  to-prd  →  to-issues  →  tdd
(코드 정합성)     (요구사항)    (작업 분할)     (테스트 주도 구현)

domain-model은 계획을 코드베이스의 실제 도메인 용어·구조와 맞춰보는 단계라, Grill Me보다 한 단계 무겁습니다. 그렇다고 Grill Me가 한물간 건 아닙니다. “코드베이스 점검까지는 필요 없고 계획만 집요하게 압박받고 싶다”면, 여전히 가볍게 꺼내 쓰기 좋은 도구로 남아 있습니다

마냥 좋기만 할까 — ‘추천 답안’의 함정

반론도 있습니다. 한 개발자 블로거는 Grill Me의 추천 답안 방식이 오히려 사고를 좁힐 수 있다고 지적했습니다

행동경제학의 선택 설계(choice architecture) 개념을 빌린 비판입니다. AI가 질문과 선택지, 추천안까지 미리 깔아주면 사용자는 그 틀 안에서만 생각하게 됩니다. 결국 AI가 학습한 가장 흔한 답으로 수렴하면서, “내가 주도적으로 결정했다”는 착각만 키울 수 있다는 우려입니다. 앞서 빠른 동의가 장점이라고 했던 바로 그 추천 답안이, 뒤집으면 가장 큰 위험이 되는 셈입니다

함정은 구체적입니다. 추천안이 그럴듯할수록 의심 없이 통과시키기 쉽고, 정작 “이 선택지 말고 제3의 방법은 없나”라는 질문은 영영 떠오르지 않습니다. 면접의 주도권이 어느새 면접관에게 넘어가 있는 것입니다

핵심은 운전대를 누가 잡느냐
AI의 질문에 끌려다니지 않고, 추천 답안도 한 번씩 의심하며 내 판단을 더한다면 Grill Me는 분명 쓸 만한 도구입니다. 추천안을 그대로 받아 적기 시작하는 순간, 도구는 사고의 보조에서 사고의 대체로 바뀝니다

마무리

Grill Me의 인기는 한 가지를 보여줍니다. 좋은 AI 활용은 더 긴 프롬프트가 아니라 AI의 역할을 바꾸는 짧은 한 수에서 나온다는 점입니다. 정작 화제가 된 스킬의 본문은 네 줄이었습니다

만들기 전에 한 번 제대로 닦달당해 보는 것, 그리고 그 닦달에 끌려다니지 않고 운전대를 쥐고 있는 것. 이 둘을 같이 챙긴다면 생각보다 큰 차이를 만들어 줍니다

참고 출처