- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 도메인 환경에서 Windows 시간 서비스(W32Time)의 동기화 지연으로 발생하는 Kerberos 오류, 로그인 실패, GPO 적용 지연, 인증서 검증 실패를 줄이기 위해 폴링 주기와 관련 설정을 안전하게 커스터마이즈하는 방법을 실무 절차로 정리하는 것이다.
1. 도메인에서 “시간 지연”이 장애로 번지는 구조 이해
Active Directory 도메인에서는 클라이언트와 도메인 컨트롤러 간 시간이 일정 범위 이상 어긋나면 Kerberos 인증이 실패하기 쉽다. 이 문제는 단순히 “시간이 틀렸다” 수준이 아니라 로그온 지연, 파일 서버 접근 실패, 원격 데스크톱 인증 실패, 그룹 정책 처리 실패로 이어지기 쉽다.
도메인 시간 동기화는 일반적으로 “도메인 계층”을 따른다. 즉, 도메인 멤버는 도메인 컨트롤러에서 시간을 받고, 다른 도메인 컨트롤러는 PDC 에뮬레이터(PDC Emulator) 역할을 가진 DC를 기준으로 동기화하도록 설계되어 있다. 따라서 PDC 에뮬레이터의 시간원이 불안정하거나 폴링이 느리면 도메인 전체가 느리게 흔들리는 구조가 된다.
주의 : 도메인 멤버(일반 PC, 일반 서버)에 임의로 외부 NTP를 직접 물리면 계층이 깨져 문제가 더 커질 수 있다. 시간 커스터마이즈는 “PDC 에뮬레이터를 외부 시간원에 안정적으로 동기화”시키고 나머지는 도메인 계층을 따르게 하는 방식이 원칙이다.
2. 증상 체크리스트로 원인 범위 좁히기
2.1 대표 증상
- 사용자 로그온이 느리거나 간헐적으로 실패하다.
- 이벤트 뷰어에 Time-Service, W32Time, Kerberos 관련 경고가 반복된다.
- GPO가 즉시 적용되지 않고 재부팅 후에만 적용되는 듯 보인다.
- 서버 간 인증서 기반 통신(TLS)에서 “유효하지 않은 시간” 오류가 간헐적으로 발생한다.
- VPN, RDP, 파일 공유에서 인증 오류가 특정 시간대에 몰려 발생한다.
2.2 즉시 확인해야 하는 3가지
| 확인 항목 | 확인 방법 | 의미 |
|---|---|---|
| PDC 에뮬레이터가 누구인지 확인하다 | | 도메인 시간의 최상위 기준점을 확정하다 |
| 현재 동기화 원본과 상태를 확인하다 | | DOMHIER인지, MANUAL인지, 오프셋/폴링 상태를 확인하다 |
| 실제 오프셋을 측정하다 | | 체감 지연이 “네트워크 지연”인지 “시간 오프셋”인지 구분하다 |
3. W32Time 폴링 주기의 핵심 개념 정리
W32Time의 “폴링 주기”는 시간을 얼마나 자주 동기화하는지를 의미한다. 도메인 계층(도메인 멤버가 DC를 따라가는 모드)과, 특정 NTP 서버를 직접 지정하는 모드(수동 피어)에서 주기 제어 방식이 달라지는 점이 핵심이다.
3.1 도메인 계층 동기화(DOMHIER, NT5DS)의 특징
도메인 멤버는 기본적으로 도메인 컨트롤러를 통해 시간을 받는다. 이 모드에서는 운영체제가 네트워크/오프셋/안정성에 따라 폴링 주기를 동적으로 조절하는 경향이 있다. 따라서 “멤버 PC의 폴링을 억지로 과도하게 줄이는 방식”은 효과가 제한적이며, 오히려 PDC 에뮬레이터의 안정화가 우선이다.
3.2 수동 NTP 동기화(MANUAL)의 특징과 SpecialPollInterval
특정 NTP 서버를 직접 지정하면, SpecialPollInterval이라는 “초 단위 주기”를 사용하도록 구성할 수 있다. 즉, “몇 초마다”를 명확히 정하는 방식이 가능하다. 다만 너무 짧게 하면 NTP 서버 부하, 네트워크 노이즈, 이벤트 로그 폭증으로 운영 품질이 떨어질 수 있다.
주의 : 폴링 주기를 무작정 짧게 하는 것은 “정확도가 좋아지는 것”과 동의어가 아니다. 시간원 품질, 네트워크 지연, 가상화 시간 동기화 충돌을 먼저 정리한 뒤에 주기를 조정해야 한다.
3.3 MinPollInterval과 MaxPollInterval의 의미
MinPollInterval과 MaxPollInterval은 “초가 아니라 log2(초)” 기반 값으로 쓰이는 경우가 많다. 예를 들어 값이 6이면 2^6인 64초를 의미한다. 실무에서는 너무 공격적인 값으로 내리기보다, 목표 지연과 네트워크 안정성을 보고 점진적으로 조정하는 것이 안전하다.
4. 권장 아키텍처: PDC 에뮬레이터만 외부 NTP를 사용하다
도메인 안정성을 최우선으로 보면 다음 구조가 기본이다.
- PDC 에뮬레이터는 외부(또는 사내 Stratum 1/2) NTP에 동기화하도록 구성하다.
- 다른 DC는 PDC 에뮬레이터를 도메인 계층으로 따라가도록 유지하다.
- 도메인 멤버는 DC를 도메인 계층으로 따라가도록 유지하다.
| 대상 | 동기화 방식 | 주기 커스터마이즈 포인트 | 운영 포인트 |
|---|---|---|---|
| PDC 에뮬레이터 | 외부 NTP(MANUAL) 권장이다 | SpecialPollInterval, 보정 한계값 조정이 핵심이다 | 시간원의 품질과 접근성, 방화벽 UDP 123을 보장하다 |
| 기타 DC | 도메인 계층(DOMHIER/NT5DS) 권장이다 | 필요 시 폴링 범위는 제한적으로 조정하다 | PDC 변경, 사이트 간 복제 지연을 함께 점검하다 |
| 도메인 멤버 | 도메인 계층(DOMHIER/NT5DS) 원칙이다 | 멤버는 과도한 주기 튜닝보다 원인 제거가 우선이다 | 가상화 시간 동기화 충돌을 우선 제거하다 |
5. PDC 에뮬레이터에서 “폴링 주기 커스터마이즈” 실전 절차
5.1 외부 NTP 피어 목록을 구성하다
PDC 에뮬레이터에서 아래 형태로 외부 NTP 서버를 지정하다. 운영 환경에서는 최소 2개 이상을 권장하다.
w32tm /config /manualpeerlist:"ntp1.example.com,0x8 ntp2.example.com,0x8" /syncfromflags:manual /reliable:yes /update여기서 0x8은 클라이언트 모드로 질의하는 플래그로 쓰이는 구성이며, 실무에서 가장 널리 쓰이는 형태로 운영되는 경우가 많다.
5.2 SpecialPollInterval로 주기를 “초 단위”로 지정하다
수동 피어를 쓰는 경우, SpecialPollInterval을 초 단위로 정할 수 있다. 예를 들어 900초는 15분이다. 지연이 큰 환경에서는 900~3600초 범위를 시작점으로 두고, 이벤트 로그와 오프셋 안정성을 보며 조정하는 접근이 안전하다.
| 목표 | 권장 시작 주기 | 설명 |
|---|---|---|
| 일반 사무/서버 도메인 | 3600초(60분)이다 | 대부분의 환경에서 충분히 안정적이다 |
| 지연/드리프트가 체감되는 환경 | 900~1800초(15~30분)이다 | 서버 부하와 로그량을 관찰하며 접근하다 |
| 특정 규제/정밀 로그가 중요한 환경 | 300~900초(5~15분)이다 | 시간원 품질이 높고 네트워크가 안정적일 때만 권장하다 |
레지스트리로 적용하려면 다음 경로를 사용하다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient SpecialPollInterval (DWORD, 단위: 초) 값을 설정하다5.3 시간 보정 한계값을 함께 점검하다
동기화 주기를 짧게 해도 “한 번에 보정할 수 있는 오프셋 한계” 때문에 보정이 멈추는 경우가 있다. 큰 오프셋이 누적된 환경이라면 보정 한계값 관련 항목을 점검해야 한다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config MaxPosPhaseCorrection (DWORD, 초) MaxNegPhaseCorrection (DWORD, 초)주의 : 보정 한계값을 과도하게 키우면 “잘못된 시간원”을 따라가며 대규모 장애를 만들 수 있다. 외부 NTP가 신뢰 가능한지, 내부에 자체 시간 서버(Stratum 장비)가 있는지 먼저 확인한 뒤에 조정해야 한다.
5.4 서비스 재시작과 강제 동기화로 반영하다
net stop w32time net start w32time w32tm /resync /rediscover상태 확인은 다음 명령으로 수행하다.
w32tm /query /status w32tm /query /source w32tm /query /peers6. 도메인 멤버와 다른 DC에서 “지연 체감”을 줄이는 운영 팁
6.1 멤버는 DOMHIER 유지가 기본이다
도메인 멤버에서 시간 지연이 체감된다고 해서 외부 NTP를 직접 지정하면 도메인 인증 문제를 악화시키는 경우가 많다. 멤버는 도메인 계층 동기화를 유지하고, PDC 에뮬레이터의 안정화가 먼저이다.
w32tm /config /syncfromflags:DOMHIER /update6.2 사이트 간 지연이 큰 환경은 “시간”보다 “네트워크/복제”를 먼저 의심하다
원격지 사이트에서 시간이 늦게 따라온다면, 시간 주기만의 문제가 아니라 AD 복제 지연, 사이트 링크 비용, UDP 123 방화벽, 라우팅 지연이 원인인 경우가 많다. 시간 동기화는 UDP 123의 안정성과 DC 간 도달성이 선행 조건이다.
6.3 가상화 환경에서 시간 동기화 충돌을 제거하다
가상 머신에서는 Hyper-V 통합 서비스나 VMware Tools가 게스트 시간을 “호스트 시간”으로 강제로 당기는 구성인 경우가 있다. 이 구성은 W32Time과 충돌하여 짧은 주기 튜닝을 무력화하거나 시간 튐을 만들 수 있다. 도메인 컨트롤러 VM은 원칙적으로 도메인 계층(W32Time) 기준으로 수렴하도록 설계하는 것이 안전하다.
주의 : 도메인 컨트롤러 VM에서 호스트 기반 시간 동기화를 무심코 켜면 “가상화 호스트의 시간”이 도메인 시간을 좌우하는 구조가 된다. 이 구조는 장애 전파가 매우 빠르므로 설계 단계에서 원칙을 확정해야 한다.
7. 그룹 정책(GPO)로 표준화하는 방법
대규모 환경에서는 로컬 수정을 분산 적용하는 대신 그룹 정책으로 표준화하는 것이 운영 안정에 유리하다. PDC 에뮬레이터 전용 정책과 일반 DC/멤버 정책을 분리하여 적용하는 방식이 일반적이다.
7.1 PDC 에뮬레이터 전용 정책에서 다루는 항목
- Windows NTP 클라이언트를 사용하도록 설정하다
- NtpServer 목록을 설정하다
- 동기화 형식을 MANUAL로 설정하다
- SpecialPollInterval 값을 표준화하다
- 필요 시 신뢰 가능한 시간원으로 표시하다
7.2 일반 DC/멤버 정책에서 다루는 항목
- 동기화 형식을 도메인 계층으로 유지하다
- 불필요한 수동 피어 설정을 금지하다
- 시간 서비스 동작을 변경하는 레지스트리 편차를 제거하다
8. 장애 없이 적용하기 위한 변경 순서와 검증 절차
8.1 권장 변경 순서
| 순서 | 작업 | 목표 |
|---|---|---|
| 1 | PDC 에뮬레이터 식별 및 현재 설정 백업을 수행하다 | 원복 가능성을 확보하다 |
| 2 | PDC 에뮬레이터에 외부 NTP 및 폴링 주기를 적용하다 | 도메인 시간 기준을 안정화하다 |
| 3 | 다른 DC는 도메인 계층 유지 상태를 확인하다 | 계층 붕괴를 방지하다 |
| 4 | 멤버는 강제 재탐색 및 동기화를 수행하다 | 체감 지연을 빠르게 줄이다 |
| 5 | 이벤트 로그와 오프셋을 24~72시간 관찰하다 | 부작용 없이 안정화되는지 확인하다 |
8.2 멤버 확산을 빠르게 하는 명령 예시
w32tm /config /update w32tm /resync /rediscover8.3 설정 백업과 원복 개념을 확보하다
레지스트리 변경을 동반한다면 변경 전 값을 기록해야 한다. 운영에서는 GPO로 표준화하더라도 “긴급 원복 절차”를 문서화하는 것이 필수이다.
9. 실무에서 자주 틀리는 포인트와 해결 가이드
9.1 “폴링을 줄였는데도 늦다”는 경우
이 경우는 다음 중 하나일 가능성이 높다.
- PDC 에뮬레이터가 실제로 외부 NTP에 정상 동기화되지 않다
- UDP 123이 방화벽/보안장비에서 간헐적으로 차단되다
- 가상화 호스트 시간 동기화가 게스트를 덮어쓰다
- 큰 오프셋 보정 한계값으로 인해 보정이 멈추다
- 시간원 자체가 불안정하거나 품질이 낮다
9.2 “외부 NTP를 여러 대 넣으면 좋아진다”는 오해
무작정 많은 서버를 넣는 것이 안정성을 보장하지는 않다. 동일 네트워크 구간, 동일 사업자, 동일 장비 계열만 잔뜩 넣으면 장애 상관성이 높아진다. 서로 독립성이 있는 시간원을 2~4개 수준으로 구성하고, 내부에 신뢰 가능한 시간원이 있으면 내부 시간원을 우선하는 설계를 고려하는 것이 일반적이다.
9.3 “클라이언트도 외부 NTP로 빨리 맞추자”는 유혹
도메인 멤버가 외부 NTP를 직접 참고하면, 도메인 컨트롤러와 시간 계층이 분리되어 Kerberos 오류가 오히려 늘어날 수 있다. 멤버는 도메인 계층을 유지하고, 최상위 기준인 PDC 에뮬레이터만 외부 시간원과 안정적으로 동기화하는 것이 원칙이다.
10. 예시 스크립트: PDC 에뮬레이터에서 주기와 피어를 빠르게 표준화하다
아래는 운영에서 자주 사용하는 형태의 예시이다. 환경에 맞게 NTP 서버와 주기를 조정해야 한다.
REM PDC Emulator에서 실행을 권장하다 w32tm /config /manualpeerlist:"ntp1.example.com,0x8 ntp2.example.com,0x8" /syncfromflags:manual /reliable:yes /update
REM SpecialPollInterval을 900초(15분)로 설정하다
reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient" ^
/v SpecialPollInterval /t REG_DWORD /d 900 /f
REM 서비스 재시작과 강제 동기화를 수행하다
net stop w32time
net start w32time
w32tm /resync /rediscover
REM 상태를 확인하다
w32tm /query /status
w32tm /query /source
w32tm /query /peers주의 : 배치/스크립트 적용 전에는 반드시 “대상 서버가 PDC 에뮬레이터인지” 확인해야 한다. 일반 DC나 멤버에 동일 스크립트를 적용하면 계층이 깨질 수 있다.
FAQ
도메인에서 시간 지연이 있으면 왜 로그인이나 파일 접근이 실패하다?
도메인 인증의 핵심인 Kerberos는 시간 오차에 민감하게 설계되어 있다. 클라이언트와 DC의 시간이 허용 범위를 벗어나면 티켓 발급과 검증 과정이 실패하거나 지연되어 로그인 지연, 접속 실패, 정책 적용 지연으로 나타나기 쉽다.
SpecialPollInterval을 60초처럼 매우 짧게 하면 가장 정확해지다?
반드시 그렇지 않다. 너무 짧은 주기는 서버 부하, 네트워크 노이즈, 로그 폭증을 만들고 오히려 오프셋이 흔들리는 경우도 있다. 시간원 품질과 네트워크 안정이 확보된 뒤에 5~15분 단위로 점진적으로 조정하는 접근이 안전하다.
다른 DC도 외부 NTP를 보게 하면 더 안정적이다?
일반적으로는 권장되지 않다. 여러 DC가 제각각 외부 시간을 따라가면 도메인 내부 시간 계층이 흐트러져 인증 문제가 늘어날 수 있다. PDC 에뮬레이터만 외부 시간원을 신뢰하고, 나머지는 도메인 계층을 따르게 하는 구성이 기본이다.
가상화 환경에서 시간 튐이 반복되면 무엇을 먼저 보아야 하다?
가상화 호스트 기반 시간 동기화 기능이 게스트 시간을 강제로 조정하는지부터 확인해야 한다. 도메인 컨트롤러 VM은 W32Time 기준으로 수렴하도록 구성하는 것이 일반적으로 안정적이며, 호스트 동기화가 켜져 있으면 충돌이 발생하기 쉽다.