소프트웨어 아키텍처 The Hard Parts 1주차 - 김지수

2026/Fundamentals_of_Software_Architecture_2nd_Edition/tttghost/chapter 1.md

@@ -0,0 +1,65 @@
+# 1장 '베스트 프랙티스'가 없다면?
+
+## 주요 내용
+하드파트: 어렵다와 단단하다의 뜻  
+아키텍처 설계는 한번 정해놓으면 쉽사리 바꿀 수 없게 되기에 그만큼 근본적이다.  
+마이크로서비스: 나는 해당하는 부분이 없지만 서버팀에서 서버 설계 시 각 파트별로 나눠서 작업했던 걸 본 기억이 있다  
+
+오케스트레이션  
+여러 서비스 호출의 순서, 성공/실패 판단, 보상 동작까지 하나의 흐름으로 책임지는 중앙 제어 로직  
+
+데이터는 모든 것: 데이터 설계가 가장 중요하다.  
+운영데이터와 분석데이터가 있다.  
+운영데이터는 회사 시스템이 돌아가는 데 필요한 데이터다. 정합성, 트랜잭션이 중요  
+분석데이터는 서비스를 이해, 개선, 판단을 위한 데이터로 트랜잭션과 무관하며 과거 누적 축적형 데이터로 현재 운영에   필요하진 않지만 장기적인 전략 수립 및 의사결정에 중요하게 활용되는 데이터다.  
+
+아키텍처 거버넌스  
+시스템이 커져도 방향을 잃지 않게 하는 '기술 헌법'이다.  
+잘못 이해한 경우 = 통제 지옥  
+잘 이해한 경우 = 자유를 유지하기 위한 최소 규칙  
+
+아키텍처 피트니스 함수  
+관리해주는 함수. 피트니스 클럽은 몸을 관리해주지만 피트니스 함수는 아키텍처를 관리해준다.  
+필연적으로 트레이드오프가 발생할 수밖에 없다. 더 빠르게-더 정확하게, 더 강하게-더 가볍게 등  
+목표가 하나라면 상관없지만 둘 이상이면 바로 트레이드오프가 발생한다.  
+
+피트니스 함수와 단위테스트는 비슷하지만 다르다.  
+비슷한 부분은 자동 검증 + 실패 시 즉시 차단이라는 것인데  
+피트니스 함수는 아키텍처의 특성을 검증하는 것이고  
+단위테스트는 로직의 정확성을 보는 것이다. 즉 도메인 로직을 본다.  
+
+코드 위생 도구인 소나큐브는 피트니스 함수의 재료를 턴키 방식으로 제공한다.  
+자바 진영의 아크유닛이라는 도구는 소나큐브와 다르게 경고 수준이 아닌  
+"이 구조는 금지"라는 규칙을 테스트로 정의해 차단할 수 있다.  
+닷넷 진영에도 넷아크테스트(NetArchTest)라는 도구가 있다.  
+
+피트니스 함수는 대부분 반복/자동화해 사용하지만 간혹 수동으로 실행해야 하는 경우도 있다.  
+민감한 법률 정보가 담긴 시스템은 합법성을 준수해야 하기에 변호사가 직접 검토해야 하므로 자동화할 수가 없다.  
+
+이런 아키텍처 피트니스 함수가 중요한 이유는 엔터프라이즈 수준의 거버넌스 사례를 볼 때 지속적으로 체크해야 하는 영역이기 때문이다.  
+제로데이 익스플로잇이 발견될 수도 있지만, 지속적인 피트니스 함수로 구조, 의존성, 권한 경계 등을 체크한다면 그 확산과 피해를 최소화할 수 있다.  
+
+피트니스 함수는 아키텍처 구조를 설계하는 사람에게 단비 같은 존재이다.  
+모든 코드를 직접 많이 볼 수는 없지만(코드의 디테일이 아니라 구조의 방향성을 보기 위함), 피트니스 함수를 통해 프로젝트의 구조와 상태를 검증할 수 있기 때문에 해당 프로젝트의 전반적인 방향성을 잡을 수 있다.  
+
+하지만 피트니스 함수의 과용은 금물이다.  
+너무 복잡한 피트니스 함수는 오히려 설계 의도를 흐리고, 개발자에게 '무엇을 지켜야 하는지'를 모호하게 만든다.  
+
+아키텍처와 설계는 구분되어야 한다.  
+아키텍처 결정 - 구조 설계  
+
+아키텍처의 기본 원칙을 이해할 때는 How보다 Why가 더 중요하다.  
+아키텍처 개념에 집중하면 구현부에 대한 상세한 이야기는 과감히 건너뛸 수 있다.  
+구현 과정을 일일이 따라가기 시작하면 논의 범위가 지나치게 방대해지기 때문이다.  
+
+아키텍처의 개념들은 다음과 같이 볼 수 있다.  
+서비스, 커플링, 컴포넌트, 동기통신, 비동기통신, 오케스트레이션, 코레오그래피(오케스트레이션과 반대), 원자성, 컨트랙트(계약) 등이 있다.  
+
+사가(Saga)는 영웅적인 업적을 기리는 긴 이야기라는 의미에서 유래했다.  
+결제 서비스와 배송 서비스가 있을 때, 결제 서비스는 성공했지만 배송 서비스가 실패한 경우, 오케스트레이션 사가를 통해 결제 취소라는 보상 트랜잭션을 실행하여 사가를 실패 상태로 종료한다.  
+
+## 논의 주제: 아키텍처 검증의 자동화와 수동 검토
+피트니스 함수에서 자동화한 부분(소나큐브, 아크유닛 등)과 수동으로 검토해야 하는 부분이   
+있다고 나오는데 실무에서 이 두 부분에 대한 경험이 있으신가요?  
+
+어떤 것을 자동화하였고 어떤 것을 왜 사람이 직접 해야 했는지 궁금합니다.