모델 자체가 버그일 때: AI 증강 상태 관리의 비결정적 실패 디버깅

원래 tamiz.pro에 게시됨.

AI 시스템에서의 결정론이라는 환상

전통적인 소프트웨어 엔지니어링에서는 폐쇄 세계의 법칙(Law of the Closed World)에 의존합니다. 즉, 동일한 입력이 주어지면 프로그램은 항상 같은 출력을 생성한다는 것입니다. 이러한 예측 가능성은 단위 테스트(unit testing), 결정론적 상태 관리(deterministic state management), 재현 가능한 빌드(reproducible builds)의 초석을 이룹니다. 하지만 대규모 언어 모델(LLMs)이나 다른 확률적 구성 요소를 애플리케이션의 핵심 상태 기계에 통합할 때, 이러한 가정은 무너집니다. 갑자기 '버그'는 단순한 논리 오류가 아니라, 실행할 때마다 다르게 나타나는 통계적 이상 현상이 됩니다.

AI 증강 상태 관리에서 비결정적 실패를 디버깅하는 것은 단순히 로그를 더 많이 추가하는 문제가 아닙니다. 이는 우리가 상태(state), 제어 흐름(control flow), 검증(verification)을 바라보는 방식에 근본적인 변화가 필요함을 의미합니다. 이 글에서는 이러한 확률적 괴물들을 길들이는 데 필요한 아키텍처 및 엔지니어링 전략을 탐구하며, 모델 자체가 '버그'일지라도 시스템이 관찰 가능하고(observable), 디버깅 가능하며(debuggable), 신뢰할 수 있도록(reliable) 하는 방법을 다룹니다.

비결정성의 해부학 (The Anatomy of Non-Determinism)
LLMs에서의 '하이젠버그'(Heisenbug): 재현이 실패하는 이유
아키텍처: 결정론과 확률의 분리
결정론적 가드레일(Deterministic Guardrails) 구현하기
관찰 가능성 (Observability): 확률적 경로 추적하기
확률적 상태를 위한 테스트 전략
결론

비결정성의 해부학

실패를 디버깅하려면, 먼저 그 근원을 이해해야 합니다. AI 증강 시스템에서 비결정성은 세 가지 주요 벡터(vectors)에서 발생합니다:

확률적 샘플링 (Stochastic Sampling): LLM은 확률에 기반하여 토큰을 선택하는 소프트맥스(softmax) 계층으로 작동합니다. temperature=0인 경우에도, 하드웨어 또는 라이브러리 버전에 따른 수치 부동소수점 차이가 상위-k개(top-k) 선택에서 미세한 변화를 초래할 수 있습니다.
맥락 드리프트 (Contextual Drift): 상태 관리 시스템은 종종 모델에 증가하는 컨텍스트 창(context window)을 전달합니다. 상태 표현(예: JSON 키 순서 변경)의 사소한 변화가 모델의 어텐션 메커니즘(attention mechanism)을 변경하여 현재 상태를 다르게 해석하게 만들 수 있습니다.
지연 시간 및 타임아웃 (Latency and Timeouts): 분산 AI 시스템에서 타임아웃과 재시도(retries)는 비결정적 동작을 도입합니다. 모델 호출이 시간 초과되어 재시도가 발생하면, 시스템 상태가 이미 발전했을 수 있으며, 이는 다른 프롬프트와 다른 결과를 초래할 수 있습니다.

LLM의 '하이젠버그 (Heisenbug)': 재생성이 실패하는 이유

하이젠버그는 관찰될 때 변화하거나 사라지는 문제입니다. AI 시스템에서 이것은 동일한 요청을 다시 실행하여 실패를 재현하려고 할 때 나타납니다. LLM은 상태적(context 측면)이며 확률적이기 때문에, '정확히 동일한 요청'이 실제로는 거의 동일하지 않습니다.

사용자 요청을 처리하는 상태 기계(state machine)를 고려해 봅시다. 상태는 JSON 객체입니다. 이를 LLM에 전달하여 의도(intent)를 분류하게 합니다. 만약 LLM이 의도를 잘못 분류하면, 상태가 잘못 전이됩니다. 버그를 재현하기 위해 상태를 재생할 때, 모델의 내부 확률 분포가 근본적인 모델 가중치(model weights)의 사소한 업데이트나 프롬프트 형식 지정의 미묘한 차이로 인해 이동했기 때문에 다른 토큰 시퀀스를 얻게 됩니다.

이는 전통적인 '재생 기반' 디버깅을 거의 불가능하게 만듭니다. 우리는 _입력 재현(replaying inputs)_에서 _결정 경로 재현(replaying decision paths)_으로 전환해야 합니다.

아키텍처: 결정론과 확률의 분리

이러한 시스템을 디버깅하는 핵심 아키텍처 원칙은 확률적 구성 요소를 격리하는 것입니다. 상태 관리 계층(state management layer)을 설계할 때, 전이 로직(transition logic)이 입력 자체가 확률적이더라도 결정론적(deterministic)이어야 합니다.

결정론적 래퍼 패턴 (The Deterministic Wrapper Pattern)

LLM이 상태를 직접 수정하도록 허용하는 대신, 우리는 LLM을 자문(advisory) 구성 요소로 사용합니다. LLM은 제안된 상태 전이를 생성하지만, 실제 적용하기 전에 결정론적 검증기(deterministic validator)가 이를 비즈니스 규칙과 비교하여 확인합니다.

class AIStateManager:
    def __init__(self, model):
        self.model = model
...

AI의 "환각(hallucination)"을 시스템의 "확정적 약속(commitment)"으로부터 분리함으로써, 우리는 디버깅하기 쉬운 실패 지점을 도입합니다. 만약 시스템에 오류가 발생한다면, 파서가 실패했는지, 상태를 거부한 검증기가 실패했는지, 아니면 유효하지 않은 형식을 생성한 AI가 실패했는지 알 수 있습니다. 이 각각은 결정론적이며 테스트 가능한 단위입니다.

상태 버전 관리 및 스냅샷 (State Versioning and Snapshots)

비결정론적인 오류는 종종 미묘합니다. 이를 디버깅하려면, 모든 전이 시점에서 상태를 스냅샷(snapshot)으로 저장할 수 있어야 합니다. 하지만 AI의 내부 표현은 불투명하기 때문에, 상태와 함께 전체 프롬프트 및 전체 원본 응답을 기록해야 합니다.

우리는 변경 불가능하고 해시 가능한 StateSnapshot 객체를 구현합니다:

interface StateSnapshot {
  id: string; // 입력의 해시를 기반으로 한 결정론적 ID
  timestamp: number;
...

aiPrompt와 aiRawResponse를 기록함으로써, 우리는 결정론적인 기록을 만듭니다. 모델 자체가 비결정론적이더라도, 모델에 대한 입력은 결정론적이었습니다. 이는 버그가 프롬프트 구성(우리 코드)에 있는지 아니면 모델의 해석("버그")에 있는지를 격리할 수 있게 해줍니다.

결정론적 가드레일 구현 (Implementing Deterministic Guardrails)

가드레일(Guardrails)은 확률적 AI를 제약하는 결정론적 로직입니다. 이는 비결정론적 실패를 디버깅하기 위한 주요 도구입니다. 실패가 발생하면, 시스템이 왜 AI의 제안을 거부했는지 확인하기 위해 가드레일을 검사합니다.

스키마 유효성 검사 (Schema Validation)

AI의 출력에 항상 엄격한 JSON Schema를 적용해야 합니다. 만약 AI가 스키마에서 벗어나면, 시스템은 결정론적 오류와 함께 빠르게 실패합니다. 이 오류는 디버깅하기 쉽습니다. 왜냐하면 AI가 존재하지 않는 필드를 반환하려고 했거나 잘못된 유형을 가지고 있음을 알려주기 때문입니다.

의미론적 일관성 검사 (Semantic Consistency Checks)

구조적 유효성 검사를 넘어, 우리는 의미론적 검사를 수행합니다. 예를 들어, 상태 기계(state machine)가 user.balance가 절대 음수가 되어선 안 된다고 요구한다면, 가드레일이 이를 확인합니다. 만약 AI가 user.balance가 -5인 상태를 제안하면, 가드레일이 이를 거부합니다. 이 거부는 SemanticViolation 이벤트로 기록되며, 이는 중요한 디버깅 아티팩트(debugging artifact)입니다.

폴백 전략 (Fallback Strategies)

가드레일이 실패할 때, 시스템은 결정론적인 폴백 경로를 가져야 합니다. 이는 다음과 같을 수 있습니다:

이전 상태로 되돌아가기(Reverting to the previous state).
AI 기능을 비활성화하는 '안전 모드'(safe mode) 트리거.
높은 심각도의 오류를 기록하고 사람에게 알림(alerting a human) 보내기.

핵심은 폴백 경로가 항상 예측 가능한 방식으로 취해진다는 것입니다. 이를 통해 AI가 오작동하더라도 시스템의 동작이 일관되게 유지됩니다.

관측 가능성 (Observability): 확률적 경로 추적

전통적인 관측 가능성(로그, 메트릭, 트레이스)은 AI 시스템에 충분하지 않습니다. 우리는 **확률적 관측 가능성(Probabilistic Observability)**이 필요합니다.

'의사 결정 트리' 추적 (The "Decision Tree" Trace)

선형적인 추적 대신, 우리는 AI가 내린 선택의 의사 결정 트리를 시각화합니다. 각 상태에 대해 다음을 기록합니다:

모델이 고려한 상위 3개 토큰.
각 토큰의 확률 점수(probability score).
선택된 토큰이 선택된 이유 (만약 모델이 사고 과정(chain-of-thought)을 제공하는 경우).

이 데이터는 전문 시각화 도구로 내보낼 수 있습니다. 버그가 발생했을 때, 해당 상태에 대한 '의사결정 트리(Decision Tree)'를 열어보면 모델이 올바른 행동에 대해 60% 확률을 가지고 있고 잘못된 행동에 대해 40% 확률을 가졌다는 것을 볼 수 있습니다. 이는 디버깅 초점을 '왜 코드가 실패했는가?'에서