뱅가드 현금 원장 현대화: AI가 조사 시간을 7일에서 15분으로 줄이다

날짜: 2026-10-21
채널: AI Engineer (@aiDotEngineer)
발표자: Gareth Yoder, Vanguard 현금 프로그램 기술 리드
영상 길이: 15분 38초
원문 제목: AI Cut Our Research Time From 7 Days to 15 Minutes — Gareth Yoder, Vanguard
URL: https://www.youtube.com/watch?v=uA4ah-dVHvU
영상 ID: uA4ah-dVHvU

---

📌 핵심 질문 / 레거시 현금 원장을 대규모 금융 서비스 중단 없이 어떻게 현대화할까?

레거시 코드와 업무 지식을 MCP 서버를 통해 AI가 조회할 수 있게 만들고, 데이터·생산자·소비자 이전을 병렬로 진행하면 조사 주기를 7일에서 15분으로 줄이면서도 대규모 원장 시스템의 정합성·멱등성·관측 가능성을 지킬 수 있다.

• 현금 원장은 외부에서 들어오거나 계정 사이를 이동하는 모든 현금 거래를 기록하며, 하루 최대 3천만 건의 서비스 호출과 50만 건의 원장을 처리한다.
• 데이터 이전은 CDC와 매일 수행하는 데이터 검증으로, 생산자·소비자 이전은 공통 스키마와 사용 목적 기반 접근으로 통제한다.
• MCP 기반 AI 질의, 팀 지식 공유, 점진적 현대화와 관측 가능성이 기술 이전과 운영 전환을 함께 뒷받침한다.

Vanguard는 2022년 Cash Plus를 중개 계좌 고객에게 출시한 뒤 다음 대형 과제로 현금 프로그램 현대화를 시작했다. Gareth Yoder는 현금 프로그램의 4~6개 팀을 감독하며, 단일 시스템 교체가 아니라 데이터, 생산자, 소비자를 함께 바꾸는 엔터프라이즈 우선순위 과제를 이끌었다. AI 도구가 도입되기 전에는 메인프레임 엔지니어와 아키텍트가 레거시 코드를 분석해 데이터 모델을 알아내는 데 일주일이 걸렸지만, 코드베이스와 업무 문서를 MCP에 연결한 뒤에는 AI 프롬프트로 15분 안에 답을 얻었다. 데이터 검증과 멱등성, 최소 권한, 업무 맥락이 있는 관측 가능성을 각 이전 경로에 적용해 변화가 운영 가능한 상태로 이어지게 했다.

---

1. 현금 프로그램의 규모와 현대화 과제

1.1. Cash Plus 출시 이후 시작된 현대화

1. 현금 프로그램의 다음 대형 과제
   1. Cash Plus 출시: Vanguard는 2022년에 중개 계좌 고객을 위한 Cash Plus 상품을 출시했다.
   2. 현대화 신호: 상품 출시 후 다음 주요 프로젝트로 시스템 현대화가 예정되어 있다는 이야기가 조직 내에서 나오기 시작했다.
   3. 리더십 범위: Gareth Yoder는 현금 프로그램 기술 리드로서 4~6개 팀을 감독한다.
   4. 청중과의 공감대: 레거시 코드베이스를 가진 사람이 얼마나 되는지, 그 코드베이스가 저절로 현대화되기를 바라는 사람이 얼마나 되는지 물었고, 많은 청중이 손을 들었다.

1.2. 원장 시스템이 처리하는 업무와 규모

1. 현금 원장의 범위

   1. 외부 자금 유입: 외부 세계에서 Vanguard 중개 계좌로 들어오는 모든 자금 이동 거래를 처리한다.
   2. 계좌 간 이동: 계좌 사이의 현금 이동도 기록한다.
   3. 결제 경로: ACH, 전신 송금 등 결제 레일을 통해 발생하는 거래가 대상이다.

2. 다중 채널·고가용성 운영

   1. 접점: 웹, 모바일, 배치 채널을 지원한다.
   2. 복원력: 액티브-액티브(active-active) 다중 리전 장애 허용 구조로 운영된다.
   3. 처리량: 서비스 호출은 하루 최대 3천만 건에 이르고, 고객은 하루 약 50만 건의 원장을 생성한다.

---

2. 병렬 현대화와 AI 기반 레거시 조사

2.1. 데이터·생산자·소비자를 동시에 이전

1. 세 개의 현대화 축

   1. 데이터 이전: 기존 데이터베이스에서 클라우드 데이터베이스로 데이터를 옮기고 결과를 검증한다.
   2. 생산자 이전: 원장 데이터를 생성하는 애플리케이션과 쓰기 경로를 새 생태계로 전환한다.
   3. 소비자 이전: 원장 데이터를 읽는 애플리케이션의 실시간·배치·스트리밍 접근을 현대화한다.

2. 병렬 추진의 이유

   1. 이 과제는 엔터프라이즈 차원의 우선순위였으므로 세 축을 순차 처리하지 않고 병렬로 진행했다.
   2. 초기에는 AI 도구가 준비되어 있지 않아 메인프레임 엔지니어와 아키텍트가 코드를 살펴 데이터 스키마와 모델을 파악했다.

2.2. MCP 서버가 바꾼 조사 피드백 주기

1. 레거시 코드베이스를 AI 질의 대상으로 전환

   1. 연결 방식: 레거시 코드베이스를 MCP(Model Context Protocol) 서버를 통해 AI 도구에 제공했다.
   2. 기존 절차: 메인프레임 엔지니어가 코드를 조사하고 분석한 뒤 답을 가져오는 과정에 최대 7일이 걸렸다.
   3. 새 절차: 같은 조사 질문을 AI 도구 프롬프트로 질의할 수 있게 되면서 답변을 15분 만에 받았다.

2. 영향을 받은 역할

   1. 피드백 주기의 단축은 제품 책임자, 기술 리드, 개발자에게 큰 도움이 됐다.
   2. 특정 전문가의 응답을 기다리는 시간을 줄여 현대화 의사결정과 구현을 빠르게 이어갈 수 있었다.

---

3. 데이터와 생산자 이전의 설계

3.1. CDC를 통한 데이터 검증

1. 데이터 동기화와 감사

   1. 업계에서 널리 쓰이는 CDC(Change Data Capture) 방식을 적용했다.
   2. 양쪽 데이터베이스를 모두 스캔하고, 한 팀이 매일 감사를 수행했다.

2. 일관성과 무결성 확인

   1. 행 수준: 먼저 행 개수가 서로 맞는지 확인해 데이터 집합의 일관성을 검증했다.
   2. 열 수준: 개별 열을 비교해 무결성을 점검했다.
   3. 비교 속성: 금액, 계좌 정보, 주(州) 원천징수, 연방 원천징수를 포함해 레거시 데이터베이스의 모든 속성이 클라우드 데이터와 일치하는지 확인했다.

3. 폐기될 이전 코드를 과도하게 만들지 않기

   1. 현대화가 끝나면 검증용 이전 코드는 더 이상 필요하지 않아 폐기된다.
   2. 따라서 데이터 검증은 강하게 하되, 수명이 짧은 전환 코드에 과도한 엔지니어링을 투자하지 않는 것이 중요하다.

3.2. 세 가지 생산자 경로를 공통 게이트웨이로 정리

1. 기존 데이터 생성 경로

   1. 생산자는 서비스 요청(service request)으로 인프라를 호출했다.
   2. 서비스 요청을 감싼 API를 호출하는 경로도 있었다.
   3. 가장 파악하기 어려운 경로는 데이터베이스 테이블에 직접 쓰는 방식이었다. 데이터가 나타나도 누가 어떤 경로로 생성했는지 알기 어려웠다.

2. 공통 스키마와 게이트웨이

   1. 공통 데이터 스키마를 API 게이트웨이에 적용했다.
   2. 게이트웨이가 API를 감싸 클라우드 데이터 삽입을 수행하게 해 생산자별 쓰기 경로를 정돈했다.

3.3. 단순 복제가 아닌 데이터 생태계 재설계

1. 금융 기술에서 가져온 안정성 개념

   1. 생산자 작업에 멱등성(idempotency)을 반영해 재시도해도 같은 작업이 중복 적용되지 않게 했다.
   2. 여러 작성자가 동시에 작업해도 강한 일관성을 유지하도록 했다.
   3. 여러 작성자에게 일관된 식별자를 주기 위해 Snowflake ID와 유사한 패러다임을 활용했다.

2. 리프트 앤 시프트를 피한 이유

   1. 기존 구조를 새 환경으로 그대로 옮기는 데 그치지 않고 현대화된 생태계를 다시 설계했다.
   2. 기존 데이터 모델과 처리 방식을 새 환경의 기능에 맞춰 개선했다.

3.4. 35개 생산자 이전을 돕는 문서와 AI

1. 생산자 온보딩

   1. 초기 현대화 과정에서 35개 생산자가 새 생태계로 전환해야 했다.
   2. 전환을 돕기 위해 수동으로 마이그레이션 문서를 작성했다.

2. 문서를 제품처럼 제공

   1. AI 도구가 준비된 뒤 문서를 사내 위키에 두고 MCP 서버를 통해 검색할 수 있게 했다.
   2. 이전에는 여러 팀과 채팅을 주고받으며 문의를 분류하고 답했지만, 생산자 팀이 프롬프트로 필요한 답을 얻으면서 채팅과 지원 업무가 크게 줄었다.

3. 레거시 상태 코드의 의미 연결

   1. 클라우드에서는 원장 열거형(enum)을 사람이 읽을 수 있는 표현으로 만들었다.
   2. 레거시 환경의 숫자형 원장 상태 코드와 새 환경의 표현 사이에서 AI 도구가 상태와 의도를 연결하도록 했다.

---

4. 소비자 접근과 업무 맥락을 활용한 운영

4.1. 실시간·배치·스트리밍 소비 경로

1. 공통 스키마 레지스트리

   1. 소비자는 실시간, 배치, 스트리밍 방식으로 데이터를 읽는다.
   2. 어떤 채널을 쓰든 공통 스키마 레지스트리를 통해 데이터 정의를 제공했다.

2. 실시간 잔액 조회

   1. 사용 가능 자금(funds available) API는 가장 트래픽이 많은 실시간 API이며 계정 화면에 표시할 잔액을 결정한다.
   2. GraphQL을 사용해 각 소비자가 자신의 사용 사례에 필요한 속성만 구독하게 했다.

4.2. 배치 데이터와 최소 권한 원칙

1. 분석·대사 업무

   1. 대사(reconciliation)와 데이터 분석 같은 배치 업무에는 데이터 웨어하우스를 사용했다.
   2. 웨어하우스는 데이터 공유 뷰를 제공하고, 각 소비자의 업무에 맞춘 뷰를 만들었다.

2. 데이터 거버넌스

   1. 소비자는 데이터가 필요한 이유와 사용 사례를 알렸다.
   2. 데이터 거버넌스 팀은 특정 속성이 필요한 소비자만 해당 속성을 볼 수 있어야 한다는 원칙을 강하게 지지했다.

4.3. Kafka 스트리밍, 최소 한 번 전달, 멱등 처리

1. 이벤트 공급

   1. 데이터베이스의 모든 삽입과 업데이트를 Kafka 이벤트 토픽으로 스트리밍했다.
   2. 사기 탐지 팀은 이 이벤트를 받아 사기 탐지 도구에 실시간으로 데이터를 넣었다.

2. 전달 보장과 안전한 재시도

   1. 스트리밍은 최소 한 번(at-least-once) 전달을 제공해 생성된 원장 이벤트가 소비자에게 도달하도록 했다.
   2. 생산자 측의 멱등성 개념을 이벤트 소비에도 이어 적용했다.
   3. 배치 작업이 중간에 실패해 소비자가 재시도하더라도 중복 원장이 만들어지지 않게 하고, 동시에 원장 이벤트가 빠지지 않게 했다.

4.4. 50개 소비자 온보딩에 사업 목적을 연결

1. 애플리케이션 식별과 데이터 요청 사유

   1. 원장 데이터가 필요한 조직 내 소비자는 50개였다.
   2. 애플리케이션 등록에는 애플리케이션의 정체와 기능을 나타내는 세 글자 코드가 필요했다.
   3. Vanguard는 등록 코드 외에도 데이터가 필요한 이유와 사업 사례를 설명하도록 요청했다.

2. 업무 사례의 구체적 예시

   1. 거래 주문은 거래의 현금 의무를 이행하기 위해 현금 원장이 필요할 수 있다.
   2. 은퇴 계좌는 의무 분배(required mandatory distribution)를 처리해야 할 수 있다.
   3. 529 교육 계좌는 대학 등록금 계좌에 기여금을 납입할 수 있다.

3. 요청 설명을 활용한 업무 인벤토리

   1. AI 도구는 소비자가 제출한 업무 설명을 묶어 어떤 사용 사례가 현대화됐는지 정확히 정리할 수 있다.
   2. 조직이 지원하는 핵심 사업 기능이 무엇인지도 파악할 수 있다.

4.5. SLA 영향과 로그·추적에 업무 맥락 반영

1. 장애 대응 우선순위

   1. 애플리케이션별 업무 목적을 알면 SLA 위반이 발생할 때 어떤 영향이 생기는지 평가할 수 있다.
   2. 가용성 수치가 “the 59s” 기준 아래로 내려가기 시작한 애플리케이션 코드를 확인하면 사용 사례에 맞는 대응을 판단할 수 있다.
   3. 배치 애플리케이션은 대응까지 몇 시간이 있을 수 있지만, 고객에게 오류를 반환하는 실시간 API는 몇 분 안에 조치해야 한다.

2. 관측 가능성에 업무 정당성 결합

   1. 업무 목적과 데이터 필요성을 관측 가능성(Observability), 로그, 트레이스에 결합해 더 빠른 자가 복구와 대응을 추구한다.
   2. 시스템이 커질수록 단순한 기술 지표뿐 아니라 어떤 업무가 영향을 받는지도 확인할 수 있어야 한다.

---

5. AI 활용의 정착과 운영 전환 원칙

5.1. 팀 단위 AI 활용과 공유 지식

1. AI 도구의 점진적 도입

   1. 현대화는 AI 도구가 등장하기 전에 시작됐지만 이후 새로운 기술을 받아들였다.
   2. AI는 조사, 개발, 테스트를 크게 도왔다.
   3. 현금 프로그램 엔지니어의 90%가 매일 AI 도구를 사용한다.

2. 멀티 에이전트와 팀 브레인

   1. 팀은 멀티 에이전트 워크플로와 공유 지식 베이스를 사용하고, 현대화 수요에 맞춰 AI 하네스를 계속 발전시킨다.
   2. 엔지니어가 제품 기능을 만들며 얻은 지식을 공용 저장소에 넣어 팀 전체가 활용하게 하는 ‘팀 브레인’ 개념을 운영한다.
   3. 새로 합류한 엔지니어도 5년간 근무한 엔지니어와 같은 맥락을 프롬프트에 제공받을 수 있다.

5.2. 두 코드베이스를 함께 운영하는 동안의 규칙

1. 과거가 아니라 현대화된 상태를 고치기

   1. 현대화 기간에는 두 코드베이스를 함께 유지해야 하므로 운영이 어렵다.
   2. 수십 년 동안 존재한 버그를 만나더라도 과거 시스템을 고치기보다 현대화된 상태를 계속 개선한다.
   3. 개선된 클라우드 상태를 생산자와 소비자가 전환하도록 유도하는 동력으로 삼는다.

2. 감사 로그와 운영 지표 보강

   1. 과거 상태를 고치지 않고 앞으로 나아가면 감사 로그가 기존과 달라질 수 있으므로 허용 목록(whitelisting)을 준비해야 한다.
   2. 적절한 지표, 알람, 추적 가능성을 갖추고 제품이 성장하는 동안 자주 검토해야 한다.
   3. 현대화가 완료되고 제품이 BAU(Business as Usual)로 넘어가면 팀이 일상 운영을 책임지므로, 누가 데이터를 만들고 소비하는지 계속 파악해야 한다.

5.3. 리더십을 위한 다섯 가지 실천 원칙

1. 레거시 코드와 지식을 AI 질의 가능하게 만들기

   1. MCP 서버 등을 통해 코드를 질의 가능하게 하면 레거시 조사 주기를 7일에서 15분으로 단축할 수 있다.
   2. 이는 빠른 피드백 루프를 만드는 직접적인 방법이다.

2. 마이그레이션 문서를 제품의 일부로 다루기

   1. 생산자가 새 애플리케이션에 온보딩할 때 마이그레이션 문서를 활용하므로 문서 품질은 사업 기능만큼 중요하다.
   2. 문서는 전환 기간이 끝나면 폐기될 수 있지만 그 중간 과정의 성공을 좌우한다.

3. 리프트 앤 시프트 대신 재설계하기

   1. 기존 것을 그대로 옮기려는 소비자와 생산자는 현대화된 환경으로 온보딩하는 데 가장 큰 어려움을 겪었다.
   2. 새 현금 원장 생태계의 현대적 기능을 이용해 제품을 어떻게 발전시킬지 고민한 팀이 더 잘 전환했다.

4. AI를 점진적으로 채택하기

   1. 완벽한 시작 시점이나 완성된 도구를 기다릴 필요가 없다.
   2. 먼저 시작한 뒤 기술 변화에 맞춰 제품과 활용 방식을 계속 개선한다.

5. 관측 가능성을 협상 불가 원칙으로 삼기

   1. 데이터 생산자와 소비자를 파악할 수 있어야 한다.
   2. 현대화가 끝난 뒤 BAU 운영을 이어가는 팀에 지표, 알람, 추적 정보가 필수다.

5.4. 마무리

발표를 마치며 시간이 있으면 질문을 받고, 그렇지 않으면 행사장 밖에서 대화를 이어가겠다고 안내했다. 이후 청중에게 감사를 전하고 발표 기회에 다시 감사를 표했으며 박수가 이어졌다.

---

주요 발언 모음

“과거를 고치지 말고 앞으로 나아가라.”

“마이그레이션 문서를 제품의 일부로 다뤄라.”

“리프트 앤 시프트하지 말고 다시 상상하라.”

“AI를 점진적으로 채택하라.”

“관측 가능성은 협상할 수 없다.”

“누가 데이터를 만들고 누가 데이터를 소비하는지 알아야 한다.”

핵심 데이터 & 수치

• 하루 최대 3천만 건: 현금 원장 서비스가 받는 일일 호출량.
• 하루 약 50만 건: 고객이 생성하는 일일 원장 수.
• 7일 → 15분: 메인프레임 엔지니어가 레거시 코드를 분석해 답하던 조사 피드백 주기가 MCP 기반 AI 질의로 줄어든 시간.
• 4~6개 팀: Gareth Yoder가 감독하는 현금 프로그램 팀 범위.
• 35개 생산자: 초기 현대화 과정에서 새 생태계로 이전해야 했던 생산자 수.
• 50개 소비자: 원장 데이터를 필요로 해 온보딩한 조직 내 소비자 수.
• 엔지니어 90%: 현금 프로그램에서 AI 도구를 매일 사용하는 엔지니어 비율.
• 세 가지 소비 경로: 실시간, 배치, 스트리밍.
• 세 글자 애플리케이션 코드: Vanguard 애플리케이션 등록에 필요한 식별자.
• 수 시간 대 수 분: 배치 업무는 장애 대응 시간이 몇 시간일 수 있지만 고객에게 오류를 내는 실시간 API는 몇 분 내 조치가 필요하다.

결론 및 시사점

1. 레거시 코드와 업무 문서를 검색 가능한 맥락으로 만들면 전문가의 지식 대기 시간을 줄이고 현대화 결정을 빠르게 내릴 수 있다.
2. 병렬 이전에서는 CDC와 행·열 단위 감사로 데이터 신뢰성을 확보하고, 수명이 짧은 전환 코드는 과도하게 설계하지 않는다.
3. 생산자와 소비자에게 공통 스키마·멱등성·최소 권한·업무 목적 기반 문서를 제공하면 대규모 이전과 재시도를 안전하게 운영할 수 있다.
4. 멀티 에이전트와 팀 브레인으로 지식을 공유하고 AI를 점진적으로 도입하되, 운영 전환까지 추적 가능성·알람·관측 가능성을 유지한다.

20줄 핵심 요약

Vanguard는 2022년 Cash Plus 출시 이후 현금 프로그램의 다음 엔터프라이즈 과제로 레거시 원장 현대화를 시작했다.

현금 원장은 외부 자금 유입과 계좌 간 이동을 처리하며 ACH·전신 송금 등 결제 경로를 지원한다.

웹·모바일·배치 채널을 지원하는 액티브-액티브 다중 리전 시스템은 하루 최대 3천만 건의 호출과 약 50만 건의 원장을 처리한다.

현대화는 데이터, 생산자, 소비자 이전이라는 세 축으로 나뉘어 엔터프라이즈 우선순위에 따라 병렬 진행됐다.

AI 도구가 없던 시기에는 메인프레임 엔지니어와 아키텍트가 레거시 코드와 데이터 모델을 조사하는 데 최대 7일이 걸렸다.

레거시 코드베이스를 MCP 서버로 AI에 연결하자 조사 피드백 주기가 7일에서 15분으로 줄었다.

데이터 이전에는 CDC를 적용하고 양쪽 데이터베이스를 스캔해 매일 검증했다.

검증팀은 행 개수와 금액·계좌·주 및 연방 원천징수 등 개별 열이 일치하는지 확인했다.

전환이 끝나면 폐기될 코드는 목적에 맞게만 만들고 불필요한 과잉 설계를 피했다.

생산자는 서비스 요청, 이를 감싼 API, 직접 테이블 삽입으로 데이터를 만들었으며 공통 스키마 게이트웨이로 클라우드 쓰기 경로를 정리했다.

새 생산자 설계에는 멱등성과 다중 작성자 간 일관성을 넣고 Snowflake ID와 유사한 식별자 방식을 활용했다.

35개 생산자 이전 문서를 위키와 MCP에 공개하자 반복적인 팀 채팅과 생산자 지원이 크게 줄었다.

AI 도구는 레거시 상태 코드의 의도를 사람이 읽을 수 있는 클라우드 원장 열거형으로 연결했다.

소비자는 공통 스키마 레지스트리를 바탕으로 실시간·배치·스트리밍 경로를 사용하고 GraphQL로 필요한 실시간 속성만 구독했다.

배치 소비자에게는 용도별 데이터 공유 뷰를 제공하고 필요한 속성만 공개하는 데이터 거버넌스 원칙을 적용했다.

Kafka는 모든 삽입·업데이트를 스트리밍하고 최소 한 번 전달과 멱등 처리를 결합해 재시도 시 중복 원장 없이 이벤트를 보장했다.

50개 소비자는 세 글자 앱 코드 외에 데이터 사용 목적을 제출했으며 거래 주문, 은퇴 계좌 의무 분배, 529 교육 계좌가 사례로 제시됐다.

AI는 업무 설명을 묶어 현대화된 사용 사례와 핵심 기능을 정리하고 SLA 영향 및 관측 가능성에 연결했다.

배치 장애에는 수 시간이 있을 수 있지만 실시간 API 오류는 수 분 내 대응해야 하며 현금 프로그램 엔지니어의 90%는 매일 AI를 쓴다.

팀 브레인과 멀티 에이전트로 지식을 공유하고 현대화된 상태를 고치며, AI 질의 가능성·제품급 이전 문서·재설계·점진적 도입·관측 가능성을 지켜야 한다.