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

2026/Fundamentals_of_Software_Architecture_2nd_Edition/kimdokyung/Chapter4_5.md

@@ -0,0 +1,37 @@
+# Chapter 04: 아키텍처 분해
+
+솔직히 이번 챕터는 페이지를 넘길 때마다 쉽지 않았다. 내용 자체가 어렵다기보다는, "이론을 이해하는 것"이 아니라 "실제로 적용할 수 있는 판단을 요구하는 내용"이라서 읽는 내내 머리를 계속 쓰게 됐다.
+
+이번 챕터는 아키텍처 분해를 시작하기 전에 먼저 "분해가 가능한 상태인지"를 판단해야 한다는 점을 강조한다. 분해를 잘하는 방법보다, 지금 코드베이스가 분해를 감당할 수 있는 구조인지 확인하는 게 중요하다고 느꼈다.
+
+책에서는 분해 방법을 크게 두 가지로 설명한다.
+
+- 컴포넌트 기반 분해: 기존 코드에서 컴포넌트 단위를 식별할 수 있는 경우
+- 전술적 분기: 코드가 너무 얽혀 있어서 구조적으로 분해하기 어려운 경우
+
+전술적 분기는 이상적인 아키텍처 방식이라기보다 현실적인 방법으로 보였다. 구조를 완전히 정리해서 분해하는 게 힘든 상황이라면, 먼저 경계를 나누고 각 영역에서 불필요한 것을 제거하면서 점진적으로 나아가는 선택지가 될 수 있다는 점이 인상 깊었다.
+
+구심/원심 커플링, 추상도/불안정도 같은 지표는 "분해 결정을 감으로 하지 말고" 근거를 가지고 판단해보라는 의도라고 이해했다. 다만 실제 코드에서는 추상화가 항상 클래스/인터페이스로 드러나는 게 아니라서, 이런 지표가 실무에서 얼마나 직관적으로 적용될지는 의문이 들었다.
+
+실시간 협업처럼 상태 동기화가 핵심인 시스템에서는 분해가 특히 조심스러운 작업이라고 생각한다. 분해하면 구조는 깔끔해질 수 있지만 네트워크 호출 증가, 디버깅 난이도 상승, 성능 문제로 이어질 수 있기 때문이다. 그래서 분해는 "정리"라기보다 운영과 복잡도까지 포함한 선택이라는 느낌을 받았다.
+
+⸻
+
+# Chapter 05: 컴포넌트 기반 분해 패턴
+
+이 챕터도 쉽게 읽히는 내용은 아니었다. 특히 "패턴"이라고 해서 단순히 읽고 넘길 수 있는 게 아니라, 단계별로 실제로 구조가 바뀌는 과정을 상상해야 해서 나에겐 한장한장 집중력이 꽤 필요했다.
+
+이번 챕터는 컴포넌트 기반 분해를 실제로 진행하는 과정을 6단계 패턴으로 설명한다. 1. 컴포넌트 식별 및 사이징 2. 공통 도메인 컴포넌트 수집 3. 컴포넌트 눌러펴기 4. 컴포넌트 디펜던시 결정 5. 컴포넌트 도메인 생성 6. 도메인 서비스 생성
+
+전체적으로 느낀 건 서비스 분해는 끝단의 단계라는 점이다. 처음부터 서비스를 나누는 것보다 먼저 컴포넌트 단위로 경계를 잡고, 의존성을 정리하고, 도메인 단위로 묶는 과정이 필요하다고 이해했다.
+
+특히 사이징 단계는 실무적으로 적용하기 쉬워 보였다. 파일 수나 문장 수 같은 기준으로 너무 큰 컴포넌트를 찾고 나누는 방식은 프론트/백엔드 모두 적용 가능하다고 생각했다.
+
+공통 컴포넌트 수집은 장점과 위험이 같이 있다고 느꼈다. 공통화를 하면 중복 제거와 속도 측면에서 이득이 있지만, 시간이 지나면 공통 모듈에 의존이 몰리고 결합도가 커지는 문제가 생길 수 있다. 공통화를 어디까지 허용할지 기준을 세우는 게 중요해 보였다.
+
+⸻
+
+# 논의 주제
+
+초기 프로젝트에서 "아직 분해하지 말자"고 판단하는 기준은 뭘까?
+아직 규모가 작은 프로젝트에서는 어느 시점에 "이제 분해를 고민해야겠다"고 느끼는지 궁금하다.