세션과 세션 관리

세션은 웹사이트가 당신을 기억하는 방법입니다. HTTP의 근본적인 기억상실과 현대 웹 애플리케이션에서 우리가 기대하는 지속적이고 개인화된 경험 사이의 간극을 메워줍니다.

기억상실 문제

HTTP는 기억이 없습니다. 모든 요청은 낯선 사람처럼 도착하며, 이전 요청과 어떠한 연결도 없습니다. 방금 당신의 비밀번호를 확인한 서버는 당신을 만난 적이 있다는 사실을 즉시 잊어버립니다.

세션이 없다면, 모든 클릭마다 아이디와 비밀번호를 전송해야 할 것입니다. 모든 페이지 로드, 모든 버튼 클릭, 모든 폼 제출마다 자격 증명이 필요하게 됩니다. 이것은 매우 불편할 뿐만 아니라 위험하기까지 합니다.

세션은 브라우저와 서버 사이에 임시적인 관계를 만들어 이 문제를 해결합니다. 로그인에 성공하면 서버는 세션을 생성합니다. 세션은 고유한 식별자에 연결된 데이터 저장소입니다. 이 식별자는 브라우저로 전달되며 (일반적으로 쿠키를 통해), 브라우저는 이후의 모든 요청에 이를 포함시킵니다. 서버는 식별자를 확인하고 세션 데이터를 가져와 당신이 누구인지 기억합니다.

세션 식별자

세션 식별자는 모든 것의 열쇠입니다. 일반적으로 3f7b2a8c9d1e4f6a8b0c2d4e6f8a0b2c와 같은 긴 무작위 문자열입니다. 그 자체로는 아무 의미가 없지만, 서버의 세션 데이터와 유일하게 연결되어 있습니다.

브라우저는 이 식별자를 저장하고 해당 도메인에 대한 모든 요청과 함께 자동으로 전송합니다. 서버는 이를 받아 연결된 데이터를 조회하고 당신의 신원을 확인합니다. 로그인 여부, 장바구니 내용, 설정, 권한 등이 여기에 포함됩니다.

이것이 핵심입니다: 서버 입장에서 세션 식별자 자체가 곧 당신의 신원입니다. 이를 훔치면 당신이 됩니다. 비밀번호가 필요 없습니다.

세션 저장 위치

세션 데이터는 서버 어딘가에 저장되어야 합니다. 어디에 저장하느냐에 따라 애플리케이션의 성능과 확장성이 결정됩니다.

메모리: 가장 빠른 접근 방법입니다. 세션 데이터가 서버의 RAM에 저장됩니다. 하지만 서버가 재시작되면 모든 세션이 사라집니다. 로드 밸런서 뒤에 여러 서버가 있는 경우, 세션은 그 중 한 서버에만 존재합니다. 개발 환경에는 적합하지만 운영 환경에서는 문제가 됩니다.

데이터베이스: 세션이 재시작 후에도 유지되며 여러 서버에서 작동합니다. 어느 서버든 세션을 가져올 수 있습니다. 단점은 속도입니다. 데이터베이스 조회는 메모리 접근보다 느립니다.

캐시 시스템 (Redis, Memcached): 현대적인 최적의 선택입니다. 메모리처럼 빠르고, 데이터베이스처럼 공유 가능하며, 만료 처리가 기본으로 제공됩니다. 대부분의 운영 애플리케이션에서 사용하는 방식입니다.

클라이언트 측 (JWT 토큰): 세션 데이터가 암호화되거나 서명되어 브라우저 자체에 저장됩니다. 서버에 아무것도 저장하지 않으므로 완벽한 확장성을 갖지만, 세션을 즉시 무효화할 수 없습니다. 사용자가 자신의 신원을 직접 가지고 다니는 것으로, 장단점이 있습니다.

세션 생명주기

세션은 영구적이지 않습니다. 태어나고, 살다가, 사라집니다.

생성: 서버가 고유한 식별자를 만들어 브라우저로 전송합니다. 이것은 첫 방문 시, 로그인 시, 또는 처음 상태가 필요할 때 (예: 장바구니에 무언가 추가할 때) 발생할 수 있습니다.

활성 사용: 각 요청은 세션의 마지막 접근 시간을 갱신합니다. 계속 활동하는 한 세션은 살아있습니다.

유휴 타임아웃: 15~30분 동안 활동이 없으면 서버는 당신이 떠났다고 판단하고 세션을 삭제합니다. 다음 요청은 아무것도 찾지 못하고 로그인 페이지로 리다이렉트됩니다.

절대 타임아웃: 일부 애플리케이션은 활동과 관계없이 고정된 시간이 지나면 세션을 종료합니다. 8시간 동안 로그인 상태를 유지했나요? 재인증할 시간입니다. 이는 세션 식별자가 도난당했을 때 피해를 제한합니다.

명시적 종료: 로그아웃 버튼을 클릭합니다. 서버는 즉시 세션 데이터를 삭제하고 식별자를 무효화합니다.

가비지 컬렉션: 사용자들은 로그아웃하지 않고 탭을 닫습니다. Wi-Fi 연결이 끊깁니다. 자리를 떠납니다. 서버는 주기적으로 명시적으로 종료되지 않은 만료된 세션을 정리합니다.

세션 보안

세션 식별자가 곧 신원이기 때문에, 이를 보호하는 것이 가장 중요합니다.

세션 하이재킹: 공격자가 세션 식별자를 획득하여 당신을 사칭합니다. 이는 다음과 같은 방법으로 발생할 수 있습니다:

• 보안이 없는 Wi-Fi에서의 네트워크 스니핑 (전송 중 식별자를 도청)
• 쿠키를 JavaScript로 훔치는 XSS (크로스사이트 스크립팅) 공격
• 브라우저 기록, 로그, URL에서 식별자 발견

방어는 여러 겹으로 이루어집니다:

• HTTPS: 전송 중 식별자를 암호화
• Secure 플래그: 암호화되지 않은 HTTP로는 쿠키가 전송되지 않음
• HttpOnly 플래그: JavaScript가 쿠키에 접근할 수 없음
• SameSite 속성: 크로스사이트 요청에 쿠키가 전송되지 않음
• 세션 재생성: 로그인 후 새 식별자를 생성하여, 공격자가 사전에 획득했을 수 있는 식별자를 무효화

세션 고정: 공격자가 로그인 전에 당신의 세션 식별자를 미리 설정합니다. 당신이 인증을 완료하면 공격자는 이미 세션 ID를 알고 있습니다. 본인이 선택했으니까요. 해결책은 간단합니다. 로그인 성공 후에는 항상 식별자를 재생성하세요.

무차별 대입 공격: 세션 식별자가 예측 가능하거나 너무 짧으면 공격자가 유효한 것을 추측할 수 있습니다. 세션 ID는 최소 128비트의 엔트로피를 가진 암호학적으로 안전한 난수 생성기를 사용하여 만들어야 합니다. 그래야 추측이 사실상 불가능해집니다.

세션 vs. 무상태 토큰

전통적인 세션은 상태를 서버에 저장합니다. JWT와 같은 무상태 인증은 상태를 클라이언트에 저장합니다.

세션은 서버에 완전한 제어권을 줍니다. 누군가를 즉시 로그아웃시켜야 하나요? 세션을 삭제하세요. 보안 사고가 발생했나요? 해당 사용자의 모든 세션을 무효화하세요. 서버가 정보의 원천입니다.

무상태 토큰은 서버 측 저장소를 없앱니다. 토큰에는 사용자 ID, 권한, 만료 시간 등 모든 것이 포함되며 변조를 방지하기 위해 서명됩니다. 확장성은 뛰어나지만 제어권을 포기해야 합니다. 서버 측 상태를 다시 도입하지 않으면 만료 전에 토큰을 무효화할 수 없습니다.

많은 현대 애플리케이션은 둘 다 활용합니다. API 요청에는 수명이 짧은 무상태 토큰을, 더 긴 세션에는 서버에서 추적하는 갱신 토큰을 결합합니다. 두 방식의 장점을 모두 가져가는 것입니다.

모범 사례

예측 불가능한 식별자 생성: 암호학적 수준의 무작위성을 사용하세요. 순차적인 정수나 타임스탬프는 절대 사용하지 마세요.

권한 변경 후 재생성: 로그인, 비밀번호 변경, 권한 업데이트 후에는 새 식별자를 발급하세요.

최소한의 데이터 저장: 세션 저장소를 간결하게 유지하세요. 모든 것을 저장하는 대신 사용자 ID만 저장하고 필요에 따라 세부 정보를 조회하세요.

제대로 된 로그아웃 구현: 서버 측에서 세션을 삭제하고 쿠키도 지우세요. 쿠키만 삭제하면 식별자를 획득한 사람이 있을 경우 세션이 여전히 유효합니다.

적절한 타임아웃 설정: 보안과 사용자 불편함 사이의 균형을 맞추세요. 민감한 애플리케이션은 짧은 타임아웃이 필요하고, 일반적인 애플리케이션은 더 여유롭게 설정해도 됩니다.

이상 징후 모니터링: 동일한 세션이 여러 IP에서 동시에 접근하고 있나요? 비정상적인 접근 패턴이 있나요? 이는 침해를 의심해볼 수 있는 신호입니다.

세션에 대해 자주 묻는 질문

세션과 쿠키의 차이점은 무엇인가요?

쿠키는 전송 수단입니다. 브라우저가 저장하고 요청과 함께 전송하는 작은 데이터 조각입니다. 세션은 서버에 저장된 실제 데이터입니다. 쿠키는 일반적으로 세션 식별자만 담고 있으며, 세션에는 그 식별자가 열어주는 모든 것이 들어 있습니다.

브라우저를 닫으면 왜 로그아웃이 되나요?

세션 쿠키는 "세션 쿠키"(브라우저 종료 시 삭제)와 "영구 쿠키"(브라우저를 재시작해도 유지)로 나뉩니다. 브라우저를 닫으면 로그아웃되는 사이트는 세션 쿠키를 사용합니다. 당신을 기억하는 사이트는 수명이 더 긴 세션과 함께 영구 쿠키를 사용합니다.

세션은 쿠키 없이도 작동할 수 있나요?

가능하지만 불편합니다. 세션 식별자를 URL에 포함시키거나 (보기에 안 좋고 안전하지 않습니다. 식별자가 북마크, 기록, 로그에 남습니다) 숨겨진 폼 필드를 통해 전달할 수도 있습니다 (모든 탐색에 폼이 필요합니다). 쿠키가 표준 방식인 이유는 자동으로 처리되고 사용자에게 보이지 않기 때문입니다.

여러 기기에서 세션은 어떻게 작동하나요?

각 기기는 자체 세션을 가집니다. 스마트폰으로 계정에 로그인하면 노트북 세션과는 독립적인 새 세션과 새 식별자가 만들어집니다. 일부 애플리케이션은 사용자의 모든 활성 세션을 추적하여 다른 기기의 세션을 확인하거나 종료할 수 있도록 합니다.

비밀번호를 변경하면 왜 모든 곳에서 로그아웃이 되나요?

잘 설계된 애플리케이션은 비밀번호를 변경할 때 기존의 모든 세션을 무효화합니다. 누군가 비밀번호를 훔쳐 자신의 세션을 만들었더라도 당신이 계정을 되찾으면 그 즉시 접근 권한을 잃게 됩니다.