기타 페달 화면 만들 땐 웃었지만 커널에선 한숨: 리누스 토발즈가 밝힌 인공지능 코딩의 빛과 그림자

오픈소스 진영에서는 최근 인공지능이 만든 코드를 둘러싸고 날 선 공방이 이어지고 있다. 대표적으로 시스템76(System76)은 자체 리서치팀톱 환경인 코스믹(COSMIC)에 인공지능으로 만든 결과물을 일체 들이지 않겠다고 선언했다. 기계가 대충 뽑아낸 설익은 코드가 오픈소스 생태계를 망친다는 반발 때문이다.

그런데 체코 프라하에서 열린 유럽 오픈소스 서밋 무대에 오른 리눅스 창시자 리누스 토발즈(Linus Torvalds)는 정반대의 말을 꺼냈다. 그는 “요즘은 인공지능을 쓰는 일이 정말 즐겁다”고 털어놓았다. 까다롭기로 유명한 그가 인공지능 도구를 칭찬하자 전 세계 개발자들의 시선이 쏠렸다.

하지만 토발즈의 찬사에는 아주 단단한 전제 조건이 붙어 있었다. 취미로 만드는 작은 프로젝트에서 재미를 붙이는 일과, 수억 대의 서버와 스마트폰을 움직이는 리눅스 커널처럼 엄격한 환경에 인공지능 코드를 들이붓는 일은 완전히 다른 문제라는 지적이다. 진짜 중요한 실무 현장에서는 기계가 만든 코드를 맹신하지 말고 극도로 조심해야 한다는 경고다.

토발즈는 자신이 처음 컴퓨터를 만졌던 1981년 이야기를 꺼냈다. 그 시절에는 컴퓨터 구조가 단순해서 코드가 어떻게 돌아가는지 한눈에 파악할 수 있었다. 하지만 오늘날 소프트웨어는 거대한 빌딩처럼 복잡해졌다. 초보 개발자가 혼자 힘으로 뭔가를 만들면 전문가들이 내놓은 매끄러운 프로그램에 비해 너무 초라해 보여 쉽게 지치기 마련이다.

토발즈는 이런 초보자들에게 인공지능이 훌륭한 디딤돌이 될 수 있다고 봤다. 최근 유행하는 ‘바이브 코딩(분위기나 말로 지시해 프로그램을 짜는 방식)‘을 두고 장난감 놀이라고 비웃는 이들도 있지만, 토발즈는 코딩의 재미를 되살려주는 훌륭한 계기라고 평가했다.

그는 최근 자신이 진행한 작은 개인 프로젝트를 예로 들었다. 작은 액정이 달린 마이크로컨트롤러로 악기용 기타 페달을 만드는 작업이었다. 핵심 동작은 익숙한 C 언어로 직접 짰지만, 화면에 표시되는 사용자 환경이 문제였다. 1980년대 구형 기계 화면처럼 촌스러웠던 것이다.

평생 운영체제 커널만 다뤄온 그에게 요즘 스타일의 화면 그래픽을 손수 만드는 일은 낯설고 번거로운 영역이었다. 유튜브 영상에서 본 것처럼 처음에는 말 한마디로 화면 전체를 만들어달라고 프롬프트를 쳐봤지만 엉망진창인 코드가 나왔다.

하지만 접근법을 바꾸자 결과가 달라졌다. 토발즈가 C 언어로 작성한 핵심 동작 방식을 인공지능에게 먼저 보여주며 “동작 논리는 이미 제대로 짜두었으니, 화면만 최신 형태로 다듬어달라”고 지시하자 순식간에 깔끔한 코드가 완성됐다. 자신이 가장 잘하는 핵심 뼈대는 직접 쥐고, 손에 익지 않은 겉껍질 작업을 맡길 때 인공지능은 비로소 든든한 조수가 되었다.

75%의 시간과 19만 건의 검토: 숫자로 드러난 인공지능의 진짜 비용

개인 창작에서는 훌륭한 조수였던 인공지능이 리눅스 커널 같은 초대형 프로젝트로 넘어오면 이야기가 완전히 달라진다. 코드 생성 도구인 Cursor 같은 최신 에디터가 쏟아져 나오면서 누구나 손쉽게 패치(수정 코드)를 만들어 올릴 수 있게 되었지만, 이를 검토하는 관리자들의 일상은 지옥으로 변했다.

실제로 이번 행사 전날 열린 리눅스 커널 관리자 정상회의(Maintainer Summit)에서는 전체 논의 시간의 무려 75%를 ‘인공지능 검토 작업의 스트레스를 어떻게 줄일 것인가’에 쏟아부었다. 코드가 부족해서 개발이 늦어지는 것이 아니라, 기계가 쏟아낸 코드를 사람이 일일이 읽고 검증하느라 작업이 마비되고 있기 때문이다.

물론 인공지능이 무조건 골칫거리인 것만은 아니다. 구글 엔지니어들이 주도해 리눅스 재단에 기증한 오픈소스 자율 검토 시스템 ‘사시코(Sashiko)‘가 대표적인 반례다. 사시코는 패치가 등록되는 메일링 리스트를 실시간으로 지켜보며 보안 취약점이나 코드 결함을 짚어내는 에이전트 시스템이다.

사시코는 단순히 텍스트만 읽고 답하는 수준을 넘어선다. 코드 저장소의 지난 기록을 1,900만 번 이상 스스로 뒤져보며 수정한 코드가 다른 시스템을 망가뜨리지 않는지 파고든다. 그 결과 올해 리눅스 커널에서 공식 등록된 보안 취약점(CVE) 중 463건이 사시코의 검토를 거쳐 바로잡혔다. 인간 관리자의 눈을 피해 수년간 방치되었던 낡은 장치 드라이버의 결함도 여럿 찾아냈다.

표에서 드러나듯 인공지능은 뚜렷한 장점과 치명적인 약점을 동시에 안고 있다. 사람이 놓치기 쉬운 옛날 코드의 구멍을 샅샅이 뒤져내는 데는 탁월하지만, 앞뒤 맥락을 깊이 이해하지 못해 겉핥기식 수정안을 남발한다. 결국 진짜 실력자가 달라붙어 기계가 한 말이 맞는지 검증해야 하므로 일손이 두 배로 들어가는 역설이 발생한다.

기업 개발 현장의 3대 위험: 비용, 일정, 품질에 미치는 직격탄

리눅스 커널이 겪고 있는 진통은 오픈소스 진영만의 이야기가 아니다. 사내 개발팀에 인공지능 코딩 도구를 전면 도입하려는 모든 기업이 내일 당장 마주칠 현실이다.

시니어 엔지니어의 시간 낭비와 보이지 않는 운영 비용 폭증

기업에서 가장 몸값이 비싼 인력은 복잡한 설계를 이해하고 최종 승인을 내리는 수석 엔지니어들이다. 주니어 개발자가 인공지능을 써서 코드를 빠르게 뽑아 올리면 겉보기에는 생산성이 오른 것처럼 보인다.

하지만 그 코드가 시스템 전반에 어떤 나비효과를 불러올지 검증하는 몫은 고스란히 시니어의 어깨에 얹힌다. 토발즈가 뭄바이 강연에서 꼬집었듯, 인공지능이 그럴듯하게 지어낸 버그 리포트를 받아 들면 그것이 왜 틀렸는지 반박하는 데만 몇 시간씩 써야 한다. 개발 속도를 높이려다 가장 귀한 인력의 시간을 낭비하는 셈이다.

땜질식 패치가 쌓여 발생하는 납기 지연

토발즈는 일부 인공지능 코드를 가리켜 “생각 없이 붙여놓은 반창고(mindless band-aid)“라고 일갈했다. 시스템 밑바닥에서 왜 메모리가 새는지, 왜 통신 충돌이 일어나는지 근본 원인을 파악하지 않고 에러 메시지만 안 뜨게 덮어버리는 코드가 많다는 뜻이다.

이런 반창고식 코드가 사내 프로그램에 하나둘 섞여 들어가면 당장은 돌아가는 것처럼 보여도 나중에 대규모 장애로 이어진다. 문제를 수습하느라 전체 일정이 한두 달씩 뒤로 밀리는 사태가 일어난다.

코드 품질의 겉핥기화와 장기 유지보수 붕괴

소프트웨어는 한번 만들고 끝나는 조각상이 아니다. 끊임없이 고치고 덧붙여야 하는 살아있는 기계다. 인공지능이 만든 코드는 문법적으로는 완벽해 보여도, 코드를 짠 당사자조차 내부 논리를 깊이 설명하지 못하는 경우가 잦다.

시간이 흘러 해당 기능을 뜯어고쳐야 할 때 아무도 손을 대지 못하는 이른바 ‘블랙박스 코드’가 늘어난다. 리눅스 커널의 핵심 관리자들이 인공지능 패치에 극도로 까다로운 잣대를 들이대는 이유도 바로 5년, 10년 뒤의 유지보수성을 지키기 위해서다.

35년 리눅스 역사가 보여주는 해결책: 도구가 아니라 규칙을 세워라

올해로 35주년을 맞은 리눅스는 과거에도 비슷한 성장통을 겪었다. 프로젝트 초창기인 1990년대에는 인프라라고 부를 만한 시스템이 아예 없었다. 토발즈는 압축 파일(tarball) 형태로 수정 내역을 매일 모아 일주일에 한 번씩 사람들에게 배포했다.

하지만 전 세계에서 개발자가 몰려들면서 손으로 패치를 하나하나 합치는 방식은 한계에 부딪혔다. 토발즈 개인이 전체 개발 속도를 가로막는 거대한 병목이 된 것이다. 이 문제를 해결하기 위해 도입한 것이 비트키퍼(BitKeeper)였고, 훗날 직접 만들어낸 분산 버전 관리 시스템이 바로 오늘날 전 세계 표준이 된 깃(Git)이다.

리눅스 커널이 찾아낸 해법은 명확하다. 인공지능을 무작정 막아서지도 않고, 그렇다고 맹목적으로 믿지도 않는다. 사시코처럼 철저하게 규칙이 짜인 에이전트를 앞단에 세워 기본적인 문법 오류나 뻔한 보안 결함을 먼저 걸러낸다. 실제로 일부 하위 서브시스템 관리자들은 사시코의 검토를 먼저 통과하지 않은 패치는 아예 검토 목록에 올리지 않기 시작했다.

동시에 사람이 확인해야 할 선을 분명하게 그었다. 인공지능이 지적한 문제라도 관리자가 직접 납득할 수 있는 증거가 없으면 메일링 리스트에서 가차 없이 쳐낸다. 도구의 성능이 아무리 좋아져도 최종 책임을 지는 인간 관리자의 눈을 거치지 않고는 단 한 줄의 코드도 커널 본체에 들어갈 수 없도록 방어벽을 세운 것이다.

인공지능 코딩 도구 도입을 가르는 3가지 실무 판정 기준

리누스 토발즈의 경험담과 리눅스 커널의 진통은 기업들이 인공지능 개발 도구를 어떻게 받아들여야 할지 명확한 나침반을 제공한다. 무작정 최신 도구를 전사에 깔아주기 전에, 우리 조직이 도구를 다룰 준비가 되어 있는지 냉정하게 따져보아야 한다.

지금 즉시 도입해야 할 조직: Fit 조건 3가지

• 기존 코드의 아키텍처를 꿰뚫고 있는 베테랑이 중심을 잡고 있는가: 토발즈가 C 언어 로직을 쥔 상태에서 UI 변환을 맡겼듯, 기계가 짠 코드가 올바른지 단숨에 판별할 수 있는 시니어 개발자가 직접 도구를 쓸 때 생산성이 가장 크게 오른다.
• 방대한 레거시 코드나 오래된 문서를 훑어보는 작업이 많은가: 수십 년간 쌓인 옛날 시스템에서 보안 결함을 찾거나 테스트 케이스를 촘촘하게 메워야 하는 작업에는 인공지능 자동화가 큰 힘을 발휘한다.
• 실수를 걸러내는 엄격한 자동 테스트 파이프라인을 갖추었는가: 코드가 생성되자마자 결함을 잡아내는 단위 테스트와 시스템 모니터링 체계가 갖춰져 있다면 인공지능의 헛소리를 실시간으로 차단할 수 있다.

도입을 보류하고 지켜봐야 할 조직: Non-Fit 리스크 3가지

• 코드 리뷰 체계가 없거나 시니어 개발자가 부족한가: 주니어가 인공지능으로 만든 코드를 검증할 사람이 없다면, 그 코드는 고스란히 서비스 장애를 일으키는 시한폭탄이 된다.
• 작은 장애도 법적 분쟁이나 금융 사고로 이어지는 핵심 코어를 다루는가: 금융 거래 원장이나 의료 장비 제어처럼 작은 오류도 치명적인 영역에서는 인공지능이 내놓은 땜질식 패치를 일일이 검증하는 비용이 손수 코딩하는 비용보다 훨씬 커진다.
• 생성된 코드의 양을 개발자의 생산성 지표로 평가하고 있는가: 하루에 몇 줄의 코드를 작성했는지를 따지는 조직에 인공지능을 던져주면, 검토자들을 과로사로 몰고 가는 반창고식 코드만 넘쳐나게 된다.

토발즈는 “인공지능을 도구로 대할 때 비로소 코딩이 즐거워진다”고 말했다. 중요한 것은 화려한 프롬프트 기술이 아니라, 시스템의 진짜 주인이 누구인지 잊지 않는 태도다. 핵심 뼈대는 사람이 직접 깎고, 서툴거나 번거로운 작업에만 조수를 부리는 절제가 갖춰질 때 인공지능은 비로소 진정한 무기가 된다.