표준 라이브러리와 그 불만들 · Alex Gaynor

2025년 5월 19일 월요일

표준 라이브러리는 프로그래밍 언어 설계에서 가장 논쟁이 많은 주제 가운데 하나다. 어떤 프로그래밍 생태계에서든 가장 널리 쓰이는 API이자, 동시에 가장 많은 비판을 받는 대상이기도 하다. 이 글은 표준 라이브러리를 표준 라이브러리답게 만드는 요소가 무엇인지 탐구한다. 전적으로 비규범적(non-normative)인 글이며, 표준 라이브러리가 어떠해야 하는지 규정하려는 것이 아니라 무엇인지 설명하는 것이 목적이다.

표준 라이브러리는 프로그래밍 언어 사용자가 별도의 추가 조치 없이 사용할 수 있는 라이브러리/API의 집합을 말한다. 어떤 API가 제공되는지는 언어 자체의 의미론(semantics)이 정의되는 것과 같은 곳에서 규정된다. 이렇게 간단한 정의를 가진 대상이 어찌하여 그토록 많은 논쟁의 원천이 될 수 있을까?

그럼, 사람들이 표준 라이브러리에 대해 무엇을 좋아하고 무엇을 싫어하는지부터 살펴보자. 다시 말하지만, 이는 순전히 기술적 서술일 뿐 옳고 그름에 대한 판단을 내리려는 것은 아니다.

좋아하는 점

아마도 표준 라이브러리에 대해 가장 많은 호감을 받는 점은 사용이 쉽다는 것이다. 그냥 거기 있다(“배터리 포함”). 별도의 설정이나 패키지 설치 등이 필요 없다. 보편적 패키지 관리가 없거나, 외부 의존성을 추가하는 일이 고통스러운 환경에서는 표준 라이브러리와 서드파티 의존성 간의 사용 편의성 차이가 더욱 크게 부각된다.

기술적 차원의 용이함을 넘어서, 표준 라이브러리는 인지적으로도 더 쓰기 쉽다. 표준 라이브러리의 Date 타입을 쓸지 말지는 사실상 고민거리가 아니지만, 서드파티 라이브러리를 쓰기로 하면 여러 경쟁 옵션 중에서 골라야 한다. 표준 라이브러리는 단지 표준일 뿐만 아니라, 기본값이다.

표준 라이브러리는 또한 다른 라이브러리들 간의 상호운용성을 가능하게 하는 표준 어휘 타입들을 제공한다. 예를 들어, 표준 DateTime 타입이 있으면 DateTime 값을 파싱하는 서드파티 ASN.1 파서 라이브러리와, 데이터베이스에 DateTime 값을 저장하는 방법을 아는 서드파티 MySQL 라이브러리 사이의 상호운용이 쉬워진다. 마찬가지로, 표준 라이브러리의 Reader 인터페이스가 있으면 서드파티 .zip 라이브러리가 생성한 리더를 서드파티 CSV 파서가 소비할 수 있다. 널리 쓰이는 서드파티 라이브러리도 비슷한 역할을 할 수 있지만, 표준 라이브러리는 말 그대로 표준이기 때문에 이런 상호운용을 더 수월하게 만든다.

사람들이 표준 라이브러리를 좋아하는 또 다른 이유는, 언어 자체로부터 하위 호환성이나 지원 플랫폼 같은 정책을 상속받는다는 점이다. 또한 (적어도 언어만큼은) 높은 품질을 갖춘 것으로 간주되며, 보안 이슈를 책임감 있게 관리하고, 충분히 테스트되었다고 여겨진다. 어떤 부분은 실제 사용 경험에서 나온 관찰이고, 어떤 부분은 사람들의 가정이지만, 모두가 라이브러리에 바라는 요소이며 일반적으로 표준 라이브러리는 이러한 점들을 보장한다고 믿어진다.

이러한 관찰과 가정의 결과로, 표준 라이브러리는 정책 제약이 있는 환경(예: 서드파티 보안 심사 정책이 있거나 에어갭(air-gapped) 환경에서 운영하는 경우)에서도 항상 사용 가능하다. 반면, 이런 환경에서 서드파티 라이브러리는 검토가 필요하며, 허용되더라도 그 일정이 길어질 수 있다. 이것 역시 표준 라이브러리가 단순히 더 쓰기 쉬운 이유 중 하나다.

표준 라이브러리에 포함되는 것이 공급망(supply chain) 리스크를 어떻게 증가시키는지(컴플라이언스와는 별개로) 계산하는 문제는 약간 더 복잡하다. 다른 모든 것이 동일하다면, 기존 표준 라이브러리 유지관리자들이 관리하는 라이브러리는 독립적인 유지관리자가 있는 서드파티 라이브러리에 비해 공급망 리스크를 줄인다. 그렇다면 표준 라이브러리 유지관리자이기도 한 사람들이 유지관리하는 서드파티 패키지는 공급망 리스크를 추가할까? 아마도 아니다(단, 이후에 유지관리자가 바뀌었을 때 다운스트림 소비자가 이를 알아차릴 방법이 있어야 한다). 비슷하게, 서드파티 라이브러리를 표준 라이브러리로 이관하는 과정에서 표준 라이브러리에 새로운 유지관리자를 추가해야 한다면, 그것은 리스크에 어떤 영향을 줄까? 일반적으로 우리는 표준 라이브러리가 매우 중요하고 면밀히 감시되므로 공급망 리스크가 무시할 만하다고 생각하지만, 가장자리에서는(한계 상황에서는) 유지관리자 풀을 확장하면 어떤 형태의 공급망 리스크는 분명 도입될 것이다(동시에, 더 많은 사람이 잠재적 악의를 감시함으로써 다른 형태의 리스크를 완화할 수도 있다).

전혀 다른 맥락에서, 표준 라이브러리는 프로그래밍 언어 구현과 함께 개발·배포되기 때문에 구현 세부사항에 의존할 수 있다. 이는 표준 라이브러리만이 제공할 수 있는 API나 내부 구현을 가능하게 하며, 서드파티 라이브러리에서는 안전하게 재현할 수 없는 이점을 준다(성능은 구현 세부사항에 의존할 수 있을 때 얻는 대표적 이점이다). 비슷한 이유로, 표준 라이브러리 개선이 필요해지면 그 기능을 수용하기 위해 언어 자체를 변경하도록 동기를 부여할 수 있는데, 이는 서드파티 라이브러리라면 정당화하기 어려운 일이다.

마지막으로, 이러한 모든 결과로 표준 라이브러리는 매우 널리 사용된다. 따라서 성능, 마감(polish), 문서, 그 밖에 손이 많이 가는 축들에 대해 상당한 투자를 정당화할 수 있다. 물론 정당화된 투자가 항상 이뤄지는 것은 아니지만, 사용자들은 적어도 때때로는 그렇게 될 것이라고 일반적으로 기대한다.

싫어하는 점

아마 표준 라이브러리에 대한 가장 큰 비판은 시간이 지날수록 쇠퇴(“표준 라이브러리는 모듈이 죽으러 가는 곳”)한다는 것이다. 이는 여러 방식에서 사실이다. 첫째, 강한 하위 호환성 정책을 갖고 있지만 시맨틱 버저닝(Semantic Versioning) 같은 절차를 적용하기는 제한적이기 때문에(참고: Python 3), 좋지 않은 API를 오랜 기간 떠안는 경향이 있다(종종 옛 API를 감가상각(deprecate)하고 진화시키려는 시도조차 하지 않는다). 둘째, 독립 라이브러리보다 개발·기여가 덜 편하다. 사실상 거대한 모노레포에서 개발되는데(이를 전담 지원하는 엔지니어링 팀은 없는 경우가 많다), CI 사이클이 길고, 종종 특수한 빌드 프로세스를 갖는다. 셋째, 언어의 수명이 길어질수록 표준 라이브러리에 무언가를 추가하기가 어려워져, 시간이 지나면서 표준 라이브러리가 일관성이 떨어진다는 인상을 주고, 어떤 라이브러리를 보면 그것이 표준 라이브러리에 편입된 시대를 알아차릴 수 있을 정도가 된다.

표준 라이브러리에 대한 또 다른 불만은, 새로운 추가(또는 버그 수정)의 이점을 누리려면 전체 프로그래밍 언어를 업그레이드해야 한다는 점이다. 매우 흔한 패턴은 사용자가 운영체제 벤더로부터 프로그래밍 언어를 공급받고, 서드파티 라이브러리는 비(非)시스템 패키지 관리자로 설치하는 것이다. 그 결과 표준 라이브러리는 업그레이드 주기가 수년에 이르는 반면, 서드파티 라이브러리는 훨씬 짧은 주기를 가질 수 있다. 이 역학은 오픈 소스 라이브러리 개발자들에게도 해당되는데, 이들은 서드파티 의존성 버전 선택에는 상당한 유연성이 있지만, 최소 지원 프로그래밍 언어 버전을 공격적으로 올리려 하면 더 큰 반발에 부딪힌다.

마지막으로, 표준 라이브러리로 배포되는 것이 사실상 라이브러리 간 경쟁에서 불공정한 방법이라는 우려가 있다. 표준 라이브러리에 들어가면, API 사용성, 성능, 신뢰성, 문서 같은 품질 지표가 아니라 배포 용이성을 기반으로 서드파티 대안과 경쟁할 수 있다. 결과적으로, 표준 라이브러리에 포함된 라이브러리가 서드파티 대안보다 못하더라도 기본값 지위를 유지할 수 있다. 극단적으로는 서드파티 라이브러리가 표준 라이브러리를 능가할 수 있겠지만, 흔한 경우에는 배포의 용이성이 자주 승리하여, 표준 라이브러리의 무언가와 경쟁하려는 시도 자체를 좌절시키기까지 한다.

결론

분명한 점 한 가지는, 사람들이 표준 라이브러리에 대해 좋아하는 것과 싫어하는 것 사이에 놀라운 대칭성이 있다는 것이다. 하위 호환성은 두려움 없이 업그레이드할 수 있다는 점에서 훌륭하지만, 동시에 과거의 모든 실수를 영원히 짊어지고 간다는 점에서 끔찍하다. 미리 설치되어 있고 쓰기 쉬운 것은 대단히 편리하지만, 서드파티 라이브러리에 대한 투자를 밀어내어 최선의 것을 만들려는 경쟁 압력을 약화시키기도 한다. 각자가 이 동전의 양면을 어떻게 저울질하느냐는, 대개 표준 라이브러리가 더 커져야 하는지 더 작아져야 하는지에 대한 신념과 선호를 반영한다.

이상적으로는, 이러한 장점들(의 일부)만 취하고 단점은 피하는 방법을 찾을 수 있으면 좋겠다. 이 글이 그것을 달성하기 위한 사고를 촉발하는 유용한 자료가 되기를 바란다.