Claude Code Sub Agent와 Loop Agent Pattern: 분리 실행과 반복 개선

업데이트: July 06, 2026

개요

Claude Code를 실무에서 사용하다 보면 모든 작업을 하나의 대화 컨텍스트에서 처리하기 어렵다.

대규모 코드베이스 분석, 보안 점검, 로그 요약처럼 탐색량이 많은 작업은 메인 대화 컨텍스트를 빠르게 오염시킨다. 반대로 테스트 실패를 수정하거나 문서를 다듬는 작업은 한 번의 응답보다 반복적인 계획, 실행, 관찰, 재계획이 더 중요하다.

이 글에서는 Claude Code에서 활용 가능한 두 가지 Agent 실행 방식을 정리한다.

첫 번째는 Claude Code가 공식적으로 제공하는 Sub Agent이다.

두 번째는 반복적인 개선 작업을 위해 자주 사용하는 Loop Agent Pattern이다.

중요한 점은 다음과 같다.

항목	구분	설명
Sub Agent	Claude Code 공식 기능	별도 Agent Context에서 작업을 수행하고 요약 결과를 Parent Agent에 반환
Loop Agent Pattern	Agent 설계 패턴	목표 달성까지 계획, 실행, 관찰, 평가, 재계획을 반복

즉, Loop Agent는 Claude Code의 독립된 공식 기능명이 아니다. 이 글에서는 반복 개선 루프를 구성하는 설계 패턴이라는 의미로 사용한다.

환경

이 글의 예제는 다음 구성을 기준으로 한다.

항목	값
Agent Runtime	Claude Code 및 호환 Agent 환경
Customization	Skills, Hooks
Hook 설정	`.claude/settings.json`, `.github/hooks/development.json`
Skill 위치	`.github/skills` 예제
Script 위치	`scripts`
필수 도구	`bash`, `jq` 권장

jq는 Hook 입력 JSON을 안전하게 파싱하고 로그 JSON을 생성하기 위해 사용한다. 없어도 샘플 스크립트가 동작하도록 fallback을 두었지만, 운영 환경에서는 jq를 설치하는 편이 좋다.

Claude Code Agent 구조

Claude Code에서 Parent Agent는 사용자의 요청을 해석하고, 필요하면 별도의 Sub Agent에 일부 작업을 위임한다. Sub Agent는 Parent Agent의 전체 컨텍스트를 그대로 공유하지 않는다.

필요한 작업 설명, 현재 작업 디렉터리, 허용된 도구, 시스템 지시사항 등 실행에 필요한 정보만 전달받아 독립적으로 작업하고, 최종 결과만 Parent Agent에 반환한다.

Parent Agent
      |
      | Task Delegation
      v
+----------------+
|  Sub Agent     |
| context: fork  |
+----------------+
      |
      | Analysis
      | Tool Use
      | Reasoning
      v
 Summary
      |
      v
Parent Agent

이 구조의 핵심은 컨텍스트 절약이다.

Parent Agent가 모든 검색 결과, 로그, 중간 추론, 실패한 시도까지 직접 들고 있으면 대화 품질이 빠르게 떨어진다. Sub Agent는 그런 탐색성 작업을 별도 컨텍스트에서 처리하고, Parent Agent에는 의사결정에 필요한 요약만 돌려준다.

Sub Agent

개념

Sub Agent는 Claude Code가 공식적으로 제공하는 분리 실행 구조이다. 특정 작업을 별도의 Agent Context에서 처리하고, 결과를 Parent Agent에 반환한다.

대표적인 사용 사례는 다음과 같다.

대규모 코드베이스 분석
보안 취약점 탐지
로그 분석
문서 요약
변경 영향도 조사
테스트 실패 원인 탐색

Sub Agent를 사용할 때는 다음 기준이 중요하다.

기준	설명
작업 범위	Parent Agent가 직접 처리하기에는 탐색량이 큰가
컨텍스트 비용	검색 결과나 로그가 메인 대화에 오래 남을 필요가 있는가
도구 권한	Sub Agent가 사용할 도구를 제한할 필요가 있는가
결과 형태	최종 요약, 근거, 다음 액션만 받으면 충분한가

동작 과정

Sub Agent 실행 흐름은 다음과 같다.

사용자 요청
    |
    v
Parent Agent
    |
    | 필요한 Context만 전달
    v
Sub Agent 시작
    |
    | 독립 Context에서 분석
    | 도구 사용
    | 중간 결과 정리
    v
Sub Agent 종료
    |
    | Summary 반환
    v
Parent Agent 결과 병합

Sub Agent는 Parent Agent의 전체 대화 기록을 복사해서 사용하는 방식이 아니다. 따라서 Sub Agent가 알아야 하는 제약, 파일 범위, 출력 형식은 명확하게 전달해야 한다.

Context 관계

Sub Agent를 이해할 때 가장 헷갈리는 지점은 Context 관계이다.

Context	의미	사용 시점
`inline`	Parent Context를 그대로 사용	짧은 작업, 현재 대화 흐름과 밀접한 작업
`fork`	별도 Sub Agent Context 생성	탐색량이 많거나 메인 컨텍스트를 오염시키고 싶지 않은 작업
`isolated`	파일 시스템 또는 실행 환경까지 분리하는 설계 개념	워크트리 격리, 샌드박스 실행 등 별도 구현이 있는 경우

Claude Code Skill의 context 값으로는 fork를 사용해 Sub Agent Context 실행을 표현할 수 있다. inline은 별도 fork를 만들지 않는 기본 실행에 해당한다. isolated는 이 글의 샘플에서 사용하는 공식 Skill frontmatter 값이 아니라, 더 강한 격리를 설명할 때 쓰는 설계 용어로 구분한다.

SKILL.md 메타데이터

Skill은 Agent에게 특정 작업 방식과 실행 지침을 제공하는 재사용 가능한 단위이다. 아래는 Sub Agent 실행을 의도한 Skill 예제이다.

---
name: claude-subagent
description: 대규모 코드베이스 분석, 로그 요약, 보안 점검처럼 메인 대화를 오염시킬 수 있는 작업을 fork 컨텍스트에서 수행하고 요약만 반환합니다.
user-invocable: true
disable-model-invocation: false
context: fork
agent: Explore
---

# Claude Sub Agent

## 목적

메인 대화 컨텍스트에 모든 탐색 결과를 남기지 않고, 독립적인 Sub Agent Context에서 분석한 뒤 요약 결과만 반환합니다.

주요 메타데이터 의미는 다음과 같다.

항목	설명
`name`	Skill 이름. 목록 표시와 식별에 사용
`description`	Skill 설명. Agent가 언제 이 Skill을 사용할지 판단하는 핵심 정보
`context`	`inline` 또는 `fork` 실행 방식
`agent`	`context: fork`일 때 사용할 Sub Agent 타입
`user-invocable`	사용자가 Slash Command 형태로 직접 호출할 수 있는지 여부
`disable-model-invocation`	모델이 상황에 맞춰 자동으로 Skill을 호출할 수 있는지 제어
`allowed-tools`	Skill 활성화 중 별도 승인 없이 허용할 도구
`disallowed-tools`	Skill 활성화 중 제거할 도구

실무에서는 description을 가장 신경 써야 한다. Agent는 설명을 보고 Skill 사용 여부를 판단하므로, 단순한 이름보다 “언제 써야 하는지”를 구체적으로 쓰는 편이 좋다.

Hook

Sub Agent의 라이프사이클은 Hook으로 추적할 수 있다. 특히 SubagentStart와 SubagentStop은 Sub Agent의 시작과 종료 시점에 실행된다.

사용자 요청
    |
    v
Parent Agent
    |
    v
SubagentStart Hook
    |
    v
Sub Agent 실행
    |
    v
SubagentStop Hook
    |
    v
Parent Agent 결과 병합

Claude Code의 .claude/settings.json에서는 matcher group과 hook handler를 구분해 작성한다.

{
  "hooks": {
    "SubagentStart": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "bash ./scripts/subagent-log.sh",
            "timeout": 10,
            "statusMessage": "Logging subagent start"
          }
        ]
      }
    ],
    "SubagentStop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "bash ./scripts/subagent-log.sh",
            "timeout": 10,
            "statusMessage": "Logging subagent stop"
          }
        ]
      }
    ]
  }
}

VS Code Agent Hooks와 Copilot 호환 예제에서는 .github/hooks/*.json에 더 단순한 command 배열 형태를 사용할 수 있다.

{
  "hooks": {
    "SubagentStart": [
      {
        "type": "command",
        "command": "bash ./scripts/subagent-log.sh",
        "timeout": 10
      }
    ],
    "SubagentStop": [
      {
        "type": "command",
        "command": "bash ./scripts/subagent-log.sh",
        "timeout": 10
      }
    ]
  }
}

두 형식 모두 핵심은 같다. Hook은 stdin으로 이벤트 JSON을 받고, stdout으로 JSON 응답을 반환한다.

Script

Sub Agent 로그 스크립트는 단순히 echo >> log로 작성할 수도 있지만, 운영 환경에서는 다음 요소를 고려하는 편이 좋다.

jq를 사용한 안전한 JSON 생성
stdout에는 Hook 응답 JSON만 출력
오류 메시지는 stderr로 분리
로그 파일 크기 제한 또는 rotation
logger를 통한 시스템 로그 연동
agent_id, agent_type, session_id 등 상관관계 식별자 기록

예제 스크립트는 다음과 같은 형태가 적절하다.

#!/usr/bin/env bash
set -u

INPUT="$(cat)"
LOG_DIR="${SUBAGENT_LOG_DIR:-.subagent-logs}"
TIMESTAMP="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
MAX_LOG_BYTES="${SUBAGENT_LOG_MAX_BYTES:-1048576}"

if ! mkdir -p "$LOG_DIR"; then
  echo '{"continue":true,"systemMessage":"subagent-log: log directory could not be created"}'
  exit 0
fi

rotate_if_needed() {
  file="$1"
  if [ -f "$file" ]; then
    size="$(wc -c < "$file" | tr -d ' ')"
    if [ "$size" -gt "$MAX_LOG_BYTES" ]; then
      mv "$file" "$file.$(date -u +%Y%m%dT%H%M%SZ)"
    fi
  fi
}

if command -v jq >/dev/null 2>&1; then
  EVENT="$(printf '%s' "$INPUT" | jq -r '.hook_event_name // "unknown"' 2>/dev/null || printf 'unknown')"
  SESSION_ID="$(printf '%s' "$INPUT" | jq -r '.session_id // "unknown"' 2>/dev/null || printf 'unknown')"
  AGENT_ID="$(printf '%s' "$INPUT" | jq -r '.agent_id // .hook_event_data.subagent_id // "unknown"' 2>/dev/null || printf 'unknown')"
  AGENT_TYPE="$(printf '%s' "$INPUT" | jq -r '.agent_type // .hook_event_data.agent_type // "unknown"' 2>/dev/null || printf 'unknown')"

  LOG_FILE="$LOG_DIR/${SESSION_ID}-${AGENT_ID}.jsonl"
  rotate_if_needed "$LOG_FILE"

  printf '%s' "$INPUT" | jq -c \
    --arg event "$EVENT" \
    --arg timestamp "$TIMESTAMP" \
    --arg sessionId "$SESSION_ID" \
    --arg agentId "$AGENT_ID" \
    --arg agentType "$AGENT_TYPE" \
    '{
      event: $event,
      timestamp: $timestamp,
      session_id: $sessionId,
      agent_id: $agentId,
      agent_type: $agentType,
      payload: .
    }' >> "$LOG_FILE"
else
  LOG_FILE="$LOG_DIR/subagent-raw.log"
  rotate_if_needed "$LOG_FILE"
  {
    printf '{"timestamp":"%s","payload":' "$TIMESTAMP"
    printf '%s' "$INPUT"
    printf '}\n'
  } >> "$LOG_FILE"
fi

if command -v logger >/dev/null 2>&1; then
  logger -t claude-subagent "event=${EVENT:-unknown} session=${SESSION_ID:-unknown} agent=${AGENT_ID:-unknown}"
fi

echo '{"continue":true}'

이 스크립트는 Hook을 차단 정책으로 사용하지 않는다. 로그 기록에 실패해도 Agent 실행 자체를 막지 않도록 continue: true를 반환한다.

실행 흐름

Sub Agent 분석 흐름은 다음처럼 정리할 수 있다.

Parent Agent가 작업 위임 여부 판단
SubagentStart Hook 실행
Sub Agent가 별도 Context에서 코드, 로그, 문서 분석
Sub Agent가 근거와 요약을 Parent Agent에 반환
SubagentStop Hook 실행
Parent Agent가 최종 답변 또는 후속 작업 수행

실무에서는 Sub Agent에게 다음 출력 형식을 요구하면 결과 병합이 쉬워진다.

## Summary
- 핵심 결론

## Evidence
- 확인한 파일, 로그, 테스트 결과

## Risks
- 불확실한 점과 추가 확인 필요 사항

## Next Actions
- Parent Agent가 이어서 수행할 작업

Loop Agent Pattern

개념

Loop Agent Pattern은 목표가 만족될 때까지 동일한 작업을 반복하는 Agent 설계 패턴이다.

반복의 목적은 단순 재시도가 아니다. 각 반복에서 관찰한 결과를 기준으로 다음 계획을 수정한다.

Plan
  |
  v
Tool Execute
  |
  v
Observe
  |
  v
Evaluate
  |
  v
Replan
  |
  v
Repeat or Done

예를 들어 테스트 실패를 고치는 상황에서는 다음과 같이 동작한다.

실패 테스트 확인
원인 가설 수립
최소 수정
테스트 재실행
결과 관찰
실패하면 가설 수정 후 반복
종료 조건 만족 시 요약

반복 구조

Loop Agent Pattern에는 반드시 종료 조건이 있어야 한다.

항목	설명
최대 반복 횟수	무한 루프 방지
성공 조건	테스트 통과, 린트 통과, 리뷰 이슈 0개 등
실패 조건	같은 오류 반복, 권한 부족, 의존성 누락 등
관찰 기록	각 반복의 입력, 명령, 출력, 판단 근거
재계획 기준	이전 관찰 결과를 다음 계획에 반영

종료 조건이 없는 Loop Agent는 자동화가 아니라 위험한 무한 반복이다. 운영 환경에서는 max_iterations, timeout, same_error_limit 같은 안전장치를 둔다.

Skill

Loop Agent Pattern은 Parent Context와 강하게 연결되는 경우가 많다. 따라서 예제 Skill은 context: inline을 사용한다.

---
name: loop-agent
description: 테스트, 린트, 문서 검토처럼 반복적인 계획, 실행, 관찰, 평가, 재계획이 필요한 작업을 제한된 루프로 개선합니다.
user-invocable: true
disable-model-invocation: false
context: inline
---

# Loop Agent Pattern

## 목적

작업을 한 번에 끝내려고 하지 않고, 관찰 가능한 결과를 기준으로 반복 개선합니다.

Loop Agent Skill에는 다음 제한 사항을 명시해야 한다.

무한 루프를 만들지 않는다.
기본 최대 반복 횟수를 둔다.
종료 조건을 먼저 정의한다.
같은 실패가 반복되면 중단하고 원인을 보고한다.
도구 실행 결과를 관찰한 뒤 다음 계획을 수정한다.
사용자의 승인 없이는 위험한 변경이나 광범위한 삭제를 수행하지 않는다.

Script

Loop Script는 Iteration -> Done만 기록하면 실무에서 부족하다. 반복마다 Plan, Tool Execute, Observe, Evaluate, Replan 단계를 남기는 편이 좋다.

#!/usr/bin/env bash
set -u

INPUT="$(cat)"
MAX_ITERATIONS="${LOOP_AGENT_MAX_ITERATIONS:-${1:-5}}"
TARGET_COMMAND="${LOOP_AGENT_COMMAND:-}"
DONE_PATTERN="${LOOP_AGENT_DONE_PATTERN:-}"
LOG_DIR="${LOOP_AGENT_LOG_DIR:-.loop-agent-logs}"
LOG_FILE="$LOG_DIR/loop-agent.jsonl"

mkdir -p "$LOG_DIR"

ITERATION=0
STATUS="continue"
LAST_EXIT_CODE=0
OBSERVATION="no command configured"

while [ "$ITERATION" -lt "$MAX_ITERATIONS" ] && [ "$STATUS" = "continue" ]; do
  PLAN="plan iteration $ITERATION based on previous observation"

  if [ -n "$TARGET_COMMAND" ]; then
    OUTPUT_FILE="$LOG_DIR/iteration-$ITERATION.out"
    sh -c "$TARGET_COMMAND" > "$OUTPUT_FILE" 2>&1
    LAST_EXIT_CODE=$?
    OBSERVATION="$(tail -n 20 "$OUTPUT_FILE" | tr '\n' ' ')"
  else
    LAST_EXIT_CODE=0
    OBSERVATION="dry run iteration $ITERATION"
  fi

  if [ "$LAST_EXIT_CODE" -eq 0 ]; then
    if [ -z "$DONE_PATTERN" ] || printf '%s' "$OBSERVATION" | grep -Eq "$DONE_PATTERN"; then
      STATUS="done"
    fi
  fi

  if command -v jq >/dev/null 2>&1; then
    jq -n -c \
      --arg phase "loop" \
      --arg plan "$PLAN" \
      --arg observation "$OBSERVATION" \
      --arg status "$STATUS" \
      --argjson iteration "$ITERATION" \
      --argjson exitCode "$LAST_EXIT_CODE" \
      '{
        phase: $phase,
        iteration: $iteration,
        plan: $plan,
        tool_execute: { exit_code: $exitCode },
        observe: $observation,
        evaluate: $status
      }' >> "$LOG_FILE"
  else
    printf 'iteration=%s exit_code=%s status=%s observation=%s\n' \
      "$ITERATION" "$LAST_EXIT_CODE" "$STATUS" "$OBSERVATION" >> "$LOG_FILE"
  fi

  if [ "$STATUS" != "done" ]; then
    STATUS="continue"
  fi

  ITERATION=$((ITERATION + 1))
done

if [ "$STATUS" != "done" ]; then
  STATUS="max_iterations"
fi

if command -v jq >/dev/null 2>&1; then
  jq -n \
    --arg status "$STATUS" \
    --argjson iterations "$ITERATION" \
    --argjson lastExitCode "$LAST_EXIT_CODE" \
    '{
      continue: true,
      systemMessage: ("Loop Agent completed " + ($iterations | tostring) + " iterations with status " + $status),
      hookSpecificOutput: {
        iterations: $iterations,
        status: $status,
        last_exit_code: $lastExitCode
      }
    }'
else
  printf '{"continue":true,"systemMessage":"Loop Agent completed %s iterations with status %s","hookSpecificOutput":{"iterations":%s,"status":"%s","last_exit_code":%s}}\n' \
    "$ITERATION" "$STATUS" "$ITERATION" "$STATUS" "$LAST_EXIT_CODE"
fi

이 스크립트는 샘플이므로 운영에서는 실행할 명령을 고정하거나 allowlist로 제한해야 한다. LOOP_AGENT_COMMAND처럼 문자열 명령을 실행하는 방식은 편리하지만, 신뢰할 수 없는 입력을 그대로 넣으면 안 된다.

활용 사례

Loop Agent Pattern은 다음 작업에 잘 맞는다.

테스트 실패 → 수정 → 재실행
코드 리뷰 → 리팩토링 → 재검토
문서 초안 → 검토 → 개선
린트 → 수정 → 재검사
마이그레이션 스크립트 → dry run → 보정 → 재실행

반대로 다음 작업에는 적합하지 않다.

한 번의 조회로 끝나는 정보 검색
사용자의 판단이 매 단계 필요한 작업
비용이 큰 외부 API 호출을 반복해야 하는 작업
실패 시 부작용이 큰 배포, 삭제, 권한 변경 작업

Sub Agent vs Loop Agent

두 방식을 비교하면 다음과 같다.

항목	Sub Agent	Loop Agent Pattern
목적	작업 분리	반복 개선
Context	Fork	Inline 중심
실행	병렬 또는 독립 실행 가능	순차 반복
종료	위임 작업 완료	종료 조건 만족
대표 용도	코드 분석, 문서 요약, 로그 분석	테스트 개선, 리팩토링, 문서 개선
공식 지원	Claude Code 기능	Agent 설계 패턴
주요 리스크	필요한 Context 전달 누락	무한 반복, 과도한 변경
관찰 포인트	`SubagentStart`, `SubagentStop`	iteration log, exit code, done condition

선택 기준은 단순하다.

탐색량이 많고 메인 대화에 남길 필요가 없는 작업이면 Sub Agent가 적합하다. 실행 결과를 보고 다시 계획을 수정해야 하는 작업이면 Loop Agent Pattern이 적합하다.

실무 적용 시 고려사항

1. Context 전달은 명시적으로 한다

Sub Agent는 Parent Agent의 전체 Context를 공유하지 않는다. 따라서 다음 정보를 명확히 전달해야 한다.

분석 대상 파일 또는 디렉터리
변경 가능 여부
사용할 도구 범위
출력 형식
제외할 경로
보안 또는 운영상 제약

2. Hook은 감사와 제어를 분리한다

모든 Hook을 차단 정책으로 만들 필요는 없다.

SubagentStart, SubagentStop은 감사 로그와 추적에 적합하다. 반면 위험한 명령 차단은 PreToolUse에 두는 편이 자연스럽다.

3. stdout과 stderr를 구분한다

Hook 스크립트의 stdout은 Agent가 파싱할 JSON 응답으로 사용된다. 디버그 로그를 stdout에 섞으면 Hook 결과 파싱이 깨질 수 있다.

운영 스크립트에서는 다음 원칙을 지킨다.

stdout: Hook 응답 JSON
stderr: 사람이 볼 오류 메시지
파일 로그: 상세 이벤트 기록
시스템 로그: 운영 모니터링용 요약

4. Loop는 반드시 종료 조건을 둔다

Loop Agent Pattern에서 가장 중요한 것은 종료 조건이다.

권장 기본값은 다음과 같다.

설정	권장값
`max_iterations`	3~5
`timeout`	반복당 30~120초
`same_error_limit`	2
성공 조건	테스트 또는 린트 통과처럼 관찰 가능한 조건
실패 조건	같은 오류 반복, 의존성 누락, 권한 부족

5. 샘플과 운영 코드를 구분한다

이 글의 스크립트는 구조를 보여주는 샘플이다. 운영에서는 다음 보강이 필요하다.

실행 명령 allowlist
로그 rotation 정책
민감 정보 마스킹
실패 알림
CI 연동
OS별 shell 차이 처리
Hook 버전 관리

파일	역할
`.claude/settings.json`	Claude Code용 Sub Agent Hook 설정
`.github/hooks/development.json`	VS Code/Copilot 호환 개발용 Hook 설정
`.github/skills/claude-subagent/SKILL.md`	`context: fork` 기반 Sub Agent Skill
`.github/skills/loop-agent/SKILL.md`	`context: inline` 기반 Loop Agent Pattern Skill
`scripts/subagent-log.sh`	Sub Agent 시작/종료 이벤트 로그
`scripts/loop-agent.sh`	반복 개선 루프 샘플
`scripts/hook-pass.sh`	일반 Hook 이벤트를 통과시키며 감사 로그만 남기는 샘플

정리

Sub Agent와 Loop Agent Pattern은 비슷해 보이지만 목적이 다르다.

Sub Agent는 Claude Code의 공식 기능으로, 탐색량이 큰 작업을 별도 Context에 분리해 Parent Agent의 대화 품질을 보호한다. Loop Agent Pattern은 공식 기능명이 아니라, 관찰 가능한 결과를 기준으로 계획과 실행을 반복하는 설계 패턴이다.

실무에서는 두 방식을 함께 사용할 수 있다.

예를 들어 Sub Agent가 대규모 코드베이스를 분석해 원인을 요약하고, Parent Agent가 그 결과를 바탕으로 Loop Agent Pattern을 사용해 테스트 실패를 고칠 수 있다.

핵심은 다음 세 가지이다.

Sub Agent는 Context 분리를 위해 사용한다.
Loop Agent Pattern은 반복 개선을 위해 사용한다.
Hook과 Script는 실행 흐름을 관찰하고 안전장치를 두기 위해 사용한다.

참고 자료

본 글의 샘플 코드와 완전한 프로젝트는 GracefulSoul/copilot-project에서 확인할 수 있습니다.

Kim

Claude Code Sub Agent와 Loop Agent Pattern: 분리 실행과 반복 개선

개요

환경

Claude Code Agent 구조

Sub Agent

개념

동작 과정

Context 관계

SKILL.md 메타데이터

Hook

Script

실행 흐름

Loop Agent Pattern

개념

반복 구조

Skill

Script

활용 사례

Sub Agent vs Loop Agent

실무 적용 시 고려사항

1. Context 전달은 명시적으로 한다

2. Hook은 감사와 제어를 분리한다

3. stdout과 stderr를 구분한다

4. Loop는 반드시 종료 조건을 둔다

5. 샘플과 운영 코드를 구분한다

관련 샘플 파일

정리

참고 자료

댓글남기기

참고

Claude Code Skills와 Hooks : Agent 커스터마이제이션과 자동화

Anthropic Claude API를 Spring Boot 4.0에서 사용하기 - 완벽 가이드

메타지침 바인딩 기술 (Semantic Directive Binding) - Java 25 + Spring Boot 4.0 가이드

AI Ops와 AI DLC (AI Data Labeling Cloud) 완벽 가이드