소프트웨어 아키텍처 The Hard Parts 1주차 - 이동현 #586
Conversation
dhlee3994
requested review from
GeunJuLEE,
TaeHyoungKwon,
benscookie,
chichoon,
jongfeel,
tttghost and
ymkim97
dhlee3994
added
2026
Software Architecture: The Hard Parts
|
우측에 있는 |
Summary of ChangesHello @dhlee3994, 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주차 학습 내용을 정리한 문서를 추가합니다. 이 문서는 현대 소프트웨어 아키텍처의 핵심 개념들을 요약하고, 특히 AI 시대의 인력 제약과 마이크로서비스 아키텍처(MSA)의 적용 가능성에 대한 심도 있는 논의를 포함하여, 아키텍처 설계에 대한 이해를 심화하는 데 기여합니다. 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}
| - 간혹 수동으로 실행해야 하는 함수도 있음 (수동 피트니스 함수) | ||
| - 아키텍처 퀀텀: 독립 배포 가능한 아티팩트 (높은 기능 응집도, 높은 정적 커플링, 동기적 동적 커플링) | ||
| - 정적 결합: 공유 DB는 시스템 간의 결합점이 되어 진정한 의미의 독립 배포가 불가능하다 => 1퀀텀 = 1DB | ||
| - 동적 결합: 통신(동기? 비동기?), 일관성(원자성? 최종 일관성?), 조정(오케스트레이터? 코레오그래피?) |
There was a problem hiding this comment.
이 줄의 끝에 불필요한 공백이 있습니다. 문서의 일관성과 가독성을 위해 제거하는 것이 좋습니다.
| - 동적 결합: 통신(동기? 비동기?), 일관성(원자성? 최종 일관성?), 조정(오케스트레이터? 코레오그래피?) | |
| - 동적 결합: 통신(동기? 비동기?), 일관성(원자성? 최종 일관성?), 조정(오케스트레이터? 코레오그래피?) |
2026/Fundamentals_of_Software_Architecture_2nd_Edition/donghyeon/week1.md
Outdated
Show resolved
Hide resolved
dhlee3994
force-pushed
the
dhlee-2026-FSA-week1
branch
from
97143a8 to
c2bca07
Compare
| ## 논의 | ||
|
|
||
| 최근 개발자를 AI로 대체하는 기업이 많다는 뉴스를 심심치 않게 볼 수 있습니다. | ||
| 인력 제약은 아키텍처를 결정할 때 가장 중요한 요소 중 하나인데, 인력이 줄어든 조직에서 MSA는 여전히 합리적일까요? |
There was a problem hiding this comment.
제 개인적인 경험상 아닌거 같다라는 결론 입니다
실제로 저희 회사에서도, 인력이 많이 줄어들었는데, 인력이 많을 때, 많이 만들어두었던 MS 들 유지보수에 어려움을 겪고 있는 상태이고, 이를 통폐합하고 있습니다
근데 최근에 마켓컬리에서 AI Agent를 적극적으로 활용하는 아티클 을 봤었고, 지금 당장은 아니더라도 가까운 미래에는 MSA의 개수와 인력간의 문제는 없어질 가능성이 있지 않을까 기대해봅니다
There was a problem hiding this comment.
저는 합리적이라고 생각합니다.
AI등장 전에는 "팀의 역량 = Σ팀원 의 역량"이었다면 현재는 "팀의 역량 = Σ(팀원 의 역량*AI 활용능력)" 이라고 생각합니다. 고로 팀원 수가 줄어들어도 개개인의 AI활용능력(회사가 지원하는 AI 리소스, AI의 성능 등 AI에 관련된 모든 것을 포함으로 전제)이 훨씬 더 증가한다면, 오히려 팀의 역량은 늘었다고 생각합니다.
그리고 MSA의 목적이 책에 여러 번 등장하였고, 여러 관점 및 여러 상황에서 MSA가 모놀리식보다 낫다는 결론이 있습니다(당연히 무조건은 아닙니다). 그리고 이 또한 AI가 발전한다하더라도 여전히 모놀리식의 side effect가 MSA보다 높을거 같고, 이러한 예시들로 AI의 발전으로 인해 MSA가 모놀리식보다 낫다는 결론에 영향을 주지는 못할거 같습니다.
결론적으로 저는 여전히 합리적일것이라 생각합니다.
만약 유지보수에 인력이 줄어듦으로서 유지보수에 어려움이 있다면 아직 AI의 성능(주석으로 단다고 아직 인간만큼 개발을 해주지는 못 하는거 같음. 아직은 리팩토링, 테스트코드 작성 정도만 유용가능)이 충분히 올라와주지 않은 상태에서 인력이 줄어들어서 생긴 상황이라 생각합니다. "팀의 역량 = Σ(팀원 의 역량*AI 활용능력)" 의 공식에서 팀원 수 : 10, 개개인 역량 1(모두 1로 통일), AI 활용능력 1(모두 1로 통일) 에서 팀원 수 : 5(절반으로 감소), 개개인 역량 1(동일), AI 활용능력 1.5(0.5증가) 하여
10 -> 7.5가 된 상황이지 않을까 싶습니다.
| ## 논의 | ||
|
|
||
| 최근 개발자를 AI로 대체하는 기업이 많다는 뉴스를 심심치 않게 볼 수 있습니다. | ||
| 인력 제약은 아키텍처를 결정할 때 가장 중요한 요소 중 하나인데, 인력이 줄어든 조직에서 MSA는 여전히 합리적일까요? |
There was a problem hiding this comment.
저는 합리적이라고 생각합니다.
AI등장 전에는 "팀의 역량 = Σ팀원 의 역량"이었다면 현재는 "팀의 역량 = Σ(팀원 의 역량*AI 활용능력)" 이라고 생각합니다. 고로 팀원 수가 줄어들어도 개개인의 AI활용능력(회사가 지원하는 AI 리소스, AI의 성능 등 AI에 관련된 모든 것을 포함으로 전제)이 훨씬 더 증가한다면, 오히려 팀의 역량은 늘었다고 생각합니다.
그리고 MSA의 목적이 책에 여러 번 등장하였고, 여러 관점 및 여러 상황에서 MSA가 모놀리식보다 낫다는 결론이 있습니다(당연히 무조건은 아닙니다). 그리고 이 또한 AI가 발전한다하더라도 여전히 모놀리식의 side effect가 MSA보다 높을거 같고, 이러한 예시들로 AI의 발전으로 인해 MSA가 모놀리식보다 낫다는 결론에 영향을 주지는 못할거 같습니다.
결론적으로 저는 여전히 합리적일것이라 생각합니다.
만약 유지보수에 인력이 줄어듦으로서 유지보수에 어려움이 있다면 아직 AI의 성능(주석으로 단다고 아직 인간만큼 개발을 해주지는 못 하는거 같음. 아직은 리팩토링, 테스트코드 작성 정도만 유용가능)이 충분히 올라와주지 않은 상태에서 인력이 줄어들어서 생긴 상황이라 생각합니다. "팀의 역량 = Σ(팀원 의 역량*AI 활용능력)" 의 공식에서 팀원 수 : 10, 개개인 역량 1(모두 1로 통일), AI 활용능력 1(모두 1로 통일) 에서 팀원 수 : 5(절반으로 감소), 개개인 역량 1(동일), AI 활용능력 1.5(0.5증가) 하여
10 -> 7.5가 된 상황이지 않을까 싶습니다.
| 최근 개발자를 AI로 대체하는 기업이 많다는 뉴스를 심심치 않게 볼 수 있습니다. | ||
| 인력 제약은 아키텍처를 결정할 때 가장 중요한 요소 중 하나인데, 인력이 줄어든 조직에서 MSA는 여전히 합리적일까요? |
There was a problem hiding this comment.
당장은 AI를 효율적으로 잘 사용하는 개발자와 그걸 생산성으로 연결시켜 인력 문제를 해결한 사례가 많지 않고 진행 중에 있으므로 아닐 것 같다가 제 의견입니다.
그런데 점점 개발자가 직접 해야 하는 일은 줄고 AI가 해주는 일이 많아질 것이므로 AI가 대체한다고 하면
과거 AI가 없던 시절의 MSA 보다는 인력을 줄이는 건 맞는 방향이라고 봅니다.
| 최근 개발자를 AI로 대체하는 기업이 많다는 뉴스를 심심치 않게 볼 수 있습니다. | ||
| 인력 제약은 아키텍처를 결정할 때 가장 중요한 요소 중 하나인데, 인력이 줄어든 조직에서 MSA는 여전히 합리적일까요? |
There was a problem hiding this comment.
AI가 없었던 시절엔 인력 감축이 직접적으로 팀 역량 감소로 이어졌을텐데, 지금은 적은 인력이 AI를 충분히 활용할 수만 있다면 다수의 퍼포먼스를 내는 것이 충분히 가능한 세상이 됐기 때문에 그런 방면에서 개발자 인원 감소가 마이너스 요소가 될 것 같진 않습니다
물론 전제가 'AI를 잘 다룬다' 이기 때문에 다른 분들이 말씀하신 것처럼 AI를 잘 다루지 못하는 인력만 남거나 or AI에 발전이 없다면 별 소용이 없을 것 같긴... 한데 요즘 AI 발전하는 속도 보면 AI에 발전이 없다 는 가능성이 없는 말인 것 같죠
또한 AI 툴을 효과적으로 다루는 게 개발자 필수역량이 된 만큼 AI를 잘 다루지 못하는 인력만 남을 일도 점점 없어질 것 같네요
장기적으로 보면 합리적? 이라기보단 AI 흐름 속에서 인력 감축은 팀에 (어떤 부분이든) 마이너스가 되지 않을 것이라는 게 제 의견입니다 ..
최근 관심있는 주제의 책이라 재밌게 읽었습니다. 논의 내용만 30분 넘게 고민했네요..