ThinkAboutSoftware · ymkim97 · Jan 6, 2026 · gemini-code-assist · Jan 6, 2026 · TaeHyoungKwon
diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter1_2_3.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter1_2_3.md
@@ -0,0 +1,69 @@
+# 소프트웨어 아키텍처 The Hard Parts
+## 1장 ~ 3장
+---
+## 논의 내용
+* 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 할동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요?
-* 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 할동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요?
+* 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 활동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요?
-* 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 할동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요?
+* 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 활동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요?
+
+## Chapter 1 - ‘베스트 프랙티스’가 없다면?
+
+> *소프트웨어 아키텍처에서는 최고의 설계를 고집하지 마세요. 그 대신에 나쁜 것 중에서 제일 나은(least worst) 트레이드오프 조합을 찾으세요.*
+
+흔히 개발자 사이에서 알려진 “은제 탄환(silver bullet) 같은 건 없다” 와 같이 공감하는 말이다.
+그렇다면 많은 조합과 수를 고려할 때 최선을 선택하는 방법과 그것이 정말 제일 나은 트레이드오프인지 판단할 줄 아는 엔지니어가 되려면 어떻게 해야할지가 나의 고민이다.
+결국은 정말 많은 경험을 해야 될 것 같다는 생각이 들었다.
+
+1.1절에서는 책의 제목에 포함된 “The Hard Parts”의 이유를 간략히 설명해주었다.
+가장 먼저 떠오르는 의미인 어려움(Difficulty)이며, 이는 이전에 그 누구도 경험해보지 못한 난제에 끊임없이 직면해 의사 결정을 내리는 아키텍트의 어려움이다.
+두번째로는 단단함(Solidity)이다. 하드웨어와 소프트웨어를 구분하는 이치와 마찬가지로, 하드한 것은 소프트한 것의 기반이 되므로 쉽사리 바뀌지 않는다는 것이다.
+설명을 읽고나니 그냥 책이 어렵다라는 뜻이 아니라는 것에 덜 걱정된 마음으로 다가갈 수 있게 되었던 것 같다.
+
+소프트웨어 아키텍처 101에서 간간히 나왔던 피트니수 함수에 대해서 다시 한번 생각해 볼 수 있었다.
-소프트웨어 아키텍처 101에서 간간히 나왔던 피트니수 함수에 대해서 다시 한번 생각해 볼 수 있었다.
+소프트웨어 아키텍처 101에서 간간히 나왔던 피트니스 함수에 대해서 다시 한번 생각해 볼 수 있었다.
-소프트웨어 아키텍처 101에서 간간히 나왔던 피트니수 함수에 대해서 다시 한번 생각해 볼 수 있었다.
+소프트웨어 아키텍처 101에서 간간히 나왔던 피트니스 함수에 대해서 다시 한번 생각해 볼 수 있었다.
+결국 팀에는 여러 개발자가 공통의 코드를 작성해 나갈 것이기 때문에, 아키텍트가 의도한대로 아키텍처가 지켜지지 않을 가능성이 아주 크다.
+이에 따라 아키텍처 특성이 예기치 않은 변화에 대비하기 위해 피트니스 함수를 구현한다.
+그렇지 않으면 언젠가는 진흙잡탕 안티패턴처럼 변질될 것이다.
+예전에 ArchUnit에 관한 Spring I/O 2024 영상을 봤던 적이 있어 기억이 났는데, 때마침 책에서도 소개가 되었다.
+
+이번 책에서는 아키텍트로서 난제에 직면하고 현명하게 결정을 내릴 수 있는 목표를 두고 있어 “한빛가이버 사가”라는 가상의 회사를 설정했다.
+이를 통해 다양한 기법과 트레이드오프 기술할 것이라고 하는데, 이런 가상의 예시는 무언가를 이해하는데에 좋고재미있는 방법이라고 생각한다.
-이를 통해 다양한 기법과 트레이드오프 기술할 것이라고 하는데, 이런 가상의 예시는 무언가를 이해하는데에 좋고재미있는 방법이라고 생각한다.
+이를 통해 다양한 기법과 트레이드오프를 기술할 것이라고 하는데, 이런 가상의 예시는 무언가를 이해하는 데에 좋고 재미있는 방법이라고 생각한다.
-이를 통해 다양한 기법과 트레이드오프 기술할 것이라고 하는데, 이런 가상의 예시는 무언가를 이해하는데에 좋고재미있는 방법이라고 생각한다.
+이를 통해 다양한 기법과 트레이드오프를 기술할 것이라고 하는데, 이런 가상의 예시는 무언가를 이해하는 데에 좋고 재미있는 방법이라고 생각한다.
+
+## Chapter 2 - 아키텍처 퀀텀
+
+트레이드오프 분석의 첫 단추는 문제의 차원을 풀어헤치는 것이다.
+어느 부분이 어떻게 서로 얽혀 있고 변경을 하면 얼마만큼의 영향이 있을지 살펴보기 위해 **커플링**이라는 용어를 다음과 같이 간단하게 정의한다.
+
+> *소프트웨어 시스템의 어느 한쪽을 변경하면 다른 쪽도 함께 변경해야 할 경우, 양쪽은 서로 결합된(coupled) 것이다.*
+
+책에서는 현대적인 소프트웨어 아키텍처의 트레이드오프 분석을 위해 다음과 같이 조언한다.
+1. 어느 부분이 서로 얽혀 있는지 찾는다.
+2. 그 부분이 서로 어떻게 결합돼 있는지 분석한다.
+3. 상호 의존적인 시스템에 변경을 가하면 어떤 영향이 있을지 파악해 트레이드오프를 평가한다.
+세 단계로 간단해 보이지만 디테일이 하드 파트다.
+
+이번 챕터에서 **아키텍처 퀀텀**을 이해하는 것이 가장 어려웠다.
+계속 읽다보니 그나마 쉽게 이해할 수 있는 부분은 “아키텍처에서 개별 배포가 가능한 단위”로 생각한다.
+분산 아키텍처에서 아키텍처 퀀텀은 서비스를 적절하게 분해하고자 하는 아키텍트가 고려해야할 힘 (정적 커플링) 중 하나를 나타낸다.
+아키텍처 퀀텀은 높은 기능 응집도, 높은 정적 커플링, 동기적 동적 커플링의 특성을 띤, 독립적으로 배포 가능한 아티팩트다.
+
+마이크로서비스는 이론적으로 각각 자체 퀀텀으로 구성된다. 하지만 이런 시스템도 유저 인터페이스와 단단하게 결합돼 있으면 또다시 단일 아키텍처 퀀텀으로 돌아간다.
+마이크로프론트엔드 프레임워크를 사용해서 유저 인터페이스 요소를 설계하면 대부분 이벤트를 매개로 컴포넌트 간의 느슨하게 결합된 통신을 가능하게 한다.
+
+[대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 1. 마이크로프론트엔드 너 뭐야? | 올리브영 테크블로그](https://oliveyoung.tech/2025-06-29/what-is-MFE-part1/)
+
+이번 챕터와 책 전반적으로 정말 마음에 들었던 부분은 각 챕터의 마지막 절이었다.
+앞서 소개되었던 가상의 회사의 동료들이 이야기를 나누면서 챕터에서 배운 내용을 상기시켜 주며 요약한다.
+이 부분을 통해 다시 한번 생각하고 한층 더 깊게 이해할 수 있어 정말 좋았다.
+
+## Chapter 3 - 아키텍처 모듈성
+
+한빛가이버에서 두 명의 애플리케이션 아키텍트가 기존 모놀리식 애플리케이션을 분산 아키텍처로 마이그레이션하는 타당한 이유를 찾아가는 것이 핵심 내용이다.
+분산 아키텍처로 전환하는 것은 많은 비용이 들기 때문에 합당한 명분이 필요하고, 회사를 설득해야 한다.
+
+아키텍트는 뚜렷한 비즈니스 동인 없이 시스템을 더 잘게 나누면 안된다.
+애플리케이션을 더 작은 부분으로 나누는 주요 비즈니스 동인은 시장 출시 속도와 시장에서의 경쟁 우위 확보다.
+
+가용성(내고장성), 확장성, 배포성, 시험성, 유지 보수성은 오늘날 시장에서 민첩성, 시장 출시 속도, 경쟁 우위를 달성하기  위해 필요한 5대 핵심 아키텍처 특징이다.
-가용성(내고장성), 확장성, 배포성, 시험성, 유지 보수성은 오늘날 시장에서 민첩성, 시장 출시 속도, 경쟁 우위를 달성하기  위해 필요한 5대 핵심 아키텍처 특징이다.
+가용성(내고장성), 확장성, 배포성, 시험성, 유지 보수성은 오늘날 시장에서 민첩성, 시장 출시 속도, 경쟁 우위를 달성하기 위해 필요한 5대 핵심 아키텍처 특징이다.
-가용성(내고장성), 확장성, 배포성, 시험성, 유지 보수성은 오늘날 시장에서 민첩성, 시장 출시 속도, 경쟁 우위를 달성하기  위해 필요한 5대 핵심 아키텍처 특징이다.
+가용성(내고장성), 확장성, 배포성, 시험성, 유지 보수성은 오늘날 시장에서 민첩성, 시장 출시 속도, 경쟁 우위를 달성하기 위해 필요한 5대 핵심 아키텍처 특징이다.
+
+확장성과 탄력성과 같이 헷갈렸던 단어의 의미를 구분할 수 있게 되었다.
+
+이번 장을 통해 아키텍처 모듈화와 분산 아키텍처가 왜 필요하고 어떠한 부분에서 장점을 가지는지 생각해 볼 수 있는 시간을 가질 수 있었다.
+