상명대학교 / 서광규 교수


 

 

클라우드 네이티브라는 용어는 현대 클라우드 컴퓨팅 환경의 이점을 최대한 활용하는 방식으로 애플리케이션을 개발하고 운영한다는 개념을 설명한다. 이 맥락에서 언급하는 애플리케이션 유형은 조직에서 고객에게 서비스를 제공하거나 내부 네트워크나 인터넷을 통해 내부 요구 사항을 충족하기 위해 구현하는 웹 애플리케이션이다. 여기서 사용하는 애플리케이션이라는 용어는 이러한 웹 애플리케이션을 의미한다. 이를 Cloud Native Computing Foundation(CNCF) Landscape에 나열된 소프트웨어와 같이 클라우드 네이티브로 설명되는 다른 소프트웨어와 구별된다.

이러한 클라우드 네이티브 애플리케이션의 구현은 클라우드 서비스 제공 및 기술 선택, 구성 요소에 대한 비즈니스 로직의 기능적 분해, 구성 요소 간 통신 설정 또는 애플리케이션의 배포 및 업그레이드 프로세스 관리 등 광범위한 측면을 포괄한다. 올바르게 적용하면 성능 및 확장성 향상, 비용 효율성, 안정성 또는 유지 관리 개선과 같은 클라우드 네이티브 애플리케이션과 관련된 많은 이점이 있다. 따라서 클라우드 네이티브 방식으로 애플리케이션을 구현하거나 기존 애플리케이션이 클라우드 네이티브 개념에서 어떻게 이점을 얻을 수 있는지 평가할 때 이를 정보에 입각하고 체계적인 방식으로 수행할 수 있는 방법에 대한 의문이 제기된다.

개념적 관점에서 이러한 의문을 해결하기 위해 필수적인 질문은 클라우드 네이티브 개념과 관련된 특성이 애플리케이션의 관찰 가능한 동작에 어떤 영향을 미치는가이다. 아키텍처 특성으로서 우리는 개발자가 내린 결정의 결과인 애플리케이션의 설계 시간 속성을 고려한다. 여기에는 기술적 옵션이나 소프트웨어 설계와 같은 모든 구현 측면이 포함된다. 관찰 가능한 동작으로서 우리는 애플리케이션이 실행되고 작동될 때 측정 가능한 애플리케이션의 런타임 속성을 고려한다. 따라서 런타임 속성은 애플리케이션이 의도한 기능을 얼마나 잘 충족하는지를 나타낸다. 이는 일반적으로 애플리케이션의 품질로 요약된다. 그러나 아키텍처 특성과 관찰 가능한 동작 간의 관계는 복잡할 수 있으며 다양한 아키텍처 특성이 간섭 효과를 가질 수도 있다. 그러나 이러한 관계를 체계적이고 포괄적인 방식으로 설명할 수 있다면 품질 측면에 따라 애플리케이션 아키텍처를 평가하는 데 필요한 지식을 나타낼 것이다. 따라서 이 지식은 개념적 관점을 충족시킬 것이다.

하지만 개발자와 아키텍트가 클라우드 네이티브 방식으로 애플리케이션을 설계하고 구현하도록 실제로 지원하려면 실용적인 관점도 고려해야 한다. 실용적인 관점에서 추가적인 질문은 이러한 지식을 적절한 도구 내에서 어떻게 통합하고 유용하게 만들 수 있는가이다.

이러한 고려 사항을 바탕으로, 클라우드 네이티브 애플리케이션의 소프트웨어 아키텍처에 대한 계층적 품질 모델을 적절한 접근 방식으로 볼 수 있다. 이는 아키텍처 특성과 품질 측면 간의 관계를 설명하고 품질 평가를 위한 실용적인 도구에 통합될 수 있다.

이러한 계층 구조는 다른 기존 방법과 차별화하는 요인 중 하나이다. 예를 들어 더 광범위한 클라우드 네이티브 범위 대신 마이크로서비스에 초점을 맞추는 방법도 있고 여러 품질 측면을 조합하여 고려할 수 있다. 또한 마이크로서비스에 초점을 맞춘 품질 측면 성능 및 안정성을 특별히 평가하는 접근 방식도 있다. 이러한 방법은 런타임 메트릭을 품질 측면에 직접 연결하지만 얻은 결과로 이어지는 아키텍처 특성에는 덜 집중한다. 계층적 품질 모델을 구축하기 위한 견고한 기반을 위해 Quamoco 메타 모델에서 설명한 구조에 의존한다. 이 메타 모델에서 품질 측면은 품질의 뚜렷한 차원을 구별하며 제품 요인과 함께 계층 구조로 구성된다. 제품 요인은 소프트웨어의 특성을 나타낸다. 계층 구조는 제품 요인의 존재가 품질 측면에 어떤 영향을 미치는지 설명하는 영향 관계를 통해 구축된다. 따라서 이러한 품질 모델은 애플리케이션의 아키텍처 특성이 구조화된 방식으로 개념적으로 품질 측면에 어떤 영향을 미치는지 설명하는 데 적합하다. 그런 다음 제품 요인을 엔터티, 즉 소프트웨어 아키텍처의 구별 가능한 구성 요소에 연결하여 측정할 수 있다. 따라서 품질 모델의 관계에 따라 소프트웨어 아키텍처를 실질적으로 평가하는 것이 가능해진다.

본 고에서는 클라우드 네이티브 애플리케이션의 소프트웨어 아키텍처에 대한 품질 모델을 설명하는 것이다. 이는 본질적으로 완전한 품질 모델에 필요한 모든 다양한 요소인 품질 측면, 제품 요소, 영향 관계, 엔티티, 측정 및 평가 등을 정의하는 것을 의미한다. 본 고에서는 평가를 제외한 언급된 모든 요소의 공식화 및 검증에 중점을 두고 통합적이고 전체론적인 관점에서 접근 방식을 제시한다. 이를 위하여 품질 모델의 요소를 추가로 정의하고 소프트웨어 아키텍처를 적절하게 표현할 수 있는 방법을 기술하기로 한다.

 




 

1. 품질 모델 개념

여기에서는 품질 모델 유형(계층적)을 보다 명확하게 지정하기 위해 관련 기반이 되는 내용을 제시한다. 그리고 품질 모델을 어떻게 공식화하고 검증할 수 있는지, 그리고 이러한 활동이 서로 어떻게 관련되어 있는지 기술하기로 한다.

 

1-1. 계층적 품질 모델

품질 모델의 역사는 소프트웨어 엔지니어링 자체의 역사와 밀접하게 연결되어 있다. 그 핵심 아이디어는 소프트웨어의 측정 가능한 특성을 품질 측면과 연결하기 위한 개념적 기반을 제공하는 것이다. 소프트웨어의 품질을 측정하고 평가할 수 있다면 소프트웨어의 특성을 변경하여 소프트웨어 품질을 개선할 수 있는 방법도 보여줄 수 있다.이전에는 개별 메트릭을 사용하여 예를 들어 소스 코드의 복잡성을 측정했다. 그러나 소프트웨어의 특성과 품질 간의 관계가 더 복잡하다는 것이 분명해졌다. 따라서 일반적인 품질 모델은 계층적 품질 모델로 구성되었다. 이러한 상위 수준 품질 측면은 품질 하위 측면으로 차별화될 수 있으며, 이를 통해 소프트웨어 특성과의 관계를 공식화하기가 더 쉽다. 따라서 계층적 품질 모델은 본질적으로 그래프를 통해 표현할 수 있다. 상위 수준 품질 측면은 이러한 그래프에서 독립적인 노드이고 다른 요소는 이러한 품질 측면에 영향을 미친다. 이러한 영향은 그래프의 모서리이다. 이를 통해 계층적 품질 모델은 소프트웨어 특성이 품질에 어떻게 영향을 미치는지의 복잡성을 파악할 수 있으며, 또한 여러 측면을 서로 관련하여 고려할 수도 있다.

소프트웨어 품질 모델에 대한 작업은 ISO 25000 시리즈가 최신인 표준으로 통합되었다. 이는 소프트웨어 품질을 다소 추상적인 수준에서 고려하기 때문에 그 이후로 새로운 품질 모델을 공식화하는 기반으로 사용되었다. 또한 품질 모델을 비교하고 차별화하는 데 사용할 수 있다. 품질 모델의 주요 차별화 요소는 다루는 범위이다. 품질 모델의 범위는 요소의 수와 이질성에 의해 정의된다. 이질성은 포함된 다양한 품질 측면의 수와 관련하여 고려할 수 있으며, 종종 ISO 25000 표준의 다양한 상위 수준 품질 측면의 수를 말한다. 그리고 이질성은 품질 모델의 다른 요소가 다루는 측면, 즉 차원에서도 관찰할 수 있다. 다른 차원은 예를 들어 인프라, 애플리케이션 로직 또는 지원되는 비즈니스 기능, 런타임 동작, 개발 프로세스 특성 또는 조직적 측면과 같이 다양한 계층의 애플리케이션의 정적 특성일 수 있다.

일반적인 품질 모델에 대한 검토가 있지만 웹 서비스와 같은 특정 영역의 품질 모델에 대한 검토도 있다. 한 가지 발견은 고수준 품질 측면에서 주로 유지 관리성, 신뢰성 및 성능 효율성이 품질 모델의 초점이었다는 것이다. 기존에 많은 품질 모델이 문헌에 제안되었지만 산업에서의 실제 사용과 관련된 관련성이 상당히 다르다는 것이다. 가장 높은 관련성을 가진 품질 모델은, ISO 25000 표준과 그 전신인 ISO 9126, SQALE 모델 및 Quamoco 모델이다. 그러나 각각의 이유는 다르다. ISO 25000 표준이 인기 있는 이유는 단순성과 보다 구체적인 맥락에 적용할 수 있는 가능성 때문이다. SQALE 의 인기는 광범위한 도구 지원에 기인하며 개발 프로세스에 통합하는 것을 용이하게 한다. 그리고 Quamoco의 중요성은 그것이 기반으로 하는 광범위한 연구와 새로운 품질 모델을 구축할 수 있는 계층적 품질 모델을 위한 포괄적인 메타 모델의 공식화에 있다.

SQALE의 경우와 같이 품질 모델 채택을 위한 효과적인 도구 지원의 중요성에 있는데 도구 측면과 관련하여 품질 모델 채택을 위한 추가 성공 요인은 요소에 대한 정의의 완전성이다. 이를 분석하기 위해 품질 모델을 사용할 수 있는 여러 단계(계획, 실현, 문서화 및 평가)를 구별한 다음 품질 모델의 요소 유형을 사용되는 단계에 매핑한다. 이를 통해 품질 모델 요소의 정의 완전성에 대한 상당한 차이점을 식별한다. 또한 특정 소프트웨어 속성 및 프로세스를 초점에 맞는 품질 측면에 매핑하는 것과 관련하여 격차를 찾을 수 있다. 그러나 이는 품질 모델의 실제 적용에 중요하다.

따라서 주요 측면은 품질 모델 자체의 요소와 적합한 도구 지원이다. 품질 모델의 요소를 고려할 때, 우리의 관점에서 언급된 Quamoco 메타 모델은 구축을 위한 가장 포괄적인 기반을 제공한다. Quamoco 메타 모델의 주요 요소는 그림 1에 제시되어 있다.

 


[그림1.Quamoco 메타 모델의 요소]


 

Quamoco 메타 모델의 핵심 요소는 품질 측면 과 제품 요인으로 구분되는 요인이다.

품질 측면은 예를 들어 ISO 25000 표준의 다소 추상적인 품질 특성을 나타낸다. 제품 요인은 측정을 기반으로 특정 소프트웨어에 대해 측정 가능해야 하는 소프트웨어의 특성을 포착한다. 영향 관계를 통해 품질 측면이 최상위 요소를 정의하고 제품 요인이 아래에 구조화된 요인의 계층을 정의할 수 있다. 영향 관계는 예를 들어 긍정적 또는 부정적으로 대략적으로 정의할 수 있으며, 해당 요인이 소프트웨어에 존재하는 경우 요인이 다른 요인에 어떻게 영향을 미치는지 설명한다.

수학적 접근 방식을 사용하여 특정 제품 요인이 품질 측면에 어떻게 영향을 미치는지에 대한 보다 자세한 설명은 평가를 사용하여 만들 수 있다. 평가는 측정, 제품 요인 및 품질 측면을 사용하여 소프트웨어 시스템의 품질을 평가할 수 있는 정확한 방식을 구성하는 일종의 규칙으로 간주할 수 있다. 평가는 서로 관련하여 설정할 수도 있으며, 예를 들어 평가 집계를 가능하게 할 수 있다.

마지막으로, 품질 모델을 고려 중인 실제 소프트웨어와 연결하기 위해 소프트웨어 시스템의 다양한 구성 요소를 나타내는 엔티티를 사용한다. 특정 소프트웨어 시스템에 제품 요소가 존재하는 정도는 이 소프트웨어 시스템을 설명하는 특정 엔티티 집합을 통해 특징지어진다.

이러한 엔티티가 어떻게 구조화되어 있고 어떤 속성을 가지고 있는지에 따라 제품 요소를 측정하여 궁극적으로 소프트웨어 시스템의 품질을 평가할 수 있다.

 

 

1-2. 품질 모델 검증

품질 모델은 필연적으로 현실에서 추상화되지만 그럼에도 불구하고 소프트웨어에 대한 의미 있는 평가를 위해 현실을 가능한 한 정확하게 반영해야 한다. 따라서 실제로 관찰 가능한 품질 영향을 반영하는 것은 유용한 품질 모델의 중요한 속성이다. 이러한 보증을 검증이라고 하며, 이는 품질 모델 요소의 공식화에 근거하는 이론이 적절한 접근 방식을 사용하여 검증된다는 의미이다.

검증할 수 있는 품질 모델의 측면이 여러 가지 있으며 검증도 여러 가지 방법으로 수행할 수 있다. 품질 모델의 검증 접근 방식과 범위를 조사해 보면 중요한 측면은 품질 모델 생성 프로세스의 모든 단계에서 모든 유형의 검증이 가능한 것은 아니라는 것이다.

특히 품질 측면, 제품 요소 및 해당 영향 관계만 공식화되는 초기 단계에서는 측정 및 평가가 누락되어 소프트웨어 평가에 기반한 품질 모델의 완전한 검증이 어렵다. 그럼에도 불구하고 이러한 공식화된 요소를 검증하는 것은 가능하지만 적절한 접근 방식을 선택해야 한다. 어떤 검증 방식이 적합한지 결정하려면 해당 방식이 성공적인 검증의 목표를 달성할 수 있는지 확인해야 한다. 그리고 그 목표는 처음에 사용된 것과 다른 유형의 근거에 기반하여 품질 모델을 처음 공식화하는 동안 정의된 관계와 내용을 확인하는 것이다.

예를 들어, 품질 모델이 전문가의 경험에 따라 공식화된 경우 실제 소프트웨어 시스템의 측정에 의존하는 실험적 접근 방식을 사용하여 검증할 수 있다. 또는 품질 모델이 이론, 예를 들어 문헌에 의존하여 공식화된 경우 경험적 조사(합의 기반)를 통해 검증할 수 있으며, 이는 이 작업에서 고려하는 시나리오이기도 한다.

품질 모델의 모든 요소를 ??완전히 공식화할 필요가 없는 접근 방식으로는 예를 들어 인터뷰나 설문 조사와 같은 합의 기반 경험적 접근 방식이 있다. 이러한 접근 방식은 설명의 명확성이나 소프트웨어 시스템에 대한 적용 가능성을 묻는 방식으로 요인을 검증하는 데 사용할 수 있다. 또는 특정 요인이 다른 요인에 미치는 영향의 유형과 강도를 묻는 방식으로 요인 간의 공식화된 영향 관계를 검증하는 데 사용할 수 있다.

따라서 새로운 공식화를 통한 공식화, 검증 및 개선의 반복적 접근 방식을 취하고 검증을 반복적으로 다른 관점에서 적용할 수 있다. 일반적으로 다른 관점에서 더 많은 검증을 수행할수록 품질 모델이 적절하고 사용 가능하다는 확신이 높아진다고 말할 수 있다. 따라서 생성 프로세스 중의 검증은 품질 모델의 모든 요소가 정의된 후에 검증으로 보완해야 한다.

 



참 고 문 헌




  1. Lichtenth?ler, R., Fritzsch, J., Wirtz, G.: Cloud-native architectural characteristics and their impacts on software quality: a validation survey. In: 2023 IEEE International Conference on Service-Oriented System Engineering (SOSE). IEEE Computer Society, Los Alamitos, CA, USA (2023).
  2. Lichtenth?ler, R., Wirtz, G.: Towards a quality model for cloudnative applications. In: Service-Oriented and Cloud Computing, pp. 109?117. Springer, New York (2022).
  3. Apel, S., Hertrampf, F., Sp?the, S.: Towards a metrics-based software quality rating for a microservice architecture. In: 19th I4CS, pp. 205?220. Springer, New York (2019).

  4. Wagner, S. et al.: The quamoco quality meta-model. Tech. Rep. TUM-I128, TU M?nchen, Institut f?r Informatik (2012).
  5. ISO/IEC: ISO/IEC 25000 Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) (2014).
  6. Zdun, U., et al.: Microservice security metrics for secure communication, identity management, and observability. ACM Trans. Softw. Eng. Methodol. (2023).
  7. Lichtenth?ler, R., Wirtz, G.: Formulating a quality model for cloud-native software architectures: conceptual and methodological considerations, Cluster Computing, Volume 27, pages 4077?4093, (2024)




저작권 정책


K-ICT 클라우드혁신센터의 저작물인 『클라우드 기반 소프트웨어 아키텍처를 위한 품질 모델』은 K-ICT 클라우드혁신센터에서 상명대학교 서광규 교수에게 집필 자문을 받아 발행한 전문정보 브리프로, K-ICT 클라우드혁신센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.