본문 바로가기

에포크 시간이란? 유닉스 타임스탬프 개념과 변환 방법, 실무 활용까지 완벽 정리

로그와 API에서 만나는 열 자리 숫자의 정체. 1970년 기준 시간 개념부터 언어별 변환법, 2038년 문제까지 한 번에 이해합니다.


에포크 시간이란? 유닉스 타임스탬프 개념과 변환 방법, 실무 활용까지 완벽 정리

로그 파일을 열었더니 날짜 자리에 1719500400 같은 숫자가 찍혀 있어 당황한 적 있으신가요. 개발 문서나 API 응답에서 이런 열 자리 숫자를 만나면 도대체 언제를 가리키는지 감이 오지 않습니다. 이 숫자가 바로 에포크 시간입니다.

에포크 시간이란 무엇인가

에포크 시간은 1970년 1월 1일 00시 00분 00초(UTC)를 기준점으로 삼아, 그 시점부터 흐른 시간을 초 단위로 센 값입니다. 유닉스 운영체제에서 처음 쓰기 시작해 유닉스 타임스탬프(Unix Timestamp) 또는 포식스 시간(POSIX Time)이라고도 부릅니다.

기준점인 1970년 1월 1일을 에포크(epoch), 우리말로 기원 혹은 기준 시점이라고 합니다. 예를 들어 값이 0이면 정확히 1970년 1월 1일 0시를 의미합니다. 1719500400은 그로부터 약 17억 초가 지난 2024년 6월 27일 무렵을 가리킵니다.

에포크 시간은 사람이 읽기 위한 형식이 아니라 컴퓨터가 시간을 다루기 위한 형식입니다. 사람에게는 불친절하지만 기계에게는 가장 단순하고 정확한 시간 표현입니다.

에포크 시간을 사용하는 이유

왜 굳이 읽기 어려운 숫자를 쓸까요. 시간을 하나의 정수로 표현하면 여러 이점이 생기기 때문입니다.

  • 시간대 문제가 사라집니다. 에포크 시간은 항상 UTC 기준 절대값이라 서울이든 뉴욕이든 같은 순간은 같은 숫자입니다.
  • 계산이 단순합니다. 두 시점의 차이를 구할 때 그냥 숫자를 빼면 초 단위 간격이 나옵니다. 월말이나 윤년을 따로 따질 필요가 없습니다.
  • 저장과 비교가 효율적입니다. 문자열 날짜보다 정수가 용량도 작고 정렬과 비교 속도도 빠릅니다.
참고: 자바스크립트는 초가 아니라 밀리초(1000분의 1초) 단위를 씁니다. 그래서 Date.now()는 열세 자리 숫자를 반환합니다. 다른 언어의 열 자리 초 단위 값과 혼동하면 1000배 차이가 나므로 주의해야 합니다.

에포크 시간 변환 방법

에포크 시간과 사람이 읽는 날짜는 양방향으로 변환할 수 있습니다. 대표적인 값을 표로 정리했습니다.

에포크 시간(초)UTC 기준 날짜한국 시간(KST)
01970-01-01 00:00:001970-01-01 09:00:00
10000000002001-09-09 01:46:402001-09-09 10:46:40
17000000002023-11-14 22:13:202023-11-15 07:13:20
21474836472038-01-19 03:14:072038-01-19 12:14:07

한국 시간은 UTC보다 9시간 빠르므로, UTC 값에 9시간을 더하면 됩니다. 온라인 에포크 변환기를 쓰면 숫자를 붙여넣는 것만으로 바로 날짜를 확인할 수 있습니다.

프로그래밍 언어별 에포크 시간 다루기

현재 시각의 에포크 값을 얻는 방법은 언어마다 조금씩 다릅니다. 단위가 초인지 밀리초인지가 핵심입니다.

언어현재 에포크 구하기반환 단위
JavaScriptMath.floor(Date.now()/1000)밀리초 → 초 변환
Pythonimport time; time.time()초(소수점 포함)
PHPtime()
JavaSystem.currentTimeMillis()밀리초
MySQLUNIX_TIMESTAMP()
팁: 서로 다른 시스템을 연동할 때는 초 단위인지 밀리초 단위인지 먼저 확인하세요. 값이 열 자리면 초, 열세 자리면 밀리초일 가능성이 높습니다. 이 한 가지만 맞춰도 시간이 1970년이나 수만 년 후로 튀는 버그를 막을 수 있습니다.

2038년 문제와 주의사항

에포크 시간을 32비트 부호 있는 정수로 저장하는 시스템은 2038년 1월 19일 03시 14분 07초(UTC)까지만 표현할 수 있습니다. 이 값이 2147483647인데, 1초만 더 지나면 정수가 넘쳐 음수로 바뀌면서 시간이 1901년으로 되돌아갑니다. 이것을 2038년 문제(Y2038)라고 부릅니다.

대부분의 현대 시스템은 64비트 정수로 전환해 이 문제를 해결했습니다. 64비트라면 약 2920억 년까지 표현할 수 있어 사실상 걱정할 필요가 없습니다. 다만 오래된 임베디드 장비나 레거시 데이터베이스는 여전히 점검이 필요합니다.

실무에서 자주 묻는 질문

에포크 시간을 고유 식별자로 써도 될까요

로그 순번처럼 대략적인 정렬에는 쓸 수 있지만, 완전한 고유값으로는 부족합니다. 같은 밀리초에 여러 요청이 들어오면 값이 겹치기 때문입니다. 충돌 없는 식별자가 필요하다면 UUID 생성기로 만든 고유 ID를 함께 쓰는 편이 안전합니다.

왜 하필 1970년이 기준인가요

1970년대 초 유닉스를 개발하던 시점에 가까운 기준점이 필요했고, 계산 편의상 1970년 1월 1일이 채택되었습니다. 특별한 역사적 의미가 있다기보다 실용적인 선택이었습니다.

음수 에포크 시간도 있나요

네. 1970년 이전 시점은 음수로 표현합니다. 예를 들어 1969년 12월 31일 0시는 -86400(하루 전, 즉 마이너스 8만 6400초)입니다.

에포크 시간은 한 번 개념을 잡아 두면 로그 분석, API 연동, 데이터 정렬에서 두고두고 쓰입니다. 낯선 열 자리 숫자를 만나면 온라인 변환기에 넣어 날짜를 확인하는 습관부터 들이고, 시스템을 만들 때는 초와 밀리초 단위를 명확히 구분해 두세요. 텍스트를 다루다 분량이 궁금할 때 쓰는 글자수 세기 같은 도구처럼, 에포크 변환기도 즐겨찾기에 하나 넣어 두면 작업이 한결 수월해집니다.

3일 무료체험큰손탐지기, 지금 바로 시작하세요

설치 없이 웹에서 바로 사용 가능 · PC & 모바일 지원

무료체험 시작
카카오톡 상담