하나의 포크, 수천 개의 의존성: 파이썬의 취약한 비동기 HTTP 기반을 드러낸 HTTPX 분열 사태

해커 뉴스 691포인트. 한 개발자가 "HTTPX를 포크했습니다"라고 올렸을 때, 파이썬 백엔드 커뮤니티 전체가 대체 누가 이 바닥을 떠받치고 있는 건지 불편한 질문을 쏟아내기 시작한 그 순간의 열기다.

아무도 소리 내어 말하고 싶어 하지 않는 사실이 있다. 여러분이 애용하는 AI 에이전트 프레임워크, FastAPI 마이크로서비스, LangChain 파이프라인, API와 통신하는 모든 비동기 코드의 핵심에 있는 HTTP 클라이언트 — 이 모든 것이 encode GitHub 조직 아래 소수의 저장소로 귀결된다. 그리고 수년간 이 조직은 사실상 한 사람에 의해 운영되어 왔다.

어쩌다 여기까지 왔는지 짚어보겠다.

2019, 2020: 모던 HTTP 클라이언트가 공백을 채우다

파이썬 생태계에는 문제가 있었다. requests는 모두가 사랑한 HTTP 라이브러리였고, 철저히 동기 방식이었으며, 모든 곳에서 읽기 좋은 코드를 위한 Kenneth Reitz의 선물이었다. 하지만 비동기 파이썬은 빠르게 성숙하고 있었다. AIOHTTP가 존재했지만 자체 웹 서버라는 짐을 짊어지고 있었고, 완전히 다른 언어에나 어울릴 법한 API를 가지고 있었다.

Django REST Framework와 비동기 웹 프레임워크 Starlette로 이미 이름을 알린 Tom Christie가 HTTPX를 모던 대체제로 내놓았다. 제안은 우아했다. requests 호환 API이면서 비동기도 네이티브로 지원하는 것. 동기든 비동기든 같은 인터페이스. 실질적인 빈틈을 메웠고, 채택은 빨랐다.

2021년이 되자 HTTPX는 파이썬의 사실상 표준 비동기 HTTP 클라이언트가 되었다. 마케팅 덕분이 아니라 — 진짜 잘 만들었기 때문이다.

2022, 2023: 아무도 생각하지 않았던 엘리베이터 샤프트

이야기가 흥미로워지는 동시에 약간 불안해지는 지점이다.

AI/ML 붐이 가속되면서 새로운 세대의 파이썬 프레임워크가 등장했다 — LangChain, LlamaIndex, AutoGPT를 비롯한 수십 개의 에이전트 프레임워크 — 모두 추론 API로의 비동기 HTTP 호출 위에 구축되었다. 대부분이 HTTPX를 직접, 또는 openai, anthropic, httpcore 같은 전이적 의존성을 통해 끌어왔다.

층마다 다른 건축가가 설계했지만, 모두 같은 엘리베이터 샤프트를 공유하는 고층 빌딩을 떠올려 보라. 아무도 엘리베이터 샤프트가 고장 나기 전까지는 신경 쓰지 않는다.

HTTPX가 바로 그 엘리베이터 샤프트가 되었다. 의존성 추적 도구에 따르면, 이 라이브러리는 월간 다운로드 수 합계가 수억 건에 달하는 패키지들의 의존성 트리에 자리 잡고 있다. openai 파이썬 SDK만 해도 — HTTPX를 번들링하거나 의존하고 있는 — 월 수천만 건의 설치를 기록한다.

그런데 버스 팩터는? 여전히 1이다.[^1]

[^1]: 버스 팩터(bus factor)란 "프로젝트가 죽기 전에 버스에 치여야 하는 사람 수"를 뜻하는 개발자 은어다. 버스 팩터 1이 의미하는 바는 정확히 여러분이 떠올리는 그대로다.

2025년 하반기: 미뤄진 유지보수의 느린 연소

오픈소스 유지보수는 갑작스러운 폭발이 아니라 느리게 타들어가는 위기다. 이슈가 쌓인다. 풀 리퀘스트가 리뷰 림보에 방치된다. 기능 요청은 인정만 되고 구현되지 않는다. 이 중 어떤 것도 악의에서 비롯된 것이 아니다 — Tom Christie는 사실상 혼자서, 때로는 스폰서십의 도움을 받고 때로는 받지 못한 채, 여러 핵심 프로젝트를 유지하는 것의 어려움에 대해 놀라울 정도로 투명하게 밝혀왔다.

그러나 투명성이 병목을 해결해 주지는 않는다.

개발자들이 불만을 표출하기 시작했다. 간단한 버그 수정이 몇 주, 몇 달씩 방치되었다. HTTP/2 구현에는 알려진 거친 부분이 있었다. 의존성 버전 고정이 하류에서 마찰을 일으켰다. encode 조직의 다른 프로젝트들 — httpcore, uvicorn, Starlette — 도 같은 역학에 직면했다. 유지보수자 한 명, 유한한 시간, 무한한 수요.

2026년 초: 드라마 없는 포크

포크 자체는 보통의 테크 드라마처럼 격렬하지 않았다. 분노에 찬 선언문도 없었다. 공개적 갈등도 없었다. 한 개발자가 왜 HTTPX를 포크했는지 차분하게 설명하는 글을 올렸다. 필요한 패치가 머지되지 않고, 프로덕션 시스템이 무한정 기다릴 수 없으며, 업스트림에 커밋 권한을 얻을 경로가 보이지 않았다는 것이다.

그 뒤를 이은 해커 뉴스 스레드는 결코 차분하지 않았다.

일부는 포크가 필수적이고, 심지어 건강한 것이라고 주장했다 — 오픈소스 라이선스는 정확히 이를 가능하게 하려고 존재한다. 다른 이들은 성급하다며, 외교적 수단을 다 쓰지 않은 것이라 비판했다. 내가 가장 설득력 있다고 보는 세 번째 진영은 포크가 병이 아니라 증상이라고 지적했다.

병은 구조적이다. 파이썬 생태계는 단일 유지보수자 프로젝트 위에 핵심 인프라를 반복적으로 구축하고는, 산술이 따라잡으면 놀란다.

파이썬이 유독 취약한 이유

파이썬만의 문제는 아니지만, 유독 취약할 수 있다. 자바스크립트 생태계는 2016년 left-pad와 2022년 colors.js로 이런 교훈을 뼈아프게 배웠다. 러스트에는 러스트 재단이 있고, 초기부터 공동 유지보수 문화가 녹아 있다. Go는 표준 라이브러리가 HTTP를 네이티브로 포함해 문제 자체를 우회한다.

파이썬의 접근 방식은 역사적으로 달랐다. 표준 라이브러리의 urllib과 http.client는 작동은 하지만 미니멀하다. 커뮤니티가 서드파티 라이브러리로 빈틈을 메운다. 이 모델은 그 라이브러리들이 잘 유지될 때 아름답게 작동한다. 그렇지 않을 때는, 전체 의존성 체인이 위험을 상속받는다.

HTTPX가 특히 우려스러운 것은 스택에서 차지하는 위치 때문이다. 이것은 날짜 포매팅을 위한 유틸리티 라이브러리가 아니다. TLS, 커넥션 풀링, HTTP/2 멀티플렉싱, 네트워크 호출의 재시도 로직을 처리하는 계층이다. 이것들이 잘못되면 무음의 데이터 손상, 보안 취약점, 또는 연쇄적 프로덕션 장애를 의미한다.

AI 붐이 판돈을 키운 방식

계속 머릿속을 떠나지 않는 것이 있다. AI 에이전트 물결은 파이썬 HTTP 클라이언트 문제의 폭발 반경을 대폭 확대시켰다. 전형적인 에이전트 프레임워크는 사용자 상호작용당 수십 건의 HTTP 호출을 수행한다 — 종종 여러 LLM 제공업체, 도구 API, 검색 서비스에 대해서. 그 호출 하나하나가 HTTPX를 통해, 또는 HTTPX에 의존하는 무언가를 통해 흐른다.

에이전트 인프라를 구축하는 팀들과 이야기해 보면, 대부분은 자신의 스택에 HTTPX가 있다는 사실조차 모른다. OpenAI SDK나 LangChain을 임포트했을 뿐, 의존성 트리를 더 깊이 들여다본 적이 없다. 그것은 태만이 아니다 — 소프트웨어 합성이란 원래 그렇게 작동하도록 되어 있다. 하지만 이는 HTTPX 수준의 거버넌스 실패가 수천 개의 프로덕션 배포에 조용히 전파된다는 뜻이다.

포크의 가장 유력한 궤적

오픈소스에서 포크는 비교적 예측 가능한 생명주기를 따른다. 대부분은 시든다. 소수가 충분한 견인력을 얻어 새로운 표준이 된다. 때로는 신뢰할 만한 포크의 존재가 원본 프로젝트에 거버넌스 개혁의 압력을 가한다. 그 마지막 결과가 아마 여기서는 최선의 시나리오일 것이다.

2026년 3월 하순 현재, 상황은 여전히 유동적이다. 여러 기여자들이 보다 넓은 거버넌스 모델 하에서 HTTPX 유지보수를 돕겠다고 나섰다. Tom Christie가 그 제안을 받아들일지 — 그리고 어떤 조건으로 — 가 포크의 성장 또는 소멸을 좌우할 것이다.

파이썬 소프트웨어 재단과 기업 스폰서들이 귀담아들어야 할 더 큰 교훈이 있다. 파이썬의 비동기 HTTP 스택 위에 수십억 달러 규모의 AI 제품을 구축하는 기업들은 그 유지보수에 실질적 이해관계가 있다. 유지보수자 한 명을 후원하는 것은 거버넌스가 아니다. 거버넌스란 머지 권한을 가진 복수의 커미터, 문서화된 의사결정 프로세스, 그리고 특정 한 사람의 지속적 가용성과 의지에 의존하지 않는 승계 계획을 의미한다.

당신에게 의미하는 것

HTTP와 관련된 프로덕션 코드를 배포하는 파이썬 개발자라면, 내 솔직한 견해는 이렇다.

당황하지 마라. HTTPX는 작동한다. 포크는 특정 패치를 더 빨리 머지해야 할 때의 대안으로 존재한다. 어느 프로젝트도 내일 당장 사라지지 않는다.

의존성 트리를 감사하라. pip show httpx를 실행하거나 락 파일을 확인하라. 직접 사용하고 있는 건지, 전이적 의존성 세 단계를 거쳐 상속받은 건지 파악하라. 그 지식은 위험을 평가할 때 중요하다.

업스트림에 기여하라. 이건 좀 불편한 이야기다. 당신이나 당신의 회사가 무엇을 돌려줄 수 있을지 고민해 보라. 돈, 코드 리뷰 시간, 문서화, 테스트 인프라. 오픈소스 지속가능성 위기는 새로운 것이 아니지만, 인센티브가 바뀌지 않았기에 같은 실패 양상을 계속 만들어낸다.

HTTPX 포크는 무언가의 끝이 아니다. 수년간 쌓여 온 압력을 분출하는 안전밸브다. 문제는 파이썬 생태계가 이를 경종으로 받아들일 것인가 — 아니면 하루 트렌드에 올랐다 아무것도 바꾸지 못하는 또 하나의 해커 뉴스 스레드로 치부할 것인가이다.[^2]

[^2]: 내 예상? 그 사이 어딘가. 거버넌스 제안서를 만들어 낼 정도의 소음은 있을 것이고, 그것을 완전히 이행할 만큼의 지속적 관심은 부족할 것이다. 틀리고 싶다.