2,000원 이벤트가 수십조 ‘유령코인’이 된 이유
이번 빗썸 오지급 이슈를 보면서 가장 많이 받은 질문은 거래소가 실제로 가지고 있지도 않은 비트코인이 어떻게 계정에 찍히고, 그게 실제로 거래까지 될 수 있냐는 것이었는데요.
과거 국내 및 해외 거래소에서 마케팅/전략 팀장으로 근무하며 경험했던 운영구조를 바탕으로 오지급 사태에 관한 궁금하신 부분들 정리해 보았습니다.
사건의 발단.
빗썸에서 발생한 이번 사고는 이벤트 참여자에게 지급해야 할 금액을 잘못 입력하면서 시작되었습니다. 직원의 실수로 2,000원 대신 2,000 비트코인(BTC)이 지급이 되었는데요, 거래소의 자산 관리 시스템과 준비금 증명 방식에 대한 근본적인 의문을 제기했습니다.
사건이 거래소의 운영 구조에서 비롯된 문제였던 만큼, 자칫 비트코인 자체의 신뢰 문제로까지 확대 해석되지 않을까 하는 우려가 들었습니다.
그래서 이번 글에서는 중앙화 거래소가 어떤 방식으로 장부와 자산을 관리하는지 구조적인 측면에서 차분히 짚어보고자 했습니다
Q. 거래소는 실제로 없는 코인을 장부상으로 만들 수 있나?
대부분의 가상자산 거래소(CEX)에서는 고객이 입금한 코인을 거래소의 공용 지갑에 보관하고, 사용자 계정에는 내부 장부 잔고(DB Balance)만 기록합니다.
즉, 사용자 화면에 보이는 코인은 온체인 자산이 아니라 거래소 DB입니다. 그래서 운영과정에서 이벤트 지급, 에어드롭, 보상, 내부정산 같은 기능은 온체인 전송 없이 장부 잔고를 증가시키는 방식으로 처리되는 경우가 많습니다.
쉽게 말해, 블록체인 거래는 수수료가 발생하고 처리시간이 걸리다 보니 매 거래마다 온체인 전송을 하기 어렵습니다. 따라서, 대부분의 거래소에서는 거래는 내부 장부 지갑으로 빠르게 처리하고, 실제 코인 이동은 입출금 시점에서만 수행핸다고 볼 수 있습니다.
정식적으로는 이벤트 지급 시 이벤트용 자산을 내부 이벤트 계정에 먼저 발행(차변/대변)하고 이후 사용자 계정으로 입금처리하는 복식부기 형태의 내부 장부 처리가 이뤄지는데요. 총량도 관리하고, 회계 추적하고 감사 로그가 모두 남겨집니다. 근데, 시스템적으로 허수가 있었던 것 같습니다. 100만 원 미만 건들은 굉장히 소액이다 보니 이벤트 전용 계정을 거치는 절차나 추가 승인 단계가 빠졌을 수도 있습니다.
Q. 실제 이벤트 지급은 어떻게 진행되는 거길래, 이런 거죠?
마케팅 이벤트나 리워드 지급 프로세스는 모든 시스템과 팀이 엮여있습니다
회사 시스템마다 다르겠지만. 혼자서 실수를 했다고 보기 어렵습니다. 이벤트가 기획단계에서부터 당첨자 조건과 지급 기준 정의하고, 총 지급 물량을 정의합니다. 이벤트 종료 후, 대상자 추출을 위해 쿼리를 돌려 지급 대상자를 선별합니다. 그때, 리워드 지갑하기 위해 기안 올리고, 지출결의서도 준비합니다. 이 과정에서는 보통 마케팅팀+개발팀+재무팀+회계팀 함께 검토하는 구조로 진행됩니다.
쿼리를 보통 이벤트마다 바꾸지 않고, 이미 짜있는 쿼리에서 수량이나 코인명을 변경하게 되는데, 마지막에 오입력을 했을 수도 있습니다.
다만, 마지막 지급 단계가 잘못되었다고 하더라도 여러 팀이 엮여 있기 때문에 수차례 체크가 될 것입니다. 개인이 잘못했다기보단, 조직에서 충분하게 검토가 되지 않았던 케이스일 것 같습니다.
Q. 왜 온체인 자산과 장부 잔고가 분리되는 걸까요?
거래소 자산이 내부지갑에서 이동되는 구족이기 때문에 리워드 지급 시에는 보통 3가지 시점을 나눠서 확인합니다. 지급시점, 온체인 반영시점, 시세 기준 반영 시점 (CMC 기준) 반영 여부를 함께 확인하게 됩니다. 즉, 장부상 잔고 생성과 실제 블록체인 이동은 동시에 일어나지 않는 경우가 많습니다.
정석대로 하자면, 시스템 상으로 이벤트용 원화, 비트코인 먼저 내부잔고에 발행하고, 그다음에 입금처리하는 복식부기 방식입니다만, 지금은 단순 입금내역 처리가 된 것으로 보입니다. 그러니까 위탁하고 있는 비트코인보다 보유물량 12배 넘는 게 나온 것 같아 보이고요.
이벤트에 따라, 지원 네트워크를 (ETH, BSC, 자체체인인지) 확인하고, 멀티 네트워크 여부를 확인합니다. 그리고 해당 2차 주소나 커스터디나, 지갑팀 공유를 하게 됩니다. 코인 프로필 등록, 공지사항 업로드까지 이벤트 일정 일주일 전에 사전 준비가 다 됩니다.
Q. 왜 시스템이 2,000 BTC 지급을 막지 못했는지? 총 발행량, 보유량 초과 지급인데 경고가 없었는지?
흠.. 내부통재 시스템 상 거래소 내부 데이터베이스에서 충분히 막힐 수 있었을 거라고 생각됩니다. 이상칙 탐지될 것이라서요.
승인 프로세스에서도, 분명히 여러 번 지급결제가 나가기 위해 서류 작성하고 여러 팀이 나눠지게 될 테니니 혼자서 독립적으로 잘못했다고 보기 어려울 것 같습니다. 이벤트 스크립트가 잘못되었건, 테스트 권한이 잘못 넘겨져 있건 무언가 프로세스상 문제 있었을 것 같습니다.
해외 거래소의 방식 (머클 트리): 해외 거래소들은 머클 트리(Merkle Tree) 방법을 주로 사용합니다. 이 방식은 해시값을 활용해 익명화하고 합산한 뒤 검증하는 방식으로, 두 가지 이상의 방식으로 동시에 증명하여 안정성을 높입니다.
국내 거래소들도 해외 방식처럼 온체인 지갑 자산이 고객 예치량 이상으로 있는지를 암호학적으로 증명하는 기술을 도입해야 신뢰성을 얻을 수 있습니다
마치며.
일부에서는 빗썸 관계자가 허점을 알고 외부 MM이나 관계자의 고의 개입 가능성을 이야기하지만, 거래소가 회수에 실패할 경우 민사나 형사 문제로 확대될 수 있는 사안입니다. 그 정도의 법적, 재무적 리스크를 감수하면서 의도적으로 이런 사고를 만들 주체는 현실적으로 존재하기 어렵다고 생각합니다
이번 사건을 특정 개인의 실수로만 설명하기는 어렵다고 생각합니다. 이벤트 설계, 지급 모듈, 권한 구조, 보유량 검증 로직 등 여러 단계의 통제 장치가 동시에 느슨해졌을 때 비로소 이런 상황이 발생한다고 봅니다.
그래서 이 문제의 본질은 “누가 입력을 잘못했냐, 버튼 잘못 눌렀느냐”가 아니라, 소액 이벤트 기준으로 설계된 시스템과 내부 통제가 잘 안 된 시스템인 것 같습니다.
이번 사안은 가상자산 자체의 문제라기보다, 관리하는 중앙화 거래소의 운영 구조와 내부 통제의 한계를 드러낸 사건에 가깝습니다.
괜히 이번 일을 계기로 비트코인이나 가상자산 전반에 대한 신뢰까지 함께 낮아지지 않길 조심스럽게 바라봅니다. 오히려 더 견고한 운영 구조와 실질적인 내부 통제 기준을 마련하는 계기가 되기를 기대합니다.