# Django에는 토큰이 아니라 시간과 돈을 투자하라 > Clean Markdown view of GeekNews topic #27595. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27595](https://news.hada.io/topic?id=27595) - GeekNews Markdown: [https://news.hada.io/topic/27595.md](https://news.hada.io/topic/27595.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-18T05:37:14+09:00 - Updated: 2026-03-18T05:37:14+09:00 - Original source: [better-simple.com](https://www.better-simple.com/django/2026/03/16/give-django-your-time-and-money/) - Points: 5 - Comments: 1 ## Summary Django에 **LLM을 활용한 자동 기여 시도는 커뮤니티의 신뢰와 품질 유지에 도움이 되지 않습니다.** Django는 장기적 안정성과 높은 코드 기준을 중시하기 때문에, 단순한 코드 생성보다 문제를 직접 이해하고 토론하는 과정이 중요합니다. 오픈소스 기여의 핵심은 인간적 협력에 있으며, LLM은 이를 보조하는 도구로만 사용되어야 합니다. 진정한 기여는 시간을 들여 학습하고 실험하며, 그 경험을 통해 성장하는 데서 비롯됩니다. ## Topic Body - **LLM을 이용해 Django 티켓을 처리하는 방식은 도움이 되지 않으며**, 그 자원을 Django Software Foundation에 직접 기부하는 편이 더 유익함 - Django는 **품질 기준이 매우 높고 장기적 안정성을 중시하는 프로젝트**로, 단순 코드 생성 이상의 깊은 이해가 필요함 - LLM이 작성자 대신 코드를 만들고 PR 설명과 리뷰 대응까지 처리하면, **기여자의 실제 이해 여부를 판단하기 어려워지는 문제**가 발생함 - 오픈소스 기여는 **인간적 소통과 공동체적 협력**이 핵심이며, LLM이 이를 가리면 리뷰어와의 신뢰가 약화됨 - Django에 기여하려면 **직접 학습과 실험을 통해 이해를 쌓는 과정**이 필수이며, 이는 개발자로서의 성장으로 이어짐 --- ### LLM을 통한 Django 기여의 한계 - LLM을 활용해 Django 티켓을 해결하는 것은 **커뮤니티에 실질적 도움이 되지 않음** - LLM이 생성한 코드로 PR을 제출하고 피드백을 처리하는 경우, 작성자의 이해 수준을 파악하기 어려움 - 리뷰어 입장에서는 사람이 아닌 **‘가짜 이해의 외피’** 와 대화하는 느낌을 받게 됨 - Django는 **대규모 사용자 기반과 느린 변화 주기**, 그리고 **20년 이상 지속될 프로젝트로서의 품질 요구**를 갖춤 - 이러한 특성 때문에, 단순 자동화된 코드 생성보다 **깊은 이해와 책임 있는 기여**가 중요함 ### LLM의 올바른 활용 방식 - LLM은 **이해를 돕는 보조 도구**로 사용해야 함 - 자신의 언어로 설명을 작성한 뒤, LLM을 이용해 표현을 다듬는 형태가 바람직함 - 의사소통이 어려울 때는 LLM을 적극 활용하되, **사용 사실을 명시**해야 함 - Django에 기여할 때는 **기여자가 문제와 해결책, 리뷰 피드백을 직접 이해해야 함** - 이해 없이 생성된 코드는 프로젝트 전체의 품질을 해칠 수 있음 ### 인간 중심의 오픈소스 협력 - Django 기여는 **공동체적 경험**이며, 인간적 투명성과 취약성을 포함함 - LLM이 이러한 인간성을 가리면 협업이 어려워짐 - 리뷰어는 **‘인간의 진짜 이해’** 를 바탕으로 소통할 때 동기부여를 얻음 - LLM은 **보조 수단**으로만 사용되어야 하며, **기여자의 본질적 역할을 대체해서는 안 됨** ### Django 기여의 본질과 가치 - Django는 **20년의 역사와 장기적 비전**을 가진 프로젝트로, 추가되는 모든 코드는 깊이 이해되어야 함 - 이해에는 **시간, 실험, 학습**이 필수적임 - Django 기여는 단순한 이름 등재보다 **개발자로서의 성장**을 가져오는 경험임 - 기여 과정에서 얻는 학습이 **리스트에 이름이 오르는 것보다 훨씬 가치 있음** ### 커뮤니티에 대한 제안 - LLM을 과도하게 사용해 자신과 이해를 숨기지 말아야 함 - Django 커뮤니티는 **진짜 사람과 협력하고 싶어함** - Django를 지원하고 싶다면 **시간과 돈을 투자하거나 Django Software Foundation에 기부**하는 것이 가장 효과적임 ## Comments ### Comment 53257 - Author: neo - Created: 2026-03-18T05:37:14+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47400089) - 나는 **LLM**이 인간 리뷰어가 있는 어떤 코드베이스에서도 문제를 일으킬 수 있다고 봄 티켓이나 솔루션, PR 피드백을 이해하지 못한 채 LLM을 쓰면 프로젝트 전체에 해로움 오픈소스 기여는 공동체적 행위인데, LLM은 인간의 **투명성과 취약성**을 가려버림 리뷰어 입장에서는 인간의 ‘가면’과 대화하는 느낌이라 **의욕이 꺾이는 경험**임 그래서 LLM은 도구로서 보조적으로 써야지, 대체 수단이 되어서는 안 됨 요즘 팀에서도 AI가 작성한 PR이 급증하고, Claude나 Codex가 리뷰 피드백까지 대신하는 걸 봄 이런 문화가 자리 잡으면 업계 전반의 **신뢰 붕괴**와 사기 저하로 이어질 것 같음 - Jira의 **AI 자동완성 기능**이 티켓 시스템을 스팸 천국으로 만들어버림 생산성 향상보다는 “기분상 빨라진 느낌”만 남음 실제로 조직들이 생산성을 제대로 측정하지 않기 때문에, 이런 기능의 순효과를 아무도 모름 - 예전에는 PR이 선의로 제출된다고 믿었지만, 이제는 대부분 AI가 쓴 것처럼 느껴짐 AI의 광범위한 사용이 **신뢰를 침식**시키고 있음 - LLM은 오픈소스 기여에 있어서 **Photoshop이 Tinder에 미치는 영향**과 같음 겉모습은 좋아 보이지만 진정성이 사라짐 - 이런 AI 기반 PR들이 실제로는 리뷰를 통과하고 코드가 병합되는 경우도 있음 결과적으로는 코드가 통과되니, 사람들이 불만이 없는지도 궁금함 - 내가 함께 일했던 최고의 동료들은 항상 리뷰어가 **비판하기 쉽게** 만들어줬음 가정, 모르는 부분, 시행착오를 명확히 적고, 리뷰어가 쉽게 반박할 수 있도록 설명했음 이런 **겸손과 자기성찰**이 보이는 PR이라면 LLM이 개입했더라도 걱정되지 않음 문제는 예전부터 기본적인 빌드조차 안 되는 코드를 올리던 사람들이 이제 LLM으로 더 많은 **형편없는 PR**을 양산한다는 점임 그래서 “코드가 돌아가면 됐지, 누가 썼는지는 중요하지 않다”는 말에는 동의하지 않음 - 지금 상황은 통제 불능 수준임 특히 채용 과정에서 GitHub 활동이 평가 요소가 되면서, 사람들은 LLM으로 **기여 이력 조작**을 시도함 실제로는 프로젝트를 이해하지 못한 채 PR이 통과되면 끝 - 하지만 글이 ‘왜’ 이런 현상이 문제인지 충분히 설명하지는 못했다고 봄 좋은 개발자가 LLM을 쓰는 건 문제가 아님 문제는 원래도 실력이 부족한 사람들이 LLM 덕분에 더 많은 **저품질 코드**를 제출한다는 것임 - 사실 이건 **AI 문제가 아니라 사람 문제**임 예전에도 StackOverflow 복붙으로 이해 없이 코드를 제출하던 사람들이 있었음 AI가 그걸 단지 증폭시켰을 뿐임 - 내가 채용 담당자라면 PR의 **수락 대비 거절 비율**을 볼 것임 여러 저장소에 비슷한 PR을 남발하고 대부분 거절당했다면, 그건 명백한 신호임 결국 양보다 **질 중심의 기여 문화**로 돌아가야 함 - 사람을 탓하기보다 **시스템의 인센티브 구조**를 바꿔야 함 문제를 인식하는 건 쉽지만, 합의와 실질적 해결책을 만드는 건 어렵고, 기술자들은 그 부분에 약함 - 농담이지만, 이제는 **AI 리뷰어 스타트업**이 쏟아져 나올 것 같음 - 나는 돈을 기부하는 아이디어가 마음에 듦 Django 핵심 기여자들이 토큰보다 자금을 더 잘 활용할 수 있을 것 같음 다른 프로젝트들은 [AI 사용 공개](https://news.ycombinator.com/item?id=46730504)나 외부 기여 일시 중단, 혹은 [이슈 등록 제한](https://news.ycombinator.com/item?id=46460319) 같은 조치를 취함 **저품질 PR**이 너무 쉽게 생성되면서 커뮤니티의 시간과 집중력이 침해되고 있음 그래서 더 **폐쇄적인 협업 모델**로 이동할 필요가 있을지도 모름 Debian이 이 문제를 신중히 다루기로 한 결정도 인상 깊었음 - 나는 이 주제에 대해 [에세이](https://essays.johnloeber.com/p/31-open-source-software-in-the-age)를 쓴 적이 있음 토큰을 사는 대신, 그냥 핵심 기여자에게 돈을 기부하고 그들이 알아서 쓰게 하는 게 낫다고 생각함 - “리뷰어가 인간의 가면과 대화하는 건 **정신적으로 소모적**이다”라는 말에 깊이 공감함 오픈소스의 보상 중 하나는 **사람과의 교류**인데, 그게 사라지면 단순한 노동처럼 느껴짐 결국 모두의 인내심이 줄고, 협업의 즐거움이 사라짐 - 예전에도 Reddit에서 “let me google that for you” 같은 반응이 있었지만, 사람들은 여전히 **인간적인 교류**를 원함 마치 단골 정육점에서 대화하듯, 관계를 맺고 싶어함 - 학계에서도 비슷한 논의가 있음 논문 작성은 LLM으로 쉬워졌지만, **검증과 리뷰**는 여전히 어렵고 시간이 듦 그래서 AI 사용 여부를 명시하거나, AI 검출 알고리즘으로 PR을 표시하는 방안이 필요함 결국 사람들에게 LLM의 답변을 **자신의 언어로 번역**하게 만드는 효과가 있을 것임 - 이미 늦었을 수도 있지만, GitHub가 “AI PR 허용 여부”를 설정할 수 있게 했으면 좋았을 것 같음 하지만 현실적으로는 **규칙을 무시하는 사람들**이 항상 존재함 - 요즘 혁신은 전부 **단기 보상**을 추구하게 만드는 방향으로 작동함 인센티브 구조가 장기적 시야를 가진 사람을 지지하지 않음 게임이론을 한 번 보면, 세상이 그렇게 설계되어 있다는 걸 부정하기 어려움 - 정부의 **통화 팽창**이 사람들을 생존을 위해 단기 수익에 집착하게 만들었음 - 하지만 게임이론은 인생처럼 **연속적 상호작용**을 완전히 설명하지 못함 그래서 장기 전략을 평가하기엔 한계가 있음 - 좋은 메시지이지만, LLM으로 모든 걸 하는 사람들은 이런 글을 읽지도 않을 것 같음 오픈소스 유지보수자로서 나도 **AI 작성 코드인지 구분하기 어려움** - “모든 걸 LLM으로 하는 사람들”이라는 표현은 과장임 실제로 그런 전문 개발자는 거의 없음 - **허위 정보나 환각**을 탐지하는 게 완전한 LLM 생성물을 구분하는 첫 단계일지도 모름 - 차라리 **LLM 전용 오픈소스 프로젝트**를 만들어보면 어떨까 생각함 LLM이 만든 코드만 모으고, 기여 프로토콜을 명확히 정의하는 식으로 다만 많은 LLM 기여가 단순히 **포트폴리오용**일 가능성이 높음 - 실제로 [OpenClaw](https://github.com/openclaw/openclaw)는 그런 실험적 프로젝트임 수천 명의 기여자와 수만 건의 커밋이 있음 - 이런 프로젝트가 **저품질 LLM 코드의 허니팟** 역할을 할 수도 있음 - 농담이지만, “Moltbook meets GitHub”라면 유니콘 기업이 될지도 모름 - AI는 종종 **생산성을 높이지 않고**, 단지 검증 부담을 다른 사람에게 떠넘김 결국 유지보수자들이 더 많은 일을 떠안게 되고, 기여자는 **공로만 챙기는 구조**가 됨 - 나도 Django 같은 프로젝트에 LLM을 써서 패치를 만든 적이 있음 LLM이 없었다면 시도조차 안 했을 것임 하지만 결과물은 직접 리뷰하고 테스트도 작성했음 - 문제는 LLM을 쓰느냐가 아니라, **기여자가 내용을 이해하느냐**임 요즘은 코드, PR 설명, 리뷰 대응까지 전부 LLM이 대신해서 리뷰어 입장에서는 “그냥 내가 LLM으로 리뷰하면 되지 않나?” 싶을 정도임 그래서 LLM은 **보조 도구**로 써야지, **대체 수단**이 되어서는 안 됨