43.1 그냥 새로고침하면 안 되나요?
실시간이라는 말부터 좀 풀고 갈게요. 우리가 흔히 만드는 웹은 사용자가 움직여야 새 데이터를 가져와요. 링크를 누르거나, 새로고침을 하거나, 버튼을 눌러야 fetch가 나가죠. 서버에 새 소식이 생겨도, 사용자가 가만히 있으면 화면은 옛날 그대로예요. 이게 우리가 지금까지 만들어온 요청-응답(사용자가 물어야 서버가 답하는) 방식이에요.
그런데 채팅을 이렇게 만들면 어떻게 될까요? 상대가 메시지를 보내도 내가 새로고침을 눌러야 보여요. 말이 안 되죠. 그래서 "화면을 안 건드려도 알아서 최신으로 바뀌는" 느낌이 필요한데, 그게 바로 실시간이에요. 저도 처음엔 "그냥 몇 초마다 새로고침 돌리면 되는 거 아냐?"라고 쉽게 생각했다가, 그게 왜 나쁜 선택인지 뒤에서 뼈저리게 배웠어요. 이번 편은 코드보다 언제 실시간이 필요한지, 그리고 방식이 왜 여러 개인지를 먼저 잡는 이야기예요.
43.2 실시간이 진짜 필요한 순간은 언제예요?
모든 서비스에 실시간이 필요한 건 아니에요. 오히려 대부분은 필요 없어요. 블로그 글, 상품 상세 페이지, 회사 소개 페이지에 실시간이 왜 필요하겠어요. 필요한 건 내가 안 움직이는 동안 남이 만든 변화가 중요할 때예요.
실시간이 필요한 대표 상황
- 채팅, 댓글 실시간 표시
- 여러 명이 같이 편집하는 문서
- 주식, 코인 시세
- 배달 기사 위치 추적
- 알림(누가 나를 언급했어요)
- 경매 남은 시간, 실시간 응원 수
공통점이 보이시나요? 전부 남이나 서버 쪽에서 변화가 생기고, 그걸 내가 기다리지 않고 바로 알아야 하는 경우예요. 반대로 "내가 누르면 그때 최신을 받으면 충분한" 것들은 실시간이 아니에요. 여기서 자기 서비스를 딱 대보면 돼요. 누가 나를 위해 화면을 바꿔주길 기다리는 화면인가, 아니면 내가 눌러서 가져오면 되는 화면인가. 이 질문 하나면 절반은 판가름 나요.
조심할 게 하나 있어요. 실시간은 공짜가 아니에요. 화면을 계속 최신으로 유지하려면 서버는 그만큼 일을 더 하고, 연결도 더 오래 붙잡아야 해요. 사용자가 많아지면 이 비용이 훅 커져요. 그래서 저는 "있으면 멋있을 것 같아서" 실시간을 넣는 걸 늘 말려요. 상세 페이지 조회수가 1 늘어난 걸 실시간으로 반영해 봤자 아무도 안 쳐다봐요. 없으면 서비스가 어색해지는 화면에만 실시간을 얹는 게 맞아요.
43.3 실시간처럼 보이는데 사실 아닌 것도 있죠?
여기서 오해를 하나 풀고 갈게요. 화면이 자동으로 바뀐다고 다 진짜 실시간은 아니에요. 예를 들어 날씨 위젯이 5분마다 슬쩍 갱신된다면, 사용자는 실시간처럼 느끼지만 서버 입장에선 그냥 5분에 한 번 물어보는 거예요. 이런 걸 저는 속으로 준실시간(거의 실시간, 약간의 지연 허용)이라고 불러요.
이 구분이 왜 중요하냐면, 허용 가능한 지연에 따라 쓸 기술이 완전히 달라지기 때문이에요. 채팅에서 상대 말이 3초 늦게 뜨면 어색하죠. 하지만 코인 시세가 2초 늦는 건 대부분 괜찮고, 날씨는 5분 늦어도 아무도 몰라요. 그래서 실무에선 "실시간 되게 해주세요"라는 요청을 받으면 저는 꼭 되물어요. "몇 초까지 늦어도 괜찮아요?" 이 답에 따라 무거운 웹소켓을 쓸 수도, 가벼운 폴링으로 끝낼 수도 있거든요. 실시간이라는 단어에 겁먹지 말고, 얼마나 빨라야 하는지를 숫자로 바꾸는 게 첫 단추예요.
43.4 방식이 여러 개라던데 뭐가 있어요?
실시간을 만드는 방법은 크게 네 가지예요. 이번 시리즈에서 하나씩 깊게 볼 거라, 여기선 이름과 성격만 훑어요.
실시간 4대 방식
1. 폴링: 몇 초마다 서버에 "새 거 있어?"라고 물어봄
2. 롱폴링: 물어보고, 답이 생길 때까지 서버가 붙잡고 있음
3. SSE: 서버가 한쪽으로 계속 소식을 흘려보냄
4. 웹소켓: 서버와 브라우저가 전화선처럼 계속 연결됨
위에서 아래로 갈수록 더 실시간에 가깝고, 대신 더 복잡해져요. 폴링은 우리가 아는 fetch만으로 만들 수 있을 만큼 쉽지만 낭비가 있고, 웹소켓은 강력하지만 다뤄야 할 게 많아요. 여기서 흔한 실수가 "실시간이면 무조건 웹소켓"이라고 생각하는 거예요. 알림 하나 띄우자고 웹소켓 서버를 붙이는 건, 편지 한 장 보내자고 전용 전화선을 까는 격이에요. 각 방식을 직접 만들어 보면, 왜 상황마다 답이 다른지 몸으로 느끼게 돼요.
43.5 방향이 중요하다는 게 무슨 말이에요?
방식을 고를 때 제가 제일 먼저 따지는 건 방향이에요. 데이터가 어느 쪽으로 흐르느냐는 거죠. 두 가지로 나뉘어요.
단방향은 서버에서 브라우저로 한쪽으로만 소식이 흘러요. 주식 시세, 뉴스 속보, 알림처럼 "나는 받기만 하면 되는" 화면이 여기예요. 양방향은 서버와 브라우저가 서로 주고받아요. 채팅이 대표적이죠. 나도 보내고 상대 것도 받아야 하니까요.
이 구분이 실전에서 아주 유용해요. 받기만 하면 되는데 굳이 양방향 기술을 쓰면 과해요. 앞 목록에서 SSE는 서버가 흘려보내기만 하는 단방향이고, 웹소켓은 양쪽이 오가는 양방향이에요. 그래서 "내 화면은 받기만 하나, 보내기도 하나"만 정해도 SSE냐 웹소켓이냐가 반쯤 정해져요.
헷갈리기 쉬운 지점을 하나 짚을게요. "채팅도 내가 보내는 건 그냥 fetch로 POST하면 되잖아요?"라고 생각할 수 있어요. 맞아요, 보내는 건 평범한 요청으로도 돼요. 문제는 받는 쪽이에요. 상대가 보낸 메시지를 내가 안 움직여도 받아야 하니까, 결국 실시간 연결이 필요한 거죠. 그래서 방향을 따질 땐 "보내기"보다 "받기"를 중심에 놓고 봐요. 저는 시세 대시보드를 처음에 웹소켓으로 만들었다가, 클라이언트가 서버로 보낼 게 아무것도 없다는 걸 깨닫고 SSE로 갈아엎어서 코드가 훨씬 단순해진 적이 있어요.
43.6 그래서 뭘 기준으로 고르나요?
정리하면 고를 때 던질 질문은 딱 세 개예요.
실시간 방식 고르는 3가지 질문
1. 얼마나 빨라야 하나? (몇 초 지연까지 OK인가)
2. 방향이 어느 쪽인가? (받기만 vs 주고받기)
3. 얼마나 자주 바뀌나? (초당 여러 번 vs 가끔)
대충 감을 드리면 이래요. 지연이 넉넉하고 가끔 바뀌면 폴링이면 충분해요. 서버가 자주 밀어주는데 받기만 하면 SSE가 딱이에요. 서로 자주 주고받고 지연도 짧아야 하면 그때가 웹소켓이에요. 롱폴링은 웹소켓을 쓰기 애매한 환경에서 폴링을 개선하는 중간 카드고요. 이 표를 외우려 하지 마세요. 각 방식을 손으로 만들다 보면, 이 세 질문이 왜 이런 답으로 이어지는지 자연스럽게 이해돼요.
43.7 정리하면요?
이번 편은 코드 없이 지도만 그렸어요. 마지막으로 짚고 넘어갈게요.
이번 편 핵심
1. 실시간은 "안 움직여도 최신으로 바뀌는" 것, 남과 서버의 변화가 중요할 때 필요해요.
2. 진짜 실시간과 준실시간을 나누는 건 "허용 지연"이에요. 숫자로 물어보세요.
3. 방식은 폴링, 롱폴링, SSE, 웹소켓 네 가지고 아래로 갈수록 강력하고 복잡해요.
4. 방향(단방향 vs 양방향)만 정해도 절반은 골라져요.
실시간이라는 단어에 지레 겁먹지 않는 게 이번 이야기의 진짜 목표예요. "실시간 = 무조건 어려운 웹소켓"이 아니라, 필요한 만큼만 골라 쓰면 돼요. 얼마나 빨라야 하고, 어느 방향으로 흐르고, 얼마나 자주 바뀌는지. 이 세 가지를 자기 화면에 대보는 습관, 그게 이번 이야기에서 여러분이 챙겨 갔으면 하는 진짜 알맹이예요.