초침은 서버시간을 어떻게 재나: 초 단위 Date 헤더로 밀리초를 추정하는 원리와 한계
2026년 11월 1일 기준, 초침 서버에서 실제로 돌아가는 측정 코드를 그대로 설명한 글입니다. 측정 방식이 바뀌면 이 글도 함께 고칩니다.
웹사이트는 응답할 때마다 Date라는 헤더에 "지금 몇 시인지"를 적어 보냅니다. 문제는 이 값이 초 단위라는 점입니다. HTTP 표준(RFC 9110)이 정한 형식이 Sun, 01 Nov 2026 06:00:00 GMT처럼 초까지만 있기 때문입니다. 그런데 티켓팅에서는 0.3초 차이로 대기 순번이 수천 번 갈립니다. 초침은 초 단위 정보만으로 어떻게 밀리초를 추정할까요?
핵심 아이디어: "이 순간 상대 시계는 어느 1초 구간 안에 있다"
Date 헤더가 12:00:00이라면 상대 서버의 시계는 그 순간 12:00:00.000 이상, 12:00:01.000 미만 어딘가에 있었다는 뜻입니다. 정확한 값은 몰라도 범위는 압니다.
요청을 한 번 보내면 초침 서버는 세 가지를 기록합니다.
- s0: 요청을 보낸 순간의 초침 시계
- s1: 응답을 받은 순간의 초침 시계
- D: 응답의 Date 헤더(초 단위)
상대 서버가 Date를 찍은 순간은 s0와 s1 사이 어딘가이므로, "상대 시계 − 초침 시계"는 반드시 D − s1 이상, D + 1초 − s0 이하에 들어갑니다. 이 범위를 여러 번 구해서 겹치는 부분만 남기면 범위가 점점 좁아집니다.
계산 예시: 세 번 재서 범위를 좁히기
아래는 이해를 돕기 위한 가상의 숫자입니다. 초침 시계 기준 12:00:00.000을 0ms로 놓고, 차이(상대 − 초침)를 ms로 계산합니다.
| 요청 | 보낸 시각 s0 | 받은 시각 s1 | Date 헤더 | 가능한 차이 범위 | 겹친 결과 |
|---|---|---|---|---|---|
| 1번 | 120 | 180 | 12:00:00 | −180 ~ +880 | −180 ~ +880 |
| 2번 | 830 | 890 | 12:00:01 | +110 ~ +1170 | +110 ~ +880 |
| 3번 | 1450 | 1510 | 12:00:01 | −510 ~ +550 | +110 ~ +550 |
세 번 만에 범위가 1,060ms에서 440ms로 줄었습니다. 초침은 범위의 가운데(+330ms)를 측정값으로, 범위의 절반(±220ms)을 오차로 표시합니다. 즉 "상대 서버가 초침보다 약 0.33초 빠르다"는 결과입니다. 실제 측정에서는 이것을 최대 10번 반복하므로 범위가 훨씬 좁아집니다.
초침이 실제로 하는 일
- 예매처에 요청 10번: 사이트 첫 페이지에 본문 없이 헤더만 받는 HEAD 요청을 보냅니다. 캐시된 응답을 피하려고 no-cache를 붙이고, 리디렉션은 따라가지 않습니다.
- 간격을 일부러 엇갈리게: 요청 사이 간격을 97~185ms 사이에서 매번 다르게 둡니다. 간격이 일정하면 매번 1초 경계의 같은 위치에 걸려 범위가 잘 좁혀지지 않기 때문입니다.
- 범위 겹치기: 위 예시처럼 범위를 겹쳐 가운데 값과 오차를 계산합니다. 유효한 응답이 3개 미만이면 측정 실패로 처리합니다.
- 범위가 아예 안 겹칠 때: 큰 사이트는 여러 대의 서버가 번갈아 응답하는데, 서버마다 시계가 조금씩 다르면 범위가 서로 모순될 수 있습니다. 이때는 각 응답에서 추정한 값의 중앙값을 쓰고 오차를 ±500ms로 크게 표시합니다.
- 30초 동안 결과 공유: 같은 사이트를 여러 사람이 동시에 재면 그 사이트에 요청이 몰립니다. 그래서 한 번 잰 결과를 30초 동안 저장해 같이 씁니다.
내 기기와 초침 서버의 차이는 따로 잰다
위 과정은 "예매처 시계 − 초침 서버 시계"입니다. 여러분 화면에 맞추려면 "초침 서버 시계 − 내 기기 시계"도 알아야 합니다. 브라우저는 초침 서버에 짧은 요청을 4번 보내고, 왕복이 가장 빨랐던 한 번을 기준으로 삼습니다. 응답이 왕복 시간의 절반 지점에서 만들어졌다고 보고 차이를 계산하는데, 이는 인터넷 시간 동기화 표준인 NTP와 같은 발상입니다. 왕복 시간은 브라우저의 고정밀 타이머(performance.now)로 잽니다. 이 값은 1분마다 다시 잽니다.
화면의 최종 값은 두 차이를 더한 것이고, 표시되는 오차는 "범위 오차 + 왕복 시간의 절반"입니다.
이 방식으로 알 수 없는 것
- 대기열 서버는 다를 수 있습니다. 초침은 사이트 첫 페이지의 응답 시계를 잽니다. 실제 예매 버튼이 열리는 시점은 별도의 대기열·예매 서버나 사이트 운영 방식이 정합니다.
- CDN 시계일 수 있습니다. 큰 사이트는 콘텐츠 전송망(CDN)이 대신 응답하므로, 재는 시계가 예매 서버가 아니라 CDN 서버의 시계일 수 있습니다. 대부분의 CDN은 표준 시각에 맞춰져 있습니다.
- Date를 안 주는 사이트는 잴 수 없습니다. 이 경우 "서버 시각을 알려 주지 않는 사이트"라고 표시합니다.
- 내 네트워크가 불안정하면 오차가 커집니다. 와이파이보다 유선이, 혼잡 시간보다 한산한 시간이 정확합니다.
그래서 초침의 값은 "정각을 판단하는 참고 시계"로 쓰는 것이 맞습니다. 서버 시계가 무엇이고 왜 내 시계와 다른지는 서버시간이란?, 정각에 맞춰 누르는 요령은 티켓팅 성공 가이드, 사람의 반응속도 한계는 반응속도 가이드를 참고하세요.