[내일배움캠프 사전캠프] 15회차 TIL(7/10 금)

각종 개념 정리

POJO란?

• 순수 자바 문법만으로 만든, 프레임워크에 종속되지 않은 객체

Spring 3대 핵심 (IoC/DI, AOP, PSA) 

• IoC: 개발자가 직접 객체의 생명주기(생성, 소멸)를 관리하던 주도권을 Spring 컨테이너에게 통째로 넘겨버린 아키텍처 개념
• DI: IoC를 구현하는 구체적인 방법으로, 개발자가 코드에 new를 쓰지 않아도 Spring이 필요한 객체(Bean)를 딱 찾아서 알아서 조립(주입)해 주는 기술(결합도 낮아짐)

@RequiredArgsConstructor:롬복(Lombok) 라이브러리가 지원하는 기능으로, 스프링이 권장하는 생성자 주입(DI)을 가장 깔끔한 코드로 구현할 수 있게 돕는 도구

AOP: 관점 지향 프로그래밍(로그, 트랜잭션 처리, 보안 검사 등)

• @Transactional 이 대표적인 AOP이다. 트랜잭션 시작, 커밋, 롤백을 자동으로 실행해준다.

PSA: 기술 구현체가 달라도 똑같은 방식으로 쓰게 스프링이 감싸주는 것

---

브라우저(Client) request -> 톰캣(WAS) -> DispatcherServlet -> Controller -> 브라우저(Client) Response

톰캣(Tomcat) : 자바 서블릿을 실행하고 동적 웹 페이지를 생성할 수 있는 WAS (Web Application Server). 클라이언트 요청을 받아 서블릿 컨테이너에서 처리함.

DispatcherServlet: 스프링 MVC의 중심점으로, 모든 요청을 가장 먼저 받는 통로(Front Controller). URL을 분석하여 이 요청을 처리할 담당 컨트롤러를 찾아 요청을 위임(dispatch)함.

• 모든 요청을 가장 먼저 받아, 담당 컨트롤러를 찾아 연결.
• 동적(Dynamic) 웹 페이지 생성
• 클라이언트 요청 처리

멱등성 (Idempotency): 동일한 연산을 여러 번 수행해도 결과(서버의 상태)가 최초 1회 수행했을 때와 변함없이 동일하게 유지되는 성질 (예: GET, PUT, DELETE는 멱등함 / POST는 반복하면 데이터가 계속 생기므로 멱등하지 않음).

값의 출처 어노테이션 예시

URL 쿼리	@RequestParam	/members?page=2 → page=2
요청 본문(JSON)	@RequestBody	본문 JSON 전체 → 객체로 변환
URL 경로	@PathVariable	/members/1 → id=1

 

RESTful 하게 URI 설계하기 

메서드를 통해 어떤 행동을 할지 아니까 URL에는 /members 로 통일 

생성	POST / members
조회	GET / members /{id}
수정	PUT or PATCH /members /{id}
삭제	DELETE /members /{id}

 

HTTP 상태 코드

200(OK)	요청 성공
201(Created)	생성 성공
400(Bad Request)	클라이언트 요청이 잘못됨
404(Not Found)	자원을 못 찾음
500(Internal Server Error)	서버 내부 오류

 

Swagger: API 명세서를 수동으로 쓰지 않고 코드를 통해 웹 페이지 문서로 자동화해주는 툴.

---

오늘의 TIL

핵심 요약

• 권한 검증 구조 개선: 서비스 레이어의 등급 분기문을 @PreAuthorize로 이관하여 컨트롤러단에서 책임을 처리하도록 분리
• 조회 쿼리 최적화: 사용자를 조회하던 불필요한 userRepository.findById() 쿼리를 완전히 제거하고 식별자(userId)를 직접 활용하여 DB 부하 감소
• 의존성 다이어트: 사용하지 않는 UserRepository 의존성을 제거하여 도메인 간의 결합도를 낮춤

주요 배운 점

1. Spring Security @PreAuthorize를 통한 책임 분리

• 서비스 내부에서 비즈니스 로직과 권한 검증 로직이 뒤섞여 있던 구조를 개선
• @PreAuthorize를 활용해 정적 권한 검증 책임을 시큐리티 가드 레이어로 완전히 이관하여 서비스단이 순수 비즈니스 로직에만 집중할 수 있게 수정

2. 불필요한 SELECT 쿼리 제거

• 이미 인증 객체를 통해 유저 고유 식별자(Long userId)를 알고 있으므로, 엔티티 간 연관관계 매핑이 필수적인 상황이 아니라면 유저 엔티티를 통째로 조회할 필요가 없음을 깨달았습니다.
• 단순 대조나 Soft Delete 로그 기록 등 식별 값만 필요한 곳에서는 DB 조회 없이 매개변수를 바로 바인딩하도록 최적화했습니다.

교차 검증 테스트 결과

포스트맨을 활용해 등급별 JWT 토큰으로 API 접근 권한이 정확하게 제어되는지 확인했습니다.

• CUSTOMER 토큰: 배송지 추가 성공(200 OK) / 지역 생성 차단(403 Forbidden)
• MANAGER 토큰: 배송지 추가 차단(403 Forbidden) / 지역 생성 성공(200 OK)