diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter6_7.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter6_7.md
new file mode 100644
index 00000000..25b31f97
--- /dev/null
+++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter6_7.md
@@ -0,0 +1,65 @@
+# 소프트웨어 아키텍처 The Hard Parts
+## 6장 ~ 7장
+---
+## 논의 내용
+* 서비스를 분리하면서 고려해야 하는 것 중 각자 생각하는 가장 큰 걸림돌이 무엇인지 의견이 궁금합니다.
+> 저 같은 경우에는 트랜잭션 관리라고 생각합니다. 분산 환경으로 가는 순간 하나의 물리적인 트랜잭션은 불가능하여 데이터 일관성, 무결성에 대한 문제를 해결하는 것 때문입니다. 물론 Saga 패턴 등 으로 해결 방법은 존재하나, 모든 기능에 대해서 이런 패턴으로 커버해야하는지 판단하기 어렵다고 느낍니다. 예를 들어 결제와 같은 기능이 다른 서비스와 통신을 한다면 중요하기 때문에 당연히 해결해야 하지만, 새로 만드는 기능이 비교적 덜 중요한다 하더라도 적용해야 할지 입니다. 자신에게 주어진 리소스와 시간은 한정적이기 때문에 정말 모든 기능에 적용하는 것이 맞을지, 그렇다면 오버 엔지니어링은 아닐지 의문이긴 합니다.
+
+## Chapter 6 - 운영 데이터 분리
+지금까지 책을 읽으면서 슬슬 궁금했던 데이터베이스의 분해에 대해서 나와서 재미있게 읽을 수 있었다.
+모놀리식 데이터베이스 분해는 실제로 애플리케이션 기능보다 훨씬 더 분해하기 어려우므로, 데이터 분해인이 중요하며, 데이터 통합인도 역시 중요하다.
+데이터 분해인은 변경 관리, 커넥션 관리, 확장성, 내고장성, 아키텍처 퀀텀, 데이터베이스 유형 최적화로 나누어서 생각할 수 있다.
+분해의 반대로 데이터 통합인은 데이터 관계, 데이터베이스 트랜잭션을 생각할 수 있다.
+
+데이터를 분해하면서 생기는 가장 큰 골칫거리는 트랜잭션이라고 생각하며, 대다수의 엔지니어들이 동의하지 않을까 예상한다.
+모놀리스 데이터베이스는 하나의 물리적인 트랜잭션이면 해결되지만, 분산 환경으로 가는 순간 그것이 불가능 하기 때문에 어쩔 수 없이 데이터 일관성, 무결성 이슈가 발생한다.
+이를 해결하기 위해 트랜잭셔널 사가 등이 있으며 더 깊게 가고 싶지만, 12장에서 자세히 다룬다고 나와 있으니 일단 넘어가기로 한다.
+
+애플리케이션에서 도메인 별로 서비스를 나누듯이 데이터베이스를 분석하여 데이터 도메인을 생성하면서 분해를 시작한다.
+한번에 데이터베이스를 나눌 수는 없으니, 데이터 도메인을 생성(구분) 해낸 후, 데이터 도메인마다 스케마를 만들어 테이블들을 각자 속한 스키마로 옮긴다.
+이때 서로 다른 데이터 도메인에 속한 테이블 간에 밀접한 연관성과 커플링이 존재한다면, 해당 데이터 도메인들은 반드시 통합해야 한다.
+
+데이터베이스를 분리하면서 각 데이터 도메인을 특성에 맞게 데이터베이스 타입을 선택할 수 있다.
+표준이라고 할 수 있는 관계형 데이터베이스 뿐만 아니라, 키-값, 문서형, 컬럼형, 그래프, NewSql, Cloud native, 시계열 등 정말 다양하다.
+이렇게 다양한 DB 기술들을 혼합하여 사용하는 것을 폴리글랏 데이터베이스라고 하며, 책에서 한빛가이버는 고객 설문은 문서형으로 마이그레이션 하기로 결정했다.
+
+문서형에서도 단일 애그리거트 문서와 분할된 애그리거트 문서가 있다. (Survey : Question)
+이 역시 장단점이 존재한다.
+단일 애그리거트 문서는 한번의 get으로도 온전한 고객 설문 데이터를 데이터베이스에서 가져올 수 있으므로 여러 개발 팀 사람들이 데이터를 쉽게 사용할 수 있다.
+다만 각 설문 문서마다 문항이 중복된다.
+
+분할된 애그리거트 문서는 동일한 문항을 여러 설문에서 사용할 수 있는 반면, 화면 렌더링 및 데이터 검색은 단일 애그리거트보다 힘들어진다.
+
+## Chapter 7- 서비스 세분도
+각 서비스의 크기를 정하는 것에 대한 내용이 주인 챕터다.
+서비스를 나누면 크기가 너무 작거나, 커질 수 도 있기 때문에 그 크기(세분도)를 올바르게 결정해야 하지만 매우 어렵다.
+분산 아키텍처를 생각하면 분해를 먼저 떠올리고 집중하기 쉬운데, 결국 통합도 중요하다.
+
+**분해인:**
+* 서비스의 범위와 기능
+* 코드 변동성
+* 확장성/처리량
+* 내고장성
+* 보안
+* 신장성
+
+같은 예시 (책에서 나오는 알림 - sms, 이메일, 우편 - 서비스)에서도 각 분해인에 따라 적합 여부가 달라진다.
+서비스의 범위와 기능으로 볼때는 응집도가 높아 분해하는 것으로 판단하기 어렵지만, 코드 변동성으로 볼때 구분이 되면 적절한 후보가 된다.
+
+당연히 무작정 분해하는 것이 능사가 아니기 때문에 어떤 패턴이 확실히 드러나거나 지속적으로 확장될 거라는 확신이 생기기 전에는 하지 말아야 한다.
+이 부분을 읽으면서 YAGNI 원칙이 생각났다, 대신 아키텍처로, 상위로 올라온 느낌.
+
+정반대로 어떤 경우에 서비스를 다시 합쳐야 하거나, 애당초 서비스를 분리하지 말아야 하는지에 대한 부분도 있다.
+**통합인:**
+* 데이터베이스 트랜잭션
+* 워크플로와 코러오그레피
+* 공유 코드
+* 데이터 관계
+
+운영 데이터 분리에서도 나왔지만, 데이터베이스 트랜잭션만으로도 서비스를 분리하느냐 마느냐를 크게 결정하는  요인이라고 생각한다.
+데이터 무결성, ACID 트랜잭션의 필요성이 큰 경우에는 어쩔 수 없이 통합해야 한다.
+
+서비스를 분해한다 해도 의존성이라는 것이 없어지는 것은 아니다.
+따라서 서비스를 잘게 나누다 보면 언젠가는 서비스 간 통신이 점점 늘어나 부정적인 영향을 끼치기 시작하는 지점에 이르게 된다.
+예를 들어 과도하게 디펜던시가 전이되면 SPOF가 발생할 수도 있고, latency가 각각 서비스 호출로 누적되어 응답성이 떨어지게 되는 것이다.
+성능 손실을 감수하면서까지 서비스를 반드시 분리해야 하는지 고민해야 한다.