에포크 시간이란 무엇일까 - 유닉스 타임스탬프 개념과 변환 방법 완벽 정리
개발자라면 한 번쯤 마주치는 1735689600 같은 숫자, 사실 1970년부터 흘러간 초를 의미합니다. 에포크 시간 개념과 실무 변환법을 정리했습니다.
웹 개발이나 데이터베이스를 다루다 보면 1735689600처럼 알 수 없는 숫자를 자주 만나게 됩니다. 처음 보면 무슨 의미인지 짐작조차 어렵지만, 사실 이 숫자에는 시간이 담겨 있습니다. 컴퓨터가 시간을 다루는 가장 기본적인 방식이 바로 에포크 시간입니다.
에포크 시간이란 무엇인가
에포크 시간(Epoch Time)은 1970년 1월 1일 0시 0분 0초(UTC)부터 현재까지 흘러간 초의 누적값입니다. 유닉스 시간(Unix Time) 또는 POSIX 시간이라고도 부르며, 컴퓨터 내부에서 시간을 표현하는 표준 방식 중 하나입니다.
예를 들어 2026년 1월 1일 0시(UTC) 시점의 에포크 시간은 1767225600입니다. 이 숫자는 1970년 1월 1일부터 약 56년 동안 흘러간 초의 합계입니다. 컴퓨터 입장에서는 연도, 월, 일, 시, 분, 초를 따로 저장하는 것보다 하나의 정수로 시간을 다루는 것이 훨씬 효율적입니다.
왜 1970년 1월 1일이 기준이 되었을까
1970년이라는 시점은 임의로 정해진 것이 아니라 유닉스 운영체제 개발 시기와 맞물려 있습니다. 1969년 켄 톰슨과 데니스 리치가 유닉스를 개발하면서, 시스템이 다룰 수 있는 가장 낮은 정수값을 시작점으로 삼는 것이 합리적이라고 판단했습니다. 그 결과 1970년 1월 1일 자정(UTC)이 모든 컴퓨터 시간의 출발점이 되었습니다.
에포크 시간은 인간이 읽기에는 어렵지만 컴퓨터가 가장 빠르게 처리할 수 있는 형태이며, 시간대(Timezone) 변환 시에도 혼란이 없는 절대 기준점 역할을 합니다.
에포크 시간이 사용되는 이유와 활용 분야
에포크 시간은 단순한 정수이기 때문에 여러 가지 강력한 장점을 가집니다. 사람이 읽기에는 다소 불친절하지만, 시스템 사이에서는 가장 안전하게 시간 정보를 주고받을 수 있는 형식입니다.
- 시간대 독립성: UTC 기준 단일 값이므로 서울, 뉴욕, 런던 어디서든 같은 숫자를 공유할 수 있습니다.
- 연산 효율성: 두 시점 사이의 차이를 단순 뺄셈으로 구할 수 있습니다.
- 저장 공간 절약: 32비트 또는 64비트 정수 하나면 충분합니다.
- 정렬과 비교 편의성: 숫자 크기 비교만으로 시간 순서를 판별할 수 있습니다.
실제로 에포크 시간은 다음과 같은 분야에서 광범위하게 사용됩니다.
| 분야 | 사용 목적 | 대표 예시 |
|---|---|---|
| 웹 개발 | 로그인 토큰 만료 시각 표현 | JWT의 exp 클레임 |
| 데이터베이스 | 레코드 생성/수정 시각 저장 | created_at 컬럼 |
| 로그 시스템 | 이벤트 발생 시점 기록 | 서버 액세스 로그 |
| API 통신 | 요청 시각 검증과 서명 | HMAC 서명 timestamp |
| 금융 시스템 | 거래 시각 정렬 | 주문 체결 순서 |
에포크 시간 변환 방법 정리
실무에서는 사람이 읽을 수 있는 날짜와 에포크 시간을 자주 변환해야 합니다. 주요 프로그래밍 언어와 데이터베이스에서 다음과 같이 처리할 수 있습니다.
JavaScript
Math.floor(Date.now() / 1000)으로 현재 에포크 초를 얻을 수 있습니다. Date.now()는 밀리초 단위이므로 1000으로 나눠야 일반적인 에포크 초가 됩니다. 반대로 숫자를 날짜 객체로 변환할 때는 new Date(epoch * 1000)을 사용합니다.
Python
import time; time.time()은 부동소수점 형태로 현재 시각을 반환합니다. 정수가 필요하면 int(time.time())으로 변환합니다. 날짜 객체로 바꾸려면 datetime.fromtimestamp(epoch)을 사용하면 됩니다.
MySQL
SELECT UNIX_TIMESTAMP()로 현재 에포크 시간을 조회할 수 있고, FROM_UNIXTIME(epoch)으로 사람이 읽을 수 있는 날짜로 바꿀 수 있습니다. 반대 변환에는 UNIX_TIMESTAMP('2026-04-29 12:00:00') 형태를 사용합니다.
2038년 문제와 시스템의 한계
에포크 시간을 32비트 부호 있는 정수로 저장하는 시스템은 2038년 1월 19일 03시 14분 07초(UTC)에 한계에 도달합니다. 이 시점에 정수가 오버플로우되어 음수로 바뀌면서 시간이 1901년으로 돌아가는 현상이 발생합니다. 이를 Y2K38 문제 또는 유닉스 종말의 해(Year 2038 Problem)라고 부릅니다.
다행히 현대의 64비트 시스템은 이 문제에서 자유롭습니다. 64비트 정수가 표현할 수 있는 시간 범위는 약 2920억 년이기 때문에 사실상 영구적으로 사용할 수 있습니다. 하지만 일부 임베디드 장비, 오래된 데이터베이스 컬럼, 레거시 코드에는 여전히 32비트 시간 값이 남아 있을 수 있어 미리 점검이 필요합니다.
실무에서 자주 마주치는 문제와 해결법
에포크 시간을 다루다 보면 단위 혼동, 시간대 오류, 윤초 처리 같은 함정을 만나기 쉽습니다. 자주 발생하는 문제를 미리 알고 있으면 디버깅 시간을 크게 줄일 수 있습니다.
- 밀리초/초 단위 혼동: 1735689600과 1735689600000은 같은 시각을 가리키지만 단위가 다릅니다. API 명세를 반드시 확인합니다.
- 로컬 시간대 적용 누락: 에포크는 UTC 기준이므로 화면 표시 시 사용자의 시간대(한국이면 KST, UTC+9)로 변환해야 합니다.
- 윤초(Leap Second) 무시: POSIX 표준은 윤초를 카운트하지 않습니다. 정확한 천문학적 시간이 필요한 곳에는 부적합할 수 있습니다.
실무 작업을 할 때는 에포크 변환 사이트나 유틸리티를 한두 개 즐겨찾기에 등록해 두면 편리합니다. 비슷하게 자주 쓰이는 개발 보조 도구로는 비밀번호 생성기처럼 무료로 즉시 결과를 받을 수 있는 웹 유틸리티가 있어 함께 북마크해두면 작업 효율을 끌어올릴 수 있습니다.
에포크 시간은 처음에는 낯설지만, 한 번 익숙해지면 시간대 혼동 없이 시간을 다룰 수 있는 강력한 도구가 됩니다. 자주 쓰는 변환 함수를 노트에 정리해 두시고, 32비트 한계가 있는 컬럼이 프로젝트에 남아 있는지 한 번 점검해 보시길 권장합니다.
