From 3635e208147faaa7f48b42f1c917c27f2efc8ec3 Mon Sep 17 00:00:00 2001 From: ymkim97 Date: Tue, 6 Jan 2026 23:57:27 +0900 Subject: [PATCH] chapter 1,2,3 --- .../ymkim97/chapter1_2_3.md | 69 +++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter1_2_3.md 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 new file mode 100644 index 00000000..460fd9d3 --- /dev/null +++ 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에서 간간히 나왔던 피트니수 함수에 대해서 다시 한번 생각해 볼 수 있었다. +결국 팀에는 여러 개발자가 공통의 코드를 작성해 나갈 것이기 때문에, 아키텍트가 의도한대로 아키텍처가 지켜지지 않을 가능성이 아주 크다. +이에 따라 아키텍처 특성이 예기치 않은 변화에 대비하기 위해 피트니스 함수를 구현한다. +그렇지 않으면 언젠가는 진흙잡탕 안티패턴처럼 변질될 것이다. +예전에 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대 핵심 아키텍처 특징이다. + +확장성과 탄력성과 같이 헷갈렸던 단어의 의미를 구분할 수 있게 되었다. + +이번 장을 통해 아키텍처 모듈화와 분산 아키텍처가 왜 필요하고 어떠한 부분에서 장점을 가지는지 생각해 볼 수 있는 시간을 가질 수 있었다. +