Unix 타임스탬프란? 날짜 변환 방법과 2038년 문제

API 응답에 "created_at": 1709251200이라고 찍혀 있다. 이 숫자만 보고 "2024년 3월 1일"이라는 걸 바로 알아채기는 어렵다. Unix 타임스탬프는 1970년 1월 1일 00:00:00 UTC부터 경과한 초(second) 수를 의미하는데, 사람이 읽으려면 변환 과정이 필요하다.

왜 이런 방식을 쓸까

날짜를 "2024-03-01 09:00:00" 같은 문자열로 저장하면 시간대(timezone) 처리가 복잡해진다. 서울에서 오전 9시는 런던에서 자정이고, 뉴욕에서는 전날 오후 7시다. 타임스탬프는 시간대와 무관하게 하나의 숫자로 특정 시점을 표현할 수 있다. 비교 연산(어느 쪽이 먼저인지)도 숫자 크기만 비교하면 되니까 빠르다.

초 단위와 밀리초 단위의 차이

자릿수만 봐도 어느 단위인지 구분할 수 있다. 10자리면 초, 13자리면 밀리초다.

변환이 필요한 실무 상황

• DB 조회 결과 확인 — 저장된 타임스탬프가 어느 날짜인지 확인할 때
• API 디버깅 — 요청/응답에 포함된 시간값을 사람이 읽을 수 있는 형태로 바꿀 때
• 로그 분석 — 서버 로그의 epoch 시간을 날짜로 변환해서 시간대별 패턴 파악
• 테스트 데이터 생성 — 특정 날짜에 해당하는 타임스탬프를 만들어야 할 때

타임스탬프 변환기에서 숫자를 넣으면 로컬 시간, UTC, ISO 8601 형식으로 동시에 보여준다. 반대로 날짜를 입력해서 타임스탬프를 얻을 수도 있고, 현재 시간의 타임스탬프도 실시간으로 확인된다.

2038년 문제는 뭔가

32비트 시스템에서 Unix 타임스탬프는 부호 있는 정수(signed int)로 저장된다. 최대값이 2,147,483,647이고, 이 값은 2038년 1월 19일 03:14:07 UTC에 해당한다. 이 시점을 넘기면 정수 오버플로우가 발생해서 날짜가 1901년으로 돌아가는 버그가 생긴다.

참고 대부분의 최신 시스템은 이미 64비트 정수를 사용하므로 2038년 문제가 발생하지 않는다. 하지만 임베디드 장비나 레거시 시스템에서는 여전히 대비가 필요하다.

타임스탬프는 개발자가 거의 매일 마주치는 형식이다. 변환기를 즐겨찾기에 넣어두면 디버깅 시간을 꽤 줄일 수 있다.