SLASH 22 - 토스뱅크의 완전히 새로운 대출 시스템

토스·토스 SLASH 22 2022·2022년

AI 요약

토스뱅크 대출 서버 개발자가 '완전히 새로운 대출 시스템'을 소개한다. 전통 금융의 강결합 모놀리식 코어 뱅킹을 넘어, MSA로 비즈니스 로직을 직접 해결하면서 코어 뱅킹·대외 기관과 안전하게 연계하는 구조를 설계한 과정이다.

핵심 포인트

서비스 서버와 코어 뱅킹을 독립 API로 정의하고 전문 대신 HTTP API로 통신하며, 신용정보를 위한 KCB·나이스·신용정보원 연동에 사용자 수에 맞춰 동적으로 요청하는 유량 제어 시스템을 도입했다
DB 형상과 코드를 동기화하기 위해 Flyway로 마이그레이션을 버전·코드 리뷰 대상으로 관리하고, 운영은 DBA 요청으로 진행하되 하이버네이트 validate 옵션으로 엔티티-스키마 불일치 시 서버가 아예 시작되지 않게 막는다
Kafka 파티션별 독립 스레드 풀로 기관이 견딜 TPS만 전달하고, Redis 기반 지표로 서킷 브레이커를 동작시켜 실패 시 앱 스크래핑으로 전환하며, 대기열 시스템으로 2022년 1월 1일 대출 오픈런 폭주를 견뎌냈다

왜 읽나금융 도메인에서 MSA·DB 마이그레이션·유량 제어·대기열로 안정성과 개발 속도를 함께 잡으려는 백엔드 엔지니어에게 실전 아키텍처를 준다.

챕터별 상세

010:00 – 4:45

전통 코어 뱅킹을 넘어 — MSA로 새로 설계한 대출 시스템

토스뱅크에서 대출 서버 개발을 맡은 발표자가 '토스뱅크의 완전히 새로운 대출 시스템'을 연다. 전통 금융회사는 대부분의 비즈니스 로직이 강하게 결합된 모놀리식 코어 뱅킹 시스템 위에 구현되고, 채널계라 불리는 서비스 서버는 사용자 요청·응답을 코어 뱅킹의 전문 규격에 맞춰 변환·전달하는 데 그쳤다. 이런 구조는 신규 피처마다 영향도 분석에 많은 시간이 들고 그 피처가 다시 분석 대상이 되는 악순환을 만들어, 빠르게 바뀌는 애자일 조직에서는 유지보수가 어렵다.

토스뱅크는 마이크로서비스의 장점을 가져오면서 전통 금융 시스템과의 연계를 새로 설계했다. MSA로 구성한 서비스 서버와 모놀리식 코어 뱅킹을 각각 독립된 API 서비스로 정의하고, 전문 방식이 아닌 HTTP API 통신으로 필요할 때만 코어 뱅킹과 통신하면서 독립된 마이크로서비스가 비즈니스 로직을 직접 해결하도록 했다. 대출에 필요한 신용정보를 위해 KCB·나이스·신용정보원 같은 대외 기관과의 통신 구조도 새로 설계했는데, 관여 기관이 늘며 심사 응답 속도가 늘어지는 문제가 생겼다. 기존 금융권은 여러 기관을 동시에 호출하는 비동기로 풀었지만 사용자가 급증하면 기관이 감당 못 할 트래픽이 몰려 시스템이 마비되곤 했다. 그래서 토스뱅크는 기관이 견딜 만큼만 보내고 사용자 수에 맞춰 동적으로 요청을 처리하는 유량 제어 시스템을 도입했고, 관계형 DB로 MySQL, 메시지 서비스로 Kafka, 유량 제어·캐시로 Redis를 활용했다. 대출이 실행되기까지는 사용자·약관·상품·대출 서버 등 여러 서비스가 관여하고 각자 독립 스키마를 가져, 협업 없이는 이렇게 큰 시스템을 유지할 수 없다. 협업을 위해서는 스키마를 언제든 복제·생성할 수 있어야 하고, 버전 컨트롤과 연동해 DDL 쿼리 버전이 관리되어야 하며, 비즈니스 로직과 스키마의 동기화가 보장되어야 한다.

비즈니스가 빠르게 바뀌는 조직에서는 DB 스키마도 끊임없이 변해야 하지만, 잦은 변경은 협업을 어렵게 하고 오류를 부른다. 안정성과 개발 속도를 모두 잡기 위해 토스뱅크는 초기부터 DB 마이그레이션 툴 Flyway와 하이버네이트의 DDL validate 옵션을 적용하기로 결정했다. Flyway는 버전 기반 마이그레이션 스크립트를 SQL 파일로 관리하며 Git에서 소스 코드와 함께 관리되므로, DDL·DML SQL을 서비스 코드와 함께 코드 리뷰할 수 있고 코드와 DB 간 동기화를 버전 컨트롤로 유지할 수 있다. 개발자 각자의 PC와 개발·테스트·스테이지 환경이 모두 독립된 DB를 갖고, 피처 브랜치에는 아직 반영되지 않은 버전 SQL 파일이 존재한다. 피처 브랜치가 개발 브랜치에 머지되면 해당 SQL이 적용돼 Flyway 동작으로 개발 DB가 브랜치와 동일한 형상을 갖는다. 잘 세팅해 두면 새 개발자가 로컬에서 서버만 구동해도 DB 세팅이 끝나고, 서비스 배포와 함께 마이그레이션이 진행돼 형상을 반영하지 않은 채 로직만 배포되는 참사를 막는다.

Flyway는 CI에서도 유용하다. 마이그레이션 전략이 없으면 통합 테스트 시 DB 연동 부분을 모킹하거나 인메모리로 처리해야 하지만, 전략이 있으면 실제 DB를 직접 연계해 트랜잭션이나 DB 동작을 통합 테스트로 반복 확인할 수 있다. 테스트 전 DB를 실행하고 테스트 스키마를 생성한 뒤 스프링 컨텍스트 로딩 시 Flyway가 자동으로 최신 형상을 만들어 모킹 없이 실제 DB 연계 테스트를 진행한다. 다만 이 전략을 운영 시스템에 그대로 적용하지는 않았다. 서버 개발자가 작성한 DDL·DML은 운영에서 치명적일 수 있어, 버전 컨트롤의 SQL 파일을 기반으로 DBA에게 작업을 요청해 운영 배포를 진행한다. 그러면 운영 DB 형상과 서비스 코드가 어긋날 위험이 남는데, 이를 막기 위해 하이버네이트 DDL의 validate 옵션만 쓴다. 이미 Flyway로 정확한 마이그레이션을 끝냈기 때문에 하이버네이트의 마이그레이션 전략은 무의미하고, 현재 엔티티가 DB 스키마와 동일한지 확인만 한다. 동기화가 맞지 않으면 서비스가 아예 시작되지 않아 잘못된 서버로 요청이 들어가는 것을 사전에 방지한다.

안정적인 DB 전략을 갖춘 뒤 발표는 대외 기관 연동 문제로 넘어간다. 대출은 신용 평가와 소득 산출을 위해 나이스·KCB 같은 신용평가사, 신용정보원 등 여러 대외 기관과의 연동이 필수다. 과거 새 은행이 오픈하면 이런 기관들이 트래픽을 감당하지 못해 한동안 대출 신청이 동작하지 않는 일이 잦았기에, 토스뱅크는 초기부터 기관이 견딜 만큼만 트래픽을 전달하는 파이프라인과 유량 제어를 적용했다. 대외 기관 요청을 파이프라인화하기 위해 Kafka를 도입하고, 파티션마다 일대일로 대응되는 컨슈머와 독립된 스레드 풀을 배정해 트래픽이 몰려도 기관이 견딜 수 있는 TPS만 전달되도록 했다. 스레드 풀은 서버 상태에 맞게 동적으로 사이즈를 조절하는데, 코틀린의 fixed thread pool로 서로 다른 크기의 풀을 배열로 선언해 필요에 따라 선택한다. 정확한 TPS 측정을 위해 API 호출은 동기로 구성했고, 기관마다 최적 요청 수가 달라 사전에 기관별로 연동을 최적화한다. 지표 수집은 100% 코틀린의 코루틴·WebClient·Redis 기반 논블로킹 시스템으로 구축해 수집이 서비스에 영향을 주지 않게 했고, 요청 시작·완료 시각과 성공/실패를 Redis에 기록해 분 단위 통계로 쌓아 기관의 처리 시간과 실패율을 판단한다.

이 통계로 서킷 브레이커를 동작시킨다. 기관이 약속된 TPS보다 성능이 떨어지고 실패율이 오르면 파이프라인의 동적 풀 사이즈를 줄여 요청 수를 조정하고, 그래도 마이데이터 API 실패율이 계속 오르면 서킷을 열어 인증서 기반 앱 스크래핑으로 전환한다. 반면 KCB·나이스처럼 대체 불가능한 기관에서 문제가 나면 대출상품 전체 진입을 차단한다. 사용자가 급증하면 입장 티켓을 받아야 진입할 수 있는 대기열 시스템도 Redis로 구현해, 대기열과 입장열 두 큐로 일정 주기마다 정해진 수만 입장시켜 속도를 제한한다. 실제로 2022년 1월 1일 대출 재개 때 사용자가 폭주했지만, 정해진 TPS만 기관에 전달하고 앱 스크래핑 전환과 대기열까지 동작시켜 많은 고객이 일정 시간 내에 결과를 받게 했다. 은행 시스템도 강결합이 아니라 느슨하게 분리돼 기술 발전에 빠르게 대응할 수 있는 시스템을 만들었다는 메시지로 끝맺는다.