▲

SaaS는 브랜딩만 바뀐 "벤더 락인" 이에요

 (rwsdk.com)
8P by GN⁺ 3일전 | ★ favorite | 댓글 2개
  • SaaS 연동은 개발자가 제품에만 집중할 수 있게 해준다고 하지만, 실제로는 매번 숨겨진 5가지 비용(세금) 이 존재함
  • 도입 전 발견, 가입, 통합, 로컬 개발, 운영 각각의 단계에서 시간, 복잡성, 정신적 부담이 지속적으로 발생
  • SaaS가 아닌 통합형 플랫폼(Cloudflare, Supabase 등) 을 선택하면 이 반복적인 비용과 복잡성을 크게 줄일 수 있음
  • 벤더 락인은 피할 수 없는 현실이므로, 여러 서비스 혼합 대신 하나의 통합 플랫폼에서 개발 흐름(Flow) 을 지키는 것이 최선임
  • 결국 가장 중요한 것은 프레임워크·서비스 자체가 아니라, 내가 만들고자 하는 소프트웨어임

SaaS는 단지 더 나은 브랜딩의 벤더 락인임

  • 개발자들은 “제품 개발에만 집중하라”는 말을 듣지만, 실제로는 auth, 큐, 파일 저장, 이미지 최적화 같은 SaaS 벤더 도입 시 다양한 부담이 발생함
  • 금전적 비용뿐 아니라, 시간 소모, 마찰, 그리고 정신적 피로도 존재함.

1. 발견 세금 (Discovery Tax)

  • SaaS 서비스 도입 전, 실제로 판매하는 기능과 가치를 파악하는 과정이 필요함
  • 문제 해결 범위, 기존 스택과의 호환성, 규모 대비 합리적 가격, 문서의 명확성, 특이 구현 방식 등 세부 요소를 평가해야 함
  • 이러한 조사 과정은 이전 경험과 쉽게 공유되거나 반복되지 않으며, 상당 부분은 주관적 결정임
  • 마케팅 메시지가 나와 맞을지, 서비스가 실제로 도움이 될지 스스로 판단해야 하는 부담이 있음

2. 가입 세금 (Sign-Up Tax)

  • 서비스 선택 후, 이메일과 카드 정보를 제공해야 함
  • 사용 기반 과금이 가능한지, 구독형 락인만 지원하는지 검토가 필요함
  • 팀 멤버가 대시보드 접근을 위해 추가 비용이 발생하는 등 불투명한 가격 구조가 문제임
  • 무료 시험 사용 없이도 테스트가 가능한지, 초반부터 결제 요구가 있는지 점검해야 함
  • 코드 한 줄 작성 전부터 벤더와 계약 관계가 형성됨

3. 통합 세금 (Integration Tax)

  • 실제 도입 과정에서 문서 확인, 라이브러리 설치, 프레임워크 연결, 문서 외 추가 문제 해결이 필수임
  • 종종 도구와의 충돌이나 예상치 못한 문제에 직면함
  • SaaS가 최소 공통 분모만 대상으로 할 때, 최신 스택이나 특화된 환경에서는 더 많은 작업이 필요함

4. 로컬 개발 세금 (Local Development Tax)

  • SaaS 서비스의 로컬 환경 지원 여부가 불확실함
  • 로컬 에뮬레이터 제공, 테스트 목적으로 스텁 처리 가능성 필요
  • 일부 기능 확인을 위해 클라우드 터널링 등이 요구되어 환경 구성이 복잡해짐
  • 프로덕션, 스테이징, 로컬 각각의 설정 분기가 불가피해지는 상황임

5. 프로덕션 세금 (Production Tax)

  • 서비스 통합 후 프로덕션 환경에서 새로운 부담 발생
  • 스테이징, PR 프리뷰 환경에서도 사용 가능성, API 키 관리, 모니터링 및 로깅, 알림 등 추가 관리 필요
  • 개발 환경에서는 문제 없지만 실제 운영 환경에서만 발생하는 에러나 불일치에 대비해야 함
  • 서비스 안정성을 유지하는 책임이 결국 개발자에게 전가됨

결론

  • 현대 SaaS의 슬로건은 "바퀴를 다시 만들지 말라"이지만, 서비스 추가마다 마찰이 동반됨
  • 서비스 도입은 단순 통합이 아니라 계약이며, 의존성 증가와 아키텍처 변화를 수반함. 벤더 락인은 불가피하며, 교체 시 상당한 코드 재작성 부담이 따름.
  • 따라서, 이런 의사결정을 반복하기보다는 처음부터 일체형 플랫폼을 선택하는 것이 효율적임
  • 중요한 것은 개발자가 실제 만들고자 하는 소프트웨어임
  • Cloudflare, Supabase와 같은 통합 플랫폼은 데이터베이스, 큐, 이미지, 스토리지를 동일한 환경에서 제공하여 위에서 언급된 세금 부담을 대폭 줄여줌.
    • 여러 벤더 사이 전환(컨텍스트 스위칭) 필요 없음
    • API 키 조작 문제 발생 빈도 감소
    • 호환성 및 환경 별 분기 관리 필요성 최소화
    • 개발 및 프로덕션 환경에서 일관성 있는 통합 경험 제공
  • 이러한 플랫폼은 마치 모든 것이 동일한 머신에서 동작하는 느낌을 제공하며, 코드와 서비스 간 거리를 최소화하여, 어떤 SaaS에서도 제공하지 못하는 개발의 몰입감("Flow") 을 되찾게 해 줌.

중요한 것은 프레임워크나 서비스 선택이 아니라, 내가 만들고자 하는 소프트웨어와 흐름(Flow)을 지키는 것임

▲
galadbran 3일전  [-]

Supabase 가 좋은 사례로 제시되고 있는데요, 그러면 어떤 SaaS 들이 피해야할 서비스인 걸까요?

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 이것은 아담 스미스의 “rent seeking(임대료 추구)”을 현대에서 초대형 확장 방식으로 보는 시각임
    이런 경제 행위는 사회적으로 해롭기 때문에 지양해야 하고 범죄화해야 한다고 생각
    한편, 무료 소프트웨어의 극단 역시 경제적으로 문제이며, 그 이유는 소프트웨어 창작자의 노력이 사용자가 얻은 가치에 비례하지 못하기 때문
    소프트웨어를 구매하는 방식과 따로 서비스 계약을 맺어 각각 실제로 별도의 가치를 제공해야 한다고 주장
    SaaS에서 이런 것들이 하나로 묶이면서 실제로는 서비스 자체보다 패키징이 지나치게 기형적으로 변하는 부분이 문제라고 생각

    • 내가 그렇게 열정적이라면, 직접 SaaS를 구축해서 온프레미스 배포·운영하는 업체를 차려서 현재 SaaS와 유사한 가격에 제공해야 한다는 주장
      만약 기업들이 데이터 통제권을 유지하고 벤더 락인을 막으면서도 SaaS와 동일한 품질, 보증, 가격을 제공할 수 있다면 시장을 지배할 수 있다고 말함

    • 항상 이런 고민을 하게 되는데, 바이너리 제공만 하고 사용자가 AWS나 GCP, 또는 cloudflare workers에서 실행할 수 있게 하면 되지 않을까 생각
      내 입장에서 saas는 개발자로선 매력적이지만 소비자로선 싫어하는 구조라 스스로 윤리적 딜레마에 빠짐
      만약 내가 소프트웨어 판매를 한다면, 사용자가 무단으로 재배포해버리면 어떻게 하지? 사스처럼 배포를 통제하지 못할 텐데
      나는 foss(오픈소스) 지지자이지만, 말씀처럼 이 방식도 경제적으로 문제가 있음
      github 스폰서로 라이선스 발급 같은 방식도 생각하며 어떤 프로젝트에서는 인증이 SSPL, 아니면 라이선스 구입 시 BSD/MIT로 전환하는 모델(예전 redis와 유사)도 고민
      다만, 이런 모델을 직접 적용했을 때 실제로 사람들이 구매할지 의문이며, 양쪽 방법을 다 지원하는 것도 고려하고 있지만 뚜렷한 답이 없어 조언을 구함
      참고로 내가 만든 프로젝트로는 누구나 무료로 암호화폐를 만들 수 있는 툴, 유튜브에서 블로그 가져오는 기능, 유튜브 커뮤니티와 비디오를 구글포토 대체로 사용하는 무제한 저장소 등이 있으며, 프라이버시 보완도 고민하고 있음. 수익화 아이디어가 있다면 알려주길 바람

    • SaaS 대부분은 공급자 입장에서는 호스팅, 지원, R&D 등 지속적인 비용이 발생한다는 점을 언급
      이런 구조가 왜 “임대료 추구”인지 논리에 공감하기 어려움

    • SaaS가 모두 임대료 추구라고 볼 순 없고, 소프트웨어의 “stickiness(달라붙음, 락인)” 자체가 본질적으로 rent-seeking과 비슷하다는 점을 지적
      대부분 SaaS 업체가 stickiness를 추구하지만, SaaS 고유의 속성은 아니라는 관점

    • 나는 내 SaaS 제품을 시장에서 합리적인 가격에 구매하려는 고객에게 판매하는 입장임

  • 벤더 락인은 보통 사내에서 “왜 NEWTHING 도구를 도입하지 않느냐?”고 물었을 때, 이미 Oracle이나 MS, IBM, Salesforce와 5년 장기계약을 맺었기 때문에 어쩔 수 없다는 대답에서 느끼는 것임
    그래서 10년쯤 지나면 정말로 그 업체에 완전히 묶여 버리게 되고, 더는 바꿀 수 없어지는 구조가 생김

    • 사업이 10년이나 지속될 정도라면 오히려 축복 또는 지루한 문제일 수 있지만, 창업 초기에 여러 도구 선정에 시간 쓰지 말고 신속하게 한 플랫폼을 골라 집중하라는 조언을 하고 싶음

    • 이런 경우에도 서비스들을 표준화된 인터페이스로 추상화하는 것이 좋다는 견해
      추상화해두면 나중에 다른 서비스로 전환할 때 단순히 대안 구현만 제공하면 됨
      이 방식이 미래지향적이지만 요즘 많은 기업이 이런 준비가 부족하다는 점을 지적

  • 의존성 최소화는 제품과 비즈니스 지속 가능성을 향상시키는 가장 중요한 요소 중 하나라고 생각
    내가 이전 직장에서 DocuSign 스타일의 전자 서명 경험을 우리 제품에 통합하는 업무를 담당했음
    DocuSign, Adobe 등 주요 벤더와 논의했지만, API 제약이 많아 제품·고객 요구에 잘 맞지 않음을 느꼈고, 결국 내부적으로 직접 구현하기로 함
    보통은 DocuSign 같은 툴을 직접 만드는 건 악수이지만, 우리 제품은 이미 고객 신뢰를 받고 있었기에 도입 장벽이 낮았음
    직접 구현 과정에서 초기에는 일이 많았지만, 실제 고객 맞춤형 소규모 수정이 필요할 때 신속하게 대응할 수 있었고, 벤더 사용했으면 훨씬 번거로운 대공사가 됐으리라는 점에서 직접 구현 선택이 옳았음

  • 글쓴이는 SaaS는 벤더 락인이니 구매하지 말라고 주장한다고 이해됨
    그런데 정작 본문에서는 Cloudflare라는 특정 플랫폼에 올인하라고 권장하고 있음
    결국 어떤 선택을 해도 모두가 락인이고, 오픈소스·셀프호스팅조차 대체하면 대량 코드를 다시 짜야 한다는 식
    단순히 벤더 종속 기능을 사용하는 것과 “진짜 락인”은 다르고, 락인은 차라리 바꾸는 게 기존 방식을 유지하는 것보다 더 많은 비용과 시간이 들 때 발생함
    소프트웨어를 느슨하게 결합하고 응집성 있게 만들면 특정 부분 교체가 쉬움
    왜냐하면 인터페이스가 단순하면 교체도 쉽기 때문
    따라서 “모두 락인이니 그냥 더 확실하게 한 플랫폼에 묶인다”는 선택은 개발자 입장에서는 편하지만, 경영자 입장에서는 안 좋은 전략이고, 회사의 유연성과 변화 가능성에 집중해야 함

    • 사업가 입장에서는 회사에 유연성과 변화 가능성을 주는 솔루션을 선택해야 하고, 아무 대안 없이 SaaS에 묶이는 건 어리석은 이유라고 생각
      시작 단계나 수익이 없을 때는 SaaS보다는 플랫폼을 쓰는 게 유리하고, 성장해 확장 단계에 도달하면 장기적인 기술 변화까지 생각하는 게 맞음

    • 나는 cloudflare workers를 자주 활용하며 코드도 어디든 이식 가능하도록 작성 중임
      wrangler dev로 로컬 실행도 가능하고, 실제로 pure node/bun/deno에서도 큰 수정 없이 동작할 수 있음

  • OP(글 작성자)는 SaaS 자체를 반대하는 것이 아니라(결국 Cloudflare나 Supabase 같은 as a service 솔루션을 추천함), 너무 많은 공급자와 계약을 맺고 관리하는 운영 비용, 관계 관리의 부담을 지적하는 것이 요지임
    벤더 수가 적을수록, 의존성이 적을수록 운영이 쉬워진다는 이야기
    실제로 모든 기능을 표준 라이브러리로 구현하는 건 너무 이상적인 연상이지만, 현실적으로 아주 어려움

    • 네가 내 취지를 정확히 요약해줬으며, 내가 글 제목에서 자극적으로 표현했다는 점을 잘 지적함
      시작할 때 여러 서비스를 뒤섞기보다는 하나의 플랫폼을 써보라는 제안이 핵심
      내가 cloudflare를 선호하는 이유는 바인딩을 fetch처럼 표준화해, fetch가 웹 세계에서 유닉스 파이프처럼 느껴지기 때문임

  • 벤더 락인을 피하겠다고 한쪽 플랫폼에 전부 올인하며 더 심하게 자신을 한 회사에 묶는 건 아이러니라는 시각임

    • 만약 플랫폼은 락인이라 싫다고 하면서 SaaS를 쓴다면 논리적으로 성립하지 않는다는 주장
      SaaS에도 분산 비용(“세금”)이 있기 때문임

  • 오히려 이 논의는 오픈소스 옹호에 가깝다고 봄
    오픈소스와 셀프호스트 방식이라면 글에서 언급한 대부분의 “세금(발견, 가입, 통합, 로컬 개발 관련 비용)”이 해소됨
    오픈소스의 production tax(운영 부담)는 생태계 활성화나 플러그인, 모듈생태계로 해결 가능하다고 생각

    • 오픈소스도 결국 직접 관리, 개발에 시간을 꽤나 써야 해서, 시간 비용까지 고려하면 무료는 아니라는 지적

  • (종교와 컬트의 차이에 빗대어) 데이터를 표준 포맷으로 추출해 떠날 수 있으면 벤더 락인이 아님
    고객은 자기 데이터를 얻게 되면 덜 피해의식이 생기지만, 너무 많은 SaaS 서비스가 이를 불가능하게 만들고 있다는 문제의식도 언급

    • 사이드 프로젝트 수익화에 도전하려는 입장으로서, 자신이 어떤 라이선스·배포 방식을 택해야 할지 고민됨
      1. MIT 등 완전 허용 오픈소스
      2. AGPL/SSPL 등 제약 있는 오픈소스
      3. 소스는 공개하되 유료 결제 시에만 허용 라이선스로 바꿔주는 방식(초기부터 라이선스 정책을 명시적으로 유지)
      4. 소스 공개 없이 바이너리 판매
      5. 위 방안 중 하나를 따르되 기본은 SaaS로 제공하며, 고객이 쉽게 떠날 수 있는 구조까지 지원
        현재는 주로 MIT로 공개 배포하고, 중요한 건 비공개로 두는 식으로 운영하고 있음

  • SaaS의 한계는 소프트웨어의 “거의 0에 가까운 한계비용”으로부터의 혜택을 고객이 누릴 수 없게 만든다는 점임
    SaaS 사업자는 어느 정도 그 이득을 반영해 가격을 낮추긴 하지만, 사용자가 충분히 많고 단가가 높은 단계에선 결국 SaaS 이용자가 손해를 보게 됨
    하지만 스타트업 초기에는 직접 구축은 무모한 선택이고, “생존”과 “초기 비용 최소화” 단계에서는 SaaS가 매우 현명한 전략임
    사업이 성장하고 SaaS가 일상에 깊이 자리 잡은 뒤에야 락인, 이관, 전환 비용 문제가 발생
    SaaS 문제란 것도 결국 성공의 부작용이라고 생각

  • 그래서 이런 SaaS 모델이 엄청 많은 것임
    연금처럼 반복적으로 수익이 들어오고, 가격 결정권까지 갖는 사업모델이 너무 매력적임

답변달기