에이전트에게 바로 코드를 시키지 않습니다 — 오늘 Copilot에서 grill-with-docs로 이슈부터 맞추십시오 | DAKER 커뮤니티

에이전트에게 “이슈 1612 고쳐 주십시오”라고 바로 보내는 순간, 파일은 이미 바뀌기 시작합니다. 화면에는 진행이 빠르게 쌓이고, 잠깐은 일이 끝난 것처럼 보입니다. 그런데 PR을 열어 보면 원한 동작이 아니거나, 용어가 제각각이거나, 리뷰어가 어디를 봐야 할지 글로만 길어집니다. GitHub 공식 채널의 GitHub Copilot Day 세션에서 Matt Pocock은 그 앞에서 순서를 바꾸라고 말합니다. 바로 구현을 시키지 말고, 먼저 grill-with-docs로 이슈를 맞춘 뒤에야 코드를 만지라는 것입니다.

grill-with-docs로 이슈부터 맞춥니다
설명용 생성 이미지입니다.

영상이 말하는 것, 말하지 않는 것

영상 제목은 “25 agent skills”이지만, 발표가 붙잡는 축은 스킬 개수 자랑이 아닙니다. 발표자는 자신의 오픈소스 모음 mattpocock/skills를 소개하며, 발표 당시 별이 약 25만 9천 개에 가깝다고 말합니다. 설치는 저장소 README 기준으로 npx skills@latest add mattpocock/skills 또는 Claude Code 플러그인으로 할 수 있습니다. 다만 오늘 글의 핵심은 “스킬을 많이 까는 것”이 아니라, 구현 전에 정렬하고, PR을 사람이 볼 수 있게 만들고, 끝난 뒤 세션을 돌아보는 순서입니다. 토큰을 몇 퍼센트 줄인다는 식의 숫자는 영상에서 주장하지 않으므로 여기서도 만들지 않습니다.

왜 grill-with-docs가 먼저인가

발표자는 메인 흐름의 출발점으로 grill-with-docs를 둡니다. 에이전트가 아직 코드를 쓰기 전에, 서브에이전트로 저장소를 탐색한 뒤 사용자에게 질문을 던져 공유 이해를 만드는 절차입니다. 라이브 데모는 본인이 쓰는 course video manager 저장소의 GitHub 이슈 1612였습니다. Copilot에서 이슈에 들어가 워크트리(W)를 연 다음, grill with docs issue 1612라고만 보냈습니다. 이슈 내용은 CLI에 기능을 더하는 일이었고, 에이전트는 hierarchy selector 지원 범위 같은 선택을 물었습니다. 답을 맞춘 뒤에야 구현으로 넘어가 PR이 생겼습니다.

여기서 중요한 점은 “질문이 많으면 무조건 좋다”가 아닙니다. 해커톤·대회 저장소처럼 제출 기한이 가까운 곳일수록, 에이전트가 학습 코드와 제출 포맷을 한꺼번에 건드리는 실수를 줄이려면 오늘 끝낼 범위와 건드리지 않을 범위를 먼저 말로 고정해야 합니다. grill-with-docs는 그 고정을 질문 형태로 강제합니다. Cursor Plan Mode가 계획 문서를 받는 축이라면, 이 스킬은 이슈·도메인 용어·문서(CONTEXT.md·ADR)까지 같이 맞추는 축입니다.

PR을 사람이 보게 만드는 Show Me와 code-review

정렬 다음으로 영상이 강조하는 것은 리뷰 비용입니다. Dexter Horthy(HumanLayer Skills)의 Show Me 스킬은 PR을 글 더미로 두지 않고, 의사코드·호출 트리·프론트 UI 구조 같은 HTML 시각 산출물로 보여 줍니다. 발표자는 “사람이 시간을 쓸 가치가 있는 PR”을 만들자고 말합니다. 이어서 code-review 스킬은 origin main을 기준점으로 diff를 잡은 뒤, 저장소의 코딩 표준·CLAUDE.md를 읽고 Standards와 Spec 두 축을 서로 다른 서브에이전트로 병렬 검사합니다. 컨텍스트가 분리되므로, 구현 대화에 쌓인 선입견을 줄인 채 “표준을 지켰는지”와 “스펙을 지켰는지”를 따로 봅니다. 데모에서는 스펙 쪽 소견이 없었고, 표준 쪽에서 중복 설정 같은 판단이 나왔습니다.

구현·아키텍처·회고로 이어지는 흐름

더 큰 변경에서는 improve-codebase-architecture로 심화 후보 리포트를 받고, 필요하면 평이한 문장으로 다듬은 뒤 스펙·티켓으로 나눕니다. implement spec은 티켓 의존성을 매핑하고 초안 PR을 연 다음, 서로 독립인 티켓은 워크트리·브랜치에서 병렬로 구현한 뒤 다시 합칩니다. 마지막에 소개된 새 스킬 Retro는 최근 네 개 세션을 읽어 회고합니다. Copilot처럼 세션 이력에 접근할 수 있는 에이전트라면, “PR 베이스 브랜치를 헷갈렸다”, “도구 호출이 비효율적이다”처럼 스킬 자체를 고칠 단서를 세션에서 건집니다. 설치만 하고 끝내는 것이 아니라, 흐름을 돌린 뒤 스킬 문구를 고치는 순환이 목표입니다.

설치만 하고 끝내지 않는 이유

스킬 파일을 저장소에 복사하는 순간, 에이전트는 그 문장을 읽을 수 있게 됩니다. 그런데 팀이 이슈 트래커·문서 위치·라벨을 맞춰 두지 않으면, grill-with-docs가 물어보는 질문이 프로젝트 밖 일반론으로 흐르기 쉽습니다. 그래서 저장소 README도 설치 직후 /setup-matt-pocock-skills를 한 번 돌리라고 적습니다. 이슈를 GitHub에 둘지, 로컬 파일로 둘지, 도메인 문서를 어디에 둘지를 먼저 정하면, 이후 그릴링·티켓·회고가 같은 주소를 바라봅니다.

발표 데모처럼 이슈 번호를 스킬에 그대로 넘기는 습관도 도움이 됩니다. “CLI에 뭔가 추가해 주십시오”보다 “issue 1612에 grill-with-docs”가 범위가 분명합니다. 대회 이슈 보드가 있다면, 오늘 카드 하나에만 그 형식을 적용해 보십시오. 카드 제목에 비범위를 한 줄 적어 두면, 에이전트가 학습 코드를 건드리는 질문을 줄일 수 있습니다.

팀으로 쓸 때는 그릴링 답변을 이슈 댓글이나 짧은 ADR로 남겨 두십시오. 다음 사람이 같은 이슈를 열었을 때, 에이전트가 이미 합의한 범위·비범위를 다시 읽게 할 수 있습니다. 이것이 CONTEXT.md와 그릴링을 같이 쓰는 이유입니다. 용어가 고정되면 변수·파일 이름도 같은 단어를 쓰게 되어, 이후 세션의 탐색 비용이 줄어듭니다.

오늘 바로 할 일

  1. 쓰는 코딩 에이전트(GitHub Copilot·Claude Code·Codex 등)에 mattpocock/skills를 설치합니다. README의 npx skills@latest add mattpocock/skills 또는 Claude 플러그인 중 하나만 고릅니다.
  2. 저장소에서 한 번 /setup-matt-pocock-skills를 실행해 이슈 트래커·문서 위치를 맞춥니다.
  3. 오늘 고칠 이슈 하나만 고릅니다. 예: 제출 CSV 컬럼 순서, 평가 스크립트 연결, README 실행 명령, CLI 플래그 하나.
  4. 에이전트에게 바로 “구현해 주십시오”를 보내지 말고, grill-with-docs로 그 이슈를 지정합니다. 질문이 나오면 오늘 범위·비범위만 짧게 답합니다.
  5. PR이 생기면 Show Me 또는 동등한 시각 요약으로 변경 위치를 확인한 뒤, code-review로 Standards·Spec을 한 번 돌립니다.
  6. 하루를 마칠 때 Retro로 최근 세션을 돌아보고, 반복된 실패 문장 하나만 스킬·규칙 파일에 추가합니다.

grill-with-docs는 더 화려한 한 방이 아닙니다. 에이전트가 만질 범위와 용어를 사람이 먼저 고르는 절차입니다. 대회·해커톤 저장소처럼 사람이 여러 명이고 제출 시간이 정해진 곳일수록, “바로 코딩”보다 “질문으로 맞추기 → 시각 PR → 리뷰 → 회고” 순서가 안전합니다. 오늘은 이슈 하나에 grill-with-docs만 걸어 보십시오.

대회·해커톤 저장소에 옮기는 방법

DAKER·DACON 대회 코드는 전처리, 학습, 제출 스크립트가 한 저장소에 섞여 있는 경우가 많습니다. 이런 구조에서 에이전트에게 “점수만 올려 주십시오”라고 하면, 제출 포맷과 학습 설정을 한꺼번에 건드리기 쉽습니다. grill-with-docs에 넣을 문장은 짧게 유지하십시오. 예: “제출 폴더 CSV 컬럼 순서만 대회 안내에 맞추고, 학습 하이퍼파라미터는 바꾸지 않습니다.”처럼 오늘 범위와 비범위를 같이 적습니다. 질문이 경로·컬럼·실행 명령 밖으로 새면, 오늘은 다루지 않는다고 잘라 답하면 됩니다.

PR이 열린 뒤에는 Show Me류 시각 산출물로 “어느 파일이 제출 경로인지”를 먼저 확인합니다. code-review의 Spec 축에는 대회 안내 문장이나 이슈 본문을 기준으로 두고, Standards 축에는 팀의 포맷·린트 규칙을 둡니다. 독립된 작업(문서 수정과 스크립트 수정처럼 서로 안 막는 일)만 implement spec식 병렬 워크트리를 쓰고, 점수 실험은 다음 이슈·다음 세션으로 넘기십시오.

오늘 하지 말아야 할 것

스킬 25개를 하루 만에 다 설치하고 전부 켜 두지 마십시오. 영상도 메인 흐름부터 보여 줍니다. 한 이슈에 구현·리팩터·문서·점수 실험을 한꺼번에 넣지 마십시오. grill-with-docs를 켠 뒤에도 질문을 건너뛰고 바로 코딩을 재촉하면, 정렬 절차가 형식만 남습니다. Show Me 결과만 보고 사람 diff를 안 보는 것도 위험합니다. 시각 자료는 리뷰를 돕는 도구이지, 병합 승인 자체가 아닙니다. Retro 없이 같은 실패를 다음 이슈에 반복하는 것도 피하십시오. 세션 이력에 이미 단서가 있는데 스킬 문구를 고치지 않으면, 다음 에이전트도 같은 구멍을 밟습니다.

정리

Matt Pocock의 Copilot Day 세션이 반복하는 말은 “에이전트를 더 많이 돌린다”가 아니라 “에이전트가 보기 전에 사람과 맞춘다”입니다. grill-with-docs로 이슈를 정렬하고, Show Me와 code-review로 PR을 사람이 검토할 수 있게 만들고, Retro로 스킬을 고칩니다. 오늘은 이슈 하나, grill-with-docs 한 번이면 충분합니다. 구현은 그다음입니다.

출처