발신: TLDR 2026-07-27 | 원문: antirez.com (Redis 창시자 Salvatore Sanfilippo, 9분 분량, YouTube 영상 원고 각색)
전문 번역
리누스 토발즈가 최초의 리눅스 커널을 만들었을 때, 그는 Minix 소스코드를 연구했고, 컴퓨터 아키텍처를 공부했으며, 필요한 기초 지식을 갖추고 있었고, 누가 봐도 매우 뛰어난 프로그래머였다. 하지만 386용 최소한이면서도 동작하는 유닉스 커널을 짜는 그 작업 자체는(당시 리눅스는 단일 아키텍처였다) 다른 많은 프로그래머와 학생들도 손댈 수 있는 영역이었다. 많다고 해봐야, 뭐, 0.1% — 천 명 중 한 명, 만 명 중 한 명 정도겠지만. 물론 대부분의 사람은 이런 일을 해내지 못하지만, 충분히 많은 사람이 할 수 있다. 최근 몇 년간 해커뉴스를 보면 C로 짠 커널 프로젝트, 밑바닥부터 구현한 마이크로커널, Rust로 짠 커널, 온갖 방식으로 만든 커널들, 라즈베리파이용으로 수직 통합한 작은 유닉스 시스템, ESP32용 운영체제 등이 얼마나 많은지 알 수 있다. 커널을 짜는 건 누구나 할 수 있는 일은 아니지만, 충분히 노력을 쏟으면 많은 사람이 완수할 수 있는 일이다. 물론 모두가 잘 해내지는 못할 것이다. 그는 의심할 여지 없이 천재 프로그래머이니, 그가 더 잘 해낸 것이다.
그럼에도 리누스는 단 한 명뿐이다. 사실 그의 이런 구현 능력 자체는 그에 대해 많은 것을 말해주지 않는다. 우리가 주목해야 할 것은 오히려 그 이후에 일어난 일이다.
그는 코드를 그만 짰다
유명 오픈소스 프로젝트의 메인테이너들 중에서, 그는 리눅스 개발 역사 아주 초기에 코드를 직접 짜는 일을 거의 완전히 그만두고 프로젝트를 이끄는 데 집중한 극소수 중 한 명이었다. 리더가 되는 것, 조율자가 되는 것, 프로젝트의 목표가 무엇이어야 하는지에 대한 명확성을 지닌 단 하나의 정신이 되는 것 등. 이것은 드문 일이다. 많은 메인테이너들은(나 자신도 오랫동안 그랬다) 계속 직접 구현하고, 위임하지 않는다.
이는 소프트웨어에 대한 다른 관점에서 출발한다. 리눅스는 필연적으로 어마어마하게 커질 수밖에 없었다. 많은 디바이스, 플랫폼, 서브시스템을 끌어안고, 시대와 새 소프트웨어의 필요, 조금씩 나오는 새 하드웨어에 계속 적응해야 하는 커널이라면 원래 그런 성질을 갖는다. 그러니 이것은 실수가 아니었다. 반대로 Redis는 자기완결적으로 남을 수 있었다. 얼마 전 나는 SQLite의 Richard Hipp 박사로부터 linenoise에 대한 풀 리퀘스트를 받았는데, 그 역시 안정성과 미니멀리즘, 성능을 지향하면서도 코드베이스를 아주 작게 유지했고, 아주 오랫동안 계속 직접 코드를 짰다. 리누스는 달랐다. 그는 자신의 시간을 더 중요한 무언가에, 한 사람의 구현 능력을 훨씬 뛰어넘는 크기로 커질 운명인 프로젝트에 바쳐야 한다는 것을 곧바로 이해했다.
그렇게 그는 프로젝트 리더, 아이디어와 방향을 소유한 사람이 되었다. 그럼 그때부터 리누스는 무엇을 하는가? 그는 매번 모든 패치를 한 줄 한 줄 들여다보지 않는다. 물론 그도 어떤 구현을 깊이 파고들어 무슨 일이 일어나는지 이해하는 경우가 있다. 수년간 그는 새 서브시스템을 짜거나 심지어 다시 짜기도 했다. 예를 들어 오래전 USB 레이어를 그렇게 한 적이 있고, VFS(가상 파일시스템)도 아이노드와 아이노드 캐시 구조를 바꾸며 재구현한 것으로 알고 있으며, 그 밖에도 여러 이유로 그렇게 했다. Git을 만들었을 때처럼, 그는 이따금 계속 프로그래밍을 했다. 하지만 대부분의 경우 그는 패치를 하나하나, 한 줄 한 줄 자세히 들여다보지 않는다. 대신 서브섹션의 메인테이너들과 소통하며, 어떤 기능이나 방향이 가야 할 길인지 아닌지를 이해한다.
그러니까, 브룩스(Brooks)식으로, 즉 『맨먼스 미신(Mythical Man Month)』식으로 말하자면, 리누스는 커널의 설계 개념을 쥐고 있고, 커널 계층구조 아래 있는 모든 사람과 계속 대화하며 커널이 특정 방향으로 나아가도록 한다. 개발이 특정 방향으로 가도록, 구현 관점에서는(이런 개발들이 어떻게 구현되는지, 품질은 어떤지, 코드가 실제로 쓰이는 방식에서의 구현 아이디어는 무엇인지), 그리고 설계 관점에서는(우리가 하고 싶은 것은 무엇이고 하고 싶지 않은 것은 무엇인지, 모듈·스케줄러·하드웨어 지원·Rust 통합 여부 등에 대해 최선의 전략은 무엇인지) 말이다.
이것이 바로 리누스의 진짜 천재성이라고 나는 생각한다. 그는 단지 매우 뛰어난 프로그래머인 것만이 아니다 — 그런 사람은 다른 이들도 있다. 그는 또한 메인테이너이자, 놀라운 설계자이며, 거대한 프로젝트의 아이디어와 구조를 일관되게 다루면서 수많은 다른 사람들과 대화할 수 있는 사람이다. 이것은 누구나 할 수 있는 일이 아니다.
이제 우리가 리누스다
이제 우리가 인공지능과 함께 프로그래밍할 때, 우리는 정확히 그와 같은 존재다. 우리는 리누스 토발즈다 — 항상 그가 가진 재능만큼은 아니더라도, 우리가 모든 코드 줄을 리뷰하지 않는 프로젝트에서 우리가 맡아야 할 역할은 정확히 그 유형의 역할이다. 정확히 그가 맡았던 역할이다.
다만 이 일은 다스리기가 더 단순하다. 병렬로 아주 많은 에이전트를 쓰지 않는 한, 여러 경로에서 도착하는 수많은 패치를 다스리는 것보다는 훨씬 단순하다. 하지만 훨씬 빠르다. 마치 사람 속도로 움직이는 여러 명으로 구성된 팀과 상호작용하는 대신, 그 순간 진행 중인 병렬 브랜치 개수에 따라 한두세 명으로 구성된 팀과 상호작용하는 것과 같다 — 다만 그들은 훨씬 빨라서 즉시 훨씬 빠른 피드백을 준다. 이는 작업 방식을 다소 바꾸지만, 내 생각엔 더 나은 쪽으로다: 컨텍스트 스위칭이 줄고, 상대할 사람이 줄고, 성격이나 태도 같은 것으로 인한 문제도 훨씬 줄어든다.
그러니 이 역할이 중요하다고 생각한다면, 자동 프로그래밍(automatic programming)을 "프롬프트를 넣으면 알아서 짜인다"는 식으로 생각해서는 안 된다. 바이브 코딩은 자동 프로그래밍이 무엇인지, 그리고 대다수 사람들에게 자동 프로그래밍이 앞으로 무엇이 될지에 대한 잘못된 발상이다. 바이브 코딩은 기술적 능력이 없으면서도 자기 도구를 만드는 데 영향력을 갖고 싶어 하는 사람에게는 매우 흥미로운 일이다 — 그러니 환영이다, 이는 그 가능성을 민주화하기 때문이다. 하지만 그것이 전부는 아니다.
자동 프로그래밍은 오히려, 숙련된 기술자·숙련된 프로그래머·숙련된 소프트웨어 아키텍트의 손에서는, 리누스의 역할을 맡는 것이다. 에이전트와 LLM들이 여러 서브시스템의 메인테이너 역할을 맡는 가운데 말이다. 그리고 모두가 이 일을 그렇게 잘 해낼 수 있는 건 아니기 때문에, 자동 프로그래밍 역시 에이전트들과 대화하고, 아이디어를 점검하고, 어떤 구현을 해야 하고 어떤 것은 하지 말아야 하는지 알고, 에이전트들이 최선의 작업을 하도록 소통하는 법을 아는 재능이 필요하다 — 뛰어난 프로그래머가 직관하는, 좋은 프로그래머가 직관하고 미리 계산해내는 그 설계적 힌트들을 거기에 심어 넣으면서 말이다.
그러니까 자동 프로그래밍은, 잘 이뤄질 때 리누스의 역할을 맡는 것을 의미한다. 그리고 이 일은 잘 될 수도 있고, 나쁘게 될 수도 있고, 이해될 수도 있고, 반대로 격하될 수도 있다. 그리고 이것 역시 훈련이 필요한 것이다 — 정확히 리누스가 그것을 배워야 했던 것처럼 말이다. 그는 분명 이 일에 타고난 재능이 있었겠지만, "내가 전부 구현한다"에서 교향곡을 다스리는, 오케스트라 지휘자가 되는 그 능력으로 옮겨간 것이다.
나에게 이것이 리누스가 주는 교훈이며, 이는 "LLM이 있으면 프로그래밍은 누구에게나 쉬워진다"고 말하는 사람들에 대한 반박 논거로 즉시 사용해야 할 교훈이다.
핵심 요약 (20줄)
- 리누스 토발즈가 최초의 리눅스 커널을 짠 것은 뛰어난 재능이었지만, 실은 노력하면 소수(약 0.1%)의 프로그래머가 해낼 수 있는 영역이었다.
- 진짜 주목할 점은 커널을 짠 능력이 아니라 그 이후 리누스가 한 선택이다.
- 리누스는 리눅스 개발 초기에 코드를 직접 짜는 일을 거의 그만두고 프로젝트 리딩에 집중했다.
- 이는 리눅스가 수많은 디바이스·플랫폼을 아우르며 계속 커질 수밖에 없는 성격의 소프트웨어였기 때문이다.
- 반면 Redis(저자 안티레즈 자신의 프로젝트)나 SQLite의 linenoise는 미니멀함을 지향해 창시자가 계속 직접 코드를 짤 수 있었다.
- 리누스는 자신의 시간을 한 사람의 구현 능력을 넘어서는 프로젝트에 바쳐야 한다는 것을 일찍 깨달았다.
- 리더가 된 이후 리누스는 모든 패치를 줄 단위로 검토하지 않고, 서브시스템 메인테이너들과 소통하며 방향을 조율한다.
- 그는 USB 레이어, VFS(가상 파일시스템) 등 필요할 때만 직접 재구현에 참여했다.
- 브룩스의 『맨먼스 미신』식으로 말하면, 리누스는 설계 개념을 쥐고 구현·설계 양쪽 방향을 조율하는 사람이다.
- 저자는 이것이 리누스의 진짜 천재성이라 말한다 — 뛰어난 프로그래머일 뿐 아니라, 거대한 프로젝트를 일관되게 이끄는 메인테이너·설계자라는 점.
- 이제 AI와 프로그래밍하는 우리 모두가 정확히 그 리누스의 역할을 맡고 있다는 것이 이 글의 핵심 주장이다.
- 다만 AI 에이전트를 다스리는 일은 사람 여럿을 다스리는 것보다 단순하지만 훨씬 빠르다 — 성격·태도로 인한 문제도 적다.
- 이 역할이 중요하다고 믿는다면 자동 프로그래밍을 "프롬프트만 넣으면 알아서 짜인다"는 바이브 코딩으로 오해해서는 안 된다.
- 바이브 코딩은 기술적 능력이 없는 사람이 자기 도구에 영향력을 갖게 해주는 민주화 도구로서는 가치 있지만, 자동 프로그래밍의 본질은 아니다.
- 숙련된 엔지니어·아키텍트에게 자동 프로그래밍은 에이전트와 LLM이 여러 서브시스템의 메인테이너 역할을 맡는 가운데 리누스의 역할을 맡는 것이다.
- 이 역할 역시 모두가 잘 해내는 것은 아니며, 에이전트와 대화하고 아이디어를 점검하는 재능과 훈련이 필요하다.
- 뛰어난 프로그래머가 직관적으로 아는 설계 힌트를 에이전트에게 미리 심어주는 능력이 핵심이다.
- 리누스도 타고난 재능은 있었지만 "직접 구현자"에서 "오케스트라 지휘자"로 전환하는 법을 배워야 했다.
- 저자는 이 교훈이 "LLM 덕분에 이제 누구에게나 프로그래밍이 쉬워졌다"는 주장에 대한 직접적 반박 논거가 된다고 말한다.
- 토니의 CLAUDE.md/AGENTS.md 운영 방식 — 직접 코드를 짜기보다 에이전트에게 방향과 설계 힌트를 주고 조율하는 방식 — 과 정확히 맞닿아 있는 글이다.