온체인 지갑 잔액은 아직 채널에 넣지 않은 UTXO이고, 채널 잔액은 commitment transaction에서 나뉜 로컬·원격 몫입니다. 로컬 잔액이 대체로 송신 여력, 원격 잔액이 수신 여력의 출발점이지만 channel reserve, commitment 수수료, pending HTLC와 경로 제한을 빼야 실제 사용 가능액이 됩니다. 따라서 앱의 총액과 즉시 보낼 수 있는 금액은 다를 수 있습니다.
온체인 UTXO와 채널 commitment 상태를 나눕니다
채널을 열 때 온체인 funding transaction이 공동 지출 조건의 출력을 만듭니다. 그 뒤 결제는 매번 온체인 거래를 만들지 않고 양측이 최신 commitment transaction 상태를 교환해 로컬과 원격 잔액을 갱신합니다. 지갑의 온체인 탭과 라이트닝 탭이 같은 코인을 보여도 즉시 이동 가능한 경로가 다릅니다.
채널을 열기 전 500,000 sat 온체인 잔액이 있었다고 가정해 보겠습니다. 300,000 sat을 채널 funding에 쓰고 수수료 5,000 sat을 냈다면 온체인 쪽에는 약 195,000 sat이 남고 채널 capacity는 300,000 sat입니다. 이 capacity 전부가 로컬 송신 가능액이라는 뜻은 아닙니다.
채널 capacity는 통의 크기이고 로컬·원격 잔액은 현재 어느 쪽에 물이 있는지를 보여줍니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 온체인 UTXO와 채널 commitment 상태를 나눕니다
채널을 열 때 온체인 funding transaction이 공동 지출 조건의 출력을 만듭니다.
- 결제할수록 잔액의 방향이 바뀝니다
처음 로컬 잔액이 280,000 sat, 원격 잔액이 20,000 sat인 채널에서 60,000 sat을 상대 방향으로 보내면 수수료를 제외한 개념상 로컬은 약 220,000 sat, 원격은 약 80,000 sat으로 이동합니다.
- reserve와 commitment 수수료가 안전 여유를 남깁니다
BOLT 2의 channel reserve는 상대가 채널 지분을 모두 소진하지 않도록 두는 최소 잔액입니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
결제할수록 잔액의 방향이 바뀝니다
처음 로컬 잔액이 280,000 sat, 원격 잔액이 20,000 sat인 채널에서 60,000 sat을 상대 방향으로 보내면 수수료를 제외한 개념상 로컬은 약 220,000 sat, 원격은 약 80,000 sat으로 이동합니다. 채널 총 capacity는 유지되지만 내가 더 보낼 공간은 줄고 받을 공간은 늘어납니다.
반대로 다른 사람이 이 채널을 통해 나에게 지급하면 원격 쪽 잔액이 로컬 쪽으로 이동합니다. 한 방향 결제를 반복하면 capacity가 충분해도 필요한 방향의 유동성이 고갈됩니다. 앱이 총 300,000 sat 채널이라고 표시해도 250,000 sat을 바로 받을 수 있다고 결론 내릴 수 없습니다.
| 항목 | 포함 범위 | 바로 쓸 수 없는 이유 |
|---|---|---|
| 온체인 잔액 | 일반 UTXO | 채널 개설 또는 온체인 송금 필요 |
| 채널 capacity | 양측 잔액 총합 | 상대 몫 포함 |
| 로컬 잔액 | 내 commitment 몫 | reserve·수수료·pending 차감 |
| 원격 잔액 | 상대 commitment 몫 | 수신 경로와 상대 정책 필요 |
reserve와 commitment 수수료가 안전 여유를 남깁니다
BOLT 2의 channel reserve는 상대가 채널 지분을 모두 소진하지 않도록 두는 최소 잔액입니다. 또한 누가 commitment transaction 수수료를 부담하는지에 따라 로컬 사용 가능액이 달라질 수 있습니다. 노드 구현은 dust HTLC 노출과 fee spike buffer 같은 추가 안전 여유도 적용할 수 있습니다.
그래서 로컬 balance 숫자에서 지급액만 빼면 된다고 계산하면 실패할 수 있습니다. 지갑이 제공하는 `available balance`, pending open/close, limbo balance를 따로 읽고 정확한 계산은 사용 중인 구현의 RPC 정의를 확인하세요. 서로 다른 앱의 필드 이름을 같은 의미로 단정하지 않습니다.
- 온체인 confirmed·unconfirmed 잔액을 분리합니다.
- 채널별 local·remote balance를 확인합니다.
- pending HTLC와 reserve, commit fee 영향을 기록합니다.
- 보내려는 방향의 첫 홉 유동성을 확인합니다.
- 받으려는 금액은 마지막 홉 인바운드로 판단합니다.
pending HTLC는 잔액을 잠시 사용할 수 없게 합니다
결제가 진행 중이면 관련 금액은 어느 쪽 최종 잔액으로도 자유롭게 쓸 수 없는 보류 상태일 수 있습니다. 여러 부분 결제는 하나의 지급을 여러 HTLC로 나누므로 pending 합계와 개수도 확인해야 합니다. 앱 재시작이 보류 계약을 즉시 해제하지는 않습니다.
HTLC가 fulfill되면 잔액 이동이 확정되고 fail 또는 timeout이면 원래 방향으로 풀립니다. 장시간 pending 상태에서 채널을 강제 종료하면 온체인 timeout과 확인 대기가 추가될 수 있으므로, 중복 결제나 데이터 삭제보다 payment hash 상태 조회를 먼저 합니다.
여러 채널의 합계도 단일 결제 가능액과 다릅니다
채널 A에 70,000 sat, 채널 B에 50,000 sat의 로컬 사용 가능액이 있어 총 120,000 sat로 보여도 지갑과 경로가 MPP를 지원하지 않으면 100,000 sat 한 건을 보내지 못할 수 있습니다. 각 첫 홉 한도, 중간 경로, 수신 인보이스 feature가 모두 맞아야 합니다.
수신도 마찬가지입니다. 여러 채널의 인바운드 합계를 이용하려면 분할 결제를 받아들일 수 있어야 하고 각 경로의 최소·최대 HTLC 조건을 충족해야 합니다. 총액 표시는 계획 시작점이지 성공 보장이 아닙니다.
닫기 전 온체인으로 돌아오는 조건을 확인합니다
협력 종료는 양측이 최종 잔액을 합의해 closing transaction을 만들고, 강제 종료는 한쪽 commitment transaction을 게시합니다. 후자는 로컬 출력에 CSV 지연이 걸릴 수 있고 pending HTLC 출력도 별도 해결이 필요합니다. 채널 잔액이 닫는 즉시 온체인 spendable로 바뀐다고 보면 안 됩니다.
장부를 맞출 때는 채널 개설 funding, 채널 안 잔액 변화, 종료 거래와 온체인 수수료를 한 흐름으로 추적하세요. 앱의 총자산 숫자가 어느 시점 기준이며 pending close를 중복 포함하지 않는지 확인해야 합니다.
자주 묻는 질문
채널 capacity 전부를 보낼 수 있나요?
대개 아닙니다. 상대 잔액, reserve, commitment 수수료와 pending HTLC 때문에 실제 송신 가능액이 더 작습니다.
온체인 잔액이 있는데 라이트닝 결제가 왜 실패하나요?
그 UTXO가 채널 로컬 유동성으로 들어가 있지 않다면 즉시 라이트닝 경로에 쓸 수 없습니다.
채널을 닫으면 즉시 지갑 잔액이 되나요?
협력 종료도 온체인 확인이 필요하고 강제 종료는 CSV 지연과 HTLC 해결 때문에 더 오래 걸릴 수 있습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
