Debian, 2038년 문제를 기다리지 않고 전면 64비트 시간 체계로 전환
(theregister.com)- Debian이 Y2K38(Unix Epochalypse) 문제를 사전에 차단하기 위해 차기 버전 Debian 13부터 32비트 아키텍처까지 64비트 time_t 적용을 공식화함
- 기존 32비트 time_t의 한계로 2038년 1월 19일 이후 시간이 1900년으로 되돌아가는 현상이 발생할 수 있어, 이 문제를 더 이상 방치하지 않기로 함
- 64비트 하드웨어는 이미 안전하지만, 임베디드, IoT 등 비용 민감한 32비트 디바이스에 Debian 수요가 남아 있어 사전 대처 필요성이 강조됨
- 전체 6,429개 패키지에 분포한 time_t 타입을 한 번에 ABI 호환성 깨짐을 감수하고 동시 전환하는 대규모 작업이 진행됨
- i386, hurd-i386 등 일부 레거시 지원 아키텍처는 예외로 남겨두되, 새로운 64비트 time_t 기반 x86(i686) 아키텍처 도입 가능성도 언급됨
Debian의 Y2K38 버그 대응: 64비트 시간으로 전환
- Debian은 다가올 Y2K38 또는 Unix Epochalypse 문제를 피하기 위해, 지원되는 가장 오래된 하드웨어 일부를 제외하고 모든 환경에서 64비트 시간으로 전환함
- 이를 통해 2038년 1월 19일 발생 예정인 32비트 signed int 범위 초과로 인한 시간 값 오류를 방지함
Y2K38 및 Unix Epochalypse 문제 배경
- Y2K38 문제는 1970년 1월 1일 이후 경과한 초를 32비트 signed int로 표현하는 Unix 시스템에서, 2038년이 지나면 오버플로우가 발생해 시간이 1900년 등 과거로 잘못 되돌아가는 현상임
- 이는 과거 Y2K(2000년 문제)처럼 짧은 데이터 형식을 선택한 아키텍처적 결정에서 기인함
- Y2K 때는 개발자들의 사전 대응 덕분에 대혼란을 막을 수 있었음
- 64비트 하드웨어용 소프트웨어는 이미 안전하지만, Debian은 임베디드, 저사양, 레거시 환경에서 여전히 널리 쓰임
Debian의 주요 대응
- Debian 13 "Trixie" 릴리즈부터 모든 주요 아키텍처에서 64비트 time_t를 기본값으로 적용함
- 64비트 하드웨어는 이미 안전하나, 32비트 프로세서 기반의 임베디드 기기 및 레거시 하드웨어에서 문제가 잦음
- 이러한 장비는 자동차제어, IoT, TV, 라우터 등 비용 민감하고 대량 출하되는 분야에서 여전히 사용되고 있음
- 많은 신형 장비는 OpenEmbedded, Alpine, Android, Gentoo 등 자체 빌드 리눅스를 사용하나, Debian 기반 임베디드 기기 사용처도 향후 수년간 지속될 전망임
적용 및 변경 사항
- time_t 변수는 관련 코드에 6,429개 패키지에 분산되어 있어 대규모 작업이 필요했음
- 이번 변화는 ABI(애플리케이션 바이너리 인터페이스) 호환성을 깨뜨릴 수 있으므로, 모든 관련 라이브러리와 패키지에서 동시에 조정됨
- 유지보수팀에 따르면, 해당 작업은 완결 및 충분히 테스트가 이루어진 상태임
예외 및 미래 계획
- i386 포트(기존 x86)는 32비트 time_t를 계속 유지하며, 기존 바이너리 실행 호환성의 목적으로 남김
- i686 아키텍처에 64비트 시간 및 최신 ISA(명령어 세트 아키텍처) 적용이 별도로 논의될 수 있음
- hurd-i386 포트는 커널 지원 미비로 전환되지 않으며, 대신 hurd-amd64로 옮기는 방안이 진행 중임
개발자 참고 사항
- 개발자들은 자신의 소프트웨어가 64비트 시간 변수 적용에 따라 깨지지 않는지를 Debian 위키에서 안내하는 방법을 통해 테스트 가능함
- 자세한 내용 및 기술 문서는 Debian wiki에서 제공됨
Hacker News 의견
- Steve Langasek가 생애 마지막 몇 년 동안 이 문제 해결에 집중하며 큰 발전을 이끌었음, 앞으로 64비트 time_t를 볼 때마다 그를 떠올릴 것임
- 좋은 소식 다시 알려줘서 고마움, Steve를 그리워함, Joey는 Debian 활동을 계속하고 있는지 궁금함
- Y2K 문제(2자리 연도 표현 때문에 생긴 2000년 문제)에 대해, 당시 2바이트 절약이 아주 큰 가치가 있었음, 70~90년대 소프트웨어는 빠르게 변화했으므로 5년 이상 사용될 거라 기대하지 않았음, 너무 폄하하는 관점 같음
- 지금도 2자리 연도 많이 사용 중임, 예를 들어 신용카드 만료일(mm/yy)은 짧게 쓰기 편하므로 2자리 연도 표현을 씀, 카드 수명엔 충분하지만 2100년엔 변환 문제가 생길 수 있음, Y2K 대부분은 UI 문제에서 비롯됨(두 글자 text field, +1900 hardcode 등), 직접 겪은 Y2K 버그는 인터넷 포럼이 1999년에서 19100년으로 넘어간 것(단순 출력 오류), Y2K는 COBOL만의 문제가 아니었음
- 이런 경우엔 ‘성급한 최적화’가 오히려 도움이 되었을 것임, 1900년에 0인 단순 int값으로 날짜를 표현했어도 더 많은 바이트를 절약할 수 있었음, 3바이트로 1900년~약 44,000일까지, 2바이트로도 ~2070년까지 커버 가능함
- 사람들이 혼동하는 지점은 2바이트 추가가 아니라 2문자를 추가해야 했다는 것임, COBOL엔 숫자든 데이터든 문자 크기만큼 고정 width로 할당해서, 4자리 연도를 넣으려면 4개 문자 위치가 필요했음, 이런 필드 사이즈는 데이터 접근, UI, 배치 파일, 중간 파일, 전달 파일 등 전체 프로그램에 하드코딩 됨
- Y2K 직전에 대형은행 주가 폭락을 기대하고 put 옵션을 대량 매수한 지인들이 있었으나, 실제로는 큰 일은 거의 없었음
- 80년대 후반 COBOL로 일하면서 1자리 연도만 저장하는 프로그램 경험이 있음, 구조 설명 들었을 때는 이상하다고 생각했지만, 기록은 4년마다 자동 삭제되어서 사용상 문제 없었음, 항상 어떤 연도인지 명확했음
- 64비트 time_t가 Epochalypse를 해결하겠지만, 모든 시스템이 단순히 64비트 초로 가는 건 아님, ext4는 이미 30비트 소수점 해상도(나노초 수준)와 34비트 초 해상도로 바뀌었지만, 역시 수백 년 뒤엔 문제 재발 예정임, 언젠가 64비트 초+64비트 소수점의 128비트 타임스탬프로 정착하게 될 것이라 예상함, 그러면 인류 역사상 예측가능한 미래는 모두 커버할 수 있음
- 64비트 초 시간은 약 5850억 년에 해당함, WolframAlpha 계산 결과
- 64비트 소수점 해상도로도 부족할 수 있음, 플랑크 타임에 가까워지려면 144비트까지 써야 함
- ext4 타임스탬프 궁금했는데, zfs와 btrfs 파일시스템은 시간 처리 어떻게 하는지도 호기심 생김, btrfs는 아마 64비트 쓸 것 같고, zfs도(ext4랑 헷갈림) 비슷할 거라 기대함
- Debian이 Y2K38, 즉 Unix Epochalypse 문제를 해결한다고 하는데, 사실은 i386을 제외한 모든 32비트 포트에서 time64_t로 이미 전환 완료함, i386만 기존 바이너리 호환성 때문에 예외이고, 나머지는 m68k 포함 모두 변경함, 직접 m68k, powerpc, sh4, hppa를 전환함
- time_t는 변수(variable)가 아니라 데이터 타입임
- 기사에서 나온 내용은 Debian 위키를 바탕으로 한 것임, 원문엔 “time_t가 정말 여기저기 등장함. 35,960개 패키지 중 6,429개 소스코드에 등장함. time_t를 포함한 구조체를 ABI로 노출하는 패키지는 ABI 전체를 동시 마이그레이션해야 함”이라고 명시되어 있음, 위키는 기사보다 더 명확히 설명했음
- “For everything”은 armel, armhf, hppa, m68k, powerpc, sh4가 대상이고 i386은 아니라고 명시, i386은 미래가 없고 기존 바이너리/동적 라이브러리 구동이 주목적이라 깨지길 원하지 않음
- “Debian 13 Trixie 출시 이후 적용 예정”은 실제로 Trixie에 포함된다는 의미임
- 커맨드라인 길이제한도 무제한/동적으로 바꿔주면 좋겠음, 96GB 메모리인데도 “argument list too long” 에러가 자주 나서 불편함
- 커널을 재컴파일해서 명령줄 길이(약 10만자) 제한을 풀 수 있음, stackoverflow 참고, 근본적인 문제 해결 같지는 않음, 4k JPEG만큼 긴 인자를 어디에 쓸지 의문임
- RLIMIT_STACK 값을 늘리면 됨, 예를 들어
ulimit -s 4000
이면 4MB 스택임, 더 크게 하려면 /etc/security/limits.conf를 수정하고 재로그인 필요함 - Electron에 패킹하고 http post json 요청으로 넘기면 되지 않을까 싶음
- MAX_ARG_STRLEN를 재정의해서 커널 재컴파일하면 됨, 페이지 사이즈가 더 큰 머신(예: 64k 페이지사이즈인 RHEL Arm 커널) 사용도 방법임, 하지만 명령버퍼 대신 파이프를 써서 프로세스 간에 데이터 넘기는 게 훨씬 쉬움
- 파일 경로 제한도 마찬가지 문제임, 일부 빌드시스템(Debian + python + dh-virtualenv 등)은 경로가 매우 길어질 수 있는데 그냥 허용하는 게 더 편함
- 64비트로 바꿔도 언젠가는 한계가 올 것임, 292277026596년 12월 4일 오후 3시 30분 7초(UTC)에 인류는 뭘 할지 궁금함
- 아마도 그때쯤엔 ipv6 완전 도입 100주년을 축하할 것임
- 50억 년 이내엔 태양이 적색거성 돼서 지구 표면이 전부 증발할 것임
- 그쯤 되면 더 나은 달력 시스템으로 옮겨갔으면 함, 물론 타임스탬프 문제는 여전히 남겠지만
- 128비트 타임으로 가면 될 것임
- RFC 2550(Y10K & beyond) 적용 가능할 듯, 1999년 4월 1일 발표됨
- OpenBSD 5.5가 동일한 변경을 적용한 지 벌써 11년이나 지났음, OpenBSD 5.5 릴리즈 노트
- 모두를 이긴 케이스임, 90년대에 OS/2 32비트 API가 64비트 시간을 반환하는 걸 발견하고, 직접 64비트 time_t로 C++ 표준 라이브러리를 작성해 사용함
- 약간 다른 이야기지만, 이런 시기에 Linux 대신 OpenBSD로 서버를 바꾸고 싶은 마음이 생김
- OpenBSD는 호환성에 덜 신경 써도 되고, 사용자 수도 훨씬 적어서 변화 시 버그나 엣지 케이스 가능성이 낮아짐
- “Debian은 이제 충분히 완성 및 테스트가 됐으므로 Trixie 출시 이후 전환될 예정”이라고 하면 Trixie에는 적용 안 되는 것인지 궁금함
- Trixie 릴리즈 노트엔 적용된다고 나와 있음, Trixie 릴리즈 노트
- Y2K38을 Unix Epochalypse라 부르는 건 처음 듣는데, 귀엽긴 해서 퍼질 수도 있을 듯함
- 위키백과 Year 2038 Problem에도 해당 이름이 나옴, 2017년부터 우스갯소리로 쓰이며 퍼짐
- epochalypse-project.org 프로젝트도 있음
- “it’s kind of fetch”라는 표현에 Mean Girls 영화 드립(?)이 보임
- Epochalypse까지 약 12년 5개월 22일 13시간 22분 남음