❓ 왜 비동기가 필요할까?
1. 사용자 경험(UX) 개선
- 동기 처리: 요청 동안 인터페이스 멈춤, 전체 리로드 → UX 저하
- 비동기 처리: 필요한 부분만 갱신, 반응성 높은 UI 제공
동기 처리
사용자 요청
↓
[서버 처리 중...]
↓
전체 페이지 응답 (페이지 깜빡임, 응답 지연)
비동기 처리
사용자 요청 (fetch)
↓
서버 처리 (백그라운드)
↓ ✅ UI는 멈추지 않음
필요한 영역만 업데이트 (해당 부분만 렌더링, 빠르고 부드러운 UX)
2. 병렬 처리 & 자원 효율
동기(Sync) 처리: I/O 블로킹
- 요청이 들어오면 작업 스레드 하나를 할당
- 서버는 I/O 작업 결과가 올 때까지 기다림.
- 기다리는 동안 스레드는 블로킹 상태 → CPU 낭비
- 동시 요청이 많으면? ⇒ 스레드 수가 부족, 서버가 느려짐
요청 A → [스레드 A] DB 요청... (대기 중)
요청 B → [대기 중] (A가 끝날 때까지 처리 못함)
비동기(Async) 처리: I/O 동안 대기 안 함
- 하나의 메인 스레드가 모든 요청을 받아서
- 시간이 오래 걸리는 I/O는 OS에 위임
- 응답이 도착할 때까지만 기다리지 않고 다른 요청을 먼저 처리하거나, 콜백/이벤트로 이어서 처리
- 하나의 스레드로도 수많은 요청을 동시에 처리할 수 있음
요청 A → DB 요청 (비동기)
요청 B → 즉시 처리 가능
↓
DB 응답 도착 → 이어서 A 처리 (스레드 재배정 or 이벤트 큐)
| 동기 처리 | 비동기 처리 | |
|---|---|---|
| 요청 처리 방식 | 완료될 때까지 기다림 | 응답 올 때까지 대기 안 함 |
| 스레드 점유 | 요청당 1개 | 요청당 점유 안 함 |
| 처리량 | 적음 (스레드 한계) | 많음 (병렬 처리 효과) |
| I/O 대기 시 | 스레드 낭비 | 스레드 반환 |
| 메모리/CPU 효율 | 낮음 | 높음 |
| 확장성 | 낮음 | 높음 |
3. 실시간 인터랙션
- 실시간 알림, 채팅, 피드 갱신 등
- WebSocket, SSE(Server-Sent Events)를 통한 실시간 피드백
- Slack, Gmail 알림 등
동기 방식으로 하면?
👉 서버에 불필요한 요청이 많고, 딜레이가 생길 수 있음. 비동기로 이벤트가 발생할 때만 푸시하는게 좋다.
단점
- 디버깅 어려움
- 흐름이 끊기거나 콜백 중첩 시 추적 어려움
- 예외 처리 복잡
try-catch보다.catch()나async/await필요
- 순서 보장 어려움
- 실행 순서가 비보장되므로 흐름 제어 필요
동기(Sync) VS 비동기(Async)
동기(Sync)
-
처리 순서가 중요할 때
이전 작업이 끝나야 다음 작업을 할 수 있는 경우 (예: 결제 처리 → 주문 등록)
-
로직이 단순하고 직관성이 중요한 경우
빠르게 개발해야 하거나, 복잡도보다 안정성을 우선할 때
-
동기화된 리소스를 다룰 때
트랜잭션, DB 락 등 데이터 일관성이 중요한 작업
비동기(Async)
-
UI 반응성을 높이고 싶을 때
화면이 멈추지 않고 빠르게 응답해야 하는 UX 요구 (SPA, 대시보드, 검색 등)
-
병렬로 처리 가능한 작업이 있을 때
외부 API 여러 개를 동시에 호출, 대용량 작업을 나눠 처리할 때
-
I/O 중심 로직이 많은 경우
DB, 파일, 네트워크 호출처럼 대기 시간이 긴 작업을 효율적으로 처리해야 할 때
| 추천 방식 | 이유 | |
|---|---|---|
| 단일 사용자 요청, 트랜잭션 중요 | 동기 | 안정성과 예측 가능성 |
| 많은 사용자, 빠른 응답 필요 | 비동기 | UI 반응성 & 리소스 절약 |
| 외부 API 여러 개 호출 | 비동기 | 병렬 처리 가능 |
| 단순한 조회 페이지 | 동기 또는 비동기 | 둘 다 가능, 개발 편의 vs UX 선택 |
https://inpa.tistory.com/entry/👩💻-동기비동기-블로킹논블로킹-개념-정리
https://miki3079.tistory.com/141
https://dev-coco.tistory.com/46