#1 파일 처리에 웹소켓보다 폴링을 선택한 이유

Source: Dev.to

파일 변환 및 공유 앱을 만들면서, 사용자에게 파일 처리 상태를 보여줄 방법이 필요했습니다.
처음에는 WebSocket을 떠올렸습니다.
실시간 업데이트가 가장 명백한 선택처럼 보였죠.
하지만 실제 요구사항을 생각해보니, 사용자는 즉각적인 푸시 알림이 아니라 변환이 끝났는지 여부에 대한 가끔씩의 피드백만 필요하다는 것을 깨달았습니다.
그래서 2초마다 폴링하기로 했습니다.
흐름은 다음과 같이 바뀌었습니다:
업로드 → 작업 대기 (BullMQ) → 워커가 파일 처리 → 프론트엔드가 상태를 폴링 → 결과 준비 완료

여기서 폴링이 더 잘 맞았던 이유:

• 구조가 단순함
• 지속적인 연결을 관리할 필요 없음
• 워커와 소켓 서버 사이의 통신 레이어가 없음
• 디버깅과 이해가 쉬움

트레이드오프:

• HTTP 요청이 더 많아짐
• 사용자는 처리 완료될 때까지 계속 폴링함
• 저지연이나 협업 경험에는 적합하지 않음

채팅, 실시간 협업, 즉시 알림 같은 요구사항이 생기면 다시 WebSocket을 고려하겠습니다.
이 경험은 아키텍처 선택이 기술 선호보다 요구사항에 더 크게 좌우된다는 좋은 교훈이었습니다.