Spring Boot 확인

문항 9개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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