diff --git a/docs/foundations/1-construction.mdx b/docs/foundations/1-construction.mdx
index 0f55229..c969672 100644
--- a/docs/foundations/1-construction.mdx
+++ b/docs/foundations/1-construction.mdx
@@ -77,7 +77,7 @@ 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 안에 녹아 있다"는 관점이 애자일 현실에 더 가까울 수 있다.`}
 />
 
@@ -110,7 +110,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 ### 😈 Devil's Advocate
 
 <DevilsAdvocate
-  author="unknown"
+  author={`"비유는 이해를 돕지만, 잘못된 비유는 잘못된 의사결정을 만든다"`}
   argument={`"비유는 이해를 돕지만, 잘못된 비유는 잘못된 의사결정을 만든다" — McConnell은 "건축" 비유를 가장 유용하다고 권하면서, 사전 계획의 중요성을 강조한다. 그런데 이 비유를 FE에 가져오면 위험한 면이 있다. 건축은 한 번 지으면 구조를 바꾸기 극히 어렵지만, 소프트웨어는 리팩터링이 가능하고, 피처 플래그로 실험하고, 롤백이 된다. 건축 비유를 내면화하면 "처음부터 완벽하게 설계해야 한다"는 압박이 생기고, 빠른 실험과 반복을 꺼리게 될 수 있다. FE에 더 맞는 비유는 오히려 "정원 가꾸기"일 수 있다 — 심고, 가지치고, 계절마다 다시 배치하는 지속적인 과정. 비유의 선택이 곧 팀의 개발 문화를 형성한다는 점에서, McConnell의 건축 비유를 무비판적으로 받아들이는 건 주의가 필요하다.`}
 />
 
@@ -145,7 +145,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';
 ### 😈 Devil's Advocate
 
 <DevilsAdvocate
-  author="unknown"
+  author={`"'두 번 재고 한 번 자르라'는 맞지만, FE에서 '재는 비용'은 생각보다 비싸다"`}
   argument={`"'두 번 재고 한 번 자르라'는 맞지만, FE에서 '재는 비용'은 생각보다 비싸다" — McConnell은 요구사항 오류를 나중에 잡을수록 비용이 10~100배 증가한다는 데이터를 제시한다. 인상적인 수치지만, 이 데이터의 출처는 대부분 대규모 워터폴 프로젝트(1970~90년대)다. 2026년 FE에서는 상황이 다를 수 있다. 프로토타입을 하루 만에 만들어 사용자에게 보여주고, 피드백을 받아 다음 날 수정하는 비용이 매우 낮다. 이런 환경에서 "코딩 전에 요구사항을 완벽히 정의하라"는 조언을 문자 그대로 따르면, 문서를 쓰는 데 일주일을 쓰고 정작 프로토타입을 보여줬을 때 "이게 아닌데"가 되는 상황이 벌어진다. 핵심은 "사전 준비의 양"이 아니라 "불확실성이 큰 부분부터 먼저 검증하라"이고, 그 검증 수단이 문서일 수도 있고 프로토타입일 수도 있다.`}
 />
 
@@ -184,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에서 늘 열려 있는 질문이다.`}
 />