Unix 타임스탬프 다루기: 에포크 시간 쉽게

API 응답이나 데이터베이스 행을 열면 날짜가 1751760000 같은 평범한 숫자로 저장돼 있는 걸 흔히 봅니다. 그것이 Unix 타임스탬프이며, 엄청나게 많은 소프트웨어가 이렇게 시간을 추적합니다. 이 가이드는 그 숫자가 무엇을 뜻하는지, 왜 컴퓨터가 이렇게 시간을 세는지, 그리고 함정 — 초 vs. 밀리초, 시간대, 2038년 문제 — 을 설명합니다.

Unix 타임스탬프란 무엇인가

Unix 타임스탬프는 에포크(epoch)라 불리는 고정된 순간 — 1970년 1월 1일 00:00:00 UTC — 이후 흐른 초 수입니다. 그래서 0은 에포크 자체이고, 60은 그로부터 1분 뒤, 1751760000은 2025년의 한 순간입니다. 그저 초를 세는 누계입니다.

왜 1970년부터 초를 세나?

시간을 하나의 정수로 표현하는 것은 컴퓨터에 엄청나게 편리합니다. 두 순간을 비교하는 것은 두 숫자를 비교하는 일이 되고, 그 사이 간격을 구하는 것은 뺄셈, 이벤트를 정렬하는 것은 정수 정렬일 뿐입니다 — 달력·월·윤년·시간대를 따질 필요가 없습니다. 1970년이라는 시작점은 Unix 운영체제 초창기의 역사적 선택이 그대로 굳어진 것입니다.

초 vs. 밀리초 함정

거의 모두가 적어도 한 번은 겪는 실수입니다. Unix 타임스탬프는 고전적으로 초 단위지만, 많은 시스템 — 특히 JavaScript — 은 밀리초(1000분의 1초)를 씁니다. 둘은 1000배 차이입니다:

초:      1751760000
밀리초:  1751760000000

밀리초를 기대하는 곳에 초 값을 넣으면 날짜가 1970년에 떨어지고, 반대로 하면 수만 년 미래로 갑니다. 빠른 점검: 현재 타임스탬프는 초로는 10자리, 밀리초로는 13자리입니다. 변환된 날짜가 터무니없어 보이면 거의 언제나 이것 때문입니다.

시간대와 UTC

Unix 타임스탬프의 핵심 강점: 숫자 자체가 항상 UTC입니다. 그것은 지구상 모두에게 동일한, 하나의 정확한 순간을 나타냅니다. 타임스탬프 1751760000은 단 하나의 순간이며, 그것이 런던에서 오후 4시로 보이든 뉴욕에서 오전 11시로 보이든 그건 마지막에 적용되는 순수한 표시 선택일 뿐입니다. 시간을 UTC 타임스탬프로 저장하고 보여줄 때만 지역 시간으로 변환하면 시간대 버그 한 부류를 통째로 피할 수 있습니다. 같은 순간을 여러 지역에서 보려면 시간대 변환기가 제격입니다.

사람 날짜와 상호 변환

양방향이 끊임없이 필요합니다 — 로그를 디버깅하려고 타임스탬프를 읽을 수 있는 날짜로, API를 조회하려고 날짜를 타임스탬프로. 우리 Unix 타임스탬프 변환기는 둘 다 즉시 하고 결과를 당신의 지역 시간과 UTC로 보여줍니다. 대신 두 날짜 사이 간격을 재려면 날짜 차이 계산기가 바로 처리합니다.

2038년 문제

오래된 시스템은 타임스탬프를 부호 있는 32비트 정수로 저장하는데, 이는 2,147,483,647까지만 셀 수 있습니다. 그 한계는 2038년 1월 19일 03:14:07 UTC에 도달하며 — 1초 뒤 카운터가 넘쳐 음수로 되돌아가, 날짜를 1901년으로 던져 버립니다. Y2K와 같은 부류의 버그입니다. 해법은 이미 널리 퍼져 있습니다: 64비트 정수를 쓰면 한계가 약 2920억 년 뒤로 밀립니다. 대부분의 현대 소프트웨어는 괜찮지만, 레거시 시스템을 건드릴 때 알아두면 좋습니다.

빠른 참조

• Unix 타임스탬프 = 1970년 1월 1일 UTC 이후의 초.
• 10자리 = 초; 13자리 = 밀리초.
• 값은 항상 UTC — 시간대는 표시할 때만 적용.
• 32비트 저장은 2038년에 깨짐; 64비트는 안 그럼.