서버 로그에 1709251200이라고 찍혀 있다. 에러가 발생한 시각을 확인해야 하는데, 이 숫자만 봐서는 언제인지 알 수 없다. 이게 Unix 타임스탬프다. 1970년 1월 1일 자정(UTC)부터 흘러간 초(seconds)를 숫자로 표현한 것이다.
왜 날짜 대신 숫자를 쓰나
"2026-03-01 09:00:00"은 사람이 읽기 편하지만, 컴퓨터 입장에서는 비교와 정렬이 번거롭다. 타임스탬프는 단순 정수라서 크기 비교가 바로 가능하고, 시간대(timezone) 문제에서도 자유롭다. UTC 기준 하나로 전 세계 서버가 같은 시간을 공유할 수 있다.
- 초 단위 (10자리)
- 대부분의 서버, 리눅스 시스템에서 사용. 예: 1709251200
- 밀리초 단위 (13자리)
- 자바스크립트 Date.now(), 일부 API에서 사용. 예: 1709251200000
10자리면 초, 13자리면 밀리초다. 이것만 기억하면 어떤 형식인지 바로 구분할 수 있다.
타임스탬프 ↔ 날짜 변환
각 언어별로 변환 함수가 있다.
| 언어 | 타임스탬프 → 날짜 | 날짜 → 타임스탬프 |
|---|---|---|
| JavaScript | new Date(1709251200 * 1000) | Math.floor(Date.now() / 1000) |
| Python | datetime.fromtimestamp(1709251200) | int(datetime.now().timestamp()) |
| PHP | date('Y-m-d', 1709251200) | time() |
| Linux | date -d @1709251200 | date +%s |
코드를 실행하지 않고 빠르게 확인하고 싶을 때는 타임스탬프 변환기에 숫자를 넣으면 로컬 시간, UTC, ISO 8601 형식이 동시에 나온다. 반대로 날짜를 입력해서 타임스탬프로 바꾸는 것도 가능하다. 현재 시각의 타임스탬프도 실시간으로 표시된다.
실무에서 주의할 점
- 시간대 혼동 — 타임스탬프 자체는 UTC 기준이다. 한국 시간(KST)은 UTC+9. 변환 시 시간대를 확인하지 않으면 9시간 차이가 난다.
- 초 vs 밀리초 — 자바스크립트는 밀리초를 쓰고, 대부분의 서버는 초를 쓴다. 1000을 곱하거나 나누는 것을 빠뜨리면 1970년이 나온다.
- 2038년 문제 — 32비트 시스템에서 Unix 타임스탬프는 2038년 1월 19일에 오버플로가 발생한다. 64비트 시스템에서는 문제없다.
TIP API 응답에서created_at: 1709251200처럼 숫자만 오면 디버깅이 불편하다. ISO 8601 형식(2024-03-01T00:00:00Z)과 함께 제공하면 가독성이 좋아진다.
타임스탬프 변환은 백엔드 개발에서 거의 매일 하는 작업이다. 숫자 하나 확인하는 데 코드를 돌리기 번거로울 때, 웹 도구 하나 북마크해두면 시간을 절약할 수 있다.