purl — HTTP 결제가 필요한 API를 curl처럼 호출하는 CLI 도구

유료 API 호출, 터미널에서 바로 결제까지

개발자라면 curl은 거의 매일 사용하는 도구입니다. API 테스트, 디버깅, 간단한 데이터 수집까지, HTTP 요청이 필요한 거의 모든 상황에서 curl은 가장 먼저 떠오르는 선택지입니다. 그런데 최근 API 생태계에서 한 가지 변화가 눈에 띕니다. 점점 더 많은 서비스가 API 호출 자체에 과금하는 모델을 채택하고 있다는 점입니다. AI 모델 API(OpenAI, Anthropic, Cohere 등), 데이터 API, 프리미엄 SaaS API 등이 대표적입니다. purl은 바로 이 지점에서 출발한 도구로, "결제가 필요한 HTTP 요청을 curl처럼 간편하게 보낼 수 있게 하자"는 아이디어를 구현했습니다.

어떻게 동작하는가

purl은 curl의 인터페이스를 최대한 유지하면서, HTTP 402(Payment Required) 응답을 자동으로 처리하는 레이어를 추가한 CLI 도구입니다. HTTP 402 상태 코드는 사실 HTTP/1.1 표준에 "미래 사용을 위해 예약됨"으로 정의되어 있었는데, 실제로 널리 사용된 적은 거의 없습니다. purl은 이 코드에 새로운 생명을 불어넣는 시도입니다.

동작 흐름은 다음과 같습니다. 사용자가 purl로 유료 API 엔드포인트에 요청을 보내면, 서버가 402 응답과 함께 결제 정보(금액, 결제 방법 등)를 반환합니다. purl은 이 정보를 파싱하고, 사용자에게 결제 확인을 요청한 후, 결제를 처리하고 원래 요청을 다시 보냅니다. 이 모든 과정이 터미널 안에서 이루어집니다.

결제 수단으로는 주로 Lightning Network(비트코인 레이어2)와 같은 마이크로페이먼트 프로토콜을 활용하는 것으로 보입니다. 이는 기존 신용카드 결제의 최소 금액 제한(보통 0.50달러 이상)을 우회하여, 0.001달러 같은 극소액 결제를 가능하게 합니다. API 호출 한 건에 수 센트를 과금하는 마이크로페이먼트 모델에 적합한 방식입니다.

HTTP 402, 잊혀진 상태 코드의 부활

HTTP 상태 코드 중 402 Payment Required는 독특한 역사를 가지고 있습니다. 1997년 HTTP/1.1 표준(RFC 2068)에 처음 등장했을 때부터 "미래 사용을 위해 예약됨"이라는 설명이 붙어 있었습니다. 당시에는 웹에서 마이크로페이먼트가 보편화될 것이라는 기대가 있었지만, 실제로는 광고 모델이 웹의 주된 수익 구조가 되면서 402는 거의 사용되지 않았습니다.

그런데 최근 AI API의 폭발적 성장과 함께 "API 호출 단위 과금" 모델이 다시 주목받고 있습니다. OpenAI의 API는 토큰 단위로 과금하고, 각종 데이터 API는 쿼리 단위로 과금합니다. 이런 환경에서 402 상태 코드가 실질적으로 활용될 수 있는 토양이 만들어진 셈입니다. purl은 이 가능성을 구체적인 도구로 만들어낸 사례입니다.

L402 프로토콜과 마이크로페이먼트

purl의 기술적 기반에는 L402 프로토콜이 있습니다. L402는 Lightning Labs에서 제안한 프로토콜로, HTTP 402 응답에 Lightning Network 결제 정보를 포함시키는 표준화된 방식을 정의합니다. 서버는 macaroon(인증 토큰의 일종)과 Lightning invoice를 402 응답에 포함하여 반환하고, 클라이언트가 결제를 완료하면 macaroon에 결제 증명(preimage)을 첨부하여 다시 요청합니다.

이 방식의 장점은 기존의 API 키 발급, 구독 관리, 월별 청구 등의 복잡한 과정 없이 요청 단위로 즉시 결제하고 즉시 접근할 수 있다는 것입니다. 회원가입 없이, 신용카드 등록 없이, 단일 API 호출에 대해 수 밀리사토시(satoshi) 단위의 결제를 처리할 수 있습니다.

기존 도구들과의 비교

curl 자체도 HTTP 402 응답을 받을 수는 있지만, 결제 처리 로직은 없습니다. Postman이나 Insomnia 같은 API 클라이언트 역시 결제 통합 기능은 제공하지 않습니다. purl은 이 틈새를 노린 것입니다.

다만 현실적인 한계도 분명합니다. L402 프로토콜을 지원하는 API 서버가 아직 극소수라는 점, Lightning Network 월렛 설정이 일반 개발자에게는 진입장벽이 된다는 점, 그리고 마이크로페이먼트 모델 자체가 아직 메인스트림이 아니라는 점입니다. 현재로서는 실험적인 도구에 가깝습니다.

한국 개발자에게 주는 시사점

당장 실무에서 purl을 사용할 일은 많지 않겠지만, 이 프로젝트가 제시하는 방향성은 주목할 가치가 있습니다. API 과금 모델이 점점 정교해지는 추세에서, 결제와 인증이 프로토콜 레벨에서 통합되는 미래를 상상해볼 수 있습니다. 특히 AI 에이전트가 자율적으로 외부 API를 호출하는 시나리오에서는, 에이전트가 "필요한 API를 찾아서 소액 결제 후 사용"하는 패턴이 현실화될 수 있습니다.

또한 HTTP 402라는 30년 가까이 방치된 표준의 재발견은, 기존 스펙을 다시 들여다보는 것의 가치를 보여줍니다. RFC 문서에는 이처럼 시대를 앞서 정의되었다가 뒤늦게 빛을 보는 아이디어가 종종 있습니다.