480. WebSocket - 하나의 TCP 연결 위 전이중 (Full-Duplex) 실시간 브라우저-서버 통신

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

본질: WebSocket은 HTTP의 Upgrade 헤더를 통해 최초 연결을 맺은 후, HTTP의 굴레를 벗어던지고 하나의 지속적인 TCP 연결 위에서 서버와 클라이언트가 자유롭게 이진/텍스트 프레임을 양방향(Full-Duplex)으로 쏘아대는 독립적인 프로토콜이다.

가치: 기존의 폴링(Polling)이나 롱폴링(Long-Polling)이 낭비하던 무거운 HTTP 헤더 오버헤드와 잦은 연결 맺음/끊음 지연을 99% 이상 제거하여, 채팅, 게임, 주식 호가창 같은 초저지연 실시간 양방향 서비스 구현을 가능하게 했다.

융합: TCP 소켓과 유사하지만 웹 환경(80/443 포트)의 방화벽을 우회할 수 있도록 교묘하게 설계되었으며, 상태 유지(Stateful) 특성 탓에 로드밸런서 증설 시 세션 클러스터링이나 Pub/Sub(Redis) 아키텍처 확장이 필수적으로 요구되는 인프라적 도전을 동반한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: WebSocket은 ws:// (암호화 시 wss://) 스킴을 사용하는 HTML5 표준 프로토콜이다. 초기에 HTTP로 핸드셰이크를 수행하여 웹 서버의 포트(80 또는 443)를 그대로 통과한 뒤, 프로토콜을 WebSocket으로 '업그레이드'하여 순수한 양방향 스트리밍 소켓처럼 동작한다.
필요성: 근본적으로 HTTP는 철저한 "단방향(Half-Duplex), 요청-응답(Request-Response)" 아키텍처다. 클라이언트가 물어보지 않으면, 서버는 아무리 급한 일(새로운 카톡 메시지, 주식 급등)이 생겨도 클라이언트에게 먼저 데이터를 보낼 방법이 없었다. 실시간 주식 호가창을 만들기 위해 프론트엔드가 1초마다 서버에 "변한 거 없어요?"라고 끝없이 질문(Polling)을 날렸으나, 이는 매번 무거운 HTTP 헤더를 실어 나르고 서버 CPU를 낭비하는 끔찍한 오버헤드를 낳았다. "서버가 클라이언트에게 언제든 마음대로 데이터를 밀어 넣을 수 있는 진짜 파이프(소켓)"가 웹 브라우저 안에도 절실했다.
💡 비유: HTTP 폴링 방식이 직원이 상사 자리에 1분에 한 번씩 찾아가 "지시할 일 있습니까?"라고 묻고 되돌아오는 무한 반복의 피곤한 삶이라면, 웹소켓(WebSocket)은 직원의 책상과 상사의 책상 사이에 끊기지 않는 **'실통화 핫라인 전화기'**를 연결해 두고, 상사든 직원이든 용건이 생기면 언제든 수화기에 대고 말하는 완벽한 실시간 소통 시스템입니다.
등장 배경:
1. 실시간 웹의 열망과 꼼수: 폴링(Polling), 롱폴링(Long-Polling, 응답을 쥐고 있다가 변화가 생기면 응답), 스트리밍(Streaming) 등 서버 부하를 담보로 한 Comet 기법들이 난무했다.
2. 오버헤드 폭발: 1바이트짜리 주식 가격을 받기 위해, 클라이언트는 800바이트짜리 HTTP 헤더와 쿠키를 매초마다 날려야 했고, 네트워크 트래픽의 99%가 헤더 찌꺼기로 버려졌다.
3. HTML5 표준화: 2011년 IETF에서 WebSocket 스펙(RFC 6455)이 제정되며, 브라우저에 C언어의 TCP 소켓과 유사한 파이프라인이 정식으로 탑재되었다.

┌─────────────────────────────────────────────────────────────┐
│          HTTP Polling vs WebSocket 아키텍처 및 페이로드 비교     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ ❌ 구시대 방식: HTTP Polling ]                              │
│                                                             │
│ Client ──(HTTP 요청 + 무거운 헤더/쿠키 800 Bytes)──▶ Server     │
│ Client ◀──(HTTP 응답 + 무거운 헤더 + "변화없음")── Server     │
│ Client ──(HTTP 요청 + 무거운 헤더/쿠키 800 Bytes)──▶ Server     │
│ Client ◀──(HTTP 응답 + 무거운 헤더 + "변화없음")── Server     │
│ 🌟 결과: 매초마다 엄청난 트래픽 낭비, 서버 연결/종료 부하 극심         │
│                                                             │
│ [ ✅ 현대 방식: WebSocket (Full-Duplex) ]                     │
│                                                             │
│ Client ──(최초 1회 HTTP Upgrade 핸드셰이크)─────▶ Server     │
│ Client ◀──(101 Switching Protocols 수락)─── Server     │
│          ====== [ 영구적인 TCP 파이프 연결 완료 ] ======         │
│                                                             │
│ Client ──(Frame: 단 2 Bytes 헤더 + "채팅")───▶ Server     │
│ Client ◀──(Frame: 단 2 Bytes 헤더 + "알림")─── Server     │
│ Client ◀──(Frame: 단 2 Bytes 헤더 + "주식")─── Server     │
│ 🌟 결과: 연결을 유지한 채 2바이트 초경량 프레임으로 마음껏 양방향 핑퐁!  │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] HTTP 폴링은 "상태가 없는(Stateless) 단방향 통신"의 한계를 극복하기 위한 억지 꼼수였다. 질문할 때마다 무거운 패딩 옷(HTTP 헤더와 쿠키)을 매번 껴입고 왕복해야 한다. 반면 WebSocket은 처음에만 HTTP 옷을 입고 인사를 나눈 뒤, 수락(101 Switching Protocols)을 받으면 즉시 HTTP의 껍데기를 훌렁 벗어던진다. 그리고 가벼운 프레임(최소 2바이트 오버헤드) 형태의 알맹이 데이터만 끝없이 연결된 고속도로(TCP 소켓) 위로 자유롭게 쏘아댄다. 전송 효율성 면에서 HTTP 폴링 대비 수백 배 이상의 개선이 일어난다.

📢 섹션 요약 비유: 매번 새 편지봉투를 사서 우표(HTTP 헤더)를 붙이고 주소를 적어 보내는 답답한 펜팔에서, 무제한 데이터 요금제로 평생 켜져 있는 카카오톡(웹소켓)으로 진화한 것과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

구성 요소

요소명	역할	특징 및 원리	비유
Upgrade Header	일반 HTTP를 웹소켓으로 신분 상승시키는 마법의 헤더	`Connection: Upgrade`, `Upgrade: websocket` 명시	"이제부터 우리 다른 언어로 대화하자"는 제안
Sec-WebSocket-Key	연결이 무작위 캐시에 의해 왜곡되지 않았는지 검증하는 보안 난수표	클라이언트가 생성해 보내면, 서버가 특정 해시 공식으로 연산해 반환	비밀 암호 검증
101 Switching Protocols	웹소켓 변환 성공을 알리는 HTTP 상태 코드	이 응답이 떨어지는 순간 HTTP 프로토콜은 죽고 소켓만 남음	신분 상승 승인 도장
Frame (프레임)	웹소켓이 데이터를 쪼개어 보내는 최소 통신 단위	HTTP 헤더(수백 바이트)를 버리고 단 2~10 바이트로 축소된 초경량 헤더	포장지 없는 속알맹이 택배
Ping / Pong Frame	영구 연결된 소켓이 끊어지지 않도록 확인하는 생존 박동(Heartbeat)	텍스트/바이너리 외에 뼈대 유지용 제어(Control) 프레임	"너 살아있니?" "어 살아있어"

WebSocket 핸드셰이크와 프레이밍(Framing) 메커니즘

웹소켓은 처음부터 새로운 포트를 뚫지 않는다. 기업이나 공공기관의 방화벽(Firewall)은 기본적으로 웹 포트(80, 443) 외에는 모두 막아버리기 때문이다. 따라서 교묘하게 브라우저의 기본 포트를 타고 들어가 안에서 구조를 바꾼다.

┌───────────────────────────────────────────────────────────────┐
│               WebSocket 최초 연결 및 신분 상승 로직               │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│ [ 1. HTTP Request (클라이언트 ➔ 서버) ]                           │
│ GET /chat HTTP/1.1                                            │
│ Host: server.example.com                                      │
│ Upgrade: websocket                ◀─ "웹소켓으로 폼 체인지 원함"      │
│ Connection: Upgrade               ◀─ "이 연결의 성질을 바꾸겠다"      │
│ Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== ◀─ (클라이언트 난수) │
│ Sec-WebSocket-Version: 13                                     │
│                                                               │
│ [ 2. HTTP Response (서버 ➔ 클라이언트) ]                          │
│ HTTP/1.1 101 Switching Protocols  ◀─ "오케이! 폼 체인지 승인"       │
│ Upgrade: websocket                                            │
│ Connection: Upgrade                                           │
│ Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= ◀─(해시 답변)│
│                                                               │
│ 💥 이 순간부터 HTTP 끝! TCP 소켓이 직접 연결된 완전 양방향 상태 진입!     │
│                                                               │
│ [ 3. Data Frame (양방향 이진 통신 시작) ]                         │
│ Frame 1 (Opcode: Text, Payload: "Hello Server!")              │
│ Frame 2 (Opcode: Binary, Payload: [0x12, 0x34...])            │
│ Frame 3 (Opcode: Ping) ➔ 서버 응답: Frame 4 (Opcode: Pong)       │
└───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 핸드셰이크의 핵심은 1번과 2번의 교환이다. 클라이언트가 던진 Sec-WebSocket-Key 난수에, 서버는 전 세계 웹소켓 스펙에 하드코딩된 마법의 문자열(GUID)을 붙인 뒤 SHA-1 해시 함수에 돌려서 Sec-WebSocket-Accept로 되돌려준다. 이 복잡한 검증은 중간의 오지랖 넓은 프록시(Proxy) 서버나 구형 캐시 서버가 웹소켓 연결을 단순 HTTP 응답으로 착각하여 엉뚱한 데이터를 클라이언트에 캐싱해주는 치명적 사고를 막기 위한 스펙이다. 이 인증을 통과해 101 응답이 떨어지면, 그때부터 브라우저와 서버는 무거운 HTTP 옷을 벗고 날렵한 Data Frame만으로 서로 공격적인 핑퐁(Ping-Pong)을 시작한다.

📢 섹션 요약 비유: 적국(방화벽)의 국경을 통과하기 위해 처음에는 평범한 농부의 옷(HTTP 80포트)을 입고 검문소를 통과한 뒤, 성 안에 들어오자마자 옷을 벗어 던지고 날렵한 닌자(양방향 소켓)로 돌변하여 임무를 수행하는 완벽한 잠입 액션입니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: WebSocket vs SSE vs Long-Polling

실시간 데이터를 얻기 위한 3가지 대표 아키텍처의 트레이드오프다.

항목	WebSocket (웹소켓)	SSE (Server-Sent Events)	Long-Polling (롱 폴링)
통신 방향	양방향 (Full-Duplex)	단방향 (서버 ➔ 클라이언트 푸시)	단방향 모방 (요청 후 무한 대기)
베이스 프로토콜	TCP 직접 제어 (HTTP 101 업그레이드)	철저한 HTTP/1.1 또는 HTTP/2 기반	순수 HTTP
자동 재접속	미지원 (끊어지면 JS로 직접 재연결 코드 짜야 함)	기본 내장 (브라우저가 알아서 끈질기게 다시 붙음)	수동으로 타임아웃 처리 구현 필수
데이터 포맷	이진 데이터(Binary) 및 텍스트 완벽 지원	텍스트(UTF-8)만 전송 가능	제약 없음 (HTTP 응답)
최고의 사용처	다중 접속 채팅, 실시간 주식 호가, 찰나의 멀티플레이 게임	카톡 알림 푸시, SNS 피드 업데이트, 뉴스 티커	웹소켓/SSE 지원 불가한 극악의 레거시 망

결론적으로 클라이언트가 서버로 보낼 데이터는 거의 없고 "서버가 일방적으로 알림만 내려주는" 구조(주식 시세, 인스타 알림)라면 무겁고 재접속 코딩이 귀찮은 WebSocket보다 SSE가 압도적으로 효율적이다. 양방향으로 쉴 새 없이 치고받아야 하는 채팅이나 게임에서만 WebSocket을 꺼내 들어야 한다.

과목 융합 관점

보안 (Security): wss:// (WebSocket Secure)는 HTTPS 환경과 동일하게 밑바탕에 TLS(Transport Layer Security) 계층을 깔고 소켓 통신을 암호화한다. 또한 웹소켓은 브라우저의 CORS(교차 출처 자원 공유) 정책이나 SOP(동일 출처 정책)의 보호를 느슨하게 받기 때문에(Origin 헤더만 검사), 해커가 악성 사이트에서 남의 은행 웹소켓 서버로 소켓을 연결해버리는 CSWSH(Cross-Site WebSocket Hijacking) 공격에 노출될 수 있어 백엔드 단의 철저한 Origin 검증이 필수다.
📢 섹션 요약 비유: 롱폴링이 '택배 아저씨 바짓가랑이를 붙잡고 안 놔주는 것'이라면, SSE는 '라디오 방송국에서 뉴스만 일방적으로 틀어주는 것'이고, 웹소켓은 '친구와 완벽하게 무전기로 쉴 새 없이 수다를 떠는 것'입니다.

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

실무 시나리오

시나리오 — L7 로드밸런서 증설 후 웹소켓 연결 붕괴 (Connection Drop): 스타트업이 채팅 서버를 3대로 스케일아웃(Scale-out)하고 앞단에 Nginx 로드밸런서를 붙였다. 그런데 사용자들의 채팅이 30초마다 툭툭 끊기고 101 Switching Protocols 업그레이드가 실패하는 장애가 터졌다.
- 판단: 웹소켓은 "연결이 지속되는 Stateful" 아키텍처다. 클라이언트 A가 1번 서버와 소켓을 뚫었는데, 다음 Ping 프레임이 Nginx 라운드 로빈에 의해 2번 서버로 가버리면 연결이 깨진다. 실무 인프라에서는 L7 로드밸런서(Nginx, AWS ALB) 설정에서 반드시 **Sticky Session (IP Hash 등)**을 켜서, 웹소켓을 한 번 맺은 놈은 죽을 때까지 그 서버로 꽂아주도록 아키텍처를 강제해야 한다. 또 Nginx의 기본 프록시 타임아웃(60초)을 무제한급으로 늘려주어야 소켓이 안 잘린다.
시나리오 — 마이크로서비스 간 채팅 메시지 유실 (Pub/Sub 부재): 사용자 A는 1번 채팅 서버에 웹소켓이 연결되어 있고, 사용자 B는 2번 채팅 서버에 연결되어 있다. A가 B에게 "안녕"이라고 보냈으나, 1번 서버는 B가 자신과 소켓이 연결되어 있지 않아 메시지를 씹어버렸고, 2번 서버의 B에게 전달되지 않는 사태가 발생했다.
- 판단: 웹소켓을 다중 서버로 운영하려면 서버 단독으로는 절대 아키텍처를 완성할 수 없다. 백엔드 뒤에 Redis Pub/Sub 또는 Kafka 같은 메시지 브로커를 달아야 한다. 1번 서버가 "안녕"을 받으면 브로커로 쏘아 올리고(Publish), 모든 채팅 서버(1, 2, 3번)가 이 브로커를 구독(Subscribe)하고 있다가, B와 소켓을 잡고 있는 2번 서버가 그 메시지를 가로채서 B의 웹소켓 파이프라인으로 내려보내는 분산 Pub/Sub 아키텍처가 필수불가결하다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: 다중 서버 환경의 WebSocket Pub/Sub 구조     │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [Client A]  (목적지: B에게 채팅 쏨)        [Client B]           │
  │     │                                         ▲             │
  │  (WebSocket)                              (WebSocket)       │
  │     │                                         │             │
  │     ▼                                         │             │
  │ [WAS 1번 서버]   ── (1번 서버엔 B가 없다!) ──  [WAS 2번 서버]     │
  │     │                                         ▲             │
  │     │ 1. Publish (발행)                        │ 3. 메시지 캐치│
  │     │    "B에게 전달해줘: 안녕"                   │   & 소켓전송  │
  │     ▼                                         │             │
  │  ======================================================     │
  │  │         Redis Pub/Sub (또는 Kafka Broker)          │     │
  │  │  2. 수신된 메시지를 모든 구독 WAS 서버로 브로드캐스팅(전파)│     │
  │  ======================================================     │
  │                                                             │
  │ ✅ 판단 지점: 웹소켓 서버를 스케일아웃하려면 그들의 뒤통수를 묶어주는 │
  │    거대한 중앙 신경망(메시지 큐) 설계가 반드시 동반되어야 한다!       │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 웹소켓의 상태 유지(Stateful) 특성은 클라우드 네이티브의 수평 확장성(Scale-out) 철학과 정면으로 충돌한다. 백엔드 개발자가 Socket.io나 Spring WebSocket으로 로컬 환경에서 완성한 채팅 코드가 프로덕션 환경(서버 10대)에 올라가면 100% 무너지는 이유가 여기에 있다. A가 서버 1번에 붙고, B가 서버 2번에 붙어있다면, 두 서버는 서로의 존재를 모른다. 이 단절을 극복하기 위해 Redis라는 외부 장부(Pub/Sub)를 도입하여, 어떤 서버가 메시지를 받든 중앙에 던지고 모든 서버가 귀를 기울이게 만드는 것이 대용량 실시간 서버 설계의 뼈대다.

도입 체크리스트

기술적: 클라이언트가 네트워크 음영 지역(터널 등)을 지날 때 TCP 껍데기는 살아있는데 실제 핑이 안 가는 'Half-Open' 좀비 커넥션을 끊어내기 위해, 앱 단과 서버 단 양쪽 모두 자체적인 Heartbeat (Ping/Pong) 타이머 로직이 구현되어 있는가?
운영·보안적: Nginx나 HAProxy, AWS ALB 등 중간 게이트웨이의 proxy_read_timeout 설정이 짧게 잡혀 있어 멀쩡하게 연결된 웹소켓을 1분마다 강제 절단(Drop)하고 있지 않은지 인프라 설정을 전수 조사했는가?

안티패턴

단방향 데이터 조회(GET 성향)에 웹소켓 남발: "웹소켓이 최신 기술이니까 빠르겠지?"라는 착각으로, 단순히 유저 프로필 정보를 1회 조회하거나, 결제 완료 여부를 한 번 조회하는 일반 REST(Stateless) 로직까지 전부 웹소켓 프레임에 때려 박는 행위. 이는 클라이언트 수백만 명의 TCP 연결을 강제로 붙들고 있게 하여 서버 RAM을 순식간에 고갈시키는 미친 짓이다.
📢 섹션 요약 비유: 웹소켓은 끊을 수 없는 '실가닥 전화기'입니다. 긴박한 작전 회의(채팅, 게임)를 할 때는 팽팽하게 당겨두는 게 맞지만, 그냥 "오늘 날씨 어때?"라고 한 번 물어볼 거라면 전화선을 개통할 게 아니라 그냥 문자메시지(HTTP REST) 한 통을 띡 보내고 마는 게 훨씬 경제적입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	기존 HTTP Polling 환경	WebSocket 프로토콜 전환 후	개선 효과
정량	1회 요청마다 800Byte 이상의 HTTP 헤더 낭비	2~10Byte의 초경량 바이너리 프레임 사용	네트워크 대역폭 낭비 99% 이상 제거
정량	매초마다 잦은 TCP 3-Way 연결/끊음 오버헤드	단 1번의 TCP 유지로 영구 사용	체감 실시간 딜레이 수 밀리초(ms) 단위로 진입
정성	불필요한 서버 조회로 백엔드 부하 폭증	변화가 있을 때만 핑퐁 전송	인프라 부하 감소 및 극한의 멀티플레이 게임 UX 달성

미래 전망

HTTP/2와 HTTP/3 확장: 기존 웹소켓은 HTTP/1.1의 위에서 TCP를 통째로 장악하는 방식이라, HTTP/2의 멀티플렉싱(하나의 연결로 여러 데이터 섞어 쏘기)의 축복을 받지 못했다. 최근 RFC 8441 스펙을 통해 HTTP/2의 단일 스트림 내에서도 WebSocket 파이프를 뚫어, 여러 웹소켓 연결을 하나의 HTTP/2 소켓 위에 멀티플렉싱하는 고도화 기술이 브라우저들에 적용되고 있다.
WebTransport의 위협: 웹소켓의 경쟁자로 구글이 밀고 있는 HTTP/3(QUIC) 기반의 WebTransport API가 급부상 중이다. TCP 기반의 웹소켓이 갖는 치명적 약점인 패킷 유실 시 HOL(Head-of-Line) 블로킹 문제를, UDP(QUIC) 위에서 여러 독립 스트림을 열어 완벽히 해결한 차세대 실시간 프로토콜이다. 게임 업계에서는 이미 웹소켓을 넘어 WebTransport로 눈을 돌리고 있다.

참고 표준

RFC 6455: The WebSocket Protocol
W3C WebSocket API: 브라우저 환경에서 제어하기 위한 자바스크립트 인터페이스 스펙

웹소켓은 "문서를 보여주기 위한 단방향 기술"로 출발했던 웹(WWW)의 태생적 한계를 깨부수고, 브라우저를 완벽한 '양방향 애플리케이션 플랫폼'으로 진화시킨 역사적 징검다리다. 무거운 HTTP의 사다리를 타고 올라가 도착하자마자 사다리를 걷어차 버리는 그 우아한 핸드셰이크 메커니즘은, 레거시 인프라(방화벽, 80포트)를 거스르지 않고 혁신을 끼워 넣은 네트워크 공학의 훌륭한 타협점이자 정수다.

📢 섹션 요약 비유: 옛날에는 라디오 신청곡을 들으려면 방송국에 매번 엽서(HTTP 요청)를 통째로 써서 보내고 죽어라 기다려야 했습니다. 웹소켓은 방송국 DJ와 다이렉트로 연결된 전용 전화선(TCP 파이프)을 내 방에 놔주어, 엽서 봉투 따위 없이 바로바로 입으로 말을 주고받게 해준 기적의 통신망입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
HTTP Upgrade Header	웹소켓으로 통신 방식을 전환(Switching Protocols)하기 위해 최초 한 번만 사용되는 일회성 HTTP 변신 마법 주문이다.
TCP (Transmission Control Protocol)	웹소켓이 껍데기를 벗고 나면 그 밑바탕을 지탱하는 영구적이고 신뢰성 있는 전송 계층의 진짜 고속도로다.
SSE (Server-Sent Events)	굳이 양방향 통신이 필요 없고 서버가 일방적으로 알림(Push)만 밀어낼 때, 웹소켓 대신 선택해야 하는 경량화된 단방향 대안 아키텍처다.
Redis Pub/Sub	분산 서버 환경에서 웹소켓의 한계(서버 간 소통 불가)를 연결해주는 메시지 브로커 신경망의 글로벌 표준이다.
Socket.io / SockJS	웹소켓 기술 자체가 구형 브라우저나 방화벽에 막혔을 때, 롱폴링(Long-polling) 같은 구닥다리 방식으로 알아서 등급을 낮춰(Fallback) 연결을 유지해주는 상위 프레임워크다.

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

옛날 인터넷은 궁금한 게 있을 때마다 엄마(서버)한테 다가가서 "다 됐어?"라고 수백 번씩 물어봐야(Polling) 했어요. 엄마도 나도 너무 피곤했죠.
웹소켓은 엄마와 내 방 사이에 팽팽한 **'실 전화기'**를 연결해둔 거예요. 언제든 궁금한 게 있으면 입만 대고 물어보고, 엄마도 밥 다 되면 바로 실 전화기로 말해주죠!
무겁게 매번 방문을 열고 왔다 갔다 할 필요 없이, 끊어지지 않는 실 전화기(TCP 연결) 하나로 하루 종일 쉴 새 없이 수다를 떨 수 있는 마법 같은 기술이랍니다!