왜 G7은 세션과 인증 토큰을 분리했을까

최근 "세션 유지시간을 늘렸는데 왜 로그인은 빨리 풀리는 것처럼 느껴질까?"라는 이슈를 보면서, G7 인증 구조는 기존 CMS 계열과 방향 자체가 꽤 다르다는 생각이 들었습니다. 기존 PHP CMS 환경에서는 보통 PHP Session, 로그인 상태, 서버 인증 상태가 거의 같은 의미로 취급됩니다. 즉 session.gc_maxlifetime이나 Redis session TTL 같은 값을 늘리면 자연스럽게 "로그인도 오래 유지된다"고 받아들이게 됩니다. 반면 G7 문서를 보면 현재 구조는 세션과 인증 토큰의 역할을 비교적 분리해서 가져가는 형태에 가깝습니다. 실제 인증은 Sanctum 기반 Bearer Token 중심으로 동작하고, 세션은 일부 web guard 흐름이나 개발 대시보드 등 제한적인 영역에서 사용되는 구조로 보입니다. 또한 sliding expiration 기반의 토큰 갱신 흐름도 존재합니다. 특히 문서를 보면 토큰은 API 호출 시마다 유효시간을 검사하고, 남은 시간이 전체 시간의 절반 이하이면 만료시간을 다시 최대값으로 연장하는 구조입니다. 즉 사용 중(active)인 상태에서는 토큰이 계속 연장될 수 있지만, 브라우저를 그냥 띄워둔 상태처럼 요청이나 ping 등이 전혀 없으면 refresh 흐름 자체가 실행되지 않아 토큰이 그대로 만료될 수 있습니다. 이 부분이 기존 CMS 감각과 가장 크게 다른 지점처럼 느껴졌습니다. 기존 CMS에서는 사실상 "Session = Login State"에 가까웠다면, G7은 "Session과 Auth Token의 역할을 분리"하는 방향에 더 가까워 보입니다. 왜 이렇게 설계했을까 생각해보면 얻는 장점도 꽤 분명합니다. SPA 프론트와 API를 더 명확하게 분리할 수 있고, 모바일과 웹에서 인증 구조를 일관되게 가져갈 수 있습니다. 또한 Authorization 헤더 중심 인증 흐름을 유지할 수 있고, 멀티 서버나 로드밸런서 환경에서도 세션 의존도를 줄이기 쉽습니다. 토큰 단위로 만료, 회수, refresh 정책을 제어할 수 있다는 점도 기존 세션 중심 구조와는 다른 특징으로 보입니다. OptionalSanctumMiddleware, token sliding expiration, 401 응답 시 cookie cleanup, StartApiSession 분리 등의 흐름도 기존 PHP 세션 기반 CMS보다는 현대적인 API 서버 구조에 더 가까운 인상을 받았습니다. 다만 운영자 UX 측면에서 혼선이 생기기 쉬운 부분도 있는 것 같습니다. 운영자는 보통 Redis session TTL이나 "세션 유지시간"을 늘리면 로그인 유지시간도 함께 늘어난다고 기대하는 경우가 많습니다. 하지만 현재 구조에서는 실제 로그인 유지가 auth token lifetime, refresh 조건, 요청 발생 여부 등에 더 큰 영향을 받습니다. 그래서 기존 CMS 운영 경험 기준에서는 "세션을 늘렸는데 왜 로그인이 빨리 풀리지?"로 느끼기 쉬운 구조 같습니다. 개인적으로는 현재 구조 자체는 꽤 현대적이고 방향성도 명확하다고 느껴졌습니다. 다만 세션 유지시간, 인증 토큰 유지시간, 실제 로그인 유지시간, refresh 조건이 서로 어떤 관계인지 설정 UI나 도움말에서 조금 더 명확히 드러나면 운영자 입장에서 혼선이 훨씬 줄어들 수 있을 것 같습니다. G7 관련 문서: docs/backend/authentication.md docs/backend/middleware.md docs/frontend/auth-system.md