Conversation
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
TaeHyoungKwon
added
2026
Software Architecture: The Hard Parts
TaeHyoungKwon
requested review from
GeunJuLEE,
benscookie,
chichoon,
dhlee3994,
jongfeel,
tttghost and
ymkim97
|
우측에 있는 |
Summary of ChangesHello, 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" 스터디 그룹의 일환으로, 10장, 11장, 12장에 대한 개인 학습 노트와 토론 주제를 추가합니다. 각 장에서는 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. Changelog
Activity
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.
Code Review
소프트웨어 아키텍처 'The Hard Parts' 10, 11, 12장에 대한 요약 및 생각을 정리한 마크다운 파일을 추가하셨네요. 각 장의 핵심 내용을 잘 정리하고, 실무 경험을 바탕으로 한 깊이 있는 고민을 공유해주셔서 좋습니다. 몇 가지 사소한 오타와 서식 문제를 수정하면 문서가 더 명확해질 것 같습니다.
Note: Security Review has been skipped due to the limited scope of the PR.
| - 컬럼 스키마 복제 패턴에서, 데이터 오너십 통제가 어렵다는 것이 딱히 틀린 얘기는 아니지만, 일반적으로 이벤트를 통해서 해당 값의 CUD 를 제어하는 것외에 별도로 값을 수정하진 않는 거 같다. 즉, 실제로 데이터 오너가 다른 MS 에 저장된 데이터가 오염될 수 있다는 걱정을 하지만, 이벤트를 구독하는 MS에서도 사실 그 데이터를 따로 가공하거나 하지 않는다는 것이다 | ||
| - 회사에서 컬럼 스키마 복제 패턴을 많이 사용하는데, 사내에서도 사용 사례를 살펴보면, 사실상 서비스 간 통신 패턴과 양분되어 있는 것 같다. 그래서 대개는 둘 중에 어떤 것을 할지 선택의 기로에 서게 되는데, 그 판단 기준은 상황에 따라, 담당자가 누군지에 따라서 다른데 대개의 기준은 어떤 값이 필요한데, DB에 저장할만한 가치가 있는가? 를 기준으로 DB에 저장해서 내부에서 내가 데이터 오너인것 처럼 작업을 하는게 필요한 상황일 때는 컬럼 스키마 복제 패턴을 많이 활용하는 것 같다. 추가로, 도메인 경계 상 크게 관련이 없는 서비스 간에도, API 호출을 통해 의존성을 가지도록 하는 것 보다는 의존성이 없도록 하려는 목적으로 컬럼 스키마 복제 패턴을 많이 활용하는 것 같다. 이 결정을 할 때, 상황을 잘 고려해야하는데, 잘못 선택하는 순간 괜한 데이터를 DB에 가지고 있는 상황이 있을 수도 있고, 우리 서비스 경계와 전혀 다른 서비스에서 장애가 났는데, 그 장애가 전혀 관련 없는 우리 서비스까지 전파될 수도 있기 때문이다. 아무튼 상황에 맞춰서 판단해야한다 | ||
| - 복제 캐싱 모델의 경우, 내가 있는 회사의 환경에서는 경험해보지 못한 패턴이다. 경계 컨텍스트가 일치하는(즉, 같은 팀에서 운영하는 MS 범위) 환경에서는 편의상 써봄직할만한 것 같다 | ||
| - 데이터 도메인의 경우 경험해 본 적은 있지만, 합리적 의사결정에 의해 선택했다기보다는 부채로 남겨둔 것으로 보는게 맞을 것 같다 다행히, 데이터를 CUD 하는 주체가 확실하였고, 트래픽도 많지 않았기 때문에, 운영하면서 큰 문제는 없었지만, 책에서 나온대로, 만약에 전혀 다른 경계 컨텍스트를 가진 MS 끼리 묶는 경우엔, 서로 이 의존성 때문에 불편한 경우가 생기지 않을까 생각된다f No newline at end of file |
There was a problem hiding this comment.
문장 끝에 의도하지 않은 문자 'f'가 포함되어 있습니다. 제거하는 것이 좋겠습니다.
| - 데이터 도메인의 경우 경험해 본 적은 있지만, 합리적 의사결정에 의해 선택했다기보다는 부채로 남겨둔 것으로 보는게 맞을 것 같다 다행히, 데이터를 CUD 하는 주체가 확실하였고, 트래픽도 많지 않았기 때문에, 운영하면서 큰 문제는 없었지만, 책에서 나온대로, 만약에 전혀 다른 경계 컨텍스트를 가진 MS 끼리 묶는 경우엔, 서로 이 의존성 때문에 불편한 경우가 생기지 않을까 생각된다f | |
| - 데이터 도메인의 경우 경험해 본 적은 있지만, 합리적 의사결정에 의해 선택했다기보다는 부채로 남겨둔 것으로 보는게 맞을 것 같다 다행히, 데이터를 CUD 하는 주체가 확실하였고, 트래픽도 많지 않았기 때문에, 운영하면서 큰 문제는 없었지만, 책에서 나온대로, 만약에 전혀 다른 경계 컨텍스트를 가진 MS 끼리 묶는 경우엔, 서로 이 의존성 때문에 불편한 경우가 생기지 않을까 생각된다 |
| - 11-5 그림에서, 책에서는 주문서비스에 주문정보를 먼저 업데이트 하는 것을 먼저 수행되도록 전제하여서 말하고 있는데, 결제완료부터 되고 나서 주문 서비스에 주문정보를 업데이트 하는게 관리차원에서 더 낫지 않을까? 라는 생각이 들었다 | ||
| - 오케스트레이션의 경우엔, 책에선 복잡한 flow를 처리할 때 더 좋은 선택일 수 있음을 말하는데, 사실 이 사유 보다는 팀의 상황이 어떻게냐에 따라서, 오케스트레이션 혹은 코레오그래피가 갈리지 않을까 생각된다. 팀의 상황이 모든 개발자가 하나의 개발팀으로써 오케스트레이션 역할을 하는 MS를 메인으로 활용하고 있다고 한다면, 오케스트레이션의 대상이 되는 MS들은 오케스트레이터의 명령을 수행하는 수동적인 형태가 될 수밖에 없을 거 같고, MS 설계도 요런 형태로 되지 않을까 싶다. 반대로 팀 자체가 각 도메인 경계 별로 확실히 나누어져 있고, 각 팀의 목소리와 권력이 각각 비슷비슷 하다면, 자연스럽게 코레오그래피 형태로 가지 않을까 생각된다 | ||
| - 현재 회사에서는 주문 워크플로우를 코레오그래피로 구성해서 처리하고 있고, 상태관리는 완전히 같진 않지만, 프런트 컨트롤러 패턴으로 진행하고 있다 | ||
| - No newline at end of file |
There was a problem hiding this comment.
내용이 없는 빈 목록 항목이 있습니다. 이 줄을 제거하여 문서를 깔끔하게 정리하는 것이 좋겠습니다.
| - 각각 사가 패턴들의 특징들과 주의해야할점들 등등을 보면, 결국에는 상황에 따른, 최악이 아닌 선택이 있을뿐이고, 상황이 변경됨에 따라서 그에 맞게 아키텍쳐도 변경이되어야만 흔히 말하는 지옥을 겪지 않을 수 있지 않을까? 라는 생각이 들었다. but, 아키텍쳐 레벨에서의 구조 변경은 코드를 변경하는 수준 보다도 훨씬더 부담스럽고 큰 작업이기 때문에, 대부분의 회사에서는 어쩔 수 없이 지옥에 가더라도 그걸 순순히 받아들이고, 유지보수에 열을 올리는게 아닌가? 라는 생각이 들었다 | ||
| - 이 장에서 제공하는 사가 패턴들의 경우는 특정 패턴을 하나 정해서, 서비스에 적용하는 형태로 하는 것 보다, 우리 서비스의 어떤 워크플로우를 어떻게 관리할 것인지에 대한 설계가 선행되어야 한다고 생각한다. 선 설계가 된 이후에, 책에 있는 패턴들에 매칭되는 것을 찾고, 어떤 점들을 신경써야할지 설계를 검토하거나 구현 이후에 운영에 참고를 하는 방식으로 사용되면 좋지 않을까? 라는 생각이 들었다 | ||
| - 맨 마지막에 나오는 사례는 실제 실무에서도 충분히 있을법한 일로 보이고, 이게 바로 MSA의 지옥이라고 볼 수 있다고 생각된다. 책에서 제시한 아주 복잡하게 꼬이는 상황이 평시에는 잘 발생하지 않지만, 장애가 발생할 때 문제가 발생할 가능성이 높아지고, 장애 처리가 오래걸리는 원인이 된다 | ||
| - 맨 마지막 노건우님이 말하는 테일 사가 혹은 패러렐 사가패턴을 고려해보라고 하면서, 하는 얘기는 실제 현재 실무에서도 활용되고 있다. 가게 사장님이 주문을 수락 하는 경우에, 수락 요청이 중간 MS에서 어떤 사유로 실패하더라도, 주문을 취소 시키지 않는데, 그 이유는 회사와 사장님 입장에서는 주문을 최대한 수용하는게 더 이득이기 때문이다. 그래서 실패가 탐지되면, 내부 MS들에서 문제 원인을 빠르게 확인하고 자동 혹은 수동으로라도 주문 자체가 정상처리될 수 있도록 하는데, 이부분이 해당 하는 사례로 볼 수 있을거 같고, 결국 최종 일관성만 만족하면 되기 때문에 가능한 것으로 볼 수 있다 No newline at end of file |
There was a problem hiding this comment.
그게 "스타벅스는 2단계 커밋을 하지 않는다" 라는 표현으로 책에 나와 있는데,
궁금해서 찾아보니까 실세계에서는 주문과 커피 제조를 동기화해서 진행하지 않는다를 표현한 말이더군요.
그래서 스타벅스는 2단계 커밋을 하지 않는다라는 문장을 기억에 두면 좋겠다는 생각을 했습니다.
| # 12장 | ||
|
|
||
| - 논의주제 | ||
| - 현재 실무에서 MSA 환경에서 MS를 운영하고 있을 때, 현재 본인의 팀에서 적용하고 있는 트랜잭션 관리 방법이 어떤 것이 있고, 관련된 장단점을 얘기해보면 좋을것 같습니다 |
There was a problem hiding this comment.
저는 책을 읽으면서 상상으로만 보기 때문에 워크플로의 복잡성을 매우 단순화 한다면 앤솔로지 사가가 좋아 보인다는 생각을 하긴 했습니다.
| # 11장 | ||
|
|
||
| - 논의주제 | ||
| - 책 내용을 봤을 때, 오케스트레이션과 코레오그래피 + 프론트 컨트롤러는 거의 같은 것으로 보입니다. 차이가 있다면, 오케스트레이션에서의 오케스트레이터는 워크플로우 자체만 신경 쓰는 MS 라는 점이고, 코레오그래피의 프론트 컨트롤러는 MS 자체에서 처리하는 비즈니스로직도 있으면서, 워크플로우의 상태관리 까지 책임지는 느낌 입니다. 이 상황에서 발생하는 문제들은 워크플로우가 복잡할것을 고려해서 오케스트레이션 방식을 선택했지만, 워크플로우가 별로 복잡하지 않은 경우에 오버엔지니어링 일 수 있다는 것, 그리고, 응답성과 확장성 때문에 코레오그래피 + 워크플로우를 선택 했지만, 워크플로우가 너무 복잡해지는 문제가 생기는 경우 입니다. 각각의 경우 모두 문제가 생겼을 때, 반대로 돌아가기에 선택의 부담이 크다고 느껴지는데요 이런 상황에서 각각 어떤 선택을 하실지에 대해서 궁금하고, 실제 사례도 있다면 얘기해보면 좋을거 같습니다 |
There was a problem hiding this comment.
저라면 워크플로가 복잡하다면 명시적으로 오케스트레이터가 워크플로를 책임지게 하는게 좋다고 보고
단순하다면 코레오그래피를 선택하되 프론트 컨트롤러의 책임을 조금 가져가게 하는 방향이 좋다고 봅니다.
하지만 이건 상상일 뿐이고, 이걸 개발해 나가면서 판단하고 결정해서 다시 바꾸기에는 정말 쉽지 않을 것 같다는 것도 상상해 볼 수 있는데 상상만으로도 힘들 것 같다는 생각이 드네요.
| # 10장 | ||
|
|
||
| - 논의주제 | ||
| - 일반적인 MSA 환경에서, 내 것이 아닌 데이터를 조회하기 위해서 가장 많이 사용하는 패턴은 서비스 간 통신 패턴과 컬럼 스키마 복제 패턴이라고 생각하고, 대개의 경우 둘 중에 하나를 선택하는 것 같습니다. 본인의 기준이 어떻게 되는지에 대해서 추가로 의견 나눠보면 좋을 것 같습니다 |
There was a problem hiding this comment.
서비스간 통신이 일반적이고 캐싱하는 것 까지가 성능 문제를 어느 정도 해결하는 것이라고 생각하는데
책에서는 다른 방법에 대해 언급을 해서 선택의 폭을 넓힐 수 있을 것도 같습니다.
There was a problem hiding this comment.
'내 생각'에서 적어주신 것 처럼 기본적으로 서비스간 통신을 사용하는 것 같습니다.
사용량이 많지 않아서 스키마 복제와 같은 방법은 고려하지 않았었네요.
There was a problem hiding this comment.
해당 데이터가 얼마나 조회되냐와 변경이 되냐 혹은 얼마나 자주 변경되는지에 따라 달린거 같습니다.
| # 10장 | ||
|
|
||
| - 논의주제 | ||
| - 일반적인 MSA 환경에서, 내 것이 아닌 데이터를 조회하기 위해서 가장 많이 사용하는 패턴은 서비스 간 통신 패턴과 컬럼 스키마 복제 패턴이라고 생각하고, 대개의 경우 둘 중에 하나를 선택하는 것 같습니다. 본인의 기준이 어떻게 되는지에 대해서 추가로 의견 나눠보면 좋을 것 같습니다 |
There was a problem hiding this comment.
'내 생각'에서 적어주신 것 처럼 기본적으로 서비스간 통신을 사용하는 것 같습니다.
사용량이 많지 않아서 스키마 복제와 같은 방법은 고려하지 않았었네요.
5 participants
Closes #618
챕터 12의 8개의 사가패턴의 특징과 장단점 등을 3d 큐브와 시퀀스 다이어그램으로 확인해볼 수 있도록 작업 해보았습니다 참고 부탁 드립니다 🙇🏻 (작업은 클로드 코드로 했습니다)
링크 / 코드