Wallet Node는 디지털자산 월렛에 필요한 트랜잭션, 데이터, 모니터링, 노드 인프라를 하나의 운영 계층으로 제공합니다.

TL;DR디지털자산 월렛에서 이용자에게 보이는 것은 보내기 → 완료이지만, 금융기관은 그 뒤의 거래 검증, 안정적인 전송, finality 확인, 실시간 모니터링, 내부 원장 정합까지 운영해야 합니다.Wallet Node는 금융기관의 실제 프로젝트에서 반복적으로 필요했던 API와 데이터, 노드 인프라를 하나의 월렛 운영 패키지로 제공합니다. 기존 Wallet·MPC/HSM·원장 시스템은 그대로 두고, 필요한 온체인 계층만 연결할 수 있습니다.거래가 확인된 뒤가 더 중요합니다. Wallet Node는 온체인 결과를 내부 원장과 맞추고, 특정 시점의 잔액·가치를 사후 감사 시점에 다시 설명할 수 있도록 뒷받침합니다.국내 이중화 IDC, 자동 failover, 24×7 운영, SLA, SOC 2 Type II 기반 인프라로 프로덕션 운영을 지원하며, 현재 대형 증권사를 포함한 금융기관의 디지털자산 환경에 적용되고 있습니다.

고객에게는 송금 한 번, 금융기관에게는 온체인 운영 과정

이용자가 디지털자산을 쓰려고 블록체인을 공부할 이유는 없습니다.

은행 앱에서 계좌번호를 넣고 송금하듯, 디지털자산도 특별한 학습 없이 자연스럽게 쓸 수 있어야 합니다. 주소를 확인하고, 자산을 보내고, 잔액과 거래 결과를 이해하는 과정이 지금의 금융 경험만큼 익숙해야 합니다.
네트워크마다 주소 형식이 다르고, 확정까지 걸리는 시간과 수수료도 제각각입니다. 멀티체인 환경이라면 더 복잡해집니다. 이 복잡성을 고객이 직접 감당하게 두는 대신, 금융기관이 흡수해 단순한 경험으로 바꿔주는 것이 좋은 디지털자산 서비스의 조건입니다.

이미 좋은 UX와 이용자 기반을 갖춘 금융기관이나 핀테크라면 더욱 그렇습니다. 블록체인을 도입한다고 해서 익숙한 금융 경험까지 블록체인 방식으로 바꿀 이유는 없습니다. 블록체인은 새로운 사용법이 아니라, 기존 금융 경험을 떠받치는 새로운 인프라여야 합니다.

그런데 이용자에게 보이는 경험이 단순해질수록 그 뒤에서 금융기관이 풀어야 하는 일은 많아집니다.

이용자 화면에서는 보내기 → 완료입니다. 그 사이에서 금융기관은 트랜잭션이 정상 실행될지 확인하고, 예상 수수료를 계산하고, 받는 주소가 맞는지 검증한 뒤, 서명된 트랜잭션을 정상 노드로 전달해야 합니다. 전송이 끝난 뒤에도 화면 뒤에서는 블록 포함 여부와 finality를 확인하고, 되돌림(reorg)이나 누락된 이벤트를 처리하고, 그 결과를 내부 기록과 맞추고, 특정 시점의 잔액과 가치를 사후 감사 시점에 다시 설명할 수 있어야 합니다.

이용자에게는 한 번의 송금이지만, 금융기관에게는 하나의 온체인 운영 과정입니다. 기관은 월렛과 키를 그대로 통제하고, 그 아래 온체인 운영은 람다256의 인프라 플랫폼 노딧(Nodit)의 Wallet Node가 담당합니다.

직접 구축하던 운영 부담을 관리형 인프라로

Wallet Node를 검토하거나 도입하는 금융기관이 실제로 보는 것은 기능 목록이 아니라, "직접 할 때와 무엇이 달라지는가"입니다.

RPC 대응부터 노드 동기화 관리, failover, 트랜잭션 상태 추적, 입출금 모니터링, 과거 데이터 조회까지 내부 팀이 계속 책임져야 합니다. 이 영역들을 각각 다른 시스템으로 구축하면 개발할 것뿐 아니라 운영할 것도 늘어납니다.

Wallet Node는 이 영역을 관리형 인프라로 가져갑니다.

Wallet Node가 줄이려는 것은 API 호출 횟수가 아닙니다. 팀이 직접 고르고, 연결하고, 운영하고, 장애 원인을 찾아야 하는 온체인 인프라의 범위입니다.

그리고 이 과정에서 기존 월렛, 키 관리, 원장 시스템을 바꿀 필요는 없습니다. 월렛 백엔드, MPC·HSM·KMS, 원장·ERP는 기관이 그대로 두고, 그 아래 트랜잭션·데이터·이벤트·노드 인프라만 Wallet Node가 제공합니다.

무엇이 필요한지, 이미 정리된 구성에서 시작

디지털자산 월렛을 처음 준비하는 팀에게 가장 어려운 질문은 "API가 있는가"가 아닙니다.

"우리 서비스에는 무엇이 필요한가." 여기서부터 시작합니다.

RPC가 필요하다는 것은 알지만, 어떤 노드 구성이 필요한지, 송금 전 어떤 데이터를 확인해야 하는지, 입금을 어떻게 감지할지, finality를 어디까지 볼지, 과거 잔액과 거래 기록은 어떻게 가져올지 하나씩 정해야 합니다. 기능을 찾았다고 끝나지도 않습니다. 서로 다른 API와 노드, 데이터 시스템을 하나의 Wallet Backend 안에서 연결하고, 실제 환경에서 함께 도는지 검증해야 합니다.

대형 증권사를 비롯한 금융기관의 디지털자산 프로젝트를 지원하며 본 것도 이 지점이었습니다. 서비스 형태는 달라도 현장에서 나오는 질문은 상당 부분 반복됐습니다.

송금 전에는 —

• 이 트랜잭션이 정상 실행될지 미리 확인할 수 있는가.
• 예상 수수료는 얼마인가.
• 이 주소는 누구의 주소인가.

송금할 때는 —

• 서명된 트랜잭션을 어떤 노드로 보내야 하는가.
• 노드 동기화가 늦어지거나 장애가 나면 어떻게 되는가.
• 같은 트랜잭션이 중복 처리되지는 않는가.

송금한 뒤에는 —

• 체인에 실제로 포함됐는가. 성공했는가.
• 언제 최종 확정됐다고 볼 수 있는가.
• 입출금 이벤트를 실시간으로 받을 수 있는가.

운영과 결산에서는 —

• 특정 시점의 잔액과 거래 내역을 다시 조회할 수 있는가.
• 온체인 기록을 내부 원장과 맞출 수 있는가.
• 과거 처리 결과를 다시 확인할 수 있는가.

Wallet Node는 임의로 고른 인기 API 묶음이 아니라, 금융기관이 실제로 요청한 구성을 하나로 정리한 것입니다. 그래서 도입의 시작점이 달라집니다. 어떤 온체인 API가 필요한지부터 조사하는 대신, 우리 서비스에는 어떤 Wallet Node 기능을 연결하면 되는지부터 시작할 수 있습니다.

송금 후 네 단계의 트랜잭션을 한 번에 운영할 수 있는 구조

Wallet Node의 기능을 API 목록으로 보면 복잡합니다. 실제 월렛 업무 흐름으로 보면 네 단계로 정리됩니다.

검증(Validate): 송금 전 사전 검증

금융 서비스에서는 트랜잭션을 보내고 나서 오류를 발견하기보다, 보내기 전에 확인하는 쪽이 중요합니다.

Wallet Node로 트랜잭션 실행 결과를 미리 시뮬레이션하고, 예상 수수료를 확인하고, 목적지 주소 정보를 조회할 수 있습니다. 예를 들어 이용자가 출금 주소를 입력했을 때, 주소만 보여주는 대신 확인 가능한 상대방 정보를 함께 보여줄 수 있습니다.

Transaction Simulation · Fee Estimation · Account Labels · Pre-submission Validation

전송(Execute): 서명 이후 트랜잭션 전송

MPC나 HSM에서 서명했다고 송금이 끝나는 것은 아닙니다. 서명된 트랜잭션을 정상 노드에 전달하고, nonce와 중복 요청을 관리하고, 안정적으로 처리할 경로를 골라야 합니다.

특정 RPC Endpoint 하나에 기대는 구조는 운영 리스크가 됩니다. 노드 동기화 상태나 장애 여부를 보지 않고 요청을 보내면, 이용자가 보는 월렛 상태와 실제 블록체인 상태가 어긋날 수 있습니다. 서명은 기관의 영역으로 남기고, 그 이후 전달 구간을 온체인 인프라가 받칩니다.

Signed Transaction Submission · Routing · Nonce Handling · Deduplication

추적(Observe): 포함·finality 상태 추적

트랜잭션을 제출했다는 사실만으로 이용자에게 완료를 보여줄 수는 없습니다. 실제 블록에 포함됐는지, 결과는 성공인지, 어느 수준까지 finality가 확보됐는지 계속 확인해야 합니다. reorg로 이미 관찰한 상태가 달라지기도 합니다.

입금 모니터링도 같은 문제입니다. Wallet Backend가 모든 블록을 반복 조회할 필요 없이, 필요한 주소와 이벤트를 기준으로 온체인 변화를 서비스 로직에 연결할 수 있습니다.

Transaction Result · Finality · Reorg Handling · Webhooks · Real-time Streams

정합(Reconcile): 내부 원장 정합과 감사 대응

금융기관에게는 여기서 한 단계가 더 남습니다. 블록체인에서 거래가 끝난 것과 금융기관의 업무가 끝난 것은 같지 않습니다.

감사에서 "이 시점의 이용자 잔액이 왜 이 값이었습니까"라고 물었을 때, 다시 설명할 수 있어야 합니다. 현재 잔액을 조회하는 것만으로는 부족합니다. 그 시점의 온체인 상태, 해당 트랜잭션, 당시 원화 환산 가치, 처리 이력, 내부 원장과의 연결을 재현할 수 있어야 합니다.

Wallet Node는 이를 위해 잔액, 전송 내역, 과거 상태 등 월렛 운영에 필요한 Indexed Data를 제공하고, 특정 시점의 원화 환산 가치를 재현할 데이터를 함께 지원합니다. 요청·처리 기록은 감사 증거 재현과 reconciliation 과정을 뒷받침합니다.

Balances · Transfers · Historical Data · Transaction-time KRW Valuation · Request/Processing Logs

이 데이터는 기관의 Ledger → ERP → Reconciliation → Audit workflow로 이어집니다. 단순 RPC가 현재 상태 조회에 초점을 둔다면, 금융기관의 월렛은 그 결과를 내부 금융 기록과 어떻게 연결할지까지 봐야 합니다. Wallet Node가 Node Access에서 멈추지 않고 Data와 Reconciliation까지 함께 구성하는 이유입니다.

거래소 수준의 장애대응 시스템, 어떻게 운영하는가

금융기관이 온체인 인프라를 검토할 때 가장 먼저 묻는 질문이자, 도입 여부를 가르는 기준입니다. 고객 자산을 다루는 서비스에서 운영 신뢰성은 부가 기능이 아니라 전제이기 때문입니다.

이용자 자산을 다루는 서비스에서는 특정 노드나 데이터 시스템의 문제가 곧바로 입출금 지연, 잘못된 상태 표시, 내부 운영 부담 증가로 이어집니다. 그래서 인프라 안정성은 부가 기능이 아니라 도입의 전제입니다.

노딧은 국내 금융 서비스의 서비스 연속성과 안정적인 응답 환경을 고려해 국내 이중화 IDC 기반 인프라를 운영합니다. 두 개의 IDC가 있다는 사실보다 중요한 것은 장애 상황에서 이 구조가 어떻게 작동하는가입니다.

• 국내 이중화 IDC — 서비스 연속성을 고려한 이중화 구조
• Sync-aware Routing — 요청을 처리할 노드의 동기화 상태를 고려
• Automatic Failover — 특정 인프라에 문제가 생기면 다른 경로로 전환
• 24×7 Operations · SLA · Request Logs — 프로덕션 운영 요구와 사후 추적 지원

즉 Wallet Node의 신뢰성은 특정 API 기능이 아니라, 이중화 인프라 → 노드 상태 인식 → 라우팅 → failover → 모니터링 → 24×7 운영으로 이어지는 운영 구조입니다. 

무장애를 약속하기보다, 장애가 날 수 있다는 전제에서 서비스 연속성을 설계하는 것이 금융기관용 블록체인 인프라의 기준입니다. 여기에 SOC 2 Type II 인증 기반의 보안 통제와 멀티체인 인프라가 이 운영 구조를 함께 뒷받침합니다.

이미 국내 대형 금융기관 프로덕션에 적용 중

Wallet Node는 "월렛에 이런 API가 있으면 좋겠다"는 가정에서 만든 제품이 아닙니다. Nodit이 금융기관의 디지털자산 프로젝트를 지원하며 반복해서 받은 요구사항을 종합해 하나의 제품 구조로 정리한 결과입니다.

어떤 기관은 송금 전 Transaction Simulation이 필요했고, 어떤 기관은 실시간 입출금 모니터링을 고민했습니다. 또 다른 기관에서는 특정 시점의 온체인 데이터를 내부 시스템과 연결하는 것이 핵심 과제였습니다. 요구는 달라 보여도 결국 하나의 흐름으로 이어집니다. 거래 전에 확인하고, 안정적으로 전달하고, 결과를 계속 관찰하고, 금융 시스템의 기록으로 연결하는 것입니다.

현재 대형 증권사를 포함한 금융기관의 디지털자산 인프라 환경에 Wallet Node가 프로덕션으로 적용되고 있으며, 공개 가능한 고객 사례는 협의를 거쳐 순차적으로 소개할 예정입니다.

월렛을 준비하고 있다면, 인프라부터 함께 고도화

디지털자산 월렛을 처음 준비하는 단계라면 어떤 API를 고를지부터 정할 필요는 없습니다.

먼저 어떤 월렛 모델을 준비하는지, 어떤 네트워크와 자산을 지원할지, 어떤 트랜잭션 흐름이 필요한지, 출시 이후 어떤 수준의 운영 환경이 필요한지 확인하면 됩니다. 그 내용을 바탕으로 필요한 노드·API·데이터·이벤트 인프라를 어떻게 구성할지 검토를 지원합니다.

기존 월렛을 운영 중인 경우에도 마찬가지입니다. 새로운 네트워크를 추가하거나, 기존 RPC·데이터 인프라의 운영 부담을 줄이거나, 트랜잭션 모니터링과 정산(reconciliation) 영역을 보완하는 방향으로 적용 범위를 검토할 수 있습니다.

커스터디와 논커스터디는 단순한 기능 차이가 아닙니다.

누가 키와 자산을 관리하는지, 누가 트랜잭션을 승인하는지에 따라 필요한 아키텍처가 달라지고, 관련 규제와 라이선스도 국가와 서비스 구조에 따라 별도 검토가 필요합니다. 어떤 모델을 택할지는 기관이 결정하고, 노딧의 Wallet Node는 그 결정 위에서 필요한 온체인 인프라를 연결합니다.

람다256(Lambda256)은 두나무의 블록체인 연구소에서 출발해 2019년 설립된 블록체인 전문 기업으로, 글로벌 시장을 겨냥한 블록체인 인프라 플랫폼 노딧(Nodit), 온톨로지 기반 데이터 분석 솔루션 클레어(CLAIR), 그리고 기관용 스테이블코인 통합 플랫폼 스코프(SCOPE)를 중심으로 블록체인 기술의 상용화와 금융 데이터 생태계 조성을 선도하고 있습니다.

도입 문의