Python httpx를 포크한 개발자 이야기: 오픈소스 거버넌스와 개발자의 선택

무슨 일이 있었냐면

파이썬 생태계에서 HTTP 클라이언트 라이브러리 하면 requests가 가장 유명하지만, 최근 몇 년간 httpx가 빠르게 자리를 잡아왔어요. httpx는 requests와 비슷한 API를 제공하면서도 async(비동기)를 네이티브로 지원하고, HTTP/2까지 다루는 모던한 라이브러리거든요. FastAPI 같은 현대적인 파이썬 웹 프레임워크와 궁합이 특히 좋아서 많은 프로젝트에서 채택하고 있었어요.

그런데 한 개발자가 이 httpx를 포크(fork)해서 httpxyz라는 새 프로젝트를 만들었어요. 포크가 뭐냐면, 기존 오픈소스 프로젝트의 코드를 복사해서 독립적인 새 프로젝트로 가져가는 거예요. 단순히 "내가 더 잘 만들겠다"가 아니라, 포크에는 보통 꽤 구체적인 이유가 있거든요.

왜 포크했을까: 기술적 이유와 거버넌스 문제

이 개발자(Michiel)가 포크를 결심한 이유는 크게 두 가지로 나뉘어요.

첫 번째는 기술적 방향성의 차이예요. httpx는 encode 팀이 관리하는데, 이 팀은 starlette, uvicorn 같은 프로젝트도 함께 만들어요. 이런 멀티 프로젝트 구조에서는 각 라이브러리가 서로의 방향성에 영향을 받게 되거든요. Michiel이 보기에 httpx에 필요한 몇몇 변경사항들이 다른 프로젝트와의 호환성 때문에 계속 미뤄지거나 거부되는 상황이었어요.

구체적으로 언급된 이슈들을 보면, 타임아웃 처리 방식, 리다이렉트 동작, 커넥션 풀링(여러 요청을 보낼 때 연결을 재사용하는 방식) 같은 부분에서 버그 리포트나 개선 PR이 오랫동안 반영되지 않았다는 거예요. 오픈소스에서 이런 상황이 쌓이면 사용자 입장에서는 꽤 답답하거든요.

두 번째는 오픈소스 거버넌스 문제예요. 거버넌스라는 게 좀 어려운 말 같지만, 쉽게 말하면 "이 프로젝트의 방향을 누가 어떻게 결정하느냐"에 대한 이야기예요. httpx에서는 외부 기여자(contributor)의 의견이 충분히 반영되지 않는다는 불만이 있었어요. PR을 올려도 리뷰가 느리거나, 피드백 없이 닫히는 경우가 있었던 거죠.

이건 비단 httpx만의 문제가 아니에요. 오픈소스 생태계에서 반복적으로 나타나는 패턴이거든요. 메인테이너는 시간이 부족하고, 기여자는 자신의 PR이 무시당한다고 느끼고, 결국 포크로 이어지는 거예요.

httpxyz는 뭐가 다른가

httpxyz는 httpx의 코드베이스를 가져오되, 몇 가지 핵심적인 변경을 적용했어요.

우선 그동안 httpx에서 머지되지 않았던 커뮤니티 PR들을 적극적으로 반영했어요. 오래된 버그 픽스부터 성능 개선까지, "왜 안 머지됐지?" 싶은 것들을 모아서 가져온 거예요. 또한 API 설계에서도 일부 변경이 있어요. 기존 httpx에서 호환성 때문에 유지하던 레거시 동작들을 정리하고, 더 직관적인 기본값(defaults)을 채택했다고 해요.

프로젝트 거버넌스도 다르게 가져가려 하고 있어요. 더 열린 기여 정책, 빠른 리뷰 사이클을 목표로 하고 있는데, 물론 이건 프로젝트가 커지면서 어떻게 유지될지 두고 봐야 해요.

업계 맥락: 파이썬 HTTP 클라이언트의 지형도

파이썬에서 HTTP 요청을 보내는 라이브러리의 계보를 보면 재미있어요. urllib이 표준 라이브러리로 있지만 쓰기가 불편해서, requests가 나와서 사실상 표준이 됐죠. 그런데 requests는 동기(sync) 전용이고 HTTP/2를 지원하지 않아요. 이 빈자리를 httpx가 채운 거예요.

비동기 HTTP 클라이언트로는 aiohttp도 있는데, API 디자인이 requests 스타일과 많이 달라서 러닝커브가 있어요. httpx의 매력은 requests를 써본 사람이라면 거의 그대로 쓸 수 있다는 점이었거든요.

이런 상황에서 httpxyz의 등장은 생태계 분열이라기보다는, 오픈소스의 자연스러운 진화 과정으로 볼 수 있어요. 리눅스 역사에서도 비슷한 사례가 수없이 있었잖아요. 프로젝트의 방향에 동의하지 않으면 포크하는 게 오픈소스의 기본 원리니까요.

다만 포크가 성공하려면 단순히 코드를 가져가는 것만으로는 부족하고, 지속적인 메인테넌스와 커뮤니티 빌딩이 핵심이에요. io.js가 Node.js에서 포크됐다가 다시 합쳐진 사례처럼, 때로는 포크가 원본 프로젝트를 자극해서 오히려 더 나은 방향으로 이끄는 역할을 하기도 해요.

한국 개발자에게 주는 시사점

이 이야기에서 가져갈 수 있는 포인트는 크게 두 가지예요.

첫째, 의존성 관리에 대한 경각심이에요. 프로젝트에서 httpx를 쓰고 있다면 당장 httpxyz로 갈아탈 필요는 없지만, 내가 쓰는 라이브러리의 유지보수 상태를 주기적으로 체크하는 습관이 중요해요. GitHub Issues 탭을 보면 응답이 얼마나 빠른지, PR이 얼마나 활발하게 머지되는지 대략 감이 오거든요.

둘째, 오픈소스 기여에 대한 시각이에요. 한국 개발자들 중에 오픈소스에 기여하고 싶은데 어디서부터 시작할지 모르겠다는 분들이 많잖아요. 이번 사례처럼 기존 프로젝트에서 오래 방치된 이슈나 PR을 찾아보는 것도 좋은 시작점이에요. 그리고 기여가 받아들여지지 않을 때 "포크"라는 선택지도 있다는 걸 기억해두면 좋아요.