#032 다중 SaaS를 하나로 묶는 통합 계정(SSO)과 크로스 인증 에코시스템 구축

두 번째 서비스(OptionMaker)를 배포(#031)하고 나면 유저 경험에서 치명적인 마찰(Friction)이 발생한다. ReviewZip을 쓰던 유저가 OptionMaker를 쓰기 위해 또다시 회원가입을 하고, 신용카드 정보를 중복 입력해야 한다면 이탈률이 급증한다.

여러 개의 마이크로 SaaS를 개별 서비스가 아닌 하나의 ‘통합 B2B 스위트(Suite)’ 브랜드로 인식시키려면, 단 한 번의 로그인(SSO)과 결제로 모든 자매 서비스를 넘나들 수 있는 통합 인증 에코시스템이 필수적이다. 오늘은 Supabase 단일 DB와 쿠키 공유를 활용해 1인 개발자도 반나절 만에 구현하는 통합 계정 아키텍처를 정리했다.

🌐 루트 도메인 기반 쿠키 공유와 통합 인증 메커니즘

각 서비스를 개별 도메인으로 분리하지 않고, 동일한 루트 도메인의 서브도메인 체계로 묶으면 브라우저 쿠키를 100% 공유할 수 있다.

Plaintext

[통합 도메인 및 인증 구조]
- 허브 메인: auth.mysaas.io (통합 로그인/회원가입 센터)
- 서비스 1: review.mysaas.io (ReviewZip 앱)
- 서비스 2: option.mysaas.io (OptionMaker 앱)
1. 유저가 어느 서브도메인에서든 [구글 로그인] 클릭
2. Supabase Auth가 세션 토큰을 발급하며 쿠키 도메인을 '.mysaas.io'로 와일드카드 설정
3. 유저가 review -> option으로 페이지를 이동해도 세션이 그대로 유지되어 자동 로그인 완료

TypeScript

// Supabase 클라이언트 쿠키 도메인 공유 설정 (Next.js 미들웨어)
import { createServerClient } from '@supabase/ssr';
import { NextResponse, type NextRequest } from 'next/server';
export async function updateSession(request: NextRequest) {
  let response = NextResponse.next({ request: { headers: request.headers } });
  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value, options }) => {
            request.cookies.set(name, value);
            response = NextResponse.next({ request: { headers: request.headers } });
            // 핵심: 모든 서브도메인에서 쿠키를 공유하도록 도메인 지정
            response.cookies.set(name, value, {
              ...options,
              domain: process.env.NODE_ENV === 'production' ? '.mysaas.io' : undefined,
              sameSite: 'lax',
              secure: process.env.NODE_ENV === 'production',
            });
          });
        },
      },
    }
  );
  await supabase.auth.getUser();
  return response;
}

💳 단일 결제로 모든 툴을 여는 ‘올인원 패스(All-Access Pass)’ 구독 설계

개별 결제창 대신, 상위 통합 번들 요금제를 배치하여 객단가와 LTV를 폭발적으로 끌어올린다.

Plaintext

[통합 구독 테이블 DB 스키마 설계]
Table: user_subscriptions
- user_id: uuid (users.id 참조)
- has_review_access: boolean (ReviewZip 권한)
- has_option_access: boolean (OptionMaker 권한)
- is_all_access: boolean (통합 번들 권한)
- stripe_customer_id: string
* 단일 툴 구독: 월 19,900원 / 월 14,900원
* 올인원 번들 패스: 월 29,900원 (두 가지 툴 무제한 + 향후 출시될 신규 툴 자동 포함)

• 유저 심리 자극: “월 1만 원만 더 내면 전체 서비스를 다 쓸 수 있다”는 강력한 가격 앵커링이 작동해 신규 가입자의 60% 이상이 올인원 패스를 선택하게 된다.
• 개발 효율성: 향후 세 번째, 네 번째 SaaS를 출시할 때도 has_tool3_access 컬럼만 추가하면 기존 결제 인프라를 그대로 재활용할 수 있다.

🧭 우측 상단 ‘앱 런처(App Launcher)’ UI를 통한 상호 유입

구글의 ‘바둑판 모양 앱 런처(G Suite 메뉴)’처럼, 대시보드 우측 상단에 자매 프로덕트 목록을 보여주는 네비게이션 드롭다운을 기본 장착한다.

• 인터랙션 설계:
  • 현재 사용 중인 서비스는 [사용 중] 배지 표시
  • 아직 구독하지 않은 서비스는 [1클릭 활성화 (번들 할인)] 버튼을 노출하여 자연스러운 교차 사용(Cross-usage) 유도
• 트래픽 공유: 서비스 A로 유입된 신규 트래픽이 자연스럽게 서비스 B로 흘러 들어가며 외부 광고비 지출 없이 전체 생태계의 활성 유저(DAU)가 동반 상승한다.

💡 통합 시스템 구축 시 주의해야 할 점

1. 데이터베이스 완전 분리 vs 단일 DB 스키마 분리:
   • 서비스마다 DB를 따로 파면 유저 동기화 작업이 지옥이 된다. 단일 Supabase 인스턴스 안에서 테이블명 접두사(review_crawls, option_jobs)로 격리하거나 PostgreSQL의 다중 schema 기능을 활용하는 것이 1인 운영에 압도적으로 유리하다.
2. 단일 장애점(SPOF) 방어:
   • 한 서비스의 크롤링 부하로 인해 메인 DB가 느려져 다른 서비스까지 먹통이 되지 않도록, 각 서비스별 쿼리에는 엄격한 타임아웃(Timeout: 3초)과 커넥션 풀링(Supavisor)을 필수 적용한다.

• 인사이트 요약: 단일 마이크로 SaaS는 쉽게 대체될 수 있지만, 여러 도구가 긴밀하게 연결된 통합 소프트웨어 스위트는 유저에게 대체 불가능한 업무 인프라가 된다. 통합 로그인과 번들 결제를 구축함으로써 개별 점포 수준의 서비스를 거대한 ‘디지털 소프트웨어 프랜차이즈’로 확장하는 기틀을 마련했다.
• 차기 분석 테스크: 리스트 033번 “크롬 익스텐션(Chrome Extension)으로 SaaS 기능 확장하기: 웹 브라우저에서 1초 만에 실행되는 사이드 패널 개발법” 정리.

🚀 지금 바로 1인 AI SaaS 창업을 시작하세요!

이 글에서 다룬 모든 아키텍처와 운영 전략이 담긴 마스터북 + 풀스택 보일러플레이트 코드를 지금 확인해보세요.

$0에서 $10k MRR까지의 완벽한 로드맵. 7일 내 환불 보증.

1인 AI SaaS 시리즈 더 보기 (Phase 2: 코어 프로덕트 & 비용 최적화)

• #031 두 번째 SaaS 기획: 검증된 보일러플레이트로 48시간 만에 신규 아이템 런칭하기
• #033 크롬 익스텐션(Chrome Extension)으로 SaaS 기능 확장하기: 브라우저 원클릭 추출과 사이드 패널 개발
• #021 런칭 첫 주에 터진 실전 버그 3가지와 광고비 0원 아웃바운드 영업 실전기