Claude Code로 루프를 생성하는 방법

대부분의 Claude 워크플로우는 여전히 일회성입니다.

프롬프트를 작성합니다. Claude가 응답합니다. 세션이 종료됩니다. 다음 날 다시 처음부터 시작합니다.

일회성 작업에는 괜찮습니다.

하지만 반복적인 작업(일일 리뷰, CI 분류, 프로젝트 모니터링, 회의 후속 조치)의 경우 매일 동일한 컨텍스트를 다시 구축하고 있습니다.

그건 워크플로우가 아닙니다. AI를 약간 뿌린 수작업입니다.

더 나은 추상화는 루프입니다.

이 내용을 저장해 두세요. 유용하게 사용할 것입니다.

Claude 루프가 실제로 무엇인가

루프는 "그냥 Claude에게 다시 물어보는 것"이 아닙니다.

루프는 모델 주변의 반복 가능한 워크플로우 구조입니다.

다음을 정의합니다:

→ 실행을 트리거하는 것

→ Claude가 실행 전에 읽는 컨텍스트

→ Claude가 수행할 수 있는 작업 → 출력이 검증되는 방식

→ 상태가 저장되는 위치

→ 중지, 반복 또는 사람의 검토를 요청해야 하는 시점

모델은 여전히 추론을 수행합니다.

루프는 운영 구조를 제공합니다.

이러한 전환이 중요한 이유는 Claude 세션이 일시적이기 때문입니다.

루프가 없으면 모든 실행이 처음부터 시작됩니다. 루프가 있으면 Claude는 이전에 발생한 상황을 읽고 그 지점에서 계속 진행합니다.

모든 Claude 루프에 필요한 6가지 요소

구조가 없는 루프는 두 번 실행되는 프롬프트에 불과합니다.

루프가 실제로 작동하게 만드는 6가지 요소는 다음과 같습니다:

→ 1. 트리거

실행을 시작하는 것.

수동 명령. 예약된 타이머. 파일 변경. CI 실패. Git 이벤트.

→ 2. 컨텍스트

Claude가 실행 전에 읽는 것.

작업 정의. 이전 진행 상황. 프로젝트 파일. 지침.

→ 3. 액션

Claude가 수행하는 작업.

보고서 작성. 수정 초안 작성. 실패 분류. 문서 업데이트.

→ 4. 검증

결과를 확인하는 방법.

체크리스트. 테스트 스위트. 필수 섹션. 안전 경계 확인.

→ 5. 상태 업데이트

다음 번을 위해 기억되는 것.

PROGRESS.md 업데이트. 차단 항목 기록. 다음 실행 안내.

→ 6. 결정

중지. 반복. 또는 사람에게 에스컬레이션.

이것이 전체 루프입니다.

그리고 모든 단계가 중요합니다.

검증을 건너뛰면 → 루프가 맹목적으로 자신을 신뢰합니다.

상태를 건너뛰면 → 모든 실행이 처음부터 시작됩니다.

결정을 건너뛰면 → 루프는 언제 중지해야 할지 결코 알지 못합니다.

루프가 작동하게 만드는 4가지 파일 시스템

인프라가 필요하지 않습니다.

4개의 파일과 1개의 폴더가 필요합니다.

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — 목표. 이 루프가 달성하려는 것.

LOOP_INSTRUCTIONS.md — 운영 절차. Claude가 실행해야 하는 방식, 허용되는 작업, 검증 방법.

PROGRESS.md — 메모리. 지난번에 발생한 상황, 차단된 항목, 다음 실행이 집중해야 할 사항.

outputs/ — Claude가 결과를 작성하는 곳. 예측 가능. 검사 가능. 안전.

이것이 전부입니다.

Claude는 각 실행 시작 시 이러한 파일을 읽습니다. 실행 종료 시 업데이트합니다. 다음 실행은 마지막 실행이 중단된 지점에서 계속됩니다.

이것이 루프를 반복되는 프롬프트와 다르게 만드는 것입니다.

상태는 채팅 외부에 존재합니다.

TASK.md — 목표를 명확하게 정의

이 파일은 Claude에게 루프의 목적을 알려줍니다.

높은 수준으로 유지하세요. 운영 세부 사항은 여기에 넣지 마세요. 해당 내용은 LOOP_INSTRUCTIONS.md에 넣습니다.

이 템플릿을 복사하세요:

1# 일일 프로젝트 리뷰 루프
2
3## 목표
4이 프로젝트 폴더를 검토하고, 변경된 사항을 요약하며,
5차단 항목을 식별하고, 짧은 일일 리뷰 보고서를 생성합니다.
6
7## 예상 출력
8각 실행은 다음을 생성하거나 업데이트해야 합니다:
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## 범위
13Claude는 이 워크스페이스의 파일을 검사하고
14`outputs/` 폴더에 보고서를 작성할 수 있습니다.
15
16Claude는 다음을 수행해서는 안 됩니다:
17- 소스 파일 수정
18- 파일 삭제 또는 이름 변경
19- 메시지 전송 또는 티켓 열기

마지막 섹션을 주목하세요.

모든 루프의 첫 번째 버전에는 명시적인 "금지" 규칙이 있어야 합니다.

이것은 Claude를 신뢰할 수 없기 때문이 아닙니다.

이것은 여러분이 좋은 엔지니어이기 때문입니다.

PROGRESS.md — 루프의 메모리

이것은 시스템에서 가장 중요한 파일입니다.

이것이 없으면 모든 실행이 처음부터 시작됩니다. 이것이 있으면 Claude는 무슨 일이 일어났는지 알고 그 지점에서 계속 진행합니다.

실제로 작동하는 구조:

1# 루프 진행 상황
2
3## 현재 상태
4- 상태: 활성
5- 주요 목표: 일일 프로젝트 리뷰
6- 현재 초점: [현재 중요한 사항]
7- 마지막 업데이트: [날짜]
8
9## 마지막 실행
10- 날짜:
11- 요약:
12- 검토된 파일:
13- 생성된 출력:
14
15## 미해결 항목
16-
17
18## 차단 항목
19-
20
21## 사람 검토 필요
22-
23
24## 다음 실행은 다음을 수행해야 함
25-
26
27## 결정 사항
28-
29
30## 반복 금지
31-

"반복 금지" 섹션은 매우 중요합니다.

이미 실패한 작업을 Claude가 다시 시도하는 것을 방지합니다.

"사람 검토 필요" 섹션은 매우 중요합니다.

루프가 그래서는 안 될 때 조용히 계속되는 것을 막습니다.

PROGRESS.md를 유용하게 유지하기 위한 두 가지 규칙:

→ Claude가 다음 작업을 결정하는 데 필요 → PROGRESS.md에 유지 → 단순히 기록을 원함 → outputs/history/로 이동

계속 커지는 상태 파일은 쓸모없게 됩니다.

PROGRESS.md를 아카이브가 아닌 제어판으로 유지하세요.

LOOP_INSTRUCTIONS.md — 운영 절차

이 파일은 Claude 주변의 제어 계층입니다.

Claude에게 무엇을 읽고, 무엇을 쓰고, 무엇을 건드리지 말아야 하며, 중지하기 전에 결과를 검증하는 방법을 정확히 알려줍니다.

작동하는 템플릿:

1# 루프 지침
2
3당신은 일일 프로젝트 리뷰 루프를 실행하고 있습니다.
4
5## 시작하기 전에
61. `TASK.md`를 읽으세요
72. `PROGRESS.md`를 읽으세요
83. 프로젝트 폴더를 검사하세요
94. 변경된 사항, 완료되지 않은 사항, 사람의 검토가 필요한 사항을 식별하세요
10
11## 수행해야 할 작업
12`outputs/daily-review.md`에 짧은 일일 리뷰를 작성하세요. 여기에는 다음이 포함됩니다:
13- 현재 상태 요약
14- 검토된 파일
15- 중요한 변경 사항
16- 차단 항목 또는 해결되지 않은 질문
17- 권장되는 다음 조치
18
19작성 후 `PROGRESS.md`를 다음으로 업데이트하세요:
20- 이 실행 날짜
21- 발생한 상황 요약
22- 확인된 파일
23- 다음 실행이 수행해야 할 작업
24- 사람의 검토가 필요한지 여부
25
26## 안전 규칙
27- 파일을 삭제하지 마세요
28- 파일 이름을 바꾸거나 이동하지 마세요
29- 소스 파일을 수정하지 마세요
30- `outputs/daily-review.md` 및 `PROGRESS.md`에만 작성하세요
31- 작업이 허용되는지 확실하지 않은 경우 → 중지하고 물어보세요
32
33## 검증 체크리스트
34실행을 종료하기 전에 다음을 확인하세요:
35- `outputs/daily-review.md`가 모든 필수 섹션과 함께 존재하는지
36- `PROGRESS.md`가 업데이트되었는지
37- 허용된 경로 외부의 파일이 수정되지 않았는지
38
39## 실패 정책
40검증에 실패한 경우:
411. 보고서에 누락된 섹션 → 한 번 수정
422. PROGRESS.md가 업데이트되지 않음 → 한 번 업데이트
433. 금지된 파일이 수정됨 → 즉시 중지
444. 동일한 검사가 두 번 실패 → 사람 검토 필요로 표시

하단의 실패 정책을 주목하세요.

대부분의 루프에는 실패 정책이 없습니다.

따라서 문제가 발생하면 Claude가 즉흥적으로 대처합니다.

바로 그 지점에서 루프가 문제를 만듭니다.

실패 경로를 명시적으로 정의하세요. 항상 그렇게 하세요.

첫 번째 루프를 수동으로 실행하기

아직 예약하지 마세요.

먼저 수동으로 실행하세요.

Claude Code 또는 Claude Desktop/Cowork에서 폴더를 엽니다. 다음 프롬프트를 사용하세요:

1이 워크스페이스에 대한 일일 프로젝트 리뷰 루프를 실행하세요.
2
3`LOOP_INSTRUCTIONS.md`를 정확히 따르세요.
4
5실행 전에 다음을 읽으세요:
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10그런 다음 워크스페이스를 검사하고, 일일 리뷰를
11`outputs/daily-review.md`에 작성하고, `PROGRESS.md`를 업데이트하고,
12검증 체크리스트를 실행하고, 변경된 사항을 보고하세요.
13
14`outputs/daily-review.md` 및 `PROGRESS.md` 이외의
15파일은 수정하지 마세요.

실행 후 두 가지를 확인하세요:

→ outputs/daily-review.md — 모든 섹션이 포함된 구조화된 보고서

→ PROGRESS.md — 업데이트된 상태, 다음 실행 안내, 사람 검토 플래그

둘 다 올바르게 보이면 → 루프가 작동하는 것입니다.

이제 작은 변경 사항을 적용하여 3-5회 더 실행하세요.

메모 파일을 추가하세요. PROGRESS.md에 차단 항목을 추가하세요. 워크스페이스에서 무언가를 변경하세요.

각 실행은 처음부터 시작하지 않고 변경 사항을 반영해야 합니다.

이러한 연속성이 핵심입니다.

검증: 대부분의 사람들이 건너뛰는 부분

아무도 이야기하지 않는 실패 모드가 있습니다.

Claude가 루프를 실행합니다. 완료되었다고 말합니다. 상태를 업데이트합니다. 중지합니다.

모든 것이 괜찮아 보입니다.

하지만 보고서에 필수 섹션이 누락되었습니다. 또는 PROGRESS.md가 실제로 업데이트되지 않았습니다. 또는 Claude가 수정해서는 안 될 파일을 조용히 편집했습니다.

무언가가 깨졌을 때만 알게 됩니다.

그렇기 때문에 검증이 존재합니다.

루프는 Claude가 완료되었다고 말했기 때문에 중지되어서는 안 됩니다.

구체적인 조건이 확인되었기 때문에 중지됩니다.

좋은 검증은 다음과 같습니다:

최신 루프 실행에 대한 검증 패스를 실행하세요.

LOOP_INSTRUCTIONS.md의 검증 체크리스트에 대해

출력을 확인하세요.

보고:

1. 통과한 검사
2. 실패한 검사
3. 수정된 파일
4. 실행을 수락해도 안전한지 여부
5. 사람의 검토가 필요한지 여부

이 검증 패스 중에는 파일을 수정하지 마세요.

작업자를 실행하세요. 그런 다음 검증기를 실행하세요. 별도로 실행하세요.

시간이 지나면 병합할 수 있습니다. 하지만 초기 테스트 중에는 분리하여 유지하세요.

검증기에는 통과/실패 기준이 필요합니다.

"이것을 검토하고 괜찮아 보이는지 알려주세요"는 검증기가 아닙니다.

"이 7가지 조건을 확인하고 7가지 모두 통과하는 경우에만 실행을 수락된 것으로 표시"하는 것이 검증기입니다.

/loop로 예약하기

루프가 수동으로 안정적으로 실행되고 있습니다.

이제 예약하세요.

Claude Code에서 /loop를 사용하세요:

1/loop 24h 이 워크스페이스에 대한 일일 프로젝트 리뷰 루프를 실행하세요.
2
3`LOOP_INSTRUCTIONS.md`를 정확히 따르세요.
4먼저 `TASK.md` 및 `PROGRESS.md`를 읽으세요.
5`outputs/daily-review.md`에 보고서를 작성하세요.
6중지하기 전에 `PROGRESS.md`를 업데이트하세요.
7검증 체크리스트를 실행하세요.
8의미 있는 변경 사항이 없으면 → 보고서를 짧게 유지하세요.
9사람 검토가 필요한 경우 → `PROGRESS.md`에 명확히 표시하세요.
10`outputs/daily-review.md` 및 `PROGRESS.md` 이외의
11파일은 수정하지 마세요.

간격 옵션:

→ /loop 15m — 테스트 케이던스 (지켜보는 동안 사용)

→ /loop 1h — 시간별 모니터링

→ /loop 24h — 일일 리뷰

→ /loop 7d — 주간 정리 또는 요약

중요: /loop는 마법이 아닙니다.

단지 프롬프트를 반복할 뿐입니다.

루프의 품질은 프롬프트 주변의 구조(파일, 지침, 검증, 상태)에서 비롯됩니다.

/loop는 트리거만 제공합니다.

또한 /goal에 대해 알아두세요:

/loop = 시간이 지났으므로 다시 실행

/goal = 조건이 충족될 때까지 계속 실행

1/goal outputs/daily-review.md가 존재하고, PROGRESS.md가 업데이트되고,
2검증 체크리스트가 통과되고, 금지된 파일이 수정되지 않음.

시간 기반 작업(일일 리뷰, 모니터링)에는 /loop를 사용하세요.

완료 기반 작업(테스트 통과까지 수정, 모든 섹션 완료까지 작성)에는 /goal을 사용하세요.

권한 사다리

대부분의 루프가 잘못되는 지점입니다.

사람들은 작동하는 루프를 만듭니다. 그런 다음 즉시 너무 많은 권한을 부여합니다.

루프가 Slack에 직접 게시합니다. 검토 없이 코드를 푸시합니다. 티켓을 자동으로 종료합니다.

그러면 문제가 발생하고 엉망이 됩니다.

대신 권한 사다리를 사용하세요:

1레벨 1 — 읽기 전용
2Claude가 파일, 티켓, 로그, 이슈를 읽습니다.
3
4레벨 2 — 출력 초안 작성
5Claude가 outputs/에만 작성합니다.
6보고서, 계획, 권장 사항.
7외부에는 아무것도 없습니다.
8
9레벨 3 — 샌드박스 편집
10Claude가 통제된 샌드박스 내에서 파일을 수정합니다.
11격리된 브랜치 또는 워크트리.
12
13레벨 4 — 외부 작업 초안 작성
14Claude가 PR, Slack 메시지, 티켓 업데이트를 준비합니다.
15전송하거나 병합하지 않습니다.
16
17레벨 5 — 사람 승인 작업
18Claude는 명시적인 승인 후에만 변경 사항을 적용합니다.
19
20레벨 6 — 자동화된 저위험 작업
21Claude가 좁은 범위의 작업을 자동으로 완료합니다.
22로그, 제한 및 롤백과 함께.

첫 번째 루프는 레벨 1 또는 레벨 2에 있어야 합니다.

그것은 약함이 아닙니다. 그것은 엔지니어링입니다.

레벨 1 및 2 루프는 여전히 엄청나게 가치 있을 수 있습니다.

Claude는 GitHub 이슈를 검사하고, CI 실패를 읽고, PRD를 검토하고, 중요한 것을 건드리지 않고 모든 것을 요약할 수 있습니다.

먼저 레벨 2에서 루프가 작동함을 입증하세요.

그런 다음 레벨 3을 받을 자격이 있는지 결정하세요.

루프가 잘못될 때 (그리고 방지하는 방법)

잘못된 첫 번째 루프:

매일, 제품 전략이 더 강력해질 때까지 개선하세요.

→ 중지 조건 없음 → 검증 없음 → 상태 없음 → "더 강력해짐"은 체크리스트 항목이 아님

이 루프는 유용한 작업을 수행하지 않거나 수정해서는 안 될 것을 변경할 것입니다.

좋은 첫 번째 루프:

매주 금요일, 제품 전략 문서를 검토하세요.

이번 주에 변경된 섹션을 식별하세요.

해결되지 않은 가정을 나열하세요.

구조화된 리뷰 노트를 outputs/strategy-review.md에 작성하세요.

전략 문서를 직접 편집하지 마세요.

→ 명확한 일정 → 제한된 범위 → 예측 가능한 출력 파일 → 안전한 권한 경계

차이는 지능이 아닙니다. 설계입니다.

루프를 망치는 5가지:

→ 수동 테스트 전에 예약

→ 상태 파일 없음 — 모든 실행이 처음부터 다시 시작

→ 검증 없음 — 루프가 자신을 신뢰

→ 실패 정책 없음 — 나쁜 결과가 즉흥적으로 처리됨

→ 너무 이른 시기에 너무 많은 도구 — 폭발 반경 확장

첫 번째 /loop 명령 전에 다섯 가지를 모두 수정하세요.

도구 및 커넥터 추가

로컬 루프가 안정화되면 확장할 수 있습니다.

GitHub. Slack. Linear. Jira. CI 로그.

하지만 모든 새 도구는 폭발 반경을 확장합니다.

동일한 원칙을 따르세요: 먼저 읽고, 두 번째로 초안을 작성하고, 반복적인 성공적인 실행 후에만 작성하세요.

도구별 규칙은 LOOP_INSTRUCTIONS.md에 넣습니다:

1## 도구 권한 정책
2
3### GitHub
4허용:
5- 공개 이슈 읽기
6- 풀 리퀘스트 상태 읽기
7- CI 상태 읽기
8- `outputs/github-review.md`에 요약 초안 작성
9허용되지 않음:
10- 커밋 푸시
11- 풀 리퀘스트 병합
12- 이슈 종료
13- 승인 없이 공개 댓글 작성
14
15### Slack
16허용:
17- `outputs/slack-update.md`에 메시지 초안 작성
18허용되지 않음:
19- 메시지 전송
20- 사용자 멘션
21- 채널에 게시
22
23### Linear/Jira
24허용:
25- 할당된 티켓 읽기
26- 제안된 업데이트 초안 작성
27허용되지 않음:
28- 상태 변경
29- 티켓 종료
30- 승인 없이 티켓 생성

도구가 나열되지 않은 경우 → 중지하고 사람의 검토를 요청하세요.

이것은 생각하지 못한 작업을 루프가 수행하는 것으로부터 여러분을 보호합니다.

첫 번째 완전한 루프의 모습

처음부터 전체 설정입니다.

1## 도구 권한 정책
2
3### GitHub
4허용:
5- 공개 이슈 읽기
6- 풀 리퀘스트 상태 읽기
7- CI 상태 읽기
8- `outputs/github-review.md`에 요약 초안 작성
9허용되지 않음:
10- 커밋 푸시
11- 풀 리퀘스트 병합
12- 이슈 종료
13- 승인 없이 공개 댓글 작성
14
15### Slack
16허용:
17- `outputs/slack-update.md`에 메시지 초안 작성
18허용되지 않음:
19- 메시지 전송
20- 사용자 멘션
21- 채널에 게시
22
23### Linear/Jira
24허용:
25- 할당된 티켓 읽기
26- 제안된 업데이트 초안 작성
27허용되지 않음:
28- 상태 변경
29- 티켓 종료
30- 승인 없이 티켓 생성

그런 다음 각 파일을 채웁니다 (위의 템플릿 사용).

그런 다음 수동으로 실행합니다:

1이 워크스페이스에 대한 일일 프로젝트 리뷰 루프를 실행하세요.
2
3`LOOP_INSTRUCTIONS.md`를 정확히 따르세요.
4실행 전에 TASK.md, PROGRESS.md
5및 LOOP_INSTRUCTIONS.md를 읽으세요.
6일일 리뷰를 `outputs/daily-review.md`에 작성하세요.
7중지하기 전에 `PROGRESS.md`를 업데이트하세요.
8검증 체크리스트를 실행하세요.
9`outputs/daily-review.md` 및 `PROGRESS.md` 이외의
10파일은 수정하지 마세요.

그런 다음 검증합니다:

1검증 패스를 실행하세요.
2`LOOP_INSTRUCTIONS.md`의 검증 체크리스트에 대해
3확인하세요.
4통과한 검사, 실패한 검사,
5수정된 파일, 사람 검토 필요 여부를 보고하세요.
6파일을 수정하지 마세요.

작은 워크스페이스 변경 사항을 적용하여 3-5회 수동으로 실행하세요.

그런 다음 예약합니다:

1/loop 24h 일일 프로젝트 리뷰 루프를 실행하세요...
2[수동과 동일한 프롬프트, /loop 24h 접두사 포함]

신뢰하기 전에 예약된 출력의 첫 주를 검토하세요.

이것이 전체 시스템입니다.

모든 것을 바꾸는 전환

루프 이전:

→ 프롬프트를 작성했습니다

→ Claude가 대답했습니다

→ 다음 날 동일한 프롬프트를 다시 작성했습니다

→ Claude는 어제의 기억이 없었습니다

→ 변경된 사항을 수동으로 추적했습니다

→ 모든 것이 각 세션과 함께 재설정되었습니다

루프 이후:

→ TASK.md는 목표를 한 번 정의합니다

→ PROGRESS.md는 실행 간에 메모리를 전달합니다

→ LOOP_INSTRUCTIONS.md는 동작을 제어합니다

→ Claude는 읽고, 실행하고, 검증하고, 업데이트하고, 중지합니다

→ 다음 날 중단된 지점에서 계속됩니다

→ 프롬프트가 아닌 출력을 검토합니다

병목 현상이 작업 생성에서 작업 검토로 이동합니다.

그것이 진정한 레버리지입니다.

Claude에게 더 나은 질문을 하는 것이 아닙니다.

여러분 없이도 계속 작동하는 시스템을 설계하는 것입니다.

이번 주에 구축할 수 있는 10가지 루프

→ 일일 프로젝트 리뷰 — 워크스페이스를 읽고 요약 작성

→ 회의 후속 조치 추출기 — 노트를 실행 항목으로 변환

→ 폴더 정리 플래너 — 정리하고, 제안하고, 건드리지 않음

→ CI 실패 분류 — 로그를 읽고, 실패를 분류하고, 조사 초안 작성

→ GitHub 이슈 요약기 — 공개 이슈를 읽고, 주제별로 그룹화

→ PR 리뷰 어시스턴트 — diff를 읽고, 잠재적 문제 플래그 지정

→ 뉴스레터 연구 루프 — 소스를 수집하고, 요약 초안 작성

→ 문서 격차 찾기 — 문서를 읽고, 누락된 섹션 플래그 지정

→ 일일 스탠드업 초안 작성기 — PROGRESS.md를 읽고, 스탠드업 작성

→ 주간 회고 루프 — 주간을 검토하고, 패턴 식별

이 모든 것은 동일한 4가지 파일 시스템으로 시작됩니다.

변경되는 유일한 것은 TASK.md와 LOOP_INSTRUCTIONS.md입니다.

이 내용이 유용했다면:

→ Claude를 사용하는 모든 개발자와 공유하기 위해 리포스트하세요

→ 더 많은 시스템에 대해 @sairahul1를 팔로우하세요

→ 북마크하세요 — 템플릿은 복사하여 붙여넣기 준비가 되어 있습니다

더 많은 흥미로운 기사를 보려면 theaibuilders.co를 구독하세요

저는 AI, 제품 구축 및 자동화 시스템에 대해 글을 씁니다.