코딩 에이전트에게 일을 맡기는 세 가지 방법: 명세, 제품 모델, 새로운 눈의 리뷰

엉뚱한 것을 내놓는 코딩 에이전트는 대개 요청은 이해했지만 제품을 오해한 것입니다. 2026년 말의 흥미로운 질문은 더 이상 어떤 에이전트를 쓰느냐가 아니라 어떻게 지시하느냐이며, 서로 다른 세 가지 답이 나왔습니다. 차이는 한 가지입니다. 무엇을 문서로 남기고, 그것이 얼마나 오래 유지되느냐입니다.

명세 중심: 변경마다 문서 하나

가장 많이 채택된 방식은 기능마다 명세를 쓰고, 이어서 계획과 작업 목록을 쓴 다음, 에이전트가 이를 기준으로 만들게 합니다. Spec Kit(4.3)은 GitHub의 버전으로, 별 약 143,000개를 받았고 구현을 문서와 대조하는 수렴 단계가 있으며, 이름이 명시된 40개가 넘는 에이전트를 지원합니다. BMAD-METHOD(3.8)는 여러 페르소나를 두고 비슷한 영역을 다룹니다. 장점은 계약이 git에 남고 코드처럼 풀 리퀘스트를 거친다는 점입니다. 비용은 읽는 시간입니다. Scott Logic이 공개한 시험에서는 사람의 검토에 기능당 약 2시간에서 3시간 30분이 들었으며, 그래서 두 도구 모두 작은 수정을 위한 가벼운 경로를 제공합니다.

제품 중심: 계속 유지되는 모델 하나

더 새로운 학파는 명세가 제품이 아니라 변경을 설명하기 때문에 제품이 계속 처음부터 재구성된다고 주장합니다. pdd-kit(3.7)는 엔터티, 사용자 여정, 비즈니스 규칙, 변형으로 이루어진 git 추적 제품 모델 하나를 유지하며, 모든 에이전트가 추측 대신 이를 읽고, 검증 단계에서 코드를 모델과 대조합니다. 명세 폴더보다 날카로운 아이디어지만 아직 초기 단계입니다. 별은 약 97개이고 관리자는 한 명이며, 코드보다 뒤처진 모델은 모델이 아예 없는 것보다 에이전트를 더 크게 오도합니다. 실제 도메인 복잡성이 있는 제품에서는 효과가 있지만 CRUD 앱에서는 아닙니다.

리뷰 우선: 새로운 눈이 허점을 찾게 하기

세 번째 방식은 초안을 쓴 에이전트가 자기 맹점을 놓친다는 것을 인정하고, 대화를 본 적 없는 리뷰어를 투입합니다. Google의 오픈소스 플러그인인 Elephant-Goldfish Model(4.2)은 깊은 컨텍스트를 가진 에이전트(Elephant)로 설계 초안을 작성한 뒤, 문서와 인용된 출처만 읽는 컨텍스트 없는 서브에이전트(Goldfish)에게 넘깁니다. 이들은 설계를 만든 대화에 기댈 수 없기 때문에 말하지 않은 가정을 드러냅니다. 방법론의 논리가 탄탄하고 이미 별이 약 6,500개입니다. 주의할 점은 새 서브에이전트를 띄울 수 있는 하네스가 필요하다는 것이며, 그럴 수 없는 곳에서는 리뷰를 흉내 내지 않고 멈춥니다.

워크플로 팩의 자리

이들과 나란히 Superpowers(4.7) 같은 범용 워크플로 설치 도구가 있습니다. 명세 형식을 정하지 않고 에이전트에게 계획과 자체 점검 습관을 줍니다. 세 가지 지시 방식 중 어느 것과도 경쟁하지 않고 함께 쓸 수 있으며, 가장 적은 노력으로 시작할 수 있는 곳입니다.

무엇을 쓸까

한 줄짜리 수정에는 이 중 어느 것도 필요 없습니다. git, 테스트, 그리고 파일을 짚어 주는 짧은 프롬프트가 이깁니다. 코드 전에 설계 결정이 필요한 기능이라면, 에이전트가 서브에이전트를 지원한다는 전제에서 리뷰 우선 방식이 가장 적은 글쓰기로 가장 많은 실제 버그를 잡습니다. 나중에 감사자가 읽을 규제 대상 변경이라면, 명세 중심 방식의 문서 기록이 바로 핵심입니다. 그리고 에이전트가 같은 규칙을 계속 다시 만들어 내는 복잡한 제품이라면, 누군가 최신 상태로 유지한다는 조건에서만 제품 모델이 유지 비용만큼의 값을 합니다.