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

2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/00.md

@@ -0,0 +1,53 @@
+## Chapter 01: 베스트 프랙티스가 없다면?
+
+### 개요
+
+- 개발자: 좀 더 기술적인 분야를 다룸, 라이브러리를 활용해서 문제를 어떻게 해결할 것인지? 에 초점인듯
+  - 소프트웨어의 좀 더 세부적인 범위를 작업
+- 아키텍트: 하나의 제품 (소프트웨어) 에서 전체적인 흐름을 설계하고 구조를 잡아내는 기술자
+  - 소프트웨어의 큰 흐름을 주도
+- 소프트웨어 아키텍트의 경우 시대의 흐름이나 트렌드에 따라 고려해야 할 점이 지속적으로 변화하고 각 구조별 장단점이 극명하므로, 개발에는 최선이 있을 수 있으나 아키텍트는 그러기 어려움
+  - 최고의 설계를 고집하기보단 상황에 맞는 최적의 설계를 고려하는 것이 좋다
+  - 하나의 아키텍처를 바라볼 땐 특히나 그 아키텍처가 대세가 되었을 때의 시대적 배경을 고려해야 함
+  - 옛날에는 중앙 집중식 체제가 강세였다면, 오픈소스의 대두와 함께 요즘은 마이크로서비스 인프라를 쉽게 구축할 수 있게 된 것처럼
+
+```
+논의점: 오픈소스 혁명처럼, 2023년경 챗지피티를 필두로 한 LLM 인공지능의 범람으로 새로운 패러다임이 또 등장하고 있진 않을까? AI와 아키텍처를 긴밀하게 엮을 수 있다면 어떤 부분이 있을지?
+```
+
+### 데이터
+
+- 데이터는 아키텍처를 넘어서서, 소프트웨어의 모든 것이라고 볼 수 있음
+  - 어떻게 하면 특정 데이터를 효율적, 효과적으로 다룰 수 있는지가 소프트웨어의 목표라고 할 수 있음?
+  - 수익과 직결
+  - 운영 데아터: 비즈니스 활동에 사용되는 데이터 (소비자와 직접적으로 연결)
+  - 분석 데이터: 제품의 전략을 짜거나 의사결정을 할 때 큰 영향을 미치는, 통계적이고 분석적인 데이터
+
+### ADR
+
+- 아키텍처 결정을 문서화할 때 ADR (아키텍처 결정 레코드) 활용
+  - 문제와 대안 열거
+  - 확정된 아키텍처와 그 이유
+  - 해당 아키텍처를 적용했을 때 예상 결과와 고려해야 할 트레이드오프
+
+### 피트니스 함수
+
+- 피트니스 함수
+  - 아키텍처가 정상적으로 도입되었고 그에 따라 적절히 개발되고 있는지 평가할 수 있는 함수
+  - 계층별로 적절한 데이터를 주고받는지, 계층이나 객체 간 적절한 방법으로 데이터를 주고받는지 등등...
+  - 개발자들이 아키텍처를 정확하게 이해하고 있지 않거나, 자동화 도구를 사용할 때 발생하는 부작용 등을 방지
+
+```
+논의점: 피트니스 함수 등 아키텍처 테스트를 위한 도구를 적절하게 도입한 예시가 있을지? 일단 저희 팀은 모르겠습니다. 별도의 도구 없이 개발자들 간의 합의와 믿음으로 진행되는듯.
+단순 유닛 테스트 기반 CI/CD 자동화도 아키텍처 테스트 도구라고 볼 수 있을지? '아키텍처가 흐트러지는 것을 방지하는' 피트니스 함수의 범위는 어디까지일까?
+```
+
+### 아키텍처 vs 설계
+
+- 아키텍트는 소프트웨어의 상세 구현보다는 전체적인 흐름에서의 구조를 보려고 함
+- 아키텍처를 도입할 땐 왜? 라는 질문을 지속적으로 던져야 하는 듯
+  - 왜 이러한 구조를 도입했는지, 왜 이것이 최적으로 여겨지는지, 도입했을 때 부작용은 왜? 어떤 부분에서 발생할지? 등...
+
+```
+논의점?: FE 관점으로 봤을 때, 폴더 구조, 페이지 및 컴포넌트 간의 데이터 흐름도 (소프트웨어 전체에서 봤을 때) 미시적 측면에서의 아키텍처에 영향받는 부분으로 볼 수 있을까? (위의 논의점과 연관되는듯)
+```

2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/01.md

@@ -0,0 +1,44 @@
+# 따로 떼어놓기
+
+## Chapter 02: 아키텍처 퀀텀
+
+### 개요
+
+- 개발은 라이브러리 문서, 최적의 알고리즘 등 다양한 베스트 프랙티스가 존재하지만, 아키텍처는 명확한 가이드가 없기 때문에 특정 아키텍처를 도입하려고 해도 세부적인 면을 파고들었을 때 난관에 봉착하기도 함
+- 겉보기에는 우리 소프트웨어에 적절히 도입할 수 있을 것 같았는데, 막상 도입하려고 보니 다음과 같은 요소들이 눈에 띄는 것
+  - 현재 구현된 소프트웨어에 아키텍처를 끼워맞추려 할 때 봉착하는 문제점
+  - 미래에 높은 확률로 예상되는 부작용
+  - 한빛전자 아키텍트들이 무조건적인 디커플링만으론 데이터 통신 시의 문제를 염두에 두는 것과 같음
+- 무작정 좋아 보인다고 해서 바로 가져다 쓸 수 있는 게 없다
+- 마이크로서비스가 대세가 되면서 소프트웨어의 복잡도가 늘어났고, 아키텍트들의 의사 결정을 더 까다롭게 만들었다
+  - 마이크로서비스 아키텍처는 하나의 큰 어플리케이션을 독립적이고 작은 서비스들의 집합으로 분할하여 개발하는 스타일
+  - 온갖 관심사들이 하나의 소프트웨어에 뭉쳐지면서 요소 파악이 어려워지고 구조가 복잡해졌기 때문
+  - 독립적인 서비스를 어느 정도의 크기로 쪼갤 것인지부터 고려해야 함
+- 복잡한 서비스에서는 내부적으로 서로 얽혀 있는 부분 (커플링) 을 파악하고, 변경을 가했을 때의 영향을 고려하여 트레이드오프를 분석
+
+### 아키텍처 퀀텀
+
+- 아키텍처 퀀텀: 독립적으로 분리 및 배포가 가능한 하나의 서비스 집합체
+  - 마이크로서비스 아키텍처가 잘 도입되었다는 전제하에, 각 서비스들을 아키텍처 퀀텀으로 볼 수 있다
+  - 적절히 구성된 아키텍처 퀀텀은 제품과 그 흐름을 효과적으로 이해하고, 각 부서간 소통에 도움을 준다
+  - 아무리 서비스가 잘 격리되어 있어도 각 서비스들이 하나의 데이터베이스를 같이 바라볼 경우 독자적인 아키텍처 퀀텀으로 여기지 않는다
+    - 퀀텀이 데이터베이스를 통해서 데이터를 주고받으면 안됨, 각 퀀텀간에는 별도의 통신이 필요 (비동기 통신 등)
+  - 하나의 사용자 인터페이스를 여러 서비스들이 공유해도 안됨
+    - 하나의 사용자 인터페이스 내에서 독자적으로 운용되는 컴포넌트들을 각각 바라볼 경우 아키텍처 퀀텀으로 분류할 수 있음
+
+```
+논의점? 궁금증?: '독자적으로 배포 가능한 서비스 집합' 이 아키텍처 퀀텀이기 때문에 데이터베이스 or 사용자 인터페이스가 분리되어 있지 않고 하나의 DB에 모든 서비스가 접근할 경우 아키텍처 퀀텀으로 볼 수 없다고 이해하면 되는 것일지? 2개 이상의 아키텍처 퀀텀들로 구성된 서비스의 예시가 무엇이 있을까
+```
+
+### 퀀텀 커플링 트레이드오프
+
+- 기능 응집도: 구성 요소들이 비슷한 도메인과 구조로 잘 결합되어 있는지
+  - 모놀리식 (소프트웨어가 하나의 구조? 서비스? 로 이루어져 있는 아키텍처) 의 경우 응집도가 매우 낮다
+  - 높은 정적 커플링
+- 통신: 서비스 간 데이터 주고받는 방식, 동기 | 비동기가 있음
+  - 동기적 통신은 송신자가 수신자의 응답을 대기함
+  - 비동기적 통신은 송신자가 응답과 관계없이 하던 일을 계속함 (ACK 시그널 정도만 받는듯)
+- 일관성: 통신 시의 무결성 엄격함
+- 조정: 통신 방식을 도입한 워크플로에서의 조정 필요성
+- 통신, 일관성, 조정은 서로 영향을 주고받으므로 한 쪽을 택하면 다른 쪽으로 트레이드오프가 발생한다
+  - 아키텍처 선택 시 중요한 지표

2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/02.md

@@ -0,0 +1,40 @@
+# 따로 떼어놓기
+
+## Chapter 03: 아키텍처 모듈성
+
+### 개요
+
+- 아키텍처는 소프트웨어의 근간을 다루지만, 막상 시장이 변화하고 기술이 발전함에 따라 구조부터 다시 짜야 하는 경우가 많다
+  - 옛날엔 모놀리식이 유행하다가도 지금은 마이크로서비스가 유행하는 것처럼
+  - 모놀리식 시스템의 경우에는 확장이 어렵기 때문에 변화에 대처하기가 힘듦
+    - 물컵 예시: 같은 양의 물을 여러 컵에 나눠 담으면, 각 컵은 물을 추가로 담을 수 있기 때문에 확장성 면에서 유연하다
+  - 하지만 오선빈의 예처럼, 그럴 듯한 이유 없이 무작정 쪼개려고만 해서는 제품의 상위 담당자를 설득시키기 어렵다
+  - 큰 아키텍처를 갑자기 한번에 바꾸려고 시도하기보다는 아키텍처 또한 시대의 변화에 민첩하게 따르는 것이 적절하다
+
+### 모듈화 동인
+
+- 동인: 움직이게 만드는 계기?
+  - 오선빈이 상사를 어떻게 잘 설득시킬 수 있을지 여기서 엿볼 수 있음
+- 시장에서 우위를 점하기 위한 아키텍처 특성: 가용성, 확장성, 배포성, 시험성, 유지보수성
+  - 이 중 몇몇은 모놀리식 아키텍처에서도 충분히 달성가능
+- 유지보수성: 기능의 추가, 변경, 삭제 및 코드 내부적 변경이 얼마나 쉽게 달성 가능한지의 여부
+  - 컴포넌트간 결합도가 높을 수록, 유지보수성은 낮아진다
+    - 하나의 컴포넌트만 수정하려 해도 다른 컴포넌트 (또는 어플리케이션 전체) 를 손봐야 하므로
+    - 아키텍처 전체에 같은 도메인이 흩어져있는 경우가 많기 때문에 도메인별 관리 또한 어렵다
+  - 마이크로서비스 아키텍처처럼 모듈화를 적절히 수행했을 경우 변경이 필요한 서비스의 컴포넌트만 수정하면 나머지는 영향이 없다
+- 시험성: 테스트의 완전성과 용이함
+  - 작은 컴포넌트 하나의 변경점 때문에 더 큰 컴포넌트 또는 어플리케이션 전체에 테스트를 수행해야 할 경우, 수고로움이 클 것이다
+  - 모듈화를 통해 필요한 테스트의 범위를 좁히고 관리를 수월하게 할 수 있음
+- 배포성: 배포의 용이함 (낮은 리스크, 배포에 필요한 작업이 적음)
+- 확장성: 부하가 증가해도 시스템에 오류가 발생하지 않고 부하를 감당가능한 정도
+  - 확장성은 제품이 서비스되는 기간이 길어짐에 따라 사용자 수가 점점 증가해도 시스템이 응답을 유지함
+  - 탄력성은 갑자기 짧은 기간 내에 사용자 수가 폭증하고 사그라드는 것을 반복해도 시스템이 응답을 유지함
+  - 확장성이 조금 더 모듈화와 관련이 깊다 > 구조의 덩치가 작을 수록 이것저것 붙이기도 쉽고 구조별 목적이 정확하기 때문에 확장이 용이
+- 가용성 (내고장성): 시스템의 특정 부분이 고장나도 나머지 부분은 정상적으로 작동하는 능력
+  - 모놀리식은 내고장성에 매우 취약하다
+    - 도메인 분리가 되어있지 않고 각 컴포넌트가 강결합 되어있어 하나의 구조에서 오류가 발생하면 다른 곳에서도 오류가 발생할 확률이 높음
+  - 모듈화를 통해 특정 배포 단위에서만 버그가 발생하도록 제한하여 다른 모듈에서는 오작동을 막을 수 있다
+
+```
+느낀점: FE 관점이긴 하지만 최근에 레거시 코드를 들어내면서 (하나의 큰 화면 컴포넌트가 모든 기능을 담당하고 있었음) 컴포넌트의 관심사를 분리하여 작은 단위로 쪼개는 작업을 했었는데, 그래서 그런지 가용성과 시험성, 유지보수성 측면에서 예시에 공감이 많이 갔음. 허나 FE 하나의 파트에서도 컴포넌트 모듈화는 쉽지 않은 작업이었는데 하나의 제품 단위에서는 얼마나 많은 공수가 필요할지.
+```