975. 웹소켓 (WebSocket)

핵심 인사이트 (3줄 요약)

본질: 웹소켓은 빈출 주제와 용어에서 핵심 동작과 제약을 이해하게 해 주는 개념이다.

가치: 웹소켓을 이해하면 구분 명확성과 설명력 사이의 균형을 더 정확히 볼 수 있다.

판단 포인트: 설계 시에는 개념 자체보다 적용 조건, 운영 복잡도, 인접 기술과의 경계를 함께 판단해야 한다.

Ⅰ. 개요 및 필요성

단방향 통신 (Half-Duplex 느낌): 무조건 클라이언트(웹 브라우저)가 먼저 "요청(Request)"을 해야만, 서버가 "응답(Response)"을 줄 수 있습니다. 서버가 나에게 먼저 "야 주식 올랐어!"라고 밀어줄(Push) 방법이 아예 없습니다.
눈물겨운 꼼수들 (AJAX, Polling, Long Polling):
- 브라우저가 1초에 한 번씩 "새 카톡 왔어요?" 계속 새로고침을 해서 서버에 물어봅니다(폴링).
- 매번 무거운 HTTP 헤더(껍데기)를 1KB씩 싣고 물어보느라, 실제 대화(1바이트)보다 쓰레기 통신(오버헤드)이 100배 커서 서버 대역폭이 찢어집니다.

[RESTful API]
    │
    ▼
[웹소켓]
    │
    └──▶ [DNS 스푸핑]

📢 섹션 요약 비유: 웹소켓은 왜 필요한지 보여주는 교통 규칙 표지판과 같다. 문제가 생긴 배경을 알면 이후 선택도 쉬워진다.

Ⅱ. 아키텍처 및 핵심 원리

개념: HTML5 표준의 일부로, 브라우저와 웹 서버 사이에 한 번 연결을 맺으면 끊지 않고(지속 연결), TCP 기반의 완벽한 양방향 전이중(Full-Duplex) 통신 채널을 형성하여 서버가 원할 때 언제든 데이터를 클라이언트로 쏠 수 있게(Push) 해주는 실시간 프로토콜입니다. (ws:// 또는 보안 적용된 wss:// 접두사를 씁니다.)

[RESTful API]
    │
    ▼
[웹소켓]
    │
    └──▶ [DNS 스푸핑]

📢 섹션 요약 비유: 웹소켓의 내부 원리는 기계의 톱니바퀴처럼 맞물려 돌아간다. 한 부분이 어긋나면 전체 효과가 떨어진다.

Ⅲ. 비교 및 연결

1단계: HTTP의 탈을 쓴 악수 (Handshake)

웹소켓은 별도의 이상한 포트를 안 씁니다. 무적의 방화벽 통과를 위해 일반 웹 포트(80번, 443번)를 그대로 씁니다.
브라우저가 서버에 평범한 HTTP 요청을 던집니다. 단, 헤더에 폭탄선언을 박습니다.
- Connection: Upgrade
- Upgrade: websocket
해석: "서버야, 우리 지금까지 하던 HTTP 단방향 통신 재미없지? 이거 웹소켓 양방향 통신망으로 업그레이드(교체)하자! 콜?"

2단계: 파이프 뚫기 (Switching Protocols)

서버가 동의하면 상태 코드 101 Switching Protocols를 반환합니다.
이 순간, 두 컴퓨터를 잇고 있던 무겁고 답답한 HTTP 프로토콜의 영혼은 증발해 버리고, 그 자리에 가볍고 날쌘 '웹소켓' 프로토콜의 피가 흐르는 고속 터널이 영원히 뚫리게 됩니다.

3단계: 양방향 무제한 폭격 (Full-Duplex)

이제 파이프가 뻥 뚫렸습니다. 더 이상 "새 카톡 있어?" 묻지 않아도 됩니다.
친구가 카톡을 보내면, 서버가 알아서(Push) 열려있는 터널로 0.01초 만에 내 화면에 "ㅋㅋㅋ" 메시지를 쏴버립니다.
HTTP의 거대한 1KB짜리 헤더(껍데기) 다 버리고, 고작 2~10바이트 수준의 초경량 프레임 단위로 데이터를 주고받기 때문에, 증권사 주식 호가창이 미친 듯이 깜빡여도 서버가 1도 부담을 안 느끼는 궁극의 효율이 달성됩니다.

웹소켓을 볼 때는 앞뒤 개념과의 경계를 함께 봐야 전체 흐름이 선명해진다. RESTful API가 기반 조건을 만든다면, 웹소켓은 그 위에서 핵심 메커니즘을 구현하고, DNS 스푸핑은 이를 더 확장된 적용 단계로 연결한다. 따라서 단일 정의보다 구분 명확성과 설명력에 어떤 차이를 만드는지 비교하는 것이 중요하다.

관점	선행 개념	현재 개념	확장 개념
초점	RESTful API의 기반 정리	웹소켓의 핵심 동작	DNS 스푸핑의 확장 적용
자원 관점	기본 조건 확보	구분 명확성 최적화	규모와 범위 확대
판단 포인트	도입 가능성 확인	현재 메커니즘의 적합성 판단	운영·확장 전략 연결

📢 섹션 요약 비유: 웹소켓은 비슷한 기술들 사이의 차선을 구분하는 분기점과 같다. 어디서 갈라지는지 알아야 헷갈리지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

적용: 웹 브라우저 기반의 실시간 채팅, 주식 HTS, 캔디크러쉬 같은 멀티플레이어 웹 게임 등 지연시간 0.1초가 생명인 곳의 절대 군주입니다.
경쟁자 (SSE, Server-Sent Events):
- 채팅처럼 양방향이 아니라, "주식 시세"처럼 오직 '서버에서 브라우저로 한 방향으로만 쏟아내는(Push)' 거라면 무거운 웹소켓 대신 HTTP 규격에 내장된 단방향 푸시 기술인 **SSE(965번 참조)**를 쓰는 것이 배터리와 성능 면에서 유리합니다. (트레이드오프 선택)

실무 체크리스트

요구사항과 병목 지점을 먼저 수치화한다.
운영 복잡도와 도입 효과를 함께 검증한다.
인접 기술과의 연계를 배포 전에 점검한다.

📢 섹션 요약 비유: 기존 HTTP 통신(폴링)은 친구랑 문자로 대화하는데 매번 **'등기 우편'**을 고집하는 짓입니다. "철수야 뭐해?" 편지를 봉투에 넣고 우표(무거운 HTTP 헤더)를 붙여서 우체통에 넣고, 답장이 올 때까지 멍때립니다(오버헤드 지옥). **웹소켓(WebSocket)**은 첫 번째 등기 우편 안에 '종이컵 실 전화기'를 하나 동봉해서 보내는 짓(Upgrade 요청)입니다. 철수가 그걸 뜯어서 귀에 대는 순간(101 응답), 우편 배달은 끝납니다. 이제부터 둘은 팽팽하게 연결된 실 전화기(양방향 터널)를 통해, 편지 봉투나 우표 없이 입만 뻥끗하면 0.01초 만에 서로의 목소리가 직통으로 전달됩니다. 내가 묻기도 전에 철수가 "야 밥 먹자!" 소리치면 즉각 내 귀에 박히는(서버 푸시) 실시간 웹 통신 아키텍처의 혁명입니다.

Ⅴ. 기대효과 및 결론

웹소켓은 빈출 주제와 용어를 이해할 때 핵심 축을 잡아 주는 개념이다. 올바르게 적용하면 구분 명확성 개선과 구조적 단순화에 기여하지만, 조건을 잘못 잡으면 오히려 복잡도와 운영 부담이 커질 수 있다. 앞으로는 DNS 스푸핑, 컨텍스트 기반 용어 해석, 자동화 운영과의 결합을 통해 더 정교하게 발전할 가능성이 크다. 따라서 이 개념은 정의 자체보다 “언제 쓰고 언제 다른 방법으로 넘길 것인가”의 관점으로 기억하는 것이 좋다. 향후에는 컨텍스트 기반 용어 해석 같은 자동화 흐름과 결합되어 더 정교한 형태로 확장될 가능성이 크다.

📢 섹션 요약 비유: 웹소켓은 큰 흐름 속에서 기억해야 오래 남는다. 지금의 장점과 다음 확장 방향을 같이 보면 전체 그림이 선명해진다.

📌 관련 개념 맵

개념	연결 포인트
RESTful API	현재 개념이 등장하기 전에 갖춰야 할 배경이나 인접 선행 개념이다.
정의 (Definition)	용어의 시작점을 분명하게 만든다.
비교 (Comparison)	헷갈리는 개념의 경계를 드러낸다.
DNS 스푸핑	현재 개념이 확장되거나 적용 단계로 이어질 때 자주 함께 언급된다.

📈 관련 키워드 및 발전 흐름도

[선행 개념: RESTful API]
    │
    ▼
[현재 개념: 웹소켓]
    │
    ├──▶ [확장 A: DNS 스푸핑]
    └──▶ [확장 B: 컨텍스트 기반 용어 해석]

웹소켓는 RESTful API에서 출발해 현재 메커니즘을 정교화하고, 이후 DNS 스푸핑와 컨텍스트 기반 용어 해석 같은 확장 흐름으로 이어진다고 보면 기억이 오래간다.

👶 어린이를 위한 3줄 비유 설명

비슷한 이름의 장난감을 헷갈리지 않게 표를 붙이는 것과 같아요.
이 개념은 무엇이 어떻게 다른지 쉽게 구별하게 도와줘요.
그래서 시험에서도 실무에서도 말을 더 정확하게 쓸 수 있어요.