유닉스 타임스탬프란? 에포크 시간 이해와 변환

로그 파일을 들여다보거나 API 응답을 받아 보면 1700000000 같은 정체 모를 숫자가 시간 자리에 들어 있는 경우가 많습니다. 사람이 읽기 좋은 "2023년 11월 15일"이 아니라 그냥 큰 정수 하나로 시각을 표현한 것인데, 이것이 바로 유닉스 타임스탬프입니다. 컴퓨터끼리 시간을 주고받을 때는 이렇게 숫자 하나로 다루는 편이 훨씬 단순하고 오류도 적기 때문에, 거의 모든 프로그래밍 언어와 데이터베이스가 이 방식을 기본으로 씁니다. 이 글에서는 유닉스 타임스탬프가 무엇을 의미하는지, 왜 초와 밀리초를 헷갈리면 안 되는지, 타임존은 어떻게 처리해야 하는지, 그리고 한 번쯤 들어봤을 2038년 문제까지 차근차근 정리합니다. 숫자와 날짜를 직접 바꿔 보고 싶다면 유닉스 타임스탬프 변환 도구를 함께 열어 두고 읽으면 이해가 훨씬 빠릅니다.

한눈에 보기

• 유닉스 타임스탬프는 1970년 1월 1일 00:00:00 UTC(에포크)부터 흐른 초의 개수입니다.
• 값이 0이면 1970년, 약 17억(예: 1700000000)이면 2023년경입니다.
• 자바스크립트 Date.now()는 밀리초(초 × 1000)를 돌려주므로 서버·DB의 초 단위와 섞으면 1000배 오차가 납니다.
• 타임스탬프 값 자체는 UTC 기준이라 타임존과 무관하며, 화면에 표시할 때만 지역 시간대로 변환합니다.
• 32비트 정수로 저장하면 2038년 1월 19일에 오버플로가 발생하는데, 64비트로 저장하면 해결됩니다.

유닉스 타임스탬프란 무엇인가

유닉스 타임스탬프(Unix timestamp)는 1970년 1월 1일 00:00:00 UTC라는 기준 시점에서부터 지금까지 흐른 초의 개수입니다. 이 기준 시점을 에포크(epoch)라고 부르며, 그래서 "에포크 시간(epoch time)" 또는 "POSIX 시간"이라는 이름으로도 불립니다. 시간을 연·월·일·시·분·초처럼 여러 단위로 쪼개지 않고 단 하나의 정수로 표현한다는 점이 핵심입니다.

예를 들어 값이 0이라면 정확히 1970년 1월 1일 자정(UTC)을 가리킵니다. 값이 약 17억, 즉 1700000000 정도라면 2023년 11월경에 해당합니다. 매초 1씩 증가하므로 1년은 약 3,150만 초이고, 50년이 조금 넘게 쌓이면서 오늘날 10자리 정수가 된 것입니다. 이렇게 숫자 하나로만 다루면 시간대나 달력 규칙을 신경 쓰지 않고도 두 시각의 선후 관계를 단순한 크기 비교로 판단할 수 있고, 두 값을 빼기만 하면 경과 시간(초)을 바로 얻을 수 있습니다. 데이터베이스 정렬, 만료 시간 계산, 로그 정리 같은 작업이 간단해지는 이유입니다.

초 vs 밀리초, 단위를 꼭 구분하기

타임스탬프를 다룰 때 가장 흔하게 겪는 실수가 초와 밀리초를 혼동하는 것입니다. 전통적인 유닉스 타임스탬프와 대부분의 서버·데이터베이스는 초 단위(10자리)를 사용하지만, 자바스크립트는 다릅니다. Date.now()나 new Date().getTime()은 에포크 이후 흐른 밀리초를 돌려주므로, 초에 1000을 곱한 13자리 값(예: 1700000000000)이 나옵니다.

문제는 단위를 잘못 맞췄을 때 오류가 곧바로 드러나지 않는다는 점입니다. 밀리초 값을 초로 착각해 그대로 변환하면 5만 년 뒤의 엉뚱한 날짜가 나오고, 반대로 초 값을 밀리초로 다루면 1970년 근처의 시각으로 계산됩니다. 그래서 값을 받으면 자릿수를 먼저 확인하고, 초 ↔ 밀리초 변환은 1000으로 나누거나 곱해 명시적으로 맞춰야 합니다. 헷갈릴 때는 유닉스 타임스탬프 변환 도구에 숫자를 그대로 넣어 사람이 읽는 날짜로 바꿔 보면 단위가 맞는지 단번에 검증할 수 있습니다.

타임존은 어떻게 처리할까

여기서 많은 사람이 오해하는 부분이 있습니다. 타임스탬프 값 자체에는 타임존 정보가 들어 있지 않습니다. 유닉스 타임스탬프는 언제나 UTC(협정 세계시) 기준으로 흐른 초이기 때문에, 서울에서 만들든 뉴욕에서 만들든 같은 순간이라면 정확히 같은 숫자가 됩니다. 즉 타임스탬프는 시간대와 무관한 "절대 시각"입니다.

타임존이 개입하는 시점은 오직 그 숫자를 사람에게 보여줄 때뿐입니다. 같은 1700000000이라도 한국 시간(KST, UTC+9)으로는 2023년 11월 15일 오전 6시 13분, UTC로는 같은 날 오후 9시 13분처럼 표시 결과가 달라집니다. 따라서 저장과 계산은 타임존 없는 타임스탬프(또는 UTC)로 일관되게 하고, 변환과 출력 단계에서만 사용자의 지역 시간대를 적용하는 것이 안전합니다. 이렇게 하면 서버 위치나 사용자 위치가 어디든 데이터의 의미가 흔들리지 않습니다.

2038년 문제

마지막으로 알아 둘 것이 2038년 문제입니다. 과거 많은 시스템은 타임스탬프를 32비트 부호 있는 정수에 저장했습니다. 이 자료형이 담을 수 있는 최댓값이 약 21억 4천만(2,147,483,647)인데, 이 값에 도달하는 시점이 2038년 1월 19일입니다. 이 순간을 넘기면 정수가 오버플로되어 음수로 뒤집히고, 시각이 1901년 같은 엉뚱한 과거로 계산되어 버립니다. 2000년의 Y2K 문제와 비슷한 성격이라 "Y2K38"이라고도 부릅니다.

해결책은 단순합니다. 타임스탬프를 64비트 정수로 저장하면 됩니다. 64비트는 사실상 수천억 년을 표현할 수 있어 현실적으로 오버플로를 걱정할 필요가 없습니다. 오늘날 새로 만드는 시스템과 최신 운영체제, 데이터베이스는 대부분 64비트를 기본으로 쓰므로 안전하지만, 오래된 임베디드 장비나 레거시 코드에서는 여전히 점검이 필요합니다.

자주 묻는 질문

유닉스 타임스탬프와 에포크 시간은 다른 건가요? 같은 것을 가리키는 다른 이름입니다. 둘 다 1970년 1월 1일 00:00:00 UTC를 기준으로 흐른 초를 의미하며, POSIX 시간이라는 표현도 함께 쓰입니다.

받은 숫자가 초인지 밀리초인지 어떻게 구분하나요? 자릿수로 짐작할 수 있습니다. 현재 시점 기준으로 초 단위는 10자리, 밀리초 단위는 13자리입니다. 확실히 하려면 유닉스 타임스탬프 변환 도구에 넣어 나오는 날짜가 현재와 비슷한지 확인하면 됩니다.

타임스탬프에는 왜 타임존을 같이 저장하지 않나요? 타임스탬프 자체가 이미 UTC 기준의 절대 시각이라 타임존이 필요 없기 때문입니다. 지역 시간대는 화면에 표시할 때만 적용하면 되고, 저장·계산 단계에서는 단일 기준을 유지하는 편이 오류를 줄입니다.

2038년 문제는 지금 내 서비스에도 영향이 있나요? 64비트 정수를 사용하는 최신 환경이라면 사실상 영향이 없습니다. 다만 32비트로 시간을 저장하는 오래된 시스템이나 임베디드 장비를 쓴다면 미리 64비트로 전환해 두는 것이 안전합니다.

음수 타임스탬프도 가능한가요? 가능합니다. 에포크인 1970년 이전 시각은 음수로 표현됩니다. 예를 들어 1969년의 어떤 시각은 0보다 작은 값을 가집니다.

마무리

유닉스 타임스탬프는 "1970년부터 흐른 초"라는 단순한 약속 하나로 전 세계 컴퓨터가 시간을 일관되게 주고받게 해 주는 표준입니다. 초인지 밀리초인지 단위만 정확히 맞추고, 저장은 UTC 기준으로 하되 표시할 때만 지역 시간대를 적용한다는 원칙을 지키면 대부분의 시간 관련 버그를 피할 수 있습니다. 실제 값을 날짜로, 또는 날짜를 값으로 바꿔 봐야 할 때는 유닉스 타임스탬프 변환 도구를 활용해 빠르고 정확하게 확인해 보세요.