이 도구는 무엇인가요?
유닉스 타임스탬프(에포크 타임이라고도 함)는 1970년 1월 1일 00:00:00 UTC부터 흐른 초 수입니다. 컴퓨터가 시각을 저장하는 표준 방식으로, 데이터베이스·로그 파일·API·프로그래밍 언어 대부분이 이를 사용합니다. 타임존 혼동 없이 명확한 하나의 숫자로 표현할 수 있기 때문입니다.
형식은 두 가지입니다: 초 단위(현재 기준 10자리, 예: 1720500000)와 밀리초 단위(13자리, JavaScript와 Java에서 주로 사용). 이 도구는 붙여넣은 값이 둘 중 무엇인지 자동으로 판별합니다.
왜 사용해야 할까요?
- 로그, 데이터베이스 행, API 응답에 있는 타임스탬프를 즉시 읽을 수 있습니다.
- 초/밀리초를 자동으로 감지해 따로 판단할 필요가 없습니다.
- 로컬 시간, UTC, ISO 8601, 그리고 상대 시간("3시간 전")을 한 번에 보여줍니다.
- 양방향 변환 가능: 타임스탬프 → 날짜, 날짜 → 타임스탬프.
- 지금 시각의 타임스탬프가 바로 필요할 때 쓰는 실시간 시계.
사용 방법
- 디코딩하려면: 왼쪽 상자에 타임스탬프(예: 1720500000)를 붙여넣고 "변환"을 클릭하세요.
- 결과를 로컬 시간, UTC, ISO 8601, 상대 시간으로 확인할 수 있습니다.
- 인코딩하려면: 오른쪽 상자에서 날짜와 시간을 선택하고 "변환"을 클릭하면 초/밀리초 단위 타임스탬프가 나옵니다.
- 지금 당장의 타임스탬프만 필요하다면 상단의 실시간 시계를 확인하세요.
예시
입력
1720500000결과
로컬 시간: 2024. 7. 9. 오후 1:20:00
UTC 시간: Tue, 09 Jul 2024 05:20:00 GMT
ISO 8601: 2024-07-09T05:20:00.000Z10자리 값은 초 단위로, 13자리 값은 밀리초 단위로 처리됩니다.
실무 팁
- "시간이 이상하다"는 버그의 90%는 타임스탬프 자체가 틀린 게 아니라 타임존 표시 문제입니다. 코드를 손대기 전에 UTC 항목을 서버 로그와 먼저 비교해 보세요(서버는 보통 UTC로 로그를 남깁니다).
- 날짜가 정확히 1970-01-01로 나온다면 타임스탬프 값이 0이거나 비어 있었다는 뜻입니다 — 실제 날짜라기보다는 null 값의 전형적인 증상입니다.
- 1970년 근처(며칠 차이)로 나온다면 어딘가에서 밀리초 값을 초로 잘못 해석한 경우가 많고, 반대로 56,000년대 같은 날짜가 나온다면 초 값을 밀리초로 잘못 해석한 경우입니다.
- 스프레드시트에서는: 엑셀은 1970년부터의 초가 아니라 1900년부터의 일수를 셉니다. 초 단위 타임스탬프라면 =(A1/86400)+DATE(1970,1,1) 로 변환하세요.
실제 사용 사례
타임스탬프가 실무에서 자주 문제가 되는 지점들: JWT나 API 토큰의 만료 필드 읽기(exp/iat는 유닉스 초 단위입니다), 사용자의 버그 리포트 시각과 서버 로그 줄을 대조하기, 캐시 TTL이나 cron 실행 구간 설정하기, 인증서나 토큰이 실제로 만료됐는지 확인하기. 상대 시간("3시간 전") 항목이 이런 상황들을 가장 빠르게 검증하는 방법입니다.
JWT 디버깅은 워낙 흔한 상황이라 절차를 짚어두면: Base64 도구로 토큰의 payload를 디코딩한 다음, exp 값을 이 도구에 붙여넣으세요 — "이 토큰이 만료됐는지, 얼마나 지났는지" 바로 답이 나옵니다.
유닉스 타임은 왜 이런 방식으로 설계됐을까
고정된 기준 시점부터 계속 증가하는 하나의 숫자를 저장하는 방식(년/월/일/시 구조 대신)은 의도적인 단순화 선택이었습니다. 두 타임스탬프는 캘린더 로직 없이 단순 산술 연산만으로 비교하거나 뺄셈할 수 있습니다. 데이터베이스, 로그 포맷, 그리고 사실상 모든 프로그래밍 언어의 내부 날짜 표현이 이 방식 위에 세워진 이유입니다. 그 단순함의 대가가 바로 이 도구가 존재하는 이유이기도 합니다 — 사람은 1970년부터 흐른 초로 시간을 생각하지 않으니, 모든 타임스탬프는 사람이 읽을 수 있는 달력 날짜로 다시 번역되어야 의미가 생기고, 그 번역 과정에서 타임존, 정밀도(초 vs 밀리초), 표시 형식을 동시에 고려해야 합니다.
→ Base64 인코더/디코더 · 나이 계산기
자주 묻는 질문
타임스탬프가 초 단위인지 밀리초 단위인지 어떻게 구분하나요?
자릿수(크기)로 구분합니다. 1,000,000,000,000(1e12) 이상이면 밀리초로, 그보다 작으면 초로 처리합니다. 현재 시점 기준으로 초 단위는 약 17억, 밀리초 단위는 약 1조 7천억이라 실제 사용되는 날짜 범위에서는 두 범위가 겹치지 않습니다.
변환된 시각이 예상한 시간과 다르게 나오는 이유는 뭔가요?
타임존 때문입니다. 타임스탬프는 항상 UTC 기준이며, "로컬 시간" 항목은 이를 사용자 기기의 타임존으로 변환한 값입니다. 원본 시스템이 남긴 로그와 비교할 때는 UTC 항목을 확인하세요 — 많은 서버가 UTC로 로그를 남깁니다.
2038년 문제란 무엇인가요?
타임스탬프를 부호 있는 32비트 정수로 저장하는 시스템은 2038년 1월 19일에 오버플로가 발생합니다. 최신 시스템은 64비트 정수를 사용해 이 문제의 영향을 받지 않습니다. 이 도구는 JavaScript 숫자를 사용하므로 2038년 이후 날짜도 문제없이 처리합니다.
음수 타임스탬프도 변환할 수 있나요?
네. 음수 타임스탬프는 1970년 1월 1일 이전 날짜를 나타냅니다 — 예를 들어 -86400은 1969년 12월 31일입니다.
윤초(leap second)도 반영되나요?
아니요. 유닉스 타임은 하루가 정확히 86,400초라고 가정하고 윤초를 무시합니다 — 계산을 단순하게 유지하기 위한 의도적인 단순화입니다.