2026년에 제 AI 코딩 에이전트들에게 한 가지 더 규칙을 가지고 싶어: 언제 멈춰야 할지 알아야 한다.
AI 에이전트는 항상 멈추면서 실패하지 않는다.
때로는 계속하면서 실패한다.
제가 실제 브랜드 시스템용 고유의 키릴 문자 폰트 확장을 만들 때 이 문제를 마주했다. 작업은 구체적으로 보였다: 키릴 문자, 라틴 문자, 숫자, 특수 문자가 하나의 편집용 타이포그래피 패밀리처럼 느껴지도록 만들다.
Claude Code와 Codex는 계속 작동했습니다. 파일을 생성하고, 증명서를 내보내고, 진행 상황을 보고하고, 마지막으로 보이는 불만을 수정했습니다.
하지만 동일한 결함 유형이 계속 반복되었습니다.
이것은 AI 에이전트 실패 루프의 위험한 버전입니다: 워크플로우는 생산적처럼 보이지만 실제 품질 문제는 생존합니다.
실패 루프는 무엇인가요?
실패 루프는 에이전트가 동일한 기저 결함이 해결되지 않은 상태에서 새로운 후보 수정 사항을 계속 생성하는 반복 패턴입니다.
이는 일반적으로 다섯 단계로 구성됩니다.
- 사용자가 동일한 유형의 결함을 다시 거부합니다.
- 에이전트는 최신 증상을 수정합니다.
- 확증 게이트는 문제를 포착할 수 있는 만큼 약합니다.
- 에이전트는 다른 수동 검토를 요청합니다.
- 모두 같은 문제에 대해 또 한 번의 순환을 보낸다.
한 실수는 정상이다.
실제 프로세스 버그는 에이전트가 검증 시스템이 이미 실패한 후에도 계속될 때 나타난다.
왜 정상적인 증명 루프가 실패할 수 있는가
증명 루프는 유용하다. 테스트, 스크린샷, 빌드 확인, 린팅, 차이점, 생성된 보고서 모두 중요하다.
하지만 증명 루프는 잘못된 것을 측정하면 극장이 될 수도 있습니다.
제 폰트 프로젝트에서는 에이전트가 폰트가 컴파일되었음을 증명할 수 있었고, PDF가 렌더링되었음을, 스크린샷이 존재함을, 경계 상자가 변경되었음을, 그리고 숫자 점수가 향상되었음을.
그것은 글자가 제대로 보였음을 증명하지 못했습니다.
사용자들은 다른 것을 거부하고 있었습니다: 시각적 일관성.
키릴리 문자들은 라틴 문자들 옆에서 너무 짧거나, 두껍거나, 너무 희박하게 간격을 두거나, 구조적으로 잘못되어 보였습니다.
만약 게이트가 인간이 계속 보는 결함을 볼 수 없다면, 게이트는 작업이 완료되었다고 선언할 수 없습니다.
지금 사용하는 규칙은
동일한 눈에 띄는 결함 클래스가 두 번 나타나면 정상적인 실행을 중단합니다.
더 이상 추측적인 패치를 만들지 마세요.
임계점을 완화하지 마세요.
다른 후보 항목을 검토하도록 사용자에게 요청하지 마세요.
실패 루프 파괴 모드로 전환하세요.
실패 루프 파괴기가 하는 일
실패 루프 파괴기는 AI 에이전트 작업의 어려운 모드 스위치입니다.
더 나은 다음 출력은 다른 후보 수정 사항이 아니라 진단 패키지입니다.
다음과 같은 내용을 포함해야 합니다:
- 반복적인 실패 클래스;
- 거부된 잘못된 예시의 코퍼스;
- 이런 예시들에 실패하는 빨강-먼저 게이트;
- 게이트를 녹색으로 바꾸는 수정;
- 작가가 정답을 본 경우의 맹인 또는 독립 검증;
- 명확한 계속, 중단, 또는 인간의 결정 추천.
이것은 재시도 제한만이 아니다.
반복 제한은 비용 증가를 막습니다. 실패 루프 분해기는 작업 자체를 변경합니다.
빨간색 우선 게이트는 중요합니다
유용한 게이트는 수정 전에 실패해야 하며, 그렇지 않으면 오래된 실패를 볼 수 있는지 증명되지 않았습니다.
대리인이 이전에 잘못된 아티팩트에서 새로운 체크러를 실패시킬 수 없으면 실제 문제를 위한 체크러를 구축하지 않았습니다.
많은 대리인 워크플로우는 이 부분을 건너뜁니다.
새로운 지표를 추가하고, 새로운 후보 점수가 더 높게 나타나서 진전이라고 부릅니다. 이 지표는 결코 오래된 실패를 거부하도록 강요되지 않았습니다.
주관적이거나 시각적 작업의 경우, 이는 더욱 중요합니다. 거부된 말뭉치는 인간의 취향과 결정론적 검증 사이의 다리가 됩니다.
에이전트가 오염되었을 때
다른 함정은 오염된 검증입니다: 동일한 에이전트가 수정 사항을 작성하고, 타겟을 알고, 결과를 평가합니다.
이는 반복 중에 유용할 수 있지만, 독립적인 검증이 아닙니다.
대리인이 기대되는 답변을 이미 본 경우, 최종 검사는 보류된 예제와의 결정론적 게이트, 맹인 리뷰어, 작성자의 사유를 받지 않는 별도의 모델, 또는 요구 사항이 계산보다는 취향일 때 인간의 결정이 필요합니다.
동일 작성자 검증은 종종 자기 일관성이지 증명은 아닙니다.
저는 이를 작은 공개 기술로 포장했습니다.
나는 규칙을 작은 공개 저장소로 바꿨습니다:
https://github.com/g-shevchenko/agent-failure-loop-breaker
Claude Code, Codex, Cursor, 그리고 Windsurf를 위한 간결한 스킬과 저장소 지역 규칙을 설치합니다.
설치된 규칙은 의도적으로 간단합니다:
동일한 결함 클래스가 두 번 나타나면 에이전트는 정상적인 패치를 중단하고 거부된 코퍼스와 빨간색 우선 게이트를 만들기 전에 계속해야 합니다.
이 패키지는 모델을 더 지능적으로 만들기 위해 만들어지지 않았습니다.
그것은 워크플로우가 움직임을 진전으로 혼동할 가능성을 줄입니다.
회사들이 잘못하는 부분
팀들은 종종 에이전트의 지속성을 기본적으로 자산으로 취급합니다.
괜찮은 범위의 구현 작업과 강력한 테스트가 있는 경우 그것은 합리적입니다. 수용 기준이 시각적, 편집적, 아키텍처적, 또는 운영적인 작업에서는 위험합니다.
Claude Code, Codex, Cursor, 또는 Windsurf가 동일한 종류의 검토를 계속 실패하면 다음 투자는 검증 계약에 가야 합니다.
세계에서 가장 좋은 프롬프트라도 게이트가 잘못된 아티팩트를 보상할 때는 여전히 루프에 빠집니다.
이곳에서 도움이 됩니다
이 패턴은 UI 마무리 루프, 시각적 재현 작업, PDF 및 프레젠테이션 생성, 타이포그래피 시스템, 콘텐츠 QA, 그리고 동일한 버그가 반복되는 에지스틱 코딩 작업에 유용합니다.
신호는 이렇습니다:
사용자가 "이것이 여전히 같은 문제입니다"라고 두 번 말하면, 프로세스가 변경되어야 합니다.
실용적인 트레이드오프
AI 에이전트에게 영원히 “다시 시도해”라고 요청하지 마세요.
그 대신, 그의 검사기가 마지막으로 실패한 시도를 포착할 수 있음을 증명하도록 요청하세요.
그렇지 못하면 다음 작업은 구현이 아닙니다.
그때, 다음 작업은 더 나은 게이트를 구축하는 것입니다.
전체 기록:
https://gregshevchenko.com/notes/ai-agent-failure-loop-breakers/