날씨 정보를 불러오는 중...

리눅스 시간 동기화 완벽 가이드 - NTP vs Chrony 비교 및 설치·설정 방법

2026-09-04 06:32 · IT기술 · 조회 42
리눅스 Chrony NTP 시간 동기화 가이드

리눅스 시간 동기화 완벽 가이드 – NTP와 Chrony 비교, 개념부터 설치·설정까지

서버 시간이 몇 초만 틀어져도 로그 순서가 뒤섞이고, TLS 인증서 검증이 실패하고, 분산 DB나 클러스터 노드 간 정합성이 깨질 수 있습니다. 그래서 리눅스 서버에는 반드시 시간 동기화 데몬이 떠 있어야 하는데, 예전에는 ntpd를 주로 썼다면 요즘 배포판(RHEL 8/9, CentOS Stream, Ubuntu 최신 버전 등)은 기본값으로 chrony를 채택하고 있습니다. 이 글에서는 시간 동기화가 왜 필요한지 개념부터, 기존 NTP(ntpd)와 chrony가 무엇이 다른지, 그리고 실제 리눅스 서버에 chrony를 설치·설정하고 정상 동작을 검증하는 방법까지 명령어 단위로 정리했습니다.

1. 시간 동기화 개념 – NTP란 무엇인가

개념 NTP(Network Time Protocol)

NTP는 인터넷상의 표준 시각 서버(원자시계·GPS 기반)와 통신해 로컬 서버의 시계를 맞추는 표준 프로토콜입니다. 여러 대의 상위 서버(Stratum)로부터 시각 정보를 받아 왕복 지연시간(RTT)과 오프셋을 계산하고, 자신의 시스템 클럭을 점진적으로 보정합니다. 서버는 계층 구조(Stratum 0~15)로 구성되는데, Stratum 0은 원자시계/GPS 자체, Stratum 1은 그것과 직접 연결된 서버, 내 서버는 보통 Stratum 2~3 서버를 참조하게 됩니다.

시간 동기화가 실무에서 중요한 이유

  1. 로그/감사 추적 – 여러 서버의 로그를 시간 순으로 취합·분석할 때 시각이 어긋나면 장애 원인 분석 자체가 불가능해집니다.
  2. 인증/보안 – TLS 인증서 유효기간 검증, Kerberos 인증(허용 오차 보통 5분)은 시각이 틀어지면 곧바로 실패합니다.
  3. 분산 시스템 정합성 – 클러스터, 분산 DB, 메시지 큐 등에서 이벤트 순서 판단에 시각을 사용하는 경우가 많아 오차가 곧 데이터 정합성 문제로 이어집니다.

2. 기존 방식 – ntpd

NTP ntpd의 특징

1980년대부터 쓰여온 전통적인 구현체로, 오랫동안 리눅스의 기본 시간 동기화 데몬이었습니다. 안정적이지만 다음과 같은 한계가 있습니다.

  1. 상위 서버와의 오프셋이 128ms를 넘으면 즉시 보정(step)하지 않고 서서히(slew) 조정하는 알고리즘이라, 초기 동기화나 네트워크가 끊겼다 복구된 직후처럼 오차가 크게 벌어진 상황에서는 시각이 맞기까지 시간이 오래 걸립니다.
  2. 네트워크가 자주 끊기는 환경(노트북, 간헐적 연결 서버)이나 가상머신처럼 호스트가 일시 정지(suspend)되었다가 재개되는 환경에는 잘 대응하지 못합니다.
  3. 설정 문법이 상대적으로 오래되고 복잡하며, 최신 보안 기능(NTS 등)을 기본 지원하지 않습니다.

3. Chrony란? – 왜 최신 배포판의 기본값이 되었나

Chrony Chrony의 설계 목표

Chrony는 ntpd의 한계를 보완하기 위해 나온 후속 구현체로, RHEL 7부터 기본 시간 동기화 데몬으로 채택되었고 현재 대부분의 주요 배포판에서 표준으로 쓰입니다. 초기 동기화 속도가 훨씬 빠르고, 네트워크 단절/가상화 환경 같은 불안정한 조건에서도 강건하게 동작하도록 설계되었습니다.

4. NTP(ntpd) vs Chrony 비교

비교 항목별 차이

  1. 초기 동기화 속도 – ntpd: 서서히 보정해 시간이 오래 걸림 / Chrony: 오프셋이 크면 즉시 스텝 보정해 훨씬 빠르게 정확한 시각에 도달
  2. 간헐적 네트워크 대응 – ntpd: 연결이 자주 끊기면 정확도가 떨어짐 / Chrony: 짧은 접속 구간에서도 통계적으로 더 정확하게 오프셋을 추정하도록 설계됨
  3. 가상화/절전 환경 – ntpd: VM 일시정지·재개, 절전 후 복귀 상황에 취약 / Chrony: 이런 상황을 감지해 빠르게 재보정
  4. 서버 없이도 동작(랙 없는 오프라인 환경) – ntpd: 상위 서버가 없으면 사실상 대기 상태 / Chrony: local stratum 설정으로 자체 시각을 기준으로 로컬 클라이언트에 시간을 배포 가능
  5. 보안 – ntpd: 레거시 인증 방식 위주 / Chrony: 최신 NTS(Network Time Security) 지원, 권한 분리(privilege drop) 설계로 공격 표면이 더 작음
  6. 설정 파일/명령어 – ntpd: ntp.conf, ntpq / Chrony: chrony.conf, chronyc로 훨씬 직관적인 대화형 명령 제공
  7. 기본 채택 현황 – RHEL/CentOS Stream 8·9, Rocky/Alma Linux, 최신 Ubuntu LTS 모두 기본 데몬을 chrony로 전환한 상태

5. 리눅스에 Chrony 설치 및 설정하기

설치 1단계. 설치

# RHEL / CentOS Stream / Rocky / Alma Linux
sudo dnf install -y chrony

# Ubuntu / Debian
sudo apt update && sudo apt install -y chrony

2단계. 서비스 활성화

# RHEL 계열 서비스명: chronyd
sudo systemctl enable --now chronyd
sudo systemctl status chronyd

# Ubuntu/Debian 계열 서비스명: chrony
sudo systemctl enable --now chrony
sudo systemctl status chrony

3단계. 설정 파일 수정

설정 파일 위치는 RHEL 계열은 /etc/chrony.conf, Ubuntu/Debian 계열은 /etc/chrony/chrony.conf입니다. 기본 pool 설정을 지우고 국내에서 응답 속도가 빠른 NTP 서버로 교체하는 예시입니다.

sudo vi /etc/chrony.conf
# 기존 pool/server 라인은 주석 처리하고 아래처럼 국내 NTP 서버 지정 (iburst로 초기 동기화 가속)
server time.bora.net iburst
server time.kriss.re.kr iburst
pool 2.kr.pool.ntp.org iburst

# 측정 로그/통계 파일을 남길 디렉터리
logdir /var/log/chrony
log measurements statistics tracking

서버 4단계. (선택) 이 서버를 NTP 서버로도 쓰고 싶을 때

내부망의 다른 서버/장비가 이 리눅스 서버를 시간 기준으로 참조하게 하려면 allow로 대상 대역을 허용합니다.

# 사내망 192.168.0.0/24 대역에게 시간 응답을 허용
allow 192.168.0.0/24

# 상위 서버로 나가는 인터넷이 끊겨도 로컬 클럭 기준으로 하위 클라이언트에 계속 응답 (Stratum 10으로 표시)
local stratum 10
# 설정 반영을 위해 재시작
sudo systemctl restart chronyd   # Ubuntu는 chrony

5단계. 방화벽에서 NTP(UDP 123) 허용

# firewalld (RHEL 계열)
sudo firewall-cmd --add-service=ntp --permanent
sudo firewall-cmd --reload

# ufw (Ubuntu)
sudo ufw allow 123/udp

6. 정상 동작 확인 및 테스트 방법

테스트 동기화 상태 확인 명령어

# 현재 동기화 상태 요약 (System time 오프셋, Stratum, Leap status 확인)
chronyc tracking

결과 중 System time 값이 몇 초 이상 차이 나면 아직 동기화가 덜 된 상태이고, Leap status : Normal이면 정상입니다.

# 참조 중인 NTP 서버 목록과 각 서버와의 오프셋 확인
chronyc sources -v
  1. Reach 컬럼이 377(8진수, 최근 3회 응답 모두 성공)에 가까울수록 안정적으로 통신 중이라는 뜻입니다.
  2. ^* 표시가 붙은 줄이 현재 실제로 동기화 기준으로 선택된 서버입니다.
  3. Offset 값이 크게 흔들리는 서버는 네트워크 품질이 불안정하다는 신호입니다.
# 각 소스별 오프셋 추이 통계 (장기 안정성 확인)
chronyc sourcestats -v

# systemd 관점의 시간 동기화 상태 요약
timedatectl status

강제로 즉시 보정해보기 (테스트용)

# 일부러 시각을 어긋나게 한 뒤 정상화되는지 확인해보는 실습
sudo date -s "2020-01-01 00:00:00"
chronyc tracking          # System time 오프셋이 크게 벌어진 것을 확인

# 즉시 스텝 방식으로 강제 보정
sudo chronyc makestep
chronyc tracking          # 오프셋이 정상 범위로 돌아왔는지 재확인

7. 운영 팁 및 주의사항

체크 실무 적용 시 챙길 것들

  1. ntpd와 동시 실행 금지 – 같은 서버에 ntpd와 chronyd가 동시에 떠 있으면 UDP 123 포트 충돌이 나므로, 전환 시 반드시 sudo systemctl disable --now ntpd로 기존 서비스를 먼저 내리세요.
  2. 가상머신 시각 드리프트 – 하이퍼바이저 자체 시간 동기화 기능(VMware Tools, qemu-guest-agent 등)과 chrony를 동시에 쓰면 서로 충돌해 시계가 튈 수 있으니, VM에서는 보통 하이퍼바이저 시간 동기화를 끄고 chrony만 쓰는 것이 권장됩니다.
  3. NTS(암호화 인증) 적용 검토 – 외부 공용 NTP 서버를 신뢰하기 어려운 보안 민감 환경이라면 chrony 4.0 이상에서 지원하는 NTS를 적용해 시간 정보 위변조를 방지할 수 있습니다.

주의 흔히 하는 실수

  1. 설정 파일만 고치고 서비스 재시작을 잊는 경우 – chronyc sources로 반영 여부를 꼭 재확인하세요.
  2. 사내망 NTP 서버 역할까지 맡길 때 allow 대역을 빠뜨려 클라이언트가 계속 Reach = 0으로 뜨는 경우.
  3. 컨테이너 안에서 chronyd를 별도로 띄우려는 경우 – 컨테이너는 보통 호스트 커널 시계를 그대로 공유하므로, 시간 동기화는 호스트에서만 한 번 하면 충분합니다.

마무리

Chrony는 기존 ntpd보다 초기 동기화가 빠르고 불안정한 네트워크·가상화 환경에 훨씬 강건하게 대응하도록 설계되어, 이제는 사실상 리눅스 시간 동기화의 표준으로 자리 잡았습니다. 새로 서버를 구축한다면 굳이 ntpd를 쓸 이유가 없고, 기존에 ntpd를 쓰고 있었다면 이번 기회에 chrony로 전환해보시길 권합니다. 설치 후에는 반드시 chronyc tracking과 chronyc sources -v로 실제 동기화 상태를 눈으로 확인하는 습관을 들이세요.

댓글 0

로그인 후 댓글을 작성할 수 있습니다.