세션 유지시간과 인증 토큰 유지시간이 분리된 구조에 대한 운영자 UX 혼선

G7 최근 이슈 #44를 보면서 기존 CMS 운영 경험과 G7 인증 구조 사이에 체감 차이가 꽤 클 수 있겠다는 생각이 들었습니다. 기존 CMS 계열에서는 보통: * 세션 유지시간 = 로그인 유지시간 으로 인식되는 경우가 많습니다. 즉 PHP session.gc_maxlifetime이나 Redis session TTL 값을 늘리면 자연스럽게 "로그인도 오래 유지된다"고 받아들이는 경우가 많습니다. 반면 현재 G7 구조는 문서를 보면 다음 개념들이 비교적 분리되어 있습니다. * PHP/Redis 세션 유지시간 * Sanctum 인증 토큰 유지시간 * 실제 로그인 유지 흐름 * 토큰 슬라이딩 갱신 조건 특히 현재 인증 흐름은 Sanctum Bearer Token 중심 구조에 가깝고, 세션은 일부 web guard 흐름이나 `/dev` 계열 개발 대시보드 등에서 보조적으로 사용되는 형태로 보입니다. 관련 문서: * docs/backend/authentication.md * docs/backend/middleware.md * docs/frontend/auth-system.md 문서를 기준으로 보면 현재 토큰은 기본적으로: * 기본 30분 * 남은 시간이 전체 시간의 50% 미만일 때 refresh 대상 진입 구조로 동작합니다. 다만 여기서 중요한 부분은 refresh가 시간 기반 자동 작업이 아니라, API 요청 발생 시점에 검사된다는 점입니다. 즉 사용자가 실제로 API 요청을 발생시키는 상태라면 토큰이 계속 연장될 수 있지만, 브라우저를 그냥 띄워둔 상태처럼 요청이나 ping 등이 전혀 없으면 refresh 흐름 자체가 실행되지 않아 토큰이 그대로 만료될 수 있습니다. 그래서 운영자가: * 세션 유효시간 360분 으로 설정했더라도, 인증 토큰 유지시간이 기본 30분 상태라면 실제 체감은: * 일정 시간 이후 로그인 만료 흐름 진입 처럼 느껴질 가능성이 있습니다. 특히 기존 CMS 운영 경험 기준에서는: * Redis 세션 TTL 증가 = 로그인 유지 증가 로 받아들이는 경우가 많기 때문에, 현재 구조와 운영자 인식 사이에 차이가 생기기 쉬워 보입니다. 개인적으로는 현재 구조 자체는 상당히 현대적인 방향이라고 느껴졌습니다. SPA/API 구조와 인증 흐름을 분리하기 쉽고, 모바일/웹 클라이언트 간 인증 모델을 일관되게 가져가기 좋으며, Authorization 헤더 기반 인증 흐름도 자연스럽게 유지할 수 있습니다. 또한 토큰 단위로 만료, 회수, refresh 정책을 제어할 수 있다는 점도 기존 세션 중심 구조와는 다른 장점으로 보입니다. OptionalSanctumMiddleware, token sliding expiration, 401 응답 시 cookie cleanup, StartApiSession 분리 등의 흐름 역시 전통적인 PHP 세션 기반 CMS보다는 현대적인 API 서버 구조에 가까운 인상을 받았습니다. 다만 운영자 UX 측면에서는 혼선이 생기기 쉬운 부분도 분명 존재하는 것 같습니다. 예를 들면: * 세션 유지시간 * 인증 토큰 유지시간 * 실제 로그인 유지시간 * 슬라이딩 갱신 정책 등이 UI나 설정명, 도움말에서 충분히 분리되어 설명되지 않으면 운영자 입장에서는 자연스럽게: "세션을 늘렸는데 왜 로그인이 빨리 풀리지?" 로 받아들이기 쉬운 구조처럼 느껴집니다. 아마 장기적으로는: * 설정명 분리 * 도움말 강화 * 실제 로그인 유지 흐름 시각화 * 토큰 만료/refresh 정책 설명 보강 같은 UX 보완이 들어가면 운영자 혼선이 많이 줄어들 수 있을 것 같습니다.