오픈소스 Stripe 대안 ‘Lago’, 330억원 투자 유치

 (techcrunch.com)
3P by GN⁺ | ★ favorite | 댓글 2개
  • 파리 기반 Lago는 공식 출시와 함께 개발자용 오픈소스 청구 플랫폼으로 전환한 성과를 공개하며, 두 라운드에서 약 2,200만 달러($22m) 를 유치함
  • 최신 Series A 1,500만 달러는 FirstMark가, 이전 시드 700만 달러는 SignalFire가 주도했으며 Y Combinator, New Wave, Script와 개인 투자자들이 참여함
  • 원래 마케팅 팀용 “Zapier”를 만들려던 팀은 Hacker News의 개발자 청구 문제 글이 큰 반응을 얻자 청구 플랫폼으로 피벗함
  • Mistral.ai, Together.ai, Juni가 비공개 베타 초기 고객으로 합류했고, Lago는 구독·사용량 기반·하이브리드 가격제를 다루는 스타트업을 겨냥함
  • Stripe, Adyen, Salesforce, Zoho, Paddle 등이 있는 시장에서 Lago는 확장성과 맞춤형 청구 구현을 차별점으로 삼음

공식 출시와 투자 구조

  • 파리 기반 스타트업 Lago는 오픈소스 청구 플랫폼 공식 출시와 함께 총 2,200만 달러 투자 유치를 공개함
  • 투자는 두 라운드로 구성됨
    • 최신 Series A 1,500만 달러는 FirstMark가 주도함
    • 이전 시드 700만 달러는 SignalFire가 주도함
  • Y Combinator, New Wave, Script도 투자자로 참여함
  • 개인 투자자로는 MongoDB 수익화 책임자 Meghan Gill, 전 Stripe 출신이자 OpenAI 개발자 관계 담당 Romain Huet, Hugging Face CEO Clément Delangue가 포함됨
  • 소식통 기준 Lago의 기업가치는 약 1억 달러 수준임

비공개 베타와 초기 고객

  • Lago는 공식 출시 전 비공개 베타로 운영됨
  • 초기 고객에는 Mistral.ai, Together.ai, Juni 같은 스타트업이 포함됨
  • 개발자가 새 서비스에 맞춰 청구 체계를 직접 조정할 수 있도록 돕는 데 초점을 둠
  • 사용량 데이터를 측정해 구독이나 다른 가격제를 처리하도록 지원함

마케팅 도구에서 청구 플랫폼으로 피벗

  • Lago는 처음부터 청구 플랫폼을 만들려던 회사가 아니었음
  • 공동창업자 Anh-Tho Chuong과 Raffi Sarkissian은 Qonto에서 일하다가 창업했고, Y Combinator Summer 2021 코호트에 합류함
  • YC에 들어갈 당시 제품은 없었고, 이후 마케팅 팀을 위한 “Zapier” 아이디어를 선택함
  • 경쟁이 치열한 마케팅 기술 시장에서 초기 제품은 거의 견인력을 얻지 못함
  • Sarkissian은 관심을 끌기 위해 Hacker News에 개발자 청구 문제를 다룬 글을 올림
    • 제목은 “Billing systems are a nightmare for engineers”였음
    • Qonto에서 청구 문제를 해결하는 제품을 만들었던 경험과 맞닿아 있었음
  • 많은 사용자가 자신의 청구 문제를 공유하면서 Lago는 개발자용 청구 문제 해결로 방향을 바꿈

복잡한 청구를 겨냥한 오픈소스 전략

  • 단순한 가격제와 청구에는 이미 많은 솔루션이 있지만, 복잡한 청구에는 충분한 해법이 없다고 봄
  • AI 기반 제품을 만드는 회사들은 실행 가능한 비즈니스 모델을 찾는 중이며, 정액 구독과 사용량 기반 가격제를 섞는 하이브리드 방식을 고려하는 사례가 많음
  • 이런 방식은 개발자가 만드는 제품과 통합되고, 사용량 데이터를 판별해 적용할 수 있는 도구를 필요로 함
  • 많은 회사는 Qonto처럼 자체 청구 시스템을 만들지만, 엔지니어가 이를 싫어하고 전담 엔지니어를 고용하는 비용도 큼
  • Mistral.ai 공동창업자 겸 CTO Timothée Lacroix는 Lago 선택 이유로 오픈소스 생태계에 대한 믿음을 들었고, Lago 덕분에 릴리스 속도를 따라가며 본업에 집중할 수 있었다고 밝힘

경쟁 구도와 다음 확장 영역

  • 청구 시장에는 Stripe, Adyen, Salesforce, Zoho, Paddle 등 대형 기술 기업의 솔루션이 이미 있음
  • 오픈소스 접근을 택한 기존 제공자도 있음
    • FOSSBilling
    • ChargeBee
    • Kill Bill
    • AppDirect의 jBilling
    • Open Source Billing
  • Lago는 경쟁이 많은 시장에서도 확장성과 스타트업별 맞춤형 청구 구현에 기회가 있다고 봄
  • 향후에는 기존 사업을 확장하면서 두 가지 영역을 검토함
    • 원래 마케팅 아이디어와 연결되는 데이터 분석: 고객이 무엇을 소비하고 결제하는지, 결제 패턴이 어떤지 제공
    • 청구의 반대편인 결제 영역
  • 결제 스택 자체를 만들 가능성은 낮고, 사용자가 원하는 결제 도구를 쓰면서 청구 플랫폼과 잘 통합되도록 하는 결제 오케스트레이션에 초점을 둘 가능성이 큼

함께 보면 좋은 글 β

xguru   [-]

Lago 는 Stripe 와의 비교에 엄청 열을 올렸는데.. 역시나 투자 많이 받았네요.
Stripe의 실제 가격: 입문서 같은 글도 공개했었구요.

근데 빌링 API가 오픈소스라는게 뭔가 어울리지 않기는긴 합니다.

답변달기
GN⁺   [-]
Hacker News 의견들

  • 새 SaaS 제품에 써보려 했는데, 요금제가 월 $3,000부터 시작해서 당황했음
    방향이 반대인 듯함. 나 같은 작은 팀은 셀프 호스팅을 원하지 않고 관리형 솔루션을 원함. 큰 회사들은 규모가 있어서 오히려 셀프 호스팅할 여력이 있음

    • 무슨 말인지는 알겠지만, 이 전략이 통할 수도 있음. 이전 회사에서는 처음에 Stripe로 시작했고, 매출이 적어서 비용도 거의 없고 연동도 쉬웠음
      몇 년 지나 거래량이 커지자 계약 재협상을 원했는데, 그때 Lago로 재연동할 수 있었다면 Stripe 계약 갱신 때 협상 카드가 됐을 것 같음. Stripe 수수료로 월 $30k를 내고 있었으니, 월 $3k짜리 대안은 충분히 가치가 있었을 수 있음. 우리 상황은 SaaS 청구가 아니라 리테일이라 조금 달랐지만, 재무적으로 말이 되는 경우가 보임
    • 같은 함정에 걸렸음. 사용량 기반 과금은 우리에게 큰 고통이라 Lago에 기대가 컸지만, 외주로 맡길 수 있다면 인프라를 직접 운영하고 싶지는 않았음
      사용량 기반 과금 API 업체 5곳 정도와 이야기했는데, 현실적으로 우리가 내년 성장기 동안 머물 월 $1,000 미만 시장에는 거의 아무도 관심이 없었음. 게다가 Lago와 다른 업체들은 “매출 쉐어 없음”을 광고하면서도 항상 매출 비율로 가격을 제시함. 기술적으로는 매출 쉐어가 아니지만, 비용이 매출에 거의 선형으로 따라 올라감
    • 시장의 하단을 노리는 전략일 때만 방향이 반대인 것임. 여기서는 그런 전략으로 보이지 않음
    • 이 가격은 월 $3,000 이상을 수수료로 쓰는 Stripe 대형 고객이 목표라는 뜻으로 보임
      작고 지원 비용이 많이 들며 수익성이 낮은 고객은 피하고, 그런 고객은 Stripe가 손해 보게 둔 뒤 Stripe에서 이미 성장한 좋은 고객만 골라 가져오는 가격 전략이라면 영리함
    • 의도한 시장은 중간 크기 송어쯤일 수도 있음

  • 개발자에게 파는 건 힘들 거라고 봄. 개발자는 돈을 안 쓰고, 기회비용이 10배 들어도 직접 만들려고 함
    그리고 어떤 식으로든 수익화를 시도하는 순간 Redis 때처럼 “배신”이라며 대규모 이탈이 생길 것임. 나도 그런 개발자라서 앎

    • 사용량 기반 과금은 어렵다. Lago를 꽤 진지하게 검토했지만, 내 B2C API 사업에는 맞지 않았음
      고객 포털이 꼭 필요했는데 프리미엄 기능이었고, 프리미엄은 최소 월 $1,500였음. 내 매출로는 정당화하기 어려웠다. 다만 Lago는 의도적으로 매출 비율 과금을 피하고 있어서 기본 요금을 높게 받을 수밖에 없음. Stripe Billing은 비율로 과금하고, 성장하는 사업이라면 Stripe 청구서가 $1.5k를 넘는 건 시간문제임
      Stripe Billing의 사용량 기반 과금도 검토했지만 내 요구사항을 만족하지 못했음. 정액 과금에는 Stripe Billing을 쓰고 있음
      정확한 요구사항은 API 크레딧을 구독 포함 선불로 팔고 싶다는 것임. 예를 들어 사용자가 월 $10 크레딧에 가입하면 먼저 $10를 내고 그만큼의 크레딧을 쓰는 방식임. Stripe Billing은 사용량 기반에서 선불 청구를 지원하지 않고, 청구 기간이 끝난 뒤에만 청구함. 일부 사용자가 취소하고 안 내는 식으로 시스템을 악용해서 내게는 맞지 않음. Lago는 선불 청구를 지원했던 것으로 기억함
      구독 크레딧과 선불 크레딧도 자유롭게 섞고 싶었음. 사용자가 한 달에 할당량을 넘겼을 때 최고 요금제로 업그레이드하기보다 일회성 충전을 선호함. 어떤 크레딧이 먼저 소모되는지도 제어해야 하는데, Stripe Billing과 Lago 모두 여기서 문제가 있었음
      결제 수단도 최대한 많이, 특히 선불 크레딧에 대해 Alipay와 WeChat 같은 중국 지갑을 지원하고 싶었음. Lago는 이를 구현할 계획이 없었고, 직접 Lago 안에 구현하는 것까지 반쯤 고려했음. B2B에서는 WeChat과 Alipay가 크게 중요하지 않을 수 있음
      또 회귀 테스트가 매우 촘촘한 코드를 좋아하는데, Stripe Billing은 테스트 시계 기능 덕분에 이 면에서 Lago보다 훨씬 앞섬. Lago에는 구독 생명주기 테스트를 위해 시간을 앞으로 넘기는 기능이 없음. 제품을 신뢰한다면 제때 올바른 콜백을 받는다고 기대하면 되니 덜 중요할 수도 있음
      그래도 Lago 개발자들이 Slack에서 매우 깊은 기술 질문까지 시간을 들여 답하는 건 봤음. B2B 스타트업을 운영한다면, 특히 Stripe 계정 정지 사례가 많이 보이는 시점이라면 Lago를 어떻게든 맞춰 넣어보려 했을 것 같음
    • 전형적인 전형적 마음 오류임. 나도 개발자지만 시간을 아껴주는 것에는 기꺼이 돈을 냄
      그리고 이게 Lago의 핵심 가설 아닌가 싶음. 개발자들은 Stripe 같은 독점 제공자에 의존하기보다, 필요하면 직접 수정할 수 있는 오픈소스 청구 소프트웨어를 원한다는 것임. 그렇게 터무니없는 생각은 아님
    • 돈 안 쓰는 개발자는 아님. 경제적으로 생각하는 것은 공학의 기본 요소라고 믿음. 경제적으로 생각하지 않는다면 뭔가를 하고 있을 수는 있어도 공학은 아닐 수 있음
      옆 댓글처럼, 가치를 만들고 시간을 아껴주는 것에는 기꺼이 돈을 냄. 애초에 자체 청구 시스템을 만들 생각은 해본 적도 없음
    • 이 문제를 이미 풀지 못했다면 그 정도 투자금을 받지는 못했을 것 같음

  • 내가 늙어서 오픈소스의 의미에 대한 감각이 현실 변화에 적응하지 못한 걸 수도 있지만, 오픈소스와 “$22M 투자”가 한 문장에 있으면 바로 “오픈소스는 무슨”이라는 생각이 듦

    • 오픈소스 소프트웨어를 수익화하지 않고 만들려면 어떻게 해야 하는지 가이드가 있나? 아니면 VC 자금을 받으면 진짜 오픈소스가 아니게 되는 건가?
      이런 정서를 많이 봤고, 특히 rich harris 같은 오픈소스 베테랑에게서도 봤음. 아이러니하게도 그는 지금 VC 돈에서 월급을 받음. 한편으로는 나도 불평하고 싶고, 사람들은 만들고 나누는 즐거움만으로 열린 소프트웨어를 만들어야 한다고 말하고 싶음. 하지만 현실 세계에서 살아가는 데는 돈이 많이 들고, 내가 유용하게 쓰고 아마 직접 수익까지 낼 소프트웨어를 누군가 밤과 주말에 만들고 GitHub 스타만 받으라고 기대하는 건 비생산적이고 불공정해 보임
    • 동의하지만 동시에 대안이 뭔지 모르겠음. 여가 시간에 그냥 만들고, 기부 몇 푼을 구걸하고, $corporate가 아무것도 돌려주지 않으면서 서비스로 팔게 두는 건가?
      Lago 맥락에서 오픈소스의 이점은 홍보와 개발자 호감 말고는 잘 모르겠음. 요즘 오픈소스로 만들면 진퇴양난이고, 이것이 더 긴 수명과 지원을 가져오는 미래라면 받아들일 수밖에 없다고 봄
    • 내가 틀렸다면 고쳐주면 좋겠지만, SUSE, Red Hat, Databricks도 이런 식 아닌가? 유용한 오픈소스 도구를 제공하고, 그 주변 서비스로 개발을 지속할 돈을 버는 구조라고 이해하고 있음
    • “VC가 수익화 압박을 높일 때까지의 오픈소스”라는 뜻임. 이후 더 제한적인 라이선스로 바꿔서 기존 기여자와 커뮤니티 전체를 망치는 흐름임
    • “오픈소스는 무슨”이라는 직감과 싸우고 싶지는 않지만, 왜 그렇게 느껴지는지 설명해볼 수 있음
      1970년대 중반 오픈소스가 시작됐을 때의 정신은 소프트웨어를 무료로 나누는 것이었음. 돈은 대학이나 기업 연구 보조금 형태였고, 사업 모델은 없었음. 1998년에 RedHat, MySQL 등이 자유 소프트웨어 위에 유료 지원과 서비스를 얹으면서 돈이 본격적으로 들어왔음. 2000년대 중반부터는 클라우드 컴퓨팅 때문에 오픈소스로 돈 버는 생각이 흔해짐. SaaS에서는 사용자가 내부가 오픈소스인지 독점 소프트웨어인지 모르거나 신경 쓰지 않으므로, 오픈소스도 같은 경기장에 올라오게 됨
      VC가 오픈소스를 좋아하는 이유는 몇 가지가 있음. 나는 머신러닝 엔지니어 출신 투자자인데, 개인적으로는 spaCy 같은 훌륭한 오픈소스를 대학 때 썼던 향수도 있고, 커뮤니티·투명성·환원 같은 가치에 공감함. 동시에 VC의 일은 돈을 버는 것임
      폐쇄 소스 회사는 영업과 마케팅에 많은 돈을 쓴다. 개발자는 보통 판매당하는 걸 싫어하고, 설득당하기보다 직접 선택해야 함. 회사가 개발자의 마음을 얻으면, 수백만 달러를 영업과 마케팅에 쓰지 않아도 구매 검토 단계로 소프트웨어가 끌려 들어가므로 사업 모델이 더 효율적임. 방어력도 더 강함. 대기업은 정장을 입은 영업 인력에 돈을 쏟아 제품을 팔 수 있지만, 개발자의 사랑은 살 수 없음. 거기에는 훌륭한 개발자 경험과 좋은 개발자 관계가 필요함
      다만 오픈소스로 돈 버는 일은 SaaS보다 훨씬 어렵다. SaaS에서는 제품-시장 적합성을 이야기함. 같은 방식으로 쓰고, 같은 방식으로 사고, 같은 가치를 얻는 고객 5곳 이상을 찾아 예측 가능성을 만들면 VC가 돈을 주고 영업을 확장함. 오픈소스에서는 이 문제가 3배가 됨. 프로젝트-커뮤니티 적합성은 GitHub Stars로 보고, 제품-시장 적합성은 다운로드로 보고, 가치-시장 적합성은 매출로 봐야 함. 게다가 구매자가 개발자나 사용자와 다를 수 있음. 훌륭한 오픈소스 제품 대부분은 가치-시장 적합성에서 실패함
      오픈소스 회사 창업자 대부분은 가치를 회수하는 데 실패함. 너무 어렵거나, 오픈소스는 “무료 소프트웨어”여야 한다는 느낌 때문에 수익화를 미루기 때문임. 그리고 수익화를 시작할 때는 너무 늦어짐. 몇 년 동안 우유를 공짜로 받아왔다면 소를 사겠는가? 또 다른 이유는 방법을 모르기 때문임. 오픈소스로 돈 버는 전형적인 방법은 지원과 서비스 판매, 독점 기능을 파는 오픈 코어, 호스팅과 도구를 파는 SaaS임. 예로 RedHat, Confluent, Elastic, Databricks가 있음
      성공한 오픈소스 회사를 기준으로 단순하게 보면, 무료 버전은 한 명의 개발자가 일을 끝내는 데 필요한 모든 기능을 가져야 함. 유료 제품은 팀으로 일을 끝내는 데 필요한 추가 기능을 제공해야 함
      오픈소스를 좋아하고, 매우 똑똑한 창업자와 수많은 기여자가 열정을 쏟아 만들고도 확장하지 못하고 보상받지 못하는 걸 보면 안타까움. 상업화는 거기에 도움이 되지만 정말 어렵다. 오픈소스에 기여하고 만드는 사람은 커뮤니티를 중시하고 무료로 주고 싶어하므로, 돈을 버는 생각 자체가 불편해짐. 불편해지면 사람은 익숙한 곳으로 돌아가고, 대부분의 엔지니어에게 그것은 코딩임. 그래서 멋진 기능이 많은 훌륭한 오픈소스 소프트웨어와, 수익화를 너무 오래 미룬 창업자가 생김. 어느 순간 돌아올 수 없는 지점을 지나면 또 하나의 유망한 회사가 죽고, 아무리 제품이 멋져도 투자자는 돈을 돌려받을 수 없다면 투자하지 않음

  • 여전히 처리 수수료를 내야 한다면 여기서 장점이 뭔가?
    자체 결제 스택과 PCI 준수를 유지해야 한다면 엄청난 산만함이 될 것 같음

    • 이건 Stripe의 핵심 결제망 자체가 아니라 Stripe Billing 대안임. 실제로 Lago와 함께 Stripe나 비슷한 결제 수단을 쓰게 됨: https://docs.getlago.com/guide/payments/overview
      반복 결제, 청구서, 비례 정산되는 요금제 변경, 계량 과금의 엣지 케이스를 추적하는 건 어렵다. 그리고 Stripe Billing API도 많은 경우에 그리 유려하지 않음. 이 영역에 새 레이어가 나오는 건 반가움
    • 사실 PCI 준수는 상당 부분 해결된 문제임. https://verygoodsecurity.com 같은 걸 쓰고 Lago와 셀프 호스팅 앞에 프록시를 감싸면 가장 쉬운 PCI 준수 등급에 해당할 수 있음
      참고로 Very Good Security를 창업했고 8년간 CEO였음
    • 그런데도 사람들은 블록체인에 쓰임새가 없다고 말할 것임

  • 비슷하게 Rust로 작성된 오픈소스 https://hyperswitch.io가 있음
    Lago는 Ruby로 작성됐고, Java로 작성된 다른 오픈소스 청구 시스템도 몇 개 찾았음. Node.js로 된 걸 아는 사람 있나?

    • 서비스가 어떤 언어로 만들어졌는지가 왜 중요한가? Stripe나 Lago의 코드베이스와 직접 상호작용하지는 않을 텐데
    • Hyperswitch는 청구가 아니라 결제만 하는 것처럼 보임

  • Paris가 새 핀테크 스타트업을 만들어내는 데 정말 뜨거운 곳처럼 보임

    • 완전히 동의하지만, 실적은 좋지 않았고 EU의 지원으로 설명되는 부분도 있음. EU 지원 자체가 나쁘다는 뜻은 아니지만, 유럽에는 배고픈 창업자가 충분하지 않고, 높은 생활 수준을 생각하면 설명하기 쉬움. 이게 역설임
      반대로 France에서 훌륭한 의도로 나온 반례도 있음. 예를 들어 Semmle [1]은 저장소 정적 분석을 위해 GitHub에 인수됐음. Inria [2]도 훌륭하지만, 문제는 연구가 아니라 미국식 회사들과 사업 수준에서 어떻게 경쟁하느냐임
      [1] https://en.wikipedia.org/wiki/Semmle
      [2] https://www.inria.fr/en

  • GitHub README에 Drake 밈을 쓰고 있음
    https://github.com/getlago/lago
    https://imgur.com/a/gsrhUXm
    기술 문서의 밈화는 볼 줄 몰랐는데… 세상에

    • 2015년 이후에 업계에 들어온 건가 싶음. Cassandra DB 같은 기술적 주장을 평가한 Jepsen Reports처럼 매우 기술적인 분석에도 기술 내용 사이에 밈이 많이 들어갔음. 발표 자료에도 늘 고양이나 개 사진이 있었고
    • 기술 문서에는 예전부터 다양한 형태로 밈이 있었음. 무해하고 지능·감성 신호도 주니 반갑다. 뭐든 너무 진지하게 받아들이는 건 좋은 일이 아님
    • 다만 패널 순서가 잘못된 건 이상함
    • 기술자와 문서가 존재한 만큼 오래전부터 기술 문서에는 밈이 있었음
    • K&R에서 재귀를 찾아본 적 없나? Google도 한때 그 농담에 참여했던 걸로 기억함

  • 실제 Stripe Payments 대안 아는 사람 있나? Stripe가 우리와는 일하기 싫어하고, 폐쇄 소스 경쟁사와만 일하려 해서 PayPal에 묶여 있음

    • https://mollie.com을 시도해볼 수 있음
      참고로 거기서 일함
    • 시장에는 많이 있음. 다만 각각 장단점이 있고, API는 더 다루기 어려울 가능성이 큼

  • 이건 Stripe 대안이 아님
    청구, 송장, 결제, 권한, 구독은 모두 다른 것들임

    • 실제로 우리는 청구부터 시작하고 있고, 장기적으로는 open revenue hub가 되는 비전을 갖고 있음. 큰 단계는 여기 정리했음: https://www.getlago.com/blog/lago-raises-22-millions
      RevOps 전반에 대한 열린 대안을 제공하고 싶다는 뜻임. Stripe처럼 폐쇄 소스 생태계에 들어가는 대신, 맞춤형 스택을 만들고 “최고의 도구 조합” 접근으로 긴 꼬리의 도구, 사용 사례, 자체 시스템을 붙일 수 있게 하려는 것임. Stripe에는 21개 제품이 있고, 많은 창업자는 자신이 “Stripe payments”만 쓰는 게 아니라 그중 3~6개를 쓰고 있으며 각각이 보통 매출 일부를 가져간다는 걸 잘 모름

  • Series A로 15M을 유치했고, 밸류에이션은 발표되지는 않았지만 100M으로 소문남
    Crunchbase에 따르면 7M은 2023년에 받은 시드 투자였음. 링크된 글의 마지막 문단을 보면 Stripe 전체를 대체하려는 건 아닌 듯함. 어쨌든 열정적인 HN 글에서 시작된 성공적인 스타트업 피벗 이야기라 흥미로움

    • 우리는 먼저 Stripe의 핵심 서비스 중 하나인 Billing 대안을 만드는 데 집중하고 있음. 특히 Stripe가 약한 혼합 과금이나 사용량 기반 과금 모델 영역의 청구를 만들고 있음
답변달기