Unix Timestamp Explained — Concepts, Conversion, and the Y2K38 Problem

Unix 타임스탬프란?

**Unix 타임스탬프(Unix Timestamp)**는 1970년 1월 1일 00:00:00 UTC를 기준점(Epoch)으로 하여 경과한 초(seconds) 수를 정수로 표현한 값입니다. 예를 들어 타임스탬프 0은 정확히 1970년 1월 1일 자정(UTC)이고, 1700000000은 2023년 11월 14일 22시 13분 20초(UTC)를 의미합니다.

왜 하필 1970년 1월 1일일까요? 이는 Unix 운영체제가 개발되던 시기에 정해진 관례입니다. 당시 컴퓨터의 메모리와 저장 공간이 극도로 제한적이었기 때문에, 단 하나의 정수로 시간을 표현하는 방식이 매우 효율적이었습니다. 이 설계가 그대로 현재까지 이어져 사실상 모든 운영체제와 프로그래밍 언어에서 표준으로 사용되고 있습니다.

타임스탬프의 장점

단순한 정수 한 개로 시간을 표현하는 이 방식에는 여러 강력한 장점이 있습니다.

시간대 독립성

타임스탬프는 항상 UTC 기준의 절대값입니다. “2026년 4월 7일 오후 3시”라고 말하면 한국 시간인지, 미국 동부 시간인지 알 수 없지만, 1775656800이라는 타임스탬프는 전 세계 어디서든 동일한 순간을 가리킵니다.

정렬과 비교의 용이성

두 시각을 비교할 때 문자열 날짜(“2026-04-07”과 “2026-12-25”)보다 정수(1775656800과 1798070400)를 비교하는 것이 훨씬 간단하고 빠릅니다. 대소 비교 한 번이면 어느 시점이 더 과거인지 즉시 알 수 있습니다.

저장 공간 효율

타임스탬프는 32비트(4바이트) 또는 64비트(8바이트) 정수 하나로 저장됩니다. “2026-04-07T15:00:00+09:00” 같은 ISO 형식 문자열(25바이트 이상)에 비해 훨씬 적은 공간을 차지합니다.

언어 및 시스템 간 호환

JavaScript, Python, Java, PHP, SQL 등 어떤 환경에서도 Unix 타임스탬프를 읽고 쓸 수 있습니다. 서로 다른 시스템 간에 시간 데이터를 주고받을 때 포맷 차이로 인한 오류를 방지할 수 있습니다.

타임스탬프 vs ISO 8601

시간을 표현하는 또 다른 국제 표준인 ISO 8601 형식과 타임스탬프를 비교해 보겠습니다.

비교 항목	Unix 타임스탬프	ISO 8601
예시	`1775656800`	`2026-04-07T06:00:00Z`
가독성	낮음 (숫자만 보고 날짜 파악 어려움)	높음 (사람이 바로 읽을 수 있음)
계산 효율	높음 (정수 연산)	낮음 (문자열 파싱 필요)
크기	4~8바이트	20~30바이트
시간대	항상 UTC	명시적 표기 가능 (`+09:00`)

API 설계 시 어떤 것을 선택해야 할까요? 일반적으로 내부 시스템 간 통신이나 데이터베이스 저장에는 타임스탬프가 효율적이고, 외부 API 응답이나 사용자에게 보여줄 데이터에는 ISO 8601이 더 적합합니다. 많은 API가 두 형식을 모두 제공하기도 합니다. 예를 들어 GitHub API는 created_at에 ISO 8601을 사용하고, JWT 토큰의 iat, exp 필드에는 Unix 타임스탬프를 사용합니다.

프로그래밍 언어별 타임스탬프

각 언어에서 현재 시각의 Unix 타임스탬프를 얻는 방법입니다.

JavaScript

// 초 단위 타임스탬프 (10자리)
const timestamp = Math.floor(Date.now() / 1000);

// 타임스탬프 → 날짜
const date = new Date(timestamp * 1000);

Python

import time

# 초 단위 타임스탬프
timestamp = int(time.time())

# 타임스탬프 → 날짜
from datetime import datetime
date = datetime.utcfromtimestamp(timestamp)

Java

// 초 단위 타임스탬프
long timestamp = Instant.now().getEpochSecond();

// 타임스탬프 → 날짜
Instant instant = Instant.ofEpochSecond(timestamp);

PHP

// 초 단위 타임스탬프
$timestamp = time();

// 타임스탬프 → 날짜
$date = date('Y-m-d H:i:s', $timestamp);

SQL (MySQL)

-- 현재 타임스탬프
SELECT UNIX_TIMESTAMP();

-- 타임스탬프 → 날짜
SELECT FROM_UNIXTIME(1775656800);

밀리초 vs 초 — 13자리와 10자리의 차이

타임스탬프를 다루다 보면 10자리와 13자리 값을 혼용하게 되는데, 이 차이를 정확히 이해해야 합니다.

구분	초 단위	밀리초 단위
자릿수	10자리	13자리
예시	`1700000000`	`1700000000000`
정밀도	1초	0.001초
주요 사용처	Unix 표준, PHP, Python	JavaScript, Java

JavaScript의 Date.now()는 밀리초를 반환합니다. 이를 초 단위 타임스탬프로 변환하려면 1000으로 나눈 뒤 소수점을 버려야 합니다. 반대로 초 단위 타임스탬프를 JavaScript의 new Date()에 넘길 때는 1000을 곱해야 합니다.

이 변환을 빠뜨리면 1970년 1월 20일경의 날짜가 나타나는 흔한 버그가 발생합니다. 예를 들어 new Date(1700000000)은 1970년 1월 20일이 되어버립니다. 올바른 사용법은 new Date(1700000000 * 1000)입니다.

시간대(Timezone)와 타임스탬프

왜 UTC 기준인가?

타임스탬프의 핵심 원칙은 시간대를 포함하지 않는다는 것입니다. 1775656800이라는 값 자체에는 시간대 정보가 없으며, 이 숫자는 UTC 기준 2026년 4월 7일 06:00:00을 나타냅니다. 한국(KST, UTC+9)에서는 같은 순간이 2026년 4월 7일 15:00:00이 됩니다.

한국 시간(KST) 변환

타임스탬프를 한국 시간으로 변환할 때 단순히 9시간(32400초)을 더하는 방법은 권장되지 않습니다. 대신 시스템의 시간대 라이브러리를 사용하세요.

// 올바른 방법
new Date(timestamp * 1000).toLocaleString('ko-KR', {
  timeZone: 'Asia/Seoul'
});

서머타임(DST) 문제

한국은 서머타임을 사용하지 않지만, 미국, 유럽 등 많은 국가에서는 서머타임을 적용합니다. 서머타임 전환 시 같은 시각이 두 번 존재하거나 존재하지 않는 경우가 발생할 수 있어, 국제 서비스에서는 반드시 UTC로 저장하고 표시할 때만 로컬 시간으로 변환하는 것이 모범 사례입니다.

데이터베이스 저장 모범 사례

저장: 항상 UTC 타임스탬프 또는 TIMESTAMP WITH TIME ZONE 타입 사용
표시: 사용자의 브라우저 시간대에 맞춰 클라이언트에서 변환
비교: UTC 기준으로 통일하여 비교

2038년 문제(Y2K38)

32비트 정수 오버플로

전통적으로 Unix 타임스탬프는 **32비트 부호 있는 정수(signed int32)**로 저장됩니다. 이 타입이 표현할 수 있는 최대값은 2,147,483,647이며, 이 값은 2038년 1월 19일 03:14:07 UTC에 해당합니다.

이 시점을 넘으면 정수 오버플로가 발생하여 값이 -2,147,483,648(1901년 12월 13일)로 되돌아가게 됩니다. 이것이 Y2K38 문제입니다.

영향 범위

32비트 운영체제 및 임베디드 시스템
오래된 C/C++ 코드에서 time_t를 32비트로 사용하는 경우
32비트 MySQL의 TIMESTAMP 타입 (2038년 1월 19일까지만 저장 가능)
IoT 장비, 자동차 ECU 등 수명이 긴 임베디드 장치

64비트 전환

64비트 정수로 전환하면 약 2920억 년 후까지 표현할 수 있어 사실상 문제가 해결됩니다. 현재 대부분의 최신 운영체제(Linux 5.6+, Windows, macOS)와 프로그래밍 언어는 이미 64비트 타임스탬프를 사용합니다. 하지만 레거시 시스템과 임베디드 장치의 업데이트가 과제로 남아 있습니다.

역사적 유사 사례 — Y2K

2000년 문제(Y2K)에서는 연도를 두 자리로 저장하던 시스템이 2000년을 1900년으로 인식할 위험이 있었습니다. 전 세계적으로 수천억 원의 비용을 들여 사전 대응한 덕분에 큰 사고 없이 넘어갔지만, Y2K38은 아직 많은 시스템이 대비하지 못하고 있어 소프트웨어 업계의 지속적인 관심이 필요합니다.

실무 활용 사례

로그 분석

서버 로그에 타임스탬프를 기록하면 시간대에 관계없이 이벤트 순서를 정확히 추적할 수 있습니다. 분산 시스템에서 여러 서버의 로그를 합칠 때 특히 유용합니다.

API 요청/응답

RESTful API에서 리소스의 생성·수정 시각을 타임스탬프로 포함하면, 클라이언트가 자유롭게 원하는 시간대로 변환하여 표시할 수 있습니다.

캐시 만료

HTTP 캐시 헤더나 CDN 설정에서 만료 시각을 타임스탬프로 지정합니다. 현재 타임스탬프와 비교하여 캐시 유효성을 간단한 정수 비교로 판단할 수 있습니다.

JWT 토큰 만료 시간

JSON Web Token(JWT)의 iat(발급 시각), exp(만료 시각), nbf(유효 시작 시각) 클레임은 모두 Unix 타임스탬프를 사용합니다. 토큰 검증 시 현재 타임스탬프와 exp를 비교하여 만료 여부를 확인합니다.

cron 작업 및 스케줄링

주기적 작업의 마지막 실행 시각을 타임스탬프로 저장하면, 다음 실행 시각 계산이 단순한 덧셈이 됩니다. 예를 들어 1시간마다 실행하는 작업이면 마지막 실행 타임스탬프에 3600을 더하면 됩니다.

마무리

Unix 타임스탬프는 단순하지만 강력한 시간 표현 방식입니다. 시간대 독립성, 계산 효율성, 시스템 간 호환성 덕분에 수십 년간 소프트웨어 개발의 핵심 도구로 자리 잡았습니다. 밀리초와 초의 차이, UTC 기준 원칙, 그리고 2038년 문제까지 이해하고 있다면 시간 데이터를 다루는 데 훨씬 자신감을 가질 수 있습니다.

타임스탬프를 날짜로, 또는 날짜를 타임스탬프로 빠르게 변환하고 싶다면 Timestamp 변환기를 사용해보세요. 밀리초와 초 단위 모두 지원하며, 현재 시간의 타임스탬프도 즉시 확인할 수 있습니다.