[내일배움캠프 TIL, Day2] 스프링 3계층 구조부터 JWT 인증 및 백엔드 심화 키워드 정리
1. 오늘 학습 키워드
- Architecture: 3 Layer Architecture(Controller, Service, Repository)와 IoC/DI 컨테이너
- JPA: 영속성 컨텍스트(1차 캐시, Dirty Checking), N+1 문제, Query Methods
- Auth: 쿠키/세션 방식 및 JWT(JSON Web Token) 기반 무상태 인증
- Communication: 동기(Sync) vs 비동기(Async) 처리 및 제어권 흐름
- Utility: 모듈화를 위한 Utility Class와 API 문서 자동화(Swagger)
2. 학습 내용 정리하기
🏗️ 3 Layer Architecture: 역할의 분리
계층 간 역할을 명확히 나누어 비즈니스 로직과 데이터 접근 로직의 간섭을 최소화함.
- Controller: API의 진입점. 요청을 받고 응답을 반환하며, 서비스와 메서드명을 일치시켜 가독성을 확보함.
- Service: 비즈니스 로직의 핵심 수행. 사용자 요구사항을 처리하며 CRUD 관점에서 명명함.
- Repository: 데이터베이스 관리 및 실제 CRUD 수행. 공용 메서드는 하단에 배치하여 구조적 안정성을 도모함.
🎨 Spring IoC와 DI: 제어권의 변화
- 제어의 역전(IoC): 스프링 컨테이너가 객체의 생성을 전담함. 개발자는 인터페이스와 어노테이션을 통해 ‘사용’에만 집중할 수 있음.
- 의존성 주입(DI): 생성자 주입을 통해 약한 결합을 지향함.
- 불변성 보장:
private final필드와@RequiredArgsConstructor를 활용한 생성자 주입 방식을 사용하여 객체의 안전성을 확보함.
🌐 JPA 영속성 컨텍스트의 메커니즘
엔티티를 효율적으로 관리하기 위한 메모리상의 저장소 역할을 함.
- 1차 캐시: 동일 트랜잭션 내 객체 동일성을 보장하고 DB 접근 횟수를 줄여 성능을 최적화함.
- 쓰기 지연 저장소: SQL을 즉시 실행하지 않고 모아두었다가
commit시점에 일괄 처리함. - 변경 감지(Dirty Checking): 영속 상태 엔티티의 상태 변화를 감지하여 별도의
save()호출 없이도 Update 쿼리를 자동 생성함.
🔐 인증 전략: 세션 vs JWT
웹의 무상태성을 보완하고 유저를 식별하기 위한 두 가지 핵심 메커니즘
- 쿠키/세션 방식: 서버가 세션 ID를 발급·저장하고 클라이언트는 쿠키에 이를 담아 보냄. 보안 제어가 용이하나 사용자가 늘어날수록 서버 메모리 부하가 증가함.
- cf. 쿠키(Cookie): 클라이언트에 저장될 목적으로 생성된 작은 정보를 담은 파일.
-
JWT 방식: 서버의 토큰 발급 → 클라이언트의 매 요청 시 전달 → 서버의 서명 검증 및 사용자 식별
서버는 사용자가 로그인하면 인증 정보를 담은 토큰을 발급하여 전달함.
JWT는 단순한 암호화가 아닌 ‘변조 방지(서명)’에 초점을 맞춘 인증 방식임.- 구조 (Header.Payload.Signature)
- Header: 알고리즘과 토큰 타입 명시.
- Payload: 유저 ID, 권한 등 실제 정보(Claim).
- Signature: 서버의 Secret Key로 만든 서명. 토큰의 무결성을 증명함.
- 동작 프로세스
- 로그인 성공 시 서버가 토큰 발급 및 전달.
- 클라이언트는 이후 모든 API 요청 시 HTTP Header에 토큰을 포함.
- 서버는 보유한 비밀키로 토큰의 서명(Signature)을 검증하여 정당성 판단.
- 결과: 서버가 세션을 유지할 필요가 없어 서버 부하를 낮추는 ‘무상태(Stateless)’ 인증 실현.
- 구조 (Header.Payload.Signature)
3. 학습하며 겪었던 문제점 & 에러
🔍 개념 재정립 및 심화 학습
1)의존성 주입(DI)의 선택 기준 : 의존성 주입의 3가지 방식(필드, 수정자, 생성자) 생성자 주입이 권장되는 이유
- 객체의 불변성(Immutability) 보장:
final키워드 사용이 가능하여 객체 생성 시점에 의존성이 주입된 후 변경되지 않음을 보장
2)JPA 상태 관리 : 엔티티의 4가지 상태(비영속, 영속, 준영속, 삭제)와 변경 감지(Dirty Checking)가 일어나는 시점의 연관성
- 비영속 (New/Transient): 순수한 객체 상태. 영속성 컨텍스트나 DB와는 아무런 관련이 없음.
- 영속 (Managed): 영속성 컨텍스트에 의해 관리되는 상태. 1차 캐시, 쓰기 지연, 변경 감지가 모두 적용되는 핵심 상태임.
- 준영속 (Detached): 영속성 컨텍스트에서 분리된 상태. 영속 상태였다가
em.detach()나em.clear()로 인해 관리 대상에서 제외됨. 가장 흔히 하는 실수로, 이 상태의 객체를 수정해도 DB에 반영되지 않음. - 삭제 (Removed): 엔티티를 영속성 컨텍스트와 DB에서 삭제하기로 마킹된 상태.
💡 새롭게 알게 된 점- 변경 감지의 트리거: 변경 감지(Dirty Checking)는 오직 영속(Managed) 상태일 때만 작동함. 트랜잭션이 종료(
commit)되는 시점에 영속성 컨텍스트가 가진 스냅샷과 현재 엔티티를 비교하여 자동으로 SQL을 생성함. - 상태 전환의 인지: 수동으로 엔티티를 분리(
detach)하거나 준영속 상태의 객체를 다룰 때는 반드시 영속성 컨텍스트로 다시 편입시키는 작업(예:merge)이나 트랜잭션 범위에 대한 재설계 필요
- 변경 감지의 트리거: 변경 감지(Dirty Checking)는 오직 영속(Managed) 상태일 때만 작동함. 트랜잭션이 종료(
3) Sync (동기) vs Async (비동기) : 요청과 응답의 타이밍에 관한 처리 방식
- Sync: 요청 후 응답이 올 때까지 대기하며 제어권을 프로세스가 점유
- Async: 요청 후 응답을 기다리지 않고 제어권을 반환받아 다른 작업을 수행
4) API 문서 자동화 (Swagger / JavaDoc) : 코드 주석이나 설정을 통해 API 명세서(Endpoint, Parameter 등)를 자동 생성하는 도구
- Swagger: 브라우저 UI를 통해 API 테스트가 가능한 동적 문서 생성.
- JavaDoc: 소스 코드 주석 기반의 정적 HTML 문서 생성.
5) JPA N + 1 문제
- 개념: 연관 관계가 설정된 엔티티를 조회할 때, 1번의 쿼리를 예상했으나 연관된 데이터 조회를 위해 N번의 추가 쿼리가 발생하는 성능 저하 현상
- 해결:
Fetch Join이나@EntityGraph를 사용하여 한 번의 조인 쿼리로 데이터를 가져와야 함.
6) 순환 참조 (Circular Reference)
- 개념: 양방향 연관 관계에서 두 객체가 서로를 참조하여, JSON 변환(직렬화) 시 무한 루프에 빠지는 현상
- 해결: 엔티티를 직접 반환하지 말고 반드시 DTO를 사용하거나,
@JsonIgnore로 참조를 끊어주어야 함.
4. 내일 학습 할 것은 무엇인지
- Spring 숙련&심화 코스
#내일배움캠프 #단기Java #TIL
Leave a comment