소프트웨어 아키텍처 The Hard Parts 2주차 - 권태형

2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/4.md

@@ -0,0 +1,29 @@
+# 4장
+
+- 논의 주제
+    - 전술적 분기의 경우 모놀리스의 코드 구조가 어떻게 되어있든 만능으로 활용할 수 있다고 생각하고, 먼저 빠르게 전술적 분기를 적용한 이후에 코드 리팩토링을 하는 전략을 가져간다면, 컴포넌트 기반 분해의 각각의 스텝을 천천히 가져가면서, 실행을 늦출 필요가 있을까? 라는 생각이 들었습니다 다른 분들은 이부분에 대해서 어떻게 생각하시는지 의견이 궁금합니다
+- 요약
+    - 아키텍쳐 분해 방법 2가지가 존재하고, 가라로 하는 방법과 면밀하게 설계해서 하는 방법이 있다
+- 키워드
+    - 컴포넌트 기반 분해
+    - 전술적 분기
+- 내용
+    - 아키텍쳐 분해 방법
+        - 컴포넌트 기반 분해
+        - 전술적 분기
+    - 주요 개념들
+        - 구심/원심 커플링
+            - 의존성의 방향과 책임의 흐름을 나타냄
+        - 추상도/불안정도
+- 내 생각
+    - 컴포넌트 기반 분해는 애초에 컴포넌트 별로 잘 분해가 되어 있는 상태라면, 잘 분해된 컴포넌트 별로 분해하는 작업은 별로 어렵지 않은 작업일 것으로 보인다. 반면, 전술적 분기는 애초에 코드 상태에 상관 없이 할 수 있는 전략으로 보인다. 
+
+    컴포넌트 별로 잘 분해하기위한 전제조건은 컴포넌트 별로 유지보수 관리가 잘 되고 있어야한다는 점이다. 그러나 제대로 유지보수 관리가 되지 않았다면, 컴포넌트의 경계가 희미해지고, 분해를 위해서 다시 정리를 해야하는 일이 발생할 것 같다. 
+
+    반대로, 전술적 분기는 코드의 상태가 상관이 없기 때문에, 더 과감하게 해볼 수 있지 않을까 생각된다
+
+    물론, AI를 활용한다면, 전자/후자가 큰 차이는 없을거 같은데, 실행을 빠르게 해볼 수 있다는 측면에서 개인적으로는 전술적 분기로 일단 분해를 하고 나서, 일반적으로는 AI를 통해서 리팩터링하는게 더 좋은 방법이지 않을까 생각됩니다
+    4장에서 아키텍쳐 분해와 관련된 개념들인 구심/원심 커플링, 추상도/불안정도의 경우는 기존의 정적분석 도구를 통해서도 충분히 정확한 값을 잘 측정해볼 수 있었을 것 같다. (명확한 정의와 수식이 있기 때문에, AI 에게 시켜도 잘 할 것 같다)
+
+    책에서 이 값들을 활용하는 구체적인 사례를 제시하진 않는데, 내가 생각하는 활용 방법은 위 개념들에 대한 결과 지표를 우리 회사에 있는 마이크로서비스들 각각을 상대적 기준의 지표로 활용하는 것이다. 
+    실무자 레벨에서, 실질적으로 도움이 되는 지표는 아닐거 같은데, 회사차원에서는 사내 각 마이크로 서비스 별 현황을 알 수 있고, 앞으로 개선이나 관리 포인트 등을 잡을 때 좋을 것 같다

2026/Fundamentals_of_Software_Architecture_2nd_Edition/taehyoung/5.md

@@ -0,0 +1,40 @@
+# 5장
+
+- 논의 주제
+    - 공통 기능을 식별해서, 별도의 클래스 혹은 패키지로 추출하는 기준은 각 회사, 팀, 사람 마다 다를 것 같습니다. 공통 기능을 식별해서 추출하는 시점은 어느정도로 잡으시는지, 공통 기능 추출을 어느정도 중요도로 판단하고 있는지 얘기해보면 좋을 것 같습니다
+        - 나의 답변
+            - 기타 의견
+                - 일단 책의 예제는 너무 쉽습니다. 책의 예제를 기준으로는, 당연하게도 공통기능으로 식별해서 추출하는게 맞다고 생각합니다.
+            - 답
+                - 제 개인적으로는 정말로 재활용도가 높은 유틸리티성 기능이 아니라면, 섣부르게 추상화해서, 공통 기능으로 추출하는 것은 최대한 자제하는 편이고, 충분히 코드베이스에 익숙해지고, 코드의 변화 패턴이 보일 때, 천천히 추출하는 편입니다. 이렇게 하는 이유는 섣부르게 추출해서 되돌리는 것보다, 충분히 시간을 가지고 관찰하다가 나중에 추출해서 공통기능을 만드는 것이 더 이득이라고 생각하기 때문입니다. 그래서 스스로 공통기능을 추출하는 것에 조급해하지 않는 편이라 생각합니다.
+                    - 코드 수정을 해야 할 때, 중복되는 코드들을 같이 고쳐야 하는 경우가 많지 않다면, 어느정도 중복은 허용해도 별 문제 없다는 입장
+- 요약
+    - 감이 아닌, 논리적인 사유를 바탕으로한 분해패턴을 적용해서, 점진적으로 통제가능한 컴포넌트 분해를 진행하자
+- 키워드
+    - 컴포넌트 기반 분해
+- 내용
+    - 컴포넌트 기반 분해 패턴
+        - 컴포넌트 식별 및 사이징
+        - 공통 도메인 컴포넌트 수집
+        - 컴포넌트 눌러 펴기
+        - 컴포넌트 디펜던시 결정
+        - 컴포넌트 도메인 생성
+        - 도메인 서비스 생성
+- 내 생각
+    - 5.1 컴포넌트 식별 및 사이징
+        - 컴포넌트 사이즈를 측정하는 용도로 문장을 활용하는 것은 모든 문제를 해결해주진 않지만, 그렇다고해서 전혀 참고하지 못할 지표는 아니라고 생각한다. 문장이 많다는 것은 다르게 말하면, 조건문 등이 많다는 것을 의미하고, 이는 도메인 규칙이 많다라고도 볼 수 있기 때문이다. 대개의 경우 도메인 규칙이 많으면, 도메인이 복잡하다고 생각해볼 수 있다는 측면에서 이 문장을 컴포넌트 사이즈를 측정하는 지표로 활용하는 것은 나쁘지 않은 선택이라고 생각한다
+        - 이 컴포넌트 사이즈를 아키텍트의 의도를 담아 일관적으로 관리하기 위해서, 이에 맞는 피트니스 함수를 쓰는 것은 매우 적절한 선택으로 볼 수 있다. 다만, 현실세계에서 이렇게 까지 제약을 두는게 맞을까에 대해서는 조금 의문이 들고, 실제로 해보면서 느껴봐야 효용성을 알 수 있을 것 같다
+        - 이러한 피트니스 함수를 적용하는 것은 빌드 시점 혹은 github workflow 에 추가해볼 수 있을 거 같고, AI를 활용하면 매우 쉽게 구현하면서 적용해볼 수 있을 것 같다 개인프로젝트에서 한번 테스트 해보면 좋을거 같다
+    - 5.2 공통 도메인 컴포넌트 수집 패턴
+        - 책의 예제는 공통 도메인의 추출할지 결정하기에 좀 쉬운 예제인 것 같다. 현실세계에서는 책의 예제보다 더 복잡한 경우가 많고, 이를 잘 판단해서 추상화할 수 있는 것이 개발자의 역량이라고 생각한다
+        - 개인적으로는 공통 코드에 대해서는 조심스럽게 접근해야한다고 생각하는데, 충분히 성숙치 않은 상태에서 성급하게 추상화 했을 때, 이전 보다 유지보수가 어렵게 될 수 있기 때문이다. 충분히 성숙했다고 판단이 되었을 때, 공통으로 묶는 것을 고려하면 좋을거 같다
+        - 중복코드인지 판별하는 피트니스 함수는 조금 과한 것 같다는 생각이다. 굳이 피트니스 함수가 없어도 사람이 식별할 수 있는 수준으로 보이기 때문이다(컴포넌트 사이즈와 비교했을 때)
+    - 5.3 컴포넌트 눌러펴기
+        - 5장 내용 중에서 가장 실무에서 활용 해볼 법한 내용이 아닐까 생각된다. 실제로 어떤 식으로 컴포넌트 분리 혹은 합칠지에 대해서는 사람마다 기준이 모호해서 논쟁의 여지가 있는 부분인데, 책에서 나온 평탄화 방법 2가지는 확실한 기준으로써 활용가치가 있다고 생각했다
+        - 이렇게 평탄화 작업을 했을 때의 장점은 모든 소스코드가 최하위 노드에만 존재하기 때문에 도메인 분류와 실제 기능을 하는 컴포넌트의 경계를 명확히 나눌 수 있다는 점이고, 이로 인해서 도메인 파악을 하기 더 쉽지 않을까 라는 생각이 들었다(실제 책의 예제를 봤을 때도 이전보다 훨씬 명확해진 느낌)
+    - 5.4 컴포넌트 디펜던시
+        - 컴포넌트 간 의존성을 판단하는 것은 굳이 말을 하지 않아도 당연한 결과이고, 의존성이 적을수록 마이크로서비스로 분리하기 훨씬 쉽다는 것도 어찌보면 상식으로 볼 수 있다
+    - 5.5 컴포넌트 도메인 생성 패턴
+        - 컴포넌트 도메인 생성 패턴은 네임스페이스의 체계를 조정함으로써, 컴포넌트들의 의도를 더 잘 나타낼 수 있게 해주는 도움을 준 것 같다
+    - 5.6 도메인 서비스 생성 패턴
+        - 그림 5-22를 그냥 보는 것 만으로도, 어떤 도메인으로 이루어진 서비스들인지 한눈에 알 수 있어서 좋았다