Chrono Mock애플리케이션을 테스트하려고 시스템 날짜를 바꾸기
가장 오래된 방법입니다. Windows 시계를 테스트하려는 날짜로 맞추고, 프로그램을 실행하고, 시계를 되돌립니다. 이 방법은 통합니다. 다만 시계가 옮겨져 있는 동안에는 컴퓨터의 다른 모든 것도 함께 옮겨집니다.
시계와 함께 실제로 움직이는 것
시스템 시계는 테스트 중인 프로그램만의 것이 아닙니다. 컴퓨터의 모든 프로세스, 서비스, 네트워크 통신이 같은 시계를 읽으므로, 테스트 하나를 위한 변경은 모두를 위한 변경이 됩니다.
| 시계를 읽는 것 | 시계를 옮기면 일어나는 일 |
|---|---|
| 도메인 로그온과 공유 폴더 | Kerberos는 기본적으로 5분의 시계 차이를 허용합니다. 그 이상이면 티켓이 거부되고, 로그온이나 공유 폴더 접근이 실패합니다. |
| 인증서와 HTTPS | 인증서가 유효한지는 시계로 판단합니다. 인증서의 만료일을 지나도록 시계를 맞추면 그 인증서에 의존하는 모든 연결이 만료로 거부되고, 충분히 과거로 돌리면 인증서가 아직 유효하지 않습니다. |
| Windows 시간 서비스 | 도메인에 가입된 컴퓨터는 도메인 컨트롤러에서 시간을 가져오며, 기본적으로 이 서비스는 차이의 크기와 관계없이 시계를 바로잡습니다. 설정한 날짜가 아직 테스트하는 도중에 되돌려질 수 있습니다. |
| 시간을 기록하는 모든 것 | 시계가 옮겨진 동안 만들어진 파일, 로그, 데이터베이스 행, 보낸 메일에는 테스트 날짜가 남고, 시계를 되돌린 뒤에도 그대로 남습니다. |
| 본 가장 늦은 날짜를 기억하는 소프트웨어 | 일부 프로그램은 거꾸로 가는 시계를 조작으로 읽습니다. 실제 날짜를 복원할 때 일어나는 일이 바로 이것입니다. |
날짜가 멀수록 이런 일을 더 많이 만납니다. 2038년으로 맞춘 컴퓨터는 오늘 발급된 모든 인증서를 만료된 것으로 봅니다. 그런 부작용 없이 2038년을 테스트하기 →
또한 대부분의 계정에 없는 권한이 필요합니다. 시스템 시간을 바꾸는 것은 관리자 권한이며, 관리되는 컴퓨터에서는 자신에게 허용되지 않는 경우가 많습니다.
시계를 바꾸는 것이 정답인 경우
다른 사람이 쓰지 않는 가상 머신에서 자체 시계 동기화를 꺼 두었다면 훌륭한 테스트 환경입니다. 끝나면 버리니 그 안에 기록된 것은 아무 상관이 없습니다. 이런 가상 머신이 있고 테스트가 날짜 하나라면, 통하는 가장 간단한 방법입니다.
문제는 그 컴퓨터가 내가 작업하는 컴퓨터이거나, 도메인에 속한 컴퓨터이거나, 아무것도 눈치채면 안 되는 무언가를 동시에 돌리고 있는 컴퓨터일 때 시작됩니다.
대신 프로그램 하나의 시계만 옮기기
옮겨진 시간은 프로세스 하나와 그것이 시작한 자식 프로세스에만 보입니다. 도메인 로그온, 인증서, Windows Update는 이 시간을 전혀 보지 못하므로 위 표의 어느 것도 움직이지 않고, 나중에 되돌릴 것도 없습니다.
# 앱에는 2027년 12월 31일 23:59:50으로 보입니다. 나머지는 모두 실제 날짜를 유지합니다. chrono run "C:\apps\test.exe" --at 2027-12-31T23:59:50 # 자정 10분 전에 시작해 60배속으로 실행 - 10초 만에 해가 바뀝니다 chrono run "C:\apps\test.exe" --at 2027-12-31T23:50:00 --mode x60
프로그램 하나를 위해 옮긴 날짜가 정말 그 프로그램에 닿았는지는 짐작할 일이 아닙니다. 모든 세션은 판정과 프로그램이 실제로 읽은 시간 채널 목록으로 끝납니다. 적용되었는지 어떻게 알 수 있을까요? →
이것이 대신하지 못하는 것
- 서버에 시간을 묻는 프로그램은 로컬 대체가 닿는 범위 밖에 있습니다. 세션은 프로그램이 네트워크 연결을 여는 것을 보면 이를 알려 주며, 테스트가 통과했다고 짐작하게 두지 않습니다.
- 시스템 자체를 테스트하는 일, 즉 실제 시계의 변경에 반응하는 서비스, 예약된 작업, 시계 변경 전후의 Windows 동작에는 시계를 바꾸는 것 말고는 대신할 것이 없습니다. 그것도 희생해도 되는 컴퓨터에서 하세요.