Conversation
|
우측에 있는 |
Summary of ChangesHello @benscookie, 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" 책의 4장부터 7장까지의 핵심 내용을 요약하고, 아키텍처 분해, 컴포넌트 패턴, 운영 데이터 분리 및 서비스 세분도에 대한 저자의 이해와 생각을 담고 있습니다. 또한, 실제 개발 환경에서 아키텍처 결정을 내릴 때 마주할 수 있는 실질적인 문제들에 대한 심도 깊은 논의 주제들을 제시하여, 이론적 지식을 넘어선 실무적 고민을 공유하고 있습니다. 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
|
benscookie
changed the title
benscookie
added
2026
Software Architecture: The Hard Parts
![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 3주차 스터디 요약 잘 읽었습니다. 4~7장에 대한 깊이 있는 이해와 함께 자신의 생각을 잘 정리해주셨습니다. 특히 책의 내용을 자신의 경험과 연결하여 구체적인 예시를 들어 설명한 부분이 인상 깊었습니다. 전반적으로 내용이 훌륭하지만, 몇 가지 부분에서 마크다운 문법을 활용하여 가독성을 높이거나, 문장을 더 자연스럽게 다듬을 수 있는 부분이 있어 몇 가지 제안을 드립니다. 자세한 내용은 각 파일의 리뷰 코멘트를 참고해주세요.
|
|
||
| # Chapter 05: 컴포넌트 기반 분해 패턴 | ||
|
|
||
| 이 챕터도 쉽게 읽히는 내용은 아니었다. 특히 "패턴"이라고 해서 단순히 읽고 넘길 수 있는 게 아니라, 단계별로 실제로 구조가 바뀌는 과정을 상상해야 해서 나에겐 한장한장 집중력이 꽤 필요했다. |
There was a problem hiding this comment.
가독성을 위해 '한장한장'을 '한 장 한 장'으로 띄어쓰는 것이 좋습니다.
| 이 챕터도 쉽게 읽히는 내용은 아니었다. 특히 "패턴"이라고 해서 단순히 읽고 넘길 수 있는 게 아니라, 단계별로 실제로 구조가 바뀌는 과정을 상상해야 해서 나에겐 한장한장 집중력이 꽤 필요했다. | |
| 이 챕터도 쉽게 읽히는 내용은 아니었다. 특히 "패턴"이라고 해서 단순히 읽고 넘길 수 있는 게 아니라, 단계별로 실제로 구조가 바뀌는 과정을 상상해야 해서 나에겐 한 장 한 장 집중력이 꽤 필요했다. |
|
|
||
| 이 챕터도 쉽게 읽히는 내용은 아니었다. 특히 "패턴"이라고 해서 단순히 읽고 넘길 수 있는 게 아니라, 단계별로 실제로 구조가 바뀌는 과정을 상상해야 해서 나에겐 한장한장 집중력이 꽤 필요했다. | ||
|
|
||
| 이번 챕터는 컴포넌트 기반 분해를 실제로 진행하는 과정을 6단계 패턴으로 설명한다. 1. 컴포넌트 식별 및 사이징 2. 공통 도메인 컴포넌트 수집 3. 컴포넌트 눌러펴기 4. 컴포넌트 디펜던시 결정 5. 컴포넌트 도메인 생성 6. 도메인 서비스 생성 |
There was a problem hiding this comment.
6단계 패턴을 한 줄로 나열하기보다 마크다운의 번호 목록 형식을 사용하면 가독성을 더 높일 수 있습니다.
| 이번 챕터는 컴포넌트 기반 분해를 실제로 진행하는 과정을 6단계 패턴으로 설명한다. 1. 컴포넌트 식별 및 사이징 2. 공통 도메인 컴포넌트 수집 3. 컴포넌트 눌러펴기 4. 컴포넌트 디펜던시 결정 5. 컴포넌트 도메인 생성 6. 도메인 서비스 생성 | |
| 이번 챕터는 컴포넌트 기반 분해를 실제로 진행하는 과정을 다음 6단계 패턴으로 설명합니다. | |
| 1. 컴포넌트 식별 및 사이징 | |
| 2. 공통 도메인 컴포넌트 수집 | |
| 3. 컴포넌트 눌러펴기 | |
| 4. 컴포넌트 디펜던시 결정 | |
| 5. 컴포넌트 도메인 생성 | |
| 6. 도메인 서비스 생성 |
|
|
||
| 책에서 데이터 아키텍처가 "왜 굳이 DB를 나눠야 하는데?"라고 버티는 장면이 인상 깊었다. 찾아보니까 실무에서도 DB 분리에 대한 저항이 제일 크다고 한다. 코드는 롤백이라도 하면 되는데, 데이터는 한번 꼬이면 복구가 어렵기 때문이라고. | ||
|
|
||
| DB를 나눠야 하는 이유로 변경 관리, 커넥션 관리, 확장성, 내고장성 같은 것들이 나오는데, 결국 핵심은 "장애 격리"와 "독립적 변경"이라고 이해했다. 스키마 바꿨는데 어떤 서비스가 터질지 모르는 상황, 서비스들이 DB 하나 바라보면서 커넥션 풀이 바닥나는 상황, DB 하나 죽으면 전체가 다 죽는 상황. 이런 걸 피하려면 DB도 나눠야 한다. 근데 지난 토론 때 다른 분들이 아키텍처 분해는 보통 운영 중 문제가 발생했을 때 진행한다고 하셨는데, DB 분해도 마찬가지인지 궁금해서 찾아봤다. 역시 대부분 운영 중에 문제가 터지고 나서야 진행한다고 한다. 처음부터 완벽하게 나누기보다는 모놀리스로 시작해서 필요할 때 분리하는 게 현실적이라는 얘기도 있었다. |
There was a problem hiding this comment.
문어체에서는 '근데'보다 '그런데'를 사용하는 것이 더 자연스럽습니다. 문맥의 흐름을 고려하여 수정하는 것을 제안합니다.
| DB를 나눠야 하는 이유로 변경 관리, 커넥션 관리, 확장성, 내고장성 같은 것들이 나오는데, 결국 핵심은 "장애 격리"와 "독립적 변경"이라고 이해했다. 스키마 바꿨는데 어떤 서비스가 터질지 모르는 상황, 서비스들이 DB 하나 바라보면서 커넥션 풀이 바닥나는 상황, DB 하나 죽으면 전체가 다 죽는 상황. 이런 걸 피하려면 DB도 나눠야 한다. 근데 지난 토론 때 다른 분들이 아키텍처 분해는 보통 운영 중 문제가 발생했을 때 진행한다고 하셨는데, DB 분해도 마찬가지인지 궁금해서 찾아봤다. 역시 대부분 운영 중에 문제가 터지고 나서야 진행한다고 한다. 처음부터 완벽하게 나누기보다는 모놀리스로 시작해서 필요할 때 분리하는 게 현실적이라는 얘기도 있었다. | |
| DB를 나눠야 하는 이유로 변경 관리, 커넥션 관리, 확장성, 내고장성 같은 것들이 나오는데, 결국 핵심은 "장애 격리"와 "독립적 변경"이라고 이해했다. 스키마 바꿨는데 어떤 서비스가 터질지 모르는 상황, 서비스들이 DB 하나 바라보면서 커넥션 풀이 바닥나는 상황, DB 하나 죽으면 전체가 다 죽는 상황. 이런 걸 피하려면 DB도 나눠야 한다. 그런데 지난 토론 때 다른 분들이 아키텍처 분해는 보통 운영 중 문제가 발생했을 때 진행한다고 하셨는데, DB 분해도 마찬가지인지 궁금해서 찾아봤다. 역시 대부분 운영 중에 문제가 터지고 나서야 진행한다고 한다. 처음부터 완벽하게 나누기보다는 모놀리스로 시작해서 필요할 때 분리하는 게 현실적이라는 얘기도 있었다. |
|
|
||
| 반대로 합쳐야 하는 이유도 있다. 외래 키로 엮여 있거나 조인이 필수인 테이블들은 분리하면 오히려 복잡해진다. ACID가 필요한 상황에서 억지로 나누면 Saga 같은 보상 로직이 필요해지는데, 찾아보니까 이게 구현하기 꽤 까다롭다고 한다. | ||
|
|
||
| 5단계 분해 프로세스가 나오는데, 도메인 정의 → 테이블 할당 → 커넥션 분리 → 스키마 이전 → 독립 운영 순서다. 동의어(별칭)를 활용해서 점진적으로 마이그레이션하는 팁이 나오는데, 한번에 다 바꾸는 게 아니라 별칭으로 연결해두고 서비스 하나씩 옮기는 방식이라고 한다. |
There was a problem hiding this comment.
5단계 분해 프로세스를 한 줄로 나열하기보다 마크다운의 번호 목록을 사용하면 가독성을 높일 수 있습니다. 화살표(→) 대신 번호 목록을 사용하면 각 단계를 더 명확하게 구분할 수 있습니다.
| 5단계 분해 프로세스가 나오는데, 도메인 정의 → 테이블 할당 → 커넥션 분리 → 스키마 이전 → 독립 운영 순서다. 동의어(별칭)를 활용해서 점진적으로 마이그레이션하는 팁이 나오는데, 한번에 다 바꾸는 게 아니라 별칭으로 연결해두고 서비스 하나씩 옮기는 방식이라고 한다. | |
| 5단계 분해 프로세스가 나오는데, 그 순서는 다음과 같습니다. | |
| 1. 도메인 정의 | |
| 2. 테이블 할당 | |
| 3. 커넥션 분리 | |
| 4. 스키마 이전 | |
| 5. 독립 운영 | |
| 동의어(별칭)를 활용해서 점진적으로 마이그레이션하는 팁이 나오는데, 한번에 다 바꾸는 게 아니라 별칭으로 연결해두고 서비스 하나씩 옮기는 방식이라고 한다. |
| - 서비스나 DB를 나눌 때 분해인/통합인을 실제로 정량화해서 판단해본 경험이 있으신가요? 있다면, 결국 이런 결정은 팀이나 사내에서 하게 될 텐데 각자 다른 생각을 가지고 있을 것 같습니다. 각자 주장이 맞다고 내세울 때 어떤 근거들을 들고, 그 근거들은 어떤 방식으로 가져오시는지 궁금합니다. | ||
| > 저는 팀 프로젝트에서 API 분리할 때 대부분 감으로 결정했던 것 같아서, 이런 상황에서 어떻게 합의를 이끌어내는지 경험을 들어보고 싶습니다. |
There was a problem hiding this comment.
논의 주제에 여러 질문이 포함되어 있어, 다른 사람들이 질문의 요지를 더 쉽게 파악하고 답변할 수 있도록 각 질문을 별도의 항목으로 나누는 것을 제안합니다.
| - 서비스나 DB를 나눌 때 분해인/통합인을 실제로 정량화해서 판단해본 경험이 있으신가요? 있다면, 결국 이런 결정은 팀이나 사내에서 하게 될 텐데 각자 다른 생각을 가지고 있을 것 같습니다. 각자 주장이 맞다고 내세울 때 어떤 근거들을 들고, 그 근거들은 어떤 방식으로 가져오시는지 궁금합니다. | |
| > 저는 팀 프로젝트에서 API 분리할 때 대부분 감으로 결정했던 것 같아서, 이런 상황에서 어떻게 합의를 이끌어내는지 경험을 들어보고 싶습니다. | |
| - 서비스나 DB를 나눌 때 분해인/통합인을 실제로 정량화해서 판단해본 경험이 있으신가요? | |
| - 만약 경험이 있다면, 팀 내에서 의견이 다를 때 어떻게 합의점을 찾으셨나요? 각자 주장이 맞다고 내세울 때 어떤 근거들을 들고, 그 근거들은 어떤 방식으로 가져오시는지 궁금합니다. | |
| > 저는 팀 프로젝트에서 API 분리할 때 대부분 감으로 결정했던 것 같아서, 이런 상황에서 어떻게 합의를 이끌어내는지 경험을 들어보고 싶습니다. |
같은 코드가 반복적으로 나타났을 때 그 횟수와 반복적으로 사용되는 지점을 고려해서 통합의 근거로 삼아본다던지 추후 개발될 기획 브리핑을 듣고 확장성을 고려하여 컴포넌트 덩어리를 쪼개는 정도의 경험은 있었던 것 같습니다 언급되는 분해인과 통합인이 수치적으로 딱딱 맞아떨어지는 요인들이 아니다보니 실체를 정확히 판단하기가 어려운 지표들 같아요 |
| # 논의 주제 | ||
|
|
||
| 초기 프로젝트에서 "아직 분해하지 말자"고 판단하는 기준은 뭘까? | ||
| 아직 규모가 작은 프로젝트에서는 어느 시점에 "이제 분해를 고민해야겠다"고 느끼는지 궁금하다. |
There was a problem hiding this comment.
분해를 하지 않으면 문제가 발생한다고 느낄 때, 분해를 시도하는 것 같고 그렇지 않다면, 굳이 분해 시도를 하지않는 것 같습니다
|
|
||
| # 논의 주제 | ||
|
|
||
| - 서비스나 DB를 나눌 때 분해인/통합인을 실제로 정량화해서 판단해본 경험이 있으신가요? 있다면, 결국 이런 결정은 팀이나 사내에서 하게 될 텐데 각자 다른 생각을 가지고 있을 것 같습니다. 각자 주장이 맞다고 내세울 때 어떤 근거들을 들고, 그 근거들은 어떤 방식으로 가져오시는지 궁금합니다. |
There was a problem hiding this comment.
장애 빈도와 영향도(주문 소실 수 등) 정량화된 지표로 볼 수 있을거 같은데요 이 지표들을 장애 격리를 위한 분해인으로 판단해본 적이 있습니다. 정량화할 수 있냐 없냐가 그렇게 중요한 것 같진않고, 분해 되어있거나 통합되어 있음으로써 어떤 문제가 있다는 걸 같은 회사 팀원들이 동일하게 느낀다면, 그 때가 분해 혹은 통합해야할 시기라고 생각합니다
말씀하신 근거들은 상황에 따라서 다를거 같고, 각자 생각이 다른 것도 어쩔 수 없는 부분이라고 생각하고, 동료와 협의를 해야할 부분이라고 생각합니다
3 participants
Summary
논의 주제