2038년 문제

2038년 문제(2038年 問題, )란 컴퓨터 분야에서 2038년 또는 전후에 특정한 컴퓨터 소프트웨어에 이상이 발생하는 문제를 말한다. 이 문제는 POSIX 시간 표기법을 이용하는 프로그램에서 발생하는데, 이 표기법은 시간을 1970년 1월 1일 자정 UTC 이후 경과된 초 시간을 이용하여 표현한다. 이 표기법은 유닉스 계열의 운영 체제에서 표준이며, C가 널리 이용되기 때문에 다른 대부분의 운영 체제에서 작동하는 프로그램에도 영향을 준다. 대부분의 32비트 시스템에서 초 시간을 저장하는 데 이용되는 time_t 자료 형식은 부호 있는 32비트 정수형이다. POSIX 표준에 따르면, 이 형식을 이용하여 나타낼 수 있는 최후의 시각은 1970년 1월 1일 자정에서 2147483647초가 지난 2038년 1월 19일 화요일 03:14:07 UTC이다. 이 시각 이후의 시각은 범위를 초과하여 내부적으로 음수로 표현되며, 프로그램의 이상 작동을 유발하는데, 왜냐하면 이러한 값은 2038년 대신 프로그램의 구현 방법에 따라 1970년 또는 1901년을 가리키기 때문이다. 따라서 계산 오류와 결정 오류가 발생할 수 있다.

 해결책 
현재의 CPU와 OS 조합에서 이 문제의 간단한 해결책은 없다. 표현 범위를 확장하려 32비트 대신 64비트를 이용하도록 time_t의 정의를 변경할 수 있지만, 이렇게 할 경우 소프트웨어, 저장 장치, 그리고 일반적으로는 시간의 이진 표현을 이용하는 모든 곳에서 바이너리 수준의 호환성에 이상이 생길 수 있다. time_t를 부호 없는 32비트 정수형으로 바꿀 경우 2106년 2월 7일 06:28:15 UTC까지는 다룰 수 있게 되지만, 프로그램이 시간 차이를 다루거나 상대적인 시간을 표현할 때 음수를 다룰 수 없어 문제가 생긴다.

64비트 아키텍처를 이용하는 대부분의 운영 체제는 이미 time_t에 64비트 정수를 이용하고 있다. 이미 이러한 아키텍처로의 이전이 진행 중이며, 많은 사람들은 이것이 2038년 전에 완료될 것으로 예상하고 있다. 하지만 2012년 기준으로 수억대의 32비트 시스템이 있으며, 많은 수가 임베디드 시스템에 내장되어 있는데, 이 모두가 2038년까지 교체될 수 있을지는 불분명하다. 또한 time_t는 ZIP 파일 포맷을 비롯한 많은 파일 포맷들에 사용되고 있다.

64비트 정수형 체제 하에서는 이 문제를 약 3000억 년 정도 연기시킬 수 있다. 만약 그때까지 그레고리력이 단 한번도 개정되지 않고 쓰이고 있다면, 정확히 2922억 7702만 6596년 12월 4일 일요일 15:30:08 UTC 이후의 시각을 다루려 할 때 문제가 발생한다.(이것은 당연히 UTC(그리니치 표준시) 시간이다. 따라서 대한민국 표준시로는 UTC보다 9시간 빠르므로, 292277026596년 12월 5일 월요일 00시 30분 07초 까지는 안전하다. 물론, 당연히 128비트로는 이 문제를 약 500양년(년) 정도 연기시킬 수 있다.) http://www.merlyn.demon.co.uk/critdate.htm#2038  그러나 이는 태양의 수명보다 훨씬 긴 시간이기 때문에 지구상의 컴퓨터에서는 문제가 발생하지 않는다.

 알려진 문제 

2006년 5월에 발생한 AOLserver 소프트웨어의 문제는 최초로 나타난 2038년 문제의 예로 알려져 있다. 소프트웨어 설정에서 데이터베이스 연결의 지속 시간을 10억 초로 지정하여 ‘절대로 연결이 끊기지 않음’을 나타내는 경우가 있었는데, 2006년 5월 13일 01:27:28 UTC에서 10억 초 지난 시간은 time_t로 표시할 수 없었고, 따라서 이 시점부터 지속 시간이 과거의 시간으로 계산되어 소프트웨어에 문제를 일으켰다. AOLServer 버그 관련 메일링 리스트 글타래.

 같이 보기 
 2000년 문제
 2010년 문제
 10000년 문제
 10억 초 문제

 각주 

분류:리눅스
분류:유닉스
분류:운영체제 기술
분류:소프트웨어 버그
분류:2038년
분류:미래 문제