소프트웨어 아키텍처 The Hard Parts 2주차 - 김도경 #595
Conversation
|
우측에 있는 |
Summary of ChangesHello @benscookie, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 이 PR은 '소프트웨어 아키텍처 The Hard Parts' 책의 4장(아키텍처 분해)과 5장(컴포넌트 기반 분해 패턴)에 대한 학습 내용을 정리한 Markdown 문서를 추가합니다. 아키텍처 분해의 이론적 개념과 실질적인 적용 방법론을 탐구하며, 특히 분해 전 고려사항, 다양한 분해 전략, 그리고 실무에서의 적용 난이도 및 장단점에 대한 개인적인 통찰을 담고 있습니다. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
|
|
||
| # Chapter 05: 컴포넌트 기반 분해 패턴 | ||
|
|
||
| 이 챕터도 쉽게 읽히는 내용은 아니었다. 특히 "패턴"이라고 해서 단순히 읽고 넘길 수 있는 게 아니라, 단계별로 실제로 구조가 바뀌는 과정을 상상해야 해서 나에겐 한장한장 집중력이 꽤 필요했다. |
There was a problem hiding this comment.
가독성을 높이기 위해 '한장한장'을 '한 장 한 장'으로 띄어쓰는 것을 제안합니다. 이는 표준 맞춤법에도 더 부합합니다.
| 이 챕터도 쉽게 읽히는 내용은 아니었다. 특히 "패턴"이라고 해서 단순히 읽고 넘길 수 있는 게 아니라, 단계별로 실제로 구조가 바뀌는 과정을 상상해야 해서 나에겐 한장한장 집중력이 꽤 필요했다. | |
| 이 챕터도 쉽게 읽히는 내용은 아니었다. 특히 "패턴"이라고 해서 단순히 읽고 넘길 수 있는 게 아니라, 단계별로 실제로 구조가 바뀌는 과정을 상상해야 해서 나에겐 한 장 한 장 집중력이 꽤 필요했다. |
|
|
||
| 이 챕터도 쉽게 읽히는 내용은 아니었다. 특히 "패턴"이라고 해서 단순히 읽고 넘길 수 있는 게 아니라, 단계별로 실제로 구조가 바뀌는 과정을 상상해야 해서 나에겐 한장한장 집중력이 꽤 필요했다. | ||
|
|
||
| 이번 챕터는 컴포넌트 기반 분해를 실제로 진행하는 과정을 6단계 패턴으로 설명한다. 1. 컴포넌트 식별 및 사이징 2. 공통 도메인 컴포넌트 수집 3. 컴포넌트 눌러펴기 4. 컴포넌트 디펜던시 결정 5. 컴포넌트 도메인 생성 6. 도메인 서비스 생성 |
There was a problem hiding this comment.
6단계 패턴을 한 줄로 나열하는 것보다 마크다운의 번호 목록(numbered list)을 사용하면 가독성이 더 좋아질 것 같습니다.
| 이번 챕터는 컴포넌트 기반 분해를 실제로 진행하는 과정을 6단계 패턴으로 설명한다. 1. 컴포넌트 식별 및 사이징 2. 공통 도메인 컴포넌트 수집 3. 컴포넌트 눌러펴기 4. 컴포넌트 디펜던시 결정 5. 컴포넌트 도메인 생성 6. 도메인 서비스 생성 | |
| 이번 챕터는 컴포넌트 기반 분해를 실제로 진행하는 과정을 6단계 패턴으로 설명한다. | |
| 1. 컴포넌트 식별 및 사이징 | |
| 2. 공통 도메인 컴포넌트 수집 | |
| 3. 컴포넌트 눌러펴기 | |
| 4. 컴포넌트 디펜던시 결정 | |
| 5. 컴포넌트 도메인 생성 | |
| 6. 도메인 서비스 생성 |
benscookie
added
2026
Software Architecture: The Hard Parts
| # 논의 주제 | ||
|
|
||
| 초기 프로젝트에서 "아직 분해하지 말자"고 판단하는 기준은 뭘까? | ||
| 아직 규모가 작은 프로젝트에서는 어느 시점에 "이제 분해를 고민해야겠다"고 느끼는지 궁금하다. |
There was a problem hiding this comment.
초기 프로젝트에서 "아직 분해하지 말자"고 판단하는 기준은 뭘까?
- 어떤 문제가 발생했거나, 발생할것으로 예상되어서, 분해를 해야한다는 니즈가 생기지 않는 이상은 굳이 분해를 할 필요가 없다고 생각합니다. 이 기준으로 봤을 때의 판단 기준은 분해를 하지 않으면 어떠한 문제가 발생하거나, 발생할것으로 기대되는 어떤 상황으로 볼 수 있지 않을까 생각 됩니다
아직 규모가 작은 프로젝트에서는 어느 시점에 "이제 분해를 고민해야겠다"고 느끼는지 궁금하다.
- 위에서 말씀드린 것처럼 어떤 분해를 하지 않았을 때, 어떤 문제가 발생했거나, 할것으로 예상이 되는 순간이 분해를 고민해야하는 시점이지 않을까 생각 됩니다
| 초기 프로젝트에서 "아직 분해하지 말자"고 판단하는 기준은 뭘까? | ||
| 아직 규모가 작은 프로젝트에서는 어느 시점에 "이제 분해를 고민해야겠다"고 느끼는지 궁금하다. |
There was a problem hiding this comment.
여러 경험에 비추어 봤을 때는 그런 판단은 론칭 된 이후에 나오는 얘기 같습니다.
개발 중간 그리고 후반에는 구현해야 할 기능들이 밀려 있고 그마저도 우선순위로 잘라 내기에도 버거울 테니까요.
책에서도 이미 모놀리스로 구축된 운영 시스템을 전제로 분해를 고민하고 있으니
판단 기준은 운영 시스템에서 문제가 발견되고 해결 방안을 찾는 과정에서 판단 기준이 나오게 될 것 같습니다.
| - 컴포넌트 기반 분해: 기존 코드에서 컴포넌트 단위를 식별할 수 있는 경우 | ||
| - 전술적 분기: 코드가 너무 얽혀 있어서 구조적으로 분해하기 어려운 경우 | ||
|
|
||
| 전술적 분기는 이상적인 아키텍처 방식이라기보다 현실적인 방법으로 보였다. 구조를 완전히 정리해서 분해하는 게 힘든 상황이라면, 먼저 경계를 나누고 각 영역에서 불필요한 것을 제거하면서 점진적으로 나아가는 선택지가 될 수 있다는 점이 인상 깊었다. |
There was a problem hiding this comment.
저는 해왔던 프로젝트들이 전술적분기를 택한 경우가 많았던 것 같습니다.
No description provided.