가장 비싼 조합은 검증기 없는 루프 + 상태 없는 재시도 — 안티패턴 10종과 진단 순서

루프가 이상하게 동작할 때 가장 먼저 나오는 가설은 대개 "모델이 별로다"이다. 그런데 실제로 잡히는 원인의 대부분은 앞의 세 자리 — 종료 조건, 상태 반영, 예산 경계 — 에 있다. 모델 교체는 가장 비싸고 가장 늦게 검토해야 할 선택지다.

이 글은 그 진단 순서를 고정한다. 루프가 무너지는 열 가지 방식을 증상·원인·해결로 세우고 가장 비싼 조합을 지목한 뒤, 여섯 단계 진단 체크리스트와 남겨야 할 트레이스 필드로 내려간다. 후반은 조직 쪽이다 — 도입 자체를 하나의 루프로 다루는 절차, 그리고 근거의 강도를 다섯 종으로 나눠 남의 사례 수치를 자사 예측으로 직결하는 실수를 막는 법. 앞 편이 여덟 개 설계 표면을 세웠다면 이 글은 그 표면들이 무너지는 자리를 짚고, 시리즈의 마지막 편이라 세 자료를 관통하는 서사로 닫는다.

이 글은 2026년 4월부터 6월까지의 자료를 정리한 것이다. 인용된 통계·벤치마크·벤더 주장은 근거 강도가 서로 다르며, 아래 「근거 강도 구분」 절이 그 차이를 표로 정리한다.

용어 정리

앞 편들의 용어표에서 이 글이 쓰는 행만 추리고, 실패 모드 용어를 더했다.

루프가 무너지는 열 가지 방식

가장 비싼 조합은 검증기 없는 루프 + 상태 없는 재시도다. 비용은 선형으로 늘고 품질은 그대로다.

이 조합이 위험한 이유는 겉으로 정상 동작처럼 보이기 때문이다. 에러도 나지 않고 로그도 쌓이며 에이전트는 계속 무언가를 한다. 다만 나아지지 않을 뿐이다. 자율성을 올리기 전에 이 둘부터 막아야 하고, 순서가 반대면 자율성이 커진 만큼 낭비도 커진다.

열 항목을 원인별로 묶으면 넷이 된다 — 종료 조건 계열(1·3), 상태 계열(2·4·5), 권한 계열(6·7·8), 구조 계열(9·10). 셋째 묶음이 가장 크다는 점이 2026년 담론의 무게중심을 보여준다.

모델을 바꾸기 전에 좁히는 순서

루프가 이상하게 동작하면 아래 순서로 좁힌다. 대부분의 문제는 1~3번에서 잡힌다.

여섯 항목이 앞 절 안티패턴과 대응하지만 순서가 다르다. 안티패턴 표는 비용순이고 이 표는 확인 비용순이다 — 종료 조건은 코드 한 줄로 답이 나오고 권한 경계는 전수 조사가 필요하다.

디버깅에 꼭 남길 트레이스 필드는 여섯이다.

trace.fields
step         n
state_in     {budget, done, last_proof}
action       tool_name, args, scope
observation  exit_code, summary, error_kind
proof        verifier_result, failures[]
decision     continue | retry | handoff | stop(reason)

트러블슈팅 원칙: "모델이 왜 그랬을까"로 시작하지 않는다.

트레이스를 펼쳐 어떤 상태와 관찰, 검증기 결과가 그 행동을 만들었는지부터 본다. 위 여섯 필드가 재구성에 필요한 최소 집합이고, 특히 stop(reason)이 결정적이다 — 중단 사유가 없으면 성공한 종료와 예산 소진을 구분할 수 없어 성공률 통계 자체가 무의미해진다. 재현 가능한 트레이스가 없으면 디버깅이 아니라 추측이다.

도입 체크리스트

기술 레벨 — 최소 루프 다섯 단계

도구 선택은 마지막 문제다. 성공 기준·상태·권한·관찰 형식·검증기·종료 조건을 먼저 정한다.

네 번째 열이 이 표의 값어치다. 각 단계의 완료 판정이 "했다"가 아니라 관찰 가능한 조건으로 적혀 있어서, 단계를 건너뛰었는지를 스스로 확인할 수 있다.

custom_loop.py · 직접 작성
spec  = load_task_contract(goal, success_criteria, risk_policy)
state = pack_context(spec, repo_snapshot, memory, budget)
while budget.ok() and not state.done:
    action = policy.choose_next(state)
    obs    = guarded_tools.run(action)      # scoped, timed, logged
    proof  = verifier.check(obs, spec)
    state  = update_state(state, obs, proof)
    if proof.requires_human:
        break                                # 고위험 변경은 사람에게 handoff
return artifact, trace, proof, stop_reason

검증을 루프에 넣는 evaluator-optimizer 템플릿은 그래프 프레임워크에서 이렇게 생겼다.

def route(state) -> Literal["Accepted", "Rejected + Feedback"]:
    return "Accepted" if state["grade"] == "pass" else "Rejected + Feedback"

builder.add_edge(START, "generate")
builder.add_edge("generate", "evaluate")
builder.add_conditional_edges("evaluate", route, {
    "Accepted": END,
    "Rejected + Feedback": "generate",   # 피드백을 들고 다시 생성
})

주석 한 줄이 요점이다 — 피드백을 들고 다시 생성한다. 그냥 되돌아가면 앞 절의 "상태 없는 재시도"가 된다.

조직 레벨 — 도입 자체가 루프다

pilot이 행동, 측정이 관찰, 채택 기준이 검증기, 확장 또는 중단이 계속/중지다.

세 번째 단계의 순서가 이 절의 핵심 주장이다 — 거버넌스를 확장 후가 아니라 파일럿과 동시에 설계한다.

근거는 앞 편의 통계에 있다. 파일럿 78%, 프로덕션 14%, 실패의 89%가 비기술 요인. 파일럿은 거버넌스 없이도 성공하고 프로덕션은 그렇지 않으므로, 나중에 붙이는 계획은 64포인트 격차를 그대로 재생산한다. 도식의 되돌림 화살표도 같은 성격이다 — 측정 결과가 다음 파일럿의 범위를 정한다는 것은 실패한 파일럿에도 산출물이 있다는 뜻이다.

근거 강도를 구분한다

같은 자료가 보고한 배경 수치로, 2024년 미국 민간 AI 투자는 1,091억 달러, 글로벌 생성형 AI 민간 투자는 339억 달러였고, 조직의 AI 사용은 2023년 **55%**에서 2024년 **78%**로 늘었다.

가장 흔한 실수는 남의 사례 수치를 자사 ROI 예측으로 직결하는 것이다.

두 번째 행이 특히 오독되기 쉽다. "49%가 절감했다"는 절감을 경험한 조직의 비율이지 평균 49%를 아꼈다는 뜻이 아니고, 실제 절감 폭은 대부분 10% 미만이다. 공개 수치는 방향 신호일 뿐이고, 실제 효과는 어떤 작업을 루프화하고 어떤 검증·승인 경계를 뒀는지가 가른다.

산출량이 아니라 결과를 센다

왼쪽 넷의 공통점은 측정이 쉽다는 것이고, 그래서 대시보드에 먼저 올라간다. ROI를 묻기 전에 검증기부터 만든다 — 결과를 테스트·리뷰·운영 지표로 판정할 수 없는 작업은 효과도 증명할 수 없으며, 이는 측정 가능한 작업이 루프화에 적합한 작업이라는 앞 편의 기준과 같은 말이다. DORA 지표와 묶으면 속도와 안정성을 함께 본다.

여섯 줄로 압축한 운영 원칙

loop-designer.operating-principles
start with a small task and explicit success criteria
build deterministic eval before autonomy
scope tools by least privilege and reversible side effects
trace state, actions, observations, verifier evidence
expand only when the loop improves outcome, not vibes

도식은 여섯 마디인데 원칙 코드는 다섯 줄이다. 5·6번이 코드의 마지막 줄 하나로 합쳐지는데, 승인 지점을 명시하는 것과 검증된 만큼만 확장하는 것이 실행상 같은 동작이기 때문이다. 이름은 바뀌어도 이 원칙은 남는다 — 프롬프트가 아니라 검증 가능한 반복 시스템을 작게 설계하고 안전하게 확장하는 능력.

무엇을 더 읽을 것인가

단일 "Loop Engineering 논문"은 없다. 여섯 종류의 루프 조합으로 본다.

출처 위생 — 출판사 설명만으로 핵심 주장을 근거화하지 않는다.

추천 목록에는 넣되 핵심 주장에는 논문·공식 문서·저자 원문·저장소를 우선한다. 커뮤니티도 같다. 큐레이션 목록·포럼·저장소 토픽은 새 도구 발견에는 좋지만 사실 근거로는 약해서, 거기서 찾은 항목은 공식 문서나 논문으로 역추적한 뒤에 인용한다.

세 축은 하나로 수렴한다

"Loop Engineering"이 표준 용어가 되는지는 중요하지 않다. 분명한 것은 능력·런타임·평가가 하나의 운영 루프로 수렴한다는 점이다.

개발자의 역할도 그 수렴을 따라간다 — 모델에게 한 번 잘 말하는 사람에서 실패를 관찰·복구하며 검증 가능한 단위로 자율성을 안전하게 확장하는 사람으로.

루프의 목표는 사람을 제거하는 것이 아니라, 사람이 아키텍처·품질·정확성을 소유한 채 반복 작업을 위임 가능하게 만드는 것이다. AI 보조 코딩 담론도 같은 결론에 닿는다 — 검토 없이 산출물을 받아들이는 방식은 프로토타이핑으로 제한하고, 전문 워크플로에서는 명세·작업 범위·diff 리뷰·테스트·버전 관리·CI·문서화·모니터링을 유지한다. 자율성이 커질수록 규율은 줄지 않고 늘어난다.

조직에 옮기면 무엇이 되는가

열 행 중 여섯의 세 번째 열이 감사·전수 조사·목록 확정으로 시작한다. 새로 만드는 것보다 이미 도는 것을 들여다보는 일이 앞선다는 배치이며, 이것이 이 시리즈 전체의 실행 지침이기도 하다.

세 자료를 관통하는 하나의 서사

세 달치 자료는 독립 발표처럼 보이지만 같은 문제의 세 단면이다.

여섯 행 중 네 번째가 이 시리즈의 서사다. 설계자 → 판단자 → 소유자로 사람의 위치가 옮겨 가는데, 승격이 아니라 같은 사람이 세 층에서 하는 서로 다른 일이다. 편으로 대응시키면 첫 두 편이 왼쪽 열, 세 번째·네 번째 편이 가운데, 마지막 세 편이 오른쪽이다.

세 메시지가 각각 세 번 반복됐다는 것이 이 표의 정보다. 서로 다른 문제를 다루는 세 자료가 독립적으로 같은 결론에 도착했다면, 그것은 특정 도구나 시기의 특성이 아니라 에이전트를 운영한다는 일 자체의 성질일 가능성이 높다.

일곱 편에 걸쳐 2026년 하반기의 논의를 정리했다. 모델은 상향 평준화됐고 차이는 하네스에서 나며, 하네스는 스스로 진화하되 거버넌스와 짝을 이뤄야 하고, 위임 격차는 신뢰의 구조로 메우며, 자율 실행은 단일 디스패처와 결정 로그로 감사 가능하게 만들고, 루프는 여덟 표면을 가진 런타임 계약이며, 무너질 때는 열 가지 방식 중 하나다.

이 카테고리에는 앞서 프레임워크 비교부터 멀티에이전트 패턴까지의 구현 계보가 따로 정리돼 있다. 도구를 고르는 문제와 루프를 소유하는 문제는 층위가 다르므로, 두 계열을 나란히 읽으면 어느 결정이 어느 층에 속하는지가 분명해진다.

그리고 두 계열에서 반복해 돌아오는 질문들은 네 편의 문답으로 따로 모아 두었다 — 기본기 · 실행 모델 · 멀티에이전트 · 운영.