diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md
new file mode 100644
index 00000000..d8201c7d
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter1_What_Happens_When_There_Are_No_Best_Practices.md
@@ -0,0 +1,27 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1576
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1576#issuecomment-3705494790
+
+### 1.4 ADR 에서
+
+아키텍처 책이다 보니 ADR이 빠질 수 없는데, 나도 ADR을 실험적으로 몇 개의 문서를 작성해 관리해 봤다.
+확실히 프로젝트 시작 부분에서 ADR 몇 개를 기록해 두니, 프로젝트 중반 이후에 왜? 라는 의문이 어느 정도 해소가 되는 경험을 했었다.
+
+처음엔 ADR에 대해 잘 이해를 못해서 아키텍처 결정이라기 보다는 어떤 기법에 대해 사용해야 하는가 말아야 하는가로 적은 적도 있다.
+예) Singleton 패턴을 사용하지 말아야 하는 이유
+
+하지만 아키텍처의 의사 결정이므로 아키텍처 초반에 결정해야 하는 것들에 대한 걸 적는 건 효과가 있긴 했다.
+예) DI 플러그인에서 Zenject 대신 VContainer를 선택해야 하는 이유
+그래서 결정에 대한 이유를 적다 보니, 나중에 프로젝트 투입한 사람이나 처음부터 아키텍처 작업을 하지 않았던 사람도 왜? 라는 의문을 가질 때쯤 ADR을 살펴보는 건 상당히 유용한 것 같고, 경험상 필요하다고 느껴졌다.
+
+어쩌면 초반 화면 설계 회의나 개발 논의 회의를 할 때 나온 내용을 회의록 처럼 적은 것들이 상당히 많이 있을 텐데
+거기에는 분명 의사결정에 대한 논의가 포함되어 있었을 것이고(팀장이 그냥 하자고 해서 없을 수도 있음)
+그래서 결정을 한 것에 대한 기록을 조금 더 확실하게 파악하고 관리하기 위한 형태가 ADR이라고 이해하는게 좋다고 본다.
+
+## 논의 주제
+
+아마 ADR을 처음 접하거나 들어본 적 없는 분이 많을 텐데, 제 ADR 리뷰에 대해 라이브로 설명해 드리고 혹시 ADR을 작성해 본 분이 있다면 제 경험했던 효과와 다른 효과를 얻었는지에 대해 얘기해 보면 좋겠습니다.
\ No newline at end of file
diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md
new file mode 100644
index 00000000..1ee54670
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter2_Discerning_Coupling_in_Software_Architecture.md
@@ -0,0 +1,14 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1578
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1578#issuecomment-3714443240
+
+### 2.1.3 높은 정적 커플링에서
+
+아키텍처 퀀텀이라는 용어는 이전에 봐왔던 아키텍처 책에서는 보지 못했던 생소한 용어인데
+다 읽고 나서 이해한 건 왜 마이크로서비스가 필요한지를 아키텍처 특성 관점에서 설명할 수 있다는 점이다.
+여태까지 이해한 건 작은 서비스를 만들면 응집도, 결합도 관점에서 설명이 가능했지만 이건 선호해야 하고 피해야 할 기능 관점에서의 설계 목표였지 아키텍처 특성의 레벨 까지는 아니었던 것 같다.
+이제 마이크로서비스가 아키텍처 특성의 관점에서 필요한 이유에 대해 서비스 별 아키텍처 특성인 확장성, 보안 등을 별도 적용 범위를 가질 수 있다는 점에서 좋다고 얘기할 수 있게 됐다.
diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter3_Architectural_Modularity.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter3_Architectural_Modularity.md
new file mode 100644
index 00000000..59cc294b
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter3_Architectural_Modularity.md
@@ -0,0 +1,14 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1579
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1579#issuecomment-3718371662
+
+### 3.1.2 시험성에서
+
+서비스 별로 테스트 코드가 독립적이어야 하는 건 상식적이긴 한데
+책의 설명대로라면 서비스가 동적 연결 그러니까 2장에서 설명한 아키텍처 퀀텀의 통신에 있어서 커플링이 일어난다면 시험성이 떨어지는 건 막을 수 없다고 본다.
+이런 상황일 때 내가 생각한 대안은 각 서비스 별로 다른 서비스에 의존적인 부분이 꼭 필요하다면 그 서비스의 mock을 만드는 것도 좋은 방법이라고 본다.
+책의 그림에서는 서비스 B, C의 mock 2개를 만들어야 하는데 보통은 이상적인 커플링의 대상은 1개 이므로 커플링이 만들어지는 서비스의 mock을 만들면 시험성이 좋아질 것이라고 본다.
\ No newline at end of file