더 나은 배터리

• 표준 라이브러리의 핵심 쟁점은 크기가 아니라 일관된 품질의 API를 설계하고 제공할 조직 역량임
• Python 표준 라이브러리는 품질과 명명 규칙이 고르지 않지만, 기능을 일찍 제공한 덕분에 데이터 과학 혁명의 기반이 됨
• Go는 포괄적인 표준 라이브러리로도 높은 평가를 받으며, Go 팀은 잘 설계된 API와 golang.org/x까지 운영할 제도적 역량을 갖춤
• Rust 1.0의 컬렉션과 이터레이터 API는 뛰어나지만, 현재 팀은 기존 API 유지와 일부 공백 보완을 넘어 설계 결정을 실행할 역량이 제한적으로 보임
• 2026년에도 Rust에 운영체제의 임의 바이트 스트림을 얻는 API가 없다는 사실은 간단한 기술 문제도 자금 지원을 포함한 조직 구조 없이는 해결하기 어려움을 보여줌

크기보다 품질과 조직 역량

• 표준 라이브러리를 최소화할지 포괄적으로 만들지를 둘러싼 오랜 논쟁은 핵심을 비껴감
• Python의 문제는 표준 라이브러리의 크기가 아니라 고르지 않은 품질에 있음
  • 일부 모듈은 언어의 명명 규칙조차 따르지 않으며 unittest가 그 사례임
  • 미래를 지나치게 고려하지 않고 기능을 일찍 제공하는 Python core의 방식은 실수가 아니라 장점이기도 함
  • 이 방식은 CPython을 사실상 언어로 굳힌 cAPI를 낳았지만, 동시에 Python이 데이터 과학 혁명을 이끄는 기반도 만듦
• Go의 표준 라이브러리 역시 포괄적이지만 높은 평가를 받음
  • Go 팀은 잘 설계된 표준 라이브러리 API뿐 아니라 추가 기능을 제공하는 golang.org/x까지 운영할 제도적 역량을 갖춤

Rust가 드러낸 실행 역량의 한계

• Rust 1.0 표준 라이브러리 API는 뛰어나며, 특히 컬렉션과 이터레이터가 높은 완성도를 갖춤
• 현재 팀은 기존 API를 보존하고 일부 공백을 채울 수 있지만, 설계 결정을 실제로 실행할 역량은 제한적으로 보임
  • Go의 golang.org/x가 초과 역량을 담는 반면, rust-lang-nursery는 묘지에 가까운 상태임
• Rust는 2026년에도 운영체제에서 임의 바이트 스트림을 얻는 API를 제공하지 않음
  • 기술적으로는 쉬운 문제지만, 프로그래밍 언어라는 전 세계적 조정 환경에서 해결하려면 사람에게 비용을 지급하는 일까지 포함한 까다로운 조직 구조가 필요함
  • 다만 난수에 관한 기존 관심사에 과도한 비중을 둔 해석일 가능성도 남아 있음