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

지난주 스터디에서는 수많은 아키텍처 특성과 아키텍처에서 특성을 도출할 수 있는 연습 방법에 대해 소개가 되었다. 이번 스터디에서는 ‘아키텍처 카타’를 이용한 아키텍처 특성 도출 연습을 하기 전 아키텍처 특성을 측정하는 지표와 관점에 대해서 ‘소통 주제’에 따라 이야기해보고자 한다.

💡 ‘내 생각’ 부분은 스터디때 바로바로 적었던 내용이라 올바른 정보가 아닐 수 있음을 전달드립니다. 또한 ‘멘토’ 부분 또한 필자 관점으로 해석된 글임을 안내드립니다.

 

---

 

Chapter6. 아키텍처 특성의 측정 및 거버넌스

6.1 아키텍처 특성 측정

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

 

Q1. "성능"이라는 아키텍처 특성을 측정하기 위해 어떤 지표들을 사용할 수 있을까요?

내 생각

책에서는 아키텍처 특성을 측정하기 위한 지표로 ‘운영적 측정, 구조적 측정, 프로세스 측정’ 이렇게 3가지로 말하고 있습니다. ‘성능’과 같이 정확하게 측정할 수 아키텍처 특성은 ‘운영적 측정’에서 다룰 수 있으나 업계별, 부서별 성능에 대한 정의가 다를 수 있으므로 측정하는 모델이 다를 수 있습니다.

1. 운영적 측정 : 아키텍처 특성을 다루는 업계별, 부서별 해석이 다르고 이에 따른 측정 모델 수립이 다른 측정법. 주로 성능, 확장성과 같이 비교적 정확하게 측정할 수 있는 것들을 다룬다.
2. 구조적 측정 : 메트릭과 공통 도구를 이용해서 코드 구조, 복잡도를 확인하는 측정법. 주로 성능처럼 목표치가 확실하지 않은 특성들을 다룬다.
3. 프로세스 측정 : 소프트웨어 개발 프로세스와 교차하게 되는 아키텍처 특성을 확인할 때 사용되는 측정법.

 

멘토

• ‘성능’을 바라보는 개발자의 시각도 이렇게나 다른데 기획자나 디자이너의 시각이 다름을 알아야한다.
• 아키텍처 측정은 운영적 측정, 구조적 측정, 프로세스 측정으로 나뉠 수 있다.
• 운영적, 구조적 측정은 필수. 프로세스 측정은 팀바팀

 

운영적 측정

Hystrix Dashboard - Netflix API Usage Example

 

구조적 측정

• 순환 복잡도, 순환 의존성, 메인 시퀀스로부터의 거리, ArchUnit
• 구조적 측정은 CodeMetrics, ArchUnit 과 같은 라이브러리를 사용하여 측정할 수 있다

 

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

아키텍트는 개발자에게 피트니스 함수 사용을 권하기 전에 그들이 정확한 목적을 이해할 수있도록 충분히 설명해야 합니다.

 

Q2. 피트니스 함수가 목표치를 달성하면 실제로 아키텍처 특성을 잘 만족한다고 볼 수 있을까요?

내 생각

아키텍처 특성의 객관적인 무결성을 평가하는 모든 메커니즘이 ‘피트니스 함수’인데 이 말은 즉, 다양한 측면으로 테스트하여 결과가 목표에 얼마나 근접했는지를 나타내는 목표 함수를 뜻합니다. 그러므로 목표치를 달성했다는 건 즉 아키텍처 특성을 만족했다는 뜻으로 생각됩니다.

 

멘토

• 피트니스 함수가 목표치를 달성하였다고 하여도 테스트 코드를 위한 코드가 작성될 수 있다. 때문에 피트니스 함수를 사용하려는 작업자들과의 이해도, 목표가 같아야 정량적인 목표치를 달성할 수 있고 신뢰할 수 있는 피트니스 함수가 될 수 있다.
• 결국 상황에 따라서 맞을 수도 있고 아닐 수도 있다.

---

 

마무리

원래 이번 스터디 범위는 6, 7 이였으나 시간 관계상 6장에서 마무리 되어 카타 연습까지 진행되진 않았다. 대신 질의 시간에 나온 다른 사람들의 질문들이 인상적이였는데 확실히 혼자 읽고 공부할 때와는 다른 시각을 접할 수 있어서 좋았다.

 

예를 들면, 오늘은 ‘성능’을 측정하기 위한 지표에 대한 이야기가 메인이였는데 이를 위해 다른 사람들은 성능 지표 기준을 누가 정하는지 궁금해하기도 하였고, 실무에서의 성능 모니터링 주기도 궁금해하였다.

과연 나는 이런 의문을 가지고 개발에 임한적이 있는지 스스로에게 궁금해진 순간이였다. 멘토님께서 말씀하신대로 그런 경험을 할 수 없는 상황이라고 말하는건 좋지 않은 이야기로 들릴 수 있으니 방법은 만들어가면 되지 않을까?

 

내가 경험하지 못한 상황을 예상하고 측정하여 나만의 결과를 도출해보는 경험을 해보다 보면, 이전 회사에서 경험해볼 수 없는 환경이였다는 말이 마냥 변명만 되는 일은 없지 않을까 싶다.

 

그렇담 이 스터디가 끝나면 어떤 프로젝트를 해볼까? 이론 공부만 하기엔 심심..