자체 구축이냐 도입이냐: 코어뱅킹 시스템의 진짜 비용

조만간 모든 핀테크 창업자는 같은 결정에 가격표를 붙이게 됩니다. 코어뱅킹 시스템을 사내에서 직접 구축할 것인가, 아니면 라이선스를 받아 설정할 것인가. 순진한 비교 — 한쪽에는 라이선스 비용, 다른 쪽에는 개발자 몇 명의 급여 — 는 거의 항상 틀립니다. 두 열에 담긴 항목 자체가 같지 않기 때문입니다.

정직한 비교는 제품 수명 전체에 걸친 총소유비용입니다. 구축 자체, 영구적인 유지보수, 보안과 컴플라이언스의 상시 관리, 그리고 구축하는 동안 벌지 못하는 매출까지. 저희는 코어뱅킹 소프트웨어를 만드는 회사이니 당연히 입장이 있습니다 — 하지만 아래의 계산은 저희가 구매자라면 꼭 보고 싶었을 바로 그 계산입니다.

"코어뱅킹 시스템"이 실제로 의미하는 것

자체 구축이냐 도입이냐의 견적 대부분은 숫자 하나를 적기도 전에 어긋납니다. 범위가 과소평가되기 때문입니다. 고객이 보는 뱅킹 앱은 시스템에서 눈에 보이는 일부일 뿐입니다. 프로덕션급 코어는 하나 안에 네 가지 제품을 담고 있습니다.

• 트랜잭션 코어: 동시 부하에서도 균형을 유지하는 복식부기 원장. 모든 잔액은 원장에서 도출되고 모든 프로바이더와 매일 대사합니다.
• 고객용 제품: 뱅킹 앱 자체, KYC·KYB 등급을 갖춘 온보딩, 다중 통화 계좌, 이체, 카드 — 그리고 점점 더 많은 경우, 진짜 키 커스터디를 갖춘 암호화폐 지갑까지.
• 아무도 범위에 넣지 않는 두 번째 제품: 컴플라이언스 대기열, 거래 모니터링, 수수료 설정, 리포팅, 세분화된 직원 역할을 위한 운영 백오피스.
• 보이지 않는 레이어: 추가 전용(append-only) 감사 기록, 로그인 이후에도 이어지는 2단계 인증 플로우, 요청 속도 제한, 기기 핑거프린팅, 그리고 시크릿을 코드와 데이터베이스 밖에 두는 키 관리.

구축의 길: 예산에 실제로 담기는 것

현실적인 자체 구축에는 금융 시스템 경험을 갖춘 시니어 백엔드 엔지니어, 프런트엔드 엔지니어, DevOps와 보안, QA, 그리고 컴플라이언스를 이해하는 제품 조율 인력이 필요합니다. 프로덕션 품질에 도달하는 팀이 시니어 6~10명보다 작은 경우는 드뭅니다 — 그리고 가장 희소한 프로필, 즉 원장과 커스터디를 프로덕션에서 운영해 본 엔지니어야말로 채용도, 유지도 가장 어려운 인재입니다.

일정의 패턴은 일관됩니다. 성숙한 플랫폼이 첫날부터 제공하는 수준에 도달하는 데 1~2년. 그 시간은 화면에 쓰이지 않습니다. 동시성 아래에서의 원장 정확성, 저마다 고유한 sandbox 특성과 인증 절차를 가져오는 프로바이더 연동, 보안 강화, 그리고 실제 고객과 실제 돈이 있어야만 드러나는 엣지 케이스의 긴 꼬리에 쓰입니다.

그리고 지출은 론칭으로 끝나지 않습니다. 프로바이더는 API를 바꾸고, 블록체인 네트워크는 업그레이드되고, 규제는 움직이고, 의존성은 낡아 갑니다. 사내 코어는 끝나는 프로젝트가 아닙니다. 제품이 존재하는 한 계속 자금을 대겠다고 약속하는 영구적인 팀입니다.

스프레드시트에 절대 나타나지 않는 비용

• 기회비용: 원장을 만드는 데 쓰는 한 달은 제품이 시장에 없는 한 달입니다. 코어 라이선스를 도입한 경쟁사는 여러분이 아직 프로바이더를 연동하는 동안 고객을 유치하고 가격 정책을 다듬고 있습니다.
• 채용 리스크: 구축 계획은 시작한 팀이 끝까지 완주한다고 가정합니다. 원장을 이해하는 두 엔지니어 중 한 명을 구축 도중에 잃는 것은 개월 단위로 측정되는 일정 사고입니다.
• 정확성의 꼬리: 99% 정확한 원장은 거의 완성된 것이 아닙니다 — 지원 티켓과 대사 불일치와 규제 사고를 만들어내는 기계입니다. 마지막 1%가 처음 99%보다 비쌉니다.
• 운영으로서의 보안: 침투 테스트, 키 로테이션, 사고 대응, 모니터링과 알림 — 아무 일이 없어도 계속 발생하는 반복 비용입니다.
• 컴플라이언스 유지: KYC 서류 만료, 계속 진화하는 암호자산 규정, 새로운 보고 의무. 이 작업은 매년 반복되며 미룰 수 없습니다.
• 백오피스: 자체 구축에서는 직원용 도구가 으레 뒷전으로 밀리고, 운영팀은 SQL 콘솔을 물려받습니다. 그것을 본 규제기관과 감사인은 반드시 제대로 다시 만들라고 요구할 것입니다.
• 현지화: 진짜 RTL 지원을 갖춘 다국어 출시는 첫날부터 설계에 넣으면 저렴하지만, 제품이 완성된 뒤에 덧붙이면 비쌉니다.

도입의 길: 무엇을 지불하고 무엇이 여전히 당신 것인가

도입 쪽에서 기술 열은 명시적입니다. 플랫폼의 라이선스 또는 임대료 — 진지한 벤더는 모듈, 체인, 언어를 개별적으로 가격 책정하므로 청구액은 실제로 활성화한 것을 따라갑니다 — 에 인스턴스가 구동되는 인프라를 더한 것입니다. 도입해도 사라지지 않는 것: 당신의 규제 라이선스나 파트너 계약, 프로바이더와의 상업 계약, 운영 인력, 유통 채널. 이 비용들은 어느 길을 택하든 운영자의 몫입니다 — 도입이 없애 주는 것은 엔지니어링이라는 산이지, 사업 자체가 아닙니다.

도입의 정직한 비용은 의존이라는 형태를 띱니다. 로드맵이 온전히 당신 것이 아니고, 플랫폼의 가치는 최악의 모듈이 결정합니다. 완화책은 계약 전에 검증할 수 있는 것들입니다. 자체 데이터베이스와 자체 암호화 시크릿을 갖춘 전용 인스턴스라면 벤더를 떠나는 일이 인질 협상이 아니라 이전 작업이 됩니다. 프로바이더 연동이 추상화 계층 뒤에 있다면 계약은 당신 것이고 프로바이더는 교체할 수 있습니다. 모듈 단위 라이선스라면 켠 것에만 지불합니다. 그리고 플랫폼이 실제 고객과 실제 돈을 처리해 왔다는 증거입니다.

자체 구축이 옳은 선택인 경우

자체 구축이냐 도입이냐는 답이 정해진 수사적 질문이 아닙니다. 다음 중 적어도 하나가 사실이라면 구축이 옳습니다.

• 인프라 자체가 제품인 경우: 원장, 커스터디, 혹은 banking-as-a-service 역량 그 자체를 판매하므로 그것을 소유하는 것이 곧 사업입니다.
• 차별화가 어떤 벤더도 커버하지 않는 요구사항에 있는 경우 — 벤더가 이번 분기에 우연히 빠뜨린 기능이 아니라, 플랫폼의 영역을 구조적으로 벗어난 역량이어야 합니다.
• 프로덕션 코어뱅킹 경험을 갖춘 시니어 팀이 이미 있고, 매출 없이 수년간 그들을 지탱할 자금 여력이 있는 경우.
• 규제기관이나 모기업이 스택 전체의 완전한 사내 통제를 협상 불가능한 조건으로 부과하는 경우.

다섯 가지 질문 프레임워크

• 차별화: 원장이 자체 제작이라는 이유로 고객이 당신을 선택하는 일이 과연 있을까요? 강점이 제품, 유통, 가격에 있다면 코어는 배관입니다 — 필수적이지만 당신이 재발명할 대상은 아닙니다.
• 일정: 기다려 주지 않는 시장에서, 코어를 만드는 1~2년의 무매출 기간을 사업이 감당할 수 있습니까?
• 팀: 돈을 움직이는 시스템을 프로덕션에서 운영해 본 엔지니어를 보유하고 있거나, 현실적으로 채용하고 유지할 수 있습니까?
• 3년 비용: 구축 비용에 영구 유지보수 팀을 더한 것과, 라이선스에 활성화된 모듈을 더한 것을 3년 기준으로 비교하세요 — 론칭 비용끼리 비교해서는 절대 안 됩니다.
• 출구: 각 길에서 떠나는 모습은 어떤가요? 사내 구축의 리스크는 핵심 인력이 지식을 안고 떠나는 것입니다. 벤더와 함께라면 전용 인스턴스, 자체 데이터베이스, 자체 키를 요구하세요. 그러면 출구는 이전 작업이 됩니다.

이 결정에서 Coreza의 위치

Coreza는 도입 열에 속하며, 위의 체크리스트를 통과하도록 만들어졌습니다. 각 고객사는 자체 데이터베이스와 자체 암호화 시크릿을 갖춘 전용 인스턴스를 AWS에서 운영하고, 모든 모듈은 — 체인, 언어, 토큰까지 — 개별 라이선스라 가격이 활성화한 것을 따라가며, 프로바이더 연동은 추상화 계층 뒤에 있어 상업 계약은 당신의 것으로 남습니다.

이 코어의 한 버전은 2024년부터 규제받는 유럽 핀테크의 프로덕션에서 운영되고 있으며, 새 인스턴스는 몇 주 안에 배포됩니다. 브랜딩, 모듈, 언어, 체인은 설정이지 엔지니어링이 아닙니다. 자체 구축이냐 도입이냐의 숫자를 계산하고 있다면, 저희가 권하는 비교는 바로 그것입니다 — 3년 비용 대 3년 비용, 숨은 열까지 채운 상태로.