Skip to content

소프트웨어 아키텍처 the hard parts sprint 3 - 권태형#602

Open
TaeHyoungKwon wants to merge 9 commits intomainfrom
thkwon-2026-sprint3
Open

소프트웨어 아키텍처 the hard parts sprint 3 - 권태형#602
TaeHyoungKwon wants to merge 9 commits intomainfrom
thkwon-2026-sprint3

Conversation

@TaeHyoungKwon
Copy link
Collaborator

@TaeHyoungKwon TaeHyoungKwon commented Feb 5, 2026

Screenshot 2026-02-06 at 20 07 16

6장

Screenshot 2026-02-06 at 20 05 45

7장

Screenshot 2026-02-06 at 20 05 59

@TaeHyoungKwon TaeHyoungKwon added 2026 Software Architecture: The Hard Parts 소프트웨어 아키텍처: The Hard Parts, 분산 아키텍처를 위한 모던 트레이드오프 분석 labels Feb 5, 2026
@TaeHyoungKwon TaeHyoungKwon self-assigned this Feb 5, 2026
@github-actions
Copy link

github-actions bot commented Feb 5, 2026

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

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @TaeHyoungKwon, 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" 책의 6장과 7장에 대한 학습 내용을 정리한 것입니다. 마이크로서비스 아키텍처에서 데이터 분해 및 통합의 기준, 그리고 서비스 세분도를 결정하는 방법에 대한 책의 내용과 저자의 개인적인 견해 및 논의 주제를 포함하고 있습니다. 특히, 실제 현업에서의 경험을 바탕으로 이론적 개념의 실용적 적용과 한계에 대한 깊이 있는 통찰을 제공합니다.

Highlights

  • 6장 논의 주제: MSA에서 경계 컨텍스트(BC)의 장단점, 특히 데이터 계약과 관련된 문제점, 비즈니스 복잡도 증가에 따른 마이크로서비스 관리의 어려움(새로운 MS 생성 vs 기존 MS 통합), 팀 간 소통 비용, EDA 설계 시 복잡성 증가 등을 다룹니다.
  • 6장 데이터 분해/통합인: 데이터 분해인(변경 관리, 커넥션 관리, 확장성, 내결함성, 아키텍처 퀀텀, DB 타입 최적화)과 데이터 통합인(데이터 관계, DB 트랜잭션)의 개념을 정의하고 설명합니다.
  • 6장 개인 의견: 분해인과 통합인의 핵심은 변경으로 인한 장애 격리 가능성과 효율적인 쓰기 작업 보장임을 강조합니다. DDD의 BC 및 애그리게이트 경계 식별이 쓰기 기준과 연관됨을 언급하며, 사가 패턴의 필요성 발생 시 데이터 분해/통합의 재검토를 제안합니다.
  • 7장 논의 주제: 서비스 세분도 측정 시 책에서 제시하는 정량적 분석(인터페이스/기능 수)의 한계를 지적하고, 비즈니스 임팩트 및 장애 격리 가능성 등 정성적 기준의 중요성을 주장합니다.
  • 7장 개인 의견: 정량적 분석과 정성적 분석의 균형, 마이크로서비스의 '마이크로' 의미에 대한 재해석(모놀리스 대비), 단일 책임 원칙(SRP)을 마이크로서비스 설계에 적용할 때의 유지보수 비용 문제 등을 다룹니다. 세분도 분해/통합인 역시 변경으로 인한 장애 격리 가능성과 트랜잭션 보장 여부를 기준으로 판단해야 함을 강조합니다.

🧠 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/6.md
    • 6장 "데이터 분해 및 통합"에 대한 학습 노트가 추가되었습니다. 이 파일에는 논의 주제, 요약, 키워드, 내용(데이터 분해인, 데이터 통합인), 그리고 저자의 개인적인 생각이 포함되어 있습니다.
  • 2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/7.md
    • 7장 "서비스 세분도"에 대한 학습 노트가 추가되었습니다. 이 파일에는 논의 주제, 요약, 키워드, 내용(세분도 분해인, 세분도 통합인), 그리고 저자의 개인적인 생각이 포함되어 있습니다.
Activity
  • 새로운 학습 노트 파일 두 개(6.md, 7.md)가 추가되었습니다.
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.

@TaeHyoungKwon TaeHyoungKwon changed the title 소프트웨어 아키텍처 the hard parts sprint 3 권태형 소프트웨어 아키텍처 the hard parts sprint 3 - 권태형 Feb 5, 2026
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

안녕하세요, 권태형 님. '소프트웨어 아키텍처 the hard parts' 6장과 7장에 대한 정리 문서를 추가해주셨네요. 책의 내용을 깊이 있게 이해하고 자신의 경험과 생각을 잘 정리해주셔서 인상 깊었습니다. 특히 논의 주제를 통해 팀원들과 함께 고민해볼 지점을 제시해주신 점이 좋았습니다. 전반적으로 내용이 훌륭하며, 가독성을 조금 더 높이기 위해 몇 가지 사소한 오타와 띄어쓰기 수정을 제안드렸습니다. 좋은 내용 공유해주셔서 감사합니다!

thkwon1 and others added 8 commits February 5, 2026 20:34
- Implemented a function to prompt for and validate the Issue ID, ensuring it is a required numeric input.
- Automatically append the "Closes" keyword with the Issue ID to the PR body if provided.
…ng/6.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…ng/6.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…ng/6.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…ng/6.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…ng/7.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…ng/7.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…ng/7.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Comment on lines +46 to +62
# Issue ID 입력 및 검증
get_issue_id() {
while true; do
read -p "Issue ID를 입력하세요 (필수): " ISSUE_ID
if [ -n "$ISSUE_ID" ]; then
# 숫자 검증
if [[ "$ISSUE_ID" =~ ^[0-9]+$ ]]; then
break
else
echo "오류: Issue ID는 숫자여야 합니다. 다시 입력해주세요."
fi
else
echo "Issue ID는 필수입니다. 다시 입력해주세요."
fi
done
}

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR 생성 시에 issue 연결 하기위한 기능 추가하였습니다

Copy link
Member

@jongfeel jongfeel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

# 6장

- 논의 주제
- 6장에서 경계 컨텍스트(Bounded Context) 사례로 서비스 C와 D 사이의 데이터 계약 관계에 대해서 말하고 있다. 책에서는 이렇게 데이터를 나누었기 때문에 데이터베이스 D에서 발생한 중대 변경으로 부터 서비스 C가 추상화 되는 장점이 있다고 말하고 있고, 이는 모놀리스 서버를 BC 별로 분리함으로써 얻는 MSA 의 장점으로도 볼 수 있을 거 같은데, 단점은 얘기하고 있지 않고 있다. 어떤 단점이 발생할 수 있을지에 대해서 실제 겪은 일 혹은 머릿속에서 상상해본 사례를 공유해보면 좋을 것 같다
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

7장의 서비스 분해인/통합인에서 이 부분에 대해 설명을 아주 잘 해주긴 하더라고요.
제가 생각한 단점도 비슷합니다.
분해한 서비스들 끼리의 호출 횟수, 응답 속도, 그렇게 함으로서 워크 플로의 오케스트레이션의 복잡도 증가 등을 고려해야 하는데, 그런 것들의 객관적 수치로 제시되고 분리가 되었는지에 대해 면밀한 분석이 필요하다고 봅니다.

그리고 이 책이 계속 얘기해주는 건 객관적인 데이터 증거를 통한 아키텍처 결정을 의미있게 해보자인 거 같고
특히 한빛가이버 사가의 대화들과 마지막 ADR 기록이 그 부분을 잘 보여주고 있어서 더 이해가 잘 되는 것 같습니다.

# 7장

- 논의주제
- 적절한 세분도를 측정하기 위해서 책에서는 정량적 분석이 가능한 인터페이스의 개수나 기준의 수를 언급하고 있습니다. 저는 현실과 동떨어진 방법이라고 생각하고, 오히려 비즈니스 임팩트나, 장애 상황에서 격리가 되어야하는지 여부가 세분도 측정에도 포함이 되어야 한다고 생각하는데, 적절한 세분도 측정 방법에 대해서 논의해보면 좋을 것 같습니다
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이 책의 저자가 생각하는 이키텍처 결정의 기준이 객관적 데이터가 문장 수나 인터페이스 개수로 측정하는 걸 얘기하는 거라고 생각합니다. 다른 책에서도 데이터의 입력 출력 갯수로 작업의 단위를 계산하고 분석 단위로 하는 것도 있었으니까요.
만약 얘기하신대로 장애 상황이 빈번하면 그것도 세분도의 객관적 데이터로 볼 수 있을 것 같습니다. 사후 세분도 측정 데이터인 셈이겠죠.
제 예상에는 아마 이 책의 후반부에 그런 설명을 하지 않을까 싶네요.

- 서비스 세분도는 서비스가 무엇을 하느냐에 따라 달라지기 때문에, 이상적인 마이크로 서비스 설계라면, 마이크로서비스가 최대한 한가지 책임만 가지도록 설계하는 경우가 많은데, 이런 경우에 현실세계에서 가장 큰 문제는 마이크로서비스 유지보수 비용이 너무 많이 든다는 점이다. 그래서 마이크로서비스 설계 시에는 반드시 유지보수 비용까지 고려해서 설계해야한다고 생각한다
- 세분도의 분해인도 데이터 분해인과 마찬가지로, 분해하거나 통합해야하는 명분은 변경에 의한 장애 발생 시, 격리 가능한가? 의 기준에서 생각해볼 수 있다
- 마찬가지로 통합인도 동일한 맥락에서 생각할 수 있는데, 통합했을 때, 훨씬 더 작업처리에 유리하고, 분해했을 때, 더 고려해야할 것인 많을 때(분산 트랜잭션으로 인한 데이터 정합성 문제)는 차라리 통합하는게 낫다는 것이다
- 책에서 나오는 많은 분해인, 통합인도 매우 도움이 되는 것들이라고 생각되는데, 각각을 다 이해하고 활용할 수 없다면, 어떤 게 쉬운 방법일까? 를 생각해보는게 좋을것 같다. 쉽게 풀 수 있는 방법이 있는데, 굳이 어려운 방법을 할 필요는 없기 때문이고, 이 쉬운 방법을 고민하다가 보면, 자연스럽게 책에서 말하는 분해인과 통합인이 나올 것 같다는 생각이다
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

다른 저자분이 쓴 아키텍처 책을 보고 다른 관점에 대해 이해하면 좋지 않을까 싶습니다.
저도 어려울 수도 있는 부분을 참 쉽게 설명을 잘 해주는 구나 라는 느낌을 많이 받고 있습니다.

# 6장

- 논의 주제
- 6장에서 경계 컨텍스트(Bounded Context) 사례로 서비스 C와 D 사이의 데이터 계약 관계에 대해서 말하고 있다. 책에서는 이렇게 데이터를 나누었기 때문에 데이터베이스 D에서 발생한 중대 변경으로 부터 서비스 C가 추상화 되는 장점이 있다고 말하고 있고, 이는 모놀리스 서버를 BC 별로 분리함으로써 얻는 MSA 의 장점으로도 볼 수 있을 거 같은데, 단점은 얘기하고 있지 않고 있다. 어떤 단점이 발생할 수 있을지에 대해서 실제 겪은 일 혹은 머릿속에서 상상해본 사례를 공유해보면 좋을 것 같다
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

서비스를 이상적으로 정말 적절하게 나누고 그것이 제품 판매 종료 전까지 잘 유지된다는 가정하에는 단점이 거의 없을 것 같긴 하네요

지금 생각나는 건 독립된 서비스간 아무래도 코드를 공유하지 않다 보니 중복된 코드 (특히 유틸리티 함수 등) 가 많아지는 정도의 딘점이 생각나는데 이것도 사실 서비스 통합인 중의 하나로 언급되고 있어서 궁극적으로 책이 말하는 단점은 아닐것 같습니다

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

2026 Software Architecture: The Hard Parts 소프트웨어 아키텍처: The Hard Parts, 분산 아키텍처를 위한 모던 트레이드오프 분석

Projects

None yet

Development

Successfully merging this pull request may close these issues.

<소프트웨어 아키텍처 The Hard Parts> sprint 3, chapter 6, 7, 총 95페이지, 2026-02-06

5 participants