소프트웨어 아키텍처 The Hard Parts 2주차 - 김영명 #594
Conversation
ymkim97
requested review from
GeunJuLEE,
TaeHyoungKwon,
benscookie,
chichoon,
dhlee3994,
jongfeel and
tttghost
ymkim97
added
2026
Software Architecture: The Hard Parts
|
우측에 있는 |
Summary of ChangesHello @ymkim97, 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장에 대한 학습 노트를 추가합니다. 모놀리식 애플리케이션을 분산 아키텍처로 전환하기 위한 아키텍처 분해 전략과 컴포넌트 기반 분해 패턴에 중점을 두며, 실질적인 마이그레이션 접근 방식과 피트니스 함수의 활용 방안을 탐구합니다. 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}
|
|
||
| 해당 장을 읽기 전까지 간간히 언급되었던 컴포넌트를 조금이나마 더 이해할 수 있게 되었다. | ||
| 여기에 도메인, 서브 도메인, 컴포넌트 간의 차이 및 관계가 어떻게 되는지도 처음으로 깨닫게 되어 정말 재밌게 읽었다. | ||
| 컴포넌트 기분 분해는 코드베이스가 체계가 어느 정도 잡혀 있고 네임스페이스(디렉토리)별로 그룹핑돼 있는 모놀리식 애플리케이션을 분리할 때 매우 효과적이다. |
There was a problem hiding this comment.
'컴포넌트 기분 분해'에 오타가 있습니다. 문맥상 '컴포넌트 기반 분해'가 맞는 표현으로 보입니다.
| 컴포넌트 기분 분해는 코드베이스가 체계가 어느 정도 잡혀 있고 네임스페이스(디렉토리)별로 그룹핑돼 있는 모놀리식 애플리케이션을 분리할 때 매우 효과적이다. | |
| 컴포넌트 기반 분해는 코드베이스가 체계가 어느 정도 잡혀 있고 네임스페이스(디렉토리)별로 그룹핑돼 있는 모놀리식 애플리케이션을 분리할 때 매우 효과적이다. |
| 결국 피트니스 함수는 CI/CD 파이프라인에 포함되므로, AI plugin 등도 함께 추가할 수 있지 않을지 아이디어가 떠올랐다. | ||
|
|
||
| 이전에는 모놀리식 아키텍처를 분산 아키텍처로의 마이그레이션 과정을 상상해보거나 감을 잡기 어려웠다. | ||
| 그러나 이번 장을 통해서 마이그레이션은 그냥 감으로 진행하는 것이 아니라, 구조적으로, 점진적으로, 통제 가능한 방향으로 해야하 한다는 것을 알게 되었고, 컴포넌트 기반 분해 패턴이 핵심 요령이라는 것을 배웠다. No newline at end of file |
There was a problem hiding this comment.
'해야하 한다는' 부분에 오타가 있습니다. '해야 한다는'으로 수정하는 것이 자연스럽습니다.
| 그러나 이번 장을 통해서 마이그레이션은 그냥 감으로 진행하는 것이 아니라, 구조적으로, 점진적으로, 통제 가능한 방향으로 해야하 한다는 것을 알게 되었고, 컴포넌트 기반 분해 패턴이 핵심 요령이라는 것을 배웠다. | |
| 그러나 이번 장을 통해서 마이그레이션은 그냥 감으로 진행하는 것이 아니라, 구조적으로, 점진적으로, 통제 가능한 방향으로 해야 한다는 것을 알게 되었고, 컴포넌트 기반 분해 패턴이 핵심 요령이라는 것을 배웠다. |
| ## 논의 내용 | ||
| * 책에서 나오는 단계처럼 [컴포넌트 도메인을 생성]하고 [도메인 서비스를 생성]한 이후에는 특정 도메인 서비스가 너무 크다고 느껴지는 각자의 기준이 무엇인지 논의해보고 싶습니다. 즉 해당 서비스가 다시 "미니 모놀리스(Mini-monolith)"가 되어가는 것은 아닌지 미리 판단할 수 있는 신호는 무엇일까요? |
There was a problem hiding this comment.
즉 해당 서비스가 다시 "미니 모놀리스(Mini-monolith)"가 되어가는 것은 아닌지 미리 판단할 수 있는 신호는 무엇일까요?
새로운 도메인 개발 요구사항이 들어왔을 때, 처음에 의도한 MS의 책임 범위 보다, 더 많은 기능구현을 해야해서, 책임이 크기가 커질 수밖에 없는 상황에서 MS를 만들것인지 책임의 범위를 넓힐것인지를 고민하는 시기가 미니 모놀리스가 되어가는 것은 아닌지 판단할 수 있는 신호 일거 같습니다
저는 기존에 업계에 퍼져있는 MSA는 선이고, 모놀리스는 악이다 라는 관점으로 보는 것은 적절치 않다고 보는 편 입니다. 상황에 따라서 적절한 해결책이 있을뿐이라고 생각합니다
미니 모놀리스가 되어간다라고 하는게, MSA 관점에서는 나쁜신호로 볼 수 있지만, 회사의 사정에 따라서는 그 상황에서 최선의 선택일 수도 있기 때문입니다.
인원이 넉넉한 큰 회사라면, 새로운 도메인 요구사항을 충족하는 새 MS 를 만드는 선택을 함으로써, 미니 모놀리스가 되지 않도록 조치할 수 있을거 같고, 새롭게 만들어지는 MS를 관리할 팀의 인원 새로 채용하거나, 팀을 구성하면 되기 때문에, 관리 측면에서 이점이 있을거 같습니다
반면에 인원이 넉넉치 않은 작은 회사의 경우에는 같은 상황에서, MS를 추가로 만드는 선택 대신에, 기존에 존재하는 MS 중에서 젤 적합한 MS를 찾아서, 그 MS가 책임을 가지도록 하는 식으로 하지 않을까 생각되는데요. MS로 과하게 분리했을 때, 발생하는 코드와 인프라 유지보수성과 비용, 간단한 작업을 굳이 여러 MS에 각각 구현 해야하는 문제를 해결할 수 있는 해결책의 관점으로도 볼 수 있다고 생각합니다
| ## 4장 ~ 5장 | ||
| --- | ||
| ## 논의 내용 | ||
| * 책에서 나오는 단계처럼 [컴포넌트 도메인을 생성]하고 [도메인 서비스를 생성]한 이후에는 특정 도메인 서비스가 너무 크다고 느껴지는 각자의 기준이 무엇인지 논의해보고 싶습니다. 즉 해당 서비스가 다시 "미니 모놀리스(Mini-monolith)"가 되어가는 것은 아닌지 미리 판단할 수 있는 신호는 무엇일까요? |
There was a problem hiding this comment.
한가지 일을 잘 하는 서비스라면 사실 크다는 것의 기준은 소스 코드의 양 혹은 기능(API)의 갯수 정도이지 않을까 싶습니다.
여기서 한 가지 이상의 일, 다른 도메인에서 할 법한 일이 끼어들고 있는지의 여부로 판단하면 좋을 것 같네요.
하나의 서비스 단위로 잘 분리했다면 거기에 뭔가 다른 도메인의 코드를 넣는 것 역시 쉽지 않은 일이라고 보는데, 그러면 안되겠죠.
| ## 4장 ~ 5장 | ||
| --- | ||
| ## 논의 내용 | ||
| * 책에서 나오는 단계처럼 [컴포넌트 도메인을 생성]하고 [도메인 서비스를 생성]한 이후에는 특정 도메인 서비스가 너무 크다고 느껴지는 각자의 기준이 무엇인지 논의해보고 싶습니다. 즉 해당 서비스가 다시 "미니 모놀리스(Mini-monolith)"가 되어가는 것은 아닌지 미리 판단할 수 있는 신호는 무엇일까요? |
There was a problem hiding this comment.
제 기준에서는 특정 서비스 내부에 추가 기능을 개발해야 하는 때가 올때 그 시점에서의 코드의 덩치나, 추가 기능을 붙임으로써 하위 기능의 덩치가 너무 커져버린다고 느껴지면 or 해당 기능 내에서의 컴포넌트나 함수간 의존성이 지나치게 높아지면 그 하위 기능을 새로운 서비스로 빼야겠다고 느껴지는 것 같은데 이건 화면 관점에서의 내용이긴 합니다
제품 전체의 관점에서 봤을 때 하나의 서비스가 하나의 모놀리스 덩어리가 될 정도로 커질 만한 일이 흔할지는 잘 감이 안오네요 ㅡ,,ㅡ
No description provided.