# 쓸모없는 리포트로 시간을 낭비하게 하면 당신을 밴하고 공개적으로 조롱할 것이다 > Clean Markdown view of GeekNews topic #26052. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26052](https://news.hada.io/topic?id=26052) - GeekNews Markdown: [https://news.hada.io/topic/26052.md](https://news.hada.io/topic/26052.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-23T10:41:13+09:00 - Updated: 2026-01-23T10:41:13+09:00 - Original source: [curl.se](https://curl.se/.well-known/security.txt) - Points: 3 - Comments: 3 ## Topic Body - **curl 오픈소스 프로젝트** 의 `/.well-known/security.txt` 에 기재된 내용 - 자체 제품에서 발견된 보안 문제에 대한 보고를 접수하지만, 보고된 문제에 대해 **금전적 보상이나 보상 형태의 혜택은 제공하지 않음** - 대신, 확인된 문제에는 **문서 내 감사 표시와 공로 인정**을 명시함 - **부실하거나 무의미한 보고**로 시간을 낭비시키는 경우, **공개적 조롱 및 차단 조치**를 경고함 - 보안 보고 정책의 핵심 내용을 간결히 요약한 **security.txt 표준 형식** 사용 --- ### curl 프로젝트의 보안 보고 정책 - **curl 오픈소스 프로젝트**는 curl 프로젝트에서 제작한 제품의 보안 문제를 보고받음 - 보고는 이메일(security@curl.se) 또는 GitHub 보안 권고 페이지를 통해 접수 가능 - **보상 정책 없음**을 명확히 명시하며, 금전적 또는 기타 형태의 보상은 제공하지 않음 - 대신, 확인된 문제에 대해서는 관련 문서에 **감사의 표시와 공로 인정**을 제공 ### 부적절한 보고에 대한 경고 - 프로젝트는 **“쓸모없는 보고로 시간을 낭비하게 하면 금지하고 공개적으로 조롱할 것”** 이라고 명시 - 이는 비전문적이거나 근거 없는 보고를 방지하기 위한 강한 경고 표현 - 보고 품질과 책임 있는 제보 문화를 강조 ### 보안 보고 절차 및 공식 정보 - **연락 수단**: 이메일(security@curl.se)과 GitHub 보안 권고 페이지 제공 - **정책 문서**: https://curl.se/dev/vuln-disclosure.html 에서 공개 - **감사 페이지**: https://curl.se/docs/security.html 에서 확인 가능 - **선호 언어**: 영어(en) - **정책 만료일**: 2026년 10월 22일로 명시 - **공식 URL**: https://curl.se/.well-known/security.txt ## Comments ### Comment 49831 - Author: slowandsnow - Created: 2026-01-24T06:46:42+09:00 - Points: 1 무분별한 이슈 제기 때문에 깃허브 이슈 페이지 닫는 게 답인 듯 ### Comment 49774 - Author: skageektp - Created: 2026-01-23T17:54:32+09:00 - Points: 1 공개적 조롱은 한국법으로는 위법 아닌가 싶기도 하네요 ㅋㅋㅋ ### Comment 49740 - Author: neo - Created: 2026-01-23T10:41:13+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46717556) - 최근 **cURL**이 AI가 생성한 허위 버그 리포트가 넘쳐나자, 버그 바운티 제도를 없앴다는 소식을 봤음 관련 기사: [Hacker News 스레드](https://news.ycombinator.com/item?id=46701733), [ETN 보도](https://etn.se/index.php/nyheter/72808-curl-removes-bug-boun...) - 리포트와 패치, 그리고 **테스트 케이스**까지 제대로 갖춘다면, 설령 AI가 생성했더라도 보상할 가치가 있다고 생각함 - AI 시대가 본격적으로 열렸음을 느끼는 중임 - 모두 예상했던 일이고, 오히려 이렇게 늦게 터진 게 놀라움 - 오픈소스 배포 모델이 **지속 불가능한 구조**가 되었다고 생각함 원래 자유 소프트웨어 운동은 사용자가 직접 수정하고 개선할 자유를 보장하려는 것이었음 그런데 지금은 이슈 트래커, PR 리뷰, 이메일 지원, 보안 패치까지 무료로 기대하는 문화가 생겼음 이런 건 사실상 **유료 지원 업무**이며, 취미가 아닌 이상 보상이 필요함 - 예전에 HapiJS로 간단한 정적 사이트 생성기를 만들어 GitHub에 올렸는데, Reddit에 퍼지자 PR, 버그 리포트, 욕설이 폭주했음 “지원할 생각이 없다”고 밝혔는데도 비난이 쏟아졌고, 그게 내 첫이자 마지막 **OSS 프로젝트**였음 - 사용자들이 원하는 기능에 **소액 보상**을 걸 수 있는 시스템을 상상해봄 여러 사용자가 같은 기능을 원하면 보상 풀이 커지고, 개발자는 그 작업을 선택해 수행함 프로젝트 매니저와 테스터도 일정 비율을 가져가며, 모두가 동기부여를 얻는 구조임 - 오픈소스의 창시자들이 이런 모델을 의도하지 않았다는 말에는 동의하지 않음 **Eric S. Raymond**의 “Bazaar 모델”과 “Linus의 법칙(눈이 많으면 버그는 얕다)”은 바로 공개 협업을 전제로 함 - FOSS 개발자를 피해자로 보는 시각에는 반대함 스스로 **경계와 규칙**을 설정하고, 무례한 사람은 차단하면 됨 - GitHub과 같은 공개 이슈 트래커를 통한 협업은 이미 두 세대에 걸쳐 **오픈소스의 기본 문화**로 자리 잡았음 - 최근 **OWASP 문서화 프로젝트**를 돕고 있는데, 인도 학생들이 LLM으로 생성한 엉뚱한 PR과 이슈를 대량으로 올림 Ghostty처럼 먼저 ‘Discussion’으로 시작하고, 유지자가 승인한 이슈만 PR로 전환하는 구조가 필요하다고 제안함 - 인도 개발자들이 질문을 피하고 그냥 진행하는 **‘fake it till you make it’ 문화**를 본 적 있음 - 많은 학생들이 **이력서용 GitHub 활동**을 위해 LLM 코드로 PR을 보내는데, 수정 요청을 하면 전혀 이해하지 못함 Torvalds가 말했듯, LLM 덕분에 코드 유지보수가 악몽이 될 것 같음 - 이런 무의미한 PR이 많아지면, 진짜 이슈를 찾기가 어려워짐 - Stack Overflow가 몰락한 이유 중 하나도 **저품질 질문 폭증** 때문이라고 생각함 - 한 번은 버그 리포트를 올렸는데 재현 정보가 부족하다는 이유로 Reddit에서 **심한 비난**을 받았음 그 일 이후로 SNS 활동을 거의 끊었음 - curl 팀은 보통 정중하게 추가 정보를 요청하므로, 제대로 응답하지 않았다면 닫히는 게 당연함 - 유지보수자는 수많은 잘못된 리포트 속에서 진짜 버그를 찾느라 고생함 비판은 리포트에 대한 것이지 개인에 대한 게 아님을 기억해야 함 - curl 팀은 오히려 **관대한 편**이며, Reddit에서의 비난은 공식 커뮤니티와 무관함 - 아이러니하게도, 지금 이 스레드의 반응조차 “재현 불가”한 경험을 다루고 있음 - **Eternal September**와 LLM이 만든 저품질 기여 문제를 해결하려면, 오히려 **진입 장벽을 높이는 마찰(friction)** 이 필요하다고 생각함 예를 들어 첫 기여자는 **엽서에 QR코드로 리포트**를 보내야 한다든가 하는 식임 - 하지만 이런 마찰은 오히려 진짜 기여자보다 **스팸 기여자들이 더 잘 견디는** 경향이 있어 효과가 없을 수 있음 - 프로젝트가 이모지와 오류로 가득한 PR 속에서 허우적대면, 더 이상 **Bazaar 모델**이 작동하기 어려움 - [Brandolini’s Law](https://en.wikipedia.org/wiki/Brandolini%27s_law)를 떠올림 검증되지 않은 정보가 넘쳐나는 건 오픈소스뿐 아니라 사회 전반의 문제임 문화가 아직 **가짜 정보 면역체계**를 갖추지 못했음 - 예전에 **The Pirate Bay**가 MPAA의 법적 위협 이메일을 공개하던 시절이 떠오름 [TPB의 법적 대응 페이지(웹 아카이브)](https://web.archive.org/web/20111223101839/http://thepiratebay.org/legal)에서 그 흔적을 볼 수 있음 그들의 방식이 효과적이진 않았지만, 일종의 **저항의 상징**으로 남았음 - 친구가 유지하는 유명 오픈소스 프로젝트에 중국 대학생들이 **허위 보안 취약점 리포트**를 과제용으로 제출함 대부분 재현 불가라서 유지보수자의 시간을 낭비시킴 또 배포판별 설정 차이 때문에 실제 취약점이 **업스트림 코드가 아닌 패키지 설정**에서 발생하기도 함 Kryptos K4 서브레딧에서도 LLM이 만든 “해결했다!” 글이 넘쳐, 첫 위반 시 바로 밴함 AI 숙제 부정이 이제 **모든 영역으로 번진 현실**이 걱정됨 - 인간으로서 **배움과 성장의 즐거움**을 잃지 말아야 함 AI가 아무리 발전해도 **자기 학습의 가치**는 대체 불가임 - Kryptos K4는 LLM이 모든 데이터를 알고 있음에도, **새로운 아이디어를 전혀 내지 못함** 결국 LLM은 창의적 사고가 아닌, 강화된 자동 완성 도구에 불과함 - 중국에서는 의대생이 논문을 직접 쓰지 않고 **대필로 학술지를 오염시키는** 일이 흔함 - 결국 학계의 부정이 시장으로 이어지고, **금전적 인센티브**가 있는 한 이런 일은 멈추지 않을 것임 - GitHub이 사용자에게 **신뢰 점수나 평판 시스템**을 부여하면 좋겠다고 생각함 - 하지만 GitHub은 **AI 부서(Microsoft CoreAI)** 소속이라, 이런 행동을 오히려 장려할 가능성이 큼 관련 기사: [GeekWire 보도](https://www.geekwire.com/2025/github-will-join-microsofts-coreai-group-with-departure-of-ceo-thomas-dohmke/) - Microsoft가 개발자에게 **사회적 점수**를 매기는 건 끔찍한 발상임 - 오히려 사용자를 익명화해 **명성 추구 동기**를 줄이는 게 낫다고 봄 - HackerOne 같은 플랫폼에도 평판 시스템이 있지만, **저품질 리포트**는 여전히 넘쳐남 결국 기업들은 **중간 심사(triage)** 서비스를 유료로 이용하게 됨 이 과정에서 실제 전문가가 아닌 사람이 먼저 응답해, 진짜 리포트가 늦게 처리되는 문제도 생김 지금의 상황은 **모두에게 나쁜 구조**이며 점점 악화되고 있음