기술은 외부에서 가져올 수 있습니다.
하지만 판단과 책임까지 외부화할 수는 없습니다.

은행이 Digital Wallet을 구축하려고 하면
곧 하나의 현실적인 질문을 만나게 됩니다.

이걸 전부 직접 만들어야 할까요?

Blockchain Node, MPC, Key Management, Transaction Signing,
Policy Engine, Wallet Address 관리, Chain별 연동까지.

디지털자산 Wallet은
은행이 기존에 직접 만들어온 시스템과는 기술적 성격이 상당히 다릅니다.

반면 이미 글로벌 시장에는
이 기능들을 SaaS 형태로 제공하는 전문기업들이 있습니다.

그렇다면 더 간단해 보입니다.

검증된 Wallet Infrastructure를 가져와
은행 앱과 연결하면 되지 않을까요?

하지만 금융에서는 문제가 하나 더 있습니다.

기술을 외부에서 제공받는 것과
금융의 책임을 외부에 맡기는 것은 전혀 다른 이야기이기 때문입니다.

먼저 ‘Wallet SaaS’가 무엇인지 구분할 필요가 있습니다

Wallet을 SaaS로 구축한다고 하면
은행의 고객 자산과 Private Key를
외부 회사에 모두 맡기는 모습을 떠올리기 쉽습니다.

하지만 반드시 그런 구조만 있는 것은 아닙니다.

기관용 Wallet Infrastructure는 여러 기능으로 나눌 수 있습니다.

예를 들면, 아래와 같은 영역이 있습니다.

• Key 생성과 관리
• Transaction Signing
• Blockchain Connectivity
• Address Management
• Policy Execution
• Approval Workflow
• Audit Log
• Chain별 업데이트

MPC를 사용하는 경우에도
하나의 Private Key를 외부 사업자 서버에 그대로 저장하는 구조라기보다,
암호기술을 이용해 서명 권한을
여러 요소로 분산시키는 방식으로 설계할 수 있습니다.

따라서 “SaaS를 쓸 것인가?” 처럼
하나로 묶어서 볼 필요는 없습니다.

보다 정확한 고민은

“Wallet을 구성하는 여러 기능 중 무엇을 외부 전문 인프라로 활용하고,
무엇을 금융회사가 직접 통제할 것인가?” 입니다.

모든 것을 직접 만들면 더 안전할까요?

은행의 입장에서는
중요한 시스템일수록 직접 구축하고 싶어지는 것이 자연스럽습니다.

특히 고객 자산과 연결된 Wallet이라면 더욱 그렇습니다.

하지만 직접 구축한다고 해서
자동으로 더 안전해지는 것은 아닙니다.

Blockchain은 계속 변합니다.

새로운 Chain이 생기고,
Protocol이 업그레이드되고,
서명 방식이나 Smart Contract가 변경되며,
보안 취약점에 대응해야 합니다.

MPC와 HSM 같은 암호기술도
단순히 솔루션을 한 번 구축한다고 끝나는 영역이 아닙니다.

24시간 운영, 키 복구, 권한 분리, 장애 대응, Chain Upgrade, 보안 Patch까지
지속적인 전문성이 필요합니다.

은행이 이런 기술을 모두 직접 보유하는 것이
경제적으로나 운영적으로 항상 최선이라고 보기는 어렵습니다.

어떤 영역에서는 오히려
여러 기관을 대상으로 같은 인프라를 지속적으로 운영해온
전문사업자의 기술과 경험을 활용하는 것이 더 합리적일 수 있습니다.

즉, In-house = Safe 라는 공식은 성립하지 않습니다.

중요한 것은 누가 만들었느냐보다
어떤 통제구조로 운영되고 있는가입니다.

첫 번째 경계: 기술은 외부화할 수 있습니다

Wallet Infrastructure 중 SaaS의 장점이 비교적 명확한 영역은
암호기술과 Blockchain Connectivity입니다.

대표적으로 아래와 같은 기능입니다.

• Key Management
• Signing Infrastructure
• Blockchain Connectivity
• Transaction Orchestration

이 영역은 전문성이 높고
기술 변화도 빠릅니다.

여러 Blockchain을 지원한다면
각 Chain의 업데이트와 장애에도 지속적으로 대응해야 합니다.

금융회사가 모든 기술을 자체 개발하는 것보다
전문기업의 검증된 인프라를 활용하는 것이
개발 기간과 운영 부담을 줄일 수 있습니다.

하지만 여기에서 중요한 구분이 하나 있습니다.

기술을 실행하는 것과,
그 기술이 무엇을 해야 하는지 결정하는 것은 다릅니다.

예를 들어 SaaS가 Transaction Signing을 수행할 수는 있습니다.

그렇다고
누가 거래할 수 있는지,
얼마까지 보낼 수 있는지,
어느 주소로 보낼 수 있는지까지
외부사업자가 결정해야 하는 것은 아닙니다.

이것은 금융회사의 영역입니다.

두 번째 경계: 판단은 은행 안에 남아야 합니다

은행 Wallet에서 가장 중요하게 관리해야하는 것은
Private Key만이 아닙니다.

오히려 더 중요한 것은 '이 거래를 실행해도 되는가?' 와 같은 판단 영역입니다.

예를 들어 고객이 1억원 상당의 디지털자산을
외부 Wallet으로 전송하려고 한다고 가정해보겠습니다.

Blockchain에서는 기술적으로 전송할 수 있습니다.

하지만 은행은 먼저 판단해야 합니다.

고객에게 이 거래 권한이 있는가.
거래한도를 넘지 않았는가.
상대방 주소는 위험하지 않은가.
제재 대상과 관련되어 있지 않은가.
이상거래 가능성은 없는가.
추가 승인이 필요한 거래인가.

즉 Wallet에서 중요한 것은 Can Execute 만이 아니라

Should Execute 입니다.

전자는 기술의 문제지만,
후자는 금융의 판단입니다.

그래서 저는 금융기관 Wallet의 핵심 경계를 다음처럼 나눠볼 수 있다고 생각합니다.

Execution은 외부화할 수 있습니다.
Decision은 은행 안에 남아야 합니다.

고객 식별, 권한, 거래한도, AML 판단, 최종 승인,사고 대응 같은 영역은
금융회사의 책무와 직접 연결되기 때문입니다.

Policy Engine도
‘누가 정책을 결정하느냐’가 중요합니다

조금 더 복잡한 문제가 있습니다.

Wallet SaaS에는 흔히 Policy Engine이 포함됩니다.

예를 들어,
아래와 같은 같은 규칙을 시스템에서 자동으로 집행할 수 있습니다.

• 지정 주소로만 전송
• 1회 1억원 이하
• 2인 이상 승인
• 특정 시간대 거래 제한
• 위험도가 높은 거래 자동 차단

그렇다면 Policy Engine도 외부에 두면 안 되는 것일까요?

반드시 그렇지는 않습니다.

여기서도 Policy Ownership과 Policy Execution 을 구분할 수 있습니다.

은행이 정책을 정하고,
외부 Wallet Infrastructure가 그 정책을 기술적으로 실행하는 구조는 가능합니다.

예를 들어 은행이 아래와 같은 정책을 정합니다.

법인 고객의 외부 전송은 2인 승인 + 화이트리스트 주소만 허용

SaaS는 이 규칙대로
승인 Workflow와 Signing을 실행합니다.

즉,

은행은 Rule을 소유하고
SaaS는 Rule을 실행합니다.

이 구분이 중요합니다.

정책 엔진이 외부에 있다는 이유만으로
금융의 판단까지 외부화됐다고 볼 필요는 없습니다.

반대로 시스템이 은행 내부에 있다고 해도
정책의 책임주체가 불분명하다면
좋은 통제구조라고 보기 어렵습니다.

세 번째 경계: 데이터는 필요한 만큼만 넘어가야 합니다

SaaS를 사용하는 순간
어떤 데이터를 외부로 보낼 것인가. 에 대한 고민이 생깁니다.

은행 내부에는
고객정보, 계좌정보, 거래정보, AML 정보, 권한정보처럼
민감한 데이터가 존재합니다.

Wallet SaaS가 필요하다고 해서
이 정보를 모두 외부로 전달할 필요는 없습니다.

예를 들어 외부 Signing Infrastructure가 거래를 수행하기 위해 필요한 것은

고객의 이름이나 계좌잔액 전체가 아니라

이 거래가 승인됐는지, 어떤 Address로,
얼마를, 어떤 Network에서 전송할 것인지
일 수 있습니다.

따라서 SaaS Architecture에서는

Minimum Necessary Data 원칙이 중요해집니다.

필요한 데이터만 경계를 통과시키고,
고객 식별과 금융정보는 가능한 한 내부에 남겨두는 방식입니다.

그래서 중요한 것은 '경계 설계'입니다

금융회사 내부 시스템이
외부 SaaS를 자유롭게 직접 호출하는 구조는 부담이 큽니다.

대신 중간에 통제 지점을 둘 수 있습니다.

구조를 단순화하면 다음과 같습니다.

Bank Channel → Bank Control Plane

→ Secure Gateway / Integration Layer

→ Wallet SaaS → Blockchain Network

여기서 중요한 것은 가운데 있는 Bank Control Plane입니다.

은행이 직접 가져가야 할 기능을 모아놓는 것입니다.

• Customer Identity
• Authority
• Transaction Limit
• AML Decision
• Risk Policy
• Approval
• Accounting
• Reconciliation
• Monitoring
• Incident Response

외부 Wallet Infrastructure가 바뀌더라도
은행의 핵심 정책과 책임구조는 그대로 유지할 수 있습니다.

이렇게 보면 Wallet Architecture에서
가장 중요한 자산이 반드시 Private Key 관리시스템만은 아닐 수도 있습니다.

오히려

“어떤 거래를 허용하고 누가 책임질 것인가”를 결정하는
Control Plane이 은행의 핵심 역량이 될 수 있습니다.

세 가지 구축 방식으로 나눠볼 수 있습니다

결국 금융기관의 Wallet Architecture는
크게 세 가지 접근으로 생각해볼 수 있습니다.

1. Full In-house

Key Management부터
Blockchain Connectivity와 Transaction Engine까지
대부분을 금융회사가 직접 구축합니다.

통제권은 가장 강하지만
기술개발과 운영 부담도 큽니다.

2. Full SaaS

Wallet 기능 대부분을
외부 전문사업자의 Platform에서 처리합니다.

구축과 확장은 빠를 수 있지만
금융기관의 통제권과 데이터 경계,
Vendor Dependency를 면밀히 검토해야 합니다.

3. Hybrid

전문성이 높은 Wallet Technology는 외부 인프라를 활용하면서

고객, 정책, AML, 권한, 회계, 최종 승인과 책임은
은행 내부에 유지합니다.

금융기관에는 현실적으로 이 세 번째 모델이
가장 중요한 검토 대상이 될 수 있습니다.

핵심은

Core Technology를 모두 소유하는 것이 아니라
Core Control을 소유하는 것 입니다.

그런데 장애가 발생하면 이야기가 달라집니다

평상시에는 SaaS 구조가 효율적으로 보입니다.

중요한 순간은 사고가 발생했을 때입니다.

Wallet 사업자의 서비스가 중단되면 어떻게 할 것인가.
Blockchain 거래는 만들어졌지만 서명이 완료되지 않았다면 어떻게 할 것인가.
잘못된 정책이 적용되어 거래가 차단됐다면 누가 대응할 것인가.
Key Share 중 일부를 사용할 수 없게 되면 어떻게 복구할 것인가.
외부사업자가 장애를 겪는 동안 고객의 자산은 어떻게 보호되는가.

이 순간부터 SaaS는 기술 조달의 문제가 아니라
운영 안정성(Operational Resilience)의 문제가 됩니다.

따라서 금융회사가 Wallet SaaS를 검토한다면
기능 목록만 봐서는 부족합니다.

최소한 아래와 같은 부분까지 함께 봐야 합니다.

• SLA
• BCP / DR
• Key Recovery
• Auditability
• Log Retention
• Privilege Separation
• Exit Plan

특히 Exit Plan은 중요합니다.

외부사업자를 변경해야 할 때
고객의 Wallet과 Address, Key Control, 거래 기록, 정책정보를
어떻게 안전하게 이전할 수 있는지가 정의되어 있어야 합니다.

금융 인프라에서는
들어가는 방법만큼 나오는 방법도 중요합니다.

가장 중요한 체크 사항은
‘사고가 났을 때 누가 책임지는가’입니다

기술 검토 단계에서는
MPC 방식은 무엇인지, 몇 개 Chain을 지원하는지, TPS는 얼마나 되는지,
같은 질문이 주로 등장합니다.

필요한 질문입니다.

하지만 금융기관에서는 이 체크 리스트가 더 중요합니다.

문제가 생겼을 때 누가 무엇을 책임지는가?
고객의 자산이 잘못 전송됐다면.
Signing Infrastructure에 장애가 발생했다면.
AML Screening에 문제가 있었다면.
내부 승인과 SaaS Policy가 충돌했다면.
고객에게 누가 설명하고, 누가 복구하며, 누가 감독기관에 보고할 것인가.

금융회사에게 Wallet은
Software 기능만을 구매하는 일이 아니기 때문입니다.

고객 자산의 이동과 관련된
책임 구조를 운영하는 일입니다.

그래서 최종 질문은
‘SaaS를 사용할 수 있는가’가 아닙니다

금융기관 Wallet을 SaaS로 구축할 수 있을까요?

기술적으로는 상당 부분 가능합니다.

그리고 모든 것을 직접 만드는 것이
반드시 더 효율적이거나 안전하다고 단정하기도 어렵습니다.

하지만 고민을 여기서 끝내면 안 됩니다.

보다 중요한 질문은

'어디까지 SaaS를 사용할 것인가'

그리고

'무엇만큼은 반드시 금융회사가 직접 통제할 것인가' 입니다.

제가 생각하는 기준은 세 가지로 압축됩니다.

Boundary · Control · Accountability

Boundary 어떤 데이터와 시스템까지 외부와 연결할 것인가.

Control 거래의 허용과 차단을 최종적으로 누가 결정할 것인가.

Accountability 사고가 발생했을 때 누가 고객과 감독기관 앞에서 책임질 것인가.

이 세 가지가 명확하다면
기술의 상당 부분은 외부 전문 인프라를 활용할 수 있습니다.

반대로 이 세 가지가 불명확하다면
모든 시스템을 은행 내부에 구축해도
좋은 금융 인프라라고 보기 어렵습니다.

결국 금융기관 Wallet에서 중요한 것은

Build냐 Buy냐가 아닙니다.

Technology를 어디에 둘 것인가보다
Control과 Responsibility를 어디에 둘 것인가.

이 질문에 답하는 것이 먼저입니다.

by Louis Kim, with Ari

이 글은 EBA와 ECB가 제시한 금융기관의 외부위탁 및 Cloud 이용에 대한 통제 원칙과, 실제 은행용 Digital Wallet Infrastructure의 다양한 구축방식을 함께 참고했습니다.
이를 바탕으로 Wallet의 기술적 실행은 SaaS 형태로 외부화할 수 있더라도, 정책을 정하는 권한(Policy Ownership), 거래를 통제하는 기준(Control), 최종 책임(Accountability)은 금융기관 내부에 남아야 한다는 관점으로 확장했습니다.

참고한 자료

European Banking Authority (EBA)
Guidelines on Outsourcing Arrangements
March 2019
원문 보기

금융기관이 중요 기능을 외부에 위탁하더라도 경영진의 책임과 규제 준수 의무까지 이전할 수 없으며, 외부위탁에 대한 감독과 통제 역량을 내부에 유지해야 한다는 원칙을 참고했습니다.

European Central Bank (ECB)
Guide on Outsourcing Cloud Services to Cloud Service Providers
July 2025
PDF 다운로드

금융기관의 Cloud·SaaS 활용에서 제3자 의존성, 보안, 감사와 모니터링, Exit Strategy를 어떻게 관리해야 하는지에 대한 감독 원칙을 참고했습니다.

Fireblocks
Wallet Infrastructure for Banks: A Blueprint for Building Digital Asset Operations
March 2026
원문 보기

은행의 Digital Wallet Infrastructure를 Control Requirements, Key Management, Transaction Control, Network Connectivity와 Core Banking Integration의 관점에서 설계하는 방식을 참고했습니다.

※ 기술 구현사례를 이해하기 위한 산업자료로 참고했습니다.