-
Notifications
You must be signed in to change notification settings - Fork 5
소프트웨어 아키텍처 The Hard Parts 2주차 - 김지수 #589
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
tttghost
wants to merge
1
commit into
main
Choose a base branch
from
tttghost/Software-Architecture--The-Hard-Parts-chapter4-5
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
76 changes: 76 additions & 0 deletions
76
2026/Fundamentals_of_Software_Architecture_2nd_Edition/tttghost/chapter 4.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,76 @@ | ||
| # 4장 아키텍처 분해 | ||
| ## 감상평 | ||
| 아키텍처 분해에 대해 하나씩 차근히 해결해 나가자는 접근은 비교적 바로 와닿았다. | ||
| 하지만 이번 내용을 통해 해결하는 방식에도 분명한 방향성이 존재한다는 점을 알게 되었다. | ||
| 무턱대고 아키텍처를 분해했다가는 오히려 진흙잡탕이 돼버리기 일쑤라는 | ||
| 노건우 팀장님의 말이 특히 크게 와닿았다. | ||
|
|
||
| 책에서 소개하는 방식은 크게 두 가지다. | ||
| 분해가 가능한 경우와, 분해가 불가능한 경우에 따라 접근이 나뉜다. | ||
| 분해가 불가능할 때는 구조를 억지로 바꾸기보다는 | ||
| 로직으로 버티는 전술적 분기 방식을 선택해야 하고, | ||
| 분해가 가능하다고 판단될 때는 구조를 개선하여 문제를 해결하는 | ||
| 컴포넌트 기반 분해 방식을 적용할 수 있다. | ||
|
|
||
| 책에서 지속적으로 던지는 질문은 | ||
| 코드베이스가 과연 진흙잡탕인지 아닌지에 대한 것이다. | ||
| 이를 판단하기 위해 중요한 기준은 | ||
| 식별 가능한 컴포넌트 단위의 구조가 존재하는지 여부다. | ||
| 만약 이러한 구조를 식별할 수 없다면, | ||
| 그 상태에서 분해를 시도하기보다는 전술적 분기를 선택하는 것이 | ||
| 오히려 더 현명한 선택이 될 수 있다. | ||
|
|
||
| 진흙잡탕이 된 코드베이스는 처음부터 그런 형태였던 것은 아닐 것이다. | ||
| 관리자나 개발자가 소프트웨어 시스템 관리를 소홀히 하면서 | ||
| 구조가 점점 무너지고, 결국 현재와 같은 상태에 이르게 된다. | ||
| 그 결과 책임은 뒤로 미뤄지고, 후임에게 떠넘겨지며 | ||
| 돌이킬 수 없는 형태의 코드베이스가 만들어진다. | ||
| 이러한 상태가 바로 진흙잡탕 코드베이스라고 생각한다. | ||
|
|
||
| 이런 형태의 코드를 파악할 수 있는 여러 방법 중 하나가 | ||
| 구심 커플링과 원심 커플링이라는 개념이다. | ||
| 구심 커플링은 컴포넌트, 클래스, 함수와 같은 코드 아티팩트로 | ||
| 들어오는 의존성의 정도를 의미하고, | ||
| 원심 커플링은 해당 코드 아티팩트가 | ||
| 다른 외부 코드 아티팩트로 나가는 의존성의 정도를 나타낸다. | ||
|
|
||
| 이 중에서 구심 커플링이 강할수록 분해는 훨씬 어려워진다. | ||
| 많은 곳에서 해당 코드에 기대고 있기 때문에, | ||
| 분해 시 연쇄 수정이 발생할 수밖에 없고 | ||
| 경계를 재정의하는 비용 역시 커진다. | ||
| 결과적으로 여러 코드의 의존성이 함께 흔들리게 된다. | ||
|
|
||
| 반면 원심 커플링이 강한 영역은 상대적으로 분해가 수월하다. | ||
| 외부로 나가는 의존성만 신경 쓰면 되기 때문에 | ||
| 인터페이스를 도입하고 의존성 역전을 적용함으로써 | ||
| 아키텍처 분해를 보다 안전하게 시도할 수 있다. | ||
|
|
||
| 또한 책에서는 추상도와 불안정도라는 수치도 함께 언급한다. | ||
| 이 두 수치가 지나치게 높거나, 혹은 지나치게 낮은 영역은 | ||
| 아키텍처 분해 과정에서 고통스럽거나 | ||
| 분해하더라도 실질적인 가치가 없는 영역이 된다. | ||
| 적절한 메인 시퀀스 거리에 위치한 컴포넌트일수록 | ||
| 분해와 구조 개선이 용이하다는 점도 인상 깊었다. | ||
|
|
||
| 전체적으로 이번 내용을 통해 느낀 점은, | ||
| 아키텍처 분해는 단순히 구조를 나누는 기술이 아니라 | ||
| 현재 코드베이스가 구조적 변화를 감당할 수 있는 상태인지 | ||
| 판단하는 사고 과정이라는 것이다. | ||
|
|
||
| ## 논의주제 | ||
| 메인 시퀀스로부터의 수직 거리를 나타낸 그래프가 특히 인상 깊었습니다. | ||
| 제 과거를 돌이켜보면, 저는 거의 고통스러운 구역에 머물러 있었던 것 같습니다. | ||
| 추상화를 거의 하지 않은 채, 여러 책임을 하나의 메서드에 몰아넣는 방식으로 | ||
| 개발했던 기억이 납니다. | ||
|
|
||
| 그때의 코드는 메인 시퀀스에서 꽤 멀리 벗어나 있었던 구조였다는 생각이 듭니다. | ||
| 지금은 추상화와 모듈화에 신경을 쓰며 개발하려고 하지만, | ||
| 여전히 부족한 부분이 많다고 느끼고 있습니다. | ||
|
|
||
| 제 개인적인 관점에서는 | ||
| 고통스러운 구역보다는 차라리 쓸모없는 구역이 조금은 낫지 않을까 하는 생각도 듭니다. | ||
| 적어도 추상화에 대한 고민 자체는 있었다는 뜻일 테니까요. | ||
|
|
||
| 다른 분들은 스스로를 돌아볼 때, | ||
| 메인 시퀀스 기준으로 어느 지점쯤에 있다고 느끼시는지 궁금합니다. | ||
| 저는 아직 고통스러운 구역의 좌측 상단쯤에 결국 머물러 있는 것 같습니다. | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
좋은 내용 정리와 논의 주제 감사합니다. 마지막 문장에 대해 작은 의견을 드립니다.
'메인 시퀀스' 그래프에서 '고통의 구역(Zone of Pain)'은 추상도와 불안정도가 모두 낮은 좌측 하단 (A≈0, I≈0)에 위치합니다. 앞서 '추상화를 거의 하지 않은' 코드를 이 구역에 빗대어 설명하신 부분은 매우 적절했습니다.
다만 마지막 문장에서 '고통스러운 구역의 좌측 상단'에 머물러 있다고 표현하셨는데, '좌측 상단'은 추상도는 높고(A≈1) 불안정도는 낮은(I≈0) 이상적인 구역에 해당하여 문맥상 혼동을 줄 수 있습니다. 혹시 '고통스러운 구역인 좌측 하단'을 의도하신 것이라면 표현을 수정하는 것이 논의의 명확성을 높이는 데 도움이 될 것 같습니다.