🚀 서론

2026년 6월에 Addy Osmani 씨가 제창한 루프 엔지니어링 (Loop Engineering)은, "인간이 프롬프트를 입력하는 것"을 그만두고, AI 에이전트가 자율적으로 작동하는 루프 그 자체를 설계하는 기법으로서 급속히 확산되었습니다.

한편, 실제로 루프를 돌리기 시작한 팀으로부터 들려오는 소식이 성공담만은 아닙니다. 루프는 설계자의 판단을 증폭하는 장치입니다. 좋은 판단도 증폭하지만, 판단의 결함도 동일한 배율로 증폭합니다. 본 기사에서는 실제로 보고되고 있는 실패 패턴을 6가지로 정리하고, 각각의 대책을 Bad/Good 형식으로 소개합니다.

대상 독자는 Claude Code나 Codex 등의 코딩 에이전트로 루프를 구축하기 시작했거나(구축하려는) 엔지니어입니다.

🔄 전제: 루프의 기본 구조

실패 사례에 들어가기에 앞서, 루프의 최소 구성을 확인합니다.

기동 (트리거)
→ 태스크 로드 (외부 메모리)
→ 구현 (Worktree 상에서 격리 실행)
...

이후의 실패 사례는 거의 모두 이 구조의 어딘가에서 결락되거나 소홀히 처리된 것에 기인합니다.

🎭 실패 사례 1: Verifier Theater —— 검증하는 척하기

증상: Verifier가 승인했는데도 CI가 실패함. "LGTM"을 양산하기만 하는 검증 에이전트가 완성됨.

가장 많고, 가장 뿌리 깊은 실패입니다. 원인은 Verifier의 프롬프트가 모호한 것, 그리고 테스트나 lint 실행을 생략하고 "코드를 읽은 감상"만으로 판정하게 하는 것입니다.

LLM에는 출력을 긍정하기 쉬운 편향 (Bias)이 있기 때문에, "문제가 없는지 확인해줘"라는 지시는 실질적으로 "승인해줘"와 동의어가 됩니다.

# Bad: 모호한 검증 지시
verifier:
prompt: "이 변경 사항에 문제가 없는지 확인해 주세요"

# Good: 거절 이유를 찾는 프레이밍 (Framing) + 기계적 검증의 필수화
verifier:
prompt: |
...

구현자와 검증자를 동일 모델 (동일 컨텍스트)로 만드는 것은 논외입니다. 자신의 답안을 스스로 채점하게 하면, 채점 기준이 답안 쪽으로 치우치게 됩니다.

♾️ 실패 사례 2: Infinite Fix Loop —— 수렴하지 않는 자동 수정

증상: 동일한 PR이나 티켓에 대해 자동 수정이 5회, 10회 계속 적용되어, 아침에 일어나 보니 토큰만 사라져 있음.

원인은 재시도 상한 (attempt cap) 미설정입니다. Verifier의 오승인이나 잘못된 근본 원인 진단이 수정을 계속 재트리거하여, 같은 곳을 계속 파헤치게 만듭니다.

# Bad: 정지 조건이 없음
loop:
trigger: ci_failure
...

중요한 것은 "진척이 없음"을 탐지하는 것입니다. 단순한 횟수 제한이 아니라, "같은 에러를 반복하고 있다 = 루프가 정체되어 있다"를 감지하여 멈추는 설계가 필요합니다.

💸 실패 사례 3: 비용 폭발 —— 24시간 가동되는 청구서

증상: 월말에 API 이용료 청구서를 보고 얼굴이 창백해짐.

루프는 실패하더라도 과금됩니다. 무한 재시도는 무한 청구입니다. 전형적인 유발 요인은 3가지가 있습니다. 예산 상한 미설정, 분 단위의 과도한 cadence (실행 간격), 그리고 "처리해야 할 아이템이 없어도 매번 풀 패스 (Full path)를 돌리는" 구조입니다.

# Good: 예산과 cadence 설계 예시
budget:
token_daily_limit: 2_000_000
...

"저렴한 모델로 triage → 필요할 때만 강력한 모델로 action"을 수행하는 2단계 구조와, "비어 있으면 즉시 종료"하는 조기 리턴 (Early return)만으로도 비용의 단위가 달라집니다.

🗑️ 실패 사례 4: State Rot —— 부패해가는 외부 메모리

증상: 루프의 상태 파일 (STATE.md 등)에 종료된 태스크가 증식하여, 에이전트가 오래된 정보를 읽고 오작동함.

루프는 외부 메모리 (Markdown 파일이나 Linear 티켓)에 상태를 써 내려가며 "기억"을 지속합니다. 여기에 pruning (가지치기) 단계가 없으면, 상태 파일은 계속 써지기만 하여 비대해지고, 결국 컨텍스트를 압박하여 에이전트의 판단 품질을 저하시킵니다. 여러 루프가 동일한 파일에 쓰는 구성에서는 경합 (Contention)으로 인해 더욱 가속화됩니다.

대책은 두 가지입니다. 실행할 때마다 종료된 아이템을 삭제하는 단계를 루프 자체에 포함시키는 것, 그리고 루프마다 상태 파일을 분리하는 것입니다. 스테이트풀 (Stateful)한 시스템에 GC (가비지 컬렉션)가 필요한 것은 AI 루프에서도 마찬가지입니다.

📉 실패 사례 5: 이해 부채의 소용돌이 (Comprehension Debt Spiral) —— 아무도 읽지 않는 코드의 산

증상: 어느 날, 팀의 그 누구도 변경 의도를 설명할 수 없는 코드가 운영 환경에서 돌아가고 있다는 사실을 깨닫는다.

루프가 빠르게 성과를 낼수록, "사람이 읽지 않는 코드"가 쌓여갑니다. auto-merge (자동 병합)의 범위를 조금씩 넓히고, 주간 리뷰를 "이번 주는 바쁘니까"라며 생략한다. 이 두 가지가 결합되면 이해 부채 (Comprehension Debt)는 복리로 증가합니다.

기술적 부채는 리팩터링 (Refactoring)으로 갚을 수 있지만, 이해 부채는 장애가 발생한 순간 일괄 상환을 강요받습니다. 아무도 디버깅할 수 없는 시스템의 장애 대응만큼 비용이 많이 드는 것도 없습니다.

대책은 운영 규칙으로서 강제하는 것입니다. 주간 다이제스트 (루프가 무엇을 했는지에 대한 요약) 생성과 함께 읽는 과정을 의무화하고, 리스크가 중간 단계 이상인 변경 사항은 auto-merge에서 수동 게이트 (Human Gate) 방식으로 되돌립니다. "읽는 시간 또한 루프의 운영 비용"이라고 산정해야 합니다.

🚫 실패 사례 6: 검증 불가능한 태스크의 루프화 —— 애초에 돌려서는 안 되는 것

증상: "UI를 더 사용하기 쉽게 계속 개선해줘"와 같은 루프가, 그럴듯해 보이지만 아무도 원하지 않는 변경 사항을 양산한다.

이는 설계 미스라기보다 태스크 선정의 미스입니다. 루프가 기능하는 것은 성과를 기계적으로 검증할 수 있는 태스크에 한정됩니다. 도입 전에 다음 4가지 조건으로 필터링해야 합니다.

• 반복성 (Iterability): 해당 태스크가 반복적으로 발생하는가
• 낮은 검증 비용 (Low Verification Cost): 기계적인 테스트 및 판정이 가능한가
• 좁은 영향 범위 (Narrow Blast Radius): 실패하더라도 치명적이지 않은가
• 24시간 가동의 가치 (Value of 24/7 Operation): API 비용을 지불할 가치가 있는가

"보안이 유지되는 것", "사용하기 편한 것"과 같이 검증기 (Verifier)를 작성하기 어려운 품질 특성은 루프 외부에서 사람이 리뷰할 수밖에 없습니다. 테스트를 통과하는 것과 사양 (Specification)을 충족하는 것은 동일하지 않다 (굿하트의 법칙, Goodhart's Law)라는 당연한 사실이, 루프에서는 증폭되어 돌아옵니다.

🛑 요약: 정지 조건을 퍼스트 클래스 (First-Class)로 설계하라

6가지 실패 사례를 관통하는 공통 원칙은 하나입니다. 루프를 만들기 전에, 루프를 어떻게 멈출지를 설계하라.

• Verifier (검증기)에게는 "거절할 이유를 찾게" 하여 구현자와 분리한다
• attempt cap (시도 횟수 제한)과 "진척 없음 감지"로 수렴을 보장한다
• 예산 상한, triage (트리아지) 2단계 구조, 조기 종료로 비용을 억제한다
• 외부 메모리에는 GC (가비지 컬렉션)를 포함시킨다
• 주간 리뷰를 생략하지 않는다. 이해 부채는 장애 시 일괄 청구된다
• 검증 불가능한 태스크는 루프에 넣지 않는다

루프 엔지니어링은 "실크햇을 쓴 Cron 잡 (Cron job)"이라고 야유받기도 하지만, Cron과 결정적으로 다른 점은 내부에서 작동하는 것이 비결정적 (Non-deterministic) 에이전트라는 점입니다. 비결정적 컴포넌트를 감시 없이 돌리는 리스크는 인프라 운영을 해온 사람일수록 직관적으로 이해할 수 있을 것입니다.

정지 조건이 없는 루프를 운영 환경에서 돌려서는 안 됩니다. 이를 불변의 규칙으로 삼아, 안전하게 레버리지를 활용해 나갑시다.

📚 참고

Discussion