레이디버드, 공개 풀 리퀘스트 중단 “브라우저 보안 모델에 안 맞다”

• Ladybird가 공개 풀 리퀘스트를 더 이상 받지 않겠다고 발표함

  • 앞으로 Ladybird 코드베이스에 들어가는 변경은 프로젝트 maintainer만 도입할 수 있음
  • 현재 열려 있는 공개 풀 리퀘스트도 모두 닫을 예정
  • 첫 알파 릴리스를 준비하는 단계라 개발 프로세스, 보안 모델, 책임 범위를 더 좁히겠다는 판단

• 핵심 이유는 AI 때문에 오픈소스의 오래된 신뢰 방식이 흔들렸다는 것임

  • 예전엔 큰 패치를 보내는 것 자체가 꽤 큰 노력의 증거였고, 어느 정도 선의의 신호로 볼 수 있었음
  • 이제는 AI 도구 덕분에 그럴듯하고 큰 변경을 훨씬 싸고 빠르게 만들 수 있음
  • Ladybird 팀도 AI를 매일 쓰지만, 그래서 더더욱 “풀 리퀘스트의 크기나 완성도만 보고 제출자를 신뢰하기 어렵다”고 봄

• 브라우저라는 제품 특성이 이 결정을 더 세게 밀어붙임

  • 브라우저는 인터넷 전체에서 오는 신뢰할 수 없는 입력을 사용자 머신에서 실행하고 파싱함
  • 잘 숨겨진 취약점 하나만 있어도 공격자 입장에선 충분함
  • 팀은 이미 오픈소스에서 maintainer 신뢰를 오래 쌓은 뒤 악용하는, 인내심 있고 자원이 많은 캠페인을 봤다고 언급함

• 그래서 Ladybird는 “우회 기여 경로”도 만들지 않겠다고 선을 그음

  • 이슈, 댓글, 이메일, 포크를 통해 패치를 던지고 사실상 리뷰 큐처럼 쓰는 방식을 원하지 않는다고 밝힘
  • 외부 코드는 라이선스 조건에 따라 존재할 수 있지만, upstream Ladybird의 검토 대기열로 취급하지 않겠다는 뜻
  • 이건 꽤 강한 메시지임. 공개 PR만 닫고 뒤로 패치 받는 구조가 아니라, 코드 유입 책임을 maintainer 내부로 닫는 결정

• 그렇다고 Ladybird가 오픈소스를 접는 건 아님

  • 소스 코드는 계속 오픈소스 라이선스로 공개됨
  • 외부 참여도 버그 리포트, 축소 재현, 웹사이트 테스트, 표준 논의, 디자인 논의, 보안 제보, 기술 피드백 형태로는 계속 중요하다고 말함
  • 다만 “코드 변경을 직접 넣는 방식”만 닫는 것

• 이 발표가 흥미로운 건 오픈소스 문화의 기본값을 정면으로 건드리기 때문임

  • 수십 년 동안 오픈소스에선 패치를 보내고, 책임지고, 오래 남는 과정을 통해 신뢰가 생겼음
  • Ladybird는 AI 이후엔 그 경제성이 너무 빨리 바뀌었다고 보는 쪽
  • 특히 브라우저처럼 보안 리스크가 큰 프로젝트라면, 기여를 넓히는 가치보다 코드 유입 경로를 좁히는 가치가 더 크다고 판단한 셈

---

기술 맥락

• Ladybird가 바꾼 건 라이선스가 아니라 코드 유입 권한이에요. 소스는 계속 공개하지만, upstream에 들어갈 변경을 누가 만들고 책임질지는 maintainer로 제한한 거예요. 오픈소스의 ‘공개’와 ‘기여 허용’이 같은 말은 아니라는 걸 보여줘요.

• 이 결정의 배경에는 브라우저의 위험도가 있어요. 브라우저는 인터넷에서 오는 거의 모든 종류의 입력을 처리하고, 그 입력은 기본적으로 믿을 수 없거든요. 그래서 리뷰 부담이 큰 패치 하나가 단순 유지보수 문제가 아니라 사용자 보안 문제로 이어질 수 있어요.

• AI가 문제로 등장한 이유는 코드 작성 비용을 낮췄기 때문이에요. 예전엔 큰 패치를 보내려면 시간과 이해도가 필요했고, 그 자체가 어느 정도 신뢰 신호였어요. 이제는 겉보기엔 그럴듯한 기여를 빠르게 만들 수 있어서, 프로젝트 입장에선 제출물만 보고 사람을 판단하기가 더 어려워졌어요.

• Ladybird가 우회 패치 경로까지 막겠다고 한 점도 중요해요. 공개 PR만 닫고 이메일 패치를 받으면 같은 문제가 다른 입구로 들어오거든요. 그래서 코드 책임의 경계를 흐리지 않으려면, 기여 가능한 영역과 불가능한 영역을 꽤 명확히 나눌 수밖에 없어요.