채팅 때문에 서버를 따로 뒀다면…Vercel WebSocket 정식 지원

웹사이트는 Vercel에 올렸지만 채팅 서버는 다른 곳에 두고 계신가요? 이제 실시간 연결도 같은 배포 환경에서 운영할 수 있습니다. Vercel은 2026년 10월 20일 WebSocket 지원을 정식 출시했습니다. Vercel Functions가 연결을 받아 양방향으로 데이터를 주고받는 방식입니다. 다만 연결을 무한히 유지해 주거나, 채팅방 상태까지 대신 관리해 준다는 뜻은 아닙니다. 공식 발표

채팅 하나 때문에 나뉘던 운영 환경

일반적인 웹 요청은 서버가 답을 보내면 한 차례의 처리가 끝납니다. 반면 채팅이나 여러 사람이 함께 보는 실시간 화면은 서버와 사용자가 계속 데이터를 주고받아야 합니다. WebSocket은 이처럼 연결을 열어 둔 채 양방향으로 통신할 때 쓰는 방식입니다.

가령 새 주문이 들어오면 관리 화면에 바로 표시되고, 한 직원이 처리 상태를 바꾸면 다른 직원의 화면도 함께 바뀌어야 한다고 해보죠. 화면을 만드는 일 외에 연결을 유지하는 서버, 배포 방법, 장애 대응까지 따로 챙겨야 할 수 있습니다. 이번 정식 지원은 이 연결 처리 부분도 Vercel에서 운영할 선택지를 넓혔다는 데 의미가 있습니다. 지난 6월 공개 베타에 이은 정식 출시이지, 이번에 처음 등장한 기능은 아닙니다. 공개 베타 발표

공식 문서는 모든 플랜에서 지원하되 Fluid compute가 활성화돼 있어야 한다고 명시합니다. 이미 Vercel을 쓰고 있더라도 프로젝트에서 이 조건을 충족하는지 먼저 살펴볼 부분입니다. 적용 조건

연결이 끊긴 뒤에도 같은 화면으로 돌아와야 합니다

별도 서버를 줄일 수 있다고 해서 연결 관리가 사라지는 것은 아닙니다. WebSocket 연결은 하나의 함수 인스턴스에 붙지만, 다시 접속할 때도 같은 인스턴스로 돌아간다는 보장은 없습니다. 함수의 최대 실행시간에 도달하면 연결도 종료됩니다. 이 시간은 플랜과 설정에 따라 다르며, 연장 실행시간의 일부는 베타 조건이므로 하나의 숫자를 모든 환경에 적용하면 안 됩니다. 연결 수명 · 실행시간 설정

앞의 주문 관리 화면으로 돌아가 보겠습니다. 접속이 끊겼다가 연결 표시가 다시 켜졌더라도, 그 사이에 들어온 주문이 화면에서 빠졌다면 업무는 정상으로 복구된 것이 아닙니다. 클라이언트가 다시 연결하는 것뿐 아니라 원래 구독하던 채널에 들어가고, 필요한 최신 상태를 다시 불러오는 과정까지 설계해야 합니다.

배포할 때도 같은 문제가 생깁니다. 이미 연결된 사용자는 이전 배포에 남고, 새 사용자는 새 배포에 연결될 수 있습니다. 공식 문서가 영속 상태와 접속자·채팅방 정보 등을 외부 저장소로 조정하라고 안내하는 이유입니다. 서버 메모리에만 상태를 두면 다른 인스턴스나 새 배포가 그 정보를 그대로 이어받는다고 기대할 수 없습니다. 배포와 상태 관리

제가 눈여겨보는 부분은 작은 팀이 따로 챙겨야 할 배포 환경을 줄일 수 있다는 점입니다. 그렇다고 실시간 서비스의 어려운 일이 전부 없어지지는 않습니다. 메시지 누락과 중복을 다루는 규칙, 상태를 저장하는 위치, 끊어진 뒤 복구하는 방식은 여전히 서비스가 결정해야 합니다.

조용한 채팅방도 비용은 남을 수 있습니다

연결을 열어 놓고 메시지를 기다리는 시간이 길다면 비용도 나눠 봐야 합니다. Vercel은 실제 코드 실행에 사용한 CPU 시간을 과금하고, 입출력을 기다리는 시간에는 CPU 요금을 부과하지 않는다고 설명합니다. 그러나 메모리는 마지막 처리 중인 요청이 끝날 때까지 사용량이 계산됩니다. WebSocket에는 데이터 전송 비용도 적용됩니다. ‘기다리는 동안 CPU 비용이 없다’와 ‘연결을 유지해도 비용이 없다’는 다른 말입니다. Functions 과금 구조 · 전송 비용

그래서 별도 서버 한 대의 월 비용과 함수 호출 요금 하나만 비교해서는 판단하기 어렵습니다. 평소 동시 연결 수, 연결을 유지하는 시간, 메시지가 몰릴 때의 CPU 사용량, 메모리와 전송량을 함께 봐야 합니다. 이미 외부 실시간 서비스가 재연결과 메시지 전달을 안정적으로 처리하고 있다면, 호스팅을 합치는 대신 직접 맡게 되는 운영 부담도 비교 대상입니다. 호스팅이 한곳으로 모였다는 이유만으로 더 싸거나 편해졌다고 단정하기는 어렵습니다.

이전 전에, 일부러 연결을 끊어 보는 이유

적용을 검토한다면 전체 채팅을 한꺼번에 옮기기보다 작은 기능 하나로 시작하는 편이 좋겠습니다. 저라면 연결이 잘 되는지보다, 끊어진 뒤 어떻게 돌아오는지부터 시험하겠습니다. 짧은 실행시간을 설정해 연결 종료를 유도한 뒤 재접속·채널 재구독·상태 재로딩이 이어지는지 보고, 그 사이의 메시지가 누락되거나 중복 표시되는지도 살펴보는 것입니다. 아래 과정은 직접 시험한 후기가 아니라 공식 제약을 바탕으로 제안하는 점검 방법입니다.

그다음에는 이전 연결을 유지한 상태에서 새 버전을 배포해 양쪽 사용자가 같은 상태를 보는지 비교할 수 있습니다. 메시지가 거의 없는 시간과 집중되는 시간의 CPU·메모리·전송량을 따로 기록하면, 구조를 단순하게 만드는 이점이 운영 부담과 비용을 감당할 만큼 큰지도 판단하기 쉬워집니다.

Next.js를 쓴다면 코드를 옮기는 방식도 달라집니다. 공식 문서는 일반적인 연결 전환 API 대신 @vercel/functions의 upgradeWebSocket 사용을 안내하며, 패키지 3.10.0 이상을 요구합니다. Socket.IO 역시 클라이언트가 WebSocket 전송 방식을 명시하도록 안내합니다. 기존 코드를 그대로 옮겨도 된다는 전제로 시작하지 않는 편이 안전합니다. 프레임워크별 구현 안내

앞서 다룬 Vercel Daemons 공개 베타가 뒤에서 계속 작업하는 워커의 이야기였다면, 이번 WebSocket은 사용자와 열린 연결을 주고받는 쪽의 변화입니다. 둘 다 운영 구성을 다시 검토할 계기는 되지만, 해결하는 문제는 다릅니다.

결국 질문은 ‘이제 별도 서버가 필요 없나’에서 끝나지 않습니다. 연결이 끊기거나 배포가 바뀌어도 사용자의 작업이 이어지는지, 그 상태를 어디에 보관할지, 운영 비용이 어떻게 달라지는지까지 답할 수 있어야 합니다. 그 조건이 맞는 팀이라면 이번 정식 지원은 실시간 기능을 더 익숙한 배포 환경 안으로 가져올 만한 선택지입니다.

자료 확인: 2026년 10월 21일. 공식 발표와 운영 문서를 바탕으로 작성했으며, 직접 이전하거나 비용을 측정한 후기는 아닙니다. 대표 이미지는 VECTO를 활용한 AI 제작 개념 장면으로 실제 제품 화면이 아닙니다.

저는 이번 정식 지원을 작은 팀이 별도 실시간 서버의 배포 환경을 줄일 선택지로 봅니다. 다만 재연결·상태 복구·메모리와 전송 비용까지 검증한 뒤 이전 여부를 판단해야 합니다.