한 업무에 필요한 Python 패키지를 바꿨다가 다른 업무까지 깨질 수 있다. 반대로 모든 의존성을 매번 복제하면 준비 시간과 저장량이 커진다. 나는 공통 설치를 읽을 수 있는 프로젝트별 venv를 만들고 추가·교체는 해당 프로젝트에 남기는 구성을 택했다.

가상환경이 있다는 이름보다 실제 실행기를 본다

ProjectPython은 프로젝트 경로 아래의 Python 실행기를 정하고 없으면 venv를 만든다. 생성 옵션에는 system-site-packages가 있다. 공통 패키지를 읽을 수 있게 하되 프로젝트의 쓰기 위치를 별도로 두는 선택이다.

이미 실행기가 있어도 sys.prefix를 실제로 출력해 기대한 프로젝트 경로와 대조한다. 파일 이름이 python.exe라는 것만으로 맞는 환경이라고 보지 않는다. 다른 Python이 연결됐다면 PROJECT_PYTHON_ENVIRONMENT_MISMATCH로 멈춘다. 나는 설정 문자열과 실행 중 환경을 따로 확인해야 한다고 봤다.

공통 읽기가 완전 독립을 뜻하지는 않는다

공통 의존성을 읽기 때문에 기본 환경의 패키지가 바뀌면 프로젝트의 해석에도 영향을 줄 수 있다. 이 구성을 모든 의존성의 완전 고정이나 재현 가능한 배포라고 설명하지 않는다. 프로젝트의 로컬 추가·교체와 전체 의존성 잠금은 다른 문제다.

특정 버전을 오래 유지해야 하는 업무라면 잠금 파일과 설치 기록, 깨끗한 환경에서의 재구성 시험이 더 필요하다. 나는 이 기능의 목적을 프로젝트 사이의 불필요한 쓰기 공유를 줄이는 데 뒀다. 가상환경 한 개를 만들었다고 배포와 호환성의 모든 책임이 사라지는 것은 아니다.

Python 실행과 주피터가 같은 환경을 쓰게 한다

프로젝트 runtime은 자기 ProjectPython을 만들고 runner와 NotebookService에 ensure 함수를 연결한다. 노트북 화면은 A프로젝트인데 커널만 기본 Python을 쓰는 불일치를 피하려는 구조다. 실행 방식을 바꿔도 필요한 프로젝트 패키지를 같은 기준으로 찾는다.

같은 환경을 쓴다고 같은 프로세스와 변수를 공유하는 것은 아니다. 패키지 검색 경로와 커널 메모리는 다른 상태다. 나는 환경 선택과 실행 수명을 분리해 설명한다. 한쪽이 맞는지 확인한 시험으로 다른 쪽까지 자동으로 완료했다고 쓰지 않는다.

준비 중 중복과 실패도 처리한다

ensure는 진행 중 Promise를 재사용해 같은 환경 준비가 겹치지 않게 한다. 실패하면 pending을 비워 이후 명시한 준비가 다시 가능하게 한다. 환경 생성과 확인에는 시간과 출력 제한도 있다. 무한히 기다리거나 실패한 Promise를 영원히 성공 준비처럼 남기지 않는다.

이 구조는 다른 프로세스 전체의 패키지 설치 잠금을 보장하는 기능은 아니다. 외부에서 같은 폴더를 동시에 수정하면 별도 관리가 필요하다. 준비 함수 내부의 중복 조정과 운영체제 수준의 모든 동시 쓰기 제어를 같은 것으로 소개하지 않는다. 적용 범위를 작게 적어야 실제 연결자가 필요한 보호를 더할 수 있다.

시험은 설치 위치의 실제 차이를 본다

기존 프로젝트 격리 시험은 A의 site-packages에 합성 모듈을 만들고 B에서 그 모듈을 찾지 못하는지 확인한다. 각각의 sys.prefix와 결과 노트북 경로도 대조한다. 같은 변수 이름을 분리하는 시험과 패키지 위치를 분리하는 시험을 함께 둔다.

여기서는 그 시험 코드와 현재 환경 연결을 읽었다. 운영 프로젝트에 새 패키지를 설치하거나 기존 환경을 바꾼 검수는 아니다. 역사 시험에서 확인한 한 합성 모듈의 분리와 모든 패키지 조합의 호환성은 다르다. 네이티브 라이브러리나 GPU 의존성은 별도의 실제 환경 확인이 필요하다.

맞춤 업무 도구의 변경 범위를 줄인다

회사별 자동화도 각자 필요한 패키지와 자료가 다르다. 한 업무의 개선을 다른 회사의 환경 변경으로 만들지 않으려면 설치와 실행의 소속을 명확히 해야 한다. 공통으로 읽는 자산은 활용하면서 각 프로젝트가 바꾸는 위치를 제한하는 방식이 도움이 됐다.

나는 가상환경을 보안 샌드박스라는 말보다 유지보수 경계를 만드는 도구로 쓴다. Python 코드는 사용자의 실제 로컬 권한을 가진다. 의존성 분리와 권한 격리, 재현 가능한 배포를 각각 확인해야 회사에 맞는 프로그램을 오래 수정하면서도 어떤 변경이 어디에 영향을 주는지 설명할 수 있다.