---
title: "레이디버드, 공개 풀 리퀘스트 중단 “브라우저 보안 모델에 안 맞다”"
published: 2026-06-05T07:26:33.000Z
canonical: https://jeff.news/article/3716
---
# 레이디버드, 공개 풀 리퀘스트 중단 “브라우저 보안 모델에 안 맞다”

오픈소스 브라우저 프로젝트 Ladybird가 앞으로 공개 풀 리퀘스트를 받지 않겠다고 발표했다. 코드는 계속 공개되지만, 코드베이스에 들어가는 변경은 maintainer만 만들 수 있게 바뀐다. 이유는 꽤 직설적이다. AI 도구 때문에 ‘큰 패치를 보냈다’는 사실이 더는 신뢰의 증거가 아니고, 브라우저는 그 리스크를 감당하기 너무 위험하다는 판단이다.

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

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

> [!IMPORTANT]
> Ladybird의 결정은 “AI 코드라서 싫다”가 아님. 코드가 손으로 작성됐는지가 아니라, 그 코드가 브라우저에 들어간 뒤 누가 책임질 수 있느냐가 핵심임.

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

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

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

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

> [!NOTE]
> 이 결정은 모든 오픈소스 프로젝트에 그대로 적용될 만한 일반론은 아님. 하지만 브라우저, 런타임, 패키지 매니저, 보안 도구처럼 공격 표면이 큰 프로젝트라면 꽤 진지하게 볼 만한 신호임.

---

## 기술 맥락

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

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

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

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

## 핵심 포인트

- Ladybird는 첫 알파 릴리스를 앞두고 공개 풀 리퀘스트를 전면 중단
- 현재 열려 있는 공개 풀 리퀘스트도 모두 닫을 예정
- 이슈, 댓글, 이메일, 포크를 통한 우회 패치 제출 경로도 만들지 않겠다고 명시
- 버그 리포트, 축소 재현, 웹사이트 테스트, 표준 논의, 보안 제보 같은 외부 참여는 계속 환영

## 인사이트

AI 코딩 시대의 오픈소스 신뢰 모델을 정면으로 건드린 결정이다. ‘오픈소스면 누구나 패치 보내는 게 당연하지’라는 문화와, 브라우저처럼 공격 표면이 큰 소프트웨어의 책임 모델이 충돌한 사례로 볼 만하다.