Unix 타임스탬프 이해하기
Unix 타임스탬프는 그저 숫자라 단순해 보이지만, 웹 작업 거의 모든 곳에 등장합니다. API, 로그, 내보내기, 큐 메시지, 이벤트 기록 모두 이 값을 사용합니다. 형식은 1970년 1월 1일 UTC 이후 초(또는 밀리초)를 세는 하나의 정수일 뿐입니다.
장점은 일관성입니다. 타임스탬프는 작고, 저장 단계에서는 시간대에 영향받지 않으며, 소프트웨어가 비교·정렬·전송하기에 좋습니다. 단점은 그 자체로는 읽기 어렵다는 점입니다. 1710153600 같은 값은 날짜로 변환하기 전까지 아무것도 알려 주지 않습니다.
그래서 타임스탬프 도구는 경험 많은 개발자에게도 여전히 유용합니다. 자주 실무적인 질문에 빠르게 답해야 합니다. 이 값이 초인지 밀리초인지, UTC와 현지 시간에서 무슨 날짜인지, 테스트 요청용 특정 날짜에 해당하는 타임스탬프는 무엇인지.
어떨 때 유용한가
created_at이나expires_at처럼 숫자 시간 필드를 반환하는 API 응답을 검토할 때.- 이벤트 시간이 원시 Unix 값으로 저장된 로그를 확인할 때.
- 백엔드 서비스와 브라우저 사이의 시간대 문제를 디버깅할 때.
- 요청이나 페이로드를 테스트하기 전에 일반 날짜를 Unix 시간으로 변환할 때.
실제 예시
API가 JSON 페이로드로 1710153600을 보낸다고 가정해 봅시다. 그 숫자만으로는 알기 어렵지만, 변환해 보면 특정 UTC 날짜와 사용자의 시간대에서의 현지 날짜에 대응한다는 것이 보입니다. 그 즉시 값이 합리적인지, 아니면 시간·일 단위 또는 천 배 단위의 척도 오류로 어긋났는지 알 수 있습니다.
여기서도 밀리초가 중요합니다. 1710153600000 같은 값은 같은 순간을 나타내지만 단위가 초가 아니라 밀리초입니다. 한쪽을 다른 한쪽으로 잘못 다루면 날짜가 완전히 어긋납니다.
흔한 사용 사례
- 페이로드의 타임스탬프 필드가 초인지 밀리초인지 확인할 때.
- UTC의 이벤트 시간과 사용자들이 현지 시간으로 보는 값을 비교할 때.
- 테스트와 데모용 만료 시각 샘플을 만들 때.
- 백엔드와 프런트엔드 코드가 같은 방식으로 변환하는지 확인할 때.
- 별도의 콘솔이나 스크립트를 열지 않고 오래된 내보내기 데이터를 읽을 때.
브라우저 기반 변환기 사용하기
브라우저 기반 도구를 사용하면 몇 초 만에 적용할 수 있습니다.
자주 묻는 질문
타임스탬프는 왜 UTC를 사용하나요?
UTC는 소프트웨어에 안정적인 기준점을 제공합니다. 읽기 쉬운 현지 시간은 시간대에 따라 바뀔 수 있지만, 저장된 타임스탬프 자체는 바뀌지 않습니다.
어떤 타임스탬프는 10자리이고, 어떤 것은 13자리인 이유는 무엇인가요?
열 자리는 보통 초를, 열세 자리는 보통 밀리초를 뜻합니다.
UTC와 현지 시간 둘 다 항상 필요한가요?
디버깅 중이라면 보통 그렇습니다. UTC는 시스템 간 비교에 도움이 되고, 현지 시간은 사람이 실제로 본 것을 확인하는 데 도움이 됩니다.