[은행IT] 토스뱅크는 왜 계정계를 MSA 로 채택했을까?

안녕하세요! 오늘은 새로운 금융 Tech 소식을 가져왔습니다.
바로 토스뱅크가 시중은행과 다른 구조로 계정계를 탈바꿈하고 있다고 소식인대요~ 과연 전통적인 은행의 코어뱅킹 시스템이 인터넷 은행에서는 어떻게 변화하고 있는지 함께 알아볼까요?

---

 

토스뱅크 계정계는 무엇이 변화되었을까?

토스뱅크 계정계(코어뱅킹)은 전통적인 금융권이 갖추고 있는 모놀리틱 시스템과 달리 아키텍처를 '모놀리식' 방식에서 '마이크로 서비스' 방식으로 변경하였다고 합니다. 모놀리식과 MSA에 대해 궁금하신 분들은 아래 내용을 참고하세요~
 
※ 모놀리식'과 'MSA' 아키텍처의 차이와 장단점 : 

[은행IT] 모놀리식과 MSA(마이크로 서비스 아키텍처)의 차이, 장단점

 
 

시중은행 계정계와 토스뱅크 계정계는 무엇이 다를까?

MSA 아키텍처를 채택한 토스뱅크 계정계(코어뱅킹)는 '여신/수신/외환' 등 고유의 업무 영역마다 서버와 데이터베이스가 별도로 분리되어 있다고 합니다. 서로 다른 서버를 사용하고 있기 때문에 '외환☞여신'과 같이 다른 업무 영역끼리 호출할 때에는 시스템간에는 직접적인 호출이 아닌 'HTTP API' 등의 통신을 통해서 타팀 서비스를 호출하고 있다고 합니다.

 
반면 전통적인 시중은행 계정계는 '여신/수신/외환' 등 계정계 내의 업무 팀들이 모두 동일한 서버, 동일한 데이터를 사용하고 있습니다. 따라서 자신의 서비스에서 타팀 모듈을 호출할 때에, 별도의 통신없이 직접 타팀 서비스를 호출하는 참조 방식을 택하고 있습니다.

 
 

토스뱅크는 왜 코어뱅킹을 MSA로 전환했을까요?

토스뱅크가 시중은행이 수십년간 안정적으로 운영되고 있는 전통 계정계 방식을 MSA방식으로 전환하기로 한 계기는 크게 아래 두 가지 이유가 있다고 합니다.

① 트래픽 몰림으로 인한 성능저하 문제를 해결하기 위해
② 잦은 변경과 배포에도 쉽게 대응하기 위해

 갑자기 사용자가 몰려 트래픽이 증가했을때 트래픽양을 감당하지 못해 시스템이 마비되는 경우가 있습니다. 이때 모놀리식 시스템은 유연하게 스케일아웃하고 다른 서비스의 장애로 이어지는 것을 막기 힘든 구조입니다. 하나의 거대한 덩어리구조이기 때문에 서로의 서비스 내의 타팀의 모듈이 복잡하게 엮여있기 있기 때문입니다. 하지만 MSA 아키텍쳐 내에서는 사람들이 몰릴 특정 업무 서버에서만 유량제어를 처리하면 되기 때문에 성능 저하 문제를 쉽게 해결할 수 있다고 합니다. 
 
 

MSA구조의 계정계, 실제로 어떻게 개발되어 있을까?

실제로 토스뱅크의 '지금 이자 받기' 서비스가 MSA구조로 시스템을 구성하여 매일 70만명 이상의 고객이 몰려도 트래픽 마비 현상을 대비했다고 합니다. 

기존 : 한 개의 트랜젝션 내에서 모두 진행
현재 : 별도의 트랜젝션으로 통신 

기존 모놀리식 구조 내에서는 한 트랜젝션 내에서  '고객 정보 조회 → 금리조회 → 이자계산 → 이자 송금 → 회계처리' 순으로 모든 비즈니스 로직을 순차적으로 처리하는 방식을 따릅니다.
 
하지만 토스뱅크의 새로운 코어뱅킹 아키텍처에서는 트랜잭션으로 묶지 않아도 되는 도메인은 별도의 마이크로 서버를 구성하여, 각 서버의 API 호출을 통해 비즈니스 의존성을 느슨하게 가져가도록 구성했다고 합니다. 즉 이자지급용 고객 금리조회용 서버,  ⇄ 이자의 회계처리 용 회계 정보 조회용 서버 ⇄  세금 DML처리용 서버가 서로 통신하는 방식인거죠.
 
기술스택으로는 토스뱅크의 채널계와 같이 쿠버네티스 위에 스프링 부트, 코틀린, JPA 등을 기반으로 개발했고, 비동기 메시지 처리와 캐싱은 카프카와 레디스를 채택했다고 합니다. 
 

 

트랜젝션 처리는 어떻게 했을까?

시중은행 계정계 서비스는 보통 하나의 트랜젝션(1-TX) 로 이루어져 있기 때문에 거래가 발생하다가 중간에 에러가 났을 경우, 전체 DML을 Rollback하고 있습니다. 하지만 토스뱅크 계정계의 MSA 구조 내에서는 여러 서버가 통신하며 거래가 이루어지기 때문에 트랜젝션 원자성을 보장하기 어려울 것이란 생각이 들었습니다. 하지만 자체적 기술을 통해 이러한 트랜젝션 문제를 해결했다고 합니다. 

① 계좌 단위 현재 잔액 데이터에 대해서만 고유한 로우 락킹(row locking)이 걸리도록 개발해 동시성을 보장
② 동시성이 발생했을 때 거래를 끝날 때까지 기다릴 수 있도록 재시도할 수 있는 로직과 타임아웃을 적용

이러한 개발 방식으로 고객관점에서 서비스를 사용하면서 락(Lock)이 걸렸다고 느끼지 못하도록 안정적으로 서비스를 구현했다고 합니다. 
 

 

시중은행의 모놀리식 시스템, 무조건 바꿔야 하는 걸까?

아닙니다. 모놀리식 시스템에 단점만 존재한다면 이렇게 오랫동안 유지된 이유가 없었겠죠?
 
토스뱅크는 생겨난지 얼마되지 않은 신생 은행입니다. 반면, 현 시중은행들은 인터넷, 스마트뱅킹이 비교적 최근에 생겨났을 뿐 그 역사가 매우 길고 복잡합니다. 개발 시스템도 은행의 역사와 함께 발전해왔기 때문에 수많은 히스토리가 축적되어 있습니다.
 
이러한 구조 내에서 모놀리식 시스템은 가장 효율적인 유지/보수가 가능한 구조라 생각합니다. 개발자가 트랜젝션에 대한 고려를 하지 않아도 되기 때문에 개발 방식이 MSA 구조에 비해 단순합니다. 단일 서버이기 때문에 리소스 낭비도 적다는 장점이 존재합니다. 
 
또한, 금융은 고객의 돈을 다루는 산업인만큼 '안정성'이 가장 중요합니다. 섣불리 시스템을 변경하였다가 다른 서비스까지 영향을 주는 사고가 발생하기 쉽기 때문에 토스뱅크보다 신중하고 길게 검토하고 접근해야 합니다. 이는 곧 시중은행이 기존 아키텍처를 MSA구조로 바꾼다면 토스뱅크보다 더 많은 비용과 시간이 든다는 뜻이겠죠?
 
하지만 모놀리식 시스템의 한계점 또한 분명히 존재하기 때문에 작은 신규 서비스부터 MSA 구조로 바꿔나간다면 증가하는 모바일 고객에 대비할 수 있을 것이라 생각합니다. 
 
 
 

---

여기까지, 토스뱅크의 사례를 통해 은행 계정계의 기술 이슈에 대해 공유해드렸습니다. 혹시 잘못된 내용이 있거나 더 듣고 싶은 내용이 있다면 언제든 연락 주세요📞