루프 설계 + 검토
전제. LLM은 피드포워드 시스템입니다. 프롬프트 입력 → 토큰 출력, 턴을 넘나들며 '목표를 향해 조종'하는 내장 기능은 없습니다. LLM이 목표 지향 시스템처럼 행동하게 하려면 주위에 피드백 루프를 감싸야 합니다. 이 스킬은 그 루프를 올바르게 작성하고, 검토하여 루프가 통제 불능이 되지 않도록 도와줍니다.
사용 시기 / 사용하지 말아야 할 때
이런 경우에 사용하세요:
- 반복되는 작업을 에이전트에 맡기고 싶을 때 (작성→테스트, 테스트→수정, 수정→검증…).
- 이미 루프가 있는데, 루프가 무한 반복되거나, 속임수를 쓰거나, 잘못된 답변을 끝까지 실행할까 걱정될 때.
이런 경우에는 사용하지 마세요:
- 일회성 작업 → 그냥 직접 수행하고, 굳이 루프로 감쌀 필요 없습니다.
- 단순 타이머/폴링 →
/loop를 사용하면 되며, 별도 설계가 필요하지 않습니다. - 루프 아키텍처 배선 방법 (파이프라인 → DAG, 장기 실행 복구) → 이는 메커니즘 계층입니다.
autonomous-loops/continuous-agent-loop를 참조하세요. 이 스킬은 '목표가 올바른지, 루프가 통제 불능이 될지'만 다루며, 메커니즘을 다시 설명하지 않습니다.
레드라인 전제: 두 수준의 피드백
| 수준 | 소유자 | 역할 |
|---|---|---|
| 실행 (하위) | 기계/에이전트 | '문자 그대로의 목표로부터 얼마나 떨어져 있는지' 측정하고 0으로 만듭니다. 기계가 강력한 영역입니다. |
| 판단 (상위) | 인간 | '이 목표 자체가 올바른지, 변경해야 하는지, 중단해야 하는지' 결정합니다. 기계는 자신의 루프 밖으로 나가 목표에 의문을 제기할 수 없습니다. |
온도 조절기는 '26°C에서 얼마나 떨어졌는지' 피드백할 수 있지만, 당신이 열이 나서 28°C를 원할 때 26°C가 올바른 목표인지 판단할 수 없습니다. 그저 26°C를 향해 갈 뿐입니다. '오늘은 몇 도로 설정할지'는 항상 인간의 결정입니다. 판단/최종 승인/마지막 스위치를 기계에 넘기는 것은 상위 피드백을 제거하는 것과 같습니다. 그러면 기계는 아무도 의문을 제기하지 않은 목표를 향해 빠르고 강하게 질주하여 잘못된 결과를 냅니다.
액션 1 — 루프 작성 (5단계)
0단계 · 먼저 차감: 과연 구축해야 할까? (4가지 조건 게이트, 하나라도 빗나가면 거부)
① 작업이 주 단위 이상으로 반복됨 ② 검증을 자동화할 수 있음 ③ 토큰 예산이 감당 가능함 ④ 에이전트가 실제로 실행하고 결과를 확인하는 도구를 가짐
하나라도 빗나가면 → 루프를 만들지 마세요; 직접 하거나 다른 방법을 사용하세요.
대부분의 사람을 막는 것은 '루프를 작성할 수 있느냐'가 아니라 '내 저장소에 루프가 필요하냐'입니다. 루프가 필요한 저장소는 조정 기준선(골든 샘플/업스트림 총계) + 테스트 + 린트 가드가 갖춰져 있습니다. 루프가 필요 없는 저장소는 루프로 인해 오류만 증폭될 뿐입니다.
1단계 · 기계가 판단 가능한 목표를 정의하라 (어려운 부분 — 루프의 성패가 여기서 결정)
루프 전체는 비교기의 '아직 끝났나요?' 판단에 달려 있습니다. 비교기는 종료 조건을 기계가 예/아니오로 판단할 수 있을 때만 작동합니다.
- 나쁨: 모호함 ('좋게 만들어', '더 날카롭게 작성해') → 비교기가 판단 불가 → 끝나지 않거나 (갇혀서 재시도) 추측함 (무작위로 통과/차단).
- 좋음: 판단 가능 ('96개 단위 테스트 모두 통과 AND 변경 목록 생성됨', '모듈-02 필드 채워짐, pytest 통과, 비즈니스 로직 변경 없음') → 한 번 확인으로 해결됨; 루프가 깔끔하게 수렴함.
5가지 목표 프레임워크:
- 완료 기준이 기계 검증 가능해야 함.
- 완료 기준과 함께 경계 조건이 정의되어야 함 (