주기 폴링

폴링부터 WebRTC까지, 실시간 통신 방식을 하나씩 정리하는 시리즈의 첫 번째 글입니다.

널리 알려진 방식이기 때문에 새로운 기술을 소개하기 보다는, 실제 프로젝트에서 어떤 문제를 해결하기 위해 선택했고 사용하면서 어떤 하계를 느꼈는지에 초점을 맞췄습니다.

실시간 데이터 받아오기

프로젝트를 진행할 때 새로운 요구사항이 하나 있었습니다. 팀원 하나가 회의나 문서를 만들 때 다른 사용자의 화면에도 해당 데이터가 자동으로 반영되어야 했습니다. 기존에는 페이지를 새로고침 하거나 컴포넌트가 리마운트 될 때 데이터를 가져왔습니다.

그래서 다른 사용자가 방금 회의를 만들어도 내 화면에는 바로 나타나지 않았습니다. 처음에는 문제를 단순 데이터 조회 문제라고 생각했습니다. 그러나 진짜 문제는 "서버 상태가 변경되었을 때 클라이언트가 이를 어떻게 인지 하느냐" 였습니다.

우선 실시간으로 데이터를 전달하는 방법부터 찾아 봤습니다. 대표적인 방법은 폴링부터 SSE, WebSocket 등 여러 가지 방법이 있었습니다.

저희는 현재 서비스에 필요한 수준을 먼저 생각했습니다. 저희 서비스에서는 밀리초 단위의 실시간성이 필요하지 않았습니다. 사용자가 화면을 보고 있는 동안 새로운 데이터가 어느 정도만 빠르게 반영되면 충분했습니다. 그래서 굳이 처음부터 복잡한 통신 방식을 도입하지 않기로 했습니다.

가장 먼저 사용한 것은 폴링이었습니다. 기존 REST API를 그대로 사용할 수 있고 구현도 가장 단순하기에 비용적으로 적합하다고 판단했습니다. 폴링을 충분히 사용해본 후 실제 한계를 직면하면 다음 방식을 검토하기로 했습니다.

폴링이란?

폴링(Polling)은 보통 주기 폴링(Short Polling)을 뜻합니다. 주기 폴링은 일정한 간격으로 서버에 새로운 데이터를 요청하는 방식입니다. 예를 들어 5초마다 데이터를 조회해 최신 데이터가 있는지 확인합니다.

useEffect(() => { 
  const intervalId = setInterval(() => { 
    refetch(); 
  }, 5000); 

  return () => clearInterval(intervalId); 
}, [refetch]);

구조는 매우 단순합니다.

클라이언트가 일정한 간격으로 API를 호출하고 서버는 기존 REST API와 동일하게 응답합니다.

별도의 지속 연결을 유지하지 않아도 되고, 기존에 사용하던 HTTP API를 그대로 활용할 수 있다는 것도 장점입니다.

프로젝트 초반에 이런 간편함은 중요합니다. 새로운 프로토콜을 도입하거나 서버 구조를 바꾸지 않아도 기능을 빠르게 검증할 수 있기 때문입니다.

그리고 직접 적용해 보면서 또 하나의 장점을 알 수 있었습니다. 문제가 발생했을 때 확인하기 쉽습니다.