인프런 커뮤니티 질문&답변
작성한 질문수
Batch 패키지 설계 — 실무에서 Job 단위 구조
작성
·
30
1
킬구형 ㅎㅇ 요즘에 배치 다시 학습하면서 좀 고민인 부분이 있음. 현재 회사에서 배치 Job이 좀 많이 늘어나면서 코드 관리가 너무 어렵더라고. Spring MVC에서는 Controller-Service-Repository 같은 레이어드 아키텍처나 클린 아키텍처처럼 널리 쓰이는 구조가 있는데, 배치 쪽은 이런 패키지 구조나 설계 방식에 대한 레퍼런스가 상대적으로 적은 것 같아서. 최근에 클린 아키텍처를 배우면서 배치에도 이런 구조를 적용할 수 있는지 궁금해졌거든.
지금 나는 대략 이런 식으로 구성하고 있어:
batch/
├── order/
│ ├── confirm/
│ │ ├── OrderConfirmJobConfig.java
│ │ ├── OrderConfirmReader.java
│ │ ├── OrderConfirmProcessor.java
│ │ ├── OrderConfirmWriter.java
│ │ └── OrderConfirmJobListener.java
├── payment/
│ ├── settle/
│ └── cancel/
├── support/
├── domain/
├── application/
└── infrastructure/
하나의 Job을 하나의 큰 애그리게이트처럼 보고 있어서, 관련 클래스를 패키지별로 분리하기보다 한 폴더 안에서 로우 레벨로 관리하는 게 더 편하더라고.
근데 Job이 계속 많아질수록 이게 맞는 건지, 더 나은 방법이 있는 건지 잘 모르겠어서. 혹시 형은 실무에서 Job이 많아졌을 때 패키지 구조나 코드 구성을 어떻게 가져가? 객체 간 위계나 import 의존성 방향 같은 것도 신경 써서 설계하는지도 궁금해. 물론 사람마다 차이가 있겠지만 시간 괜찮으면 경험 공유해주면 도움이 많이 될 것 같아!
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
퓨퓨님, 배치 작업 관리를 하면서 패키지 구조와 설계에 대한 고민이 많으신 것 같습니다. 배치(Job) 작업이 많아지면 관리가 점점 복잡해지기 때문에 효율적인 패키지 구조 설계가 필요하죠.
일반적인 Spring Batch 패키지 구조
배치 어플리케이션에서 일반적으로 추천되는 구조는, 각 Job을 하나의 단위로 보아서 관련된 요소들을 함께 묶어 두는 것입니다. 기존의 레이어드 아키텍처처럼 하되, Job 단위로 분리하여 관리하면 유지보수와 가독성이 향상됩니다.
예시 구조:
batch/
├── job/
│ ├── order/
│ │ ├── confirm/
│ │ │ ├── OrderConfirmJobConfig.java
│ │ │ ├── OrderConfirmReader.java
│ │ │ ├── OrderConfirmProcessor.java
│ │ │ ├── OrderConfirmWriter.java
│ │ │ └── OrderConfirmJobListener.java
│ ├── payment/
│ │ ├── settle/
│ │ └── cancel/
│ └── support/
├── config/
└── common/
패키지 구조의 중요성
관련 클래스 그룹화: Job을 중심으로 관련 클래스들을 하나의 패키지로 묶어서 관리하면, 특정 Job의 모든 동작이 같은 패키지 내에 있어 이해하기 쉽습니다.
재사용성 고려: Job 간에 공통적으로 사용하는 Reader, Processor, Writer 등이 있다면, 이를 별도의 공통 패키지로 분리하여 재사용할 수 있게 하는 것도 좋은 방법입니다.
의존성 관리: 동시에, import 의존성이나 객체 간 위계에 대해서도 관리해줘야 합니다. 가능한 한 의존성을 줄이고, 변경이 일어났을 때 그 영향이 최소화될 수 있도록 설계합니다.
클린 아키텍처의 적용
클린 아키텍처 원칙 또한 배치 어플리케이션에 적용할 수 있습니다. 이렇게 함으로써 어플리케이션이 변화에 덜 민감해지고 유지보수가 용이해질 수 있습니다. 핵심 기능과 이런 기능을 수행하기 위한 세팅 등을 레이어로 나누어, 각 레이어가 명확한 책임을 가지도록 하는 것이죠.
참고 링크
실무에서 이러한 패키지 구조를 어떻게 다루고 계신지에 대한 킬구형님의 답변이 공유된다면, 이를 통해 더 깊이 있는 이해를 도모하실 수 있을 것입니다. 프로젝트 특성과 팀의 개발 스타일에 맞추어 눈앞의 목표에 가장 적합한 구조를 선택하시기 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.