"파이썬·Go·러스트 비교" 표준 라이브러리는 왜 조직 역량 문제일까?

요약 프로그래밍 언어 생태계에서는 표준 라이브러리(Standard Library)를 최소한으로 유지해야 하는지, 아니면 '배터리 포함(Batteries Included)' 방식으로 풍부하게 제공해야 하는지를 두고 끊임없는 논쟁이 벌어집니다. 하지만 저자는 이것이 잘못된 질문이며, 진짜 핵심은 "어떤 조직적·사회적 구조(Social Architecture)가 높은 품질의 표준 라이브러리를 만들어내는가"라고 주장합니다. 파이썬은 흔히 온갖 기능이 포함되었으나 관리가 제대로 되지 않는 대표 사례로 꼽힙니다. 실제로 unittest 모듈처럼 언어 기본 네이밍 컨벤션조차 따르지 않는 등 모듈 간 품질 편차가 심각합니다. 하지만 저자는 이를 단순한 실수가 아니라 파이썬 코어의 장점이었다고 평가합니다. 미래를 너무 복잡하게 계산하지 않고 초기에 빠르게 기능을 제공했기 때문에, C API가 고착화되는 대가를 치르면서도 오늘날 데이터 사이언스 혁명을 주도하는 언어가 될 수 있었다는 분석입니다. 반면 Go 언어 역시 방대한 표준 라이브러리를 갖추고 있으면서도 높은 완성도로 호평을 받습니다. Go 팀은 훌륭하게 설계된 표준 라이브러리를 지속적으로 공급하고, 나아가 준표준 라이브러리 격인 'golang.org/x'를 통해 확장성까지 안정적으로 흡수하는 조직적 역량을 갖추고 있습니다. 가장 흥미로운 비교 대상은 Rust입니다. Rust 1.0의 컬렉션이나 이터레이터 같은 핵심 표준 라이브러리 설계는 예술의 경지에 가깝지만, 현재 팀은 기존 API를 유지하고 사소한 빈틈을 메우는 수준에 머물러 있으며 과감한 설계 결정을 내리는 실행 역량은 제한적입니다. Go의 'golang.org/x'가 성공적으로 운영되는 것과 달리 Rust의 'rust-lang-nursery'는 사실상 방치된 무덤이 되었습니다. 저자는 기술적으로는 쉬운 'OS로부터 난수 바이트 스트림 가져오기' 기능조차 수년째 표준 라이브러리에 들어가지 못하는 이유가 바로 전 세계적 조율과 자금 지원 등이 얽힌 까다로운 조직 구조 문제 때문이라고 지적합니다.