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

완전히 쇼에 불과합니다.

당신은 수천 개의 오픈소스 패키지 위에 OS를 구축하는데, 그중 많은 패키지에 AI 생성 코드가 포함되어 있습니다. 그것들을 하나하나 감사해서 문제 있는 패키지를 제거할 건가요? OS가 복구 불가능하게 망가질 것이기 때문에 제거하지 않을 패키지들은 또 어떻게 할 건가요?

이 일 때문에 제가 올려둔 PR이 닫혔습니다. VPN용 네트워크 애플릿의 비밀번호 문제가 있었는데, Claude를 사용해 문제를 식별하고 수정안을 도출했습니다. 품질을 보장하기 위해 직접 공들여 작성하는 데 많은 시간을 썼지만, 그들의 결정을 존중하며 악감정은 없습니다. 다만 오픈소스에 기여할 시간과 기회를 찾기 어려웠던 사람으로서는 작은 좌절이었습니다.

여기 AWS 전문가(전 AWS CTO)가 비슷한 주제로 올린 스레드가 진행 중입니다.

"보아하니 AI가 모든 소프트웨어 개발 팀에서 긍정적인 결과를 내지는 않는 것 같습니다. 고객들이 팀 내 AI 도입을 늦춰야 하는지 저에게 묻고 있습니다.

이에 어떻게 답하시겠습니까?

예? 아니오?"

https://www.linkedin.com/feed/update/urn:li:activity:7510679...

일부는 학습 습관, 즉 도구(AI 에이전트) 자체를 능숙하게 사용하고 그 주변의 워크플로우를 개선하는 문제인 것 같지만, AI가 아직 완벽하지는 않은 건가요?

ls가 사이버 보안과 0-day 발견에 점점 능숙해지면서 공격자/방어자 격차 속에서 이것이 어떻게 살아남을지 모르겠습니다... 하지만 어쩌면 충분히 마이너해서 상관없을지도 모르죠?

문제는 대부분 코드인지, 아니면 AI가 작성한 PR과 AI를 이용해 메인테이너와 대화하는 사람들인지 궁금합니다. 저는 개인적으로 후자를 하는 사람은 무조건 차단합니다. 이미 충분히 opus와 대화하고 있으니 더는 하고 싶지 않거든요 ㅋㅋ

자, 논란이 될 수도 있지만, LLM 코드 토큰은 공짜가 아니고 저는 꽤 무거운 프로젝트를 좀 하다 보면 주간 할당량을 꽤 자주 소진합니다. 그래서 누군가가 일부러 나쁜 PR을 만들기 위해 자기 돈을 쓰려고 할 이유를 이해하지 못합니다. 그리고 증명되기 전까지는 사람들의 선의를 가정하는 편인데, 이는 이런 대형 오픈소스 프로젝트에서 LLM이 작성한 코드를 거의 전면 금지하는 것이 다소 극단적으로 보였다는 뜻입니다. 핵심 문제는 리뷰 프로세스/정책이 시대에 맞게 바뀌어야 한다는 것 같았거든요.

예를 들어, 올해 초 저는 2021년경까지 거슬러 올라가는 오래된 텍스트 렌더링 버그 때문에 프로덕션 준비가 안 된 오픈소스 게임 엔진 작업을 돕고 있었는데, 커뮤니티와 저는 이에 대한 광범위한 우회 방법을 개발해 왔습니다. 그래서 어느 날 이제 그만하고 Claude에게 디버깅을 맡겼습니다. Claude가 버그를 찾는 데 10분이 걸렸고, 렌더러에서 3줄의 코드 변경이었습니다(네, 세 줄).

그래서 회귀 테스트를 작성하고 버그를 문서화한 뒤 수정 PR을 열었습니다. 일주일도 안 되어 병합되고 모두 넘어갈 수 있을 거라 생각했죠. 메인테이너들은 PR에서 꽤 잘 받아들였지만, PR은 거의 6개월 동안 병합되지 않고 방치되다가 결국 업스트림에서 잘못된 스쿼시로 닫혔습니다. 버그는 아직도 남아 있을 거라고 확신합니다.

그리고 덧붙이자면, 누군가 AI를 이용해 제 GitHub 프로젝트에 기여하고 싶어 한다면 저는 매우 기쁠 겁니다.

"... 많은 AI 기여가 계획되지 않았고 소프트웨어 아키텍처에 대한 이해가 부족했다. 그래서 팀은 '우리 팀과 정규 기여자의 기여를 우선시하는 것'을 원한다."

열렬한 LLM 사용자에게도 합리적으로 들리네요, 아마도요. 선을 그어야 하니까요. 이 선은 너무 단순하지만, 당장은 효과가 있을 겁니다.