`WHEEL_PKG_DIR=''`가 CWD를 훑는 순간: PR #146357이 막아준 ensurepip의 ‘빈 문자열 함정’
meta_description: CPython PR #146357은 ensurepip에서 WHEEL_PKG_DIR이 빈 문자열일 때 Path('')가 현재 작업 디렉터리(CWD)로 해석되어, 의도치 않게 CWD에서 wheel 파일을 찾는 문제를 수정한다. 운영/빌드 환경에서 설정 값이 빈 문자열로 들어가는 흔한 케이스와, 이를 방어하는 패턴(환경변수/빌드 플래그 검증, 경로 truthiness 체크)을 실무 관점으로 정리한다.
meta_keywords: python, ensurepip, WHEEL_PKG_DIR, sysconfig, wheel, pip, virtualenv, build, CWD, Path(’’), environment variable, packaging, security, CI, practical, 운영
meta_robots: index,follow
ensurepip은 평소엔 존재감이 없다가, 한 번 문제를 만나면 굉장히 현실적인 방식으로 사람을 괴롭힌다.
- “왜 이 환경에선 pip 부트스트랩이 이상하지?”
- “왜 현재 폴더에서 wheel을 찾지?”
- “왜 CI에서만 재현되지?”
PR #146357(gh-146310)은 그 중에서도 아주 작은 조건 하나가 얼마나 큰 행동 변화를 만드는지를 보여준다.
핵심은 이거다.
WHEEL_PKG_DIR가 빈 문자열('')이면,Path('')가 CWD로 해석되어 ensurepip이 현재 디렉터리에서 wheel 파일을 찾게 될 수 있다.
이건 “버그 같다”로 끝나는 문제가 아니다.
- 빌드/패키징 파이프라인이 예기치 않게 CWD에 의존하게 되고
- 특정 폴더에서만 동작이 달라지고
- 보안/무결성 관점에서도 찝찝한 동작이 된다
1) PR #146357이 바꾼 건 한 줄: and _pkg_dir
diff는 말 그대로 한 줄이다.
-if (_pkg_dir := sysconfig.get_config_var('WHEEL_PKG_DIR')) is not None:
+if (_pkg_dir := sysconfig.get_config_var('WHEEL_PKG_DIR')) is not None and _pkg_dir:
_WHEEL_PKG_DIR = Path(_pkg_dir).resolve()
else:
_WHEEL_PKG_DIR = None
포인트는 “None이 아니면 경로로 쓴다”가 아니라,
- None이 아니면서
- truthy(빈 문자열이 아님)
일 때만 경로로 쓴다는 것.
이런 패턴은 파이썬에서 흔하지만, 빌드/설정 값 쪽에서는 자주 놓친다. 왜냐하면 설정 시스템이 ‘없음’을 None이 아니라 빈 문자열로 전달하는 경우가 많기 때문이다.
2) 왜 빈 문자열이 위험한가: Path('') == Path('.')
PR 설명에 나온 문장이 실무적으로 중요하다.
Path('')는 CWD로 해석된다
즉, 어떤 설정이 “비어 있음”을 의미하려고 ''를 넣었는데,
파이썬 쪽에서는 그걸 “현재 디렉터리”라는 유효한 경로로 받아들이는 순간 행동이 바뀐다.
ensurepip 입장에선 “휠 디렉터리가 지정됐으니 그쪽에서 찾는다”가 되는데, 그 ‘그쪽’이 하필 현재 디렉터리(CWD)인 거다.
빌드/패키징에서 CWD는 상황에 따라 달라진다.
- 로컬 개발: 프로젝트 루트
- CI: 체크아웃 루트 또는 임시 작업 폴더
- 패키지 빌드: 빌드 스테이징 디렉터리
그래서 재현이 어렵고, “환경 따라 다르게 터지는” 형태가 된다.
3) 실무에서 빈 문자열은 어디서 나오나(진짜 흔한 케이스)
이게 ‘극단적인 케이스’가 아니라는 게 핵심이다.
- 템플릿 기반 CI에서 변수는 기본값이
""인 경우가 많다 - Docker/compose에서
ENV VAR=같은 형태로 선언하면 빈 문자열이 된다 - 빌드 시스템이 “unset” 대신 빈 문자열로 밀어 넣는 경우가 있다
그리고 사람은 “어차피 비어 있으니 무시되겠지”라고 생각한다.
파이썬은 그걸 무시하지 않는다. 그냥 CWD로 간다.
4) 운영/보안 관점에서 왜 찝찝한가
ensurepip이 CWD에서 wheel을 찾는다는 건, 의도치 않게 이런 상태가 될 수 있다는 뜻이다.
- 어떤 폴더에 우연히
pip-*.whl같은 파일이 있으면 - ensurepip이 그걸 후보로 취급할 수 있다
물론 현실에서 “임의 wheel이 끼어드는 공격”까지 바로 연결된다고 단정할 순 없다.
하지만 운영자는 이런 원칙을 좋아하지 않는다.
- 부트스트랩 경로가 작업 디렉터리 상태에 의존한다
- “어느 폴더에서 실행했는지”가 동작을 바꾼다
PR #146357은 이런 불확실성을 한 줄로 잘라낸다.
5) 내가 가져가는 교훈: 설정은 ‘존재 체크’가 아니라 ‘의미 체크’를 하자
이 PR은 ensurepip 이야기지만, 실무에서는 훨씬 넓게 적용된다.
패턴 A) 경로/토큰은 truthiness 체크
if value: # 빈 문자열/None 모두 거름
use(value)
else:
fallback()
이 패턴은 특히 “경로”에서 중요하다. 경로 문자열은 빈 문자열이 들어와도 파서가 대충 어떻게든 ‘유효한 경로’로 해석해버리는 경우가 많다. (Path('') 같은 케이스.)
패턴 B) “unset”을 만드는 쪽에서 빈 문자열을 금지
CI 템플릿에서 변수를 이런 식으로 관리하면 사고가 줄어든다.
- 변수 미설정 = 아예 key를 만들지 않기
- 어쩔 수 없이 만들면, 빈 문자열 대신 명시적인 sentinel(예:
__UNSET__)
그리고 가장 현실적인 방법은, 파이프라인 시작 단계에서 “빈 문자열이면 unset으로 바꾸기”를 한 번 해주는 것이다.
VAR=""이면 아예 export하지 않기- 또는 도구 호출 시 인자에 넘기지 않기
패턴 C) 디버깅 시 CWD를 항상 로그에 남기기
이런 류의 문제는 “현재 폴더”가 답인 경우가 많다.
pwd- 실행된 워크스페이스 경로
- 작업 디렉터리 변경(chdir) 여부
이걸 로그에 남기면 재현이 빨라진다.
패턴 D) 테스트는 ‘빈 문자열’ 케이스를 하나 넣어두기
PR #146357이 테스트를 추가한 이유가 딱 이거다.
- None만 테스트하면 놓친다
- 빈 문자열은 설정 시스템에서 실제로 자주 나온다
그래서 환경/설정 값을 다루는 코드라면, None, "", 그리고 “공백만 있는 문자열”까지 최소 3개를 한 번은 걸어두는 편이 안전하다.
6) “지금 내 환경”에서 확인하는 빠른 체크(1분)
이 이슈는 이론으로 이해하는 것보다, 내 환경에서 한 번 ‘감’을 잡는 게 더 빠르다.
python -c "import sysconfig; print(sysconfig.get_config_var('WHEEL_PKG_DIR'))"
여기서 출력이
None이면: 기본 번들/정상 경로로 간다''(빈 문자열)이나 공백 비슷한 값이면: 과거엔 CWD 해석 문제가 있을 수 있었고, 이번 PR이 그걸 막는다
그리고 CI에서는 pwd를 같이 찍어두는 게 좋다. 이 류의 문제는 항상 “어디에서 돌았는지”가 절반의 답이라서.
7) 마무리
PR #146357은 기능 추가도 아니고, 엄청난 리팩터링도 아니다.
하지만 운영에서 진짜 도움이 되는 PR은 이런 종류다.
- 설정의 ‘없음’을 빈 문자열로 받을 수 있다는 현실을 인정하고
- 그 빈 문자열이 CWD로 해석되는 함정을 막고
- 결과적으로 부트스트랩 동작을 더 예측 가능하게 만든다
한 줄이지만, 이런 한 줄이 CI의 밤샘을 줄인다.
덤으로, 이 PR이 좋은 이유는 ‘행동’을 바꿔서다. 로그가 더 친절해지는 게 아니라, 애초에 잘못된 경로(CWD)를 바라보지 않게 만들었다. 운영에서 이런 수정이 가장 값이 크다.
8) “ensurepip가 이상하다”를 만났을 때 체크 순서(실전)
이 PR의 구체 이슈와 별개로, ensurepip 문제를 만나면 디버깅을 어디서부터 시작해야 할지 막막할 때가 있다. 나는 아래 순서로 본다.
1) 지금 파이썬이 어디서 실행되고 있는지(CWD) - 예상치 못하게 다른 디렉터리에서 실행되면, 파일 탐색/상대경로 로직이 모두 흔들린다.
2) WHEEL_PKG_DIR 값 확인
- None인지, 빈 문자열인지, 실제 경로인지.
3) 환경의 패키징 정책 - 배포판(예: Fedora)은 번들 wheel 경로를 별도로 두고 ensurepip 번들을 제한하는 정책이 있을 수 있다(주석에도 그런 뉘앙스가 있다).
4) 재현을 작게 만들기
- “CI 전체”가 아니라, 최소한의 컨테이너/가상환경에서 python -m ensurepip만 떼어내서 재현하면 원인 규명이 빨라진다.
5) 마지막으로 로그 - 많은 경우 로그를 늘리는 것보다, 애초에 이상한 값(빈 문자열 같은)을 못 들어오게 막는 게 더 빠른 해결이다. PR #146357이 딱 그 케이스다.
Keywords
python,ensurepip,WHEEL_PKG_DIR,sysconfig,wheel,pip,CWD,Path,empty string,build,packaging,CI,env,bootstrap,virtualenv,practical,security,bugfix,linux
References
- CPython PR #146357
- https://github.com/python/cpython/pull/146357
- Diff
- https://github.com/python/cpython/pull/146357.diff
이미지 크레딧/라이선스
- Developer working on an iMac (Unsplash).jpg — Lee Campbell / CC0
- https://commons.wikimedia.org/wiki/File:Developer_working_on_an_iMac_(Unsplash).jpg
- http://creativecommons.org/publicdomain/zero/1.0/deed.en
댓글
댓글 쓰기