Auth — 통합 인증(SSO)

한 줄 요약

“모든 서비스가 로그인·회원·구독을 각자 만들지 말고, 한 서버가 대신 처리하자.” — 서버를 완성까지 만들었지만, 정작 그 위에 얹을 유료 구독 서비스가 하나도 켜지지 않아 쓸 곳이 없어 폐기했습니다.

🪦 이 프로젝트는 폐기되었습니다(2026-08-14). 아래는 무엇을 하려 했고, 무엇까지 만들었으며, 왜 배포도 안 하고 접었는지에 대한 회고입니다. “필요해지기 전에 만든 인프라는 재고가 된다"를 배운 기록입니다.

무엇을 하려 했나 — 목표

서비스가 늘어날수록 서비스마다 로그인·회원 DB를 따로 만드는 게 낭비라고 봤습니다.

• 구글·카카오·네이버 소셜 로그인을 이 서버 한 곳이 대신 받고, 성공하면 .soongbly.com 도메인 쿠키로 로그인 증표(JWT)를 발급.
• 전 서비스가 그 쿠키를 공유 → 한 번 로그인하면 옥션렌즈·성장렌즈·비즈렌즈 어디서든 로그인 상태(Single Sign-On).
• 회원·구독·결제이력 원장(SQLite)을 여기서 통합 관리하고, 각 서비스는 sso_client로 “이 사람 로그인했나 / 이 서비스 구독 중인가"만 물어보게.

무엇을 만들었나 — 실제로 구현 완료까지

설계로 끝내지 않고 동작하는 서버까지 만들었습니다.

1. OAuth 3사 로그인·콜백 — 구글/카카오/네이버 로그인 → 콜백 처리 → JWT 쿠키 발급/검증, /me(현재 사용자+구독) 엔드포인트.
2. 회원·구독·결제 원장 — users / subscriptions / payments 테이블, 내부 API(구독 부여·결제 이력)는 X-Internal-Key 헤더로 게이트.
3. 보안 골격 — 오픈 리다이렉트 차단(safe_next 화이트리스트), CSRF state, 키가 없으면 起動 자체를 거부하도록 설계.

FastAPI 서버(:5180)로 코드는 완성됐고, 남은 건 출생신고(services.json 등록)·터널 연결·3사 콘솔 콜백 등록뿐이었습니다.

왜 폐기까지 갔나 — 얹을 것이 없었다

SSO는 “여러 유료 서비스"가 있어야 값어치가 생기는 인프라입니다. 그런데 팩토리 전체가 통신판매업 신고 전까지 결제·구독을 전면 보류하는 원칙이라, 정작 SSO가 관리할 “구독"이라는 게 어느 서비스에도 켜져 있지 않았습니다.

• 수요가 없다 — 구독·결제 원장을 통합할 대상이 0개. 유료화 게이트가 무기한 보류인 이상, 구독 서버는 계속 재고로 남는다.
• 지금은 과잉이다 — 서비스별 방문자가 사실상 지인·테스트 수준. 각 서비스의 간단 로그인만으로 충분하고, 도메인 쿠키 SSO는 몇 년 뒤에나 필요한 규모의 문제.
• 유지 부담만 남는다 — 회원·결제 원장을 담은 서버를 상시 띄우는 것은 그 자체로 관리·보안 책임. 쓰지도 않는데 지고 갈 이유가 없다.

포트폴리오 수익화 진단(2026-07-31)의 결론 — “만들기 90% : 팔기 0%, 유료화가 전부 게이트에 걸려 있다” — 이 그대로 적용되는 사례였습니다. 결제를 켜는 날, 그때 다시 꺼내면 되는 부품이라 판단해, 코드는 보존하되 실험실에서는 폐기로 내렸습니다.

남긴 것

• 소셜 로그인 3사 연동·JWT 쿠키·오픈 리다이렉트 방어 코드는 레포에 보존 — 향후 유료화가 열리면 재활용.
• 교훈: 인프라는 그 위에 얹을 실물이 생긴 뒤에 만든다. 선(先)인프라는 좋아 보이지만, 수요 없는 인프라는 재고와 유지비로만 남는다.