Spring 주니어 기술면접
새 면접Q. Spring에서 @Primary와 @Qualifier 어노테이션의 사용 목적과 차이점을 설명하고, 같은 타입의 Bean이 여러 개 존재할 때 주입 우선순위를 결정하는 방법을 설명해주세요.
@Primary는 같은 타입의 Bean이 여러 개일 때 기본으로 주입될 Bean을 지정하는 어노테이션입니다. @Qualifier는 주입받을 때 Bean의 이름을 명시하여 특정 Bean을 선택하는 어노테이션입니다. 우선순위는 @Qualifier가 @Primary보다 높으며, @Qualifier로 명시적으로 지정하면 @Primary 설정을 무시하고 해당 Bean이 주입됩니다. 일반적으로 @Primary는 기본 구현체를 지정할 때, @Qualifier는 특수한 상황에서 특정 구현체가 필요할 때 사용합니다.
- • @Primary는 기본 주입 대상을 지정하는 어노테이션
- • @Qualifier는 Bean 이름을 명시하여 특정 Bean을 선택
- • @Qualifier가 @Primary보다 우선순위가 높음
- • 같은 인터페이스의 여러 구현체가 있을 때 주입 충돌 해결
@Autowired를 사용할 때 같은 타입의 Bean이 여러 개 있는데 @Primary나 @Qualifier를 사용하지 않으면 어떤 예외가 발생하나요?
Q. JPA에서 연관관계의 주인(Owner)이 무엇인지 설명하고, 양방향 연관관계를 설정할 때 mappedBy 속성의 역할과 연관관계 주인을 결정하는 기준을 설명해주세요.
연관관계의 주인은 외래키를 관리하는 쪽을 의미하며, 실제 데이터베이스에 외래키가 있는 테이블에 매핑되는 엔티티가 주인이 됩니다. mappedBy 속성은 연관관계의 주인이 아닌 쪽에 사용하며, 주인 엔티티의 필드명을 값으로 지정합니다. 일반적으로 다대일(N:1) 관계에서 '다(N)' 쪽이 외래키를 가지므로 연관관계의 주인이 되며, 일대다(1:N) 관계에서 '일(1)' 쪽은 mappedBy를 사용하여 읽기 전용으로 설정합니다. 연관관계 주인만이 외래키를 등록, 수정, 삭제할 수 있습니다.
- • 연관관계 주인은 외래키를 실제로 관리하는 엔티티
- • mappedBy는 주인이 아닌 쪽에서 사용하며 읽기 전용
- • 외래키가 있는 테이블의 엔티티를 주인으로 설정
- • 주인만이 외래키를 등록, 수정, 삭제 가능
양방향 연관관계에서 연관관계 편의 메서드(Convenience Method)를 작성하는 이유와 작성 방법을 설명해주세요.
Q. Spring Boot의 자동 설정(Auto Configuration) 기능이 무엇인지 설명하고, @EnableAutoConfiguration 어노테이션의 역할과 특정 자동 설정을 제외하는 방법을 설명해주세요.
자동 설정은 Spring Boot가 클래스패스에 있는 라이브러리와 설정을 기반으로 필요한 Bean들을 자동으로 생성하고 구성해주는 기능입니다. @EnableAutoConfiguration은 spring.factories 파일에 정의된 설정 클래스들을 읽어 조건에 맞는 Bean들을 자동으로 등록합니다. 특정 자동 설정을 제외하려면 @SpringBootApplication이나 @EnableAutoConfiguration의 exclude 속성을 사용하거나, application.properties에서 spring.autoconfigure.exclude 속성을 설정하면 됩니다.
- • 클래스패스 기반으로 필요한 Bean을 자동 생성
- • @EnableAutoConfiguration이 자동 설정 활성화
- • exclude 속성으로 특정 자동 설정 제외 가능
- • 개발자가 별도 설정 없이 바로 사용 가능하도록 지원
@ConditionalOnClass, @ConditionalOnMissingBean 같은 조건부 어노테이션들이 자동 설정에서 어떤 역할을 하나요?
Q. 데이터베이스에서 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)의 차이점을 설명하고, JPA에서 각각을 구현하는 방법과 어떤 상황에서 사용하는 것이 적합한지 설명해주세요.
낙관적 락은 트랜잭션 충돌이 드물 것이라 가정하고 버전 정보를 통해 충돌을 감지하는 방식이며, 비관적 락은 충돌이 자주 발생할 것이라 가정하고 데이터에 실제 락을 거는 방식입니다. JPA에서 낙관적 락은 @Version 어노테이션을 사용하여 구현하고, 비관적 락은 EntityManager의 lock 메서드나 @Lock 어노테이션에 LockModeType.PESSIMISTIC_WRITE 등을 지정하여 구현합니다. 낙관적 락은 읽기가 많고 충돌이 적은 경우에, 비관적 락은 쓰기가 빈번하고 충돌이 많아 데이터 정합성이 중요한 경우에 적합합니다.
- • 낙관적 락은 버전 정보로 충돌 감지, 비관적 락은 실제 락 사용
- • 낙관적 락은 @Version, 비관적 락은 LockModeType 사용
- • 낙관적 락은 충돌 적은 환경, 비관적 락은 충돌 많은 환경에 적합
- • 성능과 데이터 정합성의 트레이드오프 고려 필요
낙관적 락을 사용할 때 OptimisticLockException이 발생하면 어떻게 처리해야 하나요?
Q. RESTful API에서 HTTP 상태 코드 200, 201, 204, 400, 404, 500의 의미를 설명하고, Spring에서 ResponseEntity를 사용하여 적절한 상태 코드를 반환하는 방법과 중요성을 설명해주세요.
200(OK)은 요청 성공, 201(Created)은 리소스 생성 성공, 204(No Content)는 성공했지만 응답 본문이 없음, 400(Bad Request)은 잘못된 요청, 404(Not Found)는 리소스를 찾을 수 없음, 500(Internal Server Error)은 서버 오류를 의미합니다. Spring에서는 ResponseEntity 클래스의 status 메서드나 ok(), created(), noContent() 같은 정적 메서드를 사용하여 상태 코드를 명시적으로 반환할 수 있습니다. 적절한 상태 코드 사용은 클라이언트가 요청 결과를 정확히 파악하고 적절한 후속 처리를 할 수 있도록 하며, API의 명확성과 표준 준수를 위해 중요합니다.
- • 2xx는 성공, 4xx는 클라이언트 오류, 5xx는 서버 오류
- • 201은 POST 요청 성공 시, 204는 DELETE 성공 시 주로 사용
- • ResponseEntity로 상태 코드와 응답 본문을 함께 반환
- • 명확한 상태 코드는 API 사용성과 디버깅을 향상
RESTful API에서 리소스 수정 시 PUT과 PATCH 메서드의 차이점과 각각 어떤 상태 코드를 반환해야 하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!