소프트웨어 아키텍쳐 The hard parts 5주, 6주차 - 최지윤

2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/09.md

@@ -0,0 +1,45 @@
+## Chapter 10: 분산 데이터 액세스
+
+### 개요
+
+- 서비스간 통신패턴: 서비스 간 데이터를 주고받는 방식
+  - 요청하는 대로 데이터를 다 줬다가는 레이턴시가 발생하므로 성능이 떨어진다
+  - 또한 여러 서비스가 데이터 때문에 커플링되어 의존성이 생기기 때문에, 한 쪽을 수정할 때 다른 쪽도 수정해야 하는 불상사가 발생
+
+---
+
+### 컬럼 스키마 복제 패턴
+
+- 컬럼을 여러 테이블에 복제해서, 다른 경계 콘텍스트에서도 가져다 쓸 수 있게 하는 방법
+- 데이터를 매번 동기화해야 함 => 일관성 유지 어려움
+- 데이터 오너십 통제 어려움
+  - 복제해서 다른 서비스에 쥐어주는 순간, 해당 데이터는 내 소유가 아니기 때문
+
+### 복제 캐싱 패턴
+
+- 데이터를 그대로 복사하여 새 테이블에 저장하는 것이 아니라, 대신 캐싱을 하는 방법
+- 캐시는 서비스별로 고유하게 저장되기 때문에 타 서비스와 공유되지 않음
+- 다른 캐싱 패턴
+  - 단일 메모리 캐싱: 각 서비스별 고유 캐시 데이터를 가지고 있음
+  - 분산 캐싱: 데이터를 외부 캐시 서버에 보관, 이 덕분에 서비스간 데이터 공유가 가능
+    - 캐시 데이터는 중앙으로 공유되기 때문에, 타 서비스에서 데이터를 자유롭게 업데이트 할 수 있는 것은 그대로고, 경계 콘텍스트도 무너질 수 있다
+    - 중앙 분산 캐시 (각 서비스별 캐시가 공유되는 위치) 는 원격 호출을 위해 접근해야 하므로 레이턴시가 늘어나는 것도 동일하다
+    - 대신 위의 스키마 복제 패턴과 동일하게, 디펜던시만 이동했을 뿐 동기화 문제에서 자유롭지 않다
+- 단점
+  - 경우에 따라 복제 캐싱이 지원되지 않을 수 있다
+- 장점
+  - 각 서비스별로 캐시를 갖고 있기 때문에 서로 간섭할 일이 없다
+  - 또한 각 서비스별 캐시에 접근하면 되므로 데이터 액세스가 빠르다
+- 트레이드오프
+  - 캐시 데이터와 시작 타이밍에 서비스가 크게 의존한다
+    - 각 서비스별로 캐시에 데이터를 채우므로, 그 캐시에 접근하는 다른 서비스는 해당 주인 서비스가 먼저 시작되어야 대기 상태에서 탈출할 수 있다
+  - 데이터 양이 많을 경우 실용성이 떨어진다
+    - 캐시 수만큼 용량이 \*n 이 되므로
+
+### 데이터 도메인 패턴
+
+- 여러 서비스가 공유하는 테이블을 하나의 스키마에 집어넣어 관리
+- 서비스가 서로 디커플링되어 디펜던시 문제와 응답성, 처리량, 확장성 이슈가 해소됨
+- 여러 서비스가 동일한 테이블을 바라보기 때문에, 무결성 문제에서도 자유롭다
+- 다만 해당 스키마의 테이블 구조가 변경될 경우 다른 서비스들도 영향을 받을 수 있다
+- 서비스 오너십과 경계 콘텍스트를 엄격하게 설정하여 타 서비스가 접근해야 하면 안될 데이터들을 적절히 막는 것이 좋다

2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/10.md

@@ -0,0 +1,61 @@
+## Chapter 11: 분산 워크플로 관리
+
+### 개요
+
+- 조정: 분산 아키텍처에서 도메인에 특정한 작업을 수행하고, 그와 관련된 부수적인 문제를 처리하기 위해 서비스를 조합하는 것
+
+---
+
+### 오케스트레이션 통신 스타일
+
+- 오케스트레이터 (중재자) 를 이용하여 워크플로 상태나 에러, 알림 등을 관장
+- 복잡한 워크플로를 오케스트레이션을 통해 하나의 관리자가 전담하여 관리한다
+- 에러 조건 및 경로를 다루는 것이 가장 어려운데, 오케스트레이터는 각 트랜잭션을 관리함으로써 각 서비스의 상태와 에러 여부를 관장한다
+- 장점
+  - 중앙화 워크플로: 상태와 동작을 통합한 컴포넌트 운용
+  - 에러 처리
+  - 복원성
+  - 상태 관리
+- 단점
+  - 응답성
+  - 내고장성
+  - 확장성
+  - 서비스 커플링
+
+```
+궁금증: ESB도 전역 오케스트레이터라는데, ESB는 서비스간 결합을 유도하기 때문에 오케스트레이션이랑 차이가 있다고 한다. 허나 그냥 오케스트레이터랑 ESB가 무엇이 다른지 이해가 안된다. 오케스트레이터 중 하나가 ESB라는게 아닌가?
+```
+
+---
+
+### 코레오그래피 통신 스타일
+
+- 중앙 조정을 하는 오케스트레이션과 달리, 각 서비스가 개별로 움직이는 스타일
+- 서로 통신하고 에러 처리도 한다
+- 허나 하나의 시나리오 진행 중에 서비스에서 오류가 발생할 경우, 이미 진행이 많이 되어 각 서비스를 거쳐간 상태이기 때문에 에러가 인지한 직후 이벤트를 생성해서 메시지를 브로드캐스팅해야 다른 서비스들이 볼 수 있다
+- 통신 경로가 많아질 수 밖에 없는 구조
+- 장점
+  - 응답성, 확장성, 내고장성, 서비스 디커플링
+  - 사실상 오케스트레이션과 반대됨
+- 단점
+  - 분산된 워크플로
+  - 상태 관리
+  - 에러 처리
+  - 복원성
+
+### 워크플로 상태 관리
+
+- 코레오그래피 통신 스타일에서는 워크플로의 상태를 관장하는 대장이 따로 없다
+  - 위에 오케스트레이션 방식에서는 오케스트레이터가 직접 관장했음
+- 이 경우 상태를 관장하는 방법이 다음과 같다
+  - 프론트 컨트롤러: 시나리오상 가장 먼저 호출된 서비스에게 책임을 맡기기
+  - 무상태 코레오그래피: 각 서비스별 스냅샷을 구축하여 워크플로 전이 상태를 유지하지 않음
+- 스탬프 커플링: 서비스 간 전송되는 메시지 계약에 워크플로 상태를 같이 넣어서 전달
+
+---
+
+### 오케스트레이션 <-> 코레오그래피 간 트레이드오프
+
+- 에러 빈도가 낮고, 에러 시나리오가 복잡하지 않으면 코레오그래피
+  - 확장성 면에선 코레오그래피가 훨씬 편하다
+- 경계 조건과 에러 조건이 너무 복잡하면 오케스트레이션

2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/11.md

@@ -0,0 +1,155 @@
+## Chapter 12: 트랜잭셔널 사가
+
+### 개요
+
+- 사가 패턴: 각 업데이트가 완료되면 이벤트를 발행하고, 다음 업데이트를 실행시키는 릴레이 트랜잭션
+- 만약 업데이트들 중 하나라도 실패하면, 보상 트랜잭션을 가동시켜 이전 모든 변경사항을 무로 되돌린다
+
+---
+
+### 트랜잭셔널 사가 패턴
+
+- 에픽 사가
+- 폰 태그 사가
+- 페어리테일 사가
+- 타임트래블 사가
+- 판타지 픽션 사가
+- 호러 스토리 사가
+- 패럴렐 사가
+- 앤솔로지 사가
+- 이름이 공식은 아니고 적당히 붙인듯
+
+---
+
+### 에픽 사가
+
+- 오케스트레이티드 사가 라고도 함
+- 동기 통신 + 원자적 일관성 + 오케스트레이션 조정
+- 트랜잭션 중 하나의 호출이라도 실패할 경우, 모두 실패한 것으로 처리해 이전 상태로 되돌림
+  - 성공 or 실패밖에 없다는 뜻
+- 보상 트랜잭션을 사용하여 구현
+  - 분산 트랜잭션 도중 다른 서비스가 수행한 작업을 되돌리는 업데이트
+  - 중재자는 요청 처리 성공여부를 모니터링하다가, 실패할 경우 다른 서비스를 보상호출 하여 중단
+- 높은 결합도 (복잡한 커플링)
+- 높은 복잡도
+  - 동기 호출이라 이에 대한 복잡도는 내려감
+- 응답성이 떨어짐
+- 이 패턴을 구현하기 위한 조정 및 병목은 확장성을 낮춤
+
+---
+
+### 폰 태그 사가
+
+- 에픽 사가에서 사용하는 조정방식을 오케스트레이션 > 코레오그래피로 바꿈
+  - 동기 + 원자성 + 코레오그래피
+- 텔레폰 게임 (한 사람이 다른 사람에게 비밀을 이야기하여 마지막 사람이 이를 맞추는 게임) 과 유사하여 이런 이름이 붙음
+- 오케스트레이터가 따로 없음
+  - 따라서 각 서비스별로 책임 체인을 갖고 실패시 거슬러 올라갈 수 있어야 함
+- 결합도는 에픽 사가에 비해 약간 줄어듦 (코레오그래피이므로)
+  - 큰 차이는 없음
+- 에픽 사가보다 훨씬 복잡해짐
+  - 오케스트레이터의 빈 자리를 채우기 위해 더 많은 로직이 각 서비스별로 들어가게 됨
+- 오케스트레이션이 없어졌으므로 응답성은 좋아짐
+  - 허나 에러 처리에 더 많은 시간이 소요되므로 이 때문에 응답성이 낮아질 수 있음
+- 마찬가지로 오케스트레이션을 사용하지 않아 확장성이 아주 조금 좋아짐
+
+---
+
+### 페어리테일 사가
+
+- 동기 + 최종일관성 + 오케스트레이션
+- 서비스가 잠시 중단되었을 경우, 최종 일관성을 통해 변경된 데이터를 일시 캐싱
+- 오케스트레이터가 존재는 하지만, 트랜잭션을 관리하지 않음
+  - 요청, 응답, 에러처리만
+  - 트랜잭션은 각 서비스가 알아서 관리
+- 동기 통신이라 이해하기 쉽고, 오케스트레이터가 있어 관리하기 쉬우며, 전체 트랜잭션이 없고 최종 일관성에 따라 서비스 각각이 수행하는 트랜잭션만 관리하면 됨
+- 결합도는 매우 높음 (동기 + 오케스트레이션)
+  - 단 트랜잭션이 최종 일관성으로 대체되어, 그에 따른 결합도는 약간 낮아짐
+- 복잡도가 매우 낮음 (최종일관성 + 오케스트레이션)
+  - 아주 간단한 조합으로만 만들어짐
+- 응답성
+  - 동기 호출이지만 빠른 편
+- 확장성
+  - 커플링 (결합도) 이 낮아 확장성도 좋음
+
+---
+
+### 타임 트래블 사가
+
+- 동기 + 최종일관성 + 코레오그래피
+- 중재자가 없으므로 도메인 서비스들이 알아서 워크플로우를 관리해야 함
+  - 요청을 받고, 작업 수행 후, 다음 서비스에 요청 전달
+  - 각 단계가 한 방향으로, 하나의 시간적 흐름으로 순차적으로 흘러감
+- 트랜잭션이 없어 워크플로 모델링이 쉽지만, 오케스트레이터가 없으므로 각 서비스별로 워크플로 상태와 정보를 다 가지고 있어야 함
+  - 워크플로가 복잡할 수록 오케스트레이터의 필요성이 증가
+  - 따라서 워크플로가 단순할 때 타임트래블 사가가 적합하다
+- 결합도가 비교적 낮고 확장성이 좋음
+- 트랜잭션이 없어 복잡도가 낮음
+- 동기 호출을 사용하기 때문에 오버헤드가 발생하여 응답성은 약간 낮은 편
+- 확장성이 매우 좋음
+
+---
+
+### 판타지 픽션 사가
+
+- 비동기 + 원자적 일관성 + 오케스트레이션
+- 에픽 사가와 비슷하지만, 비동기를 사용
+  - 따라서 분산 트랜잭션을 병렬로 수행
+  - 이 비동기성 때문에 중재자가 해야할 일도 복잡해진다
+- 오케스트레이터로 조정되는 워크플로가 비동기로 움직이는 것은 일을 더 복잡하게 만들기 쉽다
+- 비동기 통신 때문에 결합도는 매우 높음 => 복잡도도 높음
+- 다수의 호출에 의해 트랜잭션 조정이 이루어지므로, 하나 이상의 서비스가 실패하면 응답성도 수직 하락함
+- 트랜잭션 체제를 사용하므로 높은 확장성 얻기가 어려움
+- 단점만 잔뜩 있는데, 비동기 통신 하나로 에픽 사가의 단점을 상쇄할 수 있다는 믿음 때문에 많이 사용되는 편
+  - 정말 별로라는 뜻
+
+---
+
+### 호러 스토리 사가
+
+- 이름부터가 호러이다
+- 비동기, 원자적 일관성, 코레오그래피 사용
+- 원자적 일관성이라는 가장 엄격한 체제 아래 가장 느슨하게 만드는 비동기 통신과 코레오그래피가 어우러져 있는 매우 최악의 조합
+- 중재자가 없기 때문에, 각 서비스들은 비동기성 때문에 언제 어디서 어긋날지 모를 트랜잭션을 계속 추적하고 되돌릴 준비를 해야 한다
+  - 하나의 트랜잭션 호출이 실패할 경우 해당 파트를 전부 되돌려야 하는데, 이 조건이 매우 까다롭기 때문에 에러 처리가 매우 어렵다고 할 수 있다
+- 결합도는 에픽 사가보단 낫다 (중재자를 사용하지 않으므로)
+- 매우 복잡하다
+- 중재자 패턴이 아니므로 확장은 비교적 잘 된다
+- 서비스끼리 지속적으로 통신해야 하므로 좋지 않은 응답성
+
+---
+
+### 패럴렐 사가
+
+- 비동기 통신, 최종 일관성, 오케스트레이션
+- 에픽 사가에서의 동기 통신에 기반된 트랜잭션 패턴은 성능 저하가 일어날 수밖에 없으므로, 이를 비동기와 최종일관성으로 보완
+- 중재자가 있으므로 복잡한 워크플로에 적합하다
+- 제약조건이 느슨한 대신, 각 단계에서 발생할 에러나 문제점을 중재자에 떠맡기므로, 이 부분에서의 타이밍 문제와 안정성이 떨어지게 된다
+- 결합도가 낮으면서 복잡도도 같이 낮다
+- 확장성이 매우 좋다
+- 비동기 통신 덕이 응답성도 좋다
+
+---
+
+### 앤솔로지 사가
+
+- 에픽 사가의 정반대
+- 비동기 통신, 최종 일관성, 코레오그래피
+  - 결합도가 낮을 수밖에 없는 요소 조합
+- 중앙 조정 기능이 없기 때문에 서비스는 복잡해지지만, 그 외의 특성 면에선 좋아진다
+- 단순하면서 선형적으로 진행되는 워크플로에 적합
+  - 중앙조정 기능이 없기 때문에 단순한 워크플로에 적합한 것
+  - 성능이 높아야 하고, 확장성도 추구한다면 가장 적합
+- 결합도가 매우 낮은 대신, 복잡도가 매우 높다 (코레오그래피 때문)
+- 확장성, 탄력성은 결합도가 낮으므로 같이 낮음
+- 응답성 높음
+
+---
+
+### 상태 관리와 최종 일관성
+
+- 상태 관리와 최종 일관성은 유한 상태 기계를 통해 현재 사가 상태를 파악하고 오류를 해결하는 방법
+  - 사가 상태 기계: 분산 아키텍처에서 있을 법한 모든 가능한 경로를 기술하는 패턴
+    - 각 상태가 변경될 때마다 수행할 액션과 전이 상태가 등장
+    - 모든 상태 전이와 그에 해당하는 액션 목록을 정리하고, 이를 토대로 코드로 구현하는 것이 좋음
+  - 사가 관리 기법: 상태들을 enum화 하고 트랜잭션을 클래스로 구현하는 것 같다

2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md

@@ -0,0 +1,53 @@
+## Chapter 13: 계약
+
+### 개요
+
+- 계약: 종류가 다른 아키텍처 파트가 어떻게 연결될 것인지 정의한 것
+  - 아키텍처의 거의 모든 부분에서 영향을 끼친다
+- 하드 파트 계약: 어떤 정보나 디펜던시를 전달하기 위해, 아키텍처의 각 파트에서 사용되는 포맷
+- 계약이란 곧 프레임워크와 라이브러리 간의 디펜던시, 통합점, 각 서비스간 통신 등 서로를 연결시키는 모든 기술들을 포괄하는 개념
+
+---
+
+### 엄격한 계약 vs 느슨한 계약
+
+- 엄격한 계약: 이름, 타입, 순서 등 세부사항을 전부 준수하고, 모호한 부분을 남기지 않음
+  - 단, 여러 아키텍처 파트에서 두루 쓰이면서 자주 변경되는 경우, 엄격한 계약에 취약점이 생길 수 있다
+  - JSON 에 키, 값 쌍을 엄격하게 제한할 수 있다
+- 느슨한 계약: 커플링이 느슨한 경우
+  - REST, 그래프QL 등
+  - 다른 개발자가 하나의 리소스와 기능을구축하고 이 리소스를 확장한다고 해도, 특정 기능이 갑자기 문제가 생기지 않는 경우
+- 필요한 정보 외에도 갖은 정보들을 다 계약에 넣어버릴 경우, 취약점이 생기기 쉽다
+  - 예를 들어, 고객의 위시리스트는 고객의 이름 식별자만 있으면 된다
+  - 허나 고객의 성별, 나이 등의 정보까지 제공해버리면 안티패턴
+  - 또한 해당 정보가 수정될 경우 계약이 깨지면서 위시리스트 기능까지 수정해야 할 수도 있다
+- 트레이드오프
+  - 엄격한 계약
+    - 계약 충실도 보장 (계약만으로 스키마 검증 가능)
+    - 버저닝
+      - 장점이자 단점인데, 적절하지 못한 버저닝 (버전을 너무 많이 만들거나 너무 적게 만들기) 는 서비스를 더 복잡하게 만든다
+    - 빌드 시 검증이 쉽다
+    - 문서화하기 좋음
+    - 커플링이 단단해짐 (한 쪽 변경하면 다른 쪽도 변경해야 함)
+  - 느슨한 계약
+    - 높은 디커플링, 매우 유연함
+    - 스키마 정보가 엄격하지 않으므로, 계약을 더 자유롭게 발전 가능
+    - 계약 자체가 엄격하지 않으므로, 이름 - 값 쌍 누락 또는 철자 오류 등 결합이 발생할 여지가 큼
+    - 피트니스 함수를 통해 느슨한 계약을 수행하는 데 필요한 정보가 모두 들어오는지 확인이 필요
+- 마이크로서비스에서는?
+  - 여러 서비스의 관계와 전달되는 정보, 결합도를 생각해야 한다
+- 컨슈머 주도 계약
+  - 사용자가 서비스 제공자로부터 받고 싶은 정보를 계약에 넣고, 이를 토대로 빌드에 포함시켜 계약 테스트를 수행하는 기법
+  - 필요에 따라 계약을 엄격하게 하거나, 느슨하게 할 수 있다
+  - 자동 테스트로 테스트 가능하므로 이 부분에선 엄격할 수 있다
+  - 단, 기술자가 이 절차들을 정확히 인지하고 지켜야 한다
+
+---
+
+### 스탬프 커플링
+
+- 서비스 끼리 매우 큰 데이터를 주고받지만, 각 서비스는 그 데이터 안에서도 매우 작은 일부만 사용하는 경우
+- 위의 위시리스트 예시에서, 고객의 이름 (또는 ID) 만 있으면 되지만 모든 회원 정보를 전부 제공하는 경우?
+- 데이터 때문에 계약에 과도한 커플링이 발생하면서, 전체 구조가 매우 취약해진다
+- 대역폭에 비해 너무 큰 데이터가 오고가면서 통신에 문제가 생길 수 있다
+- 코레오그래피 방식을 사용할 수 밖에 없는 경우, 스탬프 커플링을 이용하여 도메인 정보, 워크플로 상태를 계약에 넣어 전달하면 각 서비스는 이를 받아 계약 상태와 워크플로 상태를 업데이트하여 다음 서비스에 전달할 수 있다