로그인 기능은 어떻게 구현하나요?(이론)

✅ 들어가며
웹 서비스에서 인증은 필수적인 기능입니다. 특히 사용자의 로그인 과정은 단순한 인증을 넘어 보안, 확장성, 유지관리성과 밀접하게 연관되어 있습니다. 이번 글에서는 로그인 기능 구현의 기본 흐름부터 세션과 JWT의 차이, 저장 방식, 토큰 재발급, 혼합 사용 사례까지 정리해보았습니다.

1. 로그인 기능의 구현 흐름

로그인 기능은 다음과 같은 순서로 구현됩니다:

1. 사용자 입력 검증

• 이메일, 비밀번호 등 입력값의 유효성 검사
• 포맷 오류 시 적절한 에러 메시지 반환

2. 인증 처리

• DB에서 사용자 정보 조회 및 비밀번호 일치 확인
• 일치 시 인증 성공, 불일치 시 실패

3. 세션 or 토큰 발급

• 인증 성공 시 서버는 세션을 생성하거나 JWT를 발급

4. 클라이언트 저장

• 세션 ID 또는 JWT를 클라이언트에 저장 (쿠키, 로컬스토리지 등 활용)

5. 인증 유지

• 이후 요청 시 저장된 세션 ID나 JWT로 인증 유지

2. 세션 vs JWT

항목	세션(Session)	JWT (JSON Web Token)
저장 위치	서버 (세션 데이터), 클라이언트는 세션 ID만 보관	클라이언트가 토큰 전체를 보관
확장성	서버 상태 유지 필요 → 서버 부하, 분산 처리 어려움	서버 스테이트리스 → 확장성에 유리
보안성	서버에서 직접 관리 → 상대적으로 안전	클라이언트에 저장되므로 탈취 위험 있음
사용 예시	로그인 후 세션 ID를 쿠키로 보냄	로그인 후 JWT 토큰을 쿠키 또는 로컬스토리지에 저장

3. JWT의 구조

JWT는 Header.Payload.Signature 형식으로 구성됩니다.

• Header: 토큰 타입과 서명 알고리즘 (예: {"alg": "HS256", "typ": "JWT"})
• Payload: 사용자 정보 및 클레임 포함 (예: sub, iat, exp 등)
• Signature: Header + Payload에 비밀 키로 서명하여 생성

⚠️ 주의:

• alg: none 사용 금지
• 비밀 키는 예측 불가한 값으로 설정

4. 토큰 저장 위치: 쿠키 vs 스토리지

저장 방식 장점 단점
쿠키 - 자동으로 요청에 포함됨

• HttpOnly, Secure 설정 가능 - CSRF 공격에 취약
• 용량 제한 있음
  로컬/세션 스토리지 - CSRF에 안전
• 용량이 비교적 큼 - XSS에 취약
• HttpOnly 설정 불가 → JS 접근 가능

✔ 보안이 중요한 인증 정보는 일반적으로 HttpOnly 쿠키 사용을 권장합니다.

5. 토큰 재발급 시점은?

• Access Token 만료 직전: 백그라운드에서 갱신

• Refresh Token 보유 시: refresh로 새로운 access 토큰 발급

• 이상 활동 탐지 시: 기기 변경, 위치 변경 등에서 재인증 요구

6. JWT와 세션을 함께 사용하는 방법은?

하이브리드 접근 방식으로 다음과 같이 사용합니다:

• JWT로 인증 처리: 클라이언트는 JWT를 보관, 요청 시 인증용으로 전송
• 세션으로 상태 관리: 서버는 세션에 사용자 상태, 권한, 설정 등을 저장

📌 이 방식은 인증은 무상태(stateless)로, 상태 관리는 서버에서 이루어져 보안성과 확장성의 균형을 맞춥니다.

✍️ 마치며
로그인 기능은 단순한 기술 구현을 넘어 보안, 사용자 경험, 서비스 구조 전반에 영향을 주는 핵심 기능입니다. 세션과 JWT 각각의 특징을 이해하고, 서비스의 규모와 특성에 따라 적절히 선택하거나 조합하는 것이 중요합니다.