2038년 문제(Y2K38) 설명

2038년 문제란?

Unix 타임스탬프는 전통적으로 1970년 1월 1일 00:00:00 UTC 이후의 초를 세는 32비트 부호 있는 정수로 저장됩니다. 32비트 부호 있는 정수의 최댓값은 2,147,483,647이며, 이는 2038년 1월 19일 03:14:07 UTC에 해당합니다. 그 1초 뒤 정수는 -2,147,483,648로 오버플로됩니다. Unix 타임스탬프로 해석하면 이 음수 값은 1901년 12월 13일에 해당하여, 영향을 받는 시스템을 약 137년 과거로 보냅니다.

오버플로 값

• 2^31 − 1 = 2,147,483,647 (32비트 부호 있는 정수 최댓값)
• 2,147,483,647을 날짜로 = 2038년 1월 19일 03:14:07 UTC
• 2,147,483,647 + 1은 −2,147,483,648로 오버플로(가장 작은 32비트 값)
• −2,147,483,648을 날짜로 = 1901년 12월 13일 20:45:52 UTC

어떤 시스템이 위험한가?

이 문제는 타임스탬프를 32비트 부호 있는 정수로 저장하는 시스템에 영향을 줍니다:

• 32비트 time_t를 쓰는 임베디드 시스템과 마이크로컨트롤러
• 타임스탬프에 time_t나 int를 쓰며 32비트 대상으로 컴파일된 레거시 C/C++ 코드
• 아직 운영 중인 32비트 하드웨어의 오래된 Linux 커널(5.6 이전)
• MySQL TIMESTAMP 열 — 2038-01-19까지로 제한; 대신 DATETIME을 사용
• 타임스탬프를 32비트 값으로 인코딩하는 일부 네트워크 프로토콜과 파일 형식
• 수십 년 수명을 가진 산업 제어 시스템과 IoT 기기의 펌웨어

어떤 시스템이 안전한가?

대부분의 현대 코드와 인프라는 이미 영향을 받지 않습니다:

• 모든 64비트 OS — Linux(glibc 2.34+는 32비트 하드웨어도 수정), macOS, Windows
• Python — 타임스탬프가 64비트 부동소수점을 써서 서기 2억 9200만 년을 훨씬 넘어 안전
• JavaScript — Date가 64비트 IEEE 754 부동소수점을 써서 서기 275,760년까지 안전
• Go와 Rust — 내부적으로 int64를 써서 수십억 년 안전
• Java — java.time.Instant가 long(64비트)을 써서 서기 약 2억 9200만 년까지 안전
• PostgreSQL TIMESTAMP — 2038년 이후 날짜도 올바르게 저장
• MySQL DATETIME — 범위 1000-01-01~9999-12-31, 영향 없음

2038년 문제 FAQ

2038년 문제란?

2038년 문제(Y2K38)는 Unix 타임스탬프를 저장하는 데 32비트 부호 있는 정수를 쓰는 시스템이 2038년 1월 19일 03:14:07 UTC에 오버플로되는 버그입니다. 32비트 부호 있는 정수의 최댓값은 2,147,483,647입니다. 1초 뒤 정수는 -2,147,483,648로 넘어가며, 이는 1901년 12월 13일에 해당합니다.

2038년 1월 19일의 Unix 타임스탬프는?

2038년 1월 19일 03:14:07 UTC의 Unix 타임스탬프는 2,147,483,647로, 32비트 부호 있는 정수의 최댓값(2^31 - 1)입니다. 32비트 시스템에서 2038년 오버플로가 일어나는 정확한 순간입니다.

Y2K38은 Y2K와 같은가?

아닙니다. Y2K(2000년 문제)는 연도를 두 자리로 저장한 프로그램 때문이었습니다. Y2K38은 Unix 타임스탬프를 32비트 부호 있는 정수로 저장해 2038년에 오버플로되기 때문입니다. 원인도, 영향을 받는 시스템도 다릅니다.

2038년에 인터넷이 멈출까?

크게 멈추지는 않을 것입니다. 인터넷 인프라 대부분은 이미 64비트 시스템으로 이전했습니다. 위험은 임베디드 시스템, 오래된 IoT 기기, 수십 년간 업데이트되지 않은 소프트웨어에 집중됩니다. 현대 운영체제, 언어, 데이터베이스는 이미 안전합니다.