2000년을 앞두고 전 세계가 ‘밀레니엄 버그’ 때문에 긴장했던 일을 기억하는 분이 많을 것입니다. 연도를 두 자리로만 적던 프로그램이 2000년을 1900년으로 착각할 수 있다는 걱정이었습니다. 그런데 컴퓨터 세계에는 이와 닮은 또 하나의 날짜 문제가 아직 남아 있습니다. 바로 ‘2038년 문제(Year 2038 Problem)’입니다.

2038년 문제란 쉽게 말해 시간을 초 단위 숫자로 세는 컴퓨터가 2038년 1월 19일 이후의 시각을 제대로 나타내지 못하게 되는 현상을 의미합니다. 숫자를 담는 칸의 크기가 정해져 있어 생기는 일이며, 영어권에서는 Y2K38이나 시대(epoch)와 종말(apocalypse)을 합친 ‘에포칼립스(Epochalypse)’라는 별명으로도 불립니다.

본 자료에서는 컴퓨터가 시간을 세는 방식부터 2038년 문제가 생기는 원리, 이미 나타난 사례와 위험한 장치, 그리고 지금까지 마련된 해결책까지 차례로 살펴보겠습니다.

시계가 거꾸로 돌아가는 날, 2038년 문제

컴퓨터는 시간을 어떻게 셀까

우리는 날짜를 연, 월, 일로 적지만, 많은 컴퓨터는 시간을 하나의 큰 숫자로 기억합니다.

(1) 유닉스 시간
유닉스(Unix) 계열 운영체제와 그 영향을 받은 수많은 시스템은 1970년 1월 1일 0시 0분 0초(협정 세계시 기준)를 출발점으로 삼고, 그때부터 몇 초가 흘렀는지를 세어 시간을 표현합니다. 이 방식을 ‘유닉스 시간(Unix Time)’이라고 하고, 출발점을 ‘유닉스 시대 기점(Unix Epoch)’이라고 부릅니다.

(2) 숫자 하나로 다루는 장점
시간이 숫자 하나로 정리되면 두 시각 사이의 간격을 빼기 한 번으로 구할 수 있고, 저장하거나 비교하기도 쉽습니다. 그래서 파일이 만들어진 시각, 로그 기록, 예약 작업처럼 시간이 필요한 곳 어디에나 이 방식이 쓰였습니다.

(3) 정해진 칸의 크기
문제는 이 숫자를 담는 칸입니다. 오랫동안 많은 시스템이 유닉스 시간을 ‘부호 있는 32비트 정수’에 저장했는데, 이 칸에 담을 수 있는 가장 큰 수는 2,147,483,647입니다.

2038년 문제가 생기는 원리

정해진 칸에 숫자를 계속 더하면 언젠가 칸이 넘치는 순간이 옵니다.

(1) 마지막 1초
1970년부터 2,147,483,647초가 지나는 시각은 협정 세계시로 2038년 1월 19일 3시 14분 7초, 한국 시간으로는 같은 날 낮 12시 14분 7초입니다. 32비트 칸이 나타낼 수 있는 마지막 순간이 바로 이때입니다.

(2) 넘침과 부호 뒤집힘
여기서 1초가 더해지면 숫자가 칸을 넘쳐 맨 앞의 부호 자리가 바뀝니다. 이를 ‘정수 오버플로(Integer Overflow)’라고 하며, 가장 큰 양수였던 값이 순식간에 가장 작은 음수가 됩니다.

(3) 1901년으로 돌아간 시계
음수가 된 시간은 기점보다 앞선 과거로 해석됩니다. 그 결과 시스템은 지금이 1901년 12월 13일이라고 착각하게 되고, 날짜로 계산하는 기능들이 엉뚱하게 움직일 수 있습니다.

밀레니엄 버그가 연도를 십진수 두 자리로 적은 탓에 생겼다면, 2038년 문제는 시간을 이진수 32자리 칸에 담은 탓에 생긴다는 점이 다릅니다.

이미 나타난 사례와 위험한 장치

2038년은 아직 오지 않았지만, 먼 미래의 날짜를 계산하는 프로그램에서는 이미 문제가 드러났습니다.

• 웹 서버의 시간 초과(AOLserver): 2006년 5월, 한 웹 서버 프로그램이 ‘절대 끝나지 않아야 할’ 요청의 마감 시각을 10억 초 뒤로 잡아 두었다가, 그 마감이 2038년을 넘어서면서 계산이 꼬여 멈추는 일이 생겼습니다.
• 메일 서버의 새해 오류(Exchange Server): 2022년 1월 1일, 마이크로소프트의 메일 서버 프로그램이 업데이트 번호를 32비트 숫자로 다루다가 그 값이 한계를 넘자 악성 코드 검사 기능이 멈췄습니다.
• 오래 쓰는 내장 장치(Embedded Systems): 자동차 제동 장치, 공유기, 네트워크 카메라처럼 한 번 설치하면 수십 년씩 쓰고 업데이트가 드문 장치들이 가장 걱정되는 대상으로 꼽힙니다.

물론 모든 장치가 위험한 것은 아닙니다. 날짜가 필요 없거나 두 시각의 차이만 계산하는 장치는 큰 문제를 겪지 않을 수 있습니다.

2038년 문제를 막는 방법

2038년 문제에는 한 번에 모든 것을 고치는 만능 해결책이 없어서, 여러 방법이 함께 쓰이고 있습니다.

(1) 64비트로 칸 넓히기
가장 널리 쓰이는 방법은 시간을 담는 칸을 64비트로 늘리는 것입니다. 이렇게 하면 넘침이 일어나기까지 약 2,920억 년이 걸려, 사실상 끝이 없는 시계가 됩니다. 64비트 컴퓨터용 운영체제 대부분은 이미 이 방식을 쓰고 있습니다.

(2) 오래된 32비트 환경 손보기
리눅스는 2020년 5.6 버전부터 32비트 장치에서도 64비트 시간을 쓸 수 있게 바뀌었고, 넷BSD와 오픈BSD 같은 운영체제도 일찍부터 64비트 시간으로 옮겨 갔습니다. 다만 칸의 크기를 바꾸면 기존 프로그램과 맞지 않을 수 있어 조심스럽게 진행해야 합니다.

(3) 남은 시간 동안 점검하기
운영체제가 바뀌어도 그 위에서 도는 프로그램이나 데이터베이스가 여전히 32비트 숫자로 시간을 다루면 문제는 남습니다. 그래서 오래된 코드와 장치를 미리 찾아 고치는 꾸준한 점검이 가장 확실한 대비가 됩니다.

2038년 문제는 아주 작은 설계 선택이 수십 년 뒤에 커다란 숙제로 돌아올 수 있다는 사실을 보여 줍니다. 당장은 충분해 보이는 칸도 시간이 쌓이면 언젠가 넘친다는 점을 기억하고 미리 대비하는 자세가 필요합니다.

오늘의 편리한 선택이 내일의 한계가 될 수 있음을 아는 것, 그것이 오래가는 시스템 설계의 첫걸음입니다.