리누스 토르발스, AI를 활용한 커널 기여를 말하다

AI 요약

리누스 토르발스는 커널 문서에서 패치에 붙이는 "Assisted-by" 표기를 없애자는 논의에 답하며, AI 사용을 별도 규칙으로 금지하는 데 반대합니다. 기여자가 코드를 이해하는지 확인하려고 어셈블리만 쓰게 하고 컴파일러를 금지하자는 것과, 커밋 메시지를 쓸 때 편집기를 쓰지 못하게 하자는 주장을 예로 들었습니다. 그런 규칙은 도구를 썼다는 사실만으로 역량을 판단하는 어리석은 기준이라는 설명입니다.

토르발스가 제시한 기준은 기여자가 최선을 다하고 자신의 작업을 이해해야 한다는 것입니다. 어떤 도구를 썼는지는 이해 여부와 별개라고 봅니다. 그는 자신이 지적으로 높이 평가하는 사람들은 새롭고 흥미로운 도구를 피하지 않는다고 덧붙였습니다.

Lobsters 반응

• @elobommart — 컴파일러를 예로 든 주장은 어색합니다. 결정론적인 알고리즘과 확률적 과정을 비교하고 있습니다. AI도 도구라는 말은 오래전에 반박되지 않았나요?
  • @stip — 이 주제에 대한 제 생각은 계속 바뀌고 있으니 LLM을 옹호하는 함정 질문으로 읽지는 말아 주세요. 다만 컴파일러가 생각만큼 결정론적이지는 않다고 말하고 싶었습니다. 대형 프로젝트에서 재현 가능한 빌드를 설정하는 작업을 조금 해봤는데, 실제 배포용 컴파일러는 기본 설정에서 대체로 결정론적입니다.
  • @gunduzc — 그건 도움이 되는 비유가 아닙니다. 도박은 운에 달렸다고 말하자, 사업을 만들거나 교육에 투자하는 일도 그다지 "결정론적"이지 않다고 답하는 것과 같습니다. 좋은 컴파일러는 예측하기 어려울 수 있어도 결정론적입니다. 예측하기 어렵다는 말은 비결정론적이거나 확률적이라는 뜻이 아닙니다. 해시 함수가 좋은 예입니다. LLM이 결정론적이면 괜찮겠냐고요? 저는 불평을 덜 할 겁니다. 최소한 같은 입력에 같은 출력을 내면 재현성은 조금 더 나아지니까요. 제 기준에서 신뢰할 수 있는 도구란 같은 입력에 매번 같은 출력을 내는 도구입니다.
  • @gspr — LLM이 컴파일러와 같다고 가정해도, 그렇다면 이제 소스 코드는 무엇인가요? 자연어 문장인가요? 사람이 쓰는 자연어보다 더 나쁜 프로그래밍 언어가 있을까요? 그 문장을 Git에 저장하고 공개하고 빌드 시스템에 넣어야 한다는 뜻인가요? 더구나 "컴파일러"는 대부분 독점적이고 원격 API 뒤에 숨어 있습니다.
  • @thisalex — 실제로 좋은 결과를 내는 방식은 자연어 문장으로 끝나는 게 아닙니다. 긴 대화형 에이전트 세션을 거치는 경우가 많습니다. 이런 상호작용을 미리 정의한 복잡한 규칙으로 대체하려는 방식도 있습니다. 그 경우에는 규칙의 조합이 소스 코드입니다.
• @joshuao — 이 주장은 두 가지로 나뉜다고 봅니다. 첫째는 LLM이 더 고차원적인 컴파일러이고 GCC도 실제로는 완전히 결정론적이지 않다는 주장입니다. 둘째는 LLM과 컴파일러 모두 코드를 더 빨리 쓰게 돕는 도구이며, 결정론 여부는 특성 중 하나일 뿐 도구 사용의 근본 기준은 아니라는 주장입니다. 첫 번째는 틀렸다고 생각합니다. 토르발스는 도구의 특성에 맞춰 쓰는 두 번째 주장을 한 것 같습니다. 그쪽이 더 설득력 있습니다.
• @fgaz — 결정론 여부는 바람직한 성질이긴 하지만 논점을 흐립니다. 진짜 문제는 LLM에 의미론이 없다는 점입니다.
• @yshui — 토르발스가 정신을 놓았나 봅니다. 바이브 코딩을 컴파일러와 편집기 사용에 비교한 건가요?
  • @creesch — 저는 그렇게 읽지 않았습니다. 토르발스는 작업을 이해하고 있음을 보여야 한다고 분명히 말합니다. KDE의 LLM 사용 원칙에도 "게으르게 굴지 말 것"이라는 항목이 있습니다. 도구로 판단이나 소통, 학습 과정을 대신하지 말고 지속 불가능한 지름길을 택하지 말라는 뜻입니다. 토르발스는 수십 년간 다양한 기여를 검토해 왔으니 LLM 결과나 사람의 작업을 비판적으로 검토할 능력이 있는 사람이라고 생각합니다.
  • @marginalia — 토르발스가 LLM 피로에 다른 사람보다 더 잘 버틸지는 모르겠습니다. 그건 기술이라기보다 인간의 처리 용량 한계에 달린 문제입니다.
• @pralkarz — 토르발스도 많은 사람처럼 LLM의 효율이 사용 여부를 결정하는 유일한 기준이라는 이야기의 영향을 받은 것 같습니다. 윤리, 환경, 사회에 미치는 영향은 고려하지 않았습니다.
• @ianloic — 저는 대학 시절 vi만 고집했습니다. Emacs의 자동 들여쓰기와 Vim의 구문 강조가 방해된다고 생각했고 코드를 제대로 이해하면 그런 기능이 필요 없다고 여겼습니다. 제가 틀렸습니다. 더 나은 소프트웨어를 효율적으로 만들게 해주는 도구를 받아들여서 다행입니다.
  • @elliotmorris — Vim이나 Emacs가 사회적, 정치적 쇠퇴나 부의 집중을 초래하고 경제를 무너뜨릴 거라는 우려를 낳지는 않았습니다. LLM을 두고는 사람들이 서로 다른 쟁점을 말하는 경우가 많습니다. 저도 사회적 결과가 받아들이기 어려울 만큼 심각하다고 생각하면서 과거에 AI의 효용을 인위적으로 부풀린 적이 있습니다.
  • @gspr — 구문 강조와 자동 들여쓰기가 코딩 에이전트와 무슨 관계인지 모르겠습니다. 둘 다 소스 코드를 다루는 프로그램이라는 공통점만으로는 유용한 비유가 되지 않습니다.
• @colefox — 도구를 너무 믿는 사람을 부르는 말이 필요합니다. 직장에서 "Claude가 그렇다고 했다"는 사람들과 계속 부딪혀서 잠을 설칠 정도입니다. 누군가 자신만만하게 30만 줄이 넘는 diff를 내놓으면 AI로 보안 문제를 확인했다고 합니다. 그런데 근본 설계의 결함을 지적한 뒤에도 10만 줄을 더 추가했다고 하고, 결국 그 사람이 자기 코드보다 더 오래 코드를 이해하려고 시간을 써야 합니다.
• @rtfeldman — Lobsters 첫 화면에는 AI에 대한 개인적인 감정만 담은 글이 거의 항상 하나씩 올라옵니다. 이런 글은 사이트가 권하는 좋은 글의 기준, 즉 독자의 다음 프로그램을 개선하는지, 지난 프로그램에 대한 이해를 깊게 하는지, 5년이나 10년 뒤에도 흥미로운지에 맞지 않는다고 봅니다. 그래도 많은 추천을 받습니다.
  • @thang — 어느 정도 동의하지만, 이번 글은 리누스 토르발스가 커널 개발에서 AI를 쓰는 문제에 의견을 낸 것입니다. 그의 영향력을 고려하면 일반적인 개인 감상과는 무게가 다릅니다.

원문: Linux Kernel Mailing List / 번역·요약: Trawling