- 윤초는 “하루가 86,400초가 아니라 86,401초”인 특이한 1초의 추가 보정이다
- 2012년·2017년 윤초가 글로벌 IT 기업의 서버를 동시에 마비시킨 사건이 있다
- 구글·아마존은 “윤초를 하루 동안 매 초마다 분산”하는 “smear” 기법을 도입했다
왜 1년에 1초가 더 들어갈까
지구의 자전은 일정하지 않다. 달의 인력, 지각의 질량 분포, 해류 변동 등으로 매년 약 1ms씩 자전 주기가 길어진다. 즉, 100년 단위로 보면 지구의 “하루”는 점점 길어진다. 반면 원자시계가 정의하는 “1초”는 절대적으로 같다(세슘 원자가 9,192,631,770번 진동하는 시간). 이 둘 사이의 누적 차이를 보정하기 위해 만든 것이 윤초다.
1972년부터 2024년까지 총 27회의 윤초가 추가되었다. 즉, “인류의 시계”와 “지구의 회전”은 27초 어긋났고, 그 차이를 우리가 살짝씩 메워온 셈이다.
23:59:60 — 1년에 한 번 등장하는 특별한 초
윤초는 보통 12월 31일 23:59:59 다음에 23:59:60을 추가하는 형태로 시행된다. 즉, “86,400초가 아니라 86,401초”인 하루가 1년에 한 번 발생한다. 일반인의 일상에서는 알아채기 어렵지만, 컴퓨터 시계에 직접 연결된 시스템은 다음 두 가지 문제를 만난다.
- 23:59:60은 일반적인 시간 표기 코드가 다루지 않는 값이다.
- 이 1초 동안 시간이 “정지” 또는 “두 번 1초 0초로 카운트”되어, 분산 시스템의 시간 비교 로직이 깨질 수 있다.
2012년 윤초 사건 — 글로벌 인프라가 흔들리다
2012년 7월 1일 09:00:00 KST(UTC 00:00:00)에 시행된 윤초는 다음 같은 대형 사고를 일으켰다.
- 레딧, 링크드인, 야후의 일부 서버가 시간 비교 코드의 무한 루프로 응답 불능 상태에 빠졌다.
- 리눅스 커널 버그로 인해 일부 서버의 CPU 점유율이 100%로 치솟았다.
- 호주 콴타스 항공의 예약 시스템이 약 2시간 마비되었다.
이후 2015년·2017년 윤초에서도 비슷한 형태의 작은 사고가 반복되었다. 결국 글로벌 IT 기업들은 다른 접근을 모색하기 시작했다.
“Leap Smear” — 1초를 24시간에 나눠 천천히 더한다
구글이 2011년 도입하고, 이후 아마존·페이스북 등이 채택한 방식이 “leap smear(윤초 분산)”이다. 1초를 단번에 더하는 대신, 윤초가 시행되는 날의 24시간 동안 시계를 매 초 약 11.6 마이크로초씩 천천히 늦게 흐르도록 만든다. 그 결과 24시간이 끝날 때 정확히 1초가 추가되어 있고, 이 사이에 “23:59:60”이라는 비정상 시각은 한 번도 등장하지 않는다.
- 1초 ÷ 86,400초 ≒ 11.574 μs/s (시계 속도 보정량)
- 이 방식은 “정확한 UTC”를 일시적으로 따르지 않게 되지만, 시스템 안정성을 우선시한다.
- 구글, AWS, 메타, 페이스북 등 대부분의 클라우드가 이 방식을 사용한다.
한 가지 흥미로운 점은, leap smear를 쓰는 클라우드와 그렇지 않은 NTP 서버가 같은 네트워크에 섞여 있으면 24시간 동안 시간이 미세하게 어긋난다는 것이다. 그래서 정밀 거래 시스템(예: 주식 매매)은 이 충돌을 피하기 위해 보통 한 가지 방식의 NTP 풀을 일관되게 사용한다.
2035년 윤초 폐지 결정
2022년 11월, 국제도량형총회(CGPM)는 윤초를 2035년까지 폐지하기로 결정했다. 향후 100~200년 동안은 누적 차이가 1분 정도까지 허용된 후, 다른 보정 방식을 도입할 가능성이 크다. 이 결정의 배경에는 “윤초가 IT 시스템에 만드는 위험이 천문학적 정확도의 가치보다 크다”는 판단이 있었다.
일광절약시간(DST) — 시계가 1시간 점프하는 또 다른 사건
윤초가 “1초의 점프”라면, DST는 “1시간의 점프”다. 미국·유럽·호주 등은 봄에 시계를 1시간 앞당기고, 가을에 1시간 뒤로 돌린다. 이 점프는 시스템에 다음과 같은 영향을 준다.
- 봄 점프(spring forward): 02:00:00이 03:00:00으로 점프한다. 이 시각에 예약된 작업은 “건너뛰어짐”.
- 가을 점프(fall back): 02:00:00이 01:00:00으로 되돌아간다. 같은 시각이 두 번 등장한다 → 같은 작업이 두 번 실행될 수 있다.
이 두 시점에 예약된 작업·로그·결제 시스템에서 미세한 오류가 흔히 발생한다. 글로벌 SaaS 회사들은 보통 “DST 시점에 자동화 작업을 스케줄링하지 않음”을 사내 규약으로 둔다.
한국에서는 큰 영향이 없지만
한국은 DST를 시행하지 않으므로 국내 시스템만 운영하는 경우 DST 관련 문제는 거의 없다. 그러나 해외 사용자를 다루는 글로벌 서비스, 해외 물류·결제·콘서트 티켓팅에서는 DST가 직접 영향을 준다. 예를 들어 미국 콘서트 티켓 판매 시작 시각이 “EDT 10:00”이라고 하면, KST 기준으로 봄·가을의 환산이 한 시간씩 다르다.
| 구간 | 시기 | UTC 오프셋 | 한국 기준 |
|---|---|---|---|
| EST(미국 동부 표준시) | 11월 ~ 3월 | UTC−5 | KST 14시간 차이 |
| EDT(미국 동부 일광시) | 3월 ~ 11월 | UTC−4 | KST 13시간 차이 |
일반 학생에게 윤초·DST는 직접 마주칠 일이 거의 없다. 그러나 해외 티켓팅·항공권·해외 자격시험을 다룬다면 다음 두 가지를 기억해 두면 된다.
- 해외 시각은 “현지 시각 + UTC 오프셋”을 함께 보고, 봄·가을 DST 전환을 확인한다.
- 같은 시간 “재계산”을 두 번 한 결과가 다르면, 시계 점프(윤초·DST)가 영향을 줬을 가능성이 있다.
다음 글에서는 GPS·PTP·NTP 정밀 시간 동기화 비교로 더 깊은 시간 인프라 세계로 들어간다.