[소프트웨어 아키텍처 101] CHAPTER 7. 아키텍처 특성 범위

이번주는 5장 내용 중 요구사항에서 아키텍처 특성을 도출하는 연습을 할 수 있도록 소개됐었던 ‘아키텍처 카타’를 통해 아키텍처 특성 범위를 설정해보는 나눠보는 시간을 가졌다. 선정된 카타는 ‘Going Going Gone’과 ‘Going Green’로 아키텍처 특성 범위를 어떻게 바라볼지 함께 고민해보자.

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

 

---

 

Chapter7. 아키텍처 특성 범위

3장에서는 모듈성 측정을 위한 개념(커플링, 커네이선스)을 소개하였고, 4장에서는 운영적, 구조적 및 공통 아키텍처 특성을, 5장에서는 요구사항 안에 있는 아키텍처 특성을 ‘식별’하였고, 6장에서는 식별한 특성을 ‘측정’하는 방법에 대해서 이야기했다. 7장에서는 3~6장의 내용을 적용하여 아키텍처 특성을 새로운 시각으로 바라보는 방법에 대해서 소개한다.

 

7.1 아키텍처 퀀텀(Quantum)

전통적으로 아키텍처 특성의 범위를 시스템 레벨에 두는 것은 당연했다. 이는 많은 시스템들이 하나의 코드베이스와 하나의 배포 단위로 구성된 모노리식 아키텍처에 기반을 두었기때문이다. 하지만 현대의 복잡한 요구사항과 환경을 수렴하기엔 더이상 당연하지 않게 되었고 안전하지 않은 아키텍처가 되었다.

빠르게 진화를 거듭하는 소프트웨어 개발 생태계에서 과연 어떤 아키텍처가 구조적인 진화 가능성이 있는지 측정할 기술이 필요해졌다. 6장에서 소개된 아키텍처 특성을 측정하는 방법(피트니스 함수, 아크유닛 등)은 코드에 관한 저수준의 세부만 밝힐 뿐 우리의 과제인 아키텍처의 구조적인 진화 가능성 측정 방법은 아니였다.

이런 고민을 선행한 ‘Building Evolutionary Architectures’ 저자들은 운영 아키텍처 특성을 따져보고 아키텍처 특성에 영향을 미치는 코드베이스 외부의 컴포넌트들의 의존성을 측정하기 위해 ‘아키텍처 퀀텀(architecture quantum)’이라는 개념을 만들어 냈다.

아키텍처 퀀텀을 이해하기 위해서는 3장에서 소개된 커플링과 커네이선스 개념이 필요하다.

 

커플링이란?

모듈 간의 상호 의존성, 연결 정도를 나타나내는 개념으로 결합도(Coupling)로도 불린다.

 

웹개발자의 커플링 측정 필요성

• 프론트엔드 : 컴포넌트 간 의존성이 많을수록 재사용성 낮아짐
• 백엔드 : 서비스 간 의존도가 높으면 변경/배포 어려워짐
• 마이크로서비스 : 서비스 간 커플링은 시스템 전체 안정성에 영향을 미침
• 코드 리팩토링 : 개선 전후 커플링 측정으로 효과 확인 가능

 

커네이선스란?

두 컴포넌트 중 한쪽이 변경될 경우 다른 쪽도 변경해야 전체 시스템의 정합성이 맞는다면 이들은 커네이선스를 갖고 있는 것이다. - Meilir Page-Jones, 80p

 

커네이선스는 소프트웨어 요소 간의 의존성이나 결합도를 측정하는 방법으로 "한 요소의 변경이 다른 요소의 변경을 필요로 하는 관계"를 의미한다.

 

책에서 표현한 ‘커네이선스 강도’

그림3-5가 이해 안가 그려본 ‘커네이선스 강도’. 강도가 높을수록 의존성이 높다.

 

정적 커네이선스(static connascence)

‘구심/원심 커플링 메트릭’을 발전시킨 개념으로 소스 코드 레벨의 커플링(의존성)을 의미한다. 컴파일 시 커플링을 확인 할 수 있다.

 

종류

• 이름(Name): 여러 컴포넌트가 식별자의 이름에 의존
• 타입(Type): 여러 컴포넌트가 데이터 타입에 의존
• 의미(Meaning): 여러 컴포넌트가 특정 값의 의미에 의존
• 위치(Position): 여러 컴포넌트가 값의 순서에 의존
• 알고리즘(Algorithm): 여러 컴포넌트가 특정 알고리즘에 의존

 

동적 커네이선스(dynamic connascence)

런타임 시 발생하는 커플링(의존성)을 의미한다.

 

종류

• 실행(Execution): 코드 실행 순서에 대한 의존성
• 타이밍(Timing): 시간이나 타이밍에 대한 의존성
• 값(Value): 데이터 값에 대한 의존성
• 식별(Identity): 여러 컴포넌트가 동일한 엔티티를 참조

 

3장에서는 정적, 동적 커네이선스가 갖는 특성과 종류를 설명하며 구조적 프로그래밍(코드 구조)에서 발생할 수 있는 커플링과 커네이선스에 대한 관점에 대해서 소개되었다. 7장에서는 4장에서 소개된 운영 아키텍처 특성을 고려할 수 있는 커네이선스의 새로운 관점인 ‘아키텍처 퀀텀’을 소개한다.

 

아키텍처 퀀텀

높은 기능 응집도와 동기적 커네이선스를 가진, 독립적으로 배포 가능한 아티팩트 - 133p

 

기존 동적 커네이선스와 헷갈릴 수 있는 ‘동기적’이라는 특징이 언급되었는데 이는 동기 호출이 기존의 동적 커네이선스의 한 형태이면서도, 운영적 특성에 집중한 새로운 관점을 제공한다는 것을 의미한다.

즉 아키텍처 퀀텀은 기존의 정적/동적 커네이선스에 포함되는 개념이 아니라, 운영 측면에서의 시스템 의존성을 설명하기 위해 확장된 개념인 커네이선스의 새로운 분류로 볼 수 있다. 이는 "시스템 레벨보다는 운영적 레벨의 아키텍처 특성을 정의"하는 데 도움을 주는 개념이다.

다이어그램을 보면 3장에서 소개된 기존의 정적 커네이선스와 동적 커네이선스 외에 새로운 카테고리로 ‘퀀텀 커네이선스’를 추가하고 있으며, 이것은 ‘동기’와 ‘비동기’로 구분된다.

 

퀀텀 개념이 추가된 커네이선스

 

 

웹개발자 관점의 퀀텀

독립적으로 배포 가능

• 프론트엔드/백엔드 분리: 프론트엔드 애플리케이션(React, Vue 등)과 백엔드 API를 독립적으로 배포할 수 있다. 한 쪽에 변경이 있어도 다른 쪽을 다시 배포할 필요가 없다.
• 마이크로 프론트엔드: 대규모 웹 애플리케이션에서 각 기능 영역(예: 상품 목록, 장바구니, 결제 시스템)을 독립적으로 개발하고 배포할 수 있다.
• CI/CD: 각 퀀텀마다 독립적인 CI/CD 파이프라인을 구축하여 개발 팀이 다른 팀의 일정에 영향받지 않고 기능을 출시할 수 있다.

높은 기능 응집도

• 도메인 중심 설계: 특정 비즈니스 도메인(예: 사용자 관리, 주문 처리)에 집중된 코드를 함께 그룹화하여 관련 기능이 한 곳에 모이도록 한다.
• 컴포넌트 기반 아키텍처: React나 Vue와 같은 프레임워크에서 기능적으로 응집된 컴포넌트를 만들어 재사용성과 유지보수성을 높일 수 있다.
• 마이크로서비스: 각 서비스가 하나의 비즈니스 기능(예: 인증, 결제, 제품 카탈로그)에 집중하도록 설계한다.

동기적 커네이선스

• API 호출 의존성: 프론트엔드가 백엔드 API를 동기적으로 호출할 때, 두 시스템은 성능과 가용성 측면에서 밀접하게 연결되므로 백엔드 API가 느리거나 다운되면 프론트엔드도 영향을 받는다.
• 서비스 간 통신: 마이크로서비스 아키텍처에서 서비스 A가 서비스 B를 동기적으로 호출한다면, 서비스 B의 성능 문제는 서비스 A에도 직접적인 영향을 미친다.
• 확장성 고려사항: 동기적으로 연결된 서비스들은 비슷한 수준으로 확장해야 한다. 예를 들어, 상품 목록 서비스와 상품 상세 서비스가 동기적으로 연결되어 있다면, 트래픽 증가 시 두 서비스 모두 비슷한 비율로 확장해야 한다.

 

7.2 아키텍처 특성 범위 설정(Scoping)

Q1. Going…Going…Gone 카타에서 어떤 아키텍처 특성이 보이시나요?

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

 

내 생각

• 전국 규모로 온라인 경매 : 확장성, 탄력성, 성능
• 경매당 수백 명의 참가자를 수용, 수천 명까지 확장 가능해야 함 : 확장성, 탄력성, 성능
• 가능한 한 동시 진행되는 경매 수를 최대화해야 함 : 확장성, 탄력성, 성능 동시성
• 경매는 카테고리화되고 검색 가능해야 함
  • 특성을 잘 모르겠습니다
  • 데이터베이스의 특성 인덱싱, 캐시를 사용하면 좋음
• 경매는 실시간에 가깝게 진행되어야 함 : 확장성, 성능
• 오프라인 경매와 온라인 경매가 혼합된 형태로 진행되어야 함
  • 특성을 잘 모르겠습니다
• 경매 진행 영상을 나중에 다시 볼 수 있도록 제공해야 함 : 데이터 무결성, 일관성(?)
• 금전 거래를 처리할 수 있어야 함 : 신뢰성, 보안
• 참가자는 신뢰 지수를 통해 추적될 수 있어야 함 : 신뢰성(?)

멘토

• 확장성과 탄력성 차이를 이해해야 한다.
• 보안에는 감사성이 포함이 되므로 함께 고려해야 된다
• 신뢰성은 가용성과 연결된다 -> 입찰이다보니 신뢰성 중요
• 가용성, 성능, 탄력성, 확장성, 신뢰성, 보안

 

확장성과 탄력성

	확장성	탄력성
정의	시스템이 증가하는 작업량을 처리하기 위해 자원을 추가할 수 있는 능력	시스템이 변동하는 워크로드에 따라 자동으로 자원을 확장하거나 축소할 수 있는 능력
특징	- 장기적인 성장을 위한 설계 - 시스템의 기본 구조를 변경하지 않고 용량을 늘릴 수 있음 - 수평적 확장(서버 추가) 또는 수직적 확장(더 강력한 서버로 업그레이드)으로 구현	- 단기적인 수요 변화에 대응 - 자동화된 방식으로 리소스를 할당하고 해제 - 클라우드 환경에서 특히 중요한 특성 - 필요에 따라 자원을 늘리고 줄여 비용 최적화

 

	확장성	탄력성
시간 범위	장기적 성장 계획	단기적 수요 변동 대응
자동화 정도	수동 또는 계획된 확장이 가능	주로 자동화된 확장/축소 메커니즘 사용
목적	더 많은 트래픽을 처리하는 능력	변동하는 트래픽에 효율적으로 대응하는 능력
비용 모델	일반적으로 장기적 투자	사용한 만큼만 지불

결국 멘토님께서 전달하고 싶으셨던 두 특성의 차이점은, 확장성이 높은 시스템이 반드시 탄력적인 것은 아니며 그 반대도 마찬가지라는 것.

 

Q2. Going…Going…Gone 카타에서 모든 아키텍처 특성을 만족하는 시스템을 설계할 수 있을까요? 아니라면 어떻게 분리하면 좋을까요?

'소프트웨어 아키텍처 101' 스터디 모습

 

내 생각

경매 정보, 경매 비디오 스트리밍, 결제, 경매인, 입찰자로 나누어 독립적인 분산 시스템으로 구축하는 것이 좋을 것 같습니다.

 

멘토

• 입찰자: 신뢰성, 가용성, 확장성, 탄력성
• 경매인: 신뢰성, 가용성, 확장성, 탄력성, 성능, 보안
• 입찰 스트리밍: 가용성, 확장성, 성능

 

Q3. Going Green 카타에서 어떤 아키텍처 특성이 보이시나요?

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

 

내 생각

• 수천, 수백만까지 늘어날 수 있는 유저
  • 확장성 : 유저 수, 요청 수가 늘어나도 시스템이 그에 맞는 성능을 발휘하는 능력
  • 탄력성 : 유저 폭증을 견딜 수 있는 능력
• 웹, 키오스크 통해 견적 발급
  • 이식성 : 하나 이상의 플랫폼에서 시스템을 실행할 수 있나
  • 설치성 : 필요한 모든 플랫폼에 시스템을 얼마나 손쉽게 설치할 수 있나
  • 구성 가능성 : 다양한 설정과 환경에 맞게 시스템을 쉽게 구성하고 업데이트할 수 있는 능력
  • 데이터 일관성 : 서로 동기화되어 일관성 상태를 유지
• 배송받은 상자에 판매할 전자 기기를 배송 후 수신 확인되면 고객은 돈을 받는다
  • 응답성 : 사용자가 요청 후 응답을 받기까지 걸리는 시간
• 중고 물건에 대한 평가에 따른 판매, 폐기 결정, 견적 및 평가에 대한 규칙
  • 워크플로 : 여러 단계를 거쳐야 하는 비지니스 프로세스
• 새로운 전자 제품 추가될 것으로 예상
  • 신장성(?) : 새로운 기능을 삽입하는 일의 중요성
  • 업그레이드성(?) : 구 버전을 새 버전으로 쉽고 빠르게 업그레이드 할 수 있는가?

멘토

가용성, 유지보수성, 배포 용이성, 확장성, 민첩성, 테스트 용이성, 보안, 데이터 무결성

 

 

Q4. Going Green 카타에서 모든 아키텍처 특성을 만족하는 시스템을 설계할 수 있을까요? 아니라면 어떻게 분리하면 좋을까요?

내 생각

• 고객: 가용성(웹사이트, 키오스트를 통한 지속적인 고객 접근), 응답성(요청에 대한 신속 대응)
• 전자기기 평가: 유연성(다양한 평가 규칙), 정확성(제품 상태 평가의 정확성)
• 결제, 정산: 보안, 신뢰성, 감사 가능성(감사성은 보안과 함께 고려대상, 모든 거래 추적 필요)

멘토

• 대면 고객: 확장성, 가용성, 민첩성
• 전자기기 평가: 민감성, 배포 용이성, 테스트 용이성, 민첩성
• 재활용, 보고, 회계: 보안, 데이터 무결성, 감사 가능성

 

마무리

진도가 7장 뿐이였지만 미리 읽었던 책 내용과 스터디 후 새롭게 얻은 인사이트들을 토대로 책을 다시 보게 되었을 땐 추상적이던 책이 조금 더 구체적으로 다가왔다.

퀀텀을 이해하기 위해 커네이선스가 소개되었던 3장을 보아야했고, 커네이선스와 커플링이 일어날 수 있는 아키텍처의 특징과 범위를 이해하기 위해 4장을 봐야 했으며, 7장에서 다시 이야기하고 있는 카타에 대해서 복습하기 위해 5장을 봐야했다.

이제서야 카타를 통해 아키텍처 특성들을 도출하는 연습을 왜 하는지, 아키텍처 특징은 왜 알고 있어야 하는지도 아주 조금은 알게된 기분. 조만간 새로 개인 프로젝트를 진행하게 되면 운영적, 구조적 특성을 뽑아 설계, 구현해볼 수 있지 않을까 : )? 모르는걸 알고 시작하니 재밌어지겠는걸ㅋㅋ