배치 프로세스 개념과 아키텍처

2. 핵심 원리

2.1 온라인 트랜잭션 vs 배치

온라인 코드에서 "for 문으로 100만 번 DB 조회"는 상상하기 어렵지만, 배치에서는 그것이 본업입니다. 그래서 배치 코드는 같은 언어를 써도 설계 감각이 다릅니다. 온라인은 "이 한 건을 얼마나 빨리 끝내나", 배치는 "전체를 얼마나 안전하게, 메모리 안 터지고, 중간에 죽어도 이어서 끝내나"를 봅니다.

2.2 실무 배치 사례

공통점이 보입니다. 입력 → 가공 → 출력의 3단계이고, 입력이 매우 크고, 재실행이 안전해야 합니다.

2.3 배치의 핵심 요구사항

1. 대용량: 입력이 메모리보다 클 수 있다는 전제로 설계합니다. List<Row> all = repository.findAll() 은 배치에서 금기어입니다.
2. 재시작 가능성(restartability): 100만 건 중 70만 건에서 죽으면 70만 건부터 이어서 실행할 수 있어야 합니다. 그러려면 "어디까지 했는지"를 기록해야 합니다.
3. 멱등성(idempotency): 같은 배치를 두 번 실행해도 결과가 한 번 실행한 것과 같아야 합니다. 정산을 두 번 하면 돈이 두 번 나갑니다.
4. 로깅/모니터링: 시작·종료 시각, 읽은 건수, 쓴 건수, 실패 건수, 상태를 남겨야 새벽에 죽은 배치를 아침에 분석할 수 있습니다.
5. 실패 격리: 한 건의 데이터 오류가 전체 배치를 죽이면 안 됩니다. 잘못된 건은 따로 기록하고 나머지는 계속 진행합니다(05 레슨).
6. 성능: 실행 시간 창(window)이 있습니다. 새벽 2시~5시 안에 끝나야 아침 업무에 지장이 없습니다.

2.4 Reader → Processor → Writer — 왜 이렇게 나누는가

가장 단순한 배치 코드는 이렇습니다.

for (String line : Files.readAllLines(path)) {   // 읽기
    Member m = parse(line);
    m.setGrade(calc(m));                           // 가공
    db.update(m);                                  // 쓰기
}

이 코드에는 세 가지 문제가 있습니다.

• readAllLines 가 파일 전체를 메모리에 올립니다. 100만 줄이면 수백 MB, 1000만 줄이면 OOM 입니다.
• 한 건마다 db.update 를 호출합니다. DB 왕복이 100만 번입니다. 묶어서 보내면 100배 빨라집니다.
• 읽기·가공·쓰기가 한 덩어리라 재사용도, 테스트도, 교체도 어렵습니다. 입력을 파일에서 DB 로 바꾸려면 전체를 고쳐야 합니다.

그래서 역할을 셋으로 나눕니다.

   ┌──────────────┐    1건     ┌──────────────┐    1건     ┌──────────────┐
   │  ItemReader  │ ────────▶ │ ItemProcessor│ ────────▶ │  (chunk 버퍼) │
   │  read(): T   │           │ process(I):O │           │  List<O>      │
   └──────────────┘           └──────────────┘           └──────┬───────┘
      파일/DB/API                 변환, 검증,                   │ N건 모이면
      한 건씩 꺼냄                필터(null)                    ▼
                                                        ┌──────────────┐
                                                        │  ItemWriter  │
                                                        │ write(List)  │
                                                        └──────────────┘
                                                          N건 한 번에 저장
                                                          = 커밋 포인트

Reader 는 "한 건씩", Writer 는 "묶음으로"라는 비대칭이 핵심입니다. 읽기는 메모리 때문에 한 건씩, 쓰기는 I/O 효율 때문에 묶음으로. 그 사이에서 묶음을 만드는 것이 청크(chunk)입니다.

2.5 Job / Step / Chunk — Spring Batch 용어와의 대응

Job (dailyMemberJob)
 ├── Step 1 (regradeMembers)      reader → processor → writer, chunk=100
 │     ├── chunk #1  (100건 읽고 → 가공 → 한 번에 쓰기 → 커밋)
 │     ├── chunk #2
 │     └── ...
 ├── Step 2 (extractUnpaid)       chunk=200
 └── Step 3 (sendNotifications)

Spring Batch 는 여기에 메타데이터를 DB 테이블에 자동 저장하고, 재시작·스킵·재시도·병렬화를 설정으로 제공합니다. 하지만 구조 자체는 위 표 그대로입니다. 직접 만든 골격을 이해하면 Spring Batch 문서가 "우리가 만든 것의 확장판"으로 읽힙니다.

2.6 실행 메타데이터를 왜 기록하는가

배치는 사람이 보고 있지 않을 때 실행됩니다. 아침에 출근해서 확인할 수 있는 것은 오직 기록뿐입니다.

StepExecution 을 record 로 만든 이유는 이것이 불변의 실행 기록이기 때문입니다. 실행이 끝난 뒤 값이 바뀌면 안 되고, toString/equals 가 자동으로 생기며, DB 한 행에 그대로 대응됩니다.

2.7 스케줄링과 실행 시간 창

배치는 누군가가 정해진 시각에 실행해 줘야 합니다.

실행 시간 창(batch window)은 배치가 돌아도 되는 시간대입니다. 새벽 2시~5시라면 3시간 안에 끝나야 하고, 처리량이 하루 5% 씩 늘면 몇 달 뒤 창을 넘깁니다. 그래서 메타데이터에 소요 시간을 남기고 추세를 봐야 합니다. 또 같은 시각에 여러 배치가 몰리면 DB 가 느려지므로 순서와 의존관계를 설계합니다(정산 배치는 거래 마감 배치 이후에).

cron 표현식 한 줄만 기억합시다.

┌──────── 분 (0-59)
│ ┌────── 시 (0-23)
│ │ ┌──── 일 (1-31)
│ │ │ ┌── 월 (1-12)
│ │ │ │ ┌ 요일 (0-6, 0=일)
0 2 * * *      매일 02:00
0 3 1 * *      매월 1일 03:00
*/10 * * * *   10분마다

2.8 배치 설계 체크리스트

새 배치를 만들기 전에 답해야 할 질문입니다.