불완전한 상태에서의 배치 수동 실행 차단

등급 동기화 배치(GradeSyncBatch)에 상태 기반 실행 제어를 추가했다. 특정 조건(웰컴 비활성)에서 수동 실행이 가능하던 구간을 막아 데이터 무결성 문제를 사전에 방지하는 작업이었다. 코드리뷰 2차 검증에서 지적된 부분을 처리한 것이다.

배치 작업의 상태 의존성 문제

배치 시스템은 보통 정해진 일정에 자동으로 실행되지만, 운영 중 특정 데이터 보정이나 긴급 처리를 위해 수동 실행을 지원한다. 문제는 배치가 선행 조건에 의존하는 경우다. 예를 들어 학사 시스템의 등급 동기화는 '학기 시작 절차(웰컴)'가 완료된 후에만 의미 있는 동작을 한다. 만약 웰컴 단계가 비활성화된 상태에서 누군가 수동으로 배치를 돌린다면 어떻게 될까?

• 초기화되지 않은 학기 데이터로 동기화 시도
• 기존 등급 정보가 불완전하게 덮어씌워짐
• 데이터 일관성 깨짐 → 나중에 수정하기 아주 복잡

이건 단순 버그가 아니라 아키텍처 레벨의 전제 조건 위반이다. 배치가 암묵적으로 가정하는 선행 조건을 명시적으로 검증하지 않으면, 정상 흐름 밖의 시나리오(수동 실행 + 부실한 상태)에서 침묵하는 데이터 corruption이 생긴다.

상태 검증을 통한 실행 제어

이번 작업은 배치 수동 실행 지점에 상태 검증 로직을 삽입하는 것이다. 개념적으로는 간단하다:

if (웰컴 비활성) {
  throw new BatchExecutionException("웰컴이 활성화되지 않아 수동 실행 불가");
}
// 이후 배치 로직 진행

실제 구현은 더 세밀할 텐데, 예를 들어:

이렇게 상태별로 실행 가능 여부를 명시하면, 운영자가 실수로 버튼을 눌러도 시스템이 거절할 수 있다. 이를 "fail-safe" 원칙이라고 부르는데, 특히 배치나 비동기 작업에서 중요하다.

코드리뷰의 가치

흥미로운 부분은 이 문제가 2차 코드 검증(codex 검증)에서 발견되었다는 점이다. 1차에서 미처 안 봤거나, 처음 리뷰에서는 구조에만 집중했을 가능성이 높다. 다단계 리뷰 문화가 제 역할을 하고 있다는 신호다. 특히 배치나 상태 관리 코드는:

• 정상 경로(sunny day)는 눈에 보이지만
• 엣지 케이스(상태 불일치, 수동 개입)는 놓치기 쉽다
• 두 번째 리뷰어가 "이 배치가 언제 깨질까?"라는 질문을 던지면 비로소 보인다

팀 입장에서 배우게 된 점:

1. 상태 머신 관점: 배치도 상태를 가진다. 각 상태에서 어떤 동작이 허용되는지 명시하기
2. 선행 조건 문서화: "이 배치는 다음 조건이 만족될 때만 실행된다"를 코드와 문서에 남기기
3. 수동 실행의 위험성: UI에서 "배치 수동 실행" 버튼을 편하게 만들수록, 검증이 더 엄격해야 함

일반적으로 배치 시스템에서:

• 자동 실행(스케줄)은 선행 조건이 이미 만족된 상태에서 돈다고 가정
• 수동 실행(운영자 버튼)은 예외 상황이므로 더 많은 검증 필요
• 따라서 수동 실행 시에는 자동 실행 때의 검증 + 추가 상태 검사를 하는 게 맞다

마무리

이번 작업은 작은 상태 검증 추가지만, 배경에는 "어떻게 배치를 더 견고하게 만들 것인가"라는 질문이 있었다. 제품이 복잡해질수록 데이터의 선행 조건이 증가하고, 수동 개입의 위험도 커진다. 상태 기반 실행 제어는 그 위험을 줄이는 기본 패턴이다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.