[Chapter 06] 아키텍처 특성의 측정 및 거버넌스

아키텍처 특성 측정

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

• 물리학이 아니다 : 아키텍처 특성은 대부분 의미가 모호하다.
• 정의가 너무 다양하다 : 부서마다 정의를 통일하기 전까지는 원활한 소통이 어렵다.
• 너무 복합적이다 : 바람직한 아키텍처 특성은 대부분 더 작은 다른 여러 특성들로 구성된다.

이 세가지 문제들은 아키텍처 특성을 객관적으로 정의하면 모두 해결된다.

 

운영적 측정

• 아키텍처 특성은 성능, 확장성처럼 비교적 정확하게 측정할 수 있는 것도 많지만, 팀 목표에 따라 그에 따른 해석은 미묘하게 갈릴 때가 많다.
  • 예를 들어 특정 요청에 대한 평균 응답 시간을 측정할 경우, 어떤 경계 조건 때문에 1%의 요청이 다른 요청보다 처리 시간이 10배 오래 걸리면 어떻게 해야 할까? 사내 네트워크 리소스가 충분하다면 특이점(outlier)은 나타나지 않을 수 있으니 최대 응답 시간도 함께 측정해야 특이점까지 잡아낼 수 있을 것이다.
• 수준 높은 팀은 달성하기 어려운 성능 수치를 정하는 대신, 통계 분석 결과로 얻은 나름대로의 정의에 기반한다. 
• 도구가 발전하고 이해도가 높아지면서 팀이 측정할 수 있는 아키텍처 특성은 빠르게 진화하고 있다. 
• 최초 콘텐츠 렌더링(First Contentful Paint)과 최초 CPU 유휴(First CPU idle)같은 메트릭에 성능 예산을 집중해서 모바일 기기로 접속한 유저의 성능 문제를 비중있게 다루는 경우도 많다.

구조적 측정

• 성능처럼 목표치가 확실하지 않은 메트릭도 있다. 
•  잘 정의된 모듈성처럼 내부 구조에 관한 특성도 그렇다. 아직 내부 코드 품질에 대한 종합적인 메트릭은 없지만, 아키텍트는 다른 메트릭과 공통 도구를 이용해서 코드 구조에 관한 중요한 부분을 들여다 볼 수 있다.
• 구체적인 동작과 명확한 테스트 경계에 집중하면 짜임새 있고 고도로 응집된 메서드를 개발할 수 있으며  순환복잡도(코드의 복잡도) 값도 낮게 나온다.

프로세스 측정

• 시험성은 거의 모든 플랫폼에서 테스트의 완전성을 평가하는 코드 커버리지 도구로 측정할 수 있다. 
•  배포성 역시 실패 대비 배포 성공률(%), 배포 소요 시간, 배포 시 발생한 이슈/버그 등 다양한 메트릭으로 측정된다. 
•  소프트웨어 프로젝트 범위에 있는 모든것 들이 제시한 측정 세가지 기준을 만족한다면 아키텍처 특성의 수준까지 이르게 되며 아키텍트는 그런 특성까지 고려하여 설계 결정을 내리게 된다.

거버넌스와 피트니스 함수

피트니스 함수

• 개발자가 유전자 알고리즘을 설계하여 유익한 결과를 얻으려면 결과의 품질을 객관적으로 측정하면서 이 알고리즘을 통제할 수 있어야 한다.
• 결과가 목표에 얼마나 근접했는지를 나타내는 목표 함수가 피트니스 함수(fitness function)이다.
• 최근 수년 간 피트니스 함수 도구는 점점 더 정교해졌고 목적에 따라 특화된 것도 있다. JUnit에 영향을 받아 탄생한 ArchUnit은 JUnit 체계의 일부를 활용한 자바 테스트 프레임워크이다.