은행의 공식을 따르지 않는 '보통이 아닌 코어뱅킹' 이야기

안녕하세요, PFCT의 코어뱅킹팀 백엔드 엔지니어 배수한입니다.

여러분은 혹시 ‘코어뱅킹(Core Banking)’이라는 단어를 들어보신 적이 있으신가요? 아마 금융권에 종사해본 개발자라면 익숙하시지 않을까 싶은데요. 흔히들 ‘코어뱅킹’은 금융의 심장이라 불리곤 합니다. 이름에서부터 유추가 가능하듯 은행의 예금(수신)과 대출(여신)처럼, 고객의 모든 금융 거래를 처리하는 가장 핵심적인 정보기술 시스템을 지칭하기 때문이죠.

PFCT의 코어뱅킹팀은 이 심장을 직접 만들고 있는 팀입니다. 지금부터 저희가 어떻게 ‘보통이 아닌 코어뱅킹’을 만들어 가고 있는지, 그 치열하고 매력적인 여정에 대해 이야기해보고자 합니다.

보통이 아닌 금융, 온투금융

PFCT는 ‘크플’이라는 이름으로 ‘온라인투자연계금융(온투금융)’ 서비스를 제공하고 있습니다. 온투금융은, 투자를 통해 수익을 얻고 싶은 사람(투자자)과 자금이 필요한 사람(차입자)을 온라인 플랫폼에서 직접 연결하는 금융업을 말하는데요.

여기서부터 저희의 고민은 특별해집니다. 일반적으로 은행의 코어뱅킹은 고객의 여신(대출)과 수신(예금)을 별개의 흐름으로 처리합니다. 하지만 온투금융의 시스템에서는 여러 투자자로부터 받은 투자금이 곧 차입자에게 나가는 대출금이 되죠.

이때, 차입자가 대출금을 ‘상환’하는 순간, 그 즉시 투자자에게 상환금이 ‘지급’되어야 하는데요. 하나의 상환 거래가 곧 여신(상환)과 수신(지급)의 성격을 동시에 갖게 되는 것입니다. 게다가, 한 건의 대출에 여러 투자자가 붙는 형태이기에 고려해야 하는 것들은 더욱 많아집니다.

이 독특한 구조는 코어뱅킹 시스템의 깊이와 복잡도를 훨씬 높입니다. 기존 금융권이 풀어온 문제와는 결이 다른, 새로운 차원의 문제가 저희 앞에 놓여 있었고, 그렇기에 저희는 코어뱅킹을 직접 구축하기로 결정했습니다.

온투금융, 정의되지 않은 길 위에서

PFCT는 2015년에 설립되어 2016년부터 서비스를 시작했고, 2021년에서야 ‘온투금융’이라는 새로운 명칭과 함께 제도권 금융에 편입될 수 있었습니다. 이후로는 제1호이자 최상위 온투금융 플랫폼으로서 수많은 위기를 극복해내며 업계를 선도하고 있는데요.

그 말은 곧, 풀어야 할 문제가 명확하게 정의되어 있지 않다는 뜻이기도 합니다. PFCT는 법규를 해석하고, 비즈니스 모델을 구체화하며, 그것을 기술로 구현하는 모든 과정에서 업계 최초의 사례를 만들어가고 있습니다. 내리는 결정 하나하나가 곧 업계의 표준이 될 수 있다는 사명감과 책임감을 가지고 일하고 있죠.

단적인 예로 온투금융에는 ‘플랫폼 이용료’라는 개념이 있습니다. 차입자의 이자비용이 곧 투자자의 이자수익으로 이어지는 온투금융의 특성상, PFCT는 차입자와 투자자 양쪽에서 ‘플랫폼 이용료’를 받아 수익을 만드는데요. 간단해 보이는 이 개념에도 아래와 같이 수많은 정책과 법규가 얽혀 있습니다.

차입자의 플랫폼 이용료는 법정 최고금리 계산에 포함되어야 합니다.
투자자에게 수익을 지급할 때, 플랫폼 이용료를 공제하는 정책이 필요합니다.
플랫폼 이용료가 발생할 때 마다, 현금영수증을 발행하며, 국세청에 보고해야 합니다.
…

개인 투자자 한도가 3천만 원에서 4천만 원으로 상향되거나, 채무자보호법이 시행되거나, 저축은행의 온투금융 투자가 허용되는 등 관련 규제는 계속해서 진화하고 있습니다. 저희는 이러한 법령과 정책의 변경을 단순히 숫자 하나만 바꾸면 되는 과제로 바라보지 않습니다. 그보다는 기존 시스템과 충돌 없이 안정적으로 적용되고, 관련된 모든 데이터가 정합성을 유지하도록 설계해야 하는 거대한 기술적 과제로 바라보죠.

코드 작성보다 정책 설계가 중요하다는 믿음

이러한 거대한 기술적 과제 앞에서 코어뱅킹팀은 늘 ‘정책’을 가장 중요하게 여깁니다. 저희 팀에게 PR(Pull Request)은 단순한 코드 변경 요청을 넘어, ‘정책의 변경’을 의미하는데요. 고객에게 닿는 것은 코드 한 줄이 아닌, 잘 설계된 정책이란 믿음을 가지고 있기 때문입니다.

그렇기에 저희는 개발 문화의 핵심에 ‘정책 문서’를 두고 있습니다. 새로운 프로젝트나 기능 개발은 언제나 이 문서 작성에서 출발하죠. 이때 PM과 개발자가 함께 모여 정책을 논의하고, 복잡한 시나리오는 액셀로 구체적인 예시를 만들어 시뮬레이션 하곤 합니다. 이는 TDD(Test-Driven Development) 방법론처럼, 실제 코드를 작성하기 전에 정책의 논리적 완결성을 테스트하고 검증하는 과정입니다.

정책 리뷰 단계에서 법적 검토, 정책의 모순, 고객의 이해도까지 꼼꼼하게 따져보았다면, 비로소 개발에 착수하는데요. 이렇게 함으로써 코드가 작성된 후 스펙이 변경되며 발생하는 막대한 비효율을 원천적으로 차단할 수 있습니다. 명확한 정책이 서면, 코딩은 이미 완성된 설계를 컴퓨터 언어로 옮기는 과정이 되고, 미리 만들어 둔 예제는 견고한 테스트 코드가 되어 개발의 완성도를 높입니다. 코드 리뷰 또한 관련 정책 문서를 기반으로 진행하여, 리뷰어는 정책에 대한 깊은 이해를 바탕으로 더욱 본질적인 피드백을 제공할 수 있죠.

이렇듯, 정책 문서를 만들 때 가장 중요한 것이 있습니다. 바로, 복잡성을 걷어내고 고객이 가장 이해하기 쉬운 정책을 만드는 것인데요. 저희 팀은 고객의 만족을 이끌어낼 수 있는 방향으로 정책을 단순화 하는 데에 집중하고 있습니다. 실제로 올해 4월에는 복잡했던 투자자 플랫폼 이용료 산정 방식을 단순하게 변경하는 프로젝트를 진행했는데요. ( 관련 내용 보러가기) 이는 회사의 단기적인 손해로 이어지는 결정이었지만, 고객의 만족과 개발 효율성 증가가 더 큰 가치를 창출한다고 생각해 결단력 있게 실행했습니다.

기술 부채를 넘어, 지속 가능한 아키텍처로

한편, 정책 설계에 못지 않게 아키텍쳐 설계에도 신경을 기울이고 있습니다. 잘 설계된 정책이 고객에게 가 닿기 위해서는 결국 견고한 기술이 뒷받침 되어야 한다고 생각하기 때문인데요.

PFCT는 복잡한 금융 정책을 안정적이고 정밀하게 구현하기 위해 오랫동안 Django/Python 기반의 모놀리식 코어뱅킹 시스템을 운영해 왔습니다. 그러나 변화하는 규제와 고객 요구에 더 빠르고 유연하게 대응하기 위해, 현재는 Kotlin + Spring Boot 기반의 MSA(마이크로서비스 아키텍처)로 점진적인 전환을 진행하고 있죠.

이러한 점진적 전환 방식은 필연적으로 일정 기간 동안 두 개의 시스템을 동시에 운영해야 하는 어려움을 동반합니다. 전혀 다른 언어를 쓰는 두 개의 ‘병렬 우주’가 실시간으로 완벽하게 데이터를 동기화하며 공존하는 것이죠. 이 과정에서 개발자는 복잡한 데이터 동기화 문제, 트랜잭션 라우팅, 이질적인 시스템 간의 통합 패턴 설계 등 난도 높은 기술적 과제들을 해결해야 합니다.

이 과정에서 저희는 아래와 같은 기술적 도전을 마주하고 해결하고 있습니다.

Kafka를 활용한 이벤트 기반 아키텍처(EDA) 도입으로 시스템 간 결합도를 낮추고 유연성 확보
단 1원의 오차도 허용되지 않는 엄격한 데이터 처리
복잡한 비즈니스 로직과 대규모 트래픽·분산 트랜잭션을 안정적으로 처리하는 시스템 설계 및 최적화

이러한 기술적 도전들을 해결하는 과정에서 깨달은 것은, MSA 전환을 위해선 코드 이전에 온투금융이라는 도메인 자체에 집중해야 한다는 것이었습니다. 앞서 말씀드린 것처럼 온투금융은 세상에 없던 금융이기 때문에 새롭게 정의해야 하는 복잡한 문제들이 있기 때문입니다.

DDD(도메인 주도 설계)를 도입해, 비즈니스의 본질을 꿰뚫는 모델을 설계하는 것이 필연적이라고 느꼈습니다. 이를 위해 최근에는 모든 이해관계자가 참여하는 이벤트 스토밍을 통해 우리의 핵심 도메인 이벤트를 구체적으로 정의하고 시각화하며, 앞으로 만들어갈 시스템을 그리는 시간을 가지기도 했습니다.

이렇게 정책과 기술의 근본을 다시 정의하며 쌓아온 경험은, PFCT가 금융의 새로운 표준을 만들어가는 데 든든한 기반이 되고 있습니다. 그리고 그 여정은 여전히 진행 중입니다.