diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/geunju-lee/Chapter_4_to_5.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/geunju-lee/Chapter_4_to_5.md
new file mode 100644
index 00000000..dd43dd06
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/geunju-lee/Chapter_4_to_5.md
@@ -0,0 +1,56 @@
+# 트레이드오프 위에서의 아키텍처 선택
+
+## 4 ~5장
+---
+
+## chapter 4 - 아키텍처 분해
+
+> 분해가능 여부 및 분해 방법
+
+분해를 할 때 가장 중요한 것은 장애가 나지 않고, 기존과 얼마나 똑같이 잘 작동하도록 하느냐이다.
+현재는 기존 어플리케이션을 복제하여 다시 개발하는 것을 하고 있다.
+다른 분야는 어떨지 모르지만 이정도로 개발하는 정도라면 새로운 프로젝트를 아예 개발하는게 낫지 않을까 라는 생각이든다.
+BE 개발자인 나로써는 api 단위로 새로운 프로젝트에 개발하여 새로운 버전의 api를 타 팀에게 전달할 것이다.
+
+그래도 책의 방식을 보면 프로젝트를 복사하고 리팩토링하며 개선한다.
+
+## chapter 5 - 컴포넌트 기반 분해 패턴
+
+> 컴포넌트 기반 분해 흐름
+
+컴포넌트 기반으로 분해할 때, 어떤 흐름대로 가는지를 말 해주고 있다.
+JAVA, Kotlin 개발자인 나로서는 package name에 대해 어떻게 할지 고민이 참 많을 때가 있다.
+심지어 특정 service들을 package별로 나누다 보면 결국 1개의 package 안에 1개의 service만 들어있을 때가 종종 있어서
+이게 맞나? 싶을 때도 있다.
+
+그렇지만 이 책에서는 "어떤 컴포넌트도 전체의 몇% 이상을 차지해선 안 된다고 한다"라는 말을 보고 코드 정리를 좀 해보기로 했다.
+또한 컴포넌트 눌러 펴기 패턴을 통해 기존에 정리 되지 않은 코드를 정리해봐야겠다고 느꼈다.
+
+컴포넌트 도메인 생성 패턴 관련해서는 책을 읽었지만 솔직히 와닿지 않는다. 예를 들면 이 책에서는 "과금 결제"를 "ss.customer.billing.payment"로 되어있는데, 만약 자동결제 혹은 정기결제가
+있다면 이건 "ss.customer.billing.auto.pay" 이런 식이 될 것이고, b2c를 하는 회사라면 거의 대부분의 것이 customer 하위에 있을 것이다(최근 결제 수단, 적립, 포인트 충전, 영수증
+발급 등등).
+따라서 이것 또한 정답이 없는 것 같다. 얼마나 공통된 부분을 잘 찾느냐가 관건인 것으로 보인다(티켓 관련은 ss.ticket에 있지만 티켓 리포팅은 리포팅 도메인에 속하여 ss.reporting.tickets로
+한다).
+
+결국 도메인으로 나누는 만큼 그만큼을 떼내어 완전 코드 분리하면 된다. 그리고 이 방법이 내가 지금까지 감으로 해온 방법보다는 전략적으로 잘 나누는거 같아 좋아보인다.
+
+### 정리
+
+컴포넌트를 어떻게 잘 전략적으로 나눌 것인가에 대한 내용이다. 정답은 없지만 감보다는 전략적으로 분석하여 나누라는 것이 요지인것으로 보인다.
+
+### 논의사항
+
+1. 결국 DB 분리까지 하는 MSA가 목표라면 굳이 이렇게 나눠야하는가? api 단위로 새로 app 띄우는게 빠르지 않을까?
+
+- 나는 새로운 app을 서버에 띄우고, 해당 테이블에 관련된 api를 만들어서 기존 모놀리식에서 해당 테이블을 보는 것이 아니라 신규 api를 보고 기존 모놀리식 코드에서 해당 테이블 보는 코드가 완전 없어졌다면,
+  따로 DB를 분리하는 식이 더 좋지 않을까 라는 생각이 든다.
+
+> 아래 내용은 정리나 결론을 위한 글은 아니다.  
+> 혹시 비슷한 규모의 시스템을 운영하면서  
+> 다른 팀은 어떻게 하고 있는지 궁금한 사람이 있다면,  
+> 참고가 될 수 있을 것 같아 남겨둔 개인적인 경험 기록이다.
+
+### 경험 사례
+
+분해를 하다보면 리팩토링 해야할 것이 보이고, 리팩토링은 욕심이 문제다. 리팩토링을 하다보면 고치고 싶은 것이 눈에 계속 보이고, 그것들 중 적당량만 수정한 후, 배포하는 식으로 하며 오류를 잡아야한다. 욕심이 생겨서 계속 수정을 하며 한번에 배포하는 순간,
+장애는 시작된다. 누군가는 잦은 배포가 잦은 장애를 만든다고 하지만, 난 그렇게 잘게 쪼개서 나가는 것이 경험상 더 안정적이라 생각한다.
\ No newline at end of file