소프트웨어 아키텍처 the hard parts sprint 5 - 권태형

2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/10.md

@@ -0,0 +1,19 @@
+# 10장
+
+- 논의주제
+    - 일반적인 MSA 환경에서, 내 것이 아닌 데이터를 조회하기 위해서 가장 많이 사용하는 패턴은 서비스 간 통신 패턴과 컬럼 스키마 복제 패턴이라고 생각하고, 대개의 경우 둘 중에 하나를 선택하는 것 같습니다. 본인의 기준이 어떻게 되는지에 대해서 추가로 의견 나눠보면 좋을 것 같습니다
+        - 책에서 나온 각 패턴의 장단점은 일반론에 가까운거 같고, 실제 업무에서 어떤 기준으로 선택하는지를 기준이 되면 좋을거 같습니다
+- 요약
+    - 내 것이 아닌 데이터를 어떻게 조회해 올 것인가?
+- 키워드
+    - 서비스 간 통신 패턴
+        - 필요한 서비스에 조회해서 값을 가져옴(동기)
+    - 컬럼 스키마 복제 패턴
+    - 복제된 캐싱 패턴
+    - 데이터 도메인 패턴
+- 내 생각
+    - 서비스 간 통신 패턴을 사용 했을 때, 책에서 말하는 정도의 latency 이슈는 상황에 따라 다르겠지만, 대개의 경우에는 크게 고려하진 않는 거 같다.(물론 데이터 조회 빈도가 높고, 실제로 latency가 중요한 상황에선 당연하게도 중요하겠지만… 이 말인 즉, 대개의 서비스 간 통신 패턴을 사용할 때, 데이터 조회 빈도도 그리 많지않고, latency도 중요하지 않다면, 쓰지 않을 이유가 없다고 생각된다) 오히려, 서비스 간에 커플링된다는 점이 훨씬 더 중요한 문제이고, 의사결정 시에 중요한 요소이지 않을까 생각된다
+    - 컬럼 스키마 복제 패턴에서, 데이터 오너십 통제가 어렵다는 것이 딱히 틀린 얘기는 아니지만, 일반적으로 이벤트를 통해서 해당 값의 CUD 를 제어하는 것외에 별도로 값을 수정하진 않는 거 같다. 즉, 실제로 데이터 오너가 다른 MS 에 저장된 데이터가 오염될 수 있다는 걱정을 하지만, 이벤트를 구독하는 MS에서도 사실 그 데이터를 따로 가공하거나 하지 않는다는 것이다
+    - 회사에서 컬럼 스키마 복제 패턴을 많이 사용하는데, 사내에서도 사용 사례를 살펴보면, 사실상 서비스 간 통신 패턴과 양분되어 있는 것 같다. 그래서 대개는 둘 중에 어떤 것을 할지 선택의 기로에 서게 되는데, 그 판단 기준은 상황에 따라, 담당자가 누군지에 따라서 다른데 대개의 기준은 어떤 값이 필요한데, DB에 저장할만한 가치가 있는가? 를 기준으로 DB에 저장해서 내부에서 내가 데이터 오너인것 처럼 작업을 하는게 필요한 상황일 때는 컬럼 스키마 복제 패턴을 많이 활용하는 것 같다. 추가로, 도메인 경계 상 크게 관련이 없는 서비스 간에도, API 호출을 통해 의존성을 가지도록 하는 것 보다는 의존성이 없도록 하려는 목적으로 컬럼 스키마 복제 패턴을 많이 활용하는 것 같다. 이 결정을 할 때, 상황을 잘 고려해야하는데, 잘못 선택하는 순간 괜한 데이터를 DB에 가지고 있는 상황이 있을 수도 있고, 우리 서비스 경계와 전혀 다른 서비스에서 장애가 났는데, 그 장애가 전혀 관련 없는 우리 서비스까지 전파될 수도 있기 때문이다. 아무튼 상황에 맞춰서 판단해야한다
+    - 복제 캐싱 모델의 경우, 내가 있는 회사의 환경에서는 경험해보지 못한 패턴이다. 경계 컨텍스트가 일치하는(즉, 같은 팀에서 운영하는 MS 범위) 환경에서는 편의상 써봄직할만한 것 같다
+    - 데이터 도메인의 경우 경험해 본 적은 있지만, 합리적 의사결정에 의해 선택했다기보다는 부채로 남겨둔 것으로 보는게 맞을 것 같다 다행히, 데이터를 CUD 하는 주체가 확실하였고, 트래픽도 많지 않았기 때문에, 운영하면서 큰 문제는 없었지만, 책에서 나온대로, 만약에 전혀 다른 경계 컨텍스트를 가진 MS 끼리 묶는 경우엔, 서로 이 의존성 때문에 불편한 경우가 생기지 않을까 생각된다f

2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/11.md

@@ -0,0 +1,18 @@
+# 11장
+
+- 논의주제
+    - 책 내용을 봤을 때, 오케스트레이션과 코레오그래피 + 프론트 컨트롤러는 거의 같은 것으로 보입니다. 차이가 있다면, 오케스트레이션에서의 오케스트레이터는 워크플로우 자체만 신경 쓰는 MS 라는 점이고, 코레오그래피의 프론트 컨트롤러는 MS 자체에서 처리하는 비즈니스로직도 있으면서, 워크플로우의 상태관리 까지 책임지는 느낌 입니다. 이 상황에서 발생하는 문제들은 워크플로우가 복잡할것을 고려해서 오케스트레이션 방식을 선택했지만, 워크플로우가 별로 복잡하지 않은 경우에 오버엔지니어링 일 수 있다는 것, 그리고, 응답성과 확장성 때문에 코레오그래피 + 워크플로우를 선택 했지만, 워크플로우가 너무 복잡해지는 문제가 생기는 경우 입니다. 각각의 경우 모두 문제가 생겼을 때, 반대로 돌아가기에 선택의 부담이 크다고 느껴지는데요 이런 상황에서 각각 어떤 선택을 하실지에 대해서 궁금하고, 실제 사례도 있다면 얘기해보면 좋을거 같습니다
+- 요약
+    - 쪼개진 시스템에서 어떻게 하나의 업무 흐름을 유지할 것인가?
+- 키워드
+    - 오케스트레이션
+    - 코레오그래피
+        - 상태관리
+            - 프론트 컨트롤러
+            - 무상태 코레오그래피
+            - 스탬프 커플링
+- 내 생각
+    - 11-5 그림에서, 책에서는 주문서비스에 주문정보를 먼저 업데이트 하는 것을 먼저 수행되도록 전제하여서 말하고 있는데, 결제완료부터 되고 나서 주문 서비스에 주문정보를 업데이트 하는게 관리차원에서 더 낫지 않을까? 라는 생각이 들었다
+    - 오케스트레이션의 경우엔, 책에선 복잡한 flow를 처리할 때 더 좋은 선택일 수 있음을 말하는데, 사실 이 사유 보다는 팀의 상황이 어떻게냐에 따라서, 오케스트레이션 혹은 코레오그래피가 갈리지 않을까 생각된다. 팀의 상황이 모든 개발자가 하나의 개발팀으로써 오케스트레이션 역할을 하는 MS를 메인으로 활용하고 있다고 한다면, 오케스트레이션의 대상이 되는 MS들은 오케스트레이터의 명령을 수행하는 수동적인 형태가 될 수밖에 없을 거 같고, MS 설계도 요런 형태로 되지 않을까 싶다. 반대로 팀 자체가 각 도메인 경계 별로 확실히 나누어져 있고, 각 팀의 목소리와 권력이 각각 비슷비슷 하다면, 자연스럽게 코레오그래피 형태로 가지 않을까 생각된다
+    - 현재 회사에서는 주문 워크플로우를 코레오그래피로 구성해서 처리하고 있고, 상태관리는 완전히 같진 않지만, 프런트 컨트롤러 패턴으로 진행하고 있다
+    -

2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/12.md

@@ -0,0 +1,25 @@
+# 12장
+
+- 논의주제
+    - 현재 실무에서 MSA 환경에서 MS를 운영하고 있을 때, 현재 본인의 팀에서 적용하고 있는 트랜잭션 관리 방법이 어떤 것이 있고, 관련된 장단점을 얘기해보면 좋을것 같습니다
+- 요약
+    - 분산 서버 환경에서 트랜잭션 관리를 어떻게 할 것인가?
+- 키워드
+    - 트랜잭셔널 사가 패턴
+        - 에픽 사가
+        - 폰 태그 사가
+        - 페어리 테일 사가
+        - 타임트래블 사가
+        - 판타지 픽션 사가
+        - 호러 스토리 사가
+        - 패러럴 사가
+        - 앤솔로지 사가
+    - 최종 일관성
+- 내 생각
+    - 예전에 어떤 아티클인지, 책인지에서 사가 패턴 적용을 통해 보상 트랜잭션을 다양한 경우를 고려해서 적용해야하면 할 수록 MS 설계를 의심해봐야한다는 말을 본적이 있다. 즉, 분산환경에서 트랜잭션을 유지하려고하는 시도 자체가 MSA 철학과 모순되는 행동이라는 것이다. 책에서도 에픽 사가 부분에서, 보상트랜잭션 적용의 어려움에 대해서 기술을 하고 있는데, 실무에서 사가패턴을 의도하고 적용한건 아니지만, 비슷한 맥락에서 적용해보았을 때, 뭔가 잘못된거 같은 느낌을 받았던적이 많았던 것 같다(이렇게 하는게 맞나? 너무 복잡한데? 라는 생각이 많이 듬) 책에서는 모놀리스 환경에서의 DB 트랜잭션을 통해서 원자성과 무결성 을 지키려는 컨셉을 MSA 도 동일하게 지키려는 시도로 에픽 사가 패턴을 소개하고 있고, 이 패턴 자체가 익숙하게 많이 사용되긴하지만, 그렇다고해서 반드시 지켜야할 법칙같은 건 아니라는 생각이다. 오히려, 모놀리스 적인 사고에 갇혀서, MSA 철학 자체를 제대로 이해하지 못하는게 아닌지 생각해볼 필요가 있다고 느꼈다(애초에 트랜잭션이 중요한 서비스 라면, MS를 나눌 때부터, 트랜잭션 처리에 문제 없도록 했었어야 한다고 생각함)
+    - 페어리 테일 사가는 책에서 저자가 극찬하는 패턴인데, 실제 사례가 있다면, 단점은 없었는지에 대해서 확인해보고 싶다는 생각이 들었다 글로만 봤을 때는 어떤 장점이 있는지 잘 와닿게 이해되진 않았다
+    - 판타지 픽션 사가에서 나오는 복잡도가 증가했을 때 일어날 수 있는 교착상태, 경합 조건, 수많은 병렬시스템 난제들의 경우에 실제로 발생한다고 했을 때, 시스템 유지보수에 매우 큰 병목이 될것 같다는 생각이 들었다
+    - 각각 사가 패턴들의 특징들과 주의해야할점들 등등을 보면, 결국에는 상황에 따른, 최악이 아닌 선택이 있을뿐이고, 상황이 변경됨에 따라서 그에 맞게 아키텍쳐도 변경이되어야만 흔히 말하는 지옥을 겪지 않을 수 있지 않을까? 라는 생각이 들었다. but, 아키텍쳐 레벨에서의 구조 변경은 코드를 변경하는 수준 보다도 훨씬더 부담스럽고 큰 작업이기 때문에, 대부분의 회사에서는 어쩔 수 없이 지옥에 가더라도 그걸 순순히 받아들이고, 유지보수에 열을 올리는게 아닌가? 라는 생각이 들었다
+    - 이 장에서 제공하는 사가 패턴들의 경우는 특정 패턴을 하나 정해서, 서비스에 적용하는 형태로 하는 것 보다, 우리 서비스의 어떤 워크플로우를 어떻게 관리할 것인지에 대한 설계가 선행되어야 한다고 생각한다. 선 설계가 된 이후에, 책에 있는 패턴들에 매칭되는 것을 찾고, 어떤 점들을 신경써야할지 설계를 검토하거나 구현 이후에 운영에 참고를 하는 방식으로 사용되면 좋지 않을까? 라는 생각이 들었다
+    - 맨 마지막에 나오는 사례는 실제 실무에서도 충분히 있을법한 일로 보이고, 이게 바로 MSA의 지옥이라고 볼 수 있다고 생각된다. 책에서 제시한 아주 복잡하게 꼬이는 상황이 평시에는 잘 발생하지 않지만, 장애가 발생할 때 문제가 발생할 가능성이 높아지고, 장애 처리가 오래걸리는 원인이 된다
+    - 맨 마지막 노건우님이 말하는 테일 사가 혹은 패러렐 사가패턴을 고려해보라고 하면서, 하는 얘기는 실제 현재 실무에서도 활용되고 있다. 가게 사장님이 주문을 수락 하는 경우에, 수락 요청이 중간 MS에서 어떤 사유로 실패하더라도, 주문을 취소 시키지 않는데, 그 이유는 회사와 사장님 입장에서는 주문을 최대한 수용하는게 더 이득이기 때문이다. 그래서 실패가 탐지되면, 내부 MS들에서 문제 원인을 빠르게 확인하고 자동 혹은 수동으로라도 주문 자체가 정상처리될 수 있도록 하는데, 이부분이 해당 하는 사례로 볼 수 있을거 같고, 결국 최종 일관성만 만족하면 되기 때문에 가능한 것으로 볼 수 있다