아키텍처 전술 : 변경 용이성(Modifiability) 정의, 개념, 시나리오, 전술 목록

이번 글에서는 아키텍처 전술 중 하나인 변경 용이성 전술에 대해서 정리했습니다. 변경 용이성은 소프트웨어 아키텍처 주요 품질 속성 중 하나입니다. 변경 용이성의 정의와 기본 개념부터 품질 속성 시나리오, 전술 목록까지 알아보도록 하겠습니다. 

 

이번 글의 순서는 아래와 같습니다.

• 변경 용이성의 정의와 기본개념
• 변경 용이성의 품질속성 시나리오
• 변경 용이성 전술 목록 및 상세 설명

 

아키텍처 전술 : 변경 용이성

 

변경 용이성의 정의와 기본개념

변경 용이성이란 소프트웨어 시스템에 변경 요구사항이 발생했을 때, 변경 사항이 적용되는데 필요한 비용과 시간입니다. 즉, 변경 사항을 소프트웨어에 반영(분석, 설계, 구현, 테스트, 적용)할 때, 용이한 정도를 시간과 비용으로 수치화 한 품질 속성이라고 보면 됩니다.

 

소프트웨어 시스템 변경은 주로 구축 및 릴리즈(이행, 오픈) 이후 운영하면서 발생합니다. 시스템의 변경과 비용이 발생하는 구체적인 경우를 정리해 보면 다음과 같습니다.

• 새로운 기능을 추가할 때
• 오래된 시스템을 대체할 때
• 결함을 수정할 때
• 보안을 강화할 때
• 성능을 개선할 때
• 사용자 경험을 개선할 때
• 새로운 기술, 플랫폼, 프로토콜, 표준을 도입할 때
• 다른 시스템과 연동되도록 변경할 때

 

소프트웨어는 지속적으로 진화하고 변화하기 때문에 기능변경이 자주 발생하고 시간과 비용이 들어갑니다. 이때 변경 용이성이 좋은 소프트웨어는 변경 요구사항을 반영하기 쉽고, 시간과 비용이 적게 드는 소프트웨어라고 할 수 있습니다.

 

변경 용이성 종류를 구체적으로 살펴보면 유지보수성(Maintainability), 확장성(Extensibility), 재구조화(Restructuring), 이식성(Portability) 등이 있습니다.

• 유지보수성 : 소프트웨어의 안정적인 운영과 이슈 및 트러블 슈팅(trouble shooting)에 필요한 시간과 비용 정도
• 확장성 : 기능을 확장, 추가, 제거 가능 여부와 필요한 시간과 비용 정도
• 재구조화 : 컴포넌트 재배치와 구조 고도화에 필요한 시간과 비용 정도
• 이식성 : 다양한 운영체제에 설치 및 적용하는데 필요한 시간과 비용 정도

 

변경 용이성의 품질 속성 시나리오

변경 용이성을 품질 속성 시나리오 구성 요소로 정리하면 다음과 같습니다.

시나리오 구성 요소	설명	예시
자극의 근원(Source)	변경을 일으키는 주체	개발자, 시스템 관리자, 최종 사용자
자극(Stimulus)	변경의 원인이 되는 요구사항	새로운 기능의 추가 기능의 수정/삭제 품질 속성의 변경
환경(Environment)	변경이 발생하는 환경	설계 단계 컴파일, 빌드시간, 초기화 런타임
대상(Artifact)	변경되는 대상	시스템의 기능(성) 시스템의 플랫폼 사용자 인터페이스(UI) 환경, 상호 운용되는 타시스템
응답(Response)	변경이 적용된 결과	다른 기능에 영향을 주지 않고 수정 변경을 시험하고 변경된 결과를 배치
응답 측정 (Response Measure)	변경을 위해 필요한 시간과 비용	M/M, 개발/테스트/반영 기간

 

변경 용이성을 품질 속성 시나리오로 표현하면 다음 그림과 같습니다.

품질 속성 시나리오(변경 용이성)

 

변경 용이성 전술 목록 및 상세 설명

변경 용이성 전술목록에는 응집성 증가(Increase Cohesion), 모듈 분할(Split Module), 책임 재분배(Redistribute Responsibilities), 결합성 감소(Reduce Coupling), 캡슐화(Encapsulate), 중재자 사용(Use an Intermediary), 공통 추상 서비스(Abstract Common Services), 의존성 제약(Restric Dependencise) 바인딩 지연(Defer Binding), 바인딩 시간 결정(Binding Time Decisions) 등이 있습니다.

 

변경 용이성 전술 목록

 

1. 응집성 증가 Increase Cohesion

응집성이란 모듈 하나의 책임들이 강력하게 연결되는 정도입니다. 응집성이 높을수록(책임들 간에 연결되는 정도가 강할수록) 변경 요구사항이 다른 모듈에 미치는 영향과 확률이 낮아집니다.

 

변경 용이성에서 응집성 증가는 응집성을 낮추는 요소를 제거해 응집성을 높이는 것입니다. 구체적으로 보면 변경 요구사항에 영향을 받지 않는 책임들을 제거하면 응집성이 증가합니다.

 

2. 모듈 분할 Split Module

모듈의 크기가 크다면, 수정 비용도 높아집니다. 따라서 모듈 분할은 모듈을 작게 분할해서 평균적인 변경 비용을 줄입니다.

 

또한 모듈이 응집성이 낮거나 없는 책임을 가지고 있으면 변경 비용이 높아집니다. 이때, 하나의 모듈을 여러 개의 응집성이 있는 모듈로 나눠서 변경 비용을 낮출 수 있습니다.

 

이때 단순히 모듈을 반으로 나누는 게 아니라 응집성 있는 모듈로 분할해야 합니다.

모듈 분할(Split module)

 

3. 책임 재분배 Redistribute Responsibilities

유사한 책임이 여러 모듈로 나눠져 있다면 합치는 것이 좋습니다. 이동해야 할 책임을 명시하는 방법은 변경 시나리오의 집합을 가정해 보는 것입니다.

 

변경 시나리오가 모듈의 일정 부분에만 영향을 미치는 경우, 다른 부분들은 별도의 책임을 가지고 있다고 볼 수 있습니다. 이런 경우에는 모듈을 합쳐서 책임을 이동해야 합니다.

 

변경 시나리오가 여러 모듈의 변경을 필요로 하는 경우 영향을 받는 책임들을 묶어서 새로운 모듈로 그룹핑해야 합니다.

 

4. 결합성 감소 Reduce Coupling

두 개의 모듈의 책임이 어떤 측면에서 중복된다면, 하나의 변경이 양 모듈에 영향을 미칩니다. 이러한 중복은 모듈 하나의 변경이 다른 모듈에게 어떻게 영향을 미치는지 확률로 평가할 수 있습니다.

 

결합성이란 이런 모듈 사이의 확률적 관계입니다.

 

변경 용이성 전술에서 결합성 감소는 두 개의 모듈의 결합도를 낮춰서 비용을 줄이는 것입니다. 결합도를 줄이는 전술은 높게 결합될 모듈 사이에 다양한 중재자를 두는 방식이 적용됩니다.

 

5. 캡슐화 Encapsulate

캡슐화란 구성요소에 인터페이스를 도입해서 내부 정보를 숨기고, 요소 내부에 대한 의존성을 제거하는 것입니다. 구성요소에 접근할 때 인터페이스를 통해서 접근하는지 확인하고, 모든 의존성이 인터페이스를 통해 구성되도록 흐름을 만듭니다.

 

캡슐화는 하나의 구성요소를 변경해서 의존하는 숫자를 줄이거나, 의존 거리를 줄임으로써 다른 구성요소에 영향을 미치는 확률을 줄입니다.

 

캡슐화는 외부에 책임이 있는 시스템이나 구성요소가 다른 구성요소들과 상호작용하는 정도를 제약하는 단점이 있습니다. 인터페이스를 통해서 직접적인 상호작용 지원과 간접적인 상호작용 지원을 바꾸기가 어렵습니다.

 

6. 중재자 사용 Use an Intermediary

중재자 사용은 시스템에 있는 두 컴포넌트 간의 상호 의존성을 제거하기 위해 사용합니다. 책임 A와 책임 B 사이에 의존성이 있다면, 중재자를 사용해서 의존성을 제거할 수 있습니다.

 

중재자는 아래와 같은 서로 다른 타입의 의존성을 해결하는데 활용할 수 있습니다.

• Publish - Subscribe
• Shared data repository
• Dynamic service discovery
• Data transformers
• Protocol translators

중재자 사용(Use an Intermediary)

 

7. 공통 추상 서비스 Abstract Common Services

두 개의 모듈이 완전히 같지는 않으나 비슷한 기능을 제공할 때, 좀 더 일반적인 서비스를 제공하기 위해서 추상화를 통해 구체적인 요소를 숨기는 것이 유용합니다.

 

공통 추상 서비스 전술 구현 방법은 두 개의 모듈이 구현하는 공통 인터페이스로 구현합니다. 그리고 중재자를 활용해서 추상 서비스 요청을 추상화 뒤의 요소를 위한 구체적 요청으로 번역하면 됩니다.

 

즉, 공통 추상 서비스와 중재자로 구현하는 것입니다. 이는 특정 요소의 형식적 내용 변이를 정규화할 수 있습니다. 예를 들어 서로 다른 제조사에서 같은 타입 센서를 사용한다면, 공통 인터페이스(UI 아님)를 제공하는 것과 같습니다.

여기서 중재자는 Wrapper 또는 Adapter입니다.

 

공통 추상 서비스는 공통 인프라(common infrastructure)에 대한 번역, 보안, 로깅 메커니즘 등의 관심 사항을 처리할 때 일관성을 지원합니다. 

 

8. 의존성 제약 Restrict Dependencies

의존성 제약은 주어진 모듈에 의존하거나 상호작용하는 다른 모듈을 제약하는 것입니다. 구체적으로는 모듈의 가시성 제약과 사용 승인 등의 방법이 있습니다.

 

모듈의 가시성 제약은 개발자가 인터페이스를 보지 못하게 함으로써 해당 모듈을 활용하는 선택을 제한하는 것입니다. 사용승인은 승인받은 모듈만 접근할 수 있도록 제한하는 것입니다.

 

또 Wrapper를 사용할 수도 있습니다. 외부 Entity는 오직 Wrapper만 볼 수 있고, 내부 기능을 직접 볼 수 없습니다.

 

Layered Architecture에서 이러한 의존성 제약을 확인할 수 있습니다. 레이어는 오직 하위 레이어만 사용할 수 있기 때문입니다.

 

9. 바인딩 지연 Defer Binding

바인딩이란 컴퓨터 프로그래밍에서 각종 값들이 확정되어 더 이상 변경할 수 없는 구속 상태가 되는 것입니다. 바인딩 지연은 이런 구속 상태를 늦추는 것입니다.

 

바인딩 지연에는 바인딩 지연 시점에 따라 빌드 시점 바인딩 지연, 배포 시점 바인딩 지연, 초기화 시점 바인딩 지연, 실행 시점 바인딩 지연 등이 있습니다. 각각의 상세 설명은 아래와 같습니다.

• 빌드 시점 : 컴파일 및 빌드 시점에 바인딩하는 것
• 배포 시점 : 환경 설정 시점에 바인딩하는 것
• 초기화 시점 : 초기화될 때, 리소스 파일을 활용해 바인딩하는 것
• 실행 시점 : 실행할 때 바인딩하는 것

 

10. 바인딩 시간 결정 Binding Time Decisions

바인딩 시간 결정은 변경 요구사항을 적용변경할 수 있는 가장 늦은 시점(데드라인 등)을 결정하는 것입니다.

 

바인딩 시간 결정은 적절한 여건이 갖추어진 시점을 선택하기 위해 바인딩 지연 메커니즘을 선택하는 것입니다. 선택한 메커니즘을 사용해 변경 요구사항 반영 비용을 결정합니다.

 

너무 많은 바인딩을 선택하면 해당 선택 간에 의존성이 복잡하고 알기 힘들어서 바람직하지 않습니다.

 

컴파일 및 빌드 시점에 바인딩 시간을 결정하는 것은 컴포넌트 대체(build script, makefile), 컴파일 시점의 파라미터(Compile-time parameterization), Aspects 적용 등이 있습니다.

 

배포 시점 및 초기화 시점에 바인딩 시간을 결정하는 것은 Configuration-time binding, Resource files 등이 있습니다.

 

런타임 시점에 바인딩 시간을 결정하는 것은 Discovery, interpret parameters, Shared repositories, Polymorphism 등이 있습니다.

 

---

※ 함께 보면 좋은 글

 

1. 소프트웨어 아키텍처 전술과 적용시 고려할 설계 결정 항목

 

소프트웨어 아키텍처 전술과 적용할 때 고려해야 할 설계 결정 항목들

 

2. 소프트웨어 아키텍처의 품질 속성 특징과 문제점, 그리고 품질 속성 시나리오

소프트웨어 아키텍처의 품질 속성 특징과 문제점, 시나리오(with 예시)

 

3. 소프트웨어 아키텍처 정의, 역할, Desing Mindset

소프트웨어 아키텍처 정의, 역할, Design Mindset 알아보기

 

4. 소프트웨어 아키텍트 정의, 하는 일, 되는 방법, Design Thinking

소프트웨어 아키텍트(SA) 정의, 하는 일, 되는 방법, Design Thinking 4가지 원칙 알아보기