From 86121894f22e04176087fa9cd8cac06f033823d9 Mon Sep 17 00:00:00 2001
From: tttghost <tttghost@gmail.com>
Date: Mon, 19 Jan 2026 00:48:00 +0900
Subject: [PATCH] upload chapter 4

---
 .../tttghost/chapter 4.md                     | 76 +++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/tttghost/chapter 4.md

diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/tttghost/chapter 4.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/tttghost/chapter 4.md
new file mode 100644
index 00000000..2807c894
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/tttghost/chapter 4.md	
@@ -0,0 +1,76 @@
+# 4장 아키텍처 분해
+## 감상평
+아키텍처 분해에 대해 하나씩 차근히 해결해 나가자는 접근은 비교적 바로 와닿았다.
+하지만 이번 내용을 통해 해결하는 방식에도 분명한 방향성이 존재한다는 점을 알게 되었다.
+무턱대고 아키텍처를 분해했다가는 오히려 진흙잡탕이 돼버리기 일쑤라는
+노건우 팀장님의 말이 특히 크게 와닿았다.
+
+책에서 소개하는 방식은 크게 두 가지다.
+분해가 가능한 경우와, 분해가 불가능한 경우에 따라 접근이 나뉜다.
+분해가 불가능할 때는 구조를 억지로 바꾸기보다는
+로직으로 버티는 전술적 분기 방식을 선택해야 하고,
+분해가 가능하다고 판단될 때는 구조를 개선하여 문제를 해결하는
+컴포넌트 기반 분해 방식을 적용할 수 있다.
+
+책에서 지속적으로 던지는 질문은
+코드베이스가 과연 진흙잡탕인지 아닌지에 대한 것이다.
+이를 판단하기 위해 중요한 기준은
+식별 가능한 컴포넌트 단위의 구조가 존재하는지 여부다.
+만약 이러한 구조를 식별할 수 없다면,
+그 상태에서 분해를 시도하기보다는 전술적 분기를 선택하는 것이
+오히려 더 현명한 선택이 될 수 있다.
+
+진흙잡탕이 된 코드베이스는 처음부터 그런 형태였던 것은 아닐 것이다.
+관리자나 개발자가 소프트웨어 시스템 관리를 소홀히 하면서
+구조가 점점 무너지고, 결국 현재와 같은 상태에 이르게 된다.
+그 결과 책임은 뒤로 미뤄지고, 후임에게 떠넘겨지며
+돌이킬 수 없는 형태의 코드베이스가 만들어진다.
+이러한 상태가 바로 진흙잡탕 코드베이스라고 생각한다.
+
+이런 형태의 코드를 파악할 수 있는 여러 방법 중 하나가
+구심 커플링과 원심 커플링이라는 개념이다.
+구심 커플링은 컴포넌트, 클래스, 함수와 같은 코드 아티팩트로
+들어오는 의존성의 정도를 의미하고,
+원심 커플링은 해당 코드 아티팩트가
+다른 외부 코드 아티팩트로 나가는 의존성의 정도를 나타낸다.
+
+이 중에서 구심 커플링이 강할수록 분해는 훨씬 어려워진다.
+많은 곳에서 해당 코드에 기대고 있기 때문에,
+분해 시 연쇄 수정이 발생할 수밖에 없고
+경계를 재정의하는 비용 역시 커진다.
+결과적으로 여러 코드의 의존성이 함께 흔들리게 된다.
+
+반면 원심 커플링이 강한 영역은 상대적으로 분해가 수월하다.
+외부로 나가는 의존성만 신경 쓰면 되기 때문에
+인터페이스를 도입하고 의존성 역전을 적용함으로써
+아키텍처 분해를 보다 안전하게 시도할 수 있다.
+
+또한 책에서는 추상도와 불안정도라는 수치도 함께 언급한다.
+이 두 수치가 지나치게 높거나, 혹은 지나치게 낮은 영역은
+아키텍처 분해 과정에서 고통스럽거나
+분해하더라도 실질적인 가치가 없는 영역이 된다.
+적절한 메인 시퀀스 거리에 위치한 컴포넌트일수록
+분해와 구조 개선이 용이하다는 점도 인상 깊었다.
+
+전체적으로 이번 내용을 통해 느낀 점은,
+아키텍처 분해는 단순히 구조를 나누는 기술이 아니라
+현재 코드베이스가 구조적 변화를 감당할 수 있는 상태인지
+판단하는 사고 과정이라는 것이다.
+
+## 논의주제
+메인 시퀀스로부터의 수직 거리를 나타낸 그래프가 특히 인상 깊었습니다.
+제 과거를 돌이켜보면, 저는 거의 고통스러운 구역에 머물러 있었던 것 같습니다.
+추상화를 거의 하지 않은 채, 여러 책임을 하나의 메서드에 몰아넣는 방식으로
+개발했던 기억이 납니다.
+
+그때의 코드는 메인 시퀀스에서 꽤 멀리 벗어나 있었던 구조였다는 생각이 듭니다.
+지금은 추상화와 모듈화에 신경을 쓰며 개발하려고 하지만,
+여전히 부족한 부분이 많다고 느끼고 있습니다.
+
+제 개인적인 관점에서는
+고통스러운 구역보다는 차라리 쓸모없는 구역이 조금은 낫지 않을까 하는 생각도 듭니다.
+적어도 추상화에 대한 고민 자체는 있었다는 뜻일 테니까요.
+
+다른 분들은 스스로를 돌아볼 때,
+메인 시퀀스 기준으로 어느 지점쯤에 있다고 느끼시는지 궁금합니다.
+저는 아직 고통스러운 구역의 좌측 상단쯤에 결국 머물러 있는 것 같습니다.
\ No newline at end of file