https://kristoff.it/blog/contributor-poker-and-ai/에 따르면, LLM 기반 기여는 대체로 부정적이었다고 함
가치 없는 drive-by PR이 환각 코드로 배경 소음을 늘렸고, 컴파일도 안 되거나 CI를 통과하지 못했으며, 처음 기여하는 사람이 1만 줄 PR을 보내는 일도 있었음
겉보기엔 괜찮고 LLM을 쓰지 않았다고 명시한 PR도 있었지만, 후속 논의에서 작성자가 몰래 LLM을 참고해 오류 많은 답변을 되풀이하고 있음이 바로 드러났다고 함
LLM 팬층을 꽤 잘 요약해 줌
Fake it till you make it인데, LLM도 거기에 올라탄 것 같음
규모가 큰 OSS 프로젝트가 컴파일 실패나 linter 실패 제출을 막는 자동화를 갖추지 않은 게 개인적으로 놀라움
hooks는 clone에 설치를 강제할 깔끔한 방법이 없지만, GHA Workflows나 다른 forge의 동등한 기능이 있을 수 있음
어느 정도 규모와 인기를 가진 프로젝트라면 이런 건 기본 요건이라고 봄
“AI가 기여를 못 한다”는 문제 중 상당수는 더 나은 자동 검사와 견제 장치로 어느 정도 줄일 수 있어 보임
이건 AI 문제라기보다 스팸 문제에 가까움
AI가 이런 새 유형의 스팸을 가능하게 했다는 점을 빼면 본질은 AI가 아님
AI가 없더라도 사람들이 값싼 해외 개발자 군단을 고용해 중간 품질의 drive-by PR을 대량 생산하게 하면 효과는 같을 것임
AI로도 좋은 코드를 만들 수 있지만, 다른 도구처럼 신중하게 써야 함
이건 프로젝트와 목표를 아는 사람이 도구를 잘 활용해 신중히 만든 기여가 아니라 스팸임
LLM이 원하는 일을 하도록 유도할 수는 있지만, 안타깝게도 사람들에게 그 인내심이나 기술이 부족함
AI 정책을 둘러싼 소음은 Bun 개발자들이 그 정책 때문에 성능 PR을 upstream하지 못한다고 말하면서 생긴 듯함
하지만 실제 이유는 그 PR 코드 자체가 상태가 좋지 않고, 건강하지 않은 복잡성을 도입하기 때문으로 보임 https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
인용된 설명에 따르면 병렬 semantic analysis는 오래전부터 Zig 컴파일러의 명시적 계획이었고 self-hosted Zig compiler 설계에도 큰 영향을 줬지만, 올바르게 구현하려면 컴파일러 구현뿐 아니라 Zig 언어 자체에도 변화가 필요하다고 함
그 답변은 Bun fork를 merge하지 않을 설득력 있는 근거를 줌
Zig가 더 나은 결과를 얻기 위한 자체 로드맵과 충돌하고, 언어 전체를 계속 개선하려는 방향을 방해하기 때문임
3000줄 추가를 단일 PR로 보내면 어차피 거절될 가능성이 높음
PR 품질을 논쟁하는 게 무슨 의미가 있는지 모르겠음
정책이 모든 LLM 코드를 명시적으로 금지하니, 그 정책이 당연히 “진짜 이유”임
Zig 쪽은 ZeroMQ의 길을 따르는 것처럼 보임 https://zguide.zeromq.org/docs/chapter6
“프로젝트의 집단 소유권을 강제해 기여자의 경제적 유인을 키우고, 적대적 주체에 의한 hijack 위험을 줄인다”는 방향임
건강한 기여자 커뮤니티가 단순한 코드 성능, 기능 수, 코드 줄 수보다 더 중요함
안타깝게도 그건 대체로 지나간 시대의 말이 됐음
오늘날 zeromq “커뮤니티”는 희박한 편이고, 아직 활동하는 몇몇 훌륭한 사람이 있지만 인간 수준의 프로세스와 소통 채널은 잘 정의되어 있지 않고 충분히 운영되지도 않음
libzmq와 대부분의 binding이 안정적이라 이런 인간 활동과 상호작용 부족이 어느 정도 괜찮거나 정당화될 수도 있지만, Hintjens의 훌륭한 비전이 zeromq를 여기까지 데려왔고 그를 잃은 뒤 프로젝트는 표류하는 느낌임
커뮤니티 중심 비전과는 다소 아이러니하게도, 커뮤니티를 얻고 유지하려면 카리스마 있고 활동적인 리더가 필요한 듯하고, 이는 소프트웨어 개발보다 인간 본성에 대해 더 말해 줌
Zig 이야기로 다시 연결하자면, Zig는 PR이 부족하지 않으니 no-LLM 기여를 미리 선별할 수 있다는 전제가 있음
그들에게는 좋은 선택이고 “contributor poker” 아이디어도 이해됨
하지만 신규 유입이 줄어들면 게임은 바뀌고, 그때도 Zig 사람들이 신규 기여자를 원한다면 그물을 넓혀야 할 수 있음
다만 그런 시점이 오면 LLM 보조 기여를 열어도 회복하기엔 너무 늦을 수 있음
AI 생성 OSS 기여에서 궁금한 건 이것임
AI가 개발자 생산성을 그렇게 크게 올린다면, 왜 OSS maintainer가 자기와 LLM 사이에 모르는 기여자를 끼워 넣고 싶어 하겠는가?
maintainer가 직접 Claude Code에 질의하면 됨
동료의 말을 빌리면, “우리는 AI 모델과 대화할 중간상이 필요하지 않고, 코딩이 병목도 아니다”임
AI를 거의 쓰지 않지만, 가능한 시나리오는 기여자가 총 20시간 정도를 쓰는 경우임
AI로 초기의 나쁜 버전을 만들고, 프롬프트를 조정하고, 수동 수정도 하고, 다른 부분을 고치게 하며, 관련 기능을 발견해 추가하게 하고, benchmark를 돌려 작은 기능을 제거하거나 비슷한 구현 둘 중 하나를 고르는 식임
여기저기 수동 수정도 더하고, 확장된 자동 테스트를 돌려 특이한 설정의 이상한 버그를 찾고, AI와 수동 작업으로 고침
그렇게 20시간 뒤 최종 버전은 50줄뿐이고 각 줄은 5번씩 다시 쓰였을 수 있음
maintainer는 최종 버전만 1시간쯤 검토하면 됨
5분 동안 AI에게 패치를 쓰게 해서 컴파일도 안 되는 1000줄을 읽어보지도 않고 maintainer에게 보내는 것과는 완전히 다름
코딩이 병목이 아닐 수는 있지만, LLM 생성 코드의 정확성을 검증하는 데 병목이 걸릴 확률은 높음
특정 예술 비판이 떠오름
“그건 너무 쉬워서 나도 할 수 있었겠다”
맞지만, 실제로 하지는 않았음
AI가 성공적으로 작동할 때는 2~3배 속도 향상을 줌
하지만 사람에게 하듯 고수준 지시만 던질 수 있는 종류는 아님
AI가 고수준 지시만으로 작동한다고 주장하는 사람들은 대체로 “생각 없는” 프로젝트를 하고 있어서, 세부에 들어간 개발자가 많이 고민할 필요가 없는 경우가 아닐까 싶음
생산성의 유일한 지표가 코드 줄 수라고 말하려는 건 아니겠지?
LLM의 유일한 이점이 직접 치기 귀찮은 코드를 생성하는 것뿐이라는 뜻도 아니길 바람
“Zig는 기여보다 기여자를 중시한다. PR을 리뷰하고 받는 주된 목적은 새 코드를 넣는 게 아니라, 시간이 지나며 신뢰할 수 있고 생산적인 기여자로 성장하도록 돕는 것이다. LLM 보조는 이를 완전히 깨뜨린다. LLM이 완벽한 PR을 제출하게 도와도 마찬가지다”라는 설명이 지금까지 본 가장 좋은 근거임
Zig의 결정을 전적으로 지지하고, 커뮤니티와 실제 프로젝트 모두에 대한 장기적 비전을 높게 평가함
솔직히 LLM이 더 협력적인 작업에 그렇게 잘 맞는다고 보지는 않음
앞으로 어떻게 변할지는 보겠지만, AI 생성 PR을 받으면 결국 내가 다시 해야 하는 경우가 많고, 아이러니하게도 LLM을 써서 다시 하게 되어 점점 갈등을 느낌
LLM은 훌륭하다고 생각하고, locally deployed semi-embedded on-prem 장치에서 Zig를 많이 vibe coding함
그래도 적어도 향후 5년 정도는 Zig 정책이 좋은 아이디어라고 봄
그들이 할 수 있는 말 중 가장 덜 적대적인 표현이라고 생각하고, 자기 프로젝트에 대한 결정으로 존중함
다만 여전히 프로젝트를 불필요하게 묶어 두는 느낌도 듦
LLM은 도구이고, 생각하고 조사하고 코딩하는 데 도움을 줄 수 있음
과용할 수는 있지만 도움이 되는 곳에서는 받아들여야 함
Bun의 PR을 다른 이유로 받지 않는 건 전혀 괜찮지만, 모든 LLM 작성 PR을 단순히 금지하는 건 불필요하게 제한적임
그냥 작업 품질에 집중하면 됨
모르는 사람이 보낸 수천 줄의 LLM 생성 코드를 왜 리뷰해야 하나?
maintainer가 직접 LLM을 써서 같은 일을 하면, 아마 더 나은 설계와 더 신중한 접근으로 할 수 있음
maintainer는 저노력 PR 리뷰만 하는 게 아니라 개발에 시간을 써야 함
LLM 코드의 홍수는 maintainer에게 불리하게 균형을 바꾸고 있고, 그냥 금지하고 싶어 하는 이유를 충분히 이해함
한동안 LLM과 coding agent를 돌려 본 전체 인상은, 이건 전동 공구나 크레인이지 의사결정 도구가 아니라는 것임
조직 안에서 개념 이해와 깊은 엔지니어링 이해가 뛰어난 사람들은 생산성이 폭발적으로 늘어남
반대로 이해가 부족하거나 신입, junior는 돌아가기만 하면 끝났다고 생각하면서 지옥 같은 코드를 만들고 있음
LLM은 조직 안에 지적 격차를 만들고, 더 많이 쓸수록 그 격차를 넓힘
나중에 생성된 코드 때문에 조직 내부의 결과물을 신뢰하지 못하게 될 수도 있음
내 경험과 동료들의 경험도 정확히 같음
AI는 대체로 스킬셋을 증폭하며, 좋은 쪽도 나쁜 쪽도 모두 키움
최근 훌륭했던 사용 사례는 authentication daemon의 concept를 작성하는 일이었음
Codex와 대화하면서 제안을 고르고, 일반 웹 검색으로 교차 확인하고, 최종 초안을 정한 뒤 동료들과 논의함
이런 통합 웹 검색이 있는 대화형 planning은 엄청나게 유용하고, 이미 작성된 코드를 AI로 리뷰하는 것도 순수하게 이점이 있다고 봄
다만 AI의 핵심 caveat는 결국 도구보다 똑똑해야 한다는 것임
Codex가 tech stack X를 쓰라고 제안하면, 왜 실제로 좋은지 조사해 완전히 이해하고 다른 해결책과 비교해야 함
많은 사람이 이 단계를 건너뛰기 때문에 수많은 문제가 생기고, 그건 치명적임
대화가 끝난 뒤에는 AI보다 똑똑해져 있어야 하고, AI가 말한 내용을 완전히 이해하고 비판할 수 있어야 함
LLM을 아키텍처 결정의 sounding board로 쓰고, 팀에 논의 포인트를 가져가 가정과 장단점을 함께 검토함
아키텍처가 정해지고 나면 LLM은 구현을 꽤 잘함
이 평가에 동의하지만, 축적된 지식이 있는 senior에게도 발밑에서 빠져나가듯 통제 밖으로 커지며 완전히 이해하지 못한 코드를 대량으로 만들어낼 위험이 있음
대체로 훌륭하고 테스트도 잘 된 코드를 만들게 할 수 있고, 같은 시간에 혼자 했을 때보다 훨씬 낫기도 함
하지만 AI가 만든 모든 것에 대한 지식을 계속 따라잡는 건 도전임
“PR이 대부분 LLM이 쓴 것이라면, maintainer가 그 PR을 리뷰하고 논의할 시간에 자기 LLM을 켜서 같은 문제를 풀면 되지 않나?”라는 논리는 오픈소스 자체에도 적용됨
로봇이 직접 써 줄 수 있는데 왜 남의 프로젝트를 쓰나?
특히 그 오픈소스 프로젝트가 vibe coded라면 더 그렇음
AI와 기술 전반은 개인화를 싸고 쉽게 만듦
예전에는 모두에게 그럭저럭 만족스러운 대량생산품을 써야 했지만, 이제는 나에게만 뛰어난 무언가를 얻을 희망이 생김
또한 여러 사람이 곳곳에서 LLM으로 오픈소스 프로젝트를 다시 만들게 되어 노동 경제도 자극됨
“로봇이 직접 써 줄 수 있는데 왜 남의 프로젝트를 쓰나?”를 최근 많이 생각해 봤고, 이제 소프트웨어에서 가장 가치 있게 보는 건 탄탄한 테스트나 철저한 문서가 아님
LLM은 그런 걸 몇 분 안에 뱉어낼 수 있음
내가 가장 원하는 건 사용 이력임
나보다 앞서 다른 사람들이 써 본 소프트웨어를 쓰고 싶고, 그들이 버그와 날카로운 모서리를 만나 다듬어 놓았기를 바람
2010년대 초 3D 프린팅 혁명이 곧 온다던 때도 같은 논리를 들었음
집에서 모델을 다운로드해 출력하고 무한히 커스터마이즈할 수 있는데 누가 물건을 사겠느냐는 식이었음
문명을 갖는 이유는 삶의 대부분을 다른 누군가의 문제로 넘기고, 자신은 한 가지를 잘하는 데 집중할 수 있기 때문임
치과의사이거나 muffler shop을 운영한다면 하루 시간은 제한되어 있고, 아마 vibecoding을 배우고 이상하고 손 많이 가는 부하를 감독하느니 SaaS vendor에게 돈을 내고 싶을 것임
예외는 있지만 어디까지나 예외임
vendor가 합리적이고 유능한 제품을 만든다면 기꺼이 돈을 냄
오픈소스도 마찬가지임
LLM이 처음부터 새 운영체제를 안정적으로 만들 수 있다 해도, 내가 정말 그걸 원할까?
OS를 유지보수하고 싶지 않고, OS를 유지보수하는 누군가를 관리하고 싶지도 않으며, 애초에 OS에 대한 일관된 비전을 내가 갖고 있다고 믿지도 않음
그 논리는 가장 작은 규모의 오픈소스 프로젝트에만 맞음
어느 정도 복잡도를 넘으면 로봇이 내 마음을 충분히 읽어서 “나에게만 뛰어난” 고품질 결과를 줄 거라고 기대하기 어렵다
Zig 프로젝트는 분명 그런 능력 범위를 훨씬 벗어나 있음
LLM 접근성은 아직 보편적이지 않음
비용을 감당하기 어려운 사람도 있고, 접근권이 있어도 Claude 장애나 시간이 갈수록 전반적 성능 저하 같은 문제가 종종 또는 지속적으로 있음
몇 달 전 Claude를 막 쓰기 시작했을 때는 한 주 안에 여러 프로젝트에서 쉽게 진전을 냈지만, 요즘은 대부분 spinner만 보이고 코드 품질도 급락한 느낌이라 거의 아무것도 못 하고 있음
내 저장소들에 대한 PR이 줄어드는 걸 보고 있음
별이 약 100개쯤 되는 저장소 몇 개가 있고 대단한 건 아니지만 작년까지는 가끔 PR을 받았는데, 올해는 지금까지 거의 없음
내 가설은 LLM이 mainstream 프로젝트에 붙어 있기를 선호한다는 것임
많은 개발자가 이제 LLM에 크게 의존하면서, 내가 제공하는 것 대부분을 무시하는 쪽으로 bias가 생김
LLM으로 wheel reinvention이 많아지는 이유도 새로 만드는 비용이 싸졌기 때문임
그래서 GitHub의 obscure한 것, 예컨대 내 것 같은 것을 쓰기보다 필요한 걸 그냥 생성하는 게 쉬워짐
내 dependency 선택에서도 같은 현상을 봄
아주 좋은 이유가 없으면 LLM이 제안하는 것을 그대로 택하는 경향이 있음
어느 정도 동의하지만 완전히 동의하지는 않음
기여자를 키우는 것이 올바른 우선순위인 건 맞음
하지만 AI를 보조 기술로 봄
screen reader나 magnifying glass와 비슷하지만, 물론 다른 점도 많음 로봇 외골격처럼 생각할 수 있음
나쁜 일과 어리석은 일에 쓰이겠지만, 원래는 할 수 없던 사람이 좋은 일을 하거나 더 유능해지도록 돕는 데도 쓰일 것임
어떤 사람에게 AI는 이전에는 못 하던 코딩을 가능하게 하고, 많은 사람에게는 AI가 하는 것을 보며 코딩을 배우는 수단이 되며, 다른 사람에게는 훨씬 빠르거나 더 잘 코딩하게 해 줌
일부에게는 특정 기술이 퇴화하는 대신 다른 기술이 발달할 수도 있음
외골격도 괜찮은 제품이 시장에 나온다면 같은 문제가 있겠지만, 전체적으로는 가능하게 만드는 도구가 될 것임
보조 기술을 쓰는 기여자를 키우는 것이 그렇지 않은 기여자를 키우는 것보다 왜 더 나쁜지 모르겠음
물론 더 어려울 수는 있음
LLM vendor들이 주장한 것만큼 LLM은 똑똑하지 않음
정말 그렇다면 완전 자율적일 테니 이런 대화를 하고 있지 않을 것임
LLM 생성 코드를 맹목적으로 제출하거나 사용 사실을 밝히지 않는 사람들은 정말 그만해야 함
거기에 도달하고 있고, 그렇게 느리지만도 않음
남은 문제는 여전히 도구라는 점임
임의의 개발자에게 “one-shot PR로 Zig를 빠르게 만들어라”라고 해도 좋은 결과가 나오지 않음
과거 OSS 프로젝트는 working code를 만들 수 있어야 했기 때문에 자기선별이 되었고, 그 정도가 되면 몇 년간 배운 덕분에 대체로 올바른 일을 하며 기능이나 필요성에 대한 나름의 reasoning도 있었음
오늘날 LLM이 완벽하고 reasoning을 잘한다 해도 결국 prompter의 지시를 수행함
더 이상 자기선별이 사라진 것임
Zig 개발자들이 실제로 무엇이 LLM이 만든 코드이고 무엇이 사람이 만든 코드인지 판단하기도 어려울 것임
이미 LLM 생성 코드가 들어가 있을 가능성도 있지만, 적어도 그런 사람 제출자는 여전히 코드를 꽤 잘 다뤄야 함
결국 “trusted badge of honor가 있는 인간만 commit 가능”으로 갈지, 아니면 “LLM이 충분히 reasoning해서 ‘아니, 꺼져. 이 기능·계획·아이디어는 쓰레기라 안 만들어’라고 말하는” 수준이 될지 궁금함
그만두지 않을 것 같음
그렇게 했을 때 제대로 한 방 먹일 방법이 없다면, 무엇이 그들을 멈추게 할지 모르겠음
Hacker News 의견들
https://kristoff.it/blog/contributor-poker-and-ai/에 따르면, LLM 기반 기여는 대체로 부정적이었다고 함
가치 없는 drive-by PR이 환각 코드로 배경 소음을 늘렸고, 컴파일도 안 되거나 CI를 통과하지 못했으며, 처음 기여하는 사람이 1만 줄 PR을 보내는 일도 있었음
겉보기엔 괜찮고 LLM을 쓰지 않았다고 명시한 PR도 있었지만, 후속 논의에서 작성자가 몰래 LLM을 참고해 오류 많은 답변을 되풀이하고 있음이 바로 드러났다고 함
hooks는 clone에 설치를 강제할 깔끔한 방법이 없지만, GHA Workflows나 다른 forge의 동등한 기능이 있을 수 있음
어느 정도 규모와 인기를 가진 프로젝트라면 이런 건 기본 요건이라고 봄
“AI가 기여를 못 한다”는 문제 중 상당수는 더 나은 자동 검사와 견제 장치로 어느 정도 줄일 수 있어 보임
AI가 이런 새 유형의 스팸을 가능하게 했다는 점을 빼면 본질은 AI가 아님
AI가 없더라도 사람들이 값싼 해외 개발자 군단을 고용해 중간 품질의 drive-by PR을 대량 생산하게 하면 효과는 같을 것임
AI로도 좋은 코드를 만들 수 있지만, 다른 도구처럼 신중하게 써야 함
이건 프로젝트와 목표를 아는 사람이 도구를 잘 활용해 신중히 만든 기여가 아니라 스팸임
AI 정책을 둘러싼 소음은 Bun 개발자들이 그 정책 때문에 성능 PR을 upstream하지 못한다고 말하면서 생긴 듯함
하지만 실제 이유는 그 PR 코드 자체가 상태가 좋지 않고, 건강하지 않은 복잡성을 도입하기 때문으로 보임 https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
인용된 설명에 따르면 병렬 semantic analysis는 오래전부터 Zig 컴파일러의 명시적 계획이었고 self-hosted Zig compiler 설계에도 큰 영향을 줬지만, 올바르게 구현하려면 컴파일러 구현뿐 아니라 Zig 언어 자체에도 변화가 필요하다고 함
Zig가 더 나은 결과를 얻기 위한 자체 로드맵과 충돌하고, 언어 전체를 계속 개선하려는 방향을 방해하기 때문임
정책이 모든 LLM 코드를 명시적으로 금지하니, 그 정책이 당연히 “진짜 이유”임
Zig 쪽은 ZeroMQ의 길을 따르는 것처럼 보임 https://zguide.zeromq.org/docs/chapter6
“프로젝트의 집단 소유권을 강제해 기여자의 경제적 유인을 키우고, 적대적 주체에 의한 hijack 위험을 줄인다”는 방향임
건강한 기여자 커뮤니티가 단순한 코드 성능, 기능 수, 코드 줄 수보다 더 중요함
오늘날 zeromq “커뮤니티”는 희박한 편이고, 아직 활동하는 몇몇 훌륭한 사람이 있지만 인간 수준의 프로세스와 소통 채널은 잘 정의되어 있지 않고 충분히 운영되지도 않음
libzmq와 대부분의 binding이 안정적이라 이런 인간 활동과 상호작용 부족이 어느 정도 괜찮거나 정당화될 수도 있지만, Hintjens의 훌륭한 비전이 zeromq를 여기까지 데려왔고 그를 잃은 뒤 프로젝트는 표류하는 느낌임
커뮤니티 중심 비전과는 다소 아이러니하게도, 커뮤니티를 얻고 유지하려면 카리스마 있고 활동적인 리더가 필요한 듯하고, 이는 소프트웨어 개발보다 인간 본성에 대해 더 말해 줌
Zig 이야기로 다시 연결하자면, Zig는 PR이 부족하지 않으니 no-LLM 기여를 미리 선별할 수 있다는 전제가 있음
그들에게는 좋은 선택이고 “contributor poker” 아이디어도 이해됨
하지만 신규 유입이 줄어들면 게임은 바뀌고, 그때도 Zig 사람들이 신규 기여자를 원한다면 그물을 넓혀야 할 수 있음
다만 그런 시점이 오면 LLM 보조 기여를 열어도 회복하기엔 너무 늦을 수 있음
AI 생성 OSS 기여에서 궁금한 건 이것임
AI가 개발자 생산성을 그렇게 크게 올린다면, 왜 OSS maintainer가 자기와 LLM 사이에 모르는 기여자를 끼워 넣고 싶어 하겠는가?
maintainer가 직접 Claude Code에 질의하면 됨
동료의 말을 빌리면, “우리는 AI 모델과 대화할 중간상이 필요하지 않고, 코딩이 병목도 아니다”임
AI로 초기의 나쁜 버전을 만들고, 프롬프트를 조정하고, 수동 수정도 하고, 다른 부분을 고치게 하며, 관련 기능을 발견해 추가하게 하고, benchmark를 돌려 작은 기능을 제거하거나 비슷한 구현 둘 중 하나를 고르는 식임
여기저기 수동 수정도 더하고, 확장된 자동 테스트를 돌려 특이한 설정의 이상한 버그를 찾고, AI와 수동 작업으로 고침
그렇게 20시간 뒤 최종 버전은 50줄뿐이고 각 줄은 5번씩 다시 쓰였을 수 있음
maintainer는 최종 버전만 1시간쯤 검토하면 됨
5분 동안 AI에게 패치를 쓰게 해서 컴파일도 안 되는 1000줄을 읽어보지도 않고 maintainer에게 보내는 것과는 완전히 다름
“그건 너무 쉬워서 나도 할 수 있었겠다”
맞지만, 실제로 하지는 않았음
하지만 사람에게 하듯 고수준 지시만 던질 수 있는 종류는 아님
AI가 고수준 지시만으로 작동한다고 주장하는 사람들은 대체로 “생각 없는” 프로젝트를 하고 있어서, 세부에 들어간 개발자가 많이 고민할 필요가 없는 경우가 아닐까 싶음
LLM의 유일한 이점이 직접 치기 귀찮은 코드를 생성하는 것뿐이라는 뜻도 아니길 바람
“Zig는 기여보다 기여자를 중시한다. PR을 리뷰하고 받는 주된 목적은 새 코드를 넣는 게 아니라, 시간이 지나며 신뢰할 수 있고 생산적인 기여자로 성장하도록 돕는 것이다. LLM 보조는 이를 완전히 깨뜨린다. LLM이 완벽한 PR을 제출하게 도와도 마찬가지다”라는 설명이 지금까지 본 가장 좋은 근거임
Zig의 결정을 전적으로 지지하고, 커뮤니티와 실제 프로젝트 모두에 대한 장기적 비전을 높게 평가함
솔직히 LLM이 더 협력적인 작업에 그렇게 잘 맞는다고 보지는 않음
앞으로 어떻게 변할지는 보겠지만, AI 생성 PR을 받으면 결국 내가 다시 해야 하는 경우가 많고, 아이러니하게도 LLM을 써서 다시 하게 되어 점점 갈등을 느낌
그래도 적어도 향후 5년 정도는 Zig 정책이 좋은 아이디어라고 봄
그들이 할 수 있는 말 중 가장 덜 적대적인 표현이라고 생각하고, 자기 프로젝트에 대한 결정으로 존중함
다만 여전히 프로젝트를 불필요하게 묶어 두는 느낌도 듦
LLM은 도구이고, 생각하고 조사하고 코딩하는 데 도움을 줄 수 있음
과용할 수는 있지만 도움이 되는 곳에서는 받아들여야 함
Bun의 PR을 다른 이유로 받지 않는 건 전혀 괜찮지만, 모든 LLM 작성 PR을 단순히 금지하는 건 불필요하게 제한적임
그냥 작업 품질에 집중하면 됨
maintainer가 직접 LLM을 써서 같은 일을 하면, 아마 더 나은 설계와 더 신중한 접근으로 할 수 있음
maintainer는 저노력 PR 리뷰만 하는 게 아니라 개발에 시간을 써야 함
LLM 코드의 홍수는 maintainer에게 불리하게 균형을 바꾸고 있고, 그냥 금지하고 싶어 하는 이유를 충분히 이해함
한동안 LLM과 coding agent를 돌려 본 전체 인상은, 이건 전동 공구나 크레인이지 의사결정 도구가 아니라는 것임
조직 안에서 개념 이해와 깊은 엔지니어링 이해가 뛰어난 사람들은 생산성이 폭발적으로 늘어남
반대로 이해가 부족하거나 신입, junior는 돌아가기만 하면 끝났다고 생각하면서 지옥 같은 코드를 만들고 있음
LLM은 조직 안에 지적 격차를 만들고, 더 많이 쓸수록 그 격차를 넓힘
나중에 생성된 코드 때문에 조직 내부의 결과물을 신뢰하지 못하게 될 수도 있음
AI는 대체로 스킬셋을 증폭하며, 좋은 쪽도 나쁜 쪽도 모두 키움
최근 훌륭했던 사용 사례는 authentication daemon의 concept를 작성하는 일이었음
Codex와 대화하면서 제안을 고르고, 일반 웹 검색으로 교차 확인하고, 최종 초안을 정한 뒤 동료들과 논의함
이런 통합 웹 검색이 있는 대화형 planning은 엄청나게 유용하고, 이미 작성된 코드를 AI로 리뷰하는 것도 순수하게 이점이 있다고 봄
다만 AI의 핵심 caveat는 결국 도구보다 똑똑해야 한다는 것임
Codex가 tech stack X를 쓰라고 제안하면, 왜 실제로 좋은지 조사해 완전히 이해하고 다른 해결책과 비교해야 함
많은 사람이 이 단계를 건너뛰기 때문에 수많은 문제가 생기고, 그건 치명적임
대화가 끝난 뒤에는 AI보다 똑똑해져 있어야 하고, AI가 말한 내용을 완전히 이해하고 비판할 수 있어야 함
아키텍처가 정해지고 나면 LLM은 구현을 꽤 잘함
대체로 훌륭하고 테스트도 잘 된 코드를 만들게 할 수 있고, 같은 시간에 혼자 했을 때보다 훨씬 낫기도 함
하지만 AI가 만든 모든 것에 대한 지식을 계속 따라잡는 건 도전임
“PR이 대부분 LLM이 쓴 것이라면, maintainer가 그 PR을 리뷰하고 논의할 시간에 자기 LLM을 켜서 같은 문제를 풀면 되지 않나?”라는 논리는 오픈소스 자체에도 적용됨
로봇이 직접 써 줄 수 있는데 왜 남의 프로젝트를 쓰나?
특히 그 오픈소스 프로젝트가 vibe coded라면 더 그렇음
AI와 기술 전반은 개인화를 싸고 쉽게 만듦
예전에는 모두에게 그럭저럭 만족스러운 대량생산품을 써야 했지만, 이제는 나에게만 뛰어난 무언가를 얻을 희망이 생김
또한 여러 사람이 곳곳에서 LLM으로 오픈소스 프로젝트를 다시 만들게 되어 노동 경제도 자극됨
LLM은 그런 걸 몇 분 안에 뱉어낼 수 있음
내가 가장 원하는 건 사용 이력임
나보다 앞서 다른 사람들이 써 본 소프트웨어를 쓰고 싶고, 그들이 버그와 날카로운 모서리를 만나 다듬어 놓았기를 바람
집에서 모델을 다운로드해 출력하고 무한히 커스터마이즈할 수 있는데 누가 물건을 사겠느냐는 식이었음
문명을 갖는 이유는 삶의 대부분을 다른 누군가의 문제로 넘기고, 자신은 한 가지를 잘하는 데 집중할 수 있기 때문임
치과의사이거나 muffler shop을 운영한다면 하루 시간은 제한되어 있고, 아마 vibecoding을 배우고 이상하고 손 많이 가는 부하를 감독하느니 SaaS vendor에게 돈을 내고 싶을 것임
예외는 있지만 어디까지나 예외임
vendor가 합리적이고 유능한 제품을 만든다면 기꺼이 돈을 냄
오픈소스도 마찬가지임
LLM이 처음부터 새 운영체제를 안정적으로 만들 수 있다 해도, 내가 정말 그걸 원할까?
OS를 유지보수하고 싶지 않고, OS를 유지보수하는 누군가를 관리하고 싶지도 않으며, 애초에 OS에 대한 일관된 비전을 내가 갖고 있다고 믿지도 않음
어느 정도 복잡도를 넘으면 로봇이 내 마음을 충분히 읽어서 “나에게만 뛰어난” 고품질 결과를 줄 거라고 기대하기 어렵다
Zig 프로젝트는 분명 그런 능력 범위를 훨씬 벗어나 있음
비용을 감당하기 어려운 사람도 있고, 접근권이 있어도 Claude 장애나 시간이 갈수록 전반적 성능 저하 같은 문제가 종종 또는 지속적으로 있음
몇 달 전 Claude를 막 쓰기 시작했을 때는 한 주 안에 여러 프로젝트에서 쉽게 진전을 냈지만, 요즘은 대부분 spinner만 보이고 코드 품질도 급락한 느낌이라 거의 아무것도 못 하고 있음
별이 약 100개쯤 되는 저장소 몇 개가 있고 대단한 건 아니지만 작년까지는 가끔 PR을 받았는데, 올해는 지금까지 거의 없음
내 가설은 LLM이 mainstream 프로젝트에 붙어 있기를 선호한다는 것임
많은 개발자가 이제 LLM에 크게 의존하면서, 내가 제공하는 것 대부분을 무시하는 쪽으로 bias가 생김
LLM으로 wheel reinvention이 많아지는 이유도 새로 만드는 비용이 싸졌기 때문임
그래서 GitHub의 obscure한 것, 예컨대 내 것 같은 것을 쓰기보다 필요한 걸 그냥 생성하는 게 쉬워짐
내 dependency 선택에서도 같은 현상을 봄
아주 좋은 이유가 없으면 LLM이 제안하는 것을 그대로 택하는 경향이 있음
어느 정도 동의하지만 완전히 동의하지는 않음
기여자를 키우는 것이 올바른 우선순위인 건 맞음
하지만 AI를 보조 기술로 봄
screen reader나 magnifying glass와 비슷하지만, 물론 다른 점도 많음
로봇 외골격처럼 생각할 수 있음
나쁜 일과 어리석은 일에 쓰이겠지만, 원래는 할 수 없던 사람이 좋은 일을 하거나 더 유능해지도록 돕는 데도 쓰일 것임
어떤 사람에게 AI는 이전에는 못 하던 코딩을 가능하게 하고, 많은 사람에게는 AI가 하는 것을 보며 코딩을 배우는 수단이 되며, 다른 사람에게는 훨씬 빠르거나 더 잘 코딩하게 해 줌
일부에게는 특정 기술이 퇴화하는 대신 다른 기술이 발달할 수도 있음
외골격도 괜찮은 제품이 시장에 나온다면 같은 문제가 있겠지만, 전체적으로는 가능하게 만드는 도구가 될 것임
보조 기술을 쓰는 기여자를 키우는 것이 그렇지 않은 기여자를 키우는 것보다 왜 더 나쁜지 모르겠음
물론 더 어려울 수는 있음
LLM vendor들이 주장한 것만큼 LLM은 똑똑하지 않음
정말 그렇다면 완전 자율적일 테니 이런 대화를 하고 있지 않을 것임
LLM 생성 코드를 맹목적으로 제출하거나 사용 사실을 밝히지 않는 사람들은 정말 그만해야 함
남은 문제는 여전히 도구라는 점임
임의의 개발자에게 “one-shot PR로 Zig를 빠르게 만들어라”라고 해도 좋은 결과가 나오지 않음
과거 OSS 프로젝트는 working code를 만들 수 있어야 했기 때문에 자기선별이 되었고, 그 정도가 되면 몇 년간 배운 덕분에 대체로 올바른 일을 하며 기능이나 필요성에 대한 나름의 reasoning도 있었음
오늘날 LLM이 완벽하고 reasoning을 잘한다 해도 결국 prompter의 지시를 수행함
더 이상 자기선별이 사라진 것임
Zig 개발자들이 실제로 무엇이 LLM이 만든 코드이고 무엇이 사람이 만든 코드인지 판단하기도 어려울 것임
이미 LLM 생성 코드가 들어가 있을 가능성도 있지만, 적어도 그런 사람 제출자는 여전히 코드를 꽤 잘 다뤄야 함
결국 “trusted badge of honor가 있는 인간만 commit 가능”으로 갈지, 아니면 “LLM이 충분히 reasoning해서 ‘아니, 꺼져. 이 기능·계획·아이디어는 쓰레기라 안 만들어’라고 말하는” 수준이 될지 궁금함
그렇게 했을 때 제대로 한 방 먹일 방법이 없다면, 무엇이 그들을 멈추게 할지 모르겠음