[ TIL ] DAY 78, 79 - 웹소켓 실시간 통신

🗓️ 수업 일자 : 2026.1.15~16

✨ 오늘의 수업 평가 :  [ HARD ]  집중은 했는데, 흡수는 글쎄? 꼭 다시 복습하기!😵‍💫📉

 

1.15 

개인적인 일 때문에 수업을 절반만 들어서 제대로 이해했는지 모르겠다 ㅠ 

GPT랑 같이 수업 내용 공부 했는데, 이론은 어느정도 이해 했고 실무는..ㅎㅎ 더 봐야할 것 같다 ㅎㅎ

 

1.16

바로 실습으로 적용하며 공부 해 볼까 하다가

전체 코드 따라치는 수준밖에 안 될거 같아서 일단 오늘까지 더 공부하는날.. 

 

👩‍💻 [개인 프로젝트] 오늘 작업 내용 💻

- 학원에서 제공해 준 모범 답안으로 전체 코드 리팩토링

- 프로젝트 시작 준비

 

📝  오늘 배운 내용  

- 실시간 통신 이론 

- WS(웹소켓 모듈) vs socket.io 라이브러리

 

---

1. 실시간 통신 이론 

기존(HTTP) 통신 방식

- 클라이언트가 요청 → 서버가 홈페이지 메인 화면 정보를 보내줌 → 사용자가 별도의 요청이 없으면 처음 보내준 상태 그대로 있음 (배너 같은게 움직이는 거 같아도 사실 처음 보내준 데이터를 기반으로 움직이는 거라, 추가 통신을 한게 아님)

 

실시간 통신 방식

- 클러이언트가 요청 → 서버가 기본 틀 & 초기 데이터를 전송 → 사용자가 가만히 있어도 추가 데이터를 자동으로 계속 업데이트 함

 

실시간 통신 방식 예시 

- 주식창 : 가만히 있어도 그래프가 오르락내리락

- 온라인 게임 : 가만히 있어도 다른 사용자가 나타나거나, 몹을 죽이고 그자리에 있으면 시간 되서 자동으로 몹이 나타나거나

- 실시간 채팅 : 카*오톡 같이 사용자는 해당 어플을 쓰지 않아도 서버에서 메세지를 전달해서 폰이나 컴퓨터 프로그램이 받음!

HTTP / WS 통신 방식 이해

 

 

실시간 통신 방식의 종류 

1. Short Polling (숏폴링)

• 클라이언트가 서버에게 주기적으로 계속 요청을 보냄
• 서버는 정보가 “없음 / 있음”으로 응답
• 변동사항이 없어도 서버가 빈번하게 호출되어 비효율적

 

2. Long Polling (롱폴링)

• 클라이언트가 요청을 보내면, 서버가 데이터 생길 때까지 잡고 있다가 생기면 응답 → 연결 종료
• 위 구조를 계속 반복함. 

 

3. SSE (Server-Sent Events)

• HTTP 기반
• 클라이언트는 요청을 1번만 보내고, 이후 서버가 계속 새로운 정보를 push함
• 단방향 (서버 → 클라이언트만) 서비스

 

4. WebSocket

• 처음 연결 할 때만 HTTP로 구동되고, 바로 WS 서버로 변경하여 연결 유지
• 양방향 서비스이자 실시간 통신을 하는데 있어서 최고 프로토콜

방식	프로토콜	방향	연결
Short Polling	HTTP	단방향	짧음
Long Polling	HTTP	단방향	길게
SSE	HTTP	서버 → 클라이언트	유지
WebSocket	WS	양방향	유지

 

 

 

 

2. WS(웹소켓 모듈) vs socket.io 라이브러리

WS 모듈의 특징

• WebSocket 서버를 만들기 위해 Node.js에 내장되어 있는 기본 모듈
• Express 는 HTTP 요청 처리용 라이브러리 이므로, 실시간 통신 처리를 위해 WebSocket과 연결하여 처리
• WebSocket 표준에 가장 가까운 저수준 모듈(기본 기능만 제공)
• 연결, 메세지, 종료 등 모든 부가적인 작업을 직접 구현하여 관리

 

socket.io 라이브러리 특징

• 웹소켓 방식의 고수준 라이브러리로 여러 부가 기능을 제공하고, 손쉽게 확장 서비스 구현 가능 
• Fallback : Websocket에 문제가 생기게 되면, polling / long-polling 방식이 적용 되면서 서버의 무한 루프를 막는 기능 
• 메세지 커스텀(이벤트 처리) : 사용할 세부 메세지 설정이 쉬우며 확장성이 높음 (WS의 경우 Switch문을 작성하여 사용할 메세지 타입 별로 세부 설정을 해야하지만, socket.io는 호출 작업에서 바로 구현 가능)
• Room : 클라이언트를 분리하여 그룹으로 묶는 기능, 각 룸마다 별도의 서비스(혹은 메세지)를 제공 가능. (브로드캐스팅이 쉬워짐)
• NameSpace : 서비스 단위로 통신 채널을 분리하여 별도의 통신 채널을 운영하는 기능

 

[왼쪽] WS로 구현한 실시간 채팅 창 / [오른쪽] Socket.io으로 구현한 실시간 채팅창

+ 추가  브로드 캐스팅? 

한 명이 보낸 메세지를 같은 공간에 있는 여러 사람에게 다시 보내는 작업.

WS의 경우, 기본 기능에 공간 분리 기능이 없기 때문에 방 분리가 안됨. 필요한 경우 목록 관리 / 조건문을 추가하여 특정 그룹에게만 보내는 방식 구현을 직접 해야하지만, 복잡하고 어려운 작업임. 반면, Socket.io의 경우 Room이라는 서비스로 쉽게 분리하기 때문에 특정 공간을 지정하고 메세지를 보내면 됨.

io.to('room1').emit('message', data);

 

 

+ 추가 Room vs NameSpace 

 

• 기능 성격이 완전히 다르면 → Namespace 분리
• 같은 기능인데 서비스의 제공 대상만 다르면 → Room 분리

 

 

---

 

📃 내일은 뭘 배울까 🤔

- 웹소켓 실시간 통신 구현