1. 학습 주제
이번에는 구현보다 웹 인증/인가 구조와 렌더링 방식 같은 이론 중심 내용을 정리했다.
특히 로그인 상태를 어떻게 유지하는지, 세션 기반과 토큰 기반 인증이 어떻게 다른지, 그리고 Spring Security가 요청 흐름 어디에서 동작하는지를 이해하는 것이 핵심이었다.
함께 정리한 주제는 다음과 같다.
- Principal, Authentication, Authorization
- 세션 기반 인증과 토큰 기반 인증
- Access Token / Refresh Token
- Filter와 Interceptor 차이
- SSR / CSR 차이와 Next.js 감각
- CQRS 패턴
- CSRF 개념
2. Principal, Authentication, Authorization
이 세 개는 보안 개념에서 가장 기본이다.
Principal
현재 시스템이 인식하고 있는 “사용자 주체”이다.
쉽게 말하면 “지금 요청을 보낸 사용자가 누구인가”를 나타내는 개념이다.
예:
- 로그인한 사용자 ID
- 사용자 이메일
- 사용자 엔티티 일부 정보
즉 Principal은 “누구냐”에 가깝다.
Authentication
인증이다.
사용자가 주장하는 신원이 진짜 맞는지 확인하는 과정이다.
예:
- 아이디/비밀번호 확인
- JWT 검증
- 소셜 로그인 토큰 검증
즉 Authentication은 “네가 진짜 그 사람이 맞냐”를 검사하는 것이다.
Authorization
인가 또는 권한 확인이다.
인증된 사용자가 특정 기능을 해도 되는지 판단하는 과정이다.
예:
- 관리자만 접근 가능
- 로그인 사용자만 접근 가능
- 본인 글만 수정 가능
즉 Authorization은 “그 사람이 이 작업을 할 권한이 있냐”를 따지는 것이다.
한 줄로 정리하면:
- Principal: 누구인가
- Authentication: 진짜 맞는가
- Authorization: 해도 되는가
3. 세션 기반 인증
세션 기반 인증은 로그인 상태를 서버에 저장하는 방식이다.
흐름은 보통 이렇게 간다.
- 사용자가 로그인 요청
- 서버가 아이디/비밀번호 확인
- 서버가 세션 저장소에 로그인 상태 저장
- 브라우저는 세션 ID를 쿠키로 보관
- 이후 요청마다 쿠키의 세션 ID를 함께 보냄
- 서버는 세션 ID를 보고 로그인 상태를 확인
즉 핵심은:
- 실제 로그인 정보는 서버 쪽에 저장
- 브라우저는 세션 ID만 들고 다님
이다.
장점
- 서버가 직접 로그인 상태를 관리하므로 통제가 쉽다
- 토큰을 직접 해석할 필요 없이 세션만 확인하면 된다
- 전통적인 Spring MVC, JSP, SSR 구조와 잘 어울린다
단점
- 서버가 세션을 저장하고 있어야 한다
- 서버가 여러 대일 경우 세션 공유 문제가 생긴다
사용자가 로드밸런서를 통해:
- 처음엔 Server A
- 다음 요청은 Server B
로 가면, 세션이 A에만 있고 B에 없다면 로그인 상태를 못 찾을 수 있다.
이 문제를 해결하는 대표적인 방법은 다음이다.
- Sticky Session : 같은 사용자를 같은 서버로 계속 보내는 방식
- Session Cluster / Session Store : Redis 같은 공용 저장소에 세션을 저장해서 서버들이 함께 쓰는 방식
즉 “Server B로 가면 다시 로그인해야 하나?”의 답은
기본적으로는 그럴 수 있고, 그래서 세션 공유 전략이 필요하다고 이해하면 된다.
4. 토큰 기반 인증
토큰 기반 인증은 로그인 상태를 서버 메모리에 직접 저장하지 않고,
클라이언트가 토큰을 들고 다니는 방식이다.
흐름은 보통 이렇다.
- 사용자가 로그인 요청
- 서버가 인증 성공 후 토큰 발급
- 클라이언트가 토큰을 저장
- 이후 요청마다 토큰을 함께 보냄
- 서버는 토큰이 유효한지만 검증
- 유효하면 요청 통과
즉 핵심은:
- 세션처럼 서버가 상태를 들고 있지 않고
- 클라이언트가 “이용권”처럼 토큰을 들고 다닌다
는 점이다.
5. JWT는 무엇인가
토큰 기반 인증에서 자주 쓰는 형식이 JWT다.
JWT
JSON Web Token
즉 JSON 형태의 정보를 담은 서명된 토큰이다.
서버는 토큰 안의 정보를 확인하고,
서명이 맞는지 검증해서 신뢰할 수 있는지 판단한다.
중요한 점은:
- 서버가 세션 저장소를 꼭 유지하지 않아도 되고
- 토큰 자체가 인증 정보 일부를 담을 수 있다는 것
이다.
다만 JWT는 편리하지만,
유출되면 토큰 만료 전까지 악용될 수 있다는 위험도 있다.
6. Access Token과 Refresh Token
이 둘은 거의 항상 같이 정리해야 한다.
Access Token
실제 API 접근에 사용하는 토큰이다.
비유하면 “단기 자유이용권”에 가깝다.
특징:
- 수명이 짧다
- 요청마다 같이 보낸다
- 노출 위험을 줄이기 위해 만료 시간을 짧게 둔다
Refresh Token
새로운 Access Token을 재발급받을 때 사용하는 토큰이다.
비유하면 “장기 회원권”에 가깝다.
특징:
- Access Token보다 수명이 길다
- 직접 모든 API를 호출하는 용도보다는 재발급 용도다
- 유출되면 더 위험하므로 관리가 더 중요하다
즉 구조는:
- Access Token이 만료되면
- Refresh Token으로 새 Access Token 발급
흐름이다.
7. 세션 기반과 토큰 기반 비교
세션 기반
- 로그인 상태를 서버가 저장
- 브라우저는 세션 ID만 전달
- 서버 수가 늘어나면 세션 공유 전략 필요
토큰 기반
- 클라이언트가 토큰을 들고 다님
- 서버는 토큰을 검증만 하면 됨
- 서버 확장에 더 유리한 편
감각적으로 보면
- 세션 기반: 서버가 출입 명부를 들고 있음
- 토큰 기반: 사용자가 유효한 이용권을 들고 다님
8. 쿠키를 많이 쓰는 이유와 조심할 점
쿠키는 브라우저가 자동으로 요청에 실어 보내는 저장 방식이라서 편하다.
많이 쓰는 이유
- 브라우저가 자동으로 전송해줌
- key=value 형태로 다루기 쉬움
- 세션 ID 저장, 간단한 상태 저장에 유용함
조심할 점
- 브라우저에 저장되므로 공용 PC에서 위험할 수 있음
- 보안 설정을 잘못하면 노출 가능성이 있음
그래서 실제로는:
- HttpOnly
- Secure
- SameSite
같은 옵션을 잘 설정해서 사용해야 한다.
즉 쿠키는 편리하지만,
“브라우저 저장소”라는 특성 때문에 보안 고려가 반드시 필요하다.
9. Filter와 Interceptor 차이
둘 다 요청을 중간에서 가로챈다는 점은 같지만, 레벨이 다르다.
Filter
서블릿 스펙 레벨에서 동작한다.
즉 Spring보다 더 바깥쪽에서 요청과 응답을 가로챈다.
특징:
- 웹 애플리케이션 전반 요청을 잡을 수 있다
- Spring MVC에 들어오기 전 단계다
- 보통 인코딩, 공통 보안 처리, 로그인 체크 전처리 등에 쓴다
Interceptor
Spring MVC 레벨에서 동작한다.
즉 DispatcherServlet 이후, 컨트롤러 호출 전후에 개입한다.
특징:
- Spring Bean에 접근 가능
- 컨트롤러 실행 전후 제어에 적합
- 로그인 체크, 권한 체크, 실행 시간 기록 등에 자주 사용
즉 한 줄로 정리하면:
- Filter = 더 바깥에서 요청 자체를 잡는 단계
- Interceptor = Spring MVC 안에서 컨트롤러 앞뒤를 잡는 단계
10. Spring Security는 어디에서 동작하나
Spring Security는 보통 Filter 체인 기반으로 동작한다.
즉 “컨트롤러까지 오기 전에”
보안 관련 필터들이 먼저 요청을 검사한다.
예:
- 로그인 요청 처리
- JWT 검증
- 인증 객체 생성
- 권한 체크 전 준비
즉 Spring Security는 단순 Interceptor 수준이 아니라,
웹 요청 흐름 초반부에서 보안 처리를 담당하는 구조라고 이해하면 된다.
11. SSR이란 무엇인가
SSR
Server Side Rendering
서버가 HTML을 만들어서 브라우저에 보내는 방식이다.
즉 브라우저는 이미 렌더링된 결과를 받는다.
장점
- 초기 화면이 빠르게 보일 수 있다
- 검색 엔진이 내용을 읽기 좋다
- SEO에 유리하다
단점
- 요청마다 서버 렌더링 비용이 든다
- 서버 부담이 커질 수 있다
네가 적은 내용처럼,
서버가 모든 화면 렌더링을 다 맡으면 요청마다 비용이 생긴다.
12. SEO란 무엇인가
SEO
Search Engine Optimization
검색 엔진 최적화이다.
즉 구글이나 네이버 같은 검색 엔진이
페이지 내용을 잘 읽고 검색 결과에 잘 노출되게 만드는 것이다.
SSR이 SEO에 유리한 이유는
검색 엔진이 처음부터 완성된 HTML을 읽기 쉽기 때문이다.
13. CSR이란 무엇인가
CSR
Client Side Rendering
브라우저에서 JavaScript가 화면을 그리는 방식이다.
예:
- React
- Vue
초기에는 빈 HTML이나 최소한의 HTML만 받고,
이후 브라우저가 API 데이터를 받아서 화면을 만든다.
장점
- 화면 전환이 빠를 수 있다
- 부분 업데이트가 유리하다
- 사용자 경험이 부드럽다
단점
- 초기 로딩 시 JavaScript 실행이 필요하다
- 검색 엔진이 내용을 즉시 읽기 어려울 수 있다
- SEO 측면에서 불리할 수 있다
14. Virtual DOM이 왜 나왔는가
CSR 프레임워크에서는 매번 전체 화면을 다시 그리는 비용을 줄이기 위해 Virtual DOM 개념을 사용한다.
즉 실제 DOM을 바로 다 건드리는 대신,
메모리 상에서 가상 구조를 비교하고 바뀐 부분만 반영하는 방식이다.
그래서:
- 한 부분만 바뀌었는데 전체를 다시 그리지 않고
- 필요한 부분만 효율적으로 업데이트할 수 있다
이 점 때문에 React 같은 라이브러리가 빠른 UI 업데이트에 강하다.
15. SSR + CSR과 Next.js
Next.js는 React 기반이지만
SSR과 CSR을 섞어서 사용할 수 있다는 점이 특징이다.
즉:
- 처음엔 서버 렌더링으로 HTML을 보여주고
- 이후에는 클라이언트에서 상호작용과 상태 관리를 한다
이런 혼합 전략이 가능하다.
use client
이건 “처음 렌더링하게 도와준다”보다는,
이 컴포넌트는 Client Component로 동작해야 한다는 선언에 가깝다.
즉:
- 상태 사용
- 이벤트 처리
- 브라우저 API 사용
이 필요한 컴포넌트는 use client가 붙는다.
즉 Next.js는
SSR과 CSR을 상황에 맞게 조합할 수 있는 프레임워크라고 이해하면 된다.
16. JSP와 Servlet, Spring MVC 흐름
JSP는 예전 Java 웹 개발에서 화면을 만들기 위한 기술이었다.
흐름을 크게 보면:
- Servlet이 요청을 받고
- JSP가 화면을 만들고
- Spring MVC에서는 이를 더 구조화해서 Handler Method로 요청을 처리한다
즉 Spring MVC는
Servlet 기반 위에서 더 편하게 요청을 처리할 수 있도록 만든 프레임워크라고 이해하면 된다.
17. CQRS 패턴
CQRS
Command Query Responsibility Segregation
즉 명령과 조회의 책임을 분리하는 패턴이다.
Command
데이터를 바꾸는 작업
예:
- INSERT
- UPDATE
- DELETE
즉 DML과 연결된다.
Query
데이터를 읽는 작업
예:
- SELECT
- 목록 조회
- 조건 조회
이 패턴을 쓰는 이유는
읽기와 쓰기의 요구사항이 다를 수 있기 때문이다.
예:
- 쓰기는 JPA로 단순하고 안전하게 처리
- 읽기는 복잡한 조회 SQL이나 별도 조회 모델로 처리
즉 CQRS는
쓰기 모델과 읽기 모델을 분리해서 각각 최적화하는 사고 방식이라고 보면 된다.
18. CSRF란 무엇인가
CSRF
Cross Site Request Forgery
즉 사용자가 모르는 사이에
다른 사이트에서 내 인증 정보를 이용해 요청을 보내게 만드는 공격이다.
예를 들어 사용자가 로그인된 상태에서
악성 페이지에 접속했는데 그 페이지가 내 브라우저를 이용해
의도치 않은 요청을 보내게 만드는 식이다.
세션 기반 인증에서 특히 더 중요하게 다뤄진다.
왜냐하면 브라우저가 쿠키를 자동으로 보내기 때문이다.
방어 방법
- CSRF 토큰 사용
- SameSite 쿠키 설정
- 상태 변경 요청은 POST/PUT/DELETE로 구분
- Origin/Referer 검증
즉 CSRF는
“내 브라우저가 가진 인증 상태를 악용하는 공격”이라고 이해하면 된다.
19. 전체 흐름 정리
보안 개념
- Principal: 누구인가
- Authentication: 진짜 맞는가
- Authorization: 해도 되는가
인증 방식
- 세션 기반: 서버가 상태 저장
- 토큰 기반: 클라이언트가 토큰 보관
- Access Token: 짧은 인증 토큰
- Refresh Token: 재발급용 긴 토큰
요청 가로채기
- Filter: 서블릿 레벨
- Interceptor: Spring MVC 레벨
- Spring Security: 주로 Filter 체인 기반
렌더링
- SSR: 서버가 HTML 생성, SEO 유리
- CSR: 클라이언트가 화면 그림, 상호작용 유리
- Next.js: SSR + CSR 혼합 가능
구조 패턴
- CQRS: Command와 Query 분리
- CSRF: 인증 상태 악용 공격에 대한 방어 필요
20. 핵심 정리
- Principal은 현재 시스템이 인식하는 사용자 주체이다.
- Authentication은 사용자의 신원을 확인하는 과정이고, Authorization은 권한을 확인하는 과정이다.
- 세션 기반 인증은 로그인 상태를 서버에 저장하고, 브라우저는 세션 ID를 쿠키로 들고 다닌다.
- 토큰 기반 인증은 사용자가 토큰을 들고 다니고, 서버는 그 토큰을 검증하는 방식이다.
- Access Token은 짧게 쓰는 인증 토큰이고, Refresh Token은 Access Token 재발급용 장기 토큰이다.
- Filter는 서블릿 레벨에서, Interceptor는 Spring MVC 레벨에서 요청을 가로챈다.
- Spring Security는 보통 Filter 체인을 기반으로 인증과 권한 처리를 수행한다.
- SSR은 서버가 HTML을 렌더링해서 보내는 방식이고, SEO에 유리하다.
- CSR은 브라우저가 화면을 그리는 방식이고, 인터랙션과 부분 업데이트에 강하다.
- Next.js는 SSR과 CSR을 상황에 맞게 함께 사용할 수 있다.
- CQRS는 데이터 변경 작업과 조회 작업을 분리하는 패턴이다.
- CSRF는 로그인된 사용자의 인증 상태를 악용하는 공격이므로 세션 기반 구조에서 특히 주의해야 한다.
'TIL > [TIL]' 카테고리의 다른 글
| [TIL]Spring Security에서 CQRS 적용과 사용자 조회 흐름 (0) | 2026.06.24 |
|---|---|
| [TIL]Spring Security와 JWT 기반 인증 흐름 (0) | 2026.06.23 |
| [TIL]Spring Data JPA로 메뉴 등록, 수정, 삭제 구현하기 (0) | 2026.06.18 |
| [TIL]Spring Data JPA로 메뉴 조회 API 구성하기 (0) | 2026.06.17 |
| [TIL]JPQL JOIN, Native Query, 그리고 Spring Data JPA 시작 (0) | 2026.06.16 |