Ladybird 개발 방식을 바꾸기

요즘 clang에서 기여 리뷰를 하는 일이 너무 비참함. 끝없는 쓰레기 PR이 밀려오고, 사람들은 티 나는 흔적을 더 잘 숨기지만 여전히 대체로 알아볼 수 있고, 그걸 걸러내는 데 시간이 탐
AI 사용을 인정하고 어떻게 썼는지 적는 사람도, 그 말이 사실인지 아니면 사용을 축소해서 나쁜 PR을 통과시키려는 건지 다시 확인해야 함
지금까지 이런 PR을 정말 많이 봤지만, 바이브 코딩 PR 중 실제로 좋았던 건 하나도 못 본 것 같음. 일부는 “괜찮은” 수준이고 작성자가 직접 일을 시작하기도 하지만, 대부분은 사라지고, 나머지는 clang 내부 지식이 없어도 기본적인 코딩 개념부터 완전히 틀린 게 명백함
더 나쁜 경우는 fuzzer→bug→LLM→PR 파이프라인을 자동화한 스크립트로, 실제 버그를 심각하게 오해하고, 망가진 방식으로 “수정”하며, 나쁜 테스트를 붙이거나 원래 실패 케이스조차 안 넣기도 함
결국 새 기여자에게 시간을 들여 역량을 키워주고 싶은 마음까지 줄어듦. 처음 보는 이름이 crash 수정 PR을 올렸을 때, 이게 시간 낭비인지 진짜 기여자가 될 사람인지부터 의심하게 됨
그냥 프로젝트에 쓰레기를 던지는 사람은 기여나 학습에 관심이 없고, 대부분은 이력서에 “clang에 기여” 같은 항목을 넣고 싶어 하는 것처럼 보임

D 웹사이트에는 병합된 PR로 자동 생성되는 기여자 목록이 있는데, 어떤 초보자가 채팅에 와서 그 목록이 어떻게 갱신되는지 묻더니 사소한 PR을 올리고 병합해 달라고 재촉했음
이후에도 계속 와서 “왜 목록이 갱신되지 않지? 왜 아직 내가 없지?”라고 물었고, 웹사이트가 갱신된 뒤에는 사라졌음
다만 나도 어릴 때는 비슷하게 어리석었음. 유명 오픈소스 인물의 웹사이트를 미러링할 수 있다고 해서 미러를 만들고 목록에 넣어 달라고 메일을 보낸 적도 있고, 1337 hax0r가 되겠다고 nmap 개발 메일링 리스트를 구독했지만 패치를 낸 적은 없었음

문제 정의는 모두에게 명확함. 수십 년 동안 오픈소스 프로젝트는 코드 기여를 통해 누구를 신뢰할지 배웠고, 사람들은 일을 하고 변경에 책임을 지며 남아 있었고, 신뢰는 작업 자체에서 생겼음
하지만 이 해결책은 Zig 프로젝트가 선택한 LLM 기여 금지보다 엄격히 더 나쁜 버전이라고 봄
AI 도구가 경제성을 빠르게 바꾸면서, 이제 PR은 제출자에 대해 예전만큼 많은 것을 말해주지 못함. 큰 패치는 예전엔 큰 노력을 의미했고 선의의 대리 지표였지만, 이제 그 가정은 성립하지 않음
걱정되는 점은, 오픈소스는 어려운 사업이고 가치 있는 장점을 최대한 활용해야 하는데, 기여자는 사실상 공짜로 엄청난 가치를 가져오며(contributor poker), 채용 경로로도 매우 중요하다는 것임. 그런데 이걸 전부 거부하는 건 미친 선택처럼 보임
LLM이 그 공백을 채울 수 있다고 주장할 수도 있지만, 첫째로는 신뢰되지 않은 기여자의 PR에서만 LLM 사용을 금지할 수도 있었고, 둘째로 최고의 LLM도 비용이 들며 토큰 가격은 오르고, 코드는 어차피 리뷰해야 하고, 결국 코드베이스 일부를 책임지는 신뢰받는 핵심 기여자가 될 수 없음
PR에서 오는 코드 유입을 제거하면 시간이 지나며 소수 기여자가 전체 코드를 소유하게 되고, 프로젝트가 라이선스 rugpull을 하기 쉬워짐. 저작권 소유가 잘 분산돼 있으면 이런 일은 더 어렵다
전체적으로 좋지 않음. 오픈소스를 불필요하게 더 문제 많은 사업 모델로 만들고, 핵심 기여자 채용을 더 어렵게 하며, 코드 소유를 소수에게 집중시키고 있음. 재앙의 명백한 레시피라서, 단순 실수인지 Ladybird 후원자 중 일부가 이상한 게임을 하는 건지 의심하게 됨

공정하게 보자면 오픈소스가 곧 공개 기여나 커뮤니티 거버넌스와 같은 건 아님. SQLite는 제3자 기여를 전혀 받지 않는 프로젝트의 좋은 예이고, 꽤 잘하고 있어 보임

후원자 목록을 보면 브라우저에서 rugpull로 이득을 볼 집단은 잘 안 보임. 몇몇은 다른 방식으로 문제가 있어 보이지만, 그런 동기는 보이지 않음
진짜 변화의 배경이 궁금함. 매달 상태 보고서 앞부분에서 다양한 신규 기여자 수를 자랑하던 프로젝트가 이렇게 갑작스럽게 방향을 바꾼 건 매우 급격한 전환임. 지금 내놓은 설명은 적어도 불완전해 보임

SUSE라는 상업 배포판 회사에서 오픈소스와 인접한 일을 하고 있고, 일은 브라우저·컴파일러·데이터베이스를 직접 쓰기보다는 그 하위 버전을 유지보수하는 쪽임. 내 관점과 한계는 거기서 나온다고 보면 됨
Zig와 Ladybird 모두 우리가 원하지 않았던 미래에서 앞으로 나아갈 방법을 찾고 있음. 몇 년 동안 아무것도 모르고 있었고 솔직히 이런 미래가 올 줄 몰랐음. 이제 “옳은 일”이 무엇인지 전혀 명확하지 않음
Zig에 묻고 싶은 건, LLM PR과 사람이 직접 만든 PR을 구분할 수 없다는 점임. 저노력 쓰레기는 걸러낼 수 있지만, “AI 금지”를 하려면 일종의 튜링 테스트를 통과해야 하는데, 나와 Claude Pro 라이선스라면 충분히 통과할 수 있음
“AI 금지”가 실제로 하는 일은, 누군가 LLM 코드를 보내놓고 수작업이라고 주장하다 걸렸을 때 그 사람과 평판을 공격할 수 있게 하는 것임. 이런 데 시간을 쓰고 싶은가? 손코딩을 가장하고 LLM을 쓰는 사람을 잡아내는 Karl Jobst 같은 존재가 생기는 셈임
LLM PR을 막지는 못하고, 게임을 “잡을 수 있으면 잡아봐”로 바꾸는 것뿐임. Ladybird에서 Andreas가 rugpull에 가까운 결정을 하는 걸 보고 처음엔 등골이 서늘했고, 다음엔 배짱은 있다고 생각했음. LLM 보조와 신뢰는 정말 큰 문제라서, Zig와 Ladybird 양쪽이 틀 밖에서 생각하는 모습을 보고 싶음

Ladybird 조직의 정관(https://ladybird.org/assets/documents/…)을 보니 Christopher Wanstrath가 공동 BDFL이라는 걸 알고 실망했음. 전에는 100만 달러를 기부하고 조직 설립을 도운 정도라고 생각했음
실제로는 Designator이고, 내가 읽기로는 사임하거나 무능력 상태가 되지 않는 한 평생 그 지위가 보장됨. Designator는 다수결로 결정하는데 2명뿐이면 둘 다 동의해야 하며, 이들이 Directors를 지정·해임하고 정관 변경에도 동의가 필요함
즉 그는 비영리 조직에 대해 견제 없는 거부권을 사실상 가진 셈임. Andreas도 마찬가지지만 Andreas는 작업의 상당 부분을 만든 사람이고 프로젝트에 관여하며 억만장자가 아님. Wanstrath는 억만장자이고 재산의 극히 일부를 기부하기로 했으며 운영에는 관여하지 않는데도 같은 권한을 가짐
내가 놓친 좋은 법적 이유가 없다면, 오픈소스 프로젝트에 좋은 거버넌스 구조로 들리지는 않음

최근 기여를 닫은 프로젝트들이 장기적으로 어떻게 될지 걱정됨. 어느 시점엔 신뢰받는 핵심 인력 중 일부가 떠날 텐데, 검증된 장기 기여자가 없으면 명확한 후임이 없을 수 있음
기본 경로는 번아웃과 방치된 프로젝트로 이어질 수 있으니, 이를 극복할 방법을 찾길 바람

LLM 열풍이 안정되거나 식고, 또는 다른 프로젝트들이 “기여” 폭주를 지속 가능한 방식으로 처리하는 방법을 찾아내길 바람. 그래서 이건 일시적일 거라고 봄. 글도 안정 릴리스 이후에는 계속 이렇게 남을 생각이 없다는 뉘앙스임

이걸 어떤 종류의 리더십으로도 보지 않음. 올바른 방향으로의 한 걸음도 아니고, 우리가 함께 살아갈 방법에 대한 아이디어도 아님
압박이 실제라는 건 알지만, 대응이 활기차고 희망적이기보다 냉소적이고 패배주의적으로 느껴져 실망스러움

왜 올바른 방향이 아니라고 보는지 궁금함

“이번 변경의 일환으로 현재 열려 있는 모든 공개 pull request를 닫겠다”는 부분은 충격적임
몇 년 전 어떤 프로젝트가 PR을 리뷰할 리소스가 없다고 결정하면서 내 PR을 닫은 적이 있는데, 꽤 아프고 해당 PR에 작업을 들인 기여자에게 공정하지 않음

마음이 상할 수는 있겠지만, 유지보수자가 실제로 그 PR 작성을 요청한 게 아니라면 불공정하다고 부르기는 어렵다고 봄

요청하지 않은 작업을 누군가 리뷰해주길 기대하는 건 공정하지 않음

제시된 이유는 이해되지만 결정은 걱정됨. 반드시 나쁘다는 건 아니고, 일시적이며 나중에 다른 절충점을 찾는다면 괜찮을 수도 있지만 그래도 우려됨
첫 번째 걱정 신호도 아님. LLM 보조 Rust 재작성도 비슷하게 느꼈음. Bun과 달리 비교적 조심스럽게, 리뷰 가능한 크기의 컴포넌트와 명확한 입력·출력, 기존 컴포넌트와 병렬 실행으로 불일치를 잡는 방식이긴 했음. 그래도 브라우저 엔진에서 보고 싶은 방식은 아님
Ladybird가 잘되길 바람. 새로운 브라우저 엔진이 과점 구조에 도전하길 원함. 하지만 Ladybird가 엇나갈 경우를 생각하면, 몇 년간 정체됐던 Servo가 잘 진전되고 있는 것도 다행임

나는 Servo를 응원함. Ladybird를 이끄는 사람이 누구인지, 그리고 그가 가진 견해를 떠올려보면, 성공하더라도 내 머신에서 가장 중요한 애플리케이션 중 하나 뒤에 그런 사람들이 있길 원하지 않음. 적어도 지금은 이런 정책도 있음

Rust 구현에 AI 쓰레기 코드를 쓰고, DHH를 지지하는 쪽, 즉 백인우월주의와 반LGBT 쪽으로 보이며, 꽤 공격적으로도 보임. 이 프로젝트가 멀리 갈 것 같지 않음

외부에서 기여자가 될 수 있는 진입 경로가 없다면 많은 걸 놓칠 것 같음. 단순히 지나가다 PR을 던지는 것보다 더 진지한 약속이 필요하더라도 말임
그렇게 해야 개발자를 추가하려 할 때 코드베이스를 아는 인재 풀이 늘어나고, 핵심 팀이 우선순위로 두지 않는 필요를 외부 조직이 해결할 수도 있음. 이는 채택에도 도움이 되고 작업 부담도 줄여줌

이 글에 vibecoding 태그를 붙이는 건 맞지 않아 보임. 바이브 코딩의 피해자를 그 행동을 홍보하는 사람들과 같은 태그로 묶는 건 근본적으로 이상함

이 글만 보면 빠져 있는 맥락이지만, 최근 다른 글과 배경을 읽어보면 PR을 닫는 이유가 바이브 코딩 PR의 확산 때문이기도 하고, 동시에 그들 자신이 주로 바이브 코딩으로 전환하고 있기 때문이기도 함. 최근 C++에서 Rust로의 바이브 코딩 포팅도 참고할 만함