REST 끝나고 WebSocket 시작하는 곳 — handoff 결정

"WebSocket 이 REST 의 대체 아냐. REST 가 잘 답 못 하는 specific 질문 하나에 대한 답: '양 측이 언제든 메시지 보내야.' 그 선이 어디 떨어지는지 알면 over-engineering 과 under-engineering 둘 다 피해."

REST 에서 WebSocket 까지 spectrum

가장 덜 real-time 에서 가장 real-time:

REST request/response — Client 물음, server 답, 끝. CRUD 와 ad-hoc query 에 best.
Polling — REST 반복. 견딜 만한 지연, 단순.
Long-polling — Response 보유하는 REST. 낮은 지연, pending client 당 더 많은 server 비용.
SSE — HTTP 위 one-way streaming. Server push; client 받음. AI token, 알림, real-time log.
WebSocket — Full-duplex 영속 연결. 양 측이 서로 독립적으로 언제든 메시지 보냄.

각 step 이 capability 위해 단순함 trade. WebSocket 이 가장 capable AND 운영적으로 가장 비쌈 — 실제 필요할 때 선택.

WebSocket 선택 위한 테스트 셋

1. 양방향성. CLIENT 도 일반 request 넘어 real-time 으로 server 한테 메시지 push 필요? 채팅 "입력 중..." 표시, 멀티플레이어 게임 입력, 협업 커서 위치 — yes. AI 채팅 (user 가 메시지 하나 보내고, server 가 response stream, 반복) — no, SSE + 일반 POST 면 충분.

2. 지연 예산. 허용 end-to-end 지연이 ~100ms 아래? 트레이딩 플랫폼, 라이브 커서 추적 — yes. 대부분 채팅 UI — no, SSE + POST 가 괜찮.

3. 메시지 빈도. Client 당 초당 작은 메시지 많이 보내? 30Hz 게임 상태 update — yes. 분 당 몇 알림 — no, SSE 이김.

셋 다 NO 답할 수 있으면 REST + SSE 가 거의 항상 맞는 선택. 하나라도 YES 면 WebSocket 매력 시작.

WebSocket 이 HTTP 위 어떻게 setup

WebSocket 연결이 upgrade header 가진 일반 HTTP/1.1 request 로 시작. Server 가 의향 있으면 101 Switching Protocols 로 응답, 그 후 아래 TCP 연결이 WebSocket frame stream 됨:

GET /ws/chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

101 후, 양 측이 WebSocket frame 교환 — 작은 binary header + payload. 어느 측이 닫을 때까지 연결 열림.

WebSocket 이 진짜 양방향성 사려고 운영 overhead — 연결 상태, 재연결 로직, per-connection 메모리 scaling, 활성 연결 monitoring — 에 복잡도 비용 지불. 양 측 적극 push 안 필요하면 그 복잡도 안 필요. Real-time bar 만족하는 가장 가벼운 protocol 선택.

흔한 하이브리드

많은 production 앱이 REST 와 WebSocket 둘 다 씀: 상태 관리와 query (login, history fetch, draft 저장) 엔 REST, live 채널 (채팅 메시지, live 편집, presence) 엔 WebSocket. 상태와 history 가 REST-접근 가능 resource 에 살고; WebSocket 이 그것들 mutate 하는 event 운반. 각 측이 REST view update; WebSocket 이 모든 듣는 사람한테 뭐 변했는지 announce.

cwkPippa 의 하이브리드

cwkPippa 가 패턴 셋 나란히 씀: 대화 관리 (POST 생성, GET fetch, PUT rename, DELETE 제거) 에 REST, AI token streaming (각 /api/chat 호출이 Server-Sent Events 통해 token stream) 에 SSE, Cinder Sidekick 채널 (Cinder 통해 Photoshop UXP 플러그인과 cwkPippa backend 간 양방향 control + 상태 sync) 에 WebSocket. WebSocket 부분 존재 — Cinder 가 cwkPippa 한테 canvas 상태 push AND 같은 채널에 Pippa 응답 받기 필요라서 — 그게 양방향성 테스트 trigger. Cinder 가 한 방향만 필요했으면 SSE 면 충분.

Code

FastAPI WebSocket: 완전 양방향, 모든 연결에 broadcast·python

# FastAPI — WebSocket endpoint (양방향)
from fastapi import FastAPI, WebSocket, WebSocketDisconnect

app = FastAPI()
_connections: set[WebSocket] = set()

@app.websocket('/ws/chat')
async def chat_socket(ws: WebSocket):
    await ws.accept()
    _connections.add(ws)
    try:
        while True:
            # Client 에서 메시지 받음 (언제든 가능)
            msg = await ws.receive_json()
            # 모든 연결된 client 한테 echo (broadcast)
            for conn in _connections:
                await conn.send_json({'from': msg.get('from'), 'text': msg.get('text')})
    except WebSocketDisconnect:
        _connections.discard(ws)

브라우저 WebSocket — full duplex, 독립적 send/receive·javascript

// 브라우저 client — WebSocket API (열기에 한 줄)
const ws = new WebSocket('ws://localhost:8000/ws/chat');

ws.onopen = () => console.log('연결됨');
ws.onmessage = (e) => {
  const data = JSON.parse(e.data);
  appendToChatUi(data);
};
ws.onclose = () => console.log('연결 끊김 — 재연결 로직 구현');

// 언제든 메시지 보냄, request/response 사이클 안 묶임
document.getElementById('send').onclick = () => {
  ws.send(JSON.stringify({ from: 'me', text: '안녕 모두' }));
};

결정 매트릭스 — REST / SSE / WebSocket / polling·text

# 결정 매트릭스 — 맞는 도구 선택

| 필요                                              | 패턴                |
|---------------------------------------------------|---------------------|
| Fetch / 저장 / list — request/response            | REST                |
| Server 가 event push; client 가 push 안 함        | SSE                 |
| 지연 tolerant (초-OK); server 에서 push           | Polling / long-poll |
| 양 측이 언제든 메시지 push; 저-지연                | WebSocket           |
| 멀티플레이어 게임, live editor, 트레이딩          | WebSocket           |
| Streaming response 가진 AI 채팅                   | REST POST + SSE     |
| 분 당 몇 알림                                      | SSE (혹은 long-poll)|
| Live 커서 추적                                     | WebSocket           |
| 진행 event 가진 파일 download                      | 진행에 SSE          |
| One-shot upload                                    | REST POST           |

Exercise

만들 생각해본 단일 기능 (채팅, 알림, 멀티플레이어 카운터, real-time dashboard) 골라서 적어: (1) real-time 양방향이야, (2) 허용 지연이 뭐야, (3) 기대 메시지 빈도 뭐야. 그 다음 결정 매트릭스에 매핑하고 REST / SSE / WebSocket 선택. 두 문장으로 선택 변호. 보너스: 셋 중 둘 구현 (예: SSE + WebSocket) 하고 운영 차이 느껴.

Hint

대부분 'real-time' 기능이 실제 생각하면 SSE 로 나옴. 진짜 WebSocket 사용 사례가 마케팅 시사하는 것보다 좁음. 연습이 modern 처럼 들리는 거 아닌 필요로 선택하는 discipline 가르쳐. Two-implementation 보너스가 WebSocket 복잡도 — 재연결 로직, 메시지 순서, 연결 상태 — SSE 가 안 가진 거 보여줘.

REST 끝나고 WebSocket 시작하는 곳 — handoff 결정

REST 에서 WebSocket 까지 spectrum

WebSocket 선택 위한 테스트 셋

WebSocket 이 HTTP 위 어떻게 setup

흔한 하이브리드

cwkPippa 의 하이브리드

Code

External links

Exercise

Progress

댓글 0