Spring Boot Check

필드에 @Autowired 를 붙이면 잃는 것이 아닌 것은?

• 필드를 final 로 선언해 생성 후 바뀌지 않게 하는 것
• 테스트에서 리플렉션 없이 가짜 구현으로 갈아 끼우는 것
• 생성자 인자 수로 의존성이 몇 개인지 한눈에 보이는 것
• 컨테이너가 그 빈을 만들어 주입해 주는 것 자체

@NotBlank 를 붙였는데 검증이 안 걸린다면 가장 흔한 원인은?

• validation 스타터 의존성이 빠져 검증기가 아예 없는 경우
• 요청 객체를 record 로 만들어 애너테이션이 무시되는 경우
• 메서드 인자에 @Valid 를 붙이지 않아 검증이 시작되지 않는 경우
• Jackson 이 값을 채우기 전에 검증이 돌도록 설정된 경우

오류를 200 OK 본문에 담으면 안 되는 이유는?

• 본문을 끝까지 읽어야 실패를 알 수 있어 클라이언트 처리가 느려지기 때문
• 상태 코드는 계약이라 클라이언트·프록시·모니터링이 그걸 보고 동작하기 때문
• 오류 정보를 본문에 담으면 응답이 커져 대역폭을 낭비하기 때문
• 규격에 어긋나 일부 HTTP 클라이언트가 예외를 던지기 때문

@Transactional 메서드에서 체크 예외(IOException)를 던지면?

• 체크 예외도 예외이므로 트랜잭션이 롤백된다
• 예외가 프록시에서 삼켜져 호출한 쪽으로 전파되지 않는다
• 체크 예외를 던지는 메서드에는 붙일 수 없어 기동 때 오류가 난다
• 기본 설정으로는 롤백되지 않고 그대로 커밋된다

같은 클래스 안에서 this.otherMethod() 로 부른 @Transactional 메서드는?

• 프록시를 거치지 않아 트랜잭션이 안 걸리고 오류도 나지 않는다
• 같은 빈 안이라도 애너테이션이 적용되어 정상으로 트랜잭션이 걸린다
• 프록시를 우회했다는 것을 스프링이 감지해 예외를 던진다
• 전파 설정과 무관하게 항상 새 트랜잭션이 하나 더 열린다

가게 300개 목록에서 지연 로딩된 물품을 순회하면 쿼리가 몇 개?

• 301개 — 목록 1개 + 가게마다 1개
• 1개 — 조인으로 한 번에 가져온다
• 300개 — 가게마다 1개, 목록은 캐시된다
• 2개 — 목록 1개 + 물품 전체 1개

N+1 을 테스트로 막는 방법은?

• 실행 로그를 눈으로 훑어 같은 쿼리가 반복되는지 확인한다
• hibernate 통계를 켜고 실행된 쿼리 수를 테스트에서 단언한다
• APM 을 붙여 운영에서 쿼리 수가 튀는 것을 감시한다
• 지연 로딩 특성상 테스트로는 막을 수 없고 리뷰로 걸러야 한다

@WebMvcTest 에서 서비스 빈을 @MockitoBean 으로 넣어야 하는 이유는?

• 웹 층만 띄우므로 서비스 빈이 컨텍스트에 아예 없기 때문
• 실제 서비스를 쓰면 컨텍스트 로딩이 길어져 테스트가 느려지기 때문
• 실제 서비스가 트랜잭션을 열어 테스트 격리가 깨지기 때문
• 보안 설정이 함께 올라오면서 인증 없이는 호출이 막히기 때문

spring.jpa.open-in-view 를 끄면 생기는 일은?

• 영속성 컨텍스트를 매번 새로 열게 되어 조회 성능이 떨어진다
• 뷰 렌더링 구간이 트랜잭션 밖으로 나가 트랜잭션이 걸리지 않는다
• 숨어 있던 LazyInitializationException 이 드러난다
• 지연 로딩 프록시가 그대로 직렬화되어 JSON 변환이 깨진다