타임스탬프 날짜 변환 방법 완벽 정리 - Unix 시간 사람이 읽는 형식으로 바꾸기
1700000000 같은 숫자가 실제 날짜로 어떻게 변환되는지 도구별 방법과 언어별 코드, 시간대 함정까지 한번에 정리한 실전 가이드입니다.
로그 파일을 열었더니 1731556800 같은 숫자가 잔뜩 적혀 있을 때, 이게 도대체 언제를 의미하는 건지 막막했던 경험이 있을 겁니다. API 응답을 받았는데 createdAt이 13자리 숫자로 와서 당황한 적도 있을 거고요. 타임스탬프는 컴퓨터 세계에서 시간을 다루는 가장 기본적인 방식이지만, 사람이 직접 읽기에는 불편합니다. 변환 방법만 알아두면 디버깅, 로그 분석, 데이터 정리가 훨씬 빨라집니다.
타임스탬프란 정확히 무엇인가
흔히 말하는 타임스탬프는 Unix 타임스탬프(에포크 시간)를 의미합니다. 1970년 1월 1일 00:00:00 UTC를 기준점으로 잡고, 그 시점부터 흐른 시간을 숫자로 표현한 값입니다. 예를 들어 1731556800은 그 기준점에서 약 17억 초가 지났다는 뜻입니다.
왜 1970년일까요. Unix 운영체제가 1970년 전후로 개발되었기 때문이고, 이 기준이 거의 모든 컴퓨터 시스템의 표준이 되어 지금까지 이어지고 있습니다. 데이터베이스, API, 로그, 파일 시스템까지 거의 모든 곳에서 이 방식을 씁니다.
타임스탬프는 시간대(timezone) 정보를 담지 않습니다. 항상 UTC 기준의 절대 시간이기 때문에, 같은 순간을 전 세계 어디서나 같은 숫자로 표현할 수 있다는 장점이 있습니다.
초 단위와 밀리초 단위 구분하기
가장 많이 헷갈리는 부분입니다. 같은 시점을 표현해도 자릿수가 다릅니다.
| 형태 | 예시 | 단위 | 주로 쓰이는 곳 |
|---|---|---|---|
| 10자리 | 1731556800 | 초(seconds) | Unix, PHP, Python time() |
| 13자리 | 1731556800000 | 밀리초(ms) | JavaScript, Java |
| 16자리 | 1731556800000000 | 마이크로초 | 고정밀 로그, 일부 DB |
| 19자리 | 1731556800000000000 | 나노초 | Go, 시스템 콜 일부 |
변환할 때 가장 흔한 실수가 단위를 잘못 보는 것입니다. 13자리 밀리초 값을 그대로 초로 해석하면 약 55,000년 후의 미래가 나옵니다. 자릿수를 먼저 세는 습관이 중요합니다.
타임스탬프 날짜 변환 방법 - 도구별 정리
가장 빠르게 변환하는 방법은 온라인 도구나 OS 내장 명령어를 쓰는 것입니다.
리눅스, macOS 터미널
- 리눅스: date -d @1731556800 입력하면 사람이 읽을 수 있는 날짜로 변환됩니다
- macOS: date -r 1731556800 형식을 사용합니다
- 역방향(날짜 → 타임스탬프): date -d "2026-05-14 12:00:00" +%s
윈도우 PowerShell
[DateTimeOffset]::FromUnixTimeSeconds(1731556800).ToLocalTime() 명령으로 변환할 수 있습니다. 밀리초 단위는 FromUnixTimeMilliseconds를 쓰면 됩니다.
엑셀, 구글 시트
타임스탬프가 A1 셀에 있다면 수식은 =A1/86400+DATE(1970,1,1)입니다. 86400은 하루의 초 수입니다. 결과 셀을 날짜 형식으로 바꿔야 제대로 보입니다. 한국 시간으로 보려면 9시간을 더해주면 됩니다.
프로그래밍 언어별 변환 코드
코드 안에서 자주 다뤄야 한다면 언어별 표준 라이브러리 사용법을 알아두면 좋습니다.
JavaScript
new Date(1731556800 * 1000)로 Date 객체를 만들 수 있습니다. JavaScript는 밀리초 기준이라서 초 단위 값에는 1000을 곱해야 합니다. 반대로 현재 시각의 타임스탬프는 Date.now()로 얻습니다.
Python
datetime.fromtimestamp(1731556800)가 가장 간단합니다. UTC 기준으로 받고 싶다면 datetime.utcfromtimestamp(1731556800)를 씁니다. 역방향은 int(datetime.now().timestamp())입니다.
PHP
date("Y-m-d H:i:s", 1731556800)로 즉시 문자열을 얻을 수 있습니다. 서버 시간대 설정에 따라 결과가 달라지므로 date_default_timezone_set으로 명시해주는 게 안전합니다.
로그 파일에서 특정 패턴의 타임스탬프만 골라내야 할 때는 정규식 테스터로 패턴을 먼저 검증해두면 시행착오를 줄일 수 있습니다. \d{10} 같은 패턴이 정확히 매칭되는지 미리 확인하는 식으로 활용하면 됩니다.
시간대 문제로 생기는 함정
변환 결과가 9시간 차이 나는 경험을 해봤다면 거의 100% 시간대 문제입니다. 타임스탬프 자체는 UTC지만, 변환 함수가 로컬 시간대로 자동 변환해주는 경우와 그렇지 않은 경우가 섞여 있기 때문입니다.
- 한국 표준시(KST)는 UTC보다 9시간 빠름 - 1731556800은 UTC 기준 2024-11-14 04:00이지만 KST로는 13:00
- 서버 로그가 UTC로 기록되는데 화면에는 KST로 표시되어야 한다면 변환 시점에 반드시 9시간을 가산
- JavaScript의 toISOString()은 UTC 반환, toLocaleString()은 브라우저 시간대 반환 - 둘을 혼동하면 안 됨
UTC와 KST 사이에서 변환 비율 계산이 필요할 때, 단순 시간 차이가 아니라 다른 단위의 비교가 들어가면 헷갈리기 쉽습니다. 예를 들어 어느 시간대 데이터가 전체의 몇 퍼센트인지 빠르게 따져봐야 한다면 퍼센트 계산기 같은 도구로 한번에 확인하면 시간을 아낄 수 있습니다.
실전 활용 사례와 주의사항
현업에서 타임스탬프 변환이 가장 많이 필요한 순간은 크게 네 가지입니다.
- 장애 분석 - 여러 서버 로그의 시점을 맞춰볼 때 모두 같은 단위로 변환해야 인과관계가 보임
- 데이터 정합성 검증 - DB에 저장된 created_at, updated_at 값이 비정상적이지 않은지 확인
- 마이그레이션 - 시스템 이관 시 시간대 설정이 다르면 전체 데이터의 시간이 어긋남
- API 연동 - 외부 서비스가 초 단위인지 밀리초 단위인지 문서를 반드시 확인
주의할 점은 2038년 문제입니다. 32비트로 저장되는 일부 옛 시스템은 2038년 1월 19일 이후의 타임스탬프를 표현하지 못합니다. 신규 시스템은 대부분 64비트로 처리하지만, 레거시 시스템을 다룬다면 이 부분을 점검해두는 게 좋습니다.
지금 다루고 있는 로그나 데이터가 있다면 그 안의 타임스탬프 한 줄을 골라 직접 변환해보세요. 자릿수 확인 → 단위 판단 → 시간대 보정 순서를 한번만 손에 익히면, 다음부터는 숫자만 봐도 대략의 시각이 머릿속에 들어옵니다.
