파이썬 개선 제안(PEP) 751은 파이썬에 종속성을 지정하기 위한 새로운 파일 형식을 제공한다. 잠금(lock) 파일이라고도 하는 이 파일을 통해 개발자는 여러 시스템에 걸쳐 정확히 동일한 종속성 집합으로 파이썬 프로젝트 설치를 재현할 수 있다.

몇 가지 커뮤니티 솔루션이 있기는 하지만, 지금까지 파이썬에는 종속성을 위한 공식적인 파일 잠금 및 충돌 해결 방법은 없다. 네이티브 솔루션에 가장 가깝다고 할 만한 것은 requirements.txt 파일 또는 pip freeze의 출력 정도다. requirements.txt 파일에는 프로젝트의 요구사항과 각 요구사항에 대한 가능한 버전 범위가 나열된다. 그러나 이 파일은 요구사항을 어디에서 가져와야 하는지, 해시를 기준으로 어떻게 요구사항을 검증해야 하는지를 비롯해 오늘날 잠금 파일이 일반적으로 처리하는 다른 많은 부분을 다루지 않는다.

포에트리(Poetry), uv와 같은 개별 프로젝트 관리 툴은 종속성 간의 충돌을 해결하고 이를 잠금 파일에 기록하기 위해 가능한 모든 노력을 기울이지만 이러한 잠금 파일에는 공통된 형식이 없기 때문에 툴 간에 파일을 상호 교환할 수가 없다. 또한 일반적으로 개발자가 잠금 파일을 만들어 재배포하는 것이 아니라 각 사용자가 프로젝트 요구사항을 설치하면서 그때그때 만든다.

잠금 파일은 무엇이고 왜 중요한가

잠금 파일은 프로젝트의 위치에 관계없이 프로젝트의 종속성을 안정적으로 재현할 수 있게 해준다. 이상적으로는 잠금 파일은 각 종속성과 종속성의 위치, 검증을 위한 해시, 그리고 종속성 집합을 재생성하는 데 필요할 수 있는 기타 정보를 나열한다.

보통 파이썬 프로젝트의 종속성 집합은 예를 들어 자바스크립트 프로젝트와 같이 다루기 힘들 정도로 방대하지는 않다. 그러나 소수의 종속성만 있는 프로젝트에서도 충돌은 발생할 수 있다.

fixthis라는 종속성이 있고, 이 종속성은 다시 fixerupper라는 패키지에 종속된다고 가정해 보자. 구체적으로 fixthis는 fixerupper의 버전 1.5에 종속된다. 그 이후 버전에서는 fixthis에서 아직 대응하지 못하는 동작이 발생하기 때문이다.

fixthis를 설치하면 fixerupper 1.5 버전이 자동으로 설치되므로 이 종속성 자체는 문제가 되지 않는다. 문제는 프로젝트의 다른 종속성에서도 fixerupper를 사용할 수 있는 경우다.

프로젝트에 fixthat이라는 또 다른 종속성을 추가하고, 이 종속성 역시 fixerupper에 종속된다고 가정해 보자. 그러나 fixthat은 fixerupper 버전 2.0 이상에서만 작동한다. 이 말은 fixthis와 fixthat은 공존할 수 없다는 의미다.

이번에는 fixit이라는 대체 패키지가 있다고 해보자. 이 패키지는 fixerupper 버전 1.5 이상에서 작동할 수 있다. 이 경우 fixthis와 fixit 둘 다 fixerupper 버전 1.5에서 작동한다. 프로젝트의 잠금 파일은 이 충돌 해결 방법을 기록할 수 있으며, 다른 사용자들은 이 기록을 참조해서 교착 상태 또는 충돌을 피하기 위해 필요한, 정확히 동일한 종속성과 버전을 설치할 수 있다.

PEP 751이 파이썬에 미치는 영향

2024년 7월 이후 많은 논의 끝에 최종 확정된 PEP 751은 파이썬 프로젝트를 위한 공통 잠금 파일 형식을 제안한다. 이 파일 형식은 위에서 설명한 많은 문제를 해결할 수 있다.

이 파일(일반적으로 pylock.toml)은 표준 파이썬 프로젝트 설명 파일인 pyproject.toml과 마찬가지로 TOML 데이터 형식을 사용한다. pylock.toml 파일을 수동으로 작성할 수도 있지만 여기서 중요한 개념은 수동 작성이 강제되면 안 된다는 점이다. 시간이 지나면 기존 툴은 자동으로 pylock.toml을 생성하게 될 것이다. 프로젝트의 가상 환경에서 pip freeze를 통해 requirements.txt 파일을 생성할 수 있는 것과 같은 방식이다.

pylock.toml 파일에는 광범위한 세부정보가 포함될 수 있다. 사용할 잠금 파일 표준의 버전(향후 변경되는 경우), 사용할 파이썬 버전, 다양한 파이썬 버전에서 준수해야 할 환경 마커, 이 정보 대부분에 대한 패키지 수준 지정자 등을 명시할 수 있다. 지정된 각 종속성에는 소스(버전 제어 시스템 포함), 해시, 소스 배포 정보(있는 경우) 등에 대한 세부정보가 포함될 수 있다.

pylock.toml 형식의 세부적인 예시는 PEP 751에서 볼 수 있다. 각 종속성에는 자체 [[packages]] 하위 섹션이 있으며, 여기에는 해당 종속성을 획득한 시점과 위치, 해시, 버전 요구사항 등에 대한 세부정보가 포함된다. 예시는 패키지에 어떻게 여러 플랫폼별 소스가 포함될 수 있는지를 보여준다. 여기서 numpy는 마이크로소프트 윈도우와 일반 리눅스 시스템에 대한 바이너리 휠을 나열한다.

PEP 751 잠금 파일은 언제 구현되는가?

이 기사를 작성하는 시점인 현재 pylock.toml을 지원하는 공식 또는 서드파티 툴은 없다. pip를 시작으로 향후 출시될 툴의 업데이트 버전은 각 개발 팀의 판단에 따라 적절한 속도로 pylock.toml을 도입할 예정이므로 시간이 지나면서 차차 새로운 잠금 파일이 워크플로우와 프로젝트 구성에 추가될 것으로 예상할 수 있다. 결국 생각해야 할 점은 프로젝트 종속성 집합의 복잡성이 pylock.toml 파일이 필요할 만큼 큰지다. 예를 들어 파이파이에 호스팅되는 패키지를 만드는 사람이라면 누구나 프로젝트에 대한 pylock.toml을 만드는 편을 선호할 것이다.

도입의 속도는 기존 툴에 pylock.toml 파일을 생성하는 기능이 얼마나 빠르게 구현될지, 그리고 해당 파일 형식이 툴 자체의 내부 형식을 즉시 대체하는지 여부에 따라 좌우될 것이다. 자체 잠금 파일을 생성하는 몇몇 서드 파티 툴은 pylock.toml로 완전히 대체하는 것을 여전히 주저하고 있다. 예를 들어 uv는 pylock.toml을 내보내기 및 가져오기 형식으로 지원하지만, pylock.toml에서 아직 지원하지 않는 일부 기능으로 인해 네이티브 잠금 파일 형식으로는 지원하지 않을 예정이다. 다만 앞으로 나올 pylock.toml 사양의 개정판에 이러한 기능에 대한 지원이 추가될 가능성도 얼마든지 있다.
dl-itworldkorea@foundryco.com