소프트웨어 아키텍쳐 The hard parts 5주, 6주차 - 최지윤

[chichoon]

한달 내내 야근하고 어제부터 감기몸살에 시달려서 업로드가 늦었습니다.. (핑계)

트랜잭션 사가 부터는 이해가 안되어서 논의점으로 적을 것이 마땅히 없었습니다

[github-actions]

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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" 스터디의 5주차 및 6주차 학습 내용을 담은 요약 노트를 추가합니다. 분산 데이터 액세스, 분산 워크플로 관리, 트랜잭셔널 사가, 아키텍처 계약, 분석 데이터 관리, 그리고 트레이드오프 분석 기법 등 소프트웨어 아키텍처의 핵심 주제들을 다루고 있습니다. 저자는 개인적인 어려움 속에서도 학습 내용을 정리하여 공유하고자 노력했습니다.

Highlights

• 분산 데이터 액세스 패턴 추가: 컬럼 스키마 복제, 복제 캐싱, 데이터 도메인 패턴 등 분산 환경에서의 데이터 액세스 전략에 대한 요약이 추가되었습니다.
• 분산 워크플로 관리 방식 정리: 오케스트레이션과 코레오그래피 통신 스타일의 장단점 및 워크플로 상태 관리 기법에 대한 내용이 포함되었습니다.
• 다양한 트랜잭셔널 사가 패턴 분석: 에픽 사가, 폰 태그 사가, 페어리테일 사가 등 여러 사가 패턴의 특징, 일관성 모델, 통신 방식 및 트레이드오프가 상세히 설명되었습니다.
• 아키텍처 계약의 중요성 강조: 엄격한 계약과 느슨한 계약의 비교, 컨슈머 주도 계약, 스탬프 커플링 등 아키텍처 계약에 대한 내용이 추가되었습니다.
• 분석 데이터 관리 방식 비교: 데이터 웨어하우스, 데이터 레이크, 데이터 메시 등 분석 데이터 관리 패턴의 진화와 특징이 요약되었습니다.
• 트레이드오프 분석 기법 제시: 아키텍처 설계 시 트레이드오프를 분석하는 3단계 과정과 정성적/정량적 분석, MECE 리스트, 콘텍스트 왜곡의 함정 등 실용적인 기법들이 소개되었습니다.

🧠 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 Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

전반적으로 소프트웨어 아키텍처의 여러 주제에 대해 잘 정리해주셨습니다. 다만 몇 가지 내용상 오류나 오타가 있어 리뷰를 남깁니다. 또한, 파일명과 파일 내부의 챕터 번호가 일치하지 않는 점(예: 09.md 파일에 10장 내용 기재)은 혼동을 줄 수 있으니 수정하는 것을 고려해보시는 것이 좋겠습니다.

[gemini-code-assist]

'앤솔로지 사가'의 확장성/탄력성에 대한 설명에 오류가 있는 것 같습니다. "결합도가 낮으므로 같이 낮음"이라고 작성하셨는데, 일반적으로 아키텍처에서 결합도(coupling)가 낮을수록 확장성(scalability)과 탄력성(elasticity)은 높아지는 경향이 있습니다. 다른 사가 패턴 설명에서도 낮은 결합도가 높은 확장성으로 이어진다고 기술하신 부분과도 상반됩니다. "결합도가 낮으므로 확장성 및 탄력성이 높음"으로 수정하는 것이 정확한 표현으로 보입니다.

Suggested change

	- 확장성, 탄력성은 결합도가 낮으므로 같이 낮음
	- 확장성, 탄력성은 결합도가 낮으므로 같이 높음

[TaeHyoungKwon]

책 문맥에서 말하는 일반적인 오케스트레이터 는 어떤 작업을 총괄해서 조정(coordinate) 하는 역할로 이해 했습니다. 이 하위에 구체적으로 ESB(Enterprise Service Bus)가 있고, MSA 환경 하에서의 오케스트레이터로 나뉠 수 있을거 같은데요

말씀하신 ESB(Enterprise Service Bus)는 전체 시스템의 조정을 담당하는 중앙 시스템? 정도로 이해 했습니다(실제 제품이 무엇이 있는지 찾아보니, 다 저는 처음 들어보는 제품들이라서 저도 잘 와닿진 않네요)

반면에, 이 장에서 말하는 MSA 환경 하에서의 오케스트레이터와는 확실히 차이가 있는 것이, MSA 환경 하에서의 워크 플로우는 좀 더 작은? 혹은 구체적인 개념입니다. 예를 들자면, 어떤 워크플로우(예를 들면, 주문 전달, 재고 처리, 회원 가입 등)에 대한 조정을 담당하는 시스템으로 볼 수 있을거 같습니다

이 맥락 하에서, ESB는 서비스간 결합을 유도하기 때문에 오케스트레이션이랑 차이가 있다고 한다. 를 이해해보자면, ESB는 전체 시스템의 조정을 담당하는 중앙 시스템이기 때문에, 그 하위 워크플로우를 조정하는 MSA 환경 하에서의 오케스트레이터 보다는 상대적으로 결합도가 더 높다고 볼 수 있을거 같고, 이것을 차이가 있다고 표현한 것이 아닌가 생각 되네요