Production-grade AI agents for financial compliance: Lessons from Stripe

🖼️ 인포그래픽

Production-grade AI agents for financial compliance: Lessons from Stripe 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Stripe는 대규모 결제·컴플라이언스 검토에서 사람의 최종 판단을 유지하면서, 작업 분해·ReAct 에이전트·전용 에이전트 서비스·LLM 프록시를 결합해 검토 시간을 줄이고 감사 가능성을 확보한 사례를 제시한다.

📌 핵심 요약

Stripe는 50개국에서 연간 1.4조 달러 규모의 결제를 처리하며, 매일 수천 건의 거래를 검토해야 하는 컴플라이언스 운영 부담을 안고 있었다.
기존 자동화만으로는 판단이 필요한 복잡한 금융 범죄 리스크 검토를 충분히 다루기 어려웠기 때문에, Stripe는 인간 검토자를 중심에 둔 보조형 AI 에이전트 구조를 설계했다.
핵심 설계는 긴 검토를 하나의 거대한 에이전트에게 맡기지 않고, 품질 측정이 가능한 작은 하위 질문들로 나눈 뒤 DAG 형태의 의존관계에 따라 오케스트레이션하는 방식이다.
각 하위 질문에는 ReAct 방식의 에이전트가 관련 신호를 도구 호출로 수집하고, 관찰 결과를 다시 추론에 반영해 최종 보조 답변을 만들지만, 최종 답변과 판단은 인간 검토자가 수행한다.
Stripe는 전통적인 ML 추론 엔진이 에이전트 실행 특성에 맞지 않는다고 보고 전용 에이전트 서비스를 만들었으며, LLM Proxy를 통해 모델 접근, 장애 대응, 사용량 모니터링, 모델 전환을 표준화했다.

🧩 주요 포인트

Stripe는 50개국에서 연간 1.4조 달러 규모의 결제를 처리하며, 매일 수천 건의 거래를 검토해야 하는 컴플라이언스 운영 부담을 안고 있었다.
기존 자동화만으로는 판단이 필요한 복잡한 금융 범죄 리스크 검토를 충분히 다루기 어려웠기 때문에, Stripe는 인간 검토자를 중심에 둔 보조형 AI 에이전트 구조를 설계했다.
핵심 설계는 긴 검토를 하나의 거대한 에이전트에게 맡기지 않고, 품질 측정이 가능한 작은 하위 질문들로 나눈 뒤 DAG 형태의 의존관계에 따라 오케스트레이션하는 방식이다.
각 하위 질문에는 ReAct 방식의 에이전트가 관련 신호를 도구 호출로 수집하고, 관찰 결과를 다시 추론에 반영해 최종 보조 답변을 만들지만, 최종 답변과 판단은 인간 검토자가 수행한다.
Stripe는 전통적인 ML 추론 엔진이 에이전트 실행 특성에 맞지 않는다고 보고 전용 에이전트 서비스를 만들었으며, LLM Proxy를 통해 모델 접근, 장애 대응, 사용량 모니터링, 모델 전환을 표준화했다.

🧠 상세 정리

1. Stripe의 규모와 컴플라이언스 부담

원문은 Stripe가 단순한 결제 API 기업을 넘어 글로벌 경제 인프라의 한 축으로 확장되었다는 배경에서 출발한다. Stripe는 2026년 초 기준 수백만 개 기업을 지원하고, 50개국에서 운영되며, Fortune 500 기업의 62%도 고객으로 포함한다고 설명한다. 연간 결제 처리 규모는 약 1.4조 달러로 제시되며, 이는 전 세계 GDP의 약 1.3%에 해당하는 수준으로 설명된다. 이런 규모에서는 거래의 원활한 처리뿐 아니라 금융 범죄 리스크, 규제 준수, 감사 가능성을 함께 관리해야 하므로 컴플라이언스 검토가 핵심 운영 과제가 된다.

2. 검토 업무가 병목이 된 이유

Stripe의 글로벌 범위가 넓어지면서 컴플라이언스 팀은 인력 증가에 비례하지 않는 방식으로 검토 운영을 확장해야 했다. 원문은 숙련된 분석가들이 고부가가치 위험 평가보다 여러 시스템에 흩어진 문서와 정보를 찾는 데 최대 80%의 시간을 쓰고 있었다고 설명한다. 이는 검토 품질을 유지하면서도 처리량을 늘려야 하는 조직에 큰 병목으로 작용한다. Stripe가 제시한 접근은 AI 에이전트와 자동 오케스트레이션을 결합해 사전 조사와 동적 분석을 보조하고, 동시에 규제기관이 요구하는 정밀성과 감사 가능성을 유지하려는 것이다.

3. 에이전트형 AI를 선택한 이유

원문은 전통적인 자동화가 복잡하고 판단이 필요한 컴플라이언스 업무에는 한계가 있다고 전제한다. 금융 리스크 검토는 단순 규칙 실행이 아니라 상황별 증거 수집, 관련 신호 판단, 후속 질문, 맥락적 해석이 필요하기 때문이다. Stripe는 이런 업무에 대해 에이전트가 보조 조사를 수행하되, 최종 결정을 인간이 내리는 구조를 택했다. 이 구조의 세 축은 인간 중심의 승인과 다층 의사결정 체크포인트, 모든 행동과 판단 근거의 변경 불가능한 감사 기록, 더 빠르고 깊은 검토를 가능하게 하는 효율성이다.

4. 하나의 거대한 에이전트 대신 하위 작업으로 분해

Stripe는 긴 컴플라이언스 검토 전체를 하나의 제약 없는 에이전트에게 맡기면 필요한 부분보다 잘못된 부분에 집중할 위험이 있다고 보았다. 그래서 복잡한 검토를 작고 조합 가능한 하위 작업들로 나누고, 각 하위 작업이 다른 하위 작업의 결과에 의존할 수 있도록 방향성 비순환 그래프 구조로 설계했다. 이런 레일은 품질 테스트를 거친 질문에 대해서만 에이전트 프로세스가 실행되도록 하고, 검토가 반드시 다뤄야 할 기반을 빠뜨리지 않게 한다. 또한 각 에이전트에게 충분히 좁은 맥락과 초점을 제공해 응답 품질을 높이는 역할을 한다.

5. 인간 검토자가 최종 책임을 갖는 오케스트레이션

원문에서 중요한 점은 Stripe가 에이전트의 답변을 그대로 최종 판단으로 사용하지 않는다는 것이다. 각 하위 작업에서 에이전트가 생성한 응답은 인간 검토자에게 보조 정보로 제공되며, 실제로 각 질문에 답하고 다음 단계로 넘기는 책임은 사람에게 남아 있다. 리뷰 도구는 현재 질문과 그 답변을 필요로 하는 후속 질문을 인식하고, 인간이 검토한 답변을 다음 질문의 맥락으로 전달하는 오케스트레이터 역할을 한다. 이 방식은 효율성은 얻되 책임성과 통제권을 잃지 않도록 설계된 구조다.

6. ReAct 에이전트의 작동 방식

각 하위 질문에 필요한 조사를 수행하기 위해 Stripe는 ReAct, 즉 추론과 행동을 반복하는 에이전트 프레임워크를 사용했다. 이 방식에서 모델은 먼저 자신이 답을 알고 있는지 판단하고, 필요하다면 계산기나 데이터베이스 같은 도구를 호출한 뒤, 그 결과를 관찰로 받아 다시 추론한다. 원문은 10을 원주율로 나누는 간단한 예와 다음 해 매출을 예측하는 복잡한 예를 통해, 도구 호출과 해석이 여러 차례 반복될 수 있음을 설명한다. 컴플라이언스 맥락에서는 거의 무한에 가까운 신호 중 어떤 것이 특정 대상에 관련 있는지 에이전트가 판단하고 후속 조사를 제안하는 점이 핵심이다.

7. 도구 호출과 관찰을 통한 폐쇄 루프 제어

ReAct 흐름에서 도구가 요청되면 프레임워크는 모델 실행을 멈추고 실제 도구를 프로그램적으로 실행한 뒤, 그 출력을 관찰로 다시 주입한다. 원문은 이 패턴이 에이전트가 도구 결과를 꾸며내거나 환각하지 못하게 하고, 검색된 정보 하나하나를 명시적으로 인식하고 추론하도록 만든다고 설명한다. 또한 관찰 단계가 체크포인트처럼 작동해 추론이 사실적 도구 출력에 묶여 있도록 돕고, 도구 호출에서 관찰, 다시 추론으로 이어지는 명시적 기록을 남긴다. 이 때문에 해당 구조는 컴플라이언스 검토에서 필요한 감사 가능성과 설명 가능성을 강화한다.

8. 긴 프롬프트와 비용 문제를 다루는 방식

ReAct 방식은 복잡한 과제에서 여러 차례의 사고, 도구 호출, 관찰이 이어지기 때문에 뒤로 갈수록 프롬프트가 길어지는 문제가 생긴다. 특히 관찰 내용이 장황하면 후반 턴에서 입력 토큰이 크게 늘어나며, 원문은 입력 토큰 비용이 주요 비용 동인이라고 설명한다. Stripe는 앞서 설명한 하위 작업 분해로 각 질문의 범위를 제한해 턴 수를 줄이고, 프롬프트 캐싱을 통해 이전 메시지를 반복 과금하지 않도록 했다. 프롬프트 캐싱에서는 매 턴 새로 추가된 관찰과 사고에 대해서만 비용을 지불하게 되므로, 긴 다중 턴 에이전트 실행의 비용을 낮추는 데 도움이 된다.

9. 전용 에이전트 서비스와 LLM Proxy 인프라

Stripe는 처음에는 에이전트를 기존 ML 추론 엔진에 맞추려 했지만, 에이전트 애플리케이션은 전통적인 ML과 실행 특성이 다르다고 판단했다. 전통적 ML은 GPU, 빠른 CPU, 큰 메모리처럼 계산 자원에 묶이는 경우가 많지만, 에이전트는 모델 응답이나 도구 호출을 기다리는 네트워크 지연에 더 크게 좌우된다. 또한 에이전트 실행 시간은 도구 호출 횟수에 따라 길어질 수 있고, 출력 스키마와 상태 유지 요구도 단순 모델 추론보다 유연해야 한다. 그래서 Stripe는 전용 에이전트 서비스를 세웠고, LLM Proxy를 통해 여러 팀의 사용량 경쟁을 제어하며, 단일 API로 다양한 모델·프롬프트 캐싱·도구 호출·모델 대체·모니터링을 관리하도록 했다.

🧾 핵심 주장 / 시사점

이 사례의 핵심은 에이전트를 인간을 대체하는 판정자로 두지 않고, 검토자가 더 빠르고 일관되게 판단하도록 돕는 조사·정리 계층으로 제한했다는 점이다.
복잡한 업무일수록 하나의 범용 에이전트보다 품질을 측정할 수 있는 작은 질문 단위로 분해하고, 의존관계와 검토 책임을 명확히 두는 설계가 중요하다는 점이 드러난다.
프로덕션 환경의 에이전트 시스템은 모델 선택만의 문제가 아니라, 프록시, 전용 실행 서비스, 비용 제어, 감사 로그, 장애 대응, 인간 승인 흐름까지 포함한 운영 아키텍처 문제다.

✅ 액션 아이템

Stripe의 사례처럼 긴 컴플라이언스 점검을 대형 에이전트 대신 하위 질문 DAG로 나눠 단계별로 오케스트레이션하도록 재설계한다.
각 하위 질문 단위에 대해 ReAct 에이전트가 신호 수집 후 관찰 결과를 추론에 반영하는 반복 과정을 표준화하고 품질 지표를 정한다.
최종 판단은 인간 검토자가 수행하고, 모델 접근·장애 대응·사용량 모니터링·모델 전환을 통합하는 LLM Proxy형 전용 에이전트 서비스를 채택한다.