[1주차] 펀딩 프로그래스 업데이트를 위한 실시간 데이터 동기화 기술

앞으로 진행할 프로젝트의 팀원들을 만나 그라운드 룰과 주제를 정하는 시간을 가졌다! 아이디에이션 끝에 "택시비 펀딩"을 주제로 한 프로젝트를 진행하게 됐다. 이렇게 빨리 정해진 적은 없었던 것 같은데... 너무 재미있을 것 같다.

 

 

요구사항

펀딩 프로그래스 업데이트에 대해 어떻게 처리해야 할 지에 대한 논의가 이루어졌다. 아래와 같은 상황이다.

 

1. 사용자 B가 펀딩 X에 접근. 총 목표 금액이 50000원임을 확인.

2. 사용자 A가 펀딩 X에 1000원 후원.

3. 사용자 B는 화면을 새로고침 하지 않아도, 펀딩 X의 초기 금액에서 1000원이 차감된 "49000원" 화면과 + 늘어난 진행도를 볼 수 있어야 함!

 

위와 같은 기능 구현을 위해, 서버에서 클라이언트로 실시간 이벤트를 전송할 수 있는 기술들을 조사했다.

 

 

Polling, Long Polling

(옛날 방식들..)

1. Polling

가장 기본적인 데이터 처리방식으로, 클라이언트가 특정 주기를 가지고 서버에 http request

장단점

• 언제 통신이 발생할지 예측이 불가능하여 클라이언트가 요청을 계속해서 하게 됨
• 클라이언트가 많아지면 서버 부담 급증
• 빠른 응답을 기대하기는 어려움 (특정 주기마다 업데이트 하기 때문에)

➡️ 서버, 클라 양측에 부담 + 심지어 응답도 느림

 

2. Long Polling

• 클라이언트에서 서버로 일단 http request를 보내고 이 상태로 계속 기다리다가,
• 서버가 업데이트되면 그 순간 response를 전달하며 연결이 종료
• 서버의 응답을 받자마자 클라이언트는 새로운 http request를 보내는 과정이 반복

장단점

• 즉각적으로 데이터가 갱신
• Polling의 불필요한 네트워크 트래픽과 서버 부하를 줄여줌 (업데이트 되었을 때만 응답하니까..), 그런데 많은 양의 메세지가 올 경우 Polling과 별 차이가 없게 됨
• 클라이언트가 많아지면 여전히 서버 부담 급증

➡️ 서버 부담 + 보내는 요청이 많아지면 폴링과 똑같이 클라 부담

 

 

단방향 통신

서버 업데이트를 클라이언트로 푸시하는 단방향 통신으로, HTTP Streaming에 포함된다.

• 클라이언트에서 서버로 http request를 보냄 (연결 요청)
• 서버에서 클라이언트로 이벤트를 전달할 때, 해당 요청을 끊지 않고 필요한 데이터를 계속해서 보냄

1. Server-Sent Events(SSE)

서버에서 클라이언트로 이벤트를 보내는 HTML5 표준기술

장단점

• 서버에서 메세지를 보내고 나서 다시 http request연결을 하지 않아도 되어 Long Polling에 비해 부담 감소
• 재접속 처리 같은 대부분의 저수준 처리가 자동으로 지원
• 바이너리 데이터 전송 불가
• http1.1의 경우 동접(탭 6개 제한)

 

2. HTTP/2 Server Push

장단점

 

 

양방향 통신

클라이언트와 서버 간의 수명이 긴 단일 연결을 통해 양방향(full-duplex) 통신 채널을 제공

Web Socket

• 웹소켓 연결을 위해 클라이언트에서 서버, 서버에서 클라이언트로 통신 (handshake)
• 성공적으로 이루어지면 HTTP에서 웹소켓으로 변경하는 프로토콜 스위칭
• 소켓 생성, 양방향 통신

 

 

WebTransport  API

QUIC HTTP/3 프로토콜을 사용하여 단방향, 양방향 통신이 가능한 Web API

장단점

• 낮은 지연 시간과 높은 처리량 (실시간 애플리케이션을 위해 특별히 설계된 프로토콜을 도입)
• QUIC의 보안 메커니즘을 통합하여 데이터의 기밀성과 무결성을 보장
• 사파리 미지원 (2025년 1월 기준)
• 이뿐만 아니라 공식 문서를 살펴보면 미지원되는게 너무 많다... 더 발전될 때까지 지켜보자 👀

 

 

결론

결국 범용성과 성능을 고려했을 때, 사용할 기술을 처음 팀원들과 이야기했던 웹소켓과 SSE로 좁힐 수 있었다.

그리고 아래와 같은 이유로 SSE로 구현하는 것이 적합하다는 결론을 내렸다.

• 클라이언트에서 서버로의 요청은 펀딩 시에만 이루어짐. 단발성이기 때문에 기존의 HTTP RESTful API에 적합. 즉 펀딩에 관한 정보만 실시간으로 서버에서 클라이언트로만 전송하면 됨
• 자동 재접속 가능
• 배터리 소모량이 웹소켓보다 적음

 

팀원들과 논의 후 결정된 기술을 더 자세히 공부해 봐야겠따! 🕶️