원격 Mac launchd 정기 작업이 실행되지 않나요? 2026 점검 가이드

Apple 문서는 launchd 작업을 사용자 에이전트와 시스템 데몬이라는 두 실행 유형으로 구분합니다 (Apple의 launchd 작업 안내). 증상 → 가장 빠른 점검: SSH에서 실행되는 스크립트가 자동으로 돌지 않는다면, 스크립트를 다시 쓰기 전에 작업이 필요한 로그인 상태부터 확인하고 사용자 작업인지 시스템 작업인지 정하세요.

독립 개발자: 원격 Mac에서 유지 관리, 빌드, 데이터 처리 스크립트를 주기적으로 실행하려는 경우에 적합합니다.
DevOps 엔지니어: SSH 수동 실행은 성공하지만 자동 작업에 결과가 없을 때 실행 기록과 로그를 확인하려는 경우에 적합합니다.
플랫폼 운영자: 사용자 에이전트, 시스템 데몬 또는 다른 실행 방식 중 무엇이 맞는지 판단해야 할 때 참고하세요.

SSH 수동 실행과 자동 실행의 실행 조건

SSH로 직접 실행하면 되는데 launchd에서는 왜 실패하나요? 수동 실행이 성공했다는 사실만으로 자동 작업도 같은 조건에서 실행된다고 볼 수는 없습니다. SSH 셸에는 로그인 과정에서 설정된 경로와 환경 변수가 있을 수 있지만, launchd 작업에는 그대로 전달된다고 가정하면 안 됩니다. Apple의 셸 스크립트 안내는 셸 스크립트가 명령을 실행하는 방식과 실행 조건을 설명합니다.

먼저 “출력이 없다”와 “스크립트가 시작되지 않았다”를 구분하세요. 작업이 시작됐지만 표준 출력이 저장되지 않았거나, 작업 중 오류가 났을 수도 있습니다. 다음 증거를 한 묶음으로 확인해야 합니다.

• 작업 설정에서 실행 프로그램과 인자, 작업 대상 계정을 확인합니다.
• 스크립트가 기록하는 시작 시각, 종료 시각, 종료 상태를 확인합니다.
• launchd 작업의 표준 출력과 오류 출력이 저장되는 위치를 확인합니다.
• 자동 실행에서 참조하는 파일과 디렉터리를 해당 계정이 읽고 쓸 수 있는지 확인합니다.
• 같은 계정과 작업 디렉터리에서 최소 명령을 실행해 차이를 좁힙니다.

작업 설정이 로드됐다는 사실은 실행 완료의 증거가 아닙니다. 시작 로그와 종료 결과가 연결되어야 실패 지점을 가릴 수 있습니다.

사용자 로그인 작업과 시스템 백그라운드 작업

사용자 에이전트와 시스템 데몬 중 어떤 유형이 맞나요? 바탕 화면 세션, 사용자 파일, 로그인한 계정의 권한이 필요한 작업은 사용자 에이전트부터 검토하세요. 로그인 세션과 무관하게 실행되어야 하는 백그라운드 작업만 시스템 데몬 후보로 두는 편이 안전합니다. Apple은 사용자와 시스템의 로그인 컨텍스트 및 백그라운드 프로세스의 실행 컨텍스트를 각각 설명합니다.

사용자 세션에 묶인 작업

현재 사용자의 홈 디렉터리, 로그인 후 제공되는 파일 접근 권한, 사용자별 설정을 쓰는 작업이라면 사용자 에이전트가 자연스러운 출발점입니다. 작업을 등록한 계정과 실제로 필요한 파일의 소유자도 대조하세요. SSH로 다른 계정에 접속해 시험했다면, 그 결과를 작업 계정의 권한 검증으로 대신할 수 없습니다.

로그인 여부와 무관해야 하는 작업

사용자 로그인 없이도 돌아야 하고, 그래픽 앱이나 사용자 세션 전용 자원에 의존하지 않는 작업만 시스템 데몬 후보로 삼으세요. 실행 계정에는 필요한 파일과 명령에 접근할 최소 권한만 부여합니다. 실행되게 만들 목적으로 권한을 넓히면, 작업은 돌아도 운영 경계가 불필요하게 커집니다.

• 적합도 높음: 사용자 홈의 파일을 처리하며 해당 사용자의 세션에서 실행해야 합니다.
• 조건부: 로그인 없이 실행해야 하지만, 필요한 디렉터리와 자격 증명에 시스템 계정이 접근 가능한지 먼저 검증해야 합니다.
• 적합도 낮음: 현재 사용자의 화면이나 로그인 상태를 요구하면서 시스템 데몬으로 실행하려고 합니다.

그래픽 인터페이스와 사용자 자격 증명

그래픽 화면이나 사용자 로그인이 필요한 작업은 어떻게 처리하나요? 스크립트가 그래픽 앱을 열거나 화면의 상태를 읽고, 사용자가 로그인해야 접근 가능한 자격 증명을 쓴다면 완전한 무인 백그라운드 작업으로 취급하지 마세요. 해당 동작을 사용자 세션 안에 남기거나, 사용자 상호작용 없이 가능한 별도 작업 흐름으로 분리해야 합니다.

Keychain에 저장된 비밀 정보도 자동으로 모든 실행 계정에서 읽을 수 있다고 가정하면 안 됩니다. Apple의 Keychain Services 문서를 확인하고, 실제 작업 계정으로 필요한 항목에 접근할 수 있는지 검증하세요. 자격 증명을 로그에 출력하거나 스크립트에 평문으로 넣어 문제를 우회하지 마세요.

그래픽 앱이 잠금 화면이나 로그인 화면에서도 동작해야 한다고 요구한다면, 먼저 그 요구가 운영체제의 사용자 세션 경계와 맞는지 확인하세요. 세션이 필요한 작업을 데몬 설정만 바꿔 해결하려 하면 실패 원인이 계속 남을 수 있습니다.

명령 경로와 실행 환경 비교

SSH 셸에서 명령을 찾더라도 자동 작업의 실행 경로가 같다는 뜻은 아닙니다. 작업 설정에는 실행 파일의 절대 경로를 지정하고, 스크립트가 기대하는 작업 디렉터리와 환경 변수를 명시하세요. Apple의 정기 작업과 실행 설정 안내는 launchd 작업의 실행 조건을 다룹니다. Terminal의 launchd 안내도 작업을 관리할 때 참고할 수 있습니다.

점검은 의존성 단위로 나누면 빠릅니다. 실행 파일이 실제 위치에 있는지, 스크립트에 실행 권한이 있는지, 상대 경로가 어떤 디렉터리를 기준으로 해석되는지 확인하세요. 네트워크 공유나 외부 서비스가 필요하다면 자동 실행 시점에 해당 자원에 접근 가능한지도 별도로 기록합니다.

Apple 문서에서 안내하는 StartInterval과 StartCalendarInterval은 반복 실행 시점을 지정하는 방식입니다. 설정에 트리거가 있어도 스크립트의 성공을 보장하지는 않습니다. Apple의 예약 작업 안내에 맞춰 트리거와 실제 완료 로그를 따로 검증하세요.

자동 트리거와 재시작 뒤의 결과 확인

설정을 저장했거나 작업을 로드했다는 이유만으로 수리를 완료 처리하지 마세요. Apple의 launchd 작업 생성 설명에서 작업 유형과 설정의 관계를 확인한 뒤, 목표 환경에서 실제 실행 결과를 남겨야 합니다.

• [ ] 작업이 필요한 로그인 세션을 정하고, 사용자 에이전트와 시스템 데몬 중 실행 유형을 선택합니다.
• [ ] 작업을 실행할 계정으로 명령을 시험하고, 파일 권한과 접근 가능한 자원을 기록합니다.
• [ ] 실행 파일의 절대 경로, 작업 디렉터리, 환경 변수, 스크립트 권한을 설정과 대조합니다.
• [ ] 그래픽 앱, 대화형 인증, 사용자 Keychain 의존성을 확인하고 무인 실행에 맞지 않는 동작을 분리합니다.
• [ ] 예정한 트리거로 작업을 실행해 시작 기록, 종료 상태, 출력 파일을 확인합니다.
• [ ] 원격 Mac을 재시작한 뒤, 로그인 후 실행이 필요한 작업인지 시스템 시작과 무관하게 실행되어야 하는 작업인지에 맞춰 다시 검증합니다.

재시작 뒤 로그만 생기고 결과 파일이 갱신되지 않았다면 정상 복구로 판정하지 마세요. 실행 기록과 산출물을 함께 비교해야 합니다. 로그인 이후 실행이 정상이라면 사용자 세션 작업으로 경계를 유지하고, 로그인 없이 실행되어야 하는데 실패한다면 계정과 접근 자원을 재검토하세요. 그래픽 또는 대화형 인증이 필수라면 다른 실행 흐름으로 옮기는 편이 안전합니다.

macOS 전용 도구 체인이 필요한 주기 작업은 Linux 서버만으로 대체하기 어렵고, 개발자의 로컬 Mac은 절전이나 접속 상태에 따라 지속 실행 노드로 쓰기 불편할 수 있습니다. 반대로 항상 같은 물리 장비를 직접 관리해야 하거나 장기간 고정 부하가 이어진다면 장비를 직접 마련하는 편이 맞을 수 있습니다. 해당 조건이 아니라면 MacDate의 원격 Mac 환경에서 SSH 접속과 작업 계정의 실행 경계를 먼저 확인한 뒤, 실제 스크립트와 재시작 검증으로 적합성을 판단하세요. 원격 실행 환경과 가상화 선택의 차이는 원격 macOS의 베어메탈과 가상화 비교에서 살펴볼 수 있으며, 장비를 직접 운영하는 방안은 Mac mini 비용 안내와 비교해 결정할 수 있습니다.