MIORA

[태그:] 리눅스 명령어 오류

  • 리눅스 서버에서 Command Not Found 오류가 발생할 때 해결 방법

    리눅스 서버에서 Command Not Found 오류가 발생할 때 해결 방법

    리눅스 서버에 SSH로 접속해 평소 사용하던 명령어를 실행했는데 갑자기 Command Not Found 오류가 나타난 경험이 있으신가요? 특히 Python이나 Node.js를 설치한 직후, 서버를 재부팅한 뒤, 또는 일반 사용자에서는 실행되던 명령어가 sudo나 Cron 환경에서 실행되지 않을 때 이런 문제가 발생할 수 있습니다.

    명령어를 분명 설치했는데도 bash: command not found라는 메시지가 나오면 프로그램이 제대로 설치되지 않았다고 생각하기 쉽습니다. 하지만 실제로는 PATH 환경변수에 실행 파일 경로가 등록되지 않았거나, 현재 셸과 실행 환경이 달라 명령어를 찾지 못하는 경우도 많습니다.

    이때 프로그램을 무작정 다시 설치하거나 인터넷에서 찾은 PATH 설정을 그대로 복사하면 기존 환경변수를 덮어쓰거나 잘못된 실행 파일을 사용하게 될 수 있습니다. 따라서 먼저 명령어가 실제로 존재하는지, 현재 셸이 어떤 경로에서 실행 파일을 찾는지 구분해서 확인하는 것이 중요합니다.

    이번 글에서는 command -v, type, echo $PATH, find 등의 명령어로 오류 원인을 추적하고, 패키지 설치, PATH 수정, 실행 권한, sudo·Cron 환경 차이, 셸 설정 문제까지 실제 서버 점검 순서대로 해결하는 방법을 살펴봅니다.

    Command Not Found 핵심 명령어 한눈에 보기

    명령어가 실행되지 않는다면 먼저 아래 점검 명령어를 사용하세요. 예제에서는 node 명령어를 기준으로 설명합니다.

    점검 목적 명령어
    명령어 검색 command -v node
    명령어 종류 확인 type -a node
    PATH 확인 printf '%s\n' "$PATH"
    실행 파일 검색 find /usr/local /opt -type f -name node 2>/dev/null
    실행 권한 확인 ls -l /usr/local/bin/node
    sudo 환경 PATH 확인 sudo env | grep '^PATH='

    command -v로 명령어를 찾지 못한다고 해서 프로그램이 반드시 설치되지 않은 것은 아닙니다. 설치된 실행 파일이 PATH에 포함되지 않았거나 현재 셸 환경에서 접근할 수 없는 상태일 수도 있습니다.

    리눅스 Command Not Found 오류와 PATH 환경변수 점검 화면
    Command Not Found 오류 발생 시 command -v와 PATH 환경변수를 확인해 명령어를 찾지 못하는 원인을 점검하는 예시입니다.

    1. Command Not Found 오류가 발생하는 대표적인 원인

    리눅스에서 명령어를 입력하면 셸은 내장 명령어, 함수, 별칭 및 PATH에 등록된 경로 등을 확인해 실행할 대상을 찾습니다.

    이 과정에서 실행할 명령어를 찾지 못하면 셸에 따라 다음과 같은 오류가 표시될 수 있습니다. 

    $ node --version
bash: node: command not found

    대표적인 원인은 다음과 같습니다.

    • 패키지 미설치: 실행하려는 프로그램이 서버에 설치되지 않은 경우
    • PATH 누락: 실행 파일이 있지만 PATH에 해당 디렉터리가 없는 경우
    • 명령어 오타: 대소문자나 명령어 이름을 잘못 입력한 경우
    • 사용자 환경 차이: SSH 사용자와 root 계정의 PATH가 다른 경우
    • 셸 설정 문제: .bashrc, .profile 등의 환경변수 설정이 잘못된 경우
    • 가상환경 문제: Python venv 또는 Node.js 버전 관리 환경이 활성화되지 않은 경우
    • 자동 실행 환경: Cron, systemd 등에서 PATH가 다르게 적용되는 경우

    따라서 Command Not Found 오류는 단순히 패키지를 설치하는 것만으로 해결되지 않을 수 있습니다.

    2. command -v와 type으로 명령어 설치 여부 확인하기

    가장 먼저 확인할 것은 현재 셸이 해당 명령어를 찾을 수 있는지입니다. 

    command -v node

    정상적으로 찾을 수 있다면 다음과 같은 경로가 표시될 수 있습니다. 

    /usr/bin/node

    아무 결과도 나타나지 않는다면 현재 환경에서 해당 명령어를 찾지 못하고 있다는 의미입니다.

    명령어가 별칭인지, 셸 함수인지, 실행 파일인지까지 확인하려면 다음 명령어를 사용합니다. 

    type -a node

    예를 들어 다음과 같은 결과가 나타날 수 있습니다.

    node is /usr/local/bin/node
node is /usr/bin/node

    이 경우 같은 이름의 실행 파일이 여러 위치에 존재한다는 것을 알 수 있습니다. 실제 실행되는 파일은 PATH 검색 순서와 셸 상태에 영향을 받습니다.

    여러 버전의 Python이나 Node.js를 설치한 서버에서는 어떤 경로의 실행 파일이 우선 사용되는지 확인하는 것이 특히 중요합니다.

    3. PATH 환경변수가 잘못됐는지 확인하기

    명령어가 설치되어 있는데도 실행되지 않는다면 PATH 환경변수를 확인해야 합니다. 

    echo "$PATH"

    일반적으로 다음과 같은 결과가 표시됩니다.

    /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

    PATH는 셸이 실행 파일을 검색하는 디렉터리 목록입니다. 각 경로는 콜론(:)으로 구분됩니다.

    예를 들어 프로그램이 /opt/myapp/bin에 설치되어 있는데 해당 경로가 PATH에 없다면 명령어 이름만으로는 실행되지 않을 수 있습니다.

    먼저 절대경로로 실행할 수 있는지 확인합니다. 

    /opt/myapp/bin/mytool --version

    절대경로에서는 실행되지만 mytool만 입력하면 실패한다면 PATH 문제일 가능성이 높습니다.

    현재 셸에서 임시로 경로를 추가하려면 다음과 같이 사용합니다. 

    export PATH="$PATH:/opt/myapp/bin"

    다시 명령어를 확인합니다. 

    command -v mytool
mytool --version

    이 설정은 현재 셸 세션에 적용됩니다. 새로운 로그인에서도 사용하려면 실제 셸 종류와 로그인 방식에 맞는 환경 설정 파일에 추가해야 합니다.

    PATH를 수정할 때 기존 값을 제거하고 새 경로만 지정하면 ls, cp 같은 기본 명령어까지 찾지 못하는 문제가 발생할 수 있으므로 주의해야 합니다.

    4. 프로그램이 설치되지 않았다면 패키지 관리자 확인하기

    실행 파일을 찾을 수 없다면 패키지가 실제로 설치되어 있는지 확인합니다.

    Ubuntu 또는 Debian 계열에서는 설치된 패키지를 다음과 같이 조회할 수 있습니다. 

    dpkg -l | grep -i curl

    설치되지 않은 것이 확인됐고 해당 프로그램이 필요한 상황이라면 패키지 관리자를 통해 설치할 수 있습니다. 

    sudo apt update
sudo apt install curl

    RHEL, Rocky Linux, AlmaLinux 등 DNF 기반 환경에서는 다음과 같은 방법을 사용할 수 있습니다. 

    sudo dnf install curl

    다만 모든 프로그램이 배포판 기본 저장소에 존재하는 것은 아닙니다. Node.js, Python 또는 특정 개발 도구는 별도 저장소나 버전 관리 도구로 설치됐을 수 있으므로 기존 설치 방식을 먼저 확인하는 것이 좋습니다.

    5. 실행 파일은 있는데 명령어가 실행되지 않는 경우

    파일이 존재한다면 먼저 실행 권한과 파일 유형을 확인합니다. 

    ls -l /opt/myapp/bin/mytool
file /opt/myapp/bin/mytool

    실행 권한이 없다면 일반적으로 Command Not Found보다는 Permission denied 같은 오류가 발생할 수 있습니다.

    스크립트 파일의 경우 첫 줄에 지정된 인터프리터가 존재하지 않거나 줄바꿈 형식이 잘못되어도 실행이 실패할 수 있습니다. 

    head -n 1 /opt/myapp/bin/mytool

    예를 들어 스크립트가 존재하지 않는 인터프리터를 참조한다면 파일 자체는 있어도 실행 과정에서 오류가 발생합니다.

    또한 현재 디렉터리에 있는 실행 파일은 현재 디렉터리가 PATH에 포함되지 않았다면 이름만으로 실행되지 않을 수 있습니다. 

    ./script.sh

    이때는 실행 권한이 있어야 하며, 권한이 없다면 파일 소유자와 실행 목적을 확인한 뒤 필요한 권한만 부여해야 합니다.

    6. sudo에서는 명령어가 실행되지 않는 이유

    일반 사용자 계정에서는 정상적으로 실행되던 명령어가 sudo를 붙이면 찾을 수 없다는 오류를 표시하는 경우도 있습니다. 

    $ mytool --version
mytool 1.0

$ sudo mytool --version
sudo: mytool: command not found

    이는 일반 사용자와 sudo 실행 환경의 PATH가 다르기 때문일 수 있습니다. 일부 시스템에서는 sudoers의 secure_path 설정이 명령어 검색 경로에 영향을 줍니다.

    먼저 일반 사용자와 sudo 환경의 PATH를 비교합니다. 

    echo "$PATH"
sudo env | grep '^PATH='

    실행 파일의 실제 위치도 확인합니다. 

    command -v mytool

    필요하다면 신뢰할 수 있는 실행 파일의 절대경로를 지정해 실행할 수 있습니다. 

    sudo /opt/myapp/bin/mytool --version

    다만 사용자별로 설치된 개발 도구를 root 권한으로 실행하면 파일 소유권이나 환경 설정이 달라질 수 있으므로 해당 프로그램에 관리자 권한이 실제로 필요한지 먼저 판단해야 합니다.

    7. SSH에서는 되는데 Cron과 systemd에서는 실패하는 경우

    SSH로 직접 로그인하면 정상적으로 실행되는 명령어가 Cron이나 systemd 서비스에서만 실패하는 경우가 있습니다.

    이는 자동 실행 환경이 사용자의 로그인 셸과 동일한 환경변수를 불러오지 않을 수 있기 때문입니다.

    Cron 작업에서는 실행 파일의 절대경로를 사용하는 것이 좋습니다. 

    /usr/bin/python3 /opt/scripts/backup.py

    필요하다면 Crontab에 명시적으로 PATH를 지정할 수도 있습니다. 

    PATH=/usr/local/bin:/usr/bin:/bin

0 2 * * * /usr/bin/python3 /opt/scripts/backup.py

    systemd 서비스라면 서비스 유닛의 ExecStart에 실행 파일의 절대경로를 지정하는 방식이 명확합니다. 

    ExecStart=/usr/bin/python3 /opt/scripts/backup.py

    특히 Python 가상환경이나 Node.js 버전 관리 도구를 사용하는 경우 일반 셸에서만 설정되는 경로에 의존하지 않도록 구성해야 합니다.

    8. .bashrc와 .profile 수정 후 명령어가 사라졌다면

    환경변수 설정을 수정한 직후 기본 명령어까지 실행되지 않는다면 PATH가 잘못 덮어써졌는지 확인해야 합니다.

    예를 들어 다음 설정은 기존 PATH를 제거합니다.

    export PATH="/opt/myapp/bin"

    이 경우 기본 명령어 디렉터리가 PATH에서 빠질 수 있습니다.

    기존 경로를 유지하면서 추가하려면 다음처럼 작성합니다. 

    export PATH="$PATH:/opt/myapp/bin"

    이미 PATH가 잘못 설정됐다면 현재 셸에서 임시로 기본 경로를 복구할 수 있습니다. 

    export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

    그다음 실제로 잘못 수정한 .bashrc, .profile 등 환경 설정 파일을 확인하고 수정해야 합니다.

    환경 설정 파일을 수정한 뒤에는 새 셸에서 테스트하는 것이 좋으며, 현재 SSH 세션을 바로 종료하지 않는 편이 안전합니다.

    실전 점검 순서

    예를 들어 서버에서 node 명령어가 실행되지 않는다면 다음 순서대로 확인할 수 있습니다. 

    # 1. 명령어 존재 여부 확인
command -v node

# 2. 명령어 종류와 경로 확인
type -a node

# 3. PATH 환경변수 확인
echo "$PATH"

# 4. 설치 경로 검색
find /usr/local /opt -type f -name node 2>/dev/null

# 5. 실제 파일이 있다면 권한 확인
ls -l /usr/local/bin/node

# 6. 절대경로로 실행 테스트
/usr/local/bin/node --version

# 7. PATH에 경로가 없다면 임시 추가
export PATH="$PATH:/usr/local/bin"

# 8. 다시 명령어 확인
command -v node
node --version

    위 경로는 예시입니다. 실제 실행 파일의 위치는 배포판과 설치 방법에 따라 달라질 수 있습니다.

    또한 command -v 결과가 비어 있어도 실행 파일이 다른 위치에 존재할 수 있으므로 바로 재설치하기보다 PATH와 설치 경로를 함께 확인하는 것이 좋습니다.

    정리

    리눅스 서버에서 Command Not Found 오류가 발생했다면 프로그램이 설치되지 않았다고 단정하기보다 명령어 검색 경로, 실행 파일 존재 여부, 사용자 환경 차이부터 확인해야 합니다.

    가장 먼저 기억할 명령어는 다음 세 가지입니다. 

    command -v 명령어
type -a 명령어
echo "$PATH"

    명령어가 설치되어 있다면 절대경로로 실행되는지 확인하고, PATH가 잘못됐다면 기존 경로를 유지하면서 필요한 디렉터리만 추가합니다.

    특히 SSH에서는 정상 실행되는데 sudo, Cron, systemd에서만 실패한다면 각 실행 환경의 PATH와 설정을 비교해야 합니다. 명령어 재설치보다 현재 환경에서 실행 파일을 어떻게 찾고 있는지 확인하는 것이 문제를 빠르게 해결하는 핵심입니다.