1. 매트릭 (Metrics)
정의 및 역할
- 매트릭은 소프트웨어나 시스템의 여러 측면(품질, 성능, 복잡도 등)을 수치적 또는 정량적으로 평가하기 위한 지표입니다.
 - 코드 품질, 유지 보수성, 성능, 복잡도 등을 객관적으로 평가할 수 있도록 도와주며, 아키텍트는 이 데이터를 기반으로 설계 개선이나 리팩토링 결정을 내립니다.
 
주요 종류 및 예시
- 코드 복잡도 지표:
- Cyclomatic Complexity (순환 복잡도): 소스 코드 내 의사 결정 분기(조건문, 반복문 등)의 수를 측정하여, 코드의 복잡도를 평가합니다. 복잡도가 높으면 테스트와 유지 보수가 어려워질 수 있습니다.
 
 - 품질 및 결함 지표:
- 버그 밀도: 릴리즈된 코드 내 버그의 수를 측정합니다.
 - 커버리지: 단위 테스트나 통합 테스트가 전체 코드의 몇 퍼센트를 검증하는지를 나타냅니다.
 
 - 의존성 관련 지표:
- 결합도 (Coupling): 모듈 간, 클래스 간 상호 의존성을 수치화하여 평가합니다.
 - 응집도 (Cohesion): 모듈 내부 구성 요소들이 얼마나 관련성이 높은지를 측정합니다.
 
 - 성능 지표:
- 처리량(Throughput), 응답 시간(Response Time), 메모리 사용량 등 실제 운영 환경에서의 성능을 측정하는 지표도 포함됩니다.
 
 
활용과 한계
- 진단 및 모니터링:
매트릭은 코드의 변경이나 새로운 기능 도입 후 품질 저하 여부, 성능 변화 등을 추적할 수 있도록 해줍니다. - 리팩토링의 근거:
개선이 필요한 부분을 객관적인 데이터로 파악하여, 효율적인 리팩토링 전략을 수립하는 데 도움을 줍니다. - 한계:
매트릭은 수치화된 정보이므로 코드의 문맥이나 도메인 지식을 완전히 대체할 수는 없습니다. 때로는 지나친 수치에 집중하면 전체 시스템의 질적 특성을 간과할 위험도 있습니다. 
2. 커네이선스 (Cohesion 또는 Coherence)
참고: 한국어 용어로는 주로 응집도라고 표현합니다. 용어 자체가 다소 다양하게 사용되기도 하는데, 문맥에 따라 모듈 내부의 일관성(coherence) 혹은 **응집도(cohesion)**를 의미할 수 있습니다.
응집도 (Cohesion)
- 정의:
응집도는 모듈이나 클래스 내에 포함된 요소들(메서드, 변수, 기능 등)이 한 가지 책임 또는 관련된 기능을 수행하는 정도를 나타냅니다. - 높은 응집도:
- 모듈 내 모든 구성 요소가 한 가지 목적이나 기능에 집중되어 있을 때, 해당 모듈은 높은 응집도를 지닌다고 말합니다.
 - 유지보수, 테스트, 재사용 측면에서 유리합니다.
 
 - 낮은 응집도:
- 한 모듈 내에 여러가지, 그리고 때로는 상충되는 역할이 혼재되어 있다면 낮은 응집도를 가지게 됩니다.
 - 이 경우 모듈이 너무 많은 책임을 지게 되어 변경 시 예측 불가능한 부작용이 발생할 수 있습니다.
 
 
일관성 (Coherence)
- 정의:
일관성은 시스템 전체, 혹은 모듈 내에서 설계 원칙, 명명 규칙, 코드 스타일 등이 얼마나 통일되어 있는지를 나타냅니다. - 중요성:
- 일관된 설계와 코드 스타일은 팀 내 협업, 코드 리뷰, 유지보수 작업의 효율성을 높여줍니다.
 - 개발자가 코드를 읽고 이해하는 데 드는 인지적 부담을 줄입니다.
 
 
관련 개념 – 결합도 (Coupling)
- 비교:
- 응집도가 높으면 하나의 모듈이 단일 책임을 가지며 내부적으로 일관성을 유지하므로, 외부 모듈과의 상호 의존성(결합도)은 낮게 유지되는 것이 바람직합니다.
 - 낮은 결합도와 높은 응집도는 모듈화된 설계를 만드는 핵심 원칙 중 하나로, 시스템의 확장성과 유지보수성을 크게 개선합니다.
 
 
3. 트레이드 오프 (Trade-offs)
정의 및 개념
- 트레이드 오프란 설계 과정에서 두 가지 이상의 요구사항이나 품질 속성(예: 성능, 유지보수성, 확장성, 보안 등)이 상충할 때, 하나를 선택하거나 개선할 경우 다른 측면에서의 손실이나 제한이 발생하는 상황을 의미합니다.
 - 본질:
모든 설계나 의사 결정은 일정 부분 타협(trade-off)을 수반합니다. 완벽한 시스템은 없으며, 각 속성 간의 최적 균형을 찾는 것이 중요합니다. 
실제 사례 및 예시
- 성능 vs. 유지보수성:
- 성능 향상을 위해 복잡한 알고리즘이나 최적화 기법을 도입하면, 코드의 가독성과 유지보수성이 떨어질 수 있습니다.
 
 - 확장성 vs. 단순성:
- 시스템의 향후 확장을 고려해 모듈화하고 유연하게 설계할 경우, 초기 구현이 복잡해지거나 성능 오버헤드가 발생할 수 있습니다.
 
 - 보안 vs. 사용자 편의성:
- 보안 강화 조치(예: 다단계 인증)는 때때로 사용자 경험(UX)을 저해할 수 있으며, 이에 대한 균형이 필요합니다.
 
 
트레이드 오프를 고려한 설계 전략
- 요구사항 분석:
- 시스템이 우선시해야 할 품질 속성을 명확히 정의하고, 비즈니스 요구사항에 따라 어느 부분을 타협할 수 있는지 결정합니다.
 
 - 프로토타입 및 피드백:
- 초기 설계와 프로토타입을 통해 실제 사용환경에서 각 선택의 영향을 평가하고, 필요하다면 재조정합니다.
 
 - 지속적 모니터링:
- 운영 중에도 관련 매트릭을 지속적으로 모니터링하여, 예측치 못한 문제가 발생할 경우 신속하게 대응할 수 있도록 합니다.