티스토리 뷰

카테고리 없음

Windows 작업 스케줄러가 로그인 상태에서만 실행되는 문제 점검

생각방 2026. 10. 28. 15:26

목차


    예약 작업의 실행 계정과 파일 경로를 함께 점검

    담당자가 로그인한 낮에는 실행되던 예약 작업이 로그오프한 밤에는 결과 파일을 만들지 않는 상황을 가정해 보겠습니다. 이때 실행 시간을 바꾸기 전에 확인할 것은 스케쥴러를 등록 한 계정, 로그온 방식, 파일 경로입니다. 작업이 시작되지 않은 것인지, 시작한 프로그램이 파일 처리에 실패한 것인지도 구분해야 합니다.
    이 글은 Windows 11과 Windows Server 2025의 작업 스케줄러 2.0 방식에서 일반 사용자 계정으로 스크립트를 실행하는 구성을 예로 듭니다. 실제 화면 문구와 정책은 버전·관리 환경에 따라 다를 수 있으며, 특정 장비에서 재현한 장애 사례는 아닙니다.

    실행 계정과 로그온 조건을 먼저 비교 점검

    작업 속성의 ‘일반’에서 실행 계정과 보안 옵션을 확인합니다. ‘사용자가 로그온할 때만 실행’은 해당 사용자의 기존 대화형 세션을 이용하므로 로그오프 상태의 무인 실행에 맞지 않습니다. ‘로그온 여부에 관계없이 실행’으로 바꾸더라도 실행 계정의 인증과 프로그램의 비대화형 실행 조건은 별도로 충족해야 합니다. 실행 계정을 확인하거나 설정을 정상적으로 등록하지 않아 일배치로 돌아야 할 작업이 밤에 진행되지 않아 다음날 수기로 등록/처리하는 등 고생한 기억이 있습니다.

     

    특히 ‘암호를 저장하지 않음’ 방식에 주의해야 합니다. S4U 로그온은 암호를 저장하지 않지만 네트워크 자원과 암호화 파일에 접근할 수 없습니다. 계정 내 패스워드를 참고할 수 있는 로직을 놓쳐 어디서 막혔는지 여러명이 투입되어 해결하다가 결국 엉뚱한 곳의 문제를 해결했었습니다. 공유폴더를 사용하는 작업이라면 로그온 여부 옵션만 바꾸어 해결된다고 판단하지 않습니다. Microsoft 로그온 방식 문서가 설명하는 제약입니다.

     

    암호를 사용하는 일반 계정이라면 계정 잠금·사용 중지·암호 변경 이후 등록된 자격 증명을 확인합니다. 실행 단계에서 권한 오류가 기록되면 ‘일괄 작업으로 로그온’ 권한도 점검합니다. 도메인 정책이 관리하는 장비에서는 로컬 설정만 보고 판단하지 않습니다. Microsoft 권한 오류 문서를 함께 참고할 수 있습니다.

    요약: 실행 계정의 로그온 가능 여부와 해당 방식의 자원 접근 범위를 함께 확인합니다.
    로컬 파일 처리와 네트워크 자원 접근의 차이

    실행 파일·작업 폴더·공유폴더 경로를 분리

    ‘동작’에서는 프로그램 경로, 인수, ‘시작 위치’를 나누어 확인합니다. 예를 들어 Windows PowerShell 5.1 스크립트를 실행한다면 프로그램에는 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, 인수에는 -NoProfile -NonInteractive -File "C:\Batch\Export.ps1", 시작 위치에는 C:\Batch를 지정할 수 있습니다. 이는 예시이며 실제 설치 경로와 스크립트 요구사항에 맞춰야 합니다.

     

    스크립트 경로가 절대경로여도 내부에서 config.json을 상대경로로 읽으면 작업 폴더의 영향을 받습니다. 작업 디렉터리를 생략하면 기본적으로 %windir%\system32에서 실행된다는 점은 Microsoft 동작 설정 문서에 명시되어 있습니다. 입력·출력 경로를 명확히 하고 실행 계정의 읽기·쓰기 권한을 각각 확인합니다.

     

    탐색기에서 보이는 Z:\Reports도 예약 작업에서 그대로 보인다고 가정하면 안 됩니다. 드라이브 연결은 로그온 세션에 종속되므로 별도 실행 환경에서는 이용하지 못할 수 있습니다. \\fileserver\Reports 같은 UNC 경로로 대상을 명시하고, 해당 실행 계정과 로그온 방식으로 접근 가능한지 확인합니다. UNC 경로는 위치를 명확히 할 뿐 인증과 권한을 대신하지 않습니다. Microsoft 드라이브 연결 문서가 세션별 차이를 설명합니다. 동일한 공유폴더로 보여도 설정에 따라 드라이브 기반인지 UNC기반인지 모니터링에서도 구분할 수 있었습니다.

    요약: 파일 위치가 맞는지와 그 위치에 접근할 수 있는지는 서로 다른 확인 항목입니다.
    실행 파일, 작업 폴더, 공유폴더의 위치 구별

    실행 이력과 결과 파일로 실패 단계를 축소

    다음 순서로 확인하면 설정을 한꺼번에 바꾸는 일을 줄일 수 있습니다. 검증에는 운영 데이터를 중복 처리하지 않는 테스트 작업을 사용합니다.

    1. 작업 이름, 실행 계정, 예정 시각, 기존 보안 옵션과 동작 설정을 기록합니다.
    2. ‘기록’과 마지막 실행 시각을 확인해 작업이 실제 시작됐는지 구분합니다. 이력이 비활성화되어 있다면 활성화 후 재현하며, 과거 기록이 복원된다고 기대하지 않습니다.
    3. 시작 기록이 없다면 로그온 조건과 트리거를 대조하고, 전원·유휴 상태 등 다른 실행 조건도 확인합니다.
    4. 시작 후 실패했다면 스크립트 로그에서 실행 계정, 현재 작업 폴더, 입력 파일 접근, 출력 파일 생성 단계를 확인합니다. 로그를 남길 로컬 폴더에도 쓰기 권한이 있어야 합니다.
    5. 설정을 조정한 뒤 로그오프 상태의 예약 시각에 다시 검증하고, 결과 파일의 위치·생성 시각·내용까지 대조합니다.

    Microsoft는 작업 이력, 단순화한 스크립트와 프로그램 자체의 로그를 이용해 범위를 좁히도록 안내합니다. 필요하면 이벤트 뷰어의 Microsoft > Windows > TaskScheduler > Operational 기록도 확인합니다. 공식 문제 해결 문서에서도 작업 완료와 기대한 결과의 발생을 구분합니다.

    자주 묻는 질문

    화면 잠금도 로그오프와 같습니까?

    화면 잠금은 사용자 세션을 종료하는 로그오프와 다릅니다. 잠근 상태에서 성공했더라도 로그오프 상태의 실행까지 검증한 것은 아닙니다.

    ‘가장 높은 수준의 권한으로 실행’을 켜면 해결됩니까?

    필요한 관리자 권한이 빠진 경우에는 검토할 수 있습니다. 다만 이 옵션이 잘못된 경로, S4U의 네트워크 제약, 공유폴더 권한을 모두 해결하지는 않으므로 오류 근거에 따라 적용합니다.

    작업이 실행 중인데 프로그램 창이 안 보이면 실패입니까?

    비대화형 실행에서는 창이 보이지 않는다는 사실만으로 실패를 판단할 수 없습니다. 입력창이나 확인 버튼을 기다리는 프로그램인지 확인하고, 무인 실행을 지원하는 명령행 방식과 로그를 사용해야 합니다.

    결론

    로그인 상태에서만 성공하는 작업은 실행 계정·로그온 조건·경로를 순서대로 대조하는 데서 점검을 시작합니다. 로컬 파일은 처리되지만 공유폴더에서 실패한다면 인증 방식과 공유 접근을, 프로그램이 시작된 뒤 입력 파일을 찾지 못한다면 작업 폴더와 상대경로를 우선 확인합니다. 최종 확인 기준은 로그오프 상태에서 예정대로 실행되어 필요한 결과물이 올바르게 만들어졌는지입니다.

    참고자료