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

2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/13.md

@@ -0,0 +1,24 @@
+# 13장
+
+- 논의주제
+    - 그림 13-7에서 위시리스트 서비스에서 name만 필요한 경우에 프로필 서비스에서 name 이외의 값까지 응답으로 주는 것을 스탬프 커플링이라고 말하며 안티패턴이라고 말하고 있습니다. 이것이 안티패턴이라면, HTTP API상에서는 실제로 name을 요청할 때 name만 주는 API를 만드는 방법밖에 없다고 생각되는데, 어떤 다른 방법이 있을까요?
+- 실험
+    - RMI
+    - gRPC
+    - 그래프QL
+- 요약
+    - 계약과 스탬프 커플링 문제
+- 키워드
+    - 계약
+        - 정의
+            - 분산된 아키텍처의 여러 조각들을 서로 연결하는 모든 수단과 데이터 규격
+        - 종류
+            - 엄격한 계약
+            - 느슨한 계약
+    - 스탬프 커플링
+- 내생각
+    - 내가 경험해 본 엄격한 계약과 느슨한 계약은 책에서 말하는 내용과는 조금 다르지만, 백엔드 개발 시 API의 요청 스키마와 응답 스키마를 쓰느냐 마느냐로 볼 수 있을 것 같다. 파이썬으로 백엔드 개발할 당시에는 따로 요청, 응답 스키마를 정의하지 않고 JSON 값을 그대로 받아서 사용하거나 응답값으로 만들어서 사용했는데, 가장 큰 장점은 개발을 빠르게 할 수 있다는 점이다. 반면에 나중에 JSON의 크기가 커지는 경우, 유효성 체크 로직이나 응답값을 만드는 로직 등이 별개의 함수 혹은 비즈니스 로직에 그대로 있는 경우가 많아서, 유지보수가 매우 힘들었던 경험이 있다. 파이썬3 이후에 pydantic을 쓰고, FastAPI나 Django Ninja 같은 프레임워크를 사용하면서는 반드시 요청과 응답 스키마를 미리 정의하고 썼는데, 개인적으로 회사에서 개발을 한다면 추후 유지보수를 생각해서라도 반드시 쓰는 것이 좋다고 생각한다
+    - 우리 회사에서는 기본적인 BE 서버 간 통신에서 REST, 단순 JSON 정도 사용하는 것으로 보인다. 책에서 나온 대로 엄격한 계약이 크게 유리한 경우가 없기 때문에 굳이 필요성을 못 느낀 것이 아닐까 생각되고, 가장 대중적이고 쉽고 빠르게 할 수 있는 것을 선택한 것이 아닐까 싶다
+    - 책에 나온 엄격한 형태에 대해서 무조건 해야 한다는 것은 아니지만, REST를 사용하더라도 가능한 엄격한 계약으로 안정성과 유지보수성을 챙기는 것을 기본으로 한 상태에서 선택적으로 느슨한 계약 쪽도 고려하는 것이 좋다고 생각한다. 그 이유는 유지보수성이 낮은 코드에 너무 많이 당했기 때문이다. 예전에는 엄격하게 하기 위해서 작성해야 하는 코드들도 많았는데, 이제는 AI가 나오면서 이런 코드들은 금방 작성할 수 있기 때문에 굳이 작성하지 않을 이유가 없다고 생각한다
+    - 컨슈머 주도 계약의 아이디어 자체는 좋은 것 같다. 하지만 현실적으로 적용하기는 쉽지 않을 것 같은데, 무엇보다도 빠른 개발 속도가 중요한 작업에서는 항상 컨슈머 쪽의 의존성을 가지게 되기 때문에 매우 좋지 않을 것 같고, 그나마 안정성 자체가 중요한 곳이라면 도움이 될 수 있는 프로세스일 것 같은데, 내 생각에는 차라리 빨리 개발해서 QA를 진행하는 것이 더 낫다고 생각한다
+    - 스탬프 커플링 문제는 흔히 발생하는데, API를 분리할지 통합 API로 한 번에 받을지 선택의 기로에서 늘 결정해야 하며, 이때 통합 API를 하는 쪽으로 선택할 때 발생하게 된다. 책에서는 안티패턴이라고 하지만, 나는 안티패턴이라고 생각하지는 않고 필요할 때는 쓸 수 있다고 생각한다

2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/14.md

@@ -0,0 +1,15 @@
+# 14장
+
+- 논의주제
+    - 없음
+- 요약
+    - 분석용 데이터를 어떻게 저장해서 사용할 것인가?
+- 키워드
+    - 데이터 웨어하우스
+    - 데이터 레이크
+    - 데이터 메시
+- 내생각
+    - 회사의 사례는 어떤지 확인해 보았는데, 일단 기본적으로는 데이터 웨어하우스로 빅쿼리를 사용하고 있고, 책에는 없지만 데이터 레이크하우스를 준비하고 있다고 한다
+    - 회사에서는 EDW라고 해서 분석용 데이터베이스로 인지하고 있는데, 빅쿼리에서 직접 쿼리를 요청하는지 앞단의 서버가 있는 것인지는 모르겠지만, 매일 새벽에 서비스의 DB Read 인스턴스에서 모든 테이블의 정보를 쿼리해서 빅쿼리에 적재하고 있다. 그 외에도 CDC를 하거나 Multi Source Replication 등으로도 적용하고 있는 것으로만 알고 있다. 그래서 사실 개발자 단에서는 따로 신경 쓰는 부분이 아니기는 하고, 관련 작업을 하시는 분들과도 직접적인 연관은 없는 편이다
+    - 데이터 레이크의 경우는 실제로 경험해 보지는 못했는데, 내용을 봤을 때 데이터 웨어하우스와 반대로 정제되지 않은 데이터를 저장하고 정제되지 않은 채로 조회하는 것 같다
+    - 데이터 메시 또한 마찬가지인데, 앞에서 나왔던 사이드카 패턴의 DB 버전이라고 보면 될 것 같다

2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/15.md

@@ -0,0 +1,19 @@
+# 15장
+
+- 논의주제
+    - 요즘 들어서 경험보다는 실험을 많이 해 보아야 한다는 말을 많이 하고 있는데, AI 발전으로 인해서 실험할 수 있는 환경이 제대로 갖추어졌기 때문입니다. 책에서 나오는 트레이드오프 분석도 AI로 인해서 분석하기 매우 좋아졌습니다. 트레이드오프 분석을 위해서 구체적으로 AI를 어떤 식으로 활용해서 제대로 해 볼 수 있을지 이야기해 보면 좋을 것 같습니다
+- 요약
+    - 나만의 트레이드오프 분석 방법 및 주의점
+- 키워드
+    - 연관된 차원
+    - 트레이드오프 기법
+- 내생각
+    - 이 책 내용의 요약은 15장에서 나오는데,
+        - 의사결정할 때 트레이드오프 표 작성(상황에 따라 적절히 골라라)
+        - ADR을 기록해 결정된 내용을 문서화(의사결정 기록을 남겨놔라)
+    - 책에 나오는 MECE 리스트의 경우 설명이 너무 어렵게 나온 것 같은데, 쉽게 설명하면 빈틈없이 리스트를 작성하는 것이다. 시중에 MECE 역량을 키우기 위한 문제집 같은 것도 있으니 한번 풀어 봐도 좋다
+    - 트레이드오프 검토 시에는 반드시 컨텍스트에 따라 의사결정을 해야 하는데, 그렇지 않게 되었을 때 구성원들의 반발을 살 수 있고, 베스트 프랙티스(라는 주장)만 찾아가다가 오히려 더 망칠 수도 있다(헥사고날 등)
+    - 사실 어떤 아키텍처 의사결정을 할 때는 컨텍스트를 고려하는 것이 가장 첫 번째가 맞고, 책에서 나온 대로 의사결정할 때 산으로 가지 않고 더 빠르게 가는 길이라고 생각하며, 기술 자체에 너무 매몰해서 컨텍스트 고려를 미루지 않는 것이 좋을 것 같다
+    - 책에서는 도메인 시나리오를 모델링하는 기술을 연마해서 실험을 통해 트레이드오프 분석과 의사결정을 할 수 있는 능력을 배양해야 한다고 말한다. 과거에는 단순히 모델링을 하고 이를 통해서 미래를 예측해 보는 정도였지만, 현재는 단순히 모델링하는 것을 넘어서 AI로 주도적으로 직접 기획 → 개발 → QA까지 모두 빠르게 해 볼 수 있기 때문에, 이런 부분은 개발자들에게 더 좋아진 부분이라 볼 수 있다
+    - 에반젤리즘이 너무 심한 사람, 너무 심하지 않은 사람 둘 다 겪어 본 입장에서 일단 둘 다 별로 좋지 않지만, 그래도 개인적으로는 심한 사람이 더 좋지 않았던 것 같다. 흔히 에반젤리즘이 심한 사람들은 기능에만 너무 치우쳐서 위에서 말한 컨텍스트를 제대로 파악하지 못한 경우를 많이 본 것 같다
+    - 대표적으로 컨텍스트를 고려하지 못하는 경우는 본인의 성과와 업적, 승진을 위해서 특정 서비스에 어떤 것들이 좋으니까 적용하자고 하는 경우인데, 개인적으로 이런 경우가 많다고 알고 있어서 좀 씁쓸한 부분이 있기는 하다