Joon's Field Notes — AI, knowledge, and systems

요약

리누스 토르발스가 더크 혼델과 나눈 대담에서 AI를 두고 한 말은 의외로 담담했다. "AI는 컴파일러 같은 도구일 뿐이다." 기계어를 직접 쓰던 시대에 어셈블러와 컴파일러가 생산성을 끌어올렸듯, AI도 개발자를 10배 빠르게 해주는 또 하나의 도구라는 것이다. 실제로 최근 6개월 리눅스 커널 커밋이 약 20% 늘었는데, 원인은 메이저 버전이 아니라 AI가 진입 장벽을 낮춘 것 이었다.

그런데 그가 정작 길게 이야기한 건 생성이 아니라 그다음 이었다. AI가 자동 생성한 무책임한 버그 리포트 홍수에 소규모 메인테이너들이 번아웃되고, 보안 메일링 리스트가 마비됐다. 그리고 커리어 조언은 분명했다. 쓰고 버릴 프로젝트(vibe coding)는 AI로 괜찮지만, 35년 가는 진지한 프로젝트를 유지하려면 AI가 만든 결과물을 (어셈블리 레이어까지) 완벽히 이해해야 한다.

생성은 싸졌다. 유지보수는 여전히 인간의 몫이다. 이걸 에이전트 시대로 옮기면 한 줄이 된다. 좋은 Agent보다 좋은 Repository가 중요하다. 다만 함정이 하나 있다. 대부분의 회사는 아직 35년 프로젝트가 아니라 내년 생존 을 다투는 단계라서, 유지보수에 먼저 투자하는 게 과투자처럼 보인다. 이 글은 그 기로를, 개인 자본을 배분하듯 푸는 시도다.

1. 리누스는 AI를 "도구"라고 불렀다

리누스는 "모든 코드가 AI로 작성될 것"이라는 비관에 동의하지 않는다. 그의 계보는 분명하다. 숫자(기계어)를 직접 쓰던 시대 → 어셈블러 → 컴파일러 → 그리고 AI. 매번 추상화 한 겹이 올라가며 생산성이 뛰었고, AI도 그 연장선의 도구 일 뿐이라는 것이다. 커널 커밋 20% 급증이 그 증거다. 생성의 진입 장벽이 낮아졌다.

흥미로운 건 그의 취향이다. 그는 시각적 UI 툴보다 코드를 직접 쓰는 쪽을 선호한다(3D 모델링도 OpenSCAD처럼 코드로 한다). 최근엔 하드웨어 설계와 소스코드를 모두 공개한 기타 이펙트 페달 프로젝트를 오픈소스로 올렸다. 결과물이 어떻게 만들어지는지를 직접 손에 쥐는 감각을 그는 놓지 않는다. 이 취향이 뒤에 나올 조언의 복선이다.

2. 그가 진짜 걱정한 건 생성이 아니라 그다음이었다

대담의 무게중심은 생성이 아니라 유지보수의 사회적 비용에 있었다.

메인테이너 번아웃. 1~3명이 떠받치는 수많은 소규모 프로젝트가, AI로 자동 생성된 무책임한 버그 리포트 홍수에 시달리고 있다. 생성 비용이 0에 가까워지자, 비용이 사라진 게 아니라 검토·유지보수 쪽으로 통째 이동 했다.
보안 리스트 마비. 수많은 사람이 같은 AI 툴을 돌려 찾아낸 버그를 "보안 위협"이라며 비공개 리스트로 보내면서 시스템이 마비됐다. 대부분 결과만 조금 다른 중복이었다.
커리어 조언. vibe coding으로 쓰고 버릴 것을 만드는 건 괜찮다. 하지만 35년 지속되는 프로젝트를 유지하려면, 프롬프트를 잘 쓰는 것을 넘어 AI가 생성한 최종 결과물을 완벽히 이해하는 능력이 필수다.

세 이야기가 한 점을 가리킨다. 코드를 잘 만드는 것 ≠ 코드를 오래 유지하는 것. 리누스는 원래부터 생성보다 유지보수를, 출력보다 이해를 더 어렵고 중요한 문제로 봤다. 리눅스도 Git도 그 철학 위에 서 있다.

생성이 싸지면, 병목은 사라지는 게 아니라 그 결과물을 책임지고 이해·유지하는 사람 에게로 옮겨간다.

3. 에이전트 시대로 번역하면: 좋은 Agent보다 좋은 Repository

이 메시지는 코드에만 적용되지 않는다. 지금 업계는 Prompt Engineering, Agent Engineering, Loop Engineering 같은 단어를 만들고 있지만, 대부분 생성 에 관한 것이다. 리누스의 언어로 번역하면 질문은 하나로 줄어든다. "10년 뒤에도 유지할 수 있는가?"

에이전트를 만드는 것은 쉽다.
워크플로를 만드는 것도 쉽다.
MCP 서버를 만드는 것도 쉽다.

어려운 건 그다음이다.

누가 관리할 것인가?
기억은 어떻게 버전 관리 할 것인가?
의사결정은 어떻게 기록 으로 남길 것인가?
에이전트가 늘어날 때 구조는 어떻게 유지 되는가?

리누스의 "메인테이너 번아웃"은 에이전트 시대에 그대로 재현된다. 에이전트는 출력을 무한히 쏟아내지만, 그것을 검토·이해할 사람의 용량은 유한하다. 생성을 늘릴수록 검토 큐가 쌓이고, 안 읽고 승인하는 고무도장으로 퇴화한다. 그래서 핵심은 더 많은 생성이 아니라, 생성을 감당할 수 있는 구조다.

좋은 Agent보다 좋은 Repository가 중요하다.

재미있는 건, 요즘 자주 거론되는 Agent-Friendly Interface, Work Memory, Repository Governance, Ontology가 사실 전부 생성이 아니라 유지보수를 위한 기술이라는 점이다. 똑똑한 에이전트를 한 번 만드는 기술이 아니라, 에이전트가 늘어나도 기억과 책임과 구조가 무너지지 않게 하는 기술이다.

4. 반론: 유지보수는 성공한 자의 사치 아닌가

여기서 멈추면 절반만 맞다. 리누스의 철학은 매우 특수한 환경에서 나왔다. 리눅스는 30년을 넘겼고, 그가 말한 건 "35년 가는 프로젝트"다. 이미 시장 검증도 생존도 끝난 뒤의 이야기다. 그리고 리누스 본인도 분명히 선을 그었다. 쓰고 버릴 프로젝트(vibe coding)는 AI로 괜찮다. 세상의 모든 코드가 35년 프로젝트는 아니다.

반면 대부분의 회사, 특히 스타트업은 10년 뒤 유지보수보다 1년 뒤 생존이 급하다. 두 개의 최적화 함수가 동시에 존재한다.

리누스의 세계	대부분 기업의 세계
유지보수 최적화	생존 최적화
안정성	성장
기술 부채 최소화	시장 검증
35년	12개월
Community	Revenue

많은 사람이 "리눅스의 교훈"을 말하지만, 실제 시장은 "워드프레스의 교훈"에 더 가깝다. 워드프레스는 완벽하지 않다. 기술 부채도 보안 이슈도 많다. 그런데 사람들이 당장 필요했기에 시장을 먹었다. 그런 단계에서 완벽한 Ontology·Governance를 먼저 까는 것은 과투자(premature optimization) 가 될 수 있다.

그래서 나는 시스템을 볼 때 질문을 하나 더 단다. "이건 35년 프로젝트인가, 쓰고 버릴 프로젝트인가." 리누스의 언어 그대로다. 리눅스 문제라면 거버넌스·기억 버전관리·이해가 중요하고, 쇼피파이 문제라면 고객 확보·전환율·시장 적합성이 먼저다. 그리고 AI 업계는 아직 대부분 쇼피파이 단계에 있는 것 같다.

5. 진짜 문제는 "언제 유지보수를 사느냐"다

두 함수는 어느 한쪽이 틀린 게 아니다. 둘 다 옳다. 너무 일찍 구조에 투자하면 과투자로 생존 자원을 태우고, 끝까지 미루면 성공이 곧 부채가 된다(deferred cost). 그리고 이 균형은 한 번 잡고 끝나지 않는다. 에이전트 하나를 만들 때마다, 기능 하나를 붙일 때마다 우리는 같은 기로에 다시 선다. 그러니 "리눅스냐 쇼피파이냐"는 한 번 고르는 진영이 아니라 상시 배분 문제다. 단일 최적화 함수로 환원되지 않는다.

그 순간 이건 더 이상 소프트웨어 철학 논쟁이 아니다. 자본 배분 문제다. 그리고 이 문제는 내가 개인 자본을 관리하는 작은 운영체제(PCA, Personal Capital Advisor)에서 이미 한 번 풀어봤다. 거기서 다루는 자본은 다섯이다. 돈·시간·집중력·추론량(AI 토큰·사람 검토)·환경. 개인 단위에서도 당장의 생존과 장기 성장이 같은 자원을 두고 매일 싸운다. PCA가 택한 네 수가, 그대로 시스템 설계의 답이 된다.

5.1 단일 함수를 고르지 않는다: 포트폴리오로 본다

어느 하나를 단일 목적함수로 삼으면 나머지가 조용히 고갈된다. 거버넌스만 최적화하면 출시가 안 되고, 출시만 최적화하면 성공이 부채가 된다. 단일 함수를 거부하고 여러 축의 포트폴리오로 본다.

5.2 생존을 먼저 보장하고, 잉여를 한계에서 배분한다

PCA에는 명시적 순서 규칙이 있다. 유지(Operation)의 최소선을 먼저 보장한 뒤, 남는 자원을 프로젝트(Project)에 배분한다. 둘 중 하나를 고르는 게 아니라 순서를 매긴다. 쇼피파이 함수(생존)로 런웨이를 깔고, 그 위의 잉여만 리눅스 함수(이해·구조)에 한계 배분한다. 리누스의 표현으로는, vibe coding으로 일단 굴러가게 하되, 35년 갈 코어에만 이해를 투자하는 것이다.

5.3 미래를 사실인 척하지 않는다

PCA의 원장은 세 층이다. 관측된 과거(Actuals), 가정(Assumptions), 그 둘로 매번 다시 계산되는 예측(Projections). 예측은 저장하는 사실이 아니라 다시 돌리는 순수 함수이고, 가정이 현실과 어긋나 낡으면(stale) 깃발이 선다.

리누스의 보안 정책 변경이 정확히 이것이다. "비공개로 보고하면 보호된다"는 오래된 가정은, AI가 버그 발견을 누구나 할 수 있게 만든 순간 낡아버렸다("AI로 찾은 버그는 이미 다른 100명도 AI로 찾은 것"). 그래서 리눅스 진영은 가정을 다시 계산해 처음부터 공개(public) 로 정책을 뒤집었다. 단기 고통이 있어도 장기적으로 AI가 찾고 고치는 게 낫다고 본 것이다. "35년"은 고정 베팅이 아니라, 사실이 쌓일 때마다 다시 돌려야 할 예측이다.

5.4 비가역적인 것에만 비싸게 투자한다

PCA는 모든 결정에 같은 무게를 두지 않는다. 위험을 blast radius(규모 × 비가역성 × 속도) 로 점수화하고, 싼 기본값 + 비싼 예외로 배분한다.

가역적 결정 → 쇼피파이 함수. vibe coding처럼 일단 싸고 빠르게. 나중에 바꿔도 싼 것들.
비가역적 결정 → 리눅스 함수. 미리 이해와 구조에 투자한다. 핵심 도메인 경계, 책임 귀속, 기억의 버전, 의사결정 기록처럼 나중에 바꾸면 출혈이 큰 소수.

리누스가 "35년 프로젝트는 결과물을 완벽히 이해해야 한다"고 요구한 것도, 결국 비가역적인 코어에 이해를 건 것이다. 되돌릴 수 있는 건 AI에 맡겨 빠르게, 되돌릴 수 없는 건 사람이 이해하고 책임진다.

6. 그래서 승자는 가장 똑똑한 모델이 아니다

좋은 Repository는 무조건 먼저 가 아니다. 생존 최소선 위에서, 비가역적인 것부터 산다. Work Memory·Ontology·Governance를 "전부 미리"도 "전부 나중"도 아니라 blast radius 순으로 들인다.

그리고 이건 손해 보는 순서가 아니다. 리누스도 기타 페달이든 Git이든, 당장 자기가 겪던 문제 를 풀려고 만들었다. 생존을 먼저 풀었더니 그게 20년, 30년짜리 자산이 됐다. 대부분의 기업이 "10년 후"를 설계해서 성공하는 게 아니라, "내년에도 살아남을 구조"를 만들다가 장기 자산을 얻는 이유다. 그건 우연이 아니라 순서다.

한 문장 요약. AI 시대의 승자는 가장 똑똑한 모델을 가진 팀이 아니라, 가장 유지보수하기 쉬운 시스템을 만든 팀일 가능성이 높다. 단, 그 유지보수는 한 번에 사는 게 아니다. 생존 최소선을 먼저 깔고, 비가역적인 것부터, 가정이 낡으면 다시 계산하며 산다. 결국 리누스의 질문은 하나로 줄어든다. "이건 쓰고 버릴 코드인가, 35년 갈 코드인가?"

근거

리누스 토르발스 × 더크 혼델(DH Consulting) 파이어사이드 챗 Q&A. (AI를 도구로 보는 관점·커밋 약 20% 증가·메인테이너 번아웃·보안 보고 공개 정책 전환·"결과물을 이해하는 능력" 조언). 영상: https://youtu.be/i6gVDcx54FY
리누스의 오픈소스 기타 페달 프로젝트: https://github.com/torvalds/guitar-pedal
PCA(Personal Capital Advisor) 설계: 5대 자본 포트폴리오 / Operation 최소선 → Project 배분 / Actuals·Assumptions·Projections 3-레이어 / risk-budget blast radius. 자체 시스템.

작성 메모: 영상 직접 시청이 아니라 대담의 상세 요약(주제·타임스탬프 포함)에 기반했다. 발행 전 핵심 인용(보안 정책 전환·커밋 수치·"35년" 표현)은 원본 영상과 대조 권장.