버그 바운티*는 오픈소스 생태계에서 “가장 설명하기 쉬운 약속” 중 하나입니다. 취약점을 찾으면 보상한다는 약속은, 전 세계의 기여자들이 같은 코드베이스를 바라보게 만들고 “더 많은 눈이 모이면 더 안전해진다”는 집단 방어의 기대와 맞물립니다. 그래서 cURL*처럼 의존성이 크고 사용자 기반이 넓은 프로젝트일수록 버그 바운티는 지속 가능성을 뒷받침하는 ‘기본 장치’처럼 보이곤 합니다.

*버그 바운티: 화이트햇 해커가 기업·기관의 서비스 및 제품에서 보안 취약점을 발견해 제보하면 포상금을 지급하는 제도

*cURL(Client URL): HTTP, HTTPS, FTP 등 다양한 프로토콜을 사용하여 서버와 데이터를 주고받는 명령줄 도구 및 라이브러리

<출처: Overrun with AI slop, cURL scraps bug bounties to ensure “intact mental health”, arstechnica>

그런데 2026년 1월, cURL은 그 정답지 같은 선택을 접었습니다. “버그 바운티를 끝낸다”는 공지만으로도 충격인데, 공지에 담긴 문장들은 더 노골적이었습니다. AI 슬롭*이 늘었고, 그 결과 유지보수자의 부담이 감당하기 어려운 수준이 됐다고 말합니다. 심지어 AI 슬롭 제보자에 대한 강경한 대응 방침까지 공식 글에 적었습니다. 보안 사건 하나를 처리하는 공지라기보다, 운영 체계가 한계에 닿았다는 경고에 가깝습니다. (이 글에서 말하는 AI 슬롭은 문장과 형식은 그럴듯하지만, 재현과 증거가 빈약해 검증이 불가능한 생성형 보고서를 뜻합니다.)

*AI 슬롭(AI Slop): 생성형 인공지능 기술을 사용하여 양산되는 글과 그림 등 저품질 컨텐츠를 경멸적인 용도로 사용되는 단어

AI는 이 현상을 더 빨리 드러내는 촉매가 됐습니다. 작성이 쉬워질수록 제출물은 늘어나지만, 검토에 필요한 정보가 자동으로 채워지지는 않습니다. 재현이 없고, 영향 범위가 없고, 테스트가 없고, 실패 시 대응이 없으면 그 빈칸을 누군가는 메워야 합니다. 보통 그 역할은 오픈소스를 운영하는 이들에게 돌아옵니다.

이번 글에서는 이와 관련해 세 가지를 정리해 봤습니다.

첫째, AI 슬롭이 늘어날수록 오픈소스 운영의 병목이 코드 품질이 아니라 ‘검토 예산’과 ‘승인 책임’에서 먼저 터지는 이유를 구조로 설명합니다.
둘째, cURL의 버그 바운티 종료를 출발점으로 삼아, 텍스트 양식이 잘 채워져도 검증 가능한 증거가 없으면 검토가 질의응답으로 무너지고 결국 채널과 정책이 재설계되는 과정을 설명합니다.
셋째, 금지나 비난이 아니라 문턱을 세우는 방식으로, 평판과 재현 가능한 증거를 기준으로 검토가 시작되게 만들고 이를 운영 규칙과 자동화로 고정하는 방법을 제안합니다. 마지막으로 기여자가 ‘설명’이 아니라 ‘증거’를 제출해 승인 책임의 불확실성을 줄이는 행동 원칙까지 정리합니다.

1. 버그 바운티가 망가지는 방식: ‘찾는 비용’은 내려가고 ‘검증 비용’은 남는다

제출은 쉬워지고, 검증은 그대로입니다. 이 비대칭이 검토 예산을 잠식합니다

버그 바운티의 전제는 단순합니다. “제보를 늘려 취약점을 빨리 발견한다.” 제보자에게 보상을 약속해 더 많은 제보가 들어오도록 만들고, 그 결과 프로젝트의 보안 수준을 끌어올립니다. 오픈소스 생태계에서 이 구조는 실제로 강력하게 작동해 왔습니다.

그런데 운영 관점에서 버그 바운티에는 함정이 하나 있습니다. 제보를 제출하는 비용은 쉽게 내려갈 수 있는데, 제보를 검증해 결론을 내리는 비용은 잘 내려가지 않습니다. 검증은 사람의 시간을 요구하고, 재현과 확인이 끝나야만 결론이 납니다. 즉, 제보 한 건이 검토 대기열에 들어오는 순간부터 비용은 제출자가 아니라 유지보수자의 검토 예산에서 빠져나갑니다.

최근 몇 년 사이 이 비대칭은 더 커졌습니다. 제보를 만드는 문서 작성 비용이 내려갔고, 그럴듯한 문장과 구조를 갖춘 보고서를 빠르게 만드는 방법도 쉬워졌습니다. 여기서 AI는 원인이 아니라 촉매로 작동합니다. “제보가 그럴듯해 보이게 만드는 비용”을 낮추기 때문입니다. 제목과 표현은 점점 긴박해지는데, 정작 재현과 증거는 비어 있는 제보가 늘어납니다. 그러면 유지보수자는 같은 일을 반복하게 됩니다. 읽고, 확인하고, 반박하고, 다시 읽고, 또 확인합니다. 결론이 나지 않는 제보가 쌓이면, 그 자체로 검토 예산을 갉아먹는 채널이 됩니다.

cURL 공지가 말하는 전환점이 바로 여기입니다. 제보가 늘어서 힘든 것이 아니라, “검토로 결론을 낼 수 없는 제보”가 늘어서 운영이 흔들렸다는 겁니다. 이 상태가 되면 질문은 “제보를 더 받는 방법”이 아니라 “검토를 어떤 조건에서 시작할 것인가”로 바뀝니다. 그리고 다음 선택지는 대체로 둘 중 하나입니다. 채널을 줄이거나, 문턱을 세우거나. cURL은 버그 바운티를 종료하며 채널을 줄이는 결정을 먼저 꺼냈고, 그 판단의 근거를 ‘검토 예산’과 ‘유지보수자의 부담’으로 정리했습니다.

보상, 채널, 문턱을 다시 잡다. cURL이 택한 운영적 해법

cURL의 결정이 흥미로운 이유는 “AI를 금지하자” 같은 선언으로 끝내지 않았기 때문입니다. 메시지는 오히려 운영적입니다. “더 이상 검토 예산을 이 채널에 소비할 수 없으니, 제보가 들어오는 방식 자체를 바꾼다”는 방향입니다.

cURL이 선택한 변화는 크게 세 가지입니다.

첫째, 금전적 보상을 중단했습니다. 심각도와 상관없이 보상 자체를 제공하지 않겠다고 했습니다.
둘째, 제보 채널에서 해커원(HackerOne)을 제거하고, 깃허브(GitHub)의 비공개 취약점 제보 기능(Private vulnerability reporting)으로 안내했습니다.
셋째, AI 슬롭을 제출하는 계정은 즉시 차단하고 공개적으로 지적하겠다는 방침을 명시했습니다.

다니엘 스텐버그는 해커원 버그 바운티로 제출된 보안 취약점 제보 중, AI 슬롭으로 의심되는 사례를 별도 목록(AI slop security reports submitted to curl)으로 공개해 두었습니다. 목록은 실제 제보 링크로 구성돼 있고, “AI 슬롭 제보자는 즉시 차단한다”는 현재 정책도 같은 문서에 함께 적혀 있습니다.

이 변화의 의미는 간단합니다. 그럴듯해 보이지만 검증이 어려운 제보가 몰려드는 상황을 줄이고, “검증 가능한 증거”가 포함된 제보가 들어오도록 문턱과 흐름을 다시 설계한 것입니다. 인력을 늘리기 어렵고 승인 책임은 사라지지 않는다면, ‘사람이 더 열심히’가 아니라 ‘사람이 판단해야 하는 순간을 줄이는 설계’를 선택할 수밖에 없습니다. 버그 바운티를 끝낸 건 “제보가 싫어서”가 아니라 “검토 가능한 제보만 남도록 운영을 재정렬하기 위해서”입니다.

2. 저품질 기여는 왜 병목이 될까: 정보가 없으면 기여가 ‘질의응답’으로 바뀐다

저품질 기여의 공통점은 잘못된 코드가 아니라 ‘정보의 공백’입니다

저품질 기여를 ‘코드가 나쁘다’로만 보면 핵심을 놓칩니다. 검토 예산을 갉아먹는 이유는 코드의 품질이 아니라, 제출물이 ‘검토를 시작할 만큼의 정보’를 담고 있지 않기 때문입니다. 저품질 기여의 핵심은 코드 품질이 아니라 정보의 공백입니다.

이 공백은 대체로 비슷한 모습으로 나타납니다. 재현 절차가 없고, 기대 결과와 실제 결과가 없고, 영향 범위가 비어 있고, 테스트가 없고, 실패 시 대응(롤백 계획, 모니터링 포인트)이 없습니다. 이런 상태의 제출물은 변경 제안이 아니라 “이 상황을 대신 파악해 달라”는 요청에 가깝습니다. 그리고 그 요청을 처리하는 비용은 제출자가 아니라 검토자, 더 정확히는 승인 책임자에게 전가됩니다.

예를 들어, 이슈가 “안 됩니다”로 시작하면 검토자는 질문부터 꺼내야 합니다. 어떤 버전에서 발생하는지, 어떤 환경에서 실행했는지, 어떤 시나리오로 재현되는지. 답을 받으면 다시 재현하고, 재현이 안 되면 다시 질문합니다. 정보가 비어 있을수록 이 왕복은 길어지고, 그 순간부터 기여는 질의응답으로 바뀝니다.

여기서 오해가 자주 생깁니다. 기여자는 “내가 시간을 들여 만들었는데 왜 이렇게 까다롭게 굴지?”라고 느낍니다. 반대로 유지보수자는 “이건 제출물이 아니라 빈칸이다”라고 판단합니다. 이 간극은 태도의 문제가 아니라 운영 비용의 문제입니다. 정보가 비어 있으면 누군가는 그 빈칸을 메워야 하고, 그 비용과 책임은 결국 승인 책임자에게 모입니다.

질의응답의 끝은 ‘승인 책임’입니다. 질문이 쌓일수록 검토는 느려지는 게 아니라 무거워집니다

정보 공백이 병목이 되는 이유는 단순히 “시간이 오래 걸려서”가 아닙니다. 공백이 클수록 승인 책임이 더 무거워지기 때문입니다. 재현과 검증에 필요한 정보가 없으면 검토자는 “아마 이럴 것이다”로 넘어갈 수 없습니다. 승인 이후 문제가 터졌을 때 책임은 그대로 돌아오기 때문입니다.

그래서 제출물의 정보가 빈 상태일수록 검토자는 가정 대신 확인을 택하게 되고, 재현 환경을 만들고 검증 절차를 설계하는 데 더 많은 시간을 써야 합니다. 특히 제보가 보안, 데이터 손상, 서비스 중단처럼 되돌리기 어려운 리스크를 암시할수록, 검토자는 더 보수적으로 움직일 수밖에 없습니다. 결과적으로 정보가 비어 있는 제출물일수록 검토 예산이 더 빨리 소진됩니다.

이 과정이 반복되면 검토 대기열은 길어지고, 응답은 늦어지고, 커뮤니케이션 비용은 늘어납니다. 그 다음부터 오픈소스 프로젝트가 선택할 수 있는 대응은 사실상 제한됩니다. 인력을 쉽게 늘릴 수 없고, 승인 책임도 사라지지 않기 때문입니다. 그래서 프로젝트는 접수 채널을 줄이거나, 기여 문턱을 높이거나, 우선순위를 규칙으로 고정하는 방식으로 움직입니다. 어떤 선택이든 공통점은 하나입니다. 사람의 판단이 필요한 순간을 줄여 승인 책임을 감당 가능한 범위로 되돌리는 방향으로 수습합니다.

결론은 단순합니다. 저품질 기여는 불쾌함의 문제가 아니라 운영의 문제입니다. 기여자가 “코드만 제출”하면, 승인자는 “정보를 채우는 업무”를 떠안게 됩니다. 그래서 해법은 도덕이나 태도가 아니라 설계입니다. 검토가 시작되는 최소 조건을 명확히 명시해야 하고, 그 조건을 양식과 규칙으로 고정해야 합니다. 그래야 기여는 질의응답이 아니라 검토 가능한 제출물로 들어옵니다.

3. 기여는 권리가 아니라 합의다: ‘증거’로 검토를 시작하는 문턱

양식은 기본값이 되었지만, AI 슬롭은 ‘채운 양식’으로 들어옵니다

앞 문단에서 정리한 결론은 분명합니다. 정보가 비어 있으면 기여는 질의응답으로 바뀌고, 그 비용과 책임은 승인 책임자에게 붙습니다. 그래서 많은 오픈소스 프로젝트는 이미 버그 리포트 양식, 이슈 양식, 변경 제안 양식처럼 “필수 입력 칸”을 갖춘 채로 운영합니다. 빈칸 제출을 줄이고, 같은 질문을 반복하지 않기 위한 최소한의 안전장치입니다.

문제는 AI 슬롭이 이 안전장치를 너무 쉽게 통과한다는 점입니다. 양식의 칸은 모두 채워져 있고, 문장도 그럴듯합니다. 그런데 검토자가 결론을 내리기 위해 필요한 핵심, 즉 재현 가능한 증거와 검증 가능한 근거는 비어 있는 경우가 많습니다. 이 순간부터 검토 예산이 소진됩니다. 빈칸이라면 “정보 보완 요청”으로 빠르게 분기할 수 있지만, 그럴듯한 서술은 사람을 붙잡아두고 “혹시 사실일지도 모른다”는 가능성 위에서 시간을 태우게 만들기 때문입니다.

cURL 사례가 정확히 이 함정에 걸렸습니다. 2025년에 들어서며 실제 취약점으로 확인되는 비율이 이전의 15%대에서 5% 아래로 떨어졌고, 슬롭 제보를 반박하는 데 드는 시간과 정신적 비용이 운영을 흔들었다고 공개적으로 적었습니다. 또한 해커원의 평판 시스템과 프로그램 설정만으로는 “모래가 기계로 들어오는 것”을 막기에 충분하지 않았다고 정리합니다. 양식이 존재한다는 사실만으로 검증 부담이 자동으로 줄어들지는 않는다는 뜻입니다.

그래서 여기서 방향이 갈립니다. 양식을 더 촘촘히 만들어 문장을 더 많이 쓰게 하는 쪽이 아니라, 검토를 시작하는 문턱을 “작성 가능한 텍스트”가 아니라 “조작하기 어려운 증거” 쪽으로 옮겨야 합니다. 그리고 그 문턱은 기여자와 유지보수자 사이의 합의로 고정돼야 합니다. 그래야 기여가 다시 질의응답이 아니라, 검토와 판단의 흐름으로 돌아옵니다.

평판과 재현물로 문턱을 세우면, 검토 예산이 ‘판단’에 쓰이기 시작합니다

양식은 누구나 채울 수 있습니다. AI는 더 쉽게 채웁니다. 그래서 문턱은 두 갈래로 세워야 합니다. 누가 제보하느냐를 걸러내는 평판 문턱, 무엇을 제보하느냐를 검증하는 재현물 문턱입니다. 둘 다 목적은 같습니다. 사람이 시간을 쓰기 전에, 검토가 시작될 조건을 먼저 만족시키게 만드는 것입니다.

<출처: New HackerOne Signal Requirement for Vulnerability Reports, node.js>

첫째, 제출자 평판 문턱입니다. Node.js는 해커원 제보에 신호 점수(Signal) 1.0 이상을 요구하는 정책으로 방향을 틀었습니다. 배경 설명이 구체적입니다. 보안 팀이 저품질 제보 증가를 겪어 왔고, 특히 12월 15일부터 1월 15일 사이에 30건이 넘는 제보가 들어오면서 분류와 검증이 실제 보안 업무 시간을 잠식했다고 명시합니다. 그래서 최소한의 평판을 요구해 “유효한 제보를 꾸준히 해온 제출자”를 우선 통과시키고, 문턱 아래의 제출자는 다른 방식으로 보안 팀과 접촉하도록 안내합니다.

이 정책은 ‘제보를 닫는 결정’이라기보다 ‘검토가 시작되는 경로를 재설계한 결정’에 가깝습니다. Node.js는 2026년 2월 19일 업데이트에서 신호 점수가 없는 신규 연구자는 해커원을 통해 더 이상 제보를 제출할 수 없다고 분명히 못 박았습니다. 대신 신규 제보자는 보안 릴리스 담당자에게 슬랙으로 먼저 연락하라고 안내합니다. 운영적으로 보면, 검토 예산이 가장 비싼 경로로 새 제보가 쏟아지는 상황을 막고, 추가 확인이 필요한 제보는 다른 통로에서 먼저 정리되도록 흐름을 바꾼 것입니다. 검토 예산이 제한돼 있을 때는 “누가 어떤 통로로 들어오느냐” 자체가 곧 문턱이 됩니다.

둘째, 재현 가능한 증거 문턱입니다. AI 슬롭을 가장 확실하게 줄이는 방식은 “설명”이 아니라 “재현물”이 제출물의 중심이 되게 만드는 것입니다. 사람들이 일상적으로 쓰는 대형 오픈소스일수록 텍스트 양식보다 “재현 링크”를 문턱으로 세우는 쪽에 더 가깝게 움직입니다.

예를 들어, 리액트 네이티브(React Native)는 제보 양식에서 “재현물 링크”를 의무 항목으로 두고, 재현물이 없으면 이슈가 닫힐 수 있다고 명시합니다. 여기서 중요한 점은 “재현 절차를 글로 적어 달라”가 아니라 “재현이 가능한 형태의 결과물로 보여 달라”는 요구입니다. 글을 잘 쓰는 능력과 상관없이, 실제로 실행 가능한 재현물이 있어야만 검토가 시작됩니다.

정리하면, “정보 공백”을 메우는 수준을 넘어 이제는 “텍스트 공백을 텍스트로 채우는 방식” 자체가 한계에 닿았습니다. AI 슬롭 시대의 합의는 더 선명해져야 합니다. 제출물은 ‘증거’를 포함해야 하고, 유지보수자는 그 증거가 들어왔을 때만 검토 예산을 판단에 씁니다. 그리고 이제 남은 과제는, 이 문턱을 개인의 판단이 아니라 운영 규칙과 자동화로 고정해 일관되게 작동시키는 일입니다.

4. 금지 대신 문턱을 세운다: 품질 문턱으로 검토 예산을 지키는 방법

오픈소스가 아니어도, 품질 문턱은 이렇게 세웁니다

검토 예산과 승인 책임이 존재하는 곳이라면 오픈소스가 아니어도 같은 원리가 작동합니다. 제보나 요청, 변경 제안이 늘어나는 속도에 비해 사람의 판단 시간은 자동으로 늘지 않습니다. 그래서 “좋은 의도”에 기대기보다, 검토가 시작되는 조건을 운영 규칙으로 고정해야 합니다.

핵심은 네 가지입니다.

첫째, 검토를 시작할 수 있는 상태를 먼저 정의해야 합니다. 재현 가능성, 검증 가능성, 영향 범위, 실패 시 대응처럼 승인 책임을 무겁게 만드는 빈칸이 무엇인지부터 합의해야 합니다. 이 정의가 없으면 검토는 매번 사람의 감각과 컨디션에 기대게 되고, 같은 유형의 왕복이 반복됩니다.
둘째, 그 기준을 “권고”가 아니라 “문턱”으로 만들어야 합니다. 필수 정보가 없으면 검토를 시작하지 않고 보완 요청 상태로 분기하고, 일정 기간 응답이 없으면 정리되는 흐름을 규칙으로 고정해야 합니다. 문턱은 누군가를 혼내기 위한 장치가 아니라, 검토가 질의응답으로 무너지는 것을 막는 운영 장치입니다.
셋째, 사람이 보기 전에 기계가 먼저 확인할 수 있는 증거를 앞단에 붙여야 합니다. 기본 테스트나 자동 검증 절차가 통과하지 않으면 사람의 검토 시간을 쓰지 않는 원칙을 세우면, 검토 예산은 설명을 읽는 데가 아니라 판단과 결론을 내리는 데 쓰이기 시작합니다. 이 한 줄 원칙이 “사람이 판단해야 하는 순간”을 눈에 띄게 줄입니다.
넷째, 우선순위를 규칙으로 공개해야 합니다. 경고와 긴박한 표현이 아니라, 재현물과 근거, 영향 범위가 우선순위를 결정하도록 설계해야 승인 책임이 통제됩니다. 무엇이 먼저 처리되고 무엇이 뒤로 밀리는지가 규칙으로 설명되면, 커뮤니케이션 비용도 함께 내려갑니다.

정리하면 품질 문턱은 “거절을 늘리는 장치”가 아니라 “검토가 시작되는 버튼을 명확히 하는 장치”입니다. 이 버튼이 없으면 친절함은 오래가지 못하고, 결국 채널 축소나 범위 축소로 이어집니다. 문턱을 먼저 세우는 편이, 닫지 않고 유지하는 쪽에 더 가깝습니다.

오픈소스에 기여하고자 한다면, 이렇게 행동하셔야 합니다

오픈소스 생태계에 기여하려는 기여자라면, “무엇을 제출할지” 이전에 “어떤 책임을 질지”부터 분명해져야 합니다. 오픈소스는 누군가의 시간과 승인 책임 위에 돌아가는 운영체제입니다. 그래서 기여는 권리가 아니라 의무를 동반한 합의입니다. 내가 던진 한 줄이 검토 대기열을 늘리고, 승인자의 불확실성을 키우고, 결국 채널 축소나 운영 범위 축소로 이어질 수도 있다는 사실을 감안해야 합니다. 기여는 ‘선한 마음’이 아니라, 생태계의 검토 예산을 아끼는 방식으로 증명됩니다.

이 관점에서 가장 위험한 기여는 ‘내가 무엇을 바꾸는지’와 ‘그 변화가 어디까지 영향을 주는지’를 충분히 이해하지 못한 상태에서 제출되는 기여입니다. 동기는 다양할 수 있습니다. 실제로 쓰다가 불편해서일 수도 있고, 학습이나 경험을 위해서일 수도 있고, 이력서 한 줄을 남기기 위한 시도일 수도 있습니다. 문제는 동기가 아니라 준비 수준입니다. 맥락을 깊게 파지 않은 채 그럴듯한 설명과 코드를 얹어 제출하면, 겉으로는 생산적으로 보이지만 실제로는 운영 비용을 소비시킵니다.

특히 AI가 이 위험을 더 키웁니다. 그럴듯한 글과 코드가 빠르게 만들어지면서 “검토 가능한 상태”로 보이게 만들기 쉬워졌기 때문입니다. 하지만 재현과 검증이 없으면, 유지보수자는 그 순간부터 제출자가 생략한 사실 확인과 영향 분석을 대신 떠안게 됩니다. 결국 남는 것은 오픈소스의 개선이 아니라 늘어난 질의응답과 더 보수적으로 변한 승인 기준입니다. 이런 기여는 커뮤니티를 돕는 제안이라기보다, 커뮤니티의 시간을 소비하는 요청에 더 가깝습니다.

그래서 기여는 “증거”에서 시작해야 합니다. 문장으로 설득하려 하지 말고, 내가 겪은 문제 혹은 불편함을 재현 가능한 형태로 고정해야 합니다. 최소 재현이 가능하도록 조건을 좁히고, 가능하면 실행 가능한 재현물 링크나 시나리오를 남겨야 합니다. “어떻게 하면 같은 문제가 다시 일어나는지”가 포함되지 않으면, 검토는 개선이 아니라 조사로 바뀝니다. 그리고 이 조사의 비용은 결국 승인 책임자에게 붙습니다.

다음은 검증입니다. 단순히 “개선했습니다”가 아니라 문제 혹은 불편함을 “어떻게 확인했는지”가 제출물 안에 있어야 합니다. 테스트가 왜 실패했고 어떻게 통과하게 됐는지, 테스트로 구현하기 힘들다면 어떤 시나리오로 발생을 했는지, 결과가 무엇인지가 포함돼야 검토가 판단으로 진행됩니다. 마지막으로 영향 범위를 좁혀 주셔야 합니다. 어디까지 영향을 주는지, 호환성 변화가 있는지, 문제가 생기면 어떻게 되돌릴 수 있는지까지 적히면 승인 책임이 가벼워지고 검토는 빨라집니다.

무엇보다 중요한 태도는 “사용자 관점의 깊이”입니다. 오픈소스에 진심으로 기여한다는 것은, 내가 실제로 쓰는 사용자로서 문제를 끝까지 파고들고 재현과 검증으로 사실을 고정한 뒤, 유지보수자가 결론을 낼 수 있는 형태로 제출물을 완성하는 일입니다. 여기서 핵심은 “열심히 썼다”가 아니라 “승인 책임을 가볍게 만들었다”입니다. 재현이 되고, 검증이 되고, 영향 범위가 좁혀져 있으면 검토는 빠르게 판단으로 진행됩니다.

생태계를 바로 잡는 기여는 시간을 요구합니다. 그 시간을 누가 먼저 쓰느냐가 운영 비용을 결정합니다. 내가 쓰지 않으면 유지보수자가 씁니다. 내가 증거를 만들지 않으면 승인 책임자가 사실을 확인합니다. 그래서 기여는 결국 “내 시간을 먼저 쓰겠다는 선택”입니다.

결론적으로, 좋은 기여는 원인이 분명하고 불확실성을 줄인 제출물입니다. 오픈소스를 아끼는 기여자는 더 많은 제안을 올리는 사람이 아니라, 한 번의 제출로 더 적은 질문이 오가게 만드는 사람입니다. 이런 합의를 지키는 기여가 늘어날수록, 오픈소스 생태계는 채널을 닫는 쪽이 아니라 더 오래 열어둘 수 있는 쪽으로, 더 건강하고 지속 가능한 방향으로 나아갈 수 있을 겁니다.