Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/7.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Author: TaeHyoungKwon

2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/7.md

@@ -20,5 +20,5 @@
     - 서비스 세분도는 서비스가 무엇을 하느냐에 따라 달라지기 때문에, 이상적인 마이크로 서비스 설계라면, 마이크로서비스가 최대한 한가지 책임만 가지도록 설계하는 경우가 많은데, 이런 경우에 현실세계에서 가장 큰 문제는 마이크로서비스 유지보수 비용이 너무 많이 든다는 점이다. 그래서 마이크로서비스 설계 시에는 반드시 유지보수 비용까지 고려해서 설계해야한다고 생각한다
     - 세분도의 분해인도 데이터 분해인과 마찬가지로, 분해하거나 통합해야하는 명분은 변경에 의한 장애 발생 시, 격리 가능한가? 의 기준에서 생각해볼 수 있다
     - 마찬가지로 통합인도 동일한 맥락에서 생각할 수 있는데, 통합했을 때, 훨씬 더 작업처리에 유리하고, 분해했을 때, 더 고려해야할 것인 많을 때(분산 트랜잭션으로 인한 데이터 정합성 문제)는 차라리 통합하는게 낫다는 것이다
-    - 책에서 나오는 많은 분해인, 통합인도 매우 도움이 되는 것들이라고 생각되는데, 각각을 다 이해하고 활용할 수 없다면, 어떤게 쉬운방법일까? 를 생각해보는게 좋을것 같다. 쉽게 풀 수 있는 방법이 있는데, 굳이 어려운 방법을 할 필욘 없기 때문이고, 이 쉬운 방법을 고민하다가 보면, 자연스럽게 책에서 말하는 분해인과 통합인이 나올 것 같다는 생각이다
+    - 책에서 나오는 많은 분해인, 통합인도 매우 도움이 되는 것들이라고 생각되는데, 각각을 다 이해하고 활용할 수 없다면, 어떤 게 쉬운 방법일까? 를 생각해보는게 좋을것 같다. 쉽게 풀 수 있는 방법이 있는데, 굳이 어려운 방법을 할 필요는 없기 때문이고, 이 쉬운 방법을 고민하다가 보면, 자연스럽게 책에서 말하는 분해인과 통합인이 나올 것 같다는 생각이다
     - 맨마지막에 고객등록 세분도 사례의 경우는 애초에 고객 정보는 한 트랜잭션에 보장되어야하는 니즈가 강했기 때문에, 아키텍쳐도 그렇게 결정이 된거라고 봐야할거 같다. 다만 현실세계에서는 트랜잭션을 보장 못하게 설계할 수밖에 없는 상황도 있기 때문에, 정답이라고 보기 보다는 해당 사례에서 의도에 맞게 잘 설계된 걸로 봐야할것 같다