SLASH 23 - 은행 최초 코어뱅킹 MSA 전환기 (feat. 지금 이자 받기)

'지금 이자 받기'는 한 달에 한 번 받던 이자를 원하는 시점에 받을 수 있게 2022년 3월 국내 최초로 출시한 토스뱅크의 대표 서비스다. 출시 당시 모놀리식 코어뱅킹에서 운영했는데, 매일 70만 명 이상이 쓰는 가장 트래픽 높은 서비스가 되며 트래픽 몰림으로 전체 토스뱅크가 지연되는 일이 생겼다. 피크타임에 유연하게 스케일 아웃하고 장애 전파를 막기 위해 독립적인 마이크로서버로 전환하기로 결정했다.

이자는 마지막 지급일부터 요청 전일까지 잔액에 약관 금리를 곱해 산출하고, 이자소득세 14%·지방소득세 1.4%를 제해 계좌에 바로 입금한다. 기술 스택은 채널 서버 기술을 채택해 쿠버네티스 위에 스프링부트·코틀린·JPA, 비동기·캐싱은 카프카·레디스를 썼다. 첫 고민은 강결합된 비즈니스 의존성을 어디까지 느슨하게 가져갈지였다. 이자지급에 필요한 고객·상품·회계 도메인을 한 서버에서 처리하면 MSA 장점을 못 살리므로 도메인 단위로 서비스를 분리하고, 트랜잭션으로 묶지 않아도 되는 도메인은 별도 마이크로서버로 구성해 API 호출로 느슨하게 연결했다.

먼저 은행 안정성과 직결되는 동시성 제어다. 고객 잔액은 앱 거래뿐 아니라 타행 입금·ATM·자동이체 등 갱신 채널이 많아 레디스 글로벌 락만으로는 부족하다. 제어하지 못하면 잔액 100원에 트랜잭션 1이 200원으로 갱신하려는 사이 트랜잭션 2가 처음 조회한 100원에 300원을 더해 400원이라는 엉뚱한 금액으로 덮어쓸 수 있다. 이를 레디스 글로벌 락과 더불어 DB 단의 JPA Lock 어노테이션으로 해결했다. 트랜잭션 2가 락 때문에 대기했다 변경된 잔액을 참조해 안전하게 500원으로 커밋된다. 데드락·성능 저하를 막기 위해 계좌단 현재 잔액 데이터에만 고유하게 로우 락을 걸고, 재시도와 타임아웃을 적용했다.

둘째는 카프카를 활용한 비동기 트랜잭션이다. 기존엔 이자 한 번에 20개 테이블 80번의 업데이트·인서트가 일어나 평균 300ms로 느렸다. 반드시 트랜잭션이 보장돼야 하는 데이터는 묶고, 세금 처리처럼 즉시성이 없는 DML은 카프카로 분리했다. 거래와 동시에 세금 토픽을 프로듀스하고 비동기 서버가 컨슘해 세금 DB에 저장하며, 데드레터 큐로 안정성을, API 멱등성으로 중복 방지를 확보해 DML을 80회에서 50회로 줄였다. 마지막은 레디스 캐싱이다. 고객은 하루 한 번만 이자를 보므로, 하루 중 처음 접근할 때만 DB에 접근해 이자 예상 결과를 레디스에 캐싱하고 만료를 하루로 둬 불필요한 DB IO를 막았다.

기존 시스템을 안정적으로 마이그레이션하는 방법을 설명한다. 이자 조회 거래를 먼저 적용한 뒤 이자 받기 거래를 적용하는 순차 배포를 택했다. 이자 계산 모델이 코어뱅킹과 마이크로서버로 이원화돼 정확성 검증이 필요했기에 3단계로 진행했다. 한 달간 실시간으로 양쪽 API를 호출해 값을 비교하고 불일치 시 알림을 받아 로직을 수정했고, 다음으로 스테이징에서 매일 전기 배치로 동일 검증한 뒤 이자 조회 API를 완전히 전환했다.

실제 입금되는 이자 받기 거래는 더 상세한 검증이 필요해, 수신 개발팀→내부 팀원→일부 고객 순으로 대상을 늘리며 모니터링하고, 구간별 차등 금리·고객/계좌 상태별 출입금 제어 등 예외 케이스를 통합 테스트했다. 이후 호출량을 코어뱅킹 99%/마이크로서버 1%에서 90:10, 50:50, 10:90으로 늘리고 검증 완료 시 100% 전환했다. 기존 은행이 연휴에 전부 내리는 빅뱅 방식으로 거래 중단을 겪던 것과 달리, 토스뱅크는 순차 배포로 무중단 전환했다. 성과로 10만 라인이던 이자 계산 코드를 2천 라인 수준으로 줄였고, API 평균 소요 시간은 기존 MCI 호출 대비 약 40배(최대 약 170배) 개선됐으며, 쿠버네티스·카프카·레디스 같은 신기술도 적용 가능해졌다.