퀴즈: 중단된 배치를 이어서 끝내기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 40건 중 10건씩 확정하도록 바꾸기 전에 가장 먼저 확인할 업무 조건은?

   1. 평균 응답 시간을 측정해 10건이 가장 빠른지 확인한다.
   2. 고객이 일부만 완료된 상태와 중단 시 처리 범위를 승인했는지 확인한다.
   3. 전체 취소 SQL에 LIMIT 10을 붙일 수 있는지 확인한다.
   4. 진행률 화면을 25% 단위로 표시할 수 있는지 확인한다.

2. 첫 청크 완료 후 새 pending 주문이 들어왔다. 원 승인 범위를 지키는 다음 청크 선택은?

   1. 현재 pending 전체를 다시 조회하고 앞에서 10건을 고른다.
   2. 현재 pending을 정렬해 OFFSET 10부터 10건을 고른다.
   3. 처음 승인한 건수만 유지하고 새 주문으로 빈자리를 채운다.
   4. 동결한 승인 ID·버전·수량 배열을 저장된 next_index부터 자른다.

3. 둘째 청크의 다섯 번째 주문에서 버전 충돌이 났다. 승인된 청크 원자성에 맞는 처리는?

   1. 둘째 청크 전체를 롤백하고 첫 청크와 다른 담당자의 후속 변경은 보존한다.
   2. 충돌한 한 행만 건너뛰고 둘째 청크의 완료 위치를 저장한다.
   3. 첫 청크까지 취소를 되돌려 전체가 처음 상태인 것처럼 만든다.
   4. 현재 버전을 새 기대값으로 바꾸고 승인 없이 둘째 청크를 다시 실행한다.

4. 두 워커가 같은 작업을 실행한다. 이 수업의 작업 행 잠금이 지키는 핵심은?

   1. orders 전체를 잠가 다른 고객의 조회를 모두 중단한다.
   2. 두 워커가 같은 청크를 병렬 변경해 처리 속도를 두 배로 만든다.
   3. 다음 구간 선택부터 변경·감사·진행률 확정까지 같은 작업을 직렬화한다.
   4. 연결이 끊겨도 잠금을 영구 보관해 다른 워커의 접근을 막는다.

5. 청크 커밋 직후 응답을 받기 전에 클라이언트가 종료됐다. 같은 작업의 다음 진행 API를 다시 호출하면?

   1. 같은 작업 ID이므로 항상 직전 processed 목록을 그대로 반환해야 한다.
   2. 저장된 다음 위치부터 진행하므로 직전 청크를 다시 실행하지 않을 수 있다.
   3. 응답 기록이 없으므로 job_audit를 지우고 처음부터 처리해야 한다.
   4. 처리 결과가 불명확하므로 새로운 작업 ID로 원 승인 전체를 다시 등록한다.

6. 진행률은 20/40이고 확정했던 2번 주문은 삭제됐다. 같은 수량의 99번 주문이 있다면 보고서는?

   1. 수량이 같으므로 99번을 2번의 대체 완료 증거로 넣는다.
   2. 삭제된 주문은 분모에서 빼고 19/39로 과거 진행률을 수정한다.
   3. 현재 없는 행을 복구한 뒤에만 보고서를 생성하도록 한다.
   4. 과거 확정 ID에는 2번을 남기고 현재 대조에서는 missing으로 분류한다.