소프트웨어 아키텍처 The Hard Parts 1주차 - 김영명 #583
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' 책의 1장부터 3장까지의 내용을 저자(ymkim97)가 정리하고 개인적인 소감 및 논의할 점을 담은 마크다운 문서를 추가합니다. 아키텍처의 본질적인 어려움, 아키텍처 퀀텀, 그리고 모듈성 및 분산 아키텍처로의 전환 동기 등 핵심 개념에 대한 이해를 공유하고 있습니다. 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}
| ## 1장 ~ 3장 | ||
| --- | ||
| ## 논의 내용 | ||
| * 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 할동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요? |
There was a problem hiding this comment.
'할동'에 오타가 있습니다. '활동'으로 수정하면 더 자연스러운 문장이 됩니다.
| * 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 할동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요? | |
| * 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 활동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요? |
| 두번째로는 단단함(Solidity)이다. 하드웨어와 소프트웨어를 구분하는 이치와 마찬가지로, 하드한 것은 소프트한 것의 기반이 되므로 쉽사리 바뀌지 않는다는 것이다. | ||
| 설명을 읽고나니 그냥 책이 어렵다라는 뜻이 아니라는 것에 덜 걱정된 마음으로 다가갈 수 있게 되었던 것 같다. | ||
|
|
||
| 소프트웨어 아키텍처 101에서 간간히 나왔던 피트니수 함수에 대해서 다시 한번 생각해 볼 수 있었다. |
There was a problem hiding this comment.
'피트니수 함수'는 '피트니스 함수'의 오타인 것 같습니다. 수정하면 좋을 것 같습니다.
| 소프트웨어 아키텍처 101에서 간간히 나왔던 피트니수 함수에 대해서 다시 한번 생각해 볼 수 있었다. | |
| 소프트웨어 아키텍처 101에서 간간히 나왔던 피트니스 함수에 대해서 다시 한번 생각해 볼 수 있었다. |
| 예전에 ArchUnit에 관한 Spring I/O 2024 영상을 봤던 적이 있어 기억이 났는데, 때마침 책에서도 소개가 되었다. | ||
|
|
||
| 이번 책에서는 아키텍트로서 난제에 직면하고 현명하게 결정을 내릴 수 있는 목표를 두고 있어 “한빛가이버 사가”라는 가상의 회사를 설정했다. | ||
| 이를 통해 다양한 기법과 트레이드오프 기술할 것이라고 하는데, 이런 가상의 예시는 무언가를 이해하는데에 좋고재미있는 방법이라고 생각한다. |
There was a problem hiding this comment.
문장의 가독성을 높이기 위해 몇 가지 띄어쓰기 및 조사를 수정하는 것을 제안합니다.
이해하는데에->이해하는 데에좋고재미있는->좋고 재미있는트레이드오프 기술할->트레이드오프를 기술할
| 이를 통해 다양한 기법과 트레이드오프 기술할 것이라고 하는데, 이런 가상의 예시는 무언가를 이해하는데에 좋고재미있는 방법이라고 생각한다. | |
| 이를 통해 다양한 기법과 트레이드오프를 기술할 것이라고 하는데, 이런 가상의 예시는 무언가를 이해하는 데에 좋고 재미있는 방법이라고 생각한다. |
| 아키텍트는 뚜렷한 비즈니스 동인 없이 시스템을 더 잘게 나누면 안된다. | ||
| 애플리케이션을 더 작은 부분으로 나누는 주요 비즈니스 동인은 시장 출시 속도와 시장에서의 경쟁 우위 확보다. | ||
|
|
||
| 가용성(내고장성), 확장성, 배포성, 시험성, 유지 보수성은 오늘날 시장에서 민첩성, 시장 출시 속도, 경쟁 우위를 달성하기 위해 필요한 5대 핵심 아키텍처 특징이다. |
There was a problem hiding this comment.
'달성하기'와 '위해' 사이에 불필요한 공백이 있습니다. 제거하여 가독성을 높이는 것이 좋겠습니다.
| 가용성(내고장성), 확장성, 배포성, 시험성, 유지 보수성은 오늘날 시장에서 민첩성, 시장 출시 속도, 경쟁 우위를 달성하기 위해 필요한 5대 핵심 아키텍처 특징이다. | |
| 가용성(내고장성), 확장성, 배포성, 시험성, 유지 보수성은 오늘날 시장에서 민첩성, 시장 출시 속도, 경쟁 우위를 달성하기 위해 필요한 5대 핵심 아키텍처 특징이다. |
| ## 1장 ~ 3장 | ||
| --- | ||
| ## 논의 내용 | ||
| * 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 할동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요? |
There was a problem hiding this comment.
왕도는 없는 것 같습니다 단순히 책에 나오는 것을 넘어서, 다양한 문제상황들을 경험해보고 고민해보는 방법 밖에 없다고 생각합니다
일단 회사를 기준으로 하시면 좋을거 같습니다(회사의 문제들이 리얼현실 문제들이기 때문에, 그 어떤 것보다 좋은 학습 자료라고 생각) 나에게 쉬운 문제이든지, 어려운 문제이든지 가리지 말고, 문제상황을 최대한 많이 접하려고 시도해보시면 좋을거 같습니다
여기서 문제상황은 꼭 아키텍쳐 레벨에서의 의사결정 문제가 아니여도 문제 없고, 어떤 문제라도 괜찮다고 생각합니다
가령 나에게 당장 주어진 백로그 티켓일 수도 있고, 미래에 해야한 우리 팀의 아키텍쳐 개선 과제일 수도 있을 것이고요
일단은 나와 나의 팀을 문제를 먼저 이해하고 해결하려는 시도를 해보시면서, 여러 트레이드오프로 인한 의사결정 경험을 쌓아보시면 좋을거 같습니다.
나와 나의 팀 문제를 거의 해결해보았다면, 그다음에는 더 넓혀서, 나의 회사기준 다른 팀의 문제들도 어떻게 해결했는지 살펴보시면서 경험을 늘려나가면 좋을것 같습니다
다만, 나에게 주어진 회사 업무 하는 것도 제대로 소화하지 못하면서, 여기저기 스터디나, 외부 프로젝트를 하는 경우를 봤는데, 제 개인적으로는, 순서가 잘못되었다고 생각됩니다. 회사 업무 기준으로 나 -> 팀 -> 회사 요렇게 까지 다양한 문제상황들을 접하는 연습을 하는것만으로도 충분하다 생각 됩니다
과거 보다 좋은 점은 요즘에는 AI 발전으로 인해서, 내가 고민하는 기술적 내용들을 쉽게 목업 형태로 빠르게 만들어서 테스트 해볼 수 있다는 점 입니다 과거에는 트레이드오프를 고려한 의사결정을 할 때, 실제 POC로 테스트 해보는데 까지 너무 많은 시간이 걸렸던게 단점이였지만, 현재는 AI를 활용하여서, 프롬프트 만으로 이런 기술 트레이드오프를 테스트해볼 수 있는 환경을 만드는 일은 너무 쉬운일이 되어버렸습니다. 요런것들도 많이 활용해보시면 좋을거 같습니다
There was a problem hiding this comment.
하나의 프로젝트를 여러 방식으로 구현해보는 것도 좋은 방법인 것 같습니다.
There was a problem hiding this comment.
일단 회사를 기준으로 하시면 좋을거 같습니다(회사의 문제들이 리얼현실 문제들이기 때문에, 그 어떤 것보다 좋은 학습 자료라고 생각) 나에게 쉬운 문제이든지, 어려운 문제이든지 가리지 말고, 문제상황을 최대한 많이 접하려고 시도해보시면 좋을거 같습니다
요 문장에 큰 공감합니다~
입사 초창기에는 제품의 코드베이스나 도메인에 대한 이해도 적고 (타 팀원분들 대비) 코드를 다룰 수 있는 능력도 뒤처진다고 생각해서 간단한 버그나 단순한 기능 추가로 대부분의 시간을 보냈었는데, 제품 코드도 조금씩 읽히고 레거시가 눈에 들어옴에 따라 자신감이 붙으면서 비록 저에게 할당되지 않은 태스크나 개선사항이더라도 일단 부딪쳐보는 식으로 경험을 쌓으면서 스스로 의사 결정을 하는 스킬을 배운 것 같습니다
코드리뷰가 적절히 이루어지는 환경이라면, 눈에 띄는 작은 요소부터 개선해보는 방식이 가장 빨리 느는 것 같기도 하네요 (코드리뷰 환경을 전제로 깔았던 건, 아무리 그래도 버그가 발생하면 안 되니까 리뷰어가 있어야 심적으로 안심이 되는것 같아요)
There was a problem hiding this comment.
회사 내에서는 현재 담당하고 있는 서비스에서 "만약에" 그리고 "어떻게"를 상상하며 팀원들과 논의해보는걸 추천드려요. 만약에 A팀에서 장애가 난다면 어떻게 해야할까? 어떻게 해야 좀 더 빠른 응답을 줄 수 있을까? 어떻게 해야 서비스 개발을 빠르게 하기 위한 바탕을 만들어놓을 수 있을까? 어떻게 해야 장애를 줄일 수 있을까? 등 생각해보면 좋을거 같습니다.
회사 밖에서는 본인이 직접 경험(사이드 프로젝트 등을 통해)하면 좋겠지만 그것은 한계가 있다 생각하여 우리가 책을 읽거나 여러 사람과 이야기를 함으로써 간접 경험하는 것이 효율적이라고 생각합니다.
| ## 1장 ~ 3장 | ||
| --- | ||
| ## 논의 내용 | ||
| * 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 할동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요? |
There was a problem hiding this comment.
하나의 프로젝트를 여러 방식으로 구현해보는 것도 좋은 방법인 것 같습니다.
| ## 1장 ~ 3장 | ||
| --- | ||
| ## 논의 내용 | ||
| * 책을 통해서는 기본적으로 이론과 예시로 이루어져 있는 것 같습니다. 회사든, 그 외의 할동에서든 주니어로서 어떤 것들을 경험하고 도전해야 나쁜 것 중에서 제일 나은 트레이드오프 조합을 찾아 의사 결정할 수 있는 엔지니어로 성장할 수 있을까요? |
There was a problem hiding this comment.
회사 내에서는 현재 담당하고 있는 서비스에서 "만약에" 그리고 "어떻게"를 상상하며 팀원들과 논의해보는걸 추천드려요. 만약에 A팀에서 장애가 난다면 어떻게 해야할까? 어떻게 해야 좀 더 빠른 응답을 줄 수 있을까? 어떻게 해야 서비스 개발을 빠르게 하기 위한 바탕을 만들어놓을 수 있을까? 어떻게 해야 장애를 줄일 수 있을까? 등 생각해보면 좋을거 같습니다.
회사 밖에서는 본인이 직접 경험(사이드 프로젝트 등을 통해)하면 좋겠지만 그것은 한계가 있다 생각하여 우리가 책을 읽거나 여러 사람과 이야기를 함으로써 간접 경험하는 것이 효율적이라고 생각합니다.
이 책은 MSA를 설계 하거나 실무에서 사용한 경험이 많을수록 토론 또는 논의할 것이 많을 것 같아 보였습니다.
아직은 경험이 많지는 않아 책을 읽을 때는 이론적인 내용을 이해하는데에 더 집중하겠지만, 모임 시간에는 다른 분들의 경험을 많이 들어보며 배워보고 싶습니다.