비트코인 담보 대출, 맡기지 않는다는 말의 한계

비트코인을 팔지 않고 필요한 돈을 마련하려는 사람에게 ‘담보를 수탁업체에 맡기지 않는다’는 설명은 매력적이다. 업체가 자산을 돌려줄 것이라는 약속에 기대는 대신, 비트코인의 규칙으로 담보를 묶고 되찾을 수 있다면 의존하는 상대가 줄어들기 때문이다. 하지만 자산을 보관하는 업체가 없다는 말은 대출 과정에서 누구의 협력도 필요 없다는 뜻일까?

이 질문에 답하려면 자산의 위치와 사용 권한부터 구분해야 한다. 업체에 맡긴 비트코인도 비트코인 네트워크에 기록된다. 따라서 ‘비트코인이 원래 네트워크에 남는다’는 사실만으로는 누가 담보를 움직일 수 있는지 알 수 없다. 돈을 빌린 사람에게 중요한 것은 코인이 기록된 장소뿐 아니라, 대출을 갚거나 서비스가 멈췄을 때 어떤 조건으로 다시 쓸 수 있는지다.

대출금이 다른 블록체인에서 지급된다면 확인할 문제가 하나 더 생긴다. 그곳의 대출 계약은 비트코인 담보가 실제로 들어왔다는 사실을 어떻게 알까? 담보를 푸는 권한과 입금을 인정하는 근거는 서로 다른 문제다. 한쪽을 잘 설계했다고 다른 쪽까지 해결되는 것은 아니다.

이 관계를 보여주는 사례가 Writz의 대출 설계다. 개발자의 설명에 따르면 이 설계는 비트코인을 담보로 잠그고, 대출금은 비트코인과 별개의 블록체인에서 달러 가치에 연동된 토큰으로 지급한다. 다만 개발자는 이 글이 출시 발표가 아니며, 코드는 시험용 환경인 테스트넷에 있고 보안 감사를 받지 않았다고 밝혔다. 실제 상품의 안전성을 평가하기보다, 비수탁 설계에 어떤 신뢰와 대기 조건이 남는지 살펴볼 사례다.

내 담보라도 혼자 움직일 수는 없다

개인 지갑에서는 보통 자신의 키로 서명해 비트코인을 보낸다. 그러나 대출 담보를 같은 방식으로 다룰 수는 없다. 돈을 빌린 사람이 언제든 담보를 다른 곳으로 보내버릴 수 있다면 돈을 빌려주는 쪽에는 담보가 없는 것과 다르지 않다. 대출에 쓰는 비트코인은 사용자에게 회수 경로를 남기면서도, 대출이 유지되는 동안에는 마음대로 지출하지 못하도록 묶어야 한다.

Writz 개발자가 설명한 담보 해제 경로는 두 가지다. 정상적으로 상환한 뒤에는 사용자와 프로토콜 측이 각각 서명해야 담보를 풀 수 있다. 여기서 프로토콜 측은 담보 해제에 쓰는 서비스 측 키로 서명하는 역할을 말한다. 양쪽 서명이 모두 필요하므로, 설명된 경로에서는 서비스 측도 사용자도 혼자 담보를 움직일 수 없다.

다른 경로는 프로토콜이 사라져 서명을 받을 수 없는 상황에 대비한다. 비트코인 기록이 미리 정한 블록 높이에 도달하면 사용자가 혼자 서명해 회수할 수 있도록 했다. 블록 높이는 기록이 몇 번째 블록까지 쌓였는지를 나타내는 순번이다. 달력의 특정 날짜가 아니라, 비트코인 장부가 정해진 지점까지 이어졌는지를 조건으로 삼는 것이다.

개발자는 기본값을 예치가 확인된 블록에서 약 37일에 해당하는 블록 수가 더 쌓인 시점으로 설명한다. 이는 모든 담보에 적용되는 확정된 달력 기한이라는 뜻은 아니다. 블록이 쌓이는 속도에 따라 실제 시간은 달라질 수 있고, 약 37일은 이 설계가 제시한 기본값이다. 또한 서비스가 멈춘 날부터 새로 37일을 세는 조건도 아니다. 예치 때 정한 회수 시점까지 얼마나 남았는지가 중요하다.

두 경로의 차이는 ‘회수할 권리가 있다’와 ‘지금 회수할 수 있다’의 차이다. 상환을 마쳤어도 상대의 서명이 없으면 정상 해제 경로를 실행할 수 없다. 그렇다고 그 상대에게 무기한 의존하도록 설계한 것도 아니다. 정해진 높이에 도달하면 단독 회수 경로가 열린다. 다만 그때까지는 상대의 협력을 기다리거나 시간 조건이 충족되기를 기다려야 한다.

프로토콜 측 서명 키의 관리도 이 맥락에서 봐야 한다. 개발자는 현재 하나의 키를 하드웨어 보안 장치에 보관한다고 설명했다. 키를 보호하는 장치는 중요하지만, 필요한 서명을 제때 제공한다는 보장과는 다르다. 누가 그 키의 사용을 통제하고, 문제가 생겼을 때 어떻게 복구하는지는 이 설명만으로 충분히 평가할 수 없다. 반대로 키가 하나라는 이유만으로 서비스 측이 혼자 담보를 가져갈 수 있다고 단정해서도 안 된다. 정상 해제에는 사용자 서명도 필요하기 때문이다.

따라서 이 설계가 줄이려는 의존은 ‘상대가 돌려주지 않으면 아무것도 할 수 없는 상태’다. 이를 대신하는 것은 즉시 행사할 수 있는 무조건적인 권한이 아니라, 협력 해제와 시간 조건을 둔 단독 회수다. 비수탁의 가치는 이 차이에 있으며, 사용자에게 남는 부담은 협력이 끊겼을 때의 대기 시간이다.

다른 장부에 있는 계약은 입금을 어떻게 알까

담보를 잠그는 규칙을 마련했다고 곧바로 대출금을 내줄 수는 없다. 돈을 지급하는 계약은 담보가 실제로 들어왔는지 확인해야 한다. 그런데 이 계약은 비트코인이 아닌 다른 블록체인에서 실행되는 프로그램이다. 두 네트워크는 각자의 장부를 유지하므로 비트코인에서 일어난 거래가 대출 계약에 자동으로 전달되지는 않는다.

그래서 누군가 입금 증거를 제출하고, 계약은 그 자료를 검사해야 한다. 이때 자료를 가져온 사람을 반드시 믿어야 하는 것은 아니다. 계약이 증거를 제대로 검증할 수 있다면 제출자는 운반자 역할에 머무를 수 있다. 핵심은 전달자의 신원이 아니라, 무엇을 검사해야 진짜 비트코인 입금이라고 판단할 수 있는지다.

검사에는 서로 다른 두 단계가 필요하다. 먼저 입금 거래가 어느 블록에 포함됐다는 사실을 확인해야 한다. 동시에 그 블록이 계약이 인정할 비트코인 기록에 속하는지도 알아야 한다. 가짜 장부에 거래가 적혀 있다는 사실을 정확히 확인해도 실제 입금을 증명한 것은 아니기 때문이다. 거래 포함 증거의 정확성과 장부 자체의 신뢰도는 따로 따져야 한다.

개발자가 처음 검토한 방식에서는 입금 증거를 내는 사람이 일련의 블록 기록도 함께 제출했다. 비트코인 블록 기록에는 앞선 블록과 연결되는 정보, 블록을 만드는 데 요구되는 계산 난이도 등이 담긴다. 블록을 만들려면 정해진 조건에 맞는 계산 결과를 찾아야 하고, 검증하는 쪽은 그 결과가 조건을 충족했는지 확인한다. 이 과정이 기록을 만드는 데 비용이 들게 한다.

문제는 제출된 기록 안에 적힌 난이도만 기준으로 삼는 데 있었다. 기록을 꾸미는 사람이 아주 쉬운 계산 조건을 골라 블록을 만들고, 그 블록에 적힌 쉬운 조건을 만족했다는 이유로 검증을 통과할 수 있다. 시험을 보는 사람이 문제의 난이도까지 정하고 채점자는 답이 맞는지만 보는 것과 비슷하다. 쉬운 문제를 풀었다는 사실은 원래 요구된 시험을 통과했다는 증거가 아니다.

꾸며낸 블록들이 서로 이어지게 만드는 것도 가능하다면, 앞뒤가 맞는다는 검사만으로는 이 허점을 해결할 수 없다. 계약은 각 기록이 자기 안에 적힌 조건을 만족하는지뿐 아니라, 실제 비트코인 규칙이 그 지점에서 요구하는 조건을 따르는지도 확인해야 한다. 개발자는 낮은 난이도로 만든 체인을 받아들일 수 있다는 이유로 초기 구상을 폐기했다고 설명한다. 이는 실제 자금 피해가 확인됐다는 이야기가 아니라, 검증 방식을 바꾼 이유다.

검증을 강화해도 시작점에 대한 신뢰는 남는다

현재 설명된 방식에서는 관리자가 실제 비트코인의 최근 블록 하나를 기준 블록으로 한 번 지정하고, 대출 계약이 그 뒤에 이어지는 기록을 검증한다. 누구나 새 블록 기록을 제출할 수 있지만, 계약은 이미 저장한 앞선 기록과 연결되는지, 계산 결과가 유효한지, 해당 높이에서 요구되는 난이도를 따르는지 등을 확인한다. 제출자가 임의로 고른 쉬운 조건을 만족하는 것만으로는 통과하지 못하도록 바꾼 것이다.

계약은 블록을 만드는 데 쌓인 계산 작업량도 추적한다. 단순히 블록 개수가 많은 기록을 고르는 것과는 다르다. 쉬운 조건으로 블록을 많이 붙이는 방식과 비트코인이 요구하는 조건에 맞춰 작업을 쌓는 방식에는 차이가 있기 때문이다. 여러 갈래의 기록이 생기면 누적 작업량이 더 큰 쪽을 따르도록 했다는 것이 개발자의 설명이다.

입금 거래의 포함 증거는 이렇게 검증해 저장한 블록 기록과 대조한다. 모든 비트코인 거래 내용을 계약에 보관하는 대신, 제출된 거래가 저장된 블록 안에 들어 있는지 확인하는 구조다. 초기 구상과 달리 매번 제출자가 가져온 자료 묶음 안에서만 진위를 판단하지 않고, 계약이 유지하는 공통의 기록을 바탕으로 입금을 인정한다.

이 변경은 검증을 강화하려는 조치지만, 출발점에 대한 의존까지 없애지는 않는다. 이후 기록이 올바른 규칙에 따라 이어졌다는 확인은 맨 처음 선택한 기준 블록 자체가 올바르다는 증명과 다르다. 지도에서 기준 위치를 정한 뒤 이동 경로를 정확하게 계산해도, 처음 표시한 위치가 맞는지는 별도로 알아야 하는 것과 비슷하다.

후속 기록과 입금 증거를 검사해도, 출발점인 기준 블록은 관리자가 정합니다.

따라서 신뢰가 놓이는 자리도 달라진다. 제출된 자료 내부의 조건에 기대던 판단을 줄이는 대신, 관리자가 정한 기준 블록을 출발점으로 받아들인다. 개발자 역시 이 기준 블록에 대한 신뢰를 어떻게 줄일지 검토를 요청했다. 누가 어떤 절차로 기준을 고르는지, 설정 권한을 어떻게 통제하는지, 잘못된 설정을 어떻게 처리하는지는 공개된 설명만으로 충분히 확인되지 않는다.

이 관리자를 앞서 나온 담보 해제 서명 주체와 곧바로 같은 사람이나 조직으로 묶어서도 안 된다. 한 역할은 대출 계약이 어느 기록을 사실로 인정할지에 관여하고, 다른 역할은 담보를 움직이는 데 필요한 서명을 제공한다. 같은 주체가 맡는지는 확인되지 않았으며, 기준 블록을 설정할 권한이 곧 비트코인을 단독으로 가져갈 권한이라는 뜻도 아니다. 두 역할을 구분해야 검증의 개선과 담보 통제의 문제를 혼동하지 않을 수 있다.

대출을 기다리는 시간과 회수를 기다리는 시간

입금이 블록에 포함됐다는 증거가 있어도 즉시 대출금을 지급할지는 별도의 선택이다. 비트코인에서는 잠시 서로 다른 갈래의 기록이 생길 수 있다. 이후 더 많은 계산 작업이 쌓인 쪽을 따르는 과정에서 최근 기록 일부가 바뀔 수 있으므로, 입금이 담긴 블록 뒤로 기록이 더 이어지기를 기다리는 절차를 둔다.

거래가 담긴 블록을 포함해 몇 개의 블록이 쌓였는지를 세는 것이 확인 횟수다. 개발자는 일반 예치에 6회 확인을 요구하고, 소액 예치에는 3회 확인을 쓰는 빠른 경로도 설계에 포함했다고 설명한다. 더 기다리는 것은 입금 기록이 되돌아가기 어렵게 하려는 선택이지만, 대출금을 받을 때까지 걸리는 시간도 늘린다. 소액 경로는 이 대기를 줄이려는 선택으로 읽을 수 있다.

개발자 자신도 대출 담보에 고정된 확인 횟수를 적용하는 것이 적절한지, 담보액에 따라 기준을 달리해야 하는지 질문했다. 3회와 6회라는 수치만으로 6회면 큰 담보도 안전하다거나 3회 경로는 반드시 위험하다고 결론내릴 수는 없다.

기록이 바뀌는 상황에 대한 처리도 설계에 들어 있다. 개발자는 누적 작업량이 더 큰 갈래가 나타나면 계약이 따르는 기록을 그쪽으로 바꾸되, 한 번의 처리에서 바꿀 수 있는 블록 수에는 상한을 둔다고 설명한다. 입금 증거를 확인하는 일은 거래가 한 번 블록에 들어갔는지만 보는 데서 끝나지 않는다. 어떤 갈래를 따르고, 이후 기록의 변화를 어떻게 반영할지도 확인 과정의 일부다.

여기서의 대기 시간은 단독 회수 때의 대기와 목적이 다르다. 확인 횟수는 대출 계약이 입금 기록을 언제 인정할지 정한다. 시간잠금은 사용자가 상대의 서명 없이 담보를 언제 움직일 수 있는지 정한다. 입금 단계에서 오래 기다렸다고 단독 회수 시점이 앞당겨지는 것은 아니다. 이용자의 자금 계획에는 돈을 받기 전의 지연과, 협력이 끊긴 뒤 담보를 되찾기까지의 지연이 각각 영향을 준다.

회수할 수 있다는 것과 자금 계획에 맞는다는 것

이 차이는 담보대출을 비교하는 개인 보유자에게 중요하다. 대출을 갚은 뒤 담보를 다른 용도로 써야 하는 상황을 가정해 보자. 정상 해제에 필요한 상대의 서명이 오지 않고 단독 회수 시점도 아직 남아 있다면, 설계상 회수 경로가 존재해도 당장 비트코인을 사용할 수는 없다. 이는 곧바로 자산을 잃었다는 뜻은 아니지만, 예정한 자금 활용이 늦어지는 문제는 남는다.

이 사례만으로 대출 전체의 유불리를 계산할 수도 없다. 개발자의 설명은 담보 잠금과 입금 검증에 초점을 맞춘다. 담보 가치를 어떻게 산정하는지, 언제 어떤 조건으로 빌린 돈을 갚아야 하는지는 이 설명만으로 충분히 평가할 수 없다. 단독 회수 경로가 있다는 사실만으로 이런 대출 조건까지 유리하거나 회수 과정 전체가 안전하다고 판단해서는 안 된다.

설계 설명과 실제 작동의 검증도 구분해야 한다. 양측 서명과 시간잠금이 어떤 권한을 의도하는지는 읽을 수 있지만, 감사받지 않은 테스트넷 코드가 운영 환경에서 그 의도대로 안전하게 작동한다는 증거는 아니다. Writz에서 확인한 질문을 다른 대출 설계에 활용할 수는 있어도, 이 사례를 모든 비트코인 담보대출의 안전성이나 위험을 대표하는 결과로 확대할 수는 없다.

앞으로 비수탁 대출의 개선을 읽을 때도 어느 부분이 바뀌었는지를 먼저 봐야 한다. 입금 기록을 더 엄격하게 검증하는 개선은 잘못된 기록을 인정할 가능성을 줄이려는 것이다. 그것이 정상 해제에 필요한 상대의 서명을 없애거나 단독 회수 시점을 앞당기는 것은 아니다. 서로 다른 보호 장치를 하나의 ‘안전하다’는 평가로 합치면, 실제로 줄어든 의존과 여전히 남은 부담을 놓치게 된다.

이 설계에서 빌리는 사람은 정상 해제 때 프로토콜 측의 서명 제공에 의존하고, 협력이 끊기면 미리 정한 시간 조건에 따른다. 대출 계약의 입금 판단에는 관리자가 정한 기준 블록에 대한 신뢰도 남는다. 비수탁의 의미는 이 모든 의존을 없애는 데 있지 않다. 상대가 단독으로 행사할 수 있는 권한을 줄이고, 협력이 없을 때도 사용자가 행동할 조건을 남기는 데 있다. ‘어디에 보관되는가’에서 ‘누가 무엇을 결정하며, 나는 언제 다시 쓸 수 있는가’로 질문을 바꾸는 것이 이 사례가 주는 판단 기준이다.