루프 설계 + 검토
전제. LLM은 피드포워드 시스템입니다. 프롬프트 입력 → 토큰 출력, 여러 턴에 걸쳐 '목표를 향한 조종' 기능이 내장되어 있지 않습니다. 이를 목표 지향 시스템처럼 행동하게 만들려면, 피드백 루프로 감싸야 합니다. 이 스킬은 루프를 올바르게 작성하고, 루프가 통제 불능 상태에 빠지지 않도록 검토하는 데 도움을 줍니다.
사용해야 하는 경우 / 사용하지 말아야 하는 경우
사용해야 하는 경우:
- 반복 작업을 에이전트에 넘겨서 계속 실행하게 하려는 경우 (작성→테스트, 테스트→수정, 수정→검증…).
- 이미 루프가 있는데, 루프가 빙글빙글 돌거나, 속임수를 쓰거나, 잘못된 답변을 끝까지 실행할까 걱정되는 경우.
사용하지 말아야 하는 경우:
- 일회성 작업 → 그냥 직접 수행하세요. 루프로 감싸지 마세요.
- 단순 타이머 / 폴링 →
/loop를 사용하세요. 설계가 필요하지 않습니다. - 루프 아키텍처를 어떻게 연결할지 (파이프라인 → DAG, 장기 실행 복구) → 이것은 메커니즘 레이어입니다.
autonomous-loops/continuous-agent-loop를 참조하세요. 이 스킬은 '목표가 올바른지, 그리고 루프가 통제 불능 상태가 될지' 만 다룹니다. 메커니즘을 다시 설명하지 않습니다.
레드-라인 전제: 두 가지 피드백 수준
| 수준 | 소유자 | 역할 |
|---|---|---|
| 실행 (낮음) | 기계 / 에이전트 | '문자 그대로의 목표로부터 얼마나 떨어져 있는지' 측정하고 0으로 만듭니다. 기계가 강합니다. |
| 판단 (높음) | 인간 | '이 목표 자체가 올바른지, 변경해야 하는지, 중단해야 하는지' 결정합니다. 기계는 자신의 루프 밖으로 나가서 목표에 의문을 제기할 수 없습니다. |
온도 조절기는 '26°C와의 차이'를 피드백할 수 있지만, 열이 나서 28°C를 원할 때 26이 올바른 목표인지 판단할 수 없습니다. 그냥 26을 향해 계속 조정할 뿐입니다. '오늘 무엇으로 설정할지'는 항상 인간의 몫입니다. 판단 / 승인 / 최종 스위치를 기계에 넘기는 것 = 높은 수준의 피드백을 제거하는 것 = 아무도 의문을 제기하지 않은 목표를 향해 빠르고 강하게 돌진 → 잘못된 출력.
액션 1 — 루프 작성 (5단계)
단계 0 · 먼저 빼기: 과연 구축해야 할까요? (4-조건 게이트, 하나라도 놓치면 거부)
① 작업이 매주 이상 반복됨 ② 검증을 자동화할 수 있음 ③ 토큰 예산이 감당 가능함 ④ 에이전트가 실제로 실행되고 결과를 볼 수 있는 도구를 가지고 있음
하나라도 놓치면 → 루프를 구축하지 마세요. 수동으로 하거나 다른 방법을 사용하세요.
대부분의 사람을 막는 것은 '루프를 작성할 수 있느냐'가 아니라 '내 리포지토리가 루프를 가질 가치가 있느냐'입니다. 루프를 가질 가치가 있는 리포지토리에는 조정 기준(골든 샘플 / 업스트림 합계) + 테스트 + 린트 가드가 있습니다. 루프를 가질 가치가 없는 리포지토리는 루프가 그 오류를 증폭시킬 뿐입니다.
단계 1 · 기계가 결정할 수 있는 목표 정의 (어려운 부분 — 루프의 성패가 여기서 결정됨)
전체 루프는 비교기의 '아직 끝났나요?' 판단에 달려 있습니다. 비교기는 종료 조건을 기계가 예/아니오로 판단할 수 있을 때만 작동합니다.
- 나쁨: 모호함 ('좋게 만들어', '더 날카롭게 써') → 비교기가 판단할 수 없음 → 영원히 통과하지 못하거나(재시도에 갇힘) 추측함(무작위로 통과/차단).
- 좋음: 결정 가능함 ('96개 단위 테스트 모두 통과 AND 변경 목록 생성됨', '모듈-02 필드 채워짐, pytest 통과, 비즈니스 로직 수정되지 않음') → 한 번 확인으로 해결됨. 루프가 깔끔하게 수렴합니다.
5-포인트 목표 프레임워크:
- 완료 기준은 기계가 검증 가능해야 합니다.
- 완료 기준과 함께 경계 조건도 정의되어야 합니다. ('하지 말아야 할 것') — Goodhart 방지; 경계 조건이 없으면 속임수 면허증입니다.
- 실패 폴백이 있어야 합니다. — 재시도 상한 N + 초과 시 인간에게 에스컬레이션.
- 목표는 계층화되어야 합니다.
- 완료 기준에 어설션보다 조정을 선호하세요. — 자신의 어설션보다 외부 사실(골든 샘플 / 업스트림 합계 / 재무 조정 / 플랫폼 백오피스 수치)에 고정하세요. '모든 테스트 통과'는 조작될 수 있습니다(어설션 완화, 목 mock, 예외 삼키기). '참조와의 차이 < 0.01'은 조작할 수 없습니다.
자가 점검: 도메인을 모르는 사람에게 목표를 읽어주세요. 그 사람이 하나의 명령을 실행하고 완료되었는지 알 수 있나요? 그렇지 않다면, 충분히 결정 가능하지 않은 것입니다. 다시 하세요.
단계 2 · 루프 유형 선택
| 작업 | 루프 유형 (사이버네틱) | 중단 방법 |
|---|---|---|
| 명확한 '완료' 테스트가 있음 (완료될 때까지 작성 / 이미지 배치 처리) | 서보 (/goal 스타일 폐쇄 루프) | 목표 도달 시 중단 |
| 종료점이 없고, 상태를 계속 유지해야 함 (재고 알림 / 정기 상태 확인) | 레귤레이터 (/loop 스타일 온도 조절기) | 절대 중단되지 않음; 변경 시에만 작동 (불감대가 잡음 억제) |
| 주기적 샘플링, 조건이 충족되면 중단 (PR이 CI 통과할 때까지 감시) | 종료 조건이 있는 레귤레이터 | 종료 조건이 충족되면 중단 |
| '무언가가 제때 일어나도록 해야 함' | 위의 루프를 /schedule로 감싸기 | cron이 실행 |
경험 법칙: 명확한 '완료' 테스트 → 서보; 계속 유지해야 하고 종료점이 없음 → 레귤레이터; '제때 일어나야 함' → 레귤레이터를 스케줄로 감싸기.
단계 3 · 스켈레톤 선택
유지 관리 유형 (존재하는 것을 관리) → 문서 기반 디스패치. 루프는 '고정된 검사를 타이머에 실행'하는 것이 아니라 **'타이머에 문서를 읽고, 문서가 변경된 경우에만 디스패치'**하는 것입니다. 문서는 작업 큐 + 상태 머신 + 인간 인터페이스입니다. 세 가지 규율: ① 문제 열은 인간만 작성 가능, 결과 열은 루프만 작성 가능, 상태는 단방향으로 진행되며 절대 롤백되지 않음; ② 종료 코드는 최종적임 (스크립트가 exit 1을 반환하면 스크립트가 이김); ③ 상태는 '검증 대기 중'까지만 진행됨 — '완료' 셀은 인간만 변경 가능. 루프는 작업자이지 승인 담당자가 아닙니다.
신규 구축 유형 (처음부터 구축) → 계획 / 구축 / 판사, 세 가지 역할.
| 역할 | 수행 | 핵심 |
|---|---|---|
| 계획 | 목표를 스펙 + 결정 가능한 승인 조건으로 분해 | 승인은 스크립트로 판단 가능해야 함 |
| 구축 | 스펙에 따라 작성 | 승인 조건을 변경해서는 안 됨 |
| 판사 | 승인을 독립적으로 실행; 통과 → 중단, 실패 → 실패 이유와 함께 구축으로 반환 | 독립적 + 결정론적 |
세 가지 불변 규칙 (모두 판사에 기반): ① 판사는 독립적이어야 함 — 구축과 동일한 에이전트가 아님 (자기 숙제를 채점하면 항상 부풀려짐); ② 결정론적 규칙 — pytest / 조정 차이 / 타입 검사 / diff, 절대 '괜찮아 보임' 안 됨; ③ 구축은 통과를 위해 승인 조건을 수정할 수 없음. 세 번 재시도 실패 → 인간에게 에스컬레이션.
단계 4 · 댐핑 추가 (발진 / 폭주 방지)
재시도 상한, 하드 스톱, 인간이 최종 스위치를 토글 = 댐핑. 댐핑이 없는 네거티브 피드백은 진동합니다 (Ralph-Wiggum 루프: 제자리에서 빙글빙글 돌며 토큰 소모).
단계 5 · 세 단계로 배포 (첫날부터 완전 자동화하지 마세요)
① 수동으로 한 번 실행 (판사가 결정하는 방식을 정확히 명시해야 함) → ② 스킬 / Claude Code 하위 에이전트로 견고하게 만듦 (메인 Claude가 루프를 돌며 계획/구축/판사를 디스패치) → ③ 완전 자동화를 위해 cron에 연결.
액션 2 — 루프 검토 (체크리스트 = 다섯 가지 실패 모드)
각 행에 대해 루프를 실행하세요. 하나라도 적중하면 이 루프는 오작동합니다. 다시 보내세요. 이 다섯 가지는 부정적인 경험(문제점)입니다. 긍정적인 규칙보다 가치가 있습니다.
| # | 실패 모드 (어떻게 고장 나는가) | 검토 질문 (적중 = 빨간색) | 항체 |
|---|---|---|---|
| 1 | 목표가 올바른 상투적인 말 → 빙글빙글 돌며 돈을 태움 | 종료 조건을 기계가 예/아니오로 판단할 수 있나요? 아니면 '잘 관리하세요 / 좋게 만드세요' 같은 것인가요? | 결정 가능한 결과 조건으로 교체 (액션 1·단계 1) |
| 2 | '검증'이 '괜찮아 보이는지 확인'으로 작성됨 → 에이전트가 자신 있게 괜찮다고 말하고 중단 | 판사가 피고인 자신인가요? 검증이 '괜찮아 보임' 또는 결정론적 규칙에 의존하나요? | 조정 + 종료 코드 규칙 + 독립적인 판사 |
| 3 | (최악) '모든 테스트 통과'만 게이트로 삼음 → 에이전트가 테스트를 삭제함 | 경계 조건 ('하지 말아야 할 것')이 있나요? 아니면 완료 기준만 있나요? | 완료 기준 + 경계 조건 함께 (Goodhart 항체) |
| 4 | 에이전트가 실행 중에 질문할 것이라고 기대함 → 그러지 않음; 잘못된 답변을 끝까지 실행 | '런타임에만 명확히 하라'는 지점이 있나요? | 모든 명확화를 사전에 처리하세요. 실행 전에 한 번 정리하세요. |
| 5 | 부풀려진 CLAUDE.md + 오래된 메모리 → 루프가 빠를수록 더 많이 실수 | 의존하는 문서/메모리가 최신인가요? 누가 유지 관리하나요? | 계층화된 메모리 + 정기적인 린트 |
추가로 세 가지 레드라인 (하나라도 위반하면 자동 실행 불가):
- 판단을 인간에게 유지하세요. 승인 / '완료' 셀은 인간이 전환합니다. 루프는 승인 담당자가 아닙니다.
- 책임은 이전되지 않습니다. 실패를 감당할 수 없는 일 (잘못된 PR 병합 / 잘못된 게시 / 자금 오배정) → 자동으로 권한을 넘기지 마세요.
- 직관에 반하는 경고. 루프가 '자기 개선 / 자신의 규칙을 다시 작성'할수록 더 엄격한 인간 검토가 필요합니다 (규칙을 무엇으로 다시 작성했는지 확인하기 위해) — 느슨해지는 것이 아닙니다. 기계는 너무 빨라서 사후에 차단할 수 없으므로, 인간의 판단은 행동 전에 (하드 게이트) 위치해야 하며 사후 패치가 아닙니다.
작업 예시 — '야간 그린-키퍼' 루프 검토
매일 밤 실행되어 실패하는 테스트를 수정하는 루프를 원합니다.
- 순진한 목표: '모든 테스트 통과.' → 단계 1 자가 점검 실패: 이것은 실패 모드 #3의 미끼입니다.
- 결정 가능한 목표 (수정됨): '모든 테스트 통과 AND 테스트 파일 삭제 또는 약화 없음 AND 커버리지 하락 없음 AND 변경 목록 생성됨.' 이제 경계 조건이 완료 기준과 함께 정의되었습니다.
- 유형: 재시도 상한 3의 서보 (단계 2 + 단계 4).
- 스켈레톤: 계획/구축/판사 — 판사는 CI가 독립적으로 실행하며, 절대 수정 에이전트가 아닙니다 (단계 3).
이제 검토 체크리스트를 실행하면, 순진한 버전이 놓쳤을 것을 잡아냅니다:
- #3 적중 → 순진한 '모든 테스트 통과'는 에이전트가 실패하는 테스트를 삭제하여 '승리'하도록 합니다. '테스트 파일 삭제/약화 없음'이라는 경계 조건으로 수정되었습니다.
- #2 적중 → 수정 에이전트가 자신의 수정을 직접 판단했다면, 스스로를 통과시켰을 것입니다. '판사 = 독립적인 CI, 결정론적'으로 수정되었습니다.
- #4 적중 → 수정이 모호할 경우, 에이전트는 새벽 2시에 멈춰서 묻지 않습니다. 추측을 커밋할 것입니다. 사전 처리로 수정: 모호한 수정은 인간에게 남겨두고 추측하지 않습니다.
- 레드라인 → 루프는 PR을 열지만 자동 병합하지 않습니다. 인간이 최종 스위치를 전환합니다 (책임 이전되지 않음).
순진한 루프와 검토된 루프는 네 줄의 제약 조건만 다릅니다 — 그리고 그것이 '삭제된 테스트 스위트로 당신을 깨우는 것'과 '깨끗한 PR로 당신을 깨우는 것'의 차이입니다.
한 줄 마무리
루프 작성의 어려운 부분은 '루프를 작성할 수 있느냐'가 아니라, 기계가 조정할 수 있는 목표를 정의하는 것입니다 — 결정 가능하고, 경계가 있으며, 조정 기반. 제어기는 결정론적이고 외부적이어야 하며, 판단과 기준은 인간에게 유지하세요. 시스템은 엔트로피를 향해 가므로 유지 관리하세요. 루프는 이미 충분히 생각한 사람에게만 보상합니다. 루프가 당신을 대신해 생각할 것이라고 믿으면, 루프는 기꺼이 당신과 함께, 대규모로, 틀리게 생각할 것입니다.
출처: 판단/실행 분할 및 레드라인에 대한 Wiener의 두 수준 피드백 (The Human Use of Human Beings, 1950); Anatoli의 Loops explained와 Addy의 Loop Engineering의 계획/구축/판사 패턴. 메커니즘 레이어 (루프 아키텍처 연결 방법):
autonomous-loops/continuous-agent-loop참조. 이 스킬은 메커니즘을 다시 구현하지 않습니다. 목표 정의와 폭주 방지만 다룹니다.