PR을 올렸더니 리뷰어가 댓글로 툭 물어본다. “이거 AI로 짜셨어요?” 순간 어떻게 답해야 할지 말문이 막힌다. 맞다고 솔직히 말하면 코드 전체를 색안경 끼고 볼 것 같고 아니라고 잡아떼자니 거짓말이 된다. 하지만 곰곰이 생각해 보면 리뷰어가 진짜로 궁금한 건 그게 아닐지도 모른다.
2026년 10월 리누스 토발즈는 이 미묘한 질문에 아주 명쾌한 방식으로 답을 내놓았다. 리눅스 커널 저장소에 noref-filemap-read-with-llm이라는 새 브랜치를 직접 올린 것이다. 브랜치 이름 끝자락에 아예 대놓고 LLM을 박아 넣었다. AI 코딩 도구와 함께 만든 패치라는 사실을 숨기기는커녕 제목에서부터 당당하게 밝힌 셈이다.
며칠 뒤 커널 메일링 리스트에서 특정 작업에는 AI 사용을 금지하자는 주장이 올라왔을 때도 토발즈는 단호했다. 그런 규칙은 절대 만들지 않겠다고 잘라 말하면서 대신 기여자들에게 전혀 다른 기준 하나를 내밀었다. 토발즈가 실제로 AI를 어떻게 부려 먹었는지, 그리고 그가 못 박은 ‘이해’라는 기준이 무엇인지 따라가 본다.
브랜치 이름에 LLM을 적어 올렸다
이 패치가 겨냥한 문제는 꽤 구체적이다. 여러 스레드가 동시에 하나의 파일을 잘게 쪼개 읽으면 커널이 급격히 느려지는 현상이다. 범인은 folio(커널이 메모리 페이지를 묶어서 관리하는 단위)의 참조 카운트였다. 참조 카운트는 지금 그 메모리를 몇 군데서 쓰고 있는지 세는 숫자다. 파일을 읽을 때마다 이 숫자를 1씩 올렸다 내리기를 반복하다 보니 똑같은 데이터를 읽기만 하는 스레드끼리도 카운터 변수 하나를 두고 줄을 서서 다투게 된다.
새 패치는 이 참조 카운트를 아예 건드리지 않고 페이지 캐시를 읽는 우회로를 뚫었다. 대신 캐시에서 빠진 메모리는 RCU 유예 기간(이미 진행 중인 읽기 작업이 전부 끝날 때까지 기다려 주는 시간)이 지난 뒤에야 재사용하도록 묶어 뒀다. 덕분에 누군가 읽고 있는 도중에 메모리가 엉뚱한 용도로 덮어써지는 참사를 막을 수 있다.
성능 개선 폭은 엄청났다. 4코어 8스레드 노트북(Core i7-8565U)에서 스레드 8개로 동시에 읽기를 돌렸더니 초당 읽기 처리량이 990만~1,040만 회에서 3,000만~3,300만 회로 세 배 넘게 뛰었다. 읽기 한 번에 소모되는 커널 CPU 사이클도 2,937~2,975에서 725~726으로 4분의 1 토막이 났다.
여기서 진짜 눈여겨볼 대목은 화려한 숫자 바로 옆에 붙은 단서다. 토발즈는 노트북이 열을 받으면 클럭 속도를 스스로 낮추기 때문에 초당 처리량 숫자에 현혹되지 말고 읽기당 CPU 사이클 비용을 보라고 꼬집었다. 게다가 아직 덩치 큰 서버나 CPU 소켓이 여러 개 달린 환경에서는 벤치마크를 돌려 보지 않았다는 사실도 숨김없이 적어 두었다. 인상적인 성능 개선 수치와 그 측정의 한계를 한 문단 안에 나란히 적어 놓은 것이다.
무엇을 맡기고 무엇을 직접 쥐었나
토발즈는 패치 설명문에 자기가 AI를 어디까지 썼는지 한 줄로 깔끔하게 밝혔다.
The code, the test programs, the review behind the list above and the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction. The measurements were run on my machine.
목록만 보면 AI에게 넘긴 일이 결코 적지 않다. 실제 커널 코드 작성부터 테스트 프로그램, 검토 항목 정리, 심지어 패치 설명문 초안까지 Claude Code에게 맡겼다. 하지만 딱 두 가지는 끝까지 자기 손에 쥐고 놓지 않았다. 하나는 “내 지시 아래(under my direction)”라는 설계 방향이고 다른 하나는 “내 컴퓨터에서(on my machine)” 직접 돌린 성능 측정이다. 문제를 어떻게 풀지 결정하는 일과 그 결과가 진짜로 맞는지 검증하는 일만큼은 남에게 넘기지 않았다.
같은 주말에 이를 보여주는 일화가 하나 더 있었다. 한 개발자가 커널의 assoc_array 라이브러리에서 버그를 찾아내 수정 패치를 보내왔는데 원래 코드가 워낙 배배 꼬여 있어서 토발즈조차 눈으로만 따라가기가 버거웠다. 그는 이번에도 LLM을 꺼내 들었다. 거대하고 난해한 함수를 읽기 좋게 잘게 쪼개고 커널 밖의 일반 사용자 공간(user space)에서 따로 테스트를 돌려 볼 수 있게 판을 짰다.
결과는 놀라웠다. 제보받은 버그를 확인하는 데 그치지 않고 숨어 있던 버그 세 개가 줄줄이 더 쏟아져 나온 것이다. 전부 2013년 이 라이브러리가 커널에 처음 들어올 때부터 10년 넘게 박혀 있던 해묵은 버그들이었다. 토발즈는 이 작업을 두고 “내가 평소 떠들던 대로 직접 해 보였다(Did What I Preach)”고 적었다. 여기서 AI는 사람이 할 생각을 대신해 준 게 아니라 사람이 복잡한 코드를 끝까지 이해할 수 있도록 발판을 놓아 준 셈이다.
그럼 컴파일러도 금지할 건가
며칠 뒤 커널 메일링 리스트에서 한 개발자가 “특정 작업에는 AI를 쓰지 말자”는 가이드라인을 제안했다. 프로젝트가 원하는 기여와 원치 않는 기여를 미리 명확히 그어 두자는 취지였다. 그러자 토발즈가 정면으로 반박하고 나섰다. 그런 건 합리적인 기대치가 아니라 그냥 개인적인 알레르기 반응일 뿐이라는 것이다.
그는 이 주장이 얼마나 우스꽝스러운지 보여 주려고 가상의 규칙 두 개를 예로 들었다. 첫째, 하드웨어가 어떻게 돌아가는지 진짜로 안다는 걸 증명하려면 C 컴파일러 따위는 쓰지 말고 어셈블리어를 손으로 직접 짜서 내라. 둘째, 커밋 메시지를 쓸 때 텍스트 편집기나 백스페이스 키를 쓰지 마라. 오타를 지워 주는 도구를 썼다는 게 곧 좋은 글을 쓸 능력이 없다는 뜻이니 말이다.
토발즈가 커널 기여자에게 요구하는 건 예나 지금이나 딱 두 가지뿐이다. 최선을 다할 것, 그리고 자기가 지금 무슨 짓을 하고 있는지 완벽히 이해할 것. 그는 사람이 문제를 이해하고 있는지 여부는 손에 쥔 도구와 아무 상관이 없다고 못 박았다. 살면서 자기가 존경했던 똑똑한 엔지니어들은 하나같이 새롭고 흥미로운 도구를 써 보는 데 거리낌이 없었다는 말도 덧붙였다.
물론 이 비유를 두고 “불확실한 확률 모델인 LLM을 결정론적인 컴파일러와 같은 선상에 놓는 건 무리수”라며 반발한 사람들도 많았다. 하지만 토발즈가 말하고자 한 핵심은 도구의 신뢰성이 아니라 기여자를 평가하는 잣대다. 코드를 어떤 도구로 찍어 냈느냐는 그 코드를 받아 줄지 말지 결정하는 기준이 될 수 없다는 뜻이다.
손에 쥔 도구인가 손을 뗀 자동화인가
이 지점에서 반대편의 날 선 시각도 함께 짚어 볼 만하다. 프로그래밍 언어 Clojure의 창시자인 리치 히키(Rich Hickey)는 10월 12일 『’AI’는 도구가 아니다』라는 짧은 글을 올렸다. 그는 도구를 “손에 쥐고 직접 휘두르는 것”으로 정의한다. 목수가 망치나 끌을 쓸 때는 손끝으로 나무의 저항을 느끼며 매 순간 힘과 각도를 조절한다. 그 끊임없는 감각의 피드백 속에서 사람의 실력이 자란다.
히키가 보기에 LLM은 전혀 다르다. 사람은 프롬프트라는 주문서를 던져 놓고 LLM이 혼자 알아서 결과를 들고 올 때까지 기다릴 뿐이다. 그 과정에 손끝의 감각이나 실시간 조종이 끼어들 자리는 없다. 그래서 그는 LLM을 도구가 아니라 ‘자동화’라고 부른다. 햄버거 드라이브스루가 요리 도구가 아니라 요리를 건너뛰게 해 주는 자동화 시스템인 것과 똑같다는 비유다.
커뮤니티 댓글에서도 현실적인 우려가 쏟아졌다. 사람이 엉성하게 짠 코드는 딱 보면 서툰 티가 나서 리뷰어가 걸러내기 쉽다. 반면 LLM은 속 빈 강정 같은 논리도 그럴듯한 변수명과 깔끔한 포맷으로 포장해 내놓기 때문에 틀린 곳을 찾아내기가 훨씬 피곤하다는 것이다. 게다가 남이 보낸 허술한 패치를 거절할 때의 엄격한 잣대와, 내가 빨리 퇴근하려고 돌린 LLM 결과물을 볼 때의 잣대가 같기 어렵다는 뼈아픈 지적도 나왔다.
사실 히키와 커뮤니티의 이런 우려는 토발즈의 주장과 정면으로 충돌하지 않는다. 오히려 토발즈가 내건 ‘이해하라’는 조건이 왜 그토록 지키기 어려운지를 정확히 설명해 준다. 프롬프트만 던지고 결과물을 복사해 붙여 넣는 식으로는 이해가 저절로 생겨나지 않는다. 토발즈가 직접 노트북에서 벤치마크를 돌리고 한계를 적어 넣은 것, 그리고 남의 난해한 코드를 이해하려고 함수를 쪼개 테스트를 돌려 본 것은 바로 그 빠져 버린 피드백 고리를 자기 손으로 직접 메운 작업이었다.
결국 질문은 하나로 돌아온다
토발즈가 보여 준 태도를 한 줄로 요약하면 간단하다. 도구는 무엇을 쓰든 자유지만 그 결과물을 이해하고 설명할 책임은 온전히 사람에게 남는다는 것이다. 그는 코드 작성과 테스트, 초안 정리를 거리낌 없이 AI에게 넘겼지만 방향을 지시하고 직접 숫자를 재고 아직 확인하지 못한 빈칸을 밝히는 일만큼은 끝까지 직접 챙겼다.
다시 처음의 코드 리뷰 장면으로 돌아가 보자. 리뷰어가 “이거 AI로 짜셨어요?”라고 물었을 때 그 말 밑바닥에 깔린 진짜 질문은 사실 이것이다. “이 코드가 왜 이렇게 돌아가는지, 혹시 문제가 터지면 어디를 고쳐야 하는지 본인이 알고 계신가요?” 이 질문에 막힘없이 답할 수만 있다면 코드를 손가락으로 쳤든 Claude와 대화를 나눠 뽑았든 숨길 이유가 전혀 없다.
반대로 그 질문에 답하지 못한다면 AI를 안 썼다고 해서 면죄부가 주어지지도 않는다. 남의 블로그에서 복사해 왔든 어젯밤에 맨정신으로 직접 짰든 작성자 본인이 이해하지 못하는 코드는 똑같이 위험한 시한폭탄이다. 토발즈가 커널 브랜치 이름에 보란 듯이 with-llm을 적어 넣을 수 있었던 건, 그 코드의 모든 줄을 자기 말로 설명할 자신이 있었기 때문이다.
출처: Phoronix — Linus Torvalds Working On A Hefty Linux Kernel Improvement With Claude Code, Phoronix — Linus Torvalds “Did What I Preach”, LKML — Linus Torvalds, Rich Hickey — ‘AI’ is Not a Tool, GeekNews Weekly #380