9.9.4 최대 재시도 횟수 설정 및 비용 효율적인 수정 프로세스

개발자가 밤을 새워가며 삽질(Trial and Error)을 반복하는 것은 훌륭한 학습 과정이지만, 클라우드 환경에서 구동되는 대형 언어 모델(LLM)이 무한정 삽질을 반복하는 것은 막대한 인프라 비용과 API 과금(Token Billing)의 재앙을 초래한다.

자가 수정(Self-Correction) 피드백 루프는 그 자체로 매력적이지만, 자칫하면 모델이 코드의 A부분을 고치면서 B부분을 망가뜨리고, B를 고치면 다시 A가 망가지는 **‘탁구 게임(Ping-Pong Effect)’**에 빠질 위험이 도사리고 있다. 따라서 엔터프라이즈 레벨의 오라클 시스템은 LLM의 자율성을 통제하고 언제 “실패를 인정하고 포기할 것인지(Circuit Breaking)“를 결정하는 엄격한 최대 재시도(Max Retry) 메커니즘을 내장해야 한다.

1. 재시도 한계치(Max Retries)의 논리적 설정

LLM은 사람과 달라서, 3~4번의 시도에도 해결하지 못한 컴파일 에러를 10번, 20번 시도한다고 해서 기적적으로 해결할 확률은 통계적으로 0에 수렴한다. 오히려 컨텍스트 윈도우(Context Window)가 누적된 에러 로그와 이전 답변들로 가득 차면서 주의력(Attention)이 산만해지고 완전히 엉뚱한 코드를 생성하기 시작한다.

따라서 오라클은 파이프라인의 성격에 따라 하드 리미트(Hard Limit)를 세팅한다.

• 단순 유닛 테스트 통과 오라클: Max Retries = 3
• 복잡한 링커(Linker) 또는 의존성(Dependency) 해결 오라클: Max Retries = 5

만약 이 한계치에 도달할 때까지 오라클(컴파일러, 린터, 보안 스캐너)의 Quality Gate를 통과하지 못하면, 루프는 강제로 종료(Abort)되고 해당 작업은 인간에게 에스컬레이션(Escalation)되거나 휴지통으로 직행한다.

2. 온도(Temperature) 파라미터의 동적 스케일링(Dynamic Scaling)

만약 LLM이 똑같은 에러에 대해 계속 같은 해답만 고집하고 있다면, 이는 첫 번째 시도에서 최적이라고 생각했던 경로(Local Minima)에 갇혀버렸다는 뜻이다. 이럴 때 오라클 미들웨어는 재시도 회차가 증가할 때마다 모델의 파라미터를 동적으로 비틀어(Tweak) 탈출로를 열어주어야 한다.

• Turn 1 (초기 텍스트 생성): Temperature = 0.0 (가장 결정론적이고 보수적인 코드 생성 시도)
• Turn 2 (첫 번째 에러 발생 시): Temperature = 0.2 (기존 로직을 미세하게 수정)
• Turn 3 (루프 정체 감지 시): Temperature = 0.6 (창의성을 부여하여 아예 다른 디자인 패턴이나 API 사용을 유도)

이렇게 각 재시도 스테이지별로 모델의 창의성 파라미터(Temperature, Top-P)를 동적으로 스케일링하면, 무의미하게 똑같은 코드를 뱉어내며 토큰 비용을 낭비하는 현상을 극적으로 억제할 수 있다.

3. 비용 효율성을 위한 캐싱(Caching) 및 Fallback 모델 스위칭

자가 수정은 필연적으로 이전의 대화 컨텍스트(코드 + 에러 로그 + 수정 지시문)를 계속해서 중첩하여 전송해야 하므로 막대한 입력 토큰(Input Tokens) 폭탄을 유발한다. 이 비용을 방어하기 위한 두 가지 핵심 전략이 존재한다.

1. 프롬프트 캐싱(Prompt Caching): 대량의 런타임 종속성 코드(package.json이나 Cargo.toml), 사내 라이브러리 인터페이스(d.ts) 등 변하지 않는 거대한 베이스 컨텍스트는 캐시 메모리에 고정시켜 매 루프마다 다시 과금되지 않도록 설계된다.
2. 모델 폭포다운(Model Waterfall): 초기 스캐폴딩과 첫 번째 에러 수정은 가장 파라미터가 적고 빠르며 저렴한 모델(예: GPT-4o-mini, Claude 3.5 Haiku)에게 맡긴다. 만약 이 경량 모델이 재시도 한도(Max Retries = 3) 내에 오라클을 통과하지 못해 실패할 경우에만, 그동안의 ’실패 로그’를 모아 가장 무겁고 비싼 SOTA 모델(예: GPT-4o, Claude 3.5 Sonnet)에게 구원 투수(Fallback)로 넘기는 전략이다.

결국 에러 수정 과정의 오라클은 무한한 자원을 가진 구세주가 아니라, 정해진 예산과 기회 안에서만 관용을 베푸는 철저한 채권자(Creditor)로 행동해야 한다. 무한정으로 주어지는 피드백 루프는 결코 완벽한 코드를 만들어내지 못하며, 오직 명확한 종료 조건(Exit Condition)과 자원 통제만이 파이프라인의 경제성을 보장한다.