SQS에서 같은 작업이 다시 실행되면 visibility timeout부터 무작정 늘리지 마세요. 수신 시각, 업무 처리 완료 시각, 메시지 삭제 결과를 같은 작업 ID로 대조해야 긴 처리와 삭제 실패를 구분할 수 있습니다.
적용 환경: Amazon SQS를 직접 소비하는 작업자; Lambda 이벤트 소스 매핑의 별도 설정은 제외. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.
1. 원인: 처리 성공과 큐에서 삭제는 별개
수신한 메시지는 즉시 없어지지 않습니다. 잠시 다른 소비자에게 보이지 않다가, 삭제되지 않은 채 제한 시간이 끝나면 다시 받을 수 있습니다. 처리 성공 로그만 보고 큐의 완료까지 확정하면 이 구간을 놓칩니다.
예를 들어 보고서 파일 생성은 끝났지만 삭제 요청의 결과를 확인하지 못했다면, 다음 작업자는 이미 생성된 결과를 다시 만날 수 있습니다. 이는 확인용 가상 사례이며 실제 장애 재현 결과가 아닙니다.
2. 해결: 세 시점을 한 줄로 모읍니다
| 기록 | 확인할 질문 |
| 수신 시각 | 현재 적용된 제한 시간은 얼마인가? |
| 업무 완료 시각 | 완료 전에 비가시 시간이 끝났는가? |
| 삭제 결과 | 요청 성공을 확인했는가? |
| 업무 ID와 결과 | 이미 반영된 작업을 식별할 수 있는가? |
평균뿐 아니라 느린 작업과 외부 API 대기 시간을 보세요. 오래 걸리는 작업은 ChangeMessageVisibility로 연장하는 설계를 검토할 수 있습니다. 연장이 실패했거나 작업자가 죽었을 때의 처리도 함께 정해야 합니다. 제한 시간을 크게만 잡으면 실패 작업이 다시 나타나는 시점도 늦어집니다.
3. 확인: 시험 큐에서 다른 실패를 나눕니다
운영 메시지를 지우거나 강제로 실패시키지 말고 승인된 시험 큐와 가상 작업으로 점검하세요. 정상 완료, 처리 지연, 결과 반영 뒤 작업자 종료를 서로 다른 사례로 기록합니다. 각 사례에서 작업 결과가 중복 생성되는지와 재수신 시점을 비교합니다.
완료된 작업 ID를 재처리했을 때 기존 결과를 확인하는 멱등성 설계가 필요합니다. 타임아웃 설정만으로 업무 부수 효과가 한 번만 발생한다고 보장하지 않습니다.
4. 주의와 FAQ
FIFO로 바꾸면 해결되나요? 소비자 처리·삭제 실패의 경계는 별도로 검증해야 합니다. 큐 종류를 즉시 바꾸기보다 현재 실패 구간부터 확인하세요.
반복 실패 메시지는요? DLQ로 분리하는 정책과 조사·재처리 절차를 함께 설계합니다. DLQ 자체가 이미 발생한 업무 중복을 되돌리지는 않습니다.
설정 변경 전 기존 값을 기록하고 한 시험 작업에서 먼저 비교하세요. 결과 기록에는 민감한 메시지 본문 대신 필요한 식별자와 시각만 남깁니다.
공식 출처와 관련 글
'소프트웨어개발' 카테고리의 다른 글
| Lambda 비동기 재시도: 함수 오류와 스로틀링을 구분해야 하는 이유 (0) | 2026.10.26 |
|---|---|
| journalctl -b -1 로그가 없을 때: 이전 부팅 기록과 저장 방식 점검 (0) | 2026.10.24 |
| git stash 후 새 파일이 남을 때: 미추적 파일과 무시 파일 구분 (0) | 2026.10.24 |
