신입 개발자 면접 준비 - 스프링, JPA

❓ 스프링 프레임워크(Spring Framework)에 대해서 설명해주세요.

자바 개발을 편리하게 해주는 오픈소스 프레임워크를 말합니다.

IoC, DI, AOP를 지원하는 지원하는 경량의 컨테이너라고 할 수 있습니다.

 

❓ 제어의 역전(Ioc)에 대해서 설명해주세요.

컨트롤의 제어권이 사용자가 아닌 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출해서

애플리케이션의 느슨한 결합을 도모하는 것을 말합니다.

 

❓ 의존성과 의존성 주입(DI = Dependency Injection)에 대해서 설명해주세요.

한 객체가 다른 객체를 사용할 때 의존성이 있다고 할 수 있습니다.

필요한 객체를 직접 생성하는 것이 아닌 외부로부터 객체를 받아서 사용하는 것을 말합니다.

의존성 주입 방법에는 생성자 주입, 필드 주입, 세터 주입으로 3개가 있습니다.

이 중에서 spring이 가장 권장하는 의존성 주입 방법은 생성자 주입이라고 할 수 있습니다.

왜냐하면 순환 참조를 방지할 수 있고 final로 인해 객체는 불변성을 가지며 테스트에 용이하기 때문입니다.

 

필드 주입은 코드가 간결하지만 외부에서 변경하기 힘들다는 단점이 있고

세터 주입은 setXXX 메서드를 public으로 열어두어야하기 때문에 언제 어디서든 변경이 가능하다는 단점이 있습니다.

 

❓ 관점 지향 프로그래밍(AOP)에 대해서 설명해주세요.

트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우

해당 기능을 분리하여 관리할 수 있는 것을 말합니다.

핵심 비즈니스 로직에 부가 기능을 하는 모듈이 중복되어 분포되어 있을 경우 사용할 수 있습니다.

 

❓ Spring Boot와 Spring Framework의 차이점에 대해서 설명해주세요.

Spring은 프로젝트 초기에 다양한 환경설정을 해야하지만 Spring Boot는 설정의 많은 부분을 자동화하여

사용자가 편하게 Spring을 활용할 수 있도록 도와준다는 점에서 차이가 있습니다.

 

---

 

❓ @RequestBody, @RequestParam, @ModelAttribute에 대해서 설명해주세요.

- @RequestBody

클라이언트가 전송하는 JSON 형태의 HTTP Body 내용을 MessageConverter를 통해

Java Object로 변환시켜주는 역할을 합니다.

 

- @RequestParam

1개의 HTTP 요청 파라미터를 받기 위해서 사용하며 @RequestParam은 필수 여부가 true이므로

기본적으로 반드시 해당 파라미터가 전송되어야 합니다.

만약 반드시 필요한 변수가 아니라면 required의 값을 false로 설정해줘야 합니다.

 

- @ModelAttribute

HTTP Body 내용과 HTTP 파라미터의 값들을 생성자, Getter, Setter를 통해 주입하기 위해 사용합니다.

 

---

 

❓ 빈(Bean)에 대해서 설명해주세요.

스프링 IoC 컨테이너가 관리하는 객체들을 Bean이라고 부릅니다.

 

❓ Spring에서 빈(Bean)을 등록하는 방법에 대해서 설명해주세요.

1. @Component

@Component 어노테이션을 통해 개발자가 직접 작성한 클래스를 빈으로 등록해줄 수 있습니다.

@Controller, @Service, @Repository 모두 @Component를 포함하고 있으며

해당 어노테이션으로 등록된 클래스들은 스프링 컨테이너에 의해 자동으로 생성되어 스프링 빈으로

등록됩니다.

 

2. @Configuration

설정 클래스를 따로 만들어 @Configuration 어노테이션을 붙이고 해당 클래스 안에서 빈으로 등록할 메소드를

만들어 @Bean 어노테이션을 붙여주면 자동으로 해당 타입의 빈 객체가 생성됩니다.

 

❓ 등록된 스프링 빈을 어떻게 사용하는지 설명해주세요.

Spring Boot의 경우 @Component, @Service, @Controller, @Repository, @Bean, @Configuration

등으로 빈들을 등록하고 필요한 곳에서 @Autowired를 통해 의존성을 주입받아서 사용합니다.

 

의존성 주입 방법 3가지 : 생성자 주입, 필드 주입, 세터 주입

 

❓ 스프링 빈의 라이프 사이클은 어떻게 관리되는지 설명해주세요.

- 스프링 빈의 라이프 사이클

스프링 Ioc 컨테이너 생성→ 스프링 빈 생성 → 의존관계 주입 → 초기화 콜백 메소드 호출 →

사용 → 소멸 → 전 콜백 메소드 호출 → 스프링 종료

 

- 빈 생명주기 콜백 관리 방법

1. 인터페이스(InitializingBean, DisposableBean)를 사용합니다.

InitializingBean은 초기화를 지원하고 DisposableBean은 소멸을 지원합니다.

이때 2개의 인터페이스는 스프링 전용 인터페이스로 해당 코드가 인터페이스에 의존하고

초기화, 소멸 코드를 오버라이드하기 때문에 메소드명을 변경할 수 없다는 단점이 있습니다.

 

2. 설정 정보에 초기화 메소드와 종료 메소드를 지정합니다.

스프링 코드에 의존하지 않고 메소드명을 자유롭게 부여 가능하다는 장점이 있으나

Bean 지정시 initMethod와 destoryMethod를 직접 지정해야 하기 때문에 번거롭다는 단점이 있습니다.

 

3. @PostConstruct, @PreDestroy 어노테이션을 지원합니다.

어노테이션 하나만 붙이면 되므로 매우 편리하다는 장점이 있으나

커스터마이징이 불가능한 외부 라이브러리에서 적용이 불가능하다는 단점이 있습니다.

 

❓ BeanFactory와 ApplicationContext의 차이점에 대해서 설명해주세요.

- BeanFactory

BeanFactory는 Bean을 제공하고 관리하는 기본적인 IoC 컨테이너 인터페이스를 뜻합니다.

기본 구현은 getBean()이 호출될 때 빈을 인스턴스화합니다.

 

- ApplicationContext

ApplicationContext는 BeanFactory의 확장된 버전으로 애플리케이션에 대한

모든 정보, 메타 데이터를 가지고 있습니다. 기본 구현은 애플리케이션이 시작될 때 빈을 인스턴스화합니다.

 

❓ 스프링의 싱글톤 패턴에 대해서 설명해주세요.

스프링에서 빈 생성시 별다른 설정이 없으면 default로 싱글톤이 적용됩니다.

스프링은 컨테이너를 통해 직접 싱글톤 객체를 생성하고 관리하는데 요청이 들어올 때마다 매번 객체를

생성하지 않고 이미 만들어진 객체를 공유하기 때문에 효율적인 사용이 가능합니다.

이를 통해 static 메소드나 private 생성자 등을 사용하지 않아 객체지향적 개발을 할 수 있고

테스트하기 편리하다는 장점을 얻을 수 있습니다.

 

❓ 스프링의 스코프 프로토타입 빈에 대해서 설명해주세요

프로토타입 빈은 싱글톤 빈과는 달리 컨테이너에게 빈을 요청할 때마다 매번 새로운 객체를

생성하여 반환해줍니다.

빈의 스코프를 간단하게 관리해줄 수 있는 것이 스프링의 장점이라고 할 수 있는데

빈의 스코프 설정은 @Scope 어노테이션으로 설정하며

프로토타입 스코프를 설정하려면 @Scope("prototype")과 같이 문자열로 지정해줍니다.

 

---

 

❓ VO와 BO, DAO와 DTO에 대해서 설명해주세요.

- DAO

데이터베이스의 데이터에 접근하기 위한 객체를 말합니다. ex) Repository or Mapper

 

- BO

여러 DAO를 활용해 비즈니스 로직을 처리하는 객체를 말합니다. ex) Service

 

-  DTO

각 계층간의 데이터 교환을 위한 객체를 말합니다.

 

- VO

실제 데이터만을 저장하는 객체를 말합니다.

 

❓ @Controller와 @Service, @Repository에 대해서 설명해주세요.

서버에서 처리 과정을 역할별로 분리해둔 것을 말합니다.

 

- @Controller

클라이언트의 요청을 받고 View 반환합니다.

 

- @Service

비즈니스 로직을 처리합니다.

 

- @Repository

데이터베이스 관리 및 데이터베이스의 CRUD 작업을 합니다.

 

❓ Service와 ServiceImpl의 구조를 사용하는 이유에 대해서 설명해주세요.

- Service

주로 비즈니스 로직을 정의하는 인터페이스로 해당 비즈니스 로직이 어떻게 구현되어야 하는지만 정의합니다.

 

- ServiceImpl

Service 인터페이스의 구현체로 실제로 비즈니스 로직을 구현합니다.

 

- 이유

1. 인터페이스와 구현 클래스를 분리하여 유지보수성이 향상됩니다.

2. 시스템의 변경 또는 확장에 있어서 유용합니다.

3. Service 인터페이스를 통해 비즈니스 로직이 정의되면 이 인터페이스의 메소드를 여러 위치에서 호출하여
   코드를 재사용할 수 있습니다.

 

---

 

❓ Spring MVC와  MVC 패턴의 실행 흐름에 대해서 설명해주세요.

- Spring MVC

각 레이어간 기능을 구분하는데 중점을 둔 디자인 패턴입니다.

Model은 데이터 관리 및 비즈니스 로직을 처리하는 부분이며 ex) DAO, DTO, Service

View는 비즈니스 로직의 처리 결과를 통해 유저 인터페이스가 표현됩니다. ex) HTML. JSP, 타임리프 등

Controller는 사용자의 요청을 처리하고 Model과 View를 중개하는 역할을 합니다.

 

- MVC 패턴의 실행 흐름

출처) https://dev-coco.tistory.com/163

1. 클라이언트는 URL을 통해 요청을 전송합니다.

2. 디스패처 서블릿은 핸들러 매핑을 통해 해당 요청이 어느 컨트롤러에게 온 요청인지 찾습니다.

3. 디스패처 서블릿은 핸들러 어댑터에게 요청의 전달을 맡깁니다.

4. 핸들러 어댑터는 해당 컨트롤러에게 요청을 전달합니다.

5. 컨트롤러는 비즈니스 로직을 처리한 후 반환할 뷰의 이름을 반환합니다.

6. 디스패처 서블릿은 뷰 리졸버를 통해 반환할 뷰를 찾습니다.

7. 디스패처 서블릿은 컨트롤러에서 뷰에 전달할 데이터를 추가합니다.

8. 데이터가 추가된 뷰를 반환합니다.

 

DispatcherServlet 

클라이언트에게 요청을 받아 응답까지의 MVC 처리 과정을 통제하는 역할을 합니다.

 

HandlerMapping 

클라이언트의 요청 URL을 어떤 Controller가 처리할지 결정하는 것을 말합니다.

 

HandlerAdapter 

HandlerMapping에서 결정된 핸들러 정보로 해당 메소드를 직접 호출해주는 역할을 합니다.

 

ViewResolver 

Controller의 처리 결과를 생성할 View를 결정하는 역할을 합니다.

 

---

 

❓ Spring Filter와 Interceptor에 대해서 설명해주세요.

- 필터

말 그대로 요청과 응답을 거른 뒤 정제하는 역할을 합니다.

스프링 컨테이너가 아닌 톰캣과 같은 웹 컨테이너에 의해 관리가 되고

디스패처 서블릿에 요청이 전달되기 전/후에 URL 패턴에 맞는 모든 요청에 대해

부가 작업을 처리할 수 있는 기능을 제공합니다.

보안 관련, 모든 요청에 대한 로깅 또는 검사, 이미지/데이터 압축 및 문자열을 인코딩하는데 사용됩니다.

 

- 인터셉터

요청에 대한 작업 전/후로 가로채 요청과 응답을 참조하거나 가공하는 역할을 합니다.

웹 컨테이너에서 동작하는 필터와 달리 인터셉터는 스프링 컨텍스트에서 동작합니다.

디스패처 서블릿이 컨트롤러를 호출하기 전/후에 인터셉터가 끼어들어 요청과 응답을 참조하거나

가공할 수 있는 기능을 제공합니다.

인증/인가와 같은 공통 작업과 API 호출에 대한 로깅 또는 검사, 컨트롤러로 넘겨주는 정보를 가공하는데

사용됩니다.

 

---

 

❓ @Transactional의 동작 원리에 대해서 설명해주세요.

@Transactional을 메소드 또는 클래스에 명시하면 AOP를 통해 Target이 상속하고 있는 인터페이스 또는

Target 객체를 상속한 Proxy 객체가 생성되며 Proxy 객체의 메소드를 호출하면

Target 메소드 전/후로 트랜잭션 처리를 수행합니다.

 

❓ @Transactional을 스프링 빈의 메소드 A에 적용했고, 해당 빈의 메소드 B가 호출되었을 때
      B 메소드 내부애서 A 메소드를 호출하면 어떤 요청 흐름이 발생하는지 설명해주세요.

Proxy는 클라이언트가 Target 객체를 호출하는 과정에만 동작하며

Target 객체의 메소드가 자기 자기 자신의 다른 메소드를 호출할 때는 Proxy가 동작하지 않습니다.

즉, A 메소드는 Proxy로 감싸진 메소드가 아니므로 트랜잭션이 적용되지 않은 일반 코드가 수행됩니다.

 

❓ A라는 Service 객체의 메소드가 존재하고 그 메소드 내부에서 로컬 트랜잭션 3개
     (다른 Service 객체의 트랜잭션 메소드를 호출했다는 의미)가 존재한다고 할 때,
     @Transactional을 A 메소드에 적용하면 어떤 요청 흐름이 발생하는지 설명해주세요.

트랜잭션 전파 수준에 따라 달라지는데 만약 기본 옵션인 Required를 가져간다면 로컬 트랜잭션 3개가 모두

부모 트랜잭션인 A에 합류하여 수행됩니다.

그래서 부모 트랜잭션이나 로컬 트랜잭션 3개나 모두 같은 트랜잭션이므로 어느 하나의 로직에서 문제가
발생한다면 전부 롤백이 됩니다.

 

---

 

❓ JPA와 MyBatis 그리고 ORM에 대해서 설명해주세요.

- JPA

자바 진영에서 ORM 기술에 대한 API 표준 명세를 말합니다.

데이터베이스와 객체 간의 매핑을 자동으로 처리합니다.

⇒ JPA를 사용함으로써 객체지향적인 프로그래밍 모델을 유지하며 데이터베이스와 효과적으로 상호작용을
할 수 있고 유지보수 용이성, 트랜잭션 관리 등을 통해 개발 생산성과 코드 품질을 향상시킬 수 있습니다.

 

- MyBatis

자바 언어를 위한 오픈 소스 ORM 프레임워크로 SQL 매핑을 사용하여 데이터베이스와 상호작용하는 것을 말합니다.

개발자가 SQL 쿼리를 직접 작성하고 매핑을 수동으로 처리해야 합니다.

 

- ORM

자바의 객체와 데이터베이스를 연결하는 프로그래밍 기법을 말합니다.

ex) 데이터베이스에 name 컬럼에 홍길동이라는 값이 들어있다면 자바에서는 어떻게 사용할까요?

      → SQL문을 사용합니다.

      하지만 SQL문을 새로 공부해야해서 힘들기 때문에 ORM을 통해 SQL을 전혀 몰라도 자바 언어로만
      데이터베이스에 접근해서 원하는 데이터를 받아올 수 있습니다.

⇒ 즉, 객체와 데이터베이스를 연결해 자바 언어로만 데이터베이스를 다룰 수 있게하는 도구를
     ORM이라고 합니다.

 

❓ JPA N + 1 문제가 발생하는 이유와 해결하는 방법에 대해서 설명해주세요.

N+1이란 1번의 쿼리를 날렸을 때 의도하지 않은 N번의 쿼리가 추가적으로 실행되는 것을 의미합니다.

 

N+1 문제가 발생하는 이유는 연관 관계를 가진 엔티티를 조회할 때 한 쪽 테이블만 조회하고

연결된 다른 테이블은 따로 조회하기 때문에 발생합니다.

 

미리 두 테이블을 JOIN하여 한번에 모든 데이터를 가져오는 1. Fetch Join을 사용하면 해결할 수 있습니다.

두 테이블을 JOIN하는 쿼리를 JPQL로 직접 지정해주면 됩니다.

하지만 Fetch Join은 쿼리 한번에 모든 데이터를 가져오기 때문에 JPA가 제공하는 Paging API를
사용할 수 없으며 번거롭게 쿼리문을 작성해야한다는 단점이 있습니다.

 

또 다른 방법으로는 2. @Entity Graph가 있습니다. 이는 패치 조인과 동일하게 JPQL을 사용해

쿼리문을 작성하고 필요한 연관 관계를 EntityGraph에 설정하면 됩니다.

 

❓ 영속성 컨텍스트 및 장점에 대해서 설명해주세요.

엔티티를 영구 저장하는 환경으로 애플리케이션과 데이터베이스 사이에서 객체를 보관하는
가상의 환경을 말합니다.

1차 캐시에 이미 있는 엔티티이면 그대로 반환하기 때문에 여러 번 조회했을 때 동일성을 보장하고

똑같은 것을 2번 조회하는 경우에 처음 조회할 때의 해당 데이터를 1차 캐시에 올려 두 번째 조회 시에는

쿼리문을 수행하지 않고 캐시에서 가져옴으로써 생산성을 높혀준다는 장점이 있습니다.

 

❓ REST API와 RESTful API에 대해서 설명해주세요.

REST API는 REST 아키텍처 원칙을 따르는 API를 의미합니다.

자원을 URI로 표현하고 HTTP 메서드를 사용하여 이러한 자원에 대한 상태를 조작하는 것을 중심으로 합니다.

RESTful API는 REST 원칙을 보다 엄격하게 준수하고 있는 구현을 나타냅니다.

REST 설계 규칙을 URI는 정보의 자원만 표현해야 하며

자원의 상태와 행위는 HTTP Method에 명시하는 것을 말합니다.

 

 

 

참고 출처

https://dev-coco.tistory.com/163

신입 개발자 기술면접 질문 정리 - 백엔드

https://cano721.tistory.com/185

백엔드 신입 면접질문 공부(스프링 Spring & JPA)