서버 로그를 열었더니 시간 필드에 1709251200이라는 숫자만 들어 있다. 날짜가 아니라 10자리 정수라서 대체 언제 발생한 이벤트인지 바로 알 수 없다. 이 숫자가 Unix 타임스탬프다.
Unix 타임스탬프가 뭔가
1970년 1월 1일 00:00:00 UTC(이를 Epoch라고 부른다)부터 경과한 초(seconds) 수를 정수로 표현한 것이다. 날짜와 시간을 하나의 숫자로 표현할 수 있어서 컴퓨터가 시간을 다루기에 편리하다.
예시 2026년 3월 1일 00:00:00 UTC =1772150400
2000년 1월 1일 00:00:00 UTC =946684800
사람이 읽기엔 불편하지만, 타임존에 관계없이 하나의 절대 시점을 나타낸다는 장점이 있다. 서울에서 보든 뉴욕에서 보든 같은 숫자가 같은 순간을 가리킨다.
초 단위와 밀리초 단위 구분
타임스탬프를 받았는데 자릿수가 다를 때가 있다. 구분법은 단순하다.
| 단위 | 자릿수 | 예시 | 사용처 |
|---|---|---|---|
| 초 (seconds) | 10자리 | 1709251200 | Unix/Linux, PHP, Python |
| 밀리초 (ms) | 13자리 | 1709251200000 | JavaScript, Java, Elasticsearch |
10자리면 초, 13자리면 밀리초다. 잘못 넣으면 1970년이나 수만 년 뒤 날짜가 나오니 자릿수를 먼저 확인해야 한다.
타임스탬프를 날짜로 변환하기
타임스탬프 변환기 상단에 현재 Unix 타임스탬프가 1초 단위로 갱신되고 있다. 변환할 숫자를 입력하고 초 또는 밀리초를 선택하면 로컬 시간(한국 시간), UTC, ISO 8601 형식이 한꺼번에 표시된다. 반대로 날짜를 넣어서 타임스탬프 숫자를 얻는 것도 가능하다.
개발에서 자주 쓰는 상황
- API 응답 해석: 외부 API가 날짜를 타임스탬프로 내려줄 때 사람이 읽을 수 있는 형태로 변환
- 로그 분석: 서버 로그의 시간 필드가 Epoch 형식일 때 실제 발생 시각 확인
- DB 쿼리 디버깅: 저장된 타임스탬프를 날짜로 바꿔서 데이터 정합성 검증
- 시간 비교 연산: 두 이벤트 사이의 경과 시간을 계산할 때 (단순 뺄셈으로 가능)
- 캐시 만료 확인: TTL 설정값과 현재 타임스탬프를 비교해 만료 여부 판단
타임존과 UTC
타임스탬프 자체는 타임존이 없다. UTC 기준 절대 시간이다. 한국 시간(KST)은 UTC +9이므로, 타임스탬프를 한국 날짜로 표시하면 UTC보다 9시간 앞서게 된다.
주의 서버가 UTC 기준으로 동작하는데 클라이언트에서 로컬 시간으로 변환하지 않으면 9시간 차이가 난다. 시간 관련 버그 중 상당수가 이 타임존 불일치에서 발생한다.
자주 묻는 질문
2038년 문제가 뭔가요?
32비트 정수로 타임스탬프를 저장하면 2038년 1월 19일에 오버플로가 발생한다. 2,147,483,647(약 21억)이 32비트 최대값인데, 이 시점 이후 시간을 표현할 수 없다. 64비트 시스템에서는 이 문제가 없다.
음수 타임스탬프도 가능한가요?
가능하다. 1970년 이전 날짜는 음수로 표현된다. 예를 들어 1969년 12월 31일은 -86400이다.
타임스탬프에 윤초가 반영되나요?
Unix 타임스탬프는 윤초를 무시한다. 하루를 정확히 86,400초로 계산하기 때문에, 극도로 정밀한 시간 측정이 필요한 분야에서는 별도 보정이 필요하다.
로그에 찍힌 숫자 10자리, 그게 정확히 어느 순간인지 모르면 디버깅 자체가 막힌다. 숫자를 넣고 날짜를 확인하는 데 걸리는 시간은 2초면 충분하다.