로그인 기능을 구현하려고 찾아보니, 요즘은 다들 JWT(JSON Web Token) 를 쓰는 추세인 것 같았습니다.
하지만 '남들이 다 쓰니까 나도 쓴다'는 마인드를 버리기 위해, 전통적인 세션(Session) 방식과 어떤 점이 다르고
실제 서비스에서는 각각 언제 쓰이는지 공부해 보았습니다.
1. 세션
세션은 서버의 메모리나 DB에 '누가 로그인했는지(방문자 명부)' 를 적어두고 관리하는 방식입니다.
클라이언트에게는 그 명부의 번호표(ID)만 줍니다.
장점: 서버가 모든 정보를 쥐고 있습니다. 만약 해킹이 의심되거나 비밀번호가 변경되면,
서버에서 그 번호표를 지워버리면 끝입니다. (즉시 강제 로그아웃 가능)
단점: 동시 접속자가 10만 명이 되면, 서버는 10만 명의 명부를 다 들고 있어야 해서 무거워집니다.
서버를 여러 대 늘릴 때 명부를 공유하기도 까다롭습니다.
2. JWT (토큰)
JWT는 서버가 기억하지 않습니다. 대신 '위조 불가능한 전자 출입증' 을 만들어서 클라이언트에게 아예 줘버립니다. 서버는 나중에 클라이언트가 문을 두드릴 때, 출입증이 진짜인지만 검사합니다.
장점: 서버가 누구를 기억할 필요가 없어서(Stateless),
접속자가 아무리 많아져도 서버 메모리에 부담이 없습니다. 서버를 여러 대 띄우기도 아주 쉽습니다.
단점: 한 번 발급한 출입증은 유효기간이 끝날 때까지 서버가 마음대로 뺏을(강제 로그아웃) 수 없습니다. 누군가 출입증을 훔쳐 가면 막기가 까다롭습니다.
그래서 언제, 무엇을 써야 할까?
공부해보니 두 기술은 '좋고 나쁨'이 아니라 '목적' 이 달랐습니다.
세션(Session)이 더 어울리는 곳
보안과 통제가 가장 중요한 서비스
예시: 은행 / 금융권 앱, 사내 관리자(Admin) 페이지, 넷플릭스처럼 '동시 접속 기기 수'를 제한해야 하는 서비스.
이유: 서버에서 특정 사용자를 즉시 차단하거나 관리할 수 있는 강력한 통제력이 필요하기 때문입니다.
JWT(토큰)가 더 어울리는 곳
사용자가 엄청 많고, 확장이 중요한 서비스
예시: 인스타그램 같은 대규모 SNS, 모바일 앱(App) 환경, 백엔드와 프론트엔드가 완전히 분리된 서비스.
이유: 앱 환경에서는 브라우저처럼 세션 관리가 쉽지 않고, 접속자가 많아 서버를 유연하게 늘려야(Scale-out) 하므로 서버가 상태를 가지지 않는 것이 유리하기 때문입니다.
결론 (Insight)
무조건 유행하는 기술(JWT)을 맹신하지 말자.
보안과 강제 로그아웃이 중요하다면 세션,
서버의 확장성과 모바일 환경을 고려한다면 JWT를 선택하는 것이 올바른 기준이다.
내가 앞으로 개발할 API 서버들도 '어떤 종류의 서비스인가' 를 먼저 따져보고 인증 방식을 결정해야겠다.
