타임스탬프 변환기 사용법: 로그 시간과 UTC/KST를 빠르게 맞추는 법

로그를 보다가 1735689600 같은 숫자를 만나면 잠깐 멈추게 된다. 이 값이 초 단위 Unix timestamp인지, 밀리초인지, UTC 기준인지, 한국 시간으로 몇 시인지 바로 떠오르지 않는다. 자동화, 웹훅, 결제 이벤트, 배포 로그는 이런 시간 표현을 자주 섞어 쓴다.

Timestamp Converter는 숫자 타임스탬프와 사람이 읽을 수 있는 날짜를 서로 바꿔 보는 도구다. 목적은 단순 변환만이 아니다. “이 이벤트가 실제로 언제 일어났는지”, “서버 로그와 사용자 화면 시간이 왜 다르게 보이는지”를 빠르게 확인하는 데 있다.

초와 밀리초부터 구분한다

Unix timestamp에서 가장 흔한 실수는 단위 혼동이다. 10자리 숫자는 보통 초 단위이고, 13자리 숫자는 보통 밀리초 단위다. 예를 들어 1735689600과 1735689600000은 같은 시점을 가리킬 수 있지만 단위가 다르다.

초 단위 값을 밀리초로 해석하면 아주 먼 과거나 이상한 날짜가 나오고, 밀리초 값을 초로 해석하면 미래의 말도 안 되는 날짜가 나온다. 그래서 변환 결과가 이상하면 먼저 시간대보다 단위를 확인해야 한다.

실무적인 판단 기준은 다음과 같다.

• 10자리: Unix seconds일 가능성이 크다.
• 13자리: Unix milliseconds일 가능성이 크다.
• 소수점이 있는 값: 초 단위에 millisecond precision이 붙었을 수 있다.
• API 문서가 있으면 문서의 단위를 우선한다.
• 변환 결과가 너무 이상하면 단위를 바꿔 다시 본다.

UTC와 KST는 표시 기준이 다르다

타임스탬프 자체는 보통 특정 시점을 가리키는 값이다. 하지만 화면에 표시할 때는 UTC, KST, 브라우저 로컬 시간처럼 기준이 달라진다. 한국에서 일하는 사람에게는 KST가 읽기 쉽지만, 서버와 데이터베이스는 UTC를 기준으로 저장하는 경우가 많다.

예를 들어 같은 이벤트라도 로그에는 2025-01-01T00:00:00Z로 보이고, 한국 화면에서는 2025-01-01 09:00 KST로 보일 수 있다. 둘은 다른 사건이 아니라 같은 시점을 다른 시간대로 표시한 것이다.

변환할 때는 다음 세 값을 함께 보는 습관이 좋다.

• UTC: 서버와 API 기준 확인
• KST: 한국 사용자·운영팀 기준 확인
• Local time: 현재 브라우저나 기기의 시간대 기준 확인

이 세 표시를 함께 보면 “저장된 값이 틀린 것인지, 표시 시간대가 다른 것인지”를 빠르게 구분할 수 있다.

로그 디버깅에서 쓰는 순서

장애나 웹훅 실패를 확인할 때는 시간 순서가 중요하다. 그런데 서비스마다 표시 방식이 다르면 사건 순서를 잘못 이해할 수 있다. 결제는 10:01에 성공했는데 알림은 10:00에 실패한 것처럼 보이는 식이다.

디버깅할 때는 다음 순서가 안전하다.

1. 각 시스템의 원본 timestamp 값을 복사한다.
2. 초/밀리초 단위를 확인한다.
3. UTC 기준으로 모두 변환해 한 줄에 맞춘다.
4. 운영자가 읽기 쉽도록 KST 표시도 함께 본다.
5. 이벤트 간 차이가 몇 초 또는 몇 분인지 계산한다.
6. 화면 표시 시간이 아니라 원본 로그 시간을 기준으로 판단한다.

이렇게 하면 서버 로그, 웹훅 요청, 프론트엔드 이벤트, 외부 서비스 대시보드의 시간을 같은 축에 놓을 수 있다.

웹훅과 자동화에서 자주 생기는 문제

웹훅 payload에는 created_at, updated_at, event_time, expires_at 같은 필드가 자주 들어간다. 문제는 필드 이름만으로 단위와 시간대를 알기 어렵다는 점이다. 어떤 서비스는 ISO 문자열을 쓰고, 어떤 서비스는 Unix seconds를 쓰고, 어떤 서비스는 milliseconds를 쓴다.

자동화에서는 만료 시간도 자주 헷갈린다. 토큰이 언제 만료되는지, 예약 작업이 언제 실행되어야 하는지, 재시도 시간이 얼마나 남았는지 확인할 때 timestamp 변환이 필요하다.

확인할 항목은 다음과 같다.

• 문서에서 timestamp 단위를 명시하는가
• 값이 숫자인가, ISO 문자열인가
• Z가 붙은 UTC 문자열인가
• 사용자에게 보여줄 때 KST로 바꾸는가
• 만료 시간 비교를 서버 기준으로 하는가, 브라우저 기준으로 하는가

Webhook Request Simulator로 받은 응답에 시간 필드가 들어 있다면, Timestamp Converter로 바로 변환해 보는 흐름이 좋다.

예약 작업과 cron 확인에도 유용하다

Cron 표현식은 반복 규칙을 표현하지만, 실제 실행 시각은 시간대에 따라 달라진다. 예를 들어 매일 오전 7시에 실행되어야 하는 작업이 서버에서는 UTC 기준으로 저장될 수 있다. 이때 timestamp 변환기는 특정 실행 시간이 KST로 언제인지 확인하는 보조 도구가 된다.

Cron Explainer로 반복 규칙을 확인하고, 실제 로그에 찍힌 timestamp를 변환해 보면 스케줄러가 의도한 시간에 실행됐는지 볼 수 있다. 특히 새벽 작업, 해외 사용자 대상 알림, DST가 있는 지역과 엮인 자동화는 시간대 확인이 중요하다.

사람이 읽는 날짜를 timestamp로 바꿀 때

반대로 사람이 읽는 날짜를 timestamp로 바꿔야 할 때도 있다. API 테스트에서 expires_at 값을 만들거나, 데이터베이스 쿼리의 범위 조건을 넣거나, 특정 시각 이후 이벤트만 필터링할 때다.

이때는 입력한 날짜가 어느 시간대 기준인지 분명히 해야 한다. 2026-05-11 09:00이라고만 쓰면 KST인지 UTC인지 모호하다. 가능하면 KST, UTC, 또는 명시적인 offset을 함께 둔다.

예를 들어 한국 사용자에게 2026년 5월 11일 오전 9시에 보이는 시간을 기준으로 timestamp를 만들고 싶다면, 그 입력이 KST임을 먼저 확인해야 한다. 서버 저장용으로는 UTC timestamp를 쓰더라도, 시작 기준은 사용자 의도와 맞아야 한다.

변환 결과를 믿기 전 체크리스트

타임스탬프 변환 결과를 복사하기 전에 아래를 확인한다.

• 입력값이 초인지 밀리초인지 맞게 선택했는가
• UTC와 KST 표시를 모두 확인했는가
• 브라우저 로컬 시간대가 기대한 지역과 같은가
• API 문서의 timestamp 단위와 일치하는가
• 만료·예약 시간은 경계 시각을 포함/제외하는지 확인했는가
• 결과를 서버 로그나 실제 이벤트 시간과 비교했는가

타임스탬프 변환기는 작은 도구지만, 시간 문제를 다룰 때는 사고를 줄이는 기준점이 된다. 숫자를 날짜로 바꾸는 것에서 끝내지 말고, 단위와 시간대, 실제 사용 맥락까지 함께 확인하는 방식으로 쓰는 것이 좋다.