Conversation
|
우측에 있는 |
Summary of ChangesHello @GeunJuLEE, 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' 스터디의 8장과 9장에 대한 학습 내용을 정리한 문서입니다. 재사용 패턴, 데이터 오너십, 분산 트랜잭션 등 핵심 아키텍처 개념들을 다루며, 특히 MSA 환경에서의 도전 과제와 실용적인 해결책에 대한 깊이 있는 통찰을 제공합니다. 저자의 경험과 고민이 담긴 논의 사항들을 통해 이론과 실제 적용 사이의 간극을 줄이는 데 기여합니다. 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
|
GeunJuLEE
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 pull request introduces a new markdown file summarizing chapters 8 and 9 of 'Fundamentals of Software Architecture 2nd Edition'. The content discusses architectural choices, reuse patterns, data ownership, and distributed transactions, including practical experiences and discussion points. The document is well-structured and provides valuable insights into the author's understanding and application of these concepts. I've identified a few areas for minor improvements in clarity and consistency.
|
|
||
| ## chapter 8 - 재사용 패턴 | ||
|
|
||
| 코드 복제 : 코드 복제는 코드 수정 시 전체를 동시에 수정해야 하는 부담이 있다. 유지보수가 너무 빡세다. |
There was a problem hiding this comment.
The phrase "유지보수가 너무 빡세다" is quite informal. While this is a personal note, for a more professional document, consider rephrasing it to something like "유지보수 부담이 크다" or "유지보수가 어렵다."
|
|
||
| 코드 복제 : 코드 복제는 코드 수정 시 전체를 동시에 수정해야 하는 부담이 있다. 유지보수가 너무 빡세다. | ||
|
|
||
| 공유 라이브러리 : 공통 코어를 JAR로 만들고, api app, admin app, batch app에서 해당 모듈을 사용해봤더니 나중에 배포할 때 이중으로 해서 빡셌다. |
There was a problem hiding this comment.
Similar to the previous comment, "빡셌다" is informal. A more formal phrasing would be "배포 시 이중으로 관리해야 하는 어려움이 있었다" or "배포 과정이 복잡했다."
2026/Fundamentals_of_Software_Architecture_2nd_Edition/geunju-lee/Chapter_8_to_9.md
Outdated
Show resolved
Hide resolved
|
|
||
| 하지만 현실적으로는 팀 구조와 책임 경계가 데이터 오너십을 결정하는 경우가 많다. | ||
|
|
||
| ACID 트랜잭션은 매우 강력하며 단일 데이터베이스 환경에서는 이상적인 모델이다(RDB가 인기 많은 이유인거 같다). |
There was a problem hiding this comment.
The parenthetical comment "(RDB가 인기 많은 이유인거 같다)" is a personal opinion and might be better placed in a "내 생각" or "논의사항" section, or rephrased to be more objective if kept here.
|
|
||
| 그리고 이런 처리를 위해 잘 설계된 서비스는 멱등성 보장, 재처리 가능 설계, 순서 보장, 장애 이후 재시도 정책 등을 가능하게 설계한다. | ||
|
|
||
| 처음부터 ACID로 해서 한번에 딱 성공하거나 실패하거나 둘 중 하나면 참 좋겠지만, 현실적으로 불가능하다. |
There was a problem hiding this comment.
The sentence "처음부터 ACID로 해서 한번에 딱 성공하거나 실패하거나 둘 중 하나면 참 좋겠지만, 현실적으로 불가능하다." is a bit informal. Consider rephrasing for a more formal tone, e.g., "ACID 트랜잭션으로 원자적 성공 또는 실패를 보장하는 것이 이상적이지만, 분산 시스템에서는 현실적으로 어렵습니다."
| 이러한 이슈로 인해 결국 예약 혹은 선점 시스템이 나왔다고 생각한다. 이는 최종 상태 이전에 중간 상태를 명시적으로 관리하는 방식이며, | ||
| 분산 시스템에서 일관성을 유지하기 위한 현실적인 접근이다. | ||
|
|
||
| 그리고 EDA를 통해 이 작업을 한다면 좀 더 높은 확률로 성공할 수 있다. 여기서 개인적으로 event가 command를 만든다는 것을 생각하며 개발을 하면 좀 더 나은 결과를 만들 수 있다. |
There was a problem hiding this comment.
The phrase "좀 더 높은 확률로 성공할 수 있다" is a bit vague. Could you elaborate on what 'higher probability of success' means in this context? Perhaps it refers to resilience or eventual consistency.
| 분산 시스템에서 일관성을 유지하기 위한 현실적인 접근이다. | ||
|
|
||
| 그리고 EDA를 통해 이 작업을 한다면 좀 더 높은 확률로 성공할 수 있다. 여기서 개인적으로 event가 command를 만든다는 것을 생각하며 개발을 하면 좀 더 나은 결과를 만들 수 있다. | ||
| 책을 예시로 들면 "고객 프로필 123이 삭제되었다"는 kafka message가 producing하면 그것을 지원계약 팀과 과금 결제 팀에서 consuming 후, 123을 삭제한다고 나온다. |
There was a problem hiding this comment.
The sentence "여기서 개인적으로 event가 command를 만든다는 것을 생각하며 개발을 하면 좀 더 나은 결과를 만들 수 있다." is a personal thought. It would fit better in the "내 생각" section or be rephrased to be more general.
| 하지만 Event → Command 파생 구조를 생각한다면 다음과 같이 개발 할 수 있다. | ||
|
|
||
| 1. 고객 서비스가 “프로필 삭제됨” message producing | ||
| 2. 고객 도메인이 이걸 consuming(이 때 다른 group id 2개로 각각 consuming 및 producing) |
There was a problem hiding this comment.
The phrase "(이 때 다른 group id 2개로 각각 consuming 및 producing)" is a bit technical and might benefit from a brief explanation of why two different group IDs are used, or how it contributes to the overall architecture.
|
|
||
| ### 내 생각 | ||
|
|
||
| 1. 저는 nbase-arc와 같은 메모리 DB를 사용하여 순서 보장 혹은 처리중 오류를 내보냅니다. 또한 서비스가 보낸 서비스의 key값도 저장하여 이중으로 중복 취소를 방지합니다. |
There was a problem hiding this comment.
The mention of "nbase-arc" is very specific. While it's good to share practical experience, consider adding a brief description of what nbase-arc is for readers who might not be familiar with it, or generalize the concept if the specific tool isn't the main point.
…lee/Chapter_8_to_9.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| ### 논의사항 | ||
|
|
||
| 1. 분산 트랜잭션 및 동시성 관련해서 lock을 어떻게 잡는지(예를 들면 같은 seq에 대해 동시에 2번 취소와 같은게 들어온다면 순서를 지키도록 하거나 하나는 이미 처리중이라며 에러를 던져야하기 때문) | ||
| 2. 중복 요청(기존 결과 반환)을 호출 측이 신규 성공으로 오해하지 않게, 응답 의미를 어떻게 구분하나 |
There was a problem hiding this comment.
신규 성공으로 오해하지 않도록 하기 위해서는 중복된 복수 요청임을 알려야해서, 409로 내려주는 선택을 주로 하는 것 같습니다
중복 요청임을 알려주지 않아도 될 경우는 그냥 2XX로 처리 합니다
|
|
||
| 1. 분산 트랜잭션 및 동시성 관련해서 lock을 어떻게 잡는지(예를 들면 같은 seq에 대해 동시에 2번 취소와 같은게 들어온다면 순서를 지키도록 하거나 하나는 이미 처리중이라며 에러를 던져야하기 때문) | ||
| 2. 중복 요청(기존 결과 반환)을 호출 측이 신규 성공으로 오해하지 않게, 응답 의미를 어떻게 구분하나 | ||
| 3. Event → Command 파생 구조는 결국 오케스트레이션 느낌인데, 오케스트레이션 vs 코레오그래피 |
There was a problem hiding this comment.
Event -> Command 형태로 했을 때, 말씀해주신 장점이 있는 반면에, 이벤트를 발행하는 측에서, 타 MS의 비즈니스 도메인에 의존되는 문제가 있을 것 같습니다
그래서 결국에는 말씀하신대로 설계했을 때, 자연스럽게 오케스트레이터가 되지 않을까 생각되고(타 MS 비즈니스 도메인 의존 때문에), 그렇기 때문에 코레오그래피 형태로 가게 된다면, 어쩔 수 없이 책에서 나오는대로, 이벤트 발행 주체의 이벤트 발생에만 집중하는 형태(프로필 삭제됨)로 가는게 더 낫지 않을까 라는 생각 입니다
저희 회사에서는 일단은, 각 팀 마다 운영효율을 가져갈 목적으로 코레오그래피 형태로 운영되고 있고, 이벤트 발행 주체의 부담을 최소화 하기위해서(다른 MS 의 비즈니스 도메인은 알 바가 아니다 라는 태도로 함), 이벤트 수신처에서 이벤트의 멱등성과 비즈니스로직 처리 여부를 결정하는 방식으로 되어있습니다
There was a problem hiding this comment.
보충 설명을 위한 도식화
단순 Event 발행
Event -> Command로 파생되는 형태
|
|
||
| ### 논의사항 | ||
|
|
||
| 1. 분산 트랜잭션 및 동시성 관련해서 lock을 어떻게 잡는지(예를 들면 같은 seq에 대해 동시에 2번 취소와 같은게 들어온다면 순서를 지키도록 하거나 하나는 이미 처리중이라며 에러를 던져야하기 때문) |
There was a problem hiding this comment.
코레오그래피 형태로 운영되고 있어서, 각 MS에서 데이터오너쉽을 가지는 데이터 기준으로, 동시성 처리에 대한 책임을 가집니다
그래서 lock 구현도 굉장히 다양한 편 입니다. 낙관적, 비관적 lock 모두 상황에 따라 각 서비스 담당자들 판단하에 선택해서 사용하고 있습니다
jongfeel
left a comment
jongfeel
left a comment
There was a problem hiding this comment.
운영자 제안
나중에 읽어야 하는 챕터에서 원하는 논의 주제가 나올 가능성이 있으므로
가급적 이번 스프린트 범위에 나온 내용 위주로 논의 주제를 가져오면 좋을 것 같습니다.
|
|
||
| ### 논의사항 | ||
|
|
||
| 1. 분산 트랜잭션 및 동시성 관련해서 lock을 어떻게 잡는지(예를 들면 같은 seq에 대해 동시에 2번 취소와 같은게 들어온다면 순서를 지키도록 하거나 하나는 이미 처리중이라며 에러를 던져야하기 때문) |
There was a problem hiding this comment.
책에 나오지 않는 주제긴 하지만 논의 주제인 것 같지만 최종 일관성과 맥락을 같이 하므로
과거 책에서 본 기억을 떠올려 보면 낙관적 락으로 우선 DB 점유를 짧게 가져가는 방식을 쓸 것 같습니다.
| ### 논의사항 | ||
|
|
||
| 1. 분산 트랜잭션 및 동시성 관련해서 lock을 어떻게 잡는지(예를 들면 같은 seq에 대해 동시에 2번 취소와 같은게 들어온다면 순서를 지키도록 하거나 하나는 이미 처리중이라며 에러를 던져야하기 때문) | ||
| 2. 중복 요청(기존 결과 반환)을 호출 측이 신규 성공으로 오해하지 않게, 응답 의미를 어떻게 구분하나 |
There was a problem hiding this comment.
전 409 에러를 의미있게 써 보진 않았지만 상태 코드로 쓰기에는 맞는 것 같습니다.
409 에러가 있는 걸 이번에 처음 알아서 검색해 봤네요.
|
|
||
| 1. 분산 트랜잭션 및 동시성 관련해서 lock을 어떻게 잡는지(예를 들면 같은 seq에 대해 동시에 2번 취소와 같은게 들어온다면 순서를 지키도록 하거나 하나는 이미 처리중이라며 에러를 던져야하기 때문) | ||
| 2. 중복 요청(기존 결과 반환)을 호출 측이 신규 성공으로 오해하지 않게, 응답 의미를 어떻게 구분하나 | ||
| 3. Event → Command 파생 구조는 결국 오케스트레이션 느낌인데, 오케스트레이션 vs 코레오그래피 |
There was a problem hiding this comment.
코레오그래피로 한다고 해도 event와 command 처리 순서에 정상 상황과 예외 상황에 대해서 오케스트레이션이 하는 방식을 대안으로 구현해 두면 어떨까? 하는 생각을 해봤습니다.
책에서는 개념에 대한 설명을 해야 하기 때문에 한 가지 방식씩 설명하는 건데, 실제로는 두 가지 방식을 혼합해서 사용해도 괜찮지 않나 하는 생각이죠.
There was a problem hiding this comment.
책에서는 개념에 대한 설명을 해야 하기 때문에 한 가지 방식씩 설명하는 건데, 실제로는 두 가지 방식을 혼합해서 사용해도 괜찮지 않나 하는 생각이죠.
혼합해서 사용하는것도 괜찮은 방법 같습니다
어느쪽에서 이벤트 발생에 대한 각 MS의 도메인로직 제어의 책임을 가질 것인가에 따라서, 오케스트레이터 혹은 코레오그래피로 나뉠거 같은데요 근주님이 말씀해주신대로 이벤트 발행 -> 커맨드(오케스트레이터) 처럼 함으로써 장애 처리에 장점이 있는 부분을 최대한 살릴 수 있는 부분은 실제로 오케스트레이터 역할을 하는 팀과 팀의 서비스가 실제 그 역할을 할 수 있도록 해주고, 나머지는 기본적으로는 코레오그래피이면서, 이벤트발행 식으로 동작하도록 하면 어떨까 생각됩니다
이부분 관련해서 가끔씩 회사 내에서도 논쟁이 있는 부분인데(도메인로직 제어 책임을 어떤 MS에서 가질 것인지), 활용해볼 만한 내용 같습니다
|
|
||
| ### 논의사항 | ||
|
|
||
| 1. 분산 트랜잭션 및 동시성 관련해서 lock을 어떻게 잡는지(예를 들면 같은 seq에 대해 동시에 2번 취소와 같은게 들어온다면 순서를 지키도록 하거나 하나는 이미 처리중이라며 에러를 던져야하기 때문) |
There was a problem hiding this comment.
저희 팀이 오너십으로 있는 서비스들은 대부분 낙관적 락을 사용합니다.
그래서 간간히 optimistic failed 로그가 발생하더라구요.
물론 비관적이나, 글로벌 락도 상황에 따라 사용중이긴 합니다.
| ### 논의사항 | ||
|
|
||
| 1. 분산 트랜잭션 및 동시성 관련해서 lock을 어떻게 잡는지(예를 들면 같은 seq에 대해 동시에 2번 취소와 같은게 들어온다면 순서를 지키도록 하거나 하나는 이미 처리중이라며 에러를 던져야하기 때문) | ||
| 2. 중복 요청(기존 결과 반환)을 호출 측이 신규 성공으로 오해하지 않게, 응답 의미를 어떻게 구분하나 |
There was a problem hiding this comment.
저도 해당 방식을 생각해 본 적이 없는데, 이번 기회에 409를 알게 되었네요!
| 2. http 응답 코드로 409 응답. | ||
| 3. 코레오그래피가 기본적으로 개발이 훨씬 편하다. 그렇지만 운영상 A가 성공했다고 무조건 B를 수행하는 것이 아닌 경우가 존재하고, 그러한 경우를 위해 오케스트레이션이 운영상 이점이 있다고 생각한다. | ||
|
|
||
| ### 경험 사례 |
There was a problem hiding this comment.
실무에서의 경험도 공유 해주셔서 감사합니다!
6 participants
No description provided.