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

소프트웨어 아키텍처 세계에서는 전통적으로 아키텍처 특성의 범위를 시스템 레벨에 두는 것을 당연시했다. 예를 들어, 아키텍트가 확장성을 논할 때에는 일반적으로 전체 시스템의 확장성을 가리키는 것이다. 10년 전까지만 해도 거의 모든 시스템은 모놀리식이었으니 이것은 안전한 전제였지만, 현대적인 공학 기술의 등장과 마이크로서비스 등의 아키텍처 스타일이 가능해지면서 아키텍처 특성의 범위는 상당히 좁혀졌다. 이렇듯 소프트웨어 개발 생태계가 무서운 속도로 진화를 거듭하면서 기존에 당연하게 여겼던 공식도 서서히 퇴물로 전락하고 있다.

 

우리가 앞에서 살펴보았던 다양한 메트릭들은 사실 모두 코드에 관한 저수준의 세부만 밝힐 뿐, (특히 운영과 관련된) 아키텍처 특성에 영향을 미치는, (데이터베이스 같은) 코드베이스 외부의 의존성을 지닌 컴포넌트는 평가할 수 없다. 따라서 아키텍트가 성능이 좋고 탄력적인 코드베이스를 설계하려고 아무리 노력해도 시스템이 그런 특성에 부합하지 않는 데이터베이스를 사용하면 애플리케이션이 성공할 리가 없다.

 

아키텍트는 운영 아키텍처 특성을 따져보고 아키텍처 특성에 영향을 미치는 코드베이스 외부의 컴포넌트를 잘 살펴봐야 한다. 그래서 이런 종류의 의존성을 측정하기 위해 「Building Evolutionary Architectures」의 저자들은 아키텍처 퀀텀(Architecture Quantum)이라는 용어를 정의했다.

 

 

1. 커플링과 커네이선스

챕터 3에서 살펴본 구심/원심 커플링 같은 코드 레벨의 커플링 메트릭은 아키텍처 분석용으로는 너무 세분도(granularity)가 높은편이다.

 

커네이선스

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

• 정적 커네이선스 : 정적 코드 분석으로 발견 가능
• 동적 커네이선스 : 런타임 동작에 관함
  • 동기
  • 비동기

 

아키텍처 퀀텀을 정의하려면 컴포넌트가 어떻게 서로 '연결되어(wired)' 있는지 측정할 방법이 필요한데, 이것이 바로 커네이선스라는 개념이다.

 

예를 들어, 마이크로 서비스 아키텍처의 두 서비스가 address라는 동일한 클래스를 공유한다면 두 서비스는 서로 정적인 커네이선스를 가진다고 볼 수 있다. 다시 말해, address라는 공유 클래스를 변경하면 두 서비스도 모두 변경해야 한다.

 

 

2. 아키텍처 퀀텀과 세분도

아키텍처 퀀텀

높은 기능 응집도(high functional cohesion)와 동기적 커네이선스(syncronous connascence)를 가진, 독립적으로 배포 가능한(independently deployable) 아티팩트

 

독립적으로 배포 가능

아키텍처 퀀텀은 아키텍처의 다른 파트와 독립적으로 작동되는 모든 필수 컴포넌트를 포함한다. 예를 들어, 데이터베이스를 사용하는 애플리케이션은 데이터베이스 없이는 작동되지 않으므로 데이터베이스는 퀀텀의 일부이다.

 

높은 기능 응집도

응집도는 컴포넌트 설계에 따라 구현된 코드가 얼마나 목적에 맞게 통합되어 있는지를 나타낸다.

 

동기적 커네이선스

아키텍처 퀀텀을 형성하는 애플리케이션 콘텍스트 내부 또는 분산 서비스 간의 동기 호출을 의미한다. 예를 들어, 마이크로서비스 아키텍처에서 어떤 서비스가 다른 서비스를 동기 호출할 때, 운영 아키텍처 특성 측면에서 두 서비스는 두드러진 차이를 나타낼 수 없다. 호출부가 피호출부보다 확장성이 훨씬 좋다면 타임아웃과 여타 신뢰성 문제가 일어날 것이다. 따라서 동기 호출은 호출의 길이에 대해 동적 커네이선스를 만들어낸다. 즉, 한 쪽이 다른 쪽을 기다린다면 호출하는 도중에는 양쪽의 운영 아키텍처 특성이 동일해야 한다.

전통적인 커플링 메트릭과 커네이선스 간의 관계에 통신 커네이선스라는 새로운 척도까지 추가된 그림

도메인 주도 설계의 경계 콘텍스트
DDD는 경계 콘텍스트(bounded context)라는 개념을 정의하는데, 도메인에 관한 모든 것이 내부에서는 보이지만 외부의 다른 경계 콘텍스트에서는 보이지 않아야 하는 것이다. DDD 이전에는 사내 공통 엔티티를 개발자가 아무렇게나 가져가서 재사용했는데, 이렇게 아티팩트를 함께 쓰다 보니 커플링이 심해져 팀 간 조율이 힘들고 복잡도가 증가하는 등 여러모로 문제가 많았다. 각 엔티티는 로컬 콘텍스트 내부에서 가장 잘 동작하므로 조직 전체가 함께 쓰는 통합 customer 클래스를 만드는 대신, 각 문제 도메인에 자체 클래스를 두고 차이점은 그것을 통합하는 지점에서 조정하는 것이 경계 콘텍스트 개념이다.

 

아키텍처 퀀텀 개념은 아키텍처 특성의 새로운 범위를 제시한다. 현대 시스템에서 아키텍트는 시스템 레벨보다는 퀀텀 레벨의 아키텍처 특성을 정의한다. 중요한 운영 관심사에 대해 범위를 좁혀보면 중요한 아키텍처 문제를 조기에 발견하여 하이브리드 아키텍처를 설계할 수도 있다.