How Ninth Wave built AI-powered open finance onboarding on Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Ninth Wave는 Amazon Bedrock AgentCore 기반 Compass를 구축해 은행별 데이터 격리, 작업별 모델 선택, 7개 전문 에이전트와 결정론적 FDX 준비도 점수를 결합한 오픈 파이낸스 온보딩을 구현했다.

📌 핵심 요약

• Ninth Wave는 은행 API를 Financial Data Exchange(FDX) 표준으로 정규화하며, 기존에 전문가가 수주간 수행하던 API 검증·필드 매핑·준비도 평가의 효율을 높이기 위해 은행 엔지니어와 파트너, 내부 온보딩 팀이 협업하는 Compass를 구축했다.
• Compass는 Amazon Bedrock AgentCore에서 Strands Agents 기반 오케스트레이터와 7개 전문 에이전트를 운영한다. 대량 작업에는 경량 모델을, 매핑·분석·대화형 질의응답에는 추론 능력이 높은 모델을 배정한다.
• 에이전트 호출 전에 은행별 OpenSearch 인덱스와 S3 접두사에서 해당 은행의 문서·설정·이전 상호작용 맥락을 구성한다. Amazon Bedrock Knowledge Bases를 통한 검색 증강 생성(RAG)은 준비도 분석 에이전트에만 적용한다.
• FDX 준비도 점수는 모델의 추정이 아니라 필수 필드 매핑 커버리지를 기반으로 애플리케이션 코드가 결정론적으로 계산한다. 보안은 테넌트 격리, MFA, 최소 권한, 암호화, 에이전트별 안전 제약을 포함하며 SOC 2와 PCI DSS 요구사항에 대한 기존 정합성을 유지하도록 설계됐다.
• Compass는 5개 스프린트로 구축됐으며, 원문은 2026년 3월 1일 베타 고객 온보딩, 5월 15일 프로덕션 환경 준비, 6월 1일 정식 출시를 명시한다. 에이전트별 호출 수·토큰 사용량·지연 시간·비용을 관측하지만, 실제 온보딩 단축률이나 정확도 개선 수치는 제시하지 않는다.

🧩 주요 포인트

1. 의도별 라우팅과 작업별 모델 선택 → 전문 에이전트 간 문맥 경쟁을 줄이고 작업 복잡도에 맞춰 모델 역량을 배분하는 구조다.
2. 은행별 데이터 격리와 준비도 분석에 한정한 RAG → 검색·문맥 구성에 대한 애플리케이션의 통제권을 유지하면서 대규모 FDX 참조 문서 처리에 대응한다.
3. 결정론적 FDX 준비도 점수와 에이전트별 관측 → 감사 가능한 평가 근거와 개별 에이전트의 성능 저하 탐지 기반을 제공하지만, 실제 효율 개선 규모는 제시된 자료만으로 확인할 수 없다.

🧠 상세 정리

1. 은행마다 다른 API와 온보딩의 부담

오픈 파이낸스는 은행이 고객의 승인을 받은 금융 데이터를 표준화된 API를 통해 외부 애플리케이션과 공유하는 네트워크지만, 실제 은행 API의 필드 이름과 형식, FDX 표준 대비 누락 사항은 서로 다르다. 따라서 API 검증과 필드 매핑, 프로덕션 연결 준비도 평가에는 전통적으로 이메일과 스프레드시트를 오가며 전문가가 수주간 작업해야 했다. Ninth Wave는 은행 API를 FDX 표준으로 정규화해 은행이 플랫폼에 한 번 통합하면 전체 오픈 파이낸스 네트워크에 접근하도록 지원한다. 연결 대상에는 Plaid, Finicity, MX 같은 데이터 집계 서비스와 Intuit QuickBooks, Xero, Sage 같은 회계 시스템이 포함된다. Compass는 이 연결 사업의 온보딩 효율과 응답성을 높이기 위해 구축한 AI 지원 도우미다.

2. 셀프서비스 협업과 세 가지 설계 요구사항

Compass의 목표는 은행 엔지니어, 데이터 집계 서비스의 통합 팀, Ninth Wave 온보딩 팀이 AI를 지원받으며 공동 작업할 수 있는 셀프서비스 포털을 제공하는 것이다. 첫 번째 요구사항은 API 검증과 필드 매핑, 준비도 평가를 간소화해 엔지니어링 자원을 효율적으로 사용하고 응답 시간을 줄이며 팀 간 정보를 일관되고 최신인 상태로 유지하는 것이었다. 두 번째는 외부 은행 개발자와 핀테크 파트너에게 통합 의사결정을 돕는 신뢰할 수 있는 AI 인사이트를 제공하면서 다중 테넌트 데이터 격리, 콘텐츠 안전 통제, 감사 로깅을 유지하는 것이었다. 세 번째는 최소 권한과 저장·전송 중 암호화, SOC 2 및 PCI DSS 요구사항과의 정합성을 포함한 기존 금융 서비스 보안·컴플라이언스 관행을 이어가는 것이었다. 원문은 이를 기존 기준의 유지로 설명하며, Compass에 대한 별도의 신규 인증 취득을 주장하지 않는다.

3. 대안 검토와 멀티 에이전트 선택

Ninth Wave는 Amazon EC2에서 모델을 직접 운영하는 방식을 검토했으며, 완전한 통제권을 얻는 대신 추가 운영 부담이 발생한다고 판단했다. 단일 에이전트 RAG 방식은 더 단순했지만 매핑, 분석, 검색, 대화형 질의응답을 함께 처리할 때 정확도가 상대적으로 낮았다고 설명한다. 멀티 에이전트 구조는 초기 복잡성이 더 크지만 각 에이전트에 단일 작업과 독립된 문맥·지시 프롬프트를 부여해 프롬프트 공간의 경쟁을 줄이는 선택이었다. Amazon Bedrock AgentCore는 에이전트의 호스팅과 확장을 위한 관리형 런타임을 제공하고, Strands Agents는 의도 분류와 전문가 라우팅을 담당한다. 오케스트레이터가 의도를 한 번 분류하고 작업 복잡도에 따라 경량 모델 또는 추론 능력이 높은 모델을 선택하는 것이 핵심이며, 제공된 본문에는 실제 모델명이나 모델별 성능 비교 수치가 없다.

4. 진입 보안과 은행별 문맥 구성

요청은 TLS 1.2 이상과 HSTS를 적용한 Amazon CloudFront 및 기본 거부 웹 ACL을 사용하는 AWS WAF v2를 통과한 뒤 TLS 1.3을 사용하는 내부 Application Load Balancer로 전달된다. AWS WAF는 엣지 트래픽을 보호하고, 애플리케이션 인가는 각 은행의 접근을 해당 온보딩 작업 공간으로 제한한다. AWS Fargate의 Amazon ECS는 MFA가 적용된 OAuth2/OIDC 자격 증명 공급자를 통해 세션을 검증하며, 은행의 테넌트 식별자는 하위 서비스의 데이터 조회 범위를 제한하는 데 사용된다. 자격 증명은 환경별 고객 관리형 KMS 키를 사용하는 AWS Secrets Manager에서 가져오고, IAM은 최소 권한을 적용하며 CloudTrail은 지원되는 AWS API 활동을 기록한다. 에이전트 호출 전에는 OpenSearch의 테넌트별 인덱스와 S3의 테넌트별 접두사에서 은행 API 문서, 설정, 이전 상호작용 맥락을 모아 공유 모델 인프라에서도 다른 은행의 정보가 세션에 포함되지 않도록 설계했다.

5. 7개 전문 에이전트의 역할 분담

은행별 근거가 포함된 요청은 교차 계정 IAM 역할을 통해 전용 Amazon Bedrock AgentCore 런타임으로 전달되며, AI 작업과 애플리케이션 작업을 계정 수준에서 분리해 사고의 영향 범위를 제한한다. Strands Agents 기반 Primary Compass Agent는 의도를 분류한 뒤 검색, 문서 질의응답, 문서 분류, 필드 매핑, 분석, 대화형 워크플로, 준비도 분석이라는 7개 전문가 중 하나로 요청을 보낸다. 검색은 포털 문서 결과의 순위를 정하고, 문서 질의응답은 Compass와 FDX 문서를 근거로 답하며, 문서 분류는 업로드된 자료를 자동으로 분류한다. 필드 매핑은 FDX 필드를 은행 API 구조에 맞추고, 분석은 필드 수준의 변화와 형식 문제, 명명 규칙의 차이를 찾아낸다. 대화형 워크플로는 AgentCore 도구 호출 체계로 온보딩을 안내하고 준비도 분석은 준비 상태를 서술하며, 각 에이전트의 제한된 문맥 창은 서로 다른 작업이 토큰 공간을 놓고 경쟁하는 문제를 줄인다.

6. 준비도 분석의 RAG와 결정론적 점수

준비도 분석은 7개 전문가 가운데 유일하게 Amazon Bedrock Knowledge Bases에서 자료를 검색하며, 이는 모든 에이전트에 같은 검색 방식을 적용하지 않기로 한 의도적인 범위 설정이다. 다른 에이전트는 애플리케이션 계층에서 구성한 근거만 사용하므로 Ninth Wave가 검색 로직과 순위 결정 방식을 직접 통제할 수 있다. 준비도 분석은 한 요청에 넣기 어려울 만큼 큰 FDX 참조 문서 집합을 종합해야 하므로 이 작업에 RAG가 적합하다고 판단했다. 한편 FDX 준비도 점수 자체는 모델이 추정하지 않고, OpenSearch에 있는 필수 필드의 매핑 커버리지를 바탕으로 애플리케이션 코드가 결정론적으로 계산한다. 원문은 필드 커버리지에 연결된 결정론적 계산이 확률적 모델 출력으로는 충족하기 어려운 감사 요구에 대응한다고 설명하며, 준비 상태의 서술과 점수 산출을 서로 다른 방식으로 처리한다.

7. 관측 체계와 에이전트별 통제

Compass는 ECS에서 에이전트별 호출 수, 토큰 사용량, 지연 시간, 비용 지표를 Amazon CloudWatch로 보내고, 이를 Amazon SNS 알림과 Amazon Managed Grafana 대시보드에 연결한다. 에이전트별로 지표를 구분하면 시스템 전체의 문제로만 인식하는 대신 특정 에이전트의 성능 저하를 찾아낼 수 있다는 것이 원문의 설명이다. 행동 및 안전 제약도 애플리케이션 계층에서 에이전트별로 적용하므로 다른 에이전트에 영향을 주지 않고 특정 에이전트의 작업 범위와 출력 경계를 조정할 수 있다. 이러한 관측과 통제는 여러 전문가가 함께 동작하는 구조에서 개별 동작과 운영 비용을 파악할 수 있는 기반을 제공한다. 다만 제공된 본문은 마지막 ‘Observability and CI/CD’ 절에서 인프라 상태와 에이전트 행동이라는 두 관측 수준을 언급하다가 끊겨 있어, 이후 CI/CD 구현이나 추가 운영 결과는 확인할 수 없다.

8. 5개 스프린트의 구축 과정과 출시 일정

Compass는 앞 단계의 결과를 바탕으로 다음 단계를 진행하는 5개 스프린트로 구축됐으며, 첫 단계에서는 테넌트별 OpenSearch 인덱스와 S3 저장소, 작업별 모델 구성, 교차 계정 IAM 역할을 마련했다. AWS CDK를 사용하는 AWS CloudFormation으로 전용 워크로드 계정, Bedrock 계정, 공유 서비스 계정의 스택을 관리했고, 두 번째 단계에서는 자동 매핑 가이드 생성과 온보딩 스크립팅, 파트너별 브랜드 포털을 포함한 개발자 포털을 구현했다. 세 번째 단계에서는 오케스트레이터와 전문 에이전트, 은행별 문맥 구성, 준비도 분석용 지식 베이스를 배포했으며, 네 번째 단계에서는 외부 파트너에게 AI를 제공한다는 조건에 맞춰 WAF, MFA, 비밀 관리, 데이터 격리, 암호화와 에이전트별 안전 제약을 강화했다. 다섯 번째 단계에 관해 원문은 2026년 3월 1일 실제 애플리케이션에 베타 고객을 온보딩했고, 5월 15일 프로덕션 환경을 준비했으며, 6월 1일 정식 출시했다고 명시한다. 구축 단계와 일정은 제시돼 있지만 온보딩 소요 시간, 매핑 정확도, 비용이 실제로 얼마나 개선됐는지에 대한 정량적 결과는 제공되지 않는다.

🧾 핵심 주장 / 시사점

• Compass의 역할 분담은 에이전트마다 작업 문맥과 모델 역량을 맞추는 방식이다. 원문은 이를 정확도 유지와 작업 유형 확장의 근거로 제시하지만 정량적 비교 결과는 제공하지 않는다.
• 테넌트 격리는 에이전트 프롬프트만이 아니라 인증·인가, 데이터 조회 범위, 호출 전 문맥 구성에 걸쳐 구현된다. 공유 모델 인프라에서 은행별 정보 경계를 유지하려는 설계다.
• 준비 상태의 설명에는 RAG를 사용하고 FDX 준비도 점수에는 결정론적 계산을 적용함으로써, 문서 종합이 필요한 작업과 감사 가능한 산출 근거가 필요한 작업에 서로 다른 처리 방식을 선택했다.

✅ 액션 아이템

• Compass의 적용 가능성 검토 시 API 검증·필드 매핑·준비도 평가를 작업별 모델 선택과 전문 에이전트 역할 분담에 연결해 검토.
• 은행별 데이터 격리와 준비도 분석에 한정한 RAG를 기준으로 에이전트 호출 전 문맥 구성 및 검색 범위 확인.
• FDX 준비도 점수의 필수 필드 매핑 커버리지 산출 근거와 에이전트별 지연 시간·비용을 확인하고, 실제 온보딩 효율 개선 규모 검증.

❓ 열린 질문

• Compass는 기존 수주간의 API 검증·필드 매핑·준비도 평가 시간을 실제로 얼마나 줄였는가?
• 작업별 모델 선택에서 경량 모델과 추론 능력이 높은 모델을 구분하는 기준은 무엇인가?
• FDX 준비도 점수를 계산하는 필수 필드 매핑 커버리지의 구체적인 산식과 준비도 판정 기준은 무엇인가?