# FFmpeg, 구글에 “자금 지원하든가 버그 제보를 중단하라” 요구 > Clean Markdown view of GeekNews topic #24307. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24307](https://news.hada.io/topic?id=24307) - GeekNews Markdown: [https://news.hada.io/topic/24307.md](https://news.hada.io/topic/24307.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-12T09:46:30+09:00 - Updated: 2025-11-12T09:46:30+09:00 - Original source: [thenewstack.io](https://thenewstack.io/ffmpeg-to-google-fund-us-or-stop-sending-bugs/) - Points: 15 - Comments: 15 ## Summary AI가 자동으로 찾아낸 **사소한 취약점 보고**가 오히려 오픈소스 커뮤니티를 압박하는 시대입니다. **FFmpeg**은 구글의 AI 스캐너가 제기한 오래된 코덱 버그를 계기로, “보안 제보보다 **패치나 재정 지원이 필요하다**”는 메시지를 던졌습니다. **AI 기반 대량 CVE 생성**이 현실적 가치보다 유지보수 부담을 키운다는 지적은, 오픈소스 생태계의 **지속 가능성**을 다시 묻게 하는데요. 누구 하나를 탓하기도 어려운 문제인 것 같습니다. ## Topic Body - **FFmpeg**은 전 세계 미디어 처리의 핵심 오픈소스 프레임워크로, **VLC·Chrome·YouTube** 등 주요 서비스에서 사용되는 필수 구성요소 - 최근 구글의 **AI 기반 보안 스캐너**가 1995년 게임 코덱 관련 **사소한 버그**를 발견하면서, 대기업이 자발적 개발자에게 과도한 부담을 지운다는 논란 확산 - FFmpeg 측은 “프로젝트는 거의 전적으로 **자원봉사자**가 유지한다”며, 구글이 취약점 보고만 할 게 아니라 **패치 제공 또는 재정 지원**을 해야 한다고 주장 - 구글은 **Project Zero의 공개 정책**과 **Patch Rewards 프로그램**을 근거로 투명한 보안 공헌을 강조했지만, FFmpeg 커뮤니티는 보상 한도와 현실적 지원 부족을 지적 - 이번 논쟁은 **AI가 생성한 대량 CVE와 오픈소스 유지보수의 지속 가능성** 문제를 드러내며, 대형 기술기업의 책임 논의로 이어짐 --- ### FFmpeg과 구글 간의 갈등 개요 - FFmpeg은 오디오·비디오 파일의 **트랜스코딩, 재생, 스트리밍**을 지원하는 오픈소스 멀티미디어 프레임워크 - **libavcodec**, **libavformat** 등 핵심 라이브러리는 VLC, Kodi, Plex, Chrome, Firefox, YouTube 등에서 사용 - 그러나 다른 주요 오픈소스 프로젝트와 마찬가지로 **심각한 재정 부족** 상태 - 트위터에서 FFmpeg, 구글, Chainguard, 보안 연구자 간에 **보안 취약점 공개 방식과 책임 소재**를 두고 논쟁 발생 - AI가 생성한 대량의 취약점 보고가 실제 가치가 낮은 경우가 많다는 점이 논의의 중심 ### 논란의 발단: 구글 AI가 발견한 사소한 버그 - 구글의 AI 에이전트가 FFmpeg에서 **LucasArts Smush 코덱 디코딩 관련 버그**를 발견 - 해당 문제는 1995년 게임 *Rebel Assault 2*의 첫 10~20프레임에만 영향을 주는 **중간 수준 취약점** - FFmpeg 개발자들은 이를 패치했지만, “**CVE 남발(CVE slop)** ”이라 표현하며 비효율적 보고를 비판 - FFmpeg은 “**FFmpeg aims to play every video file ever made**”라며 완벽한 호환성을 목표로 하지만, 대부분의 코드는 **어셈블리 언어로 작성**되어 유지보수가 어렵다고 언급 ### 오픈소스 유지보수자의 부담 - FFmpeg 커뮤니티는 구글처럼 FFmpeg을 사용하는 **대기업이 무급 자원봉사자에게 취약점 수정을 떠넘긴다**고 비판 - 구글이 취약점 보고 시 **패치 제공 또는 재정 지원**을 병행해야 한다는 입장 - 비슷한 사례로 **libxml2**의 유지보수자 **Nick Wellnhofer**가 반복되는 제3자 보안 보고로 인해 **유지보수 중단**을 선언 - 그는 “보수가 없는 자원봉사자가 매주 수시간을 보안 이슈 처리에 쏟는 것은 지속 불가능하다”고 언급 ### 구글 Project Zero의 공개 정책 논란 - 2025년 7월, **Google Project Zero(GPZ)** 는 ‘** Reporting Transparency**’ 정책을 도입 - 취약점 발견 후 **1주일 내 공개**, 이후 **90일 내 수정 기한**이 자동 시작됨 - 패치가 준비되지 않아도 공개가 진행되어, **자원봉사자 중심 프로젝트에 과도한 압박**을 준다는 비판 - FFmpeg은 “**AI가 취미 코드의 보안 문제를 찾아내고 자원봉사자에게 수정을 요구하는 것이 공정한가**”라고 반문 - 구글의 Patch Rewards Program은 존재하지만, FFmpeg은 **“월 3건 제한 등으로 실질적 도움이 되지 않는다”** 고 지적 ### 상반된 시각과 오픈소스의 지속 가능성 - Chainguard의 **Dan Lorenc**은 “보안 취약점 공개 또한 **디지털 공공재에 대한 기여**”라며 구글의 역할을 옹호 - 그는 “구글은 오픈소스 지원에 가장 적극적인 기업 중 하나이며, 이런 논쟁이 오히려 후원자를 멀어지게 할 수 있다”고 주장 - 그러나 FFmpeg 측은 **AI가 생성한 대량 CVE에 대응할 인력과 자금이 부족**하다고 강조 - 보안 전문가들은 FFmpeg이 인터넷 인프라의 핵심 구성요소이므로 **취약점 공개는 필요**하다고 인정 - 기사 말미는 “**대기업의 실질적 지원 없이는 핵심 오픈소스 프로젝트 유지가 불가능**하다”며, libxml2 사례를 들어 **지속 가능한 후원 구조의 필요성**을 강조 ## Comments ### Comment 46320 - Author: carnoxen - Created: 2025-11-14T11:35:44+09:00 - Points: 1 이러다가 설마 wordpress 재단과 wp engines 기업 관계처럼 파탄나는 건 아니겠죠? ### Comment 46315 - Author: nullptr - Created: 2025-11-14T10:07:56+09:00 - Points: 1 https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/ 의 연장선으로 보이네요 위에 글은 개인들이 버그바운티를 노리고 보내는 아예 틀린 리포트였다면, FFmpeg 건은 대기업이 보내는 유효하지만 사소한 리포트네요 ### Comment 46267 - Author: kimjoin2 - Created: 2025-11-13T10:05:57+09:00 - Points: 1 구글이 지적한다고 반드시 대응을 해야하나요? ### Comment 46268 - Author: furyheimdall - Created: 2025-11-13T10:10:28+09:00 - Points: 5 - Parent comment: 46267 - Depth: 1 취약점 자체가 공개되어버리는 상황이라 대응할 수 밖에 없을 것 같네요. ### Comment 46333 - Author: kimjoin2 - Created: 2025-11-14T22:16:42+09:00 - Points: 1 - Parent comment: 46268 - Depth: 2 아하... 그런 관점이 있었내요. 알려주셔서 감사합니다! 취약점이 공개되어 그걸로 공격해올 수 있는 부분이군요 ㄷㄷ ### Comment 46292 - Author: roxie - Created: 2025-11-13T18:21:46+09:00 - Points: 2 - Parent comment: 46267 - Depth: 1 사실 공개가 되던말던 아쉬우면 네가 고치십시오~ 해도 되겠지만, 그런 성격이 되지 못하는 분들이 메인테이너여서 여기까지 발전되어 온 것 같네요 ### Comment 46334 - Author: kimjoin2 - Created: 2025-11-14T22:17:11+09:00 - Points: 1 - Parent comment: 46292 - Depth: 2 아하.... 말씀하신게 맞는 것 같아요. 너무 제 관점에서 생각한 것 같습니다. 말씀 감사합니다! ### Comment 46218 - Author: neo - Created: 2025-11-12T09:46:30+09:00 - Points: 2 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45891016) - 기사에서 인상 깊었던 부분이 있었음. Amazon 내부에서 FFmpeg 관련 결정을 막기 위해 **Mark Atwood**가 상사들에게 “그들은 벤더가 아니고, NDA도 없으며, 우리가 그들에게 영향력을 행사할 수 없다”고 설명해야 했다는 이야기였음. 나는 “문제만 가져오지 말고 해결책을 가져오라”는 말에 동의하지만, **Google**이 버그를 찾을 돈이 있다면 고치는 데도 돈을 쓸 수 있다고 생각함 - 나는 오픈소스 소프트웨어의 수정 사항을 **upstream**하는 걸 늘 지지해왔음. 그렇게 하면 비공개 패치에 의존하지 않아도 되고, 처음 도움받은 프로젝트에 보답할 수 있으며, 윤리적으로도 옳은 일임. 하지만 실제로는 기업 내부의 **컴플라이언스나 절차 장벽** 때문에 upstream이 어렵다는 게 문제였음 - “FFmpeg가 이메일 한 통으로 AWS의 세 개 제품 라인을 멈출 수 있다”는 말이 이해가 안 됨. 구체적으로 어떻게 가능한지 궁금함 - 문제는 기사에서 언급된 “**CVE slop**”임. 만약 패치 품질이 그 수준이라면, 수정에도 꽤 많은 노력이 필요할 것 같음 - Google이 사람을 고용해 버그를 찾는 게 아니라, **AI를 무차별적으로 돌리고 있다**는 점이 핵심임 - S&P500 기업 직원이 버그를 보고하려면 일정 금액을 기부해야 하고, 일정 금액 이상을 내지 않으면 일정 기간 내 응답을 기대할 수 없다는 **풍자적 라이선스**를 상상해봤음. 기업들이 불편할 땐 소프트웨어를 비공개로 돌리거나 AGPL로 바꾸는 걸 주저하지 않으니, 이제는 직접 대가를 치를 때임 - 나는 오픈소스 **유지보수자**로서, 대기업이 보안 문제를 공개함으로써 무료 노동을 강요하는 듯한 인상을 받는다는 점에 공감함. 하지만 실제로는 누가 보고했든 보안 이슈는 결국 내가 해결해야 할 문제임. 프로젝트가 보안을 우선순위로 두지 않는 것도 괜찮지만, 그렇다면 그에 따른 평판 리스크도 감수해야 함 - 만약 Google이 문제를 찾아도 아무도 고치지 않는다면, 이는 사실상 **악의적 행위자에게 무료 취약점 리서치**를 제공하는 셈임. FFmpeg 같은 핵심 프로젝트는 대체가 어려움 - 내가 읽은 요지는 Google이 일정 기간 후 **무조건 공개하는 정책**으로 바꿨다는 것임. 상업 기업에는 빠른 수정 요구가 타당하지만, **자원봉사 기반 OSS**에 같은 요구를 하는 건 현실적이지 않음 - 기사에 따르면 Google의 AI가 FFmpeg의 **LucasArts Smush 코덱** 관련 버그를 찾았다고 함. 1995년 게임의 첫 10~20프레임에서만 발생하는 문제라는데, 이걸 ‘중간 심각도’로 분류한 건 과하다고 느낌. 유지보수자의 시간을 낭비하게 만드는 사례로 보임 - 핵심은 “누가 보고했는가”가 아니라 “**이슈의 실제 중요도**”임. 심각한 문제면 누구든 알려주는 게 좋고, 사소하거나 잘못된 보고면 무시하면 됨. 결국 어떤 버그를 고칠지는 프로젝트가 스스로 판단해야 함 - 물론 Google이 취약점을 공개할 때 **패치도 함께 제출**하면 가장 이상적일 것임 - 나는 FFmpeg 팀의 입장을 지지함. 많은 기업이 FOSS를 **마케팅용 이미지 세탁**에만 이용하고, 실제로는 기여하지 않음. 예전 같으면 그냥 불법 복제했을 사람들이 이제는 라이선스 덕분에 양심의 가책 없이 이용하는 셈임 - 하지만 Google은 FFmpeg를 위해 **지속적인 퍼징(fuzzing)** 과 **엔지니어링 리소스**를 투입하고 있음. 내부적으로 사용하지 않는 코덱까지 테스트하는 건 순수한 공익 목적임. 물론 Google이 FFmpeg에 더 많은 자금을 지원할 여력은 있지만, 이번 유지보수자에게 직접 자금을 주는 건 동의하지 않음 - 이런 이유로 **MIT 라이선스**의 한계를 지적하는 사람도 많음. 자유롭게 쓸 수 있지만, 남용의 여지도 큼. **GPL 3**이 과하다는 비판도 있지만, 최소한 착취를 막으려는 의도는 있었음 - 무료로 시대를 정의하는 소프트웨어를 만드는 사람들과, 그걸 이용해 **모든 가치를 추출하는 기업들**이 있음. 전자는 사랑으로, 후자는 거래로 움직임 - Google이 무엇을 하든 **보안 연구 자체는 유익함**. 다만 FOSS에는 좀 더 유연한 정책이 필요함 - Google과 그 외의 모든 존재를 비교하면, 선악 구분이 이렇게 쉬운 경우도 드묾 - “시대를 정의하는 소프트웨어”라지만, 솔직히 **FFmpeg를 아는 사람은 많지 않음** - 대기업에는 공개적 취약점 공개가 필요하지만, **리소스가 부족한 OSS**에는 위험이 더 클 수 있음 - 그래서 FOSS에는 “패치가 준비된 후 공개” 정책이 맞다고 생각함. Google이 빠른 수정을 원한다면 **패치도 함께 제출**하면 모두가 이득임 - 하지만 취약점을 숨기는 것도 위험함. 특히 **LLM이 발견할 수 있는 수준의 취약점**이라면, 언젠가 악용될 가능성이 큼. 공개 덕분에 사용자는 스스로 방어할 수 있고, FFmpeg가 이를 고치기로 한 건 자발적 선택임. 보안 연구 자체가 오픈소스에 대한 **고비용 기여 형태**임. 연구자에게 “기여가 충분치 않다”고 말하는 건 오히려 자원봉사자에게 무료 노동을 요구하는 셈임 - 공개하지 않으면 사용자들이 “취약점이 없다”고 착각함. FOSS의 투명성이 오히려 보안 인식에 도움이 됨 - 정보보안 업계에는 “**불안전한 소프트웨어는 존재해서는 안 된다**”는 극단적 신념이 퍼져 있음. 현실의 회색지대를 인정하지 않음 - “이메일 한 통으로 세 개의 제품 라인을 멈출 수 있다면”, **연 1~2만 달러 정도의 지원금**은 보험료로도 충분하다고 생각함 - 하지만 **Jeff Bezos의 요트**를 보면, 그가 수표를 쓰는 방식이 어떤지 알 수 있음. Google과 Amazon이 각각 5만 달러씩만 지원해도 FFmpeg 개발자들이 안정적으로 일할 수 있을 텐데, 특히 YouTube를 운영하는 Google은 10만~20만 달러 정도는 쉽게 낼 수 있을 것임 - Google 보안 책임자가 FFmpeg에 기여한 내역을 정리한 [트위터 스레드](https://x.com/argvee/status/1986194852669964528)를 공유함 - Google의 입장을 직접 보니 좋았음. 다만 일부 전·현직 직원들의 **비전문적 대응**은 아쉬웠음 - 트위터에 로그인하지 않으면 첫 글만 보이는데, 그조차 **기업식 방어 멘트**처럼 들림. 1조 달러짜리 회사가 인력이나 자금이 부족하다는 건 설득력이 없음 - **Project Zero**의 목적이 궁금함. 단순히 취약점을 찾는 것 이상의 이유가 있는지 알고 싶음 - 본질은 **PR**임. “책임 있는 공개”가 개발자가 무기한 버그를 숨기는 걸 의미하지 않는다는 메시지를 주려는 것임 - 이 프로젝트는 **스노든 사태 이후** NSA의 감청에 분노한 Google이 만든 것임 - 실제로는 Google이 사용하는 다양한 오픈소스와 커널, 펌웨어 보안을 강화하는 데 도움이 됨. 동시에 **보안 인재 유치와 명성 관리**에도 유리함. 하지만 그럴 여유가 있다면 패치 작성에도 투자해야 한다는 생각이 듦 - 결국 **마케팅 목적**도 큼. 연구자들이 소속감을 느끼고, Google은 “보안에 투자하는 기업” 이미지를 얻음 - 문제의 취약점은 **Use After Free**였고, Google의 AI가 이를 찾았음. 하지만 그걸 고치는 데 3초도 안 걸릴 일임. 돈이 넘치는 회사가 자원봉사 프로젝트에 **스팸성 버그 리포트**를 던지는 건 불쾌함 - 게다가 해당 취약점은 **기본적으로 비활성화된 코덱**에 있었음. CVE로 분류할 수준도 아니고, 단순 버그 리포트면 충분했을 것임 - 물론 “free를 지연시키면 된다”는 식으로 단순하지 않음. 메모리 누수를 막으려면 더 복잡한 수정이 필요함. 아마도 이 코덱은 **기본 비활성화**가 맞는 방향임 - 이런 행위는 단순히 불쾌한 수준이 아니라, **오픈소스 정신에 반하는 행동**임 ### Comment 46274 - Author: nobae - Created: 2025-11-13T11:52:39+09:00 - Points: 2 - Parent comment: 46218 - Depth: 1 먹을걸 줬더니 보따리를 내노라고 하네요 버그 리포트도 분명 중요한 기여일텐데... ### Comment 46276 - Author: bungker - Created: 2025-11-13T12:18:45+09:00 - Points: 11 - Parent comment: 46274 - Depth: 2 누가 자발적으로 동네청소를 하는데 동네땅 가장 많이 소유한 유지가 청소하는 사람한테 저기 구석에 담배꽁초 있어요 하는 느낌정도 될것 같아요 ### Comment 46311 - Author: reagea0 - Created: 2025-11-14T09:54:54+09:00 - Points: 1 - Parent comment: 46276 - Depth: 3 저도 이 비유가 맞다고 생각하네요. ### Comment 46294 - Author: chcv0313 - Created: 2025-11-13T19:20:38+09:00 - Points: 2 - Parent comment: 46276 - Depth: 3 적절한 비유입니다. ### Comment 46282 - Author: ifmkl - Created: 2025-11-13T13:39:17+09:00 - Points: 5 - Parent comment: 46274 - Depth: 2 먹을게 맞긴 한가요? 읽어보면 아주 고전 특정 게임의 첫 10~20프레임에서만 유효한 중간등급의 보안취약점. 이게 진실로 FFmpeg 측에 중요한 기여라고 생각하십니까? 오픈소스 커뮤니티에 제일 중요한 기여는 안정적인 개발이 가능하도록 후원해야 하는게, 특히 그 결과물을 잘 사용하고 있는 기업이라면 그게 우선일 거 같은데요? ### Comment 46278 - Author: secret3056 - Created: 2025-11-13T13:04:03+09:00 - Points: 4 - Parent comment: 46274 - Depth: 2 버그 리포트 자체는 S급이긴한데, 캐네디 대통령때나 쓰던 비디오 포맷의 중대한 취약점을 기간 내에 대응하지 못했다고 동내방내 소문내고 다니니까요. 먹을 수 있는 것을 주는게 아니라 먹어야만 하는 걸 주고 왜 기간 안에 못 먹냐고 하는겁니다. ffmpeg는 인력이 한정되어있는데 구글이 AI로 이젠 쓰이지도 않는 포맷에 대한 수십개의 버그 리포트를 쏟아내면서 기간내에 모두 고치라고 압박 하는게 옳을까요? ### Comment 46279 - Author: hohemian - Created: 2025-11-13T13:06:15+09:00 - Points: 3 - Parent comment: 46274 - Depth: 2 이런 사람 때문에 XZ에 백도어가 심긴거죠