chapter 8,9

Author: ymkim97

2026/Fundamentals_of_Software_Architecture_2nd_Edition/ymkim97/chapter8_9.md

@@ -0,0 +1,46 @@
+# 소프트웨어 아키텍처 The Hard Parts
+## 8장 ~ 9장
+---
+## 논의 내용
+* 코드 재사용 관리 기법인 코드 복제, 공유 라이브러리, 공유 서비스, 사이드카 중 기존 기법에서 어떠한 이유로 다른 기법으로 변경해본 경험이 있으시면 공유하면서 얘기해 보면 좋을 것 같습니다.
+  * 저의 회사는 현재 공휴일에 대한 데이터 및 날짜 계산이 공유 라이브러리에 있어 매년 수동으로 업데이트를 해줘야 한다는 단점이 있습니다. 따라서 데이터 오너십을 가지는 서비스를 지정하고, 이를 공유 서비스로 옮기려는 계획하고 있습니다(서비스에서는 스케쥴러로 open api를 사용하여 공휴일 db 최신화).
+
+## Chapter 8 - 재사용 패턴
+서비스를 분해하면서 기존의 공통 코드나 기능을 처리하는데에 있어서도 다양한 방법과 트레이드 오프가 발생한다.
+코드 재사용은 소프트웨어 개발에서 상식이기 때문에, 개발자들에게는 꽤나 당연하게 생각되어 코드 중복에 대해서 반응하는 편인 것 같다.
+따라서 DRY 원칙 등을 기억하고 실천하려고 한다.
+하지만 코드를 공유하거나 복제하는 것 중 하나만이 항상 정답이 아니기 때문에 다양한 기법을 알고 트레이드 오프를 분석해보아야 한다는 것을 배웠다.
+
+가장 단순한 코드 복제는 다른 공유 기법보다는 절대 우선시 되지 않는 방법이다.
+어떻게 보면 독립성의 특성을 보이는 마이크로서비스에 잘 맞는 기법으로 보이지만, 만약 수정 사항이 생긴다면 이 코드를 가지고 있는 모든 서비스를 업데이트 해야한다.
+대부분의 서비스에서 필요한 극히 정적인 일회성 코드, 독자적인 일회성 클래스라면 코드 복제 기법을 고려해 볼만 하다.
+
+가장 일반적인 방법 중 하나인 공유 라이브러리는 우리 회사에서도 잘 쓰여서 친근한 기법이다.
+공유 라이브러리는 크기에 따라 디펜던시와 영향을 받는 서비스의 수준이 제각각이다.
+공유 라이브러리가 크면 디펜던시는 낮아지고 영향을 받는 서비스는 올라가는 것이다.
+책에서는 단위가 큰 공유 라이브러리는 삼가하고 권고하며, 가능한 한 작은 단위, 즉 기능별로 분리된 공유 라이브러리를 만들어 디펜던시 관리보다 변경 관리에 더 신경을 쓰는 편이 낫다고 한다.
+
+공유 라이브러리를 대신하는 기법은 공유 서비스다.
+공유 서비스는 별도로 배포된 서비스 한 곳만 고치면 공유 기능을 필요로 하는 다른 서비스들을 다시 배포하지 않아도 간편하게 변경된 코드를 반영할 수 있다.
+하지만 이것 역시 변경 리스크, 성능, 확장성, 내고장성 등 다양한 트레이드 오프가 뒤따른다.
+
+사이드카와 서비스 메시는 이전에 몇번 들어본 기억이 있지만, 이번 책을 통해서 처음으로 구체적인 의미를 알게 되었다.
+사이드카 패턴은 도메인에서 운영 기능을 디커플링하는 좋은 방법일 뿐만 아니라, 특정한 종류의 커플링을 해소할 수 있는 직교적 재사용 패턴이라고 한다.
+마이크로서비스 아키텍처는 도메인 중심으로 구성되지만 운영 커플링은 모든 도메인에 두루 적용되므로, 사이드카 패턴을 이용하면 이렇게 아키텍처 레이어를 넘나드는 횡단 관심사를 따로 일관되게 격리할 수 있다.
+
+
+## Chapter 9 - 데이터 오너십과 분산 트랜잭션
+이번 챕터는 특히 요즘 회사에서 마주치는 실제 상황들과 잘 맞아 정말 재미있게 읽었다.
+개발 업무를 진행하면서 책에서 나오는 기법들을 나도 모르게 생각하고 어떤 것을 적용하는게 맞는지 고민이었는데, 이번 기회에 더 명확히 장단점을 곱씹어 볼 수 있었다.
+단독 오너십은 특별히 신경쓸 것이 없지만, 공통 또는 공동 오너십은 분산 아키텍처에서 결국 해결해야한다.
+책에서는 테이블 분할 기법, 데이터 도메인 기법, 대리자 기법, 서비스 통합 기법을 대표적으로 설명한다.
+회사에서는 대부분 대리자 기법을 사용하며, 주 도메인 우선 방법으로 담당하는 서비스를 지정한다.
+
+분산 트랜잭션 절을 읽으면서 BASE 속성을 제대로 배울 수 있게 되었다.
+이 용어 역시 어디선가 한번씩은 보았던 기억이 있지만, 이번 책을 읽으면서 훨씬 와닿게 되었다.
+
+핵심인 최종 일관성 패턴에서는 이벤트 기반 패턴을 주로 사용했어서 비교적 쉽게 읽혔다.
+가장 강한 동기화를 제공하는 것은 오케스트레이티드 요청 기반 패턴이지만, 이는 특히 보상 트랜잭션이 필요하기 때문에 복잡성이 증가한다.
+해당 부분에 대해서도 더 깊게 호기심이 있지만, 보상 트랜잭션과 트랜잭셔널 사가에 대해서는 12장에서 자세히 다룬다고 하니 기다려보면서 책을 읽어봐야겠다.
+
+