실시간 통신 방식 비교 글(폴링·롱폴링·SSE·WebSocket) 추가 — 시리즈 1편 - #142
Merged
Conversation
added 4 commits
July 22, 2026 11:56
폴링, 롱폴링, SSE, WebSocket을 HTTP의 무상태·비연결성 제약을 우회하는 방법이라는 관점에서 정리 한 제품의 두 화면에 SSE와 폴링을 나눠 적용한 판단 근거를 갱신 주기의 폭, 장애 격리, 처리량, 만드는 비용으로 설명 다이어그램 4종과 썸네일을 light/dark 쌍으로 추가
헤더 오버헤드는 HTTP가 실시간에 부적합한 이유가 아니라 폴링이 치르는 비용이므로 폴링 섹션 안으로 옮김 HAR로 측정한 위젯 요청별 헤더 크기를 근거 이미지로 추가하고, HTTP/2의 HPACK 압축으로 이 비용이 줄어든다는 단서를 명시 롱 폴링의 부하 성격을 대기 커넥션 수에서 요청 수와 커넥션 수 양쪽으로 정정
최종 비교표의 여섯 축 중 리스크만 파이프라인 쪽 본문 근거가 없어 표에서 처음 등장했다. 단일 소스라 방식을 바꿔도 블라스트 반경이 같다는 근거를 본문에 추가하고, 표 문구도 대시보드와 구분되게 정정 장애 파급 범위 문단이 최종 표의 축인데도 볼드 리드 없이 놓여 있어 다른 근거들과 층위를 맞춤 요청 수의 절대량이 갈림길이 아니었다는 서술이 앞 절의 트래픽 논거를 통째로 되받는 것처럼 읽혀 범위를 좁힘 SSE 프레임 도착 간격은 네트워크 지터를 그대로 받으므로 일정하다는 단정을 왕복과 조회 시간이 빠진다는 서술로 완화 연결 유지 공통 과제 표를 SSE·WebSocket 설명 직후로 옮겨 사례보다 앞세우고, info-box와 warning-box에 중복돼 있던 버퍼링·하트비트· 스케일아웃 세 항목을 표로 흡수. 박스에는 각 방식 고유 제약만 남김 목차가 h2~h3만 수집하므로(toc.ts) h4로 있던 요청 하나의 비용을 볼드 리드로 내림. 폴링 절 결론이 빈도와 건당 비용을 함께 받으므로 h3 승격 대신 절 안에 유지 파이프라인이 신규 페이지인데 개선 작업으로, 아직 없던 화면을 있었다고 적은 서두 시제 두 곳 정정
목차는 h2~h3만 수집하므로(src/lib/toc.ts) h4로 작성된 절은 본문에만 보이고 목차에서 사라진다. Shallow/Retained, Dominator Tree, Path to GC Roots 세 절이 각각 그림과 표를 낀 분량인데도 탐색이 불가능했다 h3로 올려 평탄화. 부모 절 마지막 문장이 이미 뒤의 두 절을 예고하고 있어 형제로 놓아도 흐름이 끊기지 않는다
kmg733
added
documentation
1편이 17,119자로 전체 2위 분량이었다. 개념 총정리(네 방식 비교와 선택 기준)와 실무 회고(두 화면이 SSE/폴링으로 갈린 판단)라는 성격이 다른 두 글이 한 편에 붙어 길이를 키우고 있었다 실무 사례 섹션(약 124줄)을 들어내 2편으로 넘기고, 1편은 개념 정리에 집중하도록 재봉합했다. 본문 12,285자로 중앙값 수준까지 줄었다 - 제목을 선택 기준 중심으로 변경 - description을 개념 비교 중심으로 축소 - 들어가며의 고민 제기는 남기되 답은 다음 글 예고로 전환 - 사례를 가리키던 전방 참조(후반부/뒤에서 다룰/서두에 말한) 정리 - 마치며 예고를 사례+SSE 운영 두 덩어리로 확장 용어 8개는 전부 개념부에서 쓰이므로 그대로 유지된다. 사례 원문은 직전 커밋에 온전히 남아 있어 2편 작성 시 복원한다
kmg733
changed the title
added 8 commits
July 24, 2026 08:36
마지막 분기의 'SSE 제약'이 떠 있는 점선 주석 박스로만 정의돼 분기 노드와 한 몸으로 읽히지 않았다. 추상어를 없애고 구체 조건 'HTTP/1.1 연결 6개·프록시 버퍼링을 통제할 수 있나?'를 노드에 직접 박아 주석 박스를 제거 롱 폴링이 트리 맨 끝 말단 노드에 놓여 SSE보다 나은 최종 선택처럼 읽혔다. 본문은 롱 폴링을 폴백으로 서술하는데 그림이 이를 배반했다. 말단을 '롱 폴링 (SSE 폴백)'으로 표시하고, 그림 5 뒤에 SSE 제약의 정의와 롱 폴링이 대체재임을 밝히는 단락을 추가
선택 플로우차트가 'SSE 제약을 못 넘으면 롱 폴링'으로 끝나 롱 폴링이 비용 없는 폴백처럼 읽혔다. 롱 폴링 절에 아직 다루지 않은 두 한계를 추가했다 - 이벤트마다 응답이 끝나고 재요청이 나가므로 요청당 헤더 비용을 이벤트 빈도만큼 반복한다. 이벤트가 잦으면 폴링과 구분이 흐려진다 - 자동 재연결과 놓친 이벤트 복구가 표준으로 없어 직접 만들어야 하고, 응답과 재요청 사이 공백에 뜬 이벤트는 큐가 없으면 유실된다 닫는 문장을 스트리밍 응답을 버퍼링하는 프록시나 EventSource가 없는 구형 브라우저처럼 SSE를 쓸 수 없는 환경의 대안으로 구체화했다 그림 5 뒤 폴백 단락은 재연결 서술을 롱 폴링 절로 넘기고 '앞서 본 한계를 그대로 안는다'로 되짚어 중복을 제거했다
플로우차트가 SSE와 롱 폴링을 'HTTP/1.1 연결 6개·프록시 버퍼링을 통제할 수 있나?'로 갈랐는데, 이 축이 틀렸다. 연결 6개 제한은 롱 폴링도 대기 중 커넥션을 물어 똑같이 받고 HTTP/2면 둘 다 해소되므로 두 방식을 가르지 못한다. 프록시 버퍼링도 SSE의 전제조건이 아니라 특정 레거시 환경의 예외다. 실제 프로젝트에서도 이 둘과 무관하게 SSE로 구현됐다 실제 결정 축인 실시간 갱신 필요성으로 바로잡았다. SSE를 '이벤트를 즉시 받아야 하나? 예'의 직접 답으로 두고, 롱 폴링은 EventSource 미지원 구형 브라우저나 스트리밍 버퍼링 프록시처럼 SSE를 못 쓰는 환경의 점선 폴백 노드로 내렸다. light/dark 재렌더 - 그림 5 캡션·도입 문장에서 '인프라 제약' 축 제거 - 그림 뒤 단락을 실시간성 축 + SSE 기본값 + 폴백 논리로 재작성 - 마치며 롱폴링 항목을 'SSE나 WebSocket을 쓸 수 없는 환경의 폴백' 으로 일관화
직전 커밋에서 캡션·도입·그림의 선택 축을 '통신 방향 → 실시간성' 으로 줄였는데 마치며 요약 불릿만 '통신 방향 → 실시간성 → 인프라 제약'으로 남아 있었다. 실시간성 축으로 통일하고 SSE 기본·롱 폴링 폴백을 명시 그림 뒤 단락의 '앞 SSE 절에서 짚은 프록시 버퍼링'은 부정확하다. 프록시 버퍼링은 SSE 절이 아니라 공통 과제 표에 있으므로 '앞서 짚은'으로 정정
회고 문단과 예고 문단이 연달아 '다음 글에서'를 반복했다. 회고 문단은 '같은 대시보드 안에서 답이 갈렸습니다'로 닫고, 다음 글 예고는 뒤 문단 하나로 모았다
'어떻게 고를 것인가' 절이 선택 기준을 곧바로 결론으로 제시해 근거가 비어 보였다. 방향 기반 선택 순서와 적합 방식 표가 널리 공유되는 가이드에 뿌리를 둔다는 문단을 앞에 두고, web.dev와 Ably를 인용해 근거를 밝혔다 - 그림 5 앞에 출처 문단 추가: web.dev(단방향 SSE / 양방향 WebSocket), Ably(같은 결론 + 롱 폴링은 레거시 대안). 아래 표가 그 합의의 정리임을 명시 - 'SSE는 대부분의 현대 인프라에서 그대로 동작' 주장에 web.dev·Ably의 근거(HTTP로 오감, 방화벽·프록시 통과, 자동 재연결)를 덧붙임 - 참고 목록에 MDN WebSocket API, web.dev, Ably 두 편 추가
두 소절이 결론만 제시하고 근거가 비어 보였다. 확장 비용 모델과 흔한 오해를 외부 가이드로 뒷받침했다 - '동시 사용자 수' 소절: 폴링의 요청 기반 부하와 연결 유지 방식의 커넥션 기반 부하 모델을 Ably의 롱 폴링·WebSocket 확장 문서로 인용 - '자주 하는 잘못된 판단' 소절: 세 오해가 앞서 인용한 web.dev·Ably 가이드가 공통으로 짚는 지점임을 문단으로 명시 - 참고를 '> 참고:' 인라인에서 다른 글과 같은 '## 참고' 헤딩 + 불릿 목록으로 전환하고 Ably 두 문서 추가
한 문단에 몰려 있던 선택 실마리 설명을 실마리 제시, 방식별 정리, 출처·폴백으로 끊고 결론 문장을 강조 처리
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
개요
폴링·롱폴링·SSE·WebSocket 네 가지 실시간 통신 방식을 HTTP의 제약이라는 관점에서 정리하고, 방식을 좁혀 가는 선택 기준을 다룬 글을 추가한다.
realtime-communication시리즈 1편이며, 실무 사례와 SSE 운영 이슈는 2편(별도 브랜치)에서 이어간다.신규 글:
realtime-communication-polling-sse-websocket.md제목: 폴링, 롱폴링, SSE, WebSocket — 네 가지 실시간 통신 방식과 선택 기준
DeferredResult·Thundering Herd·롱 폴링의 한계SseEmitter/EventSource, 핸드셰이크와101 Switching Protocols, 각 방식 고유 제약request.headersSize실측 이미지로 첨부sse,long-polling,event-source,handshake,deferred-result,heartbeat,thundering-herd,last-event-id)이 PR에서 다듬은 것 (초안 이후 정제)
여러 차례 검토를 거쳐 정합성과 근거를 보강했다.
## 참고를 다른 글과 같은 헤딩+목록 관례로 전환함께 수정:
jvm-memory-diagnosis-tuning.md같은 원인(목차가 h2~h3만 수집)으로 누락되던 h4 절 3개(Shallow/Retained, Dominator Tree, Path to GC Roots)를 h3로 올렸다.
src/lib/toc.ts의 h4 제외는 의도된 설계(toc.test.ts에 명시)라 라이브러리가 아니라 글을 맞췄다.테스트