소프트웨어 역사의 대부분 동안, 시스템이 예상치 못한 동작을 수행했을 때 우리가 살펴볼 수 있는 익숙한 장소들이 있었습니다.

우리는 애플리케이션 로그 (application logs)를 확인했습니다. 가공되지 않은 HTTP 페이로드 (raw HTTP payload)를 조사했습니다. 분산 트레이싱 (distributed tracing)을 통해 실행 경로를 추적했습니다. 데이터베이스 복제본 (database replica)에 쿼리를 날렸습니다. 배포 차이 (deployment delta)를 살펴보았습니다. 필요하다면, 해당 동작을 유발한 정확한 git 커밋을 찾아내고, 이를 작성한 엔지니어를 식별하며, 실행 환경을 완전히 재구성했습니다.

이 과정은 결코 사소하지 않았습니다. 새벽 3시에 분산 트랜잭션 원장 (distributed transaction ledger)에서 레이스 컨디션 (race condition)을 디버깅해 본 사람이라면 소프트웨어가 얼마나 경이롭고 창의적인 방식으로 실패하는지 알고 있습니다. 그럼에도 불구하고, 소프트웨어 공학의 근본적인 공리 (foundational axiom)는 온전하게 유지되었습니다:

동일한 입력과 동일한 상태가 주어지면, 결정론적 코드 (deterministic code)는 반드시 동일한 결과를 생성해야 한다.

그 가정이 무너지고 있습니다.

소프트웨어가 갑자기 마법처럼 변했기 때문이 아니라, 우리가 결정론적 명령 세트 (deterministic instruction sets)에서 확률적 실행 창 (stochastic execution windows)으로 이동하고 있기 때문입니다. 우리는 런타임 컨텍스트 (runtime context)를 해석하고, 멀티모달 도구 (multi-modal tools)를 평가하며, 동적 데이터 임베딩 (dynamic data embeddings)을 검색하고, 중대한 결과가 따르는 상태 변경 (high-consequence state changes)을 실행하는 에이전트 (agents)를 구축하고 있습니다.

에이전트가 자율적으로 고객 환불을 트리거하기로 결정할 수 있습니다.
실패한 카드 결제에 대해 재시도 회로 (retry circuit)를 우회하기로 선택할 수 있습니다.
중요한 예약 상태 머신 (booking state machine)을 업데이트할 수 있습니다.
...

그리고 그 결정이 틀렸을 때, 즉각적인 사후 분석 (post-mortem) 질문은 명확합니다: 왜 그렇게 했는가?

오늘날 프로덕션에서 실행되는 대부분의 에이전트 시스템은 이 질문에 답할 수 없습니다.

우리는 실행을 감사하는 방법을 알고 있습니다

전통적인 엔터프라이즈 시스템은 명시적이고 검증 가능한 관리 연속성 (chain of custody)을 남깁니다. 표준적인 프로그래밍 방식의 결제 흐름을 생각해 보십시오:

[고객 요청 (Customer Request)] 
       ↓
[API 게이트웨이 / 검증 (API Gateway / Validation)] 
...

결제가 실패하거나 예상치 못한 상태 전이 (state transition)가 발생하면, 우리는 체계적으로 근본 원인을 격리할 수 있습니다:

• 아마도 상위 결제 대행사 (upstream acquirer)가 05 (Do Not Honor)라는 원시 응답 코드 (raw response code)를 반환했을 수 있습니다.
• 아마도 우리의 내부 게이트웨이 매핑 (internal gateway mapping)이 해당 코드를 일시적인 오류 (transient error)가 아닌 영구적인 실패 (permanent failure)로 변환했을 수 있습니다.
• 아마도 Redis 기반의 속도 제한기 (rate-limiter) 또는 특정 기능 플래그 (feature-flag) 토글이 실행 도중 오케스트레이션 경로 (orchestration path)를 변경했을 수 있습니다.

토폴로지 (topology)는 매우 분산되어 있을 수 있지만, 실행 경로 (execution path)는 근본적으로 조사 가능합니다. 우리는 true로 평가된 정확한 코드 분기 (code branch)를 짚어낼 수 있습니다. 이러한 예측 가능성 때문에 업계는 지난 20년 동안 구조화된 로그 (structured logs), OpenTelemetry 트레이스 (traces), 타임 트래블 디버깅 (time-travel debugging), 그리고 불변의 감사 원장 (immutable audit ledgers)과 같은 견고한 관측성 루프 (observability loops)를 구축하는 데 시간을 보냈습니다. 우리가 이 인프라를 구축한 이유는 프로덕션 시스템 (production systems)이 결국 인간에게 스스로를 설명해야 하기 때문입니다.

에이전트는 시스템 토폴로지를 변화시킨다

이제 동일한 결제 실패를 처리하는 자율 에이전트 (autonomous agent)를 생각해 보십시오.

트랜잭션 (transaction)이 중단됩니다. 에이전트는 하드코딩된 재시도 루프 (retry loop) 대신 일련의 도구 세트 (suite of tools)에 대한 접근 권한을 부여받습니다. 에이전트는 벡터 검색 (vector search)을 통해 고객의 생애 상호작용 이력을 검색합니다. 레거시 은행 게이트웨이로부터 전달된 모호한 오류 페이로드 (error payload)의 원시 텍스트를 읽습니다. 동적인 내부 정책 문서를 조회합니다. 그리고 3일 전 약간 다른 지연 시간 (latency) 조건 하에서 유사한 트랜잭션이 성공했다는 사실을 인지합니다.

에이전트는 추가적인 재시도가 불필요한 네트워크 수수료를 발생시키고 상위 카드 속도 제한 (upstream card-velocity block)의 위험이 있다고 추론합니다. 에이전트는 시스템 상태를 PERMANENTLY_FAILED로 변경하고, 내부 CRM을 업데이트하며, 정확한 정책적 이유를 설명하는 사용자 맞춤형 알림 초안을 작성합니다.

아키텍처 흐름 (architectural flow)이 완전히 변합니다:

[Runtime Request]
       ↓
[System Prompt & Identity Instructions]
...

6개월 후 회계 감사 (accounting audit)가 발생했을 때, payment_status = permanently_failed라고 명시된 로그 항목을 보여주는 것은 완전히 무용지물입니다. 인프라는 어떤 상태가 커밋되었는지는 알려줄 수 있지만, 왜 유효한 대안들 대신 그 선택이 이루어졌는지에 대해서는 여전히 완전히 눈이 멀어 있습니다.

프롬프트는 결정 기록(Decision Record)이 아닙니다

흔히 발생하는 아키텍처 안티 패턴(anti-pattern) 중 하나는 시스템 프롬프트(system prompt)와 LLM의 원시 완성문(raw completion)을 로깅하는 것만으로 감사 추적(audit trail)에 충분하다고 가정하는 것입니다. 하지만 이는 충분하지 않습니다.

프롬프트는 매우 유동적인 실행 런타임(execution runtime) 내의 단일 순간을 포착한 스냅샷(snapshot)에 불과합니다. 에이전트가 왜 특정 행동을 취했는지 진정으로 이해하려면, 엔지니어는 전체 **결정 환경(decision environment)**을 재구성해야 합니다. 이를 위해서는 다음과 같은 복잡하게 얽힌 환경 변수들에 대한 답이 필요합니다.

• 모델 계보 (Model Lineage): 정확히 어떤 모델 가중치(weights)와 버전 태그(version tag)가 활성화되어 있었는가? 상위 제공자(upstream provider)의 무언의 업데이트가 프로덕션 엔드포인트(production endpoint)로 라우팅되었는가?
• 컨텍스트 윈도우 상태 (Context Window State): 토큰 예산(token budget)의 정확한 상태는 어떠했는가? 컨텍스트 윈도우(context window) 제한으로 인해 중요한 과거 데이터가 조용히 잘리거나(truncated) 누락되었는가?
• 검색 출처 (Retrieval Provenance): 벡터 데이터베이스(vector database)에서 어떤 특정 청크(chunks)가 추출되었는가? 해당 마이크로초(microsecond) 시점에 존재했던 내부 문서나 정책 파일의 버전은 무엇인가?
• 도구 가용성 (Tool Availability): 해당 정확한 타임스탬프(timestamp)에 어떤 외부 API들이 정상적이었으며 도구 호출 루프(tool-calling loop)에 노출되어 있었는가? 일시적인 네트워크 타임아웃(timeout)으로 인해 검증 도구가 존재하지 않는 것처럼 보였는가?

갑자기 시스템 장애를 재현하는 작업은 HTTP 요청이나 Kafka 이벤트를 재생(replay)하는 것보다 수십 배 더 복잡해집니다. 프롬프트는 단지 정황 증거일 뿐입니다. 그것은 출처(provenance)가 아닙니다.

로그는 실행을 보여줄 뿐, 판단을 보여주지 않습니다

전통적인 관측 가능성(observability) 출력물은 의미론적 의도(semantic intent)가 결여되어 있기 때문에 에이전트적 행동(agentic behavior)을 포착하는 데 실패합니다.

// 전통적인 트레이스 로그 (Traditional Trace Logs)
[INFO] 14:32:11.002 - Agent called tool: read_customer_ledger
[INFO] 14:32:11.450 - Tool returned 200 OK (Balance: €1,240)
...

이러한 항목들은 애플리케이션이 유효한 API 호출을 실행했음을 증명합니다. 하지만 환불이 정당했음을 증명하지는 않습니다.

에이전트가 업로드된 서비스 계약서에서 유효한 계약 조항을 파싱(parsing)했기 때문에 환불을 실행한 것일까요, 아니면 불만 가득한 고객이 채팅 인터페이스에서 높은 긴급성을 나타내는 키워드를 사용하여 정책 예외 사항을 환각(hallucinate)한 것일까요? 만약 환불이 회사의 회계 규칙을 위반한다면, 실행 추적(execution trace)은 아무런 방어 수단이 되지 못합니다. 여러분에게 필요한 것은 어떤 API 경로가 호출되었는지에 대한 로그가 아니라, 에이전트의 판단 기준에 대한 검증 가능한 기록입니다.

의사결정 출처(Decision Provenance)를 위한 엔지니어링

핵심 결제, 예약 워크플로(workflow), 또는 재고 할당과 같은 중요한 경로에서 자율 에이전트(autonomous agents)를 안전하게 실행하려면, 엔지니어링 팀은 **의사결정 출처 (decision provenance)**를 타협할 수 없는 최우선적인 아키텍처 요구 사항으로 취급해야 합니다.

이것이 수천 개의 토큰에 달하는 휘발성 있는 "사고의 사슬 (chain-of-thought)" 추론을 텍스트 파일에 쏟아붓는 것을 의미하지는 않습니다. 모델의 내부 추론은 사후에 신뢰할 수 없게 합리화될 수 있기 때문입니다. 대신, 시스템은 실행 시점에 에이전트가 사용할 수 있었던 정확한 사실과 증거를 구조화된 불변의 매니페스트(manifest) 형태로 출력해야 합니다.

다음은 자동화된 파싱(parsing)과 인간의 감사(auditing)에 최적화된 구조화된 **의사결정 출처 기록 (Decision Provenance Record)**의 예시입니다:

{
  "decision_id": "dec_8f31a2c9",
  "timestamp": "2026-07-05T14:32:11Z",
...

_관찰된 데이터 입력 (observed data inputs)_을 _블랙박스 추론 단계 (black-box inference step)_로부터 분리함으로써, 여러분은 중요한 운영상의 안전장치를 확보할 수 있습니다. 이를 통해 에이전트가 정확하고 최신인 데이터를 기반으로 결정을 내렸는지, 아니면 데이터 검색 레이어(data retrieval layer)가 완전히 실패했는지를 검증할 수 있습니다.

결과에 따른 의사결정 분류

모든 에이전트의 행동에 무거운 포렌식 감사 추적(forensic audit trail)이 필요한 것은 아닙니다. 비핵심적인 워크플로에 대해 과도한 엔지니어링(over-engineering)을 하는 것은 피해야 합니다. 아키텍트는 에이전트의 권한을 계층화하고, 영향 범위(blast radius)의 운영 리스크에 따라 의사결정 출처의 엄격함을 조절해야 합니다.

결과 계층 (Consequence Tier)	대상 워크플로우 (Target Workflows)	출처 요구사항 (Provenance Requirements)
낮은 결과 (Low Consequence)	• 문서 요약 (Document summarization) <br> • 카피라이팅 변형 (Copywriting variations) <br> • 텔레메트리 메트릭 (Telemetry metrics) 서식 지정	• 표준 애플리케이션 로그 (Standard application logs) <br> • 불변 스냅샷 (Immutable snapshotting) 불필요
중간 결과 (Medium Consequence)	• 사용자 프로필 메타데이터 수정 <br> • 호텔 객실 숙박 선호도 조정 <br> • 표준 알림 트리거	• 검색된 컨텍스트 ID (Context IDs)의 휘발성 트레이싱 (Ephemeral tracing) <br> • 요청/응답 상관관계 토큰 (Request/Response correlation tokens)
높은 결과 (High Consequence)	• 자본 이동 / 원장 크레딧 처리 (Moving capital / processing ledger credits) <br> • 라이브 예약 상태 변경 (HOBO 상태 머신) <br> • 시스템 보안 정책 수정	• 완전한 불변 의사결정 출처 기록 (Fully immutable Decision Provenance Records) <br> • 컨텍스트 파일의 암호학적 검증 (Cryptographic validation) <br> • 명시적인 인간 개입 (Human-in-the-loop) 에스컬레이션 경로

다가오는 컴플라이언스(Compliance)의 변화

지금까지 엔터프라이즈 기술 분야의 지배적인 엔지니어링 질문은 다음과 같았습니다: “이 수동 워크플로우를 처리할 수 있는 에이전트를 구축할 수 있는가?”

머지않아, 그 질문은 다음과 같이 바뀔 것입니다: “당신의 에이전트가 왜 그렇게 행동했는지 법적 또는 운영적으로 증명할 수 있는가?”

이러한 요구는 새벽 3시에 고장 난 시스템을 디버깅하는 엔지니어링 리드에게서만 오는 것이 아닙니다. 원장 결손을 조정하려는 재무 관리자(Financial controllers), 금융 규제 기관에 보고하는 컴플라이언스 담당자(Compliance officers), 권한 상승(Privilege escalations)을 추적하는 보안 대응 팀, 그리고 자동화된 시스템 결정에 이의를 제기하는 고객으로부터도 발생할 것입니다.

만약 당신의 프로덕션 스택이 순수하게 표준 API 로깅(API logging)만을 기반으로 구축되어 있다면, 당신은 정확히 _무엇(what)_이 일어났는지는 알 수 있겠지만, 그것이 왜(why) 일어났는지는 전혀 정당화할 수 없는 상태로 남게 될 것입니다.

우리는 버전 관리 (version control), 테스트 파이프라인 (testing pipelines), 배포 감사 (deployment audits)를 사용하여 인간의 코드 변경 사항에 대해 엄격한 책임 구조 (accountability structures)를 구축하는 데 수십 년을 보냈습니다. 소프트웨어가 자율적인 판단 (autonomous judgment)을 할 수 있게 된 순간, 이러한 원칙들을 저버릴 수는 없습니다. 신뢰할 수 있는 차세대 소프트웨어 아키텍처 (software architecture)는 에이전트가 얼마나 똑똑한가가 아니라, 얼마나 투명하게 감사 (audited)될 수 있는가에 의해 정의될 것입니다.