이 글에서 다루는 것
에이전트 응답을 실시간으로 보여 주기 위해 WebSocket 연결을 실험한 날의 짧은 회고다. 프로토콜·재연결·관측 방법을 한 작업으로 묶어 정리한다. (다음 날 WebSocket 스트리밍과 LCP 개선에서 UI·성능까지 이어진다.)
1. WebSocket 연결·재연결·관측
배경지식 (개념)
- WebSocket handshake: HTTP로 시작해 프로토콜을 Upgrade 하는 과정.
- Heartbeat: 연결이 살아 있는지 주기적으로 확인하는 ping/pong 또는 유사 메시지. 프록시·로드밸런서 타임아웃을 피한다.
어떤 상황이었나
HTTP 요청·응답 한 번으로는 길게 이어지는 에이전트 출력을 자연스럽게 보여 주기 어렵다. WebSocket으로 연결을 유지한 채 서버가 여러 메시지를 보내는 방식을 검토했다.
초기에는 재연결 시 메시지 유실·중복, 유휴 연결 끊김 같은 운영 이슈가 예상됐다. 네트워크 탭만으로는 메시지가 언제 도착하는지 파악이 어려웠다.
목표는 세 가지였다 — 핸드셰이크·재연결 로직 정리(연결), 유휴 타임아웃 대비 heartbeat 설계(안정성), 스트리밍 타이밍을 디버깅할 방법 찾기(관측).
핵심 작업
- 프로토콜: WebSocket 핸드셰이크와 재연결 로직을 정리했다.
- heartbeat: 연결 유지 비용·타임아웃을 고려해 설계할 필요성을 확인했다. 중간 프록시가 먼저 끊을 수 있어서다.
- 관측: 네트워크 탭만으로는 스트리밍 타이밍 파악이 어려웠다 — 앱 로그·프레임 단위 도구를 병행해야 한다는 결론.
교훈
- 연결 유지 비용을 고려해 heartbeat를 설계해야 한다 — 중간 프록시가 먼저 끊을 수 있다.
- 네트워크 탭만으로는 스트리밍 타이밍을 파악하기 어렵다 — 메시지 경계·UI 반영 시점은 별도 계측이 낫다.
- 재연결은 "다시 붙기"만이 아니라 상태 동기화 문제다 — 다음 날 UI placeholder·LCP 작업으로 이어짐.
→ Largest Contentful Paint — 다음 날 랜딩 성능 작업과 연결
파생 지식
- Largest Contentful Paint — 다음 날 랜딩 성능 작업과 연결
관련 TIL
- WebSocket 스트리밍과 LCP 개선 — 스트리밍 UI·placeholder·LCP