주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 5장 비동기 연동, 언제 어떻게 써야 할까

비동기는 단순히 “빠르게 만드는 기법”이 아니다.
정확히는 요청 처리 경로를 분리해서 사용자 응답 시간과 내부 처리 비용을 분리하는 설계 방식에 가깝다.

언제 비동기를 고려해야 하는가

• 요청 직후 반드시 끝날 필요가 없는 작업
• 오래 걸리는 외부 연동
• 대량 처리
• 실패해도 재시도 가능한 작업
• 사용자 경험과 분리해도 되는 후처리

예:

• 이메일 발송
• 푸시 알림
• 로그 적재
• 이미지/파일 처리
• 통계 집계

비동기를 잘못 쓰는 경우

• 정합성이 핵심인데 비동기로 넘겨 버림
• 결과 확인이 필요한데 eventually consistent로 흘려 보냄
• 재시도와 멱등성 없이 큐만 붙임
• 장애 추적 체계 없이 “나중에 처리”만 믿음

비동기 시스템에서 봐야 할 것

1. 전달 보장

• at-most-once
• at-least-once
• exactly-once는 실제론 매우 어렵다

그래서 대부분은 중복 허용 + 멱등 처리 전략으로 간다.

2. 순서 보장

메시지가 순서대로 와야 하는지 아닌지에 따라 설계가 크게 달라진다.

3. 실패 처리

• 재시도
• DLQ
• poison message 처리
• 운영자 알림

4. 적체

비동기 시스템은 병목이 사라지는 게 아니라 뒤로 밀릴 뿐이다.
큐 길이, 소비 속도, 지연 시간을 계속 봐야 한다.

동기 vs 비동기 판단 기준

• 사용자가 즉시 결과를 알아야 하는가
• 실패 시 바로 알려야 하는가
• 순서가 중요한가
• 중복을 허용할 수 있는가
• 지연을 감수해도 되는가

이 질문에 답한 뒤 결정해야 한다.

정리

비동기는 성능 최적화 기법이 아니라 처리 경계 조정 기법이다.
적절히 쓰면 응답 시간을 분리하고 확장성을 높일 수 있지만, 잘못 쓰면 정합성과 운영 복잡도만 키운다.