Unix Timestamp 초 단위와 밀리초 단위 차이

왜 숫자로 시간을 저장하는가

Unix 타임스탬프는 1970년 1월 1일 0시 0분 0초 UTC부터 흐른 시간을 초 단위 정수로 표현한 값입니다. 이 기준 시각을 에포크(epoch)라고 부릅니다.

사람이 읽는 날짜 문자열 대신 숫자를 쓰는 이유는 명확합니다. 문자열은 표기 방식이 제각각이고(2024-05-08, 05/08/2024, 8 May 2024), 타임존과 서머타임 정보가 붙어 다니며, 크기 비교와 시간 차이 계산이 번거롭습니다. 반면 정수는 어디서나 같은 의미이고 비교와 연산이 단순합니다.

그래서 데이터베이스, 로그, API, 캐시 만료 시각 등 시스템 내부에서 시각을 다룰 때는 대부분 타임스탬프를 사용하고, 화면에 보여줄 때만 사람이 읽는 형식으로 변환합니다.

초와 밀리초를 구분하는 법

가장 자주 겪는 혼란이 단위입니다. 언어와 플랫폼마다 기본 단위가 다릅니다.

초 단위를 쓰는 쪽은 Unix 계열 시스템, PHP의 time(), 대부분의 데이터베이스, JWT의 exp와 iat입니다. 밀리초 단위를 쓰는 쪽은 JavaScript의 Date.now(), Java의 System.currentTimeMillis(), 여러 로그 수집 도구입니다.

구분하는 가장 빠른 방법은 자릿수입니다. 현재 시점 기준으로 초 단위는 10자리, 밀리초 단위는 13자리입니다. 값이 1000배 차이 나기 때문입니다.

단위를 잘못 해석하면 증상이 뚜렷합니다. 밀리초 값을 초로 읽으면 수만 년 뒤의 날짜가 나오고, 초 값을 밀리초로 읽으면 1970년 1월 초로 표시됩니다. 날짜가 터무니없이 나온다면 가장 먼저 자릿수를 세어 보십시오.

타임존이 만드는 장애 분석 실수

타임스탬프 자체는 타임존과 무관한 절대값입니다. 하지만 사람이 읽는 시각으로 바꾸는 순간 타임존이 개입합니다.

서버는 UTC로 동작하는 경우가 많고 개발자의 로컬 환경은 한국 시간(UTC+9)입니다. 같은 타임스탬프가 두 환경에서 9시간 차이로 표시됩니다. 장애 보고서에는 오후 3시에 문제가 발생했다고 적혀 있는데 서버 로그에서 오전 6시 구간을 봐야 하는 상황이 생기는 것입니다.

이 혼란을 줄이려면 로그에 타임존을 명시하거나 ISO 8601 형식(2024-05-08T08:00:00Z)처럼 타임존이 포함된 표기를 쓰는 것이 좋습니다. 값을 저장할 때는 UTC 기준 타임스탬프로 통일하고 표시할 때만 변환하는 원칙을 지키면 대부분의 문제가 사라집니다.

2038년 문제

타임스탬프를 32비트 부호 있는 정수로 저장하면 표현할 수 있는 최대값이 2147483647입니다. 이 값은 2038년 1월 19일에 도달합니다. 그 이후에는 값이 넘쳐서 음수가 되고 1901년으로 해석됩니다.

현대적인 환경은 대부분 64비트 정수를 사용하므로 문제가 없습니다. 하지만 오래된 임베디드 시스템, 32비트로 컴파일된 레거시 애플리케이션, 컬럼 타입을 32비트 정수로 정의한 데이터베이스 테이블에는 여전히 위험이 남아 있습니다.

만료일이나 예약 시각처럼 미래 시점을 저장하는 필드는 이미 지금도 영향을 받을 수 있습니다. 2038년 이후의 날짜를 저장해야 하는 기능이 있다면 컬럼 타입을 먼저 확인하십시오.