큐는 비동기 처리 도구이기 전에 실패를 보관하는 장소입니다

큐를 쓰면 작업이 사라지지 않지만, 재시도와 중복 처리 규칙을 반드시 정해야 합니다.

무거운 작업을 큐로 보내면 API 응답은 빨라집니다.
사용자는 바로 “접수됨”을 봅니다.
하지만 작업이 사라진 건 아닙니다.
위치만 바뀌었습니다.
큐는 느린 일을 뒤로 미루는 도구이면서, 실패한 일을 잃어버리지 않게 붙잡는 장소입니다.

한 번만 처리된다는 말은 대개 위험합니다

많은 큐 시스템은 적어도 한 번 전달을 기본으로 생각하는 편이 안전합니다.
소비자가 처리 후 ACK를 보내기 전에 죽으면 같은 메시지가 다시 올 수 있습니다.
그래서 소비자 로직은 중복 처리에 강해야 합니다.
멱등성 키, 처리 로그, 유니크 제약이 여기서 다시 등장합니다.

재시도는 친절하지만 폭주할 수 있습니다

실패한 작업을 바로 재시도하면 일시적인 장애에는 도움이 됩니다.
하지만 외부 API가 죽어 있는데 모든 작업이 즉시 재시도되면 장애를 더 키웁니다.
지수 백오프, 최대 재시도 횟수, 데드레터 큐가 필요한 이유입니다.
재시도는 “언젠가 되겠지”가 아니라 실패를 어떻게 관찰할지까지 포함합니다.

큐의 성공은 처리 완료로 봐야 합니다

메시지를 큐에 넣었다고 끝난 게 아닙니다.
소비자가 실제로 처리했고, 실패한 메시지는 어디에 남았고, 오래된 메시지는 몇 개인지 봐야 합니다.
큐를 도입하면 API는 단순해질 수 있지만 운영 질문은 늘어납니다.
그 질문을 감당할 때 큐가 도움이 됩니다.

마지막으로 확인할 것은 하나입니다.
이 개념을 외웠는지가 아니라, 실패했을 때 어떤 상태가 남는지 설명할 수 있는지입니다.