소프트웨어 공급망 공격이 현실적 위협으로 자리 잡으면서, 배포물이 정말로 공개된 소스 코드로부터 만들어졌는지를 제3자가 독립적으로 검증할 수 있느냐가 중요한 질문이 되고 있다. 파이썬 패키징 생태계의 핵심 인물 중 한 명인 브렛 캐넌은 2026년 파이썬 패키징 협의회(PPC) 후보 지명서를 작성하던 중, PyPI에는 '재현 가능한 빌드(reproducible builds)'를 수행하는 정의된 방법이 아직 없다는 점을 문제로 지적했다. 그가 이 아이디어에 끌리는 이유는, 잘 설계하면 배포물을 만들어 올리는 사람(sdist나 wheel 생산자) 쪽에 추가 작업을 거의 요구하지 않고도 도입할 수 있어 진입 장벽이 낮기 때문이다.
순수 파이썬 패키지도 예외가 아니다
재현 가능한 빌드의 핵심 효용은, 배포물에 담긴 바이트가 그것을 만든 소스 코드로부터 기대되는 결과와 일치하는지를 외부에서 확인할 수 있다는 데 있다. 이를 통해 빌드 과정에서 누군가 코드를 변조했는지 탐지할 여지가 생긴다. 바이트 단위 검증까지 가지 않더라도, 빌드에 관여한 소프트웨어 목록을 기록해 두면 알려진 손상 도구가 쓰였는지를 더 쉽게 잡아낼 수 있다는 부수 효과도 있다. 이것은 가상의 이점이 아니다. 실제로 솔라윈즈는 빌드 과정에 악성 코드가 주입되면서 침해당했다.
여기서 오해하기 쉬운 지점이 있다. '빌드'라는 단어 때문에 컴파일이 필요 없는 순수 파이썬 wheel은 안전하다고 여기기 쉽지만, 그 wheel을 만든 빌드 백엔드가 존재하며 그 백엔드가 손상되면 wheel에 악성 코드가 주입될 수 있다. 즉 파이썬 패키징 안에 이 위험을 무시해도 되는 영역은 없다.
무엇이 아직 빠져 있나
재현 가능한 빌드를 가능하게 하려면 먼저 어떤 소스 코드가 쓰였는지를 기록해야 한다. 현재 sdist나 wheel 자체에는 이 정보가 담기지 않는다. 다만 소스 저장소나 아카이브에서 직접 설치하는 경우에는 설치 도구가 direct_url.json 파일에 그 위치를 남긴다. 같은 정보를 배포물 메타데이터에 기록하도록 하면, 배포물을 만든 소스의 출처를 알 수 있게 된다.
더 까다로운 부분은 배포물을 만드는 데 쓰인 모든 도구를 기록하는 일이다. wheel의 경우 소프트웨어 자재 명세서(SBOM)를 기록할 수 있는 지원이 이미 있다. 이 기능을 추가한 PEP 770은 SBOM으로 빌드 도구를 기록할 수 있다고 명시하는데, 캐넌은 이 PEP의 위임 결정권자였다. 빌드에 사용된 소프트웨어를 모두 남겨 두면 동일한 바이트를 재현해 변조가 없었음을 보일 수 있다는 논리다. 문제는 sdist에는 이런 메커니즘이 없다는 점이다. sdist는 대개 PKG-INFO 파일이 든 단순 tar 아카이브라서 별도 메타데이터 파일을 넣을 자리가 없다. 결국 '재현 가능한 빌드를 원하면 sdist를 쓰지 말라'고 어깨를 으쓱하고 넘기거나, 구조화된 데이터를 담을 수 있는 sdist v2 포맷을 새로 마련해야 한다.
빌드를 어떻게 다시 돌릴 것인가
정보를 다 갖췄다고 해도 실제로 빌드를 재현하는 방법이 남는다. 다행히 pyproject.toml의 [build-system] 테이블이 빌드 백엔드로 들어가는 정의된 진입점 역할을 한다. 백엔드를 실행하는 데 필요한 소프트웨어가 모두 기록돼 있다면, 같은 것들을 설치한 뒤 [build-system]이 정의한 대로 백엔드를 호출해 빌드 과정을 재생할 수 있다. 나아가 빌드 백엔드가 자신이 실행되는 환경에 무엇이 설치돼 있는지를 스스로 기록하도록 하면, 배포물 생산자가 별도 작업을 하지 않아도 오늘날의 SBOM에 빌드 관련 소프트웨어를 담을 수 있다. 다만 이는 pip 관리자들에게는 적지 않은 작업을 의미한다.
이 모든 것이 갖춰졌다고 가정할 때, 남는 질문은 이를 어떻게 사람들에게 유용하게 만드느냐다. 보안을 신경 쓰는 모든 이가 자기가 쓰는 패키지를 직접 다시 빌드해야 한다면 현실성이 없다. 캐넌이 제시하는 한 가지 방향은 '신뢰할 수 있는 검증자'다. 어차피 여러 기업이 내부적으로 재현 검증을 수행할 테니, 그 결과를 PyPI에 되돌려 주면 특정 배포 파일에 대해 '이 파일은 아무개가 독립적으로 재현했다'고 표시할 수 있다. 사용자는 배포물이 제작자가 의도한 그대로임을 알게 되고, 검증자는 커뮤니티 기여에 대한 인정을 얻는다. 이 정보를 인덱스 API에 노출하면 설치 도구가 재현이 확인된 배포물을 우선하도록 만들 수도 있다.
중요한 것은 이 모든 장치가 강제가 아니라 혜택으로 다뤄져야 한다는 점이다. 재현 가능한 배포물을 만들지 못하는 빌드 백엔드를 쓰는 사람을 탓하는 방식이어서는 안 된다. 캐넌은 이를 SLSA 빌드 레벨 1을 충족한다고 말할 수 있는 것에 비유한다. 어떤 프로젝트는 그런 배지를 얻는 것을 좋아하지만, 신경 쓰지 않기로 한 이들에게 흠이 되어서는 안 된다는 것이다.
한국의 파이썬 실무자 관점에서 이 논의는 당장 도입해야 할 규격이라기보다 방향성에 가깝다. 사내 배포 파이프라인이나 폐쇄망 미러를 운영하는 조직이라면, wheel의 SBOM 기록과 [build-system] 기반 재빌드가 이미 기술적으로 가능한 만큼 내부 검증 절차를 선제적으로 실험해 볼 여지가 있다. 반면 sdist 중심으로 배포하는 프로젝트는 포맷 자체의 한계 때문에 당분간 완전한 재현 검증을 기대하기 어렵다는 점을 감안해야 한다. 아직은 표준화되지 않은 구상 단계의 논의라는 한계 역시 분명하다.