Conversation
|
우측에 있는 |
Summary of ChangesHello @chichoon, 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'의 8장 '재사용 패턴'에 대한 학습 노트를 추가합니다. 분산 시스템에서 코드 재사용을 위한 다양한 전략들을 탐구하며, 코드 복제, 공유 라이브러리, 공유 서비스, 사이드카 및 서비스 메시와 같은 패턴들의 장단점과 적용 시 고려사항을 상세히 다룹니다. 또한, 각 재사용 기법에 대한 개인적인 통찰과 논의점을 포함하여 실질적인 이해를 돕는 것을 목표로 합니다. 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
소프트웨어 아키텍처 8장 재사용 패턴에 대한 요약 정리를 잘 작성해주셨습니다. 전체적으로 내용이 명확하고 이해하기 쉽게 정리되어 있습니다. 다만, 가독성을 더욱 높이기 위해 몇 가지 수정을 제안합니다. 문서 전반에 걸쳐 발견되는 띄어쓰기 오류를 수정하고, 일부 구어적인 표현을 기술 문서에 더 적합한 용어로 다듬었습니다. 또한, 마크다운 문법을 의미에 맞게 사용하여 '논의점 및 느낀점' 부분을 코드 블록에서 인용문 블록으로 변경할 것을 제안했습니다. 이러한 작은 개선들이 문서를 더욱 전문적이고 명확하게 만들어 줄 것입니다.
2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/07.md
Outdated
Show resolved
Hide resolved
2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/07.md
Outdated
Show resolved
Hide resolved
2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/07.md
Outdated
Show resolved
Hide resolved
| ``` | ||
| 논의점 및 느낀점: 유독 공유 서비스 기법에 대한 단점이 길게 서술된 느낌이 든다. 반면 사이드카 기법은 구축이 복잡한 편이다~ 정도 외엔 장점 위주로 적혀 있는데, 다른 분들은 해당 두 파트를 읽으면서 비슷한 생각을 하셨을지 유독 궁금한 챕터였다. | ||
|
|
||
| 개인적으론 초기 구축에 들어가는 에너지 (?) 면에선 공유 서비스 분리가 훨씬 간단해 보이고, 사이드카 기법은 서비스에 대한 충분한 지식이 뒷받침되어야 한다는 추가적인 단점이 있을 듯하다 | ||
| ``` |
There was a problem hiding this comment.
'논의점 및 느낀점' 부분은 코드가 아니므로, 코드 블록(```) 대신 인용문 블록(>)을 사용하는 것이 의미상 더 적절합니다. 이렇게 하면 마크다운 렌더러가 텍스트를 더 적절하게 표시할 수 있습니다.
| ``` | |
| 논의점 및 느낀점: 유독 공유 서비스 기법에 대한 단점이 길게 서술된 느낌이 든다. 반면 사이드카 기법은 구축이 복잡한 편이다~ 정도 외엔 장점 위주로 적혀 있는데, 다른 분들은 해당 두 파트를 읽으면서 비슷한 생각을 하셨을지 유독 궁금한 챕터였다. | |
| 개인적으론 초기 구축에 들어가는 에너지 (?) 면에선 공유 서비스 분리가 훨씬 간단해 보이고, 사이드카 기법은 서비스에 대한 충분한 지식이 뒷받침되어야 한다는 추가적인 단점이 있을 듯하다 | |
| ``` | |
| > **논의점 및 느낀점** | |
| > | |
| > 유독 공유 서비스 기법에 대한 단점이 길게 서술된 느낌이 든다. 반면 사이드카 기법은 구축이 복잡한 편이다~ 정도 외엔 장점 위주로 적혀 있는데, 다른 분들은 해당 두 파트를 읽으면서 비슷한 생각을 하셨을지 유독 궁금한 챕터였다. | |
| > | |
| > 개인적으론 초기 구축에 들어가는 에너지 (?) 면에선 공유 서비스 분리가 훨씬 간단해 보이고, 사이드카 기법은 서비스에 대한 충분한 지식이 뒷받침되어야 한다는 추가적인 단점이 있을 듯하다 |
2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/07.md
Outdated
Show resolved
Hide resolved
| ``` | ||
| 논의점 및 느낀점: 유독 공유 서비스 기법에 대한 단점이 길게 서술된 느낌이 든다. 반면 사이드카 기법은 구축이 복잡한 편이다~ 정도 외엔 장점 위주로 적혀 있는데, 다른 분들은 해당 두 파트를 읽으면서 비슷한 생각을 하셨을지 유독 궁금한 챕터였다. | ||
|
|
||
| 개인적으론 초기 구축에 들어가는 에너지 (?) 면에선 공유 서비스 분리가 훨씬 간단해 보이고, 사이드카 기법은 서비스에 대한 충분한 지식이 뒷받침되어야 한다는 추가적인 단점이 있을 듯하다 | ||
| ``` |
There was a problem hiding this comment.
저도 공유서비스의 단점이 많이 서술된 것 같다고 느끼긴 했는데, 다 맞는 말이라서 별 생각은 없이 넘어 갔습니다 사이드카패턴의 경우, 개발팀이 횡단관심사 보다 비즈니스로직에만 더 집중하게 할 목적이고, 컨테이너 환경으로 되어있다면 적극 검토해볼만 하다고 생각합니다
jongfeel
added
2026
Software Architecture: The Hard Parts
| - 사이드카끼리 맞물려 형성한 일종의 그물망을 메시라고 함 (그물망이 영어로 메시임) | ||
|
|
||
| ``` | ||
| 논의점 및 느낀점: 유독 공유 서비스 기법에 대한 단점이 길게 서술된 느낌이 든다. 반면 사이드카 기법은 구축이 복잡한 편이다~ 정도 외엔 장점 위주로 적혀 있는데, 다른 분들은 해당 두 파트를 읽으면서 비슷한 생각을 하셨을지 유독 궁금한 챕터였다. |
There was a problem hiding this comment.
마지막 한빛가이버 사가에서 최종 ADR은 공유 라이브러리로 결정했으니까 어떻게든 끝판왕이 공유 서비스가 아님을 강조하고 싶었던 저자의 치밀한 빌드업...은 아닌 것 같고
공유 서비스의 단점을 잘 알아둬야지 공유 라이브러리도 나쁘지 않은 선택지라는 걸 인식하지 않을까 싶어서 강조하지 않았나하는 관계자 같은 소리를 해봤습니다. ㅎㅎ
(유튜브 흑백리뷰에서 흑돈이 "관계자 같은 소리하지마!" 가 자동 재생되네요.)
chichoon
requested review from
GeunJuLEE,
TaeHyoungKwon,
benscookie,
dhlee3994,
jongfeel and
ymkim97
|
드래프트 해제 했습니다. 퇴근하고 마저 읽느라 너무 오래 걸렸습니다 ㅠㅠ 죄송합니다 맨날 전 주에 읽겠다고 다짐해놓고 어째 잘 안되네요 .. ;; |
| - 사이드카끼리 맞물려 형성한 일종의 그물망을 메시라고 함 (그물망이 영어로 메시임) | ||
|
|
||
| ``` | ||
| 논의점 및 느낀점: 유독 공유 서비스 기법에 대한 단점이 길게 서술된 느낌이 든다. 반면 사이드카 기법은 구축이 복잡한 편이다~ 정도 외엔 장점 위주로 적혀 있는데, 다른 분들은 해당 두 파트를 읽으면서 비슷한 생각을 하셨을지 유독 궁금한 챕터였다. |
There was a problem hiding this comment.
저도 어느정도 비슷한 생각이 들긴 했습니다.
특히 공유 서비스에서의 버저닝을 좀 큰 단점으로 보는 것으로 느껴졌는데, 이게 그 정도인가라는 생각을 했습니다.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
4 participants
연휴에 미리 할걸 싶네요 🥵