전체 사례No. 008
bunq 라우터 병목을 깨고 에이전트 도구화로 고객 지원 97%를 처리한 유럽 네오뱅크
- 사례 번호
- 008
- 1차 출처
- AWS Machine Learning Blog
- 원문 게시
- 2026-01-21
1. 왜 이 사례인가
금융 및 핀테크 산업에서 고객 지원 자동화는 가장 매력적이면서도 가장 진입 장벽이 높은 영역입니다. 사소한 응답 오류나 환각이 금융 사고, 규제 위반, 고객 신뢰 상실로 직결되기 때문입니다. 많은 은행들이 단순 시나리오 기반 챗봇을 도입하지만, 복잡한 거래 분쟁이나 계좌 관리 요청이 들어오면 곧바로 인간 상담원에게 에스컬레이션되어 병목을 해소하지 못합니다.
유럽 2위의 네오뱅크인 붕크(bunq)가 AWS 머신러닝 블로그(2026년 1월 21일)를 통해 공개한 자사 생성형 AI 어시스턴트 ‘핀(Finn)‘의 멀티 에이전트 전환 사례는, 엔터프라이즈 규모에서 에이전트 시스템이 어떻게 라우팅 복잡성을 극복하고 확장성을 확보했는지를 명확히 보여줍니다. 2,000만 명의 유럽 고객을 보유한 bunq는 계좌 관리, 거래 분쟁, 환불 요청, 금융 조언에 이르는 전 과정을 에이전트에게 맡겼습니다.
공개된 성과는 압도적입니다. bunq의 독자 AI 어시스턴트 Finn은 현재 전체 고객 지원 업무의 97%를 처리하고 있으며, 이 중 70%~82%는 사람의 개입 없이 완전히 자동 완결(fully automated)됩니다. 평균 고객 응답 시간은 47초로 단축되었고, 38개 언어에 대한 앱 내 번역과 전 세계 은행권 최초의 지원팀 실시간 음성 대 음성(Speech-to-Speech) 통역을 지원하고 있습니다.
이 사례의 핵심 가치는 화려한 수치 이면에 있는 아키텍처 혁신에 있습니다. 초기 중앙 라우터 방식에서 발생한 단일 장애점과 확장성 한계를 인정하고, 3~5개의 프라이머리 에이전트가 특화 하위 에이전트를 도구(Tool)로 동적 호출하는 ‘에이전트 도구화(Agent-as-Tool)’ 패턴으로 재설계함으로써 3개월 만에 컨셉에서 프로덕션 상용화까지 도달했습니다.
2. Problem
2,000만 명의 다국적 사용자를 지원하는 bunq의 기술 조직이 직면했던 기술적·운영적 난관은 크게 세 가지였습니다.
2.1 금융 규제 준수와 즉시 응대 요구의 충돌
금융 서비스 특성상 고객은 결제 실패, 카드 도용 분쟁, 긴급 환불 등에 대해 24시간 365일 지연 없는 실시간 응대를 요구합니다. 그러나 금융 상품의 복잡성과 엄격한 개인정보보호(GDPR) 및 금융 보안 규제로 인해, 기존 규칙 기반 챗봇은 복합적인 금융 컨텍스트를 소화하지 못하고 대부분의 티켓을 수동 상담원 큐로 넘겼습니다. 이로 인해 상담 인력에 심각한 부하가 걸리고 고객 대기 시간이 길어졌습니다.
2.2 초기 중앙 라우터 아키텍처의 한계와 병목
bunq는 초기에 중앙 라우터 에이전트가 사용자 질문을 분석해 기술 지원, 일반 문의, 거래 상태, 계좌 관리 등 도메인별 특화 서브 에이전트로 전달하는 전형적인 계층형 라우터 패턴을 구축했습니다. 그러나 시스템이 커지면서 치명적인 세 가지 문제가 드러났습니다.
- 라우팅 복잡성 폭증: 특화 에이전트 수가 늘어날수록 중앙 라우터가 최종 목적지를 결정하기 위한 분류 로직이 기하급수적으로 복잡해졌습니다.
- 역할 및 데이터 소스 중복: 여러 하위 에이전트가 동일한 거래 내역이나 사용자 프로필 데이터에 접근해야 했기에, 라우터가 1차 의도뿐 아니라 후속으로 필요할 2차, 3차 에이전트까지 사전에 예측해야 하는 불가능한 과제에 직면했습니다.
- 확장성 병목과 단일 장애점: 새로운 기능이나 전용 에이전트를 추가할 때마다 중앙 라우터 로직을 수정하고 전면 재검증해야 했습니다. 중앙 라우터가 배포와 성능의 단일 장애점(SPOF)으로 전락했습니다.
2.3 다국어 및 실시간 지원의 기술적 장벽
유럽 전역 38개 언어를 구사하는 다국적 사용자들을 대상으로 문맥이 통하는 고품질 금융 지원을 제공하고, 음성 통화 시 실시간으로 통역을 지원하는 인프라를 지연 시간(latency) 없이 구축해야 했습니다.
3. Solution
bunq는 Amazon Bedrock과 완전 관리형 AWS 서비스를 활용해, 기존 중앙 라우터를 걷어내고 에이전트 도구화(Agent-as-Tool) 기반의 오케스트레이터 패턴으로 전면 재설계했습니다.
3.1 오케스트레이터와 에이전트 도구화(Agent-as-Tool) 패턴
중앙 라우터가 모든 경로를 예측하던 방식에서 벗어나, 상위 에이전트가 필요에 따라 특화 에이전트를 함수나 도구처럼 호출하는 구조를 도입했습니다.
- 오케스트레이터 간소화: Amazon ECS 위에서 구동되는 중앙 오케스트레이터는 사용자 쿼리를 모든 하위 에이전트로 분기하지 않고, 핵심 도메인을 대표하는 3~5개의 프라이머리 에이전트(Primary Agent)로만 라우팅합니다.
- 에이전트가 에이전트를 도구로 호출: 프라이머리 에이전트는 결제 실패나 거래 분석 등 특정 전문 지식이 필요하다고 판단하면, 사전에 정의된 표준 인터페이스를 통해 특화 서브 에이전트(Specialized Agent)를 직접 도구(Tool)로 동적 호출합니다.
- 예를 들어 결제 실패를 문의한 고객에 대해 프라이머리 에이전트가 쿼리를 접수하고, 거래 로그 분석 특화 에이전트를 호출해 원인을 조회한 뒤, 환불 규정 검색 에이전트를 호출해 통합된 답변을 수초 내에 구성합니다.
3.2 Amazon Bedrock 기반의 엔터프라이즈 보안 및 하이브리드 모델 스택
금융권의 엄격한 보안과 컴플라이언스 기준을 만족하기 위해 관리형 생성형 AI 플랫폼을 활용했습니다.
- Amazon Bedrock & Anthropic Claude: 단일 통합 API를 통해 Anthropic Claude 모델을 안전한 VPC 내에서 호출하여 복잡한 금융 자연어 이해 및 다단계 추론을 수행합니다.
- 도메인 특화 모델 결합: 일반 자연어 처리는 Bedrock을 거치되, 금융 도메인 특화 시나리오에는 Amazon SageMaker에 자체 미세조정(Fine-tuned)된 모델을 연동하여 정확도와 일관성을 보강했습니다.
3.3 실시간성 및 상태 관리를 위한 인프라 아키텍처
Finn의 초저지연 응답과 컨텍스트 유지를 위해 완전 관리형 클라우드 서비스를 유기적으로 결합했습니다.
- Amazon DynamoDB: 수 밀리초 단위의 초저지연 성능으로 에이전트 메모리, 세션 상태, 이전 대화 이력을 저장하여 장기 컨텍스트를 유지합니다.
- Amazon OpenSearch Serverless: bunq의 방대한 금융 지식베이스와 규정 문서를 벡터화하여 RAG(검색 증강 생성) 파이프라인의 시맨틱 검색을 전담합니다.
- Amazon ECS 기반 수평 확장: 오케스트레이터와 에이전트 런타임을 컨테이너화하여 트래픽 급증 시 자동으로 인스턴스를 확장합니다.
- 보안 및 감사 인프라: AWS WAF, Amazon CloudFront, AWS CloudTrail, GuardDuty를 결합해 모든 에이전트 호출과 금융 데이터 조회를 철저히 모니터링하고 컴플라이언스를 준수합니다.
4. Impact
bunq가 공개한 오케스트레이터 아키텍처 전환 성과는 다음과 같습니다. (수치 출처: AWS ML Blog, 2026-01-21)
| 지표 | 전환 전 (전통/초기 라우터) | 전환 후 (Bedrock 멀티 에이전트) | 비고 |
|---|---|---|---|
| 고객 지원 처리 비중 | 인간 상담원 중심 수동 분산 | 전체 지원 업무의 97% 처리 | Finn이 1차 고객 접점 전담 |
| 무인 자동 완결율 (Automation) | 수동 에스컬레이션 다수 | 70% ~ 82% 무인 완전 자동화 | 인간 상담원 개입 없이 해결 |
| 평균 고객 응답 시간 | 수 분 ~ 수십 분 대기 | 평균 47초 | 즉각적인 실시간 응답 실현 |
| 개발 및 상용화 소요 기간 | 장기 R&D 프로젝트 | 3개월 만에 프로덕션 배포 | 2025년 1월 착수 후 초고속 출시 |
| 배포 빈도 및 운영 체계 | 정기 배치 배포 | 일 3회 프로덕션 배포 | AI 엔지니어·지원팀 80인 협업 |
| 다국어 커버리지 | 기본 언어 제한 | 38개 언어 앱 번역 및 실시간 음성 통역 | 글로벌 은행권 최초 실시간 통역 |
bunq의 머신러닝 엔지니어링 리드 벤자민 클레페(Benjamin Kleppe)는 “과거에는 지원 에스컬레이션이 대부분 수동으로 이루어졌지만, 이제는 Finn이 전체 지원의 97%를 처리하고 47초 만에 응답한다”고 강조했습니다. bunq는 80명의 크로스 펑셔널 팀을 구성해 하루 3회 이상 프로덕션 업데이트를 진행하며 에이전트의 완성도를 높였습니다.
5. Insight
bunq의 아키텍처 전환은 복잡한 도메인에서 멀티 에이전트를 구축하려는 엔지니어링 팀에게 중요한 교훈을 제시합니다.
중앙 라우터의 한계를 인정해야 합니다. 모든 쿼리를 중앙에서 완벽히 분류하려는 단일 라우터 설계는 에이전트가 10개를 넘어가는 순간 유지보수 불가능한 병목이 됩니다. 상위 계층을 소수(3~5개)의 도메인 프라이머리로 제한하고, 하위 에이전트를 도구 인터페이스로 격리하는 ‘Agent-as-Tool’ 패턴이 엔터프라이즈 확장의 정답입니다.
금융 AI의 본질은 보안과 상태 관리입니다. 최신 LLM 성능만큼이나 중요한 것은 감사 추적(Audit Trail), 세션 메모리, 벡터 검색 인프라입니다. bunq는 DynamoDB와 OpenSearch Serverless를 통해 대화 상태와 지식베이스 검색을 분리하고, 완전 관리형 Bedrock을 통해 규제 준수 부담을 최소화했습니다.
프로덕션 배포 주기와 현장 피드백 루프. 3개월 만에 컨셉에서 상용화까지 도달할 수 있었던 원동력은 AI 엔지니어와 고객 지원 실무자가 원팀(80명)으로 묶여 하루 3번 프로덕션에 배포하는 기민한 이터레이션 구조에 있었습니다.
6. 구현 방식 추론 (Architectural Walkthrough)
6.1
근거: bunq는 ECS 상에서 구동되는 오케스트레이터가 3~5개의 프라이머리 에이전트로 쿼리를 라우팅하고, 프라이머리 에이전트가 전문 서브 에이전트를 도구(Tool)로 동적 호출한다고 밝혔습니다.
사용자 인텐트 해석 및 도구 디스패치 파이프라인은 JSON 스키마 기반의 함수 호출(Function Calling) 체인으로 구성되었을 가능성이 높습니다. 클라이언트 앱에서 고객의 메시지가 유입되면 Amazon ECS의 오케스트레이터 컨테이너가 세션 ID를 기반으로 DynamoDB에서 최근 대화 기록과 MemoryDB의 실시간 세션 캐시를 로드합니다. 오케스트레이터는 경량 프롬프트를 통해 쿼리를 계좌 관리, 카드/결제, 금융 인사이트 등 3~5개 프라이머리 도메인 중 하나로 분류합니다. 지정된 프라이머리 에이전트는 Amazon Bedrock의 Claude 인스턴스에 시스템 프롬프트와 함께 등록된 특화 서브 에이전트들의 Tool 명세(OpenAPI 스키마 형식)를 주입합니다. Claude가 추론 과정에서 invoke_dispute_analyzer(transaction_id=...)와 같은 도구 호출을 생성하면, 프라이머리 런타임이 해당 서브 에이전트 컨테이너로 gRPC 또는 내부 REST 요청을 전송하고, 반환된 분석 결과를 취합하여 최종 사용자 응답 텍스트를 완성하는 구조로 동작할 것으로 보입니다.
6.2 근거: bunq는 엄격한 보안 통제와 금융 규제 준수를 유지하면서 민감한 금융 거래를 처리하고, OpenSearch Serverless 기반의 RAG를 결합했다고 설명했습니다. 금융 데이터 격리와 가드레일은 다단계 보안 프록시 레이어로 구현되었을 것으로 분석됩니다. 사용자의 질문이 모델로 전달되기 전, 프라이머리 에이전트 전면의 데이터 마스킹 미들웨어가 계좌 번호, 카드 CVV, 주민등록 식별자 등 민감 PII 정보를 토큰화(tokenization)하거나 마스킹 처리합니다. 규정 및 지식 검색 단계에서는 OpenSearch Serverless의 k-NN 인덱스를 쿼리하여 관련 약관과 최신 금융 규정을 검색하되, 사용자 권한 범위(RBAC) 내의 문서만 필터링되도록 테넌트 격리가 적용됩니다. 금융 트랜잭션 실행(환불, 카드 일시정지 등)과 관련된 도구 호출의 경우, 에이전트가 직접 DB를 수정하지 않고 bunq의 코어 뱅킹 트랜잭션 API를 호출하며, 이 과정에서 2차 인증(Step-up Authentication) 플래그를 확인하고 모든 호출 파라미터를 AWS CloudTrail 및 내부 감사 로그에 불변(immutable) 기록하는 안전장치를 갖추었을 것으로 분석됩니다.
7. 출처
- AWS Machine Learning Blog — How bunq handles 97% of support with Amazon Bedrock
URL: https://aws.amazon.com/blogs/machine-learning/how-bunq-handles-97-of-support-with-amazon-bedrock/
발행일: 2026-01-21
저자: Benjamin Kleppe (ML Engineering Lead, bunq), Jagdeep Singh Soni (Senior AI/ML Solutions Architect, AWS), Guy Kfir (GenAI Lead, AWS)