- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Active Directory 도메인 환경에서 시간 동기화가 늦게 따라오거나 간헐적으로 어긋나는 문제를 Windows 시간 서비스(W32Time) 폴링 주기와 관련 설정을 체계적으로 조정하여 안정적으로 해결하도록 돕는 것이다.
1. 도메인 시간 동기화 지연이 왜 발생하는가
도메인 환경에서 시간은 “계층 구조”로 동기화되는 것이 원칙이다.
클라이언트는 보통 로그인한 도메인 컨트롤러를 통해 시간을 맞추고, 도메인 컨트롤러는 포리스트 루트의 PDC 에뮬레이터(PDC Emulator)를 최상위 기준으로 삼는 구조이다.
이 구조가 정상이라도 “동기화가 늦다”라는 체감이 생기는 대표 원인은 동기화 주기가 길거나, 일부 노드가 잘못된 시간 소스를 바라보거나, 큰 시간 오프셋이 발생했을 때 보정 상태가 SPIKE로 머무르는 구성 문제로 이어지기 때문이다.
1-1. 현장에서 자주 보는 증상
| 증상 | 현상 | 주요 원인 범주 |
|---|---|---|
| 클라이언트 시간이 1~5분씩 뒤늦게 따라오다 | 재부팅 후 또는 장시간 방치 후 동기화가 느리다 | 폴링 주기 과다, 소스 오인, 네트워크 지연 |
| 특정 DC만 시간 오프셋이 커지다 | DC 간 시간이 들쭉날쭉하다 | PDC 구성 오류, 가상화 호스트 개입, 방화벽 UDP 123 |
| w32tm /resync가 실패하거나 “no time data”가 보이다 | 소스가 끊기거나 동기화 데이터가 없다 | NTP 접근 불가, 잘못된 플래그, 서비스 상태 이상 |
| SpecialPollInterval을 줬는데 동기화가 오히려 멈추다 | 시간이 크게 틀어지면 보정이 진행되지 않는다 | SpecialPollInterval 사용 조건 불일치, SPIKE 상태 |
주의 : Kerberos 인증은 시간 오차에 민감하다. 도메인 시간 불일치는 로그인 실패, 티켓 오류, 파일 서버 접근 실패, 인증 기반 서비스 장애로 이어지기 쉽다.
2. 먼저 해야 하는 진단: “누가 누구에게서 시간을 받는가”를 확정하다
폴링 주기 튜닝은 “시간 소스가 올바르다”라는 전제가 있어야 효과가 있다.
따라서 가장 먼저 각 역할별로 시간 소스가 무엇인지 확인해야 한다.
2-1. 필수 점검 명령어
REM 현재 동기화 상태와 소스를 확인하다 w32tm /query /status
REM 구성 전체를 확인하다
w32tm /query /configuration
REM 도메인 내 시간 소스 관측을 수행하다
w32tm /monitor
REM 특정 대상과 오프셋을 연속 측정하다
w32tm /stripchart /computer:DC1.contoso.local /samples:10 /dataonly2-2. “정상 목표 상태”를 역할별로 정리하다
| 역할 | 권장 시간 소스 | 핵심 포인트 |
|---|---|---|
| 포리스트 루트 PDC 에뮬레이터 | 외부 신뢰 가능한 NTP | 도메인 최상위 기준이므로 외부 기준을 둬야 한다 |
| 다른 도메인 컨트롤러 | 도메인 계층(NT5DS) | PDC를 따라가야 하므로 수동 NTP 지정이 남아 있으면 문제이다 |
| 도메인 멤버 서버/클라이언트 | 도메인 계층(NT5DS) | 개별 PC에 수동 NTP를 주면 계층이 깨질 수 있다 |
주의 : “일부 장비만 MANUAL NTP로 고정”된 상태는 장기적으로 시간 분열을 만들기 쉽다. 예외가 필요하면 대상과 이유를 문서화하고, 폴링 주기와 보정 한계를 함께 설계해야 한다.
3. 폴링 주기 커스터마이즈의 핵심: MinPollInterval과 MaxPollInterval을 이해하다
Windows 시간 서비스의 폴링 주기는 단순 “초 단위”만이 아니라 지수 기반 설정을 함께 사용한다.
특히 MinPollInterval과 MaxPollInterval은 “2의 제곱 초” 형태로 폴링 범위를 규정하는 값이다.
3-1. 폴링 지수 값을 사람이 이해하는 초로 바꾸다
MinPollInterval 값이 10이면 2^10초이므로 1024초이다.
MaxPollInterval 값이 15이면 2^15초이므로 32768초이다.
| 지수 값 | 초 | 대략 시간 | 운영 관점 |
|---|---|---|---|
| 6 | 64 | 1분 4초 | 과도한 빈도일 수 있으니 제한적으로 사용하다 |
| 8 | 256 | 4분 16초 | 불안정 환경에서 단기 관측 용도에 적합하다 |
| 9 | 512 | 8분 32초 | 서버군 기준으로 빠른 편에 속하다 |
| 10 | 1024 | 17분 4초 | 기본값으로 많이 쓰이는 범위이다 |
| 11 | 2048 | 34분 8초 | 트래픽을 줄이되 안정성을 유지하기 좋다 |
| 12 | 4096 | 1시간 8분 | 오프셋 체감이 생길 수 있어 업무 성격을 고려하다 |
3-2. SpecialPollInterval을 쓸 때의 함정과 안전한 접근
SpecialPollInterval은 주로 “수동 NTP(Manual peer)”를 쓰는 경우에 폴링 간격을 초 단위로 직접 지정하는 값이다.
그러나 SpecialPollInterval을 쓸 경우에도 MinPollInterval과 MaxPollInterval이 허용하는 범위와 일관되어야 한다.
SpecialPollInterval이 허용 범위를 벗어나면 서비스 시작 실패나 의도치 않은 동작이 발생할 수 있다.
주의 : 수동 NTP에서 SpecialPollInterval을 사용하면 큰 시간 오프셋이 발생했을 때 동기화가 지연되거나 멈춘 것처럼 보일 수 있다. 큰 오프셋 가능성이 있으면 MinPollInterval과 MaxPollInterval 기반 폴링으로 설계하는 편이 운영 리스크가 낮다.
4. 권장 설계안: “도메인 계층은 유지”하고 “폴링만 합리적으로 단축”하다
도메인 지연 해결의 정석은 PDC만 외부 NTP로 고정하고 나머지는 NT5DS 계층을 유지하는 방식이다.
그리고 체감 지연을 줄이기 위해 DC 및 멤버의 폴링 범위를 업무에 맞게 줄이는 방식이 안정적이다.
4-1. 시나리오별 권장 폴링 범위 예시
| 시나리오 | 대상 | MinPollInterval | MaxPollInterval | 의도 |
|---|---|---|---|---|
| 일반 사무/업무망 | 멤버 서버/클라이언트 | 10 | 11 | 17~34분 범위로 체감 지연을 줄이다 |
| 인증 민감 서비스 다수 | 핵심 서버군 | 9 | 10 | 8~17분 범위로 오프셋을 더 빠르게 줄이다 |
| 네트워크 품질 불안정 | 원격지 PC | 10 | 12 | 동기화 실패 시 과도한 재시도를 줄이다 |
| 일시적 장애 분석 기간 | 문제 DC 또는 특정 서버 | 8 | 9 | 단기 관측을 위해 폴링을 공격적으로 낮추다 |
주의 : 폴링을 과도하게 줄이면 UDP 123 트래픽이 증가하고, 방화벽이나 보안 장비에서 이상 트래픽으로 탐지될 수 있다. 운영 정책과 보안 장비 정책을 함께 점검해야 한다.
5. 구현 방법 A: 레지스트리 기반으로 폴링 주기를 조정하다
레지스트리 기반 변경은 즉시성과 명확성이 장점이지만, 도메인에서는 최종적으로 GPO로 표준화하는 편이 바람직하다.
단일 서버나 검증 단계에서는 레지스트리로 빠르게 변경하고 결과를 확인하는 방식이 유효하다.
5-1. MinPollInterval과 MaxPollInterval 경로를 적용하다
일반적으로 다음 경로에서 폴링 범위를 조정하다.
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config - MinPollInterval (DWORD) - MaxPollInterval (DWORD)5-2. PowerShell로 값 변경 후 서비스 재시작을 수행하다
# 관리자 PowerShell에서 수행하다
예시: 17~34분 범위로 맞추다(10~11)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config" -Name "MinPollInterval" -Type DWord -Value 10
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config" -Name "MaxPollInterval" -Type DWord -Value 11
서비스 재시작을 수행하다
Stop-Service W32Time
Start-Service W32Time
적용 상태를 확인하다
w32tm /query /status
w32tm /query /configuration5-3. 수동 NTP에서 SpecialPollInterval을 꼭 써야 하는 경우의 최소 원칙을 지키다
수동 NTP를 쓰는 장비에서 초 단위 폴링을 고정해야 하는 요구가 있을 수 있다.
이때 SpecialPollInterval은 다음 경로에서 조정하다.
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient - SpecialPollInterval (DWORD)단, SpecialPollInterval은 MinPollInterval과 MaxPollInterval이 허용하는 범위 안으로 넣어야 한다.
예를 들어 MinPollInterval=10, MaxPollInterval=11이라면 허용 범위를 대략 1024~2048초 사이로 설계하는 접근이 안전하다.
주의 : 수동 NTP를 쓰는 장비에서 시간 오프셋이 크게 발생할 가능성이 있으면 SpecialPollInterval 고정 전략은 운영 리스크가 커질 수 있다. 큰 오프셋이 생기는 근본 원인을 먼저 제거하고 폴링을 설계해야 한다.
6. 구현 방법 B: w32tm 명령어로 역할별 구성을 표준화하다
도메인 지연 문제는 폴링 이전에 “역할별 동기화 방식”이 흔들리는 경우가 많다.
따라서 명령어로 역할을 표준화하고, 그 위에 폴링 값을 얹는 순서가 정석이다.
6-1. 포리스트 루트 PDC 에뮬레이터를 외부 NTP로 고정하다
REM PDC에서 수행하다 w32tm /config /manualpeerlist:"time.windows.com,0x8 0.pool.ntp.org,0x8 1.pool.ntp.org,0x8" /syncfromflags:MANUAL /reliable:YES /update
net stop w32time
net start w32time
w32tm /resync
w32tm /query /status0x8 플래그는 운영 환경에서 흔히 쓰이는 클라이언트 모드 플래그로 사용되는 경우가 많다.
외부 NTP는 조직 정책에 맞는 신뢰 가능한 소스를 사용해야 한다.
6-2. 다른 DC와 멤버는 도메인 계층(NT5DS)로 되돌리다
REM 비-PDC DC 또는 멤버에서 수행하다 w32tm /config /syncfromflags:DOMHIER /update
net stop w32time
net start w32time
w32tm /resync
w32tm /query /status주의 : 도메인 계층을 써야 하는 장비에 /manualpeerlist 흔적이 남아 있으면 시간이 엇갈릴 수 있다. /query /configuration으로 NtpServer, Type, SyncFromFlags를 함께 확인해야 한다.
7. 구현 방법 C: 그룹 정책(GPO)로 폴링과 NTP 구성을 일괄 적용하다
운영 환경에서는 레지스트리 수동 변경보다 GPO 표준화가 재발 방지에 유리하다.
GPO는 “도메인 컨트롤러용”과 “도메인 멤버용”을 분리하는 편이 관리가 쉽다.
7-1. GPO 설계 체크리스트
| 구성 요소 | DC용 GPO | 멤버용 GPO | 비고 |
|---|---|---|---|
| PDC 외부 NTP 지정 | 예 | 아니오 | PDC에만 수동 NTP를 두는 것이 원칙이다 |
| NT5DS 계층 유지 | PDC 제외 예 | 예 | 도메인 시간 계층을 유지해야 한다 |
| 폴링 범위(Min/Max) 단축 | 예 | 예 | 업무 영향도에 맞춰 단계적으로 단축하다 |
| SpecialPollInterval 고정 | 필요 시 | 대부분 불필요 | 큰 오프셋 리스크를 고려해 신중히 사용하다 |
7-2. GPO 적용 후 검증 절차를 고정하다
REM 정책 강제 갱신을 수행하다 gpupdate /force
REM 현재 시간 소스를 확인하다
w32tm /query /status
REM 이벤트 로그에서 W32Time 관련 이벤트를 확인하다
eventvwr.msc검증은 “PDC의 소스가 외부 NTP인지”, “다른 DC와 멤버의 소스가 도메인 계층인지”, “폴링이 의도대로 변했는지”를 순서대로 확인해야 한다.
8. 도메인 지연을 더 악화시키는 흔한 함정을 피하다
8-1. 시간 소스가 여러 갈래로 분기되는 구성을 피하다
클라이언트 일부를 인터넷 NTP로 고정하고 나머지는 DC를 보게 하면 장비군이 서로 다른 기준 시간을 갖게 된다.
이 구조는 시간이 조금씩만 달라도 인증과 로그 상관관계를 깨뜨리기 쉽다.
8-2. 가상화 환경에서 “호스트 시간 주입”을 점검하다
가상화 플랫폼은 게스트 OS 시간 동기화 기능을 제공하는 경우가 많다.
이 기능이 도메인 시간 계층과 충돌하면 W32Time이 맞추려는 시간을 주기적으로 덮어쓰는 현상이 발생할 수 있다.
따라서 DC는 특히 “도메인 계층에 의한 동기화”가 우선되도록 가상화 동기화 정책을 점검해야 한다.
8-3. 방화벽과 보안 장비에서 UDP 123 경로를 확인하다
PDC가 외부 NTP를 본다면 UDP 123 통신이 반드시 성립해야 한다.
외부가 막히면 PDC가 신뢰할 소스를 잃고 도메인 전체가 점차 드리프트할 수 있다.
주의 : “동기화 주기를 줄였는데 더 불안정해졌다”라는 경우는 네트워크 경로가 불안정한 상태에서 재시도 빈도만 늘어난 상황일 수 있다. 이 경우 폴링 단축보다 먼저 통신 품질과 소스를 안정화해야 한다.
9. 운영 표준안 예시: 단계적으로 낮추고, 측정으로 확정하다
폴링은 한 번에 최저로 내리는 방식보다 단계적으로 낮추는 방식이 안정적이다.
다음은 현장에서 적용하기 쉬운 표준 절차 예시이다.
9-1. 표준 절차
| 단계 | 조치 | 목표 | 검증 |
|---|---|---|---|
| 1 | PDC 외부 NTP 확정 | 최상위 기준 시간 확립 | w32tm /query /status의 Source 확인을 수행하다 |
| 2 | DC/멤버 NT5DS 계층 복구 | 시간 소스 단일화 | w32tm /monitor로 계층을 확인하다 |
| 3 | 폴링 범위 10~11로 조정 | 체감 지연 완화 | stripchart로 오프셋 추이를 확인하다 |
| 4 | 문제 구간만 9~10으로 단기 조정 | 원인 분석과 안정화 | 이벤트 로그와 네트워크 경로를 함께 확인하다 |
| 5 | GPO로 표준화 | 재발 방지 | 정책 적용 결과를 샘플링 검증하다 |
9-2. 결과를 숫자로 남기는 운영 지표를 만들다
운영에서는 “감”보다 수치를 남기는 편이 재발 방지에 유리하다.
대표 지표는 오프셋 평균, 최대 오프셋, 마지막 성공 동기화 시각, 동기화 실패 이벤트 건수이다.
이 지표를 주간 단위로 비교하면 폴링 조정의 효과가 명확해진다.
FAQ
폴링 주기를 몇 분으로 설정하는 것이 정답인가?
정답은 “업무 요구, 네트워크 품질, 보안 정책”에 따라 달라진다.
일반적인 사무 환경에서는 17~34분 수준(지수 10~11)이 체감 지연과 트래픽의 균형이 좋다.
인증 민감 서비스가 많거나 오프셋 체감이 큰 구간은 8~17분 수준(지수 9~10)을 단기 적용하고, 원인 안정화 후 되돌리는 방식이 현실적이다.
SpecialPollInterval을 쓰면 더 빨라지는가?
수동 NTP를 쓰는 장비에서는 초 단위로 폴링을 고정할 수 있으니 체감상 빨라질 수 있다.
다만 MinPollInterval과 MaxPollInterval 범위와 불일치하면 서비스 시작 문제나 비정상 동작이 생길 수 있다.
또한 큰 시간 오프셋이 발생했을 때 동기화가 지연되거나 멈춘 것처럼 보일 수 있으니 운영 리스크를 함께 고려해야 한다.
도메인 멤버 PC를 인터넷 NTP로 직접 맞추면 더 정확한가?
개별 PC가 외부 NTP를 직접 보면 도메인 계층이 깨질 가능성이 커진다.
도메인 환경에서는 PDC만 외부 기준을 두고 나머지는 도메인 계층으로 맞추는 방식이 운영상 안정적이다.
설정 후에도 시간이 늦게 따라오면 무엇을 추가로 봐야 하는가?
첫째로 시간 소스가 올바른지 재확인해야 한다.
둘째로 PDC의 외부 NTP 통신이 UDP 123으로 정상인지 확인해야 한다.
셋째로 가상화 환경이라면 호스트의 시간 동기화 기능이 게스트 시간을 덮어쓰지 않는지 점검해야 한다.
넷째로 이벤트 로그에서 W32Time 경고와 오류가 반복되는지 확인하고, 반복된다면 네트워크 품질과 정책 충돌을 우선 해결해야 한다.