맥 예약 작업이 조용히 멈춰 있을 때: 파일이 있어도 안 도는 이유와 점검법

문제 · 자동화가 소리 없이 3주간 멈춰 있었다

맥에는 정해진 시간마다 프로그램을 자동 실행하는 launchd라는 예약 작업 시스템이 있습니다. 리눅스의 cron과 비슷한 역할을 하는데, 저는 이걸로 블로그 로그인 세션을 계속 살아 있게 유지하는 작업(com.aiblog.keepalive)을 걸어 뒀습니다.

그런데 어느 날 확인해 보니 이 작업이 3주 가까이 단 한 번도 실행되지 않고 있었습니다. 마지막 실행 기록이 7월 17일에 멈춰 있었고, 그 뒤로는 예약 시간이 와도 아무 일도 일어나지 않았습니다.

가장 위험했던 점은 겉으로는 아무 문제가 없어 보였다는 것입니다. 예약 작업 설정 파일은 ~/Library/LaunchAgents 폴더에 그대로 있었고, 파일을 열어 봐도 내용은 정상이었습니다. 그래서 '파일이 있으니 잘 돌겠지'라고 넘어가기 딱 좋았습니다. 이 글은 파일이 멀쩡한데도 왜 안 돌았는지, 그리고 재부팅 후에도 다시 멈추지 않게 어떻게 고쳤는지를 그대로 정리한 기록입니다.

---

왜 위험한가 · '파일이 있다'와 '서비스가 돈다'는 완전히 다른 상태다

이 문제의 핵심은 한 문장으로 요약됩니다. launchd에서 설정 파일의 존재 여부와 서비스의 실제 실행 여부는 별개다.
파일을 확인하는 것으로 점검을 끝내면, 서비스가 실제로는 죽어 있어도 계속 정상이라고 믿게 됩니다. 자동화는 원래 눈에 안 띄는 곳에서 돌기 때문에, 멈춰도 알림이 오지 않으면 며칠, 몇 주가 그냥 지나갑니다. 제 경우가 정확히 그랬습니다.
실제로 확인해 보니 겉보기와 실제 상태가 다음처럼 어긋나 있었습니다.

겉보기	실제 상태
설정 파일이 폴더에 있음	서비스로 등록되어 있지 않음
파일 내용은 정상	내부 기록에 '실행 금지'로 잠김
환경변수가 잡혀 있었음	재부팅하면 사라지는 임시 설정

정리하면 원인은 두 가지였습니다. 첫째, 작업이 launchd 내부에서 '실행 금지(disabled)' 상태로 잠겨 있었습니다. 둘째, 작업이 필요로 하는 설정값 하나가 재부팅하면 사라지는 방식으로만 걸려 있었습니다.

---

확인 절차 · 세 가지를 직접 눈으로 본다

파일 존재만 보는 습관을 버리고, 다음 순서로 실제 상태를 확인해야 합니다. 각 명령을 자기 환경에서 그대로 실행하며 값을 눈으로 확인하는 것이 핵심입니다.

1. 실행 목록에 잡혀 있는지 확인한다. 터미널에서 launchctl list | grep 작업이름을 실행합니다. 제 경우 launchctl list 출력에 com.aiblog.keepalive가 아예 보이지 않았습니다. 파일은 있는데 목록에 없다면, 서비스로 등록되지 않았다는 신호입니다.
2. 내부 잠금 상태를 확인한다. launchctl print-disabled로 해당 작업이 '실행 금지'로 잠겨 있는지 봅니다. 파일을 다시 넣어도 이 잠금이 풀리지 않으면 예약 시간이 와도 실행되지 않습니다.
3. 마지막 실행 시각이 예상 주기 안에 있는지 확인한다. 제 경우 마지막 실행이 7월 17일에 멈춰 있었고, 이 값이 예상 주기를 한참 벗어난 것이 문제의 첫 단서였습니다.

여기서 특히 주의할 점이 있습니다. 작업을 내릴 때 흔히 쓰는 launchctl bootout 명령은 작업을 멈추는 데서 끝나지 않고, 내부 기록에 '실행 금지' 표시를 남기는 특성이 있습니다. 그래서 나중에 파일을 다시 등록해도 잠금이 남아 있으면 실행되지 않습니다. 이 동작은 macOS 버전에 따라 달라질 수 있으니, 쓰고 있는 OS 기준으로 print-disabled까지 확인하는 편이 안전합니다.

---

고치는 방법 · 잠금 해제 + 설정 영구화 + 예약 경로 검증

확인이 끝났다면 다음 순서로 고칩니다.

1. 실행 금지 잠금부터 해제한다. launchctl enable로 해당 작업의 '실행 금지' 표시를 풉니다. 이 단계를 건너뛰고 재등록만 하면, 잠금이 남아 있어 여전히 안 돕니다.
2. 서비스로 다시 등록한다. 잠금을 푼 뒤 launchctl bootstrap으로 작업을 시스템에 다시 올립니다.
3. 환경변수를 설정 파일에 직접 박는다. 이 작업은 TISTORY_CDP_URL이라는 설정값에 의존하는데, 저는 이 값을 launchctl setenv로만 넣어 뒀습니다. 이렇게 넣은 값은 재부팅하면 사라집니다. 그래서 설정 파일(plist)의 EnvironmentVariables 항목에 값을 직접 적어, 재부팅 후에도 남게 했습니다.
4. 예약 시스템을 통해 한 번 실행해 확인한다. 예약 시간을 기다리지 않고 launchctl kickstart로 1회 실행시켜, 종료 코드 0(정상 종료)과 세션 유효 메시지를 눈으로 확인했습니다.

4번이 특히 중요합니다. 손으로 직접 실행하면 잘 되는데 예약으로는 안 되는 경우가 있을 수 있습니다. 환경변수나 실행 경로가 예약 환경에서만 다르게 잡힐 수 있기 때문입니다. 그래서 손 실행이 아니라 예약 시스템을 거쳐 확인해야 실제로 고쳐졌는지 확신할 수 있습니다.

---

전후 비교 · 무엇이 바뀌었나

항목	고치기 전	고친 후
작업 실행	7/17 이후 한 번도 안 돎	예약 경로로 정상 실행 확인
내부 잠금	'실행 금지'로 잠김	잠금 해제 후 재등록
환경변수	재부팅하면 사라짐	설정 파일에 박아 재부팅에도 유지
확인 방법	파일 존재만 봄	실행 목록·잠금 상태·실행 결과까지 확인

이 표에서 가장 눈여겨볼 줄은 마지막 '확인 방법'입니다. 원인 자체보다도, 원인을 못 찾게 만든 진짜 문제는 '파일만 보고 끝내는 점검 습관'이었습니다. 확인 범위를 넓히면 같은 문제가 다시 생겼을 때 발견할 가능성을 높일 수 있습니다.

---

체크리스트와 한계 · 다음에 또 조용히 멈추지 않으려면

맥 예약 작업이 잘 돌고 있는지 점검할 때 최소한 다음을 함께 봐야 합니다.

• 실행 중 목록(launchctl list)에 실제로 잡혀 있는가
• 내부 기록에 '실행 금지'로 잠겨 있지 않은가(print-disabled)
• 마지막 실행 시각이 예상 주기 안에 있는가
• 작업이 의존하는 환경변수가 임시 명령이 아니라 설정 파일에 박혀 재부팅에도 살아남는가
• 손 실행이 아니라 예약 경로를 통해 실행 결과(종료 코드·로그)를 확인했는가

잘못하면 어떻게 되는가. 이 점검을 건너뛰고 파일 존재만 확인하면, 제 경우처럼 자동화가 3주간 멈춰 있어도 모릅니다. keepalive 작업이 멈추면 항상 켜져 있어야 할 브라우저가 아니라 옛 프로필로 연결되어, 로그인 세션이 만료되는 경로가 되살아납니다.

한계와 주의사항. 여기 적은 명령 동작은 macOS 버전에 따라 달라질 수 있습니다. 특히 bootout이 disabled 표시를 남기는 동작, setenv 값이 재부팅 시 사라지는지 여부는 셸 설정·로그인 훅 같은 다른 경로가 얽히면 결과가 달라질 수 있으니 자기 환경에서 재확인해야 합니다. 그리고 마지막 실행 7월 17일 같은 값은 제 개인 로그 기준이라 독자 환경과는 무관합니다. 명령을 실행하기 전에는 되돌릴 방법(원래 plist 백업)을 마련해 두는 것을 권합니다.

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.