Dataflow 중단·재개 운영 증거 설계

1. Pause/Resume은 실패를 없애는 버튼이 아니다

긴 배치 작업이 멈추면 가장 먼저 나오는 질문은 대개 “처음부터 다시 돌려야 하나”다. 그러나 운영자가 실제로 풀어야 하는 문제는 실행 명령 하나보다 넓다. 어디까지 완료됐는지, 중단의 원인이 파이프라인 안에 있는지 외부 서비스에 있는지, 지금 재개해도 같은 문제가 되풀이되지 않는지, 그리고 그 판단을 다음 담당자도 이해할 수 있는지가 함께 걸려 있다. 복구는 기술 동작이지만 동시에 책임을 가진 의사결정이다.

Google Cloud는 2026년 9월 14일 Dataflow 배치 작업의 Pause/Resume 일반 제공을 발표했다. 발표는 실패한 장기 실행 배치 작업을 처음부터 다시 시작하는 대신 재개할 수 있는 기능이라고 설명한다. 이어진 공식 Pause 가이드는 이 기능이 배치 파이프라인에만 지원되며, 작업이 멈춘 뒤 완료된 단계나 작업 항목은 다시 처리하지 않고 진행 중이던 항목은 처음부터 다시 처리한다고 밝힌다. 이 차이는 중요하다. ‘재개’라는 단어를 데이터 전체가 그대로 이어진다는 보장으로 읽으면 안 되기 때문이다.

그래서 복구 경험을 남길 때도 “작업을 재개했다”로 끝내기보다, 완료로 간주한 범위와 다시 처리될 수 있는 범위를 분리해 기록하는 편이 낫다. 예를 들어 완료된 출력이 하류 시스템에서 이미 소비됐는지, 진행 중이던 항목을 다시 읽어도 멱등성이 보장되는지, 재처리 시 외부 API 호출이나 알림이 중복되지 않는지를 확인한다. 이 질문들은 Dataflow의 기능 설명을 모든 파이프라인에 일반화한 규칙이 아니다. 각 팀이 자신의 데이터 계약과 부작용을 확인하기 위한 운영 질문이다.

경력 관점에서 중요한 것도 ‘몇 번을 살렸는가’ 같은 횟수가 아니다. 누군가가 중단 상황에서 무엇을 확인했고, 어떤 근거로 재개와 재설계를 갈랐는지 설명할 수 있는가에 가깝다. 장애를 개인의 영웅담으로 만들 필요는 없다. 오히려 작업 ID, 로그 링크, 민감 정보를 복사해 두는 대신 결정 당시의 범위, 확인한 담당자, 보류한 질문을 안전한 운영 문서에 남기는 편이 협업에 더 유용하다.

2. 기능을 쓸 수 있는 조건과 재개해도 되는 조건

공식 문서는 Pause-on-failure를 쓰려면 배치 작업이 Dataflow Shuffle을 사용하고, 실행 시 pauseonfailure 서비스 옵션을 지정해야 한다고 명시한다. 또한 중단된 동안에는 파이프라인 코드나 워커 VM 구성처럼 작업의 구성을 바꿀 수 없다. 이 사실은 기능을 도입할 때 ‘중단 후 수정하고 그대로 이어서 실행한다’는 기대가 잘못될 수 있음을 보여 준다. 기능의 적용 가능성은 실행 전에 확인해야 한다.

하지만 이 제품 조건만 충족하면 곧바로 재개해도 된다는 뜻은 아니다. 외부 의존성이 일시적으로 제한된 상황인지, 입력 데이터의 의미가 바뀌었는지, 잘못된 변환 로직이 반복 실패를 만들었는지에 따라 다음 행동은 달라진다. 공식 가이드도 일시적인 외부 장애나 할당량 제약을 해결한 뒤 처리할 수 있다는 이점을 설명하지만, 파이프라인 코드와 워커 구성을 바꾸는 일은 중단 상태에서 허용하지 않는다고 구분한다. 즉 원인 해결이 ‘외부 환경의 정상화’인지 ‘작업 정의의 변경’인지 먼저 나누어야 한다.

이 구분을 경력 기록에 가져오면 도구 사용 이력이 조금 더 정확해진다. “Dataflow Pause/Resume을 도입했다”보다 “배치 작업의 완료 범위와 외부 의존성 원인을 분리해 재개 조건을 문서화했다”가 실제 역할을 설명한다. 반대로 코드 버그를 고친 뒤 같은 작업을 이어서 돌렸다고 쓰는 것은 문서의 제한과 맞지 않을 수 있다. 할 수 없었던 일, 기존 절차로 되돌려야 했던 이유도 기록해야 과장되지 않는다.

3. 재개 전에 남길 세 가지 확인

아래 양식은 Google Cloud의 공식 운영 템플릿이나 검증된 경력 평가 도구가 아닙니다. 제품 문서의 조건을 팀의 실제 복구 판단과 연결하기 위해 만든 편집부 제안입니다.

# 배치 작업 재개 판단 기록

- **작업과 영향 범위**: [작업 목적, 입력·출력, 영향을 받는 하류 경로]
- **현재 상태와 완료 범위**: [완료로 확인한 단계, 재처리될 수 있는 항목, 확인 근거]
- **중단 원인 분류**: [외부 서비스·할당량·입력 데이터·파이프라인 로직·미확인]
- **제품 조건 확인**: [배치 작업, Shuffle, pause_on_failure 설정, 중단 중 구성 변경 여부]
- **재개 전 확인**: [외부 원인이 해소됐는지, 중복 처리·멱등성·알림 영향을 누가 확인했는지]
- **결정과 책임**: [재개 / 새 작업으로 재시작 / 설계 변경 / 취소, 결정자와 검토자]
- **남은 질문과 다음 검토**: [지금 확정하지 못한 조건, 확인 시점, 연결 문서]

양식의 핵심은 원인과 결정을 한 줄로 합치지 않는 데 있다. “할당량 오류였으니 재개”는 아직 판단의 일부다. 오류가 사라졌는지, 같은 작업 우선순위가 여전히 맞는지, 중단 중에 다른 팀이 입력을 수정하지 않았는지, 재개 시점이 서비스 영향과 충돌하지 않는지를 따로 확인해야 한다. 반대로 오류가 코드나 구성 변경을 요구한다면, 재개 버튼을 누르는 대신 새 버전의 작업으로 검증하는 경로가 더 적절할 수 있다.

개인이 이 문서를 혼자 승인하는 도구로 써서는 안 된다. 데이터 소유자, 플랫폼 운영자, 보안 또는 제품 담당자가 이미 정한 승인 경로가 있다면 그 문서에 연결하고, 자신이 실제로 한 확인과 아직 답을 받지 못한 질문을 구분한다. 이 기록은 책임을 개인에게 몰아주기 위한 서류가 아니라, 인수인계 때 판단의 맥락을 되살리는 공용 자산이다.

4. 재개와 재설계를 가르는 흐름

이 흐름은 실패를 자동 분류하는 알고리즘도, 모든 장애를 같은 방식으로 처리하는 표준도 아니다. Google Cloud 문서에는 작업 항목이 반복 실패하면 자동 중단될 수 있는 동작과, 할당량 오류처럼 자동 중단을 유발하지 않는 오류가 있다는 설명이 있다. 이를 운영자가 읽을 때는 “어떤 오류 코드면 무조건 재개”로 단순화하지 않는 것이 좋다. 자동 상태 전환과 사람이 해야 할 원인 분석은 서로 다른 층위다.

예컨대 외부 API의 일시적 제한이 해소됐고, 완료 출력과 재처리 범위가 확인됐으며, 기존 작업 정의를 바꿀 필요가 없다면 재개 후보가 될 수 있다. 반면 변환 로직이 잘못됐거나 워커 구성을 바꿔야 한다면, 중단 상태의 기존 작업을 이어 가려 하기보다 수정된 새 작업의 검증 범위를 다시 정하는 편이 정직하다. 어느 경로든 결론만 남기지 말고 ‘무엇을 확인해서 이 경로를 골랐는가’를 남겨야 다음 사람이 같은 판단을 검토할 수 있다.

▲ 실제 운영 대시보드나 복구 성과가 아니라, 재개 전에 대조할 질문과 두 의사결정 경로를 보여 주는 편집 이미지입니다.

5. 운영 경험을 과장 없이 경력 증거로 남기기

경력 문서나 회고에서 복구 경험은 쉽게 “장애를 해결했다”는 문장으로 축소된다. 하지만 이 문장은 원인을 직접 고쳤는지, 누가 결정을 승인했는지, 재개가 데이터 품질을 보장했는지까지 말해 주지 않는다. 더 좋은 기록은 결과를 크게 보이게 하는 문장이 아니라, 본인이 맡은 판단의 범위를 분명하게 하는 문장이다.

가령 자신이 실제로 한 일이 작업 상태와 완료 범위를 정리하고, 외부 의존성 담당자에게 확인을 요청하고, 재개 판단 기록의 초안을 작성한 것이라면 그 사실을 그대로 남긴다. 데이터 소유자가 출력 검증을 했거나 플랫폼 운영자가 실행을 승인했다면 그 기여도 분리한다. 재개하지 않고 새 작업으로 시작하기로 합의했다면, 그 선택은 실패가 아니라 작업 정의 변경과 상태 재사용을 섞지 않기 위한 결정일 수 있다. 단, 그 판단이 옳았다고 자동으로 보장되지는 않으며 사후 검토와 데이터 확인은 별도로 남아야 한다.

이 기록은 면접 답변이나 승진 자료에만 쓰는 개인 포트폴리오가 아니다. 다음 온콜 담당자가 상황을 이해하는 데 쓰고, 같은 종류의 외부 제한이 다시 생겼을 때 어떤 질문부터 확인할지 알려 주며, 플랫폼 팀이 기능의 제한을 발견하는 신호가 될 수 있다. 보안상 민감한 로그, 고객 식별자, 취약점 세부, 내부 URL은 원문에 복사하지 말고 접근이 통제된 기존 기록으로 연결해야 한다.

다음에 긴 배치 작업이 멈추면 우선 재개 버튼을 찾기 전에 한 문장만 적어 보자. “완료로 확인한 범위는 무엇이고, 이번 중단의 원인은 작업 정의 변경 없이 해소됐는가?” 답이 분명하면 기존 승인 경로에서 재개를 검토하고, 답이 모호하면 그 모호함을 다음 작업의 설계·검증 질문으로 넘긴다. 이 방법은 비용 절감이나 복구 성공을 보장하지 않는다. 다만 기능 사용 경험을 결과 자랑이 아닌, 검토 가능한 운영 판단으로 바꾸는 출발점은 될 수 있다. 작업이 끝난 뒤에는 기록의 가정도 다시 읽어야 한다. 재개 당시에는 알 수 없었던 출력 지연, 소비자 재처리, 승인 절차의 누락이 발견되면 기존 결론을 숨기지 말고 후속 메모에 갱신한다. 판단 기록은 결론을 고정하는 문서가 아니라, 다음 검토가 어디서 시작해야 하는지 알려 주는 문서다.

출처와 적용 범위

• Google Cloud Blog — Pause/Resume 및 G4 VM 발표 — 2026년 9월 14일 Dataflow 배치 작업 Pause/Resume의 일반 제공, 실패한 장기 배치 작업을 재개하는 맥락을 확인했다.
• Google Cloud Documentation — Pause a Dataflow job — 배치 작업 한정 지원, Shuffle·실행 옵션 조건, 중단 중 구성 변경 제한, 완료·진행 중 항목의 재처리 동작과 중단 상태를 확인했다. 이 글의 판단 기록 양식과 경력 적용 방식은 공식 기능 문서가 아닌 편집부 제안이다.