주장보다 증거가 우선이다: AI 에이전트에게 런타임 증거(Runtime Proof)가 필요한 이유

AI 에이전트가 _"했습니다"_라고 말하는 것은 어떤 일이 실제로 일어났다는 증거가 아닙니다.

"이메일을 보냈습니다."

"데이터베이스를 업데이트했습니다."

"이슈를 에스컬레이션(Escalate)했습니다."

"포스트를 게시했습니다."

이것들은 모두 주장(Claims)입니다.

실제 운영(Production) 시스템에서 주장만으로는 충분하지 않습니다.

만약 AI 에이전트가 사용자, 데이터, 자금, 운영 또는 다른 시스템에 영향을 미치는 작업을 수행한다면, 런타임(Runtime)은 실제로 어떤 일이 일어났는지 증명할 수 있어야 합니다.

문제점

언어 모델(Language Models)은 자신감 넘치는 완료 문장을 생성하는 데 매우 능숙합니다.

그러한 자신감은 대화에서는 유용할 수 있지만, 인프라(Infrastructure)에서는 위험할 수 있습니다.

모델은 다음과 같이 말할 수 있습니다:

"완료되었습니다, 이메일을 보냈습니다."

하지만 실제로 어떤 일이 일어났을까요?

이메일 도구(Email tool)가 성공했을 수도 있습니다.

권한 확인(Permission check)이 실패했을 수도 있습니다.

API가 타임아웃(Timeout)되었을 수도 있습니다.

재시도 제한(Retry limit)에 도달했을 수도 있습니다.

도구가 호출조차 되지 않았을 수도 있습니다.

모델이 대화 흐름상 가장 자연스러운 응답이기 때문에 단지 동작이 수행되었다고 가정했을 수도 있습니다.

이것이 데모(Demo)와 운영(Production) AI 시스템 사이의 가장 중요한 차이점 중 하나입니다.

데모에서는 에이전트가 _"완료되었습니다"_라고 말하는 것이 인상적으로 느껴집니다.

하지만 운영 환경에서 _"완료되었습니다"_는 증거(Evidence)가 필요합니다.

모델의 주장 vs 런타임 증거

모델의 주장(Model claim)은 AI가 일어났다고 말하는 내용입니다.

런타임 증거(Runtime evidence)는 시스템이 일어났음을 증명할 수 있는 내용입니다.

이 둘은 같은 것이 아닙니다.

진지한 AI 에이전트 시스템은 이 둘을 명확하게 분리해야 합니다.

예를 들어:

const response = await agent.run("Send the customer follow-up email");

// 이것은 단지 모델이 생성한 주장일 뿐입니다
...

그 메시지만으로는 충분하지 않습니다.

운영 시스템은 또한 다음과 같은 런타임 기록(Runtime record)을 가지고 있어야 합니다:

{
  "actor": "support-agent-01",
  "tool": "send_email",
...

이제 시스템은 다음 질문에 답할 수 있습니다:

누가 작업을 요청했는가
어떤 도구가 실행되었는가
권한이 부여되었는가
어떤 입력값이 사용되었는가
어떤 결과가 돌아왔는가
언제 발생했는가
어떤 감사 기록(Audit record)이 이를 증명하는가

이것이 텍스트를 신뢰하는 것과 인프라를 신뢰하는 것의 차이입니다.

이것이 중요한 이유

AI 에이전트(AI agents)는 채팅 인터페이스를 넘어 실제 워크플로(workflows)로 이동하고 있습니다.

이제 에이전트는 단순히 질문에 답하는 것에 그치지 않습니다.

에이전트는 다음과 같은 일을 수행합니다:

메시지 전송
티켓 생성
레코드 업데이트
API 호출
고객 데이터 읽기
워크플로 트리거
인시던트(incidents) 에스컬레이션
보고서 생성

에이전트가 실제 업무를 수행하게 되면, 조직에는 유창한 응답 그 이상의 것이 필요합니다.

그들에게는 책임성(accountability)이 필요합니다.

만약 에이전트가 레코드를 업데이트했다고 말한다면, 시스템은 해당 레코드가 실제로 업데이트되었음을 증명해야 합니다.

만약 에이전트가 불만을 에스컬레이션했다고 말한다면, 시스템은 에스컬레이션이 실제로 발생했음을 증명해야 합니다.

만약 에이전트가 메시지를 보냈다고 말한다면, 시스템은 메시지가 실제로 전송되었음을 증명해야 합니다.

그렇지 않다면, 조직은 증거(evidence)가 아닌 모델의 확신(model confidence)을 바탕으로 운영되는 것입니다.

위험한 실패 모드 (The Dangerous Failure Mode)

위험한 실패 모드가 항상 요란한 충돌로 나타나는 것은 아닙니다.

때때로 에이전트는 단순히 다음과 같이 말합니다:

"완료되었습니다."

그리고 모두가 이를 믿습니다.

하지만 막후에서는 다음과 같은 일이 벌어지고 있을 수 있습니다:

도구(tool)가 실패함
권한이 거부됨
페이로드(payload)가 유효하지 않음
API가 에러를 반환함
작업이 실행되지 않음
워크플로가 중간에 중단됨

이는 잘못된 완료감을 조성합니다.

사용자는 작업이 끝났다고 생각합니다.

에이전트는 작업이 끝났다고 생각합니다.

조직은 작업이 끝난 것처럼 행동합니다.

하지만 런타임(runtime)에는 해당 작업이 실제로 일어났다는 증거가 없습니다.

이것은 심각한 신뢰성(reliability) 문제입니다.

멀티 에이전트 시스템(Multi-Agent Systems)은 이를 악화시킨다

이 문제는 멀티 에이전트 시스템(Multi-Agent Systems, MAS)에서 더욱 위험해집니다.

다음과 같은 흐름을 상상해 보십시오:

에이전트 A가 고객 데이터를 수집했다고 말합니다.
에이전트 B가 그 주장을 바탕으로 답변 초안을 작성합니다.
에이전트 C가 답변을 전송합니다.
에이전트 D가 해당 케이스를 해결된 것으로 요약합니다.

만약 에이전트 A의 주장이 근거가 없었다면, 전체 체인(chain)은 신뢰할 수 없게 됩니다.

근거 없는 하나의 주장이 다른 에이전트의 입력값(input)이 됩니다.

오류가 시스템 전체로 전파됩니다.

결국 최종 결과물은 일관성 있어 보일지 모르지만, 그 토대는 잘못되어 있습니다.

이것이 바로 멀티 에이전트 시스템 (Multi-Agent Systems)이 모든 중요한 경계(boundary)에서 런타임 증거 (runtime evidence)를 필요로 하는 이유입니다.

에이전트는 근거 없는 주장 (unsupported claims)을 마치 사실인 것처럼 전달해서는 안 됩니다.

에이전트는 증거와 연결된 주장만을 전달해야 합니다.

아키텍처 패턴 (The Architecture Pattern)

더 나은 아키텍처는 다음 세 가지를 분리합니다:

추론 (Reasoning)
실행 (Execution)
증거 (Evidence)

AI 에이전트는 무엇이 일어나야 하는지에 대해 추론 (reasoning)합니다.

런타임 (runtime)은 허용된 경우에만 동작을 실행 (executes)합니다.

시스템은 실제로 무엇이 일어났는지에 대한 증거 (evidence)를 기록합니다.

const request = await agent.decideNextAction(context);

const permission = runtime.permissions.verify(request);
...

모델은 여전히 사용자에게 결과를 설명할 수 있습니다.

하지만 이제 그 설명은 런타임 증거 (runtime evidence)에 기반을 둡니다.

에이전트는 더 이상 다음과 같이 말하지 않습니다:

"나를 믿으세요."

대신 다음과 같이 말합니다:

"무엇이 일어났는지 여기 있으며, 여기 그 증거가 있습니다."

런타임 증거에 포함되어야 할 사항

최소한, 증거 기록 (evidence record)은 다음을 캡처해야 합니다:

행위자 식별 정보 (actor identity)
요청된 동작 (requested action)
권한 확인 결과 (permission result)
사용된 도구 또는 워크플로우 (tool or workflow used)
입력 페이로드 (input payload)
실행 결과 (execution result)
타임스탬프 (timestamps)
실패 원인 (failure reason, 있는 경우)
재시도 횟수 (retry attempts)
감사/참조 ID (audit/reference ID)

민감한 시스템의 경우, 다음을 포함할 수도 있습니다:

승인 기록 (approval record)
정책 버전 (policy version)
리소스 식별자 (resource identifier)
제공자 응답 메타데이터 (provider response metadata)
검증 결과 (verification result)
인간 검토 상태 (human review state)

목표는 관료주의를 만드는 것이 아닙니다.

목표는 AI가 검사 가능하고 (inspectable), 디버깅 가능하며 (debuggable), 신뢰할 수 있게 (trustworthy) 만드는 것입니다.

규칙 (The Rule)

프로덕션 AI 시스템을 위한 간단한 규칙:

만약 에이전트가 외부 동작이 발생했다고 주장한다면, 런타임은 증거를 가지고 있어야 한다.

증거가 없다는 것은 그 주장이 근거가 없음을 (unsupported) 의미합니다.

반드시 거짓이라는 뜻은 아닙니다.

하지만 근거가 없습니다.

그 차이가 중요합니다.

근거 없는 주장은 완료된 작업으로 취급되어서는 안 됩니다.

이는 다음 세 가지 결과 중 하나를 트리거해야 합니다:

재시도 (retry)
검증 (verify)
에스컬레이션 (escalate)

이것이 AI 시스템이 운영 측면에서 신뢰할 수 있게 (operationally reliable) 되는 방법입니다.

챗봇에서 조직적 AI 시스템으로 (From Chatbots To Organizational AI Systems)

챗봇은 주장만으로도 넘어갈 수 있습니다.

조직적 AI 시스템 (Organizational AI Systems)은 그럴 수 없습니다.

AI 에이전트가 실제 조직 내부에서 작동할 때, 다음과 같은 요소들이 필요합니다:

권한 (permissions)
실행 경계 (execution boundaries)
감사 추적 (audit trails)
검증 게이트 (verification gates)
런타임 증거 (runtime evidence)
인간 에스컬레이션 경로 (human escalation paths)

우리가 에이전트에게 더 많은 책임을 부여할수록, 증거는 더욱 중요해집니다.

확신에 찬 답변만으로는 충분하지 않습니다.

유창한 요약만으로는 충분하지 않습니다.

완료된 것처럼 보이는 워크플로우(workflow)만으로는 충분하지 않습니다.

시스템은 실제로 어떤 일이 일어났는지 증명할 수 있어야 합니다.

결론

AI 에이전트는 추론(reason)해야 합니다.

런타임(Runtimes)은 실행(execute)해야 합니다.

증거는 증명(prove)해야 합니다.

그러한 분리가 에이전트의 동작을 단순한 대화에서 인프라(infrastructure)로 전환시킵니다.

만약 우리가 AI 에이전트가 실제 조직 내부에서 작동하기를 원한다면, 모델이 생성한 주장을 완료된 작업의 증거로 취급하는 것을 멈춰야 합니다.

증거는 주장보다 강력합니다.