[소프트웨어 아키텍처 101] CHAPTER 8. 컴포넌트 기반 사고

hyeonsunnny 2025. 3. 26. 23:22

3장 ~ 7장까지 아키텍처 특성, 식별, 측정, 범위에 대해서 스터디 했다면, 8장에서는 이를 토대로 컴포넌트를 설계하는 법에 대해서 배운다. 그동안 공부했던 개념을 적용해보고자 나름의 프로세스를 정리해보았다. 하지만 이 프로세스를 위해 추가로 필요했던 공부들도 정리하다보니 내용이 매우 길어지고 문체가 정돈되지 못한점 미리 사과드립니다..

💡 ‘내 생각’ 부분은 스터디때 바로바로 적었던 내용이라 올바른 정보가 아닐 수 있음을 전달드립니다. 또한 스터디 내용을 복습한 것이므로 정확하지 않을 수 있음을 안내드립니다.

8.1 컴포넌트 범위

8.1.1 컴포넌트란

‘3장 모듈성’에서 모듈과 컴포넌트가 어떻게 다른지에 대한 이야기를 나눴었는데 이번장에서는 컴포넌트가 핵심 주제로 등장하게 된다. 컴포넌트란 무엇일까? 책에서는 컴포넌트를 아래와 같이 정의한다.

3장에서는 모듈을 연관된 코드의 묶음이라고 했지만, 아키텍트는 보통 모듈을 몰리적으로 구현한 컴포넌트로 생각합니다. (생략) 이렇게 모듈을 물리적으로 패키징한 것을 컴포넌트라고 하며, 자바 jar, 닷넷 dll, 루비 gem 처럼 대부분의 언어는 패키징을 지원합니다. - 141p

컴포넌트는 아키텍처에서 서브시스템이나 레이어 형태로도 나타나며, 많은 이벤트 프로세서를 위한 배포 가능한 작업 단위입니다. - 142p

대에충 빠른눈으로 흘겨 보았다면 컴포넌트란 물리적인 단위라고 이해할 수 있다. 하지만 141페이지 내용으로는 모듈을 물리적으로 구현한 결과물이 컴포넌트라는 것과, 142페이지 내용으로는 아키텍처 개념에서 레이어 또는 서브시스템 형태로 구분되는 것이 컴포넌트라는 것을 말하고 있다. 이는 곧 컴포넌트가 논리적, 물리적 특성을 모두 가진다는 것을 의미한다는 걸 알 수 있다.

그렇다면 8장에서 말하는 컴포넌트는 논리적 컴포넌트일까 물리적 컴포넌트일까? 먼저 두 컴포넌트의 특징을 짚고가자.

8.1.2 논리적 컴포넌트 vs 물리적 컴포넌트

	논리적 컴포넌트	물리적 컴포넌트
정의	소프트웨어의 추상적이고 개념적인 구성 요소	실제로 배포 가능한 실행 단위
특징	- 시스템의 논리적 구조와 설계를 나타냄 - 코드의 구조적, 개념적 그룹핑 - 아키텍처적 관점에서 역할 정의	- 실제 배포 가능한 패키지 - 특정 언어/플랫폼의 패키징 메커니즘 사용 - 실행 및 배포 가능한 코드 묶음
예시	- 사용자 관리 로직 - 결제 처리 모듈 - 데이터 검증 컴포넌트	- Java JAR 파일 - .NET DLL - Ruby Gem
중요성	설계 단계에서 중요	배포 및 실행 단계에서 중요
구현 관계	- 하나의 논리적 컴포넌트가 여러 물리적 컴포넌트로 구현 가능 - 여러 논리적 컴포넌트가 하나의 물리적 컴포넌트에 포함 가능	- 여러 물리적 컴포넌트가 하나의 논리적 컴포넌트 구현 가능 - 하나의 물리적 컴포넌트에 multiple 논리적 컴포넌트 포함 가능
주요 관심사	시스템의 구조적 설계와 모듈 간 관계	실제 시스템 배포와 실행 메커니즘

눈치가 빠른 분들이라면 8장에서 이야기될 컴포넌트를 예상했을 것 같은데, ‘8장 컴포넌트 기반 사고’에서는 ‘논리적 컴포넌트 기반 사고’에 대해서 배우게 된다. 물리적 컴포넌트를 구현하기 위한 논리적 컴포넌트는 어떻게 만들까? 다음 절에서 살펴보자.

8.2 논리적 아키텍처 만들기

논리적 컴포넌트를 만들기 위한 필수 프로세스라고 생각되는 키워드들을 공부 차원에서 만든 자료이니 “저사람은 저렇게 이해했구나” 정도로만 참고해주시면 감사하겠습니다(함께 스터디하는 기분으로 다양한 생각 남겨주셔도 좋습니다 : D)

8.2.1 선행 작업

책에서는 앞서 이야기되었기 때문에 8장에서 다시 언급되지 않지만, 이 포스팅만 보는 사람으로써는 이전 단계에 대해서는 알지 못하기에 개인적으로 넣어봤다. 실제로 이것들이 선행되어 있기 때문에 컴포넌트를 설계할 수 있는 것이므로 간단하게 3~7장 내용을 짚고가자.

아키텍처 특성 식별(3~5장)

프로그램을 만들기 위한 요구사항이 발생했을테니 요구사항에서 어떤 아키텍처 특성들이 도출될 수 있는지 식별하는 단계이다. 5.3절의 실리콘 샌드위치 카타(106p)를 예로 사용해보자.

요구사항

유저가 주문을 하면 샌드위치를 픽업하러 갈 시간 및 상점까지 가는 경로를 전달받는다(교통 정보가 포함된 여러 외부 지도 서비스와의 연계는 필수임)
배달 서비스가 가능한 지점은 기사를 보내 샌드위치를 유저에게 배달한다
모바일 기기에서도 이용 가능하다
전국 어느 지점이나 이용 가능한 프로모션/스페셜 행사를 제공한다
특정 지점에서만 이용 가능한 로컬 프로모션/스페셜 행사를 제공한다
온라인 결제, 대면 결제, 배송 시 결제 등 다양한 결제 옵션을 제공한다

아키텍처 특성 식별

신뢰성, 안정성, 이식성, 맞춤성, 보안, 타당성, 국제화, 가용성

💡 식별된 특성에 대한 정의는 ‘4장 아키텍처 특성 정의’를 참고하면 됩니다.
아키텍처 특성이 식별된 이유가 궁금하다면 책에서는 ‘5장 아키텍처 특성 식별’을,
포스팅은 ‘[소프트웨어 아키텍처 101] CHAPTER 4, 5. 아키텍처 특성 정의와 식별’을 참고해주세요.

아키텍처 특성 범위 지정(7장)

아키텍처 특성을 식별하였다면 특성을 구체화하기 위한 범위를 지정해야 한다. 책에서는 범위를 지정하기 위해 아키텍처 퀀텀이라는 새로운 관점을 제시한다.

💡 아키텍처 퀀텀이란?
높은 기능 응집도와 동기적 커네이선스를 가진, 독립적으로 배포 가능한 아티팩트를 의미한다.

아키텍처 특성 식별에서 도출한 특성들을 높은 기능 응집도와 동기 호출이 일어나는 동기적 커네이선스를 가진, 독립적으로 배포 가능한 범위로 지정하면 아래와 같이 뽑아볼 수 있다.

퀀텀	정의	아키텍처 특성	동기/비동기
사용자 인터페이스	모바일 앱과 웹 애플리케이션을 통해 다양한 플랫폼에서 접근 가능	가용성, 접근성	동기 퀀텀
주문 관리	주문 접수, 픽업 경로 계산, 배달 관리를 담당	확장성, 장애 복원력, 데이터 무결성	비동기 퀀텀
위치 서비스	외부 지도 서비스와 연계하여 경로 및 소요 시간 계산, 위치 추적 기능 제공	외부 종속성 관리, 성능, 확장성, 유연성, 데이터 일관성	동기/비동기 혼합
프로모션	전국 및 지역 특화 프로모션 관리	유연성, 데이터 일관성, 확장성	비동기 퀀텀
결제	온라인, 대면, 배송 시 결제 등 다양한 결제 옵션 지원	보안, 트랜잭션 무결성, 암호화, 감사	동기/비동기 혼합

하지만 7장 아키텍처 특성 범위로 아키텍처 퀀텀은 ‘동기’와 ‘비동기’로 분류한다고 하지 않았는가? 위의 퀀텀을 동기, 비동기 관점으로 구분해보자.

퀀텀	동기/비동기	설명
사용자 인터페이스	동기	사용자와의 직접적인 상호작용으로 실시간 응답이 필요한 영역
주문 관리	비동기	백그라운드 처리, 메시지 큐, 이벤트 기반 아키텍처
위치 서비스	동기/비동기 혼합	경로 계산은 비동기, 실시간 위치 추적은 동기적 특성
프로모션	비동기	백그라운드 계산, 개인화된 프로모션 로직
결제	동기/비동기 혼합	결제 승인은 동기, 결제 처리 및 영수증 발행은 비동기

컴포넌트 최상위 분할(8장)

이제 논리적 컴포넌트 도출하기 위한 선행 작업은 모두 완료되었다. 이제 컴포넌트를 식별하기 전 최상위 분할을 어떻게 할 것인지 결정해야 한다. 아키텍처 특성 식별하듯 바로 도출하면 되지 않을까 싶지만 이 단계가 진행되지 않으면 후에 아키텍처 스타일(레이어드, 마이크로서비스 등) 선택과 코드 분할 방법을 결정지을 수가 없다.

위의 두 아키텍처 스타일은 우리가 개발을 시작하며 많이 사용하고 직간적접으로 접한 스타일이다.

위의 그림에서 왼쪽의 레이어드 아키텍처는 ‘기술적 최상위 분할’에 해당하며 시스템 기능을 기술적인 능력 즉 프레젠테이션, 비즈니스 규칙, 서비스, 퍼시스턴스 등에 따라 아키텍처를 구성하는 것이다. 오른쪽의 모듈러 모놀리스는 도메인 분할을 나타낸 것으로 복잡한 소프트웨어 시스템을 분리하는 모델링 기법을 다룬 에릭 에반스의 ‘도메인 주도 설계’에서 비롯됐다.

최상위 분할에는 기술 분할과 도메인 분할만 있을까?

의문점 그대로~! 소프트웨어 아키텍처 101에서는 기술 분할(예: 레이어드 아키텍처)과 도메인 분할(예: 마이크로서비스 아키텍처) 만을 소개해주고 있다. 정말 이 두가지만으로 빠르게 변화하는 아키텍처 특성을 체계화시킬 수 있을까? 그렇다면 GPT chance!

❓ 질문
소프트웨어 아키텍처 101에서 8장 컴포넌트 기반 사고를 읽고있는데 '컴포넌트 최상위 분할'로 기술 분할(예: 레이어드 아키텍처)과 도메인 분할(예: 마이크로서비스 아키텍처)을 소개해주고 있어. 혹시 컴포넌트 최상위를 분할할 수 있는 또다른 기준이 있을까?

❗ 답변
1. 비즈니스 기능 분할
- 비즈니스 도메인의 핵심 기능을 중심으로 컴포넌트를 구성하는 방식입니다.
- 예를 들어, 전자상거래 시스템에서 '주문 관리', '상품 카탈로그', '고객 관리', '결제' 등으로 컴포넌트를 분할할 수 있습니다.
- 이 접근법은 도메인 주도 설계(Domain-Driven Design)와 밀접하게 연관됩니다.
2. 데이터 흐름 기반 분할
- 시스템 내에서 데이터가 흐르는 방식에 따라 컴포넌트를 분할합니다.
- 데이터 입력, 변환, 처리, 출력 등의 단계별로 컴포넌트를 구성합니다.
- ETL(Extract, Transform, Load) 프로세스나 데이터 파이프라인에서 자주 사용됩니다.
3. 기술적 특성 분할
- 컴포넌트의 기술적 특성이나 요구사항에 따라 분할합니다.
- 실시간 처리, 배치 처리, 고성능 컴포넌트, 저지연 컴포넌트 등으로 구분할 수 있습니다.
4. 보안 및 격리 기반 분할
- 보안 요구사항이나 격리 수준에 따라 컴포넌트를 분할합니다.
- 민감한 데이터를 다루는 컴포넌트, 공개 컴포넌트, 내부 컴포넌트 등으로 구분합니다.
5. 확장성 및 리소스 분할
- 수평적 확장이 필요한 컴포넌트, 수직적 확장이 필요한 컴포넌트로 분할합니다.
- 고성능 계산, 메모리 집중적 작업, I/O 집중적 작업 등에 따라 구분합니다.

이러한 분할 기준들은 상호 배타적이지 않으며, 실제 아키텍처 설계에서는 여러 기준을 복합적으로 적용하는 경우가 많습니다. 프로젝트의 특성, 요구사항, 제약 조건에 따라 가장 적합한 분할 전략을 선택하는 것이 중요합니다.

8.2.2 컴포넌트 식별 흐름

초기 컴포넌트 식별: 컴포넌트 최상위 분할을 마친 후 너무 세부적이거나 지나치게 포괄적이지 않도록 컴포넌트들을 도출하는 단계
요구사항을 컴포넌트에 할당: 초기 컴포넌트를 식별한 후, 컴포넌트에 요구사항 매핑하는 단계
역할 및 책임 분석: 요구사항에 매핑할 때 밝혀진 역할과 책임, 응집도, 결합도를 확인하는 단계
아키텍처 특성 분석: 요구사항을 컴포넌트에 매핑할 때 식별된 아키텍처 특성들이 컴포넌트에 어떤 영향(성능, 부하 등)을 미치는지 확인하는 단계
컴포넌트 재구성: 초기 설계 검토 및 개선하는 단계
피드백 및 반복: "역할 및 책임 분석 → 아키텍처 특성 분석 → 컴포넌트 재구성 → 역할 및 책임 분석 → …” 의 반복을 통해 컴포넌트를 점진적으로 진화시켜나간다.

8.2.3 초기 컴포넌트 식별

	정의	특징	예시
액터/액션 접근법	액터/액션 접근법은 시스템에서 상호작용하는 사용자(액터)와 그들이 수행하는 주요 활동(액션)을 중심으로 컴포넌트를 식별하는 방법론	- 사용자 중심의 접근 방식 - 시스템의 주요 기능과 역할을 명확히 도출 - 비즈니스 로직과 사용자 요구사항을 직접적으로 연결 - 시스템의 경계와 책임을 쉽게 파악 가능	예: 온라인 쇼핑몰 시스템 - 액터: 고객, 판매자, 관리자 - 액션 1) 고객: 상품 검색, 장바구니 추가, 주문, 결제 2) 판매자: 상품 등록, 재고 관리, 주문 처리 3) 관리자: 사용자 관리, 통계 분석
이벤트 스토밍	이벤트 스토밍은 도메인 전문가, 개발자, 비즈니스 분석가가 함께 시스템의 이벤트와 흐름을 시각적으로 탐색하는 워크샵 기반 접근법	- 협업적이고 시각적인 방법론 - 복잡한 비즈니스 프로세스 이해에 효과적 - 도메인 지식 공유와 통합에 중점 - 포스트잇과 같은 시각적 도구 활용	예: 은행 대출 시스템 - 도메인 이벤트: 대출 신청, 신용 평가, 승인/거절, 계약 체결 - 액터 간 상호작용과 이벤트 흐름 매핑
워크플로 접근법	워크플로 접근법은 시스템 내 작업의 순차적 흐름과 상호작용을 분석하여 컴포넌트를 식별하는 방법	- 프로세스 중심의 컴포넌트 식별 - 작업 흐름과 의존성 파악 - 시스템의 논리적 구조 설계 - 비즈니스 프로세스의 자동화 및 최적화에 유용	예: 고객 지원 시스템 (워크플로 단계) 1. 문의 접수 2. 티켓 생성 3. 우선순위 설정 4. 담당자 배정 5. 문의 해결 6. 피드백 수집

액터/액션 접근법 vs 유스케이스 다이어그램

유스케이스 다이어그램은 시스템과 사용자의 상호작용을 ‘시각적’으로 표현한 것인데 표현방법 외에 다른 차이점은 없을까?

유스케이스 다이어그램을 작성해본적이 있다면 이런 궁금증이 생기지 않을까?

	유스케이스 다이어그램	액터/액션 접근법
차이점	- 시각적 표현에 중점 - 시스템의 기능적 요구사항 상위 수준 표현 - UML 표준 다이어그램 - 주로 분석 단계에서 활용	- 구체적인 컴포넌트 식별에 중점 - 실제 시스템 아키텍처 설계 - 비즈니스 로직과 직접 연결 - 구현 단계에 더 가까운 접근
한계	- 추상적이고 개념적인 수준 - 실제 구현 세부사항 부족 - 복잡한 상호작용 표현 제한 - 비즈니스 로직 깊이 있는 표현 어려움	- 초기 설계 단계에서 세부 구현 어려움 - 모든 비즈니스 복잡성 포괄 어려움 - 액터 간 복잡한 상호작용 표현 제한
예시 (여행 예약 시스템)	액터: 고객, 여행사 직원, 시스템 관리자 유스케이스: 1) 고객: 여행 상품 검색, 여행 예약, 결제, 예약 취소 2) 여행사 직원: 상품 등록, 예약 관리, 고객 문의 응대 3) 시스템 관리자: 사용자 관리, 시스템 모니터링, 통계 보고서 생성	액터: 고객, 여행사 직원, 시스템 관니자 액션: 1) 고객: 여행 상품 탐색, 예약 프로세스, 예약 관리 2) 여행사 직원: 상품 관리, 예약 대응, 고객 서비스 3) 시스템 관리자: 사용자 관리, 시스템 운영, 데이터 분석

책 1장, 8장에서도 말하고 있듯이 설계든 개발이든 ‘왕도’는 없다. 다양한 기술과 트레이드 오프만이 있을 뿐이므로 위의 두가지 방법론의 상호 보완적인 접근이 필요하다고 생각한다. 그러므로 유스케이스 다이어그램으로는 초기 요구사항 분석하고 액터/액션 접근법으로는 상세 설계 및 구현을 진행해보는건 어떨까? 이 또한 트레이드오프.

액터/액션 접근법 vs 엔티티

책에서 컴포넌트를 식별하기 위한 방법중 안티패턴으로 소개한 ‘엔티티’는 액터/액션 접근법처럼 시스템 내 주요 개체 또는 행위자로 구조를 식별한다는 공통점이 있다. 하지만 왜 안티패턴이라고 소개했을까? 한번 비교해보자.

	엔티티	액터/액션 접근법
차이점	- 데이터 중심 모델링 - 데이터베이스 스키마와 밀접한 관계 - 정적인 데이터 구조에 집중 - 속성과 관계에 초점	- 행위와 상호작용 중심 - 사용자 관점의 동적 모델링 - 비즈니스 로직과 프로세스 강조 - 시스템의 실제 작동 방식 표현
한계	- 비즈니스 로직 표현 부족 - 시스템의 동적 행위 반영 미흡 - 데이터 구조에 종속된 설계 - 실제 비즈니스 프로세스 간과	- 복잡성 관리가 필요한 대규모 시스템에서 모든 액터와 액션 포괄 어려움 - 시스템 아키텍처의 기술적 제약사항 반영 미흡 - 액션의 중복 및 과도한 분산 위험
예시 (온라인 쇼핑몰 시나리오)	- 엔티티: 사용자, 상품, 주문, 결제 - 속성 위주 모델링 1) 사용자: 이름, 이메일, 주소 2) 상품: 가격, 재고, 카테고리 3) 주문: 주문번호, 날짜, 총액	- 액터: 고객, 판매자, 관리자 - 액션 중심 모델링 1) 고객: 상품 검색, 장바구니 추가, 주문, 결제 2) 판매자: 상품 등록, 재고 관리, 주문 처리 3) 관리자: 사용자 관리, 통계 분석

그렇다면 컴포넌트 식별하고 설계할 때 엔티티가 불필요할까? 단일 접근법 한계를 인식하고 다양한 관점과 유연한 설계를 지향하면 진화 가능한 컴포넌트 설계를 만들어낼 수 있지 않을까 싶다(해결 전략까지 이야기하기엔 내용이 너무 길어지는 것 같아서 차이점과 한계 인지에 초점)

이벤트 스토밍 vs 도메인 주도 설계(DDD)

이벤트 스토밍(event storming)은 도메인 주도 설계(DDD)에서 사용되는 컴포넌트 발견 기법입니다. (생략) 이벤트 스토밍을 하는 프로젝트에서는 다양한 컴포넌트가 메시지나 이벤트를 이용해 서로 통신한다고 가정합니다. 따라서 팀은 요구사항과 식별된 역할에 따라 시스템에서 어떤 이벤트가 일어나는지 파악하고 컴포넌트를 이벤트와 메시지 핸들러 중심으로 구축합니다. - 157p

위의 표에서는 언급되지 않았지만 책에서는 이벤트 스토밍을 위와 같이 소개한다. 그렇다면 이벤트 스토밍을 도메인 주도 설계에 어떻게 사용되는지 구체적인 방법과 차이점이 궁금하지 않을까? 결국 직접 경험해봐야 이해가 가겠지만 의문은 던져보자.

	도메인 주도 설계(DDD)	이벤트 스토밍
차이점	- 복잡한 도메인을 위한 소프트웨어 설계 및 아키텍처 접근 방법론 - 도메인 모델의 구조화, 바운디드 컨텍스트, 애그리게이트 등 구체적인 설계 패턴 제공 - 코드 수준의 구체적인 설계 모델 - 엔티티, 밸류 오브젝트, 리포지토리, 서비스 등 구현 아티팩트 생성	- 주로 비즈니스 프로세스와 흐름을 시각적으로 탐색하고 이해하는 워크샵 형태의 접근법 - 빠르고 협력적인 방식으로 도메인의 이벤트와 경계를 파악 - 대형 포스트잇을 사용한 시각적 모델 - 도메인 이벤트, 커맨드, 액터, 시스템 경계 등을 시각화
한계	- 학습 곡선이 가파르고 초기 도입 비용이 높음 - 모든 프로젝트에 적용하기 어려울 수 있음	- 워크샵 결과를 실제 코드로 변환하는 과정이 명확하지 않을 수 있음 - 깊이 있는 기술적 설계 가이드를 제공하지 않음
예시 (온라인 주문 시스템 시나리오)	- Order 애그리게이트 - Payment 밸류 오브젝트 - OrderRepository - 주문 상태 변경 도메인 서비스	- 주문 생성 이벤트 - 결제 처리 이벤트 - 배송 시작 이벤트 - 주문 완료 이벤트

도메인 주고 설계(DDD)에서의 이벤트 스토밍 접근 방법

이벤트 스토밍 워크샵을 통해 도메인 탐색
발견된 인사이트를 바탕으로 DDD 설계 수행
바운디드 컨텍스트, 애그리게이트 식별
유비쿼터스 언어 정제
구체적인 소프트웨어 모델 구현

이벤트 스토밍 vs 워크플로

이벤트 스토밍과 워크플로의 정의, 특징, 예시를 보고 왔다면 두개가 유사한 특징이 있다고 생각할 수 있다. 예를들어 이벤트 스토밍은 상태 전이와 조건부 흐름 강조 하기 때문에 비동기적으로 보일 수 있고, 워크플로는 순차적이고 명확한 단계별 작업 흐름 때문에 동기적으로 보일 수 있다.

하지만 단순하게 동기, 비동기로 나누기엔 프로세스의 유연성, 복잡성이 존재하기 때문에 이벤트 스토밍은 더 동적이고 변화에 열려있으며, 워크플로는 더 구조화되고 예측 가능하다고 이해하면 좋을 것 같다.

Q1. 이전에 봤던 Going…Going…Gone Kata입니다. 액터/액션 접근법을 사용해서 어떤 컴포넌트들을 만들 수 있을까요?

https://nealford.com/katas/kata?id=GoingGoingGone

내 생각

입찰자
- 실시간 동영상 시청 컴포넌트
- 실시간 입찰 송신 컴포넌트
경매인
- 실시간 입찰 수신 컴포넌트
- 실시간 경매 관리 컴포넌트
입찰 스트리밍
- 입찰 송수신 컴포넌트

멘토

8.3 소프트웨어 개발 프로세스와 소프트웨어 아키텍처 101

💡 메트릭이란
방법론의 성과를 측정하고 평가하는 도구로 정량적 지표를 통한 객관적 분석을 하여 성능, 품질, 효율성을 수치화을 가능하도록 합니다. 지속적 개선을 위한 피드백 메커니즘이라고 이해하셔도 좋습니다.

	설명	방법론, 메트릭	소프트웨어 아키텍처 101	책과 매핑이유
기획	- 요구사항 정의 - 프로젝트 범위 설정 - 비즈니스 목표 수립 - 초기 리소스 및 예산 계획	- 애자일 방법론 - 스크럼 - 린 스타트업 방법론 (메트릭) - ROI (투자 수익률) - 요구사항 복잡성 지수 - 프로젝트 리스크 평가
분석	- 요구사항 상세 분석 - 시스템 요구사항 명세화 - 기능적/비기능적 요구사항 도출 - 유스케이스 다이어그램 작성	- 액터/액션 접근법을 통한 모듈 경계 정의 - 유스케이스 기반 모듈 후보 식별 - 도메인 주도 설계(DDD) (메트릭) - 요구사항 충족도 - 기능점수 분석(FPA) - 사용자 스토리 포인트	- 3장 모듈성 - 4, 5장(아키텍처 카타)	(3장) - 시스템 요구사항을 논리적 모듈로 분해 - 기능적 응집도 초기 평가(LCOM) - 도메인 관점에서 모듈 경계 식별 - 책임(Responsibility) 중심의 초기 모듈 구조 설계 (4장) - 아키텍처 후보군 탐색 - 요구사항 기반 아키텍처 접근 방식 - 초기 아키텍처 대안 평가
설계	- 아키텍처 설계 - 시스템 구조 정의 - 컴포넌트 및 모듈 설계 - 데이터베이스 스키마 설계	- 컴포넌트 기반 아키텍처 설계 - 모듈 간 인터페이스 정의 - 의존성 주입 패턴 적용 - 레이어드 아키텍처 - 클린 아키텍처 - 마이크로서비스 아키텍처 (메트릭) - 결합도/응집도 - 아키텍처 적합성 지수 - 확장성 평가	- 3장 모듈성 (메인 시퀀스로부터의 거리) - 8장 컴포넌트 기반 사고 (컴포넌트 식별, 설계) - 9장 ~ 18장 (아키텍처 스타일 선택)	(3장) - 논리적 모듈을 물리적 컴포넌트로 변환 - 모듈 간 결합도(Coupling) 최소화 - 내부 응집도 최대화 - 아키텍처 스타일 선택에 따른 모듈 구조 최적화 (8장) - 컴포넌트 식별 방법론 - 액터/액션 접근법 등 컴포넌트 설계 전략 - 모듈 간 경계 및 책임 정의 (9장) - 프로젝트 요구사항에 맞는 아키텍처 선택 - 레이어드, 마이크로서비스, 이벤트 기반 등
구현	- 실제 코딩 - 컴포넌트 개발 - 단위 테스트 - 코드 리뷰	- 테스트 주도 개발(TDD) - 행동 주도 개발(BDD) - 페어 프로그래밍 - SOLID 원칙 준수 (메트릭) - 코드 커버리지 - 기술적 부채 - 코드 복잡도 지수	- 3장 모듈성(LCOM)	- 코드 구조의 품질과 모듈 간 결합도 평가 - 단일 책임 원칙(SRP) 구현 - 모듈 내부 메서드 응집도 최적화 - 코드 복잡도 및 중복 제거
테스트	- 통합 테스트 - 시스템 테스트 - 성능 테스트 - 사용자 수용성 테스트	- 자동화 테스트 - 지속적 통합/배포(CI/CD) - 카오스 엔지니어링 (메트릭) - 결함 밀도 - 테스트 커버리지 - MTTR(평균 복구 시간)	- 6장 아키텍처 특성의 측정 및 거버넌스 (거버넌스, 피트니스 함수)	- 아키텍처 품질 평가 - 피트니스 함수를 통한 아키텍처 검증 - 비기능적 요구사항 측정
배포	- 시스템 설치 - 운영 환경 전환 - 사용자 교육 - 유지보수 계획 수립	- 블루-그린 배포 - 카나리 배포 - 점진적 마이그레이션 (메트릭) - 가동 시간 - 성능 안정성 - 사용자 만족도

마무리

책을 읽으면서 구현, 설계, 기획 등의 키워드를 함께 접하다보니 아키텍처 특성을 식별하고 컴포넌트 식별하며, 모듈성을 측정하는 등의 작업들은 소프트웨어 개발에서 어느 단계에 속할까? 내가 공부하고 있는 지식은 어떤 상황에서 적용하면 좋을까? 싶어서 ‘8.3 소프트웨어 개발 프로세스와 소프트웨어 아키텍처 101’ 주제를 추가하게 되었다.

나무만 이해할 수도 있지만 해당 나무가 열대우림에도 있고 사계절 풍부한 우리나라에도 있을 수 있는 나무라면 숲의 특성을 파악하는게 좋지 않을까? 싶어서 공부한 내용이 지난주보다 방대하고.. 너무 길어져서 급하게 마무리…

그래도 유익했다😌