diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter10_11_12.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter10_11_12.md
new file mode 100644
index 00000000..cfa96ee4
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter10_11_12.md
@@ -0,0 +1,59 @@
+# 소프트웨어 아키텍처 The Hard Parts
+## 10장 ~ 12장
+---
+## 논의 내용
+* 보상 트랜잭션 자체가 실패할 수도 있는 가능성은 정말로 무시할 수 없는 수준인가에 대해서 논의해보고 싶습니다. 그대로 적용 할거면 실패에 대한 또다른 예외 처리를 해야하는데 이는 너무 복잡해 질 수도 있다고 생각했습니다(예외를 위한 예외처리). 또한 보상 트랜잭션이 실패했던 경험이 있으면 공유해도 좋을 것 같습니다(실제 사례가 궁금해요!)
+
+## Chapter 10 - 분산 데이터 액세스
+데이터가 분해된 상태에서는 단순 조회조차 쉽지 않다.
+책은 서비스가 자신이 소유하지 않은 데이터를 읽는, 다시 말해 데이터를 필요로 하는 서비스의 경계 콘텍스트 외부에서 읽기 액세스를 획득하는 패턴으로 4가지를 소개한다.
+책에서 나온 패턴으로는 서비스 간 통신 패턴, 컬럼 스키마 복제 패턴, 복제 캐싱 패턴, 데이터 도메인 패턴이 있다.
+
+서비스 간 통신 패턴 같은 경우에는 책에서 말한 것과 같이 가장 일반적이고 흔히 사용되는 패턴인 것 같다.
+회사 내에서도 이 패턴을 가장 많이 사용하는 것이 보이기 때문에 익숙했다.
+대신 레이턴시라는 트레이드 오프가 발생하고, 서비스 커플링 또한 발생하기도 한다.
+
+컬럼 스키마 복제 패턴은 많지는 않지만 쓰이긴 하는 패턴이라 너무 새롭지 않았다.
+비동기 통신으로 데이터 변경을 알리고, 데이터를 빠르게 읽어 갈 수 있다는 장점을 느꼈다.
+
+복제 캐싱 패턴은 조금 새로웠다.
+캐시 자체가 생소하지는 않지만, 이렇게 데이터 액세스 용도로 캐시를 사용하는 부분은 처음 알게 되었고, 꽤 흥미 있게 보았다.
+특히 시작 디펜던시, 데이터양, 데이터 변경 빈도 트레이드오프를 잘 고려하면 사용에는 무리 없어 보였다.
+
+데이터 도메인 패턴은 일반적으로 잘 사용되지 않을 것 같다는 생각이 들었다.
+서비스 기반 아키텍처라면 모르겠지만, 마이크로 서비스가 추구하는 것과는 꽤 거리가 있어보인다.
+
+4가지의 패턴을 읽고 한빛가이버는 어떤 패턴을 사용할지 예상했고, 서비스 간 통신 패턴 또는 복제 캐싱 패턴을 생각했다.
+
+## Chapter 11 - 분산 워크플로 관리
+2장에서 분산 아키텍처는 통신, 일관성, 조정이라는 세 가지 커플링 힘이 서로 영향을 미친다고 했었고, 이번 장에서는 조정에 집중한다.
+분산 아키텍처의 두 가지 기본적인 조정 패턴은 오케스트레이션과 코레오그래피다.
+
+오케스트레이션은 워크플로 중앙화, 에러 처리, 복원성, 상태 관리 면에서는 장점을 보여주지만 응답성, 내고장성, 확장성, 서비스 커플링이라는 단점이 존재한다.
+신기하게도 코레오그래피는 오케스트레이션과 장단점이 뒤바뀌어 있다.
+
+소프트웨어 아키텍처가 다 그렇듯이 오케스트레이션과 코레오그래피 어느쪽도 완벽한 솔루션이 아니다.
+수많은 핵심 트레이드로프를 잘 분석해서 상황에 맞게 둘 중 한가지를 올바르게 선택해야한다.
+
+조금 쉽게 예시를 들자면, 높은 확장성이 필요하고 에러가 발생할 일이 드문 워크플로우는 정교한 에러 처리를 희생하는 대신에 코레오그래피 특유의 높은 확장성을 노려볼 만하다.
+그러나 나중에 워크플로에 포함된 시맨틱 복잡도가 증가할수록 아무래도 오케스트레이터가 있는 편이 더 실용적이다.
+
+## Chapter 12 - 트랜잭셔널 사가
+개인적으로 책에서 가장 궁금하면서도, 어려웠던 챕터였던 것 같다.
+트랜잭션 사가는 구현 방법과 동적 커플링에서 서로 맞물리는 통신, 일관성, 조정이라는 힘의 속성으로 이루어져있다.
+이 속성들은 각각 2 개씩 방식이 있어 2 X 2 X 2 = 8 이라는 경우의 수가 나와 8 개의 패턴이 존재한다.
+그리고 처음에는 외우기 정말 부담스러운 이름들이 각각 있다 (에픽 사가, 앤솔로지 사가 등등).
+
+그러나 이름 자체를 외운다기 보다는, 각각 어떤 속성을 지녔는지 천천히 알아본다면 난이도가 조금 떨어진다.
+통신, 일관성, 조정이 어떤 방식인지 집중하니 비로소 트랜잭셔널 사가의 의미를 알게 되었다.
+
+소프트웨어 아키텍처가 늘 그렇듯이 각각의 장단점이 있었고, 상황에 따라 모두 쓰일 수는 있는 패턴이다.
+다만, 서비스의 특성이나 워크플로의 다양한 케이스들을 잘 고려해야 알맞는 사가를 선택할 수 있는 것 같다.
+
+보상 트랜잭션이라는 단어만 보면, 한번 잘 구축해두면 예외 케이스를 잘 커버한 것으로 착각할 수 있지만 결국 그에 따른 부수 효과가 일어날 수 있다.
+트랜잭션을 되돌려도 그 이전에 업데이트한 데이터에 대해 이미 다른 서비스가 어떤 작업을 수행했을지 알 수 없고, 이게 아니어도 그냥 간단히 되돌릴 수 없는 경우도 있다고 한다.
+심지어 보상 트랜잭션 자체가 실패하는 경우도 있어 후속 조치할 작업들이 서로 뒤엉켜 비일관성과 혼란이 빚어질 수 있다.
+
+트랜잭셔널 사가를 알아가면서 의외로 또 새롭게 배운 것은 문서화가 중요할 수도 있다는 것이었다.
+트랜잭셔널 사가는 일련의 워크플로우이기 때문에 분산 아키텍처에서는 한 곳에 모이지 않을 수도 있다(코레오그래피).
+따라서 state machine 등을 통해 다양한 상태와 액션을 다이어그램으로 나타내고 어디선가는 문서화가 되어 있어야 유지보수 등이 편할 것 같다고 느꼈다.
\ No newline at end of file