이 글의 목적은 Windows·Linux 환경에서 시간 동기화가 틀어져 인증이 실패하는 문제를 정확히 진단하고, NTP 서버 재구성 및 강제 동기화를 통해 안정적으로 복구하는 실무 절차를 제공하는 것이다.
1. 시간 동기화 오류가 왜 인증 실패로 이어지는가
대부분의 현대 인증 프로토콜은 “시간”을 보안 요소로 활용한다. 토큰 유효 기간, 재생 공격 방지, 세션 만료 판단 등에서 시스템 시간이 기준이 되기 때문이다. 따라서 서버와 클라이언트 사이의 시간이 일정 범위를 벗어나면 인증 자체가 실패하거나, 정상 계정임에도 로그인 거부가 발생한다.
대표적인 예는 다음과 같다.
- 도메인 환경의 Kerberos 인증: 기본적으로 클라이언트와 도메인 컨트롤러(DC) 간 시간 차이가 ±5분 이상이면 인증이 거부된다.
- 웹 서비스의 TLS/SSL: 시스템 시간이 과거·미래로 크게 벗어나면 인증서의 유효 기간 검사에 실패하여 “보안 연결 실패”가 발생한다.
- 클라우드·SSO·OAuth2·SAML: 액세스 토큰, ID 토큰의 발급·만료 시간 검증 시 시스템 시간이 어긋나면 “토큰 만료” 또는 “발급 시간 오류”로 로그인 실패가 발생한다.
주의 : 인증 오류 메시지에 “시간”, “클럭”, “토큰 만료”, “증명서 유효 기간” 등의 단어가 보이면, 네트워크·계정 문제만 의심하지 말고 반드시 시스템 시간 동기화 상태를 함께 점검해야 한다.
2. 시간 동기화 이상 징후와 증상 정리
시간이 틀어져 있을 때 현장에서 자주 관찰되는 증상은 다음과 같다.
- 특정 PC에서만 도메인 로그인 실패, 다른 PC는 정상이다.
- 사내 웹 포털 또는 SSO 페이지에서 “토큰이 만료되었거나 아직 유효하지 않습니다”라는 메시지가 반복된다.
- 클라이언트에서 “서버 인증서가 아직 유효하지 않습니다” 또는 “유효 기간이 지났습니다” 오류가 발생한다.
- 이벤트 로그에 Kerberos 오류, 시간 불일치(Time Skew), NTP 동기화 실패 메시지가 다수 기록된다.
- 서버·클라이언트 시계를 비교하면 수분~수십 분 이상 차이가 난다.
이러한 증상이 하나 이상 관찰된다면, NTP 구성 및 시간 동기화 상태를 최우선으로 점검해야 한다.
3. 현재 시간 상태와 NTP 동기화 상태 진단
시간 문제가 의심될 때는 “눈으로 시계를 보는 것”과 “OS 수준 동기화 상태를 확인하는 것”을 모두 수행해야 한다.
3.1 Windows에서 시간·NTP 상태 확인
3.1.1 UI에서 기본 시간 확인
- 우측 하단 트레이 시계 표시 시간을 확인한다.
- 스마트폰 또는 인터넷 시계(예: 다른 정상 서버)와 비교하여 분 단위 이상 차이가 나는지 확인한다.
3.1.2 w32tm 명령으로 NTP 동기화 상태 확인
관리자 권한 PowerShell 또는 명령 프롬프트에서 다음 명령을 실행한다.
w32tm /query /status 확인해야 할 주요 항목은 다음과 같다.
- Source: 현재 동기화 대상(예: time.windows.com, 도메인 컨트롤러 FQDN 등)이다.
- Stratum: 시간 계층 수준이다. 1에 가까울수록 원본 시계에 가깝다.
- Last Successful Sync Time: 마지막 성공 동기화 시각이다.
- Clock Offset: 기준 서버와의 시간 차이다.
구성 정보를 더 자세히 보려면 다음 명령을 사용한다.
w32tm /query /configuration 3.1.3 이벤트 로그로 오류 코드 확인
시간 관련 오류는 이벤트 뷰어에서 확인할 수 있다.
eventvwr.msc실행- Windows 로그 > 시스템 이동
- 소스가 W32Time 또는 Time-Service인 이벤트를 필터링하여 오류/경고를 확인한다.
여기서 “시간 서비스가 구성된 시간 원본과 동기화할 수 없습니다”, “시간이 크게 변했습니다”와 비슷한 메시지가 반복된다면 NTP 구성이 잘못되었거나 네트워크 차단(UDP 123 포트) 가능성이 있다.
3.2 Linux에서 시간·NTP 상태 확인
3.2.1 timedatectl로 전체 상태 확인
systemd 기반 배포판(Ubuntu, CentOS 7+, RHEL 7+, Debian 등)에서 다음 명령을 사용한다.
timedatectl 확인할 항목은 다음과 같다.
- Local time: 현재 시스템 시간이다.
- RTC time: 하드웨어(BIOS/UEFI) 시계이다.
- NTP service: NTP 동기화 서비스 활성 여부이다.
- System clock synchronized: 실제 동기화 성공 여부이다.
3.2.2 chrony 또는 ntpd 상태 확인
Chrony 사용 시:
chronyc tracking chronyc sources -v NTPD 사용 시:
ntpq -p 출력에서 시간 서버 목록, 지연(latency), 오프셋(offset), 동기화 여부를 확인한다.
주의 : Linux에서 여러 NTP 데몬(systemd-timesyncd, chronyd, ntpd)을 동시에 켜두면 충돌이 발생할 수 있다. 하나의 NTP 솔루션만 활성화하고 나머지는 중지 및 비활성화하는 것이 좋다.
4. Windows 환경에서 NTP 서버 재구성 및 강제 동기화
Windows는 기본적으로 Windows Time 서비스(W32Time)를 통해 NTP 동기화를 수행한다. 도메인 환경인지, 단독(Workgroup) PC인지에 따라 구성 방식이 조금 달라진다.
4.1 Workgroup(단독 PC)에서 공용 NTP 서버로 재설정
인터넷에 연결된 일반 PC의 경우 공용 NTP 서버(time.windows.com, 국가별 pool.ntp.org 등)를 사용하는 것이 일반적이다.
관리자 권한으로 다음 명령을 실행한다.
net stop w32time
w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /update
net start w32time
w32tm /resync /force
명령 의미는 다음과 같다.
net stop/start w32time: 시간 서비스 재시작이다./manualpeerlist: 사용할 NTP 서버 목록을 지정한다. 여러 서버를 사용할 경우 공백으로 구분한다.0x9플래그: NTP 클라언트 모드 및 특수 폴 기능을 함께 사용한다./syncfromflags:manual: 수동 정의한 서버 목록에서만 동기화한다.w32tm /resync /force: 즉시 동기화를 강제로 수행한다.
주의 : 방화벽 또는 보안 장비에서 UDP 123 포트가 차단되어 있으면 NTP 동기화가 실패한다. 외부 NTP를 사용할 때는 해당 포트가 개방되어 있는지 반드시 확인해야 한다.
4.2 도메인 환경에서 도메인 컨트롤러(NTP 기준) 재구성
Active Directory 도메인 환경에서는 PDC 에뮬레이터 역할을 가진 도메인 컨트롤러가 전체 도메인의 시간 기준이 된다. 먼저 PDC에서 외부 또는 상위 NTP 서버와 정확히 동기화되도록 설정한 후, 도메인 내 다른 서버와 클라이언트는 도메인 계층 구조(domhier)에서 시간 정보를 받도록 구성하는 것이 원칙이다.
4.2.1 PDC 에뮬레이터에서 시간 서버 설정
PDC 역할을 가진 DC에서 관리자 권한으로 다음 명령을 실행한다.
net stop w32time
w32tm /config /manualpeerlist:"0.kr.pool.ntp.org 1.kr.pool.ntp.org" ^
/syncfromflags:manual /reliable:yes /update
net start w32time
w32tm /resync /force
/reliable:yes: 이 서버를 도메인 내에서 신뢰할 수 있는 시간 소스로 표시한다.0.kr.pool.ntp.org등은 지역별 NTP 풀을 예시로 사용한 것이다. 조직 정책에 맞는 상위 NTP 서버를 지정한다.
4.2.2 도메인 멤버 서버·클라이언트에서 도메인 계층으로 동기화
도메인에 가입된 서버·클라이언트에서는 별도 공용 NTP를 지정하지 않고, 도메인 계층에서 시간 정보를 받도록 설정해야 한다. 다음 명령을 사용한다.
net stop w32time
w32tm /config /syncfromflags:domhier /update
net start w32time
w32tm /resync /force
이 설정 후, 클라이언트는 가장 가까운 도메인 컨트롤러로부터 시간 정보를 자동으로 수신한다.
주의 : 도메인에 가입된 Windows 클라이언트가 외부 공용 NTP 서버와 직접 동기화하도록 설정하면 시간 계층이 꼬이고 Kerberos 인증 오류가 발생할 수 있다. 도메인 환경에서는 “PDC DC → 기타 DC → 도메인 멤버” 구조를 유지해야 한다.
4.3 Windows 설정(UI)에서 시간 동기화 실행
명령어 사용이 익숙하지 않은 상황에서는 UI 기반으로 기본 동기화를 시도할 수 있다.
- 설정 > 시간 및 언어 > 날짜 및 시간으로 이동한다.
- 시간 자동 설정, 시간대 자동 설정을 켠다.
- “지금 동기화” 버튼이 있는 경우 클릭하여 즉시 동기화를 수행한다.
단, UI 설정은 근본적인 NTP 서버 변경·도메인 계층 구성 등 고급 설정을 모두 다루지 못하므로, 인증 문제 해결 단계에서는 명령어를 병행하는 것이 좋다.
5. Linux 환경에서 NTP 서버 재구성
Linux에서는 systemd-timesyncd, chrony, ntpd 등 여러 방식으로 시간 동기화를 수행한다. 배포판과 환경에 맞는 한 가지 방식을 선택하여 구성해야 한다.
5.1 systemd-timesyncd 사용 환경
5.1.1 기본 활성화 및 NTP 서버 설정
먼저 서비스 활성 상태를 확인한다.
sudo systemctl status systemd-timesyncd 비활성 상태라면 다음 명령으로 활성화한다.
sudo systemctl enable --now systemd-timesyncd 이후 구성 파일을 편집한다.
sudo nano /etc/systemd/timesyncd.conf 아래와 같이 NTP 항목을 설정한다.
[Time] NTP=0.kr.pool.ntp.org 1.kr.pool.ntp.org FallbackNTP=time.google.com time.windows.com 저장 후 서비스를 재시작한다.
sudo systemctl restart systemd-timesyncd 동기화 상태를 확인한다.
timedatectl show-timesync timedatectl timesync-status 5.2 Chrony 기반 환경
5.2.1 Chrony 설치 및 구성
일반적으로 서버 환경에서는 Chrony를 많이 사용한다.
# Debian/Ubuntu sudo apt install chrony
RHEL/CentOS
sudo yum install chrony
설정 파일을 편집한다.
sudo nano /etc/chrony.conf 예시 설정은 다음과 같다.
server 0.kr.pool.ntp.org iburst server 1.kr.pool.ntp.org iburst server 2.kr.pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
저장 후 서비스를 재시작하고 동기화 상태를 확인한다.
sudo systemctl enable --now chronyd sudo systemctl restart chronyd
chronyc tracking
chronyc sources -v
5.3 ntpd 기반 환경
기존 환경에서 ntpd를 사용하는 경우 /etc/ntp.conf를 편집한다.
sudo nano /etc/ntp.conf 예시 설정은 다음과 같다.
server 0.kr.pool.ntp.org iburst server 1.kr.pool.ntp.org iburst server 2.kr.pool.ntp.org iburst
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
서비스를 재시작하고 서버 목록을 확인한다.
sudo systemctl enable --now ntpd sudo systemctl restart ntpd
ntpq -p
주의 : 가상머신(Guest OS)은 가상화 플랫폼(Hyper-V, VMware 등)의 시간 동기화 기능과 NTP 동기화를 동시에 사용할 때 시간이 튀는 현상이 발생할 수 있다. VM에서 NTP를 사용한다면 하이퍼바이저의 시간 동기화 옵션을 꺼서 충돌을 방지하는 것이 좋다.
6. 인증 오류 유형별 시간 동기화 점검 포인트
6.1 도메인 로그인·Kerberos 인증 실패
다음과 같은 증상이 있을 때는 Kerberos 시간 불일치를 의심해야 한다.
- 도메인 계정 로그인 시 “보안 데이터베이스에서 사용자 계정을 찾을 수 없습니다”와 유사한 메시지가 간헐적으로 발생한다.
- 특정 서버에만 RDP 연결 시 인증 오류가 발생하고, 다른 서버는 정상이다.
- 이벤트 로그에 Kerberos 관련 오류와 함께 “시간 차이(Time Skew)” 언급이 나온다.
이 경우 조치 순서는 다음과 같다.
- 문제가 발생하는 클라이언트와 DC의 시간을 눈으로 직접 비교한다.
- DC에서 외부 NTP 동기화 상태를 점검 및 재구성한다.
- 클라이언트에서
w32tm /config /syncfromflags:domhier /update후w32tm /resync /force를 실행한다. - 로그오프 후 재로그인하여 재현 여부를 확인한다.
6.2 TLS/SSL 인증서 오류
브라우저 또는 클라이언트 애플리케이션에서 다음과 같은 메시지가 나타날 수 있다.
- “인증서가 아직 유효하지 않습니다.”
- “인증서의 유효 기간이 만료되었습니다.”
- “보안 인증서의 날짜가 잘못되었습니다.”
실제로 서버 인증서가 정상인데 위 메시지가 나온다면 클라이언트 시스템의 날짜·시간이 과거 또는 미래로 크게 어긋난 경우가 많다. 이때는 먼저 클라이언트의 시간 동기화를 정상화한 뒤 인증을 다시 시도해야 한다.
6.3 클라우드·SSO·토큰 기반 인증 오류
Azure AD, Google Workspace, OpenID Connect, SAML 기반 SSO 등에서는 토큰의 iat(발급 시각), nbf(Not Before), exp(만료 시각)를 검증한다. 클라이언트 시간이 서버와 차이가 크면 토큰이 “아직 유효하지 않음” 또는 “이미 만료됨” 상태로 판단되어 로그인 실패가 발생한다.
이 경우에는 다음을 확인한다.
- 클라이언트 OS 시간 동기화 상태
- 프록시 또는 게이트웨이 서버의 시간
- SSO 서버·IdP 서버의 시간
토큰 기반 인증 환경에서는 “모든 주체(클라이언트·서버·게이트웨이·IdP)의 시간이 동일 기준으로 동기화되어 있는지”를 항상 확인해야 한다.
7. 시간 동기화 자동화·모니터링 실무 팁
7.1 Windows 그룹 정책으로 시간 설정 강제
도메인 환경에서는 그룹 정책(GPO)을 활용하여 시간 설정을 중앙에서 강제할 수 있다.
- 그룹 정책 관리 콘솔을 열고 도메인 또는 OU에 GPO를 링크한다.
- 컴퓨터 구성 > 관리 템플릿 > 시스템 > Windows Time 서비스에서 정책을 구성한다.
- 서비스 시작 유형, 구성 유형, NTP 서버 주소 등을 적절히 설정한다.
- 클라이언트에서
gpupdate /force후 재부팅하여 적용 여부를 확인한다.
7.2 Linux에서 주기적 확인 스크립트 활용
Linux 서버에서는 간단한 스크립트를 작성하여 오프셋이 일정 수준 이상 커질 경우 알람을 발생시키도록 구성할 수 있다.
예시(Chrony 사용 환경):
#!/bin/bash # /usr/local/bin/check_ntp_offset.sh
OFFSET=$(chronyc tracking | awk '/RMS offset/ {print $3}')
절대값 0.5초 이상이면 경고
LIMIT=0.5
awk -v off="$OFFSET" -v limit="$LIMIT" '
BEGIN {
if (off < -limit || off > limit) {
exit 1
}
}
' || echo "NTP offset warning: $OFFSET seconds"
이 스크립트를 크론(cron) 또는 모니터링 시스템(Nagios, Zabbix, Prometheus 등)에 연동하면 시간 동기화 상태를 지속적으로 감시할 수 있다.
7.3 하드웨어(RTC) 시계도 함께 점검
OS 시간은 부팅 시 하드웨어 시계(RTC)를 기준으로 설정된다. 만약 RTC가 심각하게 틀어져 있으면 부팅 직후부터 시간이 크게 어긋나게 된다. BIOS/UEFI 설정 화면에 들어가 실제 시간과 맞는지 확인하고, 장기간 전원이 끊어졌던 장비라면 보드의 CMOS 배터리 상태도 점검해야 한다.
8. 실무용 시간 동기화 점검 체크리스트
| 구분 | 점검 항목 | 점검 방법 | 기준/결과 | 점검 주기 |
|---|---|---|---|---|
| Windows 클라이언트 | 시스템 시간 오차 | 트레이 시계 vs 스마트폰 비교 | ±1분 이내 | 문제 발생 시, 분기 1회 |
| Windows 클라이언트 | NTP 동기화 상태 | w32tm /query /status | Source가 DC 또는 지정 NTP, 오차 수초 이내 | 문제 발생 시 |
| 도메인 컨트롤러 | 상위 NTP 서버 구성 | w32tm /query /configuration | PDC에서 외부 NTP로 동기화, /reliable:yes 설정 | 반기 1회 |
| Linux 서버 | NTP 서비스 상태 | systemctl status chronyd 또는 timedatectl | 활성(active), System clock synchronized=yes | 월 1회 |
| Linux 서버 | NTP 오프셋 | chronyc tracking / ntpq -p | 오프셋 절대값 0.5초 이내 | 월 1회 또는 모니터링 연동 |
| 공통 | 방화벽 포트 | 보안 장비 설정 확인 | 필요 시 UDP 123 허용 | 구성 변경 시 |
| 공통 | 가상화 환경 시간 정책 | 하이퍼바이저/게스트 설정 | 중복 동기화 기능 비활성화 | VM 신규 구축 시 |
FAQ
Q1. 시간이 조금만 틀어져 있어도 인증이 실패할 수 있는가?
도메인 Kerberos 기준으로는 기본 허용 오차가 약 ±5분이다. 그러나 토큰 기반 인증, 보안 정책, 애플리케이션 구현 방식에 따라 훨씬 엄격한 기준(수십 초 단위)을 적용하는 경우도 있다. 실무에서는 가능하면 초 단위까지 동기화가 맞도록 관리하는 것이 안전하다.
Q2. 도메인 환경에서 클라이언트를 외부 NTP 서버에 직접 붙여도 되는가?
권장되지 않는다. 도메인 환경에서는 PDC 에뮬레이터를 기준으로 한 시간 계층 구조를 유지해야 Kerberos 및 기타 도메인 서비스가 안정적으로 동작한다. 클라이언트는 syncfromflags:domhier 설정으로 도메인 계층에서 시간 정보를 받도록 구성하는 것이 원칙이다.
Q3. 인터넷이 되지 않는 폐쇄망 환경에서는 어떻게 시간 동기화를 해야 하는가?
폐쇄망 환경에서는 외부 NTP 서버 대신 내부 기준 시간 서버(예: GPS 수신 장치가 연결된 타임 서버, 또는 관리자 지정 기준 서버)를 하나 선정한 뒤, 나머지 서버와 클라이언트가 해당 서버를 기준으로 동기화하도록 구성해야 한다. 이때 기준 서버의 하드웨어 시계와 안정성을 별도로 관리하는 것이 중요하다.
Q4. 수동으로 시간을 맞추면 안 되는가?
일시적인 테스트 목적이 아니라면 수동 시간 조정은 지양해야 한다. 사람이 직접 맞추면 시·분·초 단위 오차가 필연적으로 발생하고, 여러 서버에 일관되게 적용하기 어렵다. 또한 도메인 및 NTP 계층 구조를 깨뜨릴 수 있다. 항상 NTP 기반 자동 동기화를 사용하는 것이 바람직하다.
Q5. NTP 서버를 여러 개 등록하면 더 안전한가?
여러 개의 신뢰할 수 있는 NTP 서버를 등록하는 것은 가용성 측면에서 유리하지만, 품질이 떨어지는 서버를 섞어 넣으면 오히려 시간 오차가 커질 수 있다. 운영 정책에 따라 검증된 서버 몇 개만 선택하고, 동일 네트워크 내 장비들은 되도록 같은 기준 서버 집합을 사용하도록 통일하는 것이 좋다.