한국어

게스트 모드
익명 사용자
사용자 전환

게스트 모드(익명 사용자) 구현 및 로그토 사용자의 전환 방법

게스트 세션 관리, OIDC 를 통한 인증, 그리고 게스트 데이터를 사용자 계정에 안전하게 병합하는 3단계 패턴을 사용하여 게스트 모드를 구현하고 로그토 사용자로 전환하는 방법을 알아봅니다.

Yijun

Developer

1/9/2026

사용자 인증에 몇 주를 낭비하지 마세요

Logto로 더 빠르게 안전한 앱을 출시하세요. 몇 분 만에 사용자 인증을 통합하고 핵심 제품에 집중하세요.

시작하기

많은 앱에서 사용자는 회원가입 없이 기능을 먼저 체험할 수 있습니다. 예를 들면 장바구니, 문서 초안, 저장된 환경설정 등이 있습니다. 사용자는 이런 "게스트 모드"가 기본적으로 잘 동작하기를 기대합니다.

하지만 로그토(또는 기타 OIDC 제공자)를 인증에 사용할 때 익명 사용자를 어떻게 처리해야 할지 고민할 수 있습니다.

간단히 말해: 로그토는 인증을, 여러분의 앱은 게스트 세션을 처리합니다. 각각의 관심사가 분리되어 있습니다.

이 글에서는 로그토로 게스트 모드를 구현하는 간단한 세 단계 패턴을 소개합니다. 여기서 배우게 될 내용은 다음과 같습니다:

백엔드에서 게스트 세션 관리하기
게스트가 로그토를 통해 가입할 수 있도록 하기
게스트 데이터를 실제 사용자 계정으로 병합하기

로그토에 "익명 로그인"이 없는 이유

로그토에 "익명 로그인" 기능이 있을 거라고 기대할 수 있습니다. 즉, API 호출만으로 토큰을 받고 사용자의 상호작용 없이 쓸 수 있는 기능이죠.

하지만 OIDC 의 동작 방식은 그렇지 않습니다. 그 이유는 다음과 같습니다:

OIDC 는 사용자 동의를 중심으로 만들어졌습니다. 즉, "이 사람이 누구인지"를 확인하는 것이 목적입니다. 익명 토큰은 "누군가이긴 한데, 누구인지는 모른다"는 말이 되어 의미가 사라집니다.

다시 정리하면:

인증(Authentication) = 신원 증명("너는 누구니?")
세션 추적(Session tracking) = 행동 기록("무엇을 했니?")

게스트 모드는 인증이 아닌 세션 추적의 영역입니다. 즉, 인증 시스템과는 별개입니다.

오히려 이게 좋은 소식입니다. 역할이 명확히 구분됩니다:

로그토: 신원(가입, 로그인, 토큰) 관리
여러분의 앱: 신원 생성 전 게스트 세션 관리

각 시스템이 설계된 역할에만 집중하면 됩니다.

세 단계 솔루션

패턴은 이렇습니다: 게스트 → 인증 → 병합

1단계: 인증 없는 게스트 세션 처리

여러분의 백엔드가 게스트 세션을 생성/관리합니다. 로그토는 아직 관여하지 않습니다.

사용자가 의미 있는 행동(예: 장바구니 담기)을 하면 백엔드는

guest ID(예: UUID)를 생성
쿠키나 JWT 로 반환
게스트 ID 별로 사용자 행동을 저장

정말 간단하게, guest_sessions 테이블에 guest_id, data, created_at 정도만 있으면 충분합니다.

2단계: 사용자가 로그토로 로그인하도록 유도

사용자가 "회원가입" 또는 "로그인"을 누르면, 표준 로그토 OIDC 플로우를 실행합니다.

이때 게스트 ID 는 쿠키/스토리지에 그대로 남아 있습니다. 인증이 끝난 후 프론트엔드에는

로그토 access token (사용자 신원)
이전의 게스트 ID (게스트 데이터)가 동시에 존재합니다.

3단계: 게스트 데이터를 인증된 사용자에게 안전하게 병합하기

이제 둘을 연결합니다. 백엔드 API 에 둘 다 전달하세요:

백엔드는 병합 전에 두 토큰 모두 검증해야 합니다:

access token 검증 → 사용자 ID 추출. 액세스 토큰 검증 방법은 여기를 참고하세요.
guest ID 검증 → 실존하는 게스트 세션(백엔드가 발급한 것)인지 확인. 아주 중요 — 클라이언트가 넘긴 guest ID 를 절대 곧바로 신뢰하지 마세요.

이 두 검증이 모두 통과하면:

게스트 데이터를 사용자 계정으로 병합
게스트 세션 폐기/무효화

병합 로직은 서비스마다 다릅니다. 장바구니면 아이템을 합치고, 문서 초안이면 소유권을 넘기면 됩니다. 직접 설계하세요.

토큰 검증으로 merge 엔드포인트를 안전하게 보호하기

merge 엔드포인트는 민감한 기능입니다. 체크리스트는 다음과 같습니다:

항상 access token 검증. 요청 body 에서 user ID 를 그대로 읽지 마세요. JWT 를 디코드/검증하세요. Logto 에서 하는 법
항상 guest ID 도 검증. DB 에 존재하는지, 만료되진 않았는지 확인하세요. 만약 JWT 로 발급했다면 서명도 검증하세요.
인증 필수로. 유효한 access token 이 없으면 merge 엔드포인트는 요청을 거부해야 합니다.
게스트 세션에 TTL 부여. 30일(또는 앱에 맞는 기간) 지난 세션은 정리하세요.

결론

Logto 와 함께하는 게스트 모드는 아래와 같이 단순한 패턴입니다:

게스트(앱) → 회원가입 전 세션 직접 관리
인증(로그토) → 가입/로그인 처리
병합(앱) → 게스트 데이터와 실제 사용자를 연결

이 패턴은 Logto 뿐만 아니라 어떠한 OIDC 제공자에도 적용됩니다. 핵심은: 인증과 세션 관리는 분리된 관심사라는 점. 각 시스템이 본연의 역할에 집중하도록 하세요.

로그토에 "익명 로그인"이 없는 이유#

세 단계 솔루션#

1단계: 인증 없는 게스트 세션 처리#

2단계: 사용자가 로그토로 로그인하도록 유도#

3단계: 게스트 데이터를 인증된 사용자에게 안전하게 병합하기#

토큰 검증으로 merge 엔드포인트를 안전하게 보호하기#

결론#

로그토에 "익명 로그인"이 없는 이유#

세 단계 솔루션#

1단계: 인증 없는 게스트 세션 처리#

2단계: 사용자가 로그토로 로그인하도록 유도#

3단계: 게스트 데이터를 인증된 사용자에게 안전하게 병합하기#

토큰 검증으로 merge 엔드포인트를 안전하게 보호하기#

결론#

로그토에 "익명 로그인"이 없는 이유

세 단계 솔루션

1단계: 인증 없는 게스트 세션 처리

2단계: 사용자가 로그토로 로그인하도록 유도

3단계: 게스트 데이터를 인증된 사용자에게 안전하게 병합하기

토큰 검증으로 merge 엔드포인트를 안전하게 보호하기

결론

로그토에 "익명 로그인"이 없는 이유

세 단계 솔루션

1단계: 인증 없는 게스트 세션 처리

2단계: 사용자가 로그토로 로그인하도록 유도

3단계: 게스트 데이터를 인증된 사용자에게 안전하게 병합하기

토큰 검증으로 merge 엔드포인트를 안전하게 보호하기

결론