다른 LLM을 감사하기 위해 LLM을 사용하는 것을 중단하세요: 당신은 프로덕션 지연 시간(Latency)을 망가뜨리고 있습니다

당신의 현대적인 에이전트형 AI (Agentic AI) 스택을 살펴보십시오.

에이전트가 도구(Tool)를 실행하거나, 배포를 트리거하거나, 데이터베이스에 접근하거나, 외부 API를 호출하려고 합니다.

확률론적인 블랙박스 (Probabilistic black box)를 아무도 완전히 신뢰하지 않기 때문에, 많은 팀이 이제 첫 번째 블랙박스를 검증하기 위해 두 번째 확률론적 블랙박스를 사용하고 있습니다.

실제로 어떤 일이 일어나고 있는지 생각해 보십시오.

당신은 수천억 개의 파라미터 (Parameters)를 실행하고, 토큰 (Tokens)을 소비하며, GPU 리소스를 태우고, 단지 다음과 같은 간단한 운영 질문에 답하기 위해 수백 또는 수천 밀리초의 지연 시간 (Latency)을 추가하고 있습니다:

PASS (통과)
HOLD (보류)
RED (중단)

또는 쉬운 영어로:

Continue (계속)
Verify (검증)
Stop (중단)

많은 프로덕션 시스템에서 이것이 유일하게 중요한 결정입니다.

하지만 우리는 종종 액션 자체를 실행하는 것보다, 해당 액션을 실행해야 하는지 결정하는 데 수십 배 더 많은 컴퓨팅 자원을 소비합니다.

이것은 설계적 파산 (Architectural bankruptcy)에 위험할 정도로 근접해 있는 것처럼 느껴집니다.

프롬프트 기반 안전성의 환상

우리 모두 그런 경험이 있습니다.

당신은 다음과 같은 프롬프트 (Prompt)를 만듭니다:

"당신은 보안 검증기입니다. 만약 액션이 안전하지 않아 보인다면, RED를 반환하세요."

그러면 현실이 닥쳐옵니다.

프롬프트 인젝션 (Prompt injections)이 나타납니다.

엣지 케이스 (Edge cases)가 나타납니다.

서로 다른 모델 버전 (Model versions)은 다르게 동작합니다.

동일한 입력이 가끔씩 다른 출력을 생성합니다.

그리고 당신의 클라우드 비용은 계속 늘어납니다.

어느 시점에 어려운 설계적 질문이 떠오릅니다:

확률론적인 시스템이 다른 확률론적인 시스템을 안정적으로 통제할 수 있는가?

많은 팀은 그 답이 '예'라고 가정합니다.

저는 확신하지 못합니다.

문제는 지능이 아닙니다

이 지점이 업계가 문제를 잘못 바라보고 있다고 생각하는 부분입니다.

과제는 지능이 아닙니다.

과제는 거버넌스 (Governance, 통제/관리)입니다.

LLM은 다음과 같은 작업에 탁월합니다:

추론 (Reasoning)
요약 (Summarization)
코드 생성 (Code generation)
자연어 상호작용 (Natural language interaction)

하지만 거버넌스는 다른 문제입니다.

거버넌스는 다음과 같이 묻는 것이 아닙니다:

"가장 좋은 답변은 무엇인가?"

거버넌스는 다음과 같이 묻는 것입니다:

"이 액션이 진행되도록 허용되어야 하는가?"

이것들은 근본적으로 다른 질문입니다.

다른 아키텍처

이 문제를 탐구하는 과정에서, 우리는 내부적으로 별도의 결정론적 거버넌스 계층 (Deterministic Governance Layer)을 구축하게 되었습니다.

이 계층은 텍스트를 생성하는 대신, 구조적 측정 (Structural Measurement)을 수행합니다.

토큰 예측 (Token Prediction) 대신, 운영 동작 (Operational Behavior)을 평가합니다.

문단을 생성하는 대신, 다음과 같은 명확한 결정 경계 (Decision Boundary)를 생성합니다:

PASS (통과)
HOLD (보류)
RED (거부)

이를 실용적으로 구현하기 위해, 아키텍처는 세 가지 결정론적 단계로 분리됩니다:

QRL — 정량화된 리스크 계층 (Quantified Risk Layer)

리스크 노출, 에스컬레이션 잠재력, 그리고 예상되는 운영 영향을 측정합니다.

ACE — 적대적 일관성 엔진 (Adversarial Consistency Engine)

구조적 불일치, 마스킹 패턴, 발산(Divergence), 그리고 충돌 신호를 평가합니다.

DDE — 결정론적 결정 엔진 (Deterministic Decision Engine)

측정된 운영 상태를 최종 포스처 (Posture)로 변환합니다:

PASS (통과)
HOLD (보류)
RED (거부)

흥미로운 점은 구현 방식이 아닙니다.

흥미로운 점은 그 결과입니다.

이 거버넌스 계층은 밀리초 미만(Sub-millisecond)의 지연 시간 (Latency) 내에서 작동하며, 동일한 구조적 입력에 대해 동일한 측정값을 생성합니다.

프롬프트 엔지니어링 (Prompt Engineering)이 필요 없습니다.

토큰 계산 (Token Accounting)도 필요 없습니다.

GPU 의존성도 없습니다.

의미론적 해석 계층 (Semantic Interpretation Layer)도 없습니다.

진짜 논쟁

저는 LLM이 불필요하다고 주장하는 것이 아닙니다.

오히려 그 반대입니다.

LLM은 우리 생애 가장 중요한 기술적 돌파구 중 하나입니다.

문제는 우리가 LLM을 설계 목적에 맞지 않는 문제에 사용하고 있는가 하는 점입니다.

AI 에이전트가 실제 세계의 동작을 실행하기 시작함에 따라, 우리는 다음과 같은 능력을 갖춘 시스템이 필요할 것입니다:

안전하지 않은 진행 방지
운영 경계 강제
부하 상황에서도 예측 가능성 유지
하루 수백만 건의 결정으로 확장 가능

제 추측으로는 미래의 AI 시스템은 순수하게 확률론적 (Probabilistic)이지 않을 것입니다.

그들은 하이브리드 시스템이 될 것입니다.

확률론적 생성 계층 (Probabilistic Generation Layer)과,

결정론적 거버넌스 계층 (Deterministic Governance Layer)의 결합 말입니다.

에이전트 시스템을 구축하는 엔지니어들에게 던지는 질문

만약 당신의 에이전트가 하루에 1,000만 건의 액션을 실행한다면, 당신의 거버넌스 계층은 어떻게 작동합니까?

또 다른 LLM?
규칙(Rules) 및 정규 표현식(regex)?
인간의 검토(Human review)?
전통적인 정책 엔진(Traditional policy engines)?
혹은 완전히 다른 무언가?

저는 진심으로 궁금합니다.

프로덕션 규모의 AI 시스템에서 의미론적 추론(Semantic reasoning)과 결정론적 제어(Deterministic control) 사이의 경계선을 어디에 설정하십니까?

그리고 더 직접적으로 질문하겠습니다:

만약 당신의 에이전트가 하루에 1,000만 건의 액션을 실행한다면, 정말로 또 다른 LLM이 그 모든 액션을 하나하나 승인하도록 신뢰하시겠습니까?

그 이유는 무엇입니까?