B2B SaaS 빌더를 위한 최고의 셀프 호스팅 CIAM

SaaS형 CIAM 플랫폼의 가격을 살펴본 적이 있다면 비용이 얼마나 빠르게 불어나는지 눈치챘을 것이고, 셀프 호스팅 방식을 한 번쯤 고민해봤을 것입니다.

이 글은 소규모 B2B SaaS 팀이 두 번째 정규직 업무로 만들지 않고도 실제로 운영할 수 있는 네 가지 셀프 호스팅 CIAM 플랫폼, 즉 ZITADEL, FusionAuth, Logto, Ory Hydra를 다룹니다. 네 가지는 형태가 저마다 다르고, 어느 것이 맞는지는 기능 목록보다 어떤 B2B 제품을 만들고 있는지에 더 좌우됩니다. 이 비교를 만들기 위해 한 대의 VPS에서 일주일 동안 나란히 돌려봤고, 아래는 CIAM에 대해 DM을 보낸 창업자에게 제가 보낼 그대로의 내용입니다.

먼저 한 가지. 이 글은 제품 기능으로서의 CIAM을 다루며, 사내 팀을 위한 내부 SSO가 아닙니다.

요약

셀프 호스팅 CIAM 플랫폼 네 가지를 한 줄씩 정리하면:

• ZITADEL 멀티테넌시와 B2B 조직 기능을 기본 제공으로 원한다면.
• FusionAuth 잘 다듬어진 관리자 UI와 길고 예측 가능한 릴리스 이력을 원한다면.
• Logto 첫날 개발자 경험이 가장 깔끔한 쪽을 원한다면.
• Ory Hydra 프로토콜 수준에서 직접 만드는 개발자로서, 정해진 로그인 앱이 아니라 OAuth 2.0 엔진 자체를 원한다면.

결론부터 말하면, 일반적인 B2B SaaS에는 ZITADEL이 가장 안전한 첫 선택이며, 이 글의 나머지는 그 근거를 풀어내는 부분입니다.

CIAM이 사내 SSO와 다른 결정인 이유

사내 팀용 SSO가 죽으면 피해는 대개 국지적입니다. 엔지니어가 한 시간쯤 Grafana나 다른 내부 도구에 접근하지 못하는 정도죠. CIAM이 죽으면 요금을 내는 고객이 제품에 아예 로그인하지 못합니다. 그러면 질문이 "어떤 인증 도구가 우리 팀에 편한가?"에서 "어떤 인증 시스템을 제품의 일부로 신뢰할 수 있는가?"로 바뀝니다.

B2B SaaS가 필요로 하는 종류의 아이덴티티 인프라인 CIAM에는, 많은 사내 SSO 도구가 강조하지 않는 기본 요소도 필요합니다. 고객은 한 명의 사용자가 아니라, 자체 사용자와 역할, 브랜딩, 경우에 따라 기업 IdP로 향하는 자체 SAML 연결까지 갖춘 조직(테넌트)입니다. 사람을 인증하는 데 그치지 않고, 같은 제품 안에서 한 회사의 사용자를 다른 회사의 사용자로부터 격리하는 일입니다. 아래 네 가지 도구가 저마다 다른 방식으로 겨냥하는 것이 바로 이 B2B 형태입니다. Keycloak에는 이제 일급 개념의 Organizations가 있습니다. 따라서 사내 전용 도구로 치부하는 것은 이미 낡은 시각입니다. 제외한 이유는 FAQ에서 설명합니다.

직접 만들 것인가, 살 것인가, 직접 호스팅할 것인가라는 삼각 구도도 여기서는 다르게 보입니다. OAuth를 처음부터 작성하는 것은 자초한 실수입니다. 당신이 내놓는 것은 SaaS 제품이지 아이덴티티 제공자가 아닙니다. 매니지드 서비스를 구매하는 것(Auth0, Clerk, WorkOS)은 팀에 운영 여력이 전혀 없고 예산이 합리적일 때 옳은 선택입니다. 두 명짜리 스타트업에 첫날부터 인증을 직접 호스팅하라고는 결코 말하지 않겠습니다. 셀프 호스팅이 합리적이 되는 시점은 매니지드 CIAM의 MAU 단가가 인프라 비용에 지속적인 엔지니어링 시간을 더한 값을 넘어설 때, 혹은 배포와 데이터 플레인을 직접 통제해야 할 때입니다. 제가 함께 일한 팀들에서는 그 지점이 보통 "진짜 제품이 생겼다"와 "진짜 고객 성공 조직이 생겼다" 사이에 찾아옵니다.

고객의 앱이 아니라 자체 앱을 위한 SSO를 찾고 있다면, 그것은 이 글과는 다른 비교입니다. 이제 추천 목록으로 넘어가겠습니다.

네 가지 도구, 하나씩

이 넷을 고른 이유는 내부 SSO가 아니라 제품 인프라로 평가할 만큼 충분히 CIAM다운 형태를 갖췄기 때문입니다. ZITADEL, FusionAuth, Logto, Ory는 모두 실질적인 셀프 호스팅 경로가 있고, 진지하게 검토할 만한 저변도 있습니다. 라이브러리에 그치는 선택지, 사내 SSO 지향 도구, 성숙도가 낮은 후보는 FAQ에서 다루는 편이 낫습니다.

ZITADEL

ZITADEL은 Go로 작성된 스위스 태생의 아이덴티티 플랫폼으로, 이벤트 소싱 아키텍처와 PostgreSQL 백엔드를 씁니다. 2026년 7월 27일 기준 최신 GitHub 릴리스는 the 4.16 series, current as of July 2026. ZITADEL은 v3부터 Apache 2.0에서 AGPL-3.0으로 옮겼습니다. 일반적인 SaaS 사용이라면 실무적 영향은 들리는 것만큼 무섭지 않은 경우가 많고, 자세한 내용은 FAQ에서 다룹니다.

B2B SaaS에서 ZITADEL이 두드러지는 지점: 조직과 멀티테넌시가 일급 기본 요소라는 점. 범용 객체를 조합해 만들어내는 기능이 아닙니다. Organization을 만들면 자체 사용자, 정책, 브랜딩, 접근 설정이 따라오고, 프로젝트를 부여하면 해당 조직의 관리자가 자기 사용자들의 역할 배정을 직접 관리합니다. 범용 사용자 위에 "테넌트"라는 개념을 새로 만들 필요가 없습니다. 처음부터 그것으로 시작합니다.

개발자 경험은 API 우선입니다. 현재의 v2 REST 리소스 API에 더해 레거시 v1 서비스에 대한 gRPC 및 REST 접근도 제공합니다. 공식 및 커뮤니티 SDK가 일반적인 서버 스택을 커버합니다. 관리자 콘솔은 제 몫을 하지만 FusionAuth 쪽보다는 밋밋합니다.

제 판단: B2B SaaS를 만들고 있고 테넌트가 생길 것이 확실하다면 저는 ZITADEL부터 시작하겠습니다. 셀프 호스팅 선택지 가운데 B2B 로그인 문제를 가장 뚜렷하게 중심에 두고 설계된 쪽입니다.

FusionAuth

FusionAuth는 Inversoft, LLC(FusionAuth라는 상호로 활동하는 델라웨어 LLC)의 미국 기반 플랫폼으로, 나머지 셋보다 오래됐고 그 점이 좋은 의미로 드러납니다. 관리자 UI는 다른 것들보다 눈에 띄게 잘 다듬어진 느낌이고, 문서는 성숙하며, 릴리스 주기는 숨 가쁘기보다 꾸준합니다. 4년 된 인증 연동을 물려받고서 지루한 선택지를 골라준 전임 엔지니어에게 속으로 고마워한 적이 있다면, FusionAuth가 바로 그 고마움을 받을 만한 CIAM입니다.

사람들이 걸려 넘어지는 지점은 라이선스입니다. FusionAuth Community는 직접 호스팅하면 무료지만, 핵심 제품은 오픈소스가 아닙니다. 이 제품은 다음의 적용을 받습니다: FusionAuth 자체 라이선스. 이 제한은 FusionAuth를 재배포하거나 임베드하거나 리브랜딩하거나 재판매하거나, 자사 고객을 위해 호스팅할 계획이라면 중요해집니다. 셀프 호스팅 Community 버전은 B2B SaaS의 핵심 사례를 커버합니다. 유료 플랜은 기능을 추가하며 IdP 시작 SAML, 고급 MFA, 애플리케이션별 테마 등이 포함됩니다. 반면 SCIM, Tenant Manager, 애플리케이션 수준 MFA 정책은 Enterprise에 있습니다.

B2B 형태에 관해서는, FusionAuth가 테넌트와 애플리케이션을 모델링하기는 하지만 그 추상화는 "도메인 객체로서의 B2B 조직"이라기보다 "테넌트별로 컨테이너화된 인증"에 가깝습니다. 동작은 합니다(그 위에 제품을 출시해봤습니다). 다만 멀티테넌시가 일급 B2B 모델이라기보다 격리용 기본 요소처럼 느껴집니다. 공식 SDK와 클라이언트 라이브러리는 폭이 넓습니다:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

서버 사이드 라이브러리는 얇은 API 클라이언트입니다. 관리자 콘솔은 다른 것들보다 엔지니어가 아닌 운영 담당자에게 넘기기가 상대적으로 수월합니다.

제 판단: 팀이 B2B 네이티브 기본 요소보다 UI 완성도와 길고 예측 가능한 이력을 더 중시한다면 FusionAuth입니다. 여기서 가장 "지루한" 선택이고, 그건 칭찬입니다.

Logto

Logto는 넷 중 가장 최근에 나온 것으로, Silverhand Inc.가 개발했으며 MPL-2.0 라이선스를 따릅니다, 대시보드에 가장 눈에 띄게 공을 들인 제품이기도 합니다. 첫날 셋업이 비교적 빠릅니다. 프로비저닝하고 마법사를 클릭해 넘기면 15분쯤 만에 괜찮은 기본 로그인 UI를 갖춘 OIDC 제공자가 돌아갑니다(넷을 나란히 돌리던 그 주에 실제로 시간을 재봤습니다). 공식 퀵스타트가 요즘 프레임워크와 서버 스택을 두루 다루기 때문에, 스택이 "Next.js + Postgres + 무언가"라면 금세 익숙해질 겁니다.

이 제품의 B2B 해법은 Logto Organizations. 조직 멤버십, 조직 범위 역할, 멤버 초대, 저스트 인 타임 프로비저닝, 엔터프라이즈 SSO 연동 등 핵심 B2B 기본 요소를 커버합니다. 조직 모델이 ZITADEL 것보다 새롭기 때문에, 특이한 SAML·SCIM·페더레이션 플로가 있다면 확정하기 전에 목표 고객사를 대상으로 검증해보길 권합니다.

트레이드오프는 성숙도입니다. Logto는 여기서 가장 새로운 선택지입니다. 로드맵이 빠르게 움직이는데, 필요한 기능이 도착할 때는 반갑고 호환성을 깨는 변경이 올 때는 불편합니다. 당신의 B2B SaaS가 멀티테넌시 스펙트럼의 단순한 쪽(조직 수가 적고 특이한 페더레이션 요구가 없는 경우)에 있다면, Logto의 개발자 경험이 나머지 결정을 한결 쉽게 만들어줍니다.

제 판단: 첫날을 가장 빠르게 띄우고 싶고 B2B 요구사항이 아직 비교적 단순하다면 Logto입니다.

Ory Hydra(그리고 Ory 스택)

Ory Hydra는 Ory 생태계의 OAuth 2.0 / OpenID Connect 서버로, Apache-2.0 라이선스를 따릅니다. 전체 Ory 스택은 Hydra에 Ory Kratos(아이덴티티와 사용자 관리, 셀프서비스 로그인, 가입, MFA, 계정 복구), Ory Keto(정책 결정 지점 역할을 하는 Zanzibar 스타일 인가 서버), Ory Oathkeeper(들어오는 HTTP 요청을 인증·인가·변형하는 아이덴티티 및 액세스 프록시)를 함께 씁니다. 필요한 것만 골라 조립하는 방식입니다. 전부 Go로 작성됐고 API도 깔끔합니다.

함정(그리고 이것은 결함이 아니라 알맞은 팀에게는 장점입니다)은 Hydra가 애플리케이션이 아니라 엔진이라는 점입니다. 설계상 Hydra는 별도의 로그인 및 동의 앱에 연결됩니다 . 이 앱은 당신이 직접 제공합니다. 바로 쓸 수 있는 로그인 화면을 원한다면 이 도구는 아닙니다. 반대로 인증 플로 자체가 제품의 일부인 무언가(개발자 플랫폼, 맞춤형 B2B 포털, 자체 온보딩을 갖춘 API 우선 제품)를 만들고 있다면, 정해진 UI가 없다는 점이 바로 원하던 성질입니다.

B2B 이야기는 턴키가 아니라 조립형입니다. Kratos 스키마와 Keto 관계를 여러분의 조직 레이어에 배선하면 멀티테넌시를 모델링할 수 있고 실제로 동작하지만, 그 배선은 여러분이 합니다. 비용은 배관 작업이 늘어난다는 것이고, 이득은 경험을 직접 통제할 수 있다는 것입니다. Ory 문서는 프로토콜 표면을 깊이 다루지만, 조립형 모델은 프로토콜 수준의 결정을 직접 내리는 데 익숙하다는 전제를 깔고 있습니다. "audience claim"이나 "PKCE"가 아무 감이 오지 않는다면 나머지 셋 중 하나로 시작하세요.

제 판단: 프로토콜 수준의 무언가(인증 게이트웨이, 맞춤 플로, 개발자 플랫폼)를 만들고 있고 기성 앱이 답답하게 느껴진다면 Ory가 정답입니다. 오늘 당장 로그인이 돌아가길 원하는 일반적인 B2B SaaS라면 아닙니다.

한눈에 보는 비교

네 도구의 요약을 표 하나로 정리했습니다. 두 번째로 훑을 때 유용하지만, 위의 개별 설명을 대신하지는 않습니다.

어느 것부터 시작해야 할까?

이 주제로 이야기를 나눌 팀 대부분을 포괄하는 짧은 시나리오 네 가지입니다.

B2B SaaS를 만들고 있고, 테넌트가 생길 것이 확실한 경우. ZITADEL부터 시작하세요. 멀티테넌시와 조직 기본 요소가 정확히 이 용도로 설계됐고, API 표면이 포괄적이며, 테넌트 모델을 직접 고안하는 데 드는 시간이 나머지 셋보다 적습니다. AGPL 전환은 라이선스 검토를 받을 만하지만, 수정하지 않고 별도로 통합한 배포라면 대개 단순한 SaaS 사용 사례입니다.

잘 다듬어진 관리자 UI와 안정적이고 예측 가능한 플랫폼을 원하는 경우. FusionAuth입니다. Community 플랜은 많은 팀의 핵심 요구를 충족합니다. 다만 라이선스와 기능 매트릭스를 꼼꼼히 읽을 시간을 확보하세요. IdP 시작 SAML, 고급 MFA, 애플리케이션별 테마 같은 기능은 유료 플랜이 필요하고, SCIM과 Tenant Manager, 애플리케이션 수준 MFA 정책은 Enterprise에 있습니다.

현재 B2B 요구사항이 단순하고, 첫날을 가장 빠르게 띄우고 싶은 경우. Logto입니다. 나란히 돌려본 테스트에서 첫날 개발자 경험이 가장 빨랐습니다. 더 젊은 생태계에 베팅하는 것임을 받아들이고, 요구사항이 검증하지 않은 페더레이션 엣지 케이스로 커지면 선택을 다시 검토하세요.

인증 플로가 제품 경험의 일부인 무언가를 만들고 있는 경우. Ory Hydra(권한이 필요하면 Kratos와 Keto까지)입니다. 코드를 더 많이 쓰게 됩니다. 대신 통제권도 더 커집니다. 그 맞바꿈이 와닿지 않는다면 당신은 Ory의 대상 독자가 아닙니다. 나머지 셋 중 하나를 고르세요.

이 설명 중 두 가지가 자신에게 해당한다면 기본값으로 ZITADEL을 선택하세요. 가장 폭넓게 들어맞고, 추가 질문을 많이 던지지 않고도 소규모 창업 팀에 건넬 수 있는 쪽입니다.

셀프 호스팅이 치르게 하는 비용(운영 측면)

여기부터는 이 글에서 낭만이라곤 없는 부분입니다.

PostgreSQL 백업 규율은 이제 사업이 의존하는 요소입니다. 이런 구성에서 보호해야 할 아이덴티티 상태에는 사용자 레코드, 해시된 자격 증명, MFA 시크릿, OAuth 클라이언트 자격 증명, 세션 데이터가 포함될 수 있습니다. 이 상태를 잃으면 고객이 로그인 자체를 못 하게 될 수 있습니다. 첫 실사용자가 가입하기 전에 자동 백업을 구성하고, 복원을 실제로 테스트하고, 백업 상태를 애플리케이션 가동률과 같은 알림 채널에 올려두세요.

릴리스 속도는 시기에 따라 달라집니다. ZITADEL v4.16.1은 6월에 여러 릴리스를 거친 뒤 2026년 7월 17일에 나왔고, 여기 나온 프로젝트마다 자체 주기와 호환성 정책을 유지합니다. 그 주기는 유지보수 관점의 사안으로 다루고, 품질을 가늠하는 지름길로 삼지 마세요. docker compose pull을 실행하기 전에 릴리스 노트를 읽고, 정기적인 패치 창을 잡아두세요. 아이덴티티 제공자 업데이트를 몇 달씩 건너뛰면 첫 정식 점검 때 보안·호환성 수정에서 뒤처질 수 있습니다.

늘 뒤에서 슬며시 다가오는 잡무들: TLS 인증서 갱신(Let's Encrypt를 쓰는 리버스 프록시를 두고, 갱신을 자동화하고, 실패 시 알림을 걸어두기), 인증 메일과 비밀번호 재설정 메일을 위한 발신 메일러 설정(SES, SendGrid, Postmark 중 하나를 골라 SPF/DKIM/DMARC를 제대로 설정하지 않으면 재설정 메일이 스팸함으로 떨어집니다), 엔지니어가 퇴사할 때 OAuth 클라이언트 자격 증명 교체, 그리고 크리덴셜 스터핑 공격이 CPU를 붙잡아두지 않도록 로그인 엔드포인트에 속도 제한을 거는 일.

팁: 매니지드 Postgres를 쓴다면 런타임 데이터베이스 사용자가 스키마까지 만들 수 있다고 가정하지 마세요. 데이터베이스와 사용자를 미리 만들고, 필요한 소유권 또는 설치 권한을 부여한 다음, 각 도구가 기대하는 자격 증명으로 최초 셋업을 실행하세요. 그러지 않으면 첫 실행이 모호한 데이터베이스 권한 오류로 실패하고, 엉뚱한 원인을 쫓느라 한 시간을 태우게 됩니다.

셀프 호스팅이 돈으로 아껴주는 만큼, 소유의 부담으로 되받아 갑니다. 구축이 끝나면 아이덴티티 계층을 건강하게 유지하는 데 매달 몇 시간의 엔지니어링 공수를 잡아두세요. 시간을 전혀 배정하지 않는 팀은 대개 나중에 그 비용을 발견합니다. 장애 한가운데서, 이상한 SAML 엣지 케이스에서, 또는 첫 보안 점검 자리에서요.

어디에 배포할 것인가

Docker Compose를 돌리는 Linux VPS는 평가 용도와 크지 않은 워크로드에는 합리적인 출발점이 될 수 있습니다. 다만 운영 환경의 사이징과 고가용성은 트래픽, 보안 요구사항, 그리고 다운타임을 어디까지 감내할 수 있는지에 달려 있습니다. 흔한 배포 선택지들의 위치는 다음과 같습니다:

• 공유 호스팅 는 어느 것도 돌릴 수 없습니다. 영구 저장소, 임의 포트, 컨테이너 런타임을 위한 root 권한, 그리고 진짜 데이터베이스 백엔드가 필요하기 때문입니다. 이 목록의 대부분에서 PostgreSQL이 기본 경로이지만, 모든 도구에서 지원되는 유일한 데이터베이스는 문자 그대로 아닙니다.
• Kubernetes 는 넷 다 돌릴 수 있지만, 공식 지원 경로는 고르지 않습니다. ZITADEL, FusionAuth, 그리고 Ory 는 자체 Helm 차트를 공개하지만, Logto의 셀프 호스팅 문서 는 Docker와 가상 머신 배포에 초점을 둡니다. Kubernetes가 다른 곳에서 이미 값을 하는 단계에 이르지 못한 소규모 B2B SaaS라면 대개 과잉 설계입니다. 나머지 인프라가 이미 거기에 있을 때 꺼내 드세요.
• 베어메탈 는 이미 베어메탈 위에 있다면 괜찮습니다. 대부분의 B2B SaaS 팀은 그렇지 않습니다.

소규모 단일 노드 파일럿이라면 저는 4 GB RAM, 2 vCPU, 60 GB NVMe 스토리지에서 시작한 뒤 실제 로그인 플로에 부하 테스트를 걸겠습니다. 이건 계획의 기준선이지 보편적인 운영 최소 사양이 아닙니다. 애플리케이션 자체는 비교적 가볍지만, PostgreSQL은 메모리를, 비밀번호 해싱은 CPU 여유를 필요로 합니다. ZITADEL의 운영 환경 가이드 는 비밀번호 해싱 급증에 대비해 CPU 코어 네 개를 확보해두라고 권합니다.

제품이 실체를 갖추고 트래픽이 지속되면 실측을 근거로 사이즈를 다시 잡으세요. 빠른 스토리지는 PostgreSQL 지연에 도움이 되고, CPU 여유는 동시 비밀번호 해싱 구간에서 중요해집니다. 어느 한 자원이 가장 중요하다고 단정하지 말고 메모리, 데이터베이스 I/O, 로그인 지연, CPU 포화도를 함께 지켜보세요.

CIAM을 운영 환경에서 돌린다는 것은 그 가동률이 이제 당신의 문제가 된다는 뜻입니다. 저희는 이런 워크로드에 Cloudzy Linux VPS 인스턴스를 사용하며, NVMe 스토리지와 기반 플랫폼의 99.95% 가동률 SLA를 제공합니다. Cloudzy는 또한 원클릭 ZITADEL VPS 초기 프로비저닝 스크립트를 건너뛰고 싶다면 유용합니다. 나머지 셋은 Docker 기반 설치를 위한 공식 컨테이너 이미지를 제공합니다. 접근 제어가 전체 보안 태세에서 어디에 놓이는지 관리자 관점으로 보고 싶다면, IAM 모범 사례 가이드 정책 관점에서 이를 다룹니다.

자주 묻는 질문

ZITADEL의 AGPL 라이선스가 내 SaaS에 영향을 주나요?

수정하지 않고 별도로 통합한 배포라면 대개 아니지만, 이는 법률 자문이 아닙니다. ZITADEL의 AGPL 의무는 ZITADEL 자체에 적용됩니다. ZITADEL을 수정해 그 수정본을 네트워크 서비스로 운영한다면, 라이선스가 해당 소스 코드를 AGPL로 제공하도록 요구할 수 있습니다. ZITADEL이 공표한 입장은, 수정하지 않은 인스턴스를 SaaS의 아이덴티티 서비스로 사용하는 것만으로는 별도의 애플리케이션을 AGPL로 배포할 의무가 생기지 않는다는 것입니다. ZITADEL의 라이선스 공지 를 읽고, 소프트웨어를 수정·재배포·임베드하거나 제3자에게 제공한다면 법률 자문을 받으세요. 상용 라이선스도 제공됩니다.

왜 Keycloak이나 Authentik은 이 목록에 없나요?

Keycloak과 Authentik은 훌륭한 셀프 호스팅 아이덴티티 도구이고 저도 씁니다. 다만 B2B 조직 기능이 없다는 이유로 Keycloak을 제외하는 것은 이제 틀린 얘기입니다. 현행 Keycloak 릴리스에는 Organizations, 조직 그룹, 위임 관리 기능이 들어 있습니다. 이번에 뺀 이유는 이 비교가 소규모 팀의 B2B SaaS에 더 직선적인 경로를 주는 네 가지에 초점을 맞췄기 때문입니다. JVM 운영, 생태계의 깊이, realm 수준의 유연성이 중요하다면 Keycloak은 별도의 평가를 받을 자격이 있습니다. Authentik은 여전히 제품에 내장된 테넌트 모델링보다 사내 및 내부 앱 SSO에 더 잘 맞습니다.

셀프 호스팅이 Auth0보다 저렴한가요?

MAU가 적을 때는 대개 아닙니다. 초기 스타트업 구간에서는 엔지니어 시간이 Auth0 청구서보다 비쌉니다. 셀프 호스팅이 경제적으로 이기는 지점은, 매니지드 CIAM의 MAU 단가가 작은 VPS 비용에 매달 들어가는 몇 시간의 엔지니어링 공수를 더한 값을 넘어서는 규모입니다. 정확한 손익분기점은 팀의 시간당 비용, MAU 성장 곡선, 그리고 제품이 Auth0의 상위 요금제로 밀어 올리는 엔터프라이즈 기능을 필요로 하는지에 달려 있습니다. 절감액은 실재하지만 즉시 오는 것은 아니라고 보세요.

운영 환경 CIAM의 최소 VPS 사양은?

소규모 단일 노드 파일럿이라면 4 GB RAM, 2 vCPU, NVMe 스토리지가 합리적인 출발점이지 운영 환경의 보증은 아닙니다. 데이터베이스 크기, 동시 로그인 부하, 비밀번호 해싱 비용, 가동률 목표를 기준으로 사이즈를 잡으세요. ZITADEL 자체의 운영 가이드는 해싱 급증에 대비해 CPU 코어 네 개를 확보하라고 권합니다. 다른 도구와 다른 트래픽 패턴에는 각자의 부하 테스트가 필요합니다.

나중에 매니지드 CIAM에서 셀프 호스팅으로 옮길 수 있나요?

가능합니다. 다만 제대로 된 프로젝트로 계획하세요. 비밀번호 재설정이 필연은 아닙니다. 내보내기 가능 여부와 지원되는 해시 형식은 제각각이며, 일부 대상은 일괄 또는 저스트 인 타임 사용자 마이그레이션 을 지원하지만, 어떤 곳은 재설정을 강제합니다. MFA 요소, OAuth 클라이언트, 활성 세션, 이메일 인증 상태, 테넌트나 역할 매핑은 각각 따로 다뤄야 합니다. 나중에 셀프 호스팅으로 갈 것 같다는 예감이 이미 있다면, 매니지드 제공자를 고르기 전에 그 내보내기와 마이그레이션 제약을 기록해두세요.