문서 본문을 Workflow 입력과 Activity 결과에 계속 넣으면 실행 이력에도 큰 데이터가 남을 수 있다. 그래서 본문 대신 문서 ID만 전달하자는 생각이 자연스럽다. 하지만 ID로 가리키는 원본이 나중에 수정되거나 삭제되면 같은 작업을 다시 실행할 때 다른 데이터를 읽거나 아무것도 읽지 못할 수 있다.
입력 크기를 줄이는 것과 재처리 가능한 데이터를 유지하는 것은 다른 문제다. Temporal 밖으로 데이터를 옮기면 저장과 보존의 책임도 함께 설계해야 한다. 단순히 이력이 작아졌다는 사실만으로 데이터 관리가 끝난 것은 아니다.
같은 ID가 같은 내용을 뜻하는가
가상 문서 처리에서 documentId로 항상 최신 문서를 읽는다고 하자. 변환 Activity 첫 시도는 수정 전 본문을 읽었다. 중간에 실패하고 문서가 수정된 뒤 재시도하면 두 번째 시도는 다른 본문을 읽을 수 있다.
이것을 무조건 오류라고 볼 수는 없다. 업무가 “항상 최신 본문을 처리한다”를 원할 수도 있다. 그러나 결과 저장 키는 같은데 입력이 달라지는 것을 허용할지, 예약한 허용량이 어떤 버전에 대응하는지, 사용자에게 어떤 결과를 보여줄지 정해야 한다.
특정 시점의 문서를 처리해야 한다면 문서 ID와 불변 버전을 함께 전달할 수 있다. 저장소가 그 버전의 내용을 유지하고 Activity가 정확한 버전을 읽어야 한다. 파일 경로나 URL에 버전처럼 보이는 문자열을 붙였다고 실제 불변성이 생기는 것은 아니다.
체크섬은 원본을 대신하지 않는다
문서의 체크섬을 입력에 추가하면 읽어 온 내용이 예상한 내용과 일치하는지 검사할 수 있다. 그러나 원본이 삭제됐을 때 체크섬만으로 문서를 복구할 수는 없다. 검증 정보와 데이터 보존을 구별해야 한다.
예제의 입력 계약은 다음처럼 생각할 수 있다. 구체 저장소의 기능을 전제하지 않는 개념 표현이다.
documentId: 업무 문서 식별자
documentVersion: 처리 대상으로 고정한 버전
contentDigest: 읽어 온 내용의 일치 여부 확인값
conversionVersion: 적용할 변환 규칙 버전여기에 접근 토큰이나 장기 자격증명을 무조건 넣지 않는다. Activity가 실행될 환경에서 필요한 접근 권한을 얻는 방법과, Workflow 입력으로 보존해야 할 업무 정보를 나눠서 설계한다. 만료되는 다운로드 URL을 영구 식별자로 사용하는 경우에도 재시도 시 접근 가능한지 확인해야 한다.
완료된 Activity 재생과 새 읽기를 구별한다
Activity 완료 결과가 이력에 남았다면 Workflow replay는 그 기록된 결과를 사용한다. 그때마다 원본 저장소를 다시 읽는 것은 아니다. 반면 아직 완료되지 않은 Activity의 재시도나 이후 새 Activity가 원본을 읽는 경우에는 외부 저장소의 현재 접근 가능성이 영향을 준다.
이 구분을 놓치면 원본을 삭제해도 모든 복구가 실패한다고 과장하거나, 반대로 History만 있으면 어떤 재처리도 가능하다고 오해할 수 있다. 결과에 무엇을 기록했는지와 다음 단계가 무엇을 다시 읽어야 하는지에 따라 다르다.
변환 Activity가 결과 본문 대신 결과 저장 위치만 반환했다면 이후 저장·확정 단계에서 그 위치가 계속 유효해야 한다. 임시 파일이 Worker 로컬 디스크에만 있다면 다른 Worker의 재시도에서 읽을 수 있는지도 문제다. 참조하는 저장 위치의 생애를 코드 실행 수명과 비교해야 한다.
원본을 바꾸거나 지워 본다
대표 실패 실험은 Activity 첫 시도 뒤 원본 내용을 바꾸고 재시도를 실행하는 것이다. 최신 ID만 쓰는 구성과 불변 버전을 읽는 구성을 비교한다. 반환 내용, 체크섬, 최종 결과 키가 어떻게 달라지는지 남긴다.
다음으로 원본 버전을 삭제해 본다. 이미 완료된 Activity 결과를 사용하는 replay와 새로 원본을 읽는 작업의 결과를 구별한다. 이 실험은 실습용 생성 문서로만 수행하며 삭제한 원본을 되살릴 방법을 미리 확보한다.
예상하지 않은 결과가 나오면 먼저 실제로 새 Activity가 실행됐는지 확인한다. 완료된 결과를 재사용한 replay였다면 외부 조회가 일어나지 않았을 수 있다. 원본 삭제가 반영되지 않았다는 이유로 저장소 삭제 실패라고 결론 내리지 않는다.
보존 기간은 실행 시간보다 넓게 생각한다
원본은 최소한 진행 중인 실행이 사용할 동안 남아 있어야 한다. 여기에 재시도, 수동 복구, 새 규칙으로 재처리, 감사 요구가 더해질 수 있다. 이 중 무엇을 지원할지 정한 뒤 원본과 결과, 이력 각각의 보존 정책을 맞춘다.
반대로 모든 원본을 영원히 보관하는 것도 자동 정답은 아니다. 삭제 요구가 있는 데이터라면 어떤 실행을 더 이상 재처리할 수 없는지 표시하고, 참조가 남은 경우 어떤 실패를 반환할지 정의해야 한다. “ID만 저장했으니 민감정보가 없다”는 결론도 별도 검토가 필요하다.
확인 질문: 체크섬은 맞지만 원본이 삭제됐다면 어떤 복구가 가능한가? Activity가 반환한 결과 위치를 다른 Worker도 읽을 수 있어야 하는 이유는 무엇일까?