기업용 소프트웨어 시장은 오랫동안 구독형 SaaS가 지배해 왔다. 인증, CRM, 협업 도구를 직접 운영하는 대신 외부 플랫폼에 월 사용료를 내고 빌려 쓰는 방식이다. 그러나 이 모델이 성숙기에 접어들면서, 사용자당(per-seat) 과금과 벤더 종속에 대한 피로감도 함께 쌓여 왔다. OccupySaaS는 이런 불만을 정면으로 겨냥한 프로젝트다. 자신들을 'SaaS 거인에 대한 클린룸(clean-room) 방식의, AI 보조로 개발된, 오픈소스 드롭인(drop-in) 대체재'로 규정하고, Apache-2.0 라이선스와 자체 호스팅(self-hosted)을 전면에 내세운다.
과금 구조와 종속에 대한 문제 제기
이 프로젝트가 내세우는 논리의 핵심은 두 가지다. 첫째는 과금 구조다. 신규 직원, 인턴, 외주 계약자 하나하나가 모두 별도의 요금 항목이 되는 현실을 지적하며, 인프라가 '머릿수대로 임대료를 물려서는 안 된다'고 주장한다. 둘째는 종속성이다. 독점 API, 데이터 반출을 가로막는 '내보내기 장벽(export wall)', 예고 없는 가격 인상이 고객을 묶어 둔다고 본다. 이에 대한 해법으로 호환성을 갖춘 개방형 대안을 제시한다는 것이 이들의 구상이다.
여기서 눈여겨볼 단어는 '드롭인'과 '호환'이다. 단순히 비슷한 기능을 하는 별개의 오픈소스 제품을 만드는 것이 아니라, 기존 상용 서비스의 API 계약을 그대로 흉내 내 코드 변경 없이 갈아끼울 수 있게 하겠다는 접근이다. 과거의 오픈소스 대안들이 '기능은 유사하지만 연동 방식이 달라 마이그레이션 비용이 크다'는 벽에 부딪혔던 것과는 결이 다른 전략이다.
ZeroAuthy와 Salesforce 대체재
구체적인 사례로 두 가지가 제시된다. 하나는 ZeroAuthy다. Auth0의 인증(Authentication) API를 그대로 구사하는 자체 호스팅 아이덴티티 서버로, 기존 Auth0 SDK가 바라보는 지점을 ZeroAuthy 테넌트 도메인으로 바꾸기만 하면 코드 수정 없이 동작한다고 설명한다. 인증은 한번 특정 공급자에 묶이면 이전이 가장 까다로운 영역 중 하나인데, SDK 교체 없이 백엔드만 바꾼다는 발상은 실무자에게 분명히 매력적인 지점이다.
다른 하나는 Salesforce 대체재다. 테넌트 격리(tenant-isolated)를 적용한 Go/PostgreSQL 코어, Vue 기반 레코드 편집기, 그리고 Salesforce의 공개 API 계약에 비추어 동작을 검증하는 '호환성 실험실(compatibility laboratory)'로 구성된다고 한다. 특히 호환성 실험실은 이 프로젝트의 성패를 가를 요소다. 상용 SaaS의 API는 문서화되지 않은 동작과 예외 케이스가 많아, 겉으로 비슷해 보여도 실제 연동에서 어긋나기 쉽기 때문이다. 공개 API 계약을 기준으로 지속적으로 동작을 맞춰 간다는 설계는 호환성 주장을 검증 가능한 형태로 유지하려는 시도로 읽힌다.
프로젝트의 배경에는 산업 정서도 깔려 있다. 플랫폼 기업들이 성장을 이어 가는 사이 수많은 엔지니어가 일자리를 잃었고, '우리는 여전히 제품을 만들 줄 알며 이제 그것을 공개적으로 만든다'는 메시지를 전면에 내건다. AI 보조 개발을 표방하는 것도 적은 인원으로 방대한 상용 API 표면을 재현하겠다는 현실적 계산과 맞닿아 있다.
실무자가 따져봐야 할 한계
다만 현재 공개된 정보만으로는 신중할 필요가 있다. 드롭인 호환이라는 약속은 강력하지만, 상용 제품의 전체 기능 중 어느 범위까지 재현되는지, 성능과 안정성, 보안 책임을 자체 호스팅 환경에서 어떻게 감당할지는 드러나 있지 않다. 인증처럼 장애가 곧 서비스 전면 중단으로 이어지는 영역에서는 '호환된다'는 선언과 운영 신뢰성 사이의 간극이 특히 크다. 상용 SaaS가 제공하는 SLA, 규정 준수 인증, 운영 부담 대행이라는 가치를 자체 호스팅이 어디까지 대신할 수 있는지도 별개의 문제다.
그럼에도 OccupySaaS가 던지는 질문 자체는 유효하다. 좌석당 과금과 벤더 종속 비용이 계속 커지는 환경에서, API 호환을 무기로 한 오픈소스 대체재는 적어도 협상력과 선택지를 넓히는 수단이 된다. 한국 기업이라면 당장의 전면 교체보다는, 특정 워크로드에서 호환성 수준과 운영 부담을 작게 검증해 보는 실험 대상으로 접근하는 편이 현실적일 것이다.