matklad의 아키텍처 학습법 — 책이 아닌 큰 코드베이스, 그리고 LLM 시대의 잃어버린 채널

시니어 엔지니어가 아키텍처 직관을 갖게 된 진짜 경로는 책 한 권이 아니라 큰 코드베이스를 직접 운영한 시간이었다. 그렇다면 코드를 LLM이 쓰는 시대에 주니어는 어떤 채널로 그 직관을 얻을 것인가, 아니면 그 직관 자체가 사라지는 것인가.

도입 — 한 명의 시스템 엔지니어가 자기 학습을 공개했다

2026년 5월 12일, Aleksey Kladov(닉네임 matklad)가 자기 블로그에 「Learning Software Architecture」라는 글을 올렸다. 그는 어떤 회사를 대표해서 글을 쓰는 사람이 아니다. 다만 그가 누구였는지를 짚어 두면 글의 무게가 달라진다. 그는 IntelliJ Rust의 초기 메인테이너였고, JetBrains에서 rust-analyzer를 처음부터 설계했으며, 지금은 TigerBeetle이라는 분산 회계 데이터베이스의 시스템 엔지니어로 일하고 있다. 「Why an IDE?」, 「Notes on a Smaller Rust」, 「How to Test」 같은, 시스템 프로그래밍 분야에서 한 번씩은 회자된 글들의 저자이기도 하다. 즉, “큰 코드베이스를 처음부터 끝까지 만들어 본 사람”으로서의 발언권이 있는 사람이다.

이번 글은 그 권위에 어울리지 않게 짧고 솔직하다. 한 물리학 박사 과정 학생이 그에게 “소프트웨어 디자인을 어떻게 배우면 좋겠는가”라고 물어본 것이 출발점이라고 적혀 있다. 그가 내놓은 대답은 짧게 요약하면 이렇다. 책은 거의 도움이 되지 않았다. 학교의 디자인 강의도 마찬가지였다. 자기가 진짜로 배운 것은 IntelliJ Rust 시절 어쩌다 떠맡게 된 아키텍처 책임을 통해서였고, 그때 저지른 실수가 진짜 교과서였다. 다행스러운 사실은 “소프트웨어 엔지니어링은 호기심 있는 머리만 있으면 제1원칙에서부터 알아낼 수 있을 만큼 단순하다(software engineering is simple enough that an inquisitive mind can figure it out from first principles)“는 것이다.

이 진술이 5월 12일 Hacker News 1면에 547점, 댓글 100건이 넘는 토론을 만들어냈다. 사람들이 모인 이유는 단순하다. 누구나 한 번쯤 본 적 있는 풍경이기 때문이다. 책장에는 Clean Architecture, Domain-Driven Design, Designing Data-Intensive Applications, A Philosophy of Software Design이 꽂혀 있다. 그러나 막상 어떤 PR을 머지할지, 어떤 모듈 경계를 그을지, 어떤 의존을 끊을지 결정하는 순간이 오면 책의 어느 쪽도 펼쳐지지 않는다. 결정은 누군가가 “전에 비슷한 걸 이렇게 짰다가 망했다”는 흉터에서 나온다. matklad의 글은 그 흉터가 어디에서 만들어지는지를 본인이 회고로 적은 글이다.

문제는 이 회고를 2026년의 좌표에 놓고 보면 또 다른 질문이 떠오른다는 것이다. matklad가 흉터를 얻은 채널 — 큰 코드베이스를 사람의 손으로 읽고 수정하는 수천 시간 — 은, 지금 이 순간 빠르게 좁아지고 있다. Cursor와 Claude Code, ChatGPT Codex가 코드의 첫 번째 독자이자 첫 번째 작성자가 되어 가는 시대에, 주니어가 큰 코드베이스를 “씹어서” 흉터를 만들 시간은 어디로 가는가. 이 글은 그 두 가지를 같이 보려는 시도다.

본문 1 — 책이 아닌 코드: matklad가 권한 학습 경로

먼저 matklad의 글을 정확히 따라가 보자. 그는 학습 자료를 두 개 층위로 나눈다. 첫째는 글과 강연이다. 그가 가장 강력하게 추천하는 것은 책이 아니다. Gary Bernhardt의 강연 「Boundaries」, 그리고 Pieter Hintjens의 ØMQ 가이드, Jamii의 「Reflections on a Decade of Coding」, Ted Kaminski의 블로그, 그리고 자기 자신이 쓴 「How to Test」다. 모두 한 사람의 구체적인 경험과 그것을 일반화한 짧은 글들이다.

책은 둘째로 밀려나 있다. 그가 거론한 두 권은 Software Engineering at Google과 John Ousterhout의 A Philosophy of Software Design인데, 후자에 대해 그는 “다들 추천하지만 나에게는 변화를 주지 못했다”는 식으로 미적지근하게 적었다. 즉 그는 “아키텍처 책”이라는 산업 전체에 다소 회의적이다.

그렇다면 무엇이 진짜로 그를 가르쳤는가. 그의 자기 진단은 두 가지로 모인다. 하나는 IntelliJ Rust와 rust-analyzer 시절 본인이 직접 책임자가 되어 잘못된 결정을 내려 본 경험이다. “내가 진짜로 배운 것은 IntelliJ Rust에서 — 의도하지 않게 — 아키텍처 책임자 위치에 끼워 넣어졌고, 그래서 직접 실수를 저지를 수밖에 없었기 때문이다.” 다른 하나는 그가 생각하는 학습의 메타 원칙, 즉 “소프트웨어 엔지니어링은 단순한 영역이고, 호기심 있는 머리는 제1원칙에서 출발해 답을 찾아낼 수 있다”는 신념이다.

이 두 가지가 합쳐지면 그가 권하는 학습 경로의 윤곽이 잡힌다. 책 < 글과 강연 < 큰 코드베이스를 직접 읽고 수정하는 시간 < 자기 손으로 시스템을 처음부터 끝까지 책임지는 경험. 책은 어휘를 준다. 글과 강연은 좋은 멘탈 모델을 한두 개 더해 준다. 그러나 진짜 직관 — 어떤 PR이 위험하고, 어떤 의존이 5년 뒤에 청구서가 되는지, 어떤 추상이 폭발하지 않을지에 대한 직관 — 은 직접 짠 것을 직접 운영하면서만 자란다.

이 진단은 matklad만의 것이 아니다. 그가 쓴 글에 달린 댓글 가운데 가장 많이 추천된 것은 deepsun의 다음과 같은 정리였다. “아키텍처를 배우는 가장 좋은 방법은 다음 두 가지다. 1) 충분히 큰 프로젝트를 유지하라. 만들지 말고 유지하라. 2) 적어도 두세 개의 프로젝트에 대해 그렇게 하라.” (The best way to learn architecture is to: 1. Maintain a large enough project. Not create, but support. 2. Do it for at least couple or few projects.) 그는 “Google에서 특히 잘 보이는 현상인데, 새로 만든 사람은 승진하고, 유지한 사람은 승진하지 못한다. 그래서 회사 안에서 가장 좋은 아키텍트 후보는, 모두가 떠난 프로젝트를 떠맡으러 들어온 외주 컨설턴트인 경우가 많다”고 덧붙였다. 매우 냉소적이지만, 그가 말하는 패턴은 실제로 익숙한 것이다.

또 다른 댓글에서 miki123211은 Architecture of Open Source Applications라는 책 시리즈를 추천했다. “각 챕터를 그 프로젝트의 메인테이너가 직접 썼기 때문에, 아키텍처가 무엇인지뿐 아니라, 그 아키텍처를 만들어낸 제약 — 보통은 역사와 변화하는 비전 — 까지 같이 배울 수 있다.” 이 코멘트는 matklad의 주장과 아주 잘 맞아떨어진다. 책으로 배울 수 있는 것이 있다면, 그것은 추상 원칙이 아니라 “특정 코드베이스가 왜 그렇게 생겼는지”에 대한 메인테이너의 자기 진술이다.

CSMastermind라는 사용자는 더 직설적으로 “치트 시트”라며 12개의 룰을 적었다. 좋은 디자인은 한 가지 아이디어가 일관되게 배어 있는 것이다. 더 일반화하면 목표는 놀라움(surprise)을 최소화하는 것이다. 시스템이 허용하면 사람은 한다. “모두가 그냥 이렇게만 하면 된다”로 시작하는 해법은 해법이 아니다. 데이터를 변환하는 부분과 사용하는 부분을 분리하라. 데이터 모델은 코드보다 오래 산다. 결합(coupling)이 대부분 악의 뿌리다. 버전 관리는 피할 수 없다. 상태를 명시적으로 만들라. 모든 정보는 단일 진리원(single source of truth)을 가져야 한다. 이름 짓기에 더 많은 시간을 쓰라. 테스트가 어렵다면 디자인이 잘못된 것이다. 문서화하지 않은 결정은 모두 후회하게 된다. 커뮤니케이션은 세금이며, 내기 전에 정당화해야 한다.

CSMastermind의 리스트를 매개로 보면, “책”이 약속하는 것이 무엇인지 분명해진다. 그것은 위와 같은 격언들을 한 권에 응축해 주는 일이다. 그러나 격언은 격언일 뿐 직관이 아니다. “테스트가 어렵다면 디자인이 잘못됐다”는 문장을 읽는 것과, 어떤 PR이 들어왔을 때 “이거 테스트 짜기 힘들겠는데, 이 부분 모듈 경계가 잘못 그어졌나” 하고 즉각적으로 의심이 드는 것은 완전히 다른 인지 활동이다. 그 사이의 거리를 좁히는 것은 — matklad의 답에 따르면 — 책이 아니라 시간이다.

본문 2 — Conway가 이긴다: rust-analyzer가 보여준 아키텍처의 본체

matklad의 글에는 책 추천보다 훨씬 흥미로운 한 단락이 있다. 그는 “산업 소프트웨어와 과학 소프트웨어의 품질 격차는 지식 격차가 아니라 인센티브 구조의 차이에서 온다”고 말한다. 박사 과정 학생이 “내 PhD가 3개월 안에 논문을 내야 한다”는 압력 아래에서 작성하는 코드와, 5년 동안 한 팀이 같은 컴파일러를 유지하는 코드의 차이는, 알고리즘이나 디자인 패턴 지식의 차이가 아니다. 누구의 시간이 어디에 가게 만들어졌는가의 차이다.

그가 인용한 한 줄은 신랄하다. neugierig의 표현을 빌려 그는 적었다. “우리는 프로그래밍을 코드를 쓰는 일처럼 이야기하지만, 코드는 아키텍처보다 덜 중요하고, 아키텍처는 사회적 문제보다 덜 중요하다(we talk about programming like writing code, but code matters less than architecture, and architecture matters less than social issues).” 이것은 Conway의 법칙의 실용 버전이다. 시스템의 형태는 결국 그 시스템을 만드는 조직의 의사소통 구조를 반영한다. 그러므로 진짜 아키텍처 문제는 모듈 경계가 아니라, 어떤 사람이 어떤 시간을 쓰게 되어 있는가의 문제다.

이 통찰의 가장 구체적인 사례가 그가 직접 만든 rust-analyzer다. 그는 rust-analyzer를 의도적으로 두 층위의 품질 기준으로 설계했다고 적었다. 컴파일러의 코어 — 파서, 타입 추론, 이름 해석 — 는 매우 높은 품질 기준, 최소 의존성, 빠른 테스트 스위트를 요구하도록 만들었다. 그래야 코어를 만질 수 있는 사람이 한정되고, 회귀가 들어오기 어려워진다. 그러나 “주말의 자원봉사자”가 들어와 한두 가지 기능을 추가할 수 있는 자리, 예컨대 보조 분석이나 부가 인텐션 기능 같은 영역은 일부러 격리된 모듈에 두고, catch_unwind 가드로 감싸 충돌이 코어로 번지지 않게 만들었다. 이쪽 모듈에는 완벽주의를 강요하지 않았다. 깨지면 격리될 뿐이다.

이 결정이 의미하는 바는 단순한 모듈화가 아니다. 그것은 “어떤 종류의 사람을 모이게 할 것인가”라는 사회학적 결정이다. 코어의 깐깐한 기준은 풀타임 시스템 엔지니어들을 모이게 하고, 격리된 주변부의 너그러운 기준은 주말 기여자들을 모이게 한다. 두 부류는 충돌하지 않고 같은 저장소에서 살 수 있다. 결과적으로 rust-analyzer는 “JetBrains의 풀타임 직원이 한 번에 가르쳐야 하는 프로젝트”가 아니라 “다양한 사람이 다양한 시간 단위로 기여 가능한 프로젝트”가 되었다.

matklad는 이 결정에 단서도 단다. “오늘의 문제를 해결하기 위한 실험적 아키텍처가 내일의 영구적 제약이 되는 일이 흔하다.” 이 말은 그가 자기 결정을 자랑하는 것이 아니라, 자기가 쥔 흉터의 일부로 회고한다는 사실을 보여준다. 두 층위 설계가 결과적으로 좋은 선택이었다고 해도, 그 결정 자체는 영구적이 되어 다음 세대 메인테이너의 손을 묶는다. 아키텍처는 깨끗한 칠판 위에 그리는 그림이 아니다. 늘 누군가가 직전에 그어 놓은 선들 위에 다시 그어진다.

이 지점이 책이 잘 가르치지 못하는 부분이다. Clean Architecture는 “의존성은 안쪽으로 향해야 한다”고 말한다. 그러나 의존성을 어디서 끊을지를 결정하는 순간에 진짜 압력은 두 가지다. 첫째, 누가 이 모듈을 유지할 것인가. 둘째, 그 사람들이 어떤 보상 구조 안에 살고 있는가. 책은 이 두 질문에 답하지 못한다. 답은 늘 그 코드베이스의 역사 안에 있다.

ah1508이 댓글에서 비슷한 결을 이어갔다. 그는 주니어들에게 “clean code”나 “beautiful code” 같은 형용사 대신, 명확한 목표 리스트를 제시할 것을 권한다. 유지가능한가, 성능과 확장성이 있는가, 효율적인가, 회복력이 있는가, 관찰 가능한가, 테스트 가능한가, 보안이 되어 있는가, 새로 들어오는 개발자가 읽을 수 있는가. “각 기준이 서로 균형을 이루며, 기준을 늘릴수록 망설일 때 좋은 선택을 하기 쉬워진다.” 이 또한 matklad의 진단과 잘 맞는다. 좋은 아키텍처는 격언으로 환원되지 않는다. 그것은 트레이드오프의 이름들을 정확하게 부를 수 있는 능력이다.

CSMastermind의 마지막 줄은 그래서 모든 것을 압축한다. “어떤 레벨의 엔지니어든, 그 일은 정보가 불완전한 문제를 해결하기 위해 경험칙(rules of thumb)을 사용하는 일이다(the job of an engineer at any level is to use rules of thumb to solve problems for which there is incomplete information).” 직관이라는 단어는 결국 이 의미다. 정보는 늘 불완전하고, 결정은 늘 지금 내려야 한다. 그 사이의 공백을 메우는 것이 경험이다. 책은 그 경험의 압축이지 대체가 아니다.

본문 3 — LLM 시대의 좁아진 채널: 주니어는 어디서 흉터를 얻을 것인가

matklad의 글이 2026년 5월에 1면에 오른 진짜 이유는, 한 시스템 엔지니어의 학습 회고가 새로운 것이어서가 아니다. 그 회고가 가리키는 학습 채널이 지금 빠르게 좁아지고 있다는 사실 때문이다.

다시 정리하자. matklad가 직관을 얻은 경로는 큰 코드베이스를 직접 쓰고, 직접 고치고, 직접 책임진 시간이다. 그런데 2025년 12월 이후 GitHub의 트래픽이 30배가 된 이유는 사람이 코드를 30배 많이 쓰게 되어서가 아니다. ChatGPT Codex와 Claude Code, Cursor 같은 코딩 에이전트들이 사람 대신 코드의 첫 줄과 첫 PR을 쓰게 되었기 때문이다. 즉, 코드를 처음 마주하는 주체가 인간에서 에이전트로 옮겨가는 중이다. 이 변화는 “주니어가 큰 코드베이스를 손으로 씹어서 흉터를 얻는 시간”을 정확히 그만큼 빼앗는다.

이것이 단순한 노스탤지어가 아니라는 것은 댓글창의 ramon156의 솔직한 고백에서 확인된다. “내가 일하는 프로젝트의 멘탈 모델을 얻는 데 더 많은 시간을 쓰고 싶지만, 프로그래밍 언어나 어떤 아키텍처 결정, 너무 복잡해 보이는 어떤 부분이 마음에 들지 않으면 의욕을 잃어버린다(I would like to spend my time more on gaining a mental model of the projects I work on, but I get very demotivated if I start disliking things).” 그가 추가로 말한 한 줄은 이 시대의 정서를 잘 보여준다. “이미 일주일에 40시간을 내가 상상할 수 있는 가장 따분한 프로젝트를 들여다보는 데 쓰고 있다.” 이 정서는 보편적이다. 큰 코드를 씹는 일은 근본적으로 따분하다. 그것이 흉터의 가치인데, 사람은 흉터를 적극적으로 선택하지 않는다.

LLM은 정확히 이 따분함을 줄여준다. 새 모듈을 추가하면서 이 코드베이스의 전체 구조를 머리에 넣는 대신, “이 함수를 비슷한 패턴으로 추가해 줘”라고 부탁할 수 있다. 결과는 대체로 동작한다. 동작하기 때문에 머지된다. 머지되기 때문에 다음에 비슷한 일이 생기면 또 같은 채널을 쓰게 된다. 이 사이클이 충분히 반복되면, 코드베이스를 통째로 머리에 넣지 않고도 일이 흘러가게 된다. 흘러가는 동안 직관은 자라지 않는다.

이 위험을 인식한 사람들이 새로운 학습 채널을 모색한다. 한 가지 후보는 “AI와의 페어 코드 리뷰”다. 사람이 PR을 열고, AI에게 “이 PR이 이 코드베이스의 기존 컨벤션과 어디가 어긋나는지, 그리고 5년 뒤 어떤 부담을 만들지 분석해 달라”고 부탁한다. 모델이 답하는 동안 사람은 자기 직관과 모델의 답을 비교하게 된다. 이것이 잘 굴러가면 흉터의 일부를 모델이 대신 보여주는 효과가 있다. 잘못 굴러가면 모델의 답을 외우는 새로운 종류의 책 학습이 된다.

또 다른 후보는 “AI가 만든 코드를 의무적으로 리팩터링하는 시간”이다. 즉 프로덕션에 들어가는 모든 LLM 생성 코드는 사람이 한 번 통째로 읽고 다시 쓰는 단계를 거치도록 정책을 만든다. 이것은 LLM의 생산성 이득의 일부를 학습 비용으로 의도적으로 되돌리는 일이다. 그러나 회사 입장에서 이 정책은 비용이고, 직원 입장에서 이 정책은 따분함이다. 양쪽 모두에게 자연스럽게 채택될 가능성은 높지 않다.

세 번째 후보는 “AI 시대 이전에 만들어진 큰 코드베이스를 의도적으로 골라 읽는 일”이다. miki123211이 추천한 Architecture of Open Source Applications가 한 예다. matklad가 만든 rust-analyzer 자체가 또 한 예다. Linux 커널, PostgreSQL, SQLite, Redis, CPython 같은 오랜 프로젝트들은 LLM이 등장하기 한참 전에 만들어진 결정의 흔적을 그대로 갖고 있고, 그 흔적이 지금도 작동한다. 주니어가 큰 코드베이스의 직관을 얻고 싶다면, 자기가 일하는 회사의 코드베이스 외에 의도적으로 한두 개 이런 프로젝트를 골라 메인테이너 시점에서 읽을 필요가 있다. matklad의 글이 가리키는 학습 경로는, 결국 이 종류의 자기 강제다.

0xbadcafebee의 댓글은 이 모든 논의에 좋은 비유를 더한다. “소프트웨어 아키텍처는 배관 설계와 같다. 매우 중요하지만, 우리는 배관 안에 사는 게 아니라 배관이 들어 있는 집 안에 산다. 배관이 집의 나머지를 고려하지 않으면, 매우 비싼 수리가 된다.” 아키텍처는 그 자체가 목적이 아니라, 집 — 즉 비즈니스, 팀, 사용자 — 이 살아갈 수 있게 하는 보조 구조다. LLM이 이 비유에서 하는 일은, 배관을 더 빨리 까는 일이지 집의 모양을 결정해 주는 일이 아니다. 집의 모양을 결정하는 직관을 잃은 채 배관만 빠르게 까이면, 5년 뒤 매우 비싼 수리가 청구서로 도착한다.

결론 — 책은 어휘이고, 코드베이스는 흉터다

처음의 질문으로 돌아가자. 시니어 엔지니어가 아키텍처 직관을 얻은 진짜 경로는 무엇이고, LLM 시대에 주니어는 그 직관을 어디서 얻는가.

matklad가 5월 12일 자기 글에서 답한 첫 번째 절반은 분명하다. 책은 어휘를 준다. 글과 강연은 좋은 멘탈 모델을 한두 개 보태 준다. 그러나 직관 — 어떤 PR이 위험한지, 어떤 의존이 청구서가 되는지, 어떤 사회적 인센티브가 어떤 모듈 경계를 결정하는지에 대한 즉각적인 감각 — 은 큰 코드베이스를 직접 책임지고 운영한 시간에서만 자란다. 그가 권한 길은 책 < 글 < 큰 코드베이스 읽기 < 자기 시스템 운영의 순이다. Clean Architecture가 약속하는 것이 직관 그 자체라면, matklad의 진단은 그 약속이 과장이라고 말한다. 책은 흉터를 줄 수 없다. 흉터는 직접 베어야 생긴다.

두 번째 절반은 그가 직접 답하지 않은 부분이고, 우리가 답해야 하는 부분이다. 코드를 LLM이 쓰는 시대에 주니어의 흉터 채널은 좁아진다. 이것은 도덕의 문제가 아니라 산수의 문제다. 같은 양의 PR이 인간이 짜는 시간이 줄어들수록, 인간이 흉터를 얻는 시간도 줄어든다. 그 결과는 한 세대 뒤에 도착할 것이다. 도착했을 때 비싸지 않을 거라는 보장은 어디에도 없다.

가능한 답은 결국 의도적인 자기 강제다. AI에게 처음부터 끝까지 시키지 않고, AI가 짠 것을 통째로 다시 읽고, 큰 오픈소스 코드베이스를 메인테이너 시점에서 골라 읽으며, 자기 직관을 모델의 답과 의식적으로 부딪쳐 보는 시간을 따로 떼어 두는 일이다. matklad의 글은 그 시간을 변호하는 가장 좋은 텍스트 중 하나다. “소프트웨어 엔지니어링은 호기심 있는 머리만 있으면 제1원칙에서부터 알아낼 수 있을 만큼 단순하다.” 단순하다는 그의 말은 위로지만, 그 단순함을 자기 머리로 다시 도출해 보는 일은 호기심을 가진 사람에게만 일어난다. LLM은 그 호기심을 더 쉽게 무뎌지게 한다. 이 시대에 아키텍처 직관을 갖고 싶다면, 호기심을 의식적으로 보호해야 한다. 책은 어휘일 뿐이고, 큰 코드베이스는 흉터다. 흉터를 만들 시간을 자기 일정 안에 의도적으로 남겨 두는 것 — 그것이 2026년 5월의 matklad가 우리에게 남긴 진짜 숙제다.