소프트웨어 아키텍처 The Hard Parts 2주차 - 김영명

2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter4_5.md

@@ -0,0 +1,46 @@
+# 소프트웨어 아키텍처 The Hard Parts
+## 4장 ~ 5장
+---
+## 논의 내용
+* 책에서 나오는 단계처럼 [컴포넌트 도메인을 생성]하고 [도메인 서비스를 생성]한 이후에는 특정 도메인 서비스가 너무 크다고 느껴지는 각자의 기준이 무엇인지 논의해보고 싶습니다. 즉 해당 서비스가 다시 "미니 모놀리스(Mini-monolith)"가 되어가는 것은 아닌지 미리 판단할 수 있는 신호는 무엇일까요?
+
+## Chapter 4 - 아키텍처 분해
+
+모듈화의 명분을 도출한 후, 크고 복잡한 모놀리식 애플리케이션을 나누기 위해서는 아키텍처 분해라는 방법이 필요하다.
+책에서는 “컴포넌트 기반 분해”와 “전술적 분기” 두 가지 분해 전략을 소개한다.
+
+**컴포넌트 기반 분해**
+(애플리케이션의 논리적 구성 요소인) 컴포넌트를 정제/추출한 후 분산 아키텍처를 점진적으로, 제어 가능한 방향으로 구성하면서 다양한 리팩터링 패턴을 적용하는 방법
+
+**전술적 분기**
+먼저 애플리케이션의 레플리카(사본)를 만들고 필요 없는 부분을 하나씩 잘라내며 서비스를 조금씩 완성해 나가는 방법
+
+이 중 어느 방법 하나가 가장 효과적이라고 말할 수는 없고, 기존 모놀리식 애플리케이션 코드가 얼마나 잘 구성돼 있는가에 따라 답이 달라진다.
+
+## Chapter 5 - 컴포넌트 기반 분해 패턴
+
+해당 장을 읽기 전까지 간간히 언급되었던 컴포넌트를 조금이나마 더 이해할 수 있게 되었다.
+여기에 도메인, 서브 도메인, 컴포넌트 간의 차이 및 관계가 어떻게 되는지도 처음으로 깨닫게 되어 정말 재밌게 읽었다.
+컴포넌트 기분 분해는 코드베이스가 체계가 어느 정도 잡혀 있고 네임스페이스(디렉토리)별로 그룹핑돼 있는 모놀리식 애플리케이션을 분리할 때 매우 효과적이다.
+책은 다음과 같은 순서로 점진적으로 분해하는 방법을 소개한다.
+
+* **컴포넌트 식별 및 사이징 패턴**
+  * 컴포넌트 기반 패턴인만큼 컴포넌트를 식별하고 관리하고 적절하게 크기를 정한다.
+* **공통 도메인 컴포넌트 수집**
+  * 애플리케이션 전체에 중복될 가능성이 있는 공통 비즈니스 도메인 로직을 통합해 분산 아키텍처에서 잠재적인 중복 서비스를 줄인다.
+* **컴포넌트 눌러 펴기 패턴**
+  * 도메인, 서브도메인, 컴포넌트를 축소/확장해서 소스 코드 파일을 잘 정의된 컴포넌트 내부에만 둔다.
+* **컴포넌트 디펜던시 결정 패턴**
+  * 컴포넌트 디펜던시를 식별하고 다듬어 모놀리식 아키텍처 -> 분산 아키텍처 마이그레이션의 실현 가능성과 전체 작업량을 결정한다.
+* **컴포넌트 도메인 생성 패턴**
+  * 컴포넌트를 애플리케이션 내부의 논리적인 도메인들로 그룹핑하고 컴포넌트 네임스페이스 및 디렉터리를 특정 도메인에 알맞게 리팩토링 한다.
+* **도메인 서비스 생성 패턴**
+  * 모놀리식 애플리케이션의 논리 도메인을 개별 배포된 도메인 서비스들로 옮겨 모놀리식 아키텍처를 물리적으로 분리한다.
+
+각 패턴당 정의를 알려주고, 관리용 피트니스 함수를 의사코드로 예를 들어주는게 특이했다.
+하지만 피트니스 함수의 의사코드 자체로는 바로 실무에 적용하기는 무리가 있어보이고, 참고해서 툴을 이용하여 구현해낼 수 있을 것 같았다.
+이때 순간적으로 AI를 적극 활용하여 피트니스 함수의 기능을 수행하도록 할 수 있지 않을지 생각났다.
+결국 피트니스 함수는 CI/CD 파이프라인에 포함되므로, AI plugin 등도 함께 추가할 수 있지 않을지 아이디어가 떠올랐다.
+
+이전에는 모놀리식 아키텍처를 분산 아키텍처로의 마이그레이션 과정을 상상해보거나 감을 잡기 어려웠다.
+그러나 이번 장을 통해서 마이그레이션은 그냥 감으로 진행하는 것이 아니라, 구조적으로, 점진적으로, 통제 가능한 방향으로 해야하 한다는 것을 알게 되었고, 컴포넌트 기반 분해 패턴이 핵심 요령이라는 것을 배웠다.