[Cloudflare Queues][운영] replay owner를 정한 뒤 failed message dump 파일명과 reviewer 메모를 어떤 incident row로 같이 고정하나

IT 리서치 노트

[Cloudflare Queues][운영] replay owner를 정한 뒤 failed message dump 파일명과 reviewer 메모를 어떤 incident row로 같이 고정하나

Cloudflare Queues에서 replay owner와 failed position까지 정했는데, 실제 failed message dump 파일명과 reviewer 메모가 별도 문서로 흩어지면 같은 사고를 다시 설명하게 된다. 2026년 8월 31일 KST 기준 Cloudflare 공식 문서를 다시 보면 pull API는 incident 재현에 필요한 message, attempts, lease, backlog 메트릭을 함께 주고, dashboard preview는 acknowledge나 retry를 일으키지 않는다. 이 글은 replay owner를 정한 뒤 failed message dump 파일명과 reviewer 메모를 어떤 incident row로 같이 고정해야 하는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 replay owner를 정한 뒤에는 failed dump 파일명과 reviewer 메모를 같은 incident row에 붙여야 한다. owner만 남기면 어떤 산출물을 근거로 replay를 승인했는지 끊기고, dump만 남기면 누가 언제 어떤 이유로 replay를 보류했는지 끊긴다.

특히 pull consumer에서는 message id, attempts, lease_id, backlog 메트릭을 같이 읽을 수 있으므로 dump 파일명은 단순 첨부물이 아니라 재현 키 역할을 한다. reviewer 메모도 preview 확인 시각, ack scope, replay blocker를 한 줄로 묶는 편이 안전하다.

2. 어디서 실제로 막히는가

현장에서 자주 꼬이는 지점은 세 가지다. 첫째, failed message body만 저장하고 message id와 attempts를 빼먹는다. 둘째, replay owner는 적었는데 reviewer가 다시 확인한 preview 시각과 dump 파일명은 안 남긴다. 셋째, 일부 ack가 끝난 뒤 실패한 사고인데 batch 전체를 하나의 메모로 적는다.

Cloudflare 문서는 pull API 응답에 message id, attempts, lease_id, timestamp_ms, oldest_message_timestamp_ms를 함께 노출하고, dashboard preview는 메시지 position을 바꾸지 않는다고 설명한다. 이 둘을 합치면 reviewer 메모는 단순 코멘트가 아니라 어떤 dump를 어떤 읽기 경로에서 확보했는지까지 남겨야 한다.

문제는 실제 운영에서 dump 파일은 스토리지에, replay 판단은 티켓에, reviewer 코멘트는 채팅에 흩어지는 경우가 많다는 점이다. 이렇게 되면 다음 사람이 같은 incident를 볼 때 어느 dump가 pre-replay 증거였는지, 어느 시점에서 duplicate check를 했는지 다시 물어보게 된다.

• 증상: replay 근거 파일은 있는데 승인 메모가 없다.
• 실패: dump 파일명과 reviewer 메모를 다른 시스템에 따로 남긴다.
• 막힘: 일부 ack 뒤 실패를 batch 전체 사고처럼 적는다.
• 누락: preview 확인 시각과 duplicate check 결과를 같은 row에 안 둔다.

겉으로 보이는 현상	같이 남겨야 할 값	판단 기준
replay 승인 이유가 모호하다	dump 파일명, reviewer 메모	어떤 evidence로 승인했는지 본다
같은 사고를 다시 자른다	message id, attempts, lease_id	실패 메시지를 재현할 수 있는지 본다
duplicate check 위치가 모호하다	preview 시각, post-replay check 결과	replay 전후 증거를 분리한다

3. 실무에서 적용하는 순서

가장 짧은 운영 순서는 다섯 단계다. 먼저 failed message id와 attempts가 들어간 dump 파일명을 만든다. 다음으로 preview 확인 시각과 읽기 경로를 reviewer 메모에 적는다. 세 번째로 replay owner와 reviewer를 분리한다. 네 번째로 next action과 replay blocker를 같은 row에 넣는다. 마지막으로 replay 뒤 duplicate check 결과까지 같은 incident row에 추가한다.

1. failed message id와 attempts를 포함한 dump 파일명 규칙을 고정한다.
2. preview 확인 시각과 ack 영향 없음 여부를 reviewer 메모에 적는다.
3. replay owner와 reviewer를 별도 칸으로 둔다.
4. next action과 blocker를 같은 row에 묶는다.
5. replay 뒤 duplicate check 결과를 closure 필드로 덧붙인다.

이렇게 하면 replay 판단이 채팅 로그에 묻히지 않는다. 특히 failed position과 owner를 이미 정리한 팀이라면, 이번 단계에서 dump 파일명과 reviewer 메모를 같이 규격화해야 incident handoff 시간이 짧아진다. reviewer가 보는 대상이 batch 전체인지 특정 failed message인지도 자연스럽게 분리된다.

failed_dump_file=dlq-2026-08-31-msg901-pre-replay.json
preview_checked_at=2026-08-31T10:22:00+09:00
replay_owner=queue-ops
reviewer=incident-lead
duplicate_check=required-before-replay

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 pull API 응답 구조다. Cloudflare는 message id, attempts, lease_id, timestamp_ms, 그리고 backlog_count와 oldest_message_timestamp_ms 같은 메트릭 필드를 함께 노출한다.

pull API 응답에는 message id와 attempts뿐 아니라 lease_id와 oldest_message_timestamp_ms 같은 incident 재현 필드가 같이 있다.

즉 failed dump를 남길 때는 body만 저장하면 부족하다. 어떤 메시지였는지, 몇 번째 시도였는지, 어느 시점 backlog였는지를 같은 row에서 다시 읽을 수 있어야 한다.

두 번째 자료는 dashboard preview 문서다. preview fetch는 acknowledge나 retry를 일으키지 않는다고 문서가 직접 적는다.

dashboard preview는 queue position을 바꾸지 않으므로 failed message dump를 따로 보관할 때 유용한 읽기 경로가 된다.

그래서 운영 메모에서 reviewer가 다시 확인할 자료를 남길 때는 live replay 전에 preview 기준 dump 이름과 확인 시각을 먼저 적는 편이 안전하다.

세 번째 자료는 pull consumers 문서다. 문서는 여러 번 ack를 호출할 수 있지만 API 호출 수를 줄이려면 grouping acknowledgements를 권장한다고 설명한다.

ack를 묶어 처리할 수 있다는 전제 때문에 failed message dump와 reviewer 메모는 batch 전체가 아니라 실제 실패 지점 기준으로 남겨야 한다.

일부 ack가 이미 끝난 상태라면 batch 이름 하나로 사고를 적어서는 안 된다. reviewer가 다시 볼 기준도 ack 이후 남은 메시지 집합 기준으로 구분해야 한다.

실무에서는 dump 파일명 규칙과 reviewer 메모 필드가 자주 흩어진다. 아래 표는 replay owner를 정한 뒤 같은 incident row에 무엇을 같이 묶을지 정리한 예시다.

failed dump 파일명과 reviewer 메모를 같은 incident row에 붙이면 replay 보류와 승인 이력이 짧아진다.

이미 failed position과 replay owner 글이 누가 무엇을 소유하는지 정리했다면, 이번 글은 실제 산출물 이름과 reviewer 메모 필드까지 한 줄로 닫는 후속편이다.

마지막 자료는 reviewer 메모 JSON 예시다. 핵심은 dump 파일명, failed message id, 승인자, next action이 따로 흩어지지 않게 만드는 것이다.

reviewer 메모는 dump 파일명과 replay 판단 값을 같이 담아야 다음 사람이 같은 incident를 다시 자르지 않는다.

이 형식이 있으면 post 436의 tail-message field, post 439의 disposition 표, post 442의 replay-owner row가 한 closure 흐름으로 이어진다.

5. 주의사항과 리스크

첫 번째 리스크는 dump 파일명에 message id나 attempts를 넣지 않아 나중에 같은 메시지인지 구분이 안 되는 것이다. 두 번째 리스크는 preview와 live replay를 같은 evidence처럼 적어 duplicate check 시점을 모호하게 만드는 것이다. 세 번째 리스크는 reviewer 메모를 자유문장으로만 남겨 post-replay closure까지 이어지지 않는 것이다.

운영 전에는 최소한 dump 파일명 규칙, preview 확인 시각, replay owner, reviewer, duplicate check 결과 다섯 칸을 같은 JSON 또는 표로 남기는 편이 좋다. 그래야 다음 incident에서도 같은 구조를 복사해 쓸 수 있다.

• dump 파일명은 failed message를 다시 찾을 수 있게 만든다.
• preview evidence와 replay evidence를 같은 칸으로 섞지 않는다.
• reviewer 메모는 자유문장보다 row 구조로 남긴다.

6. 결론

Cloudflare Queues replay 운영에서 owner만 남기거나 dump만 남기면 closure가 항상 끊긴다. failed message dump 파일명, reviewer 메모, replay owner, duplicate check 결과를 같은 incident row에 붙이면 replay 보류와 승인 기록이 훨씬 짧아진다.

여기서 incident를 실제로 닫는 기준까지 이어 가려면 새 후속 글인 DLQ replay 뒤 duplicate check 결과와 idempotency 메모를 어떤 closure row로 남길지 정리한 글을 함께 보면 좋다. 이번 글이 dump와 reviewer 메모를 고정하는 단계였다면, 후속 글은 close와 manual review를 어디서 갈라야 하는지 채워 준다.

• dump 파일명과 reviewer 메모를 같은 row에 둔다.
• preview 시각과 replay blocker를 분리해서 남긴다.
• closure까지 같은 incident row로 이어 붙인다.

7. 참고 링크

1. https://developers.cloudflare.com/api/resources/queues/subresources/messages/methods/pull/
2. https://developers.cloudflare.com/queues/examples/list-messages-from-dash/
3. https://developers.cloudflare.com/queues/configuration/pull-consumers/
4. https://developers.cloudflare.com/queues/configuration/dead-letter-queues/
5. https://developers.cloudflare.com/queues/configuration/batching-retries/