Skip to content

소프트웨어 아키텍처 The Hard Parts 3주차 - 김영명 #600

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ymkim97 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

소프트웨어 아키텍처 The Hard Parts 3주차 - 김영명 #600

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions 2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter6_7.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# 소프트웨어 아키텍처 The Hard Parts
## 6장 ~ 7장
---
## 논의 내용
* 서비스를 분리하면서 고려해야 하는 것 중 각자 생각하는 가장 큰 걸림돌이 무엇인지 의견이 궁금합니다.
> 저 같은 경우에는 트랜잭션 관리라고 생각합니다. 분산 환경으로 가는 순간 하나의 물리적인 트랜잭션은 불가능하여 데이터 일관성, 무결성에 대한 문제를 해결하는 것 때문입니다. 물론 Saga 패턴 등 으로 해결 방법은 존재하나, 모든 기능에 대해서 이런 패턴으로 커버해야하는지 판단하기 어렵다고 느낍니다. 예를 들어 결제와 같은 기능이 다른 서비스와 통신을 한다면 중요하기 때문에 당연히 해결해야 하지만, 새로 만드는 기능이 비교적 덜 중요한다 하더라도 적용해야 할지 입니다. 자신에게 주어진 리소스와 시간은 한정적이기 때문에 정말 모든 기능에 적용하는 것이 맞을지, 그렇다면 오버 엔지니어링은 아닐지 의문이긴 합니다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 4, 2026

Choose a reason for hiding this comment

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

medium

중요한다는 중요하다의 오타로 보입니다. 수정하면 문장이 더 자연스러워집니다.

Suggested change
> 저 같은 경우에는 트랜잭션 관리라고 생각합니다. 분산 환경으로 가는 순간 하나의 물리적인 트랜잭션은 불가능하여 데이터 일관성, 무결성에 대한 문제를 해결하는 것 때문입니다. 물론 Saga 패턴 등 으로 해결 방법은 존재하나, 모든 기능에 대해서 이런 패턴으로 커버해야하는지 판단하기 어렵다고 느낍니다. 예를 들어 결제와 같은 기능이 다른 서비스와 통신을 한다면 중요하기 때문에 당연히 해결해야 하지만, 새로 만드는 기능이 비교적 덜 중요한다 하더라도 적용해야 할지 입니다. 자신에게 주어진 리소스와 시간은 한정적이기 때문에 정말 모든 기능에 적용하는 것이 맞을지, 그렇다면 오버 엔지니어링은 아닐지 의문이긴 합니다.
> 저 같은 경우에는 트랜잭션 관리라고 생각합니다. 분산 환경으로 가는 순간 하나의 물리적인 트랜잭션은 불가능하여 데이터 일관성, 무결성에 대한 문제를 해결하는 것 때문입니다. 물론 Saga 패턴 등 으로 해결 방법은 존재하나, 모든 기능에 대해서 이런 패턴으로 커버해야하는지 판단하기 어렵다고 느낍니다. 예를 들어 결제와 같은 기능이 다른 서비스와 통신을 한다면 중요하기 때문에 당연히 해결해야 하지만, 새로 만드는 기능이 비교적 덜 중요하다 하더라도 적용해야 할지 입니다. 자신에게 주어진 리소스와 시간은 한정적이기 때문에 정말 모든 기능에 적용하는 것이 맞을지, 그렇다면 오버 엔지니어링은 아닐지 의문이긴 합니다.

Comment on lines +5 to +6
Copy link
Collaborator

@TaeHyoungKwon TaeHyoungKwon Feb 5, 2026

Choose a reason for hiding this comment

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

저는 장애 영향을 가장 크게 봅니다 어떤 크리티컬한 도메인이 있을 때, 해당 도메인이 다른 덜 중요한 도메인의 기능으로 인해서, 정상동작을 못할 때, 서비스 분해인으로 보고 있습니다

Copy link
Collaborator

@TaeHyoungKwon TaeHyoungKwon Feb 5, 2026

Choose a reason for hiding this comment

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

저 같은 경우에는 트랜잭션 관리라고 생각합니다.

저도 이부분에 대해서 이론적으로는 공감하지만, 현실세계의 MSA 환경에서는 제약이 존재하는 것 같습니다
그 이유는 대개의 회사를 보면, 콘웨이 법칙으로 인해서, MSA를 하고 있다면, MS 기준으로 팀의 경계를 나누게 되는데, 팀의 경계가 MS의 경계이면서, 업무의 경계가 되다보니, 팀 간에는 애초에 분산 트랜잭션을 관리하는 상황이 될 수밖에 없는거 같습니다

이런 경우에, 반드시 물리적 트랜잭션으로 처리하기 위한 통합 작업이 필요하다면, 역콘웨이 법칙에 인해서, 그 팀이 합쳐지는 경우가 있긴한데, 아주 크리티컬하지 않다면, 보상 트랜잭션을 통해서, 분산트랜잭션을 구현한다던지, 사후처리 로직을 통해서 보정 작업을 별도로 한다던지 하는 선택을 많이 하는 것 같습니다


## Chapter 6 - 운영 데이터 분리
지금까지 책을 읽으면서 슬슬 궁금했던 데이터베이스의 분해에 대해서 나와서 재미있게 읽을 수 있었다.
모놀리식 데이터베이스 분해는 실제로 애플리케이션 기능보다 훨씬 더 분해하기 어려우므로, 데이터 분해인이 중요하며, 데이터 통합인도 역시 중요하다.
데이터 분해인은 변경 관리, 커넥션 관리, 확장성, 내고장성, 아키텍처 퀀텀, 데이터베이스 유형 최적화로 나누어서 생각할 수 있다.
분해의 반대로 데이터 통합인은 데이터 관계, 데이터베이스 트랜잭션을 생각할 수 있다.

데이터를 분해하면서 생기는 가장 큰 골칫거리는 트랜잭션이라고 생각하며, 대다수의 엔지니어들이 동의하지 않을까 예상한다.
모놀리스 데이터베이스는 하나의 물리적인 트랜잭션이면 해결되지만, 분산 환경으로 가는 순간 그것이 불가능 하기 때문에 어쩔 수 없이 데이터 일관성, 무결성 이슈가 발생한다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 4, 2026

Choose a reason for hiding this comment

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

medium

불가능 하기 때문에는 불가능하기 때문에로 붙여 쓰는 것이 올바른 띄어쓰기입니다. 가독성을 위해 수정하는 것이 좋습니다.

Suggested change
모놀리스 데이터베이스는 하나의 물리적인 트랜잭션이면 해결되지만, 분산 환경으로 가는 순간 그것이 불가능 하기 때문에 어쩔 수 없이 데이터 일관성, 무결성 이슈가 발생한다.
모놀리스 데이터베이스는 하나의 물리적인 트랜잭션이면 해결되지만, 분산 환경으로 가는 순간 그것이 불가능하기 때문에 어쩔 수 없이 데이터 일관성, 무결성 이슈가 발생한다.

이를 해결하기 위해 트랜잭셔널 사가 등이 있으며 더 깊게 가고 싶지만, 12장에서 자세히 다룬다고 나와 있으니 일단 넘어가기로 한다.

애플리케이션에서 도메인 별로 서비스를 나누듯이 데이터베이스를 분석하여 데이터 도메인을 생성하면서 분해를 시작한다.
한번에 데이터베이스를 나눌 수는 없으니, 데이터 도메인을 생성(구분) 해낸 후, 데이터 도메인마다 스케마를 만들어 테이블들을 각자 속한 스키마로 옮긴다.
이때 서로 다른 데이터 도메인에 속한 테이블 간에 밀접한 연관성과 커플링이 존재한다면, 해당 데이터 도메인들은 반드시 통합해야 한다.

데이터베이스를 분리하면서 각 데이터 도메인을 특성에 맞게 데이터베이스 타입을 선택할 수 있다.
표준이라고 할 수 있는 관계형 데이터베이스 뿐만 아니라, 키-값, 문서형, 컬럼형, 그래프, NewSql, Cloud native, 시계열 등 정말 다양하다.
이렇게 다양한 DB 기술들을 혼합하여 사용하는 것을 폴리글랏 데이터베이스라고 하며, 책에서 한빛가이버는 고객 설문은 문서형으로 마이그레이션 하기로 결정했다.

문서형에서도 단일 애그리거트 문서와 분할된 애그리거트 문서가 있다. (Survey : Question)
이 역시 장단점이 존재한다.
단일 애그리거트 문서는 한번의 get으로도 온전한 고객 설문 데이터를 데이터베이스에서 가져올 수 있으므로 여러 개발 팀 사람들이 데이터를 쉽게 사용할 수 있다.
다만 각 설문 문서마다 문항이 중복된다.

분할된 애그리거트 문서는 동일한 문항을 여러 설문에서 사용할 수 있는 반면, 화면 렌더링 및 데이터 검색은 단일 애그리거트보다 힘들어진다.

## Chapter 7- 서비스 세분도
각 서비스의 크기를 정하는 것에 대한 내용이 주인 챕터다.
서비스를 나누면 크기가 너무 작거나, 커질 수 도 있기 때문에 그 크기(세분도)를 올바르게 결정해야 하지만 매우 어렵다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 4, 2026

Choose a reason for hiding this comment

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

medium

커질 수 도는 커질 수도로 붙여 쓰는 것이 올바른 띄어쓰기입니다.

Suggested change
서비스를 나누면 크기가 너무 작거나, 커질 수 도 있기 때문에 그 크기(세분도)를 올바르게 결정해야 하지만 매우 어렵다.
서비스를 나누면 크기가 너무 작거나, 커질 수도 있기 때문에 그 크기(세분도)를 올바르게 결정해야 하지만 매우 어렵다.

분산 아키텍처를 생각하면 분해를 먼저 떠올리고 집중하기 쉬운데, 결국 통합도 중요하다.

**분해인:**
* 서비스의 범위와 기능
* 코드 변동성
* 확장성/처리량
* 내고장성
* 보안
* 신장성

같은 예시 (책에서 나오는 알림 - sms, 이메일, 우편 - 서비스)에서도 각 분해인에 따라 적합 여부가 달라진다.
서비스의 범위와 기능으로 볼때는 응집도가 높아 분해하는 것으로 판단하기 어렵지만, 코드 변동성으로 볼때 구분이 되면 적절한 후보가 된다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 4, 2026

Choose a reason for hiding this comment

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

medium

볼때는과 볼때는 각각 볼 때는과 볼 때로 띄어 쓰는 것이 올바른 표현입니다. 가독성을 위해 수정하는 것이 좋습니다.

Suggested change
서비스의 범위와 기능으로 볼때는 응집도가 높아 분해하는 것으로 판단하기 어렵지만, 코드 변동성으로 볼때 구분이 되면 적절한 후보가 된다.
서비스의 범위와 기능으로 볼 때는 응집도가 높아 분해하는 것으로 판단하기 어렵지만, 코드 변동성으로 볼 때 구분이 되면 적절한 후보가 된다.


당연히 무작정 분해하는 것이 능사가 아니기 때문에 어떤 패턴이 확실히 드러나거나 지속적으로 확장될 거라는 확신이 생기기 전에는 하지 말아야 한다.
이 부분을 읽으면서 YAGNI 원칙이 생각났다, 대신 아키텍처로, 상위로 올라온 느낌.

정반대로 어떤 경우에 서비스를 다시 합쳐야 하거나, 애당초 서비스를 분리하지 말아야 하는지에 대한 부분도 있다.
**통합인:**
* 데이터베이스 트랜잭션
* 워크플로와 코러오그레피
* 공유 코드
* 데이터 관계

운영 데이터 분리에서도 나왔지만, 데이터베이스 트랜잭션만으로도 서비스를 분리하느냐 마느냐를 크게 결정하는 요인이라고 생각한다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 4, 2026

Choose a reason for hiding this comment

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

medium

문장 중간에 불필요한 공백이 두 칸 있습니다. 가독성을 위해 수정하는 것이 좋습니다.

Suggested change
운영 데이터 분리에서도 나왔지만, 데이터베이스 트랜잭션만으로도 서비스를 분리하느냐 마느냐를 크게 결정하는 요인이라고 생각한다.
운영 데이터 분리에서도 나왔지만, 데이터베이스 트랜잭션만으로도 서비스를 분리하느냐 마느냐를 크게 결정하는 요인이라고 생각한다.

데이터 무결성, ACID 트랜잭션의 필요성이 큰 경우에는 어쩔 수 없이 통합해야 한다.

서비스를 분해한다 해도 의존성이라는 것이 없어지는 것은 아니다.
따라서 서비스를 잘게 나누다 보면 언젠가는 서비스 간 통신이 점점 늘어나 부정적인 영향을 끼치기 시작하는 지점에 이르게 된다.
예를 들어 과도하게 디펜던시가 전이되면 SPOF가 발생할 수도 있고, latency가 각각 서비스 호출로 누적되어 응답성이 떨어지게 되는 것이다.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 4, 2026

Choose a reason for hiding this comment

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

medium

문서 내에서 의존성이라는 용어를 사용하고 있으므로, 일관성을 위해 디펜던시 대신 의존성으로 통일하는 것이 좋겠습니다.

Suggested change
예를 들어 과도하게 디펜던시가 전이되면 SPOF가 발생할 수도 있고, latency가 각각 서비스 호출로 누적되어 응답성이 떨어지게 되는 것이다.
예를 들어 과도하게 의존성이 전이되면 SPOF가 발생할 수도 있고, latency가 각각 서비스 호출로 누적되어 응답성이 떨어지게 되는 것이다.

성능 손실을 감수하면서까지 서비스를 반드시 분리해야 하는지 고민해야 한다.