유닉스 타임스탬프 변환 완벽 가이드 - 개발자가 매일 쓰는 시간 형식 변환법
1970년부터 시작된 유닉스 타임스탬프, 왜 쓰고 어떻게 변환할까요. 초/밀리초 구분부터 실전 변환 방법까지 한번에 정리했습니다.
![]()
API 응답에서 1716508800 같은 숫자를 받아보고 당황한 경험이 있으신가요. 데이터베이스에 저장된 시간 값이 사람이 읽을 수 없는 정수로 되어 있어 답답했던 분도 많을 겁니다. 이 숫자가 바로 유닉스 타임스탬프입니다. 개발자라면 매일 마주치지만 의외로 정확한 개념과 변환 방법을 모르는 경우가 많습니다.
유닉스 타임스탬프 변환은 백엔드, 프론트엔드, 데이터 분석 어느 분야에서나 필수입니다. 잘못 변환하면 1000배 차이가 나거나 시간대가 9시간씩 어긋나는 사고가 발생합니다. 오늘은 이 개념을 처음부터 끝까지 명확하게 정리해드리겠습니다.
유닉스 타임스탬프란 무엇인가
유닉스 타임스탬프는 1970년 1월 1일 00:00:00 UTC부터 현재까지 경과한 초의 누적 값입니다. 이 기준점을 에포크(Epoch)라고 부릅니다. 예를 들어 1716508800이라는 숫자는 에포크로부터 약 17억 1650만 초가 지났다는 의미이며, 이를 변환하면 2024년 5월 24일 오전 9시(KST)가 됩니다.
왜 1970년부터 시작했을까
유닉스 운영체제가 1969년 벨 연구소에서 개발되었고, 시간 계산의 기준점을 깔끔한 날짜로 잡기 위해 1970년 1월 1일이 선택되었습니다. 그 이후 거의 모든 컴퓨터 시스템이 이 방식을 채택하면서 사실상 시간 처리의 국제 표준이 되었습니다.
유닉스 타임스탬프는 시간대(타임존)를 포함하지 않습니다. 항상 UTC 기준 절대 시간이며, 사용자에게 보여줄 때만 각 지역 시간대로 변환합니다.
왜 타임스탬프를 사용할까
왜 굳이 사람이 읽기 힘든 숫자 형태로 시간을 저장할까요. 이유는 명확합니다. 단순한 정수이기 때문에 비교, 정렬, 연산이 매우 빠릅니다. 두 시간의 차이를 구하려면 그냥 빼면 됩니다.
- 저장 효율 - 4바이트 또는 8바이트 정수로 모든 시간 표현 가능
- 시간대 무관 - 어느 나라에서 저장하든 동일한 값
- 비교 용이 - 단순 숫자 비교로 시간 선후 판단
- 호환성 - 거의 모든 프로그래밍 언어와 DB가 지원
일반 날짜 형식과 비교
| 구분 | 유닉스 타임스탬프 | ISO 8601 문자열 |
|---|---|---|
| 예시 | 1716508800 | 2024-05-24T00:00:00Z |
| 가독성 | 낮음 | 높음 |
| 저장 크기 | 4~8바이트 | 20바이트 이상 |
| 비교 속도 | 매우 빠름 | 상대적으로 느림 |
| 시간대 정보 | 없음(UTC) | 포함 가능 |
유닉스 타임스탬프 변환 방법 정리
언어별로 변환 방식이 조금씩 다르지만 원리는 같습니다. 자주 쓰는 변환 방법을 정리했습니다.
JavaScript에서 변환
JavaScript의 Date 객체는 밀리초 단위를 사용하므로 주의가 필요합니다. 일반 유닉스 타임스탬프(초 단위)를 변환할 때는 1000을 곱해야 합니다.
Python에서 변환
Python은 datetime과 time 모듈을 함께 사용합니다. time.time()으로 현재 타임스탬프를 얻고, datetime.fromtimestamp()로 사람이 읽는 형식으로 바꿉니다. 시간대를 명시하지 않으면 시스템 로컬 타임존이 적용되므로 서버 환경에서는 반드시 UTC를 명시하는 것이 안전합니다.
온라인 변환 도구
코드를 작성하지 않고 빠르게 확인하고 싶다면 온라인 변환 도구를 사용하는 것이 편합니다. 디버깅 중에 API 응답의 타임스탬프를 즉시 확인해야 할 때 특히 유용합니다. 비슷한 맥락에서 네트워크 디버깅 중에는 내 IP 주소 확인 같은 도구도 함께 쓰면 작업 효율이 올라갑니다.
초 단위와 밀리초 단위 구분하기
실무에서 가장 많이 실수하는 부분이 바로 이 지점입니다. 시스템마다 사용하는 단위가 달라서 1000배 차이가 발생합니다.
| 단위 | 자릿수 | 주요 사용처 |
|---|---|---|
| 초(Seconds) | 10자리 | Unix/Linux 시스템, PHP, Python time() |
| 밀리초(Milliseconds) | 13자리 | JavaScript, Java, Kotlin |
| 마이크로초 | 16자리 | 고정밀 로깅 시스템 |
| 나노초 | 19자리 | Go, 일부 DB 시스템 |
변환 시 1000을 곱할지 나눌지
밀리초를 초로 바꾸려면 1000으로 나누고, 초를 밀리초로 바꾸려면 1000을 곱합니다. 단순하지만 이 한 줄이 빠지면 1970년 1월 1일 같은 엉뚱한 날짜가 표시됩니다.
실무에서 자주 발생하는 실수
10년 차 개발자도 가끔 빠지는 함정이 있습니다. 미리 알아두면 디버깅 시간을 크게 줄일 수 있습니다.
- 시간대 누락 - UTC와 KST를 혼동하면 9시간 차이가 발생합니다
- 단위 혼동 - 초/밀리초 변환을 빠뜨리면 1970년 또는 먼 미래로 표시됩니다
- 2038년 문제 - 32비트 정수는 2038년 1월 19일 이후 표현이 불가능합니다
2038년 문제란
32비트 부호 있는 정수의 최대값이 약 21억이라서, 2038년 1월 19일 03:14:07 UTC를 지나면 오버플로우가 발생합니다. 이를 Y2K38 문제라고 부릅니다. 최신 시스템은 대부분 64비트 정수로 전환되었지만, 오래된 임베디드 시스템이나 레거시 코드에서는 여전히 주의해야 합니다.
시간대 처리 실수 사례
한국 시간으로 자정에 발생한 이벤트를 UTC 타임스탬프로 저장한 뒤, 다시 한국 시간으로 변환하지 않고 그대로 화면에 표시하면 전날 오후 3시로 보이게 됩니다. 데이터베이스에는 항상 UTC로 저장하고, 표시할 때만 사용자 시간대로 변환하는 원칙을 지키세요.
실전 활용 팁과 마무리
유닉스 타임스탬프는 익숙해지면 시간 처리가 훨씬 수월해집니다. 특히 여러 시간대를 다루는 글로벌 서비스나 로그 분석에서 그 진가가 발휘됩니다.
꼭 기억할 핵심 3가지
- 타임스탬프는 항상 UTC 기준 절대 시간입니다
- 자릿수로 초(10자리)와 밀리초(13자리)를 구분하세요
- 저장은 UTC로, 표시는 사용자 시간대로 분리하세요
개발 외 일상에서도 시간 계산이 필요한 순간이 많습니다. 대출 상환 일정이나 만기일 계산처럼 정확한 시간 연산이 필요할 때는 대출 계산기 같은 전용 도구를 활용하면 시간을 아낄 수 있습니다.
지금 다루고 있는 시간 관련 코드가 있다면, 단위와 시간대를 먼저 확인해보세요. 이 두 가지만 명확히 정리해도 시간 관련 버그의 80% 이상을 예방할 수 있습니다. 변환 도구를 북마크에 추가해두고 필요할 때마다 빠르게 확인하는 습관을 들이는 것을 추천합니다.