Linus Torvalds가 된다는 것 - <antirez>

antirez 84일 전. 조회수 83695회. (이 블로그 글은 제 YouTube 영상의 전사본을 바탕으로 각색되었습니다: https://www.youtube.com/watch?v=l6lxgYeVZqs))

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

그럼에도 Linus는 오직 한 명뿐이다. 사실 그의 이런 구현 능력만으로는 그에 대해 많은 것을 알 수 없다. 우리가 집중해야 할 것은 그 뒤에 일어난 일이다.

그는 코드 작성을 멈췄다

유명한 오픈 소스 프로젝트의 유지보수자들 가운데 그는 Linux 개발 역사 초기에 프로젝트를 이끄는 일에 집중하기 위해 코드 작성을 거의 완전히 멈춘 몇 안 되는 사람 중 한 명이었다. 리더가 되고, 조정자가 되고, 프로젝트의 목표가 무엇이어야 하는지에 대한 명확성을 지닌 단 하나의 정신이 되는 일에 집중한 것이다. 그리고 이는 드문 일이다. 많은 유지보수자들(나 자신도 오랫동안 그랬다)은 대신 계속해서 직접 기능을 구현하고, 많이 위임하지 않으며, 그렇게 한다.

이는 소프트웨어에 대한 다른 관점에서도 시작된다. Linux는 필연적으로 헤아릴 수 없을 만큼 성장해야 했다. 많은 장치, 플랫폼, 하위시스템을 포괄하고, 시대의 변화와 새 소프트웨어의 요구, 조금씩 등장하는 하드웨어에 계속 적응하려는 커널의 본질에 그러한 성장이 포함되어 있기 때문이다. 따라서 이것은 실수가 아니었다. 반대로 Redis는 자체 완결적인 무언가로 남을 수 있었다. 며칠 전 SQLite의 Dr. Richard Hipp에게서 linenoise에 대한 풀 리퀘스트를 받았다. 그 역시 안정성, 미니멀리즘, 성능을 추구했지만, 언제나 코드베이스를 아주 작게 유지했고 오랫동안 계속 코드를 작성했다. 하지만 Linus는 달랐다. 한 사람의 구현 역량에 비해 매우 커질 운명의 프로젝트를 위해, 자신이 더 중요한 무언가에 시간을 바쳐야 한다는 사실을 즉시 이해했다.

그리하여 그는 아이디어와 방향성을 소유한 프로젝트 리더가 되었다. 그렇다면 Linus는 무엇을 하는가? 그는 매번 모든 패치를 줄마다 살펴보지는 않는다. 물론 무슨 일이 벌어지고 있는지 이해하기 위해 하나의 구현을 깊이 들여다보는 일도 있다. 세월이 흐르는 동안 그가 새로운 하위시스템을 작성하거나, 심지어 하나를 다시 작성한 적도 있다. 아주 오래전에 USB 계층에서 한 번 그렇게 했던 것으로 생각하며, 가상 파일 시스템도 어느 시점에 아이노드와 아이노드 캐시의 구조를 바꾸며 재구현했던 것으로 믿는다. 그 밖에도 여러 이유로 그렇게 했다. 때때로 그는 Git을 만들었을 때처럼 계속 프로그래밍을 했다. 하지만 대부분의 경우 그는 개별 패치를 세부적으로, 한 줄 한 줄 살펴보지 않는다. 하위 섹션의 유지보수자들과 소통하며, 어떤 기능이나 방향이 택해야 할 길인지 아닌지를 파악한다.

그러므로 Brooks의 표현으로, Mythical Man Month의 표현으로 말하자면, Linus는 커널의 설계 개념을 붙들고 있으며, 커널이 특정 방향으로 나아가도록 커널 위계 아래의 모든 사람과 계속 대화한다. 개발이 특정 방향으로 나아가도록 하는 것이다. 구현 관점에서—이러한 개발이 어떻게 구현되는지, 품질은 어떤지, 코드가 작성되는 방식 자체에 담긴 구현 아이디어는 무엇인지—뿐 아니라 설계 관점에서도 그렇다. 우리가 하려는 것은 무엇인지, 원하지 않는 것은 무엇인지, 모듈과 스케줄러, 하드웨어 지원, Rust 통합 여부를 위한 최선의 전략은 무엇인지. 바로 이런 모든 것들이다.

이제 나는 이것이 Linus의 진정한 천재성이었다고 믿는다. 그는 단지 매우 뛰어난 프로그래머가 아니다. 그런 사람은 또 있다. 그는 또한 유지보수자이자 놀라운 설계자이며, 많은 다른 사람과 대화하면서 거대한 프로젝트의 아이디어와 구조를 일관된 방식으로 다룰 수 있는 사람이다. 이것은 아무나 할 수 있는 일이 아니다.

이제 우리는 Linus다

이제 우리가 인공지능과 함께 프로그래밍할 때, 우리는 정확히 바로 그와 같은 존재가 된다. 항상 그가 지닌 재능을 갖춘 것은 아니지만, 코드의 모든 줄을 검토하지 않는 프로젝트에서 우리가 맡아야 할 역할은 정확히 그런 종류의 역할이다. 정확히 그가 맡은 역할이다.

다만 이것은 통제하기 더 쉽다. 병렬로 아주 많은 에이전트를 사용하지 않는 한, 여러 경로에서 도착하는 수많은 패치보다 실질적으로 다루기 쉽다. 하지만 훨씬 빠르다. 인간의 속도로 움직이는 많은 사람으로 구성된 팀과 상호작용하는 대신, 그 순간 우리가 개발 중인 프로젝트의 병렬 가지가 몇 개인지에 따라 한 명, 두 명, 세 명으로 구성된 팀과 상호작용하는 것과 같다. 다만 그들은 훨씬 빠르므로, 즉시 훨씬 빠른 피드백을 준다. 이것은 작업 방식을 조금 바꾸지만, 내 생각에는 더 나은 방향이다. 더 쉽고, 문맥 전환이 적으며, 상대해야 할 사람이 적고, 성격이나 태도 등에서 비롯되는 문제도 훨씬 적다.

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

반면 숙련된 기술자, 숙련된 프로그래머, 숙련된 설계자, 숙련된 소프트웨어 아키텍트의 손에서 자동 프로그래밍이란 Linus의 역할을 맡는 것이며, 에이전트와 LLM은 서로 다른 하위시스템의 서로 다른 유지보수자 역할을 맡는다. 그리고 모두가 이를 그렇게 잘할 수 있는 것은 아니므로, 자동 프로그래밍에도 에이전트와 대화하고, 아이디어를 검증하며, 해야 할 구현과 하지 말아야 할 구현이 무엇인지 알고, 에이전트가 최선의 작업을 하도록 소통하는 방식을 아는 재능이 필요하다. 훌륭한 프로그래머가 직감하고, 좋은 프로그래머가 직감하여 미리 계산해낼 수 있는 그런 설계의 단서를 그 안에 넣어야 한다.

따라서 자동 프로그래밍을 잘한다는 것은 Linus의 역할을 맡는다는 뜻이다. 그리고 이것은 잘할 수도, 못할 수도, 제대로 이해할 수도, 아니면 저급하게 만들 수도 있다. 또한 Linus가 배워야 했던 것처럼 훈련과 학습이 필요한 일이기도 하다. 그는 분명 이것에 대한 타고난 재능이 있었겠지만, “내가 모든 것을 구현한다”에서 교향곡을 다루고 오케스트라를 지휘하는 능력으로 나아갔다.

나에게 그것이 Linus의 교훈이며, LLM과 함께라면 프로그래밍은 누구에게나 쉽다고 말하는 사람들에 맞서는 논거로 즉시 사용해야 할 교훈이다.