관리자 작업의 실행 취소(Undo) 기능 부재와 운영 실수 복구 불가
증상 진단: 시스템 변경 후 되돌릴 수 없는 상태
Active Directory 사용자 계정을 실수로 삭제했거나, 파일 서버의 중요 폴더 권한을 대규모로 잘못 변경한 후, 이를 즉시 복원할 방법이 없다는 것을 깨달은 상황입니다. Windows Server의 기본 GUI나 일반적인 관리 콘솔에는 ‘실행 취소(Undo)’ 버튼이 존재하지 않습니다. 변경이 적용된 순간, 그 영향은 네트워크 전반에 즉시 퍼져나가며, 사용자 불만과 시스템 장애로 이어집니다. 이는 단순한 실수가 아닌, 복구에 수시간이 소요될 수 있는 운영 사고의 시작점입니다.

원인 분석: 상태 기반 시스템의 본질적 한계
대부분의 레거시 인프라와 현대 서버 시스템은 ‘상태 기반(State-based)’으로 동작합니다. 관리자의 명령은 시스템의 현재 ‘상태’를 새로운 ‘상태’로 직접 전환시키는 작업입니다. 삭제, 권한 변경, 구성 수정은 모두 최종 상태를 덮어쓰는 원자적 작업에 가깝습니다. GUI에 실행 취소 기능이 없는 근본 이유는, 이러한 각 변경 사항이 시스템 서비스, 레지스트리, 보안 식별자(SID), 파일 시스템 메타데이터 등 복잡하게 얽힌 다수의 하위 요소에 동시에 영향을 미치기 때문입니다. 모든 변경 전 상태를 실시간으로 저장하고 복구할 수 있는 오버헤드는 시스템 성능을 심각하게 저하시킵니다.
주의사항: 본 가이드의 복구 방법을 시도하기 전, 현재 상태를 더 이상 악화시키지 않는 것이 최우선입니다. 문제가 발생한 서버나 도메인 컨트롤러에 대한 추가 변경 작업을 즉시 중지하십시오. 가능하다면 스냅샷 또는 시스템 상태 백업을 즉시 생성하는 것이 안전합니다.
해결 방법 1: 즉시 대응을 통한 손상 최소화 (초급)
운영 실수가 발생한 직후 황금시간(Golden Time) 내에 취할 수 있는 가장 빠른 조치입니다. 완벽한 복구를 보장하지는 않지만, 상황 확산을 막고 추가 데이터 손실을 방지하는 데 목적이 있습니다.
- 작업 중단 및 영향 평가: 실수로 실행한 MMC 콘솔(Active Directory 사용자 및 컴퓨터, 파일 서버 관리 등)을 즉시 종료합니다. 변경이 발생한 정확한 시간과 대상(예: “오전 10시, ‘Finance’ OU 내 모든 사용자 계정”)을 기록합니다.
- 세션 유지: 관리자 권한 명령 프롬프트(
cmd) 또는 PowerShell 세션을 닫지 마십시오. 예를 들어 실수 명령어를 입력한 세션은 히스토리(doskey /history또는 PowerShell의Get-History)를 통해 정확한 명령어를 확인할 수 있는 단서가 됩니다. - 로그 확보: 이벤트 뷰어(
eventvwr.msc)를 열고 보안 로그 및 디렉터리 서비스 로그를 확인합니다, 실수 발생 시간대의 이벤트 id를 필터링하여 변경 사항의 상세 내역(예: 이벤트 id 4726 – 사용자 계정 삭제)을 확보합니다. 이 로그는 향후 정확한 복구 작업의 근거가 됩니다.
해결 방법 2: 시스템 제공 복구 도구 활용 (중급)
Windows Server는 실행 취소 기능은 없지만, 특정 영역에 대해 사후 복구를 지원하는 내장 도구를 제공합니다. 이 방법은 사전 구성이 일부 필요할 수 있습니다.
Active Directory 객체 삭제 복구
AD 휴지통 기능이 활성화된 환경에서 삭제된 사용자, 그룹, OU를 복구할 수 있습니다. 먼저, Get-ADOptionalFeature -Filter * PowerShell 명령어로 ‘Recycle Bin Feature’가 Enabled 상태인지 확인합니다.
- Active Directory 관리 센터(
dsac.exe)를 엽니다. - 도메인 루트를 선택하고, ‘Deleted Objects’ 컨테이너로 이동합니다, (보기 메뉴에서 ‘고급 기능’이 활성화되어 있어야 함)
- 삭제된 객체를 찾아 마우스 오른쪽 버튼으로 클릭한 후 복원을 선택합니다. 원래 위치로 복원되며, 대부분의 속성(암호 제외)이 함께 복구됩니다.
PowerShell을 이용한 정확한 복원 명령어는 다음과 같습니다: Get-ADObject -Filter {DisplayName -eq "삭제된사용자명"} -IncludeDeletedObjects | Restore-ADObject
파일 서버 이전 버전(섀도 복사본)을 통한 복구
공유 폴더에 대해 볼륨 섀도 복사본(Volume Shadow Copy) 서비스가 구성되어 있다면, 파일 또는 폴더 수준의 변경/삭제를 복구할 수 있습니다.
- 사용자가 접근하는 네트워크 드라이브 또는 관리자가 접근하는 공유 폴더 경로로 이동합니다.
- 복구가 필요한 상위 폴더를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.
- 이전 버전 탭으로 이동합니다. 사용 가능한 섀도 복사본 목록이 날짜 및 시간별로 표시됩니다.
- 실수 발생 이전의 정상적인 시점 버전을 선택한 후 복원 또는 열기를 클릭하여 필요한 파일을 추출합니다, 폴더 전체 복원은 신중히 수행해야 합니다.
해결 방법 3: 외부 백업 및 모니터링 솔루션을 통한 근본적 복구 (고급)
시스템 기본 기능으로 복구가 불가능한 경우, 또는 보다 체계적인 복구 체계가 필요한 경우 적용하는 방법입니다. 이는 복구 행위 자체보다, 재발 방지를 위한 인프라 개선에 가깝습니다.
시스템 상태 백업에서의 권한/객체 복원
Windows Server Backup(WSB) 또는 타 백업 솔루션을 이용해 정기적으로 ‘시스템 상태’ 백업을 수행하고 있다면, 이를 이용한 개별 객체 복원이 가능할 수 있습니다.
- Windows Server Backup을 관리자 권한으로 실행합니다.
- 복구 마법사를 시작하고, 백업이 저장된 위치를 지정합니다.
- 복구 유형 선택에서 시스템 상태을 선택합니다. 일부 솔루션은 ‘Active Directory 복구’ 또는 ‘권한 항목 복구’와 같은 세부 옵션을 제공합니다.
- 복구 대상 위치를 ‘원래 위치’ 또는 ‘다른 위치’로 지정합니다. 다른 위치로 복구한 후, 필요한 객체(ntds.dit 데이터베이스의 일부 또는 보안 설명자)를 추출해 현재 운영 환경에 수동으로 적용해야 합니다, 이 작업은 도메인 컨트롤러를 디렉터리 서비스 복원 모드(dsrm)로 부팅해야 할 수 있으며, 상당한 전문성과 주의가 요구됩니다.
변경 관리 및 실수 방지 솔루션 도입
근본적인 해결책은 실행 취소 기능을 대체하는 ‘변경 제어’ 프로세스와 ‘즉시 롤백’ 가능한 기술을 도입하는 것입니다.
- Just-In-Time 관리 및 승인 워크플로: Microsoft Identity Manager 또는 타 PAM(Privileged Access Management) 솔루션을 도입하여, 모든 권한 있는 작업에 대해 사전 승인을 받도록 강제합니다. 실수로 요청된 작업도 승인 단계에서 차단됩니다.
- 구성 관리 데이터베이스(CMDB) 및 변경 추적: 모든 인프라 변경 사항을 자동으로 추적하고, 이전 구성으로의 빠른 롤백을 지원하는 도구(예: Ansible, Puppet, Chef의 롤백 기능)를 활용합니다. 코드로 정의된 인프라(IaC)라면 Git 버전 관리에서 직전 커밋으로 쉽게 되돌릴 수 있습니다.
- 테스트 환경에서의 사전 검증: 모든 주요 변경 사항은 운영 환경에 적용하기 전에 동일한 구성의 스테이징(테스트) 환경에서 먼저 실행하여 결과를 검증해야 합니다. 이는 레거시 시스템에서도 적용 가능한 최고의 안전장치입니다.
주의사항 및 전문가 운영 팁
운영 실수는 기술적 결함보다 프로세스와 습관에서 비롯되는 경우가 많습니다, 복구 작업 자체도 시스템에 새로운 위험을 초래할 수 있으므로 신중해야 합니다.
전문가 팁: 4-eyes principle(4안 원칙)의 현실적 적용
중요한 삭제 또는 권한 변경 작업은 반드시 2인이 참여하도록 절차를 만드십시오. 한 사람이 작업을 수행하기 전, 대상 목록을 다른 동료에게 음성으로 다시 한번 확인받는 간단한 습관이 대형 사고를 막습니다. 특히, ‘모든 사용자’를 선택하기 전에 필터를 다시 확인하고, 스크립트를 실행하기 전에-WhatIf파라미터(PowerShell)를 사용하여 예상 결과를 먼저 출력해 보는 것이 필수입니다. 복구 가능성에 기대기보다, 실수가 발생하지 않도록 제어하는 프로세스가 가장 훌륭한 실행 취소 기능입니다.
아울러, AD 휴지통은 활성화하는 즉시 과거 삭제 내역은 복구할 수 없다는 점을 명심하십시오. 중요한 변경 전에는 수동으로 시스템 상태 백업을 생성하거나, 가상 환경이라면 스냅샷을 찍는 것이 최후의 보험입니다. 모든 복구 작업은 가능하다면 서비스 영향이 최소화되는 유지 관리 시간대에 계획하고 실행하며, 복구 후에는 관련 서비스와 응용 프로그램의 정상 동작을 반드시 검증해야 합니다.