자동 작업이 경고 없이 멈출 때, 작업 스케줄러 점검 순서

아침에 백업 폴더를 열었는데 어제 날짜 파일이 없습니다. 작업 스케줄러를 열어보면 작업은 '준비' 상태로 멀쩡히 앉아 있고, 오류 창도 메일도 오지 않았습니다. 어제까지는 같은 시각에 꼬박꼬박 돌던 작업입니다.

이런 멈춤은 프로그램이 고장 나서 생기는 경우가 드뭅니다. 대부분은 스케줄러가 프로그램을 띄우기 '전' 단계에서 조용히 끝난 경우입니다. 그래서 프로그램 로그를 뒤져도 흔적이 없고, 단서는 전부 스케줄러 쪽에 남아 있습니다.

이력이 꺼져 있으면 원인을 끝까지 찾을 수 없습니다

작업 스케줄러에는 실패 알림 기능이 없습니다. 실행에 실패하면 목록의 '마지막 실행 결과' 칼럼에 코드 하나를 적어두고 끝냅니다. 사람이 그 칼럼을 들여다보지 않으면 아무 일도 일어나지 않습니다.

게다가 실행 이력은 따로 켜야 기록됩니다. 한 번도 켜지 않은 서버에서는 작업 속성의 '히스토리' 탭을 눌러도 빈 화면만 나옵니다. 작업 스케줄러를 관리자로 열고 오른쪽 '작업' 창에서 '모든 작업 기록 사용'을 누르거나, 관리자 명령 프롬프트에서 wevtutil set-log Microsoft-Windows-TaskScheduler/Operational /enabled:true 를 실행하세요.

사고 조사의 1단계는 추측이 아니라 조사 도구를 켜는 것입니다. 지난 기록은 켠 뒤에 복구되지 않으니, 지금 켜야 다음 사고를 잡습니다.

결과 코드 일곱 개만 알면 원인이 절반으로 줄어듭니다

이력을 켜면 이벤트 101과 203이 핵심입니다. 101은 작업 시작 자체가 실패한 경우, 203은 작업은 시작됐지만 지정한 프로그램을 띄우지 못한 경우입니다. 두 이벤트와 '마지막 실행 결과'에 적히는 값은 마이크로소프트가 공식 문서로 뜻을 공개한 코드입니다.

0x41303이 보이면 프로그램을 들여다볼 필요가 없습니다. 스케줄러가 작업을 시작조차 하지 않았다는 뜻이고, 원인은 트리거나 계정 쪽입니다.

가장 흔한 원인은 바뀐 비밀번호입니다

'사용자가 로그온했는지 여부에 관계없이 실행'을 쓰면 스케줄러가 등록 시점의 비밀번호를 저장해 두고 그 암호로 로그온합니다. 계정 비밀번호를 바꾸거나 만료되면 저장된 암호는 그 순간부터 쓸 수 없습니다.

"작업에 저장된 비밀번호가 더 이상 유효하지 않으면 작업이 실행되지 않습니다. 사용자 계정 비밀번호가 만료되거나 변경될 때마다 이 절차가 필요합니다." — schtasks change 공식 문서

그래서 90일 만료 정책이 걸린 도메인에서는 분기마다 같은 사고가 반복됩니다. 자동화 전용 계정을 따로 만들어 만료를 풀거나, schtasks /change /tn "작업이름" /ru 계정 /rp 새암호 로 암호를 다시 밀어 넣는 일을 비밀번호 변경 체크리스트에 넣으세요.

'로그온한 경우에만 실행'과 '관계없이 실행'은 결과가 다릅니다

'사용자가 로그온한 경우에만 실행'은 그 계정의 로그온 세션이 실제로 열려 있어야 작동합니다. 서버를 재부팅하고 아무도 로그온하지 않았거나, 원격 데스크톱으로 쓰다가 로그아웃했다면 작업은 계속 대기합니다. 이때 코드가 0x80041320입니다.

'관계없이 실행'을 고를 때 '비밀번호를 저장하지 않음'을 함께 체크하면 S4U 방식이 됩니다. 공식 문서는 이 방식의 제약을 못 박아 두었습니다.

"S4U 로그온을 사용하면 시스템이 비밀번호를 저장하지 않으며, 네트워크나 암호화된 파일에 접근할 수 없습니다." — Principal.LogonType 공식 문서

파일 서버로 백업을 보내거나 메일을 쏘는 작업에 이 설정을 쓰면 안 됩니다. 로컬 디스크에서만 끝나는 작업에만 쓰세요.

Z: 드라이브는 서비스 계정에 존재하지 않습니다

드라이브 문자는 컴퓨터의 속성이 아니라 로그온 세션의 속성입니다. 윈도우는 드라이브를 연결할 때 드라이브 문자와 네트워크 경로를 잇는 심볼릭 링크를 만드는데, 이 객체는 로그온 세션마다 따로 생기고 세션 사이에 공유되지 않습니다.

그래서 내가 만든 Z: 는 내 세션에만 있습니다. 같은 사람이라도 관리자 권한 창에서 Z: 가 안 보이는 현상을 마이크로소프트가 별도 문서로 다루는 이유가 이것입니다. 서비스 계정 세션에서는 애초에 Z: 를 만들어 준 사람이 없습니다.

고치는 방법은 하나입니다. 스크립트와 작업 설정에서 Z:\백업 같은 표기를 모두 \\파일서버\백업 형태의 전체 경로로 바꾸세요. 작업 안에서 net use 로 다시 연결하는 방법도 있지만, 작업 내용에 비밀번호가 평문으로 남으므로 권하지 않습니다.

시작 위치를 비워두면 system32에서 실행됩니다

동작 설정의 '시작 위치(옵션)'를 비워두면 작업은 %windir%\system32 폴더에서 실행됩니다. 공식 문서에 그렇게 적혀 있습니다. 프로그램은 제대로 떠도 설정 파일과 상대 경로는 전부 엉뚱한 곳을 가리킵니다.

'손으로 돌리면 잘 되는데 스케줄러로 돌리면 안 된다'의 가장 흔한 정체가 이것입니다. 탐색기에서 더블클릭할 때는 시작 폴더가 프로그램이 있는 폴더이기 때문입니다. 실행 파일이 놓인 폴더를 시작 위치에 꼭 적어 넣으세요.

조건 탭이 막았는데도 로그는 조용합니다

'조건' 탭에는 기본으로 켜진 제약이 있습니다. 'AC 전원일 때만 시작', '컴퓨터가 유휴 상태일 때만 시작', '지정한 네트워크 연결이 가능할 때만 시작' 같은 항목입니다. 노트북이나 소형 PC에서 돌리는 작업이라면 여기를 꼭 보세요.

조건에 걸려 건너뛰면 코드가 0x80041324로 남습니다. 공식 설명은 "작업을 실행하려고 시도했지만 작업 정의의 제약 조건 중 하나 때문에 실행되지 않았다"입니다. 실패가 아니라 '안 하기로 했다'에 가까워서 더 눈에 띄지 않습니다.

실패를 사람에게 알리는 최소 장치를 붙이세요

스케줄러의 '전자 메일 보내기' 동작으로 해결하려는 시도는 접으세요. 이 기능은 윈도우 8과 윈도우 서버 2012에서 제거됐습니다. 공식 문서가 대안으로 안내한 파워셸 Send-MailMessage 도 지금은 사용 중단(obsolete)으로 표시돼 있습니다.

그래서 메일보다 먼저 붙일 것은 '성공 신호'입니다. 실패를 잡으려 하지 말고, 성공했을 때만 흔적을 남기게 하고 그 흔적이 없는 것을 사고로 보세요.

• 작업 스크립트 맨 끝에, 끝까지 성공했을 때만 신호 파일 하나를 덮어쓰게 합니다.
• 감시용 작업이 매일 오전에 그 파일의 수정 시각을 확인하고, 어제 날짜가 아니면 알립니다.
• 알림은 메일보다 사내 메신저 웹훅이 확실합니다. SMTP 설정과 스팸 처리에 묶이지 않습니다.

'이벤트 발생 시' 트리거를 쓰면 Operational 로그에 이벤트 101이나 203이 찍힐 때 알림 작업을 바로 띄울 수도 있습니다. 비용은 스크립트 몇 줄이고, 사고를 하루 안에 잡습니다.

이 순서가 통하지 않는 경우도 있습니다

마지막 실행 결과가 0x0인데 결과물이 없다면 이 점검표는 쓸모가 없습니다. 스케줄러가 프로그램을 띄웠고 프로그램이 0을 반환하며 끝났다는 뜻이므로, 원인은 프로그램 안에 있습니다. 0x1이나 0xE0434352처럼 스케줄러 코드 목록에 없는 값도 프로그램 자신의 종료 코드입니다.

작업이 열 개를 넘고 순서가 서로 얽히기 시작하면 작업 스케줄러 자체가 한계입니다. 선행 작업이 실패했을 때 후속 중단, 재시도, 실행 로그 보관 같은 기능을 스케줄러는 제공하지 않습니다. 이때는 작업 관리를 애플리케이션 쪽으로 옮기는 편이 낫습니다.

관련 글은 운영 노트와 업무 자동화에 모여 있고, 결과 코드 원문은 마이크로소프트 공식 문서에서 볼 수 있습니다. 자동화 설계와 유지보수 상담은 Codeforest로 문의하세요.

결론: 프로그램보다 계정과 경로를 먼저 보세요

조용히 멈춘 자동 작업의 원인은 거의 매번 같은 자리에 있습니다. 바뀐 비밀번호, 내 세션에만 존재하는 Z: 드라이브, 비어 있는 시작 위치입니다. 이 세 곳을 확인하는 데는 10분이면 충분합니다.

순서는 이력 켜기, 결과 코드 읽기, 계정과 비밀번호, 로그온 유형, 드라이브 경로, 시작 위치, 조건 탭입니다. 그리고 다 고친 뒤에는 성공 신호 파일 하나를 반드시 붙이세요. 다음 멈춤을 사장님이 가장 늦게 아는 사람이 되지 않게 해주는 유일한 장치입니다.