이 기사에 대하여

Linux와 Git을 만든 당사자가 AI에 대해 정리하여 이야기하고 있습니다. "AI는 대단하지만, 프로그래밍을 바꾸지는 않았다"라는, 그다운 상대화가 핵심입니다.

흥미로운 점은, Linus 본인이 AI 도구를 사용하고 있다고 명시하고 있다는 점입니다. 흔히 볼 수 있는 "거물이 AI를 부정했다"라는 구도가 아닙니다. 사용해 본 뒤, 어디에 선을 긋고 있는지에 대한 이야기입니다.

이하, 4가지 테마로 정리합니다.

1. 커널 개발에서 실제로 무슨 일이 일어났는가

커밋(Commit)이 약 20% 증가했다

최근 반년 사이, Linux 커널의 커밋 수가 명확하게 증가했습니다. 최근 2개 릴리스에서 약 20% 증가했습니다.

Linus 본인도 처음에는 "7.0 릴리스라서 분위기가 달아오른 것이겠지"라고 생각했다고 합니다. 메이저 버전이 올라가면 각 기업이 막판에 기능을 밀어 넣는 과거의 패턴(6.0 때)을 떠올린 것입니다.

하지만 그것은 틀렸다고 본인이 말하고 있습니다. 진짜 변화는, AI 도구가 많은 사람에게 실용적인 수준에 도달했다는 것이었습니다. 커널에 패치(Patch)를 제출하기까지의 초기 장벽이 낮아졌고, 도구가 작업의 상당 부분을 맡게 되었다는 것입니다.

숫자로 영향을 인정한 발언으로서 꽤 드문 사례라고 생각합니다.

AI가 발견한 버그는 "이미 공개된 것"으로 취급한다

운영 면에서는 보안 정책을 변경하고 있습니다.

AI를 사용하여 버그를 발견했다면, 그것은 이미 공개된 것으로 간주해야 한다——이유는 단순합니다. 당신이 AI로 발견했다면, 다른 100명도 AI로 발견하고 있기 때문입니다.

다만 선긋기도 있습니다. 정말로 익스플로잇(Exploit)이 될 수 있는 것에 대해서는, 수법까지 공개하지 마라고 경고하고 있습니다. "이 방법으로 대기업을 무너뜨릴 수 있다"라고 득의양양하게 공표하는 쪽이 되지 마라, 금요일 오후에 누군가의 인생을 망치는 일은 하지 마라, 라고 말입니다. 이는 Linux 커널에만 국한된 이야기가 아니라고 덧붙였습니다.

수정 3시간 후에는 블로그가 올라온다

지난주의 실례로서, 버그를 수정한 후 3시간 뒤에는 그 수정의 의미를 해설하는 블로그 기사가 공개되었다는 이야기가 나옵니다.

Linus의 견해는 구조적입니다. 보안 관계자들에게는 "가장 먼저 말하는 것"에 대한 강력한 인센티브가 있습니다. 가장 먼저 쓰면 뉴스가 되고 주목을 받습니다. 그래서 속보화는 멈추지 않으며, 이것이 앞으로의 표준이 될 것이라고 합니다.

클로즈드 소스(Closed Source)가 더 불리하다는 역설

"클로즈드 소스라면 AI가 리버스 엔지니어링(Reverse Engineering)을 하지 못할 것"이라고 생각한다면 놀라게 될 것이라고 Linus는 말합니다. AI는 닫힌 코드에서도 문제를 찾아낼 수 있습니다.

그리고 중요한 것은 여기서부터입니다. AI는 문제를 찾는 데 도움을 줄 수는 있어도, 수정을 도와주지는 않는다. 외부의 사람이 고칠 수 없는 만큼, 닫혀 있는 쪽이 오히려 불리해진다는 이야기입니다.

2. "99% AI가 작성했다"에 대한 반론

이번 회차에서 가장 어조가 강한 부분입니다.

"코드의 99%는 AI가 작성했다"라고 말하는 사람을 보면,

진심으로 화가 난다

라는 이유가 그다운 답변입니다. 그 사람들의 코드는 100% 컴파일러(Compiler)가 작성하고 있다. 하지만 아무도 그렇게 말하지 않는다. 똑같은 일인데 말이다, 라고 합니다.

Linus 자신의 이력이 배경에 있습니다. 그는 머신 코드(Machine Code)를 쓰며 자란 세대이며, 심지어 어셈블리(Assembly)가 아니라 수치 그 자체를 입력하고 있었습니다 (6502의 LDA가 16진수로 A9라는 이야기가 나옵니다).

그러다 분기 오프셋(Branch Offset)을 일일이 계산하는 것은 바보 같은 짓이라는 것을 깨닫고 어셈블러(Assembler)라는 도구가 나타났습니다. 그다음에는 컴파일러가 좋다는 것을 알게 되었습니다. 그리고 지금, AI 도구도 좋다는 것을 알게 되었습니다. 코드는 지금도 내가 쓰고 있다. 다만 옛날과 같은 방식이 아닐 뿐이다——라는 정리입니다.

AI는 ×10, 컴파일러는 ×1000

이 흐름에서 나오는 것이 이번 회차에서 가장 인상 깊은 숫자의 대비입니다.

AI는 생산성을 10배로 만들지도 모른다. 하지만

컴파일러는 1000배로 만들었다.

AI는 과거의 혁명과 같은 의미에서 혁명적이라고 Linus는 인정합니다. 많은 사람이 AI로 코드를 생성하고, 그 코드를 컴파일러가 처리하며, 어셈블러가 머신 코드로 만든다——계층이 하나 늘어났을 뿐이라고 말입니다.

그 위에서 "AI는 훌륭하지만, 프로그래밍의 본질은 바꾸지 않았다. 다른 분야는 바꾸고 있을지도 모르지만, 나는 프로그래머이기에 잘 모르겠다"라고 단언합니다.

3. 35년 동안 유지보수하는 코드 이야기

"바이브 코딩(Vibe Coding)"이라는 용어를 Linus 본인이 사용하고 있습니다. 게다가 부정하지도 않습니다.

새로운 프로젝트를 빠르게 생성해서 한 번 쓰고 버린다——이런 용도로는 AI가 최고다라고 말합니다. 이것을 바이브 코딩(Vibe Coding)이라고 부르고 있다고 말이죠.

문제는 그렇지 않은 경우입니다.

진지한 것을 만든다면,

35년 동안 계속 유지보수해야 할지도 모릅니다. 그 시점에서는 프롬프트를 작성해서 누군가에게 코드를 생성하게 하는 것만으로는 끝나지 않습니다.

장기적으로 유지보수하려면, 자신의 프롬프트뿐만 아니라 최종적인 결과물도 이해하고 있어야 한다는 것이 그의 입장입니다. 그것이 장기 유지보수의 유일한 방법이라는 것입니다.

35년이라는 숫자가 실감을 동반하고 있다는 점이, 이 사람의 경우에는 강력하게 다가옵니다.

4. AI를 사용하지 않기로 결정한 곳

Linus는 "AI 도구는 사용한다"라고 명시하고 있습니다. Google이 준비한 자동화 도구를 포함해, 커널 개발에서는 많은 자동화가 작동하고 있다고도 합니다.

그 위에서, 그는 이렇게 말합니다.

내 일은

사람과 함께 일하는 것이다. 사람과 일하는 데 AI는 사용하지 않는다. 당신들도 그러지 않는 것이 좋다.

전제로, 탑 레벨 메인테이너(Maintainer)인 자신은 코드를 그리 많이 쓰지 않는다며, 코드는 취미 프로젝트나 기타 페달(Guitar Pedal)을 즐기기 위해 쓰고 있다고 언급합니다. 그 바탕 위에서의 선긋기입니다.

짧은 발언이지만, AI를 어디까지 도입할 것인가라는 이야기 속에서는 꽤 묵직한 한마디라고 생각했습니다.

5. 25년 전과 같은 고통

마지막으로, 변화 그 자체에 대한 이야기입니다.

Linux에서 큰 고통을 수반했던 것은 코드 그 자체보다도 일하는 방식을 바꾸지 않을 수 없었을 때였다고, Linus는 회상합니다.

2000년경, Linux가 성장해 나가는 과정에서 자기 자신이 스케일(Scale)하지 못하게 되었고, 일하는 방식을 근본적으로 바꿀 필요가 생겼다. 그것은 커널 개발에서 특히 힘들었던 사건 중 하나로 지금도 기억하고 있다고 합니다.

그리고, 그로부터 25년. 지금 다시 같은 종류의 변화가 오고 있다는 것이 그의 견해입니다. 사람은 방식이 굳어지면 "나는 이렇게 한다, 이렇게 하는 것을 좋아한다"라는 틀에 빠지게 됩니다. 그곳에 무언가가 찾아와 편안한 장소에서 끌어내 버립니다.

다만 이번에는 방향이 다릅니다.

25년 전에는 Linux가 스케일하지 못했습니다.

지금은 코드가 아니라, 사람이 반드시 스케일하는 것은 아닙니다.

AI가 생성한 버그 보고나 코드를 둘러싸고 사회적 마찰이 일어나고 있는 것도, 도구 사용법을 익히는 데 시간이 걸리기 때문이라고 이어집니다.

감상

"AI는 도구다"라는 말 자체는 자주 듣지만, 컴파일러(Compiler)를 예로 들어 배율로 비교하는 것은 이 사람만의 방식이라고 생각했습니다. $\times 10$과 $\times 1000$이라는 숫자를 나란히 배치하니, 지금의 열광적인 위치가 갑자기 상대화됩니다.

동시에, 부정하지 않고 있다는 점이 인상적이었습니다. 사용하고 있고, 커밋(Commit)이 20% 늘어났다는 사실도 인정하고 있으며, 보안 운영도 바꾸고 있습니다. 그 위에서 "본질은 바꾸지 않았다"라고 말하고 있습니다. 찬성하느냐와는 별개로, 입장이 일관적입니다.

35년 유지보수하는 이야기와, 25년 전에 자신이 병목(Bottleneck)이 되었던 이야기가 같은 회차에 들어있는 것도 효과적입니다. 긴 시간축으로 같은 것을 계속 지켜봐 온 사람의 이야기로 들으니 무게감이 달랐습니다.

원본 영상

Keynote: Linus Torvalds, Creator of Linux & Git with Dirk Hohndel, Founder, DH Consulting

Open Source Summit North America 2026 / The Linux Foundation

일본어 자막이 포함된 다이제스트 버전(약 8분)도 공개되어 있습니다.

• 게시 전 예측: 5회 연속으로 예측을 틀렸기에, 예측하는 방법 자체를 바꿨다
• 지난번 해설: opencode 제작자 Dax Raad의 이야기를 요점 해설
• 영상: TikTok @talks.tldr.jp

Discussion