diff --git a/docs/foundations/1-construction.mdx b/docs/foundations/1-construction.mdx
index c969672..ba51dd7 100644
--- a/docs/foundations/1-construction.mdx
+++ b/docs/foundations/1-construction.mdx
@@ -39,9 +39,9 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ## 📝 묶음 요약
 
-1~4장은 "코딩을 시작하기 전에 무엇을 결정해야 하는가"를 네 각도로 조명하는 묶음이에요. 구현의 정의부터 비유, 사전 준비, 핵심 결정까지 따라가면, 2026년 FE 환경에서 무엇이 살아남고 무엇이 변형됐는지가 자연스럽게 드러나요.
+1~4장은 "코딩을 시작하기 전에 무엇을 결정해야 하는가"를 네 관점에서 바라보는 묶음이에요. 구현의 정의부터 비유, 사전 준비, 핵심 결정까지 따라가면, 2026년 FE 환경에서 무엇이 살아남고 무엇이 변형됐는지 자연스럽게 드러나요.
 
-- 1장 — "construction(구현)"은 AI가 코드를 대신 쓰는 시대에도 반드시 일어나는 활동이라 정의 자체는 유효해요.
+- 1장 — "구현(Construction)"은 AI가 코드를 대신 쓰는 시대에도 반드시 일어나는 활동이라 정의 자체는 유효해요.
 - 2장 — 소프트웨어를 다른 활동에 빗대는 사고법은 살아 있지만, McConnell의 건축·농사 비유는 FE의 반복 배포 환경과 잘 맞지 않아 새 비유가 필요해요.
 - 3장 — "코딩 전 요구사항·아키텍처 점검"은 여전히 중요하지만, "100% 확정 후 시작"이 아니라 "불확실성 큰 부분부터 검증"으로 변형됐어요.
 - 4장 — 언어·컨벤션·프레임워크를 의식적으로 고르라는 원칙은 TypeScript strict, 린터 룰, 프레임워크 선택이 프로젝트 운명을 가르는 FE에서 더 절실해요.
@@ -64,13 +64,13 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 <Verdict
   rating="🟢 생존"
-  rationale={`한 줄 근거: "construction은 소프트웨어 개발에서 유일하게 반드시 수행되는 활동이다"라는 정의는 AI가 코드를 생성하는 2026년에도 변하지 않아요 — 누가 쓰든, construction은 일어나요.`}
+  rationale={`한 줄 근거: "구현(Construction)은 소프트웨어 개발에서 유일하게 반드시 수행되는 활동이다"라는 정의는 AI가 코드를 생성하는 2026년에도 변하지 않아요 — 누가 쓰든, 구현(Construction)은 일어나요.`}
 />
 
 ### ✅ 체크리스트
 
-- [ ] "construction"에 포함되는 활동(상세 설계, 코딩, 디버깅, 단위 테스트, 통합)이 팀 안에서 명확히 인식되고 있나요? "코딩만 construction"이라고 여기고 있지는 않나요?
-- [ ] construction 외 활동(요구사항, 아키텍처, 프로젝트 관리)과의 경계를 팀원이 이해하고 있나요?
+- [ ] "구현(Construction)"에 포함되는 활동(상세 설계, 코딩, 디버깅, 단위 테스트, 통합)이 팀 안에서 명확히 인식되고 있나요? "코딩만 construction"이라고 여기고 있지는 않나요?
+- [ ] 구현(Construction) 외 활동(요구사항, 아키텍처, 프로젝트 관리)과의 경계를 팀원이 이해하고 있나요?
 
 판정과 체크리스트가 정답은 아니에요. 같은 원칙을 뒤집어 보는 관점도 함께 담아둬요.
 
@@ -78,7 +78,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 <DevilsAdvocate
   author={`"Construction의 경계는 이미 흐려졌다"`}
-  argument={`"Construction의 경계는 이미 흐려졌다" — McConnell은 construction을 "상세 설계 + 코딩 + 디버깅 + 단위 테스트"로 정의하고, 요구사항이나 아키텍처와 구분한다. 깔끔한 분류지만, 2026년 FE 현실에서 이 경계는 흐릿하다. 컴포넌트를 만들면서 동시에 디자이너와 요구사항을 조율하고, PR을 올리면서 아키텍처를 바꾸고, 배포하면서 A/B 테스트로 요구사항을 검증한다. 활동들이 순차가 아니라 동시에 일어나는 환경에서, "construction은 여기서 시작하고 여기서 끝난다"는 구분이 실용적인 의미를 가지는지 질문할 수 있다. 오히려 "모든 활동이 construction 안에 녹아 있다"는 관점이 애자일 현실에 더 가까울 수 있다.`}
+  argument={`"Construction의 경계는 이미 흐려졌다" — McConnell은 구현(Construction)을 "상세 설계 + 코딩 + 디버깅 + 단위 테스트"로 정의하고, 요구사항이나 아키텍처와 구분한다. 깔끔한 분류지만, 2026년 FE 현실에서 이 경계는 흐릿하다. 컴포넌트를 만들면서 동시에 디자이너와 요구사항을 조율하고, PR을 올리면서 아키텍처를 바꾸고, 배포하면서 A/B 테스트로 요구사항을 검증한다. 활동들이 순차가 아니라 동시에 일어나는 환경에서, "구현(Construction)은 여기서 시작하고 여기서 끝난다"는 구분이 실용적인 의미를 가지는지 질문할 수 있다. 오히려 "모든 활동이 구현(Construction) 안에 녹아 있다"는 관점이 애자일 현실에 더 가까울 수 있다.`}
 />
 
 ## Chapter 2. Metaphors for a Richer Understanding of Software Development
@@ -87,13 +87,13 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 **메타포는 알고리즘이 아니라 휴리스틱이에요**: 메타포는 답을 찾는 방법을 알려주는 도구이지, 답 자체를 알려주는 지도가 아니에요. 소프트웨어 개발에서 메타포를 쓴다는 건 탐조등처럼 문제를 비춰보는 것이지, 정해진 경로를 따르는 게 아니에요.
 
-**"코드 쓰기(Writing)" 메타포의 한계**: 소프트웨어 개발을 편지 쓰기처럼 보는 관점은 계획 없이 앉아서 쓰고 수정하면 된다고 암시하는데, 이 비유는 소프트웨어의 협업적 성격과 출시 이후 지속되는 유지보수 비용을 설명하지 못해요.
+**"코드 작성" 메타포의 한계**: 소프트웨어 개발을 편지 쓰기처럼 보는 관점은 계획 없이 앉아서 쓰고 수정하면 된다고 암시하는데, 이 비유는 소프트웨어의 협업적 성격과 출시 이후 지속되는 유지보수 비용을 설명하지 못해요.
 
-**시스템 성장(Accretion) 메타포**: 소프트웨어를 굴조개가 진주를 만들듯 작은 단위로 조금씩 쌓아가는 방식으로 보는 관점이에요. McConnell은 이 메타포가 증분 개발의 본질을 가장 정확하게 포착한다고 봤어요.
+**시스템 성장 메타포**: 소프트웨어를 굴조개가 진주를 만들듯 작은 단위로 조금씩 쌓아가는 방식으로 보는 관점이에요. McConnell은 이 메타포가 증분 개발의 본질을 가장 정확하게 포착한다고 봤어요.
 
-**소프트웨어 건축(Building Construction) 메타포**: 규모가 커질수록 계획과 설계의 중요성이 달라진다는 점을 건축 비유로 설명해요. 개집을 짓는 것과 마천루를 짓는 것은 접근 방식 자체가 달라지듯이, 소규모와 대규모 소프트웨어 프로젝트도 필요한 준비의 수준이 근본적으로 다르다고 했어요.
+**소프트웨어 건축 메타포**: 규모가 커질수록 계획과 설계의 중요성이 달라진다는 점을 건축 비유로 설명해요. 개집을 짓는 것과 마천루를 짓는 것은 접근 방식 자체가 달라지듯이, 소규모와 대규모 소프트웨어 프로젝트도 필요한 준비의 수준이 근본적으로 다르다고 했어요.
 
-**지적 도구상자(Intellectual Toolbox) 메타포**: 숙련된 개발자는 단일 방법론에 종속되지 않고 상황에 맞는 기법을 선택할 줄 알아야 한다고 했어요. 어떤 방법론을 100% 따르면 그 방법론의 렌즈로만 세상을 보게 되어 더 나은 선택지를 놓칠 수 있어요.
+**지적 도구상자 메타포**: 숙련된 개발자는 단일 방법론에 종속되지 않고 상황에 맞는 기법을 선택할 줄 알아야 한다고 했어요. 어떤 방법론을 100% 따르면 그 방법론의 렌즈로만 세상을 보게 되어 더 나은 선택지를 놓칠 수 있어요.
 
 <Verdict
   rating="🟡 변형"
@@ -135,7 +135,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 ### ✅ 체크리스트
 
-- [ ] 코딩 시작 전에 "이 기능이 풀려는 문제가 무엇인가?"가 한 문장으로 정의되어 있나요? (problem definition)
+- [ ] 코딩 시작 전에 "이 기능이 풀려는 문제가 무엇인가?"에 대해 한 문장으로 정의되어 있나요? (problem definition)
 - [ ] 요구사항이 변경될 때 변경 비용을 인식하고 있나요? — "나중에 바꾸면 되지"로 넘기지 않고, 변경의 영향 범위를 먼저 파악하나요?
 - [ ] 프로젝트 성격(반복적 vs 순차적)에 맞는 수준의 사전 준비를 하고 있나요? — MVP에 과도한 설계 문서를 쓰거나, 핵심 시스템에 설계 없이 바로 코딩하고 있지는 않나요?
 - [ ] 아키텍처 결정(상태 관리 방식, API 레이어, 렌더링 전략)이 코딩 전에 합의되어 있나요?
@@ -155,7 +155,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 
 **언어 선택이 생산성과 품질에 영향을 준다**: 익숙한 언어로 작업하는 프로그래머는 낯선 언어를 쓰는 경우보다 약 30% 더 생산적이고, 고수준 언어는 저수준 언어 대비 5~15배의 생산성·품질 향상 효과가 있어요.
 
-**언어는 사고를 제약한다**: 프로그래밍 언어가 제공하는 어휘가 개발자가 표현할 수 있는 생각의 범위를 결정하며, 언어에 의해 제약받는 "언어 안에서 프로그래밍"이 아니라 언어를 도구로 쓰는 "언어를 향해 프로그래밍"을 지향해야 해요.
+**언어는 사고를 제약한다**: 프로그래밍 언어가 제공하는 어휘가 개발자가 표현할 수 있는 생각의 범위를 결정하며, 언어에 의해 제약받는 "언어 안에서 프로그래밍"이 아니라 언어를 도구로 쓰는 "언어를 향한 프로그래밍"을 지향해야 해요.
 
 **컨벤션은 구현 시작 전에 확정해야 한다**: 변수명, 클래스명, 루틴명, 포매팅, 주석 등의 코딩 컨벤션은 코드가 작성된 이후에 소급 적용하기가 거의 불가능하기 때문에, 구현에 들어가기 전에 팀 전체가 합의해야 해요.
 
@@ -174,7 +174,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
   - 관련 ESLint: [`@typescript-eslint/no-explicit-any`](https://typescript-eslint.io/rules/no-explicit-any/)
   - 관련 tsconfig: [`strict`](https://www.typescriptlang.org/tsconfig/#strict)
 - [ ] 프레임워크(Next.js, Remix 등)를 의식적으로 선택했나요, 아니면 "다들 쓰니까"로 선택했나요?
-- [ ] "언어 속으로 프로그래밍"하고 있나요? — TypeScript의 타입 시스템, React의 선언적 모델을 적극 활용하나요, 아니면 JavaScript 습관을 TypeScript 위에 얹고 있나요?
+- [ ] "언어 안에서 프로그래밍"하고 있나요? — TypeScript의 타입 시스템, React의 선언적 모델을 적극 활용하나요, 아니면 JavaScript 습관을 TypeScript 위에 얹고 있나요?
 - [ ] 팀의 코딩 컨벤션(네이밍, 파일 구조, import 순서 등)이 합의되어 있고, 자동 검사되나요?
   - 관련 ESLint: [`@typescript-eslint/naming-convention`](https://typescript-eslint.io/rules/naming-convention/)
   - 보조 ESLint: [`import/order`](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/order.md)
@@ -197,7 +197,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 <MemberOpinion
   author="Alice"
   emoji="🐻"
-  opinion={`지금 요구사항을 정확히 해결하면서도 다음 변경에 무너지지 않는 코드를 만드는 것. 미래에 변경사항이 생겼을 때 쉽게 확장할 수 있는 구조를 만들되, 단순히 "확장 가능하게"가 아니라 현재 필요한 만큼만 적절히 추상화하는 균형 감각이 중요함. 설계와 구현은 섞여 있는 활동.
+  opinion={`지금 요구사항을 정확히 해결하면서도 다음 변경에 무너지지 않는 코드를 만드는 것. 미래에 변경사항이 생겼을 때 쉽게 확장할 수 있는 구조를 만들되, 단순히 "확장 가능하게"가 아니라 현재 필요한 만큼만 적절히 추상화하는 균형 감각이 중요함. 설계와 구현은 섞여 있는 활동임.
 
 현업 경험: 어드민 MVP를 만들 때 기획자 없이 직접 기획·설계·구현을 모두 맡았는데, 코드 작성 시간보다 "이 기능이 사용자에게 어떤 흐름으로 보여야 하는가"를 정리하는 시간이 더 길었음.`}
 experience=""