코인 전송, 은행 송금과는 무엇이 다를까?
가상자산 회계 실무이야기 5편
은행 송금과는 완전히 다르다
지난 글에서는 법인 지갑의 키를 어떻게 생성하고 보관할지에 대해서 다루었다. Saferoom에서 오프라인으로 키를 만들고, 멀티시그 구조로 권한을 분산하며, 원본과 백업을 분리 보관하는 방법까지 살펴보았다.
이제는 그렇게 생성한 지갑을 이용하여 실제로 가상자산을 전송할 때의 이야기다.
가상자산 지갑은 은행계좌와 유사하지만 근본적으로 다른 특성을 가지고 있다. 가상자산 내부통제에 있어 가장 크게 영향을 미치는 두 가지 요소는 다음과 같다.
익명성: 주소만 보고는 상대방의 신원을 확인할 수 없다.
비가역성: 한 번 전송하면 되돌릴 수 없다.
일반 법인이 회사 내부에 자체 가상자산 내부통제 프로세스를 수립하는 경우에는 이 두 가지 문제를 해결하기 어렵다. 따라서 통제를 설계할 때 두 특징을 고려하여 리스크를 최소화할 수 있어야 하며, 은행 송금에서는 필요하지 않은 별도의 통제가 필수적이다.
되돌릴 수 없기 때문에 더 조심해야 하는 것들
주소 검증: 한 글자 차이로 전액 손실
은행 계좌번호는 입력하면 유효한 계좌번호인지 여부와 누구의 계좌인지 표시가 되어 입력한 계좌번호가 맞는지 바로 확인할 수 있다. 하지만 가상자산 주소는 그 형태가 계좌번호보다 더 복잡할 뿐더러 유효성을 검증할 수 있는 방법이 없다. 잘못된 주소를 입력하여 전송해버릴 경우, 자산이 그대로 소실되어 버릴 위험이 있는 것이다.
예를 들어 0x742d...7d45와 0x742d...7d46 이 두 지갑주소는 끝자리만 살짝 다른데, 잘못 입력하여 거래를 진행한 경우 되돌릴 수 없다. 전송 과정에서 여러 인원이 크로스체크하고 더블체크를 할 수 있게 절차를 수립하는 것이 필요하다.
같은 이름, 다른 자산
같은 토큰 이름(티커)이더라도 네트워크가 다르면 완전히 다른 자산이라 생각하면 된다.
대표적인 예: USDT(이더리움) vs USDT(트론) vs USDT(BSC)
이더리움 네트워크의 USDT를 트론 주소로 전송하면 그 자산은 영영 찾을 수 없게 된다.
전송 전 반드시 상대방과 "어느 체인의 토큰인지"를 명시적으로 확인해야 한다. 중앙화 거래소 입금 시 체인 선택 옵션을 잘못 고르는 것도 흔한 사고 원인이다.
소액 테스트, 번거롭지만 필수
따라서 새로운 주소로 전송할 때는 반드시 다음 절차를 따라야 한다:
신원 확인: 상대측 신원이 확인된 메일 등으로 주소 확인 메시지를 받은 다음 거래를 진행할 것
소액 전송: 1~10달러 상당의 소액 가상자산을 먼저 전송해 정상 수령 여부를 확인
이때 정상 수령 여부는 신원이 확인된 메일 등으로 회신받는 방식으로 진행한다.
만약 해당 회사 내에서 가상자산 전송이 빈번한 편이라면 이 절차가 상당히 귀찮게 느껴질 수도 있다. 가상자산 업계 특성상 텔레그램 등으로 가볍게 커뮤니케이션하는 경우가 많은데, 텔레그램으로 전달받은 지갑주소로 큰 금액을 그냥 전송해버렸다가 사고가 난다면? 끔찍할 것이다. 이런 사고를 방지하기 위해 귀찮더라도 소액 테스트는 진행하는 것이 권장된다.
만약 절차를 조금 간소화하고 싶다면, 처음으로 거래하는 지갑주소에 대해서는 소액 테스트를 진행하고, 테스트를 통해 한번 검증된 지갑주소를 화이트리스트로 등록(거래처 등록)하여 이후 거래에 대해서는 소액 테스트를 생략할 수도 있다.
예상치 못한 변수들에 대비하기
가스비까지 고려한 잔고 확인
Transaction을 일으키기 전에 Wallet 잔고를 확인하여 전송에 필요한 코인, 토큰보다 많은 양을 보유하고 있는지 확인해야 한다. 가스비까지 고려한 여유분이 있어야 한다. 전송하는 자산과 가스비 자산이 다를 경우 각각 잔고 확인이 필요하다.
가스비가 부족하면 거래가 실패하고, 가스비만 소모된다. 토큰은 전송되지 않지만, 수수료만 날아가는 셈이다. 가스비는 보통 소액이 들기 때문에 간과하기 쉽다. 절차상 전송할 양이 충분한지 잔고를 확인할 때 가스비까지 같이 체크하는 통제를 추가하면 간단히 해결할 수 있다.
네트워크 혼잡도도 체크
네트워크 상태에 따라 토큰의 전송 속도가 다를 수 있다. 보통 해당 체인에 거래가 많을 경우(혼잡할 경우) 가스비가 높게 책정된다. 동일한 양을 보내기 위해 가스비도 많이 지불하는 것도 손해지만, 문제는 간혹 비정상적인 이슈가 있을 때 거래 승인이 지연될 때가 있다는 점이다.
실제로 FTX 이슈로 한참 비트코인 가격이 하락하고 있을 때 모든 사람이 거래소로 BTC를 보내 매도를 하는 와중에 회사에서 사업 목적으로 BTC 전송이 필요한 때가 있었다. 거래를 진행했음에도 이틀 이상 승인이 나지 않아 상대방이 수취를 못하는 상황이 있었는데, 그때 혹시 잘못된 주소로 보낸 건 아닌지, 이대로 코인이 소실되는 것은 아닌지 상당히 불안했던 기억이 있다. 개인 자산이 아닌 상당한 규모의 회사 자산이 이동하는 것이다 보니 더욱 각별히 조심해야 할 필요가 있었다.
네트워크 혼잡도도 사전에 체크하여, 되도록이면 혼잡한 시간대를 피해서 전송 업무를 진행하는 것이 좋다.
승인권자의 물리적 참여가 반드시 필요한 이유
은행 자금 집행과는 달리 법인의 가상자산 전송은 단순한 온라인 결재로 끝나지 않는다.
콜드월렛에 보관된 자산은 직접 서명이 필요하다. 그리고 그 콜드월렛은 Saferoom이라는 별도의 공간에 모두 보관해두었다. 따라서 온라인 뱅킹처럼 각자 자리에서 권한으로 처리할 수 없는 구조다.
중요한 지갑일 경우 멀티시그로 생성해야 한다고 언급한 바 있다. 한 사람이 단독으로 대량의 자산을 움직일 수 없는 구조여야 하는 것이다.
따라서 하나의 Transaction을 위해서라도 아래와 같이 여러 인원의 스케줄링이 필요하다.
Saferoom을 열 수 있는 사람
지갑 운영자: 전송 셋팅 등 작업을 진행할 사람
멀티시그 Signers
실무를 진행하다 보면 이 모든 인원들의 스케줄을 맞추는 것이 현실적으로 쉽지 않다. 심지어 Signer들의 경우에는 일반 실무자보다는 회사 내 승인 권한이 있는 사람들을 지정하는 것이 권장되므로 더욱 어렵다.
이런 현실적 어려움 때문에 최근에는 QR Code 방식, HSM 원격 접근, MPC, TSS 등 멀티시그 구조를 유지하면서도 원격에서 서명할 수 있는 기술들이 많이 등장하고 있다. 하지만 이런 기술을 고려함에 있어서 보안과 편의성은 트레이드오프 관계에 있다는 점은 이해하고 있어야 한다. 회사가 더 중시하는 영역이 안정성인지 아니면 편의성인지 따져보고, 회사가 핸들링하는 가상자산의 규모 수준을 고려하여 감사인과 잘 협의한다면 이런 기술들을 활용한 중간지점 타협안을 적용해볼 수도 있다.
전송 완료가 끝이 아니다
여러 인원이 한 장소에 한 시점에 모여서 더블체크, 크로스체크를 하여 어떻게든 가상자산을 전송했다고 하자.
전송이 완료되면 Etherscan 같은 explorer 사이트에서 트랜잭션 상태를 확인해야 한다. TxHash를 통해 실제로 블록체인에 기록되었는지, 컨펌을 받았는지 확인한다. 물론 상대방이 제대로 수취하였는지 확인하는 것도 반드시 필요하다.
etherscan explorer감사인은 독립적인 Node(Endpoint node)를 통해 거래 성사 여부를 확인하라는 요구를 하기도 한다. 하지만, 일반 회사에서 거래 성사 확인만을 위하여 독립적인 노드로 직접 블록체인 데이터를 조회한다는 게 쉬운 일은 아니다. 만약 감사인이 요구하는 상황이라면 대안으로 Etherscan 외에 Blockchair 등 다른 explorer에서도 교차 확인하는 절차를 제시해볼 수도 있다.
가상자산 입금 시 주의사항
입금의 경우 자산이 들어오는 것이기 때문에 출금 대비 신경 써야 할 부분이 확실히 적다. 하지만 실무적으로 알아두고 유의해야 할 점이 있다.
예를 들어 USDT가 모르는 주소로부터 입금되었다고 하자. 잘 살펴보면 진짜 USDT가 아닐 가능성이 높다.
토큰을 만드는 것은 생각보다 쉽다. 악의적인 사용자들이 USDT와 유사한 가짜 토큰을 만들어 랜덤으로 지갑주소에 뿌린다. 상대방이 실수로 그 "가짜 USDT"를 보낸 주소로 진짜 자산을 전송하기를 바라는 피싱인 것이다.
누가 가스비까지 들여가며 이런 짓을 할까?라고 생각할 수 있지만, 실제로 걸려드는 사람들이 있으니 이런 피싱이 판을 치는 것이다. 개인들은 최근 입금된 주소를 보고 "아, 이 주소로 보내면 되겠구나" 하며 자산을 송금하는 실수를 할 수 있다.
회사에서는 이런 실수는 용납되지 않는다. 지금까지 구축한 통제 절차(화이트리스트, 소액 테스트 등)를 따른다면 이런 실수는 발생하지 않을 것이다.
그럼에도 Explorer에서 조회되는 법인 지갑주소의 거래내역 중 피싱이 섞여 있을 수 있다는 점은 인지하고, 혹시라도 걸려들지 않게 조심해야 한다.
법인 가상자산 전송의 전체 프로세스
지금까지 은행과는 다르게 가상자산 내부통제 프로세스에서 별도로 필요한 통제에 대해 이야기했다. 지금까지 설명한 내용을 종합하면, 법인의 가상자산 전송은 다음과 같은 일련의 프로세스로 진행된다.
1단계: 전송 요청
현업에서 전송 필요 건이 생길 경우 거래 요청서를 작성한다.
거래 요청서 내에는 목적, 토큰 종류, 체인, 수량, 전송 주소 등이 기재되어야 한다.
2단계: 내부 결재
적절한 승인권자의 내부 승인이 이루어져야 한다.
3단계: 전송 준비
전송 작업을 위해 필요한 인원의 일정 조정, 작업 계획서 작성 등
4단계: 전송 작업
지정한 일자, 시간에 Saferoom을 오픈하고 월렛, PC를 셋팅하여 송금 작업을 준비한다. 이후 멀티시그 서명자의 순차적 승인이 이루어진 후 실제 전송을 실행한다.
5단계: 전송 결과 확인
Explorer 확인, 상대방 수령 확인 등을 통해 전송이 제대로 이루어졌는지 확인한다.
6단계: 결과 승인 및 문서화
전송 완료를 보고하고 관련 기록을 보관한다.
안전이 최우선이다
은행계좌 실명제가 도입되기 전을 생각해보면 현재 가상자산 송금의 상황을 쉽게 이해할 수 있다. 그 시절에는 계좌 추적이 어려워 송금 사고나 사기가 지금보다 훨씬 빈번했다.
가상자산 송금은 그때보다도 더 취약할 수 있다. 탈중앙화 성격에서 오는 익명성과 비가역성이라는 특성 때문이다.
"한번 나가면 되돌릴 수 없다"라는 전제를 항상 염두에 두고 철저한 내부통제를 갖춘 상태에서만 송금해야 한다. 번거롭더라도 안전이 최우선이다.
다음 편에서는 이렇게 발생한 거래를 회계장부에 어떻게 기록하고 회계감사에 어떻게 대응하는지에 대해서 다룰 예정이다.
