인증은 필터 계층,
인가는 @PreAuthorize + @EnableMethodSecurity 로 컨트롤러 단에서 처리
게시글 목록 조회 시 작성자 정보를 가져오면서 N+1 문제 발생 상황을 직접 확인
| 방식 | 결과 |
|---|---|
findAll() | N+1 발생 |
join | 여전히 N+1 발생 |
fetch join | 한 번의 쿼리로 해결 |
findAllFetchInnerJoin 등을 직접 Repository에 구현하여 성능 개선
Pageable 과 Page 구조 이해
map()을 활용한 Entity → DTO 변환
Specification을 활용한 동적 검색 조건 구현
@Scheduled 를 이용한 예약 게시글 자동 게시 처리
Spring Batch 기본 구조(Job, Step) 학습 및 실행 구조 이해
WAS vs Web Server 차이
Servlet → Controller 발전 구조
스레드 풀 기반 요청 처리 흐름 이해
필터 계층의 예외 처리: 컨트롤러 내부의 에러는 @ControllerAdvice가 잡지만, 필터에서 발생하는 에러는 닿지 않아 별도의 핸들러나 분기 처리가 필요하다는 점을 간과함
N+1 문제: 일반적인 inner join을 썼을 때와 왜 다른지 이해가 안 갔었음. 연관된 엔티티를 조회하는 시점에 쿼리가 추가로 발생하는 현상을 직접 확인하며 fetch inner join과 일반 inner join의 다른점을 확인함
보안 정보 관리: AWS 액세스 키나 DB 정보가 담긴 yml 파일을 그대로 Git에 올릴 뻔한 위험이 있었음 (.gitignore 설정의 중요성)
@ManyToOne + @JoinColumn 은 거의 세트처럼 따라다니는 구조
부모가 변하면 자식도 같이 변해야 하는 관계라면 cascade, orphanRemoval 같은 옵션이 왜 필요한지 이해
@Enumerated(EnumType.STRING) 처럼 DB에 어떤 값이 저장될지까지 고려하는 설계가 필요하다는 점
DTO는 DB가 아니라 클라이언트와의 약속이라는 걸 느꼈다.
생성용 DTO (CreateDto) 에는 클라이언트가 보내는 값만 필요하고
조회용 DTO (ListDto, DetailDto) 에는 화면에 보여줄 값만 필요하다
아직 JPA의 Specification이나 pageing 처리 부분이 조금 낯설어 반복적인 숙달이 필요한 상태
주문시스템을 간단하게 구축하는 실습을 했지만, 상세주문목록 리스트에 대한 이해가 부족한 상태
중간 프로젝트 진행시 SNS 로그인 확장
현재 배운 로컬 로그인을 바탕으로 카카오, 네이버 등 OAuth2 로그인 기능을 추가해보기
리프레시 토큰(RT) 적용
현재는 엑세스 토큰만 사용 중인데, Redis를 활용해 리프레시 토큰 보안 체계를 강화하기
설정 파일 관리: ignore 처리로 환경 변수를 통해 보안 정보를 관리하는 습관 들이기