Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Linus Torvalds가 Claude Code를 활용하여 Linux 커널 개선 작업을 진행하고 있다는 소식을 전하며, AI 코드 생성의 현황과 한계에 대해 논합니다. 특히 LLM이 만들어내는 문체와 코드가 인간이 작성한 코드와 오류 양상이 다르다는 점을 지적했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기패치 메시지를 읽으니 솔직히 낙담하게 됨. AI가 적어도 코드 검토에는 쓸모가 있다는 데는 다들 동의할 듯함. 코드 생성에 쓰는 것은 논쟁적이지만 실제로 많은 이들이 선택하고 있음. 그래도 사람을 위한 글까지 AI 양산물로 대체하는 것에는 선을 그었으면 함. Linus에 따르면 이 글의 초안은 LLM으로 작성했음.
“참조도, 스택 위 임시 버퍼도, seqcount도, 복사 후 검사도, 읽기 크기 제한도 없음”, “검증으로 볼 수 없는 지점에서 멈췄음”, “알려진 문제와 검토를 부탁하고 싶은 부분” 같은 문체가 본능적으로 지겨움. 전달력도 떨어지고 사람이 직접 생각한 흔적도 부족하게 느껴짐.
모든 LLM이 만들어내는 이 끔찍한 문체를 더 잘 분류할 방법이 있으면 좋겠음. 지금 AI 양산물을 주제로 논문을 쓰고 있는데, 정규식과 단순한 나이브 베이즈 분류기만으로도 놀라울 만큼 성과를 냈음. 그런데 사람인 나는 거의 즉시 알아채는 문체를 컴퓨터에, 특히 설명 가능한 방식으로 가르치기는 어려워 보임.
이제 이런 글이 어디에나 있음. 내가 이상해진 건가 싶어 동반자와 서로 확인해보지만, 정말 어디에나 퍼져 있음.
AI 코드 생성이 논쟁적이라는 건, 지구 평면설 신봉자들이 둥근 지구를 논쟁적이라고 하는 것과 같은 수준임.
“AI가 내 Linux에 손대는 건 정말 싫다”는 건 윤리 때문인지, 코드 품질 때문인지, 아니면 둘 다인지 궁금함.
윤리 때문이라면 이해함. 품질 때문이라면 Linus Torvalds가 세계에서 가장 경험 많은 코드 검토자라는 주장은 충분히 설득력 있음.
형편없는 PR 10만 줄을 읽고 나쁜 코드를 단호히 거절할 사람을 딱 한 명 고른다면 Linus임. 지난 30년간 개발 시간 대부분을 그렇게 보냈고, 거절을 주저하지도 않음. 주류 언론까지 그의 거절 방식을 다루면서 대인관계 교육을 받으러 가야 했을 정도임.
조금 도발하자면, 이제부터 LLM은 Linus만 쓰게 하자는 쪽임. 코드를 읽고 Claude에게 솔직한 평가를 해줄 거라고 믿음.
Linus가 LLM 코드 검토에 실패할 거라고 단정할 수는 없지만, LLM 코드는 사람이 쓴 코드와 오류 양상이 달라서 검토 방식도 달라짐. LLM은 정답 여부와 무관하게 적절한 용어를 쓰고 그럴듯한 코드를 쉽게 만들어냄. 반면 사람이 엉성하게 짠 코드에는 특정 습관이나 잘못된 용어처럼 해당 분야에 익숙하지 않다는 단서가 드러나는 경우가 많음.
Linus의 경험이 많다는 건 맞지만, 여기서는 거의 무관하다고 봄. 코드 검토는 각자의 유인에 좌우되며, 하나의 동일한 활동도 아니고 객관적인 부분도 많지 않음.
사람이 제출한 패치를 거절할 때 Linus 자신의 생산성은 손해를 보지 않음. 커널 코드 자체에 대한 구체적인 생산량 목표가 거의 없다는 것이 그의 강점 중 하나임. 개발 절차에 대한 목표는 있고 변경 없는 릴리스 주기를 비생산적이라고 보겠지만, 지난 30년간 변경 제안이 부족했던 적은 없음. 반면 자기 코드 작성 목표를 위해 LLM 출력을 검토하면 수용 기준이 낮아짐. 얼마나 낮아지는지는 알 수 없어도, 남의 코드와 자기 목적을 위한 코드를 검토하는 일의 요구 조건은 크게 다름.
더구나 사람의 패치를 거절하면 장기적으로 생산성이 좋아지는 경우가 많음. 개발자가 커널뿐 아니라 프로젝트의 절차와 가치도 배우기 때문임. 수많은 패치를 거절당하지 않고 하위 시스템 유지관리자가 된 사람은 없다고 봐도 됨. LLM 출력을 거절하면 그런 건설적 효과 없이 코드가 쓰이지 않고 버려질 뿐임.
소프트웨어 공학이 크게 달라졌고, 우리가 사랑했던 모습은 더 이상 존재하지 않는다는 사실을 받아들여야 함.
잡음은 늘고 오픈소스는 혼란스러워졌으며, 매일 수많은 정보 유출을 접함. 단순한 아이디어 단계를 넘었다지만 여전히 설익은 앱 수준인 새 사업 구상들이 쏟아지고 일자리도 잃고 있음. 그래도 일부 프로젝트의 소프트웨어 품질은 개선되고 있음.
지난 1년간 품질이 개선된 프로젝트가 구체적으로 무엇인지 정말 궁금함. 내가 사용하는 소프트웨어는 거의 전부 품질이 터무니없이 떨어졌음. 최신 macOS를 설치한 M5를 쓰는데, 자잘한 오작동과 버그, 결함의 양이 부끄러운 수준을 한참 넘어섬.
Linux에는 이미 LLM이 생성한 코드가 들어 있음. 어차피 피할 방법이 없으니 그 사실 자체는 중요하지 않음. Linux를 컴파일할 수 있는 GCC와 LLVM에도 이미 LLM 생성 코드가 들어 있음. https://codeberg.org/ethical-foss/open-slopware#operating-systems 를 보면, LLM을 완전히 배제하려면 LLM 사용에 반대하는 운영체제를 LLM 없이 작성된 컴파일러로 빌드해야 함. 그러면 모든 Linux 배포판과 BSD 계열, Illumos까지 제외됨. LLM 사용에 반대하는 NetBSD도 GCC와 LLVM을 사용함. Redox가 쓰는 Rust 컴파일러도 LLM의 도움을 받았으니, 아마 남는 건 9front뿐일 텐데 그걸로 모든 일을 하기는 어려울 것임.
펌웨어 코드도 하늘에서 내려오는 게 아니라 사람이 작성함. 요즘은 ‘환각으로 만들어진다’는 표현이 더 어울릴지도 모름. https://codeberg.org/ethical-foss/open-slopware#bootloaders 를 보면 coreboot와 U-Boot도 LLM 사용을 허용함.
LLM 사용이 만연한 것 자체에 불만을 가진 이들도 있음. “피할 수 없으니 중요하지 않다”는 건 너무 무시하거나 배려하지 않는 태도 아닐까?
널리 쓰인다고 포기할 이유는 없음. 저항은 커지고 있고 앞으로도 계속 커질 것임. 아직 초기 단계지만 점점 입지를 넓혀가고 있음.
피할 수 없는 것은 많지만, 그렇다고 정당화되지는 않음.
취지는 이해하지만, Linux의 핵심인 커널을 LLM으로 작성하는 것은 컴퓨터에서 LLM이 쓰인 부분을 샅샅이 찾아내는 일과는 다르다고 봄.
“컴파일러에 LLM 생성 코드가 들어 있으니 LLM을 피한 게 아니다”라는 말은 “결국 전부 어셈블리이니 특정 언어를 선호해봤자 소용없다”는 말만큼 무의미해 보임. 전체 기술 스택을 통제하지 못해도 분명한 입장을 갖고 그 방향으로 밀어붙일 수 있음. 기술에는 타협이 가득하며 어떤 결정도 절대적이지 않음.
위대한 이들이 이렇게 추락하는 걸 보게 됨. AI는 뛰어난 사람을 끌어내려 평범하게 만드는 것임.
어제 Lobsters에 8년간 남아 있던 취약점 두 개를 LLM으로 발견했다는 책임 있는 제보 메일을 받았음. 지난 2년 동안 LLM이 우리 코드베이스에서 찾아낸 오래된 취약점과 버그는 이제 셀 수도 없을 정도임. LLM이 Linus's Law를 현실로 만들고 있음. 평범해지는 것과는 정반대이거나, 평범함의 기준 자체가 더 높은 품질로 재정의되는 듯함.
여기서 “평범하다”는 게 어떤 뜻인지 궁금함. 윤리적인 이유로 반대한다면 이해하지만, 이 맥락에서 평범함이 무엇을 의미하는지 모르겠음.