[호기심] 1970년과 2038년: 2038년은 새로운 Y2K가 될까?

쏟아지는 AI 소식 때문에 피곤할 때도 많지만, 저는 AI와 대화함으로써 지적 호기심을 해소할 수 있는 시대인 게 참 좋습니다.

오늘은 두 가지 트리거가 있었습니다.

1. 새벽에 강규영님이 페이스북에서 '과정에 담긴 가치의 증강'이라는 흥미로운 글을 올렸다고 하셔서 읽다가, 모든 날짜가 1970년 1월 1일로 되어있는 걸 발견하고 댓글로 제보
2. 저녁때 한준구님이 페이스북에서 체르노빌 바이러스 얘기를 하셔서 옛날 기억을 돌이켜보다가, Y2K도 댓글에서 언급하셔서 문득 '날짜 단위가 바뀔 때'에 대한 흥미가 생김

그래서 불현듯 떠오른 호기심은 이런 것들이었어요.

• 왜 UTC는 1970년 1월 1일이 기준이 되었을까?
• 그 이전 날짜와 시간을 UTC는 어떻게 표현하지?
• UTC에서는 Y2K 같은 문제가 생길 수 없나?

요즘은 이러한 호기심을 해소할 때, 더 정확히 말하면 나중에 다시 자세히 안 봐도 괜찮을 법한 주제로 빠르게 답변을 얻고 싶을 때 (그리고 교차검증은 귀찮을 때) 주로 Grok을 쓰게 되더군요. 오늘도 유익한 대화를 나눠서 기분이 좋네요. 아래는 위 3개 질문에 대한 Grok의 요약입니다.

왜 UTC는 1970년 1월 1일이 기준이 되었을까?

Unix 타임스탬프가 1970년 1월 1일 00:00:00 UTC를 기준(에포크)으로 사용하는 이유는 1970년대 초 벨 연구소에서 Unix를 개발하던 켄 톰슨과 데니스 리치가 실용적이고 기억하기 쉬운 날짜를 선택했기 때문입니다. 당시 Unix가 개발된 시점(1969~1970년)에 가까운 이 날짜는 32비트 시스템에서 약 68년을 커버할 수 있어 충분히 유용했으며, UTC가 국제 표준으로 자리 잡던 시기와 맞물려 글로벌 호환성을 제공했습니다; 데니스 리치는 인터뷰에서 이를 “편리한 선택”이라고 언급하며, 깊은 철학보다는 기술적 필요에 따른 결정이었다고 밝혔습니다.

그 이전 날짜와 시간을 UTC는 어떻게 표현하지?

1970년 1월 1일 이전의 날짜와 시간은 Unix 타임스탬프에서 음수 값으로 표현됩니다. 예를 들어, 1965년 1월 1일은 약 -157,680,000초로 계산되며, 이는 에포크(1970년 1월 1일)에서 얼마나 이전인지 초 단위로 나타낸 것입니다; 대부분의 현대 프로그래밍 언어(Python, JavaScript 등)와 64비트 시스템은 이를 문제없이 처리하지만, 32비트 시스템에서는 1901년 12월 13일 이전으로 돌아가면 오버플로우가 발생할 수 있어 주의가 필요합니다.

UTC에서는 Y2K 같은 문제가 생길 수 없나?

2038년 문제(Y2K38)는 32비트 Unix 타임스탬프가 2038년 1월 19일 03:14:07 UTC에 최대값(2,147,483,647초)을 초과해 음수로 오버플로우되거나 1970년으로 리셋되는 잠재적 문제로, Y2K와 유사하지만 영향 범위는 더 제한적입니다. 현대의 64비트 시스템과 소프트웨어는 이미 이 문제를 해결했으며, 13년이라는 준비 시간과 Y2K의 성공적 대응 사례로 볼 때 대규모 혼란 가능성은 낮지만, 구형 임베디드 시스템이나 레거시 소프트웨어에서는 여전히 주의가 필요합니다.

혹시 전체 대화가 궁금하시면 이 링크로 가보시길!