윤초가 사라진다 — IT 시스템은 지금 뭘 준비해야 할까
서버 배포 직후 로그 타임스탬프가 서버마다 달라 원인 추적이 꼬였던 경험이 있다면, 이 글이 바로 그 이유를 설명한다. 그리고 윤초 폐지 이야기가 IT 담당자 귀에 유독 먼저 들리는 이유도.
먼저 정확히 짚어두면, 윤초는 2026년에 곧바로 사라지지 않는다. 국제도량형국(BIPM)은 2022년 11월 총회에서 2035년까지 윤초를 폐지하기로 결정했고, 국제전기통신연합(ITU)도 2023년 12월 WRC-23에서 같은 방향의 결의를 채택했다. 당장 운영에 즉각적인 변화가 생기는 건 아니지만, 지금이 바로 시간 동기화 정책을 다시 점검할 적기다.
윤초가 왜 그렇게 오래 골칫거리였나
원자시계 기반의 UTC는 너무 정확해서 문제다. 지구 자전 속도가 미세하게 달라지면 천문시(UT1)와 차이가 벌어지는데, 이 간격을 메우기 위해 1972년부터 평균 2년마다 1초를 더하거나 빼왔다. 이게 윤초다.
사람에게 "1초 정도야"는 아무것도 아니지만, 시스템은 다르다. 분산 서버, DB 레코드 정렬, 인증 토큰 만료, 배치 스케줄러 — 전부 시간을 기준으로 움직인다. 그 기준이 예고 없이 1초 달라지면 정렬 순서가 뒤집히거나 타임아웃 로직이 어긋날 수 있다.
실제 피해도 있었다. 2012년 Reddit은 윤초 적용 시점에 서버가 다운됐고, 2016년 Cloudflare도 관련 장애가 발생했다. 콴타스 항공 발권 시스템도 윤초 처리 과정에서 오류를 겪었다. (지디넷코리아 보도 기준)
그래서 구글, 메타 같은 대형 기업들은 오래전부터 스미어링(smearing) 방식을 써왔다. 1초를 한 번에 적용하지 않고 수십 분에 걸쳐 나눠 조정하는 방식이다. "정확한 시간"보다 "서비스 안정성"을 우선한 선택이었다.
폐지되면 끝? 조용히 남는 문제들
윤초가 없어지면 그 예외 처리 부담도 사라지니 운영 팀 입장에서는 반가운 변화다. 하지만 UTC와 UT1의 차이는 계속 쌓인다. 앞으로 최대 1분까지 오차가 허용될 수 있고, 장기적으로는 '윤분' 같은 더 큰 단위의 조정 방식이 논의되고 있다.
즉, 당장 운영 복잡도는 줄어들 수 있어도 시간 체계 문제 자체가 없어지는 건 아니다. 그래서 지금 필요한 건 "드디어 편해지겠다"는 안도감보다, 우리 시스템이 시간을 어떻게 다루고 있는지 파악하는 것이다.
중소기업·스타트업이 먼저 봐야 할 위험 신호
대기업은 전담 인프라팀이 있다. 중소기업과 스타트업은 보통 없다. 그래서 윤초 폐지의 직접 영향보다 기존에 숨어 있던 시간 설정 불일치가 더 위험할 수 있다.
가장 먼저 확인할 건 간단하다. 내 서버들이 지금 같은 기준으로 시간을 맞추고 있는가? 사내 서버, 클라우드 인스턴스, 컨테이너 호스트, 로그 수집 시스템이 제각각 다른 NTP 서버를 바라보고 있다면, 장애가 났을 때 로그 시간부터 안 맞아 원인 추적이 꼬인다.
다음은 OS 수준의 윤초 처리 방식이다. Red Hat 공식 문서를 보면 RHEL은 NTPD를 통한 무시, chrony를 통한 스미어링 등 여러 옵션을 제공한다. 문제는 어떤 옵션이 지금 우리 환경에서 실제로 적용되고 있는지 팀이 알고 있느냐다. 재배포 과정에서 기본값으로 돌아간 서버가 있을 수도 있다.
지금 해두면 좋은 실전 대응 5가지
1. 전사 시간 기준 하나로 정하기 "어느 NTP 서버를 쓸지"보다 중요한 건 전사 표준을 정하고 예외를 줄이는 것이다. 서버마다 설정이 다르면 나중에 점검 자체가 안 된다.
2. 운영 인스턴스 실제 설정 확인 문서상 설정 말고, 지금 배포된 서버를 직접 확인해야 한다. chrony를 쓴다면 스미어링 정책이 실제로 적용되고 있는지, 일부 인스턴스만 다른 설정을 쓰고 있지 않은지.
3. 시간 민감 기능 목록 만들기 다음 항목은 따로 관리해야 한다: 인증 토큰 만료, 배치 스케줄러, 로그 정렬 시스템, DB 레코드 시각 비교 로직, 분산 락·캐시 만료·세션 유효시간. 평소에도 버그를 만들기 쉬운 영역이다.
4. 테스트 환경에서 시간 변화 시나리오 돌려보기 시간이 갑자기 튀거나, 두 서버의 시간이 잠시 어긋나는 상황을 미리 재현해봐야 한다. 정밀 시뮬레이션이 아니어도 좋다. "우리 서비스가 시간 이상 상황에서 어떻게 망가지는지" 미리 보는 것 자체가 중요하다.
5. 장애 런북에 시간 이슈 항목 추가하기 로그 시간 불일치, 인증 실패 급증, 예약 작업 중복 실행이 보이면 시간 동기화를 먼저 확인하도록 런북에 한 줄 넣어두는 것. 실제 장애 순간에 이 한 줄이 대응 시간을 크게 줄여준다.
결론: 윤초 폐지는 기회이기도 하다
운영 부담이 줄어든다는 점에서 윤초 폐지는 반갑다. 하지만 그 이득은 시스템을 제대로 정비한 조직에게만 온다. "클라우드가 알아서 해주겠지"라고 미뤄온 곳은 오히려 이번 논의가 기존 취약점을 드러내는 계기가 될 수 있다.
시간 문제는 평소엔 보이지 않다가, 터지면 서비스 신뢰를 직격한다. 지금 해야 할 일은 복잡하지 않다. 내 서버와 서비스가 같은 시간 기준으로 움직이는지, 그리고 시간 보정 상황에서 어떤 방식으로 처리되는지부터 확인하는 것. 그 점검 하나가 "왜 그때 안 봤지"를 막는다.
