Skip to content
industry insights

Linus Torvalds의 AI 테스트, 3개의 숨겨진 버그 발견

수십 년 된 커널 라이브러리의 코드에 제작자조차 읽기 어려워했던 결함이 숨겨져 있었습니다. 현재 AI를 둘러싼 논쟁은 유지보수 관리자의 제한된 시간과 강제하기 어려운 규칙 사이의 갈등으로 이어지고 있습니다.

Cassidy Wolfe
Linus Torvalds의 AI 테스트, 3개의 숨겨진 버그 발견

LLM이 2013년 코드를 읽기 쉽게 만들고 추가 버그를 발견하다

성실한 개발자인 Nils Ollrogge는 최근 Linux 커널의 assoc_array 구현에서 버그를 보고했습니다. Linus Torvalds조차도 이 코드가 "너무 난해해서" 이해하기 어렵다고 솔직하게 인정했습니다. 이러한 복잡성은 예상치 못한 AI의 개입을 위한 발판이 되었습니다.

실용주의자인 Torvalds는 복잡하게 얽힌 코드를 풀기 위해 최신 LLM을 활용했습니다. 그는 AI에게 불투명한 함수를 읽기 쉽고 관리 가능한 구성 요소로 분해하도록 지시했습니다. 명확해진 결과물은 사용자 공간 하네스 내에서 엄격한 테스트를 거쳤으며, 강력한 분석 도구로서 LLM의 유용성을 입증했습니다.

이 과정은 Ollrogge가 발견한 원래의 버그를 확인했을 뿐만 아니라, 오랫동안 존재해 온 3개의 추가 결함을 밝혀냈습니다. 이러한 숨겨진 문제들은 2013년 assoc_array 라이브러리의 초기 커밋까지 거슬러 올라갑니다. 따라서 LLM은 자율적인 버그 수정자가 아니라 조사 파트너로서 기능했으며, Torvalds가 복잡한 레거시 코드를 이해하고 감사하는 능력을 크게 향상시켰습니다.

커널의 AI 패치 홍수가 초래하는 인적 비용

그러나 AI 도구에 대한 Torvalds의 새로운 인식은 현재 Linux 커널에 쏟아지는 무분별한 AI 생성 제출물까지 확장되지는 않습니다. 최근 프라하에서 열린 유지보수 관리자 서밋에서 기여자들과 관리자들은 Linux 7.3에서만 거의 800명의 신규 기여자가 제출한 패치의 급증으로 어려움을 겪었습니다. 이러한 유입은 AI 지원 개발의 인적 비용이라는 커지는 문제를 지적합니다.

공식 수치에 따르면 Linux 7.3의 18,500개 변경 사항 중 약 1,800개만이 Assisted-by 태그를 달고 있으며, 이는 전체 제출물의 10%에 불과합니다. 그러나 관리자들은 실제 LLM 사용률이 90%에 달할 정도로 훨씬 높을 것으로 추정합니다. 이는 정확한 감사가 아닌 추정치이지만, 투명성과 실제 관행 사이의 상당한 괴리를 강조합니다.

진정한 압박은 도구 자체가 아니라 도구의 잘못된 적용에 있습니다. 품질이 낮거나 제대로 이해되지 않은 패치는 검토자의 귀중한 시간을 낭비하게 하여 중요한 개발로부터 자원을 분산시킵니다. 개인적인 용도로 AI를 수용한다고 해서 스팸과 같은 제출 전략을 지지하는 것은 아닙니다. 그가 단호하게 말했듯이, 관리자들은 사용하는 도구와 상관없이 역량과 이해도를 기대합니다.

Torvalds가 도구 금지를 "완전히 어리석은 일"이라고 말하는 이유

제안된 Assisted-by: 태그 제거는 격렬한 논쟁을 불러일으켰고, 공개와 책임에 대한 근본적인 의견 차이를 드러냈습니다. 관리자들은 검증되지 않은 AI 생성 코드가 유입될 것을 우려하며 안전장치를 잃는 것에 대해 걱정했습니다. 그러나 현실은 냉혹했습니다. Linux 7.3의 약 18,500개 비병합 커밋 중 약 1,800개만이 태그를 달았지만, 추정치에 따르면 기여자의 90%가 LLM을 사용했습니다.

예상대로 Linus Torvalds는 도구 금지를 "완전히 어리석은 일"이라고 일축했습니다. 그는 "여기 새로운 규칙이 있습니다. 커널 제출물에 컴파일러를 사용하지 마십시오"라는 강력한 비유로 공개 논쟁을 해체했습니다. 그는 이 논리를 텍스트 편집기까지 확장하며, 컴파일러든 LLM이든 도구 자체가 기여자의 이해도를 증명하거나 반증하지 않는다고 주장했습니다.

Torvalds의 핵심 요점은 분명합니다. 도구 선택은 중요하지 않으며 책임이 가장 중요하다는 것입니다. 기여자는 여전히 자신의 코드를 검증하고, 검토자의 질문에 답하며, 커널 제출 프로세스에 따라 모든 책임을 져야 합니다. 시스템은 소프트웨어 선호도에 대한 선언이 아니라 역량과 주인의식을 요구합니다. 커널 거버넌스에 대한 추가 논의는 The 2026 Maintainers Summit을 참조하십시오.

이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.

하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음

여전히 중요한 원칙: 모든 코드 라인에 대한 책임

강제하기 어려운 공개 태그를 삭제하면 서류 작업은 줄어들 수 있지만, 거버넌스 측면에서 상충하는 문제가 발생합니다. Assisted-by:에 대한 공식적인 요구 사항이 사라지더라도, 메인테이너는 여전히 효과적인 검토 프로세스와 기여자의 명확한 책임 의식을 유지해야 합니다.

중요한 차이점은 도구의 사용 여부가 아니라 사용 방식에 있습니다. 인간 저자가 기여 내용을 설명, 검증 및 수정할 수 있는 AI 보조 개발은 무분별한 복사 붙여넣기나 자동화된 패치 스팸과는 확연히 다릅니다. Linus Torvalds가 직접 LLM을 사용하여 assoc_array 코드를 명확히 하고, 이를 테스트 하네스에 통과시켜 2013년부터 존재했던 세 가지 숨겨진 버그를 찾아낸 사례는 책임감 있는 도구 통합의 좋은 예입니다.

결국 오픈 소스의 핵심은 도구 체인이 아니라 증거, 정확성, 그리고 기여자의 책임에 따라 제출물을 판단하는 것입니다. 프로젝트마다 출처와 라이선스 위험을 다르게 평가할 수 있지만, 궁극적인 시험대는 인간 저자의 소유권입니다. 제출된 모든 코드 라인 뒤에는 여전히 유능하고 책임감 있는 인간이 있어야 합니다.

자주 묻는 질문

LLM은 Linus Torvalds가 무엇을 발견하도록 도왔나요?

Torvalds가 LLM을 사용하여 Linux의 assoc_array 코드를 더 쉽게 이해하고 테스트한 후, 보고된 버그를 확인하고 2013년부터 존재했던 세 가지 추가 버그를 발견했습니다.

AI가 생성한 코드가 Linux 커널에서 금지되었나요?

여기서 논의된 내용은 필수적인 Assisted-by 공개 태그를 삭제하는 것에 관한 것이지, AI 사용을 금지하는 것이 아닙니다. 기여자는 자신이 제출한 코드에 대해 여전히 책임을 집니다.

Linux는 왜 Assisted-by 태그 삭제를 고려했나요?

지지자들은 해당 태그가 거의 사용되지 않고 강제하기 어렵다고 주장한 반면, 비판자들은 이를 삭제할 경우 검토되지 않은 AI 생성 패치에 대한 안전장치가 약화될 수 있다고 우려했습니다.

AI 코딩 도구에 대한 Torvalds의 주된 논점은 무엇인가요?

그는 메인테이너가 어떤 도구가 코드를 생성하는 데 사용되었는지 감시하기보다는, 기여자가 코드를 이해하고 그에 대한 책임을 지는지 여부를 판단해야 한다고 주장합니다.

Found this useful? Share it.

For builders

Want Stork to write one of these about your product?

Send us a URL. We use the product, form a view, and publish what we actually think — in 8 languages, labeled Sponsored, with no copy approval on your side. That last part is what makes it worth quoting.

See how it works$199 · AI tools & software only

빌더를 위해

이 페이지는 지금 다른 사람의 도구를 위해 일하고 있습니다.

AI 에이전트가 읽고, 구매자가 도착합니다. 8개 언어와 MCP로 답합니다. 당신의 도구도 가질 수 있습니다 — 24시간 안에 공개.