Unix 타임스탬프 이해하기 - epoch 시간·timezone·변환 가이드

Unix 타임스탬프란?

Unix 타임스탬프는 1970년 1월 1일 00:00:00 UTC를 기준으로 흐른 초의 수로 시간을 표현하는 방식입니다. epoch time, POSIX time이라고도 불러요. 예를 들어 1700000000은 2023년 11월 14일 22:13:20 UTC를 의미합니다. 사람에게는 직관적이지 않지만 기계에게는 매우 편한 표현이에요. 정수 하나로 시간을 표현하니 비교·정렬·연산이 단순하고, 타임존 정보가 빠져 있어 표준화가 쉽습니다. 거의 모든 백엔드 언어(Java, Python, JavaScript, Go, C)가 시간을 내부적으로 epoch로 다루며, 데이터베이스의 timestamp 컬럼, 로그 파일의 시간, 캐시 만료 시간(TTL) 같은 곳에서 항상 만나게 돼요.

왜 1970년 1월 1일인가?

이 기준점은 Unix 운영체제가 처음 만들어진 시점과 관련이 있습니다. 1969년 Bell 연구소에서 Unix가 설계됐고, 시간을 정수로 다루기 위해 적당한 출발점이 필요했어요. 너무 옛날(예: AD 1년)이면 정수 범위를 빨리 소진하고, 너무 최근이면 과거 시간 표현이 어려워, 1970년 1월 1일이 기술적인 절충점으로 채택됐습니다. 이후 POSIX 표준에 그대로 들어가 거의 모든 시스템의 기본이 됐어요. 기준 시점 자체에 큰 의미가 있는 건 아니고, 전 세계가 이 시점을 0으로 합의했다는 게 핵심입니다.

초·밀리초·마이크로초·나노초 - 단위 구분

epoch는 기본적으로 초 단위지만, 정확도가 더 필요한 환경에서는 밀리초·마이크로초·나노초도 자주 쓰입니다.

• 초(second): 10자리 숫자 — 1700000000. C, Go, PHP, Unix 시스템 콜에서 기본.
• 밀리초(ms): 13자리 숫자 — 1700000000000. JavaScript의 Date.now(), Java의 System.currentTimeMillis() 기본.
• 마이크로초: 16자리 — 일부 DB 컬럼, Python의 datetime.
• 나노초(ns): 19자리 — Go의 time.Now().UnixNano(), Linux 커널.

자릿수만 보면 단위를 추정할 수 있어요. 10자리 = 초, 13자리 = 밀리초처럼이요. JavaScript에서 Python 백엔드의 epoch(초)를 받았는데 그대로 new Date()에 넣으면 1970년이 나오는 흔한 실수가 있어요. 이때는 초 × 1000을 해서 밀리초로 변환해야 합니다.

타임존은 타임스탬프와 무관하다

가장 자주 헷갈리는 부분입니다. Unix 타임스탬프 자체에는 타임존이 없어요. 1700000000은 어디서 보든 같은 순간을 가리키고, 한국 시간 1700000000이나 UTC 1700000000 같은 건 존재하지 않습니다. 타임존은 그 epoch를 사람이 읽는 형식(YYYY-MM-DD HH:mm:ss)으로 변환할 때만 의미가 있어요. 예를 들어 epoch 1700000000은 UTC로는 2023-11-14 22:13:20이고, 한국 시간(KST, UTC+9)으로는 2023-11-15 07:13:20입니다. 같은 epoch입니다. DB에는 epoch 또는 UTC로 저장하고, 표시할 때 사용자 타임존으로 변환하는 게 표준 패턴이에요. 한국 시각 그대로 DB에 넣으면 글로벌 서비스로 확장할 때 큰 문제가 됩니다.

자주 만나는 변환 시나리오

실무에서 마주하는 변환은 대체로 다음 몇 가지예요.

• 사람이 읽는 시간 → epoch: API에 2026-04-27 15:30:00 KST를 보내야 할 때. 보통 ISO 8601 문자열(2026-04-27T15:30:00+09:00)로 변환 후 백엔드에서 파싱.
• epoch → 사람이 읽는 시간: 로그·DB의 1745000000을 사람에게 보여줄 때. 사용자 타임존으로 변환.
• JS와 Python 간: JS는 ms 단위, Python은 초 단위가 기본. × 1000 또는 ÷ 1000 변환 필요.
• 다른 시스템과 비교: 두 시간의 차이를 계산할 때, 둘 다 epoch면 단순히 빼면 됩니다.

표준 라이브러리를 활용하면 거의 모든 변환이 한 줄로 끝나요. 직접 계산하면 윤년·윤초 같은 함정이 있어 라이브러리를 쓰는 게 안전합니다.

2038년 문제와 64비트

Unix 타임스탬프는 전통적으로 32비트 부호 있는 정수(signed int32)로 저장됐는데, 이 자료형의 최대값은 2,147,483,647입니다. epoch 기준으로 환산하면 2038년 1월 19일 03:14:07 UTC예요. 이 시간을 넘으면 32비트 시스템에서는 음수로 오버플로되어 1901년 같은 엉뚱한 시간이 나옵니다. 이게 흔히 말하는 2038년 문제(Y2K38) 예요. 다행히 대부분의 현대 시스템은 64비트 정수를 사용하고, 64비트면 약 2920억 년 후까지 안전합니다. 다만 일부 임베디드·옛 시스템·32비트 DB 컬럼에는 여전히 잔존 가능성이 있어 마이그레이션 점검이 필요합니다.

도구로 변환하기

툴박스의 Unix 타임스탬프 변환기는 epoch와 사람이 읽는 시간을 양방향으로 즉시 변환합니다. 초·밀리초 단위를 자동 인식하고, KST·UTC 두 형식을 함께 보여주니 디버깅 중에 빠르게 확인할 수 있어요. 로그에 찍힌 epoch가 언제인지 확인하거나, API에 보낼 시각을 epoch로 변환해야 할 때 빠르게 들렀다 가세요. 시간을 다루는 코드의 버그는 디버깅이 까다로우니, 의심스러울 때는 항상 도구로 한 번 검증하는 습관이 좋습니다.