[면접총정리] 신입 개발자 인터뷰 대비 총정리 자료 - ⑦ 백엔드(Java Spring 기반)

🧑🏻‍💻 글을 시작하기에 앞서..

- 신입 개발자 인터뷰에서 자주 나오는 질문을 모아 한 번에 정리한 포스트입니다.
- 신입 개발자 기술면접을 준비하는 사람으로, 정확하지 않은 정보가 포함될 수 있습니다. 더 올바른 답을 알고 있다면 댓글로 남겨주시면 반영하도록 하겠습니다.
- 필자는 Java 기반의 백엔드 엔지니어를 목표로 하고 있습니다. 따라서 글 내부에 Java 혹은 백엔드 관련 용어가 나올 수 있습니다. Java를 사용하지 않는다면, 자신의 직무 언어 및 프레임워크 관점에서 문제를 해결해보는 것을 추천합니다.

 

 

🧑🏻‍💻 백엔드 면접 질문

💡 Spring 프레임워크가 무엇인지 설명해주세요.

스프링 프레임워크는 자바 플랫폼을 위한 오픈 소스 어플리케이션 프레임워크로 POJO 기반을 바탕으로, DI와 AOP, PSA를 지원하는 경량의 컨테이너를 제공하는 프레임워크를 의미합니다.

 

동적인 웹을 개발하기 위한 여러가지 서비스를 제공합니다.

 

 

💡 IoC(Inversion of Control, 제어의 역전)이 무엇인지 설명해주세요.

객체의 생성부터 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀐 것을 의미합니다.

정확히 설명하면, 디자인 원칙 중 하나로 클래스간의 결합도를 줄이기 위해 다양한 종류의 제어를 반전시킬 것을 권장하는 것을 의미합니다.

 

자세한 내용은 아래의 글 참고.

2022.10.10 - [🌱 백엔드 : Backend] - [Spring] 스프링의 핵심 개념, DI / IoC란 무엇인가? (의존성 주입, 제어의 역전)

[Spring] 스프링의 핵심 개념, DI / IoC란 무엇인가? (의존성 주입, 제어의 역전)

 

 

 

💡 DI(Dependency Injection, 의존관계 주입)가 무엇인지 설명해주세요.

IoC가 디자인 원칙이라면, DI는 IoC를 구현할 때 자주 등장하는 '디자인 패턴' 중 하나입니다. DI는 의존 관계 주입으로, 의존 객체를 직접 생성하는 것이 아니라, 생성자나 setter를 통해 넣어줌으로써 의존 관계를 주입하는 것을 의미합니다.

 

• 수정자 주입
  • 대부분 의존 관계 주입은 한번 일어나면 종료시점까지 변경할 일이 거의 없다.
  • Setter를 통해 주입하게 되면 변경될 위험이 존재
  • setter을 public으로 열어야함

• 생성자 주입
  • 생성자 주입을 권장
  • 생성자 호출 시점에 딱 1번만 호출되는 것을 보장
  • final 키워드를 통해 불변하게 설계 가능
  • 의존성 주입이 누락되는 것을 방지할 수 있음(IDE에서 컴파일 오류로 알려줌)

 

자세한 내용은 아래의 글 참고.

2022.10.10 - [🌱 백엔드 : Backend] - [Spring] 스프링의 핵심 개념, DI / IoC란 무엇인가? (의존성 주입, 제어의 역전)

[Spring] 스프링의 핵심 개념, DI / IoC란 무엇인가? (의존성 주입, 제어의 역전)

 

 

 

 

💡 Spring에서 IoC와 DI를 어떻게 지원해 주는지에 대해 설명해주세요.

스프링은 IoC와 DI를 DI(IoC) Container로써 제공합니다. 클래스 사이의 의존 관계를 Bean 설정 정보를 바탕으로 컨테이너가 자동으로 연결해주는 방식으로 제공합니다.

 

• 장점
  • 스프링 자체에서 설정을 통해 연관 관계를 맺어줌으로써 객체간 결합도를 낮춰준다.
  • 클래스의 재사용성을 높이고, 유지보수가 편리해진다.
  • 의존성 주입으로 인해 stub, mock 객체를 사용해 unit 테스트의 이점이 생긴다.
• 단점
  • 의존성 주입을 위한 선행 작업이 필요해 간단한 프로그램에서는 번거롭다.
  • 코드 추적이 어렵다.

 

DI 컨테이너는, 자바 객체의 생명 주기를 관리하며, 생성된 자바 객체들에게 추가적인 기능을 제공합니다.

종류는, BeanFactory와 ApplicationContext가 있습니다. ApplicationContext가 BeanFactory의 빈 관리 기능을 상속 받고 국제화 등의 추가기능을 갖고 있어 ApplicationContext를 사용합니다.

 

자세한 내용은 아래의 글 참고.

2022.10.10 - [🌱 백엔드 : Backend] - [Spring] 스프링의 핵심 개념, DI / IoC란 무엇인가? (의존성 주입, 제어의 역전)

[Spring] 스프링의 핵심 개념, DI / IoC란 무엇인가? (의존성 주입, 제어의 역전)

 

 

 

💡 Bean 객체와 Bean 생명주기에 대해 설명해주세요.

DI 컨테이너 내부에 존재하며 관리를 받고 있는 객체를 의미합니다. @Bean 어노테이션을 등록해 사용하거나, xml을 통해 등록할 수 있습니다. Bean으로 등록된 객체는 쉽게 주입하여 사용이 가능합니다.

 

Bean의 생명 주기는 다음과 같습니다.

스프링 컨테이너 생성 → 스프링 빈 생성 → 의존 관계 주입 → 초기화 콜백 → 사용 → 소멸 전 콜백 → 스프링 종료

• 스프링 컨테이너에 의해 생명주기 관리
• 스프링 컨테이너 초기화 시 빈 객체 생성, 의존 객체 주입 및 초기화
• 생성과 의존관계 주입과 초기화 분리
  • 의존관계 주입(생성자 주입)은 필수정보를 받고 메모리 할당을 통해 객채 생성 책임
  • 초기화는 생성된 값들을 활용해 외부 커넥션을 연결하는 등 무거운 작업 수행
  • 명확하게 분리하는 것이 유지보수 관점에서 좋다.
• 싱글톤 빈들은 컨테이너가 종료되기 직전에 소멸전 콜백이 발생

 

 

 

💡 Annotation에 대해 설명해주세요.

프로그램에게 추가적인 정보를 제공하는 메타데이터입니다. annotation을 정의하고, 원하는 위치에 배치한 후, 코드가 실행되는 도중 자바 리플렉션을 이용해 추가 정보를 획득해 기능을 실시하는 방식으로 동작됩니다.

 

Spring 컨테이너에서 객체가 호출되면, 객체의 인스턴스를 생성하게 되는데 이때 자바 리플렉션이 필요하게 됩니다.

 

 

💡 Spring에서 제공하는 대표적인 Annotation 몇 가지만 예를 들어주세요.

• @ComponentScan
  • @Component, @Service, @Repository, @Controller, @Configuration이 붙은 클래스 Bean들을 찾아서 Context에 bean을 등록해주는 애노테이션
  • 전부 다 @Component를 사용하지 않고 @Repository 등으로 분리해서 사용하는 이유는, 예를 들어 @Repository는 DAO에서 발생할 수 있는 unchecked exception들을 스프링의 DataAccessException으로 처리할 수 있기 때문이다.
  • 또한 가독성에서도 해당 애노테이션을 갖는 클래스가 무엇을 하는지 단 번에 알 수 있다.
• @EnableAutoConfiguration
  • autoConfiguration도 Configuration중 하나에 해당한다.
  • spring.factories 내부에 여러 Configuration들이 있고 조건에 따라 Bean이 등록되게 되는데 메인 클래스 @SpringBootApplication을 실행하면 @EnableAutoConfiguration에 의해 spring.factories 안에 있는 수많은 자동 설정들이 조건에 따라 적용되어 수 많은 Bean들이 생성된다.
  • 간단하게 정리하면, Application Context를 만들 때 자동으로 빈설정이 되도록 하는 기능이다.
• @Component
  • 개발자가 직접 작성한 class를 Bean으로 등록하기 위한 애노테이션
• @Bean
  • 개발자가 직접 제어가 불가능한 외부 라이브러리등을 bean으로 만들려할 때 사용되는 애노테이션
• @Configuration
  • @Configuration을 클래스에 적용하고 @Bean을 해당 class의 메서드에 적용하면 @autowired로 Bean을 부를 수 있다.
• @Autowired
  • 스프링이 Type에 따라 알아서 Bean을 주입해준다.
  • Type을 먼저 확인한 후 못 찾으면 Name에 따라 주입한다.
  • 강제로 주입하고자 하는 경우 @Qulifier을 같이 명시
• @Qualifier
  • 같은 타입의 빈이 두 개 이상 존재하는 경우 스프링이 어떤 빈을 주입해야할 지 알 수 없어서 스프링 컨테이너를 초기화하는 과정에서 예외가 발생한다.
  • @Qualifier는 @Autowired와 함께 사용하여 정확히 어떤 bean을 사용할지 지정하여 특정 의존 객체를 주입할 수 있다.
• @Resource
  • @Autowired와 마찬가지로 Bean 객체를 주입해주는데 차이점은 Autowired는 타입으로, Resource는 이름으로 연결해준다.
  • 애노테이션 사용으로 인해 특정 Framework에 종속적인 애플리케이션을 구성하지 않기 위해서 @Resource 사용을 권장한다.
• @Controller
  • API와 view를 동시에 사용하는 경우에 사용
  • 보통 view 화면 return을 목적으로 사용한다.
• @RestController
  • view가 필요 없이 API만 지원하는 서비스에서 사용
• @SpringBootApplication
  • @Configuration, @EnableAutoConfiguration, @ComponentScan 3가지를 하나로 합친 애노테이션

 

 

💡 웹 서버와 웹 애플리케이션 서버가 어떻게 다른지 알고 계시나요?

• 웹 서버
  • 정적 리소스 파일을 제공하는 서버
• 웹 애플리케이션 서버(WAS)
  • 웹 서버가 하는 일 + 애플리케이션 로직(DB 연결, 동작 수행, 데이터 제공)까지 제공하여 동적인 처리를 하는 서버
  • 자바 진영에서는 서블릿 컨테이너 기능을 제공하면 WAS 라고 한다.
  • 위 그림에는 없지만 WAS 안에도 웹 서버가 따로 존재한다.

 

 

💡 서블릿과 서블릿 컨테이너에 대해서 설명해주세요.

 

웹 서버와 웹 애플리케이션 서버의 차이를 보면, '동적인 처리'에 대한 차이가 있습니다. WAS안에서 이러한 동적인 처리를 하는데 사용하는 서버 프로그램을 서블릿이라고 합니다. 서블릿이 존재하기 전에는 HTTP 요청 메시지를 파싱하는 작업 등 여러 부가적인 작업을 개발자가 해야 하나, 서블릿의 등장이후로는 이러한 부가 작업을 서블릿이 대신 하고, 개발자는 실질적인 메인 로직만 집중할 수 있게 되었습니다.

 

DI Container와 비슷하게, 서블릿 컨테이너는 서블릿의 생명주기를 관리합니다.

1. 사용자가 URL을 클릭하면 HTTP Request를 Servlet Container로 보낸다.
2. Servlet Container는 쓰레드 풀에서 쓰레드를 꺼내 할당 해주고 HttpServletRequest, HttpServletResponse 두 객체를 생성한다.
3. 사용자가 요청한 URL을 분석하여 어느 서블릿에 대한 요청인지 찾는다.
4. 서블릿 컨테이너에 존재하지 않으면 초기화하고 있다면 가져와서 service() 메서드를 호출한다.
   • Spring MVC의 경우 DispatcherServlet이 초기화되고 호출된다.
5. service 메서드가 수행이 끝나면 HttpServletResponse 객체에 응답을 보낸다.
6. 응답이 완료되면 HttpServletRequest, HttpServletResponse 객체를 소멸시킨다.

 

 

💡 Spring MVC에 대해 설명해주세요.

Spring에서 제공하는 웹 모듈로, Model / View / Controller 세 가지 구성요소를 사용해 사용자의 다양한 HTTP Request를 처리하고 단순한 텍스트 형식의 응답부터 REST 형식의 응답은 물론, View를 표시하는 HTML을 Retrun하는 응답까지 다양한 응답을 할 수 있도록 도와주는 Framework입니다.

 

 

1. 핸들러 조회
   • 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회한다.
2. 핸들러 어댑터 조회
   • 핸들러를 실행할 수 있는 핸들러 어댑터를 조회한다.
3. 핸들러 어댑터 실행
   • 조회한 핸들러(컨트롤러)를 인자로 핸들러 어댑터에 넘겨서 핸들러를 실행시킨다.
4. ModelAndView 반환
   • 핸들러(컨트롤러)가 로직을 수행하고 반환하는 정보로 ModelAndView로 변환해서 반환한다.
5. viewResolver 호출
   • 적절한 viewResolver를 찾고 해당 viewResolver를 호출한다.
   • RestController라면 이 과정과 이후 과정 없이 컨버터를 이용해 바로 결과값을 리턴한다.
6. View 반환
   • viewResolver는 뷰의 논리 이름을 물리 이름으로 바꾸고, 랜더링 역할을 담당하는 뷰 객체를 반환한다.
7. 뷰 랜더링
   • 뷰를 통해서 뷰를 랜더링한다.

 

MVC 패턴 장단점

• 정의
  • Model, View, Controller로 분리하는 아키텍처
• 장점
  • 과거에는 Controller에 다 담아두고 처리했다.
  • 기능 별로 코드를 분리하여, 가독성을 높이고 재사용성을 증가시킨다.
• 단점
  • view와 model 사이에 의존성이 높아서 애플리케이션이 커질수록 복잡해지고 유지보수가 어렵다.
  • 대규모의 프로그램에서 Controller에 다수의 Model과 View가 복잡하게 연결되어 코드 분석과 테스트가 어려워 질 수 있다.
  • 이런 의존성 문제를 해결하기 위해 MVVM, MVP 구조가 등장했다.

 

 

💡 그렇다면, 어떻게 하나의 컨트롤러로 여러 요청을 받을 수 있을까요?

컨트롤러는 컴포넌트 스캔이 되면서 스프링 빈 컨테이너에 올라갑니다. 또한 빈 객체는 싱글톤 패턴으로 구현되어있기 때문에 여러 쓰레드의 요청이 들어와도 하나의 컨트롤러 객체를 공유하면서 처리합니다. 즉, 여러 쓰레드가 메서드에 대해 공유 자원으로써 접근해 사용합니다.

 

주의할 점은, 싱글톤 패턴으로 구현되어있다는 점은, Thread-Safe하지 않다는 의미이므로, 상태를 공유하거나 저장하는 코드가 없도록 Stateless하게 정의해야 합니다.

 

 

💡 + 그럼 싱글톤 패턴은 무엇인가요?

컨트롤러는 컴포넌트 스캔이 되면서 스프링 빈 컨테이너에 올라갑니다. 또한 빈 객체는 싱글톤 패턴으로 구현되어있기 때문에 여러 쓰레드의 요청이 들어와도 하나의 컨트롤러 객체를 공유하면서 처리합니다. 즉, 여러 쓰레드가 메서드에 대해 공유 자원으로써 접근해 사용합니다.

 

public class Singleton {

    private static Singleton instance = new Singleton();
    
    private Singleton() {
        // 생성자는 외부에서 호출못하게 private 으로 지정해야 한다.
    }

    public static Singleton getInstance() {
        return instance;
    }

    public void say() {
        System.out.println("hi, there");
    }
}

 

메모리 측면에서 최초 한 번의 new 연산자를 통해 고정된 메모리 영역을 사용하기 때문에 해당 객체에 접근할 때 메모리 낭비를 방지할 수 있고, 이미 생성된 인스턴스를 활용하니 속도 측면에도 이점이 있습니다.

다른 이점으로는 다른 클래스 간에 데이터 공유가 쉽습니다. 싱글톤 인스턴스는 전역으로 사용되는 인스턴스이기 때문에 다른 클래스의 인스턴스들이 접근해 사용할 수 있습니다. 그렇기 때문에 '동시성 문제'가 일어나지 않도록 유의해 설계해야 합니다.

 

다시 말하자면, 싱글톤 패턴으로 구현되어있다는 점은, Thread-Safe하지 않다는 의미이므로, 상태를 공유하거나 저장하는 코드가 없도록 Stateless하게 정의해야 합니다.

 

 

 

💡 AOP에 대해 설명해주세요.

관점 지향 프로그래밍의 약어로, 공통 관심사항과 핵심 관심사항을 분리하는 것을 의미합니다. 각 소스코드에서 여러 번 반복해서 사용하는 코드를 흩어진 관심사라고 부르고, 이것을 Aspect로 모듈화해 핵심 로직에서 분리해 재사용하는 것이라고 볼 수 있습니다.

 

예를 들어, 로그, 성능테스트, 권한, 트랜잭션 등을 모든 메소드에 적용하고 싶을 때 일일히 추가하는 것이 아니라 AOP를 활용해 적용할 수 있다는 것입니다.

 

 

💡 POJO란 무엇인가요?

Plain Old Java Object의 약어로, 평범한 구식 자바 객체를 의미합니다. 프레임워크 인터페이스나 클래스를 구현하거나 확장하지 않은 단순한 클래스를 의미하는 것으로, 타 프레임워크에 종속되지 않아 코드가 간결하고 테스트 자동화에 유리합니다. Spring에서는 도메인과 비즈니스 로직을 수행하는 대상이 POJO 대상이 될 수 있습니다.

 

 

💡 DAO, DTO, BO, VO의 차이를 알고 계시나요? 아는대로 설명해주세요.

- DAO (Data Access Object)

• DB 데이터를 조회하거나 조작하는 기능을 전담하는 객체
• DB 접근 로직과 비즈니스 로직을 분리하기 위해서 사용

- DTO (Data Transfer Object)

• 계층간의 데이터 교환을 위한 객체
• 로직을 갖지 않는 순수 데이터 객체로 getter, setter만 포함

- VO (Value Object)

• DTO와 동일한 개념
• Read Only로 수정 불가
• getter, setter 이외의 추가 로직 포함 가능

- BO (Business Object)

• 비즈니스 로직을 포함하는 오브젝트로, 여러 DAO를 사용해 데이터를 처리
  •  

 

 

💡 Spring의 레이어드 아키텍처에 대해 설명해주세요.

 

Spring은 레이어드 아키텍처로 이루어져 있습니다.
하나의 레이어는 자신의 고유 역할을 수행하고, 인접한 다른 레이어에 무언가를 요청하거나 응답합니다.
그 밖의 다른 레이어는 신경 쓸 필요가 없기 때문에 각 레이어는 자신의 역할에 충실할 수 있습니다.
따라서 시스템 전체를 수정하지 않고 특정한 레이어의 기능을 개선하거나 교체할 수 있기 때문에 재사용성이 좋고 유지 보수에도 유리합니다. 또한, 레이어별로 테스트 구현이 편해지고 코드 가독성도 높아집니다.

• Presentation Layer
  • view를 담당하는 부분으로, 클라이언트와 직접적으로 맞닿는 부분
• Application Layer
  • 비즈니스 핵심 로직을 처리하는 부분
  • Service 객체라는 것은 하나의 트랜잭션으로 구성되어 작동
• Persistence Layer
  • 데이터 관련 처리를 담당하는 부분

 

 

💡 커넥션 풀이 무엇인지, Springboot에서의 커넥션 풀로는 어떤 것을 사용하는지 설명해주세요.

어플리케이션이 DB를 사용하기 위해서는 Connection이 필요한데, 이 생성 및 소멸 비용이 크기 때문에, 커넥션 풀을 미리 생성하고 애플리케이션이 시작하는 시점에 커넥션을 미리 다 생성하고 이것을 재활용하며 사용하게 됩니다.

 

Springboot 2.0 이후 부터는 hikariCP를 기본 CP로 사용합니다.

 

 

💡 그렇다면 DataSource는 무엇인가요?

Connection 관련 기술이 많아지면서, 코드레벨에서는 다르지만 논리적으로는 커넥션을 획득하는 역할을 하기 때문에 이를 추상화 시킨 것을 DataSource라 합니다.

 

실질적인 로직을 DataSource에 의존하도록 하고, 구현 기술이 바뀌면 DataSource의 구현체만 바꾸면 되므로, 재사용성과 확장성을 높일 수 있습니다.

 

 

💡 트랜잭션을 추상화해서 사용하는 이유를 알고 계시나요?

다양한 데이터 접근 기술이 등장하면서, 코드레벨에서는 다르지만 논리적으로는 같은 기능을 수행하기 때문에 트랜잭션을 추상화했습니다. 다양한 접근 기술로는 JDBC, JPA, 하이버네이트 등이 있습니다.

 

 

💡 트랜잭션 동기화 매니저의 역할에 대해 안다면, 아는대로 설명해주세요.

보통 서비스 단에서 트랜잭션을 시작하고 끝내게 됩니다.
그렇다면 하나의 트랜잭션 내에서는 같은 커넥션을 사용 해야 하는데 과정이 다음과 같습니다.

1. 서비스단에서 트랜잭션이 시작하면 트랜잭션 매니저가 커넥션을 생성하고(풀을 사용하면 풀에서 가져오고) autoCommit을 false로 세팅한 뒤 트랜잭션 동기화 매니저의 스레드 로컬에 커넥션을 보관
2. 이후 리포지토리 계층에서는 트랜잭션 동기화 매니저의 스레드 로컬에서 해당 커넥션을 가져와서 사용
3. 서비스 단에서 트랜잭션을 종료할 때는 트랜잭션 동기화 매니저에서 해당 커넥션을 가져와 커밋 또는 롤백을 수행하고 리소스를 정리하고 커넥션을 커넥션 풀에 반환

하나의 트랜잭션에서 같은 커넥션을 사용하도록 도움을 주는 기능을 제공한다고 보면 됩니다.

 

 

💡 Spring을 사용해 트랜잭션을 적용하는 방법 2가지에 대해 설명해주세요.

1) 선언적 트랜잭션

@Transactional 어노테이션을 사용함으로써 트랜잭션을 적용시킬 수 있습니다. 추가적인 코드 작성이 없어 대부분 사용하는 방식입니다.

@Transactional 어노테이션은 AOP로 구성되어 있습니다. AOP는 프록시 패턴으로 동작하기 때문에, 오버라이딩 개념으로 동작합니다. 메서드에 @Transactional을 붙이면, 해당 클래스가 빈으로 등록될 때, @Transactional이 붙은 메소드만 트랜잭션 처리되는 메소드로 오버라이딩 한 프록시 객체가 빈으로 등록되게 됩니다.

 

2) 프로그래밍 방식 트랜잭션

트랜잭션 매니저나 트랜잭션 템플릿을 사용해 프로그래밍 코드로 작성해 적용하는 방식입니다.

 

 

💡 JDBC, Spring JDBC, MyBatis, ORM, JPA, Hibernate, Spring Data JPA에 대해 각각 설명해주세요.

업데이트 예정.

 

 

💡 영속성 컨텍스트는 무엇인가요?

업데이트 예정.

 

 

💡 JPA N+1 문제에 대해 알고 계신가요? 문제와 해결 방법에 대해 설명해주세요.

업데이트 예정.

 

 

💡 객체간의 상속관계를 DB에 적용시키기 위해서는 어떻게 해야 할까요?

업데이트 예정.

 

 

💡 Spring Batch에 대해 설명해주세요.

단발성으로 대용량 데이터를 처리하는 애플리케이션을 Batch Application이라고 부르며, Spring에는 SpringBatch가 있습니다.

 

위와 같은 일 매출 집계를 Spring MVC에서 한다면, 많은 요청이 한 번에 들어와 CPU, I/O 등의 자원을 다 써버려 다른 Request 처리를 할 수 없게 됩니다. 따라서 단발성의 대용량 데이터를 처리하는 어플리케이션을 따로 구성할 수 있게 해줍니다.

 

BatchApplication의 배치 기능을 활성화 하고 싶다면, main 메소드가 포함된 클래스에 @EnableBatchProcessing을 추가해줍니다.

 

 

💡 Spring Batch의 Chunk와 Chunk 기반 방식에 대해 설명해주세요.

Spring Batch에서 Chunk란, 데이터 덩어리로 작업 시 각 커밋 사이에 처리되는 row 수를 이야기합니다.

Chunk 기반 방식(Chunk 지향 처리)이란 한 번에 하나씩 데이터를 읽어 Chunk라는 덩어리를 만든 뒤 Chunk 단위로 트랜잭션을 다루는 것을 의미합니다.

 

트랜잭션이므로, 실패할 경우에 Chunk 만큼만 롤백이 되고, 이전에 커밋된 범위까지는 반영됩니다.

• itemReader, itemProcessor, itemWriter로 구성된다.
  • itemReader
    • Custor 기반 처리
      • 데이터를 호출하면 다음 커서로 이동하는 스트리밍 방식으로 데이터를 한 건씩 처리
      • 모든 결과를 메모리에 할당하기 때문에 메모리 사용량 증가
      • 모든 데이터를 처리할 때까지 커넥션 유지
      • 멀티스레드 환경에서 동시성 이슈 발생하므로 동기화 처리가 필요
    • 페이징 기반 처리
      • 페이지 사이즈 만큼 데이터를 한 번에 처리
      • 페이지 사이즈 만큼 커넥션을 맺고 끊음
      • 페이징 결과만 메모리에 할당
      • 멀티 스레드 환경에서 스레드 안정성을 보장하기에 별도 동기화 처리 불필요
    • 페이지 사이즈와 청크 사이즈를 일치시켜야 하는 이유
      • 청크 사이즈가 50이고 페이지 사이즈가 10이면 5번의 read가 발생하면서 한 번의 트랜잭션 처리를 위해서 5번의 조회 쿼리를 날리는 성능 이슈가 발생할 수 있다.
      • JPA를 사용하는 경우 영속성 컨텍스트가 깨지는 문제가 발생한다. JpaPagingItemReader의 경우 페이지를 읽을때, 이전 트랜잭션을 flush, clear로 초기화 시켜버린다. 그러다 보니 마지막에 읽은 페이지를 제외한 이전에 조회한 결과들의 트랜잭션 세션이 전부 종료되어 버리면서 processor에서 Lazy 로딩이 불가능하게 되는 현상이 발생한다.
  • itemWriter
    • jpaItemWriter
      • JPA 엔티티 기반으로 데이터를 처리하고 엔티티를 하나씩 insert한다.
    • JdbcBatchItemWriter
      • Jpa처럼 단건 처리가 아닌 일괄 bulk insert 처리한다.
    • ChunkSize 만큼 데이터를 커밋하기 때문에 Chunk size가 곧 Commit Interval(커밋 간격)이 된다.
• chunkSize 만큼 데이터를 한 번에 처리하고 다음 chunkSize는 새로운 트랜잭션으로 동작한다.
• repeat, retry, skip을 통해서 반복 및 오류 제어를 할 수 있다.

 

 

💡 Spring Batch의 Job과 Step의 구조에 대해 설명해주세요.

@Slf4j // log 사용을 위한 lombok 어노테이션
@RequiredArgsConstructor // 생성자 DI를 위한 lombok 어노테이션
@Configuration
public class SimpleJobConfiguration {
    private final JobBuilderFactory jobBuilderFactory; // 생성자 DI 받음
    private final StepBuilderFactory stepBuilderFactory; // 생성자 DI 받음

    @Bean
    public Job simpleJob() {
        return jobBuilderFactory.get("simpleJob")
                .start(simpleStep1())
                .build();
    }

    @Bean
    public Step simpleStep1() {
        return stepBuilderFactory.get("simpleStep1")
                .tasklet((contribution, chunkContext) -> {
                    log.info(">>>>> This is Step1");
                    return RepeatStatus.FINISHED;
                })
                .build();
    }
}

• @Configuration
  • Spring Batch의 모든 Job은 @Configuration으로 등록해서 사용합니다.
• jobBuilderFactory.get("simpleJob")
  • simpleJob 이란 이름의 Batch Job을 생성합니다.
  • job의 이름은 별도로 지정하지 않고, 이렇게 Builder를 통해 지정합니다.
• stepBuilderFactory.get("simpleStep1")
  • simpleStep1 이란 이름의 Batch Step을 생성합니다.
  • jobBuilderFactory.get("simpleJob")와 마찬가지로 Builder를 통해 이름을 지정합니다.
• .tasklet((contribution, chunkContext))
  • Step 안에서 수행될 기능들을 명시합니다.
  • Tasklet은 Step안에서 단일로 수행될 커스텀한 기능들을 선언할때 사용합니다.
  • 여기서는 Batch가 수행되면 log.info(">>>>> This is Step1") 가 출력되도록 합니다.

 

Job은 하나의 배치 작업 단위를 말하고, Job 안에는 여러 Step이 존재하고, Step 내에 Tasklet, Reader & Writer 묶음이 존재합니다.

 

Tasklet 하나와 Reader & Processor & Writer 한 묶음이 같은 레벨입니다.
그래서 Reader & Processor가 끝나고 Tasklet으로 마무리 짓는 등으로 만들순 없다는걸 꼭 명심해주셔야 합니다.

Tasklet은 어찌보면 Spring MVC의 @Component, @Bean과 비슷한 역할이라고 보셔도 될 것 같습니다.
명확한 역할은 없지만, 개발자가 지정한 커스텀한 기능을 위한 단위로 보시면 됩니다.

 

 

 

🏃‍♂️ 다른 질문 대비 자료

[📝 신입 인터뷰 준비] - [면접총정리] 신입 개발자 인터뷰 대비 체크리스트 - ⓪ 체크리스트

[📝 신입 인터뷰 준비] - [면접총정리] 신입 개발자 인터뷰 대비 총정리 자료 - ① 자료구조
[📝 신입 인터뷰 준비] - [면접총정리] 신입 개발자 인터뷰 대비 총정리 자료 - ② 알고리즘
[📝 신입 인터뷰 준비] - [면접총정리] 신입 개발자 인터뷰 대비 총정리 자료 - ③ 데이터베이스
[📝 신입 인터뷰 준비] - [면접총정리] 신입 개발자 인터뷰 대비 총정리 자료 - ④ 네트워크
[📝 신입 인터뷰 준비] - [면접총정리] 신입 개발자 인터뷰 대비 총정리 자료 - ⑤ 운영체제
[📝 신입 인터뷰 준비] - [면접총정리] 신입 개발자 인터뷰 대비 총정리 자료 - ⑥ 자바(Java)
[📝 신입 인터뷰 준비] - [면접총정리] 신입 개발자 인터뷰 대비 총정리 자료 - ⑦ 백엔드(Java Spring 기반)
[📝 신입 인터뷰 준비] - [면접총정리] 신입 개발자 인터뷰 대비 총정리 자료 - ⑧ 개발공통 / 인성면접