launchd 스크립트가 node를 못 찾을 때, fnm default로 PATH 고정하기

터미널에서는 멀쩡히 돌던 셸 스크립트가 launchd(맥의 cron 격)에 올리면 node: command not found로 끝나는 문제를 고쳤어요. 블로그 초안 생성, 발행, 이미지 큐, 야간 리뷰, 릴리즈 노트까지 5개 스크립트가 같은 방식으로 node를 부르고 있어서 한 군데만 고칠 수 없었고요. 플랜씨·플랜엘 개발 사이사이 사람 손 없이 돌아가는 잡이라, 이런 게 조용히 멈추면 알아채기 어려운 종류예요.

왜 터미널에서는 되고 무인 잡에서는 안 될까

원인은 PATH예요. 무인 잡 안에서 echo "$PATH"를 직접 찍어 보니 시스템 기본 경로 4개(/usr/bin, /bin, /usr/sbin, /sbin)만 들어 있었어요. launchd는 로그인 셸 설정 파일(.zshrc)을 읽지 않으니, 거기서 fnm env로 등록하는 node 경로가 통째로 빠져요. 터미널에서 성공한 테스트는 애초에 다른 환경에서 한 테스트였던 셈이죠.

두 가지 선택지, 그리고 고른 쪽

고칠 방법은 2가지가 보였어요.

1. 스크립트 첫머리에서 eval "$(fnm env)"를 실행한다.
2. fnm이 default 별칭으로 관리하는 경로를 PATH에 직접 넣는다.

1번은 fnm 바이너리 자체도 PATH에 있어야 해서 문제가 한 칸 옆으로 옮겨질 뿐이에요. 그래서 2번을 골랐어요. fnm default <버전>을 실행하면 fnm 디렉터리 아래 aliases/default가 그 버전의 설치 폴더를 가리키는데, 이 링크만 PATH에 넣어 두면 나중에 node 버전을 올려도 스크립트를 다시 손댈 일이 없어요.

# 각 스크립트 상단, 셸 설정에 기대지 않고 경로를 고정
export PATH="$FNM_DIR/aliases/default/bin:$PATH"

FNM_DIR 값은 터미널에서 fnm env를 치면 나와요. 설치 방식에 따라 위치가 다르니 그대로 복사하지 말고 직접 확인하는 편이 좋아요.

적용하고 확인한 것

5개 스크립트에 이 한 줄씩 넣고 적용해 봤더니 커밋 1건, 파일 5개로 끝났어요. 확인은 3단계로 해요. 잡을 수동으로 한 번 띄워 로그에 node 버전이 찍히는지 보고, 예정 시각에 실제로 돌았는지 로그 파일의 갱신 시각을 확인하고, 마지막으로 결과물인 초안 파일이 생겼는지 봐요. 돌려 보니 결과물까지 봐야 안심이 되더라고요. 실행 로그에 성공이라고 찍혀도 파일이 없으면 의미가 없으니까요.

남겨 두는 메모

무인으로 돌리는 스크립트는 "내 터미널에서 되는가"가 아니라 "빈 환경에서 되는가"를 기준으로 봐야 한다는 걸 다시 배웠어요. env -i bash 스크립트.sh처럼 환경변수를 비우고 테스트해 보면 터미널 의존이 바로 드러나요. 혼자 여러 자동화를 굴리는 분이라면 launchd에 올리기 전에 이 한 번을 꼭 거치시길 권해요. 이 글의 초안도 그렇게 고친 파이프라인이 만들어 준 결과예요.