증상 → 수업에서 요구한 requests 설치 중 pip를 찾을 수 없거나 권한 오류가 납니다. 먼저 Python 3.14와 pip의 경로가 같은지 확인한 뒤, 프로젝트 안에 venv를 만들고 그 환경의 Python으로 pip를 실행하십시오.

이 방법은 Python 3.14를 이미 설치했지만 pip가 없거나 오래된 버전을 가리키는 학생에게 맞습니다. externally-managed-environment, Permission denied, 인증서 오류, 패키지 빌드 실패가 나온 경우에도 아래 순서로 원인을 좁힐 수 있습니다.

실패 사례부터 확인하기: 재설치보다 명령 경로 점검

수업에서 requests를 설치하라는 안내를 받고 다음처럼 입력했다고 가정하겠습니다.

pip install requests

그런데 터미널에는 command not found가 표시됩니다. 또는 설치는 되지만 pip --version이 오래된 Python 경로를 보여 줍니다.

이때 Python을 바로 지우고 다시 설치하지 마십시오. 한 대의 맥에는 여러 Python 해석기가 함께 있을 수 있습니다. 터미널이 부르는 python3, pip, pip3가 서로 다른 설치를 가리키면 설치 성공과 코드 실행 결과가 엇갈립니다.

먼저 다음 네 명령의 결과를 확인하십시오.

python3 --version
python3 -c "import sys; print(sys.executable)"
python3 -m pip --version
command -v python3

Python 3.14를 사용하려는 목적이라면 첫 번째 결과가 기대한 버전인지 확인합니다. 두 번째 명령은 실제 해석기 위치를 보여 줍니다. 세 번째 명령은 현재 python3에 연결된 pip의 버전과 위치를 확인하는 방법입니다. pip라는 짧은 명령보다 python3 -m pip를 우선하는 이유도 여기에 있습니다. Python의 pip 사용 문서는 pip를 명령줄에서 호출하는 방법을 설명합니다.

관찰할 점

  • Python 버전이 3.14가 아닌가요?
  • pip 경로가 Python 해석기와 다른 설치 폴더를 가리키나요?
  • python3 -m pip만 실패하나요?
  • 단순히 pip 명령만 셸에서 찾지 못하나요?

첫 번째와 두 번째가 맞지 않으면 재설치보다 PATH와 해석기 선택을 먼저 고쳐야 합니다.

첫 번째 조치: 현재 Python에 연결된 pip 복구

문제는 세 종류로 나눌 수 있습니다.

pip 자체가 없는 경우

공식 Python 설치 과정과 현재 해석기의 설치 기능을 먼저 확인하십시오. Python 3.14의 모듈 설치 안내에는 패키지 설치와 가상 환경을 함께 다루는 절차가 있습니다. Python 3.14 공식 설치 안내를 기준으로 설치 상태를 확인하십시오.

현재 Python에 pip 설치 기능이 남아 있는지 확인하려면 다음처럼 실행할 수 있습니다.

python3 -m ensurepip --default-pip

이 명령의 동작과 선택 항목은 ensurepip 공식 문서에서 확인해야 합니다. 출처가 불분명한 복구 스크립트를 내려받아 실행하지 마십시오.

pip 파일은 있지만 실행되지 않는 경우

다음 순서로 다시 확인합니다.

python3 -m pip --version
python3 -m pip list

pip가 버전을 표시하면 짧은 pip 명령이 없어도 현재 Python 환경에서는 사용할 수 있습니다. 수업 명령을 그대로 바꾸고 싶다면 셸의 PATH 설정을 확인해야 하지만, 초보자라면 프로젝트마다 python3 -m pip 형식을 사용하는 편이 혼동이 적습니다.

셸이 pip 명령만 찾지 못하는 경우

python3 -m pip --version은 되는데 pip --version만 실패한다면 pip가 없는 것이 아닐 수 있습니다. 두 명령은 셸이 찾는 실행 파일과 연결된 Python이 다를 수 있습니다.

복구 후의 기준은 단순합니다.

  • pip가 버전을 표시합니다.
  • 표시된 경로가 사용하려는 Python 3.14 환경과 연결됩니다.
  • 설치 뒤 같은 환경에서 작은 import 테스트가 실행됩니다.

두 번째 조치: 전역 환경 대신 프로젝트별 venv 만들기

전역 Python 환경은 여러 수업이나 도구가 함께 쓰는 공용 교실과 같습니다. 한 프로젝트가 패키지 버전을 바꾸면 다른 과제가 영향을 받을 수 있습니다. venv는 프로젝트마다 따로 쓰는 독립 작업 책상입니다.

프로젝트 폴더에서 다음을 실행하십시오.

python3 -m venv .venv
source .venv/bin/activate
python -c "import sys; print(sys.executable)"
python -m pip --version

venv의 생성과 활성화 방식은 Python 3.14 venv 공식 문서에 설명되어 있습니다. 활성화가 되면 터미널 앞부분에 .venv가 표시될 수 있습니다. 가장 확실한 확인 방법은 sys.executable이 프로젝트 안의 .venv 경로를 가리키는지 보는 것입니다.

이제 패키지를 설치합니다.

python -m pip install requests

작업을 마치면 다음으로 빠져나옵니다.

deactivate

externally-managed-environment가 표시될 때는 전역 환경을 억지로 수정하지 마십시오. Python Packaging의 외부 관리 환경 규격은 운영 체제나 다른 관리 도구가 맡은 환경을 직접 변경하지 않도록 구분하는 이유를 설명합니다. 외부 관리 환경 규격을 참고하면 오류를 우회하기보다 venv를 선택해야 하는 이유를 이해할 수 있습니다.

하지 말아야 할 행동

  • sudo pip install ...로 전역 설치를 강제하지 않습니다.
  • 보호된 시스템 폴더의 권한을 바꾸지 않습니다.
  • 외부 관리 표시를 강제로 무시하지 않습니다.
  • 학교 기기의 관리 정책을 우회하지 않습니다.

세 번째 조치: SSL과 학교 네트워크 오류를 분리하기

다운로드 실패가 모두 pip 문제는 아닙니다. 오류 문구를 다음처럼 나누어 보십시오.

  • 인증서 검증 실패: Python 또는 네트워크의 인증서 설정을 확인합니다.
  • 도메인에 연결하지 못함: 인터넷, DNS, 학교 방화벽 상태를 확인합니다.
  • 프록시 관련 오류: 학교가 요구하는 공식 프록시 설정이 있는지 문의합니다.
  • 중간에 연결이 끊김: 다른 허용 네트워크에서 같은 명령을 재현합니다.

공식 Python macOS 설치 프로그램을 사용했다면 인증서 설정 절차는 Python의 macOS 공식 설명에서 확인하십시오. 인증서 검증을 끄거나 안전하지 않은 옵션을 붙여 오류를 숨기면 안 됩니다. 학교 네트워크를 우회하는 방법도 안내할 수 없습니다.

낮은 위험의 확인 순서는 다음과 같습니다.

  1. 브라우저에서 공식 패키지 저장소에 접속되는지 확인합니다.
  2. 학교 네트워크 정책상 개발 도구 다운로드가 허용되는지 묻습니다.
  3. 허용된 다른 네트워크에서 동일한 venv 명령을 재실행합니다.
  4. 어느 환경에서만 실패하는지 오류 전문을 기록합니다.

다른 네트워크에서도 같은 인증서 오류가 계속되면 Python macOS 문서와 설치 방식부터 다시 확인하십시오. 특정 네트워크에서만 실패하면 pip를 재설치해도 해결되지 않습니다.

네 번째 조치: 패키지 버전과 Apple Silicon 호환성 확인

No matching distribution found나 빌드 실패는 pip가 고장 났다는 뜻이 아닙니다. 가능한 원인은 패키지가 Python 3.14를 아직 지원하지 않거나, 사용하는 맥의 처리 방식에 맞는 배포 파일이 없거나, 수업이 요구하는 Python 버전과 패키지 조건이 충돌하는 경우입니다.

Python 패키지는 완성된 교재를 내려받는 경우와 현장에서 교재를 제본하는 경우가 있습니다. wheel은 미리 준비된 배포 형식에 가깝고, wheel이 없으면 설치 과정에서 소스 빌드가 시도될 수 있습니다. Python 패키지 형식 안내와 바이너리 배포 형식 설명에서 이 차이를 확인할 수 있습니다.

다음 순서로 판단하십시오.

  • 패키지 공식 문서에서 Python 3.14 지원 여부를 확인합니다.
  • PyPI 메타데이터에서 현재 버전의 배포 파일과 지원 조건을 확인합니다.
  • Apple Silicon용 완성 배포 파일이 있는지 확인합니다.
  • 수업에서 지정한 Python 버전이 따로 있는지 확인합니다.
  • 호환되는 패키지 버전이나 수업 권장 Python 버전을 선택합니다.

패키지 하나의 실패를 근거로 모든 Python 패키지가 3.14에서 작동하지 않는다고 일반화하면 안 됩니다. 호환성은 패키지별 공식 기록으로 판단해야 합니다.

편집기에서는 설치됐는데 import가 안 될 때

터미널에서 설치가 성공해도 VS Code나 수업 프로젝트에서 import가 실패할 수 있습니다. 설치한 환경과 실행하는 환경이 다르기 때문입니다.

먼저 활성화된 터미널에서 확인합니다.

python -c "import sys; print(sys.executable)"
python -m pip show requests
python -c "import requests; print(requests.__file__)"

그다음 편집기의 Python 해석기를 프로젝트의 .venv로 선택합니다. 편집기에서 선택한 경로가 터미널의 sys.executable 결과와 같은 환경인지 비교하십시오.

최소 검사는 다음처럼 할 수 있습니다.

import requests
print("import success")

여기서 성공하면 패키지 설치 위치와 실행 환경이 일치할 가능성이 높습니다. 실패하면 같은 패키지를 반복 설치하지 말고 다음 세 가지를 다시 확인하십시오.

  • 편집기가 선택한 Python 경로
  • 터미널에서 활성화된 .venv
  • 실제로 실행한 파일과 프로젝트 폴더

중간 점검: 수업 환경을 바꾸어야 하는 조건

현재 맥에서 계속 수정할지, 깨끗한 원격 맥에서 먼저 과제를 검증할지 다음 목록으로 판단하십시오.

  • [ ] Python 3.14 해석기의 실제 경로를 확인했습니다.
  • [ ] 현재 해석기로 python -m pip --version이 실행됩니다.
  • [ ] 프로젝트 폴더 안에 .venv를 만들었습니다.
  • [ ] 활성화 뒤 sys.executable이 .venv를 가리킵니다.
  • [ ] python -m pip install 패키지이름을 사용했습니다.
  • [ ] 인증서 검증을 끄지 않고 네트워크 원인을 분리했습니다.
  • [ ] 패키지 공식 문서와 PyPI에서 Python 3.14 및 Apple Silicon 조건을 확인했습니다.
  • [ ] 편집기의 해석기가 터미널의 .venv와 같습니다.
  • [ ] 최소 import 테스트가 성공했습니다.
  • [ ] 오류 전문과 성공한 명령을 기록했습니다.

학교 기기에서 관리자 권한이 없더라도 이 목록의 앞부분은 허용될 수 있습니다. 그러나 .venv 생성, 외부 연결, 실행 파일 생성까지 막혀 있다면 정책을 우회하지 마십시오. 같은 과제를 권한이 분리된 환경에서 검증한 뒤 담당자에게 필요한 권한을 문의하는 편이 안전합니다.

자주 묻는 문제를 한 번에 정리하기

pip와 pip3의 차이는 이름보다 연결된 Python이 중요합니다. 두 명령이 같은 해석기를 가리킨다고 가정하지 말고 python -m pip --version으로 확인하십시오.

프로젝트마다 venv를 만들어야 하는지는 수업별 패키지 버전이 다를 때 특히 중요합니다. 작은 실습이라도 독립 환경을 사용하면 전역 환경을 오염시키지 않고 다시 만들 수 있습니다.

터미널을 닫았다고 venv가 삭제되지는 않습니다. 다음 학습 때 프로젝트 폴더로 이동해 다시 활성화하면 됩니다.

cd 프로젝트폴더
source .venv/bin/activate

반대로 .venv 폴더를 지웠다면 그 안의 패키지도 사라집니다. 설치 명령이나 requirements.txt를 보관해 두면 같은 환경을 다시 만들기 쉽습니다. 패키지 설치 방식은 pip 공식 명령 문서를 기준으로 기록하십시오.

장비를 바꿀지 결정하는 마지막 기준

Python 3.14 pip 설치 실패는 대부분 재설치 문제가 아니라 경로, 전역 환경, 네트워크, 패키지 호환성 중 하나입니다. 먼저 현재 Python으로 pip를 호출하고, 프로젝트별 venv에서 import까지 확인하십시오.

학교 컴퓨터는 관리자 권한과 네트워크 정책이 제한될 수 있습니다. 기존 환경은 오래된 Python 경로와 전역 패키지가 섞여 있을 수 있습니다. 이런 상태에서 마감 직전 계속 재설치하면 원인 기록도 사라지고 같은 오류가 반복됩니다.

반대로 장기간 같은 무거운 작업을 계속하고, 물리적인 USB 장치나 로컬 파일 접근이 필요하다면 직접 관리하는 Mac이 더 적합할 수 있습니다. 원격 환경은 네트워크 지연, 파일 업로드 절차, 세션 접근 권한을 확인해야 하며 모든 상황에서 자가 구매를 대신하지는 않습니다.

다만 지금 필요한 것이 수업 프로젝트의 venv 생성과 패키지 import 확인이라면, MACCOME의 한국어 원격 Mac 환경에서 깨끗한 개발 환경을 먼저 시험해 보는 선택지가 있습니다. 학교 기기의 전역 권한 문제와 오래된 PATH를 그대로 끌고 가지 않고, 같은 프로젝트의 설치 과정을 다시 기록할 수 있기 때문입니다. Mac mini 환경을 직접 비교하고 싶다면 Mac mini 주문 안내에서 사용 가능한 방식을 확인한 뒤, 단기 검증인지 장기 사용인지에 맞춰 결정하십시오.

결정 기준은 간단합니다. 현재 기기에서 .venv와 최소 import가 성공하면 그대로 사용하십시오. 권한, 인증서 정책, 오래된 환경이 수업 진행을 막는다면 먼저 깨끗한 원격 Mac에서 동일한 검증을 완료한 뒤 원래 장비를 계속 고칠지 판단하십시오.