소프트웨어 아키텍처 The Hard Parts 2주차 - 권태형 #593
Conversation
…t-based decomposition and tactical branching strategies in software architecture.
TaeHyoungKwon
added
2026
Software Architecture: The Hard Parts
TaeHyoungKwon
requested review from
GeunJuLEE,
benscookie,
chichoon,
dhlee3994,
jongfeel,
tttghost and
ymkim97
|
우측에 있는 |
Summary of ChangesHello @TaeHyoungKwon, 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}
| # 4장 | ||
|
|
||
| - 논의 주제 | ||
| - 전술적 분기의 경우 모놀리스 의 코드 구조가 어떻게 되어있든 만능으로 활용할 수 있다고 생각하고, 먼저 빠르게 전술적 분기를 적용한 이후에 코드 리팩토링을 하는 전략을 가져간다면, 컴포넌트 기반 분해의 각각의 스텝을 천천히 가져가면서, 실행을 늦출 필요가 있을까? 라는 생각이 들었습니다 다른 분들은 이부분에 대해서 어떻게 생각하시는지 의견이 궁금합니다 |
There was a problem hiding this comment.
'모놀리스'와 '의' 사이에 불필요한 공백이 있습니다. 가독성을 위해 붙여 쓰는 것이 좋습니다.
| - 전술적 분기의 경우 모놀리스 의 코드 구조가 어떻게 되어있든 만능으로 활용할 수 있다고 생각하고, 먼저 빠르게 전술적 분기를 적용한 이후에 코드 리팩토링을 하는 전략을 가져간다면, 컴포넌트 기반 분해의 각각의 스텝을 천천히 가져가면서, 실행을 늦출 필요가 있을까? 라는 생각이 들었습니다 다른 분들은 이부분에 대해서 어떻게 생각하시는지 의견이 궁금합니다 | |
| - 전술적 분기의 경우 모놀리스의 코드 구조가 어떻게 되어있든 만능으로 활용할 수 있다고 생각하고, 먼저 빠르게 전술적 분기를 적용한 이후에 코드 리팩토링을 하는 전략을 가져간다면, 컴포넌트 기반 분해의 각각의 스텝을 천천히 가져가면서, 실행을 늦출 필요가 있을까? 라는 생각이 들었습니다 다른 분들은 이부분에 대해서 어떻게 생각하시는지 의견이 궁금합니다 |
|
|
||
| 반대로, 전술적 분기는 코드의 상태가 상관이 없기 때문에, 더 과감하게 해볼 수 있지 않을까 생각된다 | ||
|
|
||
| 물론, AI를 활용한다면, 전자/후자가 큰차이는 없을거 같은데, 실행을 빠르게 해볼 수 있다는 측면에서 개인적으로는 전술적 분기로 일단 분해를 하고 나서, 일반적으로는 AI를 통해서 리팩터링하는게 더 좋은 방법이지 않을까 생각 된다 |
There was a problem hiding this comment.
문장 내에 띄어쓰기 오류가 있습니다. '큰차이는'은 '큰 차이는'으로, '생각 된다'는 '생각됩니다'로 수정하여 가독성을 높이는 것이 좋겠습니다.
| 물론, AI를 활용한다면, 전자/후자가 큰차이는 없을거 같은데, 실행을 빠르게 해볼 수 있다는 측면에서 개인적으로는 전술적 분기로 일단 분해를 하고 나서, 일반적으로는 AI를 통해서 리팩터링하는게 더 좋은 방법이지 않을까 생각 된다 | |
| 물론, AI를 활용한다면, 전자/후자가 큰 차이는 없을거 같은데, 실행을 빠르게 해볼 수 있다는 측면에서 개인적으로는 전술적 분기로 일단 분해를 하고 나서, 일반적으로는 AI를 통해서 리팩터링하는게 더 좋은 방법이지 않을까 생각됩니다 |
| 반대로, 전술적 분기는 코드의 상태가 상관이 없기 때문에, 더 과감하게 해볼 수 있지 않을까 생각된다 | ||
|
|
||
| 물론, AI를 활용한다면, 전자/후자가 큰차이는 없을거 같은데, 실행을 빠르게 해볼 수 있다는 측면에서 개인적으로는 전술적 분기로 일단 분해를 하고 나서, 일반적으로는 AI를 통해서 리팩터링하는게 더 좋은 방법이지 않을까 생각 된다 | ||
| - 4장에서 아키텍쳐 분해와 관련된 개념들인 구심/원심 커플링, 추상도/불안정도의 경우는 기존의 정적분석 도구를 통해서도 충분히 정확한 값을 잘 측정해볼 수 있었을 것 같다. (명확한 정의와 수식이 있기 때문에, AI 에게 시켜도 잘 할 것 같다) |
There was a problem hiding this comment.
이 문장은 앞선 문단에 이어서 개인적인 생각을 서술하는 부분으로 보입니다. 문단 구성을 위해 맨 앞의 '-'를 제거하는 것이 더 자연스러울 것 같습니다.
| - 4장에서 아키텍쳐 분해와 관련된 개념들인 구심/원심 커플링, 추상도/불안정도의 경우는 기존의 정적분석 도구를 통해서도 충분히 정확한 값을 잘 측정해볼 수 있었을 것 같다. (명확한 정의와 수식이 있기 때문에, AI 에게 시켜도 잘 할 것 같다) | |
| 4장에서 아키텍쳐 분해와 관련된 개념들인 구심/원심 커플링, 추상도/불안정도의 경우는 기존의 정적분석 도구를 통해서도 충분히 정확한 값을 잘 측정해볼 수 있었을 것 같다. (명확한 정의와 수식이 있기 때문에, AI 에게 시켜도 잘 할 것 같다) |
| - 공통 기능을 식별해서, 별도의 클래스 혹은 패키지로 추출하는 기준은 각 회사, 팀, 사람 마다 다를 것 같습니다. 공통 기능을 식별해서 추출하는 시점은 어느정도로 잡으시는지, 공통 기능 추출을 어느정도 중요도로 판단하고 있는지 얘기해보면 좋을 것 같습니다 | ||
| - 나의 답변 | ||
| - 기타 의견 | ||
| - 일단 책의 예제는 너무 쉽습니다 책의 예제를 기준으론, 당연하게도 공통기능으로 식별해서 추출하는게 맞다고 생각합니다. |
There was a problem hiding this comment.
문장 부호와 띄어쓰기를 수정하여 가독성을 향상시킬 수 있습니다. '쉽습니다' 뒤에 마침표를 추가하고, '기준으론'을 '기준으로는'으로 수정하는 것을 제안합니다.
| - 일단 책의 예제는 너무 쉽습니다 책의 예제를 기준으론, 당연하게도 공통기능으로 식별해서 추출하는게 맞다고 생각합니다. | |
| - 일단 책의 예제는 너무 쉽습니다. 책의 예제를 기준으로는, 당연하게도 공통기능으로 식별해서 추출하는게 맞다고 생각합니다. |
| - 제 개인적으로는 정말로 재활용도가 높은 유틸리티성 기능이 아니라면, 섣부르게 추상화해서, 공통 기능으로 추출하는 것은 최대한 자제하는 편이고, 충분히 코드베이스에 익숙해 지고, 코드의 변화 패턴이 보일 때, 천천히 추출하는 편 입니다. 이렇게 하는 이유는 섣부르게 추출해서 되돌리는 것 보다, 충분히 시간을 가지고 관찰하다가 나중에 추출해서 공통기능을 만드는 것이 더 이득이라고 생각하기 때문입니다. 그래서 스스로 공통기능을 추출하는 것에 조급해하지 않는 편이라 생각합니다(별로 중요한거 같지 않음) | ||
| - 코드 수정을 해야할 때, 중복되는 코드들을 같이 고쳐야하는 경우가 많지 않다면, 어느정도 중복은 허용해도 별문제 없다는 입장 |
There was a problem hiding this comment.
가독성 향상을 위해 몇 가지 수정을 제안합니다.
- 띄어쓰기:
익숙해 지고->익숙해지고,편 입니다->편입니다,것 보다->것보다,해야할->해야 할,별문제->별 문제 (별로 중요한거 같지 않음)과 같은 비공식적인 표현은 문서의 통일성을 위해 제거하거나 좀 더 공식적인 표현으로 바꾸는 것이 좋습니다.
| - 제 개인적으로는 정말로 재활용도가 높은 유틸리티성 기능이 아니라면, 섣부르게 추상화해서, 공통 기능으로 추출하는 것은 최대한 자제하는 편이고, 충분히 코드베이스에 익숙해 지고, 코드의 변화 패턴이 보일 때, 천천히 추출하는 편 입니다. 이렇게 하는 이유는 섣부르게 추출해서 되돌리는 것 보다, 충분히 시간을 가지고 관찰하다가 나중에 추출해서 공통기능을 만드는 것이 더 이득이라고 생각하기 때문입니다. 그래서 스스로 공통기능을 추출하는 것에 조급해하지 않는 편이라 생각합니다(별로 중요한거 같지 않음) | |
| - 코드 수정을 해야할 때, 중복되는 코드들을 같이 고쳐야하는 경우가 많지 않다면, 어느정도 중복은 허용해도 별문제 없다는 입장 | |
| - 제 개인적으로는 정말로 재활용도가 높은 유틸리티성 기능이 아니라면, 섣부르게 추상화해서, 공통 기능으로 추출하는 것은 최대한 자제하는 편이고, 충분히 코드베이스에 익숙해지고, 코드의 변화 패턴이 보일 때, 천천히 추출하는 편입니다. 이렇게 하는 이유는 섣부르게 추출해서 되돌리는 것보다, 충분히 시간을 가지고 관찰하다가 나중에 추출해서 공통기능을 만드는 것이 더 이득이라고 생각하기 때문입니다. 그래서 스스로 공통기능을 추출하는 것에 조급해하지 않는 편이라 생각합니다. | |
| - 코드 수정을 해야 할 때, 중복되는 코드들을 같이 고쳐야 하는 경우가 많지 않다면, 어느정도 중복은 허용해도 별 문제 없다는 입장 |
| - 이 컴포넌트 사이즈를 아키텍트의 의도를 담아 일관적으로 관리하기 위해서, 이에 맞는 피트니스 함수를 쓰는 것은 매우 적절한 선택으로 볼 수 있다. 다만, 현실세계에서 이렇게 까지 제약을 두는게 맞을까에 대해서는 조금 의문이 들고, 실제로 해보면서 느껴봐야 효용성을 알 수 있을 것 같다 | ||
| - 이러한 피트니스 함수를 적용하는 것은 빌드 시점 혹은 github workflow 에 추가해볼 수 있을 거 같고, AI를 활용하면 매우 쉽게 구현하면서 적용해볼 수 있을 것 같다 개인프로젝트에서 한번 테스트 해보면 좋을거 같다 | ||
| - 5.2 공통 도메인 컴포넌트 수집 패턴 | ||
| - 책의 예제는 공통 도메인의 추출할지 결정하기에 좀 쉬운 예제인 것 같다 현실세계에서는 책의 예제보다 더 복잡한 경우가 많고, 이를 잘 판단해서 추상화할 수 있는게 개발자의 역량이라고 생각한다 |
There was a problem hiding this comment.
문장 부호와 띄어쓰기를 수정하여 가독성을 높일 수 있습니다. '같다' 뒤에 마침표를 추가하고, '있는게'를 '있는 것이'로 수정하는 것을 제안합니다.
| - 책의 예제는 공통 도메인의 추출할지 결정하기에 좀 쉬운 예제인 것 같다 현실세계에서는 책의 예제보다 더 복잡한 경우가 많고, 이를 잘 판단해서 추상화할 수 있는게 개발자의 역량이라고 생각한다 | |
| - 책의 예제는 공통 도메인의 추출할지 결정하기에 좀 쉬운 예제인 것 같다. 현실세계에서는 책의 예제보다 더 복잡한 경우가 많고, 이를 잘 판단해서 추상화할 수 있는 것이 개발자의 역량이라고 생각한다 |
| - 5.2 공통 도메인 컴포넌트 수집 패턴 | ||
| - 책의 예제는 공통 도메인의 추출할지 결정하기에 좀 쉬운 예제인 것 같다 현실세계에서는 책의 예제보다 더 복잡한 경우가 많고, 이를 잘 판단해서 추상화할 수 있는게 개발자의 역량이라고 생각한다 | ||
| - 개인적으로는 공통 코드에 대해서는 조심스럽게 접근해야한다고 생각하는데, 충분히 성숙치 않은 상태에서 성급하게 추상화 했을 때, 이전 보다 유지보수가 어렵게 될 수 있기 때문이다. 충분히 성숙했다고 판단이 되었을 때, 공통으로 묶는 것을 고려하면 좋을거 같다 | ||
| - 중복코드인지 판별하는 피트니스 함수는 조금 과한 것 같다는 생각이다 굳이 피트니스 함수가 없어도 사람이 식별할 수 있는 수준으로 보이기 때문이다(컴포넌트 사이즈와 비교 했을 때) |
There was a problem hiding this comment.
문장 부호와 띄어쓰기를 수정하면 가독성이 향상됩니다. '생각이다' 뒤에 마침표를 추가하고, '비교 했을 때'를 '비교했을 때'로 수정하는 것을 제안합니다.
| - 중복코드인지 판별하는 피트니스 함수는 조금 과한 것 같다는 생각이다 굳이 피트니스 함수가 없어도 사람이 식별할 수 있는 수준으로 보이기 때문이다(컴포넌트 사이즈와 비교 했을 때) | |
| - 중복코드인지 판별하는 피트니스 함수는 조금 과한 것 같다는 생각이다. 굳이 피트니스 함수가 없어도 사람이 식별할 수 있는 수준으로 보이기 때문이다(컴포넌트 사이즈와 비교했을 때) |
| - 5장 내용 중에서 가장 실무에서 활용 해볼법한 내용이 아닐까 생각된다. 실제로 어떤식으로 컴포넌트 분리 혹은 합칠지에 대해서는 사람마다 기준이 모호해서 논쟁의 여지가 있는 부분인데, 책에서 나온 평탄화 방법 2가지는 확실한 기준으로써 활용가치가 있다고 생각했다 | ||
| - 요렇게 평탄화 작업을 했을 때의 장점은 모든 소스코드가 최하위 노드에만 존재하기 때문에 도메인 분류와 실제 기능을 하는 컴포넌트의 경계를 명확히 나눌 수 있다는 점이고, 이로 인해서 도메인 파악을 하기 더 쉽지 않을까 라는 생각이 들었다(실제 책의 예제를 봤을 때도 이전보다 훨씬 명확해진 느낌) |
There was a problem hiding this comment.
가독성을 높이기 위해 띄어쓰기를 수정하고 구어체 표현을 다듬는 것을 제안합니다.
해볼법한->해볼 법한어떤식으로->어떤 식으로요렇게->이렇게(구어체 표현)
| - 5장 내용 중에서 가장 실무에서 활용 해볼법한 내용이 아닐까 생각된다. 실제로 어떤식으로 컴포넌트 분리 혹은 합칠지에 대해서는 사람마다 기준이 모호해서 논쟁의 여지가 있는 부분인데, 책에서 나온 평탄화 방법 2가지는 확실한 기준으로써 활용가치가 있다고 생각했다 | |
| - 요렇게 평탄화 작업을 했을 때의 장점은 모든 소스코드가 최하위 노드에만 존재하기 때문에 도메인 분류와 실제 기능을 하는 컴포넌트의 경계를 명확히 나눌 수 있다는 점이고, 이로 인해서 도메인 파악을 하기 더 쉽지 않을까 라는 생각이 들었다(실제 책의 예제를 봤을 때도 이전보다 훨씬 명확해진 느낌) | |
| - 5장 내용 중에서 가장 실무에서 활용 해볼 법한 내용이 아닐까 생각된다. 실제로 어떤 식으로 컴포넌트 분리 혹은 합칠지에 대해서는 사람마다 기준이 모호해서 논쟁의 여지가 있는 부분인데, 책에서 나온 평탄화 방법 2가지는 확실한 기준으로써 활용가치가 있다고 생각했다 | |
| - 이렇게 평탄화 작업을 했을 때의 장점은 모든 소스코드가 최하위 노드에만 존재하기 때문에 도메인 분류와 실제 기능을 하는 컴포넌트의 경계를 명확히 나눌 수 있다는 점이고, 이로 인해서 도메인 파악을 하기 더 쉽지 않을까 라는 생각이 들었다(실제 책의 예제를 봤을 때도 이전보다 훨씬 명확해진 느낌) |
| - 5장 내용 중에서 가장 실무에서 활용 해볼법한 내용이 아닐까 생각된다. 실제로 어떤식으로 컴포넌트 분리 혹은 합칠지에 대해서는 사람마다 기준이 모호해서 논쟁의 여지가 있는 부분인데, 책에서 나온 평탄화 방법 2가지는 확실한 기준으로써 활용가치가 있다고 생각했다 | ||
| - 요렇게 평탄화 작업을 했을 때의 장점은 모든 소스코드가 최하위 노드에만 존재하기 때문에 도메인 분류와 실제 기능을 하는 컴포넌트의 경계를 명확히 나눌 수 있다는 점이고, 이로 인해서 도메인 파악을 하기 더 쉽지 않을까 라는 생각이 들었다(실제 책의 예제를 봤을 때도 이전보다 훨씬 명확해진 느낌) | ||
| - 5.4 컴포넌트 디펜던시 | ||
| - 컴포넌트 간 의존성을 판단하는 것은 굳이 말을 하지 않아도 당연한 결과이고, 의존성이 적을 수록 마이크로서비스로 분리하기 훨씬 쉽다는 것도 어찌보면 상식으로 볼 수 있다 |
There was a problem hiding this comment.
'적을 수록'을 '적을수록'으로 붙여 쓰는 것이 올바른 표현입니다.
| - 컴포넌트 간 의존성을 판단하는 것은 굳이 말을 하지 않아도 당연한 결과이고, 의존성이 적을 수록 마이크로서비스로 분리하기 훨씬 쉽다는 것도 어찌보면 상식으로 볼 수 있다 | |
| - 컴포넌트 간 의존성을 판단하는 것은 굳이 말을 하지 않아도 당연한 결과이고, 의존성이 적을수록 마이크로서비스로 분리하기 훨씬 쉽다는 것도 어찌보면 상식으로 볼 수 있다 |
No description provided.