트랜잭션과 재시작 — 청크 커밋, 체크포인트, 멱등성

배치에서 왜 청크 단위로 커밋하는지, 중간에 죽으면 어디서부터 다시 시작하는지, 두 번 실행해도 안전하려면 무엇이 필요한지를 순수 자바 트랜잭션 시뮬레이션으로 직접 구현하고 로그로 확인할 수 있게 됩니다.

1. 왜 배우는가

새벽 3시, 100만 건 이체 배치가 70만 건에서 DB 커넥션 끊김으로 죽었습니다. 아침 8시에 출근한 당신은 무엇을 해야 할까요? 처음부터 다시 돌리면 이미 처리된 70만 건이 두 번 이체됩니다. 70만 건 뒤부터 돌리려면 "정확히 어디까지 처리되었는지"를 알아야 하고, 그 70만 번째 건이 DB 에 반영됐는지 안 됐는지도 알아야 합니다. 이 질문에 코드로 미리 답해 두는 것이 배치 트랜잭션 설계입니다.

온라인 서비스에서 트랜잭션은 "요청 하나 = 트랜잭션 하나"라 단순합니다. 배치는 다릅니다. 100만 건을 하나의 트랜잭션으로 묶으면 DB 의 undo 로그가 폭발하고 락이 몇 시간씩 잡히며, 마지막 한 건이 실패하면 100만 건이 통째로 롤백됩니다. 건별로 커밋하면 100만 번의 커밋(디스크 fsync)이 발생해 느립니다. 그 사이의 답이 청크 단위 커밋이고, 03 레슨의 청크가 바로 그 단위입니다.

그리고 DB 만 트랜잭션이 있는 것이 아닙니다. 파일 출력, 외부 API 호출, 메시지 발송에도 "되돌릴 수 있는가"라는 질문이 따라옵니다. 이 레슨은 DB 없이 InMemoryDatabase 로 begin/commit/rollback 을 시뮬레이션하며, 실제 JDBC 와 어떻게 대응되는지 함께 설명합니다.