한참 옛날 일이 되어버렸지만 Y2K 라는 문제가 있었다. 컴퓨터가 날짜 계산시, 특히 1999년 12월 31일에서 2000년 1월 1일로 넘어갈 때 연도를 1900년도로 인식하여 날짜 계산에 엄청난 오류가 발생할 것이라는 인식하지 못할 것이라는 일종의 컴퓨터 설계 버그였다. 컴퓨터의 메모리가 용량은 적고 값은 무지 비쌌을 시절에 천공카드 사용시 1969년을 그냥 69년으로 표기하면 카드에 들어가는 데이터의 용량을 그나마 줄일 수 있었던 시절의 설계 오류였으나 몇몇 문제가 있는 것을 제외하고는 별 문제가 없이 끝났던 사건이었다. (이를 밀레니엄 버그라고 한다.)
근데 이젠 또 다른 시스템의 시계 문제가 불거졌다. 바로 2038년 문제라고도 하는 유닉스의 밀레니엄 버그이다. 근데 이거에 대해서는 현재 업계 종사자 대부분의 사람들이 별 걱정하지 않고 있다. 그렇다면 이게 무슨 문제이고, 왜 그냥 막 넘어가는 걸까?
POSIX 규격에 따른 시간 표기법에 의하면, 시간을 1970년 1월 1일 자정 UTC 시간 이후부터 경과된 초 시간을 이용하여 시간을 표기한다. 이 표기법은 대부분의 유닉스, 리눅스 계열의 OS에서는 거의 공통적으로 나타나는 표기 형식이고, POSIX를 지원하는 기타 운영체제들 또한 마찬가지로 일어나는 형식이다. POSIX 규격에 맞춰서 개발되었다면 C로 개발되었을 것이고, C의 데이터 표기 체계에 맞춰진 대부분은 32비트 시스템에서 초 시간을 저장하는 데 이용되는 time_t 자료 형식을 그대로 이용한다고 보면 된다.
time_t 자료 형식은 부호 있는 32비트 정수형이다. POSIX 표준에 따르면 이 형식을 이용하여 나타낼 수 있는 최후의 시각은 1970년 1월 1일 자정에서부터 정확히 2147483647초가 지난 2038년 1월 19일 화요일 03시 14분 7초 (UTC)이다. 이 시각을 지나면 시각 표기 자릿수 범위를 초과하여 내부적으로 음수로 표현되고 프로그램의 이상 작동을 유발하게 된다. 프로그램 구현 방법에 따라서 년도 값이 2038년이 아닌 1970년 또는 1901년으로 표기되기 때문에 기존에 있던 자료들의 생성 시간과의 차이가 생기게 된다. 이는 치명적인 오류를 낳게 된다. 상대시간 표기 오류가 발생하거나 바이너리 수준의 호환성 오류가 발생하여 파일이나 프로그램을 정상적으로 실행시킬 수 없게 된다.
이 문제의 해결책은 의외로 간단하다. 현재 나오는 CPU와 OS들이 이 문제를 다 해결해 주고 있다. 바로 64비트 아키텍쳐를 이용하면 된다. 표현되는 확장 범위가 32비트에서 64비트로 넘어가면 그만큼의 시간은 무지 길어지게 된다. 64비트 정수 체계로 넘기면 대략 계산 가능한 시간은 1970년 1월 1일 자정을 기준으로 9223372036854775807초를 경과한 2922억 7702만 6596년 12월 4일 일요일 15시 30분 8초 (UTC)까지 진행할 수 있게 된다. 근데 이 글을 보고 있는 여러분이 이 시간까지 살아서 오류가 날지 안날지를 지켜볼 수 있을 거라 생각하는가…? 최소한 태양의 수명이 앞으로 약 123억년이라고 하였고, 현대 과학은 아직은 시간 도약을 할 수 있는 기술이 없다. 그냥 잘~ 해결된다고 보면 된다. ㅡㅅㅡ;;;
현재 대부분의 PC의 경우에는 64비트 운영체제와 프로세서로 전환되고 있는 실정이기 때문에 문제 없이 진행이 될 수 있으나, 임베디드 장비들의 경우에는 아직도 심각한 문제일 수 있다. 임베디드형 연산은 아직까지도 최대 32비트 연산체계를 벗어나지 못하였기 때문이다. 거의 수많은 임베디드 시스템이 2038년에 모두 교체가 될지부터 엄청난 미지수이지만 눈앞에 당장 바로바로 사용되는 것들의 경우에는 쉽게 교체가 이루어질 수 있을 거란 전망이다. 단, 스마트폰 빼고는…ㅡㅅㅡ
(스마트폰 제조사들은 오버클럭 매니아들처럼 클럭 수 올리는 거에 혈안두지 말고 64비트 지원이나 먼저 신경 좀 쓰지…ㅡㅅㅡ)