표준 라이브러리인가 아니면 제3자 라이브러리인가? LLM 보조 제로 의존성 (Zero-Dependency) Python 라이브러리의 경험적

제3자 (Third-party) Python 라이브러리는 의존성 관리 오버헤드 (dependency management overhead), 공급망 리스크 (supply chain risk), 그리고 제한된 환경에서의 배포 마찰 (deployment friction)을 유발합니다. 자연스러운 질문은 이 생태계의 어느 정도를 Python의 표준 라이브러리 (stdlib)만 사용하여 복제할 수 있는지, 그리고 그 과정에서 발생하는 정확성 및 성능 비용은 어느 정도인지입니다. 우리는 엄격한 제약 조건 하에 LLM (Large Language Model)의 도움을 받아 개발된, 인기 있는 제3자 라이브러리를 각각 표준 라이브러리만으로 재구현한 단일 파일 Python 모듈 컬렉션인 zerodep을 통해 이를 경험적으로 다룹니다. 이 제약 조건은 외부 임포트 (external imports) 금지, 단일 파일 구성, 즉시 사용 가능한 API 호환성 (drop-in API compatibility), 그리고 참조 라이브러리에 대한 필수적인 정확성 검증을 포함합니다. 직렬화 (serialization), 네트워킹 (networking), 암호학 (cryptography), 에이전트 프로토콜 (agent protocols), 텍스트 처리 (text processing)를 포함한 12개 카테고리에 걸쳐 40개 이상의 모듈을 아우르는 zerodep은 서로 연관된 두 가지 질문에 대한 통제된 테스트베드를 제공합니다: (1) 표준 라이브러리가 충분한 지점은 어디인가? 그리고 (2) LLM이 엄격한 기호적 제약 (symbolic constraints) 하에서 정확하고 성능이 뛰어난 코드를 효과적으로 생성할 수 있는가? 체계적인 벤치마킹 결과, 표준 라이브러리 전용 구현체는 대부분의 사례에서 성능 동등성 (참조 라이브러리의 2배 이내)을 달성함을 보여줍니다. 주요 성능 저하 지점 (performance cliff)은 순수 Python 제3자 라이브러리의 고유한 오버헤드가 아니라, C-확장 (C-extension) 기반의 연산 (이미지 처리, 바이너리 직렬화, 저수준 암호학)입니다. 반대로, 널리 사용되는 많은 라이브러리는 LLM이 생성한 표준 라이브러리 재구현체가 피할 수 있는 아키텍처적 오버헤드를 가지고 있으며, 이는 여러 카테고리에서 5~115배의 속도 향상을 가져옵니다. 우리는 복잡도 계층 및 라이브러리 카테고리에 따른 표준 라이브러리의 역량 경계를 규정하고, LLM 보조 개발이 성공하는 지점과 반복적인 인간의 수정이 필요한 지점을 논의하며, 대규모 의존성 없는 소프트웨어 공학 (dependency-free software engineering)에 대한 시사점을 검토합니다. zerodep은 https://github.com/Oaklight/zerodep 에서 오픈 소스로 제공됩니다.