Claude Code loop와 goal은 언제 다르게 써야 할까 2026

Posted on by

2026년 6월 9일 확인 기준 Claude Code에는 반복 프롬프트용 /loop와 완료 조건 기반 /goal이 따로 있다. Managed Agents API에는 결과 기준을 rubric으로 평가하는 outcomes와 과거 세션을 정리하는 dreams도 있다.

요즘 “클로드 루프”라는 말을 보면 살짝 헷갈린다. 이게 공식 기능명인지, 개발자들이 붙인 밈인지, 아니면 그냥 “AI가 계속 일하는 것”을 멋있게 부르는 말인지 애매하다. 이름만 보면 새 프레임워크 같지만, 실제로는 여러 기능과 운영 패턴이 한 단어로 섞여 있다.

그래서 먼저 나눠야 한다. /loop는 시간을 기준으로 다시 실행하는 기능이고, /goal은 완료 조건을 기준으로 계속 일하게 하는 기능이다. Managed Agents의 outcomes는 API 쪽에서 “완료가 무엇인지”를 rubric으로 정의하고, 별도 grader가 평가해 다시 반복시키는 구조다. dreams는 작업 루프라기보다 메모리 정리 루프에 가깝다.

이 차이를 모르면 AI 루프는 생산성 도구가 아니라 자동 삽질 장치가 된다. 사람이 한 번 놓친 조건을 AI가 20번 반복하면, 결과는 20배 좋아지는 게 아니라 비용만 20배 선명해진다. 열심히 한다고 다 좋은 건 아니다. 운동도 자세가 틀리면 근육보다 병원비가 먼저 는다.

먼저 답을 나누면

Claude Code 공식 문서는 /loop를 현재 세션 안에서 프롬프트를 반복 실행하거나 상태를 polling하는 데 쓰는 기능으로 설명한다. 예를 들어 배포가 끝났는지 5분마다 확인하거나, PR 리뷰 코멘트와 CI 상태를 주기적으로 보는 식이다. /loop는 Claude Code v2.1.72 이상이 필요하고, 세션 안에서 도는 작업이라 현재 대화 범위의 영향을 받는다.

반면 /goal은 Claude Code v2.1.139 이상에서 쓰는 완료 조건 기반 기능이다. 사용자가 조건을 주면 Claude가 한 턴씩 계속 작업하고, 각 턴이 끝난 뒤 별도 evaluator가 조건 충족 여부를 확인한다. 조건이 충족되면 goal은 자동으로 해제된다.

Managed Agents의 outcomes는 더 제품화된 루프다. 사용자는 user.define_outcome 이벤트로 결과 설명과 rubric을 주고, harness는 별도 grader를 만들어 산출물이 기준을 만족하는지 평가한다. 필요하면 agent에게 피드백을 돌려 다음 iteration을 시작한다.

Dreams는 조금 다르다. Anthropic 문서 기준 dreams는 과거 세션과 memory store를 읽고, 중복과 낡은 내용을 정리해 새 memory store를 만드는 research preview 기능이다. 즉 “작업을 끝낼 때까지 반복”이 아니라 “기억을 정리해 다음 작업이 덜 흔들리게 하는 루프”다.

이름 기준 잘 맞는 일 피해야 할 일
/loop 시간 배포 확인, CI polling, PR 상태 감시 완료 조건이 복잡한 기능 구현
/goal 완료 조건 테스트 통과, acceptance criteria 충족, backlog 처리 기준이 애매한 조사나 브레인스토밍
outcomes rubric 평가 문서, 분석 파일, 모델, 보고서 같은 산출물 평가 기준 없이 “좋게 만들어줘”
dreams 메모리 정리 세션 기록 압축, 중복 memory 정리 즉시 실행해야 하는 개발 작업

/loop는 감시용에 가깝다

/loop를 가장 쉽게 이해하는 방법은 “세션 안 알람 + 반복 프롬프트”로 보는 것이다. Claude Code 문서도 /loop 5m check the deploy 같은 예시를 든다. 시간 간격과 프롬프트를 같이 주면 고정 주기로 실행되고, 프롬프트만 주면 Claude가 다음 간격을 동적으로 고를 수 있다.

이 기능이 좋은 순간은 기다림이 있는 작업이다. 배포가 끝났는지, CI가 통과했는지, PR 리뷰가 새로 달렸는지, 긴 빌드가 끝났는지 확인할 때 잘 맞는다. 사람이 계속 터미널을 새로고침하는 일을 Claude에게 넘기는 느낌이다.

다만 /loop는 만능 작업자 모드가 아니다. 공식 문서는 session-scoped scheduling의 한계를 분명히 말한다. Claude Code가 실행 중이고 idle 상태여야 하며, 새 conversation을 시작하면 session-scoped task는 사라진다. --resume이나 --continue로 일부 복원될 수 있지만, 7일 만료와 같은 제약도 있다.

그래서 /loop에 “앱을 완성해줘” 같은 큰 일을 맡기면 흐름이 어색해진다. 반복 주기가 중요한 일이 아니라 완료 조건이 중요한 일이기 때문이다. 5분마다 앱을 완성하려고 덤비는 AI를 상상해보면 된다. 성실하긴 한데, 옆에서 보는 사람의 혈압이 같이 성실해진다.

좋은 /loop 예시는 이렇게 좁다.

/loop 10m check whether the deployment finished; if it failed, summarize the failing log and wait for my instruction

이 프롬프트에는 세 가지가 들어 있다. 무엇을 볼지, 실패하면 어디까지 할지, 어디서 멈출지다. /loop는 특히 이 세 번째가 중요하다. 반복 실행은 편하지만, 반복 수정까지 열어두면 범위가 금방 커진다.

/goal은 완료 조건이 있을 때 쓴다

/goal은 “이 조건이 만족될 때까지 계속해”에 가깝다. Claude Code 문서는 모듈을 새 API로 옮겨 모든 call site가 컴파일되고 테스트가 통과할 때까지, design doc의 acceptance criteria가 모두 만족될 때까지, backlog queue가 빌 때까지 같은 예시를 든다.

여기서 핵심은 조건이 검증 가능해야 한다는 점이다. “깔끔하게 리팩토링해줘”는 약하다. “npm test와 npm run lint가 통과하고, src/auth/ 밖 파일은 수정하지 말 것”은 훨씬 낫다. AI는 추상적 칭찬보다 검사 가능한 문장을 좋아한다. 검사표가 없으면 자꾸 자기 자신과 하이파이브하려고 한다.

좋은 /goal 예시는 이렇게 쓸 수 있다.

/goal implement docs/auth-session-spec.md until npm test exits 0, npm run lint exits 0, and the diff only touches src/auth and tests/auth

이 명령은 세 부분으로 나뉜다. 해야 할 일, 통과해야 할 검증 명령, 건드릴 수 있는 범위다. 여기에 “최대 10턴 후 멈춰서 보고” 같은 제한을 더하면 더 안전하다.

/goal이 특히 좋은 곳은 테스트가 있는 코드베이스다. 테스트, 타입체크, lint, acceptance criteria가 있으면 AI가 반복할수록 더 가까워질 가능성이 있다. 반대로 테스트가 없고 기준도 흐릿하면 /goal은 감으로 전진한다. 감으로 전진하는 자동화는 빠르다. 문제는 절벽 쪽으로도 빠르다는 것이다.

outcomes는 “완료”를 문서화하는 방식이다

Managed Agents의 outcomes는 Claude Code의 /goal과 닮았지만, API 기반 장기 작업에 더 가깝다. 공식 문서는 outcome이 session을 conversation에서 work로 올린다고 설명한다. 결과물이 어떤 상태여야 하는지와 품질을 어떻게 측정할지를 정하면, agent가 그 목표를 향해 반복한다.

중요한 차이는 rubric이다. outcomes에서는 markdown rubric이 필수다. 예를 들어 DCF 모델이라면 과거 5년 매출 데이터 사용, 5년 이상 전망, WACC 가정, terminal value 방식, sensitivity analysis 같은 기준을 적는다. 그러면 별도 grader가 산출물을 평가하고, 부족하면 피드백이 agent에게 돌아간다.

이 구조는 “좋은 보고서 만들어줘”보다 훨씬 운영 친화적이다. 좋은 보고서라는 말은 사람마다 다르다. 하지만 “표지, assumptions sheet, sensitivity table, source citations, error-free formulas”처럼 적으면 평가가 가능해진다.

개인 개발자나 블로거 관점에서도 배울 점이 있다. API를 안 쓰더라도 rubric 사고방식은 그대로 가져올 수 있다. 글을 쓸 때도 “좋게 써줘” 대신 “첫 100자에 기준일과 답, 본문에 판단표 1개, FAQ 4개, 공식 출처 3개, 가짜 경험담 금지”라고 쓰면 결과가 좋아진다. 이건 프롬프트 기술이 아니라 편집 기준이다.

dreams는 자동 학습보다 메모리 청소에 가깝다

Dreaming이라는 단어는 마케팅적으로 꽤 강하다. AI가 꿈을 꾸며 스스로 배운다고 하면 뭔가 SF 냄새가 난다. 하지만 공식 문서 기준으로 차분하게 보면, dreams는 memory store와 과거 세션 transcript를 읽어 중복, 모순, 낡은 내용을 정리하고 새 memory store를 만드는 기능이다.

여기서 중요한 안전장치도 있다. 입력 store는 수정하지 않고, 새 output memory store를 만든다. 사용자는 결과를 검토한 뒤 미래 세션에 붙이거나 버릴 수 있다. 즉 꿈을 꾼다고 바로 운영 기억을 덮어쓰는 구조가 아니다.

이건 개인 지식관리에도 힌트가 된다. AI 루프를 오래 돌리면 산출물만 쌓이는 게 아니라 지시, 예외, 실패, 취향, 임시 메모도 같이 쌓인다. 이걸 정리하지 않으면 다음 세션의 AI는 오래된 규칙과 새 규칙을 동시에 믿는다. 그 상태에서 자동화가 돌면 “예전엔 이랬는데요?”라는 회사 막내 같은 문제가 생긴다.

그래서 dreams의 핵심 메시지는 자가 학습보다 memory hygiene에 가깝다. 루프를 만들었다면, 그 루프가 남긴 기억을 정리하는 루프도 필요하다. 작업 루프만 있고 정리 루프가 없으면 지식창고가 아니라 디지털 창고방이 된다.

실무 적용 순서

처음부터 Managed Agents outcomes나 dreams까지 갈 필요는 없다. Claude Code를 쓰는 개발자라면 먼저 /loop와 /goal의 역할만 분리해도 충분히 좋아진다. 핵심은 “시간으로 돌릴 일”과 “조건으로 끝낼 일”을 섞지 않는 것이다.

첫째, 기다림은 /loop로 보낸다. 배포, CI, PR, 장시간 빌드, 외부 승인처럼 사람이 새로고침하는 일은 /loop가 맞다. 단, 실패했을 때 자동 수정까지 열지 말고 요약과 보고까지만 시키는 것이 안전하다.

둘째, 테스트 있는 구현은 /goal로 보낸다. 구현, migration, refactor, issue 처리처럼 완료 상태가 명확한 일은 /goal이 맞다. 이때 검증 명령과 수정 범위를 같이 적는다.

셋째, 반복 산출물은 rubric으로 본다. 문서, 리포트, 분석표, 블로그 글처럼 “좋다”의 기준이 애매한 산출물은 outcomes식 rubric을 흉내 낸다. 공식 API를 쓰지 않아도 done criteria 문서를 만들면 충분하다.

넷째, 한 주에 한 번은 memory를 정리한다. 계속 돌린 루프에서 배운 점, 실패한 점, 더 이상 맞지 않는 지시를 분리한다. Claude의 dreams처럼 자동 기능을 쓰지 않더라도, session log -> rules update -> stale note cleanup 흐름을 만들면 된다.

바로 쓸 수 있는 체크표

AI 루프를 시작하기 전에 아래 다섯 질문만 통과시키면 사고가 줄어든다.

질문 통과 기준
이 작업은 시간 기준인가, 완료 조건 기준인가 시간은 /loop, 완료 조건은 /goal
검증 명령이 있는가 test, lint, typecheck, preview, source check 중 최소 1개
수정 범위가 적혀 있는가 파일 경로, 폴더, 금지 행동이 명확함
실패 시 어디서 멈추는가 n회 실패, n턴 초과, destructive action 전 중단
다음 루프에 남길 기록이 있는가 요약, 실패 원인, 바뀐 규칙, 후속 작업

이 표가 없으면 루프를 켜기 전에 멈추는 편이 낫다. 루프는 자동화의 엔진이지 핸들이 아니다. 엔진만 커지면 빠르게 간다. 어디로 가는지는 다른 문제다.

예시 프롬프트

CI 감시용은 짧게 쓴다.

/loop 10m check CI for the current branch. If it is still running, say nothing except the status. If it failed, summarize the failing job and wait for my instruction.

PR 유지보수용은 권한을 조심한다.

/loop 20m check review comments and CI. You may inspect files and propose fixes, but do not commit, push, delete files, or rewrite history.

구현 작업은 /goal로 보낸다.

/goal finish ISSUE-142 until npm test exits 0, npm run lint exits 0, and no files outside src/billing and tests/billing are changed. Stop and report if the same test fails 3 times.

블로그 글처럼 산출물 기준이 필요한 작업은 outcome 스타일로 쓴다.

Done means:
- 첫 100자 안에 기준일과 짧은 답이 있다.
- 본문에 판단표 1개 이상이 있다.
- 공식 출처 3개 이상이 있다.
- 경험 앵커가 없으면 1인칭 체험담을 쓰지 않는다.
- FAQ 4개 이상이 있다.
- 금지어 "완벽", "총정리", "가이드"를 제목에 쓰지 않는다.

내 판단

클로드 루프의 핵심은 “AI가 알아서 계속한다”가 아니다. “사람이 반복 조건과 검증 조건을 써서, AI가 안전하게 계속할 수 있게 한다”가 핵심이다. 이 차이가 작아 보이지만 실제 운영에서는 엄청 크다.

단발 프롬프트 시대에는 말을 잘하는 사람이 유리했다. 루프 시대에는 조건을 잘 쓰는 사람이 유리하다. 무엇을 반복할지, 무엇을 검사할지, 어디서 멈출지, 무엇을 기억으로 남길지 정하는 능력이 중요해진다.

그래서 Claude Code를 쓴다면 /loop를 먼저 써보되, 감시 작업에만 좁게 써보는 것이 좋다. 그다음 테스트가 있는 작은 issue를 /goal로 처리해본다. 이 두 개가 안정되면 outcomes식 rubric과 memory 정리 루프를 붙이면 된다.

AI 자동화는 버튼 하나로 끝나는 마법이 아니다. 반복되는 일을 시스템으로 바꾸는 훈련이다. 클로드 루프라는 말이 유행하든 말든, 진짜 중요한 질문은 똑같다. 이 루프는 무엇을 보고, 무엇을 고치고, 무엇을 통과해야 멈추는가.

FAQ

Claude Code /loop와 /goal 중 무엇을 먼저 써야 하나?

처음에는 /loop를 감시용으로 쓰는 편이 쉽다. 배포 확인, CI 상태 확인, PR 코멘트 확인처럼 사람이 기다리는 일을 맡긴다. 구현이나 리팩토링처럼 완료 조건이 있는 작업은 /goal이 더 맞다.

/loop로 코드 수정까지 시켜도 되나?

가능은 하지만 처음부터 권하지 않는다. /loop는 시간 기준 반복이라 수정 범위가 커질 수 있다. 실패 로그 요약, 상태 보고, 수정안 제안까지만 열고 실제 편집은 별도 지시나 /goal로 분리하는 편이 안전하다.

/goal 조건은 어떻게 쓰면 좋은가?

검증 가능한 문장으로 쓴다. npm test 통과, lint 통과, 특정 폴더만 수정, 동일 실패 3회면 중단처럼 도구 결과와 중단 조건이 있어야 한다. “깔끔하게”, “좋게”, “완성도 있게” 같은 말만 있으면 평가가 흔들린다.

Managed Agents outcomes는 Claude Code 사용자도 알아야 하나?

API를 직접 쓰지 않아도 사고방식은 유용하다. outcomes의 핵심은 “완료 기준을 rubric으로 적고 별도 평가를 거친다”는 점이다. 블로그 글, 리포트, 분석 파일, 코드 리뷰 체크리스트에도 이 방식을 그대로 적용할 수 있다.

Dreams는 AI가 스스로 학습한다는 뜻인가?

공식 문서 기준으로는 과거 세션과 memory store를 읽어 중복, 모순, 낡은 정보를 정리하고 새 memory store를 만드는 research preview 기능이다. 즉 즉시 작업을 자동으로 잘하게 만드는 마법보다, 장기 운영에서 기억 품질을 관리하는 기능으로 보는 편이 정확하다.

출처

관련 글