Reports
curl은 인터넷에서 데이터를 주고받는 일을 담당하는 명령행 도구이자 라이브러리다. 휴대전화와 자동차, 게임기, 텔레비전, 서버에 두루 실려 있고, 수십억 대의 기기에서 돌아간다. 그 기반 소프트웨어의 보안 접수 창구가 2026년 7월 한 달 동안 닫혔다.
취약점 신고를 중개하는 상업 플랫폼 HackerOne에 걸어 둔 curl의 제출 양식은 7월 1일 0시에 잠겼고 8월 3일 오전 9시에 다시 열렸다. 보안 전용 메일 주소도 같은 기간 응답하지 않았다. 스텐베리는 이 5주에 "curl summer of bliss"라는 이름을 붙이고, 다른 오픈소스 관리자들에게도 같은 휴가를 권했다. 몇몇 프로젝트가 같은 시기에 뒤를 따랐다.
8월 3일에 나온 결산은 짧다. 결과는 괜찮았고, 오랜만에 내린 최선의 결정이었다. 유료 지원 계약을 맺은 고객은 기간 중에도 평소와 같은 응대를 받았다. 걱정한 나머지 새로 계약을 맺은 상용 사용자는 한 곳도 없었다. 개인 메일로 들어온 보고 한 건은 그냥 읽지 않았다고 적혀 있다. 그사이 관리자들은 밀려 있던 기능 제안을 검토하고, 손대지 못하던 영역의 코드를 다시 만졌다.
세계 인터넷 인프라의 한 축이 한 달간 보안 접수를 멈춰도 아무 일이 없었다는 사실은, 그 창구를 막고 있던 것의 정체를 다시 묻게 만든다. 지난 2년 동안 오픈소스 커뮤니티가 벌인 논쟁의 제목은 "AI가 만든 코드를 받을 것인가"였다. 2026년 8월 현재 그 논쟁의 무게중심은 다른 곳으로 옮겨갔다. 검사의 대상이 코드의 출처에서 제출자의 서명으로 이동했고, 그다음 쟁점으로 남은 것은 유지보수자의 검토 시간을 어떻게 배분하느냐다.
금지의 시대는 2024년에 시작됐다. 유닉스 계열 운영체제 NetBSD는 커밋 지침에 AI 생성 코드를 오염된 것으로 추정한다는 조항을 넣었고, 리눅스 배포판 Gentoo의 의사결정 기구인 평의회는 AI 도구의 도움으로 만든 기여물을 받지 않기로 의결했다. 하드웨어를 흉내 내어 다른 운영체제를 돌리는 에뮬레이터 QEMU도 같은 길을 택했다. QEMU의 공식 문서에 지금도 남아 있는 문면은 이렇다.
DECLINE any contributions which are believed to include or derive from AI generated content
AI가 생성한 내용을 포함하거나 그로부터 파생되었다고 여겨지는 기여는 모두 거절한다
QEMU 개발자 문서, Code provenance
이 조항들이 내세운 근거는 법이었다. 오픈소스 프로젝트 대부분은 개발자 원산지 증명(Developer Certificate of Origin, DCO)이라는 절차를 쓴다. 기여자가 커밋 기록에 Signed-off-by라는 한 줄을 붙여, 이 코드를 해당 라이선스로 제출할 법적 권리가 자신에게 있다고 확인하는 방식이다. 큰 언어 모델(Large Language Model, LLM)이 뱉어낸 코드에는 그 확인이 흔들린다. 학습 데이터에 라이선스가 서로 다른 코드가 섞여 있고, 모델이 학습한 문자열을 일부 그대로 재생산하는 사례도 보고되었기 때문이다. QEMU 문서가 지목한 것도 저작권과 라이선스의 미해결 상태였다.
2026년 봄에는 금지가 배포 창구로 번졌다. 리눅스 앱 배포소 Flathub는 5월 29일 방침을 다시 써서, 애플리케이션 코드뿐 아니라 빌드 스크립트, 메타데이터, 심지어 제출용 풀 리퀘스트 본문까지 AI로 만들지 못하게 했다. 위반 제출물은 검토 없이 거절되고, 반복되면 영구 차단이다. 같은 날 GNOME 데스크톱의 외곽 앱 심사 기구인 GNOME Circle도 GNOME 셸 확장에 적용하던 AI 방침을 그대로 가져오면서, 밀린 심사를 정리할 때까지 신규 접수를 아예 중단했다.
이 규범들은 두 가지를 조용히 전제한다. 첫째, AI가 만든 기여물은 품질이 낮다. 둘째, 도구를 쓴 흔적은 심사자가 알아볼 수 있다. 2026년에 벌어진 일은 이 두 전제를 차례로 흔들었다.
Flathub의 조항에는 예외가 딸려 있다. "성숙하고 잘 관리되는 프로젝트"에는 예외를 줄 수 있다는 문장이다. 소급 적용도 하지 않아서, 이미 올라가 있는 앱은 AI로 만들었든 아니든 그대로 남는다. 규정을 문면 그대로 읽으면 금지 대상은 도구다. 예외 조항을 함께 읽으면 실제 심사 대상은 제출자의 신용이 된다. 이름이 알려진 팀이 오래 관리해 온 프로젝트라면 도구를 물을 이유가 줄고, 처음 보는 계정이 던진 앱이라면 도구가 문제 삼기 좋은 구실이 되는 구조다.
집행 범위에도 구멍이 있다. Flathub는 소스를 공개하지 않는 상용 앱도 유통한다. 심사자가 코드를 열어 볼 수 없는 쪽에는 이 규정이 작동하지 않는다. Tuba를 비롯한 여러 리눅스 앱을 만든 개발자 에방겔로스 파테라키스는 이 점을 짚으며, 결과적으로 자기 코드를 공개한 사람만 처벌받는다고 적었다. 그는 LLM에 비판적인 쪽이면서도 이 금지가 과하다고 보고, 언젠가 철회되리라 내다보며 자진 공개 태그 쪽을 지지한다.
같은 파테라키스가 금지를 옹호하는 데 가장 많이 인용되는 수치를 내놓았다는 점은 이 논쟁의 결이 단순하지 않음을 보여 준다. Flathub 심사자들은 2026년 1월부터 수상한 제출물에 "AI Slop"이라는 꼬리표를 붙여 왔고, 파테라키스는 그렇게 표시된 저장소 120개를 골라 1월부터 6월까지 추적했다. 88개가 활동을 멈췄고 일부는 저장소째 사라졌다. 살아 있는 것은 32개, 유지 비율로는 27%다.
이 숫자를 인용할 때 함께 옮겨야 할 단서가 있다. 대조군이 없다. 꼬리표가 붙지 않은 나머지 제출물의 방치율을 재지 않았으므로, 73%라는 값이 일반적인 취미 프로젝트의 소멸률과 얼마나 다른지 알 수 없다. 파테라키스 본인이 이 조사가 엄밀하지 않다고 밝혔고, 커밋 빈도만으로 유지 여부를 판정하기 어렵다는 점도 적어 두었다. 이 수치가 확실하게 재는 것은 하나다. 소수의 자원봉사 심사진이 붙들고 씨름한 대상 가운데 다수가 몇 달 뒤 아무도 돌보지 않는 물건이 되었다는 사실, 곧 낭비된 검토 시간의 규모다.
같은 시기 curl에서는 정반대 방향의 일이 벌어졌다. 순서대로 놓으면 이렇다.
4월의 정리에 담긴 내용은 금지 규범의 첫 번째 전제를 정면으로 깬다. 슬롭은 더 이상 문제 축에 들지 않는다. 확인된 취약점의 비율은 15~16%로 회복해 2024년 이전 수준을 넘어섰다. 취약점까지는 아니어도 실제 결함을 짚어내는 보고의 비중도 예전보다 크게 늘었다. 그러면서 거의 모든 보고가 어떤 형태로든 AI를 쓴다. 문장의 짜임새로 알아볼 수 있고, 사람 손으로는 나오기 힘든 수준으로 세밀하게 겹치는 중복 보고가 나오는 것으로도 알 수 있다. 어느 모델을 썼는지 밝히는 보고자는 드물고, curl 쪽도 그것을 궁금해하지 않는다.
여기서 자주 인용되는 15%라는 값의 성격을 짚어 둘 필요가 있다. 그것은 비율이고, 비율은 신뢰도를 잴 뿐 노동량을 재지 않는다. 같은 기간 제출 빈도는 2025년의 약 2배가 되었고, 2025년 자체가 그 이전의 2배를 넘던 해였다. 분자와 분모가 함께 커졌다. 확인율 5%의 슬롭 시대보다 지금 유지보수자가 읽고 재현하고 판정해야 할 총량이 많다. 확인된 취약점은 읽고 닫는 것으로 끝나지 않고 고치고 배포하고 공표하는 뒷일을 부른다. 스텐베리는 2026년 한 해 curl이 공표할 취약점이 50건에 육박할 수 있다고 내다봤다.
이 현상은 curl에 국한되지 않는다. 스텐베리가 마스토돈에서 돌린 즉석 질문에 Apache httpd, BIND, Django, Firefox, git, glibc, 파이썬, Wireshark, 리눅스 커널 등이 같은 흐름을 확인했다. 커널 쪽 수치는 더 선명하다. HAProxy를 만들고 커널 안정판을 오래 관리해 온 윌리 타로에 따르면, 2년 전 주 2~3건이던 커널 보안 메일링 리스트의 접수량이 2026년 3월에는 하루 5~10건이 되었다. 리누스 토르발스는 5월 17일 리눅스 7.1-rc4 공지에서 비공개 보안 목록이 거의 관리 불가능한 상태라고 적었다. 원인으로 지목한 것은 중복이다. 여러 사람이 같은 도구로 같은 코드를 훑어 같은 결함을 찾아내고, 서로의 제출물을 볼 수 없는 비공개 채널에 각자 집어넣는다. 관리자는 이미 몇 주 전에 고친 문제라고 답장하는 일로 시간을 쓴다.
금지 규범이 겨눈 표적은 이렇게 사라졌다. 도구의 흔적을 오염으로 규정하는 조항은 그 흔적이 곧 저품질이라는 등식 위에 서 있었는데, 등식이 성립하지 않는다. 남은 압박은 물량이고, 물량은 도구를 금지해서 줄어들지 않는다. 밖에서 도구를 쥔 사람의 수가 줄지 않기 때문이다.
2026년 4월, 리눅스 커널이 AI 코딩 도우미에 관한 공식 문서를 본류에 병합했다. 2025년 관리자 회의에서 모인 합의를 문서로 굳힌 것으로, 규칙은 간명하다. AI 도구를 써도 좋다. 대신 결과물은 커널 라이선스와 기존 기여 절차를 그대로 지켜야 하고, 도구가 관여했다면 커밋 기록에 Assisted-by: 에이전트명:모델버전 형식의 한 줄을 붙인다. 그리고 한 가지가 금지된다.
AI agents MUST NOT add Signed-off-by tags.
AI 에이전트는 Signed-off-by 태그를 붙여서는 안 된다.
리눅스 커널 문서, AI Coding Assistants
법적 확인은 사람만 할 수 있으므로, 제출한 사람이 AI가 만든 코드를 검토하고 라이선스 적합성을 확인한 뒤 자기 이름으로 서명한다. 태그의 형태를 정하는 데도 논쟁이 있었다. 사샤 레빈이 처음 내놓은 안은 Co-developed-by였는데, 이 태그는 짝이 되는 서명을 함께 요구하는 규칙과 묶여 있어 AI에게 서명을 허용하지 않는 방침과 충돌했다. 논의를 거쳐 Assisted-by로 정리됐다. "공동 개발"에서 "보조"로 낱말을 바꾼 선택에는 AI를 저자로 보지 않겠다는 입장이 담겼다. 2026년 3월에는 레빈이 패치 검사 스크립트도 이 태그를 인식하도록 고쳤다.
같은 골격이 여러 곳에서 나온다. Fedora 평의회가 2025년 10월에 승인한 방침은 기여자가 언제나 저자이며 기여물 전체에 전적으로 책임진다고 못 박고, 도구가 만든 상당 부분을 손대지 않고 가져올 때는 공개를 의무로 둔다. 맞춤법 교정 수준의 도움은 공개 대상에서 뺐고, AI를 기여 심사의 최종 판정자로 쓰는 것은 금지했다. 컴파일러 기반 프로젝트 LLVM의 방침도 도구를 묻지 않는다. 무엇을 쓰든 좋되 사람이 고리 안에 있어야 하고, 리뷰를 요청하기 전에 생성물을 스스로 읽고 검토해야 하며, 심사 중에 질문을 받으면 답할 수 있어야 한다. 처음 기여하는 사람에게는 자기가 완전히 이해할 수 있는 작은 변경부터 시작하라고 권한다. 심사자의 지적을 그대로 모델에 넘겨 다시 받아 오는 방식으로는 누구도 성장하지 않는다는 이유에서다.
합의가 갈리는 지점은 라벨이다. QEMU의 완화안이 그 사례다. 레드햇의 가상화 담당 파올로 본치니가 2026년 5월 28일 메일링 리스트에 올린 패치는 기계적 변경, 테스트, 문서, 20줄 이하의 소규모 수정에 한해 AI 사용을 허용하자고 제안한다. 그러면서 Assisted-by나 Generated-by 같은 트레일러를 쓰지 않으며 어떤 모델을 썼는지 적을 필요도 없다고 명시했다. 즉 책임은 강화하되 라벨은 붙이지 않는 조합이다. 도구가 좋아질수록 전면 금지를 정당화하기 어려워졌다는 것이 본치니가 든 이유이고, 저작권 문제가 풀린 것이 아니라 위험의 균형이 옮겨간 것이라고 덧붙였다.
| 프로젝트 | AI 기여 | 공개 의무 | 책임 소재 |
|---|---|---|---|
| 리눅스 커널 | 허용 | Assisted-by 태그 | 제출자가 서명하고 책임진다 |
| Fedora | 허용 | 그대로 가져오면 의무 | 기여자가 언제나 저자다 |
| LLVM | 허용 | 분량이 많으면 표시 | 사람이 고리 안에 있어야 한다 |
| QEMU (현행) | 거절 | 해당 없음 | DCO 서명자 |
| QEMU (완화안) | 일부 허용 | 태그를 쓰지 않는다 | DCO 서명자 |
| Flathub | 금지 | 해당 없음 | 제출자, 위반 시 영구 차단 |
| GNOME Circle | 금지 | 해당 없음 | 코드를 설명할 수 있어야 한다 |
이 갈림의 폭을 재 본 조사가 있다. 안드레 오라와 로맹 로브가 2026년 5월에 공개한 연구(arXiv:2605.16706)는 GitHub의 인기 저장소 1,000개를 훑어 그중 118개에서 기여자용 AI 방침을 찾아냈다. 별 수를 기준으로 고른 활성 저장소들로, 중앙값이 별 4만 개, 커밋 9,500건, 기여자 373명이다. 결과는 세 갈래다. 78%가 AI 기여를 허용하고 22%가 명시적으로 권하지 않는다. 공개를 요구하는 곳은 51%다. 사람의 개입을 요구하는 곳은 74%다.
공개 의무 51%와 인간 개입 요구 74% 사이의 23%포인트 차이가 이 논쟁의 현재 위치를 보여 준다. "무엇으로 썼는지 밝혀라"에는 절반이 동의하고, "네가 읽고 이해했고 네가 책임진다"에는 넷 중 셋이 동의한다.
같은 조사는 공개 조항의 문면이 헐겁다는 점도 지적한다. "상당한", "의미 있는", "significant" 같은 낱말로 기준선을 흐려 놓아, 언제 밝혀야 하는지가 기여자에게 분명하지 않다.
고지를 요구하는 규범에는 잘 알려진 부작용이 있다. Node.js에서 벌어진 일이 그 표본이다. Node.js는 서버에서 자바스크립트를 돌리는 실행 환경으로, 수많은 웹 서비스의 바닥에 깔려 있다.
2026년 1월, 기술운영위원회 위원이자 Fastify 프레임워크의 관리자인 마테오 콜리나가 가상 파일시스템 기능을 추가하는 풀 리퀘스트를 올렸다. 파일을 디스크가 아니라 메모리에 두고 실제 파일처럼 다루게 하는 기능으로, 테스트 속도, 단일 실행 파일 패키징, AI 에이전트 격리 같은 오랜 숙제를 겨냥한 제안이었다. 분량은 약 19,000줄이었다. 콜리나는 설명란에 Claude Code 토큰을 상당량 썼고 변경 사항은 전부 자기가 검토했다고 적었다.
그 한 문장이 도화선이 됐다. Node.js의 TLS 모듈을 만든 표도르 인두트니가 AI 코드를 코어에서 금지하자는 청원을 열었고 여러 개발자가 이름을 올렸다. 청원문이 든 근거는 여러 갈래다. DCO 적합성, 학습 데이터의 출처, 심사자가 기계 생성물을 검증할 수 있는가, 심사 과정이 기여자를 길러 내는 기능을 잃는다는 점, 그리고 유료 구독이 있어야 결과를 재현할 수 있다는 점까지. 그사이 이 풀 리퀘스트에는 리뷰와 의견이 길게 쌓였고 통상적인 심사 절차가 멎다시피 했다. OpenJS 재단은 사람이 책임지는 한 AI 지원 기여가 DCO에 어긋나지 않는다는 견해를 정리했다.
주목할 것은 이 사태의 출발점이다. 콜리나가 도구 사용을 적지 않았다면 청원도 없었다. 시비의 근거가 그 한 문장이었기 때문이다. 규범이 고지를 문제 제기의 조건으로 만들면 고지가 줄어든다. 청원 저장소의 이름이 no-ai-in-nodejs-core에서 no-slop-in-nodejs-core로 바뀐 것은 이 논쟁이 스스로 표적을 옮긴 흔적이다. 처음 겨눈 것은 도구였고, 나중에 남은 것은 검토되지 않은 채 떠넘겨진 물량이었다.
LLVM의 방침에는 다른 문서에 없는 개념이 하나 들어 있다. "추출적 기여(extractive contribution)"다. 나디아 에그발이 오픈소스 유지보수의 경제를 다룬 책 『Working in Public』에서 가져온 말로, 검토하고 병합하는 데 드는 비용이 프로젝트가 얻는 이득보다 큰 기여를 가리킨다. 관리자의 주의력을 순손실로 끌어가는 제출물이라는 뜻이다. LLVM은 이것을 황금률로 정리했다. 기여는 그것을 검토하는 데 드는 시간보다 프로젝트에 더 값져야 한다.
이 규칙이 겨누는 것은 거래 조건이다. 방침 문서는 그 이유를 이렇게 설명한다. LLM이 등장하기 전에는 심사 요청 자체가 장기 기여자가 될 만한 사람의 관심을 뜻했기 때문에 관리자들이 웬만한 변경은 모두 봐 주었다. 도구는 개발자 쪽의 노력을 줄이면서 심사자 쪽의 노력을 그대로 두거나 오히려 늘린다. 제출자가 모든 줄을 따져 보았으리라고 심사자가 더는 가정할 수 없기 때문이다. 그래서 LLVM은 기준에 못 미치는 제출물에 extractive라는 꼬리표를 붙이고, 붙여 넣을 정형 답변까지 문서에 실어 두었다. 이 방침에서 명시적으로 금지된 것은 사람의 승인 없이 행동하는 에이전트, 그리고 초심자용으로 표시된 이슈를 AI로 처리하는 일이다. 후자는 학습 기회를 지키려는 조항이다.
같은 판단이 다른 프로젝트에서는 다른 손잡이로 나타난다. OpenJS 재단이 정리한 2026년 2분기 보고에 따르면 Node.js는 봄에 AI 지원 기여 지침을 확정했고, 실질적 결과는 두 가지다. 풀 리퀘스트를 5,000줄 이하로 유지하도록 하고, DCO 서명을 더 엄격히 집행한다. 어느 쪽도 도구를 묻지 않는다. 심사 가능한 덩어리의 크기를 제한할 뿐이다. AI가 만들었든 사람이 썼든 50,000줄짜리 변경은 실무적으로 심사할 수 없다는 판단이 그 배경이다.
커널은 접수 경로 자체를 다시 그렸다. 7.1과 함께 들어간 문서에서 타로가 정한 원칙은 하나다. AI 도구로 찾아낸 취약점은 이미 공개된 것으로 취급한다. 흔한 도구로 재현되는 발견을 비공개 채널에서 비밀처럼 다루면 중복만 쌓인다. 그래서 그런 보고는 비공개 보안 목록이 아니라 해당 영역 관리자에게 직접, 평문으로, 재현 절차를 붙여 간결하게 보내라고 정했다. 토르발스가 여기에 덧붙인 요구는 한 걸음 더 나간다. 도구가 뱉은 결과만 던지지 말고 문서를 읽고 패치까지 만들어 오라고 했다.
Node.js 보안 워킹그룹에서도 같은 논리의 제안이 논의 중이다. 보안 담당 관리자 하파에우 곤자가가 2026년 2월에 올린 안건으로, 흔한 도구로 재현되는 발견을 비밀로 취급하는 것은 안전에 대한 착각을 준다는 취지다. 7월 9일 회의 안건에 다시 올랐고, HackerOne 접수분을 사람이 보기 전에 자동으로 재현·분류하는 방안도 함께 검토되었다. 정책 변경은 아직 발표되지 않았다.
본치니는 레드햇 소속이다. 그의 완화 제안은 기업 법무가 감당하기로 한 위험 계산을 반영하며, 커뮤니티 프로젝트에는 그런 자원이 없어 근거 없는 분쟁조차 오래 끄는 방해가 된다는 점을 제안문에 스스로 적어 두었다. Flathub의 바르트 피오트로프스키는 3명 남짓인 자원 심사진의 한 사람이고, 그가 금지를 선언하며 든 것은 소진이었다. 거절당한 제출자들과의 불쾌한 실랑이가 지난 한 달 급증했고 지쳤다는 말이다.
스텐베리의 휴가에는 유료 지원 계약 고객이라는 예외가 있었다. 지킬 자원과 물러설 여지가 저마다 다르므로, 같은 현상을 두고 금지·완화·휴지라는 서로 다른 답이 나온다. 판단의 차이보다 처지의 차이에 가깝다.
방향을 놓고 보면 금지 조항은 물러서는 쪽에 있다. QEMU의 공식 문서는 2026년 8월 중순 현재 여전히 거절 문면을 유지하지만, 완화안이 병합되면 2024년부터 쌓인 전면 금지 조항의 대표 사례 하나가 사라진다. 이 관측이 뒤집히려면 완화안이 철회된 채 금지가 유지되거나, Flathub가 "성숙한 프로젝트" 예외를 없애고 소급 적용으로 범위를 넓히는 일이 있어야 한다. 접수 경로 쪽에서는 비공개 보안 채널을 줄이고 공개 접수로 옮기는 실험이 커널과 Node.js 양쪽에서 진행 중이다. 이쪽이 뒤집히려면 두 프로젝트 가운데 하나가 공개 전환을 접고 비공개 채널로 되돌아가야 한다. 어느 쪽이든 몇 달 안에 문서와 회의록으로 확인된다.
2024년의 규범은 코드의 출처를 검사했다. AI의 흔적을 오염으로 보고 문 앞에서 돌려보내는 방식이었고, 그 방식은 두 전제 위에 서 있었다. AI가 만든 것은 품질이 낮다는 전제, 그리고 그 흔적을 알아볼 수 있다는 전제다. 2026년에 두 전제가 모두 무너졌다. curl의 확인 취약점 비율은 5% 아래에서 15~16%로 돌아왔고, 거의 모든 보고가 AI를 쓴다. 소스를 공개하지 않는 앱에는 금지가 닿지 않고, 성숙한 프로젝트에는 예외가 열린다. 실제로 걸러지는 것은 신용 없는 제출자다.
그 자리에 들어선 것이 서명이다. 커널은 AI에게 법적 확인을 맡기지 않고 제출한 사람에게 전부 지웠으며, Fedora는 기여자를 언제나 저자로 규정했고, LLVM은 질문에 답할 수 있는 사람을 요구한다. 1,000개 저장소를 훑은 조사에서 사람의 개입을 요구하는 방침이 74%로 공개 의무 51%보다 넓게 퍼져 있다는 사실이 이 이동을 수치로 보여 준다. 라벨은 아직 합의가 아니고, 책임은 합의에 가깝다. QEMU의 완화안이 책임은 유지한 채 트레일러를 거부한 것도 같은 지형에서 나온 선택이다.
그리고 서명 다음에 남은 문제는 분배다. curl이 한 달을 쉬고, Node.js가 5,000줄 상한을 걸고, 커널이 AI로 찾은 취약점을 비공개 채널에서 빼내고, LLVM이 추출적 기여라는 이름을 붙여 심사자에게 거절할 근거를 쥐여 준 것은 모두 하나를 겨눈 조치다. 도구를 쥔 사람은 늘어나는데 읽을 수 있는 사람은 늘지 않는다. 코드를 만드는 비용은 거의 사라졌고 그것을 이해하고 책임지는 비용은 그대로 남았다. 지금 오픈소스가 배분하려 애쓰는 자원은 유지보수자의 주의력이다.
이 배분에는 아직 답이 없는 물음이 붙어 있다. 접수량 상한과 휴지기, 신용 기반 선별은 모두 들어오는 양을 줄이는 방식이고, 그 부담은 이름 없는 신규 기여자에게 먼저 간다. 오픈소스가 30년 동안 새 관리자를 길러 온 통로가 바로 그 입구였다. 심사 비용을 방어하는 조치와 다음 세대를 들이는 통로가 같은 문을 쓰는 이상, 문을 좁히는 결정은 언제나 두 가지를 동시에 한다. curl의 여름 휴가가 별일 없이 끝난 것은 그 문을 한 달 닫아도 무너지지 않는다는 사실을 보여 주었을 뿐, 계속 닫아 두어도 되는지에 대해서는 아무것도 말해 주지 않는다.