{"content_id":"z9qcc6lzi3","slug":"claude-code-loop-engineering-guide","locale":"ko","schema_type":"TechArticle","category":"tutorial","category_name":"튜토리얼","title":"Claude Code Loop Engineering 가이드: 4가지 Loop와 안전한 자동화 설계","summary":"Claude Code의 Loop는 Agent가 관찰·행동·검증을 종료 조건까지 반복하도록 만드는 제어 구조다. 네 가지 Loop 유형의 차이와 함께 검증 증거, Hard stop, 멱등성, 비용, 최소 권한을 포함한 실무 설계 방법을 설명한다.","author":{"name":"인조이스 편집팀","url":"https://injoys.com/ko/about"},"key_points":["Claude Code의 Loop는 코드 반복문이 아니라 관찰·행동·검증을 종료 조건까지 반복하는 에이전트 실행 구조다.","Turn-based는 검증 절차, Goal-based는 종료 판단, Time-based는 재실행 시점, Proactive는 작업 시작과 오케스트레이션을 시스템에 넘긴다.","좋은 Loop는 측정 가능한 완료 조건, 외부 검증 증거, 강제 종료, 멱등성, 최소 권한을 갖춰야 한다.","`/goal` 평가 모델은 대화에 드러난 증거만 판단하므로 테스트 출력, 종료 코드, 변경 범위를 명확히 보고해야 한다.","결정론적 변환은 Script로 처리하고 Dynamic Workflow와 다수 Agent는 실제 병렬성이 필요한 대규모 작업에만 적용해야 한다."],"content_markdown":"Claude Code의 Loop는 단순히 모델을 오래 실행하는 기능이 아니다. 핵심은 확률적으로 행동하는 AI Agent 주위에 **Trigger, Verifier, Success condition, Hard stop, Permission boundary**를 배치해 반복 작업을 통제 가능한 시스템으로 만드는 데 있다. 이 글은 Turn-based, Goal-based, Time-based, Proactive Loop의 차이와 실무 설계 원칙을 한 번에 정리한다.\n\n## 1. Claude Code에서 Loop란 무엇인가\n\n여기서 Loop는 프로그래밍 언어의 `for`나 `while` 문이 아니다. Claude Code 팀이 설명하는 Loop는 Agent가 현재 상태를 관찰하고, 행동하고, 결과를 검증한 뒤, 종료 조건이 만족될 때까지 다시 작업하는 실행 구조다.\n\n```text\n작업 시작\n  ↓\n상태와 코드 파악\n  ↓\n계획 수립\n  ↓\n코드 수정 또는 도구 실행\n  ↓\n테스트·검증\n  ↓\n완료 조건 충족?\n  ├─ 아니오: 다음 반복\n  └─ 예: 종료 및 결과 보고\n```\n\nLoop를 구분할 때는 다음 네 질문이 유용하다.\n\n1. 무엇이 작업을 시작시키는가?\n2. 무엇이 작업을 종료시키는가?\n3. 어떤 Claude Code 기능이 반복을 제어하는가?\n4. 어떤 종류의 작업에 적합한가?\n\n모든 작업을 복잡한 Loop로 만들 필요는 없다. 한 파일의 오타 수정이나 단순한 이름 변경처럼 결과가 즉시 확인되는 작업에는 일반 프롬프트가 더 효율적이다. Loop는 여러 차례의 관찰·수정·검증이 실제로 필요한 경우에만 선택해야 한다.\n\n## 2. 네 가지 Loop 유형 비교\n\n| 유형 | 시작 조건 | 종료 조건 | 주로 사용하는 기능 | 적합한 작업 | 사람이 넘기는 책임 |\n|---|---|---|---|---|---|\n| Turn-based | 사용자의 프롬프트 | Claude가 완료했다고 판단하거나 추가 정보가 필요할 때 | 일반 대화, Skills, 테스트·브라우저 도구 | 짧고 일회성인 구현·수정 | 반복 검증 절차 |\n| Goal-based | 사용자가 완료 조건을 지정 | 평가 모델이 조건 충족을 확인하거나 사용자가 중단 | `/goal`, 필요 시 Auto mode | 테스트·빌드·마이그레이션처럼 완료 상태가 측정 가능한 작업 | 종료 판단 |\n| Time-based | 지정한 시간·간격·일정 | 사용자가 취소하거나 외부 작업이 끝남 | `/loop`, `/schedule` | PR·CI·배포 감시, 정기 요약, 상태 Polling | 다음 실행 시점 |\n| Proactive | 일정, API, GitHub 이벤트 등 | 개별 작업의 목표 충족, Routine 비활성화 | Routines, `/goal`, Skills, Dynamic Workflows, Auto mode | 이슈 분류, 버그 처리, 대규모 마이그레이션 등 지속 업무 | 작업 발견, 프롬프트 실행, 오케스트레이션 |\n\n이 분류의 핵심은 “AI가 얼마나 똑똑한가”가 아니라 **사람이 어떤 제어 책임을 시스템에 넘기는가**다. Turn-based에서 사람은 다음 프롬프트를 만들고, Goal-based에서는 완료 판단을 넘기며, Time-based에서는 재실행 시점을 넘긴다. Proactive 단계에서는 작업 발생을 감지하고 적절한 프롬프트를 실행하는 책임까지 시스템으로 이동한다.\n\n## 3. Turn-based Loop: 검증 절차를 넘긴다\n\nTurn-based Loop는 대부분의 개발자가 Claude Code를 사용하는 기본 형태다.\n\n```text\nHuman → Claude → Human → Claude\n```\n\n사용자가 요청하면 Claude는 관련 파일을 찾고, 코드를 수정하고, 테스트하고, 결과를 보고한다. 내부적으로는 여러 번의 관찰·행동·검증이 일어날 수 있지만, 다음 작업을 시작하는 권한은 사용자에게 남아 있다.\n\n### 코드 수정과 기능 완성은 다르다\n\nClaude가 “구현과 테스트를 완료했다”고 보고해도 실제 제품에서는 다음 문제가 남을 수 있다.\n\n- 버튼 클릭 후 상태가 바뀌지 않는다.\n- 브라우저 콘솔에 오류가 발생한다.\n- 모바일 레이아웃이 깨진다.\n- 접근성 속성이 빠져 있다.\n- 테스트는 통과하지만 실제 브라우저 흐름은 실패한다.\n- 변경과 무관한 파일까지 수정됐다.\n\n따라서 완료 기준은 “코드를 바꿨다”가 아니라 “외부 증거로 동작을 확인했다”여야 한다.\n\n### `SKILL.md`로 검증을 재사용한다\n\nSkill은 반복해서 사용하는 지침과 절차를 `SKILL.md`에 보관하는 방식이다. Claude가 관련성을 판단해 자동으로 불러오거나 `/skill-name`으로 직접 실행할 수 있다. 긴 운영 절차를 항상 `CLAUDE.md`에 넣는 것보다, 필요한 순간에만 Skill을 로드하도록 분리하면 컨텍스트를 더 효율적으로 사용할 수 있다.\n\n```markdown\n---\nname: verify-ui-change\ndescription: UI 변경을 완료 처리하기 전에 실제 실행 환경에서 검증한다.\n---\n\n# UI 변경 검증\n\n1. 개발 서버를 실행한다.\n2. 변경된 화면을 브라우저에서 연다.\n3. 새 컨트롤을 실제로 조작한다.\n4. 기대한 상태 변화가 발생하는지 확인한다.\n5. 브라우저 콘솔의 새 오류와 경고를 확인한다.\n6. 접근성 및 주요 성능 지표를 점검한다.\n7. 실패하면 수정 후 처음부터 다시 검증한다.\n8. 실행한 명령, 결과, 스크린샷 등 증거를 보고한다.\n```\n\n좋은 Skill은 추상적인 당부가 아니라 실행 가능한 체크리스트를 담는다. “더 신중하게 검토한다”보다 “`npm test`가 종료 코드 0인지 확인한다”가 훨씬 강한 규칙이다.\n\n### 검증 증거의 강도\n\n| 증거 | 신뢰도 | 이유 |\n|---|---:|---|\n| “정상일 것으로 보인다”라는 Agent의 설명 | 낮음 | 실행 결과가 아니라 추론에 불과함 |\n| 코드 Diff와 정적 검토 | 중간 | 변경 내용은 보이지만 Runtime 동작은 확인하지 못함 |\n| 실제 테스트 출력과 종료 코드 | 높음 | 재현 가능한 외부 결과가 존재함 |\n| 브라우저 상호작용, 스크린샷, 콘솔·성능 결과 | 매우 높음 | 사용자 경로와 Runtime 상태를 직접 검증함 |\n| 독립 Review Agent와 CI가 같은 결론을 냄 | 매우 높음 | 구현 Agent의 자기 확증 편향을 줄임 |\n\nClaude Code 공식 문서에는 실행 중인 애플리케이션을 확인하는 `/run`, 변경을 실제 실행 환경에서 검증하는 `/verify` 같은 bundled Skill도 설명되어 있다. 프로젝트 실행 방식이 복잡하다면 팀 고유의 Skill에 정확한 시작 명령, 환경 변수, 데이터 준비 절차를 기록하는 편이 안전하다.\n\n## 4. Goal-based Loop: 종료 판단을 넘긴다\n\nGoal-based Loop는 “한 번 더 작업할지”를 사용자가 매번 결정하지 않는다. 사용자는 완료 상태를 정의하고, Claude는 그 조건이 만족될 때까지 여러 Turn을 이어간다.\n\n```text\n사용자가 Goal 지정\n  ↓\nClaude 작업 Turn\n  ↓\n별도 평가 모델이 완료 조건 확인\n  ├─ 미충족: 이유를 다음 Turn에 전달\n  └─ 충족: Goal 종료\n```\n\n`/goal`은 Claude Code v2.1.139 이상에서 사용할 수 있도록 문서화되어 있다. 한 세션에는 하나의 Goal만 활성화할 수 있다.\n\n### 평가 모델이 실제로 보는 것\n\n매 Turn이 끝나면 별도의 small fast model이 완료 조건과 대화 내용을 보고 `충족` 또는 `미충족`을 판단한다. 기본 설정은 Haiku 계열 평가 모델이다. 중요한 제한은 평가 모델이 파일을 직접 읽거나 테스트를 별도로 실행하지 않는다는 점이다.\n\n따라서 작업을 수행한 Claude가 다음 증거를 대화에 명확히 남겨야 한다.\n\n- 실행한 명령\n- 테스트 개수와 통과·실패 결과\n- 종료 코드\n- 빌드 결과\n- 변경 파일 목록\n- 남아 있는 실패 원인\n- 범위 제약을 지켰다는 확인 결과\n\n평가 모델은 “실제로 무슨 일이 있었는가”가 아니라 “대화에 어떤 증거가 드러났는가”를 판단한다.\n\n### 좋은 Goal의 네 요소\n\n좋은 Goal은 다음 네 요소를 포함한다.\n\n1. **측정 가능한 성공 조건**: 테스트 통과, 빌드 성공, 큐 비움, 점수 임계치 달성\n2. **검증 방법**: 어떤 명령이나 도구로 성공을 증명할지 명시\n3. **변경 범위 제약**: 수정 가능한 디렉터리, 금지 파일, 허용된 Side effect\n4. **강제 종료 조건**: 최대 Turn, 최대 시간, 연속 실패 횟수, 권한 오류 시 중단\n\n```text\n/goal auth 관련 테스트와 lint가 모두 성공하고,\ngit diff에는 src/auth와 관련 테스트 파일만 포함되어야 한다.\n각 Turn에서 실행 결과와 종료 코드를 보고한다.\n최대 12턴 또는 45분에 도달하면 중단하고 남은 실패를 정리한다.\n```\n\n`/goal` 자체의 핵심 종료 조건은 평가 모델의 성공 판정 또는 사용자의 `/goal clear`다. Turn·시간 한도를 강제하려면 Goal 조건 안에 명시해야 한다.\n\n### 좋은 조건과 나쁜 조건\n\n| 좋은 조건 | 나쁜 조건 |\n|---|---|\n| `npm test`가 종료 코드 0으로 끝난다 | 코드를 완벽하게 만든다 |\n| 인증 관련 테스트 48개가 모두 통과한다 | 사용자 경험을 최대한 개선한다 |\n| 모든 API 호출 지점이 새 인터페이스로 변경되고 빌드가 성공한다 | 더 좋은 구조로 리팩터링한다 |\n| 처리 대상 이슈 큐가 비고 각 이슈에 결과가 기록된다 | 가능한 한 많은 이슈를 처리한다 |\n\n모호한 목표는 너무 빨리 종료되거나 끝없이 개선을 반복할 수 있다.\n\n### 상태 확인과 중단\n\n- `/goal`: 활성 조건, 실행 시간, 평가 Turn 수, 토큰 사용량, 최근 평가 이유 확인\n- `/goal clear`: 활성 Goal 중단\n- 새 Goal 설정: 기존 Goal 교체\n- `--resume` 또는 `--continue`: 미완료 Goal 복원 가능\n\n재개 시 조건은 유지되지만 Turn 수, 시간, 토큰 기준선은 초기화될 수 있으므로 Hard stop을 운영 지표와 함께 관리하는 것이 좋다.\n\n### `/goal`과 권한은 별개다\n\n`/goal`은 다음 Turn을 자동으로 시작할 뿐 도구 권한을 넓히지 않는다. 파일 쓰기, 테스트 명령, Git 작업이 승인 대상이면 Goal 중에도 승인이 필요할 수 있다.\n\n무인 실행에는 Auto mode를 함께 사용할 수 있지만, Auto mode는 “모든 도구를 무조건 허용”하는 기능이 아니다. 분류기가 파괴적이거나 되돌리기 어렵거나 신뢰 경계 밖을 대상으로 하는 작업을 차단하며, 명시적인 `ask`와 `deny` 규칙이 분류기보다 먼저 적용된다.\n\n## 5. Time-based Loop: 재실행 시점을 넘긴다\n\nGoal-based Loop가 “언제 멈출 것인가”를 다룬다면 Time-based Loop는 “언제 다시 실행할 것인가”를 다룬다. 외부 시스템의 상태가 시간이 지나면서 변하는 작업에 적합하다.\n\n- PR에 새 리뷰가 달렸는지 확인\n- CI 또는 배포가 끝났는지 확인\n- 장시간 빌드 상태 확인\n- 매일 Slack 메시지 요약\n- 이슈 큐의 신규 항목 확인\n\n### `/loop`: 현재 세션 안에서 반복 실행\n\n```text\n/loop 10m 현재 PR을 확인하고 새 리뷰를 반영하며,\n실패한 CI가 있으면 원인을 분석하고 수정한다.\n```\n\n현재 문서에 설명된 주요 형태는 다음과 같다.\n\n| 입력 | 동작 |\n|---|---|\n| `/loop 5m \u003cprompt\u003e` | 지정한 고정 간격으로 Prompt 실행 |\n| `/loop \u003cprompt\u003e` | Claude가 반복마다 간격을 선택 |\n| `/loop` | built-in 유지보수 Prompt 또는 프로젝트의 `loop.md` 실행 |\n| `/loop 20m /review-pr 1234` | 허용된 Skill을 지정 간격으로 재실행 |\n\n`/loop`는 현재 Claude Code 세션에 종속된다. 컴퓨터와 세션이 실행 중이어야 하며, 새 대화를 시작하면 세션 범위의 작업이 사라진다. 미만료 작업은 `--resume` 또는 `--continue`로 복원할 수 있지만, 반복 작업은 기본적으로 생성 후 7일 뒤 만료된다. 놓친 주기를 모두 소급 실행하지도 않는다.\n\n세션 Scheduler에는 Jitter가 적용될 수 있으므로 “정각에 반드시 실행”해야 하는 운영 요구에는 적합하지 않을 수 있다.\n\n### `/schedule`: Anthropic 관리 Cloud Routine\n\n`/schedule`은 Prompt와 Repository, Connector, Trigger를 묶어 Anthropic 관리 인프라에서 실행하는 Routine을 만든다. 노트북을 닫아도 실행할 수 있고, 공식 문서에서는 Research Preview로 안내한다.\n\nRoutine이 지원하는 Trigger는 다음과 같다.\n\n- 반복 일정\n- 특정 미래 시점의 일회성 일정\n- 인증된 API 호출\n- GitHub Pull request 또는 Release 이벤트\n\n하나의 Routine에 여러 Trigger를 연결할 수 있다. 예를 들어 PR Review Routine을 매일 밤 실행하면서 `pull_request.opened` 이벤트에도 반응하게 만들 수 있다.\n\n### `/loop`와 `/schedule` 비교\n\n| 구분 | `/loop` | `/schedule` Routine |\n|---|---|---|\n| 실행 위치 | 현재 컴퓨터와 세션 | Anthropic 관리 Cloud |\n| 컴퓨터 종료 후 실행 | 일반적으로 불가 | 가능 |\n| 열린 세션 필요 | 필요 | 불필요 |\n| 로컬 미커밋 파일 | 접근 가능 | 접근 불가, 실행마다 Repository를 새로 Clone |\n| 최소 간격 | 공식 문서 기준 1분 | 공식 문서 기준 1시간 |\n| 지속성 | 세션 중심, 반복 작업 7일 만료 | 계정에 저장되는 Routine |\n| 권한 Prompt | 현재 세션 정책 상속 | 대화형 승인 없이 자율 실행 |\n| 적합한 용도 | 짧은 PR·배포 감시 | 지속적인 운영 자동화 |\n\n### Polling보다 Event가 나은 경우\n\n변경이 드문 PR을 1분마다 확인하면 대부분의 실행은 아무 일도 하지 않고 종료된다. 외부 시스템이 이벤트를 보낼 수 있다면 다음 구조가 더 효율적이다.\n\n```text\nCI 실패 또는 PR 업데이트\n  ↓\nGitHub Trigger 또는 Routine API\n  ↓\n필요할 때만 Claude 실행\n```\n\nEvent 기반 설계는 지연을 줄이고 불필요한 모델 호출과 토큰 소비를 줄인다. Polling이 불가피하면 실제 변경 빈도에 맞춰 간격을 늘리고, 장시간 변화가 없을 때는 Backoff를 적용하는 것이 좋다.\n\n### 시간 기반 작업의 필수 조건\n\n1. **멱등성**: 같은 이벤트를 여러 번 받아도 중복 댓글, 중복 PR, 중복 배포가 생기지 않아야 한다.\n2. **처리 상태**: 마지막 처리 Event ID, Commit SHA, Review Comment ID 등을 기록해야 한다.\n3. **종료 상태**: PR merge·close, Queue empty, Deploy success·rollback처럼 종료를 판정할 수 있어야 한다.\n4. **쓰기 범위**: 댓글 허용, Merge 금지, `claude/*` Branch만 Push 등 Side effect를 제한해야 한다.\n5. **실패 처리**: 외부 서비스 장애, 인증 만료, Rate limit, 권한 부족 시 재시도와 Escalation 규칙이 필요하다.\n\n## 6. Proactive Loop: 작업 발견과 오케스트레이션을 넘긴다\n\nProactive Loop는 하나의 명령이 아니라 여러 기능을 결합한 상시 자동화 아키텍처다.\n\n```text\nTrigger\n+ Goal\n+ Skills\n+ Dynamic Workflow\n+ Auto mode\n+ Repository·Connector·Browser·CI 도구\n```\n\n사람이 실시간으로 프롬프트를 입력하지 않아도 새 작업이 감지되고, 처리되고, 검증되고, 결과가 보고된다.\n\n### 예: 버그 피드백 자동 처리\n\n```text\nGitHub Issue 또는 Slack 피드백 수신\n  ↓\n중복·우선순위·재현 가능성 분류\n  ↓\n재현 테스트 생성\n  ↓\n후보 해결책 탐색\n  ↓\n선택한 해결책 구현\n  ↓\n독립 Review Agent가 반례 탐색\n  ↓\n테스트·빌드·보안 검증\n  ↓\nDraft PR과 결과 보고\n```\n\n구성 요소별 책임은 다음과 같다.\n\n| 구성 요소 | 책임 |\n|---|---|\n| Trigger 또는 `/schedule` | 새 작업을 시작할 시점 결정 |\n| `/goal` | 이번 실행에서 무엇이 완료 상태인지 정의 |\n| Skill | 재현, 구현, 검증, 보고 절차 표준화 |\n| Dynamic Workflow | 다수 Subagent의 병렬 실행과 조건 분기 |\n| Auto mode | 허용된 도구 호출을 승인 대기 없이 실행 |\n| Permission policy | 금지·승인·자동 허용 범위 고정 |\n\n### Dynamic Workflow와 Worktree\n\nDynamic Workflow는 Claude가 작성한 JavaScript 오케스트레이션 Script를 Runtime이 실행하는 구조다. 일반 Subagent 호출에서는 Claude가 Turn마다 다음 Agent를 선택하지만, Workflow에서는 Loop, 병렬 처리, 분기, 중간 결과 저장이 Script로 이동한다.\n\n```text\nWorkflow Script\n  ├─ Agent A: 요구사항 분석\n  ├─ Agent B: 테스트 설계\n  ├─ Agent C: 구현 후보 탐색\n  ├─ Agent D: 보안 검토\n  └─ Judge: 증거 기반 비교\n```\n\n중간 결과가 메인 대화 Context가 아니라 Script 변수에 남기 때문에 대규모 작업을 더 재현 가능하게 조직할 수 있다. 현행 문서에는 동시에 최대 16개 Agent, 실행당 최대 1,000개 Agent라는 Runtime 한도가 명시되어 있으나, 제품 Preview 단계의 제한은 바뀔 수 있다.\n\n여러 구현 후보를 동시에 시험해야 한다면 Git Worktree로 작업 공간을 분리할 수 있다.\n\n```text\nrepo/\nworktree-solution-a/\nworktree-solution-b/\nworktree-solution-c/\n```\n\n각 Agent가 독립 Branch와 디렉터리에서 작업하면 같은 파일을 동시에 덮어쓰는 문제를 줄일 수 있다. Judge Agent는 요구사항 충족, 테스트 결과, 회귀 위험, 변경 범위, 복잡도, 성능, 보안, 기존 아키텍처와의 일관성을 기준으로 후보를 비교해야 한다.\n\n### 더 많은 Agent가 항상 좋은 것은 아니다\n\n병렬성이 없는 작업에 Agent 수만 늘리면 비용과 지연이 증가한다. 여러 Agent가 같은 잘못된 가정을 공유하면 오류가 확대될 수도 있다.\n\nDynamic Workflow가 적합한 경우는 다음과 같다.\n\n- 수백 파일에 같은 변환을 적용하는 Migration\n- 코드베이스 전체의 보안·품질 Audit\n- 독립적인 여러 관점의 Plan 비교\n- 많은 항목을 분할 처리하고 교차 검증해야 하는 Research\n- 한 Agent의 Context에 모든 중간 결과를 담기 어려운 작업\n\n작은 버그 수정, 한 파일 리팩터링, 단순 테스트 추가에는 일반 Turn-based Loop나 `/goal`이 더 낫다.\n\n## 7. Loop에서 코드 품질을 유지하는 시스템\n\nLoop 결과의 품질은 모델 자체뿐 아니라 모델 주변의 검증 시스템에 크게 좌우된다.\n\n### 7.1 코드베이스를 정돈한다\n\nClaude는 기존 코드의 패턴을 강하게 따라간다. 오래된 API, 중복 구현, 불명확한 테스트 구조, 거대한 모듈, 일관되지 않은 예외 처리 규칙이 있으면 Loop가 그 문제를 빠르게 복제할 수 있다.\n\n필수 기반은 다음과 같다.\n\n- Formatter와 lint\n- 명확한 디렉터리와 모듈 경계\n- 신뢰할 수 있는 Unit·Integration·E2E Test\n- 사용 중인 API와 Deprecated API의 구분\n- 프로젝트별 개발 규칙\n- 재현 가능한 Build·Dev 환경\n\n### 7.2 변경 유형별 Definition of Done을 만든다\n\n| 변경 유형 | 최소 검증 |\n|---|---|\n| API | 계약 테스트, 하위 호환성, Schema·문서 예제 갱신 |\n| Frontend | 실제 브라우저 조작, 콘솔 오류, 접근성, 반응형 화면 |\n| Database | Forward·Rollback Migration, Lock 범위, 실행 계획 |\n| Dependency | Build, 주요 회귀 테스트, License·Security 확인 |\n| Infrastructure | Plan Diff, 최소 권한, Rollback, 비밀정보 노출 검사 |\n\n이 기준은 Prompt에 매번 길게 반복하기보다 Skill, Hook, Script, CI Rule로 고정하는 편이 좋다.\n\n### 7.3 최신 문서와 정확한 버전을 제공한다\n\nLoop는 잘못된 가정을 여러 차례 반복할 수 있다. 프로젝트에서 사용하는 정확한 Version, 공식 문서, 내부 Architecture 문서, API 명세, Migration Guide, 승인된 예제를 쉽게 찾게 해야 한다.\n\n### 7.4 구현 Agent와 Review Agent를 분리한다\n\n구현한 Agent는 이미 선택한 설계와 추론에 영향을 받는다. 새 Context의 Review Agent는 다음 질문을 더 독립적으로 던질 수 있다.\n\n- 테스트를 약화시켜 통과시킨 것은 아닌가?\n- 범위 밖 파일을 바꾸지 않았는가?\n- 보안 경계가 깨지지 않았는가?\n- 실패 경로와 경계값 테스트가 빠지지 않았는가?\n- 기존 기능에 회귀가 생기지 않았는가?\n\nReview Prompt는 “좋은 점을 요약하라”보다 “구현이 틀렸다는 가정에서 반례를 찾고, 각 지적에 재현 증거를 붙여라”처럼 작성하는 편이 효과적이다.\n\n### 7.5 개별 실패를 시스템 개선으로 연결한다\n\n같은 오류가 반복되면 해당 결과만 수정해서는 안 된다. 실패 유형이 재발하기 어렵도록 다음 중 하나를 바꿔야 한다.\n\n- Regression Test 추가\n- Skill 검증 절차 강화\n- `CLAUDE.md` 규칙 추가\n- Hook 또는 lint Rule 추가\n- 권한 Deny Rule 추가\n- Goal의 완료 조건 강화\n- Review Checklist 보완\n\n좋은 Loop Engineering은 한 번의 실패를 고치는 작업이 아니라 **그 종류의 실패가 다시 나오기 어려운 시스템을 만드는 작업**이다.\n\n## 8. Token과 비용 관리\n\nLoop 비용은 단일 Prompt보다 크게 증가할 수 있다.\n\n```text\n총비용 ≈\n메인 Agent Turn 비용\n+ Goal 평가 비용\n+ Subagent 비용\n+ Workflow 반복 비용\n+ 도구 결과를 읽는 Context 비용\n+ 시간 기반 실행 빈도\n```\n\n정확한 과금은 Plan, Model, Provider에 따라 다르지만 비용 구조를 결정하는 원리는 동일하다.\n\n### 비용을 줄이는 실무 원칙\n\n1. **작은 작업에는 Loop를 쓰지 않는다.** 오타, 이름 변경, 한 파일의 타입 오류는 단일 Turn으로 처리한다.\n2. **성공 조건과 Hard stop을 함께 둔다.** 성공, 최대 Turn, 최대 시간, 연속 실패, 권한 오류를 모두 고려한다.\n3. **대규모 Workflow는 작은 범위에서 시험한다.** 5개 파일, 한 디렉터리, 일부 Issue로 비용과 품질을 검증한 뒤 확대한다.\n4. **결정론적 작업은 Script로 처리한다.** AST 치환, JSON 변환, Formatting, 고정 양식 생성은 검증된 Script가 더 저렴하고 재현 가능하다.\n5. **Polling 주기를 실제 변경 빈도에 맞춘다.** 가능하면 Event Trigger를 사용한다.\n6. **진행 중 사용량을 관찰한다.** `/usage`, `/goal`, `/workflows`에서 Skill·Subagent·MCP·Turn·Token 사용량을 확인한다.\n7. **같은 오류가 반복되면 계속 재시도하지 않는다.** 연속 실패 한도를 두고 사람에게 Escalation한다.\n\n### Model과 Effort는 다른 레버다\n\n- **Model**은 기본 추론 능력과 해결 가능한 문제의 범위를 바꾼다.\n- **Effort**는 읽는 파일 수, 사용하는 도구 수, 검증의 폭, 여러 단계 작업을 얼마나 끝까지 밀어붙이는지를 바꾼다.\n\nClaude가 필요한 파일과 테스트를 모두 확인했지만 판단 자체가 계속 틀리면 더 강한 Model이 필요할 수 있다. 반대로 중요한 파일을 읽지 않거나 테스트를 건너뛰거나 리팩터링을 중간에 끝냈다면 Effort를 높이는 편이 더 적절할 수 있다.\n\n## 9. 권한과 안전 경계\n\nProactive Loop에서 가장 위험한 설계는 Agent에게 넓은 권한을 주고, 성공 조건과 중단 조건을 느슨하게 두는 것이다.\n\nAuto mode는 일반 권한 Prompt를 줄이지만, 되돌리기 어렵거나 파괴적이거나 신뢰 경계 밖을 대상으로 하는 Tool call은 분류기가 차단할 수 있다. 또한 명시적인 `permissions.ask`와 `permissions.deny`는 Auto mode보다 우선한다.\n\n### 권한 계층 예시\n\n| 수준 | 예시 |\n|---|---|\n| 자동 허용 | 코드 읽기, 테스트·lint·Build, 분석, `claude/*` Branch 생성, Draft PR 생성 |\n| 사람 승인 | Default Branch 반영, 운영 배포, DB Migration 적용, 외부 고객 메시지 전송 |\n| 항상 금지 | Force push, Secret 출력, 운영 데이터 삭제, 권한 우회, 감사 로그 제거 |\n\n대화에서 “Push하지 마라”고 한 번 말하는 것보다 영구 `ask`·`deny` Rule로 고정하는 편이 안전하다. Context 압축이나 세션 변경으로 대화 규칙이 약해질 수 있기 때문이다.\n\nCloud Routine은 실행마다 Repository를 새로 Clone하고 연결된 GitHub·Connector 권한으로 동작한다. 다음 범위를 최소화해야 한다.\n\n- 접근 가능한 Repository와 Branch\n- 허용된 Network Domain\n- 사용할 Connector\n- 환경 변수와 Secret\n- 외부 시스템 쓰기 권한\n- PR 생성·Push·Merge 범위\n\nRoutine 실행 목록의 “정상 종료” 상태는 Infrastructure 오류 없이 Session이 끝났다는 뜻일 수 있으며, 업무 목표가 성공했다는 보장은 아니다. Transcript, Test evidence, 생성된 Diff를 별도로 검토해야 한다.\n\n## 10. 개발 프로젝트용 Loop 설계 템플릿\n\n다음 YAML은 실제 Claude Code 문법이 아니라 설계 검토용 Template이다.\n\n```yaml\ntrigger:\n  type: manual | interval | schedule | github_event | api_event\n\nscope:\n  repositories:\n    - target-repository\n  allowed_paths:\n    - src/**\n    - tests/**\n  prohibited_paths:\n    - production/**\n    - secrets/**\n\ntask:\n  objective: 변경하거나 처리할 목표\n  input: 새로 들어오는 Issue, Event, File 또는 상태\n\nverification:\n  commands:\n    - unit-test\n    - integration-test\n    - lint\n    - build\n  runtime_checks:\n    - browser-interaction\n    - console-errors\n    - accessibility\n  evidence:\n    - command-output\n    - exit-code\n    - test-summary\n    - screenshots\n\nsuccess:\n  condition: 참과 거짓으로 판정 가능한 완료 상태\n\nstop:\n  max_turns: 12\n  max_duration_minutes: 45\n  max_consecutive_failures: 3\n  stop_on_permission_error: true\n  escalate_on_external_outage: true\n\nside_effects:\n  idempotency_key: event-id-or-commit-sha\n  allow_branch_push: claude/*\n  require_human_for_merge: true\n  require_human_for_deploy: true\n\nreview:\n  independent_agent: true\n  adversarial_review: true\n\nobservability:\n  report_progress: true\n  report_token_usage: true\n  report_changed_files: true\n  report_remaining_failures: true\n```\n\n가장 중요한 항목은 프롬프트 문장 자체보다 다음 다섯 가지다.\n\n```text\nTrigger\nVerifier\nSuccess condition\nHard stop\nPermission boundary\n```\n\n## 11. 어떤 Loop를 선택해야 하는가\n\n| 상황 | 권장 방식 |\n|---|---|\n| 한 번의 수정과 검증으로 끝나는 작업 | Turn-based |\n| 여러 번 시도해야 하지만 완료 상태가 명확한 작업 | `/goal` |\n| 외부 CI·PR·배포 상태를 잠시 기다려야 하는 작업 | `/loop` |\n| 노트북을 닫아도 반복 실행해야 하는 업무 | `/schedule` Routine |\n| GitHub 이벤트나 Alert에 즉시 반응해야 하는 업무 | Event-triggered Routine |\n| 수백 항목을 병렬 처리하고 교차 검증해야 하는 업무 | Dynamic Workflow |\n| 입력과 출력 규칙이 완전히 결정론적인 변환 | Script 또는 CI Job |\n\n선택 순서는 “가장 강력한 기능”이 아니라 “목표를 달성하는 가장 단순한 제어 구조”를 기준으로 해야 한다.\n\n## 12. 안전한 도입 순서\n\n1. 사람이 반복해서 확인하는 병목 업무 하나를 고른다.\n2. 먼저 검증 절차를 Skill, Script, CI로 만든다.\n3. Turn-based 방식에서 검증 품질을 안정화한다.\n4. 완료 상태가 명확하면 `/goal`을 붙인다.\n5. 외부 상태를 기다려야 할 때만 `/loop`를 사용한다.\n6. 장기 실행이 필요하면 `/schedule` Routine으로 옮긴다.\n7. 멱등성, 권한, 비용이 검증된 뒤에만 Dynamic Workflow와 Proactive Loop로 확장한다.\n\n## 13. 자주 발생하는 오해\n\n| 오해 | 정확한 해석 |\n|---|---|\n| Loop는 무한 실행이다 | 성공 조건과 Hard stop이 있는 제한된 반복 구조다 |\n| Agent의 완료 보고는 검증이다 | 외부 명령 출력, 종료 코드, Runtime 결과가 필요하다 |\n| `/goal`이 모든 권한을 자동 허용한다 | 다음 Turn만 자동 시작하며 권한 정책은 별개다 |\n| `/loop`는 장기 운영 Scheduler다 | 세션 중심이고 7일 만료와 실행 환경 제약이 있다 |\n| Agent가 많을수록 결과가 좋아진다 | 역할·관점·검증이 다를 때만 병렬화의 가치가 생긴다 |\n| 모든 반복 작업은 LLM이 해야 한다 | 결정론적 부분은 Script가 더 싸고 재현성이 높다 |\n\n## 결론\n\nLoop Engineering은 AI를 오래 실행시키는 기술이 아니라, **AI가 틀렸을 때 스스로 발견하고, 비용 한도 안에서 수정하며, 위험한 지점에서는 멈추도록 만드는 제어 시스템 설계**다.\n\nLLM은 탐색, 추론, 구현, 예외 분석, 대안 비교에 강하다. 시스템은 실행 시점, 변경 범위, 검증 방법, 종료 기준, 비용 한도, 승인 경계를 담당해야 한다. 이 역할 분담이 명확할수록 Claude Code 자동화는 단순한 코드 생성 도구를 넘어 재현 가능하고 감사 가능한 개발 운영 시스템에 가까워진다.","content_html":"\u003cp\u003eClaude Code의 Loop는 단순히 모델을 오래 실행하는 기능이 아니다. 핵심은 확률적으로 행동하는 AI Agent 주위에 \u003cstrong\u003eTrigger, Verifier, Success condition, Hard stop, Permission boundary\u003c/strong\u003e를 배치해 반복 작업을 통제 가능한 시스템으로 만드는 데 있다. 이 글은 Turn-based, Goal-based, Time-based, Proactive Loop의 차이와 실무 설계 원칙을 한 번에 정리한다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-claude-code에서-loop란-무엇인가\" class=\"anchor\" id=\"1-claude-code에서-loop란-무엇인가\"\u003e\u003c/a\u003e1. Claude Code에서 Loop란 무엇인가\u003c/h2\u003e\n\u003cp\u003e여기서 Loop는 프로그래밍 언어의 \u003ccode\u003efor\u003c/code\u003e나 \u003ccode\u003ewhile\u003c/code\u003e 문이 아니다. Claude Code 팀이 설명하는 Loop는 Agent가 현재 상태를 관찰하고, 행동하고, 결과를 검증한 뒤, 종료 조건이 만족될 때까지 다시 작업하는 실행 구조다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e작업 시작\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e상태와 코드 파악\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e계획 수립\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e코드 수정 또는 도구 실행\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e테스트·검증\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e완료 조건 충족?\n\u003c/span\u003e\u003cspan\u003e  ├─ 아니오: 다음 반복\n\u003c/span\u003e\u003cspan\u003e  └─ 예: 종료 및 결과 보고\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eLoop를 구분할 때는 다음 네 질문이 유용하다.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e무엇이 작업을 시작시키는가?\u003c/li\u003e\n\u003cli\u003e무엇이 작업을 종료시키는가?\u003c/li\u003e\n\u003cli\u003e어떤 Claude Code 기능이 반복을 제어하는가?\u003c/li\u003e\n\u003cli\u003e어떤 종류의 작업에 적합한가?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e모든 작업을 복잡한 Loop로 만들 필요는 없다. 한 파일의 오타 수정이나 단순한 이름 변경처럼 결과가 즉시 확인되는 작업에는 일반 프롬프트가 더 효율적이다. Loop는 여러 차례의 관찰·수정·검증이 실제로 필요한 경우에만 선택해야 한다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#2-네-가지-loop-유형-비교\" class=\"anchor\" id=\"2-네-가지-loop-유형-비교\"\u003e\u003c/a\u003e2. 네 가지 Loop 유형 비교\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e유형\u003c/th\u003e\n\u003cth\u003e시작 조건\u003c/th\u003e\n\u003cth\u003e종료 조건\u003c/th\u003e\n\u003cth\u003e주로 사용하는 기능\u003c/th\u003e\n\u003cth\u003e적합한 작업\u003c/th\u003e\n\u003cth\u003e사람이 넘기는 책임\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003ctd\u003e사용자의 프롬프트\u003c/td\u003e\n\u003ctd\u003eClaude가 완료했다고 판단하거나 추가 정보가 필요할 때\u003c/td\u003e\n\u003ctd\u003e일반 대화, Skills, 테스트·브라우저 도구\u003c/td\u003e\n\u003ctd\u003e짧고 일회성인 구현·수정\u003c/td\u003e\n\u003ctd\u003e반복 검증 절차\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eGoal-based\u003c/td\u003e\n\u003ctd\u003e사용자가 완료 조건을 지정\u003c/td\u003e\n\u003ctd\u003e평가 모델이 조건 충족을 확인하거나 사용자가 중단\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e, 필요 시 Auto mode\u003c/td\u003e\n\u003ctd\u003e테스트·빌드·마이그레이션처럼 완료 상태가 측정 가능한 작업\u003c/td\u003e\n\u003ctd\u003e종료 판단\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTime-based\u003c/td\u003e\n\u003ctd\u003e지정한 시간·간격·일정\u003c/td\u003e\n\u003ctd\u003e사용자가 취소하거나 외부 작업이 끝남\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e, \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003ePR·CI·배포 감시, 정기 요약, 상태 Polling\u003c/td\u003e\n\u003ctd\u003e다음 실행 시점\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eProactive\u003c/td\u003e\n\u003ctd\u003e일정, API, GitHub 이벤트 등\u003c/td\u003e\n\u003ctd\u003e개별 작업의 목표 충족, Routine 비활성화\u003c/td\u003e\n\u003ctd\u003eRoutines, \u003ccode\u003e/goal\u003c/code\u003e, Skills, Dynamic Workflows, Auto mode\u003c/td\u003e\n\u003ctd\u003e이슈 분류, 버그 처리, 대규모 마이그레이션 등 지속 업무\u003c/td\u003e\n\u003ctd\u003e작업 발견, 프롬프트 실행, 오케스트레이션\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e이 분류의 핵심은 “AI가 얼마나 똑똑한가”가 아니라 \u003cstrong\u003e사람이 어떤 제어 책임을 시스템에 넘기는가\u003c/strong\u003e다. Turn-based에서 사람은 다음 프롬프트를 만들고, Goal-based에서는 완료 판단을 넘기며, Time-based에서는 재실행 시점을 넘긴다. Proactive 단계에서는 작업 발생을 감지하고 적절한 프롬프트를 실행하는 책임까지 시스템으로 이동한다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-turn-based-loop-검증-절차를-넘긴다\" class=\"anchor\" id=\"3-turn-based-loop-검증-절차를-넘긴다\"\u003e\u003c/a\u003e3. Turn-based Loop: 검증 절차를 넘긴다\u003c/h2\u003e\n\u003cp\u003eTurn-based Loop는 대부분의 개발자가 Claude Code를 사용하는 기본 형태다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eHuman → Claude → Human → Claude\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e사용자가 요청하면 Claude는 관련 파일을 찾고, 코드를 수정하고, 테스트하고, 결과를 보고한다. 내부적으로는 여러 번의 관찰·행동·검증이 일어날 수 있지만, 다음 작업을 시작하는 권한은 사용자에게 남아 있다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#코드-수정과-기능-완성은-다르다\" class=\"anchor\" id=\"코드-수정과-기능-완성은-다르다\"\u003e\u003c/a\u003e코드 수정과 기능 완성은 다르다\u003c/h3\u003e\n\u003cp\u003eClaude가 “구현과 테스트를 완료했다”고 보고해도 실제 제품에서는 다음 문제가 남을 수 있다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e버튼 클릭 후 상태가 바뀌지 않는다.\u003c/li\u003e\n\u003cli\u003e브라우저 콘솔에 오류가 발생한다.\u003c/li\u003e\n\u003cli\u003e모바일 레이아웃이 깨진다.\u003c/li\u003e\n\u003cli\u003e접근성 속성이 빠져 있다.\u003c/li\u003e\n\u003cli\u003e테스트는 통과하지만 실제 브라우저 흐름은 실패한다.\u003c/li\u003e\n\u003cli\u003e변경과 무관한 파일까지 수정됐다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e따라서 완료 기준은 “코드를 바꿨다”가 아니라 “외부 증거로 동작을 확인했다”여야 한다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#skillmd로-검증을-재사용한다\" class=\"anchor\" id=\"skillmd로-검증을-재사용한다\"\u003e\u003c/a\u003e\u003ccode\u003eSKILL.md\u003c/code\u003e로 검증을 재사용한다\u003c/h3\u003e\n\u003cp\u003eSkill은 반복해서 사용하는 지침과 절차를 \u003ccode\u003eSKILL.md\u003c/code\u003e에 보관하는 방식이다. Claude가 관련성을 판단해 자동으로 불러오거나 \u003ccode\u003e/skill-name\u003c/code\u003e으로 직접 실행할 수 있다. 긴 운영 절차를 항상 \u003ccode\u003eCLAUDE.md\u003c/code\u003e에 넣는 것보다, 필요한 순간에만 Skill을 로드하도록 분리하면 컨텍스트를 더 효율적으로 사용할 수 있다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: verify-ui-change\n\u003c/span\u003e\u003cspan\u003edescription: UI 변경을 완료 처리하기 전에 실제 실행 환경에서 검증한다.\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# UI 변경 검증\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. 개발 서버를 실행한다.\n\u003c/span\u003e\u003cspan\u003e2. 변경된 화면을 브라우저에서 연다.\n\u003c/span\u003e\u003cspan\u003e3. 새 컨트롤을 실제로 조작한다.\n\u003c/span\u003e\u003cspan\u003e4. 기대한 상태 변화가 발생하는지 확인한다.\n\u003c/span\u003e\u003cspan\u003e5. 브라우저 콘솔의 새 오류와 경고를 확인한다.\n\u003c/span\u003e\u003cspan\u003e6. 접근성 및 주요 성능 지표를 점검한다.\n\u003c/span\u003e\u003cspan\u003e7. 실패하면 수정 후 처음부터 다시 검증한다.\n\u003c/span\u003e\u003cspan\u003e8. 실행한 명령, 결과, 스크린샷 등 증거를 보고한다.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e좋은 Skill은 추상적인 당부가 아니라 실행 가능한 체크리스트를 담는다. “더 신중하게 검토한다”보다 “\u003ccode\u003enpm test\u003c/code\u003e가 종료 코드 0인지 확인한다”가 훨씬 강한 규칙이다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#검증-증거의-강도\" class=\"anchor\" id=\"검증-증거의-강도\"\u003e\u003c/a\u003e검증 증거의 강도\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e증거\u003c/th\u003e\n\u003cth\u003e신뢰도\u003c/th\u003e\n\u003cth\u003e이유\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e“정상일 것으로 보인다”라는 Agent의 설명\u003c/td\u003e\n\u003ctd\u003e낮음\u003c/td\u003e\n\u003ctd\u003e실행 결과가 아니라 추론에 불과함\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e코드 Diff와 정적 검토\u003c/td\u003e\n\u003ctd\u003e중간\u003c/td\u003e\n\u003ctd\u003e변경 내용은 보이지만 Runtime 동작은 확인하지 못함\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e실제 테스트 출력과 종료 코드\u003c/td\u003e\n\u003ctd\u003e높음\u003c/td\u003e\n\u003ctd\u003e재현 가능한 외부 결과가 존재함\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e브라우저 상호작용, 스크린샷, 콘솔·성능 결과\u003c/td\u003e\n\u003ctd\u003e매우 높음\u003c/td\u003e\n\u003ctd\u003e사용자 경로와 Runtime 상태를 직접 검증함\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e독립 Review Agent와 CI가 같은 결론을 냄\u003c/td\u003e\n\u003ctd\u003e매우 높음\u003c/td\u003e\n\u003ctd\u003e구현 Agent의 자기 확증 편향을 줄임\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eClaude Code 공식 문서에는 실행 중인 애플리케이션을 확인하는 \u003ccode\u003e/run\u003c/code\u003e, 변경을 실제 실행 환경에서 검증하는 \u003ccode\u003e/verify\u003c/code\u003e 같은 bundled Skill도 설명되어 있다. 프로젝트 실행 방식이 복잡하다면 팀 고유의 Skill에 정확한 시작 명령, 환경 변수, 데이터 준비 절차를 기록하는 편이 안전하다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-goal-based-loop-종료-판단을-넘긴다\" class=\"anchor\" id=\"4-goal-based-loop-종료-판단을-넘긴다\"\u003e\u003c/a\u003e4. Goal-based Loop: 종료 판단을 넘긴다\u003c/h2\u003e\n\u003cp\u003eGoal-based Loop는 “한 번 더 작업할지”를 사용자가 매번 결정하지 않는다. 사용자는 완료 상태를 정의하고, Claude는 그 조건이 만족될 때까지 여러 Turn을 이어간다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e사용자가 Goal 지정\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eClaude 작업 Turn\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e별도 평가 모델이 완료 조건 확인\n\u003c/span\u003e\u003cspan\u003e  ├─ 미충족: 이유를 다음 Turn에 전달\n\u003c/span\u003e\u003cspan\u003e  └─ 충족: Goal 종료\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e은 Claude Code v2.1.139 이상에서 사용할 수 있도록 문서화되어 있다. 한 세션에는 하나의 Goal만 활성화할 수 있다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#평가-모델이-실제로-보는-것\" class=\"anchor\" id=\"평가-모델이-실제로-보는-것\"\u003e\u003c/a\u003e평가 모델이 실제로 보는 것\u003c/h3\u003e\n\u003cp\u003e매 Turn이 끝나면 별도의 small fast model이 완료 조건과 대화 내용을 보고 \u003ccode\u003e충족\u003c/code\u003e 또는 \u003ccode\u003e미충족\u003c/code\u003e을 판단한다. 기본 설정은 Haiku 계열 평가 모델이다. 중요한 제한은 평가 모델이 파일을 직접 읽거나 테스트를 별도로 실행하지 않는다는 점이다.\u003c/p\u003e\n\u003cp\u003e따라서 작업을 수행한 Claude가 다음 증거를 대화에 명확히 남겨야 한다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e실행한 명령\u003c/li\u003e\n\u003cli\u003e테스트 개수와 통과·실패 결과\u003c/li\u003e\n\u003cli\u003e종료 코드\u003c/li\u003e\n\u003cli\u003e빌드 결과\u003c/li\u003e\n\u003cli\u003e변경 파일 목록\u003c/li\u003e\n\u003cli\u003e남아 있는 실패 원인\u003c/li\u003e\n\u003cli\u003e범위 제약을 지켰다는 확인 결과\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e평가 모델은 “실제로 무슨 일이 있었는가”가 아니라 “대화에 어떤 증거가 드러났는가”를 판단한다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#좋은-goal의-네-요소\" class=\"anchor\" id=\"좋은-goal의-네-요소\"\u003e\u003c/a\u003e좋은 Goal의 네 요소\u003c/h3\u003e\n\u003cp\u003e좋은 Goal은 다음 네 요소를 포함한다.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e측정 가능한 성공 조건\u003c/strong\u003e: 테스트 통과, 빌드 성공, 큐 비움, 점수 임계치 달성\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e검증 방법\u003c/strong\u003e: 어떤 명령이나 도구로 성공을 증명할지 명시\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e변경 범위 제약\u003c/strong\u003e: 수정 가능한 디렉터리, 금지 파일, 허용된 Side effect\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e강제 종료 조건\u003c/strong\u003e: 최대 Turn, 최대 시간, 연속 실패 횟수, 권한 오류 시 중단\u003c/li\u003e\n\u003c/ol\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/goal auth 관련 테스트와 lint가 모두 성공하고,\n\u003c/span\u003e\u003cspan\u003egit diff에는 src/auth와 관련 테스트 파일만 포함되어야 한다.\n\u003c/span\u003e\u003cspan\u003e각 Turn에서 실행 결과와 종료 코드를 보고한다.\n\u003c/span\u003e\u003cspan\u003e최대 12턴 또는 45분에 도달하면 중단하고 남은 실패를 정리한다.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e 자체의 핵심 종료 조건은 평가 모델의 성공 판정 또는 사용자의 \u003ccode\u003e/goal clear\u003c/code\u003e다. Turn·시간 한도를 강제하려면 Goal 조건 안에 명시해야 한다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#좋은-조건과-나쁜-조건\" class=\"anchor\" id=\"좋은-조건과-나쁜-조건\"\u003e\u003c/a\u003e좋은 조건과 나쁜 조건\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e좋은 조건\u003c/th\u003e\n\u003cth\u003e나쁜 조건\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003enpm test\u003c/code\u003e가 종료 코드 0으로 끝난다\u003c/td\u003e\n\u003ctd\u003e코드를 완벽하게 만든다\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e인증 관련 테스트 48개가 모두 통과한다\u003c/td\u003e\n\u003ctd\u003e사용자 경험을 최대한 개선한다\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e모든 API 호출 지점이 새 인터페이스로 변경되고 빌드가 성공한다\u003c/td\u003e\n\u003ctd\u003e더 좋은 구조로 리팩터링한다\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e처리 대상 이슈 큐가 비고 각 이슈에 결과가 기록된다\u003c/td\u003e\n\u003ctd\u003e가능한 한 많은 이슈를 처리한다\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e모호한 목표는 너무 빨리 종료되거나 끝없이 개선을 반복할 수 있다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#상태-확인과-중단\" class=\"anchor\" id=\"상태-확인과-중단\"\u003e\u003c/a\u003e상태 확인과 중단\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e/goal\u003c/code\u003e: 활성 조건, 실행 시간, 평가 Turn 수, 토큰 사용량, 최근 평가 이유 확인\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e/goal clear\u003c/code\u003e: 활성 Goal 중단\u003c/li\u003e\n\u003cli\u003e새 Goal 설정: 기존 Goal 교체\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e--resume\u003c/code\u003e 또는 \u003ccode\u003e--continue\u003c/code\u003e: 미완료 Goal 복원 가능\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e재개 시 조건은 유지되지만 Turn 수, 시간, 토큰 기준선은 초기화될 수 있으므로 Hard stop을 운영 지표와 함께 관리하는 것이 좋다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#goal과-권한은-별개다\" class=\"anchor\" id=\"goal과-권한은-별개다\"\u003e\u003c/a\u003e\u003ccode\u003e/goal\u003c/code\u003e과 권한은 별개다\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e은 다음 Turn을 자동으로 시작할 뿐 도구 권한을 넓히지 않는다. 파일 쓰기, 테스트 명령, Git 작업이 승인 대상이면 Goal 중에도 승인이 필요할 수 있다.\u003c/p\u003e\n\u003cp\u003e무인 실행에는 Auto mode를 함께 사용할 수 있지만, Auto mode는 “모든 도구를 무조건 허용”하는 기능이 아니다. 분류기가 파괴적이거나 되돌리기 어렵거나 신뢰 경계 밖을 대상으로 하는 작업을 차단하며, 명시적인 \u003ccode\u003eask\u003c/code\u003e와 \u003ccode\u003edeny\u003c/code\u003e 규칙이 분류기보다 먼저 적용된다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-time-based-loop-재실행-시점을-넘긴다\" class=\"anchor\" id=\"5-time-based-loop-재실행-시점을-넘긴다\"\u003e\u003c/a\u003e5. Time-based Loop: 재실행 시점을 넘긴다\u003c/h2\u003e\n\u003cp\u003eGoal-based Loop가 “언제 멈출 것인가”를 다룬다면 Time-based Loop는 “언제 다시 실행할 것인가”를 다룬다. 외부 시스템의 상태가 시간이 지나면서 변하는 작업에 적합하다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePR에 새 리뷰가 달렸는지 확인\u003c/li\u003e\n\u003cli\u003eCI 또는 배포가 끝났는지 확인\u003c/li\u003e\n\u003cli\u003e장시간 빌드 상태 확인\u003c/li\u003e\n\u003cli\u003e매일 Slack 메시지 요약\u003c/li\u003e\n\u003cli\u003e이슈 큐의 신규 항목 확인\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#loop-현재-세션-안에서-반복-실행\" class=\"anchor\" id=\"loop-현재-세션-안에서-반복-실행\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e: 현재 세션 안에서 반복 실행\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/loop 10m 현재 PR을 확인하고 새 리뷰를 반영하며,\n\u003c/span\u003e\u003cspan\u003e실패한 CI가 있으면 원인을 분석하고 수정한다.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e현재 문서에 설명된 주요 형태는 다음과 같다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e입력\u003c/th\u003e\n\u003cth\u003e동작\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 5m \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e지정한 고정 간격으로 Prompt 실행\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eClaude가 반복마다 간격을 선택\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003ebuilt-in 유지보수 Prompt 또는 프로젝트의 \u003ccode\u003eloop.md\u003c/code\u003e 실행\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 20m /review-pr 1234\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e허용된 Skill을 지정 간격으로 재실행\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003e/loop\u003c/code\u003e는 현재 Claude Code 세션에 종속된다. 컴퓨터와 세션이 실행 중이어야 하며, 새 대화를 시작하면 세션 범위의 작업이 사라진다. 미만료 작업은 \u003ccode\u003e--resume\u003c/code\u003e 또는 \u003ccode\u003e--continue\u003c/code\u003e로 복원할 수 있지만, 반복 작업은 기본적으로 생성 후 7일 뒤 만료된다. 놓친 주기를 모두 소급 실행하지도 않는다.\u003c/p\u003e\n\u003cp\u003e세션 Scheduler에는 Jitter가 적용될 수 있으므로 “정각에 반드시 실행”해야 하는 운영 요구에는 적합하지 않을 수 있다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#schedule-anthropic-관리-cloud-routine\" class=\"anchor\" id=\"schedule-anthropic-관리-cloud-routine\"\u003e\u003c/a\u003e\u003ccode\u003e/schedule\u003c/code\u003e: Anthropic 관리 Cloud Routine\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/schedule\u003c/code\u003e은 Prompt와 Repository, Connector, Trigger를 묶어 Anthropic 관리 인프라에서 실행하는 Routine을 만든다. 노트북을 닫아도 실행할 수 있고, 공식 문서에서는 Research Preview로 안내한다.\u003c/p\u003e\n\u003cp\u003eRoutine이 지원하는 Trigger는 다음과 같다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e반복 일정\u003c/li\u003e\n\u003cli\u003e특정 미래 시점의 일회성 일정\u003c/li\u003e\n\u003cli\u003e인증된 API 호출\u003c/li\u003e\n\u003cli\u003eGitHub Pull request 또는 Release 이벤트\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e하나의 Routine에 여러 Trigger를 연결할 수 있다. 예를 들어 PR Review Routine을 매일 밤 실행하면서 \u003ccode\u003epull_request.opened\u003c/code\u003e 이벤트에도 반응하게 만들 수 있다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#loop와-schedule-비교\" class=\"anchor\" id=\"loop와-schedule-비교\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e와 \u003ccode\u003e/schedule\u003c/code\u003e 비교\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e구분\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e실행 위치\u003c/td\u003e\n\u003ctd\u003e현재 컴퓨터와 세션\u003c/td\u003e\n\u003ctd\u003eAnthropic 관리 Cloud\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e컴퓨터 종료 후 실행\u003c/td\u003e\n\u003ctd\u003e일반적으로 불가\u003c/td\u003e\n\u003ctd\u003e가능\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e열린 세션 필요\u003c/td\u003e\n\u003ctd\u003e필요\u003c/td\u003e\n\u003ctd\u003e불필요\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e로컬 미커밋 파일\u003c/td\u003e\n\u003ctd\u003e접근 가능\u003c/td\u003e\n\u003ctd\u003e접근 불가, 실행마다 Repository를 새로 Clone\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e최소 간격\u003c/td\u003e\n\u003ctd\u003e공식 문서 기준 1분\u003c/td\u003e\n\u003ctd\u003e공식 문서 기준 1시간\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e지속성\u003c/td\u003e\n\u003ctd\u003e세션 중심, 반복 작업 7일 만료\u003c/td\u003e\n\u003ctd\u003e계정에 저장되는 Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e권한 Prompt\u003c/td\u003e\n\u003ctd\u003e현재 세션 정책 상속\u003c/td\u003e\n\u003ctd\u003e대화형 승인 없이 자율 실행\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e적합한 용도\u003c/td\u003e\n\u003ctd\u003e짧은 PR·배포 감시\u003c/td\u003e\n\u003ctd\u003e지속적인 운영 자동화\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#polling보다-event가-나은-경우\" class=\"anchor\" id=\"polling보다-event가-나은-경우\"\u003e\u003c/a\u003ePolling보다 Event가 나은 경우\u003c/h3\u003e\n\u003cp\u003e변경이 드문 PR을 1분마다 확인하면 대부분의 실행은 아무 일도 하지 않고 종료된다. 외부 시스템이 이벤트를 보낼 수 있다면 다음 구조가 더 효율적이다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eCI 실패 또는 PR 업데이트\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eGitHub Trigger 또는 Routine API\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e필요할 때만 Claude 실행\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEvent 기반 설계는 지연을 줄이고 불필요한 모델 호출과 토큰 소비를 줄인다. Polling이 불가피하면 실제 변경 빈도에 맞춰 간격을 늘리고, 장시간 변화가 없을 때는 Backoff를 적용하는 것이 좋다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#시간-기반-작업의-필수-조건\" class=\"anchor\" id=\"시간-기반-작업의-필수-조건\"\u003e\u003c/a\u003e시간 기반 작업의 필수 조건\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e멱등성\u003c/strong\u003e: 같은 이벤트를 여러 번 받아도 중복 댓글, 중복 PR, 중복 배포가 생기지 않아야 한다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e처리 상태\u003c/strong\u003e: 마지막 처리 Event ID, Commit SHA, Review Comment ID 등을 기록해야 한다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e종료 상태\u003c/strong\u003e: PR merge·close, Queue empty, Deploy success·rollback처럼 종료를 판정할 수 있어야 한다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e쓰기 범위\u003c/strong\u003e: 댓글 허용, Merge 금지, \u003ccode\u003eclaude/*\u003c/code\u003e Branch만 Push 등 Side effect를 제한해야 한다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e실패 처리\u003c/strong\u003e: 외부 서비스 장애, 인증 만료, Rate limit, 권한 부족 시 재시도와 Escalation 규칙이 필요하다.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#6-proactive-loop-작업-발견과-오케스트레이션을-넘긴다\" class=\"anchor\" id=\"6-proactive-loop-작업-발견과-오케스트레이션을-넘긴다\"\u003e\u003c/a\u003e6. Proactive Loop: 작업 발견과 오케스트레이션을 넘긴다\u003c/h2\u003e\n\u003cp\u003eProactive Loop는 하나의 명령이 아니라 여러 기능을 결합한 상시 자동화 아키텍처다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003e+ Goal\n\u003c/span\u003e\u003cspan\u003e+ Skills\n\u003c/span\u003e\u003cspan\u003e+ Dynamic Workflow\n\u003c/span\u003e\u003cspan\u003e+ Auto mode\n\u003c/span\u003e\u003cspan\u003e+ Repository·Connector·Browser·CI 도구\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e사람이 실시간으로 프롬프트를 입력하지 않아도 새 작업이 감지되고, 처리되고, 검증되고, 결과가 보고된다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#예-버그-피드백-자동-처리\" class=\"anchor\" id=\"예-버그-피드백-자동-처리\"\u003e\u003c/a\u003e예: 버그 피드백 자동 처리\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eGitHub Issue 또는 Slack 피드백 수신\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e중복·우선순위·재현 가능성 분류\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e재현 테스트 생성\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e후보 해결책 탐색\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e선택한 해결책 구현\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e독립 Review Agent가 반례 탐색\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e테스트·빌드·보안 검증\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eDraft PR과 결과 보고\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e구성 요소별 책임은 다음과 같다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e구성 요소\u003c/th\u003e\n\u003cth\u003e책임\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTrigger 또는 \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e새 작업을 시작할 시점 결정\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e이번 실행에서 무엇이 완료 상태인지 정의\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSkill\u003c/td\u003e\n\u003ctd\u003e재현, 구현, 검증, 보고 절차 표준화\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003ctd\u003e다수 Subagent의 병렬 실행과 조건 분기\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAuto mode\u003c/td\u003e\n\u003ctd\u003e허용된 도구 호출을 승인 대기 없이 실행\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermission policy\u003c/td\u003e\n\u003ctd\u003e금지·승인·자동 허용 범위 고정\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#dynamic-workflow와-worktree\" class=\"anchor\" id=\"dynamic-workflow와-worktree\"\u003e\u003c/a\u003eDynamic Workflow와 Worktree\u003c/h3\u003e\n\u003cp\u003eDynamic Workflow는 Claude가 작성한 JavaScript 오케스트레이션 Script를 Runtime이 실행하는 구조다. 일반 Subagent 호출에서는 Claude가 Turn마다 다음 Agent를 선택하지만, Workflow에서는 Loop, 병렬 처리, 분기, 중간 결과 저장이 Script로 이동한다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eWorkflow Script\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent A: 요구사항 분석\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent B: 테스트 설계\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent C: 구현 후보 탐색\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent D: 보안 검토\n\u003c/span\u003e\u003cspan\u003e  └─ Judge: 증거 기반 비교\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e중간 결과가 메인 대화 Context가 아니라 Script 변수에 남기 때문에 대규모 작업을 더 재현 가능하게 조직할 수 있다. 현행 문서에는 동시에 최대 16개 Agent, 실행당 최대 1,000개 Agent라는 Runtime 한도가 명시되어 있으나, 제품 Preview 단계의 제한은 바뀔 수 있다.\u003c/p\u003e\n\u003cp\u003e여러 구현 후보를 동시에 시험해야 한다면 Git Worktree로 작업 공간을 분리할 수 있다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003erepo/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-a/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-b/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-c/\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e각 Agent가 독립 Branch와 디렉터리에서 작업하면 같은 파일을 동시에 덮어쓰는 문제를 줄일 수 있다. Judge Agent는 요구사항 충족, 테스트 결과, 회귀 위험, 변경 범위, 복잡도, 성능, 보안, 기존 아키텍처와의 일관성을 기준으로 후보를 비교해야 한다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#더-많은-agent가-항상-좋은-것은-아니다\" class=\"anchor\" id=\"더-많은-agent가-항상-좋은-것은-아니다\"\u003e\u003c/a\u003e더 많은 Agent가 항상 좋은 것은 아니다\u003c/h3\u003e\n\u003cp\u003e병렬성이 없는 작업에 Agent 수만 늘리면 비용과 지연이 증가한다. 여러 Agent가 같은 잘못된 가정을 공유하면 오류가 확대될 수도 있다.\u003c/p\u003e\n\u003cp\u003eDynamic Workflow가 적합한 경우는 다음과 같다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e수백 파일에 같은 변환을 적용하는 Migration\u003c/li\u003e\n\u003cli\u003e코드베이스 전체의 보안·품질 Audit\u003c/li\u003e\n\u003cli\u003e독립적인 여러 관점의 Plan 비교\u003c/li\u003e\n\u003cli\u003e많은 항목을 분할 처리하고 교차 검증해야 하는 Research\u003c/li\u003e\n\u003cli\u003e한 Agent의 Context에 모든 중간 결과를 담기 어려운 작업\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e작은 버그 수정, 한 파일 리팩터링, 단순 테스트 추가에는 일반 Turn-based Loop나 \u003ccode\u003e/goal\u003c/code\u003e이 더 낫다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#7-loop에서-코드-품질을-유지하는-시스템\" class=\"anchor\" id=\"7-loop에서-코드-품질을-유지하는-시스템\"\u003e\u003c/a\u003e7. Loop에서 코드 품질을 유지하는 시스템\u003c/h2\u003e\n\u003cp\u003eLoop 결과의 품질은 모델 자체뿐 아니라 모델 주변의 검증 시스템에 크게 좌우된다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#71-코드베이스를-정돈한다\" class=\"anchor\" id=\"71-코드베이스를-정돈한다\"\u003e\u003c/a\u003e7.1 코드베이스를 정돈한다\u003c/h3\u003e\n\u003cp\u003eClaude는 기존 코드의 패턴을 강하게 따라간다. 오래된 API, 중복 구현, 불명확한 테스트 구조, 거대한 모듈, 일관되지 않은 예외 처리 규칙이 있으면 Loop가 그 문제를 빠르게 복제할 수 있다.\u003c/p\u003e\n\u003cp\u003e필수 기반은 다음과 같다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFormatter와 lint\u003c/li\u003e\n\u003cli\u003e명확한 디렉터리와 모듈 경계\u003c/li\u003e\n\u003cli\u003e신뢰할 수 있는 Unit·Integration·E2E Test\u003c/li\u003e\n\u003cli\u003e사용 중인 API와 Deprecated API의 구분\u003c/li\u003e\n\u003cli\u003e프로젝트별 개발 규칙\u003c/li\u003e\n\u003cli\u003e재현 가능한 Build·Dev 환경\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#72-변경-유형별-definition-of-done을-만든다\" class=\"anchor\" id=\"72-변경-유형별-definition-of-done을-만든다\"\u003e\u003c/a\u003e7.2 변경 유형별 Definition of Done을 만든다\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e변경 유형\u003c/th\u003e\n\u003cth\u003e최소 검증\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAPI\u003c/td\u003e\n\u003ctd\u003e계약 테스트, 하위 호환성, Schema·문서 예제 갱신\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFrontend\u003c/td\u003e\n\u003ctd\u003e실제 브라우저 조작, 콘솔 오류, 접근성, 반응형 화면\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDatabase\u003c/td\u003e\n\u003ctd\u003eForward·Rollback Migration, Lock 범위, 실행 계획\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDependency\u003c/td\u003e\n\u003ctd\u003eBuild, 주요 회귀 테스트, License·Security 확인\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInfrastructure\u003c/td\u003e\n\u003ctd\u003ePlan Diff, 최소 권한, Rollback, 비밀정보 노출 검사\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e이 기준은 Prompt에 매번 길게 반복하기보다 Skill, Hook, Script, CI Rule로 고정하는 편이 좋다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#73-최신-문서와-정확한-버전을-제공한다\" class=\"anchor\" id=\"73-최신-문서와-정확한-버전을-제공한다\"\u003e\u003c/a\u003e7.3 최신 문서와 정확한 버전을 제공한다\u003c/h3\u003e\n\u003cp\u003eLoop는 잘못된 가정을 여러 차례 반복할 수 있다. 프로젝트에서 사용하는 정확한 Version, 공식 문서, 내부 Architecture 문서, API 명세, Migration Guide, 승인된 예제를 쉽게 찾게 해야 한다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#74-구현-agent와-review-agent를-분리한다\" class=\"anchor\" id=\"74-구현-agent와-review-agent를-분리한다\"\u003e\u003c/a\u003e7.4 구현 Agent와 Review Agent를 분리한다\u003c/h3\u003e\n\u003cp\u003e구현한 Agent는 이미 선택한 설계와 추론에 영향을 받는다. 새 Context의 Review Agent는 다음 질문을 더 독립적으로 던질 수 있다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e테스트를 약화시켜 통과시킨 것은 아닌가?\u003c/li\u003e\n\u003cli\u003e범위 밖 파일을 바꾸지 않았는가?\u003c/li\u003e\n\u003cli\u003e보안 경계가 깨지지 않았는가?\u003c/li\u003e\n\u003cli\u003e실패 경로와 경계값 테스트가 빠지지 않았는가?\u003c/li\u003e\n\u003cli\u003e기존 기능에 회귀가 생기지 않았는가?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eReview Prompt는 “좋은 점을 요약하라”보다 “구현이 틀렸다는 가정에서 반례를 찾고, 각 지적에 재현 증거를 붙여라”처럼 작성하는 편이 효과적이다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#75-개별-실패를-시스템-개선으로-연결한다\" class=\"anchor\" id=\"75-개별-실패를-시스템-개선으로-연결한다\"\u003e\u003c/a\u003e7.5 개별 실패를 시스템 개선으로 연결한다\u003c/h3\u003e\n\u003cp\u003e같은 오류가 반복되면 해당 결과만 수정해서는 안 된다. 실패 유형이 재발하기 어렵도록 다음 중 하나를 바꿔야 한다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eRegression Test 추가\u003c/li\u003e\n\u003cli\u003eSkill 검증 절차 강화\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eCLAUDE.md\u003c/code\u003e 규칙 추가\u003c/li\u003e\n\u003cli\u003eHook 또는 lint Rule 추가\u003c/li\u003e\n\u003cli\u003e권한 Deny Rule 추가\u003c/li\u003e\n\u003cli\u003eGoal의 완료 조건 강화\u003c/li\u003e\n\u003cli\u003eReview Checklist 보완\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e좋은 Loop Engineering은 한 번의 실패를 고치는 작업이 아니라 \u003cstrong\u003e그 종류의 실패가 다시 나오기 어려운 시스템을 만드는 작업\u003c/strong\u003e이다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#8-token과-비용-관리\" class=\"anchor\" id=\"8-token과-비용-관리\"\u003e\u003c/a\u003e8. Token과 비용 관리\u003c/h2\u003e\n\u003cp\u003eLoop 비용은 단일 Prompt보다 크게 증가할 수 있다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e총비용 ≈\n\u003c/span\u003e\u003cspan\u003e메인 Agent Turn 비용\n\u003c/span\u003e\u003cspan\u003e+ Goal 평가 비용\n\u003c/span\u003e\u003cspan\u003e+ Subagent 비용\n\u003c/span\u003e\u003cspan\u003e+ Workflow 반복 비용\n\u003c/span\u003e\u003cspan\u003e+ 도구 결과를 읽는 Context 비용\n\u003c/span\u003e\u003cspan\u003e+ 시간 기반 실행 빈도\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e정확한 과금은 Plan, Model, Provider에 따라 다르지만 비용 구조를 결정하는 원리는 동일하다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#비용을-줄이는-실무-원칙\" class=\"anchor\" id=\"비용을-줄이는-실무-원칙\"\u003e\u003c/a\u003e비용을 줄이는 실무 원칙\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e작은 작업에는 Loop를 쓰지 않는다.\u003c/strong\u003e 오타, 이름 변경, 한 파일의 타입 오류는 단일 Turn으로 처리한다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e성공 조건과 Hard stop을 함께 둔다.\u003c/strong\u003e 성공, 최대 Turn, 최대 시간, 연속 실패, 권한 오류를 모두 고려한다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e대규모 Workflow는 작은 범위에서 시험한다.\u003c/strong\u003e 5개 파일, 한 디렉터리, 일부 Issue로 비용과 품질을 검증한 뒤 확대한다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e결정론적 작업은 Script로 처리한다.\u003c/strong\u003e AST 치환, JSON 변환, Formatting, 고정 양식 생성은 검증된 Script가 더 저렴하고 재현 가능하다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolling 주기를 실제 변경 빈도에 맞춘다.\u003c/strong\u003e 가능하면 Event Trigger를 사용한다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e진행 중 사용량을 관찰한다.\u003c/strong\u003e \u003ccode\u003e/usage\u003c/code\u003e, \u003ccode\u003e/goal\u003c/code\u003e, \u003ccode\u003e/workflows\u003c/code\u003e에서 Skill·Subagent·MCP·Turn·Token 사용량을 확인한다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e같은 오류가 반복되면 계속 재시도하지 않는다.\u003c/strong\u003e 연속 실패 한도를 두고 사람에게 Escalation한다.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#model과-effort는-다른-레버다\" class=\"anchor\" id=\"model과-effort는-다른-레버다\"\u003e\u003c/a\u003eModel과 Effort는 다른 레버다\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eModel\u003c/strong\u003e은 기본 추론 능력과 해결 가능한 문제의 범위를 바꾼다.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEffort\u003c/strong\u003e는 읽는 파일 수, 사용하는 도구 수, 검증의 폭, 여러 단계 작업을 얼마나 끝까지 밀어붙이는지를 바꾼다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eClaude가 필요한 파일과 테스트를 모두 확인했지만 판단 자체가 계속 틀리면 더 강한 Model이 필요할 수 있다. 반대로 중요한 파일을 읽지 않거나 테스트를 건너뛰거나 리팩터링을 중간에 끝냈다면 Effort를 높이는 편이 더 적절할 수 있다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#9-권한과-안전-경계\" class=\"anchor\" id=\"9-권한과-안전-경계\"\u003e\u003c/a\u003e9. 권한과 안전 경계\u003c/h2\u003e\n\u003cp\u003eProactive Loop에서 가장 위험한 설계는 Agent에게 넓은 권한을 주고, 성공 조건과 중단 조건을 느슨하게 두는 것이다.\u003c/p\u003e\n\u003cp\u003eAuto mode는 일반 권한 Prompt를 줄이지만, 되돌리기 어렵거나 파괴적이거나 신뢰 경계 밖을 대상으로 하는 Tool call은 분류기가 차단할 수 있다. 또한 명시적인 \u003ccode\u003epermissions.ask\u003c/code\u003e와 \u003ccode\u003epermissions.deny\u003c/code\u003e는 Auto mode보다 우선한다.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#권한-계층-예시\" class=\"anchor\" id=\"권한-계층-예시\"\u003e\u003c/a\u003e권한 계층 예시\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e수준\u003c/th\u003e\n\u003cth\u003e예시\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e자동 허용\u003c/td\u003e\n\u003ctd\u003e코드 읽기, 테스트·lint·Build, 분석, \u003ccode\u003eclaude/*\u003c/code\u003e Branch 생성, Draft PR 생성\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e사람 승인\u003c/td\u003e\n\u003ctd\u003eDefault Branch 반영, 운영 배포, DB Migration 적용, 외부 고객 메시지 전송\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e항상 금지\u003c/td\u003e\n\u003ctd\u003eForce push, Secret 출력, 운영 데이터 삭제, 권한 우회, 감사 로그 제거\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e대화에서 “Push하지 마라”고 한 번 말하는 것보다 영구 \u003ccode\u003eask\u003c/code\u003e·\u003ccode\u003edeny\u003c/code\u003e Rule로 고정하는 편이 안전하다. Context 압축이나 세션 변경으로 대화 규칙이 약해질 수 있기 때문이다.\u003c/p\u003e\n\u003cp\u003eCloud Routine은 실행마다 Repository를 새로 Clone하고 연결된 GitHub·Connector 권한으로 동작한다. 다음 범위를 최소화해야 한다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e접근 가능한 Repository와 Branch\u003c/li\u003e\n\u003cli\u003e허용된 Network Domain\u003c/li\u003e\n\u003cli\u003e사용할 Connector\u003c/li\u003e\n\u003cli\u003e환경 변수와 Secret\u003c/li\u003e\n\u003cli\u003e외부 시스템 쓰기 권한\u003c/li\u003e\n\u003cli\u003ePR 생성·Push·Merge 범위\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eRoutine 실행 목록의 “정상 종료” 상태는 Infrastructure 오류 없이 Session이 끝났다는 뜻일 수 있으며, 업무 목표가 성공했다는 보장은 아니다. Transcript, Test evidence, 생성된 Diff를 별도로 검토해야 한다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#10-개발-프로젝트용-loop-설계-템플릿\" class=\"anchor\" id=\"10-개발-프로젝트용-loop-설계-템플릿\"\u003e\u003c/a\u003e10. 개발 프로젝트용 Loop 설계 템플릿\u003c/h2\u003e\n\u003cp\u003e다음 YAML은 실제 Claude Code 문법이 아니라 설계 검토용 Template이다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003etrigger\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003etype\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003emanual | interval | schedule | github_event | api_event\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003escope\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erepositories\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etarget-repository\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallowed_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esrc/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etests/**\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eprohibited_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eproduction/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esecrets/**\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003etask\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eobjective\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e변경하거나 처리할 목표\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einput\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e새로 들어오는 Issue, Event, File 또는 상태\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003everification\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ecommands\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eunit-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eintegration-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003elint\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebuild\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eruntime_checks\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebrowser-interaction\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003econsole-errors\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eaccessibility\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eevidence\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ecommand-output\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eexit-code\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etest-summary\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003escreenshots\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003esuccess\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003econdition\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e참과 거짓으로 판정 가능한 완료 상태\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estop\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_turns\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e12\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_duration_minutes\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e45\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_consecutive_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e3\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003estop_on_permission_error\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eescalate_on_external_outage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eside_effects\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eidempotency_key\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eevent-id-or-commit-sha\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallow_branch_push\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eclaude/*\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_merge\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_deploy\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003ereview\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eindependent_agent\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eadversarial_review\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eobservability\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_progress\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_token_usage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_changed_files\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_remaining_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e가장 중요한 항목은 프롬프트 문장 자체보다 다음 다섯 가지다.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003eVerifier\n\u003c/span\u003e\u003cspan\u003eSuccess condition\n\u003c/span\u003e\u003cspan\u003eHard stop\n\u003c/span\u003e\u003cspan\u003ePermission boundary\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch2\u003e\u003ca href=\"#11-어떤-loop를-선택해야-하는가\" class=\"anchor\" id=\"11-어떤-loop를-선택해야-하는가\"\u003e\u003c/a\u003e11. 어떤 Loop를 선택해야 하는가\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e상황\u003c/th\u003e\n\u003cth\u003e권장 방식\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e한 번의 수정과 검증으로 끝나는 작업\u003c/td\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e여러 번 시도해야 하지만 완료 상태가 명확한 작업\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e외부 CI·PR·배포 상태를 잠시 기다려야 하는 작업\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e노트북을 닫아도 반복 실행해야 하는 업무\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eGitHub 이벤트나 Alert에 즉시 반응해야 하는 업무\u003c/td\u003e\n\u003ctd\u003eEvent-triggered Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e수백 항목을 병렬 처리하고 교차 검증해야 하는 업무\u003c/td\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e입력과 출력 규칙이 완전히 결정론적인 변환\u003c/td\u003e\n\u003ctd\u003eScript 또는 CI Job\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e선택 순서는 “가장 강력한 기능”이 아니라 “목표를 달성하는 가장 단순한 제어 구조”를 기준으로 해야 한다.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#12-안전한-도입-순서\" class=\"anchor\" id=\"12-안전한-도입-순서\"\u003e\u003c/a\u003e12. 안전한 도입 순서\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e사람이 반복해서 확인하는 병목 업무 하나를 고른다.\u003c/li\u003e\n\u003cli\u003e먼저 검증 절차를 Skill, Script, CI로 만든다.\u003c/li\u003e\n\u003cli\u003eTurn-based 방식에서 검증 품질을 안정화한다.\u003c/li\u003e\n\u003cli\u003e완료 상태가 명확하면 \u003ccode\u003e/goal\u003c/code\u003e을 붙인다.\u003c/li\u003e\n\u003cli\u003e외부 상태를 기다려야 할 때만 \u003ccode\u003e/loop\u003c/code\u003e를 사용한다.\u003c/li\u003e\n\u003cli\u003e장기 실행이 필요하면 \u003ccode\u003e/schedule\u003c/code\u003e Routine으로 옮긴다.\u003c/li\u003e\n\u003cli\u003e멱등성, 권한, 비용이 검증된 뒤에만 Dynamic Workflow와 Proactive Loop로 확장한다.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#13-자주-발생하는-오해\" class=\"anchor\" id=\"13-자주-발생하는-오해\"\u003e\u003c/a\u003e13. 자주 발생하는 오해\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e오해\u003c/th\u003e\n\u003cth\u003e정확한 해석\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoop는 무한 실행이다\u003c/td\u003e\n\u003ctd\u003e성공 조건과 Hard stop이 있는 제한된 반복 구조다\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgent의 완료 보고는 검증이다\u003c/td\u003e\n\u003ctd\u003e외부 명령 출력, 종료 코드, Runtime 결과가 필요하다\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e이 모든 권한을 자동 허용한다\u003c/td\u003e\n\u003ctd\u003e다음 Turn만 자동 시작하며 권한 정책은 별개다\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e는 장기 운영 Scheduler다\u003c/td\u003e\n\u003ctd\u003e세션 중심이고 7일 만료와 실행 환경 제약이 있다\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgent가 많을수록 결과가 좋아진다\u003c/td\u003e\n\u003ctd\u003e역할·관점·검증이 다를 때만 병렬화의 가치가 생긴다\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e모든 반복 작업은 LLM이 해야 한다\u003c/td\u003e\n\u003ctd\u003e결정론적 부분은 Script가 더 싸고 재현성이 높다\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#결론\" class=\"anchor\" id=\"결론\"\u003e\u003c/a\u003e결론\u003c/h2\u003e\n\u003cp\u003eLoop Engineering은 AI를 오래 실행시키는 기술이 아니라, \u003cstrong\u003eAI가 틀렸을 때 스스로 발견하고, 비용 한도 안에서 수정하며, 위험한 지점에서는 멈추도록 만드는 제어 시스템 설계\u003c/strong\u003e다.\u003c/p\u003e\n\u003cp\u003eLLM은 탐색, 추론, 구현, 예외 분석, 대안 비교에 강하다. 시스템은 실행 시점, 변경 범위, 검증 방법, 종료 기준, 비용 한도, 승인 경계를 담당해야 한다. 이 역할 분담이 명확할수록 Claude Code 자동화는 단순한 코드 생성 도구를 넘어 재현 가능하고 감사 가능한 개발 운영 시스템에 가까워진다.\u003c/p\u003e\n","tags":["Claude Code","Loop Engineering","AI Agent","개발 자동화","Agent Workflow"],"faqs":[{"question":"Claude Code의 Loop는 일반적인 for·while 반복문과 무엇이 다른가요?","answer":"일반 반복문은 코드에 정의된 명령을 결정론적으로 반복합니다. Claude Code의 Loop는 Agent가 코드와 외부 상태를 관찰하고, 다음 행동을 추론하고, 도구를 실행하고, 결과를 검증한 뒤 종료 조건에 따라 다시 작업하는 에이전트 제어 구조입니다."},{"question":"Turn-based Loop는 언제 가장 적합한가요?","answer":"짧고 일회성이며 사용자가 결과를 바로 검토할 수 있는 작업에 적합합니다. 다만 UI·API·데이터베이스처럼 검증 절차가 반복된다면 그 절차를 Skill이나 Script로 만들어 Claude가 같은 기준으로 자체 검증하게 하는 것이 좋습니다."},{"question":"`/goal` 평가 모델은 파일과 테스트 결과를 직접 확인하나요?","answer":"아닙니다. 평가 모델은 도구를 호출하거나 파일을 직접 읽지 않고, Goal 조건과 대화에 드러난 증거를 판단합니다. 작업 Claude가 테스트 명령, 종료 코드, 변경 파일, 실패 원인을 결과에 명확히 남겨야 합니다."},{"question":"좋은 `/goal` 조건에는 무엇이 들어가야 하나요?","answer":"측정 가능한 완료 상태, 그 상태를 증명할 명령이나 도구, 변경 가능한 범위와 금지 범위, 최대 Turn·시간·연속 실패 같은 Hard stop이 필요합니다. '깔끔하게 리팩터링'보다 '테스트와 lint가 종료 코드 0이고 지정 경로 밖 Diff가 없다'가 좋은 조건입니다."},{"question":"`/goal`에는 자동 최대 Turn이나 시간 제한이 있나요?","answer":"Goal은 평가 모델이 성공을 판정하거나 사용자가 `/goal clear`로 중단할 때까지 이어집니다. 실행 예산을 제한하려면 '최대 12턴 또는 45분 후 중단'처럼 Goal 조건에 Turn·시간 조항을 직접 포함해야 합니다."},{"question":"`/goal`을 사용하면 도구 권한도 자동으로 허용되나요?","answer":"아닙니다. `/goal`은 다음 Turn을 자동으로 시작하지만 파일 쓰기, Shell, Git, 외부 Connector 권한 정책은 그대로 유지됩니다. 무인 실행이 필요하면 Auto mode를 고려하되 `ask`·`deny` 규칙으로 위험한 작업을 별도로 통제해야 합니다."},{"question":"`/loop`와 `/schedule`의 가장 큰 차이는 무엇인가요?","answer":"`/loop`는 현재 Claude Code 세션과 컴퓨터에서 반복 실행하는 단기 Polling 수단입니다. `/schedule`은 Prompt와 Repository, Connector, Trigger를 Cloud Routine으로 저장해 Anthropic 관리 인프라에서 실행하므로 열린 세션이나 켜진 노트북이 필요하지 않습니다."},{"question":"컴퓨터를 끄면 `/loop`가 계속 실행되나요?","answer":"일반적으로 계속 실행되지 않습니다. `/loop`는 세션 범위 작업이며 Claude Code가 실행 중이어야 합니다. 장기 자동화에는 Cloud Routine, Desktop scheduled task, GitHub Actions 같은 지속 가능한 Scheduler를 사용해야 합니다."},{"question":"시간 Polling보다 Event Trigger가 더 좋은 이유는 무엇인가요?","answer":"변화가 없을 때 불필요한 모델 호출을 만들지 않고, 실제 변경 직후에 실행할 수 있기 때문입니다. CI 실패, PR 업데이트, Alert처럼 이벤트를 발행할 수 있는 시스템은 GitHub Trigger나 Routine API로 연결하는 편이 비용과 지연 모두에 유리합니다."},{"question":"검증 절차를 `CLAUDE.md`가 아니라 `SKILL.md`에 두는 이유는 무엇인가요?","answer":"`CLAUDE.md`는 프로젝트 전반에 항상 적용할 짧은 규칙에 적합하고, Skill은 특정 작업에서만 필요한 절차와 지원 파일을 묶는 데 적합합니다. 긴 검증 체크리스트를 Skill로 분리하면 관련 작업에서만 로드하고 직접 재실행할 수 있습니다."},{"question":"Dynamic Workflow는 일반 Subagent 호출과 어떻게 다른가요?","answer":"일반 Subagent 방식에서는 Claude가 Turn마다 다음 작업자를 선택하고 결과가 Context에 쌓입니다. Dynamic Workflow는 JavaScript Script가 병렬 실행, 분기, 반복, 중간 결과를 관리하므로 대규모 Migration·Audit·교차 검증을 더 재현 가능하게 조직할 수 있습니다."},{"question":"여러 Agent를 사용하면 항상 품질이 좋아지나요?","answer":"아닙니다. 역할과 관점이 겹치면 같은 오류를 반복하면서 비용만 증가할 수 있습니다. 구현, 테스트 설계, 보안 검토, 회귀 분석, Judge처럼 책임을 분리하고 각 결론에 독립적인 증거를 요구해야 병렬 Agent의 가치가 생깁니다."},{"question":"Time-based 또는 Proactive Loop에서 중복 작업은 어떻게 막나요?","answer":"Event ID, Commit SHA, Review Comment ID 같은 Idempotency key와 마지막 처리 상태를 저장해야 합니다. 이미 답변한 메시지, 이미 만든 PR, 이미 처리한 Commit을 다시 처리하지 않는 규칙을 검증 단계에 포함해야 합니다."},{"question":"처음 자동화할 Loop는 어떤 업무가 좋은가요?","answer":"사람이 반복해서 확인하지만 위험한 Side effect는 적고, 완료 상태를 명확히 측정할 수 있는 업무가 좋습니다. 예를 들어 PR의 실패한 CI 원인 요약, 문서와 코드의 불일치 탐지, 정해진 테스트·lint 검증부터 시작한 뒤 수정과 Push 권한을 단계적으로 확대하는 방식이 안전합니다."}],"sources":[{"url":"https://claude.com/blog/getting-started-with-loops","title":"Loop engineering: Getting started with loops | Claude by Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/skills","title":"Extend Claude with skills - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/goal","title":"Keep Claude working toward a goal - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/scheduled-tasks","title":"Run prompts on a schedule - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/routines","title":"Automate work with routines - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/workflows","title":"Orchestrate subagents at scale with dynamic workflows - Claude Code Docs","type":"source"},{"url":"https://claude.com/blog/claude-model-and-effort-level-in-claude-code","title":"Choosing a Claude model and effort level in Claude Code | Claude by Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/auto-mode-config","title":"Configure auto mode - Claude Code Docs","type":"source"}],"images":[{"id":195,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 06_56_28.png","translations":{"ko":{"alt":"AI 로봇과 코드 화면을 중심으로 반복 화살표, 목표·시간·보안·비용 아이콘이 연결된 자동화 구조","caption":"관찰·실행·검증을 반복하는 AI 에이전트와 목표, 일정, 권한, 강제 종료, 비용 제어 요소를 함께 보여준다.","description":null},"en":{"alt":"AI robot and code dashboard surrounded by loop arrows, goal, schedule, security, and cost control icons","caption":"The illustration shows an AI agent repeating observation, action, and verification within goal, timing, permission, stop, and cost controls.","description":null},"ja":{"alt":"AIロボットとコード画面を中心に、循環矢印、目標、時間、安全、コスト管理のアイコンが連結された構成","caption":"観察・実行・検証を繰り返すAIエージェントを、目標、実行時期、権限、停止、コストの制御要素とともに示している。","description":null},"es":{"alt":"Robot de IA y panel de código rodeados por flechas de ciclo e iconos de objetivo, tiempo, seguridad y coste","caption":"La ilustración muestra un agente de IA que repite observación, acción y verificación bajo controles de objetivo, tiempo, permisos, parada y coste.","description":null},"id":{"alt":"Robot AI dan dasbor kode dikelilingi panah loop serta ikon tujuan, waktu, keamanan, dan biaya","caption":"Ilustrasi menampilkan agen AI yang mengulang observasi, tindakan, dan verifikasi dengan kontrol tujuan, waktu, izin, penghentian, dan biaya.","description":null},"pt":{"alt":"Robô de IA e painel de código cercados por setas de ciclo e ícones de meta, tempo, segurança e custo","caption":"A ilustração mostra um agente de IA repetindo observação, ação e verificação sob controles de objetivo, tempo, permissão, parada e custo.","description":null},"zh-hant":{"alt":"AI 機器人與程式碼面板置於循環箭頭中央，周圍連結目標、時間、安全與成本控制圖示","caption":"圖中呈現 AI 代理在目標、排程、權限、強制停止與成本控制下反覆觀察、執行與驗證。","description":null}}},{"id":196,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 07_02_56.png","translations":{"ko":{"alt":"보호 울타리 안의 AI 에이전트가 검증, 중단 장치, 권한 게이트와 비용 계측을 거쳐 작업하는 자동화 구조","caption":"트리거부터 검증과 강제 중단, 자원 관리, 승인된 결과 출력까지 안전하게 통제되는 에이전트 워크플로를 보여준다.","description":null},"en":{"alt":"AI agent inside a guarded workspace with verification, stop controls, permission gates, and resource monitoring","caption":"The illustration shows an agent workflow controlled from triggers through validation, hard stops, resource checks, and approved output.","description":null},"ja":{"alt":"検証、強制停止、権限ゲート、資源監視に囲まれた保護領域内のAIエージェント","caption":"トリガーから検証、停止制御、コスト管理、承認済み出力まで安全に統制されたエージェント処理を表している。","description":null},"es":{"alt":"Agente de IA en un entorno protegido con verificación, parada forzada, permisos y control de recursos","caption":"La ilustración muestra un flujo de agente controlado desde los disparadores hasta la validación, los límites y la salida aprobada.","description":null},"id":{"alt":"Agen AI dalam area terlindungi dengan verifikasi, penghentian paksa, gerbang izin, dan pemantauan sumber daya","caption":"Ilustrasi ini menunjukkan alur agen yang dikendalikan dari pemicu hingga validasi, batas aman, pemantauan biaya, dan keluaran yang disetujui.","description":null},"pt":{"alt":"Agente de IA em área protegida com verificação, parada forçada, controle de permissões e monitoramento de recursos","caption":"A ilustração mostra um fluxo de agente controlado desde os gatilhos até a validação, os limites de segurança e a saída aprovada.","description":null},"zh-hant":{"alt":"受保護工作區中的AI代理，周圍設有驗證、強制停止、權限閘門與資源監控","caption":"圖中呈現從觸發、驗證、停止控制與成本監測，到核准輸出的安全代理工作流程。","description":null}}},{"id":197,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg5MywicHVyIjoiYmxvYl9pZCJ9fQ==--e01f93aca2cdddbb93cbe0defb4264b720d5be48/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_06_12.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 07_06_12.png","visible_locales":["ko"],"translations":{"ko":{"alt":"Claude Code의 4가지 Loop 유형, 검증 강도, 안전 원칙과 선택 기준을 정리한 인포그래픽","caption":"관찰·행동·검증의 반복 구조와 Turn-based, Goal-based, Time-based, Proactive Loop의 설계 원칙을 보여준다.","description":null},"en":{"alt":"Infographic comparing four Claude Code loops, evidence levels, safety principles, and selection guidance","caption":"It summarizes the observe-act-verify cycle and safe design principles for four Claude Code loop types.","description":null},"ja":{"alt":"Claude Codeの4種類のLoop、検証強度、安全原則、選択基準を整理したインフォグラフィック","caption":"観察・行動・検証の反復構造と4種類のLoopを安全に設計する要点を示している。","description":null},"es":{"alt":"Infografía sobre cuatro bucles de Claude Code, niveles de evidencia, seguridad y criterios de elección","caption":"Resume el ciclo observar-actuar-verificar y los principios de diseño seguro para cuatro tipos de bucle.","description":null},"id":{"alt":"Infografik empat jenis loop Claude Code, tingkat bukti, prinsip keamanan, dan panduan pemilihan","caption":"Infografik ini merangkum siklus observasi, tindakan, verifikasi, serta desain aman untuk empat jenis loop.","description":null},"pt":{"alt":"Infográfico dos quatro loops do Claude Code, níveis de evidência, princípios de segurança e escolha","caption":"Resume o ciclo observar-agir-verificar e os princípios de design seguro para quatro tipos de loop.","description":null},"zh-hant":{"alt":"整理 Claude Code 四種 Loop、驗證強度、安全原則與選擇指南的資訊圖","caption":"圖中概述觀察、行動、驗證的循環，以及四種 Loop 的安全設計重點。","description":null}}}],"published_at":"2026-07-17T09:40:17+09:00","updated_at":"2026-07-17T09:40:17+09:00","license":"cc_by","translation_status":"original","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/ko/articles/claude-code-loop-engineering-guide"}