Pop!_OS, 코드베이스 상당 부분에서 AI 생성 코드 금지

Hacker News 의견들 AI가 약속한 많은 것을 실현하지 못한다고 느껴 AI에 맡기는 범위를 줄였음. 내 프로젝트들이 유지보수 불가능한 난장판으로 변하고 있었기 때문임. 코딩은 이미 해결됐다고 하는 이들은 현실을 제대로 보지 않는 셈임. AI로 프로젝트 두 개를 처음부터 시작했지만, 둘 다 엉망이 되어 포기했음. AI 없이 만든 프로젝트는 관리와 유지보수, 기능 추가·삭제가 훨씬 쉬움. 지금은 AI를 Google 대신 프로젝트용 검색 도구로 쓰며, 코드의 문제를 물어본 뒤 내 경험을 바탕으로 직접 수정하고 개선함. 특히 소프트웨어 개발을 하지 않는 이들은 코딩과 소프트웨어 개발을 혼동하곤 함. 모델은 아키텍처와 설계에는 약하지만, 그에 관한 지시는 잘 따르고 리팩터링도 상당히 잘함. 투자할 가치가 있는지 판단한 뒤라면 바이브 코딩으로 만든 코드베이스를 에이전트로 정리할 수 있고, 처음부터 충분한 설계 지침을 주면 난장판을 피할 수도 있음. 다만 이 지침을 순전히 텍스트로 전달하는 방식은 아직 불편함. 최근 UML을 생각해 봤는데, 과거에는 코드 생성 후 구현 과정의 변경을 다시 모델에 반영하는 왕복 작업이 문제였음. UML이 정답이라고 보지는 않지만, 빽빽한 장문의 텍스트도 답은 아닌 듯함. 내 경험은 반대임. 명세 기반 개발을 하면 유지보수가 훨씬 쉬워짐. 계획 없이 프롬프트만 마구 던지면 금방 무너지게 됨. PR마다 생성된 코드를 읽고 흐름이 직관적이고 이해하기 쉬운지 확인했는지? 유지보수하기 어려운 코드를 무작정 병합해야 프로젝트도 유지보수 불가능한 난장판이 되는 것임. 이런 글에는 늘 어떤 모델을 언제 썼는지가 빠져 있음. 예를 들어 GPT 3와 6은 차이가 엄청남. 2025년 말에는 에이전트가 이전처럼 일일이 챙겨주지 않아도 상당 부분 자율적으로 코딩할 수 있게 되는 도약이 있었음. 변화가 워낙 커서 솔직히 그 이전의 AI 평가를 듣는 것은 별 의미가 없다고 봄. 이 정책 때문에 진행 중이던 내 PR도 닫혔음. 네트워크 애플릿의 VPN 비밀번호 문제를 Claude와 함께 파악하고 수정했음. 직접 다듬고 품질을 확인하는 데도 많은 시간을 썼으며, 프로젝트의 결정을 존중하고 악감정은 없음. 그래도 오픈소스에 기여할 시간과 기회를 찾기 어려웠던 입장에서는 작은 좌절이었음. 커밋을 찾아봤는데 AI 사용은 합리적이었고, PR 본문과 이후 댓글·대화도 사람이 쓴 것으로 보임. 이미 진행 중이던 PR을 그렇게...