diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md
new file mode 100644
index 00000000..e54a0618
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter13_Contracts.md
@@ -0,0 +1,13 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1641
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1641#issuecomment-4082337757
+
+### 후기
+
+느슨한 계약의 필요성에 의문이 들었습니다. 엄격한 계약을 따르더라도, 예외적인 상황에 대한 처리는 불가피하며, 이것이 단점으로 드러나는 것은 마찬가지라고 생각하기 때문입니다.
+
+컨슈머 주도 계약에서 중간에 큐나 토픽을 생략하여 서비스 간 커플링이 발생하는 점을 언급하고 있는데, 이 내용도 함께 설명해주었다면 더 좋았을 것 같습니다.
diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md
new file mode 100644
index 00000000..bda8d215
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter14_Managing_Analytical_Data.md
@@ -0,0 +1,14 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1643
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1643#issuecomment-4082269164
+
+## 후기 및 DPQ
+
+대용량 운영 데이터 분석의 역사와 함께 현재 분산 환경에서는 어떻게 하는게 좋은지에 대한 내용까지 있다.
+사실 14.2 부터는 모르는 내용이고, 용어도 어렵게 느껴지는 것들이 많아서 전체적으로 어려운 챕터에 속한 것 같다.
+
+DPQ는 별도의 운영 데이터 분석 서비스로 보입니다. DPQ 자체에 도메인 로직과 데이터베이스가 존재하므로, 비즈니스 로직의 주 흐름에서 분리하여 분석용 데이터를 수집하고 처리하는 독립적인 서비스로 구성하려는 의도로 파악됩니다.
diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md
new file mode 100644
index 00000000..33260b4d
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/jongfeel/Chapter15_Build_Your_Own_Trade-Off_Analysis.md
@@ -0,0 +1,24 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1646
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1646#issuecomment-4083228614
+
+## 후기
+
+아키텍트가 된다는 건 우선 소프트웨어 아키텍처가 무엇인지 그리고 상황에 따른 트레이드오프가 무엇인지 파악하고 결정해야 하는 위치라는 걸 다시 이해하게 되었다.
+
+나는 AI로 딸깍해서 개발이 다 되는 시대에도 소프트웨어 아키텍처는 중요한 고려사항 중의 하나로 여기고 싶다.
+분산 트랜잭션으로 만들어줘, 느린 걸 빠르게 개선해줘와 같은 프롬프트는 계속 지시하는 게 잘못된 것이라는 건 금방 알 수 있다.
+바이브 코딩은 내가 원하는 기능을 구현하는 건 문제 없이 할 수 있다.
+기능 구현의 문제를 넘어 아키텍처 결정은 필요에 의해서, 그러니까 상황에 따른 판단과 그 결정을 내리는 것인데 그건 해달라고 해서 할 수 있는 영역이 아니다.
+물론 아는 사람은 그렇게 지시하겠지만, 일반 바이브 코딩의 한계는 이 시점에서 소프트웨어의 품질과 아키텍처 문제 해결 능력에서 드러날 것입니다.
+
+## 논의 주제
+
+개발자가 직접 코딩하지 않아도 되는 AI 바이브 코딩이 가능한 시기에도 소프트웨어 아키텍처는 필요한가? 에 대한 의문입니다.
+
+=> 초기 PoC/프로토타입은 아키텍처가 없어도 되거나 AI가 제시해주는 모놀리스 기반의 통합 백엔드 프론트로 해도 문제는 없을 거라 생각합니다.
+이제 바이브 코딩을 하는 사용자가 소프트웨어 관련 지식을 얼마나 학습하고, 이를 프롬프트로 지시하여 더 나은 결과물을 만들려는 의지를 가졌는지에 따라 차이가 발생할 것입니다. 여기서 개발자가 살아남아야 하는 이유를 찾을 수 있습니다. 개발자의 경쟁력은 단순히 코드를 작성하는 것을 넘어, 서비스를 기획하고 동작하는 소프트웨어를 만드는 능력에서 나옵니다. 더 나아가, 소프트웨어/컴퓨터 공학 지식을 바탕으로 주어진 상황에 최적화된 아키텍처 특성을 갖춘 소프트웨어를 설계하고 구현하는 능력이 핵심 경쟁력이 될 것이라고 생각합니다.