수동 실행은 되는데 예약만 실패한다면 시작 위치부터 보세요|작업 스케줄러 실행 안됨·마지막 실행 결과·시작 위치 설정

먼저 얻을 답

작업 스케줄러 실행 안됨 문제는 스크립트를 다시 만들기 전에 작업의 기록과 마지막 실행 결과를 같은 시각으로 대조하고, 동작 탭의 시작 위치와 실행 계정을 확인해야 해요. 시작 위치에는 파일명이 아니라 스크립트가 사용하는 폴더를 넣으며, 정확한 원인은 작업별 기록과 자체 로그로 확인해야 합니다.

예약 실행은 다음 시각이 지나면 같은 실패를 반복하므로 현재 기록이 남아 있을 때 예약 시각과 결과를 맞춰 보는 편이 원인을 좁히기 쉽다.

읽기 전에 확인할 근거

근거 1작업 스케줄러의 마지막 실행 결과와 기록 탭 대조
근거 2이벤트 뷰어의 Microsoft-Windows-TaskScheduler/Operational 경로
근거 3Microsoft가 정의한 WorkingDirectory와 트리거 구조
예약 실행 실패를 마지막 실행 결과, 시작 위치, 실행 계정 순서로 좁히는 대표 장면

다만 시작 위치가 모든 실패의 원인은 아니에요. 예약 자체가 시작되지 않았다면 트리거와 조건을 봐야 하고, 시작된 뒤 실패했다면 프로그램 경로·인수·권한·스크립트 내부 오류를 좁혀야 해요. 특정 결과 코드가 제시되지 않은 상태에서는 원인을 하나로 단정할 수 없습니다.

마지막 실행 결과는 원인표가 아니라 출발점이에요

예약 시각과 작업 기록의 시간을 대조하는 장면

작업 스케줄러 라이브러리에서 해당 작업을 선택한 뒤 마지막 실행 시간과 마지막 실행 결과를 먼저 적어 두세요. 다음으로 기록 탭에서 같은 시각의 시작, 동작 시작, 완료 또는 실패 기록을 찾으면 문제가 어느 구간에서 생겼는지 나눌 수 있어요.

  • 예약 시각의 기록이 전혀 없다면 트리거가 사용 상태인지, 다음 실행 시간이 예상과 맞는지 확인해요.
  • 작업은 시작됐지만 동작이 시작되지 않았다면 실행 프로그램과 계정 설정을 확인해요.
  • 동작까지 시작된 뒤 실패했다면 프로그램 인수, 시작 위치, 접근 권한과 스크립트 자체 로그를 봐야 해요.
  • 정상 완료로 보이는데 결과 파일이 없다면 스크립트가 다른 폴더에 저장했거나 내부 오류를 기록하지 않았을 가능성도 따로 확인해요.

기록 탭이 비어 있다면 작업 스케줄러 오른쪽의 모든 작업 기록 사용 여부를 확인할 수 있어요. 더 자세한 기록은 이벤트 뷰어에서 응용 프로그램 및 서비스 로그, Microsoft, Windows, TaskScheduler, Operational 순서로 찾아갑니다. Microsoft의 공식 문제 해결 문서도 상태 열, 기록 탭, 마지막 실행 결과와 이 로그를 함께 확인하도록 안내해요.

시작 위치에는 파일이 아니라 기준 폴더를 넣어요

프로그램과 인수, 시작 위치 폴더의 역할을 나누는 장면

시작 위치 설정은 스크립트가 어느 폴더를 기준으로 파일을 찾을지 알려 주는 항목이에요. Microsoft의 WorkingDirectory 문서는 실행 파일이나 실행에 필요한 파일이 있는 디렉터리를 지정하는 값이라고 설명합니다.

예를 들어 스크립트가 같은 폴더의 settings.json이나 output 하위 폴더를 상대경로로 찾는다고 해볼게요. 파일을 직접 실행할 때는 스크립트 폴더에서 출발할 수 있지만, 예약 실행에서는 다른 폴더가 기준이 될 수 있어요. 이때 스크립트 파일은 열렸어도 설정 파일을 못 찾거나 결과물이 예상하지 않은 곳에 생길 수 있습니다.

동작 탭은 세 칸의 역할을 나눠 입력해요

  • 프로그램/스크립트: 실제 실행기 경로를 넣어요. PowerShell 작업이라면 사용하는 PowerShell 실행 파일이 여기에 해당합니다.
  • 인수 추가: 실행 정책이나 스크립트 파일 경로처럼 실행기에 전달할 내용을 넣어요. 경로에 공백이 있으면 사용하는 프로그램의 명령행 규칙에 맞게 따옴표를 확인해야 해요.
  • 시작 위치: 파일명이 없는 폴더 경로만 넣어요. 스크립트와 설정 파일이 있는 폴더 또는 작업이 기준으로 삼아야 할 폴더입니다.

스크립트 안의 입력·출력 경로를 절대경로로 바꾸면 현재 폴더가 달라져 생기는 문제를 줄일 수 있어요. 그렇다고 모든 경로를 무작정 고치기보다 먼저 시작 위치를 지정한 테스트 작업으로 재현 여부를 확인하는 편이 안전합니다.

수동 실행과 예약 실행은 사용하는 계정이 다를 수 있어요

수동 실행 사용자와 예약 실행 계정의 권한을 비교하는 장면

직접 실행할 때의 사용자와 작업 속성에 등록된 실행 계정이 다르면 같은 프로그램도 다른 권한으로 움직여요. 일반 탭에서 작업을 실행할 사용자 계정, 사용자가 로그온할 때만 실행하는지 여부, 가장 높은 수준의 권한으로 실행 설정이 실제 작업에 필요한지 확인하세요.

평소 내 계정으로 열 수 있는 폴더라고 해서 예약 계정도 열 수 있는 것은 아니에요. 보고서 저장 폴더, 공유 폴더, 인증서, 환경변수처럼 사용자별로 달라지는 자원을 쓰는 자동화라면 차이가 더 잘 드러납니다.

  • 예약 계정에 스크립트와 입력 폴더의 읽기 권한이 있는지 확인해요.
  • 결과 폴더에는 쓰기 권한도 필요한지 살펴봐요.
  • 관리자 권한이 실제로 필요한 작업인지 먼저 확인한 뒤 높은 권한 설정을 결정해요.
  • 사용자가 로그온하지 않은 상태에서도 필요한 인증과 네트워크 자원을 사용할 수 있는지 점검해요.

권한 문제를 피하려고 계정을 계속 바꾸기보다는 실패한 계정과 경로를 기록해 두고 한 항목씩 비교하세요. 여러 설정을 한꺼번에 바꾸면 무엇이 원인이었는지 다시 알기 어려워집니다.

예약 시각을 놓쳤다면 트리거와 조건을 함께 보세요

예약 시각과 전원, 절전, 네트워크 조건을 함께 확인하는 장면

Microsoft는 작업 스케줄러가 선택한 시간이나 이벤트 같은 트리거를 감시한 뒤 기준이 맞을 때 작업을 실행한다고 설명해요. 예약 시간이 정확해도 작업의 조건이 충족되지 않으면 기대한 시각에 시작되지 않을 수 있습니다.

트리거 탭에서는 해당 트리거가 사용 상태인지, 시작 날짜와 시간이 맞는지, 반복 간격과 종료 설정이 의도한 값인지 확인하세요. PC를 꺼 두거나 절전 상태여서 예약 시각을 놓친 경우에는 설정 탭의 예약된 시작을 놓친 경우 가능한 한 빨리 작업 실행 항목이 필요한지 판단해야 해요.

조건 탭도 빼놓으면 안 됩니다. AC 전원에서만 시작하도록 되어 있거나 유휴 상태, 특정 네트워크 같은 조건이 붙으면 노트북을 배터리로 쓰는 시간이나 네트워크가 끊긴 시각에는 작업이 미뤄질 수 있어요. 모든 조건을 무조건 해제하기보다 자동화에 꼭 필요한 제한인지 하나씩 판단하세요.

수정 뒤에는 가까운 테스트 예약으로 다시 확인하세요

가까운 테스트 예약 뒤 자체 로그를 확인하는 장면

기존 작업을 바로 삭제하지 말고 현재 설정을 메모하거나 내보낸 뒤, 가까운 시각의 테스트 트리거로 다시 실행해 보세요. 수동 실행 버튼만 누르면 예약 시각의 트리거와 조건까지 검증하지 못하므로 실제 예약 실행을 한 번 거치는 게 중요해요.

  1. 마지막 실행 시간과 결과를 적고 같은 시각의 기록을 확인해요.
  2. 프로그램, 인수, 시작 위치를 서로 다른 역할에 맞게 정리해요.
  3. 실행 계정의 읽기·쓰기 권한과 로그온 조건을 대조해요.
  4. 트리거와 전원·유휴·네트워크 조건 가운데 한 항목만 수정해요.
  5. 가까운 테스트 예약을 실행하고 작업 기록과 스크립트 로그의 시간을 다시 맞춰 봐요.

스크립트 자체 로그는 절대경로로 남기는 편이 좋아요. 시작 시각, 현재 작업 폴더, 주요 단계의 성공·실패, 종료 시각을 기록하면 작업 스케줄러가 프로그램을 시작한 뒤 어디에서 멈췄는지 구분할 수 있습니다. 비밀번호, 인증 토큰과 개인정보는 로그에 남기지 마세요.

마지막 실행 결과가 성공처럼 보이는데 결과가 없을 때도 자체 로그가 필요해요. 작업 스케줄러가 실행 파일의 종료 상태만 받은 경우라면, 스크립트 내부에서 발생한 누락이나 잘못된 저장 위치까지 한 줄로 설명해 주지는 못합니다.

이 방법이 맞지 않는 경우

작업 기록과 자체 로그에 모든 단계가 정상 완료됐는데 다른 프로그램에서만 결과가 보이지 않는다면 작업 스케줄러보다 후속 동기화, 파일 잠금, 저장 대상 서비스의 문제를 확인해야 해요. 반대로 이벤트 뷰어에도 시작 기록이 없다면 스크립트 내용을 고치기 전에 트리거와 작업 사용 상태부터 보는 편이 맞습니다.

특정 마지막 실행 결과 코드가 표시된다면 코드를 그대로 기록하되, 코드 하나만 보고 원인을 확정하지 마세요. 같은 코드라도 실행 프로그램이 반환한 값인지 작업 시작 단계에서 생긴 값인지 주변 기록과 함께 판단해야 합니다.

확인한 기준

2026년 8월 28일 Microsoft Learn에서 작업 스케줄러의 트리거 구조, 작업 기록과 마지막 실행 결과 확인 순서, Operational 로그 위치, WorkingDirectory 정의를 대조했어요. 특정 PC의 작업 XML, 결과 코드, 스크립트 원문과 실제 로그는 제공되지 않아 개별 실패 원인까지 확정하지 않았습니다. 문제 해결 세부 문서가 명시한 적용 대상은 지원되는 Windows Server이며, Windows 10·11에서는 버전에 따라 화면 문구가 조금 다를 수 있어요.

이 글이 필요한 경우직접 실행하면 정상인 자동화 스크립트가 예약 시간에는 실행되지 않고 로그 위치도 찾기 어렵다.
이 방법이 맞지 않는 경우특정 실행 결과 코드의 의미만 필요한 경우나 작업 스케줄러 밖의 클라우드 예약 서비스에서 실패한 경우

Microsoft 공식 작업 스케줄러 문서에서 현재 조건 확인하기

댓글

이 블로그의 인기 게시물

CSV 정리 자동화, 삭제 기능보다 감사 보고서를 먼저 만든 이유

뤼튼 무료 범위와 크랙 결제, 무료 AI와 유료 콘텐츠를 나눠 보세요

ChatGPT 대화 기록 삭제와 학습 제외, 임시채팅까지 따로 봐야 합니다