요약(TL;DR): 저는 원래 LLM 주변의 결정론적(Deterministic) 경계를 일관성 메커니즘으로 취급했습니다. 하지만 이제는 그 진정한 가치가 감사 가능성(Auditability)에 있다고 생각합니다. 시스템의 결정이 모델이 아닌 결정론적 코드에 의해 내려진다면, 모든 결정은 재현 가능한 구현을 갖게 됩니다. LLM은 인간에게 그 결정을 설명할 수는 있지만, 결정 그 자체의 근원이 되어서는 안 됩니다.

이전 두 개의 포스트에서 저는 서술(Narration)과 의사결정(Decision-making)을 분리해야 한다고 주장했습니다. 하나는 월간 보고(monthly reporting)를 다루었습니다. 다른 하나는 실시간 경고 주석 생성기(real-time alert annotator)를 다루었습니다. 두 포스트 모두 일관성에 초점을 맞추었습니다. 이 포스트는 일관성은 가시적인 이점일 뿐이며, 감사 가능성(Auditability)이 더 깊은 이점이라고 주장합니다. 제가 말하는 감사 가능성이란, 제3자가 사후 설명에 의존하는 대신 구현(Implementation)으로부터 어떻게 결정에 도달했는지 검사하고 이를 재현할 수 있음을 의미합니다.

결정론적 계층 (The Deterministic Layer)

경고 주석 생성기는 모든 경고를 8가지 값 중 하나로 분류하며, 이는 프롬프트(Prompt)에서 요청되는 것이 아니라 고정된 집합에 대해 Python으로 강제됩니다. 만약 모델의 출력이 8개의 문자열 중 하나와 정확히 일치하지 않으면, 해당 필드는 모델이 생성한 무엇인가를 수용하는 대신 unknown으로 대체됩니다. 그 검증(Validation) 단계는 열거형(Enum) 자체보다 더 중요합니다.

ALLOWED_CAUSES = {
    "memory_pressure", "cpu_saturation", "disk_pressure",
    "service_unavailability", "network_issue",
...

동일한 입력이 주어지면, 이 함수는 항상 동일한 출력을 생성합니다. 이는 모든 분류가 소스 코드만으로 재현 가능하다는 것을 의미합니다.

이것은 검증의 형태일 뿐, 프로덕션 코드의 복사본은 아닙니다. 하지만 핵심 원칙은 외부 시스템의 출력을 검증 없이 그대로 통과시켜 절대 신뢰해서는 안 된다는 것입니다. 이는 LLM에만 국한된 아이디어가 아닙니다. 제 데이터 모델에 닿기 전, 서드파티 웹훅(third-party webhook) 페이로드나 API 응답에 적용되어야 하는 것과 동일한 규율입니다. 모델은 제가 통합하는 외부 시스템 중 가장 예측 불가능한 시스템일 뿐이며, 이로 인해 검증(validation) 단계가 가장 눈에 띄게 가치 있는 작업이 됩니다.

저는 원래 이것을 일관성(consistency)을 위한 수정 사항으로 작성했으나, 그 전체적인 가치에 대해서는 충분히 논의하지 못했습니다. 열거형(enum)이 존재하기 전에는 동일한 경고(alert)라도 실행할 때마다 서로 다른 카테고리 문자열을 생성하여, 테넌트 간 패턴 분석(cross-tenant pattern analysis)이 불가능했습니다. 검증 단계가 실제로 보장하는 것은 모든 분류가 경계가 정해진 결정론적(deterministic) 결과 집합에 속한다는 것입니다. resolve_cause()는 순수 함수(pure function)이며, 모든 유효한 결과는 그 구현으로부터 재현 가능합니다. 이는 매번 입력과 출력의 일관성을 만들어내며, 전체 결정 과정은 단 16줄의 파이썬(Python) 코드로 이루어집니다.

전통적인 파이프라인 (Traditional pipeline):

Metrics
   |
   v
...

LLM 중심 파이프라인 (LLM-centric pipeline):

Metrics
   |
   v
...

중요한 차이점은 LLM이 대부분의 경우 정확해 보이는지 여부가 아닙니다. 검토자가 몇 달 후 동일한 입력으로부터 해당 결정을 재현할 수 있는지 여부입니다. 첫 번째 아키텍처에서 결정은 모델의 설명(narration)과는 독립적으로 존재합니다. 두 번째 아키텍처에서는 분류와 그에 대한 설명이 동일한 확률적 프로세스(probabilistic process)에서 기원하므로, 감사(audit) 중에 이 둘을 분리하기가 어렵습니다.

업계 트렌드 (Industry Trends)

알고 보니 현재 진행되는 상당수의 AI 거버넌스(AI governance) 작업은 정반대의 방향에서 접근하여 바로 이 속성(property)을 겨냥하고 있습니다. LLM 거버넌스 툴링(tooling) 시장의 상당 부분은 프로덕션 환경의 언어 모델 동작이 전통적인 소프트웨어가 제공하는 보증을 제공하지 못하기 때문에 존재합니다. 동일한 프롬프트(prompt)가 실행할 때마다 서로 다른 답변을 생성할 수 있으므로, 팀들은 확률적 시스템(probabilistic system)이 사후에 무엇을 왜 수행했는지 재구성하기 위해 구체적으로 트레이스 수준의 증거 시스템(trace-level evidence systems), 출력 평가기(output evaluators), 그리고 감사 로깅(audit logging)을 구축하고 있습니다.

규제적 배경은 이러한 이해관계가 추상적인 것이 아니라 명확하다는 것을 보여줍니다. EU AI Act에 따라 특정 클래스의 LLM 애플리케이션은 고위험(high-risk)으로 분류되며, 의무적인 로깅 및 인간 감독(human-oversight) 요구 사항이 따릅니다. 여기에는 기록이 단순히 시스템의 동작을 암시하는 수준이 아니라, 시스템의 작동을 재구성하기에 충분해야 한다는 명시적인 표준이 포함됩니다. NIST의 AI 위험 관리 프레임워크(AI Risk Management Framework)는 다른 각도에서 동일한 가정을 바탕으로 하며, 시스템 동작에 대한 신뢰할 수 있고 감사 가능한 기록을 거버넌스 기능의 전제 조건으로 취급합니다.

이 중 그 어떤 것도 제가 직접 작업하고 있는 프로젝트에는 적용되지 않습니다. 소규모 서버 플릿(server fleets)을 위한 어드바이저리 인프라 모니터링(Advisory infrastructure monitoring)은 고위험 범주가 아니며, 저는 EU AI Act 준수를 목표로 구축하고 있지도 않습니다. 하지만 근본적인 문제는 동일합니다. 단지 규모와 법적 결과의 수준이 다를 뿐입니다. 만약 어떤 결정이 누군가로부터

언어 모델에게 왜 특정 출력을 생성했는지 물어볼 수 있으며, 모델은 유창하고 그럴듯한 답변을 내놓을 것입니다. 하지만 그것이 실제 인과 기제 (causal mechanism)를 제공하는 것은 아닙니다. 설명은 원래의 답변을 생성한 내부 연산을 조사함으로써 이루어지는 것이 아니라, 대화 기록에 대한 새로운 추론 (inference) 과정 중에 생성됩니다. 모델은 이전 출력 뒤에 숨겨진 인과 과정을 검색하는 것이 아니라, 그럴듯한 설명을 생성하는 것입니다. 모델은 추측을 한 뒤 이를 직접 경험한 사실인 것처럼 제시할 것입니다.

최근의 AI 거버넌스 (AI governance) 연구는 이러한 현상의 실질적인 결과를 직접적으로 언급하며, 진정으로 재현 가능한 결정이 필요한 시스템은 확률적 계층 (probabilistic layer)에만 의존해서는 안 되며, 보조적인 안전장치로서 그 아래에 결정론적 집행 계층 (deterministic enforcement layer)을 두어야 한다고 명시하고 있습니다. 이는 LLM을 기반으로 구축하는 많은 사람들이 프로덕션 (production) 단계에 도달했을 때 독립적으로 도달하게 되는 결론을 공식적으로 기술한 방식입니다. 저의 경우, 업계가 무엇을 하고 있는지 생각하기도 전에 하나의 열거형 (enum)이 세 가지 다른 방식으로 계속 출력되는 것을 겪으며 이 결론에 도달했습니다. 다른 사람들은 규제 기관이 법적 효력이 있는 기록을 요구하기 때문에 이 결론에 도달하고 있습니다. 우리는 서로 다른 이유로 동일한 결론에 도달하고 있는 것입니다.

전통적인 소프트웨어는 스스로를 설명하지 않으며, 우리는 구현 (implementation)을 조사합니다. 순수 함수 (pure function)는 왜 cpu_saturation을 반환했는지 우리에게 말해주지 않으며, 우리는 그 출력을 생성한 코드를 읽습니다. LLM은 그 관계를 뒤집습니다. LLM은 설명을 쉽게 생성하지만, 그 설명들은 근본적인 연산의 증거라기보다는 그 자체로 모델의 출력물입니다.

서사 (Narration)는 실제로 무엇을 하는가?

이 모든 것이 서사(Narration) 레이어를 무의미하게 만드는 것은 아니며, 단지 그 레이어에 허용된 역할이 정교해지는 것뿐입니다. 모델이 고객 보고서를 위해 작성하는 산문(Prose)이나, 경고(Alert)에 첨부된 평이한 영어 문장은 여전히 확률적(Probabilistic)입니다. 저는 모델이 정확히 무엇을 말했는지는 기록할 수 있습니다. 하지만 왜 어떤 문구를 다른 방식이 아닌 특정 방식으로 표현했는지에 대해 엄격한 근거를 주장할 수는 없습니다. 그러나 그럴 필요도 없습니다. 왜냐하면 그 텍스트는 하중을 견디는 구조물(Load-bearing)이 아니기 때문입니다. 그것은 결정을 설명할 뿐, 결정을 내리지는 않습니다. 만약 내일 당장 서사 레이어가 완전히 사라지더라도, 모든 보고서와 모든 경고는 비록 투박할지언정 여전히 정확한 분류(Classification)를 담고 있을 것입니다. 분류는 산문의 존재 여부에 의존하지 않기 때문입니다.

이것이 경계의 실제 형태입니다.