Claude Code /goal 공개, 코딩 에이전트도 완료 조건을 갖는다
Claude Code 2.1.139에 /goal이 추가됐습니다. 에이전트가 언제 멈출지 별도 평가자가 판단하는 변화입니다.
- 출시: Claude Code
2.1.139에/goal추가- 세션 단위 완료 조건을 걸고, 조건 충족 전까지 여러 턴을 이어갑니다.
- 각 턴 뒤 별도 평가자가 대화 기록 기준으로 완료 여부를 판단합니다.
- 차이:
/loop는 시간 간격,/goal은 종료 조건 중심- 테스트 통과, 수정 범위, 중단 기준처럼 검증 가능한 목표에 맞습니다.
- 실무 포인트: 성공 기준과 중단 기준을 같이 써야 비용과 리스크가 줄어듭니다.
Anthropic이 Claude Code 2.1.139에서 /goal 명령을 추가했습니다. 공식 changelog 기준 릴리스 날짜는 2026년 5월 11일입니다. 겉으로만 보면 "명령어 하나가 추가됐다"는 작은 업데이트처럼 보일 수 있습니다. 하지만 이 기능이 겨냥하는 문제는 꽤 큽니다. 코딩 에이전트가 긴 작업을 맡았을 때, 누가 "이제 끝났다"고 판단하느냐의 문제입니다.
/goal은 완료 조건을 설정하면 Claude가 한 턴에서 멈추지 않고 그 조건을 향해 여러 턴을 이어가도록 합니다. 예를 들어 "auth 테스트가 모두 통과하고 lint가 깨끗해야 한다"는 조건을 주면, Claude는 작업을 진행하고, 각 턴이 끝날 때 별도의 평가자가 조건이 충족됐는지 확인합니다. 충족되지 않았으면 다음 턴이 자동으로 시작됩니다. 충족됐으면 goal이 자동으로 지워집니다.
이 변화가 흥미로운 이유는 단순한 자동 반복이 아니기 때문입니다. Claude Code 문서는 /goal을 세션 범위의 prompt-based Stop hook 래퍼로 설명합니다. 작업을 수행하는 모델이 스스로 "이 정도면 됐다"고 말하는 것이 아니라, 작은 빠른 모델이 조건과 대화 기록을 보고 별도로 판단합니다. 기본 평가 모델은 Haiku입니다. 즉, Anthropic은 코딩 에이전트의 장시간 실행을 "더 오래 생각하기"가 아니라 완료 조건과 평가 루프의 문제로 제품화하고 있습니다.
왜 지금 /goal인가
AI 코딩 도구의 초기 경쟁은 모델 성능과 편집 경험에 가까웠습니다. 더 좋은 코드를 쓰는가, 더 넓은 파일을 읽는가, IDE에서 자연스럽게 diff를 보여주는가가 중요했습니다. 그런데 실제로 에이전트에게 작업을 맡기기 시작하면 다른 문제가 앞에 옵니다. 에이전트가 언제 멈춰야 하는지, 실패했을 때 어떤 증거를 남기는지, 테스트를 통과했다는 말이 실제로 어떤 출력에 근거하는지, 사용자가 자리를 비워도 괜찮은지 같은 운영 문제가 더 중요해집니다.
기존에도 사용자는 자연어로 "테스트가 통과할 때까지 계속해"라고 말할 수 있었습니다. 하지만 이 방식은 약합니다. 모델은 중간에 충분히 했다고 판단하고 멈출 수 있고, 실패한 테스트를 우회하려고 assertion을 바꾸는 식의 나쁜 해결책을 선택할 수도 있습니다. 무엇보다 "계속"이라는 말이 세션 상태로 남지 않습니다. 사용자가 다시 확인할 수 있는 완료 조건, 평가 횟수, 토큰 소비, 최근 평가 이유가 별도 상태로 관리되지 않습니다.
/goal은 이 빈틈을 CLI 기능으로 끌어올립니다. Claude Code 문서에 따르면 goal은 세션당 하나만 활성화됩니다. /goal 뒤에 조건을 입력하면 그 조건이 현재 세션의 목표가 되고, 이미 goal이 있으면 새 조건이 기존 조건을 대체합니다. 인수 없이 /goal을 실행하면 현재 조건, 실행 시간, 평가된 턴 수, 토큰 소비, 평가자의 최신 이유를 볼 수 있습니다. /goal clear를 실행하면 목표를 일찍 지울 수 있고, stop, off, reset, none, cancel도 clear 별칭으로 허용됩니다.
이런 세부사항은 사소해 보이지만, 장시간 코딩 에이전트에서는 중요합니다. 에이전트가 단지 채팅 답변을 길게 쓰는 것이 아니라, 작업 상태를 갖고, 평가 결과를 남기고, 나중에 재개될 수 있는 실행 단위로 변하고 있기 때문입니다.
/goal은 /loop와 다르다
Claude Code에는 이미 /loop가 있습니다. 하지만 공식 문서는 /goal, /loop, Stop hook을 분명히 구분합니다. /loop는 시간 간격이 지났을 때 다음 턴을 시작합니다. 사용자가 멈추거나 Claude가 작업이 끝났다고 판단할 때 멈춥니다. Stop hook은 이전 턴이 끝날 때 사용자의 스크립트나 프롬프트가 다음 행동을 결정합니다. 반면 /goal은 이전 턴이 끝날 때마다 모델 평가자가 완료 조건을 확인하고, 조건이 충족될 때 멈춥니다.
이 차이는 코딩 작업에서 큽니다. 배포 상태를 5분마다 확인하는 일이라면 /loop가 자연스럽습니다. 하지만 "마이그레이션이 끝났고 모든 호출 사이트가 컴파일되며 테스트가 통과한다"는 작업은 시간 간격보다 완료 조건이 중요합니다. 얼마나 자주 반복하느냐가 아니라 무엇이 끝났음을 증명하느냐가 핵심입니다.
| 방식 | 다음 턴이 시작되는 기준 | 멈추는 기준 | 적합한 작업 |
|---|---|---|---|
| /goal | 이전 턴이 끝날 때 | 별도 평가자가 완료 조건 충족을 확인할 때 | 테스트 통과, 마이그레이션 완료, 이슈 큐 비우기 |
| /loop | 정해진 시간 간격이 지날 때 | 사용자가 중지하거나 Claude가 끝났다고 판단할 때 | 배포 확인, 주기적 로그 점검, 반복 리포트 |
| Stop hook | 이전 턴이 끝날 때 | 사용자 스크립트나 프롬프트가 결정할 때 | 조직별 검증, 정책 기반 차단, 커스텀 평가 |
여기서 핵심은 /goal이 Stop hook을 없애는 기능이 아니라는 점입니다. 오히려 Stop hook의 한 패턴을 제품 기본 기능으로 만든 것에 가깝습니다. 커스텀 스크립트로 확정적인 검사를 돌려야 하는 조직은 여전히 Stop hook을 쓸 이유가 있습니다. 하지만 사용자가 매번 설정 파일을 만지지 않고 현재 세션에서만 목표를 걸고 싶다면 /goal이 더 낮은 진입 장벽을 제공합니다.
완료 조건은 어떻게 써야 하나
공식 문서는 좋은 조건의 형태도 비교적 구체적으로 제시합니다. 평가자는 파일을 직접 읽거나 명령을 실행하지 않습니다. Claude가 대화에 보여준 내용만 판단합니다. 따라서 "작업 끝내줘" 같은 조건은 약합니다. 대신 하나의 측정 가능한 최종 상태, 그것을 증명하는 확인 방법, 그리고 과정에서 지켜야 하는 제약을 함께 적어야 합니다.
예를 들면 이런 식입니다.
/goal all tests in test/auth pass, npm run lint exits 0, and no files outside src/auth and test/auth are modified
이 조건에는 세 가지가 들어 있습니다. 첫째, 테스트 통과라는 최종 상태입니다. 둘째, lint 종료 코드라는 확인 방법입니다. 셋째, 수정 범위 제한이라는 제약입니다. 평가자는 독립적으로 npm run lint를 실행하지 않지만, Claude가 그 명령을 실행하고 결과를 대화에 남기면 그 증거를 읽을 수 있습니다. 즉 /goal을 잘 쓰려면 에이전트에게 실행을 맡기는 것만큼, 에이전트가 자신의 증거를 대화에 드러내도록 조건을 설계해야 합니다.
조건은 최대 4,000자까지 가능합니다. 오래 걸리는 작업에는 제한 조건을 넣을 수 있습니다. 예를 들어 "20턴 뒤에도 완료되지 않으면 멈춰라" 같은 문장을 조건에 포함하면 Claude는 각 턴에서 그 제한에 대한 진행 상황도 보고합니다. 이 부분은 에이전트 비용 관리와도 연결됩니다. /goal이 자동 반복을 열어 주는 만큼, 좋은 조건에는 성공 기준과 중단 기준이 함께 들어가야 합니다.
작은 평가자가 갖는 의미
/goal의 가장 중요한 설계는 작업 모델과 평가 모델을 분리한다는 점입니다. 공식 문서에 따르면 각 턴이 끝날 때 조건과 지금까지의 대화가 작은 빠른 모델로 전달되고, 그 모델이 예 또는 아니오와 짧은 이유를 반환합니다. "아니오"면 그 이유가 다음 턴의 지침으로 들어가고 Claude는 계속 작업합니다. "예"면 goal이 지워지고 달성 기록이 남습니다.
이 구조는 완벽한 검증 시스템은 아닙니다. 평가자는 도구를 호출하지 않으므로 파일 시스템의 실제 상태를 독립적으로 확인하지 않습니다. 테스트 로그가 대화에 제대로 남지 않았거나, Claude가 부정확한 요약을 했거나, 조건 자체가 모호하면 평가가 틀릴 수 있습니다. 그래서 /goal은 CI를 대체하지 않습니다. 오히려 CI, 테스트, lint, 타입체크 같은 외부 검증 결과를 에이전트 루프 안으로 더 잘 끌어들이는 기능에 가깝습니다.
그럼에도 작업 모델과 평가 모델을 분리한 것은 방향이 맞습니다. 코딩 에이전트가 흔히 실패하는 방식 중 하나는 자신이 만든 해결책을 스스로 관대하게 평가하는 것입니다. 별도의 평가자는 그 문제를 줄입니다. 완전히 없애지는 못하지만, 최소한 완료 판단이 작업 모델의 자기평가 하나에만 걸리지 않도록 만듭니다.
Managed Agents outcomes와 같은 선 위에 있다
Claude Code /goal은 로컬 CLI 기능이지만, Anthropic의 플랫폼 업데이트와 같은 방향을 가리킵니다. 2026년 5월 6일 Anthropic은 Claude Managed Agents에 dreaming, outcomes, multiagent orchestration, webhooks 업데이트를 발표했습니다. 그중 outcomes는 개발자가 성공 기준을 rubric으로 정의하면 agent가 그 기준을 향해 작업하고, 별도 grader가 산출물을 평가해 부족한 점을 다시 agent에게 넘기는 구조입니다.
차이는 있습니다. Managed Agents outcomes는 API와 managed runtime의 기능입니다. rubric, session event, outcome evaluation event, output file retrieval 같은 서버 측 구조가 있습니다. Claude Code /goal은 현재 세션에서 사용자가 completion condition을 걸고, 세션 범위 Stop hook 평가자를 통해 여러 턴을 이어가는 CLI 기능입니다. 하지만 개념은 닮아 있습니다. 둘 다 에이전트를 "대화 상대"에서 "완료 기준을 향해 반복하는 작업자"로 바꿉니다.
사용자가 완료 조건을 정의합니다
에이전트가 코드 수정, 테스트 실행, 로그 확인을 수행합니다
별도 평가자가 대화에 남은 증거로 충족 여부를 판단합니다
부족하면 다음 턴으로 이어가고, 충족하면 목표를 종료합니다
이 흐름은 앞으로 AI 에이전트 제품이 어떤 방향으로 가는지 보여줍니다. 모델이 더 강력해지는 것도 중요하지만, 실무에서는 반복 루프와 종료 조건이 더 중요해집니다. 특히 코딩 업무에서는 "파일을 고쳤다"보다 "테스트가 통과했고, 수정 범위가 의도한 곳에 머물렀고, 결과를 검토할 수 있다"가 더 중요합니다.
개발자에게 실제로 바뀌는 것
개인 개발자에게 /goal은 장시간 작업을 더 명확하게 맡기는 방법입니다. 예를 들어 작은 리팩터링, 테스트 복구, 타입 오류 정리, 문서 기준 구현처럼 검증 가능한 끝 상태가 있는 작업에 잘 맞습니다. 반대로 요구사항이 계속 바뀌는 제품 설계, 사용자의 판단이 필요한 UI 디테일, 외부 서비스에서 민감한 액션을 수행하는 작업에는 조심해야 합니다. 자동 반복이 가능해졌다고 해서 모든 일을 무인으로 돌릴 수 있는 것은 아닙니다.
팀 단위로 보면 더 흥미롭습니다. /goal은 목표 조건을 어떻게 쓰는지가 중요하므로, 좋은 goal 문장을 팀 규칙으로 만들 수 있습니다. 예를 들어 "변경 파일 목록을 마지막에 보고한다", "관련 테스트와 전체 lint 결과를 대화에 남긴다", "정해진 디렉터리 밖은 수정하지 않는다", "20턴 이후에는 현재 상태를 요약하고 멈춘다" 같은 패턴입니다. 이것은 프롬프트 팁이라기보다 에이전트 운영 규칙에 가깝습니다.
여기서 CI와 리뷰의 역할은 줄어들지 않습니다. 오히려 더 중요해집니다. /goal이 작업을 오래 밀어붙일수록 마지막에 사람이 봐야 하는 증거도 더 명확해야 합니다. 좋은 에이전트 루프는 사람을 완전히 빼는 것이 아니라, 사람이 봐야 할 지점을 더 높은 수준으로 끌어올립니다. "어떤 파일을 고쳤는가"보다 "어떤 조건으로 완료 판정을 받았고, 어떤 검증 출력이 있었는가"가 리뷰의 출발점이 됩니다.
커뮤니티 반응은 기대와 우려가 섞여 있다
GeekNews에는 2026년 5월 12일 /goal 기능이 빠르게 공유됐습니다. 요약은 핵심을 잘 짚었습니다. 목표가 완료될 때까지 Claude가 여러 턴을 이어가고, 각 턴 뒤 fast model이 목표 달성 여부를 평가하며, 평가자는 파일이나 명령을 직접 확인하지 않고 대화 기록 기준으로 판단한다는 점입니다. 국내 개발자 커뮤니티에서도 이 기능을 단순 편의 명령이 아니라 Codex CLI의 goal loop와 비슷한 흐름으로 받아들이는 분위기가 보입니다.
Reddit 반응은 더 직설적입니다. r/ClaudeAI의 오늘 스레드는 이를 "run until done" 모드로 표현하며, 여러 세션을 켜 두고 나중에 돌아오는 워크플로우를 기대했습니다. 동시에 중요한 반론도 나왔습니다. 목표가 live website, 브라우저 조작, 외부 시스템 변경, 민감한 권한에 닿을 때는 guardrail, scope, visible state, logs, review point가 더 중요해진다는 지적입니다. 자동 반복 기능이 좋아질수록 제어 장치도 함께 좋아져야 한다는 뜻입니다.
이 우려는 과장된 것이 아닙니다. /goal은 조건이 충족될 때까지 계속할 수 있게 합니다. 하지만 조건이 잘못 쓰였거나, 검증 증거가 대화에 제대로 남지 않았거나, 외부 부작용이 큰 작업을 맡겼다면 문제도 자동으로 커질 수 있습니다. 에이전트가 더 자율적으로 움직일수록 "무엇을 허용할지"와 "어디서 멈출지"를 더 엄격하게 설계해야 합니다.
경쟁은 목표 루프와 관찰성으로 간다
AI 코딩 도구 시장에서 앞으로의 차별화는 단순히 "코드를 더 많이 생성한다"가 아닐 가능성이 큽니다. 이미 사용자는 여러 도구로 코드를 만들 수 있습니다. 다음 질문은 그 코드가 어떤 루프 안에서 만들어졌는지입니다. 목표가 무엇이었는가, 평가자는 무엇을 봤는가, 테스트는 실제로 돌았는가, 도중에 어떤 권한 요청이 있었는가, 작업이 멈춘 이유는 무엇인가가 중요해집니다.
Claude Code 2.1.139가 같은 릴리스에서 claude agents agent view도 추가한 점은 우연처럼 보이지 않습니다. agent view는 실행 중, 사용자에게 막힌 상태, 완료된 세션을 한 목록에서 볼 수 있게 합니다. /goal은 세션이 무엇을 향해 계속 가야 하는지를 정합니다. 하나는 관찰성이고, 다른 하나는 완료 조건입니다. 둘을 합치면 개발자는 여러 에이전트 작업을 켜 두고, 어떤 작업이 목표를 향해 가고 있는지, 어떤 작업이 막혔는지를 더 잘 볼 수 있습니다.
이런 변화는 Codex, Coder, GitHub Copilot coding agent, Warp/Oz 같은 다른 도구에도 압력으로 작용할 것입니다. 기업과 전문 개발자는 "에이전트가 똑똑하다"보다 "에이전트를 어떻게 멈추고 검증하고 추적할 수 있는가"를 더 많이 묻게 됩니다. 특히 코딩 에이전트가 PR을 만들고, 테스트를 고치고, 여러 worktree에서 병렬 작업을 수행한다면 이 질문은 더 중요해집니다.
아직 남은 한계
/goal은 중요한 진전이지만 만능은 아닙니다. 가장 큰 한계는 평가자가 직접 도구를 실행하지 않는다는 점입니다. 이는 설계상 간단하고 비용이 낮지만, 검증의 강도에는 한계가 있습니다. "테스트 통과"를 조건에 넣었다면 Claude가 실제로 테스트를 실행하고 그 결과를 대화에 남겨야 합니다. 대화에 없는 사실은 평가자가 판단할 수 없습니다.
또 하나의 한계는 목표가 잘못 쓰이면 루프도 잘못 돈다는 점입니다. 목표가 너무 넓으면 에이전트는 많은 파일을 건드리며 오래 돌아갈 수 있습니다. 목표가 너무 모호하면 평가자는 만족 여부를 일관되게 판단하기 어렵습니다. 목표가 외부 시스템의 상태를 바꾸는 작업이라면 자동 반복은 편의 기능이 아니라 위험 요소가 될 수 있습니다.
그래서 /goal을 잘 쓰는 팀은 아마 다음 규칙을 만들게 될 것입니다. 완료 조건에는 검증 명령을 명시합니다. 수정 범위를 제한합니다. 중단 조건을 넣습니다. 마지막 턴에는 변경 요약과 검증 출력을 남기게 합니다. 외부 부작용이 있는 작업은 자동 반복으로 넘기지 않거나, permission과 리뷰 포인트를 더 강하게 둡니다.
더 긴 답변보다 더 명확한 종료 조건
Claude Code /goal의 핵심은 "Claude가 더 오래 일한다"가 아닙니다. 핵심은 에이전트의 실행을 완료 조건 중심으로 재구성한다는 데 있습니다. 모델이 코드를 고치고, 테스트를 실행하고, 실패 이유를 반영하고, 다시 시도하는 루프는 이미 많은 사용자가 자연어와 스크립트로 만들어 왔습니다. 이제 그 패턴이 공식 CLI 명령으로 들어왔습니다.
이 변화는 코딩 에이전트 시장의 다음 단계를 보여줍니다. 모델의 지능, 컨텍스트 길이, 도구 수만으로는 충분하지 않습니다. 실무에서 중요한 것은 목표, 증거, 평가, 중단, 재개, 관찰성입니다. Claude Code /goal은 그중 목표와 평가를 사용자 손에 더 직접적으로 쥐여 줍니다.
개발자에게 이 업데이트는 작은 명령어 하나 이상의 의미가 있습니다. AI 코딩 에이전트를 더 믿고 맡기려면 "무엇을 만들 것인가"만큼 "어떤 조건이 충족되어야 멈출 것인가"를 잘 써야 합니다. 앞으로 좋은 에이전트 사용법은 좋은 프롬프트 작성법이 아니라, 좋은 완료 조건과 검증 루프를 설계하는 능력에 가까워질 것입니다.