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

• 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)을 지키는 것임