[Spring Batch 실전] Day 5: 테스트와 운영 - 결과를 증명하는 배치

서론: COMPLETED만으로 성공을 판단할 수 없다

프로세스가 오류 없이 끝났어도 일부 데이터가 빠지거나 금액 합계가 틀리면 배치는 실패다. 반대로 재시도 후 모든 업무 결과가 맞다면 중간 오류가 있어도 성공일 수 있다. 배치 운영은 프레임워크 상태와 업무 불변식을 함께 검증해야 한다.

1. 테스트 층위

단위 테스트:
  Processor의 변환·필터·경계값

Step 테스트:
  Reader/Writer, Chunk 커밋, Skip·Retry

Job 통합 테스트:
  Step 흐름, JobParameters, 재시작

운영 리허설:
  실제 규모 데이터, 성능, 중단 후 복구

작은 정상 샘플만으로는 메모리·페이지 경계·중복 키·재시작 문제를 찾기 어렵다.

2. 재시작 테스트

1. 의도적으로 N번째 항목에서 실패
2. 첫 실행의 커밋 범위와 상태 확인
3. 같은 JobInstance를 재시작
4. 완료 후 중복·누락·외부 효과 검증

최종 행 수만 비교하지 말고 업무 키별 유일성, 합계, 상태 전이, 격리 데이터까지 확인한다.

3. 배치 메트릭

프레임워크:
  Job/Step 실행 시간, 상태, read/write/filter/skip/retry count

성능:
  초당 처리량, Chunk 시간, DB 대기, 메모리, GC

업무:
  정산 총액, 대상/제외 건수, 결과 파일 행 수, 미처리 잔량

업무 날짜·Job 이름·Step 이름은 유용한 차원이지만 사용자 ID 같은 고카디널리티 값을 메트릭 태그에 넣지 않는다.

4. 알림은 행동 가능해야 한다

나쁜 알림:
  "Job failed"

좋은 알림:
  "2026-09-10 정산 Step 2 실패, 61% 처리,
   마지막 커밋 ID 810233, 원인 DB lock timeout,
   재시작 가능, Runbook 링크"

지연 시작, 예상 종료 시각 초과, 처리량 급락, Skip 급증, 업무 합계 이상도 알림 대상이다.

5. 재처리 도구

운영자가 DB를 직접 수정하고 JobRepository 상태를 바꾸는 방식은 감사와 재현성이 약하다.

재처리 기능:
  실행 ID·업무 날짜 선택
  실패/Skip 항목 미리보기
  권한과 승인
  재처리 범위·이유 기록
  dry-run과 결과 비교

재처리도 멱등해야 하고 원래 실행과 연결된 감사 이력을 남긴다.

6. 배포와 스키마 호환성

실행 중인 Job을 새 버전이 이어받을 수 있는지, Reader의 ExecutionContext 형식과 Job 이름이 바뀌지 않았는지 확인한다. 긴 Job 실행 중 롤링 배포가 프로세스를 종료할 수 있으므로 실행 격리·graceful stop·재시작 정책을 준비한다.

변경 전:
  진행 중 실행 확인 → 메타데이터/DB 호환성 → 중단 시나리오 테스트

7. 시리즈 종합 체크리스트

1. Job·Step·Chunk로 업무와 트랜잭션 경계를 모델링했다. (Day 1)
2. 체크포인트와 멱등한 Writer로 재시작을 안전하게 했다. (Day 2)
3. Retry·Skip을 실패 유형과 업무 오류 예산에 맞췄다. (Day 3)
4. 병목 측정 후 자원 예산 안에서 파티셔닝했다. (Day 4)
5. 재시작 테스트·업무 메트릭·재처리 Runbook으로 결과를 증명했다. (Day 5)

시리즈 마무리

Spring Batch의 가치는 많은 데이터를 반복 처리하는 데 있지 않다. 실패한 대량 작업을 어디서, 어떤 상태로, 중복 없이 다시 시작할지 기록하는 것에 있다. 업무 신원을 나타내는 JobParameters, 작고 명확한 Step, 멱등한 Writer, 행동 가능한 메트릭이 갖춰지면 배치는 밤마다 기도하는 작업이 아니라 예측 가능한 운영 시스템이 된다.