Matt Pocock의 AI 에이전트 소통법: 요구사항을 구체화하고 검증하는 방법

Matt Pocock의 공식 자료로 정리해 보면, AI 에이전트 소통법의 핵심은 세 가지예요. 아직 정하지 않은 결정을 질문으로 찾아내고, 용어의 뜻을 맞추고, 실행 결과를 직접 확인하는 능력입니다. 원하는 기능을 전달하는 것으로 끝나지 않습니다. 무엇을 만들지, 어떤 상태를 완료로 볼지 구체화하는 과정까지 소통에 들어가요. 사람과 에이전트가 같은 요구사항을 기준으로 움직이려면 이 흐름이 끊기지 않아야 합니다.

제가 먼저 보라고 권하는 건 프롬프트의 길이가 아니라 아직 결정되지 않은 부분입니다. 설명을 길게 써도 작업 범위나 완료 기준이 비어 있으면, 에이전트는 그 자리를 자기 해석으로 채울 수 있어요. 그래서 처음부터 완벽한 지시문을 쓰려고 애쓰기보다는, 질문으로 불확실한 부분을 끄집어내고 합의한 내용을 검증 가능한 기준으로 바꾸는 쪽이 낫다고 봅니다.

질문으로 빈틈 찾기: 무엇부터 정해야 할까

Pocock의 공식 /grill-me 안내에 따르면, 완성된 계획이 없어도 막연한 아이디어만 가지고 대화를 시작할 수 있습니다. 에이전트가 묻고 사용자가 답하는 사이에 필요한 결정이 하나씩 구체화되는 방식이에요. 여기서 봐야 할 건 질문이 몇 개였느냐가 아닙니다. 답변을 거치며 모호함이 얼마나 줄었는지가 중요해요.

시작 단계에서는 해결할 문제와 이번 작업의 범위부터 정하세요. 무엇이 불편하고 어디까지 바꿀지가 잡혀 있어야, 뒤이어 나오는 질문이 목표에 필요한 결정인지 가려낼 수 있습니다. 세부 기능부터 이야기하면 당장 필요 없는 요구까지 슬그머니 끼어들기 쉽거든요. 범위가 불어났다고 느껴지면 처음 풀려던 문제로 돌아가 우선순위를 다시 맞추면 됩니다.

모르는 부분은 모른다고 답해도 괜찮아요.

흔히 빠지는 함정은 질문마다 동의만 하는 상황이고, 공식 안내도 이 점을 경계합니다. 그럴듯한 제안을 모두 승인하다 보면 내 요구를 구체화하는 게 아니라 에이전트의 계획을 고스란히 받아들이는 셈이 될 수 있어요. 확정한 요구와 더 확인해야 할 내용을 나눠 두고, 필요 없는 제안에는 이번 범위에서 빼겠다고 분명히 답하는 게 좋습니다. 반대로 아이디어가 이미 충분히 구체적이라면, 질문을 계속 이어가는 것 자체를 목표로 삼을 이유는 없습니다.

같은 단어, 다른 뜻: 용어와 결정의 배경 남기기

설명을 위해 ‘회원 탈퇴’ 기능을 예로 들어 볼게요. 똑같이 탈퇴라고 불러도 로그인 차단, 개인정보 삭제, 유료 구독 해지 가운데 무엇을 포함하느냐에 따라 구현할 동작이 완전히 달라집니다. 그러니 ‘탈퇴를 구현해 달라’고 요청하기 전에, 무엇을 포함하고 무엇을 따로 처리할지부터 합의해야 해요. 용어의 뜻을 맞추는 일이 곧 작업 범위를 정하는 일인 셈입니다.

/grill-with-docs는 이 질문 과정을 프로젝트 문서와 이어 줍니다. 공식 저장소에서는 공통 용어를 모아 두는 GLOSSARY.md와 설계 결정의 배경을 남기는 ADR을 안내하고 있어요. ADR은 주요 설계 선택과 그 이유를 적어 두는 문서라고 이해하면 충분합니다. 이렇게 기록하는 목적은 단순해요. 나중 작업에서 같은 용어를 다르게 해석하거나, 왜 그렇게 결정했는지를 잊어버리지 않도록 필요한 맥락을 붙잡아 두는 것입니다.

합의한 내용이 실제로 돌아가는지 확인하기

Pocock은 에이전트가 결과를 확인하는 피드백 수단으로 정적 타입, 자동화 테스트, 브라우저 접근을 제시합니다. 실제 작업에 적용한다면 타입 검사로 코드의 타입 오류를 먼저 살피고, 자동화 테스트로 합의한 동작을 확인한 뒤, 브라우저에서 사용자 흐름을 점검하는 순서로 짤 수 있어요. 이 순서는 공식 자료가 제시한 수단을 실무에서 엮어 본 구성입니다.

앞의 회원 탈퇴 예시로 돌아가면, 기능 이름만 보고 완료라고 판단하기는 어렵습니다. 합의한 범위의 동작이 실제로 일어나는지 봐야 해요. 여기서 많이들 헷갈리는데, 타입 검사를 통과했다는 사실과 사용자 요구를 충족했다는 판단은 서로 다른 근거를 필요로 합니다.

명세를 버리자는 이야기가 아닙니다

Pocock의 접근을 ‘명세를 쓰지 말자’는 주장으로 읽기는 어렵습니다. 공식 스킬 저장소에는 대화를 명세로 정리하는 /to-spec과, 그 명세를 구현하는 /implement-spec이 들어 있거든요. 질문으로 요구사항을 다듬고, 명세로 정리하고, 구현과 검증으로 넘기는 흐름에 초점을 두고 읽는 편이 맞다고 봅니다.

명세를 써 두었다고 합의가 끝난 건 아니에요. 명세 속 용어가 구현에서도 같은 뜻으로 쓰이는지, 완료 기준을 테스트나 실제 화면에서 확인할 수 있는지까지 살펴야 비로소 연결이 됩니다.

안내 자료마다 문서명과 스킬의 세부 동작에 차이가 있으니, 적용할 때는 설치한 버전의 공식 문서를 기준으로 확인하세요.