Vercel WebSocket GA: 재연결·외부 상태·연결 비용부터 확인하기

실시간 AI 채팅 화면에서 연결 표시가 다시 초록색으로 바뀌었다. 그런데 이전 대화의 진행 위치와 참여 중이던 방은 돌아오지 않는다. 연결을 다시 여는 것과 사용자가 하던 일을 복원하는 것은 다른 문제다. Vercel Functions의 WebSocket 정식 지원 소식도 이 구분부터 읽어야 한다.

이번 변화는 WebSocket이라는 기술의 탄생이 아니라, Vercel Functions의 해당 지원이 공개 베타에서 GA로 전환됐다는 것이다. 도입을 판단할 때 중요한 질문은 “소켓을 열 수 있나?”를 넘어선다. 연결 종료 뒤 무엇을 다시 구독하고, 어디에서 상태를 읽고, 어떤 사용량을 비용으로 봐야 하는지가 핵심이다.

1. 정식 지원의 범위와 기존 프로젝트의 확인 지점

Vercel 공식 발표는 6월 말 시작한 공개 베타의 GA 전환을 알린다. 발표 페이지 표기일은 2026년 10월 20일이며, 동결한 원문 HTML의 게시 시각은 한국 시간 2026년 10월 21일 05:00이다. 수집일과 발표일을 같은 날짜라고 단정하지 않는다.

WebSockets 문서는 모든 요금제에서 사용할 수 있다고 설명하지만, Fluid compute 활성화가 필요하다는 조건도 함께 둔다. 2025년 4월 23일 이후 생성된 새 프로젝트에서는 이것이 기본값이다. 기존 프로젝트라면 요금제 이름만 보고 준비됐다고 판단하지 말고 실제 설정을 확인해야 한다. “모든 요금제”는 “모든 사용량이 무료”라는 뜻이 아니다.

한 WebSocket 연결은 수명 동안 하나의 Function 인스턴스에 고정된다. 같은 연결로 보내는 메시지가 같은 인스턴스로 간다는 뜻이지, 사용자가 앞으로 여는 모든 연결이 같은 인스턴스로 돌아온다는 보장은 아니다. Fluid compute가 한 인스턴스에서 여러 연결을 처리할 수 있다는 설명도 전역 공유 메모리를 제공한다는 의미는 아니다.

연결 수명 동안의 인스턴스 고정과 재접속 뒤 상태 공유를 분리했다. 실제 배포 화면이 아닌 원문 기반 개념도다. 출처: vercel.com/docs/functions/websockets.

2. 재연결의 완료 조건은 세 가지다

공식 문서의 Handle disconnections and reconnects 절은 Function이 최대 실행 시간에 도달하면 연결이 닫힌다고 설명한다. 여기서 특정 분 단위 숫자를 모든 프로젝트에 공통인 한도로 제시하지 않는다. 실제 적용되는 Function 한도를 따로 확인해야 한다.

문서는 복구 동작으로 연결 재생성, 채널·토픽 재구독, 필요한 상태 다시 읽기를 제시한다. 이를 AI 채팅 서비스에 적용하면, 소켓의 open 이벤트만으로 복구 완료 표시를 내보내는 설계가 왜 부족한지 드러난다. 네트워크 통로가 생겼어도 대화의 현재 상태와 방 구독이 아직 준비되지 않았을 수 있기 때문이다.

아래는 원문의 복구 원칙을 서비스 설계로 풀어 쓴 흐름이다. 실제 SDK의 실행 결과나 전달 보장 사양이 아니라 편집상 제안이다. 연결 실패 시 재시도 간격을 늘리는 것과 별개로, 재접속한 세션이 볼 수 있는 방인지 확인하고 구독을 복원한 뒤 저장된 상태를 읽어 화면을 맞추는 절차가 필요하다. 상태 복원이 실패하면 “연결됨” 대신 “동기화 중” 또는 재시도 가능한 오류를 구분해 보여주는 편이 문제를 진단하기 쉽다.

공식 문서의 세 가지 복구 동작에 작성자의 복구 완료 UI 제안을 덧붙였다. 실행 시험이나 자동 복구 보장을 뜻하지 않는다. 출처: vercel.com/docs/functions/websockets.

3. 메모리 속 방을 영속 상태로 착각하지 않기

Manage persistent state 절에 따르면 새 연결이 같은 인스턴스로 간다는 보장은 없다. 재연결은 다른 인스턴스에 붙을 수 있고, 새 배포 후에는 기존 연결과 새 연결이 서로 다른 배포를 바라볼 수도 있다. 그래서 문서는 영속 상태, 접속 현황, 카운터, 방과 pub/sub 조정을 외부 저장소에 두도록 권한다.

예를 들어 현재 방의 참가자 목록을 한 프로세스의 변수에만 넣었다면, 새 연결을 받은 다른 인스턴스는 그 목록을 알지 못한다. 방 목록이 프로세스 메모리에만 있다면 연결 재시도보다 외부 상태 저장 설계를 먼저 고친다. 이것은 특정 데이터베이스 제품을 반드시 사라는 결론이 아니다. 어떤 정보가 연결과 프로세스보다 오래 살아야 하는지를 먼저 정하라는 뜻이다.

AI 응답의 진행 위치나 사용자 명령 처리 결과도 같은 관점에서 분류할 수 있다. 다만 이는 문서의 상태 외부화 원칙을 응용한 설계 제안이며 Vercel이 대화 복원이나 메시지의 정확히 한 번 처리를 자동 제공한다는 주장이 아니다. 저장소를 붙였다고 이벤트 순서나 중복 처리가 저절로 해결되는 것도 아니다. 특히 결제·작업 시작처럼 부작용이 있는 명령은 연결이 끊겼다는 이유만으로 무조건 다시 보내면 안 된다. 요청 식별자와 이미 처리한 결과 확인 같은 별도 애플리케이션 정책이 필요하다.

4. CPU 대기와 연결 전체 비용을 분리해서 읽기

GA 발표의 Active CPU pricing 설명은 메시지를 처리한 시간에 대해서만 CPU 비용이 청구된다는 내용이다. 이 문장을 “아무 메시지도 보내지 않는 연결은 언제나 무료”로 바꾸면 범위가 달라진다.

Limits and pricing 절은 연결이 활성화된 동안의 Function 사용량과, 연결을 통해 전송한 데이터에 대한 Fast Data Transfer 및 Fast Origin Transfer를 함께 언급한다. 따라서 CPU 처리 시간만 줄어든 상황과 청구서 전체가 줄어든 상황은 구분해야 한다. 외부 상태 저장소를 선택했다면 그 서비스의 비용도 독립적으로 검토할 항목이다. 이 마지막 항목은 아키텍처상 고려 사항이지 이 원문에 제시된 Vercel 가격표의 추가 수치를 옮긴 것이 아니다.

메시지 처리 CPU 비용의 범위와 연결 관련 사용량을 구별한다. 금액이나 절감률을 측정한 그래프가 아니다. 출처: vercel.com/docs/functions/websockets.

비용 비교를 준비한다면 연결이 열린 시간, 메시지 처리 패턴, 전송 데이터와 상태 동기화 빈도를 따로 기록하는 편이 유용하다. 이는 측정 계획이지 여기서 수행한 실험이 아니다. 동시 연결 수만으로 월 비용을 확정하거나, 정식 지원 전환만으로 비용 절감률을 계산할 근거는 이번 자료에 없다. 문서가 나열한 과금 항목은 확인할 수 있지만 최종 단가·청구액·성능 우위를 이 글에서 만들어내지 않는다.

5. 현재 앱에서 무엇부터 바꿀지 고르는 표

다음 표는 공식 제약을 실제 도입 판단으로 연결한 작성자의 분석이다. 각 행의 확인 결과에 따라 작업 순서가 달라진다. 서버를 옮기기 전에 복구 가능성과 상태 저장 위치를 점검하는 데 목적이 있다.

현재 앱의 상태	먼저 확인할 근거	우선 판단
오래된 프로젝트인데 연결 기능부터 추가하려 한다	Fluid compute 활성화 여부	프로젝트 조건부터 확인하고 이후 연결 구현을 검토한다
소켓은 복구되지만 방·대화 진행 위치가 사라진다	재구독과 상태 다시 읽기 절차	open 이벤트와 복구 완료를 분리한다
방·카운터를 프로세스 변수에만 둔다	다른 인스턴스·새 배포가 읽을 수 있는가	외부 상태 저장 설계를 먼저 한다
대기 중 CPU 비용만 보고 예산을 정했다	Function 사용량과 전송 항목의 누락 여부	비용 모델을 항목별로 다시 구성한다
재접속 때 모든 명령을 다시 보낸다	이미 처리된 부작용을 구별할 수 있는가	무조건 재전송을 멈추고 중복 처리 방지 정책을 정한다

서로 다른 증상에 맞춰 상태 복원·중복 처리·비용 분리를 우선한다. 공식 제약을 응용한 작성자의 분석이다. 출처: vercel.com/docs/functions/websockets.

단순한 연결 예제에서 메시지 echo가 성공하는 것과 위 표의 조건을 충족하는 것은 다르다. 채팅 데모는 통로가 열린 사실을 보여줄 수 있지만, 배포가 바뀌거나 세션이 끊겼을 때 업무가 이어지는지는 별도 문제다. 반대로 이미 외부 상태와 복구 절차가 갖춰진 앱이라면, GA 소식은 플랫폼 적용 조건과 비용을 검토하는 계기가 된다. 기존 구조를 전부 갈아엎어야 한다는 결론도 이 자료만으로는 나오지 않는다.

6. Next.js에서는 패키지 버전의 주어까지 확인하기

공식 문서의 Next.js 절은 Next.js가 WebSocket upgrade를 처리하는 API를 노출하지 않는다고 설명하고, 우회 방법으로 @vercel/functions의 upgradeWebSocket()을 제시한다. 이때 요구하는 3.10.0 이상은 Next.js 버전이 아니라 @vercel/functions 패키지 버전이다. 이 차이를 놓치면 프레임워크만 업데이트하고 필요한 API가 준비됐다고 오해할 수 있다.

원문에는 Bun, Node.js 프레임워크, Nitro와 Python 계열도 각각 다른 예제가 있다. 따라서 다른 런타임의 코드를 그대로 붙이는 대신 자신이 사용하는 프레임워크의 절을 읽는 것이 출발점이다. 여기서는 예제를 직접 배포하거나 호환성을 실행 검증하지 않았다. 문서에 적힌 API 조건을 전달하는 범위와 실제 앱의 인증·상태·운영 검증 범위를 구분한다.

7. 결론: 연결 기능의 GA와 서비스 복구의 완성은 다르다

이번 발표로 확인되는 변화는 Vercel Functions WebSocket 지원의 정식 제공이다. 서비스 선택의 핵심은 연결이 끊겼을 때도 상태를 다시 읽고, 필요한 구독을 복원하며, 이미 처리된 명령을 함부로 반복하지 않을 수 있는가에 있다. 비용 역시 메시지 처리 CPU 한 항목이 아니라 연결에 관련된 사용량과 전송을 함께 봐야 한다.

이 글은 공식 문서를 바탕으로 작성한 설계 해설이며, 실제 배포·부하 시험·비용 측정 결과가 아니다. AI를 활용해 공개 자료를 정리하고 독자용 판단표와 개념도를 작성했다. 그림은 공식 제품 화면이나 측정 그래프가 아닌 자체 제작 개념도다.

참고 자료: GA 발표 — 지원 전환과 CPU 과금 설명, WebSockets 문서 — 재연결·상태·프레임워크·과금 조건.