8-1에서 본 다섯 부품은 개념입니다. 여기서는 그 개념이 Claude Code에서 어떤 기능으로 제공되는지 짚어봅니다. 부품 이름을 알아두면 이어지는 실습이 "이건 어떤 부품이구나"로 읽힙니다.

1. 무엇이 다음 바퀴를 시작하는가

루프 도구를 고를 때 던져야 하는 질문은 하나입니다. 다음 바퀴는 무엇이 시작시키는가. 답이 셋뿐이고, Claude Code의 기능도 그 셋으로 나뉩니다.

셋은 배타적이지 않습니다. 실제로는 hooks로 매 턴 검사를 걸어두고, 그 위에서 /goal로 조건까지 밀고, 바깥에서는 루틴이 매일 밤 청소를 도는 식으로 겹쳐 씁니다.

2. 조건으로 도는 루프, /goal

가장 루프 엔지니어링다운 기능입니다. 완료 조건을 하나 정해두면, 그 조건이 충족될 때까지 Claude가 스스로 다음 턴을 시작합니다.

/goal test/auth 아래 테스트가 모두 통과하고 lint가 깨끗하다

이 한 줄을 입력하면 곧바로 첫 턴이 시작됩니다. 별도로 "해줘"라고 부탁할 필요가 없습니다. 조건 자체가 지시문이 됩니다.

2.1 어떻게 판정하는가

턴이 끝날 때마다 작은 빠른 모델이 별도로 붙어서 조건이 충족됐는지 판정합니다. 8-1의 네 번째 부품, 만드는 쪽과 검사하는 쪽의 분리가 기능으로 들어와 있습니다. 판정 결과는 셋 중 하나입니다.

"아직 아님" 판정에는 짧은 이유가 따라붙고, 그 이유가 다음 턴의 힌트로 들어갑니다. 그래서 조건을 잘 쓰면 루프가 스스로 방향을 잡습니다.

2.2 조건을 쓰는 요령

평가 모델은 도구를 쓰지 않습니다. 파일을 직접 읽거나 명령을 직접 돌리지 않고, 대화에 이미 드러난 내용만 보고 판정합니다. 그래서 조건은 "Claude가 스스로 증명해 보일 수 있는 것"으로 써야 합니다.

안 되는 조건: "코드가 깔끔해질 때까지"
             → 평가 모델이 판정할 근거가 대화에 안 남음

되는 조건:   "npm test가 0으로 끝나고, 그 출력이 대화에 남아 있다"
             → Claude가 테스트를 돌리면 결과가 대화에 남고, 평가 모델이 그걸 읽음

잘 버티는 조건에는 보통 세 가지가 들어 있습니다.

1. 측정 가능한 종료 상태 하나. 테스트 결과, 빌드 종료 코드, 파일 개수, 빈 대기열.
2. 어떻게 증명할지. "npm test가 0으로 끝난다", "git status가 깨끗하다".
3. 지켜야 할 제약. "다른 테스트 파일은 건드리지 않는다".

여기에 8-1의 두 번째 부품인 상한을 조건문 안에 한 절로 넣어둘 수 있습니다.

/goal output/*.html이 모두 검사 스크립트를 통과한다.
검사는 `bash check.sh`로 하고 출력을 대화에 남긴다.
style/ 폴더는 수정하지 않는다. 20턴 안에 못 끝내면 중단하고 이유를 보고한다.

2.3 상태 확인, 해제, 그리고 갇히지 않게 하는 장치

8-1의 세 번째 부품인 진전 없음 감지도 들어 있습니다. Claude가 도구를 전혀 쓰지 않으면서 평가 모델에게 대답만 몇 턴 계속하면, 루프를 멈추고 경고를 띄운 뒤 사람에게 제어를 돌려줍니다. 인증 실패, 크레딧 소진, 컨텍스트 초과, 모델 사용 불가처럼 사람이 고쳐야만 풀리는 오류가 나면 목표 자체가 해제되고 원인이 표시됩니다.

2.4 터미널을 붙잡고 있지 않아도 될 때

-p(비대화 모드)에서도 그대로 씁니다. 이 경우 한 번의 명령으로 루프가 끝까지 돕니다.

claude -p "/goal CHANGELOG.md에 이번 주 머지된 모든 PR의 항목이 있다"

기본 출력은 다 끝나야 한 번에 나오기 때문에, 여러 턴이 도는 동안 멈춘 것처럼 보입니다. 진행 상황을 보고 싶으면 스트리밍 출력을 붙입니다.

claude -p "/goal ..." --output-format stream-json --verbose

3. 시간으로 도는 루프, /loop

/goal이 "될 때까지"라면 /loop는 "몇 분마다"입니다. 바깥 세계의 상태를 주기적으로 확인해야 할 때 씁니다.

간격 단위는 s(초), m(분), h(시간), d(일)입니다. cron이 1분 단위라 초는 분으로 올림되고, 7m처럼 딱 떨어지지 않는 간격은 가까운 값으로 맞춰지며 그때 어떤 값으로 잡았는지 알려줍니다.

간격을 생략하면 Claude가 매 바퀴 끝에 1분에서 1시간 사이로 다음 간격을 직접 고릅니다. 빌드가 곧 끝날 것 같으면 짧게, 아무 일도 없으면 길게 잡습니다. 고른 간격과 그 이유가 매 바퀴 끝에 표시됩니다.

/loop CI가 통과했는지 확인하고 리뷰 코멘트가 있으면 반영해줘

3.1 기본 루프를 내 것으로 바꾸기

프롬프트 없이 /loop만 입력하면 내장된 정비 프롬프트가 돕니다. 이걸 우리 프로젝트의 기본 루프로 바꾸려면 loop.md 파일을 둡니다.

내용은 그냥 마크다운입니다. /loop 뒤에 타이핑하듯 쓰면 됩니다. 7장에서 만든 랜딩 하네스라면 이런 식이 됩니다.

`output/` 폴더의 HTML을 `bash check.sh`로 검사한다.
실패한 파일이 있으면 어느 규칙을 어겼는지 확인하고 최소한으로 고친다.
전부 통과하고 새로 들어온 브리프가 없으면 "이상 없음" 한 줄로 답한다.

파일을 고치면 다음 바퀴부터 반영됩니다. 루프를 돌리면서 지시문을 다듬을 수 있다는 뜻입니다.

3.2 멈추는 방법과 자동으로 멈추는 자리

다음 바퀴를 기다리는 동안 Esc를 누르면 예약된 실행이 취소되면서 루프가 멈춥니다. 간격을 Claude가 정하는 방식에서는 작업이 끝났다고 판단하면 스스로 루프를 끝내기도 합니다.

그리고 안전장치가 하나 더 있습니다. 반복 작업은 만들어진 지 7일이 지나면 마지막으로 한 번 실행되고 스스로 사라집니다. 잊어버린 루프가 영원히 도는 일을 막는 장치입니다. 그보다 오래 살아야 하는 루프는 뒤에서 볼 세션 밖 스케줄을 씁니다.

3.3 세션 안 스케줄의 성격

/loop로 만든 작업은 세션에 묶여 있습니다. 창을 닫으면 안 돌고, 새 대화를 시작하면 사라집니다. --resume이나 --continue로 이어 붙이면 아직 만료되지 않은 작업은 돌아옵니다.

자연어로 관리할 수 있습니다.

지금 예약된 작업이 뭐가 있어?
배포 확인 작업 취소해줘
오후 3시에 릴리스 브랜치 푸시하라고 알려줘

마지막 줄처럼 한 번만 실행되는 예약도 됩니다. 실행 후 스스로 삭제됩니다. 한 세션에 최대 50개까지 예약할 수 있고, 표준 5필드 cron 표현식(분 시 일 월 요일)을 직접 지정할 수도 있습니다.

4. 사건으로 도는 루프, hooks

/goal과 /loop가 "다음 턴을 시작하는" 장치라면, hooks는 정해진 사건이 일어난 직후에 반드시 무언가를 실행하는 장치입니다. 5장에서 본 가드레일이 루프에서 자동 검증 장치로 승격되는 자리입니다.

설정은 .claude/settings.json에 적습니다.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/check.sh",
            "statusMessage": "디자인 시스템 검사 중..."
          }
        ]
      }
    ]
  }
}

matcher는 어떤 도구에 반응할지를 정합니다. 위 설정은 파일을 수정하거나 새로 만들 때마다 우리 검사 스크립트를 돌립니다. 자주 쓰는 사건 몇 가지만 추리면 이렇습니다.

4.1 명령이 아니라 판단이 필요할 때

hooks가 실행할 수 있는 것은 셸 명령만이 아닙니다. 프롬프트를 실행하는 hook과 에이전트를 부르는 hook도 있습니다. 기계 검사로는 못 잡는 자리를 여기서 잡습니다.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "방금 만든 초안이 brand.md의 금지 표현을 하나라도 썼는지 확인하고, 썼다면 어느 줄인지 지적해줘."
          }
        ]
      }
    ]
  }
}

/goal도 이 구조 위에 올라가 있습니다. /goal은 세션 범위의 프롬프트 기반 Stop hook을 한 줄 명령으로 감싼 것입니다. 그래서 판정 로직을 직접 짜고 싶거나, 모든 세션에 항상 걸어두고 싶으면 Stop hook을 직접 쓰면 됩니다. 둘의 차이는 이렇습니다.

5. 세션 밖에서 도는 루프

지금까지 본 것들은 모두 세션이 열려 있어야 돕니다. 노트북을 닫으면 멈춥니다. 밤새 도는 루프, 매일 아침 도는 루프가 필요하면 세션 밖 스케줄로 넘어갑니다.

고르는 기준은 단순합니다. 내 컴퓨터가 꺼져 있어도 돌아야 하면 클라우드 루틴, 로컬 파일과 도구가 필요하면 데스크톱 예약 작업, 지금 이 작업을 지켜보는 중이면 /loop. 저장소 이벤트에 맞춰 돌아야 한다면 GitHub Actions도 같은 자리의 선택지입니다.

1장에서 본 "가비지 컬렉션" 아이디어, 즉 에이전트가 주기적으로 코드베이스를 훑으며 일관성이 깨진 자리를 치우는 일이 세션 밖 루프의 대표적인 용도입니다.

6. 병렬로 도는 루프

루프가 하나만 있어야 할 이유는 없습니다. 서로 건드리는 파일이 겹치지 않는 작업이라면 여러 개를 동시에 돌릴 수 있습니다. 이때 필요한 게 격리된 작업 공간입니다. Git worktree를 쓰면 같은 저장소를 여러 폴더로 펼쳐두고 각 폴더에서 다른 루프를 돌릴 수 있습니다.

다만 5장의 권고를 여기서도 기억하는 게 좋습니다. 단일로 안 될 때까지는 단일로 갑니다. 병렬 루프는 비용이 곱으로 늘고, 어느 루프가 무엇을 왜 했는지 추적하기가 급격히 어려워집니다.

7. 부품 정리

여기까지 나온 기능을 8-1의 다섯 부품에 맞춰 놓으면 이렇게 됩니다. 이어지는 실습에서 이 표의 자리들을 하나씩 채워봅니다.