BTCPay Server로 직접 Bitcoin 결제 받는 방법

호스팅형 결제 처리업체는 어느 곳이든 당신의 계정을 동결할 수 있는 회사다. Bitcoin을 받는 사람에게 이는 가정이 아니다 — 대형 처리업체들은 이미 수년 전부터 신원 확인, 정산 한도, 정산 규칙을 도입해 두었고, 가맹점이 그중 하나라도 걸리면 대개 돈이 이미 오가는 도중에야 그 사실을 알게 된다. BTCPay Server는 정확히 이 문제 때문에 존재한다. 이는 당신이 직접 통제하는 서버를 당신만의 체크아웃 — 인보이스, POS 화면, 스토어 플러그인, Lightning — 으로 바꿔주는 무료 오픈소스 소프트웨어이며, 중간에 낀 회사도, 떼어가는 수수료도, 잃을 계정도 없다. 설치 자체는 정말로 반나절이면 끝난다. 결과물의 완성도를 좌우하는 것은 그 밑에 놓인 머신이며, 기본 설치가 조용히 남겨 두어 결국 당신을 다시 가리키게 되는 몇 가지 세부 사항이다.

BTCPay Server가 실제로 대체하는 것

호스팅형 처리업체는 고객과 당신의 지갑 사이에 자리를 잡는다. 주소를 생성하고, 체인을 지켜보고, 금액을 환산하고, 일정 기간 자금을 보유했다가 결국 당신에게 지급한다. 이 단계 하나하나가 곧 처리업체가 당신에 대해 알게 되는 지점이자 거부할 수 있는 지점이다. BTCPay는 당신이 대여한 하드웨어 위에서 똑같은 일을 하지만, 그것이 알게 되는 정보의 차이는 완전하다.

• 결제는 곧바로 당신 자신의 지갑으로 들어온다. BTCPay에 확장 공개 키(xpub)를 건네주면 인보이스마다 새 주소를 파생시켜 지켜본다 — 온체인 결제용 개인 키는 전혀 보유하지 않으며 사토시 하나도 움직일 수 없다.
• 수수료도 계정도 없다. 소프트웨어는 오픈소스이고 당신이 직접 운영하므로, 신청할 것도 정지당할 것도 없다.
• 직접 만들기 번거로운 부분들을 대신 처리해 준다: 인보이스 만료, 실시간 환율 변환, 미달 결제와 초과 결제, 부분 결제, 환불, 그리고 고객이 스스로 검증할 수 있는 영수증까지.
• 대부분의 사람이 필요로 하는 프런트엔드도 함께 제공한다 — POS 화면, 결제 버튼, 크라우드펀딩 페이지, 흔히 쓰는 전자상거래 플랫폼용 플러그인까지 — 그리고 자신의 소프트웨어에 직접 연결하고 싶다면 전체 API도 갖추고 있다.
• 원한다면 같은 배포 안에 Lightning도 함께 딸려 온다. 몇 달러 미만의 결제를 애초에 가능하게 만들어주는 것이 바로 이것이다.

이 경계는 분명히 짚고 넘어갈 가치가 있다. BTCPay는 Bitcoin을 당신의 현지 화폐로 바꿔주지 않으며, 돈이 결국 그쪽으로 가야 한다면 거래소나 은행을 없애주지도 않는다. 이것이 없애주는 것은 처리업체다 — 수수료를 떼어가고, 그 사이에서 자금을 보유하고, 그러기 위해 당신의 신원을 요구했던 중개자 말이다. 당신이 되찾는 것은 직접 호스팅하는 웹사이트와 같은 모양이다: 더 많은 통제권, 그리고 그에 딸려 오는 수고.

당신이 곧 결제 처리업체가 된다

그 수고는 셀프 호스팅의 정직한 대가이며, 설치 후보다 설치 전에 이해해 두는 편이 훨씬 낫다. 아무도 당신의 가동 시간을 지켜봐 주지 않고, 아무도 당신의 백업을 복원해 주지 않으며, 고객이 결제했다고 우기는데 당신 눈에는 아무것도 보이지 않는 그 순간 전화 저편에서 받아줄 지원팀도 없다.

• 가동 시간은 당신의 몫이다. 서버가 다운된 동안에는 인보이스를 만들 수 없으므로, 항상 작동해야 하는 체크아웃이라면 누군가 실제로 지켜보는 머신이 필요하다.
• 백업도 당신의 몫이다. 서버를 잃는 것은 견딜 수 있지만, 지갑 디스크립터나 Lightning 채널 상태를 잃는 것은 그렇지 않다.
• 키 보관 방식은 둘로 나뉜다. 온체인 자금은 BTCPay가 그저 지켜보기만 하는 지갑에 머무르며, 이것이 안전한 구성이다. Lightning 자금은 서버 자체에 있는 핫월렛에 머무르는데, 이는 안전하지 않다 — 그 잔액은 저축이 아니라 운영 자금으로 취급하라.
• 분쟁을 조정해 줄 중재자는 없다. 지불 거절(chargeback)이 아예 없다는 것이 요점의 상당 부분이지만, 그만큼 모든 환불은 당신이 직접 내리는 결정이자 당신이 직접 보내는 거래가 된다는 뜻이기도 하다.
• 업데이트도 당신의 몫이다. 친절한 인터페이스 아래에는 Bitcoin 노드를 품은 컨테이너 스택이 있으며, 공인 IP에서 계속 돌아가는 다른 무엇과 마찬가지로 똑같은 수준의 유지 관리 규율이 필요하다.

이 중 어느 것도 무겁지 않다. 일단 돌아가기 시작하면 한 달에 몇 분이면 되고, 처음에 신중한 반나절만 들이면 된다. 다만 확실한 것은 그 비용이 0은 아니라는 점이며, 처리업체 수수료는 부분적으로 바로 이것을 대신 사주고 있었던 것이다.

머신 크기 정하기: 밑에 놓인 노드가 전부를 좌우한다

BTCPay 자체는 가벼운 애플리케이션이다. 그것이 의존하는 Bitcoin 노드는 그렇지 않으며, 이 부분에서 벌어지는 크기 산정 실수는 거의 다 그 밑에 있는 체인이 아니라 웹 애플리케이션을 기준으로 예산을 잡는 데서 비롯된다. 표준 배포는 Bitcoin Core, 지갑을 추적하는 인덱서, 데이터베이스, 리버스 프록시, 그리고 애플리케이션 자체를 함께 띄운다 — 그리고 디스크와 메모리와 인내심을 요구하는 쪽은 바로 Core다.

• 스토리지는 어떤 플랜을 골라야 하는지를 결정짓는 요소다. 프루닝하지 않은 체인은 오늘 기준 이미 750 GB를 넘었고 매달 약 7 GB씩 늘어난다. 이 배포판은 블록 데이터를 약 100, 50, 25 GB 선에서 묶어 두는 스토리지 절약 프리셋을 제공하며, 그중 무엇을 고르든 모든 규칙을 스스로 검증하는 진짜 풀 노드라는 사실은 변하지 않는다.
• 프루닝은 첫 동기화 시간을 줄여주지 않는다. 어느 쪽이든 Core는 제네시스 블록 이후의 모든 블록을 내려받아 검증하며, 프루닝은 그 이후 무엇을 남길지만 결정할 뿐이다.
• 동기화 속도는 메모리에서 나온다. 4 GB로도 돌아가지만, 8 GB면 눈에 띄게 빠르게 동기화되고 Lightning과, 캐시를 두고 노드와 다투지 않는 데이터베이스를 위한 여유까지 남는다.
• NVMe는 선택 사항이 아니다. 초기 동기화는 UTXO 데이터베이스에 대한 무작위 읽기·쓰기가 대부분을 차지하므로, 같은 작업이라도 느린 디스크에서는 몇 시간이 아니라 며칠이 걸린다.
• 일단 동기화가 끝나면 대역폭은 별다를 것이 없지만, 첫 동기화는 체인 전체를 끌어온다. 종량제 플랜은 이 작업에는 맞지 않는 형태다.

실제로는 Lightning을 곁들인 프루닝 노드에 합리적인 기본값으로 월 $13.99의 VPS-8 — 4 vCPU EPYC, 8 GB DDR5 ECC, 120 GB Gen4 NVMe — 로 귀결되며, 디스크를 두 번 다시 신경 쓰고 싶지 않다면 월 $26.99의 VPS-16을 고르면 된다. 모든 VPS 등급이 Gen4 NVMe를 RAID-10 구성으로 제공하고 무제한 전송을 지원하므로, 실질적인 선택 기준은 용량뿐이다. 체인을 프루닝하지 않은 채로 두고 싶다면 — 오래된 지갑을 다시 스캔하거나, 스토어 옆에 Electrum 서버를 함께 운영하려면 — VPS 라인 전체를 건너뛰어라: 월 $64부터 시작하는 전용 서버는 2 × 1 TB NVMe를 갖추고 있어, 가장 큰 VPS보다 오히려 더 저렴하면서 공간도 훨씬 넉넉하며, 시간이 지날수록 그 계산은 더욱 불리해진다. 이 트레이드오프는 Bitcoin 풀 노드를 운영하는 것과 똑같다 — 여기서 하고 있는 일도 정확히 그 위에 체크아웃 하나를 얹은 것에 지나지 않기 때문이다.

단계별 안내: 새 VPS에서 실제 운영 중인 체크아웃까지

1. 01VPS를 배포하고 먼저 하드닝하기값어치 있는 것이 올라가기 전에 Debian이나 Ubuntu 박스에 키 전용 SSH와 기본 차단 방화벽부터 갖춰라. 그 체크리스트를 순서대로 정리한 내용은 별도의 가이드로 따로 있다.
2. 02도메인을 서버로 연결하고 80번과 443번 포트 열기BTCPay는 처음 시작할 때 자체적으로 인증서를 발급받는데, 이는 호스트네임이 이미 그 머신을 가리키고 두 포트 모두에 도달할 수 있어야만 작동한다. 이 순서를 거꾸로 하는 것이 설치 실패의 압도적으로 가장 흔한 원인이다.
3. 03공식 Docker 배포본 클론하기이 프로젝트는 특정 방식대로 짜인 컨테이너 구성을 제공한다. 조각을 직접 조립하기보다 이것을 그대로 사용하라 — 업그레이드 경로가 검증되는 대상이 바로 이 구성이다.
4. 04첫 실행 전에 옵션 정하기네트워크, 호스트 이름, Lightning 구현체, 스토리지 프리셋은 설치 시 한 번만 읽히는 환경 변수다. 나중에 프루닝 수준을 바꾸는 것은 공짜가 아니므로, 지금 정해 두어라.
5. 05설치 스크립트를 실행하고 동기화되도록 두기모든 것이 컨테이너로 올라오고 Bitcoin Core가 초기 블록 다운로드를 시작한다. 이것이 가장 오래 걸리는 부분이다 — NVMe에서도 몇 시간은 걸리며 — 서두를 수 없는 유일한 단계다.
6. 06관리자 계정을 즉시 등록하기가장 먼저 가입하는 계정이 관리자가 된다. 인터페이스가 응답하는 바로 그 순간에 등록하고, 다음 날 아침까지 미루지 마라.
7. 07스토어에 지갑 연결하기스토어를 만든 다음, 하드웨어 지갑이나 자신의 소프트웨어 안의 전용 계정에서 확장 공개 키를 가져와 지갑을 연결하라. BTCPay는 주소만 지켜볼 뿐, 서명은 절대 하지 않는다.
8. 08실제 결제로 테스트한 다음 프런트엔드 연결하기자기 자신에게 소액을 보내 인보이스가 정산되는지 확인하라. 그런 다음에야 POS 화면이나 스토어 플러그인, 혹은 사이트가 실제로 호출할 API를 연결하라.

Lightning: 가치는 있다, 다만 실제로 드는 비용은 이렇다

온체인 결제는 어디서나 작동하지만 그날그날의 멤풀 사정만큼 비용이 들며, 그래서 몇 달러 미만의 결제는 번거롭다 못해 때로는 터무니없어진다. Lightning은 이 문제를 해결해 주며, BTCPay가 같은 배포 안에서 노드를 대신 띄워준다. 작거나 잦은 결제에는 이것이 정답이다. 다만 Bitcoin 노드와는 종류가 다른 운영상의 책임이 따르므로, 켜기 전에 그 차이를 알아 둘 가치가 있다.

• 결제를 받으려면 먼저 인바운드 유동성이 있어야 한다. 자신이 채널을 여는 것은 지출할 용량을 만들어 줄 뿐, 수신할 용량은 아니다. 누군가 당신 쪽으로 채널을 열어주거나 당신이 직접 인바운드 용량을 확보하기 전까지는, 당신의 노드는 아무것도 받을 수 없다.
• 그 잔액은 설계상 핫(hot)이다. 채널 자금은 서버 위의 지갑에 머무르며, 어쩔 수 없이 온라인 상태로 있어야 한다. 그곳에는 당장 쓸 운영 자금만 남겨 두고, 나머지는 온체인으로 정기적으로 옮겨라.
• 채널 상태는 파일을 복사한다고 백업되지 않는다. Lightning 노드의 오래된 스냅샷을 복원하면 그 스냅샷이 담고 있던 채널 자체를 잃을 수 있다. 구현체 자체의 백업 메커니즘을 사용하고, 그것이 실제로 무엇을 복원해 주는지 이해해 두어라.
• 다운타임은 온체인보다 여기서 더 큰 대가를 치른다. 오프라인 노드는 라우팅도 수신도 할 수 없고, 오래된 상태로 온라인에 복귀하면 페널티를 받을 수 있다.
• 채널은 양쪽 끝 모두에서 온체인 비용이 든다. 개설과 폐쇄 모두 거래이므로, 작은 채널을 여러 개 여는 습관은 조용히 비용을 불린다.
• 그렇게 두면 당신의 노드는 눈에 띈다. 공개적으로 알린(announced) 노드는 자신의 별칭과 네트워크 주소를 모두에게 방송하며, 이는 누구나 읽을 수 있는 지도 위에 당신의 서버를 올려놓는 셈이다.

합리적인 중간 지점은 비공개(unannounced) 채널로 Lightning을 쓰는 것이다 — 인프라를 공개하지 않고도 결제를 받을 수 있다 — 그리고 금액이 큰 것은 기본적으로 온체인으로 처리하는 것이다. 노드가 도달은 가능하되 신원과는 연결되지 않기를 원한다면 Tor를 통해 운영하라. Bitcoin 노드를 공인 IP 대신 오니언 서비스 뒤에 두는 것과 같은 이유다.

기본 설치가 그대로 남겨두는 신원 유출

당신이 누구인지 알고 있던 처리업체에서 벗어나려고 BTCPay를 선택했다면, 바로 이 절이 중요하다. 이 소프트웨어는 그 처리업체를 완벽하게 없애준다. 다만 그것만으로는 체크아웃을 한 사람과 연결 짓는 나머지 모든 것을 없애주지는 못한다 — 그리고 그 대부분은 결제와는 무관하게 느껴지는 단계에서 비롯된다.

• 도메인. 공개 WHOIS 정보가 가려져 있어도 등록기관은 당신의 신원을 보관하고 있으며, 이름을 유지하려면 실제로 작동하는 주소가 필요하다. 호스트네임은 셀프 호스팅한 체크아웃이 소유자에게로 추적되는 단연 가장 흔한 경로다.
• 인증서 투명성. 인증서가 발급되는 순간, 정확한 호스트네임이 누구나 검색할 수 있는 공개 로그에 게시된다. 비공개일 거라 생각했던 서브도메인 — pay.something, btcpay.something 같은 — 이 타임스탬프까지 찍힌 채 전 세계에 공지된다.
• 호스트. 서버를 본명으로 된 카드로 구매했다면, 그 위에서 무엇이 돌아가든 머신은 당신의 본명으로 남아 있다. 이는 첫 인보이스가 생기기 훨씬 전, 가입 시점에 이미 결정된다.
• 확장 공개 키. BTCPay에 xpub을 건네면 그 키가 파생하는 모든 주소 — 웹 애플리케이션에 노출할 생각이 전혀 없었던 잔액과 거래 내역까지 — 를 지켜볼 수 있게 된다. 스토어에는 전용 계정을 사용하고, 주 지갑의 xpub은 절대 쓰지 마라.
• Lightning 노드. 공개된(announced) 노드는 별칭과 주소를 게시한다. 당신의 브랜드가 담긴 별칭이 체크아웃도 함께 서비스하는 IP 위에 있으면, 그 둘은 공개 그래프 안에서 영구히 연결되어 버린다.
• 아웃바운드 통신. 환율 제공업체, 플러그인, 알림 연동은 모두 이 머신에서 밖으로 연결을 시도하며, 이메일 알림은 당신이 설정한 SMTP 계정을 거쳐 나간다. 이들 각각이 당신의 서버를 보는 제3자다.
• 정산 경로. 스토어를 떠나 인증된 거래소 계정으로 들어가는 코인은 자신의 이력을 그대로 매단 채 도착한다. 이 유출은 BTCPay보다 뒤쪽에서 벌어지며, 그 앞에서 아무리 신경 써도 가장 자주 그 모든 노력을 무너뜨리는 지점이다.

이런 것들을 닫아 두는 일은 특별할 것 없는 평범한 작업이다. 암호화폐를 받고 최소한의 정보만 수집하는 등록기관을 고르고, 당신의 신원과 연결되지 않는 주소를 등록기관에 알려주어라. 머신은 당신이 누구인지 물은 적 없는 호스트에 두고 암호화폐 잔액으로 결제하라 — Bitcoin은 익명이 아니라 가명(pseudonymous)일 뿐이므로, 그것이 신경 쓰인다면 Monero로 충전하는 것이 온체인 흔적을 끊는 방법이다. 그리고 돈을 다루는 물건의 로그인 페이지를 그대로 노출하는 대신, WireGuard 터널을 통해 관리자 인터페이스에 접근하라. 각각은 한 번만 내리면 되는 작은 결정이며, 이것들이 모이면 '결제 처리업체 없음'과 진짜 프라이버시 사이의 차이를 만든다.

출시 이후에도 멈추지 않게 유지하기

1년 동안 문제없이 작동해 온 체크아웃은, 1년 동안 아무도 들여다보지 않은 체크아웃이기도 하다. 짧은 유지보수 루틴이 이것이 가장 바쁜 날의 장애로 번지는 것을 막아준다.

• 업데이트는 당신의 일정이 아니라 프로젝트의 일정에 맞춰라. 이 배포판에는 서로 맞춘 컨테이너 버전을 한꺼번에 옮겨주는 업그레이드 경로가 있다 — 조각을 하나씩 손으로 올리는 것이야말로 멀쩡히 돌아가던 스택을 고장 낸 스택으로 만드는 지름길이다.
• 다시 만들어낼 수 없는 것을 백업하라: 스토어 데이터베이스와 설정, 지갑 디스크립터, 그리고 Lightning을 쓴다면 그 백업까지. 블록체인은 백업이 아니다 — 그것은 그저 다시 내려받아질 뿐이다.
• 아무 문제도 없을 때 한 번은 일부러 복원을 해 보아라. 테스트해 보지 않은 결제 시스템 백업은 당신의 매출에 대한 가설일 뿐이다.
• 디스크를 지켜보라. 프루닝 노드는 차지하는 용량이 안정적이지만, 로그와 데이터베이스는 그렇지 않으며, 디스크가 가득 차면 노드가 멈추고 그러면 인보이스도 멈춘다.
• 머신은 계속 패치하고 포트는 계속 닫아 두어라. 첫 10분짜리 하드닝 체크리스트에 있는 모든 것이 여기에도 그대로 적용되며, 걸려 있는 판돈은 오히려 더 크다.

하는 김에 스토어에 외부 점검도 하나 추가해 두어라. 외부에서 인보이스 엔드포인트를 두드리는 정도로 단순한 모니터만 있어도 고객보다 먼저 체크아웃이 다운되었음을 알 수 있으며, 이것이 셀프 호스팅과 그저 닿을 수 없는 상태 사이의 실질적인 차이 대부분을 만든다. 그리고 박스 자체는 새 VPS에서 보내는 첫 10분에서 설명하는 그대로 다루어라. 돈을 쥐고 있는 머신에서는 걸려 있는 판돈이 더 크기 때문이다.

실제 돈이 나가는 실수들

• 확장 공개 키 대신 시드 문구를 가져와서, 공개된 웹 애플리케이션을 지금까지 받은 모든 결제를 담은 핫월렛으로 만들어 버리는 경우.
• 설치 프로그램을 실행한 뒤에야 DNS를 설정하고는, 인증서가 발급되지 않고 사이트가 열리지 않는 이유를 궁금해하는 경우.
• 가장 강하게 프루닝하는 프리셋을 고른 다음, 노드가 더는 다시 스캔할 수 없는 몇 년치 이력을 가진 지갑을 연결하려는 경우.
• Lightning 잔액을 어쩌다 온라인에 놓인 운영 자금이 아니라 저축으로 취급하는 경우.
• 데이터 디렉터리를 복사하는 것으로 Lightning 노드를 백업했다고 여기고, 그것이 곧 복원 경로라고 생각하는 경우.
• 웹 애플리케이션 크기에 맞춘 플랜을 구매했다가, 초기 동기화 도중에 디스크가 바닥나는 경우.
• 다른 곳에서 재사용한 비밀번호 하나만 걸어 둔 채, 관리자 인터페이스를 인터넷 전체에 열어 두는 경우.
• 다른 모든 것은 제대로 해놓고, 정작 도메인 등록과 서버 대여는 본명으로 하는 경우.

BTCPay는 중개자를 더 친절한 것으로 갈아치우는 대신 아예 없애버리는 몇 안 되는 소프트웨어 중 하나다. 설치에는 반나절, 동기화에는 하룻밤이면 된다. 그러고 나면 남는 것은 Bitcoin과 Lightning을 받고, 아무 수수료도 물리지 않고, 아무것도 보관하지 않으며, 누구에게도 답할 필요가 없는 체크아웃이다 — 게다가 그 체크아웃이 거둬들이는 것과 같은 잔액으로 비용을 치를 수 있는 머신 위에서 돌아간다. 노드에 맞춰 디스크 크기를 정하고, 시드는 서버 밖에 두고, 박스는 당신의 이름을 물은 적 없는 곳에 두어라.