소프트웨어 아키텍처 The Hard Parts 1주차 - 권태형 #582
Conversation
… PR creation process and validations
…als of Software Architecture" to reflect accurate titles and enhance content clarity.
… to enhance visual content.
…Software Architecture" to include AI agent utilization examples for maintenance solutions.
…rchitecture" by improving clarity and correcting grammatical errors in responses regarding MSA challenges and maintenance management.
…rchitecture" by enhancing clarity and correcting grammatical errors, particularly regarding MSA challenges and the role of AI agents in maintenance management.
…enhancing clarity and correcting grammatical errors, particularly in discussions about MSA challenges, architectural agility, and the role of AI agents in maintenance management.
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! 이 Pull Request는 '소프트웨어 아키텍처: The Hard Parts' 스터디를 위한 첫 번째 주차의 학습 내용을 담은 마크다운 문서를 추가하고, GitHub PR 생성 과정을 자동화하는 스크립트를 개선합니다. 이는 스터디 참여자들이 책의 핵심 개념을 이해하고 토론하는 데 필요한 자료를 제공하며, 효율적인 PR 관리 환경을 구축하는 데 기여합니다. 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}
| LABELS="2026,Software Architecture: The Hard Parts | ||
| 소프트웨어 아키텍처: The Hard Parts, 분산 아키텍처를 위한 모던 트레이드오프 분석" |
There was a problem hiding this comment.
PR 라벨을 정의하는 부분에서 줄바꿈 문자가 포함되어 있어 gh CLI가 라벨을 올바르게 인식하지 못할 수 있습니다. -l 또는 --label 플래그는 쉼표로 구분된 단일 문자열을 기대합니다. 줄바꿈은 공백으로 처리되어 의도치 않은 라벨이 생성되거나 라벨 적용에 실패할 수 있습니다.
모든 라벨을 한 줄에 쉼표로 구분하여 정의하는 것을 제안합니다.
| LABELS="2026,Software Architecture: The Hard Parts | |
| 소프트웨어 아키텍처: The Hard Parts, 분산 아키텍처를 위한 모던 트레이드오프 분석" | |
| LABELS="2026,Software Architecture: The Hard Parts,소프트웨어 아키텍처: The Hard Parts,분산 아키텍처를 위한 모던 트레이드오프 분석" |
| - AI 시대에 1장에 나온 내용들을 어떻게 활용해볼 수 있을지 본인의 생각을 나눠보면 좋을 거 같다 | ||
| - 나의 답변 | ||
| - 개인적으로 Fitness 함수의 경우에 AI agent를 사용할 때, 제약사항으로써 제대로된 역할을 할 수 있을 것으로 기대한다 | ||
| - AI 시대가 되면서 한가지 변경되었다고 생각되는 것은 과거 사람의 러닝커브와 머리 용량의 한계로 할 수 없거나, 미루어졌던 일들을 AI를 활용해서 더 잘 한다고 판단되면 더이상 미룰 필요가 없다는 것이다. AI 의 단점 중 하나는 작성하는 코드를 예측하기 쉽지 않다는 점이고, SDD를 기반으로하는 바이브 코딩에서도 가장 중요한 것은 컨텍스트 관리를 통해 대량의 코드를 예측 가능하도록 agent를 관리하는 것인데, Fitness 함수는 Ai agent에게 아키텍쳐 특성에 관해서 객관적으로 체크해볼 수 있는 기준을 제시해주는 것이다. 이를 통해서, 의도한 아키텍쳐의 특성을 체크해볼 수 있다면, 도입하지 않을 이유가 없다고 생각한다 | ||
|
|
||
| ## 내용 요약 | ||
| - 개발 생태계는 전혀 예상치 못했던 방향으로 확장 진화한다 그래서, 기술의 상세 구현 보다는 아키텍트가 어떤 의사결정을 내리는지, 새로운 상황에서의 트레이드오프를 어떻게 객관적으로 평가할 것인지에 집중 | ||
| - 새로운 문제에 직면했을 때의 트레이드오프 분석과 그에 따른 의사 결정이 가장 중요한 주제 | ||
|
|
||
| ## 내 의견 | ||
| - 책에서는 피트니스 함수 구현의 책임을 아키텍트로 보고 있는 것 같은데, 아키텍트로 꼭 제한할 필요 없다고 생각 | ||
| - 피트니스 함수를 통해서, 일종의 단위테스트 처럼 빌드 타이밍에 체크해보는 방식이 예전에는 좀 번거로운 방식이라고 생각했었음 왜냐하면, 그냥 구조 자체를 문제없이 가져가면 되는건데, 꼭 테스트까지 만들어야 하나? 라는 생각때문에, 하지만 지금은 AI를 통해서 쉽고 빠르게 작성할 수 있기 때문에 오히려 의도하는 바를 더 빡빡하게 표현함으로써, 사람도, AI도 실수 할 수 없게 만든다는 측면에서는 좋은 선택이라고 봄(이렇게 안하면, 매번 AI를 사용할 때, 컨텍스트에 해당 내용들을 명시를 해줘야만 하기 때문에) | ||
| - 아키텍처 Fitness 함수는 아키텍쳐와 설계 레벨에서 약속한 정책(일종의 비기능적 요구사항)들을 체크해볼 수 있는 테스트로 볼 수 있고, 이를 배포 파이프라인에서 지속적으로 확인해봄으로써, 큰 효과를 거둘 수 있다 | ||
| - 1장에서는 크게 4가지를 말한다 | ||
| - 트레이드 오프 | ||
| - 각 상황마다 어떤 선택을 하느냐에 따라서, 트레이드 오프가 발생할 수 있다 | ||
| - 현 상황에서의 최고의 선택이 무엇일지 판단하여서, 선택하고, 그로 인해 발생하는 트레이드 오프는 인지하고, 감수하여야 한다 | ||
| - 아키텍처와 데이터의 관계 | ||
| - 아키텍쳐는 데이터에 영향을 받는다, 반대로 데이터 또한 아키텍쳐에 영향 받는다 | ||
| - ADR | ||
| - 위의 트레이드 오프와 아키텍처, 데이터 까지 고려해서, 의사결정을 내릴 때, 그 의사결정에 대한 기록이 필요하다 | ||
| - 아키텍쳐 결정사항은 설계와 구현에 반영되는데, 설계와 구현의 의도를 제대로 알기 위해서는 아키텍쳐 결정사항을 잘 문서화 해두어야 한다 | ||
| - Fitness 함수 | ||
| - 아키텍쳐 결정사항을 사람이 수동으로 체크하는게 아니라, 객관적으로 판단할 수 있는 방법을 제공해준다 |
There was a problem hiding this comment.
마크다운 문법에 맞게 리스트 형식을 수정하는 것을 제안합니다. 현재 각 리스트 항목 앞에 4칸 이상의 공백이 있어 전체가 하나의 코드 블록으로 렌더링됩니다. 이로 인해 가독성이 떨어지고 구조 파악이 어려울 수 있습니다.
일반적인 마크다운 리스트 문법을 사용하면 더 명확하게 내용을 전달할 수 있습니다. 예를 들어, 논의 주제 섹션은 아래와 같이 수정할 수 있습니다.
- AI 시대에 1장에 나온 내용들을 어떻게 활용해볼 수 있을지 본인의 생각을 나눠보면 좋을 거 같다
- 나의 답변
- 개인적으로 Fitness 함수의 경우에 AI agent를 사용할 때, 제약사항으로써 제대로된 역할을 할 수 있을 것으로 기대한다
- AI 시대가 되면서 한가지 변경되었다고 생각되는 것은 과거 사람의 러닝커브와 머리 용량의 한계로 할 수 없거나, 미루어졌던 일들을 AI를 활용해서 더 잘 한다고 판단되면 더이상 미룰 필요가 없다는 것이다. AI 의 단점 중 하나는 작성하는 코드를 예측하기 쉽지 않다는 점이고, SDD를 기반으로하는 바이브 코딩에서도 가장 중요한 것은 컨텍스트 관리를 통해 대량의 코드를 예측 가능하도록 agent를 관리하는 것인데, Fitness 함수는 Ai agent에게 아키텍쳐 특성에 관해서 객관적으로 체크해볼 수 있는 기준을 제시해주는 것이다. 이를 통해서, 의도한 아키텍쳐의 특성을 체크해볼 수 있다면, 도입하지 않을 이유가 없다고 생각한다파일 전체의 리스트에 일관되게 적용하면 좋을 것 같습니다. 또한, 내용 중에 몇 가지 오타나 띄어쓰기 오류(Ai agent -> AI agent, 실수 할 수 없게 -> 실수할 수 없게)가 보여 함께 검토해보시면 좋겠습니다.
| - MSA 설계 시에, 본인이 생각하는 적절한 MS 사이즈의 기준이 있다면 공유해보면 좋을거 같다 | ||
| - 나의 답변 | ||
| - 개인적으로 MSA의 가장 어려운 점은 크기를 어떻게 나눌 것인가 였다. 현재 상황에서는 적절한 크기라고 생각했는데, 이후에는 적절하지 않은 크기 였던 적도 있었기 때문에, 애초에 적절한 MS 크기라는 것은 상황에 따라서 계속 변화될 수밖에 없는 거 아닌가? 라는 생각도 들었다 | ||
|
|
||
| ## 내용 요약 | ||
| - 무작정 잘게 쪼개기만 하면 오케스트레이션과 트랜잭션, 비동기성 등이 큰 문제가 된다 | ||
| - 기존 분산환경과 MSA 의 다른점은 BC의 유무라고 볼 수 있고, 아키텍쳐의 관심사에 데이터 영역까지 들어오게 되면서, 더 의사결정을 내리기 어려워진 것으로 볼 수 있다 | ||
| - 마이크로서비스에서 가장 어려운 부분 | ||
| - 마이크로서비스의 사이즈 | ||
| - 통신방식 | ||
| - 아키텍쳐 퀀텀 | ||
| - 특징 | ||
| - 독립적 배포가능 | ||
| - 높은 기능 응집도 | ||
| - 높은 정적 커플링 | ||
| - 동적 퀀텀 커플링 | ||
| - 정적 퀀텀 커플링 | ||
| - 꼭 DB가 아니더라도, 서비스를 작동시키기 위해서 필요한 의존성들 모두가 정적퀀텀 커플링으로 볼 수 있음 | ||
| - 동적 퀀텀 커플링 | ||
| - 통신 | ||
| - 동기 | ||
| - 비동기 | ||
| - 일관성 | ||
| - 트랜잭션 | ||
| - 최종 일관성 | ||
| - 조정 | ||
| - 오케스트레이션 | ||
| - 코레오그래피 | ||
| ## 내 의견 | ||
| - 오선빈 아키텍트가 말한 사가패턴을 팀원들이 안 쓰려고 한 이유는 무엇일까? 에 대한 답은 너무 명확하다 닭 잡는데 소 잡는 칼을 쓸 것인가를 판단해봤을 때, 닭 잡는 칼을 쓰는 게 낫다고 판단했기 때문이다 아키텍쳐 결정 시에 단순히 기술적으로 적용 가능한지 여부를 떠나서, 다양한 요소들을 고려해야하는데, 그런 고려사항들을 놓친 게 아닐까 싶다. | ||
| - 각 상황에 따라 어떤 정답이 있는 것도 아니고, 최초 의사결정 때의 상황을 기준으로 아키텍쳐 의사 결정을 하더라도 상황에 따라서 전혀 예상치 못하게 변경되는 경우가 생기기 때문에, 아키텍처 레벨에서는 일단 시도해보고, 실패 혹은 성공을 통해서 배우는 방법밖에 없고, 그래서 학습비용이 비싼 게 아닐까 생각된다 | ||
| - 커플링은 의존성으로도 볼 수 있다 | ||
| - 아키텍쳐 퀀텀은 사실상 DB에 얼만큼 의존하고 있는지에 따라 갈리는데, 그래서 DB는 1개를 쓰면서, 여러 개의 MS로 나눴다고 하는 서비스들은 사실상 MSA 라고 보기보다는 분리된 모놀리식으로 보는 게 맞다는 생각이고 책에서는 서비스 기반 아키텍쳐라고 말하고 있다 | ||
| - 아키텍쳐 퀀텀이 1인 게 개인적으로 나쁘다고 생각하지는 않는 이유는, MSA를 경험해보면서, 너무 많은 MS 간 통신을 제어하고 메세지 유실과 분산 트랜잭션 등을 고민하는 비용이 너무 컸기 때문이다. 아키텍쳐 퀀텀이 1일 때의 분명한 단점은 동일한 서버가 여러 대이든, 도메인별로 분리된 서버가 여러 대이든, RDB에 SPOF가 있다는 점이다 but, 서비스 자체에 트래픽이 많지 않고, 서비스 유지보수할 인원도 적은 상태에서, DB로 인한 가용성/내고장성의 영향이 크지 않다면, 그냥 MSA를 애초에 고려하지 않는 것도 한 가지 방법이라고 생각한다 | ||
| - 실제로 회사에서 이벤트 드리븐 기반의 MSA 설계 및 개발을 진행하면서, 느낀점은 MSA를 하면서, 얻는 이점도 분명히 있지만, 그에 따른 단점도 매우 크다는 점이 였다. 같은 서비스 였다면, 그냥 함수 호출 한 번으로 끝났을 일이, 이벤트를 정의하는 것부터, 적용하는 것까지, 관련된 MS 담당자들이 모두 챙겨야 하는 게 번거롭다고 생각한 적이 있었다(여기에 의견이 일치하지 않을 때, 병목이 생기는 것은 덤이고..), 또한 이벤트가 유실되었을 때 어떻게 할 것인지, 이벤트 수행이 실패했을 때, 롤백은 어떻게 처리할 것인지 등등 고려해야 할 것들이 너무 많았던 걸로 기억한다 |
There was a problem hiding this comment.
이 파일에도 1.md와 동일한 마크다운 리스트 형식 문제가 있습니다. 각 항목이 들여쓰기 때문에 코드 블록으로 렌더링될 수 있으니, 표준 리스트 문법으로 수정하는 것을 권장합니다.
더불어, 내용 중 몇 군데 어색한 표현이나 오타가 있어 함께 수정하면 가독성이 향상될 것 같습니다.
- 33행:
...판단했기 때문이다 아키텍쳐...->...판단했기 때문이다. 아키텍쳐...(마침표 뒤 공백 추가) - 38행:
...있다는 점이 였다.->...있다는 점이었습니다.또는...있다는 점이었다.(오타 수정)
| - 책에서는 MSA를 통해서 모든 문제가 해결된다는 식으로 말하고 있진 않지만, 대체적으로 모놀리식은 문제있고, MSA는 이런 저런 장점이 있기 때문에 문제 해결이 가능할 거다 라는 식으로 논리를 전개하고 있다. 책에서 말한대로, 모놀리식을 MSA로 대체함으로써, 아키텍쳐 민첩성이 확보된다고 생각하시는지 궁금하다 만약 그렇다면, 본인이 생각하는 근거가 무엇인지 얘기해보면 좋을 거 같고, 그렇지 않다면, 그렇지 않다고 생각한 이유를 얘기해보면 좋을 거 같다 | ||
| - 나의 답변 | ||
| - 제가 생각하는 MSA의 단점은 MS 간 경계를 나누는 게 너무 어렵다는 것(사람마다 기준이 다르고, 상황마다 예전에는 맞았던 게, 이후에는 틀린 경우도 생김)과 회사의 인원이 적을 때, 이렇게 나눠진 MS들의 유지보수 관리가 힘들다는 점이다. 하지만, AI Agent 들이 점차 발전하면서, 사람이 부족한 이부분을 해결해 줄 수 있지 않을까 기대하고 있다 최근에는 [컬리의 AI agent 활용 사례](https://helloworld.kurly.com/blog/oms-claude-ai-workflow/)도 있었고, 이런 식으로 AI Agent를 적극 활용하는 방식으로 인원 부족으로 인한 유지보수 문제는 해결할 수 있지 않을까 기대하고 있다 다른 분들의 의견이 궁금하다 | ||
|
|
||
| ## 내용 요약 | ||
| - 모듈화 동인 | ||
| - 유지보수성 | ||
| - 얼마나 쉽게 추가, 변경, 삭제할 수 있는지 | ||
| - 시험성 | ||
| - 테스트의 완전성, 회귀테스트 가능성 | ||
| - 배포성 | ||
| - 배포의 용이함 | ||
| - 확장성과 탄력성 | ||
| - 부하가 증가해도 시스템 응답성을 유지하는 능력 | ||
| - 높은 확장성과 탄력성이 필요하다면, 서비스 간 동기 통신을 가능한 적게 유지해야 함 | ||
| - 가용성/내고장성 | ||
| - 특정 모듈에 문제가 생기더라도 서비스 전체에 영향이 가서는 안됨 | ||
| - 장애가 발생한 서비스에 동기적으로 의존하는 서비스가 있는 경우, 내고장성 달성이 힘들다 | ||
|
|
||
| ## 내 의견 | ||
| - 3장에서 팀이 직면한 문제는 모놀리식 아키텍쳐 구조가 급변하는 비즈니스 요구사항을 빠르게 충족하지 못한다는 것이다. 이에 해결책으로 제시하고 있는 것은 아키텍쳐 모듈화이다. 이를 통해서 아키텍쳐의 민첩성을 확보할 수 있게 되고, 그렇다면, 급변하는 비즈니스 요구사항에 대응이 가능하다는 논리이다. | ||
| - 틀린말은 아니지만, 어떤 상황이냐에 따라서, 구체적인 how는 달라질 수 있을 거 같고, 이 how를 어떻게 적용하는지가 사실상의 아키텍쳐 민첩성을 획득했느냐, 못했느냐의 차이로 이어질 것이라고 생각한다. (책에서 말한 내용은 너무 일반론적인 얘기라고 생각…) | ||
| - 개인적인 경험상 아키텍쳐 민첩성을 위해서 가장 필요한 것은 유지보수성을 확보하는 것이라고 생각한다 왜냐하면, 유지보수성이 확보가 되지 않아서, 프로젝트 추가 기능 및 개선사항들이 빠르게 반영되지 못한 적을 경험해보았기 때문이다. | ||
| - 추가로, 책에서는 MSA적용을 통해서, 기능 개발 시, 유지보수성에 도움이 됨을 어필하는데, 아주 성공적으로 MSA 경계가 잘 나눠진 상태에서, 다른 MS 와 아무 결합도가 없는 상태의 기능 개발에만 해당되는 얘기라는 말은 없어서 아쉬웠다. 실제로는 MSA 경계가 잘 나눠지지 않은 탓에, MS 간 결합도가 생겨서, 기능 개발에 더 시간이 오래 걸린 경험도 많았기 때문이다 | ||
| - 시험성 부분에서 말하는 모놀리식에서 작은 수정에도 전체 테스트 케이스를 돌려야하는 문제는 어떤 관점에서는 문제가 맞지만, 프로젝트의 도메인별 모듈화를 잘 해둬서, 어떤 수정이 발생 했을 때, 영향도를 최소화 되도록 한다면, 충분히 모놀리식에서도 꼭 전체 테스트를 돌리지 않더라도, 회귀테스트를 효율적으로 진행 할 수 있다고 생각한다 | ||
| - 다만, MSA로 나눠지면서, 자연스럽게 코드가 격리되면서, 시험성이 보장되는 부분은 장점이라고도 볼 수 있다고 생각한다 | ||
| - 배포성 관련해서 모놀리식의 가장 큰 문제점은 책에서 말하는 배포주기 라기 보다는 배포했을 때, 기능 격리와 관련된 문제라고 생각한다. 배포주기는 모놀리식이라도 빈도는 얼마든지 늘릴 수 있다고 생각한다 | ||
| - 확장성, 탄력성 문제도 비슷한 맥락인데, 모놀리식에서도 충분히 대응할 수 있다고 생각하고, 회사 상황에 따라서, 결정은 언제든 달라질 수 있다고 생각한다 만약 우리 회사의 앞으로의 방향이 반드시 탄력성과 확장성을 보장해야만하는 이벤트들이 계속 있다면, 당연하게도 처음부터 확장성과 탄력성을 최대한으로 할 수 있는 아키텍쳐를 고려하는 게 맞다 하지만, 가끔씩 있는 이벤트만 있는 상황이라면, 이 가끔있는 이벤트 한두 번을 위해서 전체 아키텍쳐를 변경하는 것은 분명한 낭비라고 볼 수 있을 거 같다 이런 경우는 기존 모놀리식 구조를 유지하면서, 이벤트 트래픽 처리를 위한 별도 인프라를 구성할 수도 있고, 혹은 스케일 업/아웃 으로 대응해보는 것을 고민해보는 게 먼저라고 생각한다 | ||
| - 그리고 책에서도 나오지만, MSA를 하더라도, 특정 MS에 트래픽이 몰리게 될 때, 동기통신으로 통신하는 다른 MS들도 같이 트래픽 영향을 받게 되기 때문에 이부분에 대해서도 대용량 트래픽 대비를 위해서 설계를 하는 입장에서는 반드시 고려해야 할 부분이다 | ||
| - 가용성/내고장성의 경우에 확실히 MSA가 유리한 게 맞지만, 이 또한 MSA 설계를 잘못한다면, MSA의 장점을 살리지 못하고, 문제가 발생할 수 있다(책에 나온 동기통신 혹은 MSA 경계를 잘못나눴을 때) | ||
| - 96page 의 ADR 문서는 책의 예제로 설명하기 위해서, 어쩔 수 없이 개략적으로만 작성되었겠지만, 너무 개략적으로만 작성된 것 같다는 생각이 들었다 |
There was a problem hiding this comment.
이 파일 역시 다른 마크다운 파일들과 마찬가지로 리스트 형식이 코드 블록으로 처리될 수 있습니다. 가독성을 위해 표준 마크다운 리스트 문법으로 수정하는 것이 좋겠습니다.
추가로, 내용 중 일부 표현을 다듬으면 더 자연스러울 것 같습니다.
- 25행:
(책에서 말한 내용은 너무 일반론적인 얘기라고 생각…)->(책에서 말한 내용은 너무 일반론적인 얘기라고 생각합니다.)(문장 마무리) - 27행:
다른 MS 와 아무 결합도가->다른 MS와 아무 결합도가(띄어쓰기 수정)
…ine the PR creation process.
| # 메인 실행 | ||
| main() { | ||
| check_prerequisites | ||
|
|
||
| get_title | ||
| get_body | ||
|
|
||
| # Dry-run 확인 | ||
| read -p "PR을 생성하기 전에 미리보기를 보시겠습니까? (Y/n): " show_preview | ||
| if [[ ! "$show_preview" =~ ^[Nn]$ ]]; then | ||
| dry_run | ||
| read -p "위 내용으로 PR을 생성하시겠습니까? (Y/n): " confirm | ||
| if [[ "$confirm" =~ ^[Nn]$ ]]; then | ||
| echo "PR 생성이 취소되었습니다." | ||
| exit 0 | ||
| fi | ||
| fi | ||
|
|
||
| # PR 생성 | ||
| echo "PR을 생성하는 중..." | ||
| if gh pr create \ | ||
| -t "$TITLE" \ | ||
| -b "$BODY" \ | ||
| -r "$REVIEWERS" \ |
There was a problem hiding this comment.
PR 생성 스크립트 업그레이드 해보았습니다(바이브 코딩으로 작성)
해당 PR 생성 시 써봤는데, 잘 되는 것 확인 하였습니다 🙇🏻
dhlee3994
left a comment
dhlee3994
left a comment
There was a problem hiding this comment.
이미지는 어떤 AI를 사용하신건가요? 👀
|  | ||
|
|
||
| ## 논의 주제 | ||
| - AI 시대에 1장에 나온 내용들을 어떻게 활용해볼 수 있을지 본인의 생각을 나눠보면 좋을 거 같다 |
There was a problem hiding this comment.
수동 피트니스 함수 영역 중 일부분은 AI의 도움을 받을 수 있을 것 같습니다.
AI는 확률 머신이기에 완전한 자동화는 어려울 것 같지만 AI가 1차적으로 검토하여 리포팅하면 아키텍트는 이 중 가장 적절한 선택을 내리는 식으로 반자동화할 수 있을 것 같습니다.
|  | ||
|
|
||
| ## 논의 주제 | ||
| - MSA 설계 시에, 본인이 생각하는 적절한 MS 사이즈의 기준이 있다면 공유해보면 좋을거 같다 |
There was a problem hiding this comment.
MS의 적정 사이즈를 수치화할 수 없다는 점이 답답한 것 같습니다. (저는 은탄환을 좋아합니다.)
저는 비즈니스 응집도라는 정성적인 기준을 사용합니다.
- 같은 단어라도 도메인에 따라 의미가 달라지기 시작하면 서로 다른 서비스가 섞여있다라고 판단합니다.
- 비즈니스 라이프사이클의 일치여부를 확인합니다. 일치하지 않는다면 다른 서비스가 섞여있다라고 판단합니다.
책 초반에 아키텍처 책이 드문이유를 설명하면서 모든 문제는 마치 눈송이와도 같다라고 했는데, 비즈니스가 성장하면서 상황이 바뀌기 때문에 MS의 적정 사이즈는 변할 수 밖에 없을 것 같습니다.
|  | ||
|
|
||
| ## 논의 주제 | ||
| - 책에서는 MSA를 통해서 모든 문제가 해결된다는 식으로 말하고 있진 않지만, 대체적으로 모놀리식은 문제있고, MSA는 이런 저런 장점이 있기 때문에 문제 해결이 가능할 거다 라는 식으로 논리를 전개하고 있다. 책에서 말한대로, 모놀리식을 MSA로 대체함으로써, 아키텍쳐 민첩성이 확보된다고 생각하시는지 궁금하다 만약 그렇다면, 본인이 생각하는 근거가 무엇인지 얘기해보면 좋을 거 같고, 그렇지 않다면, 그렇지 않다고 생각한 이유를 얘기해보면 좋을 거 같다 |
There was a problem hiding this comment.
MSA는 아키텍처 민첩성을 "보장"하지 않는다고 생각합니다.
개발, 운영 역량이 충분한 상태에서는 서비스들의 독립적인 배포, 확장이 가능해지면서 민첩성을 확보할 수 있습니다.
하지만 다음과 같은 이유로 오히려 모놀리식이 MSA보다 더 민첩할 수 있다고 생각합니다.
- MS 간 경계가 잘못 쪼개져 있는 경우
- 조직 구조가 MS 경계와 일치하지 않는 경우
- 빠른 개발을 위해 공용 라이브러리 재사용 등의 숨은 결합이 있는 경우
|  | ||
|
|
||
| ## 논의 주제 | ||
| - AI 시대에 1장에 나온 내용들을 어떻게 활용해볼 수 있을지 본인의 생각을 나눠보면 좋을 거 같다 |
There was a problem hiding this comment.
한빛컴퍼니 (?) 의 사례나, 책에서 자주 회자되었던 모놀리식이나 마이크로서비스 등의 아키텍처는 기 도입된 경우가 많고 인기가 있었던 아키텍처이기도 하니 (아무리 아키텍처에 베스트 프랙티스는 없다고 하지만) AI를 활용해서 도입하려는 아키텍처에 대해 충분한 정보를 미리 습득하는 데에 사용해볼 수 있을 것 같습니다
AI를 활용해서 ADR 문서도 시험삼아 작성해 본다면 책에서 오선빈의 사례처럼 무작정 모듈화를 하는 게 좋다는 식으로 상사를 설득시키는 일은 없을까 싶네요
|  | ||
|
|
||
| ## 논의 주제 | ||
| - MSA 설계 시에, 본인이 생각하는 적절한 MS 사이즈의 기준이 있다면 공유해보면 좋을거 같다 |
There was a problem hiding this comment.
요것도 어찌보면 1장에서 계속 나왔던 '아키텍처에는 정답이 없다' 와 비슷한 부분인 것 같습니다
과거에는 분명 적절히 모듈화되었다고 생각했던 부분이, 몇 달 뒤 새로운 기능을 추가하면서 아 이건 너무 크다 / 작다 싶어 다시 수정하거나, 과거에 추가했던 기능을 발전시키면서 걷잡을 수 없이 불어나는 경우도 왕왕 있었던 걸 생각하면
3장에 나오듯이 최대한 기민하게 대처하는게 최선이지 않을까 싶네요
jongfeel
left a comment
jongfeel
left a comment
There was a problem hiding this comment.
처음에 pull request 본문의 그림을 보고 외국의 블로그에서 이미지를 가져온건가? 라고 생각했었는데 AI가 만들어준 이미지라면 꽤 쓸만한데요?
그리고 MSA를 경험하셨다 보니 책을 상당히 분석적이고 비판적으로 읽었다는 느낌이 많이 드네요.
|  | ||
|
|
||
| ## 논의 주제 | ||
| - AI 시대에 1장에 나온 내용들을 어떻게 활용해볼 수 있을지 본인의 생각을 나눠보면 좋을 거 같다 |
There was a problem hiding this comment.
논의 주제에 대한 내용을 생각하고 적으려고 했는데 답변해 주신 내용이 제 생각과 비슷하긴 하네요.
저도 피트니스 함수에 AI를 사용한다면 그 결과를 내줄 수 있을 것이라 생각합니다.
책에서도 나온 내용이지만 아키텍처 특성에 대해 객관적인 지표를 잘 정의해 주면 충분히 활용해 볼 수 있을 것이라 봅니다.
|  | ||
|
|
||
| ## 논의 주제 | ||
| - MSA 설계 시에, 본인이 생각하는 적절한 MS 사이즈의 기준이 있다면 공유해보면 좋을거 같다 |
There was a problem hiding this comment.
아키텍처를 언급한 책 중에 서비스의 크기를 수치화 해서 알려주는 책이 있다면? (소스 코드 라인 수, 사용하는 메모리 크기, 노출한 공용 인터페이스 개수, 요청/응답 시간 평균 등등)
그 책이 이상한 책이겠죠? ㅎㅎ
동현님이 얘기하신 비즈니스 응집도에 따른 크기가 좋다고 봅니다.
|  | ||
|
|
||
| ## 논의 주제 | ||
| - 책에서는 MSA를 통해서 모든 문제가 해결된다는 식으로 말하고 있진 않지만, 대체적으로 모놀리식은 문제있고, MSA는 이런 저런 장점이 있기 때문에 문제 해결이 가능할 거다 라는 식으로 논리를 전개하고 있다. 책에서 말한대로, 모놀리식을 MSA로 대체함으로써, 아키텍쳐 민첩성이 확보된다고 생각하시는지 궁금하다 만약 그렇다면, 본인이 생각하는 근거가 무엇인지 얘기해보면 좋을 거 같고, 그렇지 않다면, 그렇지 않다고 생각한 이유를 얘기해보면 좋을 거 같다 |
There was a problem hiding this comment.
그 문제가 무엇이고 어떤 아키텍처 특성에 맞느냐가 선행되어야 하겠죠.
제가 읽고 있는 다른 아키텍처 책인 < 헤드퍼스트 소프트웨어 아키텍처 > 도 다양한 예시가 나오는데 일정, 성능, 기술적 능력 등에 큰 특성을 가져야 하고 나머지 특성은 트레이드오프 해도 되는 거라면 모놀리식이 나쁜게 아니라고 얘기합니다.
초반에 서비스의 크기가 작으면 상관 없는데 나중에 점점 커진다면 결국 MSA로 가게 되는 건 자연스러운 수순인 것 같습니다.
민첩성이라는 게 독립된 서비스들의 각 특성을 살리고 배포도 빠르게 할 수 있다는 점이 장점이지만, 이것도 비용으로 환상하면 태형님이 언급한 유지보수나 인력 추가의 단점을 안고 가야 하는 거라고 봅니다.
어쩌면 향후 몇 년 이내에 AI가 더 발전하면 이런 것도 해소가 될 수 있을 것 같기도 합니다.
|  | ||
|
|
||
| ## 논의 주제 | ||
| - MSA 설계 시에, 본인이 생각하는 적절한 MS 사이즈의 기준이 있다면 공유해보면 좋을거 같다 |
There was a problem hiding this comment.
다들 위에서 말씀하셨듯이 정답은 없다 생각하고, 다만 개발하면서 느낀건 쪼갤 수록 R&R이 명확해지고, 배포에 따른 장애 등 여러 이점이 있을거 같습니다. 그렇다고 너무 잘게 쪼개면 또 관리가 어려워서.... 뭔가 느낌상(리소스 관점) 할 수 있을만큼 쪼개는게 좋은거 같아요.
|  | ||
|
|
||
| ## 논의 주제 | ||
| - 책에서는 MSA를 통해서 모든 문제가 해결된다는 식으로 말하고 있진 않지만, 대체적으로 모놀리식은 문제있고, MSA는 이런 저런 장점이 있기 때문에 문제 해결이 가능할 거다 라는 식으로 논리를 전개하고 있다. 책에서 말한대로, 모놀리식을 MSA로 대체함으로써, 아키텍쳐 민첩성이 확보된다고 생각하시는지 궁금하다 만약 그렇다면, 본인이 생각하는 근거가 무엇인지 얘기해보면 좋을 거 같고, 그렇지 않다면, 그렇지 않다고 생각한 이유를 얘기해보면 좋을 거 같다 |
There was a problem hiding this comment.
제 생각에 '아키텍처 민첩성'이란 '얼마나 빠르게 변경하느냐' 뿐만 아니라 '얼마나 기존과 마찰을 하지 않냐' 두 가지를 의미한다고 생각합니다. 따라서 side effect, 독립적 배포 등을 생각한다면 MSA가 민첩성에 대해 더 효과적인 것 같습니다.
그러나 "보장한다" 라는 것은 100%를 의미하고, 반례가 존재할 수 있기 때문에 "보장하지 않는다" 라고 생각합니다.
결론적으로 "대부분의 경우" "MSA"하는 것이 아키텍처 민첩성에 유리하다 라고 생각합니다.
notebooklm 에 있는 인포그래픽, 슬라이드쇼 기능으로 생성 했습니다 
|
올해에는