Ladybird 개발 방식 변경

• Ladybird는 첫 alpha release와 실제 사용자용 브라우저 출시 준비에 맞춰 공개 pull request 수락을 중단하고, 코드 변경을 프로젝트 유지관리자만 도입하기로 함
• AI 도구로 진지한 기여처럼 보이는 작업을 더 빠르고 싸게 만들 수 있게 되면서, 큰 패치가 선의나 상당한 노력을 보여준다는 기존 신뢰 모델이 약해짐
• 브라우저는 인터넷 전체의 신뢰할 수 없는 입력을 사용자 머신에서 실행하므로, 잘 위장된 취약점 하나만으로도 공격자에게 충분함
• 현재 열려 있는 공개 PR은 모두 닫히며, issues·comments·email·forks를 통한 별도 패치 제출 절차나 그림자 기여 시스템을 만들지 않기로 함
• Ladybird는 오픈소스로 남고, 외부 참여는 코드 제출 대신 명확한 버그 보고, 축소 재현, 웹사이트 테스트, 표준·디자인 논의, 보안 보고, 기술 피드백으로 이어지는 방향임

---

개발 절차 변경의 핵심

• Ladybird는 앞으로 공개 pull request를 수락하지 않고, 코드베이스 변경을 프로젝트 유지관리자만 도입하는 방식으로 전환함
• 첫 alpha release를 준비하는 단계에서 더 엄격한 개발 절차, 더 명확한 보안 모델, 브라우저에 들어가는 코드에 책임지는 더 작은 집단이 필요해짐
• 과거에는 상당한 패치가 상당한 노력과 선의를 보여주는 합리적 대리 신호였지만, AI 도구로 그 가정이 더 이상 성립하지 않게 됨
• 브라우저는 인터넷의 신뢰할 수 없는 입력을 사용자 머신에서 실행하며, 잘 위장된 취약점 하나만으로 공격자에게 충분한 조건이 됨
• 오픈소스에서 유지관리자 신뢰를 얻고 남용하려는 인내심 있고 자원이 있는 캠페인이 이미 있었으며, 진지한 기여처럼 보이는 작업을 더 빠르고 싸게 만들 수 있게 된 점이 달라짐
• Ladybird에 들어오는 모든 변경은 아키텍처에 맞고, 미래 리팩터링을 견디고, 브라우저 나머지 부분과 올바르게 상호작용하며, 유지관리자가 이해할 수 있어야 함
• 코드가 손으로 작성됐는지는 핵심이 아니며, 브라우저에 들어간 뒤 누가 책임지는지가 핵심임

전환 조치와 계속 가능한 참여

• 현재 열려 있는 모든 공개 pull request는 닫히며, 기존 대기열을 유지하면 실제로 공개 기여 경로가 계속 열려 있게 되므로 지금 전환하기로 함
• 앞으로 pull request는 프로젝트 유지관리자에게만 제공됨
• issues, comments, email, forks를 통한 별도 패치 제출 절차를 만들지 않으며, fork나 patch dump를 upstream Ladybird의 review queue로 취급하지 않음
• 외부 코드는 라이선스 조건에 따라 존재할 수 있음
• Ladybird는 오픈소스로 남고, 소스 코드는 오픈소스 라이선스에 따라 계속 공개됨
• 외부 참여는 명확한 bug reports, reductions, website testing, standards discussion, design discussion, security reports, technical feedback을 통해 프로젝트 진행에 도움을 줌
• 실제 사용자에게 브라우저를 출시하려는 준비 단계에서는 개발 절차도 그 책임에 맞아야 함

[GN⁺]

Hacker News 의견들

• 최근 Godot 같은 큰 오픈소스 프로젝트의 PR을 많이 보고 있는데, 코드와 설명이 전부 AI가 만든 PR이 꽤 늘었음
  프로젝트 정책상 금지라서 보통 제출자는 가볍게 주의를 받는데, 많은 사람은 잘 받아들이는 반면 일부는 유지보수자에게 고마워하지 않는다고 화를 냄
  AI에 완전히 올라탄 사람들조차 코드 덩어리를 만들어내는 것 자체에는 본질적 가치가 없다는 점을 아직 내면화하지 못한 듯함
  본인이 들인 노력은 크게 줄었는데도, 큰 PR을 냈을 때 AI 이전과 같은 반응이나 감사를 기대함

  • AI 이전의 반응도 꼭 정당했던 건 아님. 유지보수하기 어려울 수 있는 대량의 수기 코드 커밋이 반드시 긍정적 기여는 아니고, 괜찮은 엔지니어나 그냥 보통 사람이라면 노력의 양과 관계없이 감사를 기대하지 않을 것임
    그런 맥락에서, 이 업계에 원래 너무 많았던 태도 나쁜 사람들이 AI 이후에 행동을 바꿀 거라고 기대하지 않음
    참고로 내 직장의 비기술직 직원이 내가 관리하는 내부 저장소에 AI 생성 PR을 내기 시작했는데 품질이 훌륭하고, 리뷰 피드백도 잘 받아들이고 빠르게 반영함. 기술직이 아니라서 생기는 문제가 아니라 태도 문제임
  • 일부 바이브 코딩 쪽에는 일종의 권리의식이 확실히 있음. 정확한 단어는 아니지만, 산출물에 집착하고 대부분의 작업이 자기 것이 아니었다는 걸 받아들이지 못하는 태도에 가까움
    기여 방식뿐 아니라 평소 말에서도 드러남. “내가 X를 만들었다”, 자기 “큐레이션”이 결과에 매우 큰 영향을 줬다는 고집, LLM의 기여를 말하기 어려워함, “나는 만드는 데 집중하고 남들은 세부사항에 시간을 낭비한다”는 태도, 잠재적 결함과 마주하기를 거부하는 모습 등이 있음
    자신이 만든 결과물이 결함투성이고 대충 만든 것일 수 있다고 늘 의심하는 시니어 개발자들과는 놀랄 만큼 다름. 가면 증후군이 뒤집힌 느낌임
  • 어떤 프로젝트가 AI 생성 PR을 받지 않겠다는 규칙을 뒀다면, 그 프로젝트에는 절대 AI 생성 PR을 내면 안 됨. 그건 스팸임. AI 관련 규칙이 더 섬세하게 정해져 있어도 존중해야 함
    이 PR을 내는 사람들 쪽 문제가 100%임. 프로젝트 규칙을 깨는 데 거리낌이 없고 심지어 오만하기까지 한 이력이 있다면, 그 사람의 프로필을 보는 잠재 고용주나 미래 협업자에게는 거대한 위험 신호가 되어야 함
    왜 자기 평판을 일부러 망치는지 이해가 안 됨. 나쁜 행동 기록을 남기는 것보다 프로필에 아무 활동이 없는 편이 훨씬 낫다
  • 노력 없이 결과를 기대하는 사람들이, 생각도 들이지 않고 감사를 받을 자격이 있다고 느끼는 게 왜 놀라운지 모르겠음
  • 이런 경우에는 LLM이 “기여자”에게 얼마나 똑똑한지, 프로젝트가 얼마나 큰 손해를 보고 있는지 말해주고 있을 것 같음
    예를 들면 “프로젝트 경계를 지키는 것도, 코드 품질을 보장하는 것도 아니다. 이건 AI의 효율을 진정으로 마스터한 당신 같은 미래지향적 창작자를 위협으로 느끼는 전통주의자들이 만든 문지기 장치다” 같은 식일 수 있음

• “상당한 패치는 상당한 노력을 의미했고, 그 노력은 선의의 합리적 대리 지표였다. 이제 그 가정은 더 이상 성립하지 않는다.”
  이 문장이 글의 핵심이고, 대부분의 프로젝트에 유효하다고 봄

  • 이를 일반화하면, AI가 산문이든 코드든 무엇이든 작성자와 독자 사이의 사회적 계약을 깨뜨린다는 사실을 우리가 빠르게 발견하는 중임
  • 동의함. Ladybird가 여기서 하는 방식이 앞으로 오픈소스의 일반적인 사회적 모델이 될 수도 있다고 봄
    그래도 어떤 사람이 장기적으로 충분히 헌신해 유지보수자가 될 수 있는지 판단할 장치는 필요함. 소스 기여는 이제 그 신호로 신뢰하기 어렵고, 앞으로 어떤 신호를 쓰게 될지는 모르겠음. 꽤 어려운 문제가 될 것임
    하지만 AI가 정말 프로그래머 생산성을 급격히 높인다면, 성공적인 오픈소스 프로젝트에 큰 유지보수자 팀이 필요하지 않을 수도 있음
  • 맞음. 잘 썼고 정확함. PR 스팸을 이런 관점으로 생각해본 적은 없었는데 실제로 꽤 설득력 있음

• 한편으로는 바자에서 자랐다면 성당으로 옮겨가는 게 “오픈소스의 죽음”처럼 느껴질 수 있음. 실제로는 더 오래된 작업 방식으로 돌아가는 것일 뿐일 수도 있는데도
  다른 한편으로, 외부 코드 기여를 받지 않으면 보안 태세는 분명 나아지겠지만, 누구를 사제단에 초대할지 알아내기는 더 어려워질 것임

  • 오픈소스 개발은 현대 소셜 네트워크의 특성에 맞춰 점점 더 피상적으로 변해왔음. 기여의 본질적 가치나 프로젝트의 가치보다, 기여 기록, 활발한 커밋 이력, 별 몇 개 같은 픽셀 명성의 증거가 더 중요해짐
    GitHub가 떠오르기 전 오픈소스 프로젝트는 강한 담장 안의 정원에 가까웠음. 방에 들어가면 빤히 쳐다보는 작은 클럽들 같았음. GitHub는 접촉을 상품화했고, 기여하기 전에 들여야 하는 노력이나 관심의 장벽을 낮췄음
    이제 그 시기는 끝났고, 무엇에든 기여하기 전에 신뢰를 먼저 쌓아야 함
    이건 오픈소스의 죽음이 아니라, 모두가 자유롭게 돌아다니고 쉽게 상호작용하던 지구촌의 죽음임. 작고 사회적이며 신뢰 기반인 공동체의 부활이고, 이 흐름이 인터넷 전체로 퍼지면 좋겠음
  • 이제 “모든 것”이 오픈소스이고 바자 방식으로 개발되던 세상을 본 적 없는 코더 세대가 통째로 있다는 사실에 아직도 익숙해지지 않음
    요즘 사람들은 그 은유나 Raymond의 책을 알기나 할까? Microsoft가 주요 오픈소스 공급자이고 지구상 오픈소스 프로그래밍 대부분을 가능하게 하는 플랫폼을 맡고 있는 세상임. 90년대 후반에서 온 시간 여행자에게 설명해보라
    또한 형제 댓글이 암시했듯, Linux 커널 같은 전형적 “바자”도 지금은 GitHub의 무제한 난장판 모델과 비교하면 꽤 성당처럼 보임
  • 이 발표가 말하려는 핵심은, AI 때문에 외부 기여가 사제단 초대 대상을 찾는 신호로서 이미 거의 무가치해졌다는 것임
  • SQLite와 그 형제 프로젝트들(Fossil 등)을 보면 성당 방식으로도 잘 굴러가는 훌륭한 오픈소스 프로젝트가 있음
    그래서 Ladybird의 결정을 문제로 보지 않음. 오히려 소프트웨어 개발의 인간적 측면을 강화하고, AI 무임승차자들에게 브레이크를 거는 결정이라고 봄
  • 누군가 프로젝트를 포크하고, 자기 패치를 그 포크에 넣는 방식은 어떨까. 포크가 성공해서 실제 사용자가 활발히 쓴다면, 업스트림은 필요한 패치를 선택적으로 가져갈 수 있음. 포크 유지보수자도 결국 인정받게 됨
    이상적이진 않지만, 평판을 쌓는 일은 원래 시간이 걸리는 게 맞음

• 이런 걸 보면 AI가 아예 없었으면 좋겠다는 생각이 듦
  오픈소스 프로젝트가 새 유지보수자를 찾고 멘토링할 능력을 잃는 건 너무 실망스러움

  • 그들은 자기 프로젝트의 큰 변경을 LLM으로 다시 작성했음
  • 이게 정말 AI와 얼마나 관련이 있는지 모르겠음. 오픈소스와 유지보수자 문제는 아주 오래전부터 있었음

• “어떤 수단으로도 패치를 제출하는 절차는 없을 것이다”와 “외부 참여는 여전히 중요하다: 명확한 버그 보고”라니
  그러면 버그를 찾고 고칠 수는 있지만, 정확히 어떻게 고쳤는지는 말하면 안 된다는 건가
  대신 팀이 다시 알아내야 함. 이미 다른 사람이 반복해서 해낸 일을 다시 해야 한다니 팀이 정말 신나겠음
  사용자이자 개발자로서, 내 삶을 개선할 수 있는 소프트웨어에 이런 장벽을 두는 프로젝트에 왜 시간을 들여야 하는지 모르겠음. 내 수정이 실제로 받아들여질 수 있는 Firefox나 Chromium을 쓰는 편이 훨씬 쉬워 보임
  과거에 새 Chromium 버전이 내 제품에서 크래시 났을 때, V8에 수정안을 제안할 수 있었고 다음 Chromium 릴리스에 반영되어 제품이 다시 동작한 경험은 매우 유용했음(https://github.com/v8/v8/commit/4f8a70adca01c)
  이런 통로가 없었다면 Chromium 개발자들이 시간이 부족해 원인을 파악하지 못하고 고치지 않았을 수도 있음
  “풀 리퀘스트는 더 이상 제출자에 대해 예전만큼 많은 것을 알려주지 않는다”지만, 풀 리퀘스트를 낸 사람에 대해 누구도 알 필요가 없어야 함
  Firefox나 Chromium에 들어가는 코드가 제출자의 “노력”이나 “선의”가 아니라, 리뷰에서 확인된 코드의 정확성을 기준으로 결정되길 바람
  코드 수정 리뷰는 직접 생각해내는 것보다 명백히 쉬움. 그렇지 않은 상황이라면 그냥 직접 코드를 쓰면 끝임
  프로젝트 입장에서는 언제든 원치 않는 PR을 무시하거나 닫을 수 있음. 하지만 외부 기여를 리뷰하거나, 자기 재작성의 입력으로 쓸 선택지 자체를 막는 건 현명하지 않아 보임

  • 문제 지점을 정확히 짚어내는 것은 코드보다 훨씬 가치 있음. 수정 코드를 썼다면 이미 버그를 분석한 것임. 가치는 수정 코드가 아니라 분석에 있음
    그 정교한 분석을 공유하는 것이 기여를 극대화하는 방법임. 코드는 많아야 선택적 보너스에 가깝다
  • PR 코드 리뷰는 노력 없는 행동이 아님. 프로젝트에 3명이 일하고 있는데 수천 명이 버그 수정 PR을 낸다면, 그 수정이 아무리 유용해도 3명은 PR 수 자체에 완전히 압도됨
    네 버그 수정에 가치가 있을 수는 있지만, 그 가치가 리뷰하고 받아들이는 비용보다 크지 않을 수도 있음
    “코드 수정 리뷰는 직접 생각해내는 것보다 명백히 쉽다”는 말은 충분히 복잡한 프로젝트에서는 완전히 틀림. 수정은 한 줄일 수 있어도 결과는 멀리까지 영향을 줄 수 있음
    사용자이자 개발자로서 그런 규칙의 프로젝트에 시간을 들이고 싶지 않다면, 들이지 않으면 됨. 너도 프로젝트에 빚진 게 없고, 프로젝트도 너에게 빚진 게 없음. 그만큼 단순함
    Firefox와 Chromium은 훨씬 큰 팀으로 운영되고, Linux 커널은 말할 것도 없음. 그들은 네 기여를 받아들일 여력이 있을지도 모름
  • “제출자에 대해 알 필요가 없고, 리뷰에서 코드의 정확성만 보면 되며, 코드 수정 리뷰는 직접 만드는 것보다 쉽다”는 말을 사실처럼 말하지만, 이는 오픈소스 유지보수자들의 실제 경험과 완전히 반대임
    내 경험과 원문 사례뿐 아니라 비슷한 글을 공유한 수많은 유지보수자의 경험도 그렇다
    이 문제에 대한 전문성의 근거가 되는, 수년간 유지보수하고 기여를 리뷰해온 오픈소스 프로젝트 링크를 공유해줄 수 있나?
  • 어떻게 했는지 여전히 말할 수 있음. 다만 코드나 패치 형태가 아닐 뿐임
    유지보수자가 해결 접근 방식을 이해할 수 있도록 자연어 설명으로 적으면 됨
  • “나에게 매우 유용했다”는 말이 핵심임. 너는 다른 사람들이 네 필요를 충족하기 위해 바뀌길 원함
    그들의 우선순위와 필요는 다름. 이 경우에는 평가해봤고 유용하지 않다고 판단된 것임. 비용이 이익보다 컸다는 뜻임

• 적어도 한 가지 중요한 면에서는 Chromium/Gecko/WebKit이 이제 Ladybird보다 더 “열린” 브라우저 엔진처럼 보인다는 게 흥미로움
  Servo는 AI를 쓰지 않는 한 외부 기여를 받으니 중간쯤이라고 볼 수 있음
  자금이 많지 않은 팀이 노동 비용을 아끼기 위해 기여를 닫아야 한다는 건 이해됨. 하지만 Google/Mozilla/Apple이 개방성을 가능하게 하려고 투입하는 경제적 자원에 대해 사람들이 충분히 인정하지 않는다는 느낌도 듦
  개인적 편향과 경험을 밝히자면, 지금은 은퇴했지만 예전에는 Google에서 Chrome을 만들었음. 많은 동료들이 외부 기여자를 키우는 모습을 봤고, 나도 비공식적으로나 인턴십 같은 프로그램을 통해 일부 해봤음

  • 그런 기업들은 선의로 그러는 게 아님. 자기 사업 가치를 보호하려고 통제력을 확보하기 위해 하는 것임. 경제성이 사라지면 내일이라도 멈출 것임
    독점 구축에 영원히 감사해야 한다고 생각하지 않음
  • Chrome은 Google의 손실 유도 상품임

• 왜 그런 결정을 하는지는 이해할 수 있음. 대부분의 풀 리퀘스트가 AI로 작성된 코드라면, 유지보수자도 Claude Code에 직접 프롬프트를 넣을 수 있음
  오픈소스든 아니든 소프트웨어 공학이라는 게임 전체가 완전히 바뀌었다고 봄. 코드 덩어리가 2년 전과 같은 것을 의미하거나 암시하지 않음

  • 이게 핵심이라고 봄
    몇 년 전에는 내가 컴파일되고 테스트를 통과하는 복잡한 PR을 보내면, 내가 그만큼 시간과 인지적 투자를 했다는 뜻이었음. 코드베이스, 기능 또는 버그를 이해하지 않았다면 그런 투자를 하지 않았을 가능성이 큼
    이제 그 이해를 얻는 비용은 대체로 예전과 비슷하지만, AI가 컴파일되고 테스트를 통과하는 코드를 생성하는 비용을 크게 낮췄음
    선의일 가능성이 높은 커뮤니티 구성원들은 싼 것, 즉 Claude Code 토큰을 기꺼이 기여하지만, 그게 너무 싸졌기 때문에 비싼 것인 인간의 이해를 기여했다는 좋은 지표가 되지 못함
  • “AI 생성 코드는 가치가 없다”는 식의 입장을 종종 봄. 가치 0인 코드를 만들기 쉬운 건 맞지만, 모든 AI 생성 코드가 가치 0이라는 데는 동의하지 않음
    나는 OpenCode로 사이드 프로젝트를 작업하고 있고, 꽤 많은 시간을 들여 프롬프트를 쓰고, 적절한 파일을 세팅하고, 만들려는 제품과 로드맵을 설명함
    변경 후 자동 검사를 많이 돌릴 수 있는 촘촘한 검증 루프를 갖추고, 생성된 기능이 망가뜨릴 수 있는 경계 사례를 수동으로 많이 테스트한 뒤 반복함. 다른 종류의 일이지만, 손으로 코딩할 때보다 더 빨리 진전할 수 있음. 핵심 구성 요소는 검증 루프임
    지난 몇 달간의 경험상 AI로 코딩하는 것도 기술이고, 시도하면서 새 기법을 배우고 더 나아짐. 잘하면 가치 있는 결과를 만들 수 있다는 뜻이기도 함
    그래서 첫 문장에는 이견이 있지만, 두 번째 문장에는 완전히 동의함. 우리가 잃은 것은 깊이 생각한 결과와 생각 없이 생성한 결과를 쉽게 구분하는 능력임. 여기서는 저렴한 검증에 집중하는 것이 큰 도움이 될 것임
  • 코드는 이제 작업의 주된 노력이 아님. 누구나 구현을 생성할 수 있으니, 어떤 코드 변경의 바탕이 되는 무엇을, 왜, 어떻게를 더 치열하게 다루는 편이 그 어느 때보다 합리적임
    모든 프로젝트가 이 방향으로 갈 것 같음. 함께 계획을 다듬는 편이 더 말이 됨
  • 말하듯이 차라리 프롬프트를 보내달라는 쪽이 더 유용함

• AI가 처음 등장했을 때 언젠가 직장을 잃을까 봐 두려웠음. 나는 운이 좋았지만 많은 사람이 실제로 잃었고, 그건 많이 아팠음
  자동화로 누군가 무언가를 잃을 때는 경제 논리와 관계없이 인간 편을 들거나, 적어도 가장 큰 영향을 받는 사람들에게 사회가 계속 공정하기를 바라게 됨
  이제는 커뮤니티가 영향을 받는 걸 봄. PR을 죽이면 코드 기여뿐 아니라 아이디어, 코드에 대한 더 많은 시선 같은 비가시적 기여도 크게 흔들림. 그게 훨씬 더 나쁘게 느껴짐
  나는 갈등하고 혼란스럽고 두려움. 그런데도 Claude와 DeepSeek, 각종 기술, 복잡한 하네스와 MCP 등등을 쓰고 있음. 하지만 지금은 전부 전환기처럼 보임. 대체 무엇으로의 전환인지 모르겠음
  많은 질문은 삶에 의미를 부여하지 않으면 답할 수 없음. 인간적 손길? 이미 늦었나? 또, 어떤 노래를 좋아했는데 Suno였음. 알고 나서 좋아요를 취소했음. 스스로가 너무 자주 멍청하게 느껴짐
  두서없는 탈선이라 미안함. Ladybird를 좋아하고, 노트북에 스티커도 붙어 있음. 잘 되길 바람

  • “이 모든 게 전환기처럼 보인다. 대체 무엇으로의 전환인가?”라는 말에 공감함
    토네이도 한가운데 있는 느낌임. 그래도 화면을 끄고 책상에 앉아, 침착하게 제1원칙을 떠올리며 천천히 생각하는 게 도움이 됨
    Obama의 말을 빌리면 “현실은 결국 따라잡는다”
    말은 많지만 iOS가 매년 10년치 기능과 수정을 내놓고 있지는 않음. 말 그대로 아무도 그렇게 못 하고 있고, 오히려 기존 기능이 망가진다는 불평이 나옴. 그러니 우리가 10배 생산성에 도달했다는 말은 사실일 수 없고, 이 사실은 결국 우리를 따라잡을 것임
    인간답게 생각해야 함. 많은 사람이 감정적으로 투자되어 있다는 점도 기억해야 함. 주니어들은 자신을 거부한 시장에서 빛날 기회가 되길 원함. CEO들은 AI에 베팅했고 되돌리고 싶어 하지 않음. 시니어들은 자신이 쓸모없어진 게 아니라는 신호를 보내고 싶어 함. AI 회사들은 담론을 오염시킬 것임. 하지만 이 연기는 결국 걷힐 것임
  • 이런 “기여”가 소량 존재하긴 했지만, 대부분은 실제로 말한 것과 달랐음
    대체로 원치 않는 의견, 적대적 인수 시도, 가치 추출, 일반적인 드라마, 그리고 그냥 코드를 만드는 일에 얹히는 전반적 운영 부담으로 귀결됐음
    항상 그랬던 건 아니지만, GitHub식 자유 오픈소스 개발 모델과 모든 마찰의 제거가 분명 새 기본값을 만들었음
    그 모델은 원래 지속 불가능했지만, 소진 속도가 충분히 낮아 지친 사람들을 더 많은 인간으로 대체하며 버틸 수 있었음
    AI가 소진 속도를 대체 속도보다 높여버렸음. 그래서 더 많은 프로젝트가 이런 입장이나 비슷한 입장을 택하게 될 가능성이 큼
  • 어떤 것에 대해 상충된 감정을 갖는 건 아주 정상이고, 곧바로 문제를 뜻하지 않음. 극히 인간적인 일이고 나도 비슷하게 느낌
    나는 창작자이자 프로그래머인데, 어떤 커뮤니티에서 벌어지는 일을 보기 싫어하면서도 개발에는 에이전트를 씀. Google과 Stack Overflow가 처음 나왔을 때 피하기 어려웠던 것처럼, LLM에도 명확한 전후의 순간이 있는 것 같음
    딱히 유용한 말을 더하긴 어렵지만, 이런 갈등을 느끼는 게 혼자가 아니라는 점은 말하고 싶음. 새로운 것들은 보통 그렇다. 어떤 영역에서는 엄청난 이익을 주지만 다른 곳에서는 인간성을 벗겨내는 듯하고, 어떤 사람들은 허세와 쓰레기를 만들지만 다른 사람들은 새 능력을 얻어 더 나은 것을 만듦. 안타깝게도 보편적 진리는 없는 것 같음
  • 언제든 멈출 수 있음. 피해를 보는 게 다른 사람일 때는 많은 사람이 별 신경을 쓰지 않는다는 게 불행한 현실이지만, 이제 개인적으로 소중히 여기는 것을 파괴하고 있다면 왜 그걸 도덕적으로나 재정적으로 계속 지원해야 하나?
  • 사설 LLM을 사용하고 지원하는 일이 결국 OpenAI/Anthropic/Google 등을 더 부자로 만들 뿐이라는 사실도 마음을 편하게 해주지 않음. 나는 그 사용을 정당화할 수 없음

• 이 글을 읽고 묘한 뒷맛이 남음. 작성자가 종종 1천 줄이 넘는 비사소한 PR을 만들고, 때로는 하루에 여러 개씩 만들며, 리뷰 없이 당일 병합하는 경향이 있기 때문임
  LLM 측면을 빼고 봐도 그렇다. 그중 몇 퍼센트가 도움을 받은 건지는 모르지만, 설령 0%라 해도 내가 편하게 느낄 개발 속도는 아님

  • 여기서 한 말과 완전히 일관됨
    “코드를 손으로 쳤는지는 핵심이 아니다. 중요한 것은 코드가 브라우저에 들어간 뒤 누가 책임지느냐다. Ladybird는 실제 사용자를 위한 브라우저가 되어가고 있다. 변경을 도입하는 사람은 그 변경이 프로젝트에 속한다고 결정하고, 그 결과에 답할 사람이어야 한다.”
  • 이런 일을 하는 일부 오픈소스 프로젝트 유지보수자들에 대한 신뢰를 잃었음
    회사에서 수년간 사용해온 오픈소스 플랫폼이 있는데, 유료 Enterprise 버전을 쓰고 있음. 그 플랫폼에 꽤 기괴한 보안 결함이 들어갔고, 살펴보니 AI가 프로젝트를 장악했다는 걸 알 수 있었음
    명시되어 있든 아니든 커밋 로그만 봐도 양과 빈도로 명확히 보임. 매우 실망스러웠음
  • 그의 Github 페이지 [1]도 어느 정도 맞아떨어짐. 커밋 83%, PR 14%, 리뷰 2%, 이슈 1%임. 명백히 통제 불능임
    [1] https://github.com/awesomekling

• LLM이 Ladybird의 이 결정을 이끈 이유 중 하나일 수는 있지만, 유일한 가능한 이유는 아님. 예를 들어 SQLite는 거의 처음부터 계속 이런 방식으로 개발되어 왔음
  각자 방식이 있는 것 같음

  • Lua도 기억이 맞다면 비슷함. 오픈소스이지만 열린 개발은 아님
    MIT 라이선스이고 유지보수자들은 버그 보고에 항상 감사하지만, 프로젝트의 모든 코드는 단 3명이 작성했음
  • 여기서 뭐가 큰일인지 모르겠음. 최고의 소프트웨어 중 일부는 헌신적인 아주 작은 그룹이 만들고 유지함
    자기 시간과 프로젝트를 보호하기 위한 완전히 합리적인 움직임

[GN⁺]

Lobste.rs 의견들

• 요즘 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로의 바이브 코딩 포팅도 참고할 만함