결론 : JWT 토큰은 무조건 서버가 만듭니다.
| 단계 | 누가 | 무엇을 하는가? | 설명 |
| ① | 클라이언트 | 로그인 요청 (ID, PW) | 사용자가 서버에 로그인 시도 |
| ② | 서버 | 사용자 인증 (DB 확인 등) | DB에서 사용자를 검증 |
| ③ | 서버 | JWT 생성 (Secret Key로) | 사용자 검증 완료 후 서버가 JWT 생성 |
| ④ | 서버 → 클라이언트 | JWT 전송 | 서버가 생성한 JWT를 클라이언트에 전달 |
| ⑤ | 클라이언트 | JWT 저장 후 요청 시마다 전달 | 클라이언트는 JWT를 저장했다가 매 요청 시 서버에 보냄 |
| ⑥ | 서버 | JWT 검증 | 요청 받을 때마다 JWT 검증 |
즉, 클라이언트는 서버가 만들어 준 JWT를 저장하고 있다가 요청할 때마다 서버로 전달하는 역할만 수행합니다. 직접 JWT를 생성하지 않습니다.
서버의 비밀키(Secret Key)가 왜 중요할까?
서버의 비밀키는 JWT의 서명을 생성할 때 사용하는 유일한 비밀번호 같은 존재입니다.
- 절대 클라이언트나 외부에 노출되면 안 됩니다.
- 만약 이 비밀키가 외부에 노출된다면, 누구나 원하는 데이터를 조작해 유효한 JWT를 마음대로 만들어낼 수 있게 됩니다.
그래서 보통 이 비밀키는 .env 환경변수 등으로 안전히 보관하고, 절대 소스코드나 Git 등에 올리지 않습니다.
JWT 자체 검증 vs DB 조회: 속도 차이
일반적으로 JWT 자체 검증이 DB 조회 방식보다 훨씬 빠릅니다. 이유는 다음과 같습니다.
| 작업 | 종류 과정 | 속도 | 부하 |
| JWT 검증 | 헤더/페이로드 base64 디코딩 → 서명 검증 (암호화 해시 알고리즘 수행) → 유효성 체크 |
매우 빠름 | 서버 CPU 사용(O), DB 부하 X |
| DB 조회 | 요청 → DB연결 → DB 쿼리 실행 → 결과 전송 → 결과값 분석 | 상대적으로 느림 | DB 부하 증가 |
즉, JWT는 로컬 연산이라 빠르고, DB 조회는 네트워크 + 디스크 I/O 연산이 추가되므로 상대적으로 느립니다.
왜 JWT를 써야 할까요?
- 서버 부담 감소 (세션 관리 없음) - 사용자의 인증 상태를 별도의 저장소(예: DB)에 저장하지 않는다는 뜻
- 보안 향상 (토큰 변조 방지) - 서버만 가진 Secret Key로 서명하여, 변조된 토큰을 즉시 탐지해 보안을 강화
- 성능 우수 (빠른 인증 처리) - 매 요청 시 서버가 DB를 조회하지 않고 JWT 자체만으로 인증하므로, 인증 속도가 매우 빠름