자동 교정 루프

개요

AI는 실패를 보고 스스로 고칠 수 있다. 문제는 그 자동 교정이 쉽게 무한 재시도나 범위 확장으로 변한다는 점이다.

그래서 auto-correction loop는 존재 여부보다 얼마나 bounded 되어 있는가가 더 중요하다.

이 문서는 harness/ai 적용 레이어에서 fix -> verify -> retry가 어디서 멈춰야 하는지를 다룬다.

좋은 loop의 기본 형태

가장 단순한 형태는 다음과 같다.

change
-> run narrow check
-> parse failure
-> patch within scope
-> rerun same check
-> stop or escalate

여기서 핵심은 항상 같은 check를 같은 범위에서 다시 돌린다는 점이다.

bounded loop의 조건

retry budget이 있다

반복 횟수 제한이 없으면 AI는 같은 위반을 조금씩 다른 형태로 계속 재생산한다.

scope lock이 있다

현재 task boundary 밖으로 수정 범위가 퍼지지 않게 해야 한다. 실패 하나를 고치려다 unrelated refactor로 번지면 루프 품질이 무너진다.

gate가 좁다

항상 전체 테스트나 전체 빌드를 돌리면 교정 루프가 느려지고 원인도 흐려진다.

stop condition이 분명하다

다음 경우에는 멈춰야 한다.

• 같은 rule violation이 반복된다
• failure type이 바뀌지 않는다
• check가 서로 다른 방향을 요구한다
• task scope 밖 수정이 필요해진다

나쁜 auto-correction loop 패턴

• 한번 실패하면 전체 프로젝트를 다 고치려 한다
• 매 반복마다 검사 범위를 넓힌다
• 실패 형식을 해석하지 못해 broad refactor로 도망간다
• retry budget 없이 “다시 해본다"를 반복한다
• stop 대신 fallback patch를 덧붙인다

이런 루프는 self-healing이 아니라 self-amplifying failure에 가깝다.

사람이 끼어야 하는 시점

auto-correction은 강력하지만, 모든 실패를 끝까지 자동화하려고 하면 오히려 비용이 커진다.

보통 다음 지점에서 사람 판단이 필요하다.

• 합법 경로 자체가 없을 때
• rule 충돌이 드러날 때
• 여러 파일에 걸친 구조 변경이 필요할 때
• 같은 예외가 반복되어 정책 판단이 필요할 때

좋은 loop는 자동화를 극대화하는 것이 아니라, 사람 개입이 필요한 지점을 빨리 드러낸다.

AI 코딩에서 왜 특히 중요해지는가

AI는 실패를 보고 즉시 다음 시도를 만들 수 있다. 이 장점은 loop가 좋을 때만 장점이다.

• 좁은 gate와 명확한 stop이 있으면 빠르게 수렴한다
• 반대로 범위와 stop이 흐리면 더 빠르게 무너진다

그래서 AI auto-correction은 속도보다 경계가 먼저다.

실무 질문

• retry budget이 명시되어 있는가
• 매 반복에서 같은 gate를 다시 돌리는가
• 수정 범위가 task boundary 안에 잠겨 있는가
• 반복 실패 시 사람에게 넘기는 조건이 있는가
• fallback patch가 auto-correction처럼 위장되어 있지 않은가

요약

좋은 auto-correction loop는 다음을 만족한다.

• gate가 좁고
• retry가 제한되며
• scope가 잠겨 있고
• stop condition이 분명하다

AI의 자동 교정은 많이 돌리는 것이 아니라, 같은 범위 안에서 짧게 수렴하고 빨리 멈추게 만드는 것이 핵심이다.