Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
TaeHyoungKwon
added
2026
Software Architecture: The Hard Parts
TaeHyoungKwon
requested review from
GeunJuLEE,
benscookie,
chichoon,
dhlee3994,
jongfeel,
tttghost and
ymkim97
|
우측에 있는 |
TaeHyoungKwon
changed the title
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! This pull request introduces three new markdown files containing summaries, keywords, discussion points, and personal reflections on Chapters 13, 14, and 15 from 'Fundamentals of Software Architecture, 2nd Edition'. The author, TaeHyoungKwon, shares their thoughts on applying these architectural principles in a practical business context, balancing concerns like development speed, maintainability, and trade-off analysis. 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. 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. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
| - 실험 | ||
| - RMI | ||
| - gRPC | ||
| - 그래프QL |
There was a problem hiding this comment.
gRPC는 영문으로 표기하셨는데, 그래프QL은 한글로 표기되어 있습니다. 문서 전체의 일관성을 위해 GraphQL로 통일하는 것을 제안합니다.
| - 그래프QL | |
| - GraphQL |
| - 내생각 | ||
| - 회사의 사례는 어떤지 확인해 보았는데, 일단 기본적으로는 데이터 웨어하우스로 빅쿼리를 사용하고 있고, 책에는 없지만 데이터 레이크하우스를 준비하고 있다고 한다 | ||
| - 회사에서는 EDW라고 해서 분석용 데이터베이스로 인지하고 있는데, 빅쿼리에서 직접 쿼리를 요청하는지 앞단의 서버가 있는 것인지는 모르겠지만, 매일 새벽에 서비스의 DB Read 인스턴스에서 모든 테이블의 정보를 쿼리해서 빅쿼리에 적재하고 있다. 그 외에도 CDC를 하거나 Multi Source Replication 등으로도 적용하고 있는 것으로만 알고 있다. 그래서 사실 개발자 단에서는 따로 신경 쓰는 부분이 아니기는 하고, 관련 작업을 하시는 분들과도 직접적인 연관은 없는 편이다 | ||
| - 데이터 레이크의 경우는 실제로 경험해 보지는 못했는데, 내용을 봤을 때 데이터 웨어하우스와 반대로 정제되지 않은 데이터를 저장하고 정제되지 않은 채로 조회하는 것 같다 |
There was a problem hiding this comment.
'정제되지 않은 채로 조회하는 것 같다'는 표현이 약간의 오해를 살 수 있습니다. 데이터 레이크는 원시 데이터를 저장하지만, 조회 시에는 스파크(Spark)나 프리스트(Presto) 같은 도구를 사용하여 스키마를 적용하고 데이터를 처리(schema-on-read)하는 경우가 많습니다. 의미를 더 명확하게 하기 위해 설명을 수정하는 것을 고려해 보세요.
| - 데이터 레이크의 경우는 실제로 경험해 보지는 못했는데, 내용을 봤을 때 데이터 웨어하우스와 반대로 정제되지 않은 데이터를 저장하고 정제되지 않은 채로 조회하는 것 같다 | |
| - 데이터 레이크의 경우는 실제로 경험해 보지는 못했는데, 내용을 봤을 때 데이터 웨어하우스와 반대로 정제되지 않은 원시 데이터를 저장하고, 조회 시점에 스키마를 적용하여 처리하는(schema-on-read) 방식인 것 같다 |
| # 13장 | ||
|
|
||
| - 논의주제 | ||
| - 그림 13-7에서 위시리스트 서비스에서 name만 필요한 경우에 프로필 서비스에서 name 이외의 값까지 응답으로 주는 것을 스탬프 커플링이라고 말하며 안티패턴이라고 말하고 있습니다. 이것이 안티패턴이라면, HTTP API상에서는 실제로 name을 요청할 때 name만 주는 API를 만드는 방법밖에 없다고 생각되는데, 어떤 다른 방법이 있을까요? |
There was a problem hiding this comment.
조금 쉽게 생각해 봤을 때는 name 외의 값을 얻으려면 다른 API를 호출하는 방식이 대안일 것 같습니다.
책의 예제는 백엔드에서 이미 커플링이 있을법한 API를 알려준 것 같기도 해요.
| # 15장 | ||
|
|
||
| - 논의주제 | ||
| - 요즘 들어서 경험보다는 실험을 많이 해 보아야 한다는 말을 많이 하고 있는데, AI 발전으로 인해서 실험할 수 있는 환경이 제대로 갖추어졌기 때문입니다. 책에서 나오는 트레이드오프 분석도 AI로 인해서 분석하기 매우 좋아졌습니다. 트레이드오프 분석을 위해서 구체적으로 AI를 어떤 식으로 활용해서 제대로 해 볼 수 있을지 이야기해 보면 좋을 것 같습니다 |
There was a problem hiding this comment.
제 생각에는 경험치는 운영 쪽에서는 조금 필요하다고 보고
아키텍처 설계, 개발 단계에서는 AI를 잘 쓰는 게 좋다고 봅니다.
저희 저번에 짧게 논의했던 대로라면
- 학습/검증용 AI: 무엇을 모르고 있는지, 알게 된 내용에 대해 사람이 학습한 후 계속 검증하면서 파악하는 용도
- 개발/생성용: 스펙과 프로세스, 비즈니스 흐름에 대해 명확하게 작성해 AI에게 개발을 시키는 용도
입니다.
트레이드오프 분석이라면 학습/검증용 AI 단계에서 충분히 파악이 가능할 것이라고 보고 있고
사람이 학습할 의지가 더 강해야 AI를 활용할 떄 좋은 결과를 얻을 수 있을 것 같다는 생각이 드네요.
특히 비즈니스 흐름에 대해서는 책의 설명대로 콘텍스트의 영향을 많이 받는 부분이므로 AI에게 개발 시킬 때 꼭 필요한 부분인 것 같습니다.
| - 에반젤리즘이 너무 심한 사람, 너무 심하지 않은 사람 둘 다 겪어 본 입장에서 일단 둘 다 별로 좋지 않지만, 그래도 개인적으로는 심한 사람이 더 좋지 않았던 것 같다. 흔히 에반젤리즘이 심한 사람들은 기능에만 너무 치우쳐서 위에서 말한 컨텍스트를 제대로 파악하지 못한 경우를 많이 본 것 같다 | ||
| - 대표적으로 컨텍스트를 고려하지 못하는 경우는 본인의 성과와 업적, 승진을 위해서 특정 서비스에 어떤 것들이 좋으니까 적용하자고 하는 경우인데, 개인적으로 이런 경우가 많다고 알고 있어서 좀 씁쓸한 부분이 있기는 하다 |
There was a problem hiding this comment.
책에서 매 챕터마다 구성원들의 대화가 참 건전하고 생산적인 대화라고 많이 느꼈습니다.
그래서 객관적인 조사와 논의 결과를 토대로 ADR 까지는 아니더라도 구성원들이 합의에 의한 의사결정을 존중해 아키텍처 설계를 한다면 좋지 않을까 합니다.
그런데 이 책을 쓰신 분도 그런 에반젤리스트에게 당한게 있어서 책에다가 약간 화풀이 하는 식으로 쓴 것 같다는 생각도 드네요.
There was a problem hiding this comment.
- 에반젤리즘이 너무 심한 사람, 너무 심하지 않은 사람 둘 다 겪어 본 입장에서 일단 둘 다 별로 좋지 않지만, 그래도 개인적으로는 심한 사람이 더 좋지 않았던 것 같다. 흔히 에반젤리즘이 심한 사람들은 기능에만 너무 치우쳐서 위에서 말한 컨텍스트를 제대로 파악하지 못한 경우를 많이 본 것 같다
새벽에 졸면서 써서.. 잘못적었네요 😢
그래도 개인적으로는 심한 사람이 더 좋지 않았던 것 같다. <----- (X)
그래도 개인적으로는 에반젤리즘이 심한 사람이 더 좋지 않았던 것 같다. <----- (O)
| # 13장 | ||
|
|
||
| - 논의주제 | ||
| - 그림 13-7에서 위시리스트 서비스에서 name만 필요한 경우에 프로필 서비스에서 name 이외의 값까지 응답으로 주는 것을 스탬프 커플링이라고 말하며 안티패턴이라고 말하고 있습니다. 이것이 안티패턴이라면, HTTP API상에서는 실제로 name을 요청할 때 name만 주는 API를 만드는 방법밖에 없다고 생각되는데, 어떤 다른 방법이 있을까요? |
There was a problem hiding this comment.
API단 구현방식을 잘 모르겠어서 확답은 어렵지만 특정 플래그 필드를 true로 전달했을 때만 다른 정보들을 같이 응답해주고, 그 외에는 name만 주는 케이스는 .. 적고나니 보안상 좀 위험할 것 같네요
지금까지의 경험상에도 그냥 과도하게 정보가 밀집된 API가 있을 경우 그걸 단순히 분리해서 다른 API를 만드는 경우만 보긴 했습니다
There was a problem hiding this comment.
HTTP 얘기를 하신게 아니었나요? 토론시간에 클라이언트 관점으로 논의주제를 적으신게 아니라고하셔서요
3 participants
Closes #625