diff --git a/.gitignore b/.gitignore
index 09827ab..76dce5f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -26,3 +26,5 @@ yarn-error.log*
 # 로컬 실행 플랜 (실행 안내서, PR 본문에 녹임)
 # docs/ 밖으로 분리 — docs/ 안에 두면 autogenerated 사이드바에 노출됨 (로컬 dev 오염)
 /plans/
+/docs/plans/
+/docs/brainstorms/
diff --git a/docs/brainstorms/2026-04-20-readme-renewal-requirements.md b/docs/brainstorms/2026-04-20-readme-renewal-requirements.md
deleted file mode 100644
index c636812..0000000
--- a/docs/brainstorms/2026-04-20-readme-renewal-requirements.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-date: 2026-04-20
-topic: readme-renewal
----
-
-# README 리뉴얼
-
-## Problem Frame
-
-현재 README는 초안 수준 — 비주얼 없음, 챕터 목록이 페이지 범위만 표기, 멤버 사진이 50px로 너무 작음. GitHub에서 프로젝트를 처음 보는 외부 개발자에게 스터디의 정체성과 콘텐츠 목적지를 즉각 전달해야 한다.
-
-## Requirements
-
-**비주얼 — 멤버 섹션**
-
-- R1. `스터디원.png`에서 배경 제거(rembg) → `static/img/members/study-members-nobg.png` 저장, README 최상단 히어로 배너로 사용
-- R2. 멤버 카드를 2열 HTML 테이블로 재구성 — GitHub 프로필 사진 80px + 🐾 이모지 + 이름(한국어) + 닉네임 + 연차 + 한 줄 설명 (hero.png의 캐릭터 설명 텍스트 그대로 사용)
-
-**README 구조 — 가독성**
-
-- R3. 중앙 정렬 타이틀 + 뱃지 행 (Docusaurus 사이트 링크 + Notion 링크)
-- R4. "📖 스터디 노트 보러 가기" 명확한 CTA를 누끼 배너 아래 배치
-- R5. 챕터 섹션을 파트별 테이블로 교체 — 파트 이름 + 챕터 범위 + 테마 키워드 포함
-- R6. 개발 세팅 섹션 유지 (npm → pnpm으로 정확히 반영)
-
-**범위 제외**
-
-- 영문 README 추가 (별도 이슈)
-- Docusaurus 사이트 본문 변경 없음
-
-## Success Criteria
-
-- 외부 방문자가 README에서 스터디 성격, 멤버, 콘텐츠 링크를 30초 내 파악 가능
-- 누끼 사진이 GitHub 다크/라이트 모드 둘 다 자연스럽게 표시
-
-## Key Decisions
-
-- 누끼 배너 + 2열 개인 카드 조합 선택: 단체 정체성 + 개인 목소리 동시에 살림
-- hero.png(일러스트)는 Docusaurus 사이트 히어로용으로 유지, README는 실제 사진 사용
-
-## Next Steps
-
-→ 직접 작업 진행 (rembg 처리 + README 작성)
diff --git a/docs/foundations/1-construction.mdx b/docs/foundations/1-construction.mdx
index 2c8a9aa..4edf1c8 100644
--- a/docs/foundations/1-construction.mdx
+++ b/docs/foundations/1-construction.mdx
@@ -10,6 +10,10 @@ ai_assisted:
   - summary.lead
   - summary.bullets
   - verdict.rationale
+  - chapter1.book_summary
+  - chapter2.book_summary
+  - chapter3.book_summary
+  - chapter4.book_summary
 source: notion-pull
 source_page_id: 16dde71a-aa9f-83d2-a989-014e17b8d7de
 chapters_in_book: [1, 2, 3, 4]
@@ -46,6 +50,18 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## Chapter 1. Welcome to Software Construction
 
+### 📖 원문 핵심
+
+**구현(Construction)의 범위**: 소프트웨어 구현은 단순히 코딩만을 뜻하지 않아요. 상세 설계, 코딩, 디버깅, 단위 테스트, 통합 테스트가 모두 구현에 포함돼요.
+
+**구현은 유일하게 반드시 일어나는 활동**: 요구사항 분석이나 아키텍처 설계는 프로젝트 사정에 따라 생략되기도 하지만, 구현은 어떤 프로젝트에서도 건너뛸 수 없어요.
+
+**구현은 전체 개발 시간의 30~80%를 차지해요**: 프로젝트 규모에 따라 구현이 차지하는 비중이 크기 때문에, 구현 품질이 프로젝트 성패에 직접적인 영향을 미쳐요.
+
+**소스 코드가 유일하게 항상 최신 상태인 문서예요**: 요구사항 명세서나 설계 문서는 낡아지지만 소스 코드는 언제나 실제 동작을 반영하기 때문에, 코드 품질에 가장 공을 들여야 해요.
+
+**개인 생산성 격차가 구현 단계에서 가장 크게 벌어져요**: Sackman, Erikson, Grant의 연구에 따르면 프로그래머 간 생산성 차이가 구현 단계에서 10~20배에 달하며, 좋은 구현 기법을 익히면 이 격차를 줄일 수 있어요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`한 줄 근거: "construction은 소프트웨어 개발에서 유일하게 반드시 수행되는 활동이다"라는 정의는 AI가 코드를 생성하는 2026년에도 변하지 않아요 — 누가 쓰든, construction은 일어나요.`}
@@ -61,12 +77,24 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 ### 😈 Devil's Advocate
 
 <DevilsAdvocate
-  author="unknown"
+  author={`"Construction의 경계는 이미 흐려졌다"`}
   argument={`"Construction의 경계는 이미 흐려졌다" — McConnell은 construction을 "상세 설계 + 코딩 + 디버깅 + 단위 테스트"로 정의하고, 요구사항이나 아키텍처와 구분한다. 깔끔한 분류지만, 2026년 FE 현실에서 이 경계는 흐릿하다. 컴포넌트를 만들면서 동시에 디자이너와 요구사항을 조율하고, PR을 올리면서 아키텍처를 바꾸고, 배포하면서 A/B 테스트로 요구사항을 검증한다. 활동들이 순차가 아니라 동시에 일어나는 환경에서, "construction은 여기서 시작하고 여기서 끝난다"는 구분이 실용적인 의미를 가지는지 질문할 수 있다. 오히려 "모든 활동이 construction 안에 녹아 있다"는 관점이 애자일 현실에 더 가까울 수 있다.`}
 />
 
 ## Chapter 2. Metaphors for a Richer Understanding of Software Development
 
+### 📖 원문 핵심
+
+**메타포는 알고리즘이 아니라 휴리스틱이에요**: 메타포는 답을 찾는 방법을 알려주는 도구이지, 답 자체를 알려주는 지도가 아니에요. 소프트웨어 개발에서 메타포를 쓴다는 건 탐조등처럼 문제를 비춰보는 것이지, 정해진 경로를 따르는 게 아니에요.
+
+**"코드 쓰기(Writing)" 메타포의 한계**: 소프트웨어 개발을 편지 쓰기처럼 보는 관점은 계획 없이 앉아서 쓰고 수정하면 된다고 암시하는데, 이 비유는 소프트웨어의 협업적 성격과 출시 이후 지속되는 유지보수 비용을 설명하지 못해요.
+
+**시스템 성장(Accretion) 메타포**: 소프트웨어를 굴조개가 진주를 만들듯 작은 단위로 조금씩 쌓아가는 방식으로 보는 관점이에요. McConnell은 이 메타포가 증분 개발의 본질을 가장 정확하게 포착한다고 봤어요.
+
+**소프트웨어 건축(Building Construction) 메타포**: 규모가 커질수록 계획과 설계의 중요성이 달라진다는 점을 건축 비유로 설명해요. 개집을 짓는 것과 마천루를 짓는 것은 접근 방식 자체가 달라지듯이, 소규모와 대규모 소프트웨어 프로젝트도 필요한 준비의 수준이 근본적으로 다르다고 했어요.
+
+**지적 도구상자(Intellectual Toolbox) 메타포**: 숙련된 개발자는 단일 방법론에 종속되지 않고 상황에 맞는 기법을 선택할 줄 알아야 한다고 했어요. 어떤 방법론을 100% 따르면 그 방법론의 렌즈로만 세상을 보게 되어 더 나은 선택지를 놓칠 수 있어요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`한 줄 근거: "소프트웨어 개발을 다른 활동에 비유해서 이해하라"는 사고법 자체는 유효하지만, McConnell이 제시한 비유(건축, 농사, 편지 쓰기)는 2026년 FE의 현실(반복 배포, 피처 플래그, A/B 테스트)과 거리가 생겨서 새로운 비유가 필요해요.`}
@@ -82,12 +110,24 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 ### 😈 Devil's Advocate
 
 <DevilsAdvocate
-  author="unknown"
+  author={`"비유는 이해를 돕지만, 잘못된 비유는 잘못된 의사결정을 만든다"`}
   argument={`"비유는 이해를 돕지만, 잘못된 비유는 잘못된 의사결정을 만든다" — McConnell은 "건축" 비유를 가장 유용하다고 권하면서, 사전 계획의 중요성을 강조한다. 그런데 이 비유를 FE에 가져오면 위험한 면이 있다. 건축은 한 번 지으면 구조를 바꾸기 극히 어렵지만, 소프트웨어는 리팩터링이 가능하고, 피처 플래그로 실험하고, 롤백이 된다. 건축 비유를 내면화하면 "처음부터 완벽하게 설계해야 한다"는 압박이 생기고, 빠른 실험과 반복을 꺼리게 될 수 있다. FE에 더 맞는 비유는 오히려 "정원 가꾸기"일 수 있다 — 심고, 가지치고, 계절마다 다시 배치하는 지속적인 과정. 비유의 선택이 곧 팀의 개발 문화를 형성한다는 점에서, McConnell의 건축 비유를 무비판적으로 받아들이는 건 주의가 필요하다.`}
 />
 
 ## Chapter 3. Measure Twice, Cut Once: Upstream Prerequisites
 
+### 📖 원문 핵심
+
+**사전 준비의 비용 효과**: 결함을 발견하는 시점이 늦어질수록 수정 비용이 급격히 올라가요. 요구사항 단계에서 발견한 결함을 릴리스 후에 수정하면 10~100배 더 비싸기 때문에, 구현 전에 요구사항과 아키텍처를 검토하는 것이 경제적으로 정당해요.
+
+**문제 정의 우선**: 구현을 시작하기 전 첫 번째 선행 조건은 시스템이 해결해야 할 문제를 명확히 서술하는 거예요. 문제 정의는 해결책이 아닌 사용자 언어로 작성해야 하며, 정의가 없으면 올바른 방법으로 잘못된 문제를 풀게 되는 이중 손실이 발생해요.
+
+**명시적 요구사항의 역할**: 공식 요구사항을 작성해두면 시스템 기능을 프로그래머가 아닌 사용자가 주도하게 되고, 구현 도중 발생하는 범위 분쟁을 문서로 해소할 수 있어요. 요구사항 변경은 코딩 중 발견 시 설계를 다시 짜야 하므로 평균 프로젝트에서 재작업의 70~85%를 차지해요.
+
+**아키텍처의 개념 무결성**: 소프트웨어 아키텍처는 시스템의 개념적 무결성을 결정하고, 이것이 결국 제품 품질을 결정해요. 좋은 아키텍처는 상위 레벨부터 하위 레벨까지 일관된 구조를 제공하며, 나쁜 아키텍처는 구현을 거의 불가능하게 만들어요.
+
+**아키텍처 컴포넌트의 책임 분리**: 아키텍처에서 각 빌딩 블록은 하나의 책임 영역을 가져야 하고, 다른 블록의 책임에 대해 최대한 적게 알아야 해요. 두 개 이상의 블록이 동일한 기능을 담당하면 협력이 아닌 충돌이 발생하기 때문에 기능별 소유권을 명확히 정의해야 해요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`한 줄 근거: "요구사항과 아키텍처를 코딩 전에 확인하라"는 원칙은 유효하지만, 2026년 애자일/반복 배포 환경에서는 "100% 확정 후 시작"이 아니라 "핵심 불확실성부터 검증하고, 나머지는 반복하며 발견"하는 형태로 변형됐어요.`}
@@ -105,12 +145,24 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 ### 😈 Devil's Advocate
 
 <DevilsAdvocate
-  author="unknown"
+  author={`"'두 번 재고 한 번 자르라'는 맞지만, FE에서 '재는 비용'은 생각보다 비싸다"`}
   argument={`"'두 번 재고 한 번 자르라'는 맞지만, FE에서 '재는 비용'은 생각보다 비싸다" — McConnell은 요구사항 오류를 나중에 잡을수록 비용이 10~100배 증가한다는 데이터를 제시한다. 인상적인 수치지만, 이 데이터의 출처는 대부분 대규모 워터폴 프로젝트(1970~90년대)다. 2026년 FE에서는 상황이 다를 수 있다. 프로토타입을 하루 만에 만들어 사용자에게 보여주고, 피드백을 받아 다음 날 수정하는 비용이 매우 낮다. 이런 환경에서 "코딩 전에 요구사항을 완벽히 정의하라"는 조언을 문자 그대로 따르면, 문서를 쓰는 데 일주일을 쓰고 정작 프로토타입을 보여줬을 때 "이게 아닌데"가 되는 상황이 벌어진다. 핵심은 "사전 준비의 양"이 아니라 "불확실성이 큰 부분부터 먼저 검증하라"이고, 그 검증 수단이 문서일 수도 있고 프로토타입일 수도 있다.`}
 />
 
 ## Chapter 4. Key Construction Decisions
 
+### 📖 원문 핵심
+
+**언어 선택이 생산성과 품질에 영향을 준다**: 익숙한 언어로 작업하는 프로그래머는 낯선 언어를 쓰는 경우보다 약 30% 더 생산적이고, 고수준 언어는 저수준 언어 대비 5~15배의 생산성·품질 향상 효과가 있어요.
+
+**언어는 사고를 제약한다**: 프로그래밍 언어가 제공하는 어휘가 개발자가 표현할 수 있는 생각의 범위를 결정하며, 언어에 의해 제약받는 "언어 안에서 프로그래밍"이 아니라 언어를 도구로 쓰는 "언어를 향해 프로그래밍"을 지향해야 해요.
+
+**컨벤션은 구현 시작 전에 확정해야 한다**: 변수명, 클래스명, 루틴명, 포매팅, 주석 등의 코딩 컨벤션은 코드가 작성된 이후에 소급 적용하기가 거의 불가능하기 때문에, 구현에 들어가기 전에 팀 전체가 합의해야 해요.
+
+**기술 파동(Technology Wave)의 위치가 개발 방식을 결정한다**: 성숙한 기술 환경(late wave)에서는 안정적인 도구와 문서를 활용해 기능 구현에 집중할 수 있지만, 초기 기술 환경(early wave)에서는 미문서화된 언어 특성이나 도구 버그에 상당한 시간을 써야 하므로 기대치를 그에 맞게 조정해야 해요.
+
+**주요 구현 관행은 사전에 의식적으로 선택해야 한다**: 코딩 컨벤션, 페어 프로그래밍 여부, 테스트 작성 시점, 코드 리뷰 방식, 툴체인 등의 구현 관행은 프로젝트 성격에 맞게 미리 결정해야 하며, 단순히 기본값을 따르는 것은 선택이 아니에요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`한 줄 근거: "코딩 시작 전에 언어·컨벤션·주요 실천법을 의식적으로 선택하라", "언어 안에서가 아니라 언어 속으로 프로그래밍하라"는 원칙은 TypeScript strict 설정, 린터 룰, 프레임워크 선택이 프로젝트 운명을 좌우하는 FE에서 더 절실해요.`}
@@ -132,7 +184,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 ### 😈 Devil's Advocate
 
 <DevilsAdvocate
-  author="unknown"
+  author={`"'언어 속으로 프로그래밍하라'는 맞지만, 언어가 1년마다 바뀌는 게 FE다"`}
   argument={`"'언어 속으로 프로그래밍하라'는 맞지만, 언어가 1년마다 바뀌는 게 FE다" — McConnell은 "언어에 갇히지 말고, 언어가 제공하는 것 이상을 활용하라"고 권한다. 좋은 조언이지만, FE 생태계에 적용하면 독특한 긴장이 생긴다. React는 클래스 컴포넌트 → 함수형 컴포넌트 → Server Components로 패러다임이 몇 년 단위로 바뀌었다. Next.js는 Pages Router → App Router로 전환 중이다. "언어 속으로 깊이 프로그래밍"하면 할수록 특정 패러다임에 강하게 결합되어, 전환 비용이 커질 수 있다. 그래서 반대 관점도 있다 — 프레임워크 특유의 패턴에 깊이 들어가기보다, 프레임워크에 비의존적인 핵심 로직(도메인 로직, 유틸리티)을 최대한 분리해두는 것이 장기적으로 더 안전하다는 관점. "언어 속으로"와 "언어로부터 독립" 사이의 균형은 FE에서 늘 열려 있는 질문이다.`}
 />
 
diff --git a/docs/foundations/2-design.mdx b/docs/foundations/2-design.mdx
index 7dc0206..f4e4ff6 100644
--- a/docs/foundations/2-design.mdx
+++ b/docs/foundations/2-design.mdx
@@ -11,6 +11,8 @@ ai_assisted:
   - summary.bullets
   - verdict.rationale
   - checklist.text
+  - chapter5.book_summary
+  - chapter6.book_summary
 source: notion-pull
 source_page_id: 561de71a-aa9f-8296-b752-8162200acdb6
 chapters_in_book: [5, 6]
@@ -45,6 +47,18 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## Chapter 5. Design in Construction
 
+### 📖 원문 핵심
+
+**설계는 사악한 문제(Wicked Problem)다**: 소프트웨어 설계는 풀어봐야 비로소 명확히 정의할 수 있는 문제로, 틀린 방향을 가보고 되돌아오는 과정 자체가 설계의 본질이에요.
+
+**소프트웨어의 제1 기술 명령은 복잡성 관리다**: 프로젝트가 기술적 이유로 실패할 때 그 근본 원인은 대부분 통제되지 않은 복잡성이며, 좋은 설계의 목표는 한 번에 다뤄야 할 복잡성의 양을 최소화하는 것이에요.
+
+**정보 은닉(Information Hiding)**: 각 클래스는 설계·구현 결정을 다른 클래스로부터 숨겨야 하며, 이 원칙이야말로 복잡성을 감추는 가장 강력한 휴리스틱이에요.
+
+**느슨한 결합(Loose Coupling)**: 클래스 간 연결을 최소화하도록 설계해야 하며, 연결이 늘어날수록 한 부분의 변경이 전체에 미치는 영향이 커져 유지보수 비용이 올라가요.
+
+**설계 계층(Levels of Design)**: 소프트웨어 설계는 시스템 전체 → 서브시스템/패키지 → 클래스 → 루틴 → 루틴 내부의 5개 수준에서 이뤄지며, 각 수준에서 독립적으로 복잡성을 통제해야 해요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`한 줄 근거: "복잡도 관리가 소프트웨어의 최우선 기술적 과제다"라는 대전제는 컴포넌트 트리·상태 관리·빌드 설정이 얽힌 2026년 FE에서 오히려 더 절실해요 — 도구만 바뀌었을 뿐 문제의 본질은 그대로예요.`}
@@ -181,6 +195,18 @@ function PaymentsPage() {
 
 ## Chapter 6. Working Classes
 
+### 📖 원문 핵심
+
+**추상 데이터 타입(ADT)**: 데이터와 그 데이터를 조작하는 연산을 하나의 단위로 묶어, 내부 구현을 숨기고 의미 있는 인터페이스만 외부에 노출하는 개념이에요.
+
+**일관된 추상화 수준**: 한 클래스 인터페이스 안에 employee 수준 루틴과 list 수준 루틴이 섞이면 추상화가 무너지므로, 모든 퍼블릭 루틴은 동일한 추상화 수준을 유지해야 해요.
+
+**캡슐화**: 추상화가 복잡성을 무시할 수 있게 해주는 모델을 제공한다면, 캡슐화는 구현 세부사항을 강제로 숨겨 아예 들여다볼 수 없게 막아주는 더 강한 개념이에요.
+
+**포함("has a" 관계)**: 클래스가 다른 객체를 멤버로 가지는 포함은 상속보다 덜 화려하지만 오류 가능성도 낮으며, 객체지향 프로그래밍의 핵심 작업 도구예요.
+
+**리스코프 치환 원칙(LSP)**: 파생 클래스는 기반 클래스 인터페이스를 통해 사용자가 차이를 모르고도 사용할 수 있어야 하며, 이를 위반하는 상속은 복잡성을 줄이는 것이 아니라 오히려 늘려요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`한 줄 근거: ADT·추상화·캡슐화·응집도·결합도의 원칙은 전부 살아있지만, FE에서 "클래스"의 자리를 커스텀 훅과 컴포넌트가 대체했기 때문에 적용 단위가 class에서 hook/component로 번역되어야 유효해요.`}
diff --git a/docs/good-code/1-routines.mdx b/docs/good-code/1-routines.mdx
index c139d11..20489fa 100644
--- a/docs/good-code/1-routines.mdx
+++ b/docs/good-code/1-routines.mdx
@@ -13,6 +13,9 @@ authors:
 ai_assisted:
   - summary.lead
   - summary.bullets
+  - chapter7.book_summary
+  - chapter8.book_summary
+  - chapter9.book_summary
   - checklist.text
 source: notion-pull
 source_page_id: e6bde71a-aa9f-83d4-b14f-01adf26b8bd6
@@ -48,6 +51,18 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## Chapter 7. High-Quality Routines
 
+### 📖 원문 핵심
+
+**루틴을 만드는 가장 중요한 이유**: 복잡도를 줄이기 위해서예요. 루틴 안에 세부 구현을 감춰두면, 호출하는 쪽에서는 내부 동작을 몰라도 사용할 수 있어요.
+
+**응집도(Cohesion)**: 루틴 내 연산들이 얼마나 밀접하게 관련돼 있는지를 나타내는 척도예요. 가장 좋은 형태는 루틴이 딱 하나의 일만 수행하는 기능적 응집(Functional Cohesion)이에요.
+
+**루틴 이름은 하는 일 전체를 서술해야 해요**: 이름이 길고 어색해진다면 루틴 자체에 부작용(side effect)이 있다는 신호이므로, 이름을 억지로 줄이기보다 루틴을 다시 설계하는 게 맞아요.
+
+**루틴 길이**: 연구 결과들을 종합하면 200줄 이내가 안전한 기준이에요. 길이 자체보다 응집도·중첩 깊이·변수 수 같은 복잡도 지표가 적절한 길이를 결정해요.
+
+**매개변수는 7개 이하로**: 심리학 연구에 따르면 인간이 동시에 추적할 수 있는 정보 덩어리는 약 7개예요. 그 이상이 필요하다면 루틴 간 결합이 너무 강하다는 설계 신호예요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`"루틴을 만드는 가장 중요한 이유는 복잡도를 줄이는 것이다", "하나의 루틴은 하나의 일만 한다(기능적 응집도)" — 함수형 컴포넌트·커스텀 훅·유틸 함수가 전부인 FE에서 "좋은 함수란 무엇인가"는 매일의 질문이다.`}
@@ -367,6 +382,18 @@ async function handleRefund(paymentId: string, amount: number) {
 
 ## Chapter 8. Defensive Programming
 
+### 📖 원문 핵심
+
+**방어적 프로그래밍의 전제**: 프로그램에 잘못된 데이터가 들어와도 손상되지 않아야 한다는 아이디어로, "garbage in, garbage out"은 오늘날 기준으로 허술하고 불안전한 프로그램의 징표예요.
+
+**Assertion(단언문)**: 개발 중에 코드가 스스로를 검증하는 수단으로, 절대 발생해서는 안 되는 조건을 체크하며 전제조건과 사후조건을 문서화하는 실행 가능한 명세 역할을 해요. Assertion은 버그를 잡는 것이고 에러 처리 코드는 예상 가능한 이상 상황을 처리하는 것으로, 둘은 목적이 다르므로 혼용해서는 안 돼요.
+
+**Robustness vs. Correctness**: Correctness는 부정확한 결과를 절대 반환하지 않는 것이고, Robustness는 소프트웨어가 계속 동작하게 하는 것으로, 안전 최우선 시스템은 Correctness를, 소비자용 애플리케이션은 Robustness를 우선시해요.
+
+**Exception(예외) 사용 원칙**: 예외는 다른 방법으로 처리할 수 없는 진정으로 예외적인 조건에만 사용해야 하며, 예외의 추상화 수준은 해당 루틴 인터페이스 수준과 일치해야 하고 빈 catch 블록은 금지예요.
+
+**바리케이드(Barricade) 패턴**: 시스템을 "안전 구역"과 "외부 구역"으로 나누어, 경계에서 데이터를 검증하고 정제하면 내부 코드는 데이터가 깨끗하다고 가정할 수 있어 에러 처리 부담이 줄어들어요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`"나쁜 입력으로부터 프로그램을 보호하라", "바리케이드를 세워 안전 구역을 만들라"는 원칙은 유효하지만, FE에서 방어의 주된 수단이 assertion/error code에서 TypeScript 타입 시스템 + Zod/Valibot 런타임 검증 + Error Boundary로 이동했다.`}
@@ -634,6 +661,18 @@ function getUserName(user: User): string {
 
 ## Chapter 9. The Pseudocode Programming Process
 
+### 📖 원문 핵심
+
+**PPP (Pseudocode Programming Process)**: 루틴을 슈도코드로 설계한 뒤 그 슈도코드를 주석으로 유지하면서 실제 코드를 채워 넣는 루틴 구성 방법론이에요.
+
+**슈도코드 작성 원칙**: 특정 언어 문법에 종속되지 않는 자연어로 작성하고, "어떻게"가 아니라 "무엇을"에 집중해 의도 수준에서 기술해야 해요. 일단 코드를 작성하면 설계를 버리기가 심리적으로 훨씬 어려워지므로, 슈도코드 단계에서 충분히 다듬어야 해요.
+
+**슈도코드 → 고수준 주석 전환**: 슈도코드 각 문장을 코드 내 주석으로 남기고, 그 주석 아래에 실제 구현 코드를 채워 넣는 방식으로 진행해요. 주석 하나가 약 2~10줄의 코드에 대응해요.
+
+**코드 확인(Check the Code)**: 구현 완료 후 정신적 실행(mental walkthrough), 컴파일, 디버거 단계 실행, 테스트를 순서대로 수행하며 각 단계에서 오류를 잡아내야 해요.
+
+**코드 이해 의무**: 코드가 동작하는 것으로는 충분하지 않으며, 왜 동작하는지 이해하지 못한다면 이해할 때까지 공부하고 대안 설계를 실험해야 해요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`"코딩 전에 의사코드로 설계하라"는 사고 습관은 유효하지만, 2026년 FE에서 의사코드의 자리를 타입 정의 먼저 작성하기(type-first), 인터페이스 스케치, 또는 테스트 먼저 작성하기(TDD)가 대체한 경우가 많다.`}
diff --git a/docs/good-code/2-quality.mdx b/docs/good-code/2-quality.mdx
index 31ed37a..5eeafb8 100644
--- a/docs/good-code/2-quality.mdx
+++ b/docs/good-code/2-quality.mdx
@@ -12,6 +12,10 @@ ai_assisted:
   - summary.lead
   - summary.bullets
   - checklist.text
+  - chapter20.book_summary
+  - chapter21.book_summary
+  - chapter22.book_summary
+  - chapter23.book_summary
 source: notion-pull
 source_page_id: 9e8de71a-aa9f-8363-b8b3-01ebd395678c
 chapters_in_book: [20, 21, 22, 23]
@@ -48,6 +52,18 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## Chapter 20. The Software-Quality Landscape
 
+### 📖 원문 핵심
+
+**품질 특성 간 트레이드오프**: 특정 특성을 최대화하려 하면 다른 특성과 충돌이 생기는데, 정확성을 강조하면 견고성이 낮아지고 적응성을 강조하면 견고성이 높아지는 식의 비대칭 관계가 존재해요.
+
+**명시적 품질 목표 설정**: Weinberg와 Schulman의 1974년 실험에서 팀에게 최적화할 목표를 명시적으로 알려줬더니 5개 팀 중 4개 팀이 해당 목표에서 1위를 차지했고, 이는 프로그래머가 목표를 알면 그대로 달성한다는 것을 보여줘요.
+
+**결함 탐지율 비교**: 단일 기법의 결함 탐지율은 최대 75%를 넘지 않으며 평균은 약 40%에 불과해서, 높은 탐지율을 달성하려면 여러 기법을 조합해서 사용해야 해요.
+
+**검사(Inspection)의 비용 효율성**: 코드 검사는 테스팅보다 결함을 더 많이, 더 저렴하게 발견하며 IBM 연구에서는 검사로 결함 1건 찾는 데 3.5 스태프-시간이 소요된 반면 테스팅은 15~25 스태프-시간이 필요했어요.
+
+**소프트웨어 품질의 일반 원칙**: 품질을 높이면 개발 비용이 낮아지는데, 디버깅과 재작업이 일반 개발 사이클에서 약 50%를 차지하므로 결함을 줄이는 것이 일정을 단축하는 가장 직접적인 방법이에요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`"단일 기법으로는 결함의 60%도 못 잡는다, 여러 기법을 조합해야 한다"는 원칙은 타입 체커 + 린터 + 테스트 + 코드 리뷰를 겹겹이 쓰는 2026년 FE 품질 전략의 정확한 근거다.`}
@@ -212,6 +228,18 @@ describe('pay', () => {
 
 ## Chapter 21. Collaborative Construction
 
+### 📖 원문 핵심
+
+**협업 구현(Collaborative Construction)의 가치**: 코드 리뷰, 인스펙션, 페어 프로그래밍 같은 협업 기법은 테스트보다 더 높은 비율의 결함을 더 낮은 비용으로 발견해요.
+
+**페어 프로그래밍 효과**: 비용이 인스펙션과 거의 동일한 수준이면서 결함 검출률은 40~60%에 달하며, 두 사람이 함께 코드를 작성하면 서로의 실수를 즉각 잡아낼 수 있어요.
+
+**공식 인스펙션(Formal Inspection)**: 사전 준비, 명확한 역할 분담, 결함 탐지에만 집중하는 원칙을 따르며, 모든 협업 기법 중 결함 검출률이 45~70%로 가장 높아요.
+
+**결함 탐지와 수정의 분리**: 인스펙션 회의 중에는 결함을 찾는 데만 집중하고 수정은 하지 않아요. 수정까지 같이 하면 회의가 길어지고 핵심 목적이 흐려지기 때문이에요.
+
+**협업 기법과 테스트는 상호 보완적이에요**: 협업 기법은 테스트가 잘 잡지 못하는 종류의 오류를 발견하기 때문에, 두 가지를 함께 사용해야 소프트웨어 품질을 충분히 보장할 수 있어요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`"코드를 다른 사람에게 보여주면 결함을 찾는다"는 핵심은 살아있지만, 형식이 "Fagan식 정규 인스펙션"에서 "GitHub PR 리뷰 + AI 리뷰 봇"으로 완전히 대체되었다 — 원칙은 생존, 형식은 사망.`}
@@ -259,6 +287,18 @@ describe('pay', () => {
 
 ## Chapter 22. Developer Testing
 
+### 📖 원문 핵심
+
+**개발자 테스팅의 한계**: 테스팅은 오류를 감지하는 수단이지 소프트웨어 품질을 직접 개선하는 수단이 아니며, 개발자 테스트 한 단계가 발견하는 오류는 전체의 50% 미만에 그치는 경우가 많아요.
+
+**테스트 우선(Test-First) 작성**: 코드를 작성하기 전에 테스트 케이스를 먼저 작성하면 요건 문제를 조기에 발견하고 결함 수정 비용을 낮출 수 있어요.
+
+**경계값 분석(Boundary Analysis)**: 오류는 경계에 집중되므로 최솟값, 최댓값, 경계의 ±1 값(off-by-one)을 반드시 테스트해야 해요.
+
+**오류 집중 법칙**: 프로젝트 결함의 80%는 전체 클래스·루틴의 20%에 집중되며, 50%는 단 5%의 클래스에서 발생해요.
+
+**커버리지 모니터**: 커버리지 측정 없이 테스팅하면 실제로는 50~60%의 코드만 실행되므로, 커버리지 도구를 사용해 미실행 코드를 확인해야 해요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`"코드 작성 전에 테스트를 설계하라", "경계값·나쁜 데이터·정상 데이터 클래스를 체계적으로 만들라"는 원칙은 Vitest·Testing Library·Playwright가 도구를 바꿨을 뿐, 테스트 설계의 사고방식 자체는 그대로 유효하다.`}
@@ -426,6 +466,18 @@ describe('registerOrder', () => {
 
 ## Chapter 23. Debugging
 
+### 📖 원문 핵심
+
+**디버깅 vs 테스팅**: 테스팅이 오류를 탐지하는 과정이라면, 디버깅은 이미 탐지된 오류의 근본 원인을 식별하고 수정하는 과정이에요.
+
+**결함을 학습 기회로**: 결함은 프로그램을 이해하고, 자신의 실수 패턴을 파악하고, 코드 품질을 점검하고, 문제 해결 방식을 개선할 수 있는 드문 기회예요.
+
+**의심 영역 좁히기**: 이진 탐색(binary search) 방식으로 프로그램의 절반씩 제거해 가며 결함 위치를 체계적으로 추적하면, 전체 코드를 훑는 것보다 훨씬 빠르게 결함을 찾을 수 있어요.
+
+**심리적 집합(Psychological Set)**: 개발자는 자신이 작성한 코드에서 보고 싶은 것만 보는 경향이 있어, 결함이 있는 구역을 무의식 중에 건너뛰는 맹점이 생겨요.
+
+**증상이 아닌 문제를 수정**: 특정 값에 대한 특수 케이스 처리처럼 증상만 덮는 수정은 코드를 점점 더 취약하게 만들므로, 항상 근본 원인을 이해한 후 수정해야 해요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`"과학적 방법으로 가설을 세우고 좁혀가라"는 디버깅의 핵심 사고법은 유효하지만, 2026년 FE에서는 React DevTools·브라우저 퍼포먼스 탭·에러 트래킹(Sentry) 등 도구 의존도가 훨씬 높아져서, "머릿속 디버깅"보다 "도구를 잘 쓰는 능력"이 더 결정적인 차이를 만든다.`}
diff --git a/docs/growth/1-refactoring.mdx b/docs/growth/1-refactoring.mdx
index 689d1b2..b63cf0e 100644
--- a/docs/growth/1-refactoring.mdx
+++ b/docs/growth/1-refactoring.mdx
@@ -12,6 +12,9 @@ ai_assisted:
   - summary.bullets
   - verdict.rationale
   - checklist.text
+  - chapter24.book_summary
+  - chapter25.book_summary
+  - chapter26.book_summary
 source: notion-pull
 source_page_id: a08de71a-aa9f-82e1-9b8b-01bfd7e45852
 chapters_in_book: [24, 25, 26]
@@ -46,6 +49,18 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## Chapter 24. Refactoring
 
+### 📖 원문 핵심
+
+**리팩터링의 정의**: 외부 동작은 그대로 유지하면서 내부 구조를 개선하는 변경으로, Fowler는 이를 "프로그램의 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방식으로 소프트웨어 시스템을 변경하는 과정"이라 정의해요.
+
+**소프트웨어 진화의 기본 원칙(Cardinal Rule)**: 변경이 품질을 향상시켜야 한다는 것이며, 품질이 저하되는 방향으로 시스템이 진화하고 있다면 이는 경고 신호예요.
+
+**코드 냄새 — 코드 중복**: 같은 코드가 두 곳 이상에 존재하면 한 곳을 수정할 때 나머지도 수정해야 하는 병렬 수정 문제가 생기므로, 중복 코드는 리팩터링의 가장 명확한 신호예요.
+
+**리팩터링 안전 수칙 — 작게 유지**: 리팩터링은 변경 범위를 작게 유지해야 모든 영향을 파악할 수 있고, 한 번에 하나씩 진행한 뒤 재컴파일과 재테스트를 해야 해요.
+
+**리팩터링 전략 — 작업 흐름에 통합**: 루틴이나 클래스를 추가하거나 버그를 수정할 때 관련 코드도 함께 리팩터링하면, 별도의 리팩터링 시간을 내지 않고도 코드 품질을 지속적으로 개선할 수 있어요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`"코드 냄새를 감지하고, 동작을 보존하면서 구조를 개선한다"는 리팩터링의 핵심은 2026년에도 일상적인 FE 개발 활동이에요. 오히려 IDE 자동 리팩터링과 TypeScript의 타입 안전망 덕분에 더 안전하게 실행할 수 있게 됐어요.`}
@@ -268,6 +283,18 @@ function calculatePrice(order: { items: { price: number; qty: number }[]; coupon
 
 ## Chapter 25. Code-Tuning Strategies
 
+### 📖 원문 핵심
+
+**파레토 원칙(80/20 법칙)**: 프로그램 전체 실행 시간의 약 80%는 코드의 20%에서 발생하고, Knuth의 연구에 따르면 4% 미만의 코드가 실행 시간의 50% 이상을 차지하는 경우가 많아요.
+
+**조기 최적화 금지**: 프로그램이 완성되기 전에는 어디가 병목인지 알 수 없어서, 개발 중 최적화하면 실제 중요한 4%가 아닌 나머지 96%에 시간을 낭비하게 돼요.
+
+**측정의 필수성**: 경험이나 직관으로는 어디가 병목인지 알 수 없으므로, 모든 최적화 시도 전후에 반드시 정밀하게 측정해야 하며 측정 없는 최적화는 추측에 불과해요.
+
+**반복(Iteration)**: 한 번의 최적화로 목표를 달성하는 경우는 드물고, 여러 작은 개선을 누적해야 하며 시도한 최적화의 절반 이상은 효과가 없거나 오히려 성능을 악화시킬 수 있어요.
+
+**코드 튜닝 접근 순서**: 올바르게 동작하는 코드 작성 → 성능 저하 확인 → 핫스팟 측정 → 설계·알고리즘 문제 여부 판단 → 코드 튜닝 → 개선 효과 측정 → 효과 없으면 원래 코드로 복원의 순서를 지켜야 해요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`"추측하지 말고 측정하라", "전체 시간의 대부분은 코드의 극소수에서 소비된다(파레토)"는 전략은 그대로 유효해요. 다만 FE 성능 병목이 "코드 레벨 연산 비용"에서 "네트워크·렌더링·번들 사이즈"로 이동해서, 튜닝 대상 자체가 달라졌어요.`}
@@ -324,6 +351,18 @@ function calculatePrice(order: { items: { price: number; qty: number }[]; coupon
 
 ## Chapter 26. Code-Tuning Techniques
 
+### 📖 원문 핵심
+
+**단락 평가(Short-Circuit Evaluation)**: `if (a && b)` 같은 복합 조건에서 앞 조건만으로 결과가 확정되면 뒤 조건을 아예 평가하지 않아 불필요한 연산을 제거할 수 있어요.
+
+**루프 언스위칭(Unswitching)**: 루프 안에서 매 반복마다 바뀌지 않는 조건 판단을 루프 밖으로 빼내 두 개의 전용 루프로 분리하면 조건 평가 반복 비용이 사라져요.
+
+**루프 내 작업 최소화(Minimizing Work Inside Loops)**: 루프 반복 중 값이 변하지 않는 포인터 역참조나 배열 접근은 루프 밖 변수에 캐싱해 반복 접근 비용을 제거해요.
+
+**캐싱(Caching)**: 최근에 계산한 결과를 저장해 두고 같은 입력이 들어오면 재계산 없이 반환하면 반복 호출 비용을 크게 줄일 수 있어요.
+
+**대수 항등식 활용(Exploit Algebraic Identities)**: `sqrt(x) < sqrt(y)` 대신 `x < y`를 쓰는 것처럼 수학적으로 동치인 더 저렴한 표현식으로 교체하면 연산 비용을 극적으로 낮출 수 있어요.
+
 <Verdict
   rating="🔴 사망"
   rationale={`루프 언롤링, 센티넬 탐색, 정수 나눗셈 대체 같은 코드 레벨 최적화는 C/C++ 시대의 유산이에요. JS 엔진(V8)의 JIT 최적화와 브라우저 렌더링 파이프라인이 병목인 FE 환경에서는 이 기법들 자체는 거의 의미가 없어요.`}
diff --git a/docs/growth/2-craftsmanship.mdx b/docs/growth/2-craftsmanship.mdx
index 9a71ba0..a0a90cb 100644
--- a/docs/growth/2-craftsmanship.mdx
+++ b/docs/growth/2-craftsmanship.mdx
@@ -13,6 +13,10 @@ ai_assisted:
   - summary.bullets
   - verdict.rationale
   - checklist.text
+  - chapter31.book_summary
+  - chapter32.book_summary
+  - chapter33.book_summary
+  - chapter34.book_summary
 source: notion-pull
 source_page_id: cd0de71a-aa9f-82bf-bce9-813c189c3181
 chapters_in_book: [31, 32, 33, 34]
@@ -49,6 +53,18 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## Chapter 31. Layout and Style
 
+### 📖 원문 핵심
+
+**레이아웃의 역할**: 레이아웃은 프로그램의 논리적 구조를 시각적으로 드러내는 수단이며, 코드의 동작에는 영향이 없지만 인간 독자의 이해도에는 결정적인 영향을 미쳐요.
+
+**포매팅의 기본 정리(Fundamental Theorem of Formatting)**: 좋은 레이아웃의 제1목표는 코드를 예쁘게 만드는 것이 아니라 코드의 논리적 구조를 정확하게 드러내는 것이에요.
+
+**들여쓰기(Indentation)**: 들여쓰기는 논리적으로 하위에 속하는 구문을 상위 구문 아래에 시각적으로 배치하는 방법이며, 연구 결과 2~4칸 들여쓰기가 가독성 점수를 20~30% 높였어요.
+
+**레이아웃의 일관성**: 특정 레이아웃 스타일의 세부 방식보다 팀 전체가 하나의 스타일을 일관되게 적용하는 것이 가독성과 유지보수성에 더 중요해요.
+
+**좋은 레이아웃의 4 기준**: 코드의 논리 구조를 정확히 표현하고, 그 표현을 일관되게 유지하고, 가독성을 높이며, 코드 수정 시 레이아웃이 쉽게 무너지지 않아야 해요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`"좋은 레이아웃은 코드의 논리 구조를 드러낸다"는 여전히 유효하지만, Prettier와 ESLint가 이 판단을 사람 대신 해주면서 개발자의 역할이 "직접 정렬"에서 "도구 설정 합의"로 이동했어요.`}
@@ -155,6 +171,18 @@ function calcTotal(order?: Order): number {
 
 ## Chapter 32. Self-Documenting Code
 
+### 📖 원문 핵심
+
+**내부 문서화의 주역은 주석이 아니라 코드 스타일**: 좋은 변수명, 루틴명, 명명 상수, 단순한 제어 흐름이 결합된 코드는 주석 없이도 의도를 전달해요. 주석은 가독성 케이크의 아이싱일 뿐, 케이크 본체는 스타일이에요.
+
+**코드를 반복하는 주석은 없는 것보다 나쁘다**: 반복 주석은 읽을 분량만 늘릴 뿐 정보를 추가하지 않고, 잘못된 주석은 코드와 주석 둘 다 틀렸다는 신호가 돼요.
+
+**좋은 주석은 코드보다 높은 추상화 수준에서 의도를 설명한다**: 무엇을(solution)이 아니라 왜를(problem domain) 기술해야 하며, 완성된 코드에 허용되는 주석은 의도 설명, 요약, 코드로 표현 불가한 정보 세 가지뿐이에요.
+
+**주석이 어려우면 코드가 문제다**: 주석 작성이 어렵다는 건 코드를 충분히 이해하지 못했거나 설계가 나쁘다는 신호이므로, 주석 작성 시간은 사실상 코드 이해 시간이에요.
+
+**단락(paragraph) 주석이 핵심 단위다**: 잘 문서화된 코드의 주석 대부분은 코드 단락의 의도를 1~2문장으로 기술하는 형태이며, 이 수준에서 써야 유지 보수도 쉬워요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`"좋은 코드가 최고의 문서다"는 TypeScript의 타입 시스템이 자기 문서화를 언어 레벨에서 강제하면서 더 단단해졌고, 주석의 역할은 "왜(why)"에 집중하는 방향으로 좁혀졌어요.`}
@@ -705,6 +733,18 @@ export function PaymentsWidget({ storeId }: { storeId: string }) {
 
 ## Chapter 33. Personal Character
 
+### 📖 원문 핵심
+
+**지적 겸손(Intellectual Humility)**: 프로그래밍의 핵심은 뇌의 한계를 인정하고 그것을 보완하는 방법을 찾는 것이며, 자신이 얼마나 모르는지 아는 사람이 가장 뛰어난 프로그래머가 될 수 있어요.
+
+**지속적 호기심(Curiosity)**: 기술 환경은 5~10년마다 바뀌기 때문에, 학습을 멈추면 금세 뒤처지게 되고 커리어 내내 배우려는 의지가 있어야 해요.
+
+**지적 정직성(Intellectual Honesty)**: 모르는 것을 아는 척하거나, 실수를 인정하지 않거나, 컴파일러 경고를 무시하는 행동은 전문가로서의 성장을 가로막는 가장 큰 장애물이에요.
+
+**창의성과 규율(Creativity and Discipline)**: 규율과 컨벤션은 창의성을 억누르는 것이 아니라 오히려 중요한 곳에 창의적 에너지를 집중할 수 있게 해주는 도구예요.
+
+**습관의 결정력(Habits)**: 프로그래머로서의 수준은 결국 습관으로 결정되므로, 처음 배울 때부터 올바른 방식으로 익혀야 나중에 그것이 자연스러운 습관으로 자리잡아요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`겸손·호기심·지적 정직성이 좋은 프로그래머의 핵심 자질이라는 주장은 AI 코딩 도구 시대에 오히려 더 중요해졌어요 — AI가 "어떻게"를 대신할수록, "무엇이 맞는지" 판단하는 인간의 성격과 판단력이 병목이 되니까요.`}
@@ -725,6 +765,18 @@ export function PaymentsWidget({ storeId }: { storeId: string }) {
 
 ## Chapter 34. Themes in Software Craftsmanship
 
+### 📖 원문 핵심
+
+**복잡도 정복**: 소프트웨어 설계와 구현의 핵심 목표는 복잡도를 관리하는 것이며, 서브시스템 분리·클래스 추상화·짧은 루틴·명명 규칙 등 이 책의 거의 모든 기법은 복잡도를 줄이기 위한 지적 도구예요.
+
+**추상화의 힘**: 추상화는 복잡도를 다루는 가장 강력한 도구로, 루틴·클래스·패키지 등 추상화 수준을 높일수록 두뇌의 부담이 줄어들어요.
+
+**프로세스의 중요성**: 소프트웨어 품질은 완성된 코드에 덧씌울 수 없으며, 요구사항 정의부터 설계·구현·테스트까지 매 단계에서 의식적으로 좋은 프로세스를 따를 때 비로소 품질이 만들어져요.
+
+**사람을 위한 코드**: 코드는 컴퓨터가 아닌 사람이 읽는 것이며, 가독성은 이해·검토·디버깅·수정·개발 속도 전반에 걸쳐 긍정적 영향을 미치므로 읽기 좋은 코드를 쓰는 것은 선택이 아닌 프로페셔널의 기본이에요.
+
+**교조주의 배격**: 소프트웨어 개발은 결정론적 과정이 아닌 발견적(heuristic) 과정이므로, 단일 방법론을 맹신하면 오히려 최적 해법을 놓치게 되며 다양한 도구를 상황에 맞게 선택하는 절충주의가 고품질 소프트웨어의 전제 조건이에요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`"복잡도 정복", "사람을 위해 먼저 쓰고 컴퓨터를 위해서는 두 번째로", "언어 안에서가 아니라 언어 속으로 프로그래밍하라" — 이 세 테마는 프레임워크와 도구가 아무리 바뀌어도 소프트웨어 구현의 불변 원칙이에요.`}