[소프트웨어 아키텍처 101] 6. 아키텍처 특성의 측정 및 거버넌스

인상깊은 부분

엔지니어는 아무 수치나 대충 목표로 삼는 게 아니라, 시간에 따라 어떤 추이를 보이는지 측정하고 통계 모델을 수립한다.

• 예를 들어, 특정 API의 평균 응답 시간(p116~p117)의 단축을 목표로 한다면, max와 p99, p90의 평균 응답 시간을 얻고 각 구간별 목표 응답속도를 목표한다는 뜻인 것 같다.
  그리고 목표한 수치를 벗어나는 경우 알림을 받아서, 모델 자체가 부정확했거나(팀이 알고 싶어 하는 것), 뭔가 잘못되었거나(역시 팀이 알고 싶어 하는 것) 두 가지 중 하나일 것이다.
• 모델 자체가 부정확했다는 뜻은, 구간별 평균 응답에 대한 측정이 잘못되어서 목표수치 설정을 잘못했다는 뜻이려나?

아키텍처 특성 정의 시의 문제점은, 아키텍처 특성을 객관적으로 정의하면 모두 해결된다.

정말 그럴까?

[[피트니스 함수]]의 개념

궁금한 것

• p117 구조적 측정 항목에는 코드 복잡도밖에 없는 걸까?
• p120 프로세스 측정이란 측정가능한 프로세스와 연관된 특성을 의미하는 것인가? 갑자기 왜 나온 것인지 모르겠다. 번역된 글이라 그런지 측정 유형을 운영적, 구조적, 프로세스로 세 개로 나눈 것도 잘 와닿지 않는다. 왜 이렇게 나눈 것이지?
• [[컴플라이언스와 거버넌스의 차이]]

---

요약

이번 장에서는 일반적인 아키텍처 특성을 구체적으로 정의하고 거버넌스 메커니즘을 구축하는 방법을 살펴보겠다.

6.1 아키텍처 특성 측정

• 아키텍처 특성 정의 시 문제점
  • 대부분 의미가 모호하다.
  • 정의가 너무 다양하다. 성능 같은 주요 특성의 정의도 부서마다 일치하지 않아서 개발자, 아키텍트, 운영자 모두 정의를 통일하기 전까지 의사소통이 원활하지 않음
  • 너무 복합적이다. 아키텍처 특성은 대부분 더 작은 여러 특성들로 구성된다. (이것도 바라보는 세분도에 따라 눈높이 맞추기가 힘들겠음)
• 위 세 가지 문제는 아키텍처 특성을 객과적으로 정의하면 모두 해결된다 (?)
  • 아키텍처 특성을 명확하게 정의하고 조직 전체가 이에 동의하면 공통의 아키텍처 언어를 확립할 수 있음
  • 복합적인 특성은 더 잘게 나누어 분석해보면 객관적으로 정의할 수 있는, 측정 가능한 특성을 밝혀낼 수 있음
• 측정 유형
  • 운영적 측정
    • 성능, 확장성처럼 비교적 정확하게 측정할 수 있는 것도 많지만, 팀 목표에 따라 그에 따른 해석이 미묘하게 갈릴 수 있음.
      • 예를 들어 특정 요청에 대한 평균 응답시간을 측정할 경우, 어떤 경계 조건 때문에 1%의 요청이 다른 요청보다 처리시간이 10배 걸릴 수 있음. 수준 높은 팀은 달성하기 어려운 성능 수치를 정하는 대신, 통계 분석 결과로 얻은 나름대로의 정의에 기반함
    • 엔지니어는 아무 수치나 대충 목표로 삼는 게 아니라, 시간에 따라 어떤 추이를 보이는지 측정하고 통계 모델을 수립함. 그리고 목표한 수치를 벗어나는 경우 알림을 받아서, 모델 자체가 부정확했거나(팀이 알고 싶어 하는 것), 뭔가 잘못되었거나(역시 팀이 알고 싶어 하는 것) 두 가지 중 하나일 것임
  • 구조적 측정
    • 코드의 복잡도
      • 순환 복잡도(CC, Cyclomatic complexity)라는 메트릭을 통해 측정 가능
        • 순환 복잡도란, 함수/메서드, 클래스, 또는 어플리케이션 레벨에서 코드 복잡도를 객관적으로 나타내는 지표로, 그래프 이론을 적용하여 계산함
        • 다른 메서드도 호출하는 경우까지 고려한 일반 공식은 CC = E - N + 2P 이다. (N= 노드/코드라인, E=간선/가능한 결정, P=연결된 컴포넌트 수)
      • 순환 복잡도는 어느 정도가 적당한가?
        • 경우에 따라 다르지만, 도메인 복잡도를 고려하지 않을 경우, 업계에서는 10 이하의 CC를 괜찮다고 보고, 저자는 5 이하가 적정하다고 본다.
        • 자바 진영에서는 Crap4j 라는 측정도구를 써서 CC와 코드커버리지를 함께 측정할 수 있음
  • 프로세스 측정
    • 소프트웨어 개발 프로세스와 교차하는(interesct) 아키텍처 특성도 있다.
    • 시험성은 테스트의 완전성을 평가하는 코드 커버리지 도구로 측정할 수 있다. 객관적으로 측정할 수 있는 특성이다.
    • 배포성도 배포 성공률, 배포 소요시간, 배포 시 발새한 이슈/버그 등 다ㅎ양한 메트릭으로 측정 가능하다.
    • 민첩성은 소프트웨어 개발 프로세스와 연관이 있지만, 이 프로세스는 아키텍처 구조에도 영향을 미칠 수 있다. 예를 들어 배포 용이성과 시험성이 최우선 항목이라면 아키텍트는 아키텍처 수준에서 모듈성, 격리성을 높이는 데 주력할 것이다. 이는 아키텍처 특성이 구조를 두조하는 좋은 예시이다.6.2 거버넌스와 피트니스 함수아키텍트는 개발자들이 아키텍처 특성 수선순위를 잘 지킬 수 있도록 거버넌스 메커니즘을 강구해야한다.
• 거버넌스(governance)란 '이끌다'라는 어원으로, 아키텍처 거버넌스는 아키텍트가 영향력을 행사하려는 모든 소프트웨어 개발 프로세스를 포괄함
• [[피트니스 함수]] : 결과가 목표에 얼마나 근접했는지를 나타내는 목표 함수
  • 아키텍처 거버넌스의 여러 부문을 자동화하기 위한 기법도 포함하는 개념
  • 아키텍처 피트니스 함수란 어떤 아키텍처 특성(또는 그런 특성들의 조합)의 객관적인 무결성을 평가하는 모든 메커니즘
  • 기존 도구들을 바라보는 새로운 시각으로, 사용하는 방법에 따라 메트릭, 모니터, 단위테스트 라이브러리, 카오스 엔지니어링 등 기존의 많은 검증 메커니즘과 중첩되는 부분이 있음
  • 아키텍처 특성에 따라 피트니스 함수를 다양한 도구로 구현 가능함
  • 모듈성의 다양한 측면을 테스트하는 피트니스 함수의 예시 ([[아키텍처 101 3. 모듈성]])
    • 순환 의존성
      • 모듈성 관점에서 바라볼 때 클래스나 컴포넌트를 별 생각없이 의존하는 것은 좋지 않다. 컴포넌트 간 순환 의존성이 생기게 된다면 한 컴포넌트를 재사용하기 위해 그에 딸린 다른 컴포넌트들도 함께 가져와야 하므로 모듈성이 매우 떨어진다.
      • 피트니스 함수로 순환 참조 여부를 발견함으로써 이런 순환 의존성을 미리 예방할 수 있음
      • 자바 진영에서는 JDepend라는 메트릭 도구를 사용하여 패키지 간 의존성 체크가 가능하다
    • '메인 시퀀스로부터의 거리' 피트니스 함수 ([[아키텍처 101 3. 모듈성]] - 3.2절)
      • 자바 진영의 JDepend라는 도구로 수용 가능한 임계치를 설정할 수 있음
      • 모듈성이라는 아키텍처 특성을 객관적으로 측정하는 사례 중 하나임
      • 피트니스 함수 도구가 더 정교해지고 특화되면서, JUnit의 영향을 받아 탄생한 ArchUnit 테스트 프레임워크도 탄생함