2021-06-29

Spring에 관한 필수 지식들

— Spring 기본 원리
프레임워크와 라이브러리에 대해
Spring을 왜 써야하는가
Spring의 동작과정에 대해
SpringBoot의 동작과정에 대해
Spring과 SpringBoot의 차이에 대해
— Spring 주요 구성
Springboot의 IoC컨테이너에 대해
DI(Dependency Injection)에 대해
POJO에 대해
API 요청을 처리하는 과정에 대해
DispatcherServlet에 대해
스프링에 적용된 디자인 패턴
— Spring 어노테이션
@SpringBootApplication에 대해
@Resource, @Autowired, @inject의 차이
@Transactional에 대해
— Spring Batch
Spring Batch의 주요 구성요소에 대해
Spring Batch에서 chunk에 대해
Spring Batch에서 트랜잭션 관리

프레임워크와 라이브러리에 대해

프레임워크(Framework)와 라이브러리(Library)는 모두 소프트웨어 개발에 있어 중요한 도구로 사용되지만, 그 사용 방식과 제어 흐름에 대한 책임이 있는 주체에 있어서 차이가 있습니다.

프레임워크(Framework): 프레임워크는 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스를 제공합니다. 이를 통해 개발자는 비즈니스 로직에 집중할 수 있습니다. 그러나 주의할 점은, 프레임워크에는 “제어의 역전(Inversion of Control)” 개념이 적용되어 프레임워크 자체가 작업의 흐름을 제어하며 개발자는 그 안에 필요한 코드를 작성하게 됩니다. 예를 들어, 스프링(Spring)이 대표적인 프레임워크입니다.

라이브러리(Library): 라이브러리는 특정 기능에 대한 코드의 집합으로, 주로 함수 또는 메서드 형태로 제공됩니다. 라이브러리는 개발자가 직접 제어 흐름을 결정하며 필요할 때 호출하여 사용할 수 있습니다. 그러므로, 라이브러리는 개발자의 코드 내에서 호출되어 사용됩니다. 예를 들어, 자바의 수학 계산 관련 함수를 제공하는 Math 클래스나, 파이썬의 데이터 처리를 도와주는 pandas가 라이브러리에 해당합니다.

따라서, 프레임워크와 라이브러리의 가장 큰 차이점은 ‘제어 흐름에 대한 주체’가 누구인가에 있습니다. 프레임워크는 제어 흐름을 스스로가 쥐고 있고 개발자는 그 안에서 필요한 코드를 작성하는 반면, 라이브러리는 개발자의 코드에 의해 제어됩니다.

Spring을 왜 써야하는가

스프링 프레임워크는 자바로 개발하는 애플리케이션을 편리하게 개발하도록 도와주는 애플리케이션 개발 프레임워크입니다. 이 프레임워크를 사용함으로써 개발자는 편리한 개발 환경, 코드의 재사용성 및 테스트 용이성, 그리고 효과적인 설정 관리 등을 이용할 수 있습니다.

의존성 주입(Dependency Injection): 스프링 프레임워크는 의존성 주입이라는 개념을 도입함으로써, 개발자가 객체 간의 의존성을 직접 관리하는 것이 아닌 프레임워크가 대신 관리해줍니다. 이를 통해 코드의 결합도를 낮추고 유연성을 높일 수 있습니다.

획일화된 테스트 환경 제공: 스프링은 통합 테스트 지원을 제공하여 테스트를 보다 쉽고 빠르게 수행할 수 있게 합니다. 또한 Mock 객체를 사용한 테스트 등도 지원하므로 코드의 테스트 용이성을 높일 수 있습니다.

프레임워크의 모듈성: 스프링은 필요한 부분을 선택하여 사용할 수 있는 모듈화된 구조를 가지고 있습니다. 예를 들어, 웹 애플리케이션 개발에는 스프링 MVC를, 보안에는 스프링 Security를 사용할 수 있습니다.

프로젝트 관리의 효율성: 스프링은 자바 기반의 설정, 애노테이션 기반의 설정, 그리고 XML 기반의 설정 등 다양한 방법으로 환경설정을 할 수 있어, 개발 프로젝트에 가장 적합한 설정 방식을 선택하여 사용할 수 있습니다.

트랜잭션 관리: 스프링은 선언적 트랜잭션 관리를 지원합니다. 이를 통해 개발자는 복잡한 트랜잭션 API를 직접 다루지 않아도 되며, 트랜잭션 관련 코드를 최소화할 수 있습니다.

따라서, 스프링을 사용함으로써 개발 생산성을 향상시키고, 유지보수를 용이하게 하며, 품질 높은 소프트웨어를 개발하는 데 도움이 됩니다.

Spring의 동작과정에 대해

Spring 애플리케이션이 시작하는 단계는 크게 설정 파일 로드, IoC 컨테이너 초기화, Bean 생성 및 등록으로 나눌 수 있습니다. 이 과정은 Spring 프레임워크가 개발자 대신 객체의 생명 주기와 의존성을 관리하는 IoC을 구현하는 것입니다.

Spring Framework의 실행 단계는 다음과 같습니다:

설정 파일 로드: 애플리케이션이 시작하면 먼저 Spring IoC 컨테이너는 설정 파일을 로드합니다. 이 설정 파일은 XML이거나 Java Config 등 다양한 형식이 될 수 있습니다. 설정 파일은 애플리케이션의 구성 요소인 Bean들과 이들의 의존성을 정의합니다.
IoC 컨테이너 초기화 및 Bean 생성: 설정 파일이 로드되면 IoC 컨테이너는 Bean 정의를 읽어들여 필요한 객체를 생성합니다. 이때 생성된 객체는 해당 Bean 정의에 따른 속성값과 의존성을 가지게 됩니다. 의존성은 다른 Bean들로부터 주입(Dependency Injection)받습니다.
Bean 등록 및 사용 준비: IoC 컨테이너는 생성된 Bean을 내부의 Bean 팩토리나 Bean 컨텍스트 등에 등록합니다. 이렇게 등록된 Bean은 애플리케이션의 다른 부분에서 필요할 때 IoC 컨테이너로부터 요청받아 사용될 수 있습니다.

이 과정들이 완료되면, Spring 애플리케이션이 정상적으로 작동할 수 있는 상태가 됩니다. 이는 Spring의 핵심 원칙인 IoC를 실현하는 과정으로, 개발자는 복잡한 객체 생성과 관리, 의존성 주입 과정을 Spring 프레임워크에 맡김으로써 비즈니스 로직에 집중할 수 있게 됩니다.

SpringBoot의 동작과정에 대해

SpringBoot 애플리케이션과 Spring 애플리케이션의 시작 단계는 기본적으로 동일하나, SpringBoot는 추가적인 자동 구성(자동 설정), 내장 서버 등의 기능을 제공하여 초기 구성을 보다 간편하게 합니다.

SpringBoot의 실행 단계는 다음과 같습니다:

설정 파일 로드: 둘 다 설정 파일을 로드하는 것은 같으나, SpringBoot는 Spring의 복잡한 XML 설정을 대체하는 자바 기반의 구성을 선호하며, ‘starters’ 라는 의존성 집합을 이용하여 추가적인 설정 없이 필요한 라이브러리들을 쉽게 포함시킬 수 있습니다.
IoC 컨테이너 초기화 및 Bean 생성: SpringBoot 애플리케이션은 Spring 애플리케이션과 같이 IoC 컨테이너를 초기화하고, Bean을 생성합니다. 하지만 SpringBoot는 추가적으로 ‘자동 구성’ 기능을 제공합니다. 이 기능을 통해 SpringBoot는 클래스 경로 설정, 다른 Bean들, 다양한 프로퍼티 설정 등을 기반으로 자동으로 Bean을 구성하고 생성할 수 있습니다.
내장 서버: Spring 애플리케이션은 외부 서버에 배포되어 실행되는 반면, SpringBoot는 톰캣 같은 내장 서버를 제공하여 별도의 서버 없이도 독립적으로 실행될 수 있습니다. 이를 통해 개발 및 테스트 과정을 간소화하고 빠르게 애플리케이션을 실행시킬 수 있습니다.

따라서, SpringBoot는 Spring 프레임워크의 기본 원칙을 그대로 유지하면서, 개발 및 배포 과정을 간편하게 해주는 여러 추가 기능을 제공합니다. 이로 인해 개발자는 복잡한 설정 과정을 크게 단순화하고, 비즈니스 로직에 더욱 집중할 수 있게 되었습니다.

Spring과 SpringBoot의 차이에 대해

Spring과 Spring Boot의 기본적인 차이는 설정과 간소화입니다. Spring Boot는 Spring 기반 애플리케이션을 빠르고 쉽게 구축할 수 있는 미리 설정된 기본 설정을 제공합니다.

Spring Framework는 대규모 Java 애플리케이션을 개발하는 데 널리 사용되는 오픈 소스 프레임워크입니다. 이는 IoC(Inversion of Control)와 DI(Dependency Injection)와 같은 강력한 기능을 제공하며, 데이터 액세스, 트랜잭션 관리, MVC 웹 애플리케이션 개발, 쉽게 사용 가능한 보안 구성 등과 같은 다양한 모듈을 제공합니다.

그러나 Spring Framework를 사용하여 애플리케이션을 설정하고 부트스트랩하는 과정은 복잡할 수 있습니다. 다양한 모듈을 수동으로 설정하고, 데이터 소스, 뷰 리졸버, 메시지 소스 등을 구성하고 관리해야 합니다.

이러한 복잡성을 해결하기 위해 Spring Boot가 만들어졌습니다. Spring Boot는 단독 실행 가능한 애플리케이션을 생성하는 방법, 즉 ‘spring을 위한 spring’을 제공하며, 개발자가 애플리케이션을 빠르게 시작하고 실행할 수 있도록 지원합니다. Spring Boot는 ‘opinionated defaults’를 제공하여 개발자가 설정을 최소화하고 빠르게 개발에 집중할 수 있도록 합니다.

Spring Boot는 또한 기본값이 설정된 내장된 서버(예: Tomcat, Jetty)를 제공하여 개발자가 쉽게 웹 애플리케이션을 빌드하고 배포할 수 있게 합니다. 이로 인해 개발자는 서버 설정에 대한 걱정 없이 애플리케이션 로직에 집중할 수 있습니다.

따라서 이 두 프레임워크의 주요 차이점은 Spring Boot가 빠른 프로토타이핑과 개발을 위한 간편한 설정, 내장된 서버, 기본값을 제공한다는 것입니다. 반면 Spring Framework는 개발자가 설정을 완전히 제어하고자 하는 경우 더 좋은 선택일 수 있습니다.

Springboot의 IoC컨테이너에 대해

Spring Boot의 IoC(Inversion of Control) 컨테이너는 객체의 생성, 의존성 관리 및 제공을 담당하는 Spring Framework의 핵심 부분입니다. 이 컨테이너는 객체 간의 의존성을 자동으로 관리하며, 이로 인해 개발자는 객체 생성과 의존성 설정에 대한 부담 없이 비즈니스 로직에 집중할 수 있습니다.

객체 생성: Spring IoC 컨테이너는 애플리케이션의 시작 시점에 구성 파일(Java Config, XML 등)에 기술된 대로 필요한 객체를 생성합니다. 이렇게 생성된 객체들은 Spring에서는 일반적으로 Bean이라고 부릅니다.
의존성 주입(Dependency Injection): 생성된 객체들이 서로 간에 의존성을 가지는 경우, Spring IoC 컨테이너는 이 의존성을 자동으로 해결합니다. 이를 통해 객체 간의 결합도를 낮추고 코드의 재사용성과 유지 관리성을 높일 수 있습니다. 의존성 주입은 주로 @Autowired, @Resource 등의 어노테이션을 이용해 이루어집니다.
객체 제공: Spring IoC 컨테이너는 개발자가 필요로 하는 객체를 제공합니다. 이는 주로 ApplicationContext의 getBean 메소드를 통해 이루어지며, 필요에 따라 특정 타입의 모든 Bean을 제공하거나 특정 이름의 Bean을 제공할 수 있습니다.
생명주기 관리: Spring IoC 컨테이너는 Bean의 생명주기를 관리합니다. Bean이 생성되고, 의존성이 주입된 후 초기화 메소드가 호출됩니다. 애플리케이션 종료 시에는 소멸 메소드가 호출됩니다. 초기화와 소멸 메소드는 각각 @PostConstruct와 @PreDestroy 어노테이션을 이용해 지정할 수 있습니다.

따라서, Spring Boot의 IoC 컨테이너는 객체의 생성부터 제거에 이르는 전 과정을 관리하며, 이를 통해 개발자는 객체의 생성과 관리에 들어가는 노력을 절약하고 애플리케이션의 유연성과 확장성을 높일 수 있습니다.

DI(Dependency Injection)에 대해

의존성 주입은 Spring에서 객체 간의 의존 관계를 정의하는 핵심 기능입니다. 이는 클래스 사이의 결합도를 낮추고 코드의 재사용성과 유지 보수성을 향상시키는 기법입니다.

DI의 기본 개념은 ‘의존하는 객체를 직접 생성하는 대신 외부에서 주입 받는다’는 것입니다. 이를 통해 각 클래스는 필요한 의존성만 알면 되며, 어떻게 그 의존성이 만들어지고 조립되는지 알 필요가 없습니다.

예를 들어, 어떤 클래스 A가 클래스 B의 기능을 이용해야 할 때, A가 직접 B를 생성하지 않습니다. 대신에, A의 생성자나 메서드, 혹은 필드를 통해 B의 인스턴스를 주입받습니다.

Spring에서는 이를 위해 IoC 컨테이너가 관리하는 빈들(Bean)을 사용합니다. 빈은 Spring IoC 컨테이너가 관리하는 객체로서, 필요한 곳에 자동으로 주입될 수 있습니다. 이를 통해 개발자는 객체의 생성과 생명주기를 직접 관리하지 않아도 되며, 의존성 관리를 Spring Framework에 위임할 수 있습니다.

이런 방식은 코드의 모듈성과 유연성을 향상시키며, 유닛 테스트를 더 쉽게 만들 수 있습니다. 또한 코드의 결합도를 줄이고, 유지 관리와 코드 재사용성을 향상시키는데 도움이 됩니다.

POJO에 대해

POJO(Plain Old Java Object)는 특정한 규약, 인터페이스, 클래스를 상속하거나 구현하지 않는, 순수한 자바 객체를 가리킵니다. POJO는 로직을 포함할 수 있지만, 비즈니스 로직에만 집중하고 특정 기술과는 무관하게 작성됩니다.

POJO의 개념은 “특정 기술에 종속되지 않는 일반적인 자바 객체“를 지칭하며, 이 개념은 스프링 프레임워크의 핵심 원칙 중 하나입니다. POJO는 다른 기술에 종속적인 요소들로부터 독립적이어야 하므로, 대부분의 POJO는 특정한 인터페이스를 구현하거나 특정 클래스를 상속받지 않습니다.

스프링에서 POJO를 사용하는 주요 이유는 애플리케이션의 모듈화와 유지 보수성 향상입니다. 특정 기술에 종속되지 않는다는 POJO의 특성은 개발자가 비즈니스 로직에만 집중할 수 있게 해주며, 이를 통해 코드의 가독성이 향상되고 유지 보수성이 좋아집니다.

또한, POJO를 사용하면 단위 테스트도 수월해집니다. POJO는 특정 환경이나 서버에 종속적이지 않기 때문에, 개발 환경 외부에서도 테스트를 쉽게 수행할 수 있습니다. 이는 테스트 주도 개발(TDD)와 같은 방법론을 적용할 때 큰 이점이 됩니다.

따라서 스프링에서 POJO는 중요한 역할을 하는데, 그것은 개발자가 비즈니스 로직에 집중하면서 유연하고 유지보수하기 쉬운 코드를 작성할 수 있도록 돕는 것입니다.

@SpringBootApplication에 대해

@SpringBootApplication은 Spring Boot 애플리케이션을 구성하는 중요한 어노테이션입니다. 이 어노테이션은 @Configuration, @EnableAutoConfiguration, 그리고 @ComponentScan 세 가지 어노테이션의 기능을 한 번에 제공합니다.

@Configuration: 스프링 설정 파일로 작동하게 만드는 어노테이션입니다. 이를 사용하여 스프링 빈을 생성하고 관리할 수 있습니다.

@EnableAutoConfiguration: 스프링 부트의 자동 설정 기능을 활성화합니다. 클래스 경로 설정, 다른 빈들, 다양한 프로퍼티 설정 등을 기반으로 애플리케이션에 필요한 빈들을 자동으로 설정합니다.

@ComponentScan: 이 어노테이션은 @Controller, @Service, @Repository, @Component 등과 같이 스프링에서 관리하는 다른 컴포넌트들을 검색하고 빈으로 등록하도록 합니다.

이 세 가지 어노테이션을 함께 사용하면, Spring Boot 애플리케이션은 최소한의 구성으로도 실행 및 배포가 가능해집니다. @SpringBootApplication 어노테이션은 애플리케이션의 주 클래스에 붙여 사용하며, 이 클래스는 애플리케이션의 root package를 정의하는 데 사용됩니다. 따라서 스프링 부트의 자동 구성 기능이 해당 패키지와 하위 패키지를 스캔하여 빈을 등록하게 됩니다.

@Resource, @Autowired, @inject의 차이에 대해

@Resource, @Autowired, @Inject는 모두 Spring에서 의존성을 주입하는 데 사용되는 어노테이션입니다. 이들은 주입하려는 빈을 찾는 방법과 기본적인 동작이 약간 다릅니다.

@Autowired: 이 어노테이션은 Spring에서 제공하는 어노테이션으로 주로 타입에 의한 의존성 주입을 지원합니다. 만약 같은 타입의 빈이 여러 개 존재하면 이름으로 찾아서 주입합니다. required 속성이 있는데, 기본값은 true로 되어 있습니다. 이는 의존성 주입을 해야 한다는 의미로, Spring 컨테이너에서 해당 타입의 빈을 찾지 못하면 애플리케이션은 시작되지 않습니다.
@Inject: 이 어노테이션은 자바의 표준 어노테이션으로, @Autowired와 동일하게 타입에 의한 의존성 주입을 지원합니다. 또한 @Autowired와 마찬가지로 같은 타입의 빈이 여러 개 존재하면 이름으로 찾아서 주입합니다. 하지만 @Autowired와 달리 required 속성이 없습니다.
@Resource: 이 어노테이션은 JSR-250 자바 표준으로, 이름에 의한 의존성 주입을 지원합니다. @Resource는 기본적으로 빈의 이름으로 의존성을 주입하려 시도하며, 해당 이름의 빈을 찾지 못하면 타입에 따라 의존성을 주입하려고 합니다.

이 세 어노테이션은 모두 생성자, 필드, 세터 메서드에 사용될 수 있습니다. 어떤 것을 사용할지는 개발자의 선택이지만, 특별한 이유가 없다면 Spring의 @Autowired를 사용하는 것이 일반적인 추천 방법입니다. 다만, 필요에 따라 JSR-330의 @Inject를 사용하거나, 이름 기반의 검색을 원하면 @Resource를 사용할 수 있습니다.

Spring 애플리케이션 API 요청을 처리하는 과정에 대해

Spring은 클라이언트 요청이 들어오면 먼저 Filter를 통과하고, DispatcherServlet, Interceptor 등 여러 요소를 거쳐 실제 Controller로 전달되어 요청을 처리합니다.

클라이언트로부터 요청이 들어오면, 먼저 Servlet Container가 이를 받습니다. 이 때, 가장 먼저 거치는 것이 Filter입니다.
Filter: 여기서는 HTTP 요청이나 응답에 대한 전처리 및 후처리를 진행합니다. Filter는 주로 인증, 로깅, 인코딩 등의 크로스 커팅 콘서른에 사용됩니다.
DispatcherServlet: Filter를 거친 요청은 DispatcherServlet에게 전달됩니다. DispatcherServlet는 Front Controller 패턴을 구현한 핵심 컴포넌트로, 요청을 적절한 컨트롤러에게 라우팅하는 역할을 담당합니다.
Interceptor: DispatcherServlet이 요청을 받으면, 이를 처리하기 위해 HandlerMapping을 사용해 해당 요청을 처리할 Controller를 찾습니다. 찾은 Controller에게 요청을 위임하기 전에 Interceptor가 동작하게 됩니다. Interceptor는 AOP(Aspect Oriented Programming)의 일환으로, Controller의 동작 전후에 특정 로직을 실행하게 해주는 역할을 합니다.
Controller: DispatcherServlet은 요청을 처리할 적절한 컨트롤러를 찾습니다. 컨트롤러는 요청을 처리하고 API 요청의 경우 컨트롤러는 일반적으로 JSON 형식의 데이터를 생성하고 응답 본문에 직접 씁니다.
응답 반환: 최종적으로, 응답이 클라이언트에게 전달됩니다. 이 응답은 일반적으로 JSON 형식의 데이터를 포함하며, HTTP 상태 코드와 함께 전달됩니다.

DispatcherServlet에 대해

DispatcherServlet은 Spring MVC에서 핵심 역할을 하는 Front Controller입니다. 모든 클라이언트 요청을 받아 적절한 컨트롤러에게 작업을 위임하는 중심적인 역할을 수행합니다.

Spring MVC에서 클라이언트로부터 들어오는 모든 요청은 DispatcherServlet이 처리하게 됩니다. 이러한 구조는 모델-뷰-컨트롤러(MVC) 패턴을 기반으로 합니다. 클라이언트로부터 요청을 받으면, DispatcherServlet은 이 요청을 분석하고 핸들러 매핑을 사용하여 적절한 컨트롤러를 찾습니다.

찾아낸 컨트롤러가 요청을 처리한 후, 결과 데이터와 뷰 이름을 ModelAndView 객체로 반환합니다. DispatcherServlet은 이 정보를 사용하여 ViewResolver를 통해 실제 뷰를 찾아, 해당 뷰에 모델 데이터를 전달하여 클라이언트에게 최종적인 결과를 렌더링합니다.

또한, DispatcherServlet은 Spring의 IoC 컨테이너와 연동되어 작동합니다. 이를 통해 Controller나 Service, Repository 등이 필요로 하는 의존성을 주입(DI) 받을 수 있게 됩니다.

결과적으로 DispatcherServlet은 클라이언트 요청의 생애주기 전반에 걸쳐 핵심적인 역할을 수행하며, 각 요청을 적절한 컨트롤러로 라우팅하고 최종적인 결과를 렌더링하는 과정을 관리합니다.

스프링에 적용된 디자인패턴

스프링 프레임워크는 객체 지향 프로그래밍 및 엔터프라이즈 애플리케이션 개발에 활용되는 여러 가지 디자인 패턴을 구현하고 있습니다. 가장 대표적으로는 Singleton, Factory, Template Method, Proxy, MVC(Model-View-Controller), Front Controller, Dependency Injection 패턴 등이 있습니다.

Singleton 패턴: 스프링의 Bean은 기본적으로 Singleton으로 관리됩니다. 즉, 한 개의 Bean 정의당 한 개의 객체 인스턴스만 존재하게 되어 리소스를 효율적으로 관리할 수 있습니다.
Factory 패턴: 스프링의 ApplicationContext나 BeanFactory는 Factory 패턴을 구현하고 있습니다. 이들은 Bean의 생성, 생명주기 관리 등을 담당합니다.
Template Method 패턴: 스프링의 JdbcTemplate이나 RestTemplate 등은 Template Method 패턴을 구현하고 있습니다. 이 패턴은 반복적인 코드를 피하고, 변하는 부분만 서브 클래스에서 구현하도록 하는 패턴입니다.
Proxy 패턴: 스프링의 AOP(Aspect Oriented Programming)는 Proxy 패턴을 통해 구현됩니다. 이를 통해 로깅, 트랜잭션 관리 등의 공통적인 기능을 비즈니스 로직 코드와 분리하여 개발 및 유지보수를 용이하게 합니다.
MVC 패턴: 스프링 MVC는 웹 애플리케이션 개발을 위해 사용되는 MVC 패턴을 구현하고 있습니다. 모델(Model), 뷰(View), 컨트롤러(Controller)의 세 가지 구성 요소를 사용하여 애플리케이션 로직을 분리합니다.
Dependency Injection 패턴: 스프링에서 가장 핵심적인 개념이자 패턴으로, 객체 간의 의존성을 스프링 컨테이너가 자동으로 연결해주는 방식을 의미합니다. 이를 통해 코드의 결합도를 낮추고 유연성을 높입니다.

@Transactional에 대해

@Transactional 어노테이션이 붙은 메소드는 Spring의 AOP 프록시를 통해 트랜잭션 관리가 수행됩니다. 이 프록시는 메소드 호출을 가로채서 트랜잭션 관련 로직을 적용한 후 원래의 메소드를 호출하는 역할을 합니다.

Spring의 @Transactional 어노테이션은 내부적으로 AOP를 활용해 동작합니다. 이때 사용되는 주요 컴포넌트는 TransactionInterceptor와 ProxyFactoryBean입니다.

Proxy 생성: 먼저, Spring IoC 컨테이너는 @Transactional 어노테이션이 붙은 Bean을 실제 객체가 아닌 Proxy로 감싸서 관리합니다. 이 프록시는 JDK Dynamic Proxy나 CGLIB Proxy 등을 사용할 수 있으며, 이는 설정 및 상황에 따라 달라집니다.
메소드 호출: 클라이언트로부터 메소드 호출이 발생하면, 프록시는 실제 객체의 메소드를 직접 호출하는 대신 TransactionInterceptor를 통해 호출합니다.
트랜잭션 시작: TransactionInterceptor는 TransactionManager를 사용하여 트랜잭션을 시작합니다.
실제 메소드 호출: 트랜잭션이 시작되면, 실제 비즈니스 로직을 담은 메소드가 실행됩니다.
트랜잭션 종료: 메소드 실행 후, TransactionInterceptor는 트랜잭션을 커밋하거나 롤백합니다. 이때 메소드 실행 도중 예외가 발생하면 롤백, 그렇지 않으면 커밋이 수행됩니다.

이렇게 Spring의 @Transactional은 AOP와 프록시를 통해 선언적 트랜잭션 관리를 제공합니다. 이 방식은 개발자가 직접적으로 트랜잭션을 관리하는 코드를 작성하지 않아도 되게 하므로, 비즈니스 로직에만 집중할 수 있게 해줍니다. 또한, 코드의 가독성을 향상시키고 트랜잭션 관리의 일관성을 보장하는 데에도 도움이 됩니다.

Spring Batch의 주요 구성요소에 대해

Spring Batch는 대량 데이터 처리를 지원하는 스프링 프레임워크의 부분이며, 주요 구성요소로는 Job, Step, ItemReader, ItemProcessor, ItemWriter가 있습니다.

Job: Spring Batch의 핵심 API로써, 배치 처리 과정을 나타내는 객체입니다. 일반적으로 하나의 Job은 하나의 배치 작업을 나타내며, 여러 Step 인스턴스로 구성됩니다.
Step: Step은 Job을 구성하는 독립적인 단계를 나타냅니다. 각 Step은 ItemReader, ItemProcessor, 그리고 ItemWriter를 가지며, 이들을 순차적으로 실행합니다.
ItemReader: 데이터를 읽어오는 역할을 합니다. 파일, 데이터베이스, API 등 다양한 방식으로 데이터를 읽어올 수 있습니다.
ItemProcessor: ItemReader를 통해 읽어온 데이터를 처리하는 역할을 합니다. 데이터 필터링, 변환 등의 로직을 이 곳에서 구현합니다.
ItemWriter: 처리된 데이터를 최종적으로 쓰는 역할을 합니다. 데이터베이스, 파일, 메시지 큐 등 다양한 방식으로 데이터를 쓸 수 있습니다.

JobLauncher는 Job을 실행하는 API를 제공하며, JobRepository는 배치 처리 상태 및 메타데이터를 관리합니다. Job과 Step은 순차적 또는 병렬로 실행될 수 있으며, 재시작, 건너뛰기, 재시도 등 다양한 배치 처리 전략을 지원합니다.

Spring Batch에서 chunk에 대해

Spring Batch에서 청크(chunk) 처리는 대량의 데이터를 일정량 단위로 나눠 처리하는 전략입니다. ItemReader에서 데이터를 읽어온 후 ItemProcessor에서 처리하고, ItemWriter로 데이터를 쓰는 일련의 과정을 청크 단위로 수행합니다.

청크(chunk) 방식의 처리는 대량의 데이터를 한 번에 처리하기보다는 작은 단위로 나눠서 처리하는 방식을 말합니다. 이는 메모리 이슈를 방지하고, 처리 실패 시에도 일정 단위로만 롤백을 수행해 효율적인 데이터 처리가 가능합니다.

예를 들어, 청크 크기를 1000으로 설정하면 ItemReader는 1000개의 레코드를 읽어옵니다. 이후, 각 레코드에 대해 ItemProcessor가 처리를 수행하고, 이 처리 결과를 다시 ItemWriter가 한 번에 데이터베이스에 반영합니다. 이렇게 1000개의 레코드를 처리하는 것을 하나의 청크로 보며, 이러한 청크를 처리하는 과정이 반복됩니다.

이 방식은 대용량 데이터를 처리해야 하거나, 특정 작업을 병렬로 수행해야 할 때 유용합니다. 청크 단위로 데이터를 나누어 처리함으로써, 특정 청크에서 오류가 발생하더라도 해당 청크만 롤백하고 다음 청크의 처리를 계속 진행할 수 있기 때문입니다. 이를 통해 전체 작업의 안정성과 효율성을 높일 수 있습니다.

Spring Batch에서 트랜잭션 관리

Spring Batch에서의 트랜잭션 관리는 청크 단위로 이루어집니다. 각 청크는 자체 트랜잭션 경계를 가지며, 하나의 청크 내에서 발생하는 모든 작업은 단일 트랜잭션 내에서 처리됩니다.

Spring Batch에서는 청크를 처리하는 동안 데이터 읽기, 처리, 쓰기의 세 단계를 거칩니다. 이 세 단계는 모두 같은 트랜잭션에 포함되어 있으므로, 이 중 어느 하나가 실패하면 그 청크의 전체 작업이 롤백되고 다시 시작됩니다.

또한, Spring Batch는 재시작 가능성이라는 중요한 특징을 가지고 있습니다. 청크 단위의 트랜잭션 관리는 이러한 재시작 가능성을 지원하는 핵심 요소 중 하나입니다. 청크 단위로 트랜잭션을 관리하면, 실패한 청크를 쉽게 식별하고 해당 청크부터 재시작할 수 있습니다.

즉, Spring Batch의 트랜잭션 관리는 청크 단위의 트랜잭션 경계 설정을 통해 안정성과 재시작 가능성을 보장하며, 대용량 데이터 처리를 효율적으로 수행할 수 있도록 지원합니다. 이는 Spring Batch를 통한 배치 처리가 대량의 데이터를 안정적으로 처리해야 하는 많은 비즈니스 케이스에 적합하게 만듭니다.