Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

프롤로그 — AI가 코드를 써 주는 시대에, 왜 책인가

2026년에 책 이야기를 꺼내면 두 가지 반응이 돌아온다. 하나는 "요즘 누가 책 읽나, 모델이 다 해 주는데." 다른 하나는 "맞아요, 근본을 다시 봐야 해요."

둘 다 일면 옳다. 모델은 정말로 많은 코드를 써 준다. 그래서 더 중요한 게 생겼다. 판별. 모델이 생성한 200줄 패치가 옳은가, 옳지 않은가. 빠른가, 느린가. 안전한가, 위험한가. 이 판단은 어디서 오는가. 책에서 가장 잘 자란다.

블로그 글은 사건을 가르친다 — 어제 누가 무엇을 했나.
튜토리얼은 방법을 가르친다 — 이 라이브러리를 어떻게 쓰나.
책은 원칙을 가르친다 — 왜 그렇게 해야 하는가, 그리고 그것이 변하지 않는 이유는 무엇인가.

AI 시대의 개발자에게 책이 더 중요해진 이유는 단순하다. 모델은 방법의 거의 전부를 대체할 수 있다. 그러나 원칙과 판단은 여전히 사람의 머리에 있어야 한다. 그 판단의 재료가 책이다.

이 글은 2026년에 다시 읽거나 처음 읽을 만한 컴퓨터과학·소프트웨어 엔지니어링 고전 12권을 큐레이션한다. 책별로:

무엇을 배우는가 — 핵심 가르침 한 줄
누가 읽어야 하는가 — 신참·중견·시니어 중 누구
2026년에 다시 읽는 이유 — 왜 하필 지금 이 책인가

리스트 자체는 새롭지 않다. 모두 한 번쯤 들어 본 책일 것이다. 그래서 이 글의 가치는 "어떤 책인지"가 아니라 "왜 지금"에 있다. 추가로 책에 준하는 무게를 가진 에세이·논문 몇 편을 보너스로 모았고, 끝에는 무료 PDF·출판사 링크·읽는 순서를 둔다.

책장은 자랑이 아니라 작업 도구다. 읽지 않은 책은 책장에 있어도 머리에는 없다. 12권을 추리는 이유는 그래서다 — 다 읽기 위해서.

한눈에 보는 12권 매트릭스

#	책	저자	초판	난이도	시간 투자	2026년 다시 읽는 이유
1	SICP	Abelson and Sussman	1985	상	3–6개월	50주년. 추상화의 사다리, AI 없는 시대의 사고 훈련
2	The Pragmatic Programmer (20주년)	Hunt and Thomas	1999	중	2–4주	직업 윤리의 갱신, AI 시대에도 유효한 원칙
3	Designing Data-Intensive Applications	Kleppmann	2017	상	1–3개월	분산 시스템 표준 교과서, 2판 작업 중
4	Code (2판)	Petzold	1999 / 2022	중	2주	실리콘에서 소프트웨어까지, 추상화 스택의 지도
5	Crafting Interpreters	Nystrom	2021	중	1–2개월	무료 온라인. 컴파일러를 두려워하지 않게 된다
6	The Mythical Man-Month	Brooks	1975 / 1995	하	1주	사람·소프트웨어의 비합리성은 50년째 그대로
7	A Philosophy of Software Design (2판)	Ousterhout	2018 / 2021	중	1–2주	복잡성이라는 적, deep modules의 미덕
8	Software Engineering at Google	Winters et al.	2020	중	1개월	큰 코드베이스에서 살아남기, 시간 축의 엔지니어링
9	Refactoring (2판)	Fowler	2018	중	3–4주	AI가 리팩터하는 시대의 인간 감수 기준
10	OSTEP (Three Easy Pieces)	Arpaci-Dusseau	2018	중	1–2개월	무료. 운영체제 직관의 황금 표준
11	CSAPP (3판)	Bryant and O'Hallaron	2002 / 2015	상	2–4개월	프로그래머의 관점에서 본 컴퓨터 시스템
12	The C Programming Language (K&R)	Kernighan and Ritchie	1978 / 1988	하	1–2주	명료함의 본보기. 짧은 책의 위엄
Bonus A	Build a Large Language Model (from Scratch)	Raschka	2024	중	1개월	LLM 내부를 손으로 만들어 보는 시간
Bonus B	Designing Machine Learning Systems	Huyen	2022	중	3–4주	ML 시스템의 DDIA, 2026년 ML 엔지니어의 기본서

"시간 투자"는 진지하게 읽고 연습 문제를 일부 하는 기준이다. 통독은 1/3 정도면 된다.

1장 · SICP — Structure and Interpretation of Computer Programs

저자 — Harold Abelson, Gerald Jay Sussman, with Julie Sussman
무엇을 배우는가 — 추상화의 사다리. 절차적 추상화에서 데이터 추상화로, 그리고 메타순환 평가기·레지스터 머신까지. 언어가 아니라 사고의 골격을 만든다.
누가 읽어야 하는가 — 신참부터 시니어까지. 단, 시간이 있을 때. SICP는 빨리 끝내는 책이 아니라 천천히 사는 책이다.
2026년에 다시 읽는 이유 — 50주년. 1985년 초판, 1996년 2판. 2026년에 추상화 능력은 더 중요해졌다. AI가 코드 생성을 대신해도, "이 코드가 어떤 추상의 어느 층에 있는가"를 보는 눈은 사람이 가지고 있어야 한다. SICP는 그 눈을 만드는 데 가장 효율적인 책이다.
읽는 법 — 1·2·3장은 반드시. 4장(메타순환 평가기)을 끝내면 인터프리터에 대한 두려움이 사라진다. JavaScript 판(SICP JS)도 있어서 Scheme이 부담이면 그쪽으로.
함정 — Scheme 문법이 아니라 개념이 핵심이다. 문법에 막혀 포기하지 말 것.

2장 · The Pragmatic Programmer (20주년 기념판)

저자 — David Thomas, Andrew Hunt
무엇을 배우는가 — 개발자의 직업 윤리. DRY, 직교성, 깨진 창문 이론, 신뢰할 수 있는 추정, 일찍 자주 리팩터. 한 챕터에 한 가지 원칙, 한 가지 비유.
누가 읽어야 하는가 — 전부. 특히 1–3년차에 읽으면 다음 5년이 다르다.
2026년에 다시 읽는 이유 — 1999년 초판 이후 20주년 개정판(2019)이 나왔다. AI 도구를 다루는 챕터는 없지만, 놀랍게도 그래도 거의 다 유효하다. "코드를 생성하는 도구의 출력에 책임을 진다"는 태도는 이 책의 정신과 정확히 같다.
읽는 법 — 처음부터 끝까지 한 번 통독, 1년 후 다시 통독. 챕터가 짧아서 침대 머리맡 책으로 좋다.
함정 — "원칙"이 멋져 보여도 코드를 안 쓰면 의미가 없다. 매 챕터 끝의 연습 문제를 자기 코드베이스에 한 번이라도 적용해 볼 것.

3장 · Designing Data-Intensive Applications (DDIA)

저자 — Martin Kleppmann
무엇을 배우는가 — 분산 시스템의 모든 것. 복제·파티셔닝·트랜잭션·일관성·합의·스트림 처리. 단지 카프카·카산드라가 아니라 그 밑의 원리.
누가 읽어야 하는가 — 백엔드·인프라·데이터 엔지니어 전원. 2년차부터.
2026년에 다시 읽는 이유 — 2017년에 나왔지만 여전히 분산 시스템의 표준 교과서. Kleppmann이 2판을 작업 중이라는 소식이 있어, 2026년 시점에는 1판을 끝내 두는 게 자산이다. 또한 데이터베이스 마이그레이션, 이벤트 스트리밍, 합의 알고리즘(Raft)이 일상 업무가 된 시대에 이 책은 공통 어휘가 된다.
읽는 법 — 1·2·3장(데이터 모델·인코딩·저장)은 첫 통독에, 5·7·9장(복제·트랜잭션·일관성)은 이해될 때까지 반복. 12장(미래)은 가볍게.
함정 — 두껍다. 1년에 한 챕터씩이라도 진도를 빼는 게 통독 시도하다 중단보다 낫다.

4장 · Code: The Hidden Language of Computer Hardware and Software (2판)

저자 — Charles Petzold
무엇을 배우는가 — 모스 부호에서 시작해서 손전등 → 릴레이 → 트랜지스터 → 논리 게이트 → CPU → 어셈블리 → 고급 언어로 올라가는 추상화 스택의 전 여정.
누가 읽어야 하는가 — 신참·문과 전공 개발자에게 특히. 시니어도 즐거운 복습이 된다.
2026년에 다시 읽는 이유 — 2022년에 2판이 나왔다. 2판은 GUI·인터넷까지 다룬다. 우리는 LLM·GPU·Kubernetes 위에서 살지만, 그 밑에 있는 게 무엇인지를 잊으면 안 된다. 추상화 누수(leaky abstraction)는 결국 그 밑을 보러 내려가야 잡힌다.
읽는 법 — 처음부터 끝까지. 그림이 많아 읽는 속도가 빠르다.
함정 — 너무 친절해서 가볍게 느껴지지만, 그 친절함이 핵심이다. 같은 내용을 다른 책에서 만나면 보통 훨씬 어렵다.

5장 · Crafting Interpreters

저자 — Robert Nystrom
무엇을 배우는가 — Lox라는 작은 언어의 인터프리터를 두 번 만든다 — 한 번은 트리워킹(Java), 한 번은 바이트코드 VM(C). 어휘 분석·파싱·환경·클로저·클래스·GC·해시테이블까지 직접 구현.
누가 읽어야 하는가 — 컴파일러가 무서운 모든 사람. 신참부터 시니어까지.
2026년에 다시 읽는 이유 — 2021년 책이지만 무료로 온라인에서 전부 공개되어 있고, 매년 업데이트된다. AI가 코드를 쓰는 시대에도, "이 언어가 내부에서 어떻게 동작하는가"를 아는 것은 디버깅 능력의 근본이다. 게다가 LLM·DSL·자체 구성 언어를 만드는 일이 흔해진 2026년에 이 책은 실용적이기까지 하다.
읽는 법 — craftinginterpreters.com에서 처음부터 따라간다. 코드는 직접 타이핑. 1부(Java) 끝나면 큰 산을 넘은 것이고, 2부(C VM) 끝나면 작은 영웅이 된다.
함정 — 책 외부에서 멋진 컴파일러 책을 사기 전에, 이 책을 끝까지 따라가 볼 것. Dragon Book보다 훨씬 빠른 길이다.

6장 · The Mythical Man-Month

저자 — Frederick P. Brooks Jr.
무엇을 배우는가 — 인력을 더 투입한다고 일정이 짧아지지 않는다(Brooks의 법칙). 은총알은 없다. 두 번째 시스템 효과. 외과수술팀 모델. 1975년에 IBM OS/360을 만든 사람의 회고.
누가 읽어야 하는가 — 팀을 이끌거나 곧 이끌게 될 사람 전부. 1주일에 끝낼 수 있다.
2026년에 다시 읽는 이유 — 1975년에 쓰인 이 책이 2026년에도 정확하다는 사실 자체가 메시지다. 사람과 소프트웨어의 비합리성은 변하지 않는다. AI 코딩 에이전트가 들어와도, "더 많은 에이전트를 붙이면 더 빨라진다"는 단순 가정은 여전히 무너진다. 1995년 20주년판에는 "은총알은 없다" 에세이가 부록으로 들어가 있다 — 반드시 읽을 것.
읽는 법 — 짧다. 1주일이면 충분.
함정 — 일부 예시(OS/360, IBM의 폼)는 낡았지만 원리는 안 낡았다. 표면만 보고 무시하지 말 것.

7장 · A Philosophy of Software Design (2판)

저자 — John Ousterhout
무엇을 배우는가 — 복잡성이 곧 소프트웨어 설계의 적이다. Deep modules(좁은 인터페이스 + 풍부한 기능), 정보 은닉, 일반 목적의 모듈, "전략적 프로그래밍". 짧지만 밀도가 높다.
누가 읽어야 하는가 — 3년차 이상. 본인이 짠 코드를 1년 후 다시 보고 한숨이 나온 경험이 있는 모두.
2026년에 다시 읽는 이유 — Ousterhout는 Tcl·Log-Structured File System의 저자이고 Stanford에서 소프트웨어 설계를 가르친 사람이다. 2판(2021)에서는 학생들과의 코드 리뷰 사례가 보강됐다. 2026년 시점에 AI가 쓰는 코드는 얕은 모듈(thin wrapper)을 너무 쉽게 양산한다. 이 책의 "deep module" 기준은 AI 코드의 좋은 감수자(reviewer) 척도가 된다.
읽는 법 — 짧다(약 200쪽). 한 번 통독, 본인 코드 리뷰할 때 옆에 두기.
함정 — 일부 의견(주석에 대한 강한 옹호 등)은 책 밖에서 논쟁이 있다. 그 논쟁을 추적하면 더 재밌다.

8장 · Software Engineering at Google

저자 — Titus Winters, Tom Manshreck, Hyrum Wright (편)
무엇을 배우는가 — 코드가 아니라 소프트웨어 엔지니어링이 무엇인지. "프로그래밍은 시간을 가로질러 통합된 것이다." 코드 리뷰·테스팅·정적 분석·의존성·라지 스케일 변경(LSC)·빌드 시스템 — 큰 코드베이스에서 살아남는 방법.
누가 읽어야 하는가 — 중대형 회사에서 일하는 모든 엔지니어. 시니어 후보생에게는 거의 필수.
2026년에 다시 읽는 이유 — 2020년 책. AI 코딩 에이전트가 라지 스케일 변경(LSC)을 만들 수 있게 된 2026년에 이 책은 더 실용적이다. "코드를 어떻게 안전하게 바꾸는가"는 모델이 답해 주지 않는다 — 사람이 정책으로 정해야 한다.
읽는 법 — 5장(Code Review), 11장(Testing Overview), 17장(Static Analysis), 22장(Large-Scale Changes)을 먼저. 전체를 다 안 봐도 된다.
함정 — 책이 너무 두꺼워서 통독을 시도하면 좌절한다. 챕터 단위로 필요할 때 본다.

9장 · Refactoring (2판)

저자 — Martin Fowler (with Kent Beck)
무엇을 배우는가 — 리팩터링을 일상으로 만드는 방법. 코드 스멜의 카탈로그, 안전한 변환의 카탈로그, 테스트가 어떻게 리팩터를 가능하게 하는가. 2판은 JavaScript 예시로 갱신.
누가 읽어야 하는가 — 모든 개발자. 특히 "이 코드 한 줄도 못 건드리겠다"는 코드베이스에서 일하는 사람.
2026년에 다시 읽는 이유 — AI 도구가 리팩터링 자체는 잘한다. 그러나 무엇을 리팩터해야 하는지의 판단은 사람이 한다. Fowler의 코드 스멜 목록은 그 판단의 어휘다. 또한 모델이 만든 250줄 패치를 보고 "여기는 Extract Function이 필요하다"고 한 줄로 말할 수 있는 사람은 가치가 높다.
읽는 법 — 1·2장은 통독, 카탈로그(3장 이후)는 사전처럼 참조.
함정 — 카탈로그 외우는 게 목적이 아니다. 이름을 안다는 게 핵심이다 — Extract Function이라는 이름을 알면 다음에 그 패턴을 보았을 때 알아본다.

10장 · Operating Systems: Three Easy Pieces (OSTEP)

저자 — Remzi H. and Andrea C. Arpaci-Dusseau
무엇을 배우는가 — 운영체제의 세 가지 큰 조각 — 가상화(CPU·메모리), 동시성, 영속성(파일시스템). 짧은 챕터, 풍부한 예시, 친절한 설명.
누가 읽어야 하는가 — 시스템 프로그래밍·인프라·DB·OS 일을 하는 모두. 비CS 전공 후 입사한 개발자에게 특히.
2026년에 다시 읽는 이유 — 완전히 무료. PDF·HTML로 공개. 2018년판이 안정 버전이고, 매년 작은 수정이 들어간다. 컨테이너·VM·eBPF·서버리스가 일상이 된 2026년에 OS 추상화는 더 중요해졌다. "이게 왜 느리지?"의 답이 OS 어딘가에 있는 경우는 늘었다.
읽는 법 — 가상화부터. 챕터별로 짧아서 통근 시간에도 가능. 끝에는 동시성·파일시스템.
함정 — 무료라서 "언젠가 읽어야지"가 되기 쉽다. 첫 일주일에 첫 3장을 강제로 끝내 보면 가속이 붙는다.

11장 · Computer Systems: A Programmer's Perspective (CSAPP, 3판)

저자 — Randal E. Bryant, David R. O'Hallaron
무엇을 배우는가 — 프로그래머의 관점에서 본 하드웨어·OS·네트워크. 비트·바이트·메모리 계층·캐시·가상 메모리·시스템 콜·네트워킹까지. 카네기멜런 입문 시스템 수업의 교재.
누가 읽어야 하는가 — 시스템·성능·인프라에 관심 있는 모든 사람. 신참부터.
2026년에 다시 읽는 이유 — 2015년 3판이 여전히 표준. 2026년에 AI 학습/추론은 결국 하드웨어 효율의 문제로 수렴한다. 캐시·페이지·메모리 대역폭을 모르고 GPU 클러스터를 다룰 수 없다. CSAPP는 그 기초의 단단함을 만든다. CMU의 무료 강의(15-213/15-513)와 함께 보면 더 좋다.
읽는 법 — 2장(데이터 표현), 3장(어셈블리), 6장(메모리 계층), 9장(가상 메모리)은 필수. 11·12장(네트워킹·동시성)은 선택.
함정 — 무겁다. 한 번에 다 보려 하면 부서진다. 필요 챕터부터.

12장 · The C Programming Language (K&R)

저자 — Brian W. Kernighan, Dennis M. Ritchie
무엇을 배우는가 — C 그 자체. 그리고 명료함이라는 미덕. 250페이지 안에 한 언어와 그 표준 라이브러리, 그리고 가르치는 사람의 절제된 문체.
누가 읽어야 하는가 — 모든 개발자. 특히 C를 안 쓸 사람일수록 — 짧은 책의 위엄이 무엇인지 보러.
2026년에 다시 읽는 이유 — 1978년 초판, 1988년 2판. 거의 50년 전 책이다. 그런데도 여전히 좋은 글쓰기의 본보기다. 코드는 어떻게 짧게 쓸 수 있는가, 문서는 어떻게 군더더기 없이 쓸 수 있는가 — 모델이 장황한 글을 끝없이 생성하는 시대에 이 책의 절제는 거의 도덕적 메시지에 가깝다.
읽는 법 — 1·5장은 반드시(포인터·배열). 나머지는 가볍게.
함정 — C로 일을 시작하려고 보는 책이 아니다. 명료함을 배우러 보는 책이다.

보너스 A · Build a Large Language Model (from Scratch)

저자 — Sebastian Raschka
무엇을 배우는가 — 토큰화·어텐션·트랜스포머·사전학습·미세조정·지시 조정까지 LLM을 손으로 만든다. PyTorch만 사용, 외부 라이브러리 최소.
누가 읽어야 하는가 — LLM을 쓰지만 내부가 궁금한 ML/AI 엔지니어. 응용 개발자에게도 권한다.
2026년에 다시 읽는 이유 — 2024년 책. 2026년 시점에 LLM은 일상 도구가 됐고, 더 이상 "오픈AI의 마법"이 아니다. 내부를 한 번 손으로 만든 사람과 안 만든 사람의 디버깅·튜닝 직관은 다르다. GitHub의 부속 코드와 함께 따라가면 한 달이면 끝난다.
읽는 법 — GitHub 리포의 노트북을 챕터 순서대로. 직접 GPT를 작은 규모로 학습시켜 볼 것.
함정 — "LLM 사용법" 책이 아니다. 내부 메커니즘 책이다.

보너스 B · Designing Machine Learning Systems

저자 — Chip Huyen
무엇을 배우는가 — ML 시스템 설계의 DDIA. 데이터 파이프라인, 피처, 학습·서빙·모니터링, 데이터/모델 드리프트, ML 인프라. 모델 아니라 시스템.
누가 읽어야 하는가 — 프로덕션에서 ML을 운영하는 모든 엔지니어.
2026년에 다시 읽는 이유 — 2022년 책이지만 LLM 시대에도 핵심 원리는 그대로다. RAG·미세조정·온라인 학습이 일상이 된 2026년에 "이 모델이 실서비스에서 어떻게 살아가는가"의 질문은 더 중요해졌다.
읽는 법 — 1·2·8·9장을 우선. 코드보다 시스템 그림을 그려가며.
함정 — Chip Huyen의 후속 책(AI Engineering, 2024)도 좋지만, ML 시스템 기초로는 이 책이 먼저다.

보너스 섹션 · 책에 준하는 무게의 에세이·논문

책 12권으로 부족할 때, 한 편의 글이 한 권을 대신하는 경우가 있다. 분량은 작지만 밀도가 책급인 에세이/논문 모음.

Joel Spolsky — Joel on Software

The Joel Test (2000) — 12개 질문으로 팀의 엔지니어링 성숙도를 잰다. 2026년에도 절반 이상이 여전히 유효.
The Law of Leaky Abstractions (2002) — 모든 추상화는 새고, 그것을 모르면 더 다친다.
Things You Should Never Do, Part I (2000) — 처음부터 다시 쓰지 말라. 모든 리라이트 추진자가 읽어야 한다.

Steve Yegge

Practical Magic (2007) — 추상화에 대해 가장 인간적인 글 중 하나.
Have You Ever Legalized Marijuana? / Get That Job at Google — 인터뷰·커리어에 대한 솔직한 글들. 시간이 지나도 살아남는다.
Notes from the Mystery Machine Bus — 보수파 vs. 자유파 프로그래머의 분류. 한 번 읽으면 잊지 못한다.

Dijkstra의 EWDs

EWD 1036 — On the Cruelty of Really Teaching Computer Science (1988) — CS를 가르치는 게 왜 자비롭지 못한 것에 가까운가. 짧고 잔인하고 옳다.
EWD 215 — A Case against the GOTO Statement (1968) — 한 통의 편지가 산업의 코드 스타일을 바꿨다.

Paul Graham

Beating the Averages (2003) — Lisp 이야기이지만 본질은 도구의 선택과 평균에 대한 거리.
Maker's Schedule, Manager's Schedule (2009) — 만드는 사람의 시간과 관리하는 사람의 시간. 캘린더의 폭력에 대한 가장 좋은 글.

Hamming — You and Your Research (1986)

"왜 어떤 사람은 큰 연구를 하고 어떤 사람은 못하는가." Hamming의 벨 연구소 강연. 모든 시니어가 한 번은 본다.

Bret Victor

Up and Down the Ladder of Abstraction (2011) — 인터랙티브 에세이. 추상화의 단계를 미디어로 보여 준다.
Inventing on Principle (2012) — 강연이지만 본문 못지않게 인용된다. 도구 만드는 사람의 원칙.

Lamport — Time, Clocks, and the Ordering of Events (1978)

분산 시스템 시간 개념의 출발. 짧고 어렵고 아름답다. 한 번은 직접 따라가 볼 만하다.

책 1권이 너무 멀게 느껴질 때, 위 에세이 중 한 편을 읽는다. 한 편이면 충분히 그 일주일이 바뀐다.

읽는 순서 추천

12권을 다 읽는 것은 목적이 아니지만, 시작점은 있을수록 좋다.

0–2년차 개발자

The Pragmatic Programmer — 직업 윤리의 기초
Code (Petzold) — 추상화 스택의 지도
The Mythical Man-Month — 팀과 일정의 진실
K&R — 명료함의 본보기

여기까지 1년이면 충분하고, 직업관과 어휘가 자란다.

2–5년차 개발자

A Philosophy of Software Design — 모듈 설계 감각
Refactoring — 변경 가능성을 유지하는 기술
Crafting Interpreters — 컴파일러 두려움 제거
OSTEP — OS 직관

여기까지 1–2년. 기술 깊이가 늘기 시작.

5–10년차 개발자

DDIA — 분산 시스템 공통 어휘
CSAPP — 하드웨어까지 내려가는 시야
Software Engineering at Google — 큰 코드베이스의 정치학
SICP — 한 번은 끝까지 가 보는 산행

ML 트랙 보강

Build a Large Language Model (from Scratch) — LLM 내부 손으로
Designing Machine Learning Systems — ML 시스템 원리

"순서"는 강한 권유가 아니라 약한 안내다. 회사에서 분산 시스템 일을 시작했다면 2년차여도 DDIA부터. 도구가 일을 끌어 준다.

책을 잘 읽는 작은 기술

이 12권은 모두 두껍거나 어려운 경향이 있다. 잘 읽는 작은 기술 몇 가지.

1. 통독은 1/3만, 정독은 1/10만

두꺼운 기술서는 1/3 정도면 충분히 읽었다고 친다. 정독은 1/10. 책 전체를 정독하려는 시도가 가장 흔한 실패 원인이다.

2. 한 챕터에 한 노트

각 챕터에서 단 한 가지만 메모로 남긴다. "이 챕터는 무엇을 말하나"를 한 문장으로. 책 한 권의 노트가 30문장 안에 들어오면 잘 읽은 것이다.

3. 코드는 직접 친다

특히 SICP·Crafting Interpreters·OSTEP·CSAPP·LLM from Scratch — 코드를 그대로 옮겨 친다. 읽기만 한 챕터와 친 챕터의 흡수율은 5배 차이가 난다.

4. 그룹 스터디는 강력하다

회사에서 책 모임을 1년 단위로 돌리면, 평소엔 손이 안 갈 책이 끝까지 간다. DDIA·CSAPP·SICP는 특히 그룹에서 강력하다.

5. 책의 정답은 출제자의 의도가 아니다

기술서의 본문보다 연습 문제가 본질을 더 잘 가르치는 책이 있다. SICP·CSAPP·OSTEP·LLM from Scratch가 그렇다. 문제를 풀지 않으면 그 책의 절반만 읽은 것이다.

흔한 함정

책장만 자라고 머리는 안 자란다 — "사 두면 언젠가" 라는 생각은 책장만 채운다. 사는 책을 줄이고, 끝내는 책을 늘려라.
유행에 흔들린다 — 매주 새 책 추천 트윗이 올라온다. 12권 안에 안 들어가면 일단 미뤄도 된다. 고전이 고전인 이유는 5년 뒤에도 같은 위치에 있어서다.
번역과 원서 사이 — 번역이 좋은 책은 한국어로 읽는 게 빠르다. K&R·Mythical Man-Month·Pragmatic Programmer는 번역이 좋다. SICP·DDIA·CSAPP는 원서 권장(또는 영문 PDF 무료판 활용).
무료라서 안 읽는다 — OSTEP·Crafting Interpreters는 무료라서 자꾸 미뤄진다. 첫 주에 첫 3장을 강제로 끝내라.
읽고 안 적용한다 — 책의 한 원칙을 본인 코드베이스에 한 번이라도 적용하지 않으면, 그 책은 머리에 없다.

에필로그 — 정수만 남기는 시대에

AI가 매일 좋아지는 시대에 책을 읽으라는 권유는 시대를 거스르는 것처럼 보일 수 있다. 그러나 정반대다. 모델이 더 잘할수록, 사람의 머리에 남아 있어야 할 것은 더 정수만 남는다. 그 정수는 책에서 가장 잘 자란다.

이 글이 권하는 것은 12권을 다 읽으라는 명령이 아니다. 본인의 자리에서 한 권부터 시작하라는 권유다. 1–2년차라면 The Pragmatic Programmer. 3–5년차라면 A Philosophy of Software Design. 5–10년차라면 DDIA. 그 한 권이 끝나면, 다음 한 권을 정하는 것은 자연스럽다.

읽는 데 시간이 든다. 하지만 모델이 코드를 써 주는 시대에 그 시간은 이제 더 남는다. 옛날에는 다섯 시간 동안 코드를 쳤다면, 지금은 다섯 시간 중 한 시간이 코드, 두 시간이 검토, 두 시간이 생각이다. 그 "생각"의 재료가 어디서 오는가. 책에서 가장 잘 자란다.

12권 체크리스트

다 끝낸 책에 체크.

다음 글 예고

"오픈소스 기여 가이드 — 첫 PR부터 메인테이너까지" — 책에서 배운 것을 실제 코드베이스에 적용하는 가장 좋은 방법.
"개발자의 글쓰기 — 블로그·뉴스레터·기술 문서로 청중을 만들기" — 읽기의 반대편, 쓰기에 대해.
"AI 시대의 개발자 다음 커리어 — 코더가 아니라 빌더로" — 책으로 단단해진 판단을 어디에 쓸 것인가.

이 시리즈 안에서 책장은 한 챕터에 해당한다.

참고 / References

"고전을 읽는 일의 가장 큰 보상은, 그 책 자체가 아니라 그 책을 통과한 후의 내 판단이다."

— 개발자의 책장 2026, 끝.