Copilot에서 바로 구현하지 말아야 하는 이유: grill-with-docs로 이슈부터 맞추는 순서 | DAKER 커뮤니티

에이전트에게 이슈 번호만 던지고 바로 구현을 맡기면, 작업은 빠르게 시작되지만 정작 원하는 결과와는 어긋나는 경우가 적지 않습니다. PR을 열어 보면 동작이 미묘하게 다르거나, 용어가 섞이거나, 리뷰어가 어디를 봐야 하는지 설명만 길어지는 일이 생깁니다.

GitHub 공식 채널의 GitHub Copilot Day 세션에서 Matt Pocock이 강조한 것도 바로 이 지점입니다. 구현을 먼저 시키는 대신, grill-with-docs로 이슈를 먼저 맞춘 뒤에 코드를 만지는 순서가 더 낫다는 이야기입니다.

이 세션의 핵심은 스킬 개수가 아니라 작업 순서입니다

영상 제목은 “25 agent skills”이지만, 발표의 중심은 스킬을 많이 설치하는 데 있지 않습니다. Matt Pocock은 자신의 오픈소스 모음 mattpocock/skills를 소개하고, 발표 당시 별이 약 25만 9천 개에 가깝다고 말합니다. 설치는 저장소 README 기준으로 npx skills@latest add mattpocock/skills 또는 Claude Code 플러그인으로 할 수 있습니다.

하지만 이 글에서 더 중요한 것은 설치 방법보다 흐름입니다. 발표가 보여 주는 순서는 구현 전에 정렬하고, PR을 사람이 보기 쉽게 만들고, 끝난 뒤 세션을 돌아보는 방식입니다. 영상에서 토큰 절감 같은 수치를 주장하지 않으므로, 여기서도 그런 숫자를 덧붙이지 않습니다.

핵심은 스킬을 많이 까는 것이 아니라 구현 전에 정렬하고, 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까지 함께 맞추는 흐름에 가깝습니다.

grill-with-docs는 코드를 쓰기 전에 범위와 용어를 먼저 맞추게 만드는 절차입니다.

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와 그릴링을 같이 쓰는 이유도 여기에 있습니다. 용어가 고정되면 변수와 파일 이름도 같은 단어를 쓰게 되어 이후 세션의 탐색 비용이 줄어듭니다.

대회·해커톤 저장소에서는 왜 더 중요할까

DAKER·DACON 대회 코드는 전처리, 학습, 제출 스크립트가 한 저장소에 섞여 있는 경우가 많습니다. 이런 구조에서 에이전트에게 점수만 올려 달라고 하면, 제출 포맷과 학습 설정을 한꺼번에 건드리기 쉽습니다.

이럴 때 grill-with-docs에 넣을 문장은 짧게 유지하는 편이 좋습니다. 예를 들어 제출 폴더 CSV 컬럼 순서만 대회 안내에 맞추고, 학습 하이퍼파라미터는 바꾸지 않는다고 적으면 오늘 범위와 비범위가 함께 드러납니다. 질문이 경로와 컬럼, 실행 명령 밖으로 새면 오늘은 다루지 않는다고 답하면 됩니다.

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

대회 저장소일수록 바로 코딩보다 먼저 범위와 비범위를 맞추는 절차가 중요합니다.

오늘 바로 적용할 수 있는 최소 흐름

처음부터 스킬 25개를 모두 쓰려 하기보다, 한 이슈에 필요한 흐름만 적용하는 편이 낫습니다. 먼저 mattpocock/skills를 설치하고, 저장소에서 /setup-matt-pocock-skills를 실행해 이슈 트래커와 문서 위치를 맞추면 됩니다.

그다음 오늘 고칠 이슈 하나만 고르고, 에이전트에게 바로 구현을 맡기지 말고 grill-with-docs로 그 이슈를 지정합니다. 질문이 나오면 오늘 범위와 비범위만 짧게 답하면 됩니다. PR이 생기면 Show Me 또는 비슷한 시각 요약으로 변경 위치를 확인하고, code-review로 Standards와 Spec을 한 번 점검합니다. 하루를 마칠 때는 Retro로 최근 세션을 돌아보고, 반복된 실패 문장 하나만 스킬이나 규칙 파일에 추가하면 충분합니다.

정리

Matt Pocock의 Copilot Day 세션이 반복해서 보여 주는 메시지는 에이전트를 더 많이 돌리자는 것이 아닙니다. 에이전트가 보기 전에 사람끼리 먼저 맞추자는 데 가깝습니다. grill-with-docs로 이슈를 정렬하고, Show Me와 code-review로 PR을 사람이 검토할 수 있게 만들고, Retro로 스킬을 고치는 흐름입니다.

구현은 시작점이 아니라, 이슈와 용어를 맞춘 다음 단계입니다.

오늘은 이슈 하나에 grill-with-docs를 한 번 걸어 보는 것만으로도 충분합니다.

참고 자료

25 agent skills to improve your workflow in GitHub Copilot | Matt Pocock | GitHub Copilot Day
전체 URL: https://www.youtube.com/watch?v=9yPyoxlyc5Q

스킬 저장소: https://github.com/mattpocock/skills

여러분은 에이전트에게 바로 구현을 맡기기 전에, 어떤 방식으로 범위와 비범위를 먼저 맞추고 계신가요?