Unix 타임스탬프란? 날짜 변환 방법과 2038년 문제까지

서버 로그에 1709251200이라는 숫자만 찍혀 있다. 이게 몇 월 며칠 몇 시인지 바로 알 수 있는 사람은 없다. 개발자라면 이 숫자가 Unix 타임스탬프라는 건 알지만, 매번 머리로 계산하는 건 불가능하다.

Unix 타임스탬프란

1970년 1월 1일 00:00:00 UTC부터 경과한 초(second) 수를 하나의 정수로 표현한 것이다. 이 기준 시점을 Epoch라고 부른다.

예시
0 = 1970-01-01 00:00:00 UTC
1000000000 = 2001-09-09 01:46:40 UTC
1709251200 = 2024-03-01 00:00:00 UTC

날짜를 숫자 하나로 표현하기 때문에 비교, 정렬, 저장이 간단하다. "2024-03-01"과 "March 1, 2024"처럼 형식이 다른 날짜를 비교하려면 파싱이 필요하지만, 타임스탬프는 숫자 크기 비교만으로 선후 관계를 알 수 있다.

초 단위와 밀리초 단위

시스템에 따라 단위가 다르다. 이걸 헷갈리면 1970년도 날짜가 나오거나 5만 년 후 날짜가 나온다.

JavaScript의 Date.now()는 밀리초를 반환하고, Python의 time.time()은 초 단위 실수를 반환한다. 언어 간 데이터를 주고받을 때 이 차이를 놓치면 시간이 1000배 어긋난다.

시간대(Timezone) 함정

타임스탬프 자체는 UTC 기준이다. 같은 타임스탬프 1709251200을 변환하면 UTC에서는 "2024-03-01 00:00:00"이지만, 한국(KST = UTC+9)에서는 "2024-03-01 09:00:00"이 된다.

• 서버 로그가 UTC로 기록됐는데 한국 시간으로 읽으면 9시간 차이가 난다
• 프론트엔드에서 사용자의 로컬 시간대로 변환해야 할 때는 별도 처리가 필요하다
• 서머타임(DST)을 쓰는 지역이라면 계절에 따라 시차가 바뀐다

2038년 문제

32비트 정수로 초 단위 타임스탬프를 저장하면 최대값이 2,147,483,647이다. 이 값은 2038년 1월 19일 03:14:07 UTC에 도달한다. 이 시점을 넘기면 숫자가 음수로 돌아가면서 1901년 날짜가 표시되는 오류가 발생할 수 있다.

현재 대부분의 시스템은 64비트로 전환되어 있어서 실제 문제가 될 가능성은 낮지만, 레거시 시스템이나 임베디드 기기 중 일부는 아직 32비트를 쓰고 있다.

빠르게 변환하는 법

로그 분석이나 디버깅 중에 타임스탬프 하나를 확인하려고 코드를 짜는 건 비효율적이다. 타임스탬프 변환기에 숫자를 넣으면 로컬 시간, UTC, ISO 8601 형식으로 동시에 나오고, 반대로 날짜를 입력하면 초·밀리초 타임스탬프를 얻을 수 있다. 현재 타임스탬프가 매초 업데이트되어 표시되기 때문에 API 테스트용 값을 바로 복사해서 쓸 수도 있다.

타임스탬프는 단순한 숫자지만, 단위와 시간대를 혼동하면 버그로 직결된다. 의심될 때 한 번 변환해서 확인하는 게 디버깅 시간을 줄여준다.