Skip to content

Commit 0b149b0

Browse files
TaeHyoungKwonTaeHyoungKwon
authored
Merge pull request #602 from ThinkAboutSoftware/thkwon-2026-sprint3
소프트웨어 아키텍처 the hard parts sprint 3 - 권태형
2 parents 49e73d9 + 60f2533 commit 0b149b0

3 files changed

Lines changed: 93 additions & 0 deletions

File tree

‎2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/6.md‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# 6장
2+
3+
- 논의 주제
4+
- 6장에서 경계 컨텍스트(Bounded Context) 사례로 서비스 C와 D 사이의 데이터 계약 관계에 대해서 말하고 있다. 책에서는 이렇게 데이터를 나누었기 때문에 데이터베이스 D에서 발생한 중대 변경으로 부터 서비스 C가 추상화 되는 장점이 있다고 말하고 있고, 이는 모놀리스 서버를 BC 별로 분리함으로써 얻는 MSA 의 장점으로도 볼 수 있을 거 같은데, 단점은 얘기하고 있지 않고 있다. 어떤 단점이 발생할 수 있을지에 대해서 실제 겪은 일 혹은 머릿속에서 상상해본 사례를 공유해보면 좋을 것 같다
5+
- 실제 겪은 일
6+
- 경계 컨텍스트(Bounded Context)를 아무리 잘 고려해서, MSA를 구축해도, 비즈니스 복잡도가 심해질 수록, 처음 설계와 다르게 예외상황이 발생함. 이때 선택은 예외가 발생한것을 처리할 MS(Micro Service)를 하나 더 만들지, 기존에 존재하던 MS에 통합할지 두가지 방법이 있다
7+
- 하지만, 두 가지 모두 좋지 않은 결과를 초래하는데, MS를 더 만들게 되면, 그만큼 점점 서버 관리 비용이 올라가게 되고, 그렇다고 기존 MS에 통합하게 되면, 기존에 나눠둔 경계 컨텍스트 설계의도가 무색해짐
8+
- 이렇게 되면서, 단순히 쿼리조회 1번으로 끝날 작업을 불필요하게 API로 조회요청을 해야하는 경우가 발생하게 되고, 오히려 모놀리식이었으면 금방끝냈을 작업이 여러 MS 들 간에 API호출이 필요하게되는 경우가 발생함
9+
- 대개 경계 컨텍스트로 팀이 나뉘는 경우가 많은데, 이런 경우 팀 간의 소통이 필요하게 되고, 소통이 원활하지 않을 때, 소통 비용이 발생하게 됨
10+
- 경계 컨텍스트(Bounded Context)를 잘 나누었다는 전제에서, MS간 통신 방식을 EDA(Event Driven Architecture)로 설계 했을 경우, 이벤트 정의, 순서, 소실을 신경써야 하고, 그다지 복잡하지 않은 비즈니스로직을 가진 백엔드 애플리케이션이라면, 배보다 배꼽이 커지는 경우가 발생하게 됨
11+
- 요약
12+
- 변경으로 인한 장애 격리 가능성을 고려해서 분해를 하고, 데이터를 어떤 서비스에 저장할 것인지를 기준으로 통합을 하자
13+
- 키워드
14+
- 데이터 분해인
15+
- 데이터 통합인
16+
- 모놀리식 데이터베이스 분해 5단계 프로세스
17+
- 데이터베이스 종류
18+
- 내용
19+
- 데이터 분해인
20+
- 변경 관리
21+
- 데이터베이스 스키마 변경이 다른 서비스들을 망가뜨리는 것을 막기 위해 데이터를 나눈다
22+
- 커넥션 관리
23+
- 서비스들 마다 단위 시간당 필요한 DB 커넥션 수가 다를 수 있기 때문에 이를 별도로 관리하기 위해서 데이터를 나눠서 관리해야한다
24+
- 확장성
25+
- 서비스는 쉽게 확장되는데, 공유 데이터베이스가 그 속도를 따라가지 못해 발목을 잡는 상황을 막자
26+
- 내결함성
27+
- 한 바구니에 담긴 달걀을 여러 바구니로 나누어, 하나가 깨져도 나머지는 살리는 전략
28+
- 아키텍쳐퀀텀
29+
- 아키텍쳐 퀀텀이 1이라면, 그자체가 데이터 분해인
30+
- 데이터베이스 타입 최적화
31+
- 데이터베이스에 저장하는 데이터 타입에 따라서, 데이터 분해인이 발생할 수 있음
32+
- 데이터 통합인
33+
- 데이터 관계
34+
- 반드시 분해되어야만 하지 않는다면, 통합해서 aggregate 경계 식별을 위해서, 연관 관계를 맺어라(RDB의 경우)
35+
- 데이터베이스 트랜잭션
36+
- 반드시 트랜잭션이 보장되어야 하는지
37+
- 내생각
38+
- 책 맨 앞에서 설하나 님의 반응은 정상적이라고 생각한다. 최이본 님이 말하는 데이터베이스 분리를 해야하는 이유가 충분치 않기 때문이다.
39+
- 분해인 과 통합인은 각각 분해를 해야하는 명분과 통합을 해야하는 명분이라고 보면, 좀 더 이해하기가 쉽다
40+
- 데이터 분해인들을 종합해서 말하자면, 결국엔 변경으로 인한 장애 격리 가능 여부를 따지는 것으로 볼 수 있다. 쉽게 말하면, 변경하다가 잘못해서 장애가 발생했을 때, 전체에 영향을 미치는지, 제한적으로 격리된 상태로 영향을 미치는지로 보면 된다
41+
- 반면에 통합인의 경우는 기준이 다르다. 각 서비스 마다 고유한 데이터를 소유한다고 할 때, 그 고유한 데이터들을 DB에 쓰기를 하는 기준으로 볼 수 있다. 즉, 어떻게 쓰기작업을 원활하게 할 것인가를 기준으로 통합할지에 대한 명분을 고려해볼 수 있다
42+
- 이 내용은 DDD의 BC 혹은 aggregate 경계를 식별할 때, 읽기가 아닌, 쓰기를 기준으로 나눈다는 것과 같은 맥락으로 볼 수 있고, 이런 유사한 점들 때문에, MSA와 DDD가 자주 같이 언급된다고 볼 수 있을 것 같다
43+
- 그래서, 사실 사가 패턴을 통해서 분산 트랜잭션을 보장해야하는 경우가 있다면, 오히려 데이터 분해와 통합을 제대로 못한 것의 결과로 볼 수 있다고 생각한다. 사가 패턴을 써야하는 상황이라면, 그전에 데이터 분해와 통합이 제대로 되었는지 부터 확인해보는게 필요하다고 생각한다

‎2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/7.md‎

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
# 7장
2+
3+
- 논의주제
4+
- 적절한 세분도를 측정하기 위해서 책에서는 정량적 분석이 가능한 인터페이스의 개수나 기준의 수를 언급하고 있습니다. 저는 현실과 동떨어진 방법이라고 생각하고, 오히려 비즈니스 임팩트나, 장애 상황에서 격리가 되어야하는지 여부가 세분도 측정에도 포함이 되어야 한다고 생각하는데, 적절한 세분도 측정 방법에 대해서 논의해보면 좋을 것 같습니다
5+
- 내 의견
6+
- 퍼블릭 인터페이스나 기능 수를 기준으로 서비스 세분도 값 자체를 측정하는 것은 크기를 짐작할 수 있다는 점에서는 유용할 수 있지만, 중요도의 측면에서는 판단할 수 없다고 생각된다. 세분도를 통해서 마이크로서비스의 크기를 판단할 때는, 단순히 코드에서 제공하고 있는 인터페이스의 양적인 측면이 아니라, 비즈니스 임팩트 기준으로 임팩트가 큰지, 장애 상황에서 격리가 되어야하는지 기준을 고려하는 것도 중요할것 같다.
7+
- 만약 책에서 말한대로 세분도를 측정하게 된다면, 마땅히 해당 서비스에서 개발해야할 API 인데도 불구하고, 기존에 이미 세분도가 크기 때문에(제공하는 인터페이스와 기능이 많음) 개발을 거부할 수 있는 명분이 되기 때문이다
8+
- 요약
9+
- 데이터의 분해, 통합인과 큰 맥락에서는 같다
10+
- 좀 더 넓은 범위에서 분해와 통합인을 고려하는 것으로 이해하면 적절할 것으로 보인다
11+
- 키워드
12+
- 세분도
13+
- 내용
14+
- 세분도 분해인
15+
- 세분도 통합인
16+
- 내 생각
17+
- 책 초반부에 오선빈 님이 `감으로만 분석을 하니 뭐 하나 진행하기가 쉽지 않네요` 라고 말하면서, 감으로 하는 것은 문제가 있는 것처럼 말하고 있다. 실제 현업 기준에서는 정량적분석 보다 정성적분석으로 하는 경우도 많은 것 같고, 사람의 직감이란 것이 본인의 경험에 기반으로 나오는 것이다보니, 경우에 따라선 감으로 만 해도 좋은 결과를 얻는 경우도 있는 것 같다
18+
- 마이크로서비스의 마이크로가 작다를 의미하기 때문에, 최대한 작게 쪼개야한다고 주장하는 것은 너무 일차원적이라고 생각된다 어떤 학문을 배울 때, 용어의 의미를 기준으로 단정적으로 보고 주장하는 것은 좋지 못한 태도라고 생각하고, 이 마이크로의 의미가 어떤 맥락일지에 대해서는 고민이 필요한 부분이라고 생각된다. 개인적으로는 모놀리스 서비스에 상대적으로 대비된다는 측면에서의 마이크로라고 보는게 맞다고 생각한다.
19+
- 단일 책임 원칙이 마이크로서비스의 근간이라는 말의 출처가 어딘지 궁금하다 객체지향에서 객체를 설계하는 원리와 마이크로 서비스를 설계하는 원리가 비슷한 측면이 맞아서, 그 기준으로 충분히 생각해볼 수 있고, 더 쉽게 설계를 시도해볼 수 있다는 장점은 있을거 같다. 다만, 객체지향에서의 객체를 다루는 것과 현실 세계에서 MS를 다루는 것은 관리 비용 차이부터 많이 나기 때문에, 단순히 단일 책임 원칙 하나만으로 MS를 설계하는 것은 부족하다고 생각한다
20+
- 서비스 세분도는 서비스가 무엇을 하느냐에 따라 달라지기 때문에, 이상적인 마이크로 서비스 설계라면, 마이크로서비스가 최대한 한가지 책임만 가지도록 설계하는 경우가 많은데, 이런 경우에 현실세계에서 가장 큰 문제는 마이크로서비스 유지보수 비용이 너무 많이 든다는 점이다. 그래서 마이크로서비스 설계 시에는 반드시 유지보수 비용까지 고려해서 설계해야한다고 생각한다
21+
- 세분도의 분해인도 데이터 분해인과 마찬가지로, 분해하거나 통합해야하는 명분은 변경에 의한 장애 발생 시, 격리 가능한가? 의 기준에서 생각해볼 수 있다
22+
- 마찬가지로 통합인도 동일한 맥락에서 생각할 수 있는데, 통합했을 때, 훨씬 더 작업처리에 유리하고, 분해했을 때, 더 고려해야할 것인 많을 때(분산 트랜잭션으로 인한 데이터 정합성 문제)는 차라리 통합하는게 낫다는 것이다
23+
- 책에서 나오는 많은 분해인, 통합인도 매우 도움이 되는 것들이라고 생각되는데, 각각을 다 이해하고 활용할 수 없다면, 어떤 게 쉬운 방법일까? 를 생각해보는게 좋을것 같다. 쉽게 풀 수 있는 방법이 있는데, 굳이 어려운 방법을 할 필요는 없기 때문이고, 이 쉬운 방법을 고민하다가 보면, 자연스럽게 책에서 말하는 분해인과 통합인이 나올 것 같다는 생각이다
24+
- 맨 마지막에 고객등록 세분도 사례의 경우는 애초에 고객 정보는 한 트랜잭션에 보장되어야하는 니즈가 강했기 때문에, 아키텍쳐도 그렇게 결정이 된 것이라고 봐야 할 것 같다. 다만 현실세계에서는 트랜잭션을 보장 못하게 설계할 수밖에 없는 상황도 있기 때문에, 정답이라고 보기 보다는 해당 사례에서 의도에 맞게 잘 설계된 걸로 봐야 할 것 같다

‎create_pr.sh‎

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -43,6 +43,23 @@ get_title() {
4343
done
4444
}
4545

46+
# Issue ID 입력 및 검증
47+
get_issue_id() {
48+
while true; do
49+
read -p "Issue ID를 입력하세요 (필수): " ISSUE_ID
50+
if [ -n "$ISSUE_ID" ]; then
51+
# 숫자 검증
52+
if [[ "$ISSUE_ID" =~ ^[0-9]+$ ]]; then
53+
break
54+
else
55+
echo "오류: Issue ID는 숫자여야 합니다. 다시 입력해주세요."
56+
fi
57+
else
58+
echo "Issue ID는 필수입니다. 다시 입력해주세요."
59+
fi
60+
done
61+
}
62+
4663
# PR 본문 입력 (다중 라인 지원)
4764
get_body() {
4865
echo "PR 본문을 입력하세요 (여러 줄 입력 가능, 입력 완료 후 Ctrl+D):"
@@ -54,12 +71,20 @@ get_body() {
5471
exit 0
5572
fi
5673
fi
74+
75+
# Issue 연결 키워드 자동 추가
76+
if [ -n "$BODY" ]; then
77+
BODY="${BODY}"$'\n\n'"Closes #${ISSUE_ID}"
78+
else
79+
BODY="Closes #${ISSUE_ID}"
80+
fi
5781
}
5882

5983
# Dry-run 미리보기
6084
dry_run() {
6185
echo "=== PR 생성 미리보기 ==="
6286
echo "제목: $TITLE"
87+
echo "연결된 Issue: #${ISSUE_ID}"
6388
echo "본문:"
6489
echo -e "$BODY"
6590
echo "리뷰어: $REVIEWERS"
@@ -75,6 +100,7 @@ main() {
75100
check_prerequisites
76101

77102
get_title
103+
get_issue_id
78104
get_body
79105

80106
# Dry-run 확인

0 commit comments

Comments
 (0)