소프트웨어 아키텍처 설계 : 개념, 정의, 개요

소프트웨어 아키텍처 설계 : 개념, 정의, 개요

 

소프트웨어 아키텍처 설계

커다란 건축물을 만들기 위하여 사람들은 먼저 설계도를 그립니다. 설계도를 그리는 이유는 건축물을 만들 때 설계도에 맞추어 만들려는 의도가 있고, 원하는 모습과 기능, 특징, 속성을 건축물을 만들기 전에 확인해보기 위함입니다.

크고 복잡한 소프트웨어 시스템을 만들 때에도 마찬가지로 먼저 설계를 해야 합니다. 그 이유는 만드는 소프트웨어 시스템이 원하는 기능을 갖고 원하는 품질을 갖도록 하기 위해서 입니다. 건축물의 경우도 마찬가지지만 설계와 설계의 검증 없이 시스템을 만들었을 경우 기능이 잘못되었거나 품질이 원하는 수준에 미달하여 시스템을 다시 만들거나 고쳐야 하는 경우 큰 비용과 시간이 소요되게 됩니다.

더구나 시스템 개발은 보통 완료된 후에도 오랜 시간 지속적으로 업그레이드되면서 향상된 서비스와 새로운 서비스를 제공해야 하는데,설계 없이 이런 유지보수, 진화의 작업을 하는 것은 장기적으로 큰 비용의 낭비를 가져오게 됩니다. 그래서 크고 복잡한 소프트웨어 시스템을 만드는 방법이 발전하게 되었습니다.

먼저 요구사항으로부터 바로 시스템을 구현해가는 즉흥적인 개발의 문제를 알고, 먼저 설계를 하고 설계에 기반하여 시스템을 구현하는 설계 방법론 기반의 개발로 발전하게 됩니다. 그러나 전통적 설계 기반의 개발은 아키텍처를 먼저 설계하고, 이에 기반하여 상세설계를 하고, 상세설계에 따라 시스템 구현을 하는 아키텍처 기반의 개발로 다시 발전하게 됩니다.

그 이유는 아키텍처 설계는 전통적인 설계보다 더 높은 추상수준에서 더 큰 단위로 시스템을 보게 하여 시스템에 대한 크고 중요한 판단과 분석을 가능하게 합니다. 따라서 시스템에 요구되는 다양한 품질속성들을 충족시키는 대응을 할 수 있게 해주기 때문입니다.

 

 

소프트웨어 아키텍처의 정의

소프트웨어 아키텍처를 소프트웨어 시스템의 조직, 구성으로만 보는 게 아니라, 이런 사항을 포함하는 시스템 개발에 관한 중요한 결정들의 집합으로 보는 시각입니다. 그러나 이런 정의들도 오래 전에 만들어진 정의들이라 그동안 연구자들이 알아낸 중요한 발견들을 다 반영하고 있지 못합니다. 

소프트웨어 아키텍처는 소프트웨어 시스템이 요구되는 기능과 품질로부터 궁극적으로 갖도록 소프트웨어 시스템을 용이하게 구축하고, 또한 지속적인 사용과 개선을 위하여 필요한 진화성을 갖도록 하는 소프트웨어 시스템의 구조와 이어지는 개발에 관한 중요한 결정입니다.

이 정의에서 시스템의 구축을 용이하게 해주는 성질 혹은 속성을 구축 용이성이고, 시스템의 지속적인 사용과 개선을 용이하게 해주는 성질 혹은 속성을 진화성이라고 합니다.

소프트웨어 아키텍처의 정의에 이 두 개의 품질속성을 담은 이유는 이들이 매우 중요하기 때문에 시스템의 의뢰자와 개발자가 간과하면 문제가 발생할 수도 있기 때문입니다. 

 

 

입력물과 출력물

아키텍처 설계를 어떻게 할 것인지를 논의하기 위해서는 먼저 아키텍처 설계 활동의 입력물과 출력물이 무엇인지 알아야 합니다. 물론 소프트웨어 아키텍처 설계는 입력물로서 소프트웨어 시스템의 요구사항에서 출발합니다. 그러나 모든 요구사항이 아키텍처 설계의 직접적인 출발점이 되는 것은 아니고 아키텍처적으로 중요한 요구사항들 중에서도 특히 중요한 것들을 선정하여 이들을 아키텍처 설계의 출발점으로 해야 합니다.

아키텍처 설계의 출력물은 크게 두 가지 문서로 볼 수 있는데, 개발 대상 시스템의 아키텍처를 담은 아키텍처 문서와 이 시스템을 유지보수 및 진화 관리 할 때 도움을 주는 아키텍처 가이드라인입니다. 시스템의 설계라고 말할 때 설계는 크게 세 가지의 서로 다른 수준의 설계를 포함합니다.

가장 광범위한 설계는 시스템 아키텍처 설계로 소프트웨어와 하드웨어로 이루어진 시스템 전체에 대한 아키텍처 설계입니다. 이를 바탕으로 전체 시스템의 부분으로 소프트웨어 시스템에 대한 아키텍처 설계를 하게 됩니다. 또한 소프트웨어 시스템의 아키텍처를 바탕으로 하여 소프트웨어 시스템에 대한 상세설계도 하게 됩니다.

시스템 아키텍처 설계가 소프트웨어 아키텍처 설계에 영향을 줄 뿐 아니라, 소프트웨어 아키텍처 설계도 시스템 아키텍처 설계에 영향을 줍니다.그 이유는 시스템에서 소프트웨어 부분이 차지하는 기능 및 비용이 하드웨어가 차지하는 기능 및 비용을 능가하는 경우가 많은데, 그럴 때에는 소프트웨어에 관련된 아키텍처적 결정이 오히려 시스템 전체의 아키텍처 결정에 영향을 미칠 수 있기 때문입니다.

이를 위한 아키텍처 설계의 근본 원리들은 12개입니다. 이 원리들은 네 가지 종류로 나눠집니다. 첫 번째는 아키텍처 설계가 해결해야 할 문제를 정제하고 식별하는 데 사용되는 세 가지 원리입니다. 두 번째는 아키텍처 설계의 결과가 어떤 모습을 가져야 하는가를 판단하는 데 사용되는 원리들입니다. 아키텍처 설계는 개발 대상 시스템이 달라져도 똑같은 모습의 산출물이 나오는 과정이 아니라, 시스템이 달라지면 그 시스템에 맞는 설계 결과의 모습도 달라지는 복잡한 절차입니다. 세 번째는 본격적인 아키텍처 설계에 적용되는 원리들입니다. 앞서 말한 바와 같이 설계 활동은 합성과 분석의 방법이고, 합성은 경험적 지식과 창의적 아이디어로 수행됩니다.

아키텍처 패턴과 품질속성 설계 전략은 합성 활동을 도와주는 원리입니다. 설계 절차가 실행될 때 아키텍처 분석 원리는 중간 설계 결과의 문제점을 찾아내도록 합니다. 아키텍처 설계 활동도 하나의 설계 활동이므로 설계에 적용되는 원칙들이 소프트웨어 시스템의 설계에 적용될 수 있습니다. 이러한 설계에 일반 원리를 반영하여 본격적인 설계를 위한 절차를 결정해야 한다는 것이 아키텍처 설계 절차 원리입니다. 마지막으로 네 번째는 설계가 끝나고 그 결과물을 평가하는 데 사용되는 원리입니다. 이 단계에서 평가 결과가 기대하는 수준에 미달하면 그 원인이 어디에 있는가 하는 것을 찾아서 이 원리들이 적용 과정 중 원인을 발생시킨 곳으로 돌아가 해당 원리의 적용을 다시 해야 합니다.

 

 

시스템의 요구사항 분류

소프트웨어 아키텍처 설계는 시스템 요구사항에서부터 출발합니다. 그러므로 시스템 요구사항을 잘 정리하고 명세하는 것은 아키텍처 설계뿐 아니라 성공적인 시스템 개발을 하기 위해서 반드시 선행되어야 합니다. 이를 위해서는 먼저 시스템 요구사항이 어떤 종류가 있는지 알아야 합니다.

시스템 요구사항은 기능 요구사항과 비기능 요구사항으로 나눠집니다. 비기능 요구사항은 다시 품질 요구사항과 제약사항으로 나눠집니다. 기능 요구사항이란 시스템이 제공하는 서비스를 말하며, 품질 요구사항은 시스템이 제공하는 서비스의 수준이나 성능, 즉 서비스의 품질을 말합니다. 제약사항은 시스템 개발이 지켜야 하는 준수사항을 말합니다.