diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter13_14_15.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter13_14_15.md
new file mode 100644
index 00000000..90285005
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter13_14_15.md
@@ -0,0 +1,48 @@
+# 소프트웨어 아키텍처 The Hard Parts
+## 13장 ~ 15장
+---
+## 논의 내용
+* 분석 데이터 관리에 대해서 어떤 방식을 접해보았는지 의논해보고 싶습니다.
+  * 제가 알기로는 현재 회사에서 CDC + BigQuery 형태로 분석 데이터를 관리하고 있는데요, 좀 무거운 쿼리들은 prod reader 보다는 부담없이 해당 기술로 마음껏 볼 수 있어서 꽤 편하다고 느꼈습니다.
+
+## Chapter 13 - 계약
+소프트웨어 아키텍처에서 계약은 통합점 같은 것들을 기술하기 위해 폭넓게 활용된다.
+SOAP, REST, gRPC, XMLRPC 등 다양한 계약 포맷은 소프트웨어의 설계 프로세스 중 하나다.
+때마침 회사에서 스터디로 책 “모던 API 아키텍처 설계 전략”을 읽고 있었고, 그 책에서도 API에 대해서 설명하면서 계약에 관한 내용이 나왔었다.
+따라서 계약이라는 단어가 생소하지 않고 조금 익숙하게 받아들일 수 있었다.
+
+계약도 다양한 방식이 있었고, 대부분의 개발자들에게는 REST가 가장 친숙할 것이다.
+웬만한 서비스에서는 REST로 문제 해결이 가능하기 때문에 REST가 주를 이루는 것이라고 생각한다.
+물론 회사 내에서 때에 따라 몇가지 계약 방식이 함께 사용될 수도 있다.
+엄격한 계약과 느슨한 계약도 아키텍처처럼 트레이드오프가 존재한다.
+엄격한 계약은 계약 충실도 보장, 버저닝, 쉬운 빌드 시점 검증, 우수한 문서화라는 장점이 있는 반면 단단한 커플링과 버저닝이라는 단점이 동시에 발생한다.
+느슨한 계약은 고도의 디커플링, 좋은 발전성이라은 장점과 계약 관리, 피트니스 함수의 필요가 단점이 있다.
+
+책에서 나온 컨슈머 주도 계약은 위에서 언급한 “모던 API 아키텍처 설계 전략”에서도 나오는데, 이에 반대가 되는 생산자 계약에 관한 내용은 나오지 않아서 조금 아쉬웠다.
+생산자 계약과의 트레이드오프도 나왔으면 조금 더 이해가 쉽거나 해당 방식의 언급 이유을 알 수 있었을 것이라고 생각했다.
+
+## Chapter 14 - 분석 데이터 관리
+해당 챕터는 DA, DE 등에게 좀 더 와닿을 수 있는 챕터라고 느껴졌다.
+회사의 경쟁력을 평가할 수 있는 것 중 하나가 데이터이기 때문에 분석 데이터와 운영 데이터가 분리되면서 사용된다.
+책에서 나오는 데이터 웨어하우스, 데이터 레이크, 데이터 메시 방법은 한번씩은 들어봤어도 꽤 생소했다.
+그래도 그나마 회사에서 CDC(debezium)와 BigQuery를 사용하여 분석 데이터를 분리해내는 방식을 채택하고 있어 분석 데이터를 따로 관리하는 방법 중 하나에 대해서 대략적으로만 알고 있다.
+운영 데이터와 관련된 쉽지 않은 트레이드오프는 이 책에서 이미 많은 지면을 할애하여 설명하였고 아키텍처와 꽤 연관이 있었지만, 분석 데이터 관리는 운영 데이터 만큼 나에게 메인으로 생각되지는 않고 새로운 개념이 많아 꽤 어렵게 읽혔다.
+
+## Chapter 15 - 자신만의 트레이드오프 분석
+이번 장은 책을 마무리하면서 다시 한번 책의 전반적인 내용을 요약하듯 조언을 건네는 내용이 보기 좋았다.
+물론 지금 보았을 때는 바로 적용하고 실천하기에는 나의 경험과 연차가 부족하지만, 언젠가는 도움이 될 것 같다는 느낌이 들었다.
+
+2장에서 소개했듯이, 현대 트레이드오프 분석은 다음 3단계를 거친다고 한다.
+* 어느 파트가 서로 관련돼 있는지 확인한다.
+* 어떻게 서로 결합돼 있는지 분석한다.
+* 상호 의존적 시스템의 변경 영향도를 파악함으로써 트레이드오프를 평가한다.
+
+책을 읽으면서 예시로 보았던 아키텍처들은 하나같이 모두 통신, 일관성, 조정이라는 차원의 변화에 민감했다.
+그리고 이 프로세스는 아키텍처에서 반복 설계가 얼마나 중요한지를 잘 나타낸다.
+어떤 워크플로에 대한 샘플 토폴로지를 만들어보고 그 트레이드오프를 메트릭스 형태로 나타내면, 그때그때 임시로 접근하는 방식보다 더 신속하고 철저한 분석이 가능하다고 한다.
+
+각 패턴을 독립적으로 분석한 다음, 그 특성을 비교하는 매트릭스를 작성하면 결합도와 확장성/탄력성은 직접적인 반비례 관계와 같은 흥미로운 사실을 볼 수 있다.
+이러한 분석 기법은 반복 아키텍처링의 좋은 예라고 한다.
+
+또한 트레이드오프를 검토할 때는 반드시 콘텍스트에 따라 의사 결정을 해야한다고 조언한다.
+그렇지 않으면 아키텍트가 애써 수행한 트레이드오프 분석이 외부적 요인의 막대한 영향을 받게 될 것이기 때문이다.