리누스 토발즈도 구글링·AI로 코딩한다: ‘바이브 코딩’의 시대

리눅스와 Git을 만든 리누스 토발즈라면, 밤새 문서 보면서 C 코드만 손으로 짜는 사람을 떠올리기 쉽습니다. 그런데 이 사람이 “파이썬 잘 모르는데, 구글링하다가 이제는 그냥 구글 안티그래비티(LLM 도구)에게 시켰다”고 말했습니다¹².

게다가 그 프로젝트는 취미로 만든 기타 이펙터용 오디오 샘플 시각화기. 디지털 필터 지식도 부족했고, 파이썬도 자신 없었지만, 구글과 AI 도구, 오픈 소스를 적절히 섞어가며 완성했습니다³⁴⁵⁶⁷.

이 글에서는 리누스 토발즈의 이 일화를 통해

‘구글링과 따라하기’로 시작하는 프로그래밍의 진짜 의미,
구글 안티그래비티 같은 AI 도구를 활용하는 구체적인 방식,
아날로그 필터 지식과 디지털·파이썬을 연결한 사고법,
개발자에게 필요한 기술적 다양성과 유연성

을 차근차근 풀어보겠습니다.

리누스 토발즈가 말한 “구글링과 원숭이 따라하기”의 진짜 뜻

리누스 토발즈는 자신의 오디오 이펙트 프로젝트 README에서 파이썬 시각화 도구를 이렇게 설명합니다.

요약하면, “처음에는 늘 하던 대로, 구글 검색해서 ‘원숭이처럼 따라 치는’ 방식으로 코드를 짰다. 그런데 나중에는 아예 그 중간 과정을 생략하고 구글 안티그래비티에게 오디오 샘플 시각화를 맡겼다”는 이야기입니다¹²⁷.

여기서 흥미로운 점은 두 가지입니다.

첫째, 리눅스의 아버지도 처음엔 우리와 똑같이 검색부터 한다는 점입니다. 파이썬 전문가도 아니고, 디지털 오디오 처리에 평생을 바친 DSP 엔지니어도 아닙니다. 그 역시 새로운 언어와 도메인 앞에서는 “검색 – 복붙 – 실행 – 수정” 루틴으로 시작했습니다.

둘째, 그는 이 방식을 부끄러워하지 않습니다. 오히려 “내 프로그래밍은 보통 이렇게 시작한다”고 솔직하게 적어 두었죠. 이건 개발자가 새로운 기술을 배울 때, ‘구글링 + 따라하기’가 얼마나 자연스러운 기본 패턴인지 보여줍니다.

핵심은 “처음부터 다 이해하고 시작하라”가 아니라 “대충 흉내 내면서 시작하되, 점점 내가 이해하는 영역을 넓혀가라”에 가깝습니다.

당신이 지금 검색창에 “파이썬 그래프 그리기”, “오디오 파형 시각화 예제” 같은 걸 치고 있다면, 리누스 토발즈와 같은 출발선을 밟고 있는 셈입니다.

파이썬도 서툰 리누스, 왜 굳이 파이썬을 썼을까?

리누스 토발즈는 커널 개발처럼 중요한 코드에서는 C를 고집하는 사람입니다. 그런데 이번 오디오 이펙트 프로젝트(AudioNoise)에서는 C로 필터 연산을 구현하면서, 시각화는 파이썬으로 해결했습니다³⁴⁷.

이 선택에는 현실적인 이유가 있습니다.

오디오 필터 연산은 대량의 샘플을 빠르게 처리해야 합니다. 지연시간과 성능이 중요하죠. 이런 영역엔 C가 여전히 최적입니다.

반대로, “결과를 그냥 눈으로 보고 싶은” 시각화 파트는 요구사항이 완전히 다릅니다.

성능보다는 개발 속도
최적화보다는 라이브러리 활용
하드웨어 제어보다는 그래프·GUI

이럴 때는 파이썬이 훨씬 편합니다. 이미 수많은 plotting 라이브러리, 오디오 처리 라이브러리, GUI 프레임워크가 있고, 예제도 넘쳐나죠.

문제는 리누스가 파이썬을 잘 모른다는 것. 하지만 그는 여기서 “모르면 안 쓰는” 대신 “모르니까 도구를 더 쓴다”를 선택했습니다.

결국 구조는 이렇게 나뉩니다³[^4]:

핵심 DSP 로직: 자신 있는 C로 직접 구현
결과 시각화: 파이썬 + AI 도구(구글 안티그래비티)로 빠르게 생성

이건 개발자가 여러 언어와 도구를 조합해 문제를 푸는, 아주 좋은 사례입니다. 자기가 잘 아는 언어에 집착하기보다, “어떤 작업에 어떤 도구가 더 적합한가”를 기준으로 선택한 것이죠.

구글 안티그래비티와 ‘바이브 코딩’: 코드를 설명이 아닌 느낌으로 짓는다

리누스가 언급한 ‘구글 안티그래비티(Google Antigravity)’는 구글의 AI 기반 코드 생성 도구로 알려져 있습니다³⁴⁷⁸.

그가 표현한 포인트는 한 줄로 요약됩니다.

“예전엔 구글 검색해서 예제를 보고 따라 쳤는데, 이제는 그 중간에 있는 ‘나’를 빼고, 그냥 AI에게 시켰다.”

이게 바로 요즘 많이 말하는 ‘바이브 코딩(Vibe Coding)’입니다³⁴⁷⁸.

바이브 코딩은 이런 흐름으로 진행됩니다.

“어떤 느낌의 도구를 만들고 싶다”는 의도나 기능을 말로 설명합니다. 예: “이 WAV 파일의 파형을 시간 축으로 그려줘. 줌 인/아웃도 되고, 실시간 재생에 맞춰 움직였으면 좋겠어.”
AI 도구가 그 설명을 바탕으로 파이썬 코드(예: show.py 같은 스크립트)를 생성합니다⁴. 개발자는 세부 라이브러리 이름이나 함수 시그니처를 전부 기억할 필요가 없습니다.
개발자는 생성된 코드를 실행해 보고, 마음에 들지 않는 부분만 다시 고쳐 달라고 요청하거나, 직접 조금씩 수정합니다.

이 방식의 핵심은 “구체적인 코드보다, 내가 만들고 싶은 결과의 모습에 집중”한다는 점입니다. 리누스의 경우도 “오디오 샘플을 시각화하는 도구”라는 목표를 중심에 두고, 구현 세부는 AI에게 떠넘겼습니다¹³⁴⁷.

물론 여기에도 전제가 하나 있습니다. “AI가 내놓은 코드가 말이 되는지, 대략이라도 판별할 수 있는 눈”이 있어야 한다는 것. 리누스는 C, 시스템 프로그래밍, 필터의 기본 원리를 알고 있기 때문에, 파이썬 문법이 완벽하진 않아도 “이건 이상하다” 정도는 잡아낼 수 있습니다⁴⁷⁸.

아날로그 필터를 아는 사람이 디지털 오디오 시각화를 배울 때 생기는 일

리누스는 “디지털 필터보다는 아날로그 필터를 더 잘 안다”고 밝힙니다¹²⁷. 그렇다고 아날로그 회로를 디지털 코드로 바로 옮길 수 있는 건 아닙니다.

아날로그 필터는 커패시터, 저항, 코일 같은 부품과 연속적인 신호를 다룹니다. 반면 디지털 오디오 필터는 일정한 시간 간격으로 샘플링된 숫자 배열을 다루죠.

리누스의 프로젝트(AudioNoise)는 이런 간극을 메우기 위한 일종의 “연습장”입니다. 기타 페달에서 쓰는 이펙트(딜레이, 에코, 필터, 리버브 등)를 디지털로 흉내 내보면서, 아날로그 감각을 디지털 수학과 연결해 보는 실험인 셈입니다³⁴⁷.

여기서 시각화 도구는 학습을 돕는 강력한 보조 도구가 됩니다.

숫자로만 보면 감이 안 오는 필터 효과를 파형으로 눈으로 볼 수 있습니다.
특정 설정에서 생기는 이상한 소리(클리핑, 링잉, 노이즈)를 그래프상에서 직접 확인할 수 있습니다.
“이 파라미터를 이렇게 바꾸면 파형이 이렇게 변한다”는 인과 관계를 직관적으로 이해하게 됩니다.

리누스가 굳이 파이썬 시각화기를 만들어 붙인 이유가 여기에 있습니다. 디지털 필터 이론만 책으로 보는 게 아니라, 직접 만든 C 코드의 결과를 시각적으로 확인하면서 감각을 익히고 싶었던 거죠³⁴.

그리고 파이썬과 시각화 라이브러리를 일일이 익히는 대신, 이 부분은 AI 도구(구글 안티그래비티)를 활용해 “학습 보조 도구”를 빠르게 완성해 버립니다.

결과적으로:

자신이 잘 아는 영역(C·아날로그 감각)을 기반으로
잘 모르는 영역(디지털 필터·파이썬 시각화)을
구글링과 AI, 오픈 소스로 보완해 나간 사례라고 볼 수 있습니다.

리누스 토발즈가 보여준 ‘기술적 다양성’과 개발자의 유연성

리누스 토발즈의 이 에피소드는 단순히 “유명 개발자도 AI 쓴다” 정도의 가십이 아닙니다. 몇 가지 중요한 메시지를 담고 있습니다.

첫째, “전부 손으로 짜야 진짜 개발자”라는 환상은 끝나가고 있다는 점입니다. 리누스 같은 인물조차, 새 언어나 부가적인 도구를 쓸 때는 과감하게 검색과 AI에 의존합니다³⁴⁷⁸. 중요한 건 코드의 출처가 아니라, “문제를 제대로 정의하고, 결과를 검증할 수 있는가”입니다.

둘째, 코어 로직과 주변 도구를 다르게 취급하는 태도입니다. 리눅스 커널 같은 핵심 시스템에는 여전히 수동 코딩, 꼼꼼한 리뷰, 예측 가능한 코드가 필수입니다. 반면, 취미 프로젝트의 시각화 스크립트나 내 로컬에서만 쓰는 유틸리티는 AI 코드 생성 도구를 이용해 빠르게 만들어도 됩니다³⁴⁷⁸.

개발자 입장에서 이건 현실적인 전략입니다.

운영체제, 금융 시스템, 인프라 같은 고위험 영역: 최대한 이해 가능한, 리뷰 가능한, “지루할 정도로” 안전한 코드.
오디오 시각화, 내부 툴, 실험용 프로토타입: 구글링, 복붙, AI 도구를総동원해 속도와 실험성을 우선.

셋째, 도구를 바꿀 줄 아는 사람이 결국 더 멀리 간다는 점입니다. 리누스는 C에 익숙하지만, “이건 파이썬이 더 낫겠다” 싶으면 파이썬을 씁니다. 파이썬이 부족하면 검색과 AI를 덧붙입니다. 아날로그 필터 지식이 디지털에 바로 맞지 않으면, 시각화라는 브리지 도구를 만듭니다.

이게 바로 기술적 다양성입니다. “나는 백엔드 개발자니까 파이썬 안 한다”, “나는 C 개발자니까 AI 안 쓴다”라는 태도에서 벗어나 문제를 중심에 두고, 언어와 도구를 자유롭게 갈아끼우는 능력입니다.

마무리: 우리에게 주는 실질적인 조언

리누스 토발즈의 오디오 샘플 시각화기 이야기를 정리해 보면, 다음과 같은 메시지를 던집니다.

구글링과 따라하기는 부끄러운 게 아니다. 시작점일 뿐이다. 리누스도 그렇게 시작했다가, 나중에는 그 과정 자체를 자동화해 버렸습니다.
핵심은 “무엇을 만들고 싶은지”를 명확히 설명하는 능력이다. 바이브 코딩이든 AI 프롬프트든, 원하는 결과를 구체적으로 말로 풀어낼 수 있어야 합니다.
모든 걸 잘할 필요는 없다. 중요한 부분에 집중하고, 나머지는 도구를 활용하자. 중요한 로직은 직접 짜고, 주변 자동화·시각화·보조 도구는 검색과 AI에게 맡기는 전략이 충분히 유효합니다.
아날로그 지식, 이전 경험도 디지털·AI 시대에 그대로 쓸 수 있다. 리누스는 아날로그 필터 감각을 디지털 실험과 시각화에 연결하며 자기만의 학습 루프를 만들었습니다.
AI는 ‘치트키’가 아니라, 잘 쓰면 강력한 동료다. 맹신하면 위험하지만, 적절히 활용하면 모르는 언어와 도메인을 탐험할 수 있는 좋은 가속기입니다.

지금 “파이썬을 하나도 모르는데, 이거 써도 되나?” “AI로 짠 코드, 쓰면 양심에 찔리나?” 같은 고민을 하고 있다면, 이렇게 생각해 볼 수 있습니다.