유닉스 시간

유닉스 시간(Unix time) 또는 에포크 시간(Epoch time), POSIX 시간은 1970년 1월 1일 00:00:00 UTC를 기준으로 경과한 초를 정수로 표현하는 시간 표현 방식이다. 컴퓨터계에서 가장 널리 사용되는 시간 표현 방식 중 하나로, 컴퓨터 시스템과 네트워크 장비의 시계 동기화, 로그 기록, 파일 시스템의 타임스탬프 등 다양한 용도로 활용된다.

개요

유닉스 시간은 단순한 정수 계산 방식을 사용하기 때문에 복잡한 날짜 및 시간 연산을 매우 효율적으로 처리할 수 있다. 또한 전 세계적으로 통일된 기준(UTC)을 사용하므로 지역 간 시간 차이 문제를 크게 줄여준다. 현대의 거의 모든 운영체제와 프로그래밍 언어, 데이터베이스가 이 시간 표현 방식을 지원한다.

탄생 배경

1960년대 후반, AT&T 벨 연구소의 연구원들은 유닉스 운영체제를 개발하면서 시간을 표현하는 방식을 고민했다. 당시 컴퓨터는 하드웨어 자원이 매우 제한적이었기 때문에, 날짜와 시간을 복잡한 자료구조 대신 단순한 정수로 표현하여 메모리와 연산 자원을 절약하고자 했다. 켄 톰프슨(Ken Thompson)과 데니스 리치(Dennis Ritchie)를 포함한 연구진은 1970년 1월 1일 자정(UTC)을 기준점으로 삼아 시간이 흐를수록 1씩 증가하는 단순한 카운터를 구현했다. 이것이 바로 유닉스 시간의 시작이었다.

기준점 선택의 이유

1970년이라는 시점이 선택된 것에는 몇 가지 실용적인 이유가 있었다:

• 당시 유닉스 개발자들이 사용하던 PDP-11 컴퓨터의 32비트 signed int 자료형으로 표현할 수 있는 과거와 미래의 시점을 균형있게 나누기 위해서였다.
• 1970년은 유닉스 개발이 본격화된 시기와 가까웠다.
• 컴퓨터 시스템에서 일반적으로 다룰 필요가 있는 대부분의 날짜가 1970년 이후였다.

작동 원리

기본 개념

유닉스 시간은 기본적으로 1970년 1월 1일 00:00:00 UTC로부터 경과된 초의 수를 정수로 표현한다. 예를 들어:

• 유닉스 시간 0 = 1970년 1월 1일 00:00:00 UTC
• 유닉스 시간 1 = 1970년 1월 1일 00:00:01 UTC
• 유닉스 시간 60 = 1970년 1월 1일 00:01:00 UTC
• 유닉스 시간 86400 = 1970년 1월 2일 00:00:00 UTC (하루는 86,400초)

만약 1970년 1월 1일 이전의 날짜를 표현하려면 음수 초 단위 값으로 표현하면 된다:

• 1969년 12월 31일 23:59:59 UTC → -1
• 1969년 12월 31일 00:00:00 UTC → -86400 (하루 전, 1일 = 86400초)
• 1960년 1월 1일 00:00:00 UTC → -315532800
• 1900년 1월 1일 00:00:00 UTC → -2208988800

시스템 구현

실제 컴퓨터 시스템에서 유닉스 시간은 다음과 같은 방식으로 구현된다:

하드웨어 레벨

• RTC(Real-Time Clock): 대부분의 컴퓨터는 배터리로 작동하는 실시간 시계를 내장하고 있어, 시스템 전원이 꺼져있을 때도 시간을 계속 추적한다.
• 시스템 타이머: 운영체제는 하드웨어 타이머 인터럽트를 사용해 시간을 추적하며, 보통 100Hz~1000Hz 주파수로 동작한다.
• TSC(Time Stamp Counter): 현대의 CPU들은 프로세서 클럭 틱을 카운트하는 특수 레지스터를 가지고 있어, 매우 정밀한 시간 측정이 가능하다.

소프트웨어 레벨

• 커널 타임키핑: 운영체제 커널은 하드웨어 타이머 인터럽트를 받을 때마다 내부 시간 카운터를 업데이트한다.
• time_t 자료형: C 언어와 POSIX 시스템에서는 time_t라는 특별한 자료형을 사용해 유닉스 시간을 저장한다.
• 고정밀 확장: 현대 시스템에서는 timeval, timespec 등의 구조체를 사용해 마이크로초, 나노초 단위의 정밀한 시간 측정을 지원한다.

활용 분야

시스템 관리

로그 관리

• syslog: 유닉스/리눅스 시스템의 표준 로깅 시스템으로, 모든 로그 항목에 유닉스 시간 기반 타임스탬프를 부여한다.
• audit 로그: 시스템 보안 감사 로그도 유닉스 시간을 사용해 이벤트의 정확한 발생 시점을 기록한다.
• 애플리케이션 로그: 대부분의 서버 애플리케이션(웹 서버, 데이터베이스 등)이 로그 기록에 유닉스 시간을 사용한다.

파일 시스템

• inode 타임스탬프: 유닉스 계열 파일 시스템은 각 파일의 생성 시간(ctime), 수정 시간(mtime), 접근 시간(atime)을 유닉스 시간으로 저장한다.
• 백업 시스템: 증분 백업 시 파일의 변경 여부를 판단하는 기준으로 타임스탬프를 사용한다.
• 버전 관리: git 같은 버전 관리 시스템에서 커밋 시간을 기록하는 데 유닉스 시간이 사용된다.

네트워크 프로토콜

인터넷 프로토콜

• NTP(Network Time Protocol): 컴퓨터 간 시간 동기화에 사용되는 프로토콜로, 유닉스 시간을 기준으로 동작한다.
• HTTP: 웹 프로토콜의 Last-Modified, If-Modified-Since 등 시간 관련 헤더가 유닉스 시간을 사용한다.
• DNS: 도메인 네임 시스템의 리소스 레코드 TTL(Time To Live)이 유닉스 시간 기반으로 계산된다.

보안 프로토콜

• SSL/TLS: 인증서의 유효 기간과 만료 시간이 유닉스 시간으로 표현된다.
• 토큰 기반 인증: JWT(JSON Web Token) 등에서 토큰의 발급 시간과 만료 시간을 표현하는 데 사용된다.
• Kerberos: 티켓 발급 시간과 만료 시간을 유닉스 시간으로 관리한다.

데이터베이스

관계형 데이터베이스

• MySQL: TIMESTAMP, DATETIME 타입이 내부적으로 유닉스 시간으로 변환되어 저장된다.
• PostgreSQL: timestamp 타입이 유닉스 시간을 기반으로 구현되어 있다.
• SQLite: datetime 함수들이 유닉스 시간을 기준으로 동작한다.

NoSQL 데이터베이스

• MongoDB: ObjectId가 생성 시간을 유닉스 시간으로 포함한다.
• Redis: 만료 시간(TTL) 설정에 유닉스 시간이 사용된다.
• Cassandra: 타임스탬프 컬럼이 유닉스 시간을 저장한다.

문제점과 한계

2038년 문제

개요

32비트 signed int를 사용하는 시스템에서 유닉스 시간은 2038년 1월 19일 03:14:07 UTC에 최댓값(2,147,483,647)에 도달한다. 이후의 시간은 표현할 수 없어 오버플로우가 발생하며, 시스템은 1901년으로 돌아가거나 오작동할 수 있다.

영향받는 시스템

• 임베디드 시스템: 많은 임베디드 기기가 여전히 32비트 아키텍처를 사용한다.
• 레거시 시스템: 오래된 운영체제나 소프트웨어 중 일부가 아직도 32비트 time_t를 사용한다.
• 산업용 장비: 장기간 운영되는 산업 설비의 제어 시스템이 영향을 받을 수 있다.

해결 방안

• 64비트 마이그레이션: 대부분의 현대 시스템은 64비트 time_t를 사용하도록 전환되었다.
• 소프트웨어 업데이트: 운영체제와 애플리케이션의 시간 처리 로직을 64비트로 수정한다.
• 하드웨어 교체: 32비트 임베디드 시스템을 64비트 시스템으로 교체한다.

윤초 문제

발생하는 문제

• 시간 불일치: 윤초가 추가될 때 유닉스 시간과 UTC 사이에 1초의 차이가 발생한다.
• 시스템 오작동: 일부 시스템에서는 윤초 추가 시점에 버그가 발생할 수 있다.
• 동기화 문제: 여러 시스템 간의 시간 동기화가 일시적으로 어긋날 수 있다.

대처 방안

• 윤초 스미어링: 구글은 윤초를 하루에 걸쳐 점진적으로 적용하는 방식을 사용한다.
• 윤초 무시: 일부 시스템은 윤초를 완전히 무시하고 나중에 NTP로 보정한다.
• TAI 사용: 일부 과학 기술 분야에서는 윤초가 없는 국제원자시(TAI)를 사용한다.