안녕! 개발자 친구. 혹시 이런 생각해 본 적 없어?

유튜브 라이브 방송을 보는데 수만 명의 채팅이 딜레이 없이 착착 올라오고,
코인 시세 그래프는 1초도 쉬지 않고 미친 듯이 움직이잖아.
배달 앱에서 주문한 치킨이 어디쯤 오고 있는지도 실시간으로 보이고 말이야.

"아니, 대체 어떻게 웹페이지가 가만히 있지 않고
서버에서 오는 데이터를 실시간으로 화면에 뿌려주는 거지?"

이런 궁금증, 개발자라면 한 번쯤은 품어봤을 거야. 맞아, 이건 그냥 마법이 아니야.
바로 **실시간(Real-time) 통신 기술** 덕분이지.

과거의 웹은 클라이언트가 "나 정보 좀 줘!" 하고 요청(Request)하면 서버가 "여기 있어!" 하고 응답(Response)하는 단방향 소통이 기본이었어. 이걸로는 어림도 없지. 실시간 서비스는 서버가 원할 때, 데이터가 생길 때마다 먼저 클라이언트에게 "야, 데이터 왔어! 받아!" 하고 말을 걸 수 있어야 하거든.

오늘 우리는 이 실시간 웹을 구현하는 대표적인 두 명의 플레이어,
바로 **웹소켓(WebSocket)**과 **서버-센트 이벤트(Server-Sent Events, 이하 SSE)**에 대해 아주 깊고, 재밌게 파헤쳐 볼 거야.

둘 다 실시간 통신을 위한 기술이지만, 성격도 다르고, 잘하는 것도, 못하는 것도 명확해.
마치 공격수와 수비수처럼 말이지. 어떤 상황에서 누굴 투입해야 우리 팀(프로젝트)이 승리할 수 있을까?
이 글을 다 읽고 나면 넌 실시간 기능이 필요한 프로젝트에서 어떤 기술을 선택해야 할지 명확한 기준을 갖게 될 거야.

자, 그럼 타임머신을 타고 실시간 통신 기술이 없던 시절로 잠시 돌아가 볼까?

라떼는 말이야... 실시간 흉내 내던 시절 (feat. 폴링 & 롱폴링)

웹소켓과 SSE라는 멋진 기술이 등장하기 전, 개발자들은 어떻게든 실시간 '흉내'를 내려고 눈물겨운 노력을 했어.
그 시절의 대표적인 두 가지 기법이 바로 **폴링(Polling)**과 **롱폴링(Long-Polling)**이야.

1. 폴링 (Polling): "엄마, 다 왔어? 지금은? 이제 다 왔어?"

폴링은 가장 단순하고 무식한(?) 방법이야. 비유하자면, 차 뒷좌석에 탄 아이가 10초에 한 번씩 "엄마, 다 왔어?" 하고 계속 물어보는 것과 같아.

클라이언트가 일정한 주기를 정해놓고 (예: 2초마다) 서버에게 계속해서 "새로운 데이터 없어?" 라고 물어보는 거지. 서버는 데이터가 있든 없든 무조건 응답을 해줘야 해.

자바스크립트에서는 `setInterval` 함수로 아주 간단하게 구현할 수 있어.

// 클라이언트 측 코드 (JavaScript)
setInterval(() => {
  fetch('/api/get-updates')
    .then(response => response.json())
    .then(data => {
      // 새로운 데이터가 있으면 화면을 업데이트한다.
      console.log('새로운 데이터:', data);
      updateUI(data);
    })
    .catch(error => console.error('에러 발생:', error));
}, 2000); // 2초마다 서버에 요청을 보낸다.

폴링의 치명적인 단점

• 네트워크 낭비가 심하다: 대부분의 요청은 "아직 데이터 없어"라는 빈 응답을 받게 돼. 이건 정말 불필요한 트래픽이야. 서버와 클라이언트 모두 피곤해지지.

• 서버 부하 증가: 수많은 클라이언트가 쉴 새 없이 요청을 보내면 서버는 그걸 처리하느라 정신이 없어. 정작 중요한 요청을 처리할 힘이 남아나지 않을 수도 있어.

• 실시간이 아니다: 데이터가 생기는 즉시 받는 게 아니야. 2초 주기로 폴링한다면, 운이 나쁘면 최대 2초의 딜레이가 발생할 수밖에 없어. 주기를 줄이면? 서버 부하만 더 심해지지.

그래서 폴링은 정말 간단한 기능이나, 데이터 변경이 잦지 않고 약간의 딜레이가 허용되는 상황에서만 제한적으로 사용됐어.

2. 롱폴링 (Long-Polling): "연락 올 때까지 기다릴게"

폴링의 비효율을 개선하기 위해 등장한 기법이 바로 롱폴링이야.
이건 "다 왔어?"라고 계속 묻는 대신, "도착하면 바로 알려줘!" 라고 한 번만 말하고, 알려줄 때까지 계속 기다리는 방식이지.

클라이언트가 서버에 요청을 보내면, 서버는 새로운 데이터가 생길 때까지 응답을 주지 않고 연결을 계속 붙들고 있어. 그러다가 마침내 데이터가 생기면 그때서야 클라이언트에게 응답을 보내고 연결을 종료하지. 클라이언트는 데이터를 받자마자 곧바로 다시 새로운 요청을 보내서 다음 데이터를 기다리는 거야.

롱폴링은 폴링에 비해 불필요한 요청을 획기적으로 줄였어. 데이터가 있을 때만 응답이 오니까 네트워크 낭비가 훨씬 덜하지. 딜레이도 거의 없고. 그래서 한때는 실시간 웹의 '표준'처럼 여겨지기도 했어.

하지만 롱폴링도 완벽하진 않아

• 서버 자원 소모: 서버는 수많은 클라이언트와의 연결을 계속 열어둬야 해. 이건 상당한 메모리와 CPU 자원을 소모하는 일이야. 특히 데이터 발생 주기가 길면 길수록 더 그렇지.

• 구현의 복잡성: 서버 쪽에서 타임아웃 처리, 연결 관리 등을 섬세하게 구현해야 해서 폴링보다 복잡해.

• 여전한 HTTP의 한계: 결국 요청-응답이라는 HTTP의 기본 구조를 벗어나지 못했어. 데이터를 보낼 때마다 연결을 새로 맺어야 하고, 매번 무거운 HTTP 헤더가 따라붙는다는 한계가 있지.

이런 '가짜' 실시간의 시대는 결국 진짜 실시간 기술의 등장을 갈망하게 만들었어.
개발자들은 더 이상 HTTP의 굴레 안에서 꼼수를 부리고 싶지 않았지. "아예 처음부터 실시간 통신을 위한 새로운 길이 필요해!" 라는 목소리가 커졌고, 마침내 두 명의 영웅이 등장하게 돼.

양방향 소통의 신세계, 웹소켓(WebSocket) 등판!

폴링과 롱폴링의 한계에 답답해하던 개발자들에게 2011년, 구세주처럼 등장한 기술이 바로 **웹소켓(WebSocket)**이야. 이건 기존의 HTTP와는 완전히 궤를 달리하는, 태생부터 실시간 통신을 위해 태어난 새로운 프로토콜이지.

웹소켓을 한마디로 정의하면, **"클라이언트와 서버 사이에 하나의 TCP 연결을 통해 양방향으로, 아주 적은 비용으로, 실시간 데이터 교환을 가능하게 하는 기술"**이야.

비유하자면, 롱폴링까지는 편지를 주고받는 것과 비슷했어. 편지를 보내고(요청), 답장을 기다리고(응답), 답장을 받으면 또 편지를 보내고... 하지만 웹소켓은 아예 **전화기**를 놓는 것과 같아. 한번 연결되면, 나와 상대방(클라이언트와 서버)은 누구든 먼저, 원할 때, 동시에 말할 수 있지. "여보세요?" 하고 계속 물어볼 필요도 없어.

웹소켓은 어떻게 작동할까? (feat. 악수와 변신)

웹소켓의 연결 과정은 아주 흥미로워. 바로 '악수(Handshake)'라는 과정을 통해 HTTP에서 웹소켓 프로토콜로 '변신'하거든.

1. 시작은 HTTP로: 클라이언트는 웹소켓 연결을 시작하기 위해 먼저 평범한 HTTP 요청을 서버에 보내. 하지만 여기엔 특별한 헤더가 포함되어 있어. "저... 혹시 웹소켓으로 업그레이드 가능하신가요?" 라는 신호지.

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

   여기서 `Upgrade: websocket`과 `Connection: Upgrade` 헤더가 바로 "웹소켓으로 대화 방식을 바꾸자!"는 제안이야.

2. 서버의 응답과 프로토콜 전환: 서버가 웹소켓을 지원한다면, "좋아! 웹소켓으로 전환하자!" 라는 의미의 특별한 응답을 보내. 상태 코드는 `101 Switching Protocols` 이지.

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

3. 전용 터널 개통: 이 '악수'가 성공적으로 끝나면, 둘 사이의 HTTP 연결은 끊어지고, 그 아래에 있던 TCP 연결 위로 `ws://` 또는 `wss://`(보안 연결) 라는 이름의 새로운 프로토콜 터널이 열려. 이제부터 둘은 이 전용 터널을 통해 자유롭게 데이터를 주고받는 거야.

이 터널이 한번 열리면, 데이터를 보낼 때마다 무거운 HTTP 헤더를 붙일 필요가 없어. 아주 작은 크기의 **프레임(Frame)** 단위로 데이터를 가볍고 빠르게 주고받을 수 있게 되지. 이게 웹소켓이 압도적으로 빠른 이유야.

웹소켓, 너의 장점은 뭐니?

• 진정한 양방향 통신 (Full-Duplex): 클라이언트와 서버가 서로 독립적으로, 동시에 데이터를 보낼 수 있어. 채팅 앱에서 내가 메시지를 입력하는 동시에 상대방의 메시지를 받을 수 있는 이유가 바로 이거야.

• 압도적인 성능: 한번 연결되면 아주 적은 오버헤드(약 2바이트)로 데이터를 주고받아. HTTP 헤더(수백 바이트)와는 비교가 안 되지. 그래서 지연 시간이 매우 짧고, 초당 수많은 메시지를 처리해야 하는 애플리케이션에 최적화되어 있어.

• 다양한 데이터 포맷 지원: 텍스트 데이터(JSON 등)는 물론, 이미지나 동영상 같은 바이너리 데이터도 효율적으로 전송할 수 있어.

물론 단점도 있어.

• 구현의 복잡성: SSE에 비해 서버 측 구현이 다소 복잡해. 연결 상태를 관리하고, 수많은 동시 접속을 효율적으로 처리하기 위한 별도의 웹소켓 서버나 라이브러리(예: Node.js의 `ws`, `Socket.IO`)가 필요해.

• 오래된 프록시 서버와의 호환성 문제: 일부 구형 방화벽이나 프록시 서버는 웹소켓의 '업그레이드' 요청을 이해하지 못하고 연결을 차단하는 경우가 드물게 발생할 수 있어. (물론 요즘은 거의 해결된 문제야.)

• 상태 유지(Stateful): 서버는 연결된 모든 클라이언트의 연결 상태를 계속 유지하고 있어야 해. 클라이언트 수가 기하급수적으로 늘어나면 서버의 메모리 부담이 커질 수 있지. 스케일 아웃(서버 증설) 전략을 잘 세워야 해.

웹소켓은 언제 사용할까?

**"클라이언트와 서버 간의 빈번하고 즉각적인 상호작용이 필수적인 경우"** 라면 무조건 웹소켓이야.

• 실시간 채팅 애플리케이션: 내가 메시지를 보내고, 상대방의 메시지를 동시에 받아야 하니 양방향 통신이 필수적이다.

• 온라인 멀티플레이어 게임: 나의 움직임을 서버에 즉시 보내고, 다른 플레이어들의 움직임을 실시간으로 받아야 한다. 0.1초의 딜레이도 치명적일 수 있다.

• 공동 작업 도구 (Google Docs, Figma 등): 여러 사용자가 동시에 문서를 편집하거나 디자인할 때, 각자의 변경 사항이 모든 참여자에게 즉시 반영되어야 한다.

• 실시간 주식/코인 거래 시스템: 빠른 시세 변동을 차트에 그리고, 매수/매도 주문을 즉시 처리해야 한다.

이처럼 웹소켓은 '속도'와 '상호작용'이 생명인 서비스에서 대체 불가능한 강력함을 보여줘.

서버의 일방적인 속삭임, 서버-센트 이벤트(SSE)

웹소켓이 양방향 통신의 화려한 스타 플레이어라면, **서버-센트 이벤트(SSE)**는 묵묵히 자기 역할을 120% 해내는 조용한 영웅과 같아. 이름(Server-Sent Events)에서 알 수 있듯이, 이 기술은 **오직 서버에서 클라이언트로만 데이터를 보내는(단방향)** 상황에 특화되어 있어.

SSE는 웹소켓처럼 새로운 프로토콜이 아니야. 그냥 **기존의 HTTP 프로토콜을 그대로 사용**해. 이게 SSE의 가장 큰 장점이자 핵심 아이덴티티지.

비유하자면, SSE는 **라디오 방송**이나 **뉴스레터 구독**과 비슷해. 방송국(서버)에서 계속해서 정보를 보내주면, 나는 라디오(클라이언트)를 켜놓고 듣기만 하면 돼. 내가 방송국에 대고 말을 할 수는 없지. 만약 할 말이 있다면? 따로 전화를 걸거나(새로운 HTTP 요청) 편지를 보내야(별도의 POST 요청) 하는 거야.

SSE는 어떻게 작동할까? (feat. 끊어지지 않는 HTTP)

SSE의 작동 방식은 웹소켓보다 훨씬 간단해.

1. 클라이언트의 구독 요청: 클라이언트는 자바스크립트의 `EventSource` 객체를 사용해서 서버의 특정 주소로 연결을 요청해. 이건 그냥 평범한 GET 요청이야.

   // 클라이언트 측 코드 (JavaScript)
   const eventSource = new EventSource('/api/stream-updates');

2. 서버의 특별한 응답: 요청을 받은 서버는 "알았어, 이제부터 내가 보내는 이벤트들을 계속 스트리밍해줄게" 라는 의미로 특별한 헤더와 함께 응답을 시작해. 바로 `Content-Type: text/event-stream` 이지. 그리고 중요한 건, **연결을 끊지 않고 계속 열어둔다**는 거야.

   // 서버 측 응답 헤더 예시
   HTTP/1.1 200 OK
   Content-Type: text/event-stream
   Cache-Control: no-cache
   Connection: keep-alive

3. 이벤트 스트림 전송: 이제 서버는 데이터가 생길 때마다 정해진 포맷에 맞춰 클라이언트로 데이터를 계속 흘려보내(stream). 클라이언트는 `onmessage` 이벤트 리스너를 통해 이 데이터를 받아서 처리하면 돼.

   // 서버가 보내는 데이터 스트림의 형태
   data: {"id": 1, "message": "첫 번째 알림입니다."}\n\n
   
   data: {"id": 2, "message": "새로운 뉴스가 도착했습니다!"}\n\n
   
   event: user-update
   data: {"username": "재능넷", "status": "online"}\n\n
   

   데이터는 `data:` 로 시작해야 하고, 각 이벤트는 `\n\n` (두 개의 개행 문자)으로 구분돼. `event:` 필드를 사용하면 이벤트 종류를 지정해서 클라이언트에서 다르게 처리할 수도 있어. 아주 직관적이지?

SSE, 너의 매력 포인트는?

• 압도적인 단순함: 웹소켓에 비해 구현이 정말 쉬워. 서버에서는 그냥 HTTP 응답 스트림에 정해진 형식으로 텍스트를 써 내려가기만 하면 되고, 클라이언트에서는 `EventSource` API만 쓰면 끝. 별도의 라이브러리가 거의 필요 없어.

• HTTP 기반의 높은 호환성: 기존 HTTP 위에서 동작하므로 웹소켓처럼 프록시나 방화벽 문제를 걱정할 필요가 거의 없어. 웹 생태계와 완벽하게 호환되지.

• 자동 재연결 기능: 이게 정말 꿀 기능인데, 만약 네트워크 문제로 연결이 끊어지면 클라이언트의 `EventSource`가 자동으로 서버에 재연결을 시도해. 웹소켓에서는 이 로직을 직접 구현해야 하지만, SSE는 브라우저가 알아서 해준다니! 정말 편리하지.

• 이벤트 타입 지정: 위 코드 예시처럼 `event:` 필드를 통해 이벤트의 종류를 명시할 수 있어. 클라이언트는 `addEventListener('user-update', ...)` 와 같이 특정 이벤트만 골라서 들을 수 있어서 코드를 깔끔하게 관리하기 좋아.

물론 SSE의 한계도 명확해.

• 단방향 통신: 가장 큰 한계점이야. 오직 서버 -> 클라이언트로만 데이터를 보낼 수 있어. 클라이언트가 서버에 뭔가를 보내려면, 별도의 `fetch`나 `axios`를 사용한 HTTP 요청을 날려야 해.

• 바이너리 데이터 미지원: SSE는 UTF-8 형식의 텍스트 데이터 전송을 위해 설계되었어. 이미지 같은 바이너리 데이터를 보내려면 Base64 인코딩 같은 번거로운 과정을 거쳐야 하는데, 이건 비효율적이야.

• 브라우저별 동시 연결 수 제한: SSE는 하나의 HTTP 연결을 계속 사용해. 그런데 브라우저는 보통 하나의 도메인에 대해 동시에 열 수 있는 HTTP 연결의 수가 6개 정도로 제한되어 있어. 만약 한 페이지에서 여러 개의 SSE 연결을 사용하거나 다른 API 요청이 많아지면 병목 현상이 발생할 수 있어. (HTTP/2 환경에서는 이 문제가 많이 완화되긴 해.)

• IE/Edge 구버전 미지원: Internet Explorer에서는 지원하지 않아. (하지만 이제 IE는 우리 마음속에서 보내줘야 할 때가 됐지...)

SSE는 언제 사용해야 할까?

**"클라이언트가 서버에 데이터를 보낼 일은 거의 없고, 주로 서버가 보내주는 정보를 받기만 하면 되는 경우"** 라면 SSE가 최고의 선택이야.

• 페이스북/트위터 같은 소셜 미디어의 뉴스 피드: 사용자는 그냥 새로운 게시물을 보기만 하면 된다. 서버가 알아서 새 글을 밀어 넣어주면 된다.

• 실시간 알림: 웹사이트 우측 상단에 뜨는 '새로운 메시지가 도착했습니다' 같은 알림. 사용자가 이 알림 시스템과 상호작용할 일은 거의 없다.

• 주식 시세, 스포츠 경기 실시간 스코어: 데이터가 서버에서 일방적으로 계속 업데이트되어 사용자에게 보여주기만 하면 되는 대표적인 사례다.

• CI/CD 파이프라인 상태 업데이트: 젠킨스나 깃헙 액션에서 빌드/배포 로그를 실시간으로 웹 UI에 보여줄 때 아주 유용하다.

이처럼 SSE는 '서버에서 클라이언트로의 단방향 데이터 푸시'라는 명확한 목적 아래, 가볍고, 간단하고, 안정적인 해결책을 제공하는 아주 실용적인 기술이야.

세기의 대결: 웹소켓 vs SSE, 그래서 뭘 써야 돼?

자, 이제 두 선수의 프로필을 모두 살펴봤어. 웹소켓은 강력한 양방향 펀치를 가진 복서 같고, SSE는 간결하고 효율적인 푸시 알림 전문가 같지. 그럼 가장 중요한 질문이 남았지. "내 프로젝트에는 대체 뭘 써야 할까?"

정답은 없어. "상황에 따라 다르다"가 최고의 정답이야. 둘의 장단점을 한눈에 비교해보고, 어떤 기준으로 선택해야 할지 명확한 가이드를 제시해 줄게.

한눈에 보는 비교 테이블

"이것만 기억해!" 선택을 위한 결정적 질문

아직도 헷갈린다면, 프로젝트를 시작하기 전에 스스로에게 이 질문들을 던져봐.

예를 들어, 프리랜서와 클라이언트를 연결해주는 **재능넷** 같은 플랫폼을 만든다고 상상해보자.
'새로운 프로젝트 의뢰가 등록되었습니다!' 라는 알림을 모든 프리랜서에게 보내주는 기능은 서버가 일방적으로 정보를 푸시하는 것이니 SSE가 완벽한 해결책이 될 수 있어. 아주 간단하고 효율적으로 구현할 수 있지.
하지만 '전문가와 1:1 실시간 채팅 상담' 기능을 만든다면? 이건 클라이언트와 전문가가 서로 메시지를 주고받아야 하니, 두말할 것 없이 웹소켓을 사용해야 해.

결국 기술 선택은 '어느 게 더 좋냐'의 문제가 아니라, '내 문제에 어느 게 더 잘 맞냐'의 문제라는 걸 잊지 마.

이게 끝이 아니라고? WebTransport와 미래

웹소켓과 SSE, 이 두 가지만 알면 현재의 실시간 웹은 거의 정복했다고 볼 수 있어. 하지만 기술의 발전은 멈추지 않지. 개발자들은 항상 '더 빠르고, 더 효율적인' 방법을 찾아 헤매니까.

그래서 잠깐, 실시간 통신의 미래를 엿볼 수 있는 새로운 기술에 대해서도 언급하고 넘어갈게. 바로 **WebTransport**야.

WebTransport: 웹소켓과 SSE의 장점을 합치려는 노력

WebTransport는 현재 W3C에서 표준화가 진행 중인 차세대 통신 프로토콜이야. 이건 HTTP/3의 기반이 되는 **QUIC 프로토콜** 위에서 동작해.

QUIC은 TCP와 UDP의 장점을 결합한 멋진 프로토콜인데, 이걸 기반으로 한 WebTransport는 웹소켓과 SSE의 장점을 모두 흡수하려는 야심 찬 목표를 가지고 있어.

• 여러 개의 독립적인 스트림: 웹소켓은 하나의 연결 안에서 모든 메시지가 순서대로 처리돼야 해서, 만약 큰 메시지 하나가 처리 중이면 뒤따르는 작은 메시지들이 모두 기다려야 하는 문제(Head-of-Line Blocking)가 있었어. WebTransport는 하나의 연결 안에 여러 개의 독립적인 스트림을 만들 수 있어서 이런 문제를 해결해.

• 신뢰성 있는 스트림과 신뢰성 없는 데이터그램 모두 지원: 웹소켓처럼 데이터가 순서대로, 빠짐없이 전달되는 것을 보장하는 '신뢰성 있는 스트림'도 제공하고, 온라인 게임처럼 순서보다는 속도가 더 중요해서 일부 데이터가 유실되어도 괜찮은 경우를 위한 '신뢰성 없는 데이터그램'(UDP와 비슷) 전송 방식도 지원해. 이건 정말 혁신적이지.

• 더 빠른 연결: QUIC 기반이라 연결 설정 속도도 TCP+TLS보다 빨라.

물론 WebTransport는 아직 실험적인 기술이고, 모든 브라우저에서 지원되는 건 아니야. 하지만 웹소켓의 단점을 보완하고 더 유연한 통신을 제공한다는 점에서, 앞으로 몇 년 안에 실시간 웹의 새로운 표준이 될 가능성이 매우 높아. 지금 당장 쓸 수는 없더라도, 이런 기술이 있다는 걸 알아두는 것만으로도 너의 기술적 시야는 한 뼘 더 넓어질 거야.

그래서 오늘의 결론은?

정말 긴 여정이었어! 우리는 실시간을 흉내 내던 폴링의 시대부터, 양방향 통신의 혁명을 가져온 웹소켓, 그리고 단순함과 안정성의 미학을 보여준 SSE까지 모두 살펴봤어.

오늘의 핵심을 다시 한번 요약해볼까?

이론으로 배우는 것도 중요하지만, 개발자에게 최고의 스승은 결국 '코드'야.
작은 토이 프로젝트를 하나 만들어서, 똑같은 기능을 웹소켓으로도 한번 구현해보고, SSE로도 한번 구현해보는 걸 강력히 추천해. 직접 부딪혀보면서 겪는 문제와 해결 과정 속에서 진짜 너의 지식이 될 테니까.

혹시 혼자 하기 막막하다면, **재능넷** 같은 플랫폼에서 마음 맞는 동료를 찾아 사이드 프로젝트를 시작해보는 것도 정말 좋은 방법이야. 함께 배우고 성장하는 것만큼 즐거운 일도 없으니까.

이제 넌 실시간 웹 기술에 대해 누구보다 자신 있게 이야기할 수 있게 됐어.
너의 다음 프로젝트가 사용자의 심장을 뛰게 하는 멋진 실시간 기능으로 가득 차길 응원할게!