[try] 인증 실제로 적용해보기
1편에서 세션과 토큰, 2편에서 OAuth 2.0과 실무 인증 패턴을 정리했는데요. 이번에는 실제 프로젝트에 어떻게 적용할지 정리해보겠습니다.
면접에서 “인증 어떻게 구현하셨어요?” 물어볼 때 대답할 수 있는 수준으로요.
인증 아키텍처 설계하기
상황별 추천 구조
1. 전통적인 웹 서비스 (SSR)
1
2
3
[사용자] → [웹 서버] → [DB]
↓
HTTP 세션 + Redis
- 세션 기반 인증
- Redis로 세션 공유 (서버 여러 대일 때)
- 강제 로그아웃 쉬움
적합한 경우: 관리자 페이지, 사내 시스템, 레거시 프로젝트
2. SPA + API 서버
1
2
3
4
5
[React/Vue] → [API 서버] → [DB]
↓
JWT 저장
(Access Token: 메모리)
(Refresh Token: httpOnly Cookie)
- JWT 기반 인증
- Access Token은 짧게 (15분~1시간)
- Refresh Token으로 갱신
적합한 경우: 모던 웹 앱, 모바일 앱 동시 지원
3. MSA 환경
1
2
3
4
[클라이언트] → [API Gateway] → [각 서비스]
↓
JWT 검증
(인증 서버 별도)
- 인증 서버 분리
- 각 서비스는 토큰 검증만
- 서비스 간 통신은 내부 토큰 또는 mTLS
적합한 경우: 대규모 서비스, 서비스별 독립 배포 필요할 때
외부 연동 시 인증 방식 선택
실무에서는 여러 외부 서비스와 연동하게 되는데요. 상황별로 어떤 인증 방식을 쓰면 좋을지 정리해봤습니다.
| 연동 대상 | 추천 방식 | 이유 |
|---|---|---|
| SNS 로그인 (카카오, 네이버) | OAuth 2.0 Authorization Code | 표준, 사용자 권한 위임 |
| 결제 API (토스, 네이버페이) | Basic Auth 또는 API Key | 서버 간 통신, 단순함 |
| 외부 데이터 연동 (배치) | OAuth 2.0 Client Credentials | 사용자 없이 서버 간 통신 |
| 웹훅 수신 | HMAC 검증 | 요청 출처 확인, 무결성 검증 |
| 사내 시스템 통합 | SSO | 한 번 로그인으로 여러 시스템 |
보안 체크리스트
인증 구현할 때 놓치기 쉬운 부분들이에요.
토큰 관련
- Access Token 만료 시간 적절한가? (권장: 15분~1시간)
- Refresh Token은 httpOnly Cookie에 저장했나?
- 토큰에 민감 정보 넣지 않았나? (비밀번호, 주민번호 등)
- 강제 로그아웃 방법 있나? (토큰 블랙리스트 등)
키 관리
- Secret Key 환경변수로 관리하나? (하드코딩 금지)
- 키 길이 충분한가? (최소 256bit)
- 키 로테이션 계획 있나?
통신 보안
- HTTPS 적용했나?
- CORS 설정 제대로 했나?
- Rate Limiting 있나? (브루트포스 방지)
면접 예상 질문
Q1. 세션 기반과 토큰 기반 인증의 차이는?
가장 큰 차이는 상태 저장 위치입니다.
세션은 서버가 상태를 저장하고(Stateful), 토큰은 클라이언트가 들고 다닙니다(Stateless).
세션은 강제 로그아웃이 쉽지만 서버 확장 시 세션 공유 문제가 있고, 토큰은 서버 확장이 자유롭지만 발급된 토큰 무효화가 어렵습니다.
Q2. JWT의 구조를 설명해주세요.
JWT는 Header, Payload, Signature 3부분으로 구성됩니다.
Header에는 알고리즘과 토큰 타입, Payload에는 사용자 정보와 만료시간 같은 클레임, Signature에는 위변조 방지를 위한 서명이 들어갑니다.
주의할 점은 Payload가 암호화가 아니라 인코딩이라서, 민감한 정보는 넣으면 안 됩니다.
Q3. Access Token과 Refresh Token을 왜 분리하나요?
보안과 사용자 경험을 동시에 잡기 위해서입니다.
Access Token만 사용하면, 만료를 짧게 하면 자주 로그인해야 하고, 길게 하면 탈취 시 오래 악용됩니다.
Access Token은 짧은 만료로 탈취 피해를 최소화하고, Refresh Token은 긴 만료로 사용자가 자주 로그인하지 않아도 되게 합니다.
Q4. OAuth 2.0 Authorization Code 방식을 설명해주세요.
사용자가 로그인 버튼을 클릭하면 Authorization Server로 리다이렉트됩니다.
사용자가 로그인하고 권한에 동의하면, Authorization Code와 함께 원래 서비스로 돌아옵니다.
서비스 서버는 이 Code와 Client Secret을 사용해 Access Token을 요청합니다.
Code를 거치는 이유는 토큰을 URL에 직접 노출하지 않고, 서버 간 통신으로 안전하게 교환하기 위해서입니다.
Q5. HMAC 인증의 장점은?
비밀키를 네트워크로 전송하지 않는다는 점입니다.
클라이언트와 서버가 같은 비밀키로 메시지를 해싱하고, 해시값만 비교해서 인증합니다.
비밀키가 네트워크에 노출되지 않아 Basic Auth보다 안전하고, 메시지 변조도 감지할 수 있습니다.
시리즈 마무리
3편에 걸쳐 인증에 대해 정리해봤는데요. 정리하면 이렇습니다.
1편: 기본 개념
- 인증(Authentication) vs 인가(Authorization)
- 세션 기반 vs 토큰 기반
- JWT 구조와 보안
2편: 실무 패턴
- OAuth 2.0 (Authorization Code, PKCE, Client Credentials)
- Basic Auth, API Key, HMAC, SSO
3편: 적용하기
- 상황별 아키텍처 설계
- 보안 체크리스트
- 면접 대비
인증은 한 번 제대로 이해해두면 어떤 프로젝트에서든 써먹을 수 있어요. 이 시리즈가 도움이 됐으면 좋겠습니다.
이 글은 인증 시리즈 마지막 편입니다.
- 1편: 세션 vs 토큰, 알고 사용하기
- 2편: OAuth 2.0부터 HMAC까지 실무 인증 패턴 정리
- 3편: [try] 인증 실제로 적용해보기 (현재 글)