feat: 전 챕터 원문 핵심 섹션 추가 + 히어로 개선

.gitignore

@@ -26,3 +26,5 @@ yarn-error.log*
 # 로컬 실행 플랜 (실행 안내서, PR 본문에 녹임)
 # docs/ 밖으로 분리 — docs/ 안에 두면 autogenerated 사이드바에 노출됨 (로컬 dev 오염)
 /plans/
+/docs/plans/
+/docs/brainstorms/

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은 일어나요.`}
@@ -67,6 +83,18 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## 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 테스트)과 거리가 생겨서 새로운 비유가 필요해요.`}
@@ -88,6 +116,18 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## Chapter 3. Measure Twice, Cut Once: Upstream Prerequisites
 
+### 📖 원문 핵심
+
+**사전 준비의 비용 효과**: 결함을 발견하는 시점이 늦어질수록 수정 비용이 급격히 올라가요. 요구사항 단계에서 발견한 결함을 릴리스 후에 수정하면 10~100배 더 비싸기 때문에, 구현 전에 요구사항과 아키텍처를 검토하는 것이 경제적으로 정당해요.
+
+**문제 정의 우선**: 구현을 시작하기 전 첫 번째 선행 조건은 시스템이 해결해야 할 문제를 명확히 서술하는 거예요. 문제 정의는 해결책이 아닌 사용자 언어로 작성해야 하며, 정의가 없으면 올바른 방법으로 잘못된 문제를 풀게 되는 이중 손실이 발생해요.
+
+**명시적 요구사항의 역할**: 공식 요구사항을 작성해두면 시스템 기능을 프로그래머가 아닌 사용자가 주도하게 되고, 구현 도중 발생하는 범위 분쟁을 문서로 해소할 수 있어요. 요구사항 변경은 코딩 중 발견 시 설계를 다시 짜야 하므로 평균 프로젝트에서 재작업의 70~85%를 차지해요.
+
+**아키텍처의 개념 무결성**: 소프트웨어 아키텍처는 시스템의 개념적 무결성을 결정하고, 이것이 결국 제품 품질을 결정해요. 좋은 아키텍처는 상위 레벨부터 하위 레벨까지 일관된 구조를 제공하며, 나쁜 아키텍처는 구현을 거의 불가능하게 만들어요.
+
+**아키텍처 컴포넌트의 책임 분리**: 아키텍처에서 각 빌딩 블록은 하나의 책임 영역을 가져야 하고, 다른 블록의 책임에 대해 최대한 적게 알아야 해요. 두 개 이상의 블록이 동일한 기능을 담당하면 협력이 아닌 충돌이 발생하기 때문에 기능별 소유권을 명확히 정의해야 해요.
+
 <Verdict
   rating="🟡 변형"
   rationale={`한 줄 근거: "요구사항과 아키텍처를 코딩 전에 확인하라"는 원칙은 유효하지만, 2026년 애자일/반복 배포 환경에서는 "100% 확정 후 시작"이 아니라 "핵심 불확실성부터 검증하고, 나머지는 반복하며 발견"하는 형태로 변형됐어요.`}
@@ -111,6 +151,18 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## Chapter 4. Key Construction Decisions
 
+### 📖 원문 핵심
+
+**언어 선택이 생산성과 품질에 영향을 준다**: 익숙한 언어로 작업하는 프로그래머는 낯선 언어를 쓰는 경우보다 약 30% 더 생산적이고, 고수준 언어는 저수준 언어 대비 5~15배의 생산성·품질 향상 효과가 있어요.
+
+**언어는 사고를 제약한다**: 프로그래밍 언어가 제공하는 어휘가 개발자가 표현할 수 있는 생각의 범위를 결정하며, 언어에 의해 제약받는 "언어 안에서 프로그래밍"이 아니라 언어를 도구로 쓰는 "언어를 향해 프로그래밍"을 지향해야 해요.
+
+**컨벤션은 구현 시작 전에 확정해야 한다**: 변수명, 클래스명, 루틴명, 포매팅, 주석 등의 코딩 컨벤션은 코드가 작성된 이후에 소급 적용하기가 거의 불가능하기 때문에, 구현에 들어가기 전에 팀 전체가 합의해야 해요.
+
+**기술 파동(Technology Wave)의 위치가 개발 방식을 결정한다**: 성숙한 기술 환경(late wave)에서는 안정적인 도구와 문서를 활용해 기능 구현에 집중할 수 있지만, 초기 기술 환경(early wave)에서는 미문서화된 언어 특성이나 도구 버그에 상당한 시간을 써야 하므로 기대치를 그에 맞게 조정해야 해요.
+
+**주요 구현 관행은 사전에 의식적으로 선택해야 한다**: 코딩 컨벤션, 페어 프로그래밍 여부, 테스트 작성 시점, 코드 리뷰 방식, 툴체인 등의 구현 관행은 프로젝트 성격에 맞게 미리 결정해야 하며, 단순히 기본값을 따르는 것은 선택이 아니에요.
+
 <Verdict
   rating="🟢 생존"
   rationale={`한 줄 근거: "코딩 시작 전에 언어·컨벤션·주요 실천법을 의식적으로 선택하라", "언어 안에서가 아니라 언어 속으로 프로그래밍하라"는 원칙은 TypeScript strict 설정, 린터 룰, 프레임워크 선택이 프로젝트 운명을 좌우하는 FE에서 더 절실해요.`}
@@ -220,10 +272,3 @@ experience=""
 />
 
 의견은 저마다 다르지만, 네 장이 한 흐름으로 이어진다는 감각은 공유돼요.
-
-:::note 생략된 섹션
-
-- **VotingBar**: 스터디원 투표 미작성 (votes 전원 null)
-- **BestPickCallout**: 베스트 토론 미선정 (content·reason 모두 null)
-
-:::

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로 번역되어야 유효해요.`}
@@ -571,10 +597,3 @@ export function formatDocTitle(title: string, maxLen: number): string {
 />
 
 의견은 저마다 다르지만, 두 장이 한 흐름으로 이어진다는 감각은 공유돼요.
-
-:::note 생략된 섹션
-
-- **VotingBar**: 스터디원 투표 미작성 (votes 전원 null)
-- **BestPickCallout**: 베스트 토론 미선정 (content·reason 모두 null)
-
-:::