2038년, 전 세계 컴퓨터가 멈춘다? (Y2K38 문제)

1999년 말, 전 세계는 'Y2K(밀레니엄 버그)' 공포에 떨었습니다. 연도를 두 자리(99)로만 저장하던 컴퓨터들이 2000년을 1900년으로 인식하여 오작동할 것이라는 우려였죠.

그런데 이와 비슷한, 아니 어쩌면 더 심각할 수 있는 문제가 다가오고 있습니다.

바로 **2038년 문제 (Year 2038 Problem)**입니다.

1. 유닉스 시간 (Unix Time)

컴퓨터는 시간을 어떻게 저장할까요? 대부분의 시스템은 **유닉스 시간(Unix Time)**을 사용합니다.

이는 **1970년 1월 1일 00:00:00 (UTC)**를 기준으로 흐른 시간을 '초(Second)' 단위로 셉니다.

예를 들어, 지금 이 글을 쓰는 순간은 1970년부터 약 17억 초가 지난 시점입니다.

문제는 많은 구형 시스템과 소프트웨어가 이 시간을 저장하기 위해 **32비트 부호 있는 정수(Signed 32-bit Integer)**를 사용한다는 점입니다.

32비트 정수가 표현할 수 있는 최댓값은 2,147,483,647입니다.

이 숫자를 유닉스 시간으로 환산하면 정확히 **2038년 1월 19일 03:14:07 (UTC)**가 됩니다.

이 시각에서 1초가 더 지나면 어떻게 될까요?

숫자는 최댓값을 넘어 오버플로우(Overflow)가 발생하고, 가장 작은 값인 -2,147,483,648로 돌아갑니다.

시스템은 이 시간을 1901년 12월 13일로 인식하게 됩니다.

이로 인해:

해결책은 간단하지만 비용이 듭니다. 시간을 저장하는 변수를 64비트로 확장하는 것입니다.

64비트 정수의 최댓값은 약 922경입니다. 이는 우주의 나이보다도 훨씬 긴 시간(약 2900억 년)을 표현할 수 있으므로 사실상 영원히 안전합니다.

현대적인 64비트 운영체제와 언어들은 이미 64비트 시간을 사용하고 있습니다. 문제는 여전히 현역으로 뛰고 있는 32비트 임베디드 장비들과 레거시 코드들입니다.

2038년은 아직 멀어 보이지만, 장기 계약이나 연금 계산 같은 시스템에서는 이미 문제가 발생하고 있을 수도 있습니다.

개발자라면 자신이 짠 코드에서 날짜를 다루는 변수가 32비트인지 64비트인지 한 번쯤 확인해 보는 것이 좋습니다. 미래의 재앙을 막는 첫걸음이니까요.