(이 블로그 글은 제 YouTube 영상(https://www.youtube.com/watch?v=l6lxgYeVZqs)의 전사를 바탕으로 다듬은 것입니다)

리누스 토르발스가 최초의 리눅스 커널을 개발했을 때 그는 Minix 소스를 공부했고, 컴퓨터 아키텍처를 공부했으며, 필요한 기초 지식을 갖추고 있었고, 명백히 매우 뛰어난 프로그래머였다. 하지만 386을 위한 최소한의 작동하는 유닉스 커널을 작성한다는 그 작업 — 초기 리눅스는 말하자면 단일 아키텍처였다 — 은 다른 많은 프로그래머와 학생들도 할 수 있는 범위 안에 있었다. ‘많다’는 것이 어느 정도냐면, 글쎄, 0.1%, 천 명 중 한 명, 만 명 중 한 명 정도랄까. 물론 대부분의 사람들은 이런 일을 해낼 수 없지만, 해낼 수 있는 사람은 꽤 많다. 최근 몇 년간 Hacker News를 보면 알 수 있다. C로 작성된 커널, 처음부터 구현한 마이크로커널, Rust로 작성된 커널, 온갖 방식과 형태로 만들어진 커널, 라즈베리 파이를 위해 수직적으로 만든 작은 유닉스 시스템, ESP32용 운영체제 등 얼마나 많은 커널 프로젝트가 올라오는지. 커널을 작성하는 일이 누구나 할 수 있는 일은 아니지만, 충분히 노력한다면 완성할 수 있는 사람은 많다. 물론 모두가 잘 해내는 건 아니다. 그는 의심의 여지 없이 천재적인 프로그래머였기에 더 잘 해냈다.

그런데도 리누스는 단 한 명뿐이다. 사실 그의 이러한 구현 능력은 그에 대해 많은 것을 알려주지 않는다. 우리가 주목해야 할 것은 그 이후에 일어난 일이다.

그는 코드 작성을 멈췄다

유명한 오픈소스 프로젝트의 메인테이너들 가운데 그는 리눅스 개발 역사상 매우 이른 시점에 거의 완전히 코드 작성을 멈추고 프로젝트를 이끄는 데 집중한 몇 안 되는 사람 중 하나였다. 리더가 되고, 코디네이터가 되고, 프로젝트가 어떤 목표를 가져야 하는지에 대한 명확성을 쥐고 있는 단 하나의 두뇌가 되는 데 집중한 것이다. 그리고 이는 드문 일이다. 많은 메인테이너들(오랫동안 나 자신도 포함해서)은 오히려 직접 구현을 계속하고, 위임을 많이 하지 않으려 한다.

이는 또한 소프트웨어에 대한 다른 생각에서 출발한다. 리눅스는 필연적으로 엄청나게 커져야 했다. 수많은 장치와 플랫폼, 서브시스템을 포용하고, 시대와 새로운 소프트웨어의 요구, 조금씩 등장하는 하드웨어에 끊임없이 적응하려는 커널이라는 본질 자체가 그렇다. 그러니 이는 실수가 아니었다. 반면 Redis는 스스로 완결된 무언가로 남아 있을 수 있었다. 얼마 전 나는 linenoise에 대해 SQLite의 리처드 힙 박사로부터 풀 리퀘스트를 받았다. 그 역시 안정성과 미니멀리즘, 성능을 추구하면서도 코드베이스를 매우 작게 유지했고, 아주 오랫동안 직접 코드를 작성해 왔다. 반면 리누스는 그렇지 않았다. 그는 자신의 시간을 한 사람의 구현 능력에 비해 매우 커질 운명인 프로젝트에 더 중요한 무언가에 바쳐야 한다는 것을 즉시 이해했다.

그렇게 그는 프로젝트의 리더가 되었고, 아이디어와 방향을 소유한 사람이 되었다. 그렇다면 리누스는 무엇을 하는가? 그는 매번 모든 패치를 한 줄 한 줄 들여다보지 않는다. 물론 무슨 일이 일어나고 있는지 이해하기 위해 특정 구현을 깊이 들여다보는 일도 있다. 세월이 흐르면서 그가 어떤 새로운 서브시스템을 작성하거나 심지어 다시 쓴 적도 있다. 내 기억으로는 오래전에 USB 레이어를 한 번 그런 식으로 했고, 가상 파일 시스템도 어느 시점에 아이노드와 아이노드 캐시의 구조를 바꾸며 재구현한 것으로 알고 있으며, 다른 여러 이유들로도 그런 일이 있었다. 가끔 그는 Git을 만들 때처럼 계속 프로그래밍을 하기도 했다. 하지만 대부분 그는 패치를 하나하나 세세하게, 한 줄씩 들여다보지 않는다. 그는 하위 서브시스템의 메인테이너들과 소통하고, 특정 기능이나 특정 방향이 가야 할 길인지 아닌지를 판단한다.

브룩스의 말로, 『맨먼스 미신』의 언어로 말하자면, 리누스는 커널의 설계 개념을 쥐고 있고, 커널 계층 구조 아래에 있는 모든 사람과 계속 대화하면서 커널이 특정 방향으로 나아가도록 한다. 개발이 특정 방향으로 나아가도록 하는 것이다. 구현 관점에서든(어떻게 구현하는지, 품질은 어떤지, 코드가 작성된 방식 자체에 담긴 구현 아이디어는 무엇인지), 설계 관점에서든(우리가 무엇을 하고 싶은지, 무엇을 원치 않는지, 모듈과 스케줄러, 하드웨어 지원, Rust 통합 여부 등에 대한 최선의 전략이 무엇인지) 그렇다. 이런 것들 전부 말이다.

나는 이것이 리누스의 진정한 천재성이라고 생각한다. 그는 단지 매우 뛰어난 프로그래머가 아니다. 그런 사람은 또 있다. 그는 또한 믿을 수 없을 만큼 뛰어난 메인테이너이자 디자이너이며, 거대한 프로젝트의 아이디어와 구조를 일관되게 다루면서 수많은 사람들과 대화할 수 있는 사람이다. 이건 누구나 할 수 있는 일이 아니다.

이제 우리가 리누스다

이제 우리가 인공지능과 함께 프로그래밍할 때, 우리는 정확히 바로 그 존재가 된다. 우리는 리누스 토르발스다. 언제나 그만큼의 재능을 가진 것은 아니지만, 우리가 코드의 모든 줄을 리뷰하지 않는 프로젝트에서 맡아야 할 역할은 정확히 그런 종류의 역할이다. 정확히 그가 맡은 역할이다.

다만 다루기는 더 단순하다. 많은 에이전트를 병렬로 사용하지 않는 한, 여러 경로로 들어오는 수많은 패치를 다루는 것보다 실질적으로 훨씬 단순하다. 하지만 훨씬 더 빠르다. 마치 인간 속도로 일하는 많은 사람으로 구성된 팀과 상호작용하는 대신, 그 순간 우리가 개발 중인 프로젝트의 병렬 브랜치가 몇 개인가에 따라 한 명, 두 명, 세 명으로 구성된 팀과 상호작용하지만, 그들은 훨씬 더 빠르기 때문에 훨씬 더 빠른 피드백을 즉시 주는 것과 같다. 이는 작업 방식을 약간 바꾸지만, 내 생각에는 더 나은 쪽으로 바꾼다. 컨텍스트 스위칭도 적고, 상대해야 할 사람도 적으며, 성격이나 태도 등으로 인한 문제도 훨씬 적다.

그러니 이 역할이 중요하다고 생각한다면, 자동 프로그래밍을 “프롬프트를 넣으면 알아서 써준다”는 것으로 생각해서는 안 된다. 바이브 코딩은 자동 프로그래밍이 무엇인지, 그리고 대다수 사람에게 자동 프로그래밍이 무엇이 될 것인지에 대한 잘못된 생각이다. 바이브 코딩은 기술적 능력이 없는 사람이 그래도 자신의 도구를 만드는 데 영향을 미치고 싶어 할 때 매우 흥미로운 것이다. 그래서 가능성을 민주화한다는 점에서 환영할 일이다. 하지만 그건 본질이 아니다.

반면 전문가, 숙련된 프로그래머, 숙련된 디자이너, 숙련된 소프트웨어 아키텍트의 손에 들어온 자동 프로그래밍은 리누스의 역할을 맡는 것이다. 에이전트와 LLM이 서로 다른 서브시스템의 서로 다른 메인테이너 역할을 맡는 것이다. 그리고 누구나 그것을 그렇게 잘할 수 있는 것은 아니기에, 자동 프로그래밍 역시 에이전트와 대화하고, 아이디어를 검증하며, 어떤 구현을 해야 하고 어떤 구현을 하지 말아야 하는지 알고, 에이전트가 최고의 작업을 하도록 소통하는 방법을 알며, 뛰어난 프로그래머가 직관적으로 알아채고 미리 내다보는 그런 설계 힌트를 불어넣을 수 있는 재능을 필요로 한다.

그러니 자동 프로그래밍을 잘한다는 것은 리누스의 역할을 맡는다는 뜻이다. 그리고 이 일은 잘할 수도, 못할 수도 있으며, 이해될 수도, 혹은 폄하될 수도 있다. 또한 훈련이 필요한, 배워야 하는 것이기도 하다. 리누스 역시 그것을 배워야 했던 것처럼 말이다. 그는 분명 이 일에 타고난 재능이 있었지만, ‘모든 걸 직접 구현한다’에서 교향곡을 다루고 오케스트라를 지휘하는 그 능력으로 넘어갔다.

그것이 나에게 있어 리누스의 교훈이며, LLM과 함께라면 프로그래밍이 누구에게나 쉽다는 말에 대한 반론으로 즉시 사용되어야 할 논거다.