소프트웨어 아키텍처 The Hard Parts sprint 4 - 권태형

[TaeHyoungKwon]

소감

• 마이크로서비스를 설계하고 운영하면서, 최소한 1번은 무조건 고민해보았을 만한 내용들이 나와서 주의깊게 읽어보게 되었다
• MSA 에 대한 면접 질문 용으로도 괜찮은 주제들 이였다

Overview

---

논의주제

---

Closes #607

[github-actions]

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

[gemini-code-assist]

Summary of Changes

Hello @TaeHyoungKwon, 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 2판'의 8장과 9장에 대한 학습 노트와 저자의 개인적인 경험 및 생각을 추가합니다. 8장에서는 마이크로서비스의 코드 재사용 전략과 그 트레이드오프를 다루며, 9장에서는 데이터 오너십과 분산 트랜잭션의 다양한 접근 방식에 대한 깊이 있는 통찰을 제공합니다. 이는 마이크로서비스 아키텍처 설계 시 고려해야 할 핵심적인 문제들에 대한 이해를 돕고, 실제 운영 경험을 바탕으로 한 실용적인 관점을 제시합니다.

Highlights

• 챕터 8 학습 노트 추가: 마이크로서비스 환경에서의 코드 재사용 전략(코드 복제, 공유 라이브러리, 공유 서비스, 사이드카)에 대한 논의 주제, 요약, 키워드 및 개인적인 경험과 생각을 담은 학습 노트를 추가했습니다.
• 챕터 9 학습 노트 추가: 데이터 오너십(단독, 공통, 공동, 서비스 통합)과 분산 트랜잭션(ACID, BASE, 최종 일관성 패턴)에 대한 논의 주제, 요약, 키워드 및 개인적인 경험과 생각을 담은 학습 노트를 추가했습니다.

🧠 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

• 2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/8.md
  • 챕터 8의 학습 내용 및 개인적인 경험과 생각을 추가했습니다.
  • 마이크로서비스 환경에서의 코드 재사용 전략(코드 복제, 공유 라이브러리, 공유 서비스, 사이드카)에 대한 논의 주제, 요약, 키워드, 그리고 저자의 생각을 포함합니다.
• 2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/9.md
  • 챕터 9의 학습 내용 및 개인적인 경험과 생각을 추가했습니다.
  • 데이터 오너십(단독, 공통, 공동, 서비스 통합)과 분산 트랜잭션(ACID, BASE, 최종 일관성 패턴)에 대한 논의 주제, 요약, 키워드, 그리고 저자의 생각을 포함합니다.

Activity

• 이 PR은 이슈 #607을 닫기 위해 생성되었습니다.

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.

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

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

안녕하세요, 권태형님. 소프트웨어 아키텍처 책의 8장과 9장에 대한 요약 및 생각을 정리한 마크다운 파일을 추가해주셨네요. 내용 정리가 잘 되어 있어 책의 핵심 개념과 그에 대한 깊은 고민을 엿볼 수 있었습니다.

전반적으로 가독성을 높이기 위해 몇 가지 문법 및 서식 수정을 제안드렸습니다. 주로 띄어쓰기, 마침표 사용, 표현의 일관성에 대한 부분입니다. 이러한 작은 수정들이 모여 문서를 더욱 명확하고 전문적으로 만들어 줄 것이라 생각합니다.

자세한 내용은 각 파일의 개별 코멘트를 확인해주세요. 감사합니다.

[jongfeel]

매번 "내 생각" 부분을 읽어보는데, 태형님 회사 사정을 들여다보는 것 같은 느낌이 들어서 간접 경험 및 이해가 되는 부분이 있는 것 같습니다.

[jongfeel]

저는 최악 까지는 없었던 것 같습니다.
조금 귀찮다고 느꼈던 건 공유 라이브러리 방식을 사용하면서 생기는 문제인데 태형님이 겪었던 문제와 비슷합니다.
재배포시에 버전 체크 하고 운영 전 테스트를 진행해야 했기 때문에 이걸 자주 업데이트하면 안되겠다는 본능이 생기긴 하더라고요. 하다 보면 자연스럽게 책에서 얘기하는 변경 빈도수를 체감하게 되는 것 같습니다.

최고의 경험은 아이러니하게도 코드 복제가 큰 문제 없이 잘 굴러가더라는 점이었습니다.
마찬가지로 비즈니스 로직 중복 코드 수준이 아니라 공통 적용 코드에 대해 필요 도메인마다 파라미터만 조금 다르게 써야 했는데 코드 복제해서 조금 변경해서 썼었습니다.
코드 복제가 재사용의 적인 것 처럼 생각이 들 수 있지만, 실제 운영에 재사용하는 코드들은 문제를 일으키지 않았습니다. 아마 복붙하면서도 복제가 낫겠다라는 생각이 들어서 그런 걸 수도 있습니다.

[dhlee3994]

변경이 거의 없는 공유 라이브러리를 사용하는 시스템이 보안 감사 대상으로 지정된 후, 짧은 기간 동안 여러 번 업데이트가 되는 일이 있었는데 정말 귀찮았었습니다.
그 이후로는 변경된 적이 없기는 해서 그냥 '똥 밟았다'라고 생각했었네요.

[jongfeel]

사실 그게 정석이고 맞다고 보는 입장인데, 이게 설계 때 의도하지 않았고 다른 팀에게 알려주지 않는 서비스의 등장이 분산 트랜잭션이 되지 않게 고민하는 것 보다 먼저 튀어나와서 그렇지 않을까 추측해 봅니다.

그리고 서비스를 과도하게 나누지 않고 설계해도 지난 시간에 논의했던 것처럼 인력이 많아지고 담당해야 하는 서비스들이 적으면 세분화의 욕구(?)가 생기게 되면 그걸 또 나눠서 관리하는 일이 벌어지는 문제점이 생기지 않을까 싶습니다.

[dhlee3994]

변경이 거의 없는 공유 라이브러리를 사용하는 시스템이 보안 감사 대상으로 지정된 후, 짧은 기간 동안 여러 번 업데이트가 되는 일이 있었는데 정말 귀찮았었습니다.
그 이후로는 변경된 적이 없기는 해서 그냥 '똥 밟았다'라고 생각했었네요.

[GeunJuLEE]

저도 유지 보수가 힘들었던 적은 있었어도, 최악까지는 없었던거 같습니다. 뭔가 모두 장단점을 가지고, 그 상황에서 나름의 베스트를 사용했고, 그 선택으로 인해 힘들었던 부분만 기억이 나서 그럴거 같습니다. 나름의 장점 또한 있었던거 같습니다.