FFmpeg, 구글에 “자금 지원하든가 버그 제보를 중단하라” 요구

• 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 사례를 들어 지속 가능한 후원 구조의 필요성을 강조

[carnoxen]

이러다가 설마 wordpress 재단과 wp engines 기업 관계처럼 파탄나는 건 아니겠죠?

[nullptr]

https://daniel.haxx.se/blog/2024/…
의 연장선으로 보이네요
위에 글은 개인들이 버그바운티를 노리고 보내는 아예 틀린 리포트였다면, FFmpeg 건은 대기업이 보내는 유효하지만 사소한 리포트네요

[kimjoin2]

구글이 지적한다고 반드시 대응을 해야하나요?

[roxie]

사실 공개가 되던말던 아쉬우면 네가 고치십시오~ 해도 되겠지만, 그런 성격이 되지 못하는 분들이 메인테이너여서 여기까지 발전되어 온 것 같네요

[kimjoin2]

아하.... 말씀하신게 맞는 것 같아요.
너무 제 관점에서 생각한 것 같습니다.
말씀 감사합니다!

[furyheimdall]

취약점 자체가 공개되어버리는 상황이라 대응할 수 밖에 없을 것 같네요.

[kimjoin2]

아하... 그런 관점이 있었내요. 알려주셔서 감사합니다!
취약점이 공개되어 그걸로 공격해올 수 있는 부분이군요 ㄷㄷ

[GN⁺]

Hacker News 의견

• 기사에서 인상 깊었던 부분이 있었음. 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에 기여한 내역을 정리한 트위터 스레드를 공유함

  • Google의 입장을 직접 보니 좋았음. 다만 일부 전·현직 직원들의 비전문적 대응은 아쉬웠음
  • 트위터에 로그인하지 않으면 첫 글만 보이는데, 그조차 기업식 방어 멘트처럼 들림.
    1조 달러짜리 회사가 인력이나 자금이 부족하다는 건 설득력이 없음

• Project Zero의 목적이 궁금함.
  단순히 취약점을 찾는 것 이상의 이유가 있는지 알고 싶음

  • 본질은 PR임. “책임 있는 공개”가 개발자가 무기한 버그를 숨기는 걸 의미하지 않는다는 메시지를 주려는 것임
  • 이 프로젝트는 스노든 사태 이후 NSA의 감청에 분노한 Google이 만든 것임
  • 실제로는 Google이 사용하는 다양한 오픈소스와 커널, 펌웨어 보안을 강화하는 데 도움이 됨.
    동시에 보안 인재 유치와 명성 관리에도 유리함.
    하지만 그럴 여유가 있다면 패치 작성에도 투자해야 한다는 생각이 듦
  • 결국 마케팅 목적도 큼. 연구자들이 소속감을 느끼고, Google은 “보안에 투자하는 기업” 이미지를 얻음

• 문제의 취약점은 Use After Free였고, Google의 AI가 이를 찾았음.
  하지만 그걸 고치는 데 3초도 안 걸릴 일임.
  돈이 넘치는 회사가 자원봉사 프로젝트에 스팸성 버그 리포트를 던지는 건 불쾌함

  • 게다가 해당 취약점은 기본적으로 비활성화된 코덱에 있었음.
    CVE로 분류할 수준도 아니고, 단순 버그 리포트면 충분했을 것임
  • 물론 “free를 지연시키면 된다”는 식으로 단순하지 않음.
    메모리 누수를 막으려면 더 복잡한 수정이 필요함.
    아마도 이 코덱은 기본 비활성화가 맞는 방향임
  • 이런 행위는 단순히 불쾌한 수준이 아니라, 오픈소스 정신에 반하는 행동임

[nobae]

먹을걸 줬더니 보따리를 내노라고 하네요
버그 리포트도 분명 중요한 기여일텐데...

[bungker]

누가 자발적으로 동네청소를 하는데 동네땅 가장 많이 소유한 유지가 청소하는 사람한테 저기 구석에 담배꽁초 있어요 하는 느낌정도 될것 같아요

[reagea0]

저도 이 비유가 맞다고 생각하네요.

[chcv0313]

적절한 비유입니다.

[ifmkl]

먹을게 맞긴 한가요? 읽어보면 아주 고전 특정 게임의 첫 10~20프레임에서만 유효한 중간등급의 보안취약점. 이게 진실로 FFmpeg 측에 중요한 기여라고 생각하십니까? 오픈소스 커뮤니티에 제일 중요한 기여는 안정적인 개발이 가능하도록 후원해야 하는게, 특히 그 결과물을 잘 사용하고 있는 기업이라면 그게 우선일 거 같은데요?

[hohemian]

이런 사람 때문에 XZ에 백도어가 심긴거죠

[secret3056]

버그 리포트 자체는 S급이긴한데, 캐네디 대통령때나 쓰던 비디오 포맷의 중대한 취약점을 기간 내에 대응하지 못했다고 동내방내 소문내고 다니니까요.

먹을 수 있는 것을 주는게 아니라 먹어야만 하는 걸 주고 왜 기간 안에 못 먹냐고 하는겁니다.

ffmpeg는 인력이 한정되어있는데 구글이 AI로 이젠 쓰이지도 않는 포맷에 대한 수십개의 버그 리포트를 쏟아내면서 기간내에 모두 고치라고 압박 하는게 옳을까요?