node·npm에서 No such file or directory: 삭제된 실행 파일을 부르는 래퍼 찾기

먼저 답하면

node --version이나 npm --version에서 No such file or directory가 나오는데 다른 경로의 Node는 실행된다면, PATH 앞의 node 래퍼가 삭제된 실행 파일을 부르는지 확인한다. 이 경우 프로젝트의 node_modules를 지워도 실행 경로는 고쳐지지 않는다.

먼저 아래 「실제 오류가 난 터미널에서 경로를 좁히기」에서 래퍼의 호출 대상이 사라졌는지 확인한다. macOS zsh에서 아래 순서로 실행한다. /opt/homebrew/bin/node는 이 시험에서 정상 작동한 경로다. 자기 환경에서 확인한 정상 Node 경로로 바꿔야 한다.

whence -va node npm
/opt/homebrew/bin/node --version   # 이 경로가 실제로 정상인지 먼저 확인

# 첫 줄이 alias/function이 아니라 실행 파일이고,
# 정상 Node가 이 디렉터리에 있을 때만 적용
export PATH="/opt/homebrew/bin:$PATH"
rehash
node --version
npm --version
/bin/sh -c 'node --version; npm --version'

성공 기준은 Node와 npm의 버전이 출력되고 오류가 사라지는 것이다. 자식 셸에서도 같은 결과가 나오는지 확인한다. 버전 번호는 설치본에 따라 다르다. 절대 경로 Node부터 실패하면 이 복구를 적용할 근거가 없으므로, 그 경로와 설치 상태부터 확인한다.

어떤 오류를 재현했나

2026년 10월 7일 macOS 26.6.2 arm64, zsh 5.9, Node v26.7.0, npm 11.19.0에서 시험했다. 임시 디렉터리에 node라는 실행 가능한 파일을 만들고 아래 두 줄을 넣었다. /nonexistent-node-demo/bin/node는 시험을 위해 정한 존재하지 않는 경로다.

#!/bin/sh
exec /nonexistent-node-demo/bin/node "$@"

이 파일이 정상 Node보다 PATH 앞에 오도록 격리된 zsh -f 셸을 설정했다. 실제 사용자 설정과 설치 파일은 변경하지 않았다. 현재 맥에서 장애가 발생한 상황이 아니라, 삭제된 프로그램을 부르는 낡은 래퍼의 동작을 새로 재현한 것이다.

실행하면 래퍼에서 다음 핵심 오류가 나온다. 앞의 임시 파일명은 생략했다.

line 2: /nonexistent-node-demo/bin/node: No such file or directory
line 2: exec: /nonexistent-node-demo/bin/node: cannot execute: No such file or directory

실행	PATH 수정 전	수정 후
node --version	종료 코드 126	v26.7.0, 종료 코드 0
npm --version	종료 코드 126	11.19.0, 종료 코드 0
/opt/homebrew/bin/npm --version	종료 코드 126	일반 npm --version으로 확인
/opt/homebrew/bin/node --version	v26.7.0, 종료 코드 0	일반 node --version으로 확인
자식 셸에서 node·npm	수정 전에는 별도 시험 안 함	두 버전 출력, 자식 종료 코드 0

위 126은 이 맥의 /bin/sh 래퍼에서 관찰한 결과다. 모든 No such file or directory의 종료 코드가 126이라는 뜻은 아니다. node 자체를 찾지 못한 경우와 찾은 래퍼 안에서 실행에 실패한 경우를 구별해야 한다.

npm의 절대 경로를 써도 실패한 이유

이 맥의 npm 실행 파일 첫 줄은 #!/usr/bin/env node였다. npm 파일 위치를 정확히 지정해도, 그 스크립트를 실행하는 Node는 전달받은 PATH로 찾는다. 실제로 /opt/homebrew/bin/npm --version도 잘못된 래퍼를 호출해 126으로 끝났다. 정상 Node의 절대 경로 실행은 성공했다.

따라서 npm 위치만 확인해서는 부족하다. npm이 시작할 때 찾는 node까지 확인해야 한다. 이 설명은 직접 읽은 설치본과 위 시험에 한정한다. 다른 npm 설치 방식에서는 실행 파일 구조가 다를 수 있다.

zsh 명령 실행 문서는 이름에 슬래시가 없으면 함수·내장 명령을 확인하고 실행 파일 경로를 찾는다고 설명한다. 이 글의 두 줄짜리 래퍼도 검색 가능한 실행 파일이므로, 파일 자체가 존재한다고 내부의 대상 프로그램까지 존재하는 것은 아니다.

실제 오류가 난 터미널에서 경로를 좁히기

1. whence -va node npm을 실행한다. 이 목록에서 두 번째 이후의 Node 실행 파일 경로도 볼 수 있다. 각 후보를 '/후보/경로/node' --version으로 실행해 정상 후보를 찾는다. 정상 후보가 없으면 이 글의 복구 절차는 멈추고 사용하는 설치·버전 관리 도구의 안내로 돌아간다. node의 첫 결과가 alias 또는 함수이면 alias node 또는 functions node로 정의를 확인한다. npm의 첫 결과도 따로 보고, alias이면 alias npm, 함수이면 functions npm으로 확인한다. 실행 파일 경로가 여럿이면 앞의 경로와 정상이라고 예상하는 경로를 비교한다.
2. 첫 실행 파일을 ls -l '/확인한/경로/node'로 확인한다. 심볼릭 링크이면 대상 경로가 존재하는지 본다. 텍스트 래퍼이면 file '/확인한/경로/node'로 형식을 확인한 뒤 head -n 5 '/확인한/경로/node'로 실제 호출 경로를 읽는다. 바이너리를 텍스트처럼 읽을 필요는 없다.
3. 래퍼의 exec 대상이 없다면 정상 Node를 절대 경로로 실행한다. 이것이 성공해야 위 PATH 복구를 선택할 수 있다.
4. 정상 Node가 들어 있는 디렉터리를 현재 셸의 PATH 맨 앞에 둔다. 이 시험에서는 기존 래퍼를 삭제하지 않고 node·npm을 모두 실행할 수 있었다.
5. 같은 터미널에서 원래 실패한 명령을 다시 실행한다. 버전 확인은 실행 환경 복구 확인일 뿐, 프로젝트의 빌드까지 성공했다는 증거는 아니다.

경로에 공백이 있으면 따옴표를 유지한다. 처음 보는 래퍼를 바로 지우면 버전 관리 도구가 사용하는 연결을 끊을 수 있으므로, 어느 도구가 만들었고 어디를 호출하는지 먼저 확인한다.

PATH만 바꿔도 안 되는 경우

시험에서 node alias가 없는 경로를 가리키면 PATH 복구 뒤에도 127로 실패했다. node라는 셸 함수를 정의하면 정상 Node 대신 함수의 function-node 출력이 나왔다. alias·함수는 실행 파일 PATH 순서를 바꾸는 것만으로 해결되지 않았다.

원하지 않는 정의임을 확인했다면 현재 셸에서 node alias는 unalias node, node 함수는 unfunction node로 해제한다. npm 자체의 alias는 unalias npm, 함수는 unfunction npm을 쓴다. 표시된 정의가 있는 명령에만 적용하고 whence -va node npm, node --version, npm --version으로 다시 검사한다. 시작 파일은 정의의 출처와 용도를 확인한 뒤 고친다. zsh 내장 명령 문서의 whence와 rehash 항목을 참고할 수 있다. rehash는 명령 해시를 비우는 보조 단계이며, 없는 실행 파일을 복원하거나 alias를 없애 주지는 않는다.

export PATH=…는 현재 셸과 그 뒤에 시작하는 자식 프로세스에 전달된다. 이미 열린 IDE나 다른 터미널, 예약 작업의 환경까지 바꿔 주지는 않는다. 복구가 확인되면 사용하는 Node 설치·버전 관리 방식에 맞춰 시작 파일의 PATH 순서나 오래된 래퍼를 정리한다. 이 글은 시작 파일 자동 수정, 버전 관리자 초기화, IDE·예약 실행 환경, Windows와 다른 셸은 시험하지 않았다.