• 아키텍트는 소프트웨어 프로젝트의 거의 전 부문에 걸쳐 엄청나게 다양한 아키텍처 특성을 다루는 사람
• 이 장에서는 보다 일반적인 아키텍처 특성을 구체적으로 정의하고 거버넌스 메거니즘을 구축하는 방법을 집중적으로 살펴보자.

6.1 아키텍처 특성 측정

아키텍처 특성을 정의할 때에는 흔히 다음과 같은 문제들이 발생한다.

물리학이 아니다

• 아키텍처 특성은 대부분 의미가 모호하다.
• 바라보는 시각도 제각각

정의가 너무 다양하다

• 성능 같은 중요한 특성에 대한 정의가 같은 조직에서도 부서마다 일치하지 않아 개발자, 아키텍트, 운영자 모두 정의를 통일하기 전까지는 원활하게 소통하기가 어렵다.

너무 복합적이다

• 바람직한 아키텍처 특성은 대부분 더 작은 다른 여러 특성들로 구성된다.
• 예를 들어, 개발자는 민첩성을 모듈성, 배포성, 시험성 등의 특성으로 세분화할 수 있다.

이 세가지 문제는 아키텍처 특성을 객관적으로 정의하면 모두 해결된다.
아키텍처 특성을 명확하게 정의하고 조직 전체가 이에 동의하면, 팀은 공통의 아키텍처 언어를 확립할 수 있다.
또, 복합적인 특성은 더 잘게 나누어 분석해보면 객관적으로 정의할 수 있는 측정 가능한 특성을 밝혀낼 수 있다.

6.1.1 운영적 측정

• 아키텍처 특성은 성능, 확장성처럼 비교적 정확하게 측정할 수 있는 것도 많지만, 팀 목표에 따라 그에 따른 해석은 미묘하게 갈릴 때가 많다.

6.1.2 구조적 측정

• 성능처럼 목표치가 확실하지 않은 메트릭도 있다.
• 코드의 복잡도는 순환 복잡도라는 메트릭을 통해 명쾌하게 측정할 수 있다.
• 아키텍트, 개발자 모두 너무 복잡한 코드는 곧 코드 스멜이라는 사실에 공감한다.

6.1.3 프로세스 측정

• 소프트웨어 개발 프로세스와 교차하는 아키텍처 특성도 있다.
• 예를 들어, 민첩성은 바람직한 특성으로 보일 때가 많은데 이는 시험성, 배포성 등의 특성으로 나눌 수 있는 복합적인 아키텍처 특성이다.
• 시험성은 거의 모든 플랫폼에서 테스트의 완전성을 평가하는 코드 커버리지 도구로 측정할 수 있다.
• 물론, 소프트웨어 체크가 다 그렇듯이 시험성도 사고와 의도를 대체할 수는 없다.
• 가령, 코드 커버리지는 100%로 나오지만 코드의 정확성에 신뢰감을 부여하는 어설션이 형편없는 코드베이스도 있다.
• 양과 질 모든 면에서 조직에 유용한 데이터를 포착할 수 있는 측정 세트는 각 팀별로 알아서 준비해야 한다.
• 또 이렇게 측정한 메트릭들은 실제로 대부분 팀의 우선순위, 목표가 된다.

6.2 거버넌스와 피트니스 함수

• 아키텍트가 아키텍처 특성을 확정 후 우선순위를 정하면 개발자들이 이 우선순위를 잘 지킬 거라 어떻게 확실할 수 있을까?
• 예를 들어, 모듈성은 아키텍처 관점에서는 중요하지만 긴급하지는 않은 특성이다.

6.2.1 아키텍처 특성 관리

• 커버넌스는 kubernan(이끌다)라는 그리스어에서 유래된 말이다.
• 거버넌스는 아키텍트가 담당하는 중요한 업무다.
• 아키텍처 거버넌스는 이름에서도 느껴지지만 아키텍트가 영향력을 행사하려는 모든 소프트웨어 개발 프로세스를 포괄한다.