Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI 생성 코드에 대한 제한 정책으로 인해 개발자들이 어려움을 겪고 있으며, 이는 AI가 코딩을 완전히 대체할 수 없다는 현실적인 문제점을 드러냅니다. 작성자는 명세 기반의 개발과 직접적인 검토 과정을 강조하며, 단순히 AI 사용 여부를 금지하는 것은 근본적인 해결책이 아니라고 주장합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기AI가 약속한 많은 것을 실현하지 못한다고 느껴 AI에 맡기는 범위를 줄였음. 내 프로젝트들이 유지보수 불가능한 난장판으로 변하고 있었기 때문임. 코딩은 이미 해결됐다고 하는 이들은 현실을 제대로 보지 않는 셈임.
AI로 프로젝트 두 개를 처음부터 시작했지만, 둘 다 엉망이 되어 포기했음. AI 없이 만든 프로젝트는 관리와 유지보수, 기능 추가·삭제가 훨씬 쉬움. 지금은 AI를 Google 대신 프로젝트용 검색 도구로 쓰며, 코드의 문제를 물어본 뒤 내 경험을 바탕으로 직접 수정하고 개선함.
특히 소프트웨어 개발을 하지 않는 이들은 코딩과 소프트웨어 개발을 혼동하곤 함. 모델은 아키텍처와 설계에는 약하지만, 그에 관한 지시는 잘 따르고 리팩터링도 상당히 잘함. 투자할 가치가 있는지 판단한 뒤라면 바이브 코딩으로 만든 코드베이스를 에이전트로 정리할 수 있고, 처음부터 충분한 설계 지침을 주면 난장판을 피할 수도 있음.
다만 이 지침을 순전히 텍스트로 전달하는 방식은 아직 불편함. 최근 UML을 생각해 봤는데, 과거에는 코드 생성 후 구현 과정의 변경을 다시 모델에 반영하는 왕복 작업이 문제였음. UML이 정답이라고 보지는 않지만, 빽빽한 장문의 텍스트도 답은 아닌 듯함.
내 경험은 반대임. 명세 기반 개발을 하면 유지보수가 훨씬 쉬워짐. 계획 없이 프롬프트만 마구 던지면 금방 무너지게 됨.
PR마다 생성된 코드를 읽고 흐름이 직관적이고 이해하기 쉬운지 확인했는지? 유지보수하기 어려운 코드를 무작정 병합해야 프로젝트도 유지보수 불가능한 난장판이 되는 것임.
이런 글에는 늘 어떤 모델을 언제 썼는지가 빠져 있음. 예를 들어 GPT 3와 6은 차이가 엄청남. 2025년 말에는 에이전트가 이전처럼 일일이 챙겨주지 않아도 상당 부분 자율적으로 코딩할 수 있게 되는 도약이 있었음. 변화가 워낙 커서 솔직히 그 이전의 AI 평가를 듣는 것은 별 의미가 없다고 봄.
이 정책 때문에 진행 중이던 내 PR도 닫혔음. 네트워크 애플릿의 VPN 비밀번호 문제를 Claude와 함께 파악하고 수정했음. 직접 다듬고 품질을 확인하는 데도 많은 시간을 썼으며, 프로젝트의 결정을 존중하고 악감정은 없음. 그래도 오픈소스에 기여할 시간과 기회를 찾기 어려웠던 입장에서는 작은 좌절이었음.
커밋을 찾아봤는데 AI 사용은 합리적이었고, PR 본문과 이후 댓글·대화도 사람이 쓴 것으로 보임. 이미 진행 중이던 PR을 그렇게 닫아서는 안 됐다고 봄.
이렇게 하면 사용 사실을 솔직하게 밝히는 개발자만 밀려나고, 앞으로는 숨기는 이들이 늘어날 것임.
여기서 “직접 다듬었다”는 건 구체적으로 무엇을 뜻하는지?
보여주기식 조치일 뿐임. 수천 개의 오픈소스 패키지 위에 OS를 만들고 있고, 그중 상당수에는 AI 생성 코드가 들어 있음. 하나씩 감사해서 해당 패키지를 제거할 것인지? 제거하면 OS가 복구 불가능할 정도로 망가지는 패키지는 어떻게 할 것인지?
보여주기식이 아님. 기사를 읽어보면 금지할 만한 이유가 있으며, LLM을 싫어해서가 아님.
PopOS에 직접 들어오는 기여에서 LLM 생성 코드를 어떻게 알아낼지도 해결되지 않음. Claude 공동 작성 표시가 붙은 PR이나 작성 주체와 무관하게 품질이 낮은 코드 외에, 유지보수자가 무엇으로 구별할 수 있는지 모르겠음.
PopOS는 Ubuntu에 문제를 더한 배포판임. Ubuntu 자체는 괜찮은데 PopOS가 이상한 동작을 덧붙임. Cosmic은 대체 얼마나 오래 베타 상태인 것인지?
보여주기식이라고 생각하지 않음. AI가 나쁜 코드를 만든다거나 세상에 해롭다고 하는 게 아님. 핵심은 검토할 시간이 부족할 만큼 많은 PR과 추가할 계획이 없는 기능이 쏟아진다는 데 있음.
주된 목적은 자체 검토 파이프라인에 역압을 걸어 유입량을 조절하려는 것으로 보임.
AI가 사이버 보안과 제로데이 발견을 점점 잘하게 되는데, 공격자와 방어자 사이의 격차를 어떻게 감당할지 모르겠음. 충분히 비주류인 OS라 상관없을 수도 있겠지만?
pop_os와 Cosmic의 점유율이 워낙 작아 공격자에게 중요하지 않기 때문일 것임. 공격자는 시간과 노력을 들일 가치가 더 큰 대상을 노리며, Arch AUR 공격을 보면 이해하기 쉬움.
Linux를 모르는 일반인은 물론 HN과 Linux 사용자 사이에서도 pop_os는 비주류임. 그러니 자기 실험 공간처럼 다루면서 사람이 쓴 코드만 받는 원칙을 고수할 여유가 있음.
반면 Fedora와 Debian 같은 큰 프로젝트는 현실의 개발과 위협에 대응하려면 사람이 검토한 AI 코드를 받아야 한다는 점에서 더 실용적임. Linus Torvalds도 같은 취지로 말했음. 특히 침투 테스트와 역공학에서는 이미 되돌릴 수 없는 단계임. AI는 숙련된 연구자도 능가하는 방식으로 무차별 탐색을 할 수 있으므로, 이에 맞서려면 AI가 만든 수정 사항을 받아들이는 수밖에 없음.
사실상 지속적인 저강도 DDoS나 다름없는 멍청하고 공격적인 스크레이퍼로 오픈소스 코드를 모조리 긁어가고, 수십억 달러를 써서 수조 개의 매개변수를 조정한 끝에 내놓는 가치가 “나쁜 코드로 도배하게 해주지 않으면 취약점 공격 코드를 만들겠다”는 것인지?
취약점 발견에 AI를 쓰는 것과 수정 코드를 AI로 생성해야 한다는 것은 별개임. 수정은 직접 하고 AI에게 추가 검토를 부탁할 수도 있음.
정작 Linux 커널처럼 AI 기여를 받는 상위 프로젝트의 혜택은 누리게 된다는 점이 아이러니함.
AI가 “취약점”을 많이 찾기는 하지만 대부분은 가짜이거나, 검증되지 않았거나, 실제 취약점이 아님. AI는 꽤 멍청하다는 점을 잊지 말아야 함.
논란이 될 수 있겠지만 LLM 코드 토큰은 공짜가 아님. 나도 제법 큰 프로젝트를 하다 보면 주간 한도를 자주 소진하는데, 누가 자기 돈을 써가며 일부러 나쁜 PR을 만들고 싶어 할지 이해하기 어려움. 반증이 없다면 선의를 가정하고 싶고, 핵심은 검토 절차와 정책을 시대에 맞게 바꾸는 것인데 대형 오픈소스 프로젝트의 사실상 전면 금지는 과해 보임.
올해 초 한 오픈소스 게임 엔진에 기여했는데, 2021년경부터 있던 텍스트 렌더링 버그 때문에 실서비스에 쓰기 어려웠고 나와 커뮤니티는 여러 우회책을 만들어 쓰고 있었음. 결국 Claude에게 디버깅을 맡겼더니 10분 만에 원인을 찾았고 수정은 렌더러 코드 3줄이었음.
회귀 테스트를 작성하고 버그를 문서화해 PR을 열었으며, 일주일 안에는 병합될 줄 알았음. 유지보수자들의 반응도 좋았지만 거의 6개월간 방치되다가 상위 저장소의 잘못된 스쿼시 처리로 닫혔고, 버그도 아직 남아 있는 것으로 보임. 참고로 누군가 AI를 활용해 내 GitHub 프로젝트에 기여한다면 무척 반가울 것임.
모두가 꿈꾸는 건 AI가 오픈소스 프로젝트를 자동으로 운영하는 것처럼 느껴짐. 토큰은 결코 공짜가 되지 않을 것이고 Anthropic은 기업공개도 해야 함. 개인 비용을 들인다는 점은 흥미롭지만, 나쁜 PR이 고의일 가능성은 낮아도 저품질 결과물을 검토하고 정리하는 규율은 부족할 수 있지 않을지?
문제의 핵심이 코드인지, 아니면 AI가 쓴 PR과 유지보수자에게 보내는 메시지인지 궁금함. 나는 AI로 대화를 대신하는 사람은 그냥 차단함. 이미 Opus와 충분히 이야기하고 있어서 더 대화하고 싶지는 않음.
문제는 올해 8월쯤 이미 사라진 옛 소프트웨어 개발 방식에 고착되어 AI로 기존 작업 흐름만 기계화하려는 데 있음. PR 변경분의 글자 하나하나를 직접 확인해야 한다는 태도도 이제는 지독하게 비생산적임.
이 정책 때문에 내 PR도 닫혔음. 내가 오작동을 발견하고 발생 양상을 구체화한 뒤 Claude가 수정했으며, 검증은 직접 했음. 이 수정이 없었다면 적어도 COSMIC은 포기했을 것이고 배포판 자체를 떠났을 수도 있음. 사용을 시작하기 전 이미 1.x에 도달했던 COSMIC이 앞으로 어떻게 성숙할지, 내가 계속 남을지 의문이 생김.
처음 선택한 것은 COSMIC이 없던 Pop!_OS 22.04였음. Ubuntu의 안정성과 최신 커널을 함께 제공하는 제법 인기 있는 배포판이라는 점이 이유였지, COSMIC에 끌린 것은 아니었음. 버그와 안정성 우려로 24.04 업그레이드도 오래 미뤘지만, 결국 22.04의 ibus 관련 문제 때문에 옮겨야 했음.
Rust도, 버그의 핵심 프로토콜도 잘 모르므로 혼자서는 이해하고 수정할 엄두도 시간도 없었을 것임. PR이 닫힌 이상 버그 신고 역할조차 하기 어려워 보임. 다른 사용자들도 같은 버그를 겪으며 수정을 기다리고 있음. 나는 당분간 내 포크를 계속 사용하면서 천천히 방향을 정할 예정이며, 지금까지 유지 부담은 전혀 없었음.
일반적인 버그 보고서를 직접 작성해서 제출해 보면 어떨지?
전 AWS CTO인 AWS 전문가도 비슷한 주제로 토론 중임. “AI가 모든 소프트웨어 개발팀에서 긍정적인 결과로 이어지는 것은 아닌 듯함. 고객들이 팀의 AI 도입 속도를 늦춰야 하는지 묻고 있는데, 어떻게 답해야 할지? 찬성인지, 반대인지?”라는 질문임. https://www.linkedin.com/feed/update/urn:li:activity:7510679...
학습 습관과 AI 에이전트 활용 숙련도, 더 나은 작업 흐름이 일부 영향을 주겠지만, AI 자체도 아직 완벽하지 않은 것 아닌지?
“많은 AI 기여가 계획에 없던 것이고 소프트웨어 아키텍처에 대한 이해도 부족해서, 자체 팀과 꾸준히 기여해 온 이들의 작업을 우선하고 싶다”는 취지라면 열성적인 LLM 사용자에게도 합리적으로 들릴 듯함. 어디엔가는 선을 그어야 함. 이 기준은 너무 단순하지만 당분간은 효과가 있을 것임.
이렇게 하면 각자 포크를 유지하는 방향으로 가게 됨. 이미 에이전트로 버그를 조사하고 수정해 PR까지 보낼 수 있다면, 로컬 포크를 유지하는 추가 비용은 아주 적음.
실제로 나도 그렇게 하기 시작했음. PR을 보내고 왜 수정이 필요한지 유지보수자를 설득하는 데 너무 많은 노력이 들기 때문임.