고객 계정은 어떻게 블록체인 서명으로 이어질까
고객 A가 금융 서비스에 로그인해 B에게 토큰 10개를 보낸다. 업무 서버는 로그인한 사람이 A라는 사실을 안다. 그러나 블록체인 거래에 필요한 것은 A의 로그인 정보가 아니라, 토큰을 보내는 주소 A와 그 주소의 거래에 사용할 서명이다.
여기에는 한 번의 연결로 묶기 어려운 질문이 있다. A의 요청에서 어떤 지갑을 선택하며, 그 지갑으로 이번 거래를 실행해도 된다는 판단은 누가 하는가?
BXB는 업무 시스템과 블록체인 사이에서 이 연결을 담당하는 미들웨어다. 기관이 키를 관리하고 서버에서 서명을 실행하는 수탁형 지갑 경로를 제공한다. 이 글에서는 토큰 10개를 보내는 작은 예제로 고객 계정, 지갑, 주소와 서명키의 관계를 따라간다.
토큰 10개를 보내는 데 필요한 연결
한 EVM 네트워크에 토큰 T가 있고, A와 B가 각각 자신의 주소를 가지고 있다고 하자. EVM은 이더리움과 호환되는 컨트랙트 실행 환경이다. 전송 전 토큰 잔액은 A가 100개, B가 0개다. 여기서는 BXB 서버가 지갑에 연결된 키로 거래를 서명해 제출하는 경로를 따라간다.
목표는 단순하다.
| 고객 | 전송 전 | 전송 후 |
|---|---|---|
| A | 100 | 90 |
| B | 0 | 10 |
여기서는 토큰의 발행·소각·별도 전송 수수료와 다른 동시 거래가 없다고 가정한다. 네트워크 수수료에 필요한 기본 코인은 따로 준비돼 있다. 이 조건에서 동작을 살펴보기 위한 설명용 예제다.
업무 시스템은 A를 인증하고, A가 이 토큰을 B에게 10개 보낼 수 있는지 판단한다. 그다음 A에게 연결된 지갑을 골라 거래를 만들고 서명해야 한다.
고객 A의 전송 요청
↓
업무 시스템의 인증·거래 허가
↓
A에게 연결된 지갑 선택
↓
사용할 네트워크의 주소 확인
↓
차단 정책 확인·거래 서명
↓
블록체인에 제출·실행 결과 확인
↓
토큰 잔액 A 90 / B 10
Polsto에서 BXB로 이어진 회고에서는 이런 연결을 공통 미들웨어로 묶게 된 이유를 다뤘다. 이번에는 그 흐름 중 고객의 요청에서 서명할 지갑과 키를 선택하는 부분을 자세히 살펴보자.
고객 번호와 지갑 별칭은 어떤 관계일까
A의 고객 번호가 C-A라고 하자. 업무 시스템은 이 고객을 BXB의 업무용 별칭
customer-a와 연결해 둘 수 있다. BXB 코드에서는 이 별칭을 userKey라고 부른다.
이름에 key가 들어 있지만, 서명에 사용하는 개인키는 아니다.
같은 전송 요청에 등장하는 식별자를 나란히 놓으면 역할이 드러난다. 아래 이름은 모두 설명을 위한 가상의 값이다.
| 식별자와 예시 | 역할 |
|---|---|
고객 번호C-A | 업무 시스템에서 고객을 식별 |
업무용 별칭customer-a | 체인 계열별로 지갑을 조회 |
지갑 식별자W-A | 지갑의 사용 상태와 서명키 연결을 관리 |
| 블록체인 주소 주소 A | 해당 네트워크의 잔액·거래 주체를 식별 |
HSM 키 라벨K-A | 키 보안 장치(HSM) 안에서 사용할 키를 선택 |
고객 번호와 업무용 별칭을 같은 문자열로 정할 수도 있지만, 반드시 같아야 할 이유는 없다. 중요한 것은 업무 시스템이 로그인한 고객과 사용할 별칭의 관계를 관리한다는 점이다.
예를 들어 앱이 요청에 customer-a를 넣었다는 사실만으로 요청자가 A라고 믿어서는 안 된다.
업무 서버가 인증된 고객 정보에서 별칭을 결정하거나, 요청된 별칭이 그 고객에게 허용되는지 확인해야 한다.
다른 고객의 별칭을 알아냈다고 그 고객의 지갑을 사용할 수 있어서는 안 되기 때문이다.
별칭은 지갑을 찾는 데 쓰인다. 로그인한 사람이 누구인지, 그 사람이 이번 전송을 허가받았는지는 업무 시스템이 별도로 판단해야 한다. 키를 선택하는 정보와 키를 사용해도 된다는 근거를 구분하는 것이다.
지갑을 고른 뒤에도 네트워크를 정해야 한다
BXB는 대상 네트워크가 속한 체인 계열과 업무용 별칭으로 사용할 지갑을 찾는다.
체인 계열은 코드에서 namespace라고 부른다. EVM 계열, Solana 계열 등을 구분하는 값이며
고객이나 부서를 구분하는 이름은 아니다.
예를 들어 A의 전송이 EVM 네트워크를 대상으로 한다면, EVM 계열의 customer-a에 연결된
활성 지갑 W-A를 찾는다. 지갑을 등록할 때도 같은 체인 계열에 같은 별칭의 활성 지갑이 이미 있으면
중복 등록을 거부한다. 별칭 하나가 어느 지갑을 선택하는지 분명하게 하기 위한 조건이다.
지갑을 찾았으면 그 지갑에 연결된 해당 네트워크의 주소를 확인한다. BXB는 지갑 자체의 정보와 네트워크별 주소를 나누어 관리한다. 같은 EVM 계열이라도 서로 다른 네트워크는 별도의 원장이므로, 주소 문자열이 같더라도 어느 네트워크의 잔액을 읽고 거래를 보낼지 정해야 한다.
이 예제에서 선택 결과는 “지갑 W-A”만으로 끝나지 않는다.
토큰 T가 있는 네트워크에서 주소 A의 거래를 실행한다는 데까지 구체화돼야 한다.
전송할 토큰의 컨트랙트, 받는 주소 B와 수량 10도 함께 정해져야 한다.
거래를 허가하는 일과 키를 보호하는 일
지갑을 찾았다는 사실은 이번 거래를 승인했다는 뜻이 아니다. 이 연결에는 서로 다른 판단이 들어간다.
업무 시스템은 A가 로그인한 고객인지, A에게 전송 권한이 있는지, 금액과 수신자가 업무 규칙을 만족하는지 판단한다. 필요한 결재나 거래 한도가 있다면 이 단계에서 확인한다.
BXB의 이 전송 경로는 사용할 지갑이 활성 상태인지와 업무용 별칭의 차단 여부를 확인한다. 서명에 필요한 자료를 얻는 경로에서도 지갑에 저장된 별칭의 차단 여부를 다시 확인한다. 업무 서버가 이미 요청을 허가했더라도, BXB에서 그 별칭이 차단돼 있다면 신규 서명을 진행하지 않도록 하는 통제다.
주소를 기준으로 한 검사도 있다. EVM 서명·전송 경로에서는 보내는 주소와 거래가 직접 호출하는 주소의 차단 여부를 확인한다. 토큰 전송에서는 직접 호출하는 주소가 토큰 컨트랙트 T이고, 수신자 B는 함수에 전달하는 입력에 들어간다. 따라서 이 주소 검사를 고객의 수신자·금액 정책 전체로 해석해서는 안 된다. 누가 무엇을 누구에게 얼마나 보낼 수 있는지는 업무 규칙과 함께 판단해야 한다.
이 검사를 통과한 거래에 서명을 제공하는 것이 키 관리·서명 경로의 역할이다. 서명은 해당 거래 내용이 선택한 키로 서명되었음을 확인할 수 있게 하지만, 고객이 화면에서 어떤 의사를 표시했는지까지 판단해 주지는 않는다.
HSM을 쓰면 무엇이 달라질까
HSM(Hardware Security Module)은 암호키를 보호하고 암호 연산을 수행하는 장치다. BXB는 배포 구성에 따라 소프트웨어 키를 사용하는 서명 경로 또는 HSM을 사용하는 경로를 둔다. 여기서는 이 EVM 전송에서 두 방식이 맡는 역할을 비교한다.
소프트웨어 방식에서는 서버의 서명 코드가 키 자료를 사용한다.
HSM 방식에서는 장치 안에 준비된 키를 라벨로 선택하고, 그 키를 사용한 서명 결과를 받는다.
앞의 K-A가 이때 키를 찾는 이름이다. 업무용 별칭 customer-a와 HSM 키 라벨 K-A는
서로 다른 단계에서 쓰이는 식별자다.
업무 요청을 처리하는 쪽은 먼저 지갑과 거래 내용을 결정한다. 그 뒤 서명 경로가 선택된 키로 거래에 서명하고, 블록체인에 제출할 수 있는 형태로 조립한다. 키가 어느 방식으로 보관되는지와 고객의 어떤 지갑을 선택하는지를 나눠 다루는 구조다.
HSM이 키를 보호하더라도, 업무 시스템이 A의 요청에 다른 고객의 지갑을 잘못 연결한 문제를 대신 판단해 주지는 않는다. 수신자나 수량을 잘못 구성한 경우도 마찬가지다. 키 보호는 올바르게 허가된 거래를 구성하는 책임과 함께 갖춰져야 한다.
차단된 고객의 요청은 어디서 멈출까
다시 A가 토큰 10개를 보내는 상황으로 돌아가 보자.
이번에는 요청을 처리하기 전에 customer-a가 BXB의 차단 목록에 등록돼 있다고 가정한다.
A가 업무 서비스에 로그인돼 있고 업무 서버가 전송을 요청하더라도, BXB는 이 전송 경로에서 별칭의 차단 상태를 확인하고 요청을 거절한다. 이 요청을 위한 새 서명과 제출로 이어지지 않으므로, 다른 거래가 없다면 토큰 잔액은 A 100 / B 0으로 남는다.
반대로 차단되지 않은 활성 지갑을 선택하고 필요한 검사를 통과하면, 주소 A에 대응하는 키로 거래에 서명해 제출할 수 있다. 그 거래가 성공적으로 실행된 결과를 확인했을 때 목표했던 A 90 / B 10에 도달한다. 서명했다는 사실만으로 잔액이 바뀐 것은 아니다.
여기서 차단은 신규 전송을 막는 통제다. 이미 서명되거나 제출된 거래를 취소했다는 뜻은 아니다. 지금 막으려는 것이 새로운 키 사용인지, 이미 진행 중인 거래의 처리인지도 구분해야 한다.
고객의 의사를 특정 거래의 서명으로 옮긴다
고객 A가 “B에게 10개를 보낸다”고 결정하면, 업무 시스템은 그 의사와 권한을 확인한다. BXB는 확인된 요청을 구체적인 지갑·네트워크·주소에 연결하고, 전송 경로의 통제를 거쳐 서명을 실행한다. 이 과정에서 고객 번호, 업무용 별칭, 블록체인 주소와 키 라벨은 각자의 역할을 가진다.
이들을 분리해 두면 문제를 볼 때의 질문도 분명해진다. 고객을 잘못 식별한 것인지, 지갑을 잘못 선택한 것인지, 허가되지 않은 거래를 구성한 것인지, 서명키를 보호하지 못한 것인지를 나누어 살펴볼 수 있다.
수탁형 지갑을 업무 시스템에 연결한다는 것은 이 관계를 일관되게 관리하는 일이다. 고객의 요청이 올바른 지갑을 선택하고, 허가된 내용이 그 지갑의 서명으로 이어지도록 만드는 것이다.