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

2026/Fundamentals_of_Software_Architecture_2nd_Edition/tttghost/chapter 1.md

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

2026/Fundamentals_of_Software_Architecture_2nd_Edition/tttghost/chapter 2.md

@@ -0,0 +1,25 @@
+# 2장 아키텍처 퀀텀
+
+## 논의주제
+분산 아키텍처에 대한 이해도가 한 단계 깊어졌다고 느낀 경험이 있으신지 궁금합니다.  
+예를 들어 처음에는 "기능 단위로 쪼개는 것이 분산 아키텍처지!" 라고 생각했다가,  
+트레이드오프 분석을 거치며 "이 기능들은 오히려 통합하는 편이 좋겠군." 라고 판단하게 된 경우처럼,  
+이와 비슷한 사고의 전환을 직접 경험하신 사례가 있다면 함께 이야기해 보면 좋겠습니다.  
+
+## 감상평
+분산 아키텍처에 대해서는 현업에서 직접 다뤄본 적이 없어 솔직히 잘 모른다.  
+용어도 익숙하지 않고, 실제로 왜 필요한지도 막연했다.  
+그래서 처음엔 책에 나오는 디커플링이나 이벤트 같은 말들이 그냥 정답처럼 느껴졌다.  
+
+그런데 책을 계속 읽다 보니, 분산 아키텍처가 만능은 아니라는 뉘앙스가 반복해서 보였다.  
+무언가를 나눈다고 해서 문제가 사라지는 게 아니라, 다른 종류의 문제가 생긴다는 느낌이었다.  
+특히 변경이나 배포 같은 현실적인 문제는 생각보다 고려할 게 많다는 점이 인상적이었다.  
+
+커플링이라는 용어는 예전부터 들어왔지만, 이 책을 통해 조금 다르게 느껴졌다.  
+코드만 분리한다고 독립이 되는 게 아니라, 실제로 함께 움직일 수밖에 없는 덩어리들이 존재한다는 점.  
+책에서 말하는 아키텍처 퀀텀은 그런 ‘함께 움직이는 단위’를 인정하라는 개념처럼 받아들여졌다.  
+
+아직 이해했다고 말하긴 어렵지만,  
+적어도 분산 아키텍처는 구조를 쪼개는 기술이 아니라  
+트레이드오프를 고려해 경계를 판단하는 사고의 영역이라는 생각이 들기 시작했다.  
+

2026/Fundamentals_of_Software_Architecture_2nd_Edition/tttghost/chapter 3.md

@@ -0,0 +1,28 @@
+# 3장 아키텍처 모듈성
+
+## 논의주제
+모듈화 동인을 "찾는다"가 아니라 "맞춘다"고 표현하는 것이 인상적이었습니다.
+실무에서 아키텍처를 분해하거나 모듈화할 때, 기술적 최적해를 찾는 것과 팀 상황을 고려하는 것 사이에서 어떻게 균형을 맞추셨는지 궁금합니다.
+예를 들어 "기술적으로는 A가 맞지만 팀 역량상 B로 갔다"거나, "당장은 모놀리식이지만 확장 여지를 남겨뒀다" 같은 경험이 있으신가요?
+
+## 감상평
+책에서 예시로 나온 선빈과 성한의 회의 장면을 보면서, 선빈이 모놀리식 시스템 때문에 고민하지만 "왜 분해하면 좋아질 것 같은지" 명확한 근거를 대지 못하는 모습이 인상적이었다.
+마치 문과가 싫어서 이과를 선택한 것처럼, 현재가 싫어서 반대편을 선택하는 느낌이랄까.
+
+물잔 비유로 이어지는 설명도 와닿았다.
+모놀리식 아키텍처가 물이 다 차면 그때 가서 하려면 이미 늦으니, 미리 반으로 나눠서 두 컵에 담아 추가 용량을 확보하라는 것.
+결국 미리 준비해야 한다는 것이다. 안 그러면 나중에 가서 터진다.
+
+도 흥미로운 개념이었는데, 신뢰성은 "잘 안 고장 남"이고 내고장성은 "고장 나도 버팀"이라는 구분이 명확했다.
+모듈화를 잘 해놓으면 장애 격리가 가능해서, 연쇄적으로 터지지 않고 우회, 차단, 대체가 가능하다는 점이 핵심이다.
+
+다만 배포성에서 매트 스틴이 경고한 것처럼, 지나친 마이크로서비스는 트랜잭션 완료를 위해 더 많은 통신을 하게 되면서 오히려 더 복잡한 "분산 진흙탕"이 될 수 있다는 점도 기억해야겠다.
+
+마지막으로 모듈화 동인을 "찾는다"가 아니라 "맞춘다"고 표현한 것이 가장 와닿았다.
+단순히 기술적으로 어디를 쪼갤지만 생각하는 게 아니라, 팀의 상황까지 고려해서 최선의 선택을 해야 한다는 것.
+지금 팀 내에서 불편한 서비스에 대해 인지하고, 쪼갰을 때의 리스크를 판단하고, 그 결과를 받아들일 수 있는지 등을 함께 생각해야 한다는 메시지로 이해했다.
+
+## 느낀 점
+이번 장을 읽으면서 계속 사고가 확장되는 기분이 들었다.
+분명 이 분야는 직접 접해보지도 않았고 현재 업무와도 완전히 다르지만, 머릿속에서 연관 검색어처럼 현 업무에 빗대어 생각할 만한 요소들이 계속 떠올랐다.
+결국 이런 게 메타인지적 지식의 습득이 아닐까 싶다.