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

@@ -1,7 +1,7 @@
 # 7장
 
 - 논의주제
-    - 적절한 세분도를 측정하기 위해서 책에서는 정량적 분석이 가능한 인터페이스의 개수나 기준의 수를 언급하고 있습니다. 저는 현실과 동 떨어진 방법이라고 생각하고, 오히려 비즈니스 임팩트나, 장애 상황에서 격리가 되어야하는지 여부가 세분도 측정에도 포함이 되어야 한다고 생각하는데, 적절한 세분도 측정 방법에 대해서 논의해보면 좋을거 같습니다
+    - 적절한 세분도를 측정하기 위해서 책에서는 정량적 분석이 가능한 인터페이스의 개수나 기준의 수를 언급하고 있습니다. 저는 현실과 동떨어진 방법이라고 생각하고, 오히려 비즈니스 임팩트나, 장애 상황에서 격리가 되어야하는지 여부가 세분도 측정에도 포함이 되어야 한다고 생각하는데, 적절한 세분도 측정 방법에 대해서 논의해보면 좋을 것 같습니다
         - 내 의견
             - 퍼블릭 인터페이스나 기능 수를 기준으로 서비스 세분도 값 자체를 측정하는 것은 크기를 짐작할 수 있다는 점에서는 유용할 수 있지만, 중요도의 측면에서는 판단할 수 없다고 생각된다. 세분도를 통해서 마이크로서비스의 크기를 판단할 때는, 단순히 코드에서 제공하고 있는 인터페이스의 양적인 측면이 아니라, 비즈니스 임팩트 기준으로 임팩트가 큰지, 장애 상황에서 격리가 되어야하는지 기준을 고려하는 것도 중요할것 같다.
             - 만약 책에서 말한대로 세분도를 측정하게 된다면, 마땅히 해당 서비스에서 개발해야할 API 인데도 불구하고, 기존에 이미 세분도가 크기 때문에(제공하는 인터페이스와 기능이 많음) 개발을 거부할 수 있는 명분이 되기 때문이다