솔직히 말하면, SSO라는 단어는 꽤 매력적입니다.

서비스가 여러 개로 나뉘기 시작하면 이런 생각이 바로 듭니다.

“로그인을 하나로 묶어야 하지 않을까?”

현재 goodtek이 가려는 구조를 보면 더 그렇습니다.

• goodtek.xyz — 메인 웹사이트
• blog.goodtek.xyz — Ghost 블로그
• community.goodtek.xyz — NodeBB 커뮤니티
• notes.goodtek.xyz — 공개 노트 / 개발 로그
• app.goodtek.xyz — 나중에 SaaS 앱들

이렇게 보면 SSO 방향 자체는 맞아 보입니다.

웹사이트, 블로그, 커뮤니티, 노트, SaaS 앱이 하나의 생태계로 묶이는 그림이니까요.
사용자 입장에서도 한 번 로그인해서 여러 서비스를 오가는 경험은 분명 좋습니다.

그런데 여기서 질문이 하나 생깁니다.

지금 goodtek이 해결해야 할 가장 중요한 문제가 정말 “통합 로그인”일까요?

저는 이 지점에서 조금 멈췄습니다.

SSO가 필요한가보다 중요한 질문

SSO가 필요한지 아닌지만 보면 답은 쉽습니다.

언젠가는 필요할 수 있습니다.

문제는 “언젠가”가 아니라 지금입니다.

지금 Keycloak 같은 중앙 인증 서버를 직접 붙이면, 인증은 단순 기능이 아니라 하나의 운영 대상이 됩니다.

로그인만 되는 게 아닙니다.

• 세션 관리
• 리프레시 토큰
• 이메일 인증
• 비밀번호 초기화
• OAuth 설정
• 백업
• 업그레이드
• 장애 대응
• 보안 패치
• 운영 모니터링

이 모든 게 따라옵니다.

처음에는 “로그인 통합하면 깔끔하겠다”로 시작했는데, 어느 순간 인증 서버 자체가 또 하나의 제품이 될 수 있습니다.

문제는 SSO가 좋은 기술이냐가 아니라, 지금 인증이 goodtek의 핵심 병목이냐입니다.

지금 goodtek에 더 급한 것들

goodtek 입장에서는 이미 해야 할 일이 많습니다.

웹사이트를 만들고, 블로그를 운영하고, 커뮤니티를 키우고, 공개 노트를 정리하고, SaaS 앱을 만들고, CI/CD와 운영 자동화도 다듬어야 합니다.

이 상황에서 Keycloak까지 직접 운영하기 시작하면, 제품보다 인프라가 더 무거워질 수 있습니다.

제 기준으로 보면 지금은 이렇게 나누는 게 더 현실적입니다.

영역 지금 선택 이유
웹사이트 로그인 없음 랜딩, SEO, AdSense, 연결 구조가 먼저
Ghost 블로그 Ghost 기본 멤버 뉴스레터와 구독 기능이 이미 있음
NodeBB 커뮤니티 자체 로그인 + 소셜 로그인 초기 커뮤니티에는 충분함
Notes 공개 문서 신뢰 자산과 개발 로그 역할
SaaS 앱 앱 자체 인증 또는 SaaS형 인증 실제 인증이 필요한 핵심 영역

즉, 모든 곳에 중앙 인증을 먼저 깔기보다 로그인이 진짜 필요한 곳부터 가볍게 시작하는 방식입니다.

Keycloak이 틀렸다는 말은 아닙니다

여기서 오해하면 안 되는 게 있습니다.

저는 Keycloak이 나쁘다고 생각하지 않습니다.

오히려 특정 시점이 오면 굉장히 좋은 선택이 될 수 있습니다.

예를 들면 이런 상황입니다.

• SaaS 앱이 여러 개 생긴다
• 커뮤니티 계정과 SaaS 계정을 반드시 하나로 묶어야 한다
• 조직/팀 단위 계정이 필요하다
• RBAC, 그룹, 역할 관리가 복잡해진다
• 고객사별 SSO 요청이 들어온다
• SAML, OIDC 같은 B2B 요구사항이 생긴다
• 자체 호스팅을 유지해야 하는 명확한 이유가 있다

이 정도까지 가면 이야기가 달라집니다.

그때는 Keycloak이 단순한 오버엔지니어링이 아니라 필요한 기반 인프라가 될 수 있습니다.

하지만 지금이 “나중에 필요할 것 같으니 미리 붙이자”에 가깝다면, 저는 조금 빠르다고 봅니다.

지금은 설계상 여지만 남기기

제가 생각하는 현실적인 선택은 이겁니다.

SSO를 완전히 무시하지는 않되, 지금 당장 운영하지는 않는다.

예를 들어 SaaS 앱의 DB 설계에서 나중에 외부 IdP로 옮길 수 있는 여지만 남깁니다.

users
id
email
name
avatar_url
provider
provider_account_id
created_at
accounts
user_id
provider
provider_account_id
access_token
refresh_token
memberships
user_id
product
role
status

이 정도만 해두면 나중에 Keycloak, Authentik, Zitadel, Auth0, Clerk 같은 선택지로 갈 때 완전히 막히지는 않습니다.

처음부터 중앙 인증 서버를 운영하는 것과, 나중에 옮길 수 있게 데이터 구조를 열어두는 것은 다릅니다.

저는 후자가 지금 goodtek에 더 맞다고 봅니다.

지금 필요한 건 완성된 통합 인증 시스템이 아니라, 나중에 통합할 수 있는 느슨한 구조입니다.

제 결론

제 결론은 이렇습니다.

지금 goodtek은 SSO를 도입하지 않는 쪽이 맞다.

조금 더 정확히 말하면,

SSO 방향은 고려하되, Keycloak 같은 중앙 인증 서버를 지금 직접 운영하지는 않는다.

현재 단계에서는 이렇게 가는 게 가장 현실적이라고 봅니다.

• 웹사이트: 로그인 없음
• 블로그: Ghost 기본 멤버 기능
• 커뮤니티: NodeBB 기본 로그인 + Google/GitHub 로그인
• Notes: 공개 운영
• SaaS 앱: 앱 자체 인증 또는 Better Auth / Auth.js / Supabase Auth / Clerk 같은 가벼운 인증

그리고 실제로 커뮤니티와 SaaS가 연결되고, 결제/권한/등급/조직 계정이 얽히기 시작하면 그때 SSO를 진지하게 검토합니다.

그때 Keycloak을 붙여도 늦지 않다고 생각합니다.

오히려 지금은 콘텐츠, 커뮤니티, 제품이 먼저입니다.

인증 시스템이 아무리 잘 되어 있어도 들어올 사용자가 없으면 운영할 것도 없습니다.
반대로 사용자가 생기고 서비스 간 연결이 진짜 필요해지면, 그때의 SSO는 훨씬 명확한 이유를 갖게 됩니다.

여러분은 어떻게 생각하시나요?

여러분이라면 goodtek 같은 구조에서 SSO를 지금 도입하시겠습니까?

아니면 일단 각 서비스를 독립적으로 운영하고, SaaS 앱에만 가벼운 인증을 붙인 뒤 나중에 통합하시겠습니까?

특히 궁금한 건 이 부분입니다.

초기부터 SSO를 깔아두는 게 장기적으로 이득일까요, 아니면 지금은 오히려 제품보다 인프라를 키우는 선택일까요?

저는 지금 단계에서는 후자에 가깝다고 봅니다.
하지만 SSO를 초기에 깔아두고 나중에 덕을 본 경험이 있다면, 그 이야기도 들어보고 싶습니다.