터미널에서 가장 익숙한 명령 몇 개를 꼽으라면 `curl`은 거의 빠지지 않는다. 그래서 이 프로젝트를 오래된 다운로드 유틸리티 정도로 축소해 기억하기 쉽다. 하지만 저장소 문서를 따라가 보면, curl의 정체성은 훨씬 넓고 무겁다. README는 curl을 URL을 사용해 서버와 데이터를 주고받는 command-line tool이라고 소개한다. 이 한 문장은 맞지만, 전부는 아니다.
README가 곧바로 보여 주는 것은 프로토콜의 폭이다. DICT, FILE, FTP와 FTPS, HTTP와 HTTPS, IMAP과 LDAP, MQTT, POP3, RTSP, SCP와 SFTP, SMB, SMTP, TELNET, TFTP, WS와 WSS까지 긴 목록이 이어진다. 이 나열이 중요한 이유는, curl이 특정 프로토콜 하나를 깊게 파는 도구가 아니라 서로 다른 네트워크 규약을 하나의 사용 경험으로 묶어 온 프로젝트라는 점을 말해 주기 때문이다. 게다가 같은 문서에서 libcurl도 함께 소개한다. 즉, 사용자는 CLI로 만나고 개발자는 라이브러리로 만나는 구조다. 명령어와 SDK가 같은 엔진을 공유한다는 뜻이다.
프로젝트의 성격은 `docs/INTERNALS.md`에서 더 선명해진다. 여기에는 C89 컴파일러, 32비트 이상 머신, 그리고 POSIX가 필수는 아닌 환경까지 고려한다는 설명이 적혀 있다. 요즘 기준으로 보면 보수적으로 보일 수 있지만, 바로 그 보수성이 curl의 범위를 만든다. 여기에 공개 심볼은 `curl_`, 여러 파일에서 쓰는 내부 심볼은 `Curl_`, 한 파일에서만 쓰는 심볼은 `static`이어야 한다는 규칙도 나온다. 설계의 미학이라기보다, 거대한 호환성 표면을 오래 관리하기 위한 규율에 가깝다. 의존성 목록 역시 비슷하다. brotli, c-ares, GnuTLS, libidn2, libssh 계열, mbedTLS, MIT Kerberos, nghttp2, OpenLDAP, OpenSSL, wolfSSL, zlib, zstd, Windows Vista까지 문서에 남아 있다. 최신 조합만 챙기면 끝나는 저장소가 아니라는 사실이 단번에 보인다.
`docs/HTTP3.md`는 이 프로젝트가 새 기술을 다루는 방식까지 보여 준다. curl은 HTTP/3와 QUIC을 위해 ngtcp2와 quiche 같은 백엔드를 다루지만, quiche는 문서에서 명시적으로 experimental 상태다. 반면 ngtcp2 기반은 그 라벨에서 빠져 있다. 더 나아가 OpenSSL 3.5.0 이상에는 ngtcp2 1.12.0 이상이 필요하다는 식의 조합 조건도 적어 둔다. 이것은 기능 지원 여부만 말하는 문서가 아니다. 어떤 조합을 신뢰할 수 있는지, 무엇을 아직 실험으로 남겨 둘지, 어디서부터 사용자가 주의를 기울여야 하는지를 정리한 운영 문서에 가깝다.
그래서 curl을 다시 읽을 때 가장 인상적인 대목은 화려한 새 기능이 아니다. 오히려 오래된 환경과 다양한 라이브러리, 복수의 TLS 스택, 공개와 비공개 심볼 경계, 그리고 실험 기능의 상태 표시를 꾸준히 관리해 온 시간이 더 중요하게 보인다. curl은 인터넷 전송을 위한 범용 도구이면서, 동시에 긴 수명의 호환성 레이어를 유지하는 프로젝트다. 매일 치는 한 줄이 익숙할수록, 그 뒤의 유지보수 설계는 더 과소평가되기 쉽다.