— Hugo van Kemenade 블로그 「PEPs & Co.」 (2025-05-14) 요약 oai_citation:0‡Hugo van Kemenade

한눈에 보는 키포인트

  1. PEP의 탄생 배경

    • 1990년대 후반 CNRI에 있던 배리 워쇼우(Barry Warsaw)가 IETF RFC 모델을 참고해 “제안 → 토론 → 결론”의 공식 문서를 파이썬에도 도입해야 한다고 판단했다.
    • 그는 “경쾌하다(peppy)”는 뉘앙스를 살려 ‘PEP’이라는 단어를 먼저 만들고, 거꾸로 Python Enhancement Proposal이라는 뜻을 붙인 backronym을 탄생시켰다.
    • 워쇼우는 PEP 0(목차)과 PEP 1(프로세스 설명)을 직접 작성해 체계를 확립했다. oai_citation:1‡Hugo van Kemenade
  2. RFC 모델의 성공적 이식

    • PEP는 “하나의 문서에 내용을 모아 논의한다”는 방식을 통해 핵심 개발자가 폭주하는 아이디어를 효율적으로 검토할 수 있도록 했다.
    • 이후 제안서 형식은 파이썬을 넘어 다수 오픈소스 프로젝트의 ‘협업 표준’으로 자리 잡았다. oai_citation:2‡Hugo van Kemenade
  3. 다양하게 파생된 ‘○EP’들
    대표적인 확장판만 살펴봐도 PEP 모델의 전파력을 확인할 수 있다.

    약어 커뮤니티 정식 명칭
    AIP Apache Airflow Airflow Improvement Proposal
    BIP Bitcoin Bitcoin Improvement Proposal
    DEP Django Django Enhancement Proposal
    JEP Jupyter Jupyter Enhancement Proposal
    KEP Kubernetes Kubernetes Enhancement Proposal
    NEP NumPy NumPy Enhancement Proposal
    SLEP scikit-learn Scikit-learn Enhancement Proposal
    SPEC Scientific Python Scientific Python Ecosystem Coordination
    TIP Tcl Tcl Improvement Proposal
    XEP XMPP XMPP Extension Protocol
  4. 왜 중요한가

    • PEP는 대규모 분산 개발에서 투명성·추적 가능성을 보장하며, 커뮤니티가 스스로 로드맵을 설계하도록 돕는다.
    • 블로그가 정리한 ‘○EP’ 목록은 “문서화된 제안 프로세스가 현대 오픈소스 거버넌스의 필수 요소”임을 보여준다. oai_citation:4‡Hugo van Kemenade