컴퓨터가 결코 반기지 않았던 1초의 추가 시간
현대 시간 측정의 근간인 원자 시계는 흔들림 없는 정밀함으로 작동합니다. 하지만 지구의 자전은 일정하지 않으며 예측할 수 없이 느려지거나 빨라집니다. 이러한 불일치를 해결하기 위해 역사적으로 협정 세계시(UTC)에 윤초(leap seconds)를 삽입하여 지구의 천체 리듬과 0.9초 이내의 오차를 유지해 왔습니다.
1972년 도입 이후 총 27번의 양의 윤초가 추가되었습니다. 이 드문 경우에 시계는 23:59:59에서 전례 없는 23:59:60으로 넘어간 뒤 자정으로 바뀝니다. 이 추가된 1초는 컴퓨터 시스템에 독특한 문제를 야기합니다.
시간 측정의 기본 단위인 Unix time은 모든 날이 정확히 86,400초라고 가정하며, 23:59:60을 표현할 수 있는 기본 구조가 없습니다. Linux와 같은 운영 체제는 전통적으로 1초를 반복하여 23:59:59를 두 번 재생하는 방식으로 이를 해결합니다.
벽시계 시간이 일시적으로 뒤로 가는 것처럼 보이는 이러한 '비단조적(non-monotonic)' 시간 조정은 수많은 소프트웨어 애플리케이션의 핵심 가정을 위반합니다. 이러한 혼란은 2012년 악명 높은 Reddit 장애를 포함하여 반복적으로 치명적인 오류를 발생시켰으며, 컴퓨터가 설계상 처리할 수 없었던 1초로 인해 시스템이 얼마나 취약한지를 보여주었습니다.
반복된 1초가 어떻게 Reddit을 무릎 꿇게 했는가
이러한 연쇄 반응의 대표적인 사례가 2012년 6월 30일에 발생했습니다. 그날 윤초 삽입은 Linux 커널에서 치명적인 버그를 유발했습니다. 커널의 hrtimer 코드가 futex 타이머와 상호 작용하면서 매끄럽게 조정되지 않고 프로세스가 반복적으로 즉시 깨어나는 현상이 발생했습니다. 이로 인해 CPU 사용률이 100%까지 치솟으며 시스템이 사실상 교착 상태에 빠졌습니다.
주요 온라인 플랫폼인 Reddit은 이 미묘한 시간 조정의 직격탄을 맞았습니다. 서비스는 약 30~40분 동안 중단되었으며, 단 1초의 반복이 프로덕션 인프라 전반에 파급 효과를 일으켜 널리 사용되는 애플리케이션을 마비시킬 수 있음을 입증했습니다.
이 사건과 유사한 사례들은 중요한 엔지니어링 교훈을 남겼습니다. 벽시계 시간(wall-clock time)은 항상 단조적이지 않다는 것입니다. 시간은 앞으로 점프하거나, 뒤로 가거나, 반복될 수 있으며, 이는 시간이 항상 선형적으로 흐른다는 소프트웨어의 암묵적인 가정을 정면으로 반박합니다.
견고한 시스템을 위해 개발자는 time.Now()에만 무조건 의존하지 않는 경과 시간 및 이벤트 순서 지정 로직을 설계해야 합니다. 대신 잠재적인 불연속성을 고려해야 합니다. 여기에는 기간 측정 시 단조 시계(monotonic clocks)를 사용하고 시간이 뒤로 흐르는 것처럼 보일 수 있는 이벤트 시퀀스를 신중하게 관리하는 것이 포함됩니다.
Cloudflare의 음수 시간 패닉과 스미어(smear) 해결책
2017년 새해 첫날 발생한 또 다른 윤초는 Cloudflare의 DNS를 마비시켰습니다. 그들의 Go 코드는 종료 타임스탬프에서 시작 타임스탬프를 빼서 DNS 조회 시간을 계산했습니다. 시계가 뒤로 조정되자 계산 결과는 음수 기간(negative duration)이 되었고, 음수가 아닌 인자를 기대하던 함수가 이를 받아 치명적인 패닉을 유발했습니다.
이 사건은 근본적인 결함을 드러냈습니다. 많은 소프트웨어 시스템은 시간이 항상 앞으로 흐른다고 가정하는데, 표준 윤초(leap second) 조정은 이 가정을 위반합니다. Cloudflare가 설명했듯이, "인식된 해결 시간이 음수가 되어" 예기치 않은 충돌을 일으킵니다. 자세한 내용은 How and why the leap second affected Cloudflare DNS를 참조하십시오.
이러한 급격한 시간 도약을 피하기 위해 Google 및 Meta와 같은 주요 운영자는 leap smearing이라는 기술을 사용합니다. 1초를 한 번에 삽입하는 대신, 시스템 시계를 몇 시간에 걸쳐 미세하게 늦추어 추가된 1초를 점진적으로 분산시킵니다. 이를 통해 내부 시스템에서 시간이 뒤로 흐르는 것처럼 보이는 현상을 방지합니다.
Smearing은 소프트웨어 오류를 유발하는 급격한 불연속성을 방지하지만, 새로운 과제를 안겨줍니다. 조직마다 서로 다른 smearing 일정을 사용할 수 있어 시스템 간의 시계 판독값이 일시적으로 달라질 수 있습니다. 따라서 분산 인프라 전반의 일관성을 유지하려면 시간 소스에 대한 세심한 조정이 필요합니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
윤초는 사라질 예정이지만, 시간 관리는 여전히 중요합니다
국제 도량형 기구들은 윤초를 폐지하기로 결정했으며, 이 변경 사항은 2035년까지 완전히 시행될 예정입니다. 이러한 기념비적인 변화로 인해 Coordinated Universal Time (UTC)과 지구 자전 시간 사이의 더 큰 편차가 허용되며, 지난 반세기 동안 이어진 혼란스러운 조정이 종식됩니다. 이 결정은 윤초의 위험이 이점보다 크다는 공감대가 커지고 있음을 반영합니다.
이 변화의 결정적인 동인은 최근 지구 자전 속도가 약간 빨라졌기 때문입니다. 이로 인해 UTC에서 1초를 제거해야 하는 negative leap second라는 전례 없는 가능성이 제기되었습니다. 이전에 시행된 적 없는 이러한 조정은 역사적으로 1초를 추가하는 것조차 어려워했던 소프트웨어에 훨씬 더 큰 문제를 야기할 것입니다.
개발자에게 이는 윤초의 즉각적인 위협이 결국 사라질 것임을 의미하지만, 견고한 시간 측정의 기본 원칙은 여전히 유효합니다. 시간 간격과 타임아웃을 측정할 때는 시간이 항상 앞으로 흐름을 보장하는 monotonic clocks를 사용하십시오. UTC와 연결된 일반 타임스탬프는 경과 시간 측정과 별도로 유지해야 합니다.
마지막으로, 시계 동작에 대한 모든 가정을 엄격하게 테스트하십시오. 윤초가 없더라도 시스템은 여전히 다음과 같은 상황에 직면할 수 있습니다:
- 시간 동기화 실패
- 네트워크 지연
- 수동 시계 조정
신뢰할 수 있는 분산 시스템을 위해서는 세심한 설계와 검증이 무엇보다 중요합니다.
자주 묻는 질문
윤초(leap second)란 무엇인가요?
윤초는 지구의 불규칙한 자전과 UTC를 대략적으로 맞추기 위해 가끔 추가되는 1초를 말합니다.
윤초가 소프트웨어 오류를 일으키는 이유는 무엇인가요?
일부 시스템은 시계의 1초를 반복하거나 조정하는데, 이는 시간이 항상 앞으로 흐른다고 가정하거나 모든 날이 정확히 86,400초라고 가정하는 소프트웨어에 문제를 일으킵니다.
Cloudflare의 2017년 DNS 문제는 무엇 때문에 발생했나요?
시계가 뒤로 조정되면서 음수가 아닌 값을 기대하는 코드에서 음수 기간이 생성되었고, 이로 인해 난수 함수에서 패닉이 발생했습니다.
개발자가 여전히 monotonic clocks를 사용해야 하나요?
네. 경과 시간을 측정할 때는 monotonic clocks를 사용하십시오. 월 클락(wall clocks)은 여전히 조정될 수 있으므로 타임스탬프나 달력 시간에 더 적합합니다.