웹 소켓(Web Socket) 통신: 실시간 채팅 및 알림 기능 구현의 원리

우리가 카카오톡으로 메시지를 주고받거나 주식 앱에서 실시간 시세를 확인할 때, 화면을 새로고침하지 않아도 정보가 즉각 업데이트되는 비밀은 바로 '웹 소켓(Web Socket)'에 있습니다. 과거의 웹이 일방적인 요청과 응답의 반복이었다면, 웹 소켓은 서버와 클라이언트가 서로 자유롭게 말을 주고받는 새로운 대화 방식입니다.

HTTP의 한계와 실시간성 전통적인 HTTP 통신은 클라이언트가 요청을 보내야만 서버가 응답하는 구조입니다. 서버에 새로운 소식이 있어도 클라이언트가 묻지 않으면 알려줄 방법이 없습니다. 이를 해결하기 위해 일정 간격으로 계속 묻는 'Polling' 방식이 있었지만, 이는 서버에 엄청난 부하를 주는 비효율적인 방식이었습니다.

웹 소켓이란 무엇인가? 웹 소켓은 HTML5 표준 기술로, 한 번 연결이 맺어지면 연결을 끊지 않고 유지하며 양방향으로 데이터를 주고받는 프로토콜입니다. 마치 전화 통화를 연결해 둔 상태처럼, 어느 한쪽이 말을 하면 상대방이 즉시 들을 수 있는 상태가 되는 것입니다.

핸드셰이크(Handshake) 과정의 이해 웹 소켓 통신은 처음부터 소켓으로 시작하지 않습니다. 처음에 HTTP 요청으로 "우리 소켓으로 대화할래?"라고 서버에 묻고(Upgrade 요청), 서버가 수락하면 그때부터 소켓 프로토콜로 전환됩니다. 이 악수 과정이 성공해야 비로소 실시간 통로가 열립니다.

실시간 채팅의 구현 원리 채팅 서비스에서 웹 소켓은 중계소 역할을 합니다. A가 메시지를 보내면 서버 소켓이 이를 받아 현재 연결된 B에게 즉시 쏴줍니다. 이때 서버는 어떤 사용자가 어떤 소켓 번호와 연결되어 있는지 매핑 테이블로 관리하여 정확한 대상에게 메시지를 전달하게 됩니다.

실시간 알림(Push Notification) 시스템 누군가 내 게시물에 좋아요를 눌렀을 때 뜨는 알림 역시 웹 소켓의 작품입니다. 서버는 이벤트가 발생하면 해당 사용자의 연결된 소켓을 찾아 알림 데이터를 전송합니다. 만약 사용자가 오프라인이라면 소켓 연결이 없으므로, 이때는 FCM(Firebase Cloud Messaging) 같은 외부 푸시 서비스를 병행 사용합니다.

데이터 포맷과 효율성 웹 소켓은 HTTP처럼 헤더 정보를 매번 보낼 필요가 없어 오버헤드가 매우 적습니다. 주로 JSON 형식을 사용하여 데이터를 주고받으며, 연결이 유지되는 동안에는 아주 작은 패킷만으로도 소통이 가능해 실시간성이 극대화됩니다.

연결 유지와 끊김 처리(Heartbeat) 인터넷 연결은 불안정할 수 있습니다. 소켓이 끊어졌는지 확인하기 위해 주기적으로 작은 데이터를 주고받는 'Heartbeat' 혹은 'Ping-Pong' 과정을 거칩니다. 만약 연결이 끊어지면 클라이언트 측에서 자동으로 재연결(Reconnection)을 시도하는 로직이 필수적입니다.

서버의 부하와 스케일 아웃 문제 사용자가 많아져 서버를 여러 대 운영할 때 문제가 발생합니다. A는 1번 서버에, B는 2번 서버에 연결되어 있다면 소통이 불가능해집니다. 이를 해결하기 위해 Redis의 Pub/Sub 기능을 사용하여 서버 간에 메시지를 공유하는 브로커 시스템을 구축해야 합니다.

보안 고려 사항(WSS) 데이터가 암호화되지 않는 ws:// 대신, SSL/TLS가 적용된 wss://를 반드시 사용해야 합니다. 중간에 데이터를 가로채는 공격을 방지하고, 사용자 인증 토큰(JWT 등)을 통해 검증된 사용자만 소켓을 연결할 수 있도록 제어해야 합니다.

웹 소켓은 사용자에게 생동감 넘치는 경험을 제공하는 마법 같은 도구입니다. 하지만 상시 연결을 유지해야 하는 만큼 서버 자원 관리에 더 세심한 주의가 필요합니다. 단순한 채팅 앱 구현을 넘어, 우리 서비스의 어느 부분에 실시간 기술이 필요한지 고민해 보시기 바랍니다.