이사회는 RFP(제안요청서)의 최종 결과물을 보고 싶어 합니다. 영수증(결과물)을 보여주세요.

금융 서비스 이사회는 LangChain의 7월 게시물인 금융 서비스에서 에이전트형 AI (agentic AI)의 ROI(투자 대비 수익) 증명하기에서 언급된 것처럼, AI 지출을 통해 무엇을 얻을 수 있는지 알고 싶어 합니다. 에이전트형 RFP 대응, AML(자금세탁방지) 조사, 포트폴리오 관리 워크플로, 그리고 금융 서비스 컴플라이언스(준법 감시) 검토의 경우, 해당 작업은 일반적으로 이러한 금융 업무에 관여하는 문서, 시스템, 승인, 정책 및 사람들을 가로질러 수행됩니다.

총 토큰 사용량이나 업타임(uptime)만을 보여주는 하나의 대시보드로는 충분하지 않습니다.

금융 서비스는 AI의 가치를 의심하는 것만으로도 이미 충분히 스트레스가 많은 분야입니다. 데이터에 따르면: Snowflake의 최근 설문조사에서 생성형 AI를 사용한 금융 서비스 응답자의 68%가 해당 기술로부터 긍정적인 ROI를 정량화할 수 있었다고 답했으며, 30%는 현재 실제 워크플로에서 에이전트형 AI를 사용하고 있습니다. Moody's는 Research Assistant 사용자가 연구량을 60% 더 많이 소비하고 작업 완료 시간을 30% 단축한다고 밝혔습니다. 그 결과, 금융 서비스 분야에서 에이전트형 AI는 단순한 신기함(novelty)의 범주를 벗어나 가치를 증명해야 하는 본격적인 단계로 진입하고 있습니다.

어려운 점은 바로 증명입니다.

에이전트형 AI ROI는 작업 결과물(work receipts)에서 시작됩니다

팀이 "잘못된" 단위를 측정하기 시작하는 즉시 에이전트형 AI의 ROI는 명확한 상태에서 모호한 상태로 빠르게 변합니다. 지출은 가치가 아닙니다. 프롬프트(Prompt)는 작업이 아닙니다. 단순한 월간 사용량 그래프는 활동을 증명할 뿐입니다. 그것은 이사회 보고용 자료를 더 좋게 만들기 위한 것입니다. (매우 낮은 기준입니다).

측정 단위는 완료된 작업 항목(completed work item)이어야 합니다.

RFP(제안요청서) 답변 섹션은 하나의 작업 항목 (work item)입니다. AML(자금세탁방지) 경고 처분은 하나의 작업 항목입니다. KYC(고객확인제도) 예외 패키지는 하나의 작업 항목입니다. 리스크 메모 갱신은 입력 데이터, 담당 에이전트, 도구 호출 (tool calls), 모델 비용, 인간의 승인, 정책 점검, 다운스트림 객체로의 쓰기 등을 포함하는 하나의 작업 항목이며, 일련의 검토를 거쳐 해당 항목에 대한 결과물, 즉 에이전트 작업의 최종 결과에 도달할 때까지 이어집니다. 이 최종 결과물은 재무 부서를 위한 일련의 영수증 (receipts, 평가(evals), 추적(traces) 등)을 가집니다. 에이전트의 도구를 통해 작업 항목이 실행될 때마다 하나 이상의 이러한 최종 결과 영수증이 생성됩니다.

그것이 바로 영수증입니다.

이는 기업용 AI 에이전트를 런타임 제품으로 보는 연구에 대한 이전 작업과 연결됩니다. 재무 부서가 작업 항목별 증거를 원한다면 동일한 소유권이 있는 경계 (owned boundary)가 필요합니다.

LangChain의 금융 부문은 RFP 처리와 AML 컴플라이언스 모니터링을 에이전트 활용 사례 (agentic use cases)로 명시하며, ROI (투자 대비 수익)를 동일한 스택 내의 관측 가능성 (observability), 거버넌스 (governance), 경제적 측정과 연결합니다. 운영상의 규율은 모든 의미 있는 실행이 수행될 때 영수증을 남기도록 만드는 것입니다.

Architecture diagram showing a financial services agent request flowing through an agent runtime into tools, databases, traces, side-effect receipts, a runtime ledger, and an evidence-backed KPI packet.

ROI 증거는 사후에 스프레드시트로 작성하는 것이 아니라, 에이전트가 실행되는 동안 조립됩니다.

런타임은 영수증이 작성되는 곳입니다

라이브 에이전트가 실행하는 모든 것은 이미 런타임 (runtime)에서 완전히 파악되고 있습니다. 따라서 이 모든 것을 엔지니어링 도구 내부에 숨기는 것은 스스로 상처를 내는 격입니다.

실제 업무를 처리하는 에이전트 런타임 (runtime)은 어시스턴트 (assistant), 스레드 (thread), 런 (run), 입력 (input), 도구 (tools), 재시도 (retries), 비용 (costs), 중단 (interrupts), 스트림 이벤트 (stream events), 그리고 최종 상태 (final state)를 파악하고 있습니다. LangSmith Deployment는 어시스턴트, 스레드, 런을 중심으로 한 에이전트 서버 실행 모델을 설명하며, 에이전트 워크로드에 대해 내구성이 있는 실행 (durable execution), 실시간 스트리밍 (real-time streaming), 그리고 수평적 확장 (horizontal scaling)을 제공합니다. 백그라운드 실행 (background-run) API는 메타데이터 (metadata), 컨텍스트 (context), 웹훅 (webhooks), 피드백 키 (feedback keys), 스트림 모드 (stream modes), 그리고 내구성 설정 (durability settings)을 수용합니다. 이는 작업이 트레이스 (trace) 검색 화면 속으로 사라지기 전에 비즈니스 컨텍스트 (business context)를 결합할 수 있는 충분한 접점 (surface area)을 제공합니다.

런 (run)에 대한 영수증 (receipt)은 런이 생성되는 순간 이전에(즉, 해당 런의 실행 과정에서 첫 번째 도구가 호출되기 전에) 생성되어야 합니다.

런에 작업 유형 (task type)을 할당하고, 비즈니스 객체 (business object), 비용 센터 (cost center), 정책 (policy), 예상 출력 계약 (expected output contract), 검토자 큐 (reviewer queue), 그리고 부수 효과 (side effects)가 기록될 다운스트림 시스템 (downstream system)을 연결하십시오. 그러면 런타임은 작업이 완료됨에 따라 영수증을 업데이트할 수 있습니다.

금융 분야의 AI 에이전트에게 있어, 이 영수증은 제어 표면 (control surface)이 됩니다.

금융, 리스크, 엔지니어링 부서가 읽을 수 있는 영수증

런타임 영수증은 의도적으로 지루하게 설계되었습니다.

모든 것이 기록되며, 이는 설계 단계부터 지루하도록 만들어졌습니다. 여기에는 런 ID (run ID), 스레드 ID (thread ID), 작업 (task), 액세스된 데이터 (data accessed), 도구 호출 (tool calls), 실행을 위한 모델+토큰 비용 (model+token cost), 실행 지연 시간 (latency), 재시도 (retries), 승인 (approvals) (및 모든 부수 효과 영수증), 평가자 점수 (evaluator score)와 검토자 결과 (reviewer's result), 그리고 비즈니스 결과 (business outcomes)가 포함됩니다. RFP 섹션의 경우, SME (전문가)의 내용 재작성 여부에 따라 수락할지 여부를 알 수 있습니다. AML (자금세탁방지) 경보의 경우, 에스컬레이션(escalated)되거나 종결되거나, 또는 인간의 검토를 위해 반환됩니다. 리서치 메모의 경우, 인용되거나, 거부되거나, 또는 재작성될 수 있습니다.

Per-run receipt card listing run ID, thread ID, task type, model cost, latency, data touched, tool calls, approvals, side effects, evaluator score, and business outcome.

영수증(Receipt)은 트레이스(Trace)를 금융, 리스크, 엔지니어링 부서가 모두 읽을 수 있는 증거로 변환합니다.

엔지니어링(Engineering) 측면에서는 디버깅 증거가 되고, 리스크(Risk) 측면에서는 권한 및 데이터 계보(Data Lineage)가 되며, 금융(Finance) 측면에서는 수락된 작업 항목당 비용이 되고, 제품(Product) 측면에서는 결과와 결합된 채택률(Adoption)이 됩니다. 이 영수증은 각 팀의 서로 다른 질문에 답을 제공하며, 각 팀이 상황이 얼마나 잘 돌아가고 있는지에 대해 저마다의 "진실"을 만들어내도록 강요하지 않습니다.

Honeycomb은 과거에 관측성(Observability)에 대해 유사한 관찰을 한 바 있습니다. 그들이 기술적 신호를 비즈니스 결과와 연결해야 한다고 언급했듯이, 가동 시간(Uptime), 평균 복구 시간(MTTR), 엔지니어링 생산성만으로는 비즈니스가 시스템으로부터 얻는 가치를 자동으로 측정할 수 없기 때문입니다. AI는 이미 상당한 이 장벽을 더욱 높입니다. 모델이 건강하거나 서비스가 가동 중이라는 사실만으로는, 이를 사용하는 에이전트가 시간과 비용을 생산적으로 사용하거나, 심지어 아예 사용을 하고 있는지조차 보장하기에 전혀 충분하지 않기 때문입니다.

AI 에이전트 비용은 런타임 신호(Runtime Signal)이며, 여기서 유용한 질문은 에이전트의 작업 항목을 재현(Replay)하고, 판단하고, 설명할 수 있으며, 비즈니스 결과와 연결할 수 있는지 여부입니다.

집계 대시보드는 너무 늦습니다

집계 대시보드는 팀별 지출, 평균 지연 시간(Latency), 총 실행 횟수, 오류율, 상위 에이전트, 모델별 비용, 채택 트렌드 등을 보여줍니다. 이러한 지표는 유지하고 자랑할 만한 가치가 있지만, 설계상 너무 늦습니다. 즉, 규제 준수(Compliance)가 민감한 단일 작업의 가치를 증명하는 데 사용할 수 없습니다.

평균값은 중요한 세부 사항을 숨깁니다. 특히 개별적인 고비용 실행이나 높은 채택률로 인해 발생하는 비용이 많이 드는 재작업(Rework)의 경우 더욱 그렇습니다. 비용이 많이 드는 실행은 심층적으로 조사할 가치가 있을 수 있습니다. 반면 저렴한 실행은 쓰레기 데이터일 수 있습니다. 채택률이 높은 에이전트는 재작업을 유발할 수 있는 반면, 채택률이 낮은 에이전트가 기업에 가장 위험한 작업을 수행하고 있는 것일 수도 있습니다.

영수증은 이러한 집계(Rollup)가 의미를 갖게 만드는 핵심 요소입니다.

OpenTelemetry의 졸업 포스트는 읽어볼 가치가 있습니다. 비록 이것이 텔레메트리 (Telemetry)의 미래와 현재의 벤더 종속 (Vendor lock-in)으로부터 이를 어떻게 추상화할 것인가에 대한 이야기임에도 불구하고, 현재의 현실에 확고하게 뿌리를 두고 있습니다. OpenTelemetry는 CNCF의 졸업 (Graduated) 프로젝트이며, 메인테이너들은 에이전트 워크플로우 (Agentic workflows, 워크플로우 매니저 내에서 워크플로우를 실행하는 것) 내에서의 에이전트 실행 (프로세스 또는 컨테이너 실행), 그리고 GenAI 시맨틱 컨벤션 (Semantic conventions, 현재 AI에서 사용되고 있으며 향후 사용될 것으로 예상되는 방식)이 OTel이 처리할 수 있는 미래의 워크로드라고 지적합니다. 따라서, 실행 결과가 생성한 영수증 증거는 에이전트가 실행 중인 모든 큐 (Queues), 데이터베이스 (Databases), ID 제공자 (Identity providers), SaaS API, 그리고 코드 리뷰 워크플로우 (Code review workflows) 사이를 이동할 수 있어야 합니다. 영수증은 특정 벤더의 독점적인 어휘에 갇혀 있어서는 안 됩니다.

에이전트 작업량은 측정을 아키텍처로 변화시킨다

업무 운영의 정기적인 부분으로서 에이전트에게 작업을 위임하는 것은 이제 실험실의 산물이 아닌 운영 규모 (Operating volume)가 되고 있습니다. 최근의 Codex 사용 논문에 따르면 2026년 상반기에 활성 사용자 수가 5배 이상 증가했다고 보고되었습니다. 또한, 현재 활발한 업무 중에 언제나 3개 이상의 에이전트를 관리하는 사용자가 10%를 넘어섰으며, 코딩 및 기타 지식 업무를 위한 Codex 사용 시 스킬 (Skills)을 사용하는 사용자가 26.6%에 달합니다.

병렬 실행 (Parallel execution)은 일상적인 측정을 불가능하게 만듭니다.

런타임(Runtime)은 어떤 작업 항목이 현재 활성 상태인지, 어떤 항목이 승인을 대기 중인지, 어떤 항목이 고객 데이터를 처리했는지, 어떤 항목이 후속 작업을 트리거했는지, 어떤 항목이 비용 한도를 초과했는지, 그리고 어떤 항목이 부수 효과(Side effects)를 발생시켰는지를 알아야 합니다. 최근의 무한 에이전트 루프(infinite-agent-loop)에 관한 논문은 47개 프로젝트에서 68건의 확인된 실패를 발견했습니다. 이러한 모든 실패는 비용 고갈, 컨텍스트 성장(Context growth), 모델 서비스 거부(Model denial of service), 또는 반복적인 외부 부수 효과를 유발할 수 있으며, 이는 에이전트의 반복(Iterations)과 권한이 시스템의 런타임 동작 관찰 능력을 앞지르기 때문에 발생합니다.

Agent libOS 논문은 시스템의 형태를 정확하게 짚어내고 있습니다. 장기 실행되는 에이전트에는 프로세스 식별자(Process identity), 부모-자식 계보(Parent-child lineage), 생명주기 상태(Lifecycle state), 명시적 권한(Explicit capabilities), 인간 대기열(Human queues), 체크포인트(Checkpoints), 이벤트(Events), 그리고 감사 기록(Audit records)이 필요합니다. 금융 서비스 용어로 바꾸면 이는 식별(Identity), 권한(Authority), 상태(State), 승인(Approval), 증거(Evidence), 그리고 책임(Accountability)이 됩니다.

자금 이동과 마찬가지로, 지출 권한은 런타임으로 이동하며, 따라서 지갑이 토큰 지출에 서명하기 전에 정책, 승인, 영수증(Receipts), 그리고 권한 취소(Revocation)가 반드시 고려되어야 합니다. 런타임은 단순히 토큰을 지출하고 나중에 재무 부서가 그 가치를 재구성하기를 바라서는 안 됩니다.

반복되는 작업은 측정 가능한 경로가 되어야 합니다

금융 에이전트의 첫 번째 버전은 탐색적인 형태입니다. 에이전트는 다양한 도구를 시도하고, 여기저기서 더 많은 정보를 요청하며, 평가(Evals)에 실패하고(이를 통해 복구할 수 있음), 승인을 요청하며, 그 과정에서 어떤 경로가 최선인지 학습할 것입니다.

그 후, 반복되는 경로들은 견고해져야(Harden) 합니다.

매주 진행되는 RFP(제안요청서) 프로세스는 영원히 느슨한 에이전트 루프 안에 머물러 있어서는 안 되는 작업입니다. 이는 요구사항 추출, 승인된 콘텐츠 검색, 답변, 인용, 전문가(SME) 검토, 그리고 패키징의 과정입니다. 그리고 이러한 과정은 (모호함이 존재하는 지점이 있더라도) 잘 정의된 게이트(Gates)를 가진 잘 정의된 프로세스가 되어야 합니다.

이것이 바로 에이전트 워크플로가 덜 에이전트적이어야 하는 이유입니다. 에이전트 워크플로(Agentic workflow)의 반복되는 동작은 관찰 가능하고(observable), 실행 가능하며(doable), 판독 가능한(legible) 실행 경로로 변환되어야 합니다 (그리고 현실이 다시 변하는 즉시 다시 에이전트적 성격을 유지해야 합니다). 마찬가지로 금융 에이전트의 투자 대비 효과(ROI)는 단순히 더 에이전트적이 된다고 해서 성장하는 것이 아니라, 에이전트의 작업이 먼저 발견되고, 기록되고, 측정된 다음, 견고해질 때(hardened) 함께 성장합니다.

그리고, 부수 효과(side-effect) 계층입니다. 이전에 작성했듯이, 다양한 도구들이 라이브 시스템을 업데이트하기 위해 실행되면서 부수 효과를 일으키는 작업을 오케스트레이션(orchestrating)할 때, 재시도(retry), 보상(compensation), 소유권 추적(ownership tracking)과 같은 기능을 활성화하려면 부수 효과 영수증(side-effect receipts)이 매우 중요합니다. 금융 에이전트의 경우, 이는 CRM 레코드 업데이트, 문서 요청, 새로운 케이스 작업 생성, 고객용 초안 생성, 새로운 컴플라이언스(compliance) 작업 개시 등을 포함하며, 이 모든 작업은 작업 키(operation key)와 함께 발행되어야 하고 그에 상응하는 영수증(receipt)을 받아야 합니다.