윈도우 PC에서만 채팅이 늦게 잡힌 이유 (시계가 13.6초 빨랐다)

내 윈도우 PC에서 시청자 추첨기 모집을 시작했는데, 채팅은 분명 올라오는데 참가자로 잡히지 않았다.

 

한참 지나서 올라온 채팅부터 명단에 들어갔다.

 

PC 시계가 13.6초 빨랐고, 추첨기가 그 시계를 서버 시계와 비교하고 있었다.

이 PC에서 안 되면 다른 방송인도 안 된다고 생각했다

내가 만든 사이트 Q-Fit에는 방송 중에 쓰는 시청자 추첨기가 있다. 시청자 추첨기에서 모집을 시작하고 채팅에 아무 말이나 치면 참가자로 들어간다.

 

만든 이유는 단순했다. AI에 일을 맡겨 놓고 기다리는 틈에 치지직 방송을 보다가, 스트리머들이 투표와 추첨을 자주 하는데 그걸 받쳐 주는 서비스가 부족하다고 느꼈다.

 

방송을 보면서 겪어 보니 기존 서비스는 채팅이 폭발적으로 올라올 때 채팅이 유실됐다. 내 채팅이 집계됐는지도 알 수 없었다.

 

그래서 채팅을 빠짐없이 받고 처리됐는지 보이게 만들자는 게 출발점이었다.

 

처리됐는지 보이게 하는 쪽은 시청자가 참여 여부를 직접 확인하는 참여 조회를 만들었다.

 

자세한 이야기는 Q-Fit 개발기: 치지직 스트리밍 도구 개발기에 있다.

 

맥으로 개발하면서 돌려 볼 때는 이런 적이 없었다.

 

그런데 윈도우 PC에서 돌리니 모집 시작 뒤 체감상 대략 15초가 지나서야 채팅이 참가자로 인식됐다.

 

그 PC는 윈도우 11, 램 32GB, 9800X3D, RTX 5080이다.

 

이 정도 사양에서 문제가 생기면 방송인 대부분에게도 생길 거라고 생각했다.

위 화면은 나중에 같은 상황을 재현한 것이다. 오른쪽 채팅에는 글이 보이는데 가운데 명단은 0명이다.

 

따져 본 가설은 넷이었다. 모집을 시작할 때 채팅을 다시 연결하는지, 연결이 끊겼을 때 다시 붙는 대기 시간이 걸리는지, 크롬 탭이 백그라운드에서 절전하는지, 렌더링이 느린지였다.

 

실제로 재 본 것은 아니고 코드로 확인한 것이다. 모집 시작 함수는 연결을 열지 않고, 다시 붙는 대기는 연결이 끊긴 뒤에만 돈다. 탭 절전과 렌더링은 채팅 처리를 늦출 수는 있어도 버리지는 않는다.

시계를 재 보니 13.6초가 나왔다

코드를 읽어 보니 남은 가설은 하나였다. 그 윈도우 PC의 시계가 체감한 시간만큼 빠르다는 것이다.

 

다만 이때는 코드가 그렇게 동작한다는 것만 확인했고, PC 시계가 정말 빠른지는 확인하지 못한 상태였다.

 

확인하는 방법은 간단했다. 크롬에서 time.is를 열어 보면 된다.

 

윈도우 크롬이 깔린 그 PC에서 time.is를 열어 직접 재 본 결과는 이랬다.

 

13.6초 빠르다.

 

체감은 대략 15초였는데 실제 차이는 13.6초였다.

 

그 PC는 윈도우의 자동 시간 동기화가 꺼져 있었다. 그래서 시계가 조금씩 어긋난 채로 있었던 것이다.

도구는 시계 두 개를 비교하고 있었다

범인은 추첨기가 시각을 비교하는 방식이었다.

 

추첨기는 모집을 시작한 시각을 PC 시계로 적어 둔다.

 

채팅마다 붙어 오는 보낸 시각은 치지직 서버 시계 기준이다.

 

그리고 모집 시작 시각보다 먼저 보낸 채팅은 참가에서 뺀다.

빨간 선보다 왼쪽에 있는 채팅이 버려진다. 선의 위치가 PC 시계가 빠른 만큼 오른쪽으로 밀린 것이다.

 

PC 시계가 13.6초 빠르면 모집 버튼을 누른 직후에 온 채팅도 PC 기준으로는 13.6초 전에 보낸 채팅이 된다.

 

그래서 처음 13.6초 동안 들어온 채팅이 전부 빠지고, 그 뒤부터 정상으로 잡혔다.

두 상자의 시각이 서로 다른 시계에서 나온 값이라는 점을 보면 된다.

 

채팅 창에는 그대로 보이고 명단에만 안 들어가니 더 헷갈렸다.

 

추첨기를 쓰는 방송인이었다면 「왜 수집이 안 되지?」 싶었을 것이다.

 

개발용 맥은 시계가 정확해서 내 환경에서는 재현이 안 됐던 것이다.

비교하는 시계를 하나로 맞췄다

고칠 방법은 둘 중 하나였다. PC 시계를 맞추라고 안내하거나, 사이트가 시계가 틀려도 동작하게 하거나.

 

13.6초를 확인하고 나서 사이트 쪽을 고치기로 했다. 다른 사람의 컴퓨터에도 비슷한 문제가 있을 것 같았기 때문이다.

 

같은 시각 비교를 하는 곳이 추첨기만이 아니라는 것도 알게 됐다. 룰렛, 오목 방송, 알까기 방송도 같은 PC에서는 처음 몇 초의 채팅이 빠진다. 그래서 네 도구를 한 번에 고치기로 했다.

 

고친 곳은 채팅을 받는 치지직 연결 한 곳뿐이다. 채팅에 붙는 시각을 서버가 보낸 시각 대신 이 PC가 그 채팅을 받은 순간의 시각으로 바꿨다.

 

msg.msgTime 대신 받은 순간의 Date.now()를 쓰게 했다.

비교하는 두 시각이 모두 같은 시계에서 나오니 PC 시계가 몇 초 틀려도 결과가 변하지 않는다.

 

PC 시계를 13.6초 앞당긴 상태로 흉내 내서 확인했다. 고치기 전 코드는 모집 시작 2초 뒤에도 참가자가 0명이었다. 고친 뒤에는 시작 직후 보낸 채팅 3건이 바로 참가자로 들어왔다.

가운데 명단에 일반 참가자 3명이 보이는 것이 고쳐졌다는 표시다.

 

한계도 있다. 방송 도중에 윈도우가 시계를 뒤로 맞추면 그 순간에는 같은 일이 생길 수 있다. 드문 경우라 문서에만 적어 뒀다.

 

한 가지 바뀐 점도 있다. 모집 시작 버튼을 누르기 직전에 보냈는데 직후에 도착한 채팅(보통 1초 안)도 참가로 잡힌다.

 

맥에서만 개발하다 보니 윈도우에서 시계가 틀릴 수 있다는 생각을 못 했다.

 

고친 뒤 그 윈도우 PC에서 다시 확인하니 잘 됐다. 이제 그 PC에서 모집을 시작하면 채팅이 한참 뒤가 아니라 바로 명단에 들어간다.