1. 개요
| 2038년 문제 발생까지 |
| D[dday(2038-01-19)] |
| |
2. 문제점
사람들이 쓰는 태양력을 컴퓨터에서 계산하는 방법은 여러 가지가 있는데, 가장 많이 쓰는 방법이 UNIX 운영체제에서 채용한 유닉스 시간이다. 여기서는 32비트 크기의 정수형으로 시간을 나타내는 변수를 선언하고 초당 1씩 증가하도록 처리했다. 그런데 이 변수 값이 32비트 크기의 표현 한계인 2,147,483,647까지 증가하면 더 이상 증가할 수 없게 된다. 컴퓨터에서 이런 오버플로가 발생할 경우 해당범위의 최솟값으로 돌아가는 식으로 처리된다. 가령 값(x)에 할당된 공간이 1바이트고 범위가 0 ≤ x ≤ 255일 때, 255 다음의 수는 256이 아니라 0이 되고 플래그가 세트되는 식이다.이로 인해 2038년 1월 19일 03시 14분 07초가 지나면 유닉스 시간이 맨 처음으로 돌아가게 되고, 그로 인해 컴퓨터의 각종 연산에 문제를 줄 수 있다. 조용히 넘어갈 수도 있지만 Y2K 문제에서 언급한 문제들이 더 크게 발생할 수 있다. Y2K의 경우 당시에는 인터넷 보급이 미비하던 시기였고 실시간 온라인 동기화가 생소한 개념이었으며 사용 기기가 PC와 피쳐폰에 한정되었기에 숨은 비용이 많이 들기는 했어도 큰 혼란없이 넘어가기가 수월하였다. 하지만 유닉스 시간은 그 시절보다 훨씬 더 인터넷이 발달한 시대에 여러 기기에서 실시간 동기화로 쓰고 있어 더 큰 문제가 될 가능성이 있다.
시간을 나타내는 변수를 32비트 크기가 아니라 64비트 크기의 정수형으로 바꾸면 되지만 말처럼 쉬운 게 아니란 점이 골칫거리. 시간을 표현하는 변수의 형식을 그냥 막 바꿔버리면 기존에 구현한 알고리즘들도 꼬이고 각종 호환성 문제가 터질 수 있기 때문이다.
정수형을 부호 없는 정수형(Unsigned Integer)으로 바꾸면 2106년까지 늦출 수 있다. 음수 부분 없이 0부터 시작해 4,294,967,295까지 증가하기 때문. 물론 이렇게 하면 Unix Time 0에 해당하는 1970년 1월 1일 이전의 시간을 셀 수 없으므로 60년대생이 전부 사라지기 전까지는 이 역시 문제가 있다.
이 32비트 정수형의 오버플로 문제와는 별개로 많은 공개키 인증기관의 루트인증서의 유효기간 만료일자가 2038년 1월 전후로 설정된 경우가 많다. 현재 각종 인터넷 서버나 앱스토어의 어플과 게임들, 또 개인컴퓨터의 사용자 계정보안이나 암호화 등의 인증에 공개키기반의 인증서를 사용하고 있다. 이를 위해 마이크로소프트를 비롯해 여러 상업적 공개키 인증기관들이 서비스 중인데 이들 인증기관의 루트인증서의 유효기간 만료일이 2038년 1월 전후로 설정돼 있는 것이다. 서버 인증이나 사용자 계정이나 프로그램을 계속 이용하려면 새로운 루트인증서로 교체한 인증기관으로 부터 새로 받은 개발자 인증서로 프로그램에 대해 서명을 새로 해서 프로그램을 교체해야 한다.
현재 사용중인 서버나 컴퓨터를 윈도우 OS의 새로운 버전이나 새로운 프로그램으로 업데이트하면 만료되는 인증서도 자연히 새로운 인증서로 갱신되어 문제가 없지만 예를 들어 아주 옛날에 프로그램을 설치 가동하고 업데이트하지 않고 수 십 년간 계속 이용하는 경우는 2038년 전후로 문제가 발생할 수 있다.
지금도 POS나 ATM, 키오스크, 공장자동화, 무기, 공공시설 관리 등에는 2001년에 출시된 윈도우 XP 기반 컴퓨터가 계속 쓰이는 경우가 많고 미국도 핵무기 발사시설은 1950년대에 개발된 구식 시스템을 쓰고 있다. 이런 수십 년씩 업그레이드하지 않고 계속 쓰는 시스템과 프로그램은 꼭 2038년 1월은 아니더라도 그 전후로 만료되는 인증기관 루트 인증서가 많아서 따로 서버나 프로그램을 갱신해 주지 않으면 오래된 인증서 유효기간 만료로 서버나 계정이나 프로그램 실행이 문제가 될 수 있다. 다만 이러한 인트라넷을 구축한 기관은 내부 개발자들이 이런 문제를 인지하고 사전조치를 취하므로 큰 문제없이 넘어가기 용이하다.
3. 해결책
시간을 저장할 때 64비트 정수형을 쓰도록 OS와 프로그램을 고친다는 생각은 누구나 할 수 있지만, 그러려면 기존에 나온 프로그램이나 데이터를 전부 갈아엎어야 한다. 32비트 OS가 주류였던 시기에는 누구나 시간을 저장할 때 32비트를 사용했으므로 실행 파일, 라이브러리, OS API/ABI는 시간을 다룰 때 32비트 정수형이 올 것을 가정하고 만들어져 있다. 이런 상황에서 시간 함수 및 자료형만 64비트 정수형으로 바뀌면 기존의 실행 파일과 라이브러리는 OS에서 64비트 정수형으로 시간을 처리한다는 것을 모르므로, 수정한 OS에 맞춰서 다시 컴파일하지 않으면 의도한 대로 작동하지 않는다.한 예로 OpenBSD 5.5는 32비트 플랫폼에서도 64비트로 시간 값을 처리해서 2038년 문제에서 벗어났지만, 바로 이 문제 때문에 ABI가 바뀌어서 OpenBSD 5.4의 실행 파일과 라이브러리를 실행할 수 없다. 게다가 일부 네트워크 프로토콜, 파일 형식은 내부적으로 32비트로 시간을 저장하는데 이걸 단시일 내에 모두 64비트로 전환할 수 있다는 보장이 없다. 프로그래밍 언어인 PHP 의 경우 5.4 버전부터 64비트 버전이 나왔으므로 5.3 이하 버전은 2038년 문제에 영향받게 된다.
컴퓨터 업계 쪽 사람들은 의외로 느긋하게 생각하고 있는데, 지금부터 프로그램을 짤 때 유닉스 시간에 64비트 정수형을 쓰면 된다는 것이다. 유닉스 시간을 설계하던 당시에도 이 문제를 알고 있었지만 "후손들이 그 전에 알아서 잘 해결할 거야"였다나 뭐라나.
국내 시스템은 2038년 문제가 없다고 봐도 된다. 중국에선 국내 소프트웨어를 이용해 시스템을 구축하고 상용화하기 전에 테스트를 통해 2038년 문제를 감지하고 수정 버전을 요청한 적이 있다.
때문에 이미 같은 문제를 경험 한 바 있고 남은 시간 동안 대처가 충분히 이뤄질 가능성이 높아서 막상 2038년이 되면 Y2K처럼 시끄럽지는 않을 확률이 크다.
64비트 정수형도 수 표시에 한계가 있긴 하지만, 오류가 발생하는 시점은 서기 1970년 1월 1일 UTC 00:00:00으로부터 초[2] 후 시점인 약 서기 2922억년(서기 2.922×1011년)이라 정말 머나먼 미래의 일이기 때문에 어차피 그 시점에는 64비트 컴퓨터 문제를 논할 필요가 없다. 태양의 주계열 수명이 대략 80억 년 정도 남았다고 추정하면 이것이 지구의 예상 수명이 되겠는데,[3] 이보다도 수십 배 긴 시간으로 대략 중형(M4V) 적색 왜성의 수명과 맞먹는 수준이다[4]. 혹시나 인류가 살아 있다고 쳐도 지구나 태양계와 전혀 상관없는 먼 행성에서 살면서 128비트 등 시스템을 발전시켜서 쓰고 있던지 아예 본질적으로 현대와는 다른 신 패러다임의 전산 체계로 살아가고 있을 것이다. 참고로, 128비트 정수형은 서기 1970년 1월 1일 UTC 00:00:00으로부터 초[5] 후 시점에 문제가 발생한다. 이는 약 5.39×1030년[6]이다.
아래는 마야 달력의 2012년과 유닉스 시간을 빗댄 만화다.
4. 사례
미래의 일을 계산하는 프로그램에서 이 버그가 발견됐다고 한다. 예를 들어 연금을 관리하는 프로그램을 생각해 보면, 20세인 사람이 40년간 연금을 납입 후 90세까지 연금을 받는다고 하자. 그러면, 이 프로그램은 70년 후 미래의 날짜를 다룰 수 있어야 한다. 즉, 1960년대에 만들어진 프로그램에서도 이 버그가 나타날 수 있다. 유닉스의 역사와 함께 나온 버그인 셈이다.구형 아이폰이나 안드로이드 스마트폰을 가지고 있다면 이 버그를 미리 체험해볼 수 있다. 단, 안드로이드 7.1.2 이하의 기기에서 재현이 되며 안드로이드 8.0 이후부터는 버그 재현이 불가능하다. 만약 안드로이드 7.1.2 버전 이하가 탑재된 기기의 경우 구글 캘린더로 일정을 2038년 1월 19일에 추가해 주면 추가된 날짜가 1970년으로 변한다. 32비트 AP를 탑재한 구형 iOS 기기[7]에서는 아예 2038년 1월 1일 오후 12시 정각 이후의 시점으로 날짜와 시간을 설정할 수 없다. 단 일단 설정 해 놓고 놔두면 시간이 가긴 가는데 2038년 1월 19일 3시 14분 7초 이후가 되면 날짜와 시간이 1901년 12월 14일 5시 16분으로 변한다.#
단, 요즘은 7.1 이하의 일부 기기에서도 정상적으로 날짜 추가가 되는 것으로 보아, 안드로이드 운영체제 자체의 문제가 아닌 구글 캘린더 자체의 문제로 판단되며, 현재는 구글이 캘린더 앱 자체를 수정한 것으로 보인다.[8] 화웨이와 샤오미의 캘린더는 일정을 2037년 12월 31일까지만 설정할 수 있으며, Samsung Experience 8.1 이상 버전의 캘린더와 LG의 캘린더는 2036년 12월 31일까지 설정이 가능하다. 이 버그를 겪어보기 위해서는 시차와 시각을 바꾸는 방법을 이용해야 한다. 대한민국 표준시 UTC+9에서 동부 표준시 UTC-5로 바꾸면 20시에서 당일 6시가 되는데 이 시각을 23시로 바꾸면, 대한민국 표준시 UTC+9에서는 다음날 13시가 되는데 이런 식으로 반복하면 된다. 2038년 1월 19일 12시 이후로는 설정이 불가능하고 분침을 조절해야 한다. 저 시각을 초과하면 오류가 발생했다는 메시지를 볼 수 있다.
iPhone 및 iPad에서도 이 버그를 체험할 수 있다.
iOS 설정의 날짜 수정에 가서 자동날짜설정을 풀고 연도를 2038년 이후로 설정하려고 해도 강제로 2038년으로 되돌려진다.[9]
5. 여담
- MySQL에서 지원하는 TIMESTAMP 형엔 이 버그가 남아 있다. 거기에 DATETIME 등 다른 날짜 형식으로 바꿔도 10000년 이후는 표시할 수 없다. 이는 다른 SQL도 마찬가지라, 이 문제를 해결하려면 입력받은 날짜와 64비트 정수 사이를 변환하는 기능을 구현해야 한다. 다행히 대부분의 SQL에선 64비트 정수를 날짜로 변환하는 기능을 제공하고 있다.
- 2033년 문제와는 무관하다. 이는 음력 윤달에 관한 문제다.
- 팬택의 피처폰의 캘린더 기능에선 1970년 이전의 날짜를 표시할 수 있다.
6. 관련 문서
[1] 대한민국 표준시 UTC+9 기준으로 2038년 1월 19일 12시 14분 07초. 서기 1970년 1월 1일 자정으로부터 초 후, 즉 2147483647초 후(68년 18일 3시간 14분 7초 후)의 시점이다.[2] 9, 223,372, 036, 854, 775, 807초= 922경 3372조 368억 5477만 5807초[3] 80억 년 후 태양이 적색 거성이 되어 지구를 삼키게 된다. 그러나 80억 년 정도 지나고 나서야 인류가 살 수 없는 환경이 되는 게 아니라 서서히 태양 때문에 살지 못하는 세상이 다가오는 것이다. 그래서 앞으로 10억 년도 못 가 태양열이 지금보다 훨씬 강해져서 지구에 생명체가 살 수 없게 된다. 이미 21세기 들어 지구기온 1도 상승만으로도 수많은 동식물이 힘들어하는 것을 보면 10억 년까지 가지도 못할지도 모른다. 어찌됐건 2천억 년이 넘어버린 이 시점에 태양은 백색 왜성이 되어 죽은지 오래일 것이고 나머지 행성들 역시 작살난 지 오래됐을테니 태양계는 없다고 보면 된다.[4] 태양 질량의 1/4 정도 되는 적색 왜성의 예상 수명이 이 정도 된다.[5] 170141183460469231731687303715884105727초=초[6] 수로 환산하면 539양이다. 이는 현재 우주 나이의 4조 배에 다시 1억을 곱해야 하는, 경악스러운 시간이고 이 기간 동안 평행우주가 파멸하고 재탄생하는 것이 여러 번 반복된다고 해도 될 정도다.[7] iPhone 5c, iPad 4, iPod touch(5세대) 및 이전 제품들.[8] 테스트 결과 구글 캘린더 5.7.39 까지는 버그가 발생하지만 5.8부터 버그가 수정되어 더이상 발생하지 않는 것으로 확인됐다.[9] 여담으로 계속 스크롤을 내리다보면 10000년까지 설정이 가능한 것으로 보이지만 결국 다시 2038년으로 되돌려진다.