유닉스 타임스탬프 변환기
유닉스 타임스탬프(에포크)를 현지 시간, UTC, ISO 8601 형식의 읽기 쉬운 날짜로 바꾸거나, 반대로 날짜를 타임스탬프로 변환하세요. 초 단위와 밀리초 단위를 모두 지원합니다.
—
밀리초: —
ISO 8601: —
에포크 값을 붙여넣으세요. 타임스탬프가 밀리초 단위라면 토글을 전환하세요.
날짜와 시간을 선택하면 유닉스 타임스탬프가 생성됩니다.
유닉스 타임스탬프 변환기 사용 방법
- 1
타임스탬프 입력
‘타임스탬프를 날짜로’ 입력란에 유닉스 타임스탬프를 입력하거나 붙여넣고, 값에 맞게 초 / 밀리초 토글을 전환하세요.
- 2
날짜 확인
해당 시각을 현지 시간대, UTC, ISO 8601 문자열, 그리고 ‘3시간 전’과 같은 상대 시간으로 확인하세요.
- 3
날짜를 다시 변환
‘날짜를 타임스탬프로’ 선택기에서 원하는 날짜와 시간을 고르면 초 단위와 밀리초 단위의 에포크 값을 얻을 수 있습니다.
- 4
결과 복사
아무 값에서나 복사를 누르면 클립보드에 저장되어 코드, 데이터베이스 쿼리, API 요청에 바로 붙여넣을 수 있습니다.
개발자를 위한 유닉스 시간 해설
유닉스 타임스탬프란
유닉스 타임스탬프는 특정 시점을 나타내는 하나의 숫자로, 유닉스 에포크 이후 경과한 초의 수를 뜻합니다. 유닉스 에포크란 1970년 1월 1일 자정(UTC)을 말합니다. 예를 들어 타임스탬프 1700000000은 2023년 11월 14일 22:13:20 UTC에 해당합니다. 단 하나의 숫자가 날짜와 시간을 모호함 없이 온전히 담아냅니다.
단순히 위로 증가하는 정수일 뿐이기에, 유닉스 시간은 저장하고 정렬하고 비교하기가 무척 간편합니다. 한 타임스탬프에서 다른 타임스탬프를 빼면 두 사건 사이의 정확한 초 수를 얻을 수 있습니다. 이러한 단순함 덕분에 유닉스 시간은 파일 수정 시각부터 인증 토큰에 이르기까지 컴퓨팅의 수많은 영역을 떠받치고 있습니다.
왜 1970년인가
1970년이라는 에포크는 당시 벨 연구소(Bell Labs)에서 개발 중이던 유닉스 운영체제에서 비롯된 역사적 산물입니다. 엔지니어들에게는 시스템 시계의 고정된 기준점이 필요했고, 마침 작업하던 그 십 년의 시작점은 깔끔하고 편리한 선택이었습니다. 이 기준은 그대로 자리 잡았고, 수십 년이 지난 지금도 사실상 모든 플랫폼에서 표준으로 남아 있습니다.
1970년 자체에 수학적으로 특별한 의미가 있는 것은 아닙니다. 그저 모두가 공유하는 0점일 뿐입니다. 중요한 것은 모두가 이 기준에 동의한다는 사실입니다. 이렇게 공통된 기준이 있기에, 한 컴퓨터에서 생성된 타임스탬프를 제조사나 언어, 위치와 상관없이 다른 어떤 컴퓨터에서도 정확히 해석할 수 있습니다.
초 단위와 밀리초 단위
전통적인 유닉스 시간은 초 단위로 측정하지만, 많은 최신 환경에서는 시간을 더 정밀하게 표현하기 위해 밀리초 단위를 사용합니다. 예를 들어 자바스크립트의 Date.now는 밀리초를 반환합니다. 실용적인 구분 방법은 자릿수를 세어 보는 것입니다. 현재 시점을 초 단위로 나타내면 10자리이지만, 같은 시점을 밀리초 단위로 나타내면 13자리로, 약 1,000배 더 큽니다.
두 단위를 혼동하는 것은 흔히 발생하는 버그입니다. 초를 기대하는 함수에 밀리초 값을 넣으면 날짜가 수만 년 뒤 미래로 튀어 버리고, 반대로 하면 1970년 부근으로 되돌아갑니다. 변환된 날짜가 터무니없어 보인다면 먼저 단위부터 확인하세요. 이 도구의 초 / 밀리초 토글은 바로 그 혼란을 클릭 한 번으로 해결하기 위해 마련되어 있습니다.
UTC와 현지 시간
유닉스 타임스탬프 자체에는 시간대가 담겨 있지 않습니다. 지구 어디에서나 동일한 순간을 가리키며, 도쿄에 있든 뉴욕에 있든 그 숫자는 똑같습니다. 시간대는 그 순간을 사람이 읽을 수 있는 날짜로 변환할 때 비로소 개입하며, 그래서 같은 타임스탬프라도 지역에 따라 서로 다른 벽시계 시각으로 표시됩니다.
이 변환기는 두 가지 형태를 모두 보여 줍니다. 하나는 사용자 기기의 시간대로 표시한 현지 시간이고, 다른 하나는 보편적 기준인 UTC입니다. 타임스탬프를 UTC로 저장하고 전송한 뒤 화면에 표시할 때만 현지 시간으로 변환하는 것이 표준적인 방식이며, 이렇게 하면 특히 일광 절약 시간제(서머타임) 전환 무렵에 자주 생기는, 시간이 몇 시간씩 어긋나는 부류의 버그를 통째로 막을 수 있습니다.
2038년 문제
오래된 시스템 다수는 유닉스 시간을 부호 있는 32비트 정수로 저장하는데, 이 정수가 담을 수 있는 최댓값은 2,147,483,647입니다. 이 한계는 2038년 1월 19일 03:14:07 UTC에 도달합니다. 그로부터 1초 뒤 카운터는 오버플로되어 한 바퀴 돌아 큰 음수가 되고, 해당 시스템은 이를 1901년의 어느 날짜로 해석해 버립니다.
이는 2000년 문제(Y2K)가 현대에 되풀이되는 셈이며, 임베디드 기기와 레거시 데이터베이스, 그리고 여전히 32비트 시간을 사용하는 모든 코드를 위협합니다. 해결책은 더 넓은 64비트 정수에 시간을 저장하는 것으로, 이렇게 하면 한계가 수천억 년 뒤로 밀려납니다. 이 도구 자체는 32비트 시간이 아니라 자바스크립트의 내장 날짜 처리 기능을 사용해 브라우저에서 실행되므로, 2038년을 훌쩍 넘긴 날짜도 문제없이 변환합니다.
양방향 변환
타임스탬프를 날짜로 바꾼다는 것은 그 숫자를 에포크 이후의 초로 보고 에포크에 더한다는 뜻입니다. 그 반대로 날짜를 타임스탬프로 바꾸는 것은 에포크와 해당 시점 사이에 몇 초가 놓여 있는지를 계산하는 일입니다. 이 변환기는 두 가지를 모두 해냅니다. 에포크 값을 붙여넣어 그 날짜를 확인하거나, 선택기에서 날짜를 골라 그 타임스탬프를 얻을 수 있습니다.
‘3시간 전’과 같은 상대 시간 표시는 현재 시점에서 타임스탬프를 빼고 그 간격을 평이한 말로 풀어낸 것입니다. 값을 한눈에 점검하기에 편리한데, 2년 뒤 미래에서 왔다고 주장하는 로그 항목이라면 누가 봐도 의심스럽기 때문입니다.
유닉스 시간을 만나게 되는 곳
유닉스 타임스탬프는 소프트웨어 곳곳에 존재합니다. 서버 로그는 사건을 정확한 순서로 정렬할 수 있도록 각 줄에 타임스탬프를 찍습니다. REST API는 언어에 중립적이고 간결하다는 이유로 created_at이나 expires_at 같은 필드에 타임스탬프를 담아 반환합니다. 데이터베이스는 정렬과 기간 범위 조회에 타임스탬프를 사용하고, JWT는 만료 시각을 유닉스 타임스탬프로 인코딩합니다.
개발자와 분석가에게 이러한 값을 빠르게 읽어 내는 일은 매일같이 필요한 작업입니다. API 응답을 디버깅하거나 로그 파일을 훑어보거나 토큰이 언제 만료되는지 확인할 때, 원시 숫자를 변환기에 넣기만 하면 알아보기 힘든 정수가 의미를 헤아릴 수 있는 날짜로 바뀝니다. 그것도 현지 시간과 UTC, 초 단위와 밀리초 단위로 모두 말입니다.
자주 묻는 질문
유닉스 타임스탬프란 무엇인가요?
내 타임스탬프는 초 단위인가요, 밀리초 단위인가요?
이 변환기는 어떤 시간대를 사용하나요?
2038년 문제란 무엇인가요?
내 데이터가 서버로 전송되나요?
관련 도구
이런 편리한 도구도 함께 사용해 보세요