웹 서비스를 기획하다 보면 "실시간" 기능에 대한 요구사항이 자주 등장합니다. 채팅, 알림, 대시보드 자동 갱신, 협업 편집 등. 이때 기술적으로 가장 먼저 만나는 분기점이 REST API와 웹소켓의 선택입니다. 이 두 기술은 근본적으로 다른 통신 방식이며, 잘못 선택하면 불필요한 복잡성과 비용을 떠안게 됩니다.

반대로 올바르게 선택하면 최소한의 리소스로 최적의 사용자 경험을 만들 수 있습니다.

REST API는 문자 메시지입니다

REST API는 클라이언트가 묻고 서버가 답하는 요청-응답 구조입니다. 문자 메시지를 주고받는 것과 같습니다. 메시지를 보내고, 답장을 기다리고, 답장이 오면 대화가 끝납니다. 각 요청은 완전히 독립적이며 이전 요청의 맥락을 기억하지 않습니다.

상품 목록을 불러오고, 주문을 생성하고, 사용자 정보를 조회하거나 수정하는 등 대부분의 웹 기능이 이 방식으로 충분합니다. 구현이 직관적이고, 브라우저 개발자 도구에서 요청과 응답을 명확하게 확인할 수 있어 디버깅이 쉽습니다.

HTTP 표준을 따르기 때문에 캐싱, 로드밸런싱, 모니터링 등 생태계가 매우 성숙해 있습니다. 웹 서비스의 90% 이상이 REST API만으로 완벽하게 동작합니다.

웹소켓은 전화 통화입니다

웹소켓(WebSocket)은 한 번 연결되면 끊기지 않는 양방향 통신 채널입니다. 전화 통화처럼 양쪽이 언제든 말할 수 있습니다. 핵심은 서버가 클라이언트에게 먼저 데이터를 보낼 수 있다는 것입니다. REST에서는 반드시 클라이언트가 먼저 요청해야 서버가 응답하지만, 웹소켓에서는 서버 측에 새로운 이벤트가 발생하면 연결된 모든 클라이언트에게 즉시 데이터를 전달합니다.

채팅 메시지가 도착하면 즉시 화면에 표시되고, 주식 가격이 변하면 그래프가 실시간으로 업데이트되며, 다른 사용자가 문서를 수정하면 내 화면에도 즉시 반영됩니다.

웹소켓이 정말 필요한 경우와 그렇지 않은 경우

라이브 채팅은 웹소켓의 가장 대표적인 사용 사례입니다. 메시지가 전송되는 순간 상대방 화면에 나타나야 합니다. 실시간 대시보드도 해당됩니다. 주차장 점유율 모니터링이나 서버 상태 대시보드처럼 데이터가 초 단위로 변하는 화면에는 웹소켓이 적합합니다.

동시 편집 기능도 마찬가지입니다. Google Docs처럼 여러 사람이 동시에 같은 문서를 수정하면서 서로의 편집 내용을 즉시 볼 수 있는 경험은 양방향 실시간 통신 없이는 불가능합니다. 멀티플레이어 게임, 실시간 경매, 라이브 스포츠 스코어보드도 웹소켓이 필요한 영역입니다.

반면 주문 내역 조회, 회원 정보 수정, 게시글 작성, 검색 같은 기능에 웹소켓을 쓰는 것은 과잉 설계입니다.

그런데 흥미롭게도 같은 "실시간 채팅"이라도 서비스마다 다른 기술을 씁니다. 실제 시스템들이 어떻게 만들어졌는지 봅니다.

실제 소켓으로 만든 시스템들

카카오톡: 자체 TCP 프로토콜 LOCO

초기 카카오톡은 일반 HTTP 폴링 기반이었지만, 전 국민 메신저로 트래픽이 폭증하면서 구조 자체를 바꿨습니다. 지금은 LOCO라는 자체 바이너리 프로토콜을 TCP 소켓 위에서 운용합니다. 패킷 헤더를 한 바이트까지 줄여 모바일 데이터 비용을 통제하고, 메시지 도달 보장을 자체적으로 구현합니다. WebSocket이 아니라 raw TCP를 쓰는 이유는 패킷 오버헤드를 한계까지 줄이기 위해서입니다.

비슷한 길을 간 글로벌 메신저들이 있습니다. 페이스북 메신저는 MQTT(IoT용 경량 프로토콜), 텔레그램은 자체 MTProto. 모두 일반 WebSocket으로는 비용·지연을 못 잡아 자체 프로토콜로 갔습니다.

슬랙: WebSocket 하나로 워크스페이스 통째

사용자가 슬랙에 로그인하면 단 하나의 WebSocket 연결이 열리고, 그 위에서 모든 채널·DM·타이핑 표시·온라인 상태가 멀티플렉싱됩니다. 채널이 100개여도 연결은 1개입니다. WebSocket 위에 자체 이벤트 라우팅 레이어를 올려서 어떤 채널의 누구에게 가는 메시지인지 구분합니다. 사용자 1명당 자원을 최소화하면서 수백만 동시 접속을 받는 설계입니다.

증권·코인 시세: 초고빈도 푸시 WebSocket

바이낸스·업비트·토스증권의 실시간 호가창. 서버에서 클라이언트로 초당 수백 건의 가격 업데이트가 흘러옵니다. 폴링으로는 불가능한 빈도이고, WebSocket이 사실상 유일한 답입니다. 데이터를 JSON이 아니라 바이너리(MessagePack, Protocol Buffers)로 압축해 전송 비용을 한 번 더 줄이는 것도 흔합니다.

이렇게 진짜 소켓 위에서 만든 시스템이 있는 반면, 화면에서는 실시간처럼 보여도 안에서는 다른 기술을 쓰는 사례도 있습니다.

소켓처럼 보이지만 실은 다른 기술

유튜브 라이브 채팅: long polling + SSE

화면에서는 메시지가 실시간으로 흘러내려 가지만, 안에서는 클라이언트가 짧은 주기로 HTTP 요청을 반복합니다. WebSocket이 아닙니다. 동시 접속 수백만 단위에서는 양방향 WebSocket 연결을 모두 유지하는 비용이 폴링보다 큽니다. "메시지가 1-2초 늦어도 무방"하다는 비즈니스 특성이 기술 선택을 바꿉니다.

같은 "실시간 채팅"이지만 슬랙(WebSocket)과 유튜브(폴링)가 다른 답을 쓴 이유가 여기 있습니다. "실시간이니까 WebSocket"이 아니라, 지연 허용치·동시 접속 수·메시지 빈도를 같이 보고 결정해야 합니다.

구글 닥스 동시 편집: WebSocket + 충돌 해결 알고리즘

다른 사람의 커서가 움직이고 글자가 실시간으로 입력되는 그 경험. 양방향 실시간 통신이 전제이지만, 그것만으로는 동시 편집이 안 됩니다. WebSocket으로 변경 사항을 주고받는 동시에 OT(Operational Transformation) 또는 CRDT라는 동시 편집 알고리즘이 함께 돌아갑니다. 두 사람이 같은 위치에 동시에 글자를 끼워 넣어도 결과가 양쪽에서 같아야 하는데, 이걸 보장하는 건 알고리즘입니다. 소켓은 통로, 알고리즘은 핵심. 둘이 함께 있어야 동시 편집이 됩니다.

흔한 실수: 모든 것을 웹소켓으로 처리하기

웹소켓의 매력에 빠지면 모든 통신을 웹소켓으로 하고 싶어집니다. 이것은 흔하지만 비용이 큰 실수입니다. 웹소켓은 연결을 계속 유지해야 하므로 서버 메모리를 지속적으로 소비합니다. 동시 접속 1,000명의 웹소켓 연결을 유지하려면 같은 수의 REST 사용자를 처리하는 것보다 훨씬 많은 서버 리소스가 필요합니다.

디버깅 난이도도 높아집니다. REST는 각 요청이 독립적이라 문제 지점을 특정하기 쉽지만, 웹소켓은 양방향으로 데이터가 흐르고 상태가 유지되므로 버그 추적이 복잡합니다. 연결이 끊어졌을 때의 재연결 로직, 클라이언트 간 상태 동기화, 에러 처리 등 고려할 사항이 REST 대비 몇 배로 늘어납니다.

중간 지점: SSE와 하이브리드 접근

Server-Sent Events(SSE)라는 선택지도 있습니다. 서버에서 클라이언트 방향으로만 데이터를 보내는 단방향 스트리밍입니다. 라이브 피드, 알림, 실시간 로그 출력 같은 기능에 적합하며, 웹소켓보다 구현과 운영이 훨씬 간단합니다.

HTTP 기반이므로 기존 인프라를 그대로 사용할 수 있고 캐싱도 가능합니다. 현실적으로 가장 좋은 접근은 하이브리드 방식입니다. 시스템 전체는 REST API로 견고하게 구축하고, 실시간이 진짜 필요한 특정 기능에만 웹소켓이나 SSE를 추가합니다.

프로덕트 메이커의 판단 기준

프로덕트 메이커는 REST API를 모든 시스템의 근간으로 사용합니다. 웹소켓이나 SSE는 실시간이 비즈니스 가치에 직접 연결되는 기능에만 선별적으로 도입합니다. 판단 기준은 단순합니다.

사용자가 페이지를 새로고침하지 않은 상태에서 1초 이내에 변경사항을 봐야 하는가. 답이 예라면 웹소켓을 도입하고, 아니라면 REST API에 적절한 폴링 간격을 설정하거나 SSE를 적용합니다. 기술 선택은 항상 비즈니스 요구사항과 예산을 함께 고려해야 합니다.

화려한 기술보다 적절한 기술이 좋은 제품을 만듭니다.