아웃바운드 유동성은 내 채널 쪽에서 밖으로 보낼 수 있는 잔액이고 인바운드 유동성은 상대 채널 쪽에서 내 쪽으로 이동할 수 있는 공간입니다. 내가 채널을 열어 자금을 넣으면 초기에는 보내기 쉽지만 받을 공간은 작을 수 있습니다. 실제 결제는 첫 홉부터 마지막 홉까지 같은 방향의 용량과 정책을 모두 만족해야 하므로 총 채널 용량만으로 성공을 판단하지 않습니다.
채널 잔액은 양방향으로 움직이는 공간입니다
내가 500,000 sat 채널을 열고 대부분을 로컬에 보유하면 아웃바운드는 크고 인바운드는 작습니다. 100,000 sat을 지급하면 그 금액만큼 개념상 로컬이 줄고 원격이 늘어 이후 수신 공간이 커집니다. 채널 capacity가 변하지 않아도 방향별 사용 가능액은 매 결제 후 달라집니다.
수신자는 온체인 지갑에 비트코인이 많다는 이유로 라이트닝을 받을 수 있는 것이 아닙니다. 마지막 홉 채널의 상대 측에 지급액이 있어야 내 로컬 쪽으로 이동합니다. 송신자는 반대로 첫 홉의 내 로컬 측에 지급액과 라우팅 수수료를 감당할 공간이 필요합니다.
라이트닝 유동성은 보유량 하나가 아니라 어느 방향으로 얼마를 이동시킬 수 있는가라는 질문입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 채널 잔액은 양방향으로 움직이는 공간입니다
내가 500,000 sat 채널을 열고 대부분을 로컬에 보유하면 아웃바운드는 크고 인바운드는 작습니다.
- 수신 가능액은 원격 잔액보다 작을 수 있습니다
가정으로 원격 잔액이 200,000 sat이어도 channel reserve와 pending HTLC, 최대 HTLC 정책 때문에 200,000 sat 전부를 한 번에 받지 못할 수 있습니다.
- MPP는 여러 작은 길을 합치지만 자동 만능은 아닙니다
한 채널에 충분한 용량이 없어도 지갑은 여러 경로로 금액을 나누는 multi-part payment를 사용할 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
수신 가능액은 원격 잔액보다 작을 수 있습니다
가정으로 원격 잔액이 200,000 sat이어도 channel reserve와 pending HTLC, 최대 HTLC 정책 때문에 200,000 sat 전부를 한 번에 받지 못할 수 있습니다. 또한 송신자에서 내 채널 상대 노드까지 도달하는 중간 경로가 부족하면 마지막 홉 공간이 남아도 실패합니다.
지갑의 receive capacity는 구현이 계산한 추정치입니다. 사설 채널이면 route hint가 인보이스에 포함돼야 할 수 있고 수신 노드가 오프라인이면 경로가 있어도 전달되지 않습니다. 인보이스 금액을 조금 낮춰 성공했다고 해서 원인이 반드시 마지막 홉 용량이었다고 단정하지 마세요.
| 하려는 일 | 필요한 핵심 | 자주 놓치는 조건 |
|---|---|---|
| 보내기 | 첫 홉 아웃바운드 | 수수료·reserve·중간 경로 |
| 받기 | 마지막 홉 인바운드 | route hint·상대 온라인 |
| 큰 금액 보내기 | 단일 또는 MPP 경로 | 부분 결제 feature |
| 반복 수신 | 지속적인 원격 잔액 | 유동성 재균형 비용 |
MPP는 여러 작은 길을 합치지만 자동 만능은 아닙니다
한 채널에 충분한 용량이 없어도 지갑은 여러 경로로 금액을 나누는 multi-part payment를 사용할 수 있습니다. 각 부분은 다른 경로를 지나지만 수신자는 같은 payment secret 아래 전체를 원자적으로 정산해야 합니다. 인보이스와 양쪽 구현이 기능을 지원해야 합니다.
총 인바운드가 지급액보다 커 보여도 각 경로의 최소·최대 HTLC, 수수료 한도와 CLTV가 맞지 않으면 분할이 실패합니다. 부분 시도가 pending이면 새 인보이스로 다시 보내기 전에 전체 payment hash 상태를 확인해야 합니다.
- 채널별 local·remote와 available 값을 기록합니다.
- 송신이면 첫 홉, 수신이면 마지막 홉부터 확인합니다.
- pending HTLC가 방향 용량을 잠그는지 봅니다.
- 인보이스의 route hint와 MPP 지원을 확인합니다.
- 유동성 조치의 온체인·서비스 수수료를 비교합니다.
인바운드를 만드는 방법마다 비용과 의존성이 다릅니다
상대가 내 노드로 채널을 열면 인바운드가 생길 수 있지만 상대가 유지할 의무는 없습니다. 내가 먼저 지급해 잔액을 상대 쪽으로 이동하거나 circular rebalance를 시도할 수도 있으나 라우팅 수수료와 경로가 필요합니다. submarine swap 계열은 온체인 자금과 채널 잔액을 교환하며 서비스 조건과 온체인 수수료를 확인해야 합니다.
유동성 구매 서비스는 기간, 최소 수신량, 채널 가동률과 환불 조건이 제각각입니다. 광고된 capacity 전체를 보장 수신액으로 읽지 말고 계약이 어느 노드에서 어떤 기간 동안 어떤 채널을 제공하는지 확인하세요. 실제 비용은 개설 수수료, 라우팅 비용, 자금 기회비용을 함께 계산합니다.
재균형은 총자산을 늘리지 않고 방향을 바꿉니다
순환 재균형은 내 한 채널로 지급을 내보내 다른 내 채널로 되돌려 받아 두 채널의 방향성을 조정합니다. 성공하면 총 라이트닝 자산은 수수료만큼 줄고 채널별 local·remote 배치가 바뀝니다. 새 비트코인이 생기는 작업이 아닙니다.
목표 인바운드 300,000 sat을 만들기 위해 수수료 상한 3,000 sat을 정했다면 최대 1% 비용이라는 가정입니다. 경로 시도가 반복되면 실제 비용과 실패 로그를 기록하고 상한을 넘으면 중단하세요. 무한 재시도는 라우팅 정보 노출과 운영 비용을 키웁니다.
사업자는 수신 여유를 주문 분포와 비교합니다
평균 주문이 작아도 특정 시간대 큰 주문이 몰리면 채널별 최대 HTLC와 인바운드가 병목이 됩니다. 총 인바운드, 상위 주문 백분위, 가장 큰 단일 경로, 채널 상대 가동률을 함께 모니터링하세요. 한 숫자 임계치만으로 충분 여부를 판단하기 어렵습니다.
경고는 채널 capacity가 아니라 실제 receive 가능 추정치와 pending 비율을 기준으로 두는 편이 낫습니다. 유동성 조치 후 테스트 인보이스를 외부 경로에서 결제해 보되 실제 판매 주문과 상태를 섞지 않습니다.
자주 묻는 질문
제가 채널을 열면 인바운드가 생기나요?
초기 자금을 내가 전부 넣으면 주로 아웃바운드가 생깁니다. 지급·스왑·상대 개설 등으로 잔액이 반대쪽에 있어야 수신 공간이 생깁니다.
총 인바운드가 1백만 sat이면 그 금액을 한 번에 받나요?
보장되지 않습니다. 여러 채널을 합치려면 MPP와 경로가 필요하고 reserve·HTLC 한도도 적용됩니다.
재균형하면 잔액이 늘어나나요?
총자산을 늘리지 않고 채널 사이 방향을 바꾸며 라우팅 수수료만큼 총액은 줄 수 있습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
