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년 오버플로가 일어나는 정확한 순간입니다.

2038년 문제는 어떻게 고치나요?

시간을 32비트가 아니라 부호 있는 64비트 정수로 저장하세요. 64비트 time_t를 사용하고(glibc 2.34+에서는 32비트 코드를 -D_TIME_BITS=64로 빌드), 에포크 열에는 INT 대신 BIGINT, MySQL TIMESTAMP 대신 DATETIME을 씁니다. 부호 있는 64비트 시간 값은 약 2,920억 년 동안 오버플로하지 않습니다.

Y2K38은 Y2K와 같은가요?

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

2106년 문제란 무엇인가요?

2106년은 부호 없는 32비트 타임스탬프에서 일어나는 같은 오버플로로, 2106년 2월 7일 06:28:15 UTC에 소진됩니다. 부호 있는에서 부호 없는 32비트로 바꾸면 68년을 더 벌지만 진짜 해결책은 아닙니다. 64비트 시간이 해결책입니다.

2038년에 인터넷이 무너지나요?

크게는 아마 아닙니다. 대부분의 인터넷 인프라는 이미 64비트 시스템으로 이전했습니다. 위험은 임베디드 시스템, 오래된 IoT 기기, 수십 년간 갱신되지 않은 소프트웨어에 집중되어 있습니다. 현대 운영체제, 프로그래밍 언어, 데이터베이스는 이미 안전합니다.

Year 2038 Problem

2038년 문제(Y2K38) 설명

2038년 1월 19일 03:14:07 UTC에 Unix 타임스탬프 2,147,483,647 — 부호 있는 32비트 정수의 최댓값 — 이 오버플로하여 1901년 날짜로 되돌아갑니다. 그것이 무슨 뜻인지, 어떤 시스템이 영향을 받는지, 64비트 time_t 수정이 어떻게 작동하는지, 그리고 자신의 코드를 테스트하는 방법을 설명합니다.

한 줄로 보는 오버플로

부호 있는 32비트 정수는 최대 2,147,483,647까지입니다. Unix 초로 저장하면 그 값은 2038-01-19 03:14:07 UTC이며, 1초 뒤 -2,147,483,648로 되돌아가 1901년 12월 13일로 읽힙니다. 여전히 시간을 부호 있는 32비트 정수로 보관하는 시스템은 그 순간 137년 과거로 점프합니다. 해결책은 한 단어, 64비트입니다. 아래 표는 어떤 저장 형식이 영향을 받고 어떤 것이 이미 안전한지 보여 줍니다.

저장 형식	오버플로 시점 / 최대 날짜	2038년 이후 안전?
부호 있는 32비트 time_t / SQL INT	2038-01-19 03:14:07 UTC	아니요
MySQL TIMESTAMP	2038-01-19 03:14:07 UTC	아니요 — DATETIME 사용
부호 없는 32비트	2106-02-07 06:28:15 UTC	68년을 벌지만 해결책 아님
부호 있는 64비트 time_t / SQL BIGINT	약 2,920억 년	예
64비트 부동소수점(JavaScript, Python)	서기 275,760년	예
MySQL DATETIME(패킹된 필드)	서기 9999년	예

The Open Group — Seconds Since the Epoch (time_t)

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
오버플로의 현지 시각은 다양: 1월 18일 22:14:07 EST, 1월 19일 14:14:07 JST

어떤 시스템이 위험한가

이 문제는 타임스탬프를 부호 있는 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, 영향 없음

MySQL TIMESTAMP과 2038년 상한

MySQL에는 두 가지 주요 날짜·시간 열 형식이 있고, 2038년 부근에서 매우 다르게 동작합니다.

TIMESTAMP은 내부적으로 부호 있는 32비트 Unix 정수로 저장됨 — 2038-01-19 03:14:07 UTC에 오버플로
DATETIME은 패킹된 Y/M/D h/m/s 필드로 저장되어 서기 9999년까지 지원 — 2038년 이후가 될 수 있는 날짜에 사용
TIMESTAMP은 서버의 세션 시간대로/에서 암묵적으로 변환도 함; DATETIME은 값을 그대로 저장
원시 에포크 열에는 값 자체가 오버플로하지 않도록 INT가 아니라 BIGINT를 저장
기존 스키마 점검: SELECT TABLE_NAME, COLUMN_NAME FROM information_schema.COLUMNS WHERE DATA_TYPE = "timestamp"

데이터베이스에 Unix 타임스탬프 저장하기(INT vs BIGINT)

임베디드 Linux와 32비트 time_t

남아 있는 가장 큰 Y2038 위험은 수명이 긴 임베디드 시스템에 있습니다. 라우터, 산업용 컨트롤러, 자동차 ECU, 스마트 미터, 그리고 32비트 커널로 출하되어 2038년 이후에도 운용될 수 있는 IoT 기기입니다. C 라이브러리와 모든 자체 바이너리 프로토콜 둘 다 64비트 클린이어야 합니다.

glibc는 빌드 매크로 -D_TIME_BITS=64로 32비트 ABI에 64비트 time_t를 도입(glibc 2.34+)
musl libc는 버전 1.2.0(2020)부터 기본으로 64비트 time_t
Debian, Ubuntu, OpenWrt는 32비트 포트를 모두 64비트 time_t로 이전 완료
파일 시스템 타임스탬프는 별개의 문제: ext2/ext3는 32비트 시간 사용, ext4는 256바이트 이상 inode에서 64비트 지원
2026년 이후에도 출하되는 하드웨어는 C 라이브러리와 모든 와이어 형식이 64비트인지 확인할 것

GNU Gnulib — Avoiding the year 2038 problem

Y2038 수정 및 테스트 방법

수정은 늘 같습니다 — 시간을 64비트로 넓히는 것 — 하지만 타임스탬프를 저장하거나 전송하는 모든 계층에 적용해야 합니다. C 라이브러리, 데이터베이스 열, 그리고 모든 바이너리 프로토콜이나 파일 형식입니다. 문제를 찾는 가장 빠른 방법은 테스트 환경에서 시계를 경계 너머로 옮기고 1901년에 떨어지는 날짜를 지켜보는 것입니다.

glibc 2.34+에서 32비트 코드를 -D_TIME_BITS=64(및 -D_FILE_OFFSET_BITS=64)로 컴파일
원시 Unix 초나 밀리초를 저장하는 모든 열에는 INT가 아니라 BIGINT를 사용
2038년을 넘을 수 있는 날짜에는 MySQL TIMESTAMP보다 DATETIME이나 TIMESTAMPTZ를 선호
테스트에서 시스템 또는 컨테이너 시계를 2038-01-19T03:14:08Z로 설정하고 날짜가 2038년에 머무는지 확인
와이어 형식과 파일 헤더를 점검 — 프로토콜 필드가 32비트면 64비트 OS도 소용없음

man time(2) — time_t 시스템 콜 레퍼런스

롤오버	날짜	원인
Y2K	2000-01-01	두 자리 연도 저장
GPS 주 롤오버	2019-04-06	10비트 GPS 주 카운터
NTP 에포크 롤오버	2036-02-07	1900년 이후 부호 없는 32비트 초
2038년(Y2K38)	2038-01-19	1970년 이후 부호 있는 32비트 초
2106년	2106-02-07	1970년 이후 부호 없는 32비트 초

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년 오버플로가 일어나는 정확한 순간입니다.
2038년 문제는 어떻게 고치나요?: 시간을 32비트가 아니라 부호 있는 64비트 정수로 저장하세요. 64비트 time_t를 사용하고(glibc 2.34+에서는 32비트 코드를 -D_TIME_BITS=64로 빌드), 에포크 열에는 INT 대신 BIGINT, MySQL TIMESTAMP 대신 DATETIME을 씁니다. 부호 있는 64비트 시간 값은 약 2,920억 년 동안 오버플로하지 않습니다.
Y2K38은 Y2K와 같은가요?: 아니요. Y2K(2000년 문제)는 프로그램이 연도를 두 자리로 저장한 데서 비롯됐습니다. Y2K38은 Unix 타임스탬프를 부호 있는 32비트 정수로 저장해 2038년에 오버플로하는 데서 비롯됩니다. 원인도 영향을 받는 시스템도 다릅니다.
2106년 문제란 무엇인가요?: 2106년은 부호 없는 32비트 타임스탬프에서 일어나는 같은 오버플로로, 2106년 2월 7일 06:28:15 UTC에 소진됩니다. 부호 있는에서 부호 없는 32비트로 바꾸면 68년을 더 벌지만 진짜 해결책은 아닙니다. 64비트 시간이 해결책입니다.
2038년에 인터넷이 무너지나요?: 크게는 아마 아닙니다. 대부분의 인터넷 인프라는 이미 64비트 시스템으로 이전했습니다. 위험은 임베디드 시스템, 오래된 IoT 기기, 수십 년간 갱신되지 않은 소프트웨어에 집중되어 있습니다. 현대 운영체제, 프로그래밍 언어, 데이터베이스는 이미 안전합니다.