Goal-Driven 소개
코딩 에이전트에게 규모가 큰 작업을 맡겨 본 사람이라면 익숙한 장면이 있습니다. 에이전트가 한참 작업하다가 "구현을 완료했습니다"라고 선언하는데, 정작 확인해 보면 절반쯤 되어 있거나 테스트가 통과하지 않는 상태입니다. 다시 지시하면 또 얼마쯤 진행하고 다시 멈춥니다. 문제는 능력보다 종료 조건에 있습니다. 에이전트는 자기가 언제 끝난 것인지 판단할 기준을 갖고 있지 않으므로, 대화가 길어지면 남은 작업을 완료로 간주하고 작업을 멈춥니다.
Goal-Driven 은 이 종료 판정을 에이전트 자신에게서 떼어내 별도의 감독자에게 넘기는 방식을 정리한 프로젝트입니다. 목표(Goal)와 완료 기준(Criteria)을 사람이 먼저 문장으로 정해 두고, 마스터 에이전트(Master Agent)가 그 기준만 보고 완료 여부를 판정하며, 작업은 서브 에이전트(Subagent)가 맡습니다. 마스터 에이전트는 서브 에이전트가 멈추거나 완료를 선언하면 기준과 대조해 보고, 기준에 못 미치면 같은 이름의 서브 에이전트를 새로 세워 작업을 계속하게 합니다. 저자인 lidangzzz 는 이 방식으로 다중 에이전트 시스템이 하나의 문제에 300시간 이상 연속으로 매달릴 수 있다고 적었습니다.
여기서 저장소의 실체를 먼저 짚어 둘 필요가 있습니다. Goal-Driven 저장소에 들어 있는 것은 실행 가능한 프로그램이 아니라 마크다운 문서 두 개, 즉 영문 README와 중문 README 뿐입니다. 설치할 패키지도, 실행할 스크립트도 없습니다. 이 프로젝트가 배포하는 것은 목표와 완료 기준 두 칸을 채워 Claude Code, Codex, OpenClaw 같은 서브 에이전트 생성이 가능한 도구에 그대로 붙여 넣는 프롬프트 한 장입니다. GitHub 저장소 설명이 이 프로젝트를 "다중 에이전트 시스템(multi-agent system)"이라고 소개하기 때문에 프레임워크를 기대하고 들어오기 쉬운데, 실제로 받아 가는 것은 방법론과 그것을 담은 프롬프트 문안입니다.
Goal-Driven이 정의하는 네 가지 구성요소
저장소는 이 방식의 핵심 개념을 네 가지로 나눕니다:
- 목표(Goal): 시스템 전체의 최종 목적이자 모든 서브 에이전트의 중심 과제입니다.
- 완료 기준(Criteria): 마스터 에이전트가 작업이 끝났는지, 목표에 도달했는지를 판단할 수 있게 하는 명확한 조건 묶음입니다.
- 서브 에이전트(Subagent): 문제 해결과 목표 달성을 향해 계속 작업하는 실행 주체입니다. 필요하면 작업을 더 작은 하위 작업으로 쪼개 자신이나 다른 서브 에이전트에 배분할 수 있습니다.
- 마스터 에이전트(Master Agent): 서브 에이전트를 통제하는 유일한 주체이며, 정의된 기준에 따라 목표 도달 여부를 독립적으로 평가합니다. 시스템 진행에 대한 최종 결정권을 갖습니다.
이 넷 중 실제로 사람이 쓰는 것은 앞의 둘뿐이라는 점이 중요합니다. 프롬프트 안에서 목표와 완료 기준 자리는 [[[[[ ]]]]] 로 표시된 빈칸이고, 나머지 문안은 그대로 붙여 넣습니다. 마스터 에이전트와 서브 에이전트의 역할 서술은 프롬프트 본문에 이미 적혀 있어 사람이 손댈 필요가 없습니다.
Goal-Driven 루프의 동작 방식
저장소가 제시하는 동작은 세 단계입니다. 첫째, 절차가 시작되면 마스터 에이전트가 서브 에이전트를 하나 만들고 문제 해결과 목표 달성을 향해 계속 작업하라고 지시합니다. 둘째, 마스터 에이전트는 서브 에이전트가 활동 중인지 주기적으로 확인합니다. 서브 에이전트가 비활성 상태가 되거나 완료를 선언하거나 유휴 상태로 들어가면, 마스터 에이전트는 현재 결과를 기준과 대조해 평가합니다. 기준을 충족하지 못하면 작업을 계속하라고 명령하고, 이 순환을 기준이 충족될 때까지 반복합니다. 셋째, 서브 에이전트의 산출물이 기준을 충족하면 시스템은 멈추고 완료를 알립니다.
저장소는 이 절차를 다음 의사코드로 압축해 두었습니다:
while (criteria not met)
{
let the subagent work on solving the problem and achieving the Goal
}
프롬프트 본문에서 마스터 에이전트에게 지시하는 작업은 좀 더 구체적입니다. 서브 에이전트를 만들고, 서브 에이전트가 성공하거나 실패하면 완료 기준으로 결과를 평가하고, 5분마다 각 서브 에이전트의 활동을 점검해 비활성 상태면 목표 도달 여부를 확인한 뒤 같은 이름의 새 서브 에이전트로 교체합니다. 그리고 프롬프트는 이 절차를 DO NOT STOP THE AGENTS UNTIL THE USER STOPS THEM MANUALLY FROM OUTSIDE 라는 문장으로 닫습니다. 사람이 외부에서 직접 멈추기 전까지는 에이전트를 멈추지 말라는 지시이며, 이 프로젝트를 쓸 때 비용이 어디서 발생하는지를 알려주는 문장이기도 합니다.
Goal-Driven으로 만들었다고 밝힌 결과물
저장소는 이 방식으로 개발했다는 오픈소스 프로젝트 세 개를 링크로 함께 걸어 두었습니다. 각 소요 시간은 저자가 적어 둔 값입니다:
| 결과물 | 구현 언어 | 저자가 적은 소요 시간 |
|---|---|---|
| TypeScript 컴파일러 | C++ | 약 100시간 |
| SQLite | Rust | 약 30시간 |
| Lean4 컴파일러 | TypeScript | 진행 중 |
가장 큰 결과물인 TypeScript 컴파일러 저장소는 스스로를 TypeScript 6.0과 완전히 호환되는 C++ 재구현이라고 소개하며, src/, include/, tests/, typescript-tests/, docs/ 디렉토리와 CMake 빌드 설정, 그리고 Node.js 기반 테스트 스크립트를 갖추고 있습니다. 다만 소요 시간은 저장소에서 확인할 수 있는 값이 아니라 저자의 서술입니다. 세 저장소 모두 커밋이 짧은 기간에 몰려 있어, 실제 작업은 로컬에서 진행되고 결과만 올라온 형태로 보입니다.
이 결과물 목록이 알려주는 것은 성능이 아니라 적용 범위입니다. 저장소가 적합한 과제로 드는 예시는 컴파일러 설계, 수학 정리 증명, 계산 문제, 데이터베이스 아키텍처, 복잡한 시스템 수준 설계, EDA(Electronic Design Automation) 시뮬레이션입니다. 공통점은 결과가 맞았는지를 사람의 취향이 아니라 기계가 판정할 수 있다는 것입니다. 저장소가 든 완료 기준 예시가 그 성격을 잘 보여줍니다. TypeScript 컴파일러 과제의 기준은 문법 기능을 최대한 넓게 덮는 테스트 파일 2,000개를 만들어 컴파일하고, 그 출력과 공식 tsc 의 출력을 Node.js에서 각각 실행해 결과가 동일한지 확인하라는 것입니다.
Goal-Driven은 누구에게 유용한가
성공 여부를 기계가 판정할 수 있는 과제를 오래 돌려야 하는 사람에게 Goal-Driven은 그대로 가져다 쓸 만한 문안입니다. 참조 구현과의 출력 일치, 테스트 통과율, 정리 증명기의 검증 통과처럼 판정을 자동화할 수 있는 기준이 있으면, 마스터 에이전트가 사람 대신 그 기준을 반복해서 들이댈 수 있습니다. 저장소가 문서 두 개뿐이라 도입 비용도 프롬프트를 읽고 두 칸을 채우는 정도입니다.
반대로 완료 기준을 문장으로 정할 수 없는 과제에는 Goal-Driven이 맞지 않습니다. UI의 완성도나 문서의 읽기 좋음처럼 판정에 사람의 판단이 필요한 작업은, 마스터 에이전트가 기준을 대조할 근거가 없어 루프가 언제 끝나야 하는지 알 수 없습니다. 비용도 함께 고려해야 합니다. 저장소는 이 절차가 상당한 시간과 LLM 토큰을 소모할 수 있으므로 API 요금제나 구독 잔액이 충분한지 먼저 확인하라고 권고합니다.
저자가 함께 적어 둔 주의사항이 하나 더 있습니다. 이 프롬프트를 AI 에이전트의 스킬이나 플러그인으로 등록하지 말라는 것입니다. 컨텍스트 윈도우를 오염시킬 수 있다는 이유이며, 프롬프트가 상시 로드되면 관계없는 작업에서도 이 루프의 지시문이 함께 읽힌다는 뜻으로 이해할 수 있습니다. 필요할 때 대화에 직접 붙여 넣는 방식을 전제로 만들어진 문안입니다.
한 가지 더 확인해 둘 점은 유지보수 상태입니다. 저장소의 커밋 5개는 모두 2026년 3월 18일에 몰려 있고, 2026년 8월 31일 기준으로 그 이후 갱신이 없습니다. 다만 산출물이 프롬프트 문안 하나이므로 코드 저장소와 같은 기준으로 볼 필요는 없습니다. 이 저장소에는 LICENSE 파일이 없어, 문안을 사내 자료로 재배포하려는 경우에는 저자에게 확인이 필요합니다.
Goal-Driven 프로젝트 GitHub 저장소
더 읽어보기
-
장시간 자율 코딩을 위한 에이전트 하네스 설계: GAN에서 영감 받은 멀티 에이전트 아키텍처 (feat. Anthropic)
-
Claude Code를 만든 사람은 더 이상 프롬프트를 치지 않는다 — '루프 엔지니어링'이라는 이름이 붙은 한 주
-
oh-my-claude-sisyphus: 개발자를 위한 끈질긴 AI 파트너, Claude Code 오케스트레이션 시스템 (feat. oh-my-opencode)
-
Gas Town: 20-30개 AI 코딩 에이전트를 안정적으로 조율하는 Git 기반 멀티 에이전트 오케스트레이션 시스템
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. ![]()
이 도구를 직접 설치해 사용해보셨다면, 파이토치 한국 사용자 모임
회원들을 위해 경험이나 팁을 댓글로 남겨주세요! ![]()

