ModuleNotFoundError: No module named 해결: pip install 했는데 모듈이 없다고 나올 때 (윈도우·맥·리눅스)

작성 0xmote · 2026년 10월 26일 · 16분 읽기 · 수정 2026년 10월 26일 초급 가이드

이 글의 핵심

pip install은 성공했는데 실행하면 ModuleNotFoundError: No module named 'xxx'가 나는 경우, 원인의 대부분은 패키지가 설치된 파이썬과 코드를 실행하는 파이썬이 서로 다르다는 데 있습니다. sys.executable과 pip -V로 두 인터프리터를 비교하는 방법, python -m pip로 설치 대상을 고정하는 방법, PowerShell에서 venv 활성화가 막힐 때, VS Code와 Jupyter가 다른 파이썬을 쓰는 경우, 설치 이름과 import 이름이 다른 패키지, 내 모듈의 상대 import 오류와 같은 이름의 파일이 라이브러리를 가리는 경우까지 순서대로 짚습니다.

설치는 됐는데 import가 안 되는 이유

다음 상황은 파이썬을 처음 배울 때뿐 아니라 몇 년 쓴 사람에게도 자주 생깁니다.

> pip install requests
Successfully installed ... requests-2.32.x ...

> python app.py
Traceback (most recent call last):
  File "C:\Users\me\proj\app.py", line 1, in <module>
    import requests
ModuleNotFoundError: No module named 'requests'

pip는 분명히 설치에 성공했다고 했는데, 파이썬은 그런 모듈이 없다고 합니다. 둘 다 거짓말을 하는 것은 아닙니다. 컴퓨터에 파이썬이 두 개 이상 있고, pip라는 명령은 그중 하나에 패키지를 넣었으며, python이라는 명령은 다른 하나를 실행한 것입니다. 패키지는 파이썬 설치본마다 따로 있는 site-packages 폴더에 들어가기 때문에, A 파이썬에 설치한 패키지는 B 파이썬에서 보이지 않습니다.

이 글은 이 “인터프리터 불일치”를 먼저 확인하고, 그다음으로 흔한 원인인 설치 이름과 import 이름의 차이, 내가 만든 모듈을 못 찾는 경우, 내 파일이 라이브러리를 가리는 경우를 차례로 다룹니다.

기준 환경: 윈도우 10/11에 python.org 설치 프로그램으로 파이썬을 설치한 경우(PowerShell 기준), 그리고 맥·리눅스의 python3. 아래 출력 예시는 윈도우 11에서 파이썬 3.11과 3.13을 함께 설치한 상태로 실제 실행한 결과이며, 사용자 경로만 C:\Users\me로 바꿨습니다. 맥과 리눅스에서는 python 대신 python3, Scripts 대신 bin으로 읽으면 됩니다.

첫 번째 확인: 두 개의 파이썬을 눈으로 비교하기

추측하기 전에 “코드를 실행하는 파이썬”과 “pip가 설치하는 파이썬”이 무엇인지부터 출력해 봅니다. 아래 두 명령이면 충분합니다.

python -c "import sys; print(sys.executable)"
pip -V

sys.executable은 지금 실행 중인 파이썬 실행 파일의 전체 경로입니다. pip -V는 pip 버전과 함께 그 pip가 속한 파이썬의 site-packages 경로와 버전을 알려 줍니다. 두 경로가 같은 파이썬 폴더를 가리키지 않으면 원인은 거의 확정입니다.

파이썬 3.11과 3.13이 함께 깔린 윈도우에서 실제로 확인한 결과는 다음과 같습니다.

> python -c "import sys; print(sys.executable)"
C:\Users\me\AppData\Local\Programs\Python\Python311\python.exe

> py -c "import sys; print(sys.executable)"
C:\Users\me\AppData\Local\Programs\Python\Python313\python.exe

> py -0p
 -V:3.13 *        C:\Users\me\AppData\Local\Programs\Python\Python313\python.exe
 -V:3.11          C:\Users\me\AppData\Local\Programs\Python\Python311\python.exe
 -V:3.9           C:\Users\me\AppData\Local\Programs\Python\Python39\python.exe

python을 치면 3.11이, py를 치면 3.13이 실행됩니다. python은 PATH에서 먼저 발견되는 python.exe를 쓰고, py 런처는 PATH와 상관없이 설치된 것 중 가장 최신 버전(별표 표시)을 기본으로 고르기 때문입니다. 이 상태에서 py -m pip install requests로 설치하고 python app.py로 실행하면 정확히 위의 오류가 납니다.

pip 명령 자체도 PATH 순서를 탑니다. where.exe로 보면 어떤 것들이 후보인지 드러납니다.

> where.exe python pip
C:\Users\me\AppData\Local\Programs\Python\Python311\python.exe
C:\Users\me\AppData\Local\Programs\Python\Python313\python.exe
C:\Users\me\AppData\Local\Microsoft\WindowsApps\python.exe
C:\Users\me\AppData\Local\Programs\Python\Python311\Scripts\pip.exe
C:\Users\me\AppData\Local\Programs\Python\Python313\Scripts\pip.exe

WindowsApps\python.exe는 실제 파이썬이 아니라 마이크로소프트 스토어로 안내하는 바로가기(앱 실행 별칭)입니다. 이것이 PATH에서 먼저 잡히면 python을 쳤을 때 스토어가 열리거나 Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases.라는 메시지가 나옵니다. 설정 → 앱 → 고급 앱 설정 → 앱 실행 별칭에서 python.exe, python3.exe 항목을 끄면 정리됩니다.

맥과 리눅스에서는 다음으로 같은 확인을 합니다.

which -a python3 pip3
python3 -c "import sys; print(sys.executable)"
pip3 -V

맥에서는 Xcode 명령줄 도구의 /usr/bin/python3, Homebrew의 /opt/homebrew/bin/python3, python.org 설치본이 동시에 있는 경우가 흔하고, 리눅스에서는 배포판 파이썬과 직접 빌드하거나 pyenv로 설치한 파이썬이 섞이는 경우가 흔합니다.

해결의 기본: pip 대신 python -m pip

인터프리터 불일치를 근본적으로 피하는 방법은 pip를 단독 명령으로 부르지 않고, 실행할 파이썬에게 직접 pip를 돌리게 하는 것입니다.

python -m pip install requests
python app.py

python -m pip는 “이 python의 모듈 경로에서 pip 모듈을 찾아 실행하라”는 뜻이라, 설치 대상이 항상 그 python이 됩니다. 앞의 명령과 뒤의 명령이 같은 단어(python)로 시작하므로, PATH가 어떻게 꼬여 있든 설치한 곳과 실행하는 곳이 일치합니다. 파이썬 공식 문서의 패키지 설치 안내도 이 형태를 기준으로 씁니다.

특정 버전을 지정해야 하는 경우에도 같은 원리입니다.

py -3.11 -m pip install requests   # 윈도우: 3.11에 설치
py -3.11 app.py                     # 3.11로 실행

python3.12 -m pip install requests  # 맥·리눅스: 3.12에 설치
python3.12 app.py

설치 여부를 확인할 때도 pip list 대신 python -m pip list 또는 python -m pip show <패키지>를 씁니다. 가상환경에만 설치하고 전역 파이썬으로 확인하면 다음처럼 서로 다른 답이 나옵니다.

> .venv\Scripts\python.exe -m pip show tomli-w
Name: tomli_w
Version: 1.2.0
...

> python -m pip show tomli-w
WARNING: Package(s) not found: tomli-w

> python -c "import tomli_w"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'tomli_w'

pip list에는 있는데 import가 안 된다는 질문은 거의 항상 이 경우입니다. 목록을 보여 준 pip와 코드를 실행한 파이썬이 다른 것입니다.

한 가지 덧붙이면, 우분투 23.04 이상이나 데비안 12, Homebrew 파이썬에서는 python3 -m pip install이 error: externally-managed-environment로 거부됩니다. 이것은 다른 문제이고 해결책도 가상환경을 쓰는 쪽입니다. 자세한 내용은 pip install externally-managed-environment 오류 해결에 정리해 두었습니다.

가상환경: 활성화했다고 생각했는데 안 된 경우

프로젝트마다 가상환경(venv)을 만드는 것은 버전 충돌을 막는 좋은 습관이지만, 동시에 파이썬이 하나 더 생긴다는 뜻이기도 합니다. 가상환경을 만들고 그 안에 설치했는데 활성화를 빼먹은 채 실행하면, 바로 앞에서 본 불일치가 그대로 재현됩니다.

python -m venv .venv
.venv\Scripts\Activate.ps1      # PowerShell
# .venv\Scripts\activate.bat    # cmd
# source .venv/bin/activate     # 맥·리눅스
python -m pip install requests

활성화가 실제로 됐는지는 프롬프트 앞의 (.venv) 표시만 믿기보다 sys.executable로 확인하는 편이 확실합니다. 활성화된 상태라면 경로가 프로젝트 폴더 안의 .venv\Scripts\python.exe로 나옵니다. 가상환경 안인지 판단하는 다른 방법은 sys.prefix와 sys.base_prefix를 비교하는 것으로, 두 값이 다르면 가상환경 안입니다.

> .venv\Scripts\python.exe -c "import sys; print(sys.prefix); print(sys.base_prefix)"
C:\Users\me\proj\.venv
C:\Users\me\AppData\Local\Programs\Python\Python311

PowerShell: running scripts is disabled on this system

윈도우 PowerShell에서 처음 venv를 활성화하면 다음 오류를 만나는 경우가 많습니다.

.\.venv\Scripts\Activate.ps1 : File C:\Users\me\proj\.venv\Scripts\Activate.ps1 cannot be loaded because
running scripts is disabled on this system. For more information, see about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

한국어 윈도우에서는 “이 시스템에서 스크립트를 실행할 수 없으므로 … 파일을 로드할 수 없습니다”로 나옵니다. Activate.ps1은 PowerShell 스크립트이고, 윈도우 클라이언트의 기본 실행 정책(Restricted)은 .ps1 스크립트 실행을 막기 때문입니다. 오류가 난 시점에서 활성화는 일어나지 않았으므로, 이 상태로 pip install을 계속하면 전역 파이썬에 설치됩니다. 오류 메시지를 무시하고 넘어간 뒤 ModuleNotFoundError를 만나는 흐름이 흔합니다.

해결 방법은 현재 사용자 범위에서만 실행 정책을 완화하는 것입니다.

Get-ExecutionPolicy -List
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

RemoteSigned는 로컬에서 만든 스크립트는 실행하고, 인터넷에서 내려받은 스크립트는 서명이 있어야 실행하는 정책입니다. -Scope CurrentUser라서 관리자 권한이 필요 없고 다른 사용자에게 영향을 주지 않습니다. 회사 PC처럼 그룹 정책으로 실행 정책이 고정돼 있으면 이 명령이 무시될 수 있는데, 그때는 다음 두 방법 중 하나를 쓰면 됩니다.

그 창에서만 정책을 바꿉니다: Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process. 창을 닫으면 원래대로 돌아갑니다.
활성화 없이 가상환경의 파이썬을 직접 부릅니다: .venv\Scripts\python.exe -m pip install requests, .venv\Scripts\python.exe app.py. 활성화는 PATH 앞에 .venv\Scripts를 끼워 넣는 편의 기능일 뿐이라, 경로를 직접 쓰면 똑같이 동작합니다.

두 번째 방법은 스크립트나 자동화에서 특히 유용합니다. 활성화 상태는 터미널 창마다 따로라서, 새 창을 열거나 IDE가 새 터미널을 띄우면 다시 풀립니다. 파이썬 경로를 직접 적어 두면 그런 상태에 의존하지 않습니다.

VS Code: 터미널은 맞는데 실행 버튼이 다른 파이썬을 쓸 때

VS Code에서는 같은 파일을 실행하는 방법이 여러 가지이고, 각각 다른 파이썬을 쓸 수 있습니다. 통합 터미널에서 python app.py를 치면 그 터미널의 PATH를 따르고, 오른쪽 위 실행 버튼(▷)이나 디버거(F5)는 Python 확장에 선택된 인터프리터를 씁니다. 터미널에서 venv를 활성화하고 설치했는데 실행 버튼을 누르면 ModuleNotFoundError가 나는 경우가 이 차이입니다. 편집기에서 import 줄에 노란 물결선이 생기고 Import "requests" could not be resolved가 표시되는 것도 같은 원인입니다. 이 경고는 Pylance가 선택된 인터프리터의 site-packages에서 패키지를 찾지 못했다는 뜻입니다.

확인과 수정은 다음 순서로 합니다.

창 오른쪽 아래 상태 표시줄에 표시된 파이썬 버전을 봅니다. 여기 나온 것이 실행 버튼과 Pylance가 쓰는 인터프리터입니다.
Ctrl+Shift+P → Python: Select Interpreter를 실행하고, 목록에서 프로젝트의 .venv를 고릅니다. 목록에 없으면 Enter interpreter path...로 .venv\Scripts\python.exe를 직접 지정합니다.
열려 있는 터미널을 닫고 새 터미널을 엽니다. Python 확장은 새 터미널을 열 때 선택된 가상환경을 자동으로 활성화합니다(기본 설정 기준).

VS Code는 열린 폴더 루트에 있는 .venv나 venv 폴더를 자동으로 찾아 후보로 보여 주므로, 가상환경은 프로젝트 루트에 두는 편이 관리가 쉽습니다. 상위 폴더를 열어 놓고 하위 폴더의 프로젝트를 작업하면 자동 감지가 안 되는 경우가 있습니다. VS Code에서 인터프리터를 바꾸는 기능과 함께 쓰기 좋은 단축키는 VS Code 단축키와 생산성 설정에 정리돼 있습니다.

Jupyter 노트북: 커널은 또 다른 파이썬이다

Jupyter에서는 문제가 한 단계 더 숨겨집니다. 노트북 셀의 코드는 노트북 서버가 아니라 커널이 실행하고, 커널은 서버와 다른 파이썬일 수 있습니다. 터미널에서 pip install pandas를 하고 노트북에서 import pandas를 했는데 실패한다면, 셀에서 바로 확인합니다.

import sys
print(sys.executable)

이 경로가 설치한 파이썬과 다르면 커널이 다른 것입니다. 해결 방법은 두 가지입니다.

첫째, 노트북 안에서 %pip 매직으로 설치합니다.

%pip install pandas

%pip는 현재 커널의 파이썬에 설치하도록 만들어진 IPython 매직 명령입니다. 반면 !pip install은 셸 명령을 그대로 실행하므로 PATH상의 pip가 불리고, 그것이 커널과 다른 파이썬일 수 있습니다. 노트북에서는 !pip보다 %pip를 쓰는 것이 안전합니다. 설치 후에는 커널을 재시작하는 것이 안전합니다. 실행 중인 파이썬은 모듈 검색 결과를 일부 캐시하기 때문에 새로 설치한 패키지가 바로 보이지 않는 경우가 있고, 이미 다른 버전을 import해 둔 상태에서 업그레이드했다면 재시작 전까지는 옛 버전이 메모리에 남아 있습니다.

둘째, 가상환경을 커널로 등록하고 노트북에서 그 커널을 고릅니다.

.venv\Scripts\python.exe -m pip install ipykernel
.venv\Scripts\python.exe -m ipykernel install --user --name proj-venv --display-name "Python (proj-venv)"

이후 Jupyter의 커널 선택 메뉴(VS Code에서는 노트북 오른쪽 위의 커널 선택)에서 “Python (proj-venv)“를 고르면, 그 노트북은 가상환경의 파이썬으로 실행됩니다. 프로젝트마다 커널을 등록해 두면 어떤 노트북이 어떤 환경을 쓰는지 메뉴에서 바로 보입니다. 아나콘다를 쓴다면 같은 문제가 conda 환경 사이에서 생기며, conda activate 후 python -m pip로 설치하는 원칙은 동일합니다.

설치 이름과 import 이름이 다른 패키지

인터프리터가 맞는데도 ModuleNotFoundError가 난다면, 설치한 패키지 이름과 코드에서 import하는 이름이 다른지 확인합니다. PyPI의 배포 이름(pip install에 쓰는 이름)과 파이썬 모듈 이름(import에 쓰는 이름)은 별개라서, 일치하지 않는 유명한 패키지가 꽤 있습니다.

pip install 이름	import 이름
`opencv-python`	`cv2`
`scikit-learn`	`sklearn`
`Pillow`	`PIL`
`beautifulsoup4`	`bs4`
`PyYAML`	`yaml`
`python-dotenv`	`dotenv`
`python-dateutil`	`dateutil`

예를 들어 다음 오류는 pip install cv2가 아니라 pip install opencv-python으로 해결합니다.

Traceback (most recent call last):
  File "C:\Users\me\proj\a.py", line 1, in <module>
    import cv2
ModuleNotFoundError: No module named 'cv2'

오류 메시지에 나오는 이름을 그대로 pip install하면 안 되는 이유가 여기 있습니다. cv2라는 이름으로는 설치할 패키지가 없어 실패하고, sklearn이라는 이름의 옛 패키지는 혼동을 막기 위해 설치 자체를 거부하도록 바뀌었습니다. 더 위험한 경우는 import 이름과 같은 이름으로 PyPI에 올라온, 원래 라이브러리와 무관한 패키지가 설치되는 것입니다. 오타를 노린 악성 패키지 사례가 보고된 적도 있으므로, 이름이 다를 것 같으면 해당 라이브러리의 공식 문서나 PyPI 페이지에서 설치 명령을 확인하고 설치합니다.

이미 설치된 패키지 중 어떤 배포가 어떤 모듈을 제공하는지는 파이썬 3.10 이상에서 표준 라이브러리로 확인할 수 있습니다.

python -c "import importlib.metadata as m; print(m.packages_distributions().get('cv2'))"

['opencv-python']처럼 나오면 그 파이썬에 설치돼 있는 것이고, None이면 그 파이썬에는 해당 모듈을 제공하는 패키지가 없는 것입니다. OpenCV는 opencv-python, opencv-contrib-python, opencv-python-headless가 모두 cv2를 제공하므로 둘 이상을 같이 설치하면 서로 덮어써서 엉뚱한 오류가 날 수 있다는 점도 알아 두면 좋습니다.

내가 만든 모듈을 못 찾을 때

외부 라이브러리가 아니라 같은 프로젝트 안의 내 파일을 import할 때도 ModuleNotFoundError가 납니다. 이때는 pip와 무관하고, 파이썬이 모듈을 찾는 경로(sys.path)가 무엇으로 시작하는지가 핵심입니다.

다음 구조를 예로 듭니다.

proj/
└── myapp/
    ├── __init__.py
    ├── util.py
    └── main.py

python 파일경로로 스크립트를 실행하면 sys.path의 첫 항목은 현재 작업 폴더가 아니라 그 스크립트가 들어 있는 폴더가 됩니다. 그래서 proj 폴더에서 python myapp\main.py를 실행하면 sys.path[0]은 proj\myapp이고, 파이썬 입장에서 myapp이라는 패키지는 보이지 않습니다. main.py에서 절대 import를 쓰면 이렇게 실패합니다.

> python myapp\main.py     # main.py 내용: from myapp.util import X
Traceback (most recent call last):
  File "C:\Users\me\proj\myapp\main.py", line 1, in <module>
    from myapp.util import X
ModuleNotFoundError: No module named 'myapp'

상대 import를 쓰면 다른 오류가 납니다.

> python myapp\main.py     # main.py 내용: from .util import X
Traceback (most recent call last):
  File "C:\Users\me\proj\myapp\main.py", line 1, in <module>
    from .util import X
ImportError: attempted relative import with no known parent package

attempted relative import with no known parent package는 “이 파일이 어떤 패키지에 속하는지 모르는 상태로 실행됐다”는 뜻입니다. 파일 경로로 실행된 스크립트는 패키지의 일부가 아니라 __main__이라는 최상위 모듈로 취급되기 때문에, .이 가리킬 부모 패키지가 없습니다.

두 경우 모두 해결책은 같습니다. 프로젝트 루트(proj)에서 모듈 이름으로 실행합니다.

> cd proj
> python -m myapp.main
1

-m으로 실행하면 현재 작업 폴더가 sys.path에 들어가고, main.py는 myapp 패키지의 main 모듈로 로드되므로 절대 import와 상대 import가 모두 동작합니다. 점(.)으로 구분된 모듈 이름을 쓰고 .py 확장자는 붙이지 않는다는 점에 주의합니다.

파일 맨 위에 sys.path.append(...)를 넣어 해결하는 코드를 자주 보게 되는데, 실행 위치에 따라 결과가 달라지고 IDE의 정적 분석도 이를 따라가지 못해 금방 관리가 어려워집니다. 프로젝트가 커지면 pyproject.toml을 두고 가상환경에 python -m pip install -e .로 편집 가능 설치를 해 두는 것이 정석입니다. 그러면 어느 폴더에서 실행하든 import myapp이 동작합니다. 모듈과 패키지의 기본 구조는 파이썬 모듈과 패키지에서 다룹니다.

내 파일 이름이 라이브러리를 가리는 경우

이 경우는 ModuleNotFoundError가 아니라 조금 다른 오류로 나타나지만, “설치했는데 안 된다”는 같은 증상으로 검색하게 되므로 함께 다룹니다. 앞에서 본 대로 스크립트가 있는 폴더가 sys.path의 맨 앞에 오기 때문에, 그 폴더에 requests.py, random.py, pandas.py, email.py 같은 파일이 있으면 진짜 라이브러리 대신 내 파일이 import됩니다.

공부하면서 requests.py라는 이름으로 연습 파일을 만들고 그 안에서 import requests를 하면 다음과 같이 됩니다(파이썬 3.11).

Traceback (most recent call last):
  File "C:\Users\me\proj\requests.py", line 1, in <module>
    import requests
  File "C:\Users\me\proj\requests.py", line 2, in <module>
    requests.get("https://example.com")
    ^^^^^^^^^^^^
AttributeError: partially initialized module 'requests' has no attribute 'get' (most likely due to a circular import)

같은 폴더에 requests.py가 있고 다른 파일(main.py)에서 import하면 메시지가 더 짧아집니다.

AttributeError: module 'requests' has no attribute 'get'

파이썬 3.13에서는 첫 번째 상황에서 원인을 짚어 주는 힌트가 붙습니다.

AttributeError: module 'requests' has no attribute 'get' (consider renaming 'C:\Users\me\proj\requests.py' if it has the same name as a library you intended to import)

어느 파일이 import됐는지는 직접 확인할 수 있습니다.

python -c "import requests; print(requests.__file__)"

출력이 site-packages 안이 아니라 내 프로젝트 폴더의 파일이면, 그 파일 이름을 바꾸고 같은 폴더의 __pycache__ 안에 남은 같은 이름의 .pyc 파일도 지웁니다. 표준 라이브러리 이름(random, string, email, test, queue 등)과 겹치는 경우에는 그 모듈을 내부적으로 쓰는 다른 라이브러리까지 연쇄적으로 깨지므로, 증상이 처음 import한 곳과 전혀 다른 곳에서 나타나기도 합니다. 연습용 파일에는 requests_test.py처럼 라이브러리와 겹치지 않는 이름을 붙이는 습관이 가장 확실한 예방책입니다.

다음에 같은 문제를 겪지 않으려면

여기까지 확인했으면 대부분의 ModuleNotFoundError는 해결됩니다. 앞으로 같은 문제를 줄이려면, 사용하지 않는 파이썬 버전을 정리하는 것이 효과가 큽니다. 윈도우에서는 설정 → 앱 → 설치된 앱에서 “Python 3.x”를 제거하면 되고, 제거 후에는 py -0p와 where.exe python으로 남은 것을 다시 확인합니다. PATH에 남은 옛 경로는 윈도우 PATH 환경 변수 설정을 참고해 지웁니다. 맥에서 /usr/bin/python3는 시스템 구성 요소이므로 지우지 말고, 쓰지 않을 Homebrew 버전만 brew uninstall python@3.x로 정리합니다.

프로젝트 단위로는 가상환경 안에 설치한 목록을 python -m pip freeze > requirements.txt로 남겨 두면, 환경이 꼬였을 때 .venv 폴더를 통째로 지우고 다시 만드는 것이 가장 빠른 복구 방법이 됩니다. 가상환경은 폴더를 지우는 것만으로 깨끗이 사라지고 전역 파이썬에는 아무 영향도 주지 않습니다.

Remove-Item -Recurse -Force .venv
python -m venv .venv
.venv\Scripts\python.exe -m pip install -r requirements.txt

가상환경 생성과 설치를 한 번에 관리하는 uv나 Poetry 같은 도구를 쓰면 “어느 파이썬에 설치했는가”를 도구가 대신 추적해 주므로 이 종류의 실수가 크게 줄어듭니다. 도구별 차이는 pip·uv·Poetry 비교에서 확인할 수 있습니다.

같이 보면 좋은 글

개발 환경 에러 응급처치표: 증상별 첫 확인