요약
2027년 5월 20일부터 UTC에 윤초를 넣지 않고, 태양시와의 차이를 최대 1시간까지 허용합니다.
국제도량형국(BIPM)이 연 제28차 국제도량형총회(CGPM)가 결의 5호로 '연속 UTC'를 채택했습니다. 2022년 총회가 윤초 차이 한도를 늘리기로 정한 데 이어, 이번에 시행 날짜와 새 한도를 확정했습니다.
왜 중요한가
- 1분이 59초나 61초가 되는 예외가 사라져, 시간을 다루는 소프트웨어의 오랜 골칫거리가 줄어듭니다.
- 한 번도 해 본 적 없는 음의 윤초(1초를 빼는 조정) 위험을 미리 피합니다.
- 지구 자전 기준 시각(UT1)과 UTC가 앞으로 수 세기 동안 조금씩 벌어지게 됩니다.
핵심 내용
- UT1과 UTC의 차이 한도는 3,600초(1시간)로 늘어나며, 수 세기 동안 UTC를 끊김 없이 유지할 수 있다고 봤습니다.
- 2025년 3월 전문가 회의는 2035년까지 음의 윤초가 필요해질 확률을 30%로 추정했습니다.
- 음의 윤초에 대비하려면 Y2K 대비에 맞먹는 투자가 필요하다고 봤습니다.
- IoT 기기와 스마트 그리드가 늘면서 윤초를 넣을 때 오작동 위험이 커졌고, 업체마다 처리 방식도 달라 시각이 어긋난다고 짚었습니다.
- 결정이 늦어지면 일부 기관이 UTC 대신 위성항법(GNSS) 시각으로 옮겨 국제 표준이 흔들릴 수 있다고 우려했습니다.
HN 반응
- 윤초는 버그의 단골 원인이고 23:59:60을 제대로 표시하는 시계도 드물다며 반기는 의견이 많았습니다.
- 태양에 맞춘다는 UTC의 약속을 버린 패배라며, 고정 간격이 필요하면 TAI(국제원자시)를 쓰면 된다는 반론도 나왔습니다.
배경 설명입니다. BIPM은 UTC 시간 표준을 책임지는 기관인데, 이 문서에서 2027년 5월 20일부터 윤초를 더하는 것(혹은 빼는 것)을 중단하고 당분간 그대로 가기로 했습니다. 윤시간이 필요해지는 시점까지가 기한이지만, 그때도 뭘 할지는 불분명합니다. 12월에 윤초를 넣지 않기로 한 결정까지 더하면, 지금까지 추가된 27번의 윤초가 영원히 마지막이 될 겁니다.
페이지에는 그럴듯한 이유가 여러 개 나와 있습니다.
윤초는 버그가 흔히 생기는 원인입니다.
시간대를 크게 나눠 쓰는 세상에서 태양시는 그렇게 중요하지 않습니다.
IoT 기기나 시간 업데이트를 받을 수 없는 기기는 윤초를 감당하기 어렵습니다.
음의 윤초는 지금까지 한 번도 일어난 적이 없지만 앞으로는 일어날 수 있고, 이 경우를 테스트해 본 소프트웨어는 거의 없습니다.
저라면 이런 이유도 덧붙이겠습니다.
유닉스 타임스탬프는 사실 "기준 시점 이후 경과한 초에서 지금까지 발생한 윤초 수를 뺀 값"으로 정의됩니다. "하루는 86400초"라고 가정하는 코드가 깨지지 않게 하려는 편법입니다. 그래서 윤초가 들어가는 동안 유닉스 타임스탬프가 뒤로 돌아가 이전 값을 반복하고, 그 결과 값이 모호해지고 단조 증가도 하지 않게 됩니다.
윤초는 예측할 수 없어서, 두 UTC 날짜나 유닉스 타임스탬프 사이에 몇 초가 있는지 계산하는 것 자체가 불가능해질 수 있습니다. 2038년 문제까지 남은 시간을 세는 카운트다운이 한 예입니다.
윤초를 나타내는 올바른 ISO8601 표기("23:59:60")는 지원하지 않는 곳이 많아서 파서가 깨지고, 1분·1시간·하루가 몇 초인지에 대한 가정도 함께 깨집니다.
수정: 제목을 바꿔 달라고 [email protected]에 메일을 보냈습니다. 편집하지 않으려는 취지는 알지만, 제목 때문에 이 글이 받아야 할 관심을 못 받고 있다고 생각합니다.
저는 달력에 매년 1초짜리 휴일을 넣어 둘 겁니다. 이 일로 덜게 될 온갖 골칫거리를 기념하려고요. 윤초의 종말을 축하합니다!
이유를 쭉 읽어 보니 패배 선언처럼 들립니다. 2026년에 시간 정의 하나에 드물게, 그것도 오래전에 공지한 대로 1초를 더하거나 빼는 간단한 일조차 해내지 못한다니 안타깝습니다.
게다가 윤초 없는 시간이 없는 것도 아닙니다. 시간 정의를 바꾸기보다 TAI로 갈아타는 쪽이 훨씬 합리적이라고 봅니다. 이제는 윤초를 지원하지만 절대 쓰이지 않을 UTC 코드가 사방에 남을 테고, 그걸 지우려면 옛 UTC와 새 UTC를 구분해야 합니다. 저는 반대입니다.
제 생각에는 표면적으로 봐도 간단한 일이 아닙니다.
"1분은 60초다"는 간단합니다.
"1분은 59초, 60초, 61초 중 하나다. CGPM 간행물이나 자국 시간 관측 기관에서 확인해라"는 전혀 간단하지 않습니다.
수천 년 동안 인류는 태양에 맞춘 시간을 썼고, 그 간격은 일정하지 않았습니다. 많은 용도에서 그게 자연스러운 방식이고, UTC가 존재하는 이유도 그겁니다.
태양이 아니라 고정된 간격이 필요하다면 언제든 TAI를 쓰면 됩니다.
표준은 사람을 위해 있는 것이고, 우리는 필요에 가장 잘 맞는 표준을 고를 수 있어야 합니다. 마땅한 대안이 있는데도 별다른 이유 없이 표준의 의미를 소급해서 바꾸는 건 무책임하다는 말로도 부족합니다.
수천 년 동안 태양에 맞춘 시간을 썼다고 해도, 그건 마이크로초가 아니라 몇 분씩 어긋나는 근사치였어요. 태양 기준 현재 시각이 1초 틀려도 아무도 신경 쓰지 않았죠. 어차피 그걸 알아낼 방법이 없었으니까요. 그러다 어떤 인간이 컴퓨터와 정밀 시간 측정을 발명하는 바람에, 시간이 1초만 뒤로 가는 것처럼 보여도 문제가 되는 세상이 된 거예요. :)
UTC는 지금도 태양에 고정되어 있습니다. 윤초가 없어도 UTC와 태양의 차이를 일상에서 느끼려면 수백 년은 걸립니다. 그때도 그게 문제가 될 만한 일은 떠오르지 않습니다.
저는 UT1이라는 좋은 대안이 있다고 봅니다. 어차피 UTC는 처음부터 UT1과 어긋나 있었으니, 정밀한 태양시가 정말 필요한 사람에게는 이번 변경이 영향을 주지 않을 겁니다.
더 중요한 건, 윤초를 없애야 할 좋은 이유가 많다는 점입니다. 윤초는 시간과 관련된 모든 코드의 복잡도를 엄청나게 높입니다.
표준은 사람을 위해 있어야 하니까 윤초는 애초에 존재하지 말았어야 합니다. 이런 상황을 상상해 보세요. "여객기 몇 대가 추락하고 인터넷 절반이 이틀 동안 먹통이 되긴 했지. 그래도 정확한 경도선까지 차를 몰고 가면 12:00:00에 해가 머리 위에 있잖아. 우리 동네에서는 12:23:48에 머리 위에 있고. 그 정도면 감수할 만한 값어치야. 해가 12:23:49에 뜨는 세상은 상상도 하기 싫고, 내 고조할아버지의 고조할아버지 때 12:23:47이 되는 것도 싫어."
저는 dUT1을 2036년 NTP 롤오버, 2038년 Y2K38, GPS 주 번호 롤오버 이후에 ±0.9초로 되돌렸으면 좋겠습니다. 그러면 그 사건들이 UTC로 정확히 몇 시인지 알 수 있고, 그 시점이면 dUT1도 아마 10초 미만일 테니까요. 그때쯤이면 소프트웨어가 23:59:63 같은 시각도 제대로 처리해야 할 겁니다(아직도 23:59:60 윤초조차 못 다루는 곳이 너무 많지만요). 앞으로 dUT1을 ±9.9초 미만으로 유지하는 방법도 생각해 볼 만합니다.
dUT1이 1800을 넘도록 두면 문제가 되는 건, 그보다 훨씬 전부터 거의 모든 일에 영향을 주기 시작하고 그러면 해법 데이터를 직접 찾아봐야 한다는 점입니다(아래는 2025년 것만 가져온 겁니다).
이건 사실상 미 해군이 만드는 데이터이고, 지금 윤초에 쓰는 것보다 훨씬 방대합니다. 윤초 정도의 정밀도면 대부분의 일에 충분한데도요. UT1로 된 미래 타임스탬프도 다루기 어려워질 겁니다. 예전에는 소프트웨어가 가장 가까운 초까지는 안다고 가정할 수 있었고, 그 정도면 대개 충분했습니다.
UTC가 약속하는 것은 ISO 초의 간격을 유지하면서 태양시와의 편차를 일정 범위 안에 두는 겁니다. 저는 이게 가치 있는 절충이고 계속 존재해야 한다고 생각합니다.
그리고 실제로 유지되고 있습니다. 편차의 한도가 3600초로 조금 늘어났을 뿐입니다.
아닙니다. 이번 결정의 핵심이 바로 UTC에서 그 결합을 없애는 겁니다. 단조 증가하는 시간(또는 최소한 관찰자별로 단조 증가하는 시간)을 쓰든지, 지구의 자전을 따르든지 둘 중 하나예요. 단조 시간을 택하는 것도 전혀 문제없습니다(기준 시점과 시간 단위도 마음대로 고르면 되고요). 하지만 12:00이 (대체로) 의미를 갖도록 시간대가 있는 것처럼, 사람이 시간을 이해하는 방식에는 결국 바깥에서 무슨 일이 일어나고 있는지 살펴야 하는 면이 있습니다.
표준화된 태양시로는 GMT가 있잖아요. UTC로 옮겨 간 데는 그럴 만한 이유가 있었을 텐데요? 많은 용도에서는 둘 중 아무거나 써도 되겠지만요.
"표준화된 태양시"로 원하시는 건 아마 UT1일 겁니다. 복잡한 기술적 세부 사항이 많지만 중요하지는 않습니다. 결론적으로 UT0와 UT2는 보통 사람과 상관이 없고, UT1은 천문대들이 추정하는 가상의 태양시이며, UTC는 세계의 민간 표준시로 이제 TAI에 37초를 더한 값에 고정됩니다.
GMT(그리니치 평균시)는 영국(그래서 영국 런던의 천문대가 있는 그리니치)이 더 중요하던 시절의 유산입니다. 요즘은 영국 법령에서도 GMT가 그냥 UTC를 뜻합니다. "겨울에는 BST가 아니라 GMT를 쓴다"고 할 때도 낡은 시간 체계로 오가는 게 아닙니다. GMT는 UTC+0, BST는 UTC+1로 정의되어 있을 뿐이고, 서머타임을 쓰는 다른 여러 곳의 시간대와 똑같은 방식입니다.
원 댓글 쓴 분이 원한 건 태양시였으니까, 옛날식 GMT를 말하는 거고 지금으로 치면 UT1이 되겠죠?
지금 태양시가 꼭 필요하다면 실제로 쓰게 되는 것은 UT1이 맞습니다.
제가 짚고 싶은 건, 대부분의 경우 "GMT"라고 쓰여 있어도 태양시를 뜻하지 않는다는 점입니다. 버밍엄의 "뉴 스트리트 역"이 사실은 새 역도 아니고 새 거리에 있는 것도 아니고, 버밍엄에서 "뉴 스트리트"라는 이름의 도로와 가까웠다는 이유로 영원히 그 이름이 붙은 것과 비슷합니다.
진짜 그리니치 평균시가 "아직 현역"이던 때는 더 나은 근사치가 없어서 천문학자들이 태양시로 썼습니다. 지금은 IERS가 하늘의 아주 먼 천체들을 관측합니다. 이 천체들은 너무 멀리 있어서 (우리 기준으로) 어느 정도 움직이지 않는다고 볼 수 있으니, 이걸로 지구의 자전을 측정할 수 있습니다. 그 데이터를 바탕으로 태양의 위치를 보정하는 거고요.
더 중요한 건, 두 번째 경우는 정의가 고정되어 있지 않아서 구현마다 해석이 달라질 수밖에 없고, 그러면 상황이 훨씬 더 엉망이 된다는 점입니다.
제가 알기로는 애초에 실제로 UTC를 쓰는 사람은 거의 없었습니다.
제가 써 본 거의 모든 프로그래밍 언어와 데이터베이스는 윤초를 무시하고 하루를 86400초로 가정합니다. 그리고 윤초를 적용하는 인기 있는 방법 하나가 61초짜리 분을 만드는 대신 약 24시간 동안 모든 시계를 아주 조금 빠르게 돌리는 '스미어'[1]였습니다.
그러니 우리는 UTC 대신, 이름만 UTC인 약간 탄력적인 시간 척도를 쓰고 있는 셈입니다. 대부분 UTC와 맞아떨어지지만 선형성은 TAI와 같고, 1년 뒤 19:00 콘서트에 가기로 했는데 그 사이에 윤초가 공지되어 적용돼도 콘서트가 18:59:59로 바뀌지 않는다는 바람직한 성질도 있습니다.
[1] https://developers.google.com/time/smear
저는 23:59:60을 표시할 수 있는 시계를 단 하나도 못 봤어요. 컴퓨터만이 아니라 어떤 시계든요.
시스템은 하나같이 1) 앞뒤로 점프하거나, 2) 스미어하거나, 3) 어차피 1초 넘는 오차는 감수하는 시스템이라 무시하는 것 같아요.
세기가 바뀔 무렵에 제가 갖고 있던 알람시계 하나가 23:59:60을 표시할 수 있었고 윤초도 이해했던 걸로 기억합니다.
다만 그건 연도까지 포함한 정확한 날짜와 시각을 아는 전파 알람시계였어요. 그걸 보고 "아, 이거야말로 tialaramex한테 딱 필요한 물건이네" 하고 알아본 친구들에게 받은, 제 평생 최고의 선물 가운데 하나입니다. 스마트폰 시대인 지금은 필요 없지만요.
아주 드문 일이죠. 저는 2015년에 윤초를 제대로 보려고 시계 애플리케이션을 직접 만들었습니다. 녹화한 영상은 이겁니다. https://fedorapeople.org/~mlichvar/leap2015/clock_step.gif
예전에 쓰던 오븐은 시계가 00:01로 넘어가기 전에 23:60을 표시했어요!
와, 이건 완전 미친 거잖아요. 이걸 이제 알아 버렸네요. 몰라도 됐는데 ㅋㅋ
동의합니다.
저는 윤초가 왜 그렇게 큰 문제인지 한 번도 제대로 이해하지 못했습니다. 시스템은 이미 기기 사이의 시계 오차를 보정할 만큼 유연해야 합니다. 이 문서에서 기능이 부족하다고 지목한 IoT 기기 같은 저가 기기는 값싼 수정 발진자가 별로 좋지 않아서 시계가 수시로 어긋납니다.
비싼 데스크톱 PC에서도 오디오와 비디오 하드웨어의 클록이 꽤 어긋나기 때문에, 유튜브 영상을 끝까지 소리와 화면이 맞게 보려면 보정이 필요합니다. 블루투스 기기 같은 것들이 클록을 더 끼워 넣는 건 말할 것도 없고요.
이따금 윤초 하나를 앞이든 뒤든 스미어하는 것도 감당하지 못하는 시스템이라면 뭔가 잘못된 겁니다.
윤시간이 필요해질 때쯤이면 그런 방안은 이미 물 건너갔을 겁니다. 천 년 넘게 굳어진 관행 때문에, 시계 시간을 태양에 맞추는 데 신경 쓰지 않는 것 말고는 선택지가 없을 테니까요. 그래서 윤시간 이야기를 꺼내는 것 자체가 좀 농담 같습니다. 그런 발상을 언급했다는 게 놀랍고, 해법이 못 된다고 선언했어야 합니다.
아닙니다. UTC는 그대로 두고 모든 시간대를 한 시간씩 옮기는 쉬운 방법이 있습니다. 많은 곳이 이미 일광 절약 시간제로 1년에 두 번씩 그렇게 하고 있잖아요.
태양과 시계를 맞추는 또 다른 널리 쓰이는 방법이 이미 있는데, 왜 UTC를 그렇게까지 건드리는지 저는 이해한 적이 없습니다.
물론 그렇죠. 하지만 6만 5천 년 뒤에 정치적 시간대를 12시간 넘게 옮기는 건 기존 코드를 제대로 망가뜨릴 종류의 일 같습니다. (지금 tzdata에 그런 항목을 넣으면 어떻게 될지 궁금하네요. 지금부터 대비를 단단히 하려면 널 아일랜드를 +37:00이나 +1000:00 같은 말도 안 되는 값으로 지정해 보는 것도 좋겠습니다.)
그리고 그때쯤이면 어차피 정치적 시간대는 더 건드리지 말아야 할지도 모릅니다.
반세기도 안 되는 사이에 우리는 똑같이 흐르면서 임의의 상수 오프셋(+37초, +18초, +0초)만 다른 시간 표준을 3개(TAI, GPS, 그리고 이제 UTC)나 만들었습니다. 그때까지도 우아한 해법을 못 찾았다면, 6만 5천 년 뒤에는 컴퓨팅 파워 대부분을 시간 변환 라이브러리를 돌리는 데 쓰고 있을 가능성이 큽니다.
시간대는 수시로 바뀌고, 놀랄 만큼 촉박하게 바뀌는 일도 많습니다.
이름 모를 지방 정부 관료가 이렇게 하라고 선포하면, 우리 업계는 대체로 어떻게든 해결해 냅니다.
책임감 있는 정부일수록 충분한 유예 기간을 주고, 우리 업계는 그런 대응을 아주아주 잘합니다(여러분이 모르고 있다는 것 자체가 그 증거입니다).
그리고 윤초는 잘 가라! 우리가 감당하기엔 너무 어려웠고, 누구에게도 쓸모 있는 게 아니었어요.
세기가 바뀔 때마다 새 기준 시점을 정의하면 됩니다. "UTD"나 "UT2" 같은 이름으로 2200/01/01 00:00에 시작하는데, 실제로는 UTC 2199/12/31 11:43:21 같은 시각인 거죠. 그리고 그 마법의 TAI 숫자를 중력 상수 같은 것들과 함께 헤더에 하드코딩하는 겁니다. 세기마다 이렇게 하면 time_t 문제도 풀립니다. 2^32초 = 136.102208년이니까요. 가장 큰 걱정은 그 시대 아이들이 왜 UTB와 UTA는 없었냐고 묻기 시작할 텐데, 우리 맏손주들도 그 이유를 모른다는 점이겠죠.
결의문에는 사실 윤시간이 언급되어 있지 않고, 편차가 최대 1시간까지 커져도 된다고만 되어 있습니다. 그때 어떻게 할지는 후손들이 정하게 될 겁니다.
그때쯤이면 분명 지구의 자전을 우리 표준에 맞게 조정할 기술이 생겼겠죠.
한 세기 뒤에는 마침내 지구 궤도를 고쳐서 1년을 딱 떨어지는 360일, 한 달 30일씩 12개월로 만들 수 있을 거예요. 깔끔하고, 복잡하거나 헷갈릴 일도 없고... 아, 그런 날이 오면 좋겠네요.