9.3.4.2 타입 불일치 에러 피드백을 활용한 모델 자가 수정(Self-Correction) 프롬프트

9.3.4.2 타입 불일치 에러 피드백을 활용한 모델 자가 수정(Self-Correction) 프롬프트

정적 타입 분석기(Mypy, Pyright, TypeScript Compiler 등)가 잡아낸 오류를 단순히 “검증 실패(Fail)“라는 이분법적 신호(Binary Signal)로 소비하고 코드를 버리는 것은, 오라클 파이프라인이 가진 잠재력을 절반만 사용하는 것이다. LLM은 인간 개발자와 달리 자존심이 없으며, 구조화되고 명확한 에러 로그가 주어졌을 때 자신의 코드를 되짚어 버그를 수정하는 ‘자가 수정(Self-Correction)’ 능력이 경이로울 정도로 뛰어나다.

특히, 런타임에 발생하는 Segmentation Fault나 Null Reference Exception처럼 원인을 알 수 없는 에러에 비해, 정적 타입 에러는 **‘어떤 줄(Line)에서, 어떤 기대(Expected) 타입과 실제(Actual) 타입이 충돌했는지’**가 기하학적으로 정확하게 명시된다. 오라클 설계자의 임무는 이 기계적인 에러 로그를 LLM의 Attention 매트릭스가 가장 효과적으로 인식할 수 있는 ’프롬프트(Prompt)’의 형태로 번역(Translation)하여 역으로 주입하는 것이다.

1. Mypy/TypeScript 에러 로그의 해체와 정규화

오라클 미들웨어는 Mypy나 tsc가 출력하는 거칠고 장황한 CLI(Command Line Interface) 텍스트를 그대로 LLM에게 전달해서는 안 된다. 장황한 콜스택(Call stack)이나 터미널 제어 문자(ANSI Color Code)는 LLM의 컨텍스트를 오염시키고 환각을 가중시킬 뿐이다.

오라클은 정규표현식이나 분석기 자체의 JSON 출력 옵션을 사용하여 핵심 지표 4가지를 추출해야 한다.

  1. 발생 위치: Error Line Number 및 offending code snippet
  2. 에러 유형 코드: (예: TS2322, [arg-type])
  3. 기대된 타입(Expected Type): 인터페이스나 함수 시그니처가 요구한 타입 명세
  4. 전달된 타입(Actual Type): LLM이 잘못 추론해서 밀어 넣은 타입

2. Self-Correction 프롬프트 템플릿(Template) 구성

추출된 4가지 핵심 요소는 사전 정의된 프롬프트 템플릿에 블립(Blip)되어 타겟 모델에게 새로운 System Prompt 형식으로 반송된다. 이때 중요한 것은 AI에게 “어떻게 고쳐라“라고 해결책(Solution)을 지시하는 것이 아니라, “무엇이 충돌했는지” 객관적인 팩트만 전달하여 추론의 몫을 AI에게 남겨두는 것이다.

[System Constraint Alert: Static Type Checking Failed]

당신이 방금 생성한 코드의 정적 타입 검증(Static Type Verification)이 실패했습니다. 
타입 검사기의 진단 결과는 다음과 같습니다. 이 리포트를 분석하여 타입을 일치시키도록 코드를 수정(Refactoring)하십시오. 새로운 기능이나 부작용을 추가하지 마십시오.

* 파일 및 위치: `controller.py`, Line 42
* 에러 코드: `[arg-type]`
* 에러 메시지: Argument 1 to "calculate_discount" has incompatible type "Optional[int]"; expected "int".
* 문제의 코드 라인: `result = calculate_discount(user.get_point())`

[가이던스]
이 에러는 값이 None이 될 수 있는 Optional 타입을 그대로 강타입(Strict Type) 함수에 주입하려 했기 때문에 발생했습니다.
가드 조건문(if ~ is not None)을 추가하여 안전하게 언래핑(Unwrapping) 처리하거나, 조기 반환(Early Return) 패턴을 적용하십시오. 수정된 전체 코드를 마크다운 블록으로 출력하십시오.

3. 피드백 루프의 수렴(Convergence)과 중단(Halt) 조건

타입 에러 피드백을 활용한 자가 수정 루프는 영원히 도는 무한 루프(Infinite Loop)가 되어서는 안 된다. LLM이 타입 에러를 고치려다가 오히려 비즈니스 로직을 무너뜨리거나 새로운 타입 에러를 창조해 내는 ‘에러 진동(Error Oscillation)’ 현상이 발생할 수 있다.

  • 최대 재시도(Max Retries) 제한: 오라클은 단일 코드 블록에 대해 타입 에러 피드백 루프를 최대 3~5회로 엄격하게 대조한다.
  • 에러 해시(Error Hash) 추적: 만약 LLM이 1회 차에 뱉은 에러(예: Line 42: TS2322)와 2회 차에 제출한 코드에서 터진 에러가 정확히 일치한다면, 이는 LLM이 현재의 추론 능력으로는 이 타입 컨트랙트를 해결할 수 없는 교착 상태(Deadlock)에 빠졌음을 의미한다.
  • 루프 제한에 도달하거나 동일한 에러를 반복할 경우, 오라클은 가차 없이 자가 수정을 중단(Halt)시키고 해당 생성을 [FAILED] 처리하여 인간 개발자의 리뷰 풀(Review Pool)로 티켓을 넘긴다.

타입 불일치 피드백 루프는 컴파일러라는 가장 완벽하고 차가운 심판관의 판결을, 오라클 미들웨어가 알아들을 수 있는 언어로 번역하여 AI의 이성을 회복시키는 과정이다. 이 루프가 맹렬하게 회전하는 CI/CD 파이프라인 속에서, LLM은 환각을 스스로 걷어내고 점진적으로 타입-안전한(Type-safe) 코드의 결정체로 수렴해 나간다.