리누스 토르발스 “AI는 좋은 도구지만, 프로그래머를 대체하진 않는다”

리눅스 커널에도 AI발 변화가 이미 들어옴

• 리누스 토르발스가 Open Source Summit North America에서 AI 도구에 대한 꽤 현실적인 입장을 냄

  • 한 줄로 요약하면 “AI는 훌륭한 도구지만, 어디까지나 도구”라는 쪽임
  • 프로그래머가 사라진다는 식의 마케팅 문구에는 꽤 강하게 반발함

• 리눅스 커널 개발 흐름에도 숫자로 보이는 변화가 생김

  • 토르발스에 따르면 Git으로 옮긴 뒤 약 20년 동안 커널 릴리스 프로세스는 꽤 안정적이었음
  • 그런데 최근 6개월, 특히 최근 두 번의 릴리스에서 커밋 수가 장기간 평균보다 약 20% 늘었다고 함

• 처음에는 리눅스 7.0 같은 큰 버전 변화 때문에 사람들이 들뜬 줄 알았다고 함

  • 하지만 실제 원인은 AI 코딩 도구가 충분히 좋아져서 더 많은 사람이 더 많은 영역에서 개발에 참여하기 시작한 쪽에 가까웠음
  • 도구가 진입장벽을 낮추고, 초반 작업의 큰 덩어리를 대신해주는 효과가 나타난 셈임

보안 메일링 리스트가 AI 리포트에 잠김

• 가장 큰 문제 중 하나는 리눅스 커널 보안 메일링 리스트였음

  • 토르발스는 이 리스트가 AI로 생성된 중복 제보에 “overrun”됐다고 표현함
  • 보안 리스트는 원래 소수의 사람이 민감한 취약점 정보를 다루는 제한된 공간인데, AI 버그 제보가 쏟아지며 병목이 됨

• 패턴은 이렇다고 함

  • 누군가 AI로 버그를 찾음
  • “보안 영향이 있을지도?”라고 생각하고 곧장 보안 리스트로 보냄
  • 리스트에 있는 소수의 사람들은 그걸 다시 해당 영역을 잘 아는 개발자에게 넘기느라 시간을 씀

• 그래서 토르발스는 AI 보안 제보에 대한 새 지침을 내놨음

  • “AI로 찾은 보안 버그는 사실상 공개된 것으로 간주하라”는 규칙임
  • 이유는 단순함. AI로 당신이 찾았다면, 다른 100명도 AI로 찾았을 가능성이 있다는 것

• 그렇다고 익스플로잇까지 공개하라는 뜻은 아님

  • 실제 보안 이슈라면 작동하는 공격 코드를 공개하지 말라고 당부함
  • “큰 회사를 다운시킬 수 있다”고 떠벌리는 식의 행동을 하지 말라는 얘기임

AI는 닫힌 소스를 안전하게 만들어주지 않음

• 토르발스는 “그럼 오픈소스를 닫으면 되나?”라는 방향도 잘라냄

  • AI가 닫힌 소스를 리버스 엔지니어링하지 못할 거라고 생각하면 놀라게 될 거라고 말함
  • 오히려 닫힌 소스는 더 나쁠 수 있다고 봄. AI가 문제를 찾는 데는 도움이 되지만, 고치는 데는 커뮤니티의 도움을 받기 어렵기 때문임

• 보안 생태계 자체도 더 빨라지고 있음

  • 예전에는 커널 커뮤니티가 배포판에 조용히 버그를 알리고 업데이트를 요청하면, 대부분은 어떤 취약점인지 알아채지 못했다고 함
  • 이제는 버그 수정 후 3시간 만에 그 패치의 보안 영향을 분석한 블로그 글이 올라오는 식임

• 취약점 홍보를 먼저 하는 업체들에 대한 비판도 나옴

  • Dirk Hohndel은 최근 커널 로컬 권한 상승 버그 4개 중 2개가 유지보수자에게 연락되기 전에 브랜드명, 도메인, 로고까지 붙어 공개됐다고 지적함
  • 이런 방식은 커널뿐 아니라 어떤 프로젝트에도 신뢰하기 어렵다는 메시지임

토르발스의 AI 감정은 진짜 love-hate에 가까움

• 토르발스는 AI를 기술적으로는 좋아한다고 말함

  • 도구 자체는 유용하고 흥미롭다고 봄
  • 다만 그 도구가 만들어내는 사회적 병목과 고통도 동시에 인정함

• AI가 버그를 찾는 건 장기적으로 좋은 일이라고도 봄

  • 발견된 버그는 고칠 수 있고, 결과적으로 코드가 좋아짐
  • 진짜 문제는 찾지 못한 버그들이라는 관점임

• 하지만 AI가 만들어내는 트래픽은 작은 오픈소스 프로젝트에 특히 위험함

  • 리눅스 커널처럼 대형 프로젝트도 부담을 느끼는데, 수만 개의 작은 프로젝트는 유지보수자가 한두 명인 경우가 많음
  • AI로 대충 생성한 버그 리포트를 던져놓고, 추가 정보를 요청하면 답도 안 하는 drive-by 제보는 유지보수자를 지치게 만듦

“99% AI가 코드를 쓴다”는 말에 화나는 이유

• 토르발스는 “우리 코드의 99%가 AI가 쓴다”는 식의 주장에 문자 그대로 화가 난다고 함

  • 그는 이미 “100%의 코드는 컴파일러가 쓴다”고 비유함
  • 사람은 기계어 숫자를 직접 쓰던 시절에서 어셈블러, 컴파일러, 그리고 AI 도구로 넘어왔을 뿐이라는 설명임

• 생산성 향상은 인정함

  • 컴파일러가 생산성을 1000배 올렸다면, AI는 10배쯤 올릴 수 있다고 봄
  • 하지만 그렇다고 프로그래밍의 기본이 바뀌는 건 아니라고 선을 그음

• 핵심은 결과물을 이해해야 한다는 것임

  • 토르발스는 개인 장난감 프로젝트에서도 AI가 만든 코드를 보고, 필요하면 어셈블리까지 확인한다고 말함
  • 오래 유지해야 하는 시스템이라면 프롬프트만 이해해서는 부족하고, 최종 결과물까지 이해해야 유지보수가 가능하다는 얘기임

• 그의 현재 업무도 이 관점을 잘 보여줌

  • 최상위 유지보수자로서 토르발스는 코딩보다 사람들과 일하는 비중이 크다고 함
  • 그리고 “사람과 일하는 데 AI를 쓰지 않는다. 여러분도 그러지 말라”고 덧붙임. 꽤 토르발스다운 결론임

---

기술 맥락

• 이 기사에서 중요한 선택은 AI로 찾은 보안 버그를 기존 비공개 취약점 처리 흐름에 그대로 넣을지, 공개에 가까운 방식으로 다룰지예요. 토르발스는 AI로 찾은 버그는 다른 사람도 쉽게 찾을 수 있으니 사실상 공개된 것으로 봐야 한다고 판단했어요.

• 이 판단의 배경에는 리눅스 커널 보안 메일링 리스트의 구조가 있어요. 원래는 소수의 사람이 민감한 정보를 조율하는 통로인데, AI가 만든 중복 제보가 몰리면 그 소수에게 모든 분류와 전달 부담이 쌓이거든요.

• AI가 커밋 수를 약 20% 늘린 것도 단순 생산성 뉴스로만 보면 부족해요. 코드 작성 속도만 빨라진 게 아니라 리뷰, 보안 분류, 유지보수자 응답 같은 사회적 시스템까지 같이 압박받는다는 뜻이에요.

• 토르발스가 AI를 컴파일러에 비유한 이유도 여기 있어요. 도구가 코드를 더 쉽게 만들 수는 있지만, 장기 운영되는 커널 같은 시스템에서는 결과물을 이해하고 책임지는 사람이 여전히 필요해요.

• 특히 작은 오픈소스 프로젝트는 이 변화에 더 취약해요. 리포트가 많아지는 것 자체보다, 재현 안 되는 AI 제보를 유지보수자가 계속 검증해야 하는 비용이 문제거든요.