bunq, 중앙 라우터를 버린 3~5개 주 에이전트

요약

• 중앙 라우터 대신 소수 주 에이전트가 하위 에이전트를 도구로 호출합니다.
• 고객 지원 97%를 맡고 70~82%를 자동 처리합니다.
• 복잡한 분기보다 모듈형 도구 결합이 대규모 자동화에 효과적입니다.

금융 서비스의 까다로운 제약과 고객의 기다림

해외여행 중에 식당에서 카드로 결제했는데 승인이 거절되고 계좌에서 돈만 빠져나갔다면 누구나 즉시 은행의 답변을 원합니다. 금융 고객 지원은 1분 1초가 급한 상황이 많습니다. 결제 실패, 카드 도난이나 분실, 이상 거래 분쟁, 긴급 환불 같은 요청은 밤낮없이 들어옵니다. 고객은 지금 당장 답을 원하지만 은행의 대응 속도는 늘 한계에 부딪혔습니다.

금융권 고객 지원을 가로막는 가장 큰 장벽은 강력한 규제와 보안 기준입니다. 유럽에서는 유럽 개인정보 보호 규정(GDPR)을 철저히 따라야 하고 엄격한 금융 보안 요건도 충족해야 합니다. 인공지능이 잘못된 잔액을 안내하거나 다른 사람의 금융 기록을 노출하면 바로 금융 사고와 법적 제재로 이어집니다. 기존의 규칙 기반 챗봇은 정해진 시나리오만 처리할 수 있어서, 조금만 복잡한 금융 거래 질문이 들어오면 전부 사람 상담사의 대기열로 넘겨버렸습니다. 그 결과 상담 직원은 밀려드는 업무에 지치고 고객은 답변을 받기까지 오랜 시간을 기다려야 했습니다.

이 문제를 해결하기 위해 유럽 2위 네오뱅크(지점 없이 비대면으로 영업하는 인터넷 전문 은행)인 bunq는 자체 인공지능 비서 Finn을 전면에 내세웠습니다. bunq는 계좌 관리와 거래 분쟁, 환불 요청부터 금융 조언에 이르기까지 전 과정을 처음부터 끝까지 처리하는 일을 에이전트에게 맡겼습니다. bunq는 유럽 전역에서 2,000만 명의 사용자를 두고 결제, 저축, 예산 관리, 투자 서비스를 제공하고 있습니다. 2026년 1월 21일 AWS Machine Learning 블로그에 실린 글에 따르면, bunq는 금융 지원 체계를 완전히 개편해 고객 지원 활동의 97%를 Finn에게 맡기는 데 성공했습니다.

모든 길목을 혼자 지키려던 중앙 라우터의 붕괴

bunq가 처음부터 지금과 같은 높은 자동화율을 달성한 것은 아닙니다. Finn은 2023년에 처음 출시되었습니다. bunq가 처음 구축한 구조는 전형적인 중앙 라우터 방식이었습니다. 중앙 라우터 에이전트 하나가 문지기처럼 서서 고객이 보내온 모든 질문을 읽고 의도를 분석한 뒤, 기술 지원, 일반 문의, 거래 상태 확인, 계좌 관리, 거래 분쟁 같은 전문 에이전트 중 어디로 보낼지 결정하는 구조였습니다.

은행 업무가 다양해지고 전문 에이전트 숫자가 늘어나면서 이 구조는 세 가지 심각한 문제를 드러냈습니다.

첫째, 분류 논리의 복잡성이 걷잡을 수 없이 커졌습니다. 전문 에이전트가 늘어날수록 중앙 라우터가 따져야 할 조건이 기하급수적으로 불어났습니다.

둘째, 에이전트 간의 역할이 겹치고 필요한 데이터가 중복되었습니다. 여러 전문 에이전트가 같은 거래 내역과 사용자 프로필 데이터를 조회해야 했습니다. 고객의 한 문장 안에는 여러 의도가 섞여 있을 때가 많습니다. 중앙 라우터는 첫 번째 담당자만 정하는 것으로 끝나지 않고, 다음에 어느 에이전트를 거쳐 그다음 어디로 가야 하는지 전체 경로를 미리 예측해야 하는 불가능한 과제를 안게 되었습니다.

셋째, 중앙 라우터가 시스템 전체의 단일 장애 지점이 되었습니다. 새로운 기능이나 전문 에이전트를 추가할 때마다 중앙 라우터의 분류 규칙을 고치고 전체 시스템을 다시 테스트해야 했습니다.

에이전트를 도구로 다루는 새로운 아키텍처

bunq는 2025년 1월, 이 병목을 근본적으로 뜯어고치는 작업에 착수했습니다. 중앙 라우터가 모든 경로를 사전에 계산해 전달하는 방식을 버리고, 상위 에이전트가 하위 전문 에이전트를 필요할 때마다 도구처럼 불러 쓰는 방식을 택했습니다. 이것이 바로 agent-as-tool 패턴(에이전트를 도구로 쓰는 방식)입니다.

새 구조에서는 Amazon ECS(컨테이너화된 애플리케이션을 손쉽게 실행하고 확장할 수 있는 완전 관리형 서비스)에서 오케스트레이터가 동작합니다. 오케스트레이터는 복잡한 하위 분류를 직접 하지 않고, 핵심 금융 영역을 대표하는 3~5개의 주 에이전트에게만 질문을 보냅니다. 주 에이전트는 계좌 관리, 카드와 결제 같은 넓은 범위를 나눠 맡았을 것입니다.

질문을 넘겨받은 주 에이전트는 문제를 해결하기 위해 필요한 전문 에이전트를 마치 자신의 도구 상자에서 연장을 꺼내듯 직접 호출합니다. 전문 에이전트들은 정해진 순서로 연결된 고정 경로가 아니라, 필요할 때마다 호출되는 모듈형 도구로 존재합니다.

bunq 다중 에이전트 아키텍처

예를 들어 고객이 “지난주에 식당에서 결제가 실패했는데 계좌에서는 돈이 빠져나갔어요”라고 문의했다고 가정해 보겠습니다. 오케스트레이터는 이 질문을 결제 담당 주 에이전트에 넘깁니다. 결제 주 에이전트는 질문을 이해한 뒤 거래 기록을 분석하는 전문 에이전트를 도구로 호출해 결제 승인 실패 기록과 출금 내역을 대조합니다. 원인이 파악되면 이번에는 환불 규정을 조회하는 전문 에이전트를 호출해 해당 거래가 자동 환불 대상인지 확인합니다. 주 에이전트는 이 두 전문 에이전트가 넘겨준 결과를 종합해 단 몇 초 만에 고객에게 명확한 해결책을 안내합니다.

실제 시스템에서는 고객의 질문이 들어왔을 때 오케스트레이터 컨테이너가 Amazon DynamoDB에서 대화 이력을 불러오고 Amazon MemoryDB에서 고객의 실시간 접속 상태를 확인했을 것입니다. 그런 다음 가벼운 지시문으로 질문 의도를 분석해 적절한 주 에이전트 컨테이너로 전달했을 가능성이 높습니다. 주 에이전트는 Amazon Bedrock에 연결된 Claude 모델에 표준 인터페이스 규격으로 정의된 전문 에이전트 목록을 전달하고, 모델의 판단에 따라 특정 전문 에이전트 컨테이너를 호출해 분석 값을 받아 최종 답변을 완성했을 것입니다.

민감한 금융 정보를 다루는 만큼 보안 체계도 겹겹이 배치되었습니다. 모델에 질문이 도달하기 전에 계좌 번호나 카드 보안 코드 같은 개인 식별 정보를 가리는 중간 장치를 거쳤을 가능성이 큽니다. 지식 검색 단계에서는 사용자의 권한 범위 안에서만 금융 규정과 정책 문서를 검색하도록 제한하고, 실제 환불이나 카드 정지 같은 핵심 금융 거래는 에이전트가 직접 처리하지 않고 은행의 핵심 거래 시스템 API를 엄격한 인증 절차를 거쳐 호출하도록 설계했을 것입니다. 이때 호출에 넘겨진 모든 값은 수정할 수 없는 형태로 AWS CloudTrail과 내부 감사 로그에 기록했을 것입니다.

안전한 클라우드 인프라와 결합한 금융 인공지능

금융 서비스에서 인공지능을 실무에 쓰려면 정확한 추론 능력뿐 아니라 금융 규제를 만족하는 보안 인프라가 반드시 뒷받침되어야 합니다. bunq는 관리 부담을 줄이고 안정성을 확보하기 위해 AWS의 완전 관리형 서비스들을 조합했습니다.

복잡한 금융 대화와 문맥 추론은 Amazon Bedrock을 통해 Anthropic의 Claude 모델을 호출해 해결했습니다. 고객의 금융 데이터가 외부로 새어나가지 않도록 모델 호출은 격리된 가상 사설망인 VPC(Virtual Private Cloud) 내부에서 안전하게 이루어집니다. 일반적인 자연어 처리 외에 은행 특유의 규칙이나 복잡한 금융 업무 처리가 필요한 영역에는 Amazon SageMaker에 자체 미세조정(특정 작업에 맞춰 모델을 추가 학습시키는 과정) 모델을 직접 올려 정확도를 높였습니다.

응답 지연 시간을 줄이고 이전 대화 맥락을 기억하기 위해 Amazon DynamoDB를 도입했습니다. DynamoDB는 한 자릿수 밀리초(1,000분의 1초) 단위의 빠른 속도로 에이전트의 기억, 대화 세션 기록을 저장합니다. 고객의 실시간 세션 상태는 Amazon MemoryDB에 보관해 즉각적인 반응 속도를 유지합니다.

방대한 은행 업무 규정과 정책 문서는 Amazon OpenSearch Serverless를 벡터 저장소로 활용해 RAG(검색 증강 생성, 외부 지식을 찾아 인공지능 답변의 정확도를 높이는 기술) 체계를 구축했습니다. 단어 중심의 단순 검색이 아니라 질문의 뜻을 이해하는 의미 검색을 통해 최신 규정 문서를 정확히 찾아냅니다. 전체 오케스트레이터와 에이전트 실행 환경은 Amazon ECS 컨테이너 위에서 구동되어 고객 접속이 몰리는 시간에도 인프라가 자동으로 수평 확장됩니다.

여기에 웹 공격을 차단하는 AWS WAF, 콘텐츠를 빠르게 전달하는 Amazon CloudFront, 시스템 호출 기록을 남기는 AWS CloudTrail, 지능형 위협을 탐지하는 Amazon GuardDuty, 지표를 감시하는 Amazon CloudWatch를 결합해 모든 에이전트의 동작과 금융 데이터 접근을 실시간으로 감시하고 감사 기록으로 남겼습니다.

숫자로 증명된 성과와 사람의 역할 변화

구조 개편의 효과는 명확한 수치로 나타났습니다. bunq는 2025년 1월 프로젝트를 시작해 단 3개월 만에 개념 검증을 넘어 실제 운영 서비스에 배포했습니다.

현재 Finn은 bunq의 전체 고객 지원 업무 중 97%를 도맡아 처리하고 있습니다. 사람 상담사의 개입 없이 인공지능이 처음부터 끝까지 스스로 해결하는 비율은 70~82%에 달합니다. bunq의 ML 엔지니어링 리드인 Benjamin Kleppe는 완전 자동화율 70%를 언급했으며, 최근 실제 운영에서는 이 비율이 82% 이상에 이릅니다. 고객이 질문을 남겼을 때 답변을 받기까지 걸리는 시간은 평균 47초에 불과합니다.

bunq의 고객 지원 자동화 성과

글로벌 금융 시장을 겨냥한 언어 지원도 대폭 강화되었습니다. bunq 앱은 유럽 전역의 사용자를 위해 38개 언어로 번역되어 제공됩니다. 나아가 전화 상담을 진행할 때 서로 다른 언어를 쓰는 고객과 상담사를 위해 실시간 음성 대 음성 통역을 지원합니다. 고객 지원 통화에 실시간 통역을 도입한 것은 글로벌 은행 업계에서 처음 있는 일입니다.

이처럼 빠른 배포와 높은 자동화가 가능했던 배경에는 조직 운영의 변화가 있었습니다. bunq는 인공지능 엔지니어부터 고객 지원 실무자까지 80명을 하나의 교차 기능 팀으로 묶었습니다. 기술을 만드는 개발자와 현장에서 고객의 불만을 직접 듣는 상담 직원이 한 팀에서 일하며 문제를 발견하면 즉시 코드를 고쳤습니다. 이들은 하루에 3번씩 실제 운영 환경에 업데이트를 내보내며 에이전트의 성능을 끊임없이 다듬었습니다.

Benjamin Kleppe는 오케스트레이터 구조를 도입하기 전의 상황을 돌아보며 다음과 같이 설명했습니다. “오케스트레이터 아키텍처를 도입하기 전에는 상담 업무를 넘기는 과정이 대부분 수작업으로 이루어졌습니다.” 그러나 지금은 시스템이 완전히 달라졌습니다. “현재 Finn은 전체 고객 지원 활동의 97%를 처리하며, 평균 응답 시간은 47초에 불과합니다.”

엔터프라이즈 에이전트 도입을 고민하는 이들에게

bunq의 사례는 대규모 엔터프라이즈 환경에서 다중 에이전트를 도입하려는 기업들에게 실질적인 길잡이를 제공합니다.

가장 먼저 새겨야 할 점은 중앙 라우터 방식의 한계입니다. 많은 조직이 인공지능 에이전트를 도입할 때 모든 입력을 한곳에서 분류하는 중앙 라우터를 먼저 만듭니다. 그러나 처리할 업무 영역이 늘어나고 에이전트 숫자가 10개를 넘어가는 순간, 라우터의 분기 논리는 감당하기 힘들 정도로 꼬여버립니다. bunq처럼 최상위 진입점을 3~5개의 주 에이전트로 단순하게 유지하고, 세부 기능은 도구 형태로 호출하는 agent-as-tool 패턴을 적용해야 시스템의 확장성을 지킬 수 있습니다.

또한 인공지능 도입의 성패는 모델 자체의 성능보다 인프라와 상태 관리에 달려 있습니다. 금융처럼 실수가 용납되지 않는 도메인에서는 대화의 맥락을 안전하게 유지하는 세션 메모리와 정확한 규정을 찾아오는 벡터 검색 체계가 필수적입니다. bunq는 완전 관리형 클라우드 서비스를 적극 활용해 규제 준수 부담을 덜고 본연의 비즈니스 논리에 집중했습니다.

마지막으로 기술 부서와 현업 부서의 긴밀한 협업입니다. bunq가 단 3개월 만에 상용화에 성공하고 하루 3번씩 배포를 이어갈 수 있었던 원동력은 80명의 개발자와 상담 직원이 한 몸처럼 움직였기 때문입니다. 인공지능 도입을 단순한 IT 시스템 구축으로 보지 않고, 현업의 업무 방식을 바꾸고 끊임없이 피드백을 주고받는 운영 체계로 접근할 때 실질적인 업무 개선이 완성됩니다.

---

출처

AWS Machine Learning Blog — How bunq handles 97% of support with Amazon Bedrock — https://aws.amazon.com/blogs/machine-learning/how-bunq-handles-97-of-support-with-amazon-bedrock/ — 2026-01-21