[기술 면접] 2026-06-09 — WebSocket vs HTTP

오늘의 면접 주제

 

브라우저 기반 실시간 서비스와 AI 에이전트 UI가 늘면서, HTTP와 WebSocket의 차이를 이해하는 능력이 더 중요해졌습니다.

핵심 한 줄 요약

HTTP는 요청과 응답 중심의 통신이고, WebSocket은 한 번 연결한 뒤 양방향으로 계속 메시지를 주고받는 통신 방식입니다.

면접 질문 & 모범 답변

Q1. WebSocket이란 무엇인가요?

기본 답변: WebSocket은 클라이언트와 서버가 하나의 TCP 연결을 유지하면서 양방향으로 데이터를 주고받는 프로토콜입니다. 채팅, 알림, 실시간 게임처럼 서버가 먼저 데이터를 보내야 하는 기능에 적합합니다.
심화 포인트: WebSocket은 HTTP를 대체하는 기술이 아닙니다. 처음 연결할 때는 HTTP 핸드셰이크를 사용하고, 이후 WebSocket 프로토콜로 전환됩니다.

Q2. WebSocket 핸드셰이크는 어떻게 동작하나요?

기본 답변: 브라우저는 서버에 HTTP 요청을 보내면서 Upgrade: websocket 헤더를 포함합니다. 서버가 이를 허용하면 101 Switching Protocols 응답을 보내고, 이후 같은 연결에서 WebSocket 메시지를 주고받습니다.
심화 포인트: 핸드셰이크는 인증과 권한 확인이 들어가기 좋은 지점입니다. 예를 들어 쿠키나 토큰을 확인한 뒤 연결을 허용할 수 있습니다.

[http]GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade

Q3. HTTP와 WebSocket의 가장 큰 차이는 무엇인가요?

기본 답변: HTTP는 클라이언트가 요청해야 서버가 응답합니다. WebSocket은 연결이 열려 있으면 서버도 언제든 클라이언트에게 메시지를 보낼 수 있습니다.
심화 포인트: HTTP도 Polling이나 Server-Sent Events로 실시간처럼 만들 수 있습니다. 하지만 자주 갱신되는 양방향 데이터라면 WebSocket이 더 자연스럽습니다.

Q4. 실시간 알림 기능을 구현한다면 무엇을 선택하겠나요?

기본 답변: 알림이 단방향이고 빈도가 낮다면 HTTP Polling이나 SSE도 충분합니다. 사용자가 많고 서버가 즉시 알림을 밀어줘야 한다면 WebSocket을 고려합니다.
심화 포인트: 기술 선택은 “실시간이냐 아니냐”만으로 결정하지 않습니다. 연결 수, 서버 비용, 장애 복구, 메시지 유실 허용 여부까지 함께 봐야 합니다.

Q5. WebSocket의 단점은 무엇인가요?

기본 답변: WebSocket은 연결을 계속 유지하므로 서버 자원을 오래 점유합니다. 또한 로드밸런싱, 재연결, heartbeat, 메시지 순서 처리 같은 운영 문제가 생깁니다.
심화 포인트: HTTP API처럼 요청 하나가 끝나면 상태가 사라지는 구조가 아닙니다. 그래서 서버 인스턴스를 여러 개 둘 때 연결 상태를 어디에 저장할지 고민해야 합니다.

Q6. WebSocket에서 heartbeat가 필요한 이유는 무엇인가요?

기본 답변: 네트워크가 끊겨도 서버나 클라이언트가 바로 알지 못하는 경우가 있습니다. 그래서 주기적으로 ping/pong 메시지를 보내 연결이 살아 있는지 확인합니다.
심화 포인트: heartbeat가 없으면 죽은 연결이 서버에 계속 남을 수 있습니다. 이는 메모리와 파일 디스크립터 낭비로 이어집니다.

Q7. WebSocket 서버를 확장할 때 어떤 문제가 생기나요?

기본 답변: 클라이언트가 특정 서버 인스턴스와 연결을 유지하기 때문에 수평 확장이 단순하지 않습니다. 다른 서버에 있는 사용자에게 메시지를 보내려면 Redis Pub/Sub 같은 중간 브로커가 필요할 수 있습니다.
심화 포인트: Sticky Session은 임시 해결책이 될 수 있습니다. 하지만 장애나 배포 상황까지 고려하면 메시지 브로커 기반 설계가 더 안정적인 경우가 많습니다.

Q8. WebSocket은 보안상 어떤 점을 주의해야 하나요?

기본 답변: WebSocket도 인증과 권한 검사가 필요합니다. 연결 시점뿐 아니라 메시지 처리 시점에도 사용자가 해당 작업을 할 수 있는지 확인해야 합니다.
심화 포인트: wss://를 사용해 TLS로 암호화해야 합니다. 또한 Origin 검사를 하지 않으면 의도하지 않은 웹사이트에서 연결을 시도할 수 있습니다.

꼬리 질문 대비

WebSocket과 SSE는 어떤 기준으로 선택하나요?

Polling의 단점은 무엇이고 언제는 괜찮은 선택인가요?

WebSocket 연결이 끊겼을 때 클라이언트는 어떻게 복구해야 하나요?

채팅 메시지 중복 전송은 서버에서 어떻게 막을 수 있나요?

로드밸런서 뒤에서 WebSocket을 운영할 때 주의할 점은 무엇인가요?

헷갈리기 쉬운 포인트

WebSocket은 HTTP보다 항상 빠른 기술이 아닙니다. 반복 요청이 많은 상황에서 오버헤드를 줄일 수 있을 뿐입니다.

WebSocket 연결이 열려 있다고 해서 인증이 계속 안전한 것은 아닙니다. 토큰 만료, 권한 변경, 강제 로그아웃을 별도로 처리해야 합니다.

실시간 기능이라고 해서 반드시 WebSocket이 필요한 것은 아닙니다. 서버에서 클라이언트로만 보내면 SSE가 더 단순할 수 있습니다.

면접관 시각

면접관은 지원자가 WebSocket의 정의를 외웠는지만 보지 않습니다. HTTP 요청-응답 모델과 연결 유지 모델의 차이를 실제 기능 요구사항에 맞춰 설명할 수 있는지 봅니다.

또한 운영 관점도 중요합니다. 재연결, heartbeat, 확장, 인증 같은 문제를 언급하면 단순 구현을 넘어 실서비스를 생각해 본 지원자로 평가받을 수 있습니다.