비트코인 결제 방식이 늘면 쓰기도 편해질까?

비트코인을 보관하거나 결제하는 방식은 하나만 있는 게 아니다. 그렇다면 서로 다른 방식을 고른 사람끼리도 쉽게 돈을 주고받을 수 있을까? 연결 기술이 생기면 각자 원하는 방식을 쓰기 편해질 수 있지만, 서로 다른 결제망을 지원한다는 말만으로 송금할 길이 생기는 것은 아니다. 실제 결제가 되려면 양쪽을 잇는 경로가 열려 있어야 하고, 그 경로에서 지급을 이어 줄 자금과 운영도 갖춰져야 한다.

2026년 10월 8일 개발자 토론에 소개된 Cassis는 비트코인 결제망 사이에 그런 경로를 만들려는 실험이다. 이 사례는 모든 비트코인 이용자가 당장 겪는 불편을 해결한 서비스라기보다, 서로 다른 결제 환경을 고른 사람들이 어떤 조건에서 거래할 수 있을지 살펴볼 구체적인 제안이다. 연결이 이용자의 선택을 실제로 얼마나 넓히는지 알려면, 먼저 앱이 다른 것과 결제망이 다른 것을 구분해야 한다.

앱이 달라도 같은 장부를 쓰면 송금할 수 있다

지갑 앱 이름이 서로 달라도 비트코인을 주고받을 수 있다. 두 사람이 모두 같은 비트코인 장부에 거래를 기록한다면, 한쪽이 주소를 알려 주고 다른 쪽이 그 주소로 보낼 수 있다. 앱은 달라도 같은 장부를 이용하기 때문이다. 비트코인의 기본 작동을 설명하는 Bitcoin.org 안내도 주소로 송금을 받고, 거래가 블록체인에 기록되는 과정을 설명한다. 이 경우 중요한 것은 앱의 이름이 아니라 돈이 어느 장부에 기록되는가다.

결제망 자체가 다르면 문제의 성격이 달라진다. 비트코인을 주소로 직접 주고받는 것과, 다른 주체에게 비트코인을 맡기고 그에 해당하는 전자 증표를 주고받는 것은 서로 다른 지급 방식이다. 후자의 경우 실제 비트코인은 발급자가 관리하고, 이용자는 자신의 기기에 저장한 증표로 거래한다. 증표를 다시 비트코인으로 바꾸려면 발급자가 그 요청을 처리해 줘야 한다. 같은 금액을 표시하더라도 비트코인을 직접 보낼 때와 누가 지급을 책임지는지, 무엇을 주고받는지가 다르다.

이런 방식을 쓰는 Cashu의 공식 FAQ는 발급자마다 자신의 증표를 발행한다고 설명한다. 한 발급자의 증표를 다른 사람에게 건넸다고 해서 그것이 다른 발급자의 증표로 바뀌지는 않는다. 다른 발급자의 증표로 바꾸려면 기존 증표를 비트코인 지급으로 교환하고 새 증표를 받는 절차가 필요하다. 이 전환을 돕는 기존 결제 경로도 있다. 중요한 것은 앱 이름이 아니라 그 안에서 무엇을 보유하고 어떤 주체가 지급을 처리하느냐다. 이런 차이를 글에서는 서로 다른 결제 환경이라고 부른다.

모든 결제 환경이 이 증표 방식으로 작동하는 것은 아니다. 그러나 이 예만으로도 왜 같은 비트코인과 관련된 잔액인데 별도의 연결이 필요한지 알 수 있다. 서로 다른 방식의 지급을 알아보고 처리할 경로가 없다면, 한쪽에서 보낸 돈이 상대방이 원하는 형태로 자동 도착하지는 않는다. 여러 결제 환경을 잇는다는 말에는 이 전환을 누가 맡는지에 대한 질문이 함께 들어 있다.

이 차이는 결제 방식을 실제로 고르는 사람에게 영향을 준다. 돈을 어디에 둘지 정할 때는 보관과 운영에 대한 신뢰, 결제 과정의 편리함 같은 조건을 함께 고려하게 된다. 그러나 자신이 고른 방식으로 다른 사람에게 돈을 보내거나 받을 수 없다면 선택의 이점이 줄어든다. 거래 상대와 같은 방식을 쓰려고 잔액을 여러 곳에 나누거나, 매번 다른 절차를 거쳐야 한다면 결제 방식의 선택은 겉보기만큼 자유롭지 않다.

그렇다고 서로 다른 결제망을 쓰는 사람이 모두 이런 문제를 겪는다고 말할 근거가 있는 것은 아니다. 중요한 질문은 더 구체적이다. 결제와 보관 방식을 실제로 선택해야 하는 사람, 또는 서로 다른 방식의 손님에게서 돈을 받고 싶은 가게에 연결 기술이 어떤 도움을 줄 수 있을까? 이를 보려면 연결이 이용자에게 요구하는 일을 줄이는 동시에, 어떤 일을 중개자 쪽으로 옮기는지 살펴야 한다.

이용자 대신 중개자가 망 사이의 지급을 잇는다

예를 들어 작은 가게가 한 결제 환경을 쓰고, 손님은 다른 환경에 잔액을 둔다고 가정해 보자. 연결 수단이 없다면 가게는 손님과 같은 환경을 따로 마련하거나, 두 사람이 모두 이용할 수 있는 다른 방법을 찾아야 할 수 있다. 가게가 여러 환경에 직접 잔액을 나눠 두면 손님을 더 많이 받을 여지가 생기지만, 각 환경의 자금을 관리하고 결제 방법을 안내하는 일도 늘어난다. 이는 선택지가 생겨도 사용과 관리의 부담이 함께 커질 수 있음을 보여주는 가정이다.

Cassis가 제안하는 방식에서는 두 결제 환경에 실제 지급용 잔액을 둔 중개자가 그 사이를 이어 준다. 원문에서 라우팅 노드라고 부르는 것은 이렇게 두 환경의 자금으로 지급을 이어 주는 참여자다. 중개자가 운영하는 프로그램은 결제 요청을 주고받고, 조건에 맞춰 각 구간의 지급을 진행한다. 프로그램이 스스로 돈을 만들어 연결하는 것이 아니라, 중개자가 각 환경에서 쓸 수 있는 잔액이 있어야 경로가 성립한다. 경로가 여러 구간이면 각 중개자는 자신이 잇는 앞뒤 두 환경의 지급을 맡는다. 이 때문에 송금자와 수신자는 중간에 놓인 모든 환경에 직접 잔액을 준비하지 않고도 경로를 이용할 수 있다는 설명이다.

이 원리는 돈을 새로 만들어 내거나 결제망을 하나로 합치는 것이 아니다. 중개자가 앞쪽 망에서 지급을 받고 뒤쪽 망에서 지급을 이어 주려면 양쪽에 실제로 쓸 수 있는 자금이 필요하다. 그러므로 소프트웨어가 여러 환경을 지원하더라도, 필요한 방향과 금액을 처리할 자금이 없는 중개자만 있다면 그 경로를 이용할 수 없다. 연결은 자금이 필요 없게 하는 기능이라기보다, 이용자가 직접 여러 망에 잔액을 마련하던 부담의 일부를 중개 경로로 옮기는 방식이다.

Cassis는 망마다 별도로 이뤄지는 지급이 한쪽에서만 끝나지 않도록 조건을 붙인다. 쉽게 말해, 수신자가 정해진 비밀값을 제시해야 돈을 받을 수 있고, 그 값을 제때 내놓지 못하면 지급을 시작한 쪽이 일정 시간이 지난 뒤 자금을 되찾도록 약속하는 방식이다. 각 구간은 같은 비밀값과 연결되며, 수신자 쪽으로 갈수록 회수까지 기다리는 시간이 짧아진다. 수신자가 마지막 구간의 돈을 받기 위해 비밀값을 공개하면, 그 값이 앞선 구간에도 전달돼 중개자들이 차례로 지급을 마무리한다.

이렇게 시간 조건을 두는 이유는 경로의 앞부분과 뒷부분을 따로 떼어 처리할 때 생길 수 있는 위험을 줄이기 위해서다. 뒤쪽 지급이 이어지지 않으면 앞쪽의 자금을 회수할 시간이 남도록 설계하는 식이다. 다만 지급에 시간이 붙는 동안 자금이 잠길 수 있고, 경로가 중간에 멈췄을 때 각 구간이 약속대로 처리되는지 운영해야 한다. 조건부 지급은 서로 다른 망에서 결제를 맞물리게 하는 장치이지, 중개자의 자금이나 운영을 필요 없게 만드는 장치는 아니다.

돈이 있어도 경로를 찾고 유지해야 한다

경로에 자금이 준비돼 있어도 송금하는 사람이 그 경로를 찾지 못하거나, 중개 노드와 연락할 수 없다면 결제는 시작되지 않는다. 결제 요청에는 받는 사람이 어떤 조건으로 돈을 받을지 전달하는 정보가 필요하고, 중간 노드는 다음 구간으로 요청을 넘길 수 있어야 한다. 연결할 망의 이름을 소프트웨어가 알고 있다는 사실만으로 이용 가능한 경로가 자동으로 나타나는 것은 아니다.

중개 노드의 자금은 방향에 따라서도 달라진다. 한쪽 방향의 지급을 이어 주면 그쪽 망에서 쓸 수 있는 잔액은 줄고, 다른 쪽에 있는 자금은 늘 수 있다. 그 결과 반대 방향의 결제는 가능해도 원래 방향으로는 당장 처리하지 못할 수 있다. 다시 쓸 수 있게 자금을 맞추는 일과, 특정 금액의 요청을 처리할 여력이 있는지 확인하는 일은 경로 운영의 일부가 된다. Cassis의 제안은 필요한 자금의 규모나 이를 마련하고 재배치하는 실제 비용을 보여 주지 않는다.

중개자가 요청에 응답하지 않거나 지급이 실패하면 자금이 조건에 묶일 수도 있다. 그래서 송금자는 어떤 노드가 운영 중인지, 노드가 약속한 절차를 이행하는지 알아야 하고, 중개자는 보유 자금이 불필요하게 오래 묶이지 않을 것이라는 신뢰가 필요하다. Cassis 제안문은 노드 사이의 통신, 이용자가 경로를 찾는 방법, 노드와 송금자의 평판, 결제 요청 형식 등을 앞으로 풀어야 할 문제로 든다. 이는 기술 목록이라기보다 한 가지 인과관계를 보여준다. 자금만 있어서는 경로가 되지 않고, 경로를 발견하고 요청을 전달하며 실패를 처리하는 운영 방식까지 있어야 결제가 가능하다.

받는 사람이 오프라인일 때의 결제도 아직 해결된 기능이 아니다. 수신자가 지급을 마무리할 비밀값을 제때 공개하지 못하면 경로가 이어지기 어렵다. 제안문은 신뢰하는 제삼자나 연합체가 그 정보를 대신 처리하는 방안을 가능성으로 언급하지만, 이를 조사한 단계는 아니라고 밝힌다. 다른 주체에게 맡기면 수신 편의가 나아질 수 있지만, 그 주체를 믿어야 하는 조건도 생긴다. 이 사례만으로는 어떤 방식이 구현될지, 이용자가 어떤 신뢰 관계를 받아들여야 할지 정해져 있지 않다.

가게의 선택은 무엇이 준비됐는지에 달려 있다

앞의 가게 상황으로 돌아가 보자. 손님이 다른 결제망을 쓰더라도 연결 경로가 실제로 열려 있고, 중개 노드가 필요한 방향과 금액의 자금을 갖고 있으며, 결제 요청과 정산이 안정적으로 이어진다면 가게가 모든 망을 직접 관리하지 않고도 손님을 받을 가능성이 생긴다. 반대로 중개자가 가게가 필요한 망을 잇지 않거나 자금이 부족하다면, 소프트웨어가 여러 결제 환경을 지원한다는 목록은 손님이 결제할 수 있다는 보장이 되지 않는다.

가게가 직접 여러 환경에 잔액을 마련하는 선택과 중개 경로를 이용하는 선택에는 서로 다른 부담이 있다. 직접 관리하면 특정 경로 운영자의 자금과 응답 가능성에 덜 의존할 수 있지만, 가게가 여러 환경의 잔액과 절차를 챙겨야 한다. 중개 경로를 쓰면 그런 관리 부담을 덜 가능성이 있는 대신, 실제로 이용할 수 있는 중개자가 있는지와 그 경로의 조건을 살펴야 한다. 어느 방식이 더 낫다고 일괄해서 말하기보다, 이용자가 줄이고 싶은 부담이 무엇인지 따져야 하는 이유다.

또한 중개 노드가 여러 망에 자금을 보유한다는 사실만으로 그 자금의 소유나 이용자 자금의 보관 방식을 단정할 수는 없다. 구체적인 서비스에서 누가 자금을 통제하고, 결제 중 문제가 생기면 이용자가 무엇을 할 수 있는지는 구현과 운영 방식에 따라 확인해야 한다. 연결이 수탁이나 운영에 대한 신뢰를 없애는 것이 아니라, 누구에게 어떤 역할을 맡기는지를 바꿀 수 있다는 점이 중요하다.

Cassis 개발자 토론에는 구현이 소개됐지만, 소프트웨어와 웹사이트는 실험적이고 미완성이라고 명시돼 있다. 공개된 설명에서는 실제 결제의 성공률, 필요한 중개 자금의 규모, 수수료와 운영 비용을 확인할 수 없다. 그러므로 이 사례가 보여주는 것은 조건부 지급을 이용해 서로 다른 망 사이의 경로를 구성하려는 설계와 그 구현의 존재다. 이를 이용자 사이에서 안정적으로 운영되는 결제 서비스의 성과로 받아들일 근거는 아직 제시되지 않았다.

지원 망의 수보다 실제 경로를 보자

서로 다른 결제망의 연결이 선택을 넓히려면, 이용자가 모든 망에 직접 잔액을 두지 않아도 거래할 수 있어야 한다. 그러나 그 편의는 중개자가 가진 자금, 이용자가 찾을 수 있는 경로, 지급 실패를 처리하는 방식에 달려 있다. 연결 기술이 있더라도 쓸 수 있는 방향의 자금이 없거나, 경로를 알 수 없거나, 문제가 생겼을 때 회수 절차가 분명하지 않다면 이용자가 얻는 선택지는 제한된다.

따라서 결제망을 고르는 사람은 지원 망의 숫자만 볼 것이 아니라, 실제로 자신이 이용할 경로가 열려 있는지, 그 경로가 필요한 방향의 지급을 감당할 자금을 갖췄는지, 실패했을 때 자금이 어떻게 처리되는지 확인해야 한다. 사업자라면 손님이 쓰는 방식과 자신이 받을 수 있는 방식 사이에서 누가 중개 역할을 하는지, 그 운영에 얼마나 의존하게 되는지도 판단 기준이 된다. 이런 질문은 개발자만의 관심사가 아니다. 자신의 돈을 어느 방식에 둘지, 편의를 위해 어떤 서비스의 운영을 받아들일지를 정하는 문제다.

Cassis는 연결 가능한 결제 경로를 제안하고 실험 구현으로 옮겼다. 하지만 이용자의 선택이 실제로 넓어졌다고 말하려면, 노드가 단순히 여러 망을 지원하는 것을 넘어 필요한 시점에 경로를 찾고, 충분한 자금을 제공하고, 실패를 예측 가능한 방식으로 처리해야 한다. 그 조건이 갖춰졌는지를 확인하기 전까지는 연결 목록보다 실제로 쓸 수 있는 경로와 그 경로에 따르는 의존 관계가 더 중요한 판단 기준이다.