Unix timestamp가 로그에 남긴 숫자를 날짜로 바꾸는 일은 자릿수만 세는 작업이 아닙니다. 먼저 이 숫자가 초인지 밀리초인지, 어느 시간대에서 기록되었는지, 날짜가 변환된 뒤 실제 사건과 맞는지를 순서대로 확인해야 합니다. 10자리와 13자리는 흔한 신호이지만, 그것만으로 모든 데이터의 단위를 확정할 수는 없습니다.
이 글은 API 만료 시각과 서버 로그가 어긋난 상황을 작은 사건 기록처럼 추적하는 방법을 설명합니다. 현재 도구는 현재 Unix 시간을 1초 간격으로 보여 주고, 숫자에서 날짜로 또는 날짜에서 초 단위 timestamp로 변환합니다. 기능이 제공하는 자동 판별과 사람이 해야 할 운영 검증을 나누어 읽으세요.
먼저 증상을 사건 시간표로 바꾸기
문제가 발생하면 숫자 하나를 바로 변환하지 말고 사건의 순서를 적습니다. 클라이언트가 요청을 보낸 시각, 서버가 로그를 기록한 시각, 만료 검사를 수행한 시각, 사용자가 화면을 본 시각을 각각 별도 행으로 놓으세요. 숫자가 같은 형식처럼 보여도 각 시스템이 초, 밀리초, 마이크로초 중 무엇을 쓰는지 다를 수 있습니다.
| 기록 | 확인할 값 | 의심할 오류 |
|---|---|---|
| 브라우저 | Date.now와 전송 형식 | 밀리초를 초로 오해 |
| API | 필드 설명과 단위 | 문서·구현 불일치 |
| 서버 로그 | 로그 생성기와 시간대 | 로컬 시간과 UTC 혼용 |
| 화면 | 변환 후 표시된 날짜 | 브라우저 시간대 차이 |
사건 시간표가 있으면 1970년이나 먼 미래가 표시될 때 어느 단계에서 단위가 바뀌었는지 추적할 수 있습니다. 반대로 변환 결과 하나만 보고 시스템 전체가 틀렸다고 판단하면 원인이 네트워크 지연인지 단위 오류인지 구분할 수 없습니다.
초와 밀리초를 같은 순간의 쌍으로 보기
Unix timestamp의 기본 단위는 1970년 1월 1일 UTC부터 흐른 초입니다. JavaScript의 `Date.now()`처럼 밀리초를 사용하는 값은 같은 순간을 더 큰 숫자로 표현합니다. 1초는 1,000밀리초이므로 한 형식에서 다른 형식으로 옮길 때 초→밀리초는 1,000을 곱하고, 밀리초→초는 1,000으로 나누는 관계를 먼저 적어 두세요.
예를 들어 `1725000000`과 `1725000000000`을 한 쌍으로 준비하면 앞은 초, 뒤는 밀리초 후보가 됩니다. 두 값을 각각 변환했을 때 같은 날짜와 시각을 가리키는지 비교하세요. 숫자의 끝에 0이 세 개 붙었다는 사실만 확인하는 것보다 동일 순간 검산이 더 안전합니다.
자릿수 규칙은 기간이 길어지면 약해질 수 있습니다. 현재 흔한 초 timestamp가 10자리라고 해도 먼 미래에는 자릿수가 달라질 수 있고, 중간 시스템이 잘라내거나 패딩한 값은 10·13자리 규칙과 맞지 않을 수 있습니다. API 문서, 데이터베이스 컬럼 타입, 실제 생성 코드가 있으면 자릿수보다 그 근거를 우선하세요.
이 변환기의 자동 판별 규칙 알아보기
숫자에서 날짜로 바꾸는 입력란은 값을 정수로 읽고, 입력 문자열 길이가 11자리보다 길면 밀리초로 나누어 처리하며 그렇지 않으면 초로 처리합니다. 따라서 일반적인 10자리 초와 13자리 밀리초에는 편리하지만, 11자리와 12자리 값은 실제 의미와 자동 규칙이 다를 수 있습니다. 비표준 길이의 값은 단위 정보를 확인한 뒤 별도로 계산하세요.
변환 결과는 `yyyy-MM-dd HH:mm:ss (XXX)` 형식으로 표시됩니다. 괄호 안의 오프셋은 결과를 보는 브라우저 환경에 따라 달라질 수 있으므로, 같은 숫자를 한국의 노트북과 UTC 서버에서 볼 때 표시 문자열이 다를 수 있습니다. 날짜가 달라졌다는 사실과 순간이 달라졌다는 사실을 구분하려면 UTC 기준 문자열도 함께 기록하세요.
현재 시간 배너는 1초마다 갱신되며, 표시된 숫자를 눌러 복사할 수 있습니다. 숫자를 복사할 때 그 값의 취득 시각을 함께 남기지 않으면 나중에 로그와 비교하기 어렵습니다. 복사한 현재 값은 실행 기준점을 확인하는 데 사용하고, 공식 이벤트 시각의 원본으로 대체하지 마세요.
날짜에서 timestamp로 되돌릴 때 생기는 차이
날짜 입력 영역은 로컬 날짜와 시간을 넣는 `datetime-local` 형식입니다. 도구는 입력을 ISO 형태로 읽은 뒤 Unix 초를 반환하므로, 결과가 13자리 밀리초가 아니라 10자리 안팎의 초 값으로 보이는 것이 정상입니다. JavaScript 코드의 `Date.now()`와 비교하려면 반환값에 1,000을 곱해 단위를 맞춘 뒤 비교하세요.
예를 들어 2026년 8월 28일 오전 9시를 입력하고 나온 값이 초 단위라면, 같은 순간을 밀리초로 쓰는 값은 그 결과 뒤에 단위 변환을 적용한 숫자입니다. 두 숫자의 자릿수만 복사해 붙이는 것이 아니라, 어느 시스템 필드가 어느 단위를 요구하는지 확인해야 합니다. 초 값을 밀리초 필드에 넣으면 날짜가 1970년 근처로 해석될 수 있습니다.
날짜 문자열에는 시간대 정보가 직접 보이지 않을 수 있습니다. 업무 기록에 변환 결과를 남길 때는 입력한 로컬 시간, 지역, 출력 단위, UTC로 환산했는지 여부를 같은 줄에 적으세요. 특히 자정 전후의 사건은 시간대 오해가 날짜 하루 차이로 나타날 수 있으므로 화면의 표시만 보고 종료 시각을 확정하지 마세요.
로그 오류를 네 가지 패턴으로 분류하기
| 관찰 결과 | 가능한 원인 | 검증 행동 |
|---|---|---|
| 1970년 근처 날짜 | 밀리초를 초로 읽음 | 값에 1,000배 관계 적용 |
| 먼 미래 날짜 | 초를 밀리초로 읽음 | 필드 단위와 생성 코드를 대조 |
| 하루가 어긋남 | UTC·로컬 시간대 차이 | 오프셋을 포함해 다시 표시 |
| 초가 사라짐 | 정수 변환·반올림·문자열 절단 | 원본과 전송 payload 비교 |
실제 오류를 조사할 때는 변환된 날짜가 그럴듯해 보이는지보다 원본 숫자와 필드 계약을 먼저 확인합니다. 숫자를 한 번 더 변환해서 현재 사건에 맞추는 방식은 이미 잘못된 단위를 숨길 수 있습니다. 원본 로그, API 요청·응답, 화면 표시를 각각 보관하고 같은 시각 기준으로 비교하세요.
경계값과 입력 오류를 별도로 처리하기
빈 입력은 결과를 비우고, 숫자가 아닌 문자열은 유효하지 않은 숫자로 표시됩니다. 그러나 숫자처럼 보이는 소수나 공백이 섞인 값은 정수 변환 과정에서 일부가 잘릴 수 있습니다. timestamp는 보통 정수로 주고받으므로 소수점이 있다면 원본 시스템이 소수 단위를 사용하는지 먼저 확인한 뒤 반올림 규칙을 정하세요.
시작일과 종료일을 변환하려는 목적이라면 타임스탬프 변환기와 날짜 계산기를 구분하세요. 한 숫자를 사람의 날짜로 바꾸는 작업과 두 날짜 사이의 기간을 구하는 작업은 서로 다른 질문입니다. 날짜 차이가 필요한 경우 날짜 계산기에서 두 날짜를 직접 비교하고, 숫자 단위가 문제라면 현재 변환 결과와 원본 필드를 나란히 기록하세요.
초·밀리초 외에 마이크로초나 나노초를 사용하는 시스템도 있습니다. 자릿수가 길다고 무조건 밀리초로 나누면 안 되며, 도구가 지원하는 범위를 넘어서는 값은 해당 시스템의 문서와 전용 변환 로직을 사용해야 합니다. 브라우저 화면이 모든 시간 단위를 자동으로 판별해 주는 것은 아닙니다.
운영 로그에 남길 최소 증거
- 원본 timestamp와 필드 이름을 기록합니다.
- 초·밀리초·기타 단위 중 계약상 단위를 적습니다.
- 생성 시스템의 시간대와 표시 시스템의 시간대를 분리합니다.
- 변환에 사용한 값과 결과 날짜를 함께 보관합니다.
- 실제 사건의 시작·종료·만료 시각과 비교합니다.
- 결론을 바꾼 가정이 있었는지 메모합니다.
타임스탬프를 날짜로 확인하려면 Unix 타임스탬프 변환기에서 초와 밀리초 후보를 각각 넣어 보세요. 여러 시간의 차이를 계산하거나 작업시간을 비교해야 한다면 시간 계산기로 별도 검산할 수 있습니다. Unix 시간의 저장 방식과 개발 중 흔한 오류를 더 읽고 싶다면 Unix 타임스탬프 완벽 가이드를 참고하세요.