AI 파이썬 패키지 73개의 배포 11,275건을 셌어요 — 제작자가 회수한 판이 134건이고, 버전을 못 박으면 그게 그대로 깔려요

파이썬으로 AI 관련 작업을 하다 보면 어제까지 잘 되던 설치가 오늘 안 되거나, 깔고 나서야 이상한 오류를 만나는 일이 있어요. 원인 후보 중에 잘 알려지지 않은 게 하나 있어요. 제작자가 이미 회수해 둔 판을 그대로 깔고 있는 경우예요.

결론부터 적을게요. AI 개발에 흔히 쓰는 파이썬 패키지 73개의 배포를 전수로 훑었더니, 배포 파일이 있는 버전 11,275개와 배포 파일 83,508개 가운데 제작자가 회수 표시를 붙인 버전이 134개였어요. 그리고 requirements.txt 에 버전을 == 로 못 박아 두면 pip 은 그 회수된 판을 경고 한 줄만 띄우고 그대로 설치해요. 같은 패키지를 범위로 적으면 회수되지 않은 판을 골라 주고요. 두 경우를 이 PC 에서 직접 재현했어요.

이 글이 재는 자리를 먼저 못박을게요. PyPI 가 공개해 둔 조회 창구를 인증 토큰 없이 불러서 센 값이에요. 조회 시각은 2026년 9월 14일 낮 12시 7분부터 12시 30분대까지(한국 시각)이고, 73개 전부 정상으로 응답했어요. 조회 실패는 0건이에요.

선도 하나 미리 그어 둘게요. 분모는 PyPI 전체가 아니라 이름을 지정해 고른 73개예요. 그리고 회수된 시각은 공개 창구가 내주지 않아요. 그래서 이 글에는 언제 회수됐는지를 말하는 문장이 한 줄도 없어요. 왜 그 구분이 중요한지는 글 끝에서 따로 적을게요.

무엇을 셌는지부터 적을게요

숫자보다 분모가 먼저예요. 이 조사가 잡은 자리는 이래요.

73개는 토치 계열과 트랜스포머스 같은 모델 쪽, 넘파이와 판다스 같은 수치 계산 쪽, 랭체인과 라마인덱스 같은 연결 도구 쪽, 그라디오와 스트림릿 같은 화면 쪽을 고루 넣어 이름으로 미리 적어 둔 목록이에요. 검색으로 긁어모은 게 아니라 적어 둔 이름을 하나씩 부른 거라 분모가 흔들리지 않아요.

버전 분모에서 뺀 게 하나 있어요. 번호는 있는데 배포 파일이 하나도 안 달린 껍데기 버전이 75개 있었어요. 그걸 넣으면 11,350개인데 설치할 파일 자체가 없으니 분모에서 뺐어요. 그래서 11,275개가 된 거예요.

회수는 삭제가 아니라 표시예요

여기가 이 글의 출발점이에요. 파이썬 쪽의 회수는 배포 파일을 지우는 게 아니에요. 파일은 그대로 두고 이 판은 고르지 말아 달라는 표시만 붙이는 것이에요. 그 표시를 규격으로 정해 둔 문서가 PEP 592 이고, 조회 창구가 내려 주는 회수 항목도 이 규격이 만든 거예요. 그러니 판정 기준은 제 생각이 아니라 규격 문장이에요.

원문 그대로 옮기면 이래요. 2026년 9월 14일 낮 12시 30분대(한국 시각)에 https://peps.python.org/pep-0592/ 에서 읽은 문장이에요.

An installer MUST ignore yanked releases, if the selection constraints can be
satisfied with a non-yanked version, and MAY refuse to use a yanked release even
if it means that the request cannot be satisfied at all.

Yanked files are always ignored, unless they are the only file that matches a
version specifier that "pins" to an exact version using either == (without any
modifiers that make it a range, such as .*) or ===.

The yanked attribute is not immutable once set, and may be rescinded in the
future (and once rescinded, may be reset as well).

옮긴 뜻은 이래요. 첫 문장은 회수되지 않은 판으로 요구를 채울 수 있으면 설치 도구는 회수된 판을 무시해야 한다는 뜻이에요. 둘째 문장이 이 글의 핵심이고요. 회수된 파일은 언제나 무시되지만, 정확한 한 판을 못 박은 지정자와만 맞는 경우에는 예외라는 거예요. 셋째 문장은 유보예요. 회수 표시는 한 번 붙어도 영구적이지 않고 나중에 철회될 수 있어요.

그래서 이 글의 134개는 2026년 9월 14일 조회 시점의 상태예요. 몇 달 뒤에 같은 창구를 부르면 숫자가 달라질 수 있어요.

숫자를 한자리에 모으면 이래요

73개 전수 기준이에요.

여기서 먼저 읽을 줄이 세 개 있어요.

첫째, 파일 일부만 회수된 버전이 0개예요. 회수 표시가 붙은 파일이 2,042개인데 그 파일들이 전부 134개 버전 안에 몰려 있어요. 즉 회수는 파일 하나씩 골라서 일어나는 게 아니라 버전 단위로 일어나요. 윈도우용 파일만 문제였어도 그 버전 전체가 회수돼요.

둘째, 회수 이력이 아예 없는 패키지가 36개예요. 73개 중 절반 가까이가 한 번도 회수한 적이 없어요. 회수가 흔한 사고라기보다 일부 패키지에 몰려 있는 사건이라는 뜻이에요.

셋째, 최신으로 표시되는 판이 회수된 패키지는 0개예요. 이건 이 글의 유보 수치예요. 버전을 안 적고 그냥 설치하면 회수된 판이 온다는 식으로 읽으면 틀려요. 이 73개 안에서는 그런 경우가 한 건도 없었어요.

회수 이력은 37개 패키지에 몰려 있어요

패키지별로 펼치면 이래요. 오른쪽은 그 패키지가 가진 전체 버전 수예요.

torchvision 과 opencv-python 이 눈에 걸려요. 회수 건수는 gradio 와 같은 11건인데 전체 버전 수가 훨씬 적어요. 반대로 litellm 은 887개 버전에 회수가 3건이고요. 같은 회수 건수라도 그 패키지가 얼마나 자주 배포하는지에 따라 의미가 달라진다는 뜻이에요.

다만 여기서 한 발 더 나가지는 않을게요. 어느 패키지가 더 위험하다는 식으로 읽으시면 안 돼요. 이 조사는 회수 표시를 센 것이지 그 회수가 사용자에게 실제로 어떤 피해를 줬는지는 재지 않았어요.

requirements.txt 버전 고정은 언제 문제가 되나요

정확한 답부터 드릴게요. 고정 자체가 문제인 게 아니라, 고정한 그 버전이 회수된 판일 때만 문제가 돼요. 규격이 회수된 파일을 무시하되 정확한 한 판을 못 박은 지정자와만 맞는 경우는 예외로 뒀기 때문이에요. 그래서 범위로 적으면 회수된 판이 후보에서 스스로 빠지고, 한 판으로 못 박으면 남는 후보가 그것뿐이라 그게 설치돼요.

말로만 적으면 믿기 어려운 대목이라 이 PC 에서 직접 돌려 봤어요. 윈도우 11 에 pip 25.0.1 과 파이썬 3.12 환경이고, 2026년 9월 14일 낮 12시 30분대(한국 시각)예요. 실제 설치는 하지 않고 무엇을 설치할지만 계산하는 드라이런으로 확인했어요.

먼저 회수된 판을 정확히 못 박은 경우예요.

python -m pip install --dry-run --no-deps --ignore-installed "pandas==3.0.4"

Collecting pandas==3.0.4
  Downloading pandas-3.0.4-cp312-cp312-win_amd64.whl.metadata (19 kB)
WARNING: The candidate selected for download or install is a yanked version: 'pandas' candidate (version 3.0.4 ...)
Reason for being yanked: Reported segfaults with datetime-related functionality
Downloading pandas-3.0.4-cp312-cp312-win_amd64.whl (9.7 MB)
Would install pandas-3.0.4

종료 코드는 0 이었어요. 막지 않아요. 회수됐다는 경고와 사유를 한 줄씩 띄운 다음 그 판을 설치하겠다고 알려 주고 끝나요. 로그를 안 읽고 지나가면 그대로 넘어가는 자리예요.

다음은 같은 패키지를 범위로 적은 경우예요.

python -m pip install --dry-run --no-deps --ignore-installed "pandas>=3.0,<3.1"

Collecting pandas<3.1,>=3.0
  Downloading pandas-3.0.5-cp312-cp312-win_amd64.whl.metadata (19 kB)
Would install pandas-3.0.5

이번엔 회수 경고가 아예 안 떴어요. 3.0.4 가 후보에서 스스로 빠지고 회수되지 않은 3.0.5 가 선택된 거예요. 같은 패키지인데 적는 방식이 결과를 바꾼 셈이에요.

여기서 조심해서 읽으실 대목이 둘 있어요. 첫째, 이건 pip 25.0.1 에서 나온 결과예요. 규격은 경고를 띄우는 것을 권고 사항으로 적어 두었기 때문에 도구나 판에 따라 다를 수 있어요. 둘째, uv 나 poetry 같은 다른 설치 도구는 이번에 확인하지 않았어요. 다른 도구도 그렇다고 옮겨 쓰시면 안 돼요.

회수 사유를 열어 보면 이래요

사유 칸에 문구가 적힌 112개를 낱말로 나눠 봤어요. 한 사유에 여러 낱말이 걸리면 중복으로 셌어요.

실제 문구도 몇 개 옮겨 둘게요. 아래 원문은 조회 창구가 내려 준 값을 한 글자도 고치지 않은 거예요. 오른쪽은 제가 옮긴 뜻이고요. 날짜는 그 배포를 올린 날이지 회수한 날이 아니에요.

읽어 보면 성격이 갈려요. 라이선스 위반이나 비정상 종료처럼 내 설치에 바로 영향이 오는 것이 있고, 태그를 잘못 붙였다거나 버전 값을 잘못 넣었다처럼 배포 과정의 실수도 있어요. 사유가 적혀 있다는 것만으로 심각도를 짐작하시면 안 되는 이유예요.

그리고 사유가 아예 비어 있는 22개가 있어요. 이 경우엔 회수됐다는 사실만 보이고 왜 그랬는지는 어디에도 안 적혀 있어요.

회수 사유가 제일 길었던 건이 제도를 설명해 줘요

matplotlib 3.9.1 (2024-07-04 에 올린 판) 의 사유가 이번 112개 중 제일 길었어요. 앞부분 원문은 이래요.

The Windows wheels, under some conditions, caused segfaults in unrelated user
code. Due to this we deleted the Windows wheels to prevent these segfaults,
however this caused greater disruption as pip then began to try (and fail) to
build 3.9.1 from the sdist on Windows which impacted far more users. Yanking the
whole release is the only tool available to eliminate these failures without
changes to on the user side.

옮기면 이런 이야기예요. 윈도우용 배포 파일이 특정 조건에서 관계없는 코드까지 비정상 종료시켜서 그 파일들을 지웠는데, 그랬더니 pip 이 소스 배포본에서 직접 빌드하려 들다가 실패하면서 더 많은 사용자가 영향을 받았어요. 그래서 사용자 쪽 변경 없이 이 실패를 없앨 수 있는 유일한 수단으로 버전 전체를 회수했다는 거예요.

이 한 건이 회수 제도의 존재 이유를 그대로 설명해 줘요. 파일만 지우면 더 크게 망가지니까 버전째 표시를 붙이는 것이거든요. 동시에 이 사유는 중요한 유보이기도 해요. 같은 사유 안에 소스 배포본과 macOS 리눅스 파일은 멀쩡했다는 이야기가 들어 있으니까요.

배포 파일이 플랫폼별로 갈리는 게 왜 사고의 무대가 되는지도 여기서 보여요. 이번 73개 중 32개가 플랫폼별로 따로 빌드한 파일을 내고 있어요. 조합이 많아질수록 하나가 빠지거나 잘못 올라갈 자리도 늘어나요. 앞의 표에서 특정 조합의 파일이 빠졌다는 사유가 나온 것도 같은 맥락이고요. 참고로 같은 조회 창구로 라이브러리가 요구하는 파이썬 버전을 따로 조사한 글은 AI 라이브러리의 최소 파이썬 버전 실측에 있어요. 이 글은 그 칸이 아니라 회수 표시만 다뤄요.

회수됐다고 망가진 판이라는 뜻은 아니에요

여기서 한 번 브레이크를 걸게요. 지금까지의 숫자를 읽고 회수된 판은 쓰면 안 되는 판이라고 정리하시면 그건 이 조사가 보여 준 것보다 한 발 더 나간 거예요.

이유는 셋이에요. 첫째, 방금 본 matplotlib 사례처럼 특정 환경의 파일만 문제였는데 버전째 회수한 경우가 있어요. 둘째, 사유가 실수로 올렸다거나 태그를 잘못 붙였다는 쪽이면 그 판이 망가졌다는 뜻이 아니에요. 셋째, 사유는 제작자가 자유롭게 적는 문자열이지 검증된 사고 보고서가 아니에요. 22개는 아예 비어 있고요.

그래서 실무에서 하실 일은 회수된 판을 무조건 피하는 게 아니라 사유를 읽고 내 환경에 해당하는 이야기인지 확인하는 것이에요. 경고 줄에 사유가 같이 찍히니까 로그만 안 넘겨도 반은 해결돼요.

npm 은 필드 이름부터 달라요

대조로 다른 생태계를 한 번 열어 봤어요. 2026년 9월 14일 낮 12시 30분대(한국 시각)에 npm 의 공개 조회 창구를 부른 결과예요.

npm 응답의 버전 정보에는 회수에 해당하는 항목이 없었어요. 대신 더 쓰지 않기로 했다는 뜻의 항목에 문자열이 들어가요. request 패키지는 버전 126개 전부에 그 문구가 붙어 있었고, @modelcontextprotocol/sdk 는 버전 79개 중 2개에 붙어 있었어요. 즉 같은 개념을 서로 다른 이름과 다른 성격의 항목으로 다루고 있어요.

여기서 딱 멈출게요. 확인한 건 항목 이름이 다르다는 것과 그 항목에 이런 문자열이 들어 있다는 것까지예요. npm 쪽 설치 도구가 어떻게 동작하는지는 이번에 재현하지 않았어요. npm 쪽 패키지를 따로 전수로 센 조사는 npm MCP 패키지 전수 집계에 있고, 이 글과는 다루는 칸이 달라요.

이 조사가 못 본 것을 적어 둘게요

숫자를 쓰시려면 사정권도 같이 아셔야 해요.

첫째, 분모는 이름으로 고른 73개예요. PyPI 전체가 아니에요. 비율로 옮겨 쓰면 과장이 돼요.

둘째, 회수된 시각은 확인할 수 없어요. 공개 창구가 그 값을 안 줘요. 이 글에 나오는 날짜는 전부 그 배포를 올린 날이에요.

셋째, 회수는 철회될 수 있어요. 규격 원문에 그렇게 적혀 있어요. 134개는 조회 시점의 상태예요.

넷째, 사유는 제작자가 적은 자유 문자열이에요. 검증된 사고 보고가 아니고 22개는 비어 있어요.

다섯째, pip 동작은 pip 25.0.1 에서 드라이런으로 확인한 것이에요. 실제 설치까지 간 게 아니고, 다른 설치 도구는 확인하지 않았어요.

여섯째, 다운로드 수를 보지 않았어요. 회수된 판을 실제로 얼마나 많은 사람이 쓰고 있는지는 이 조사로 알 수 없어요.

일곱째, 설치 성공 여부를 재지 않았어요. 회수된 판을 깔면 실제로 문제가 생기는지는 패키지와 환경마다 다르고, 이 조사가 답할 수 있는 질문이 아니에요.

정리

세 줄로 줄이면 이래요.

첫째, 이름으로 고른 73개 안에서 회수된 버전이 134개였어요. 배포 파일이 있는 버전 11,275개와 배포 파일 83,508개를 전수로 훑어 센 값이고, 회수 이력이 있는 패키지는 37개, 한 번도 없는 패키지는 36개예요.

둘째, 회수는 삭제가 아니라 표시예요. 파일은 그대로 남아 있고 고르지 말아 달라는 표시만 붙어요. 그래서 후보가 그것뿐인 상황을 만들면 설치돼요.

셋째, 그 상황을 만드는 게 정확한 한 판 고정이에요. pip 25.0.1 드라이런에서 회수된 판을 못 박았더니 경고 한 줄만 띄우고 설치하겠다고 나왔고, 같은 패키지를 범위로 적었더니 회수되지 않은 판을 골랐어요.

그래서 실무에서 하실 일은 두 가지예요. 설치 로그의 경고 줄을 넘기지 마시고, 고정해 둔 판이 오래됐다면 그 판이 아직 살아 있는지 한 번 확인해 보세요. 버전을 못 박는 습관 자체는 재현성을 위해 필요한 거라 버릴 이유가 없어요. 다만 못 박아 둔 판에 표시가 붙었을 때 알려 줄 사람이 없다는 것만 기억하시면 돼요.

파이썬 환경 자체를 새로 꾸리는 단계라면 로컬 LLM 설치부터 시작하는 안내를 먼저 보셔도 좋아요. 이 글은 환경을 꾸린 다음 칸, 그러니까 어떤 판이 실제로 깔리는지만 다뤘어요.