본문으로 이동

소프트웨어 구조

위키백과, 우리 모두의 백과사전.

소프트웨어 구조 또는 소프트웨어 아키텍처(software architecture)는 소프트웨어 시스템에 대해 추론하는 데 필요한 구조들의 집합이며, 그러한 구조와 시스템을 만드는 규율이다. 각 구조는 소프트웨어 요소, 요소 간의 관계, 그리고 요소와 관계 모두의 속성으로 구성된다.[1]

소프트웨어 시스템의 아키텍처는 건물의 건축에 비유되는 은유이다.[2] 이는 시스템과 개발 프로젝트를 위한 청사진 역할을 하며, 나중에 프로젝트 관리에서 관련 팀과 인력이 수행해야 할 필수 작업을 추정하는 데 사용할 수 있다.

소프트웨어 아키텍처는 한 번 구현되면 변경 비용이 많이 드는 근본적인 구조적 선택을 내리는 것과 관련이 있다. 소프트웨어 아키텍처 선택에는 소프트웨어 설계의 가능성 중에서 구체적인 구조적 옵션을 선택하는 것이 포함된다. 소프트웨어 아키텍처에는 두 가지 근본 법칙이 있다.[3][4]

  1. 모든 것은 트레이드오프다.
  2. "어떻게(how)보다 왜(why)가 더 중요하다."

"아키텍처 카타(Architectural Kata)"는 요구사항에 적합한 아키텍처 솔루션을 도출하기 위해 사용할 수 있는 팀 작업이다. 각 팀은 아키텍처 특성(일명 비기능 요건)을 추출하고 우선순위를 정한 다음, 그에 따라 컴포넌트를 모델링한다. 팀은 아키텍처를 충분할 정도로만 모델링하는 유연한 방법인 C4 모델을 사용할 수 있다. 아키텍처 컴포넌트 간의 동기 통신은 컴포넌트들을 서로 얽히게 만들며, 이들은 동일한 아키텍처 특성을 공유해야 한다는 점에 유의해야 한다.[4]

소프트웨어 문서화는 이해관계자 간의 의사소통을 촉진하고, 상위 수준 설계에 대한 초기 결정을 포착하며, 프로젝트 간 설계 컴포넌트의 재사용을 가능하게 한다.[5]: 29–35 

소프트웨어 아키텍처 설계는 흔히 소프트웨어 애플리케이션 설계와 대비된다. 애플리케이션 설계가 요구되는 기능(시스템이 제공하는 서비스)을 지원하는 프로세스 및 데이터 설계에 집중하는 반면, 소프트웨어 아키텍처 설계는 애플리케이션 기능이 실현되고 실행될 수 있는 인프라를 설계하여 시스템의 비기능 요건을 충족하는 방식으로 기능이 제공되도록 하는 데 집중한다.

소프트웨어 아키텍처는 크게 두 가지 유형인 모놀리스와 분산 아키텍처로 분류될 수 있으며, 각각 고유한 하위 범주를 가진다.[4]

소프트웨어 아키텍처는 시간이 지남에 따라 복잡해지는 경향이 있다. 소프트웨어 아키텍트는 아키텍처를 지속적으로 점검하기 위해 "적합성 함수(fitness functions)"를 사용해야 한다.[4]

소프트웨어 아키텍처 활동

범위

[편집]

소프트웨어 아키텍처의 범위에 대해서는 의견이 다양하다.[6]

  • 거시적 시스템 구조: 이는 소프트웨어 시스템의 상위 수준 추상화로서의 아키텍처를 의미하며, 계산 컴포넌트들의 집합과 이들 컴포넌트 간의 상호작용을 설명하는 커넥터들로 구성된다.[7]
  • 중요한 것(그것이 무엇이든): 이는 소프트웨어 아키텍트가 시스템과 이해관계자에게 큰 영향을 미치는 결정들에 관심을 가져야 한다는 사실을 의미한다.[8]
  • 환경 내에서 시스템을 이해하는 데 근본적인 것[9]
  • 사람들이 바꾸기 어렵다고 인식하는 것: 아키텍처 설계는 소프트웨어 시스템 수명 주기의 초기에 이루어지므로, 아키텍트는 처음부터 "제대로" 내려져야 하는 결정에 집중해야 한다. 이러한 생각에 따르면, 아키텍처 설계 이슈는 그 가역성이 극복될 수 있게 되면 더 이상 아키텍처적인 이슈가 아니게 될 수 있다.[8]
  • 아키텍처 설계 결정의 집합: 소프트웨어 아키텍처는 단순히 모델이나 구조의 집합으로 간주되어서는 안 되며, 그러한 특정 구조로 이어진 결정들과 그 배후의 근거를 포함해야 한다.[10] 이러한 통찰은 소프트웨어 아키텍처 지식 경영에 대한 상당한 연구로 이어졌다.[11]

소프트웨어 아키텍처와 설계, 그리고 요구공학 사이에는 명확한 구분이 없다(아래의 관련 분야 참조). 이들은 모두 상위 수준의 의도에서 하위 수준의 세부 사항에 이르는 "의도성의 사슬(chain of intentionality)"의 일부이다.[12]: 18 

소프트웨어 아키텍처 스타일 vs. 소프트웨어 아키텍처 패턴

[편집]

소프트웨어 아키텍처 패턴은 시스템 수준에서 반복되는 문제에 대한 재사용 가능하고 검증된 솔루션을 의미하며, 시스템의 전체 구조, 컴포넌트 상호작용 및 품질 속성과 관련된 문제를 다룬다. 소프트웨어 아키텍처 패턴은 소프트웨어 디자인 패턴보다 높은 추상화 수준에서 작동하며, 더 광범위한 시스템 수준의 과제를 해결한다. 이러한 패턴은 일반적으로 시스템 수준의 관심사에 영향을 미치지만, 아키텍처 패턴과 아키텍처 스타일 사이의 구분은 때때로 모호할 수 있다. 예로는 서킷 브레이커가 있다.[13][14][15]

소프트웨어 아키텍처 스타일은 전체적인 시스템 조직을 정의하는 상위 수준의 구조적 구성을 의미하며, 컴포넌트가 어떻게 구성되고 상호작용하는지, 그리고 그러한 상호작용에 대한 제약 조건을 명시한다. 아키텍처 스타일은 일반적으로 컴포넌트 및 커넥터 유형의 어휘뿐만 아니라 시스템의 속성을 해석하기 위한 의미론적 모델을 포함한다. 이러한 스타일은 시스템 조직의 가장 거친 수준을 나타낸다. 예로는 계층형 아키텍처, 마이크로서비스, 이벤트 기반 아키텍처 등이 있다.[13][14][15]

안티패턴

[편집]

아키텍트가 결정을 내릴 때 다음과 같은 아키텍처 안티패턴이 발생할 수 있다. 이러한 안티패턴은 종종 하나를 해결하면 다른 하나가 나타나는 점진적인 순서를 따르기도 한다.[4]

  • 아키텍트가 잘못된 선택을 할 것에 대한 두려움 때문에 아키텍처 결정을 지연하거나 회피할 수 있다. 이를 해결하기 위해 개발 팀과의 지속적이고 긴밀한 협력이 필요하며, 그들의 피드백에 따라 아키텍처 선택을 조정해야 한다. 또한 결정은 일반적으로 "마지막 책임 있는 순간(last responsible moment)"에 내려지며, 이는 결정을 정당화하고 검증할 수 있는 충분한 정보를 확보하는 동시에, 분석마비로 이어져 팀의 진행을 방해할 수 있는 불필요한 지연을 피하기 위함이다.[4]
  • 또 다른 안티패턴은 아키텍처 결정이 잊혀지거나 문서화되지 않거나 이해되지 않아 해결 없이 반복적인 논의가 이어질 때 발생할 수 있다. 이는 종종 이메일을 통해 아키텍처 결정을 전달할 때 발생한다. 이러한 문제를 해결하기 위해 아키텍트는 일반적으로 기술적 근거와 비즈니스 근거(종종 비용, 사용자 만족도, 시장 출시 기간과 관련됨)를 모두 단일 아키텍처 결정 기록(보통 아키텍처 결정 기록, ADR)에 제공한다. 이 기록은 위키와 같이 접근 가능한 저장소에 유지될 수 있다. 이메일을 통한 소통은 변경의 성격과 문맥에 집중하고 관련 이해관계자에게만 전달하며 중앙 집중식 기록에 대한 링크를 포함한다. 이를 통해 항상 업데이트된 단일 진실 공급원을 확보할 수 있다. 또한 아키텍처 결정이 가시적인 비즈니스 가치를 제공하지 않거나 비즈니스 가치가 이해관계자와 일치하지 않는 경우 재검토가 필요할 수 있다.[4]

특성

[편집]

소프트웨어 아키텍처는 다음과 같은 특성을 나타낸다.

다수의 이해관계자: 소프트웨어 시스템은 비즈니스 관리자, 소유자, 사용자, 운영자 등 다양한 이해관계자의 요구를 충족해야 한다. 이러한 이해관계자들은 모두 시스템에 대해 각자의 우려 사항을 가지고 있다. 이러한 우려 사항들의 균형을 맞추고 그것들이 해결되었음을 입증하는 것이 시스템 설계의 일부이다.[5]: 29–31  이는 아키텍처가 광범위한 관심사와 이해관계자를 다루는 일이며 다학제적 성격을 가짐을 의미한다.

관심사 분리: 아키텍트가 복잡성을 줄이기 위해 확립한 방법은 설계를 주도하는 관심사들을 분리하는 것이다. 아키텍처 문서는 다양한 이해관계자의 우려 사항과 관련된 별도의 관점에서 아키텍처를 모델링하고 설명함으로써 모든 이해관계자의 우려 사항이 해결되었음을 보여준다.[16] 이러한 별도의 설명을 아키텍처 뷰라고 한다(예를 들어 4+1 뷰 모델 참조).

품질 주도: 고전적인 소프트웨어 설계 접근 방식(예: 잭슨 구조적 프로그래밍)은 요구되는 기능과 시스템을 통한 데이터 흐름에 의해 주도되었으나, 현재의 통찰[5]: 26–28 은 소프트웨어 시스템의 아키텍처가 결함 허용, 하위 호환성, 확장 가능성, 신뢰성, 유지보수성, 가용성, 보안, 사용성 등과 같은 품질 속성(-ilities)과 더 밀접하게 관련되어 있다는 것이다. 이해관계자의 우려 사항은 종종 이러한 품질 속성에 대한 요구사항으로 번역되며, 이는 비기능 요건, 부가 기능 요구사항, 행동 요구사항 또는 품질 속성 요구사항 등으로 다양하게 불린다.

반복되는 스타일: 건축 아키텍처와 마찬가지로 소프트웨어 아키텍처 분야에서도 반복되는 문제를 해결하기 위한 표준적인 방법들을 개발해 왔다. 이러한 "표준적인 방법"은 다양한 추상화 수준에서 다양한 이름으로 불린다. 반복되는 솔루션에 대한 일반적인 용어로는 아키텍처 스타일,[12]: 273–277  전술(tactic),[5]: 70–72  참조 아키텍처 및 아키텍처 패턴이 있다.[17][18][5]: 203–205 

개념적 무결성: 프레더릭 브룩스가 그의 1975년 저서 맨먼스 미신에서 도입한 용어로, 소프트웨어 시스템의 아키텍처가 시스템이 무엇을 해야 하고 어떻게 해야 하는지에 대한 전반적인 비전을 나타내야 한다는 아이디어를 의미한다. 이 비전은 구현과 분리되어야 한다. 아키텍트는 "비전의 수호자" 역할을 맡아 시스템에 추가되는 사항들이 아키텍처와 일치하도록 보장함으로써 개념적 무결성을 유지한다.[19]: 41–50 

인지적 제약: 1967년 컴퓨터 프로그래머 멜빈 콘웨이가 처음 관찰한 것으로, 시스템을 설계하는 조직은 그 조직의 소통 구조를 복제한 설계를 생산하도록 제약받는다는 것이다.[20] 프레더릭 브룩스는 맨먼스 미신에서 이 논문과 아이디어를 인용하며 이를 콘웨이의 법칙이라고 불러 널리 알렸다.

동기 부여

[편집]

소프트웨어 아키텍처는 복잡한 시스템을 "지적으로 이해할 수 있는" 추상화이다.[21] 이러한 추상화는 여러 가지 이점을 제공한다:

  • 소프트웨어 시스템을 구축하기 전에 소프트웨어 시스템의 동작을 분석할 수 있는 프레임워크를 제공한다. 미래의 소프트웨어 시스템을 실제로 구축하지 않고도 이해관계자의 요구 사항을 충족하는지 확인할 수 있어 상당한 비용 절감과 위험 감소 효과를 제공한다.[22] 효과적인 아키텍처는 이러한 요구 사항을 충족할 뿐만 아니라 향후 확장성 및 유지 관리도 용이하게 해준다.[23]
  • 아키텍처는 요소와 솔루션을 재사용할 수 있는 프레임워크를 제공한다. 전체 소프트웨어 아키텍처 또는 개별 아키텍처 전략 및 솔루션과 같은 일부 요소를 이해관계자가 유사한 품질 속성 또는 기능을 요구하는 여러 시스템에서 재사용할 수 있으므로 설계 비용을 절감하고 설계 오류의 위험을 줄일 수 있다.[24]
  • 시스템의 개발, 배포 및 수명에 영향을 미치는 초기 설계 결정을 지원한다. 일정과 예산 초과를 방지하려면 영향력이 큰 초기 의사 결정을 올바르게 내리는 것이 중요하다.
  • 이해관계자와의 커뮤니케이션을 용이하게 하여 이해관계자의 요구를 더 잘 충족하는 시스템을 만드는 데 기여한다. 이해관계자의 관점에서 복잡한 시스템에 대한 정보를 제시하면 이해관계자가 명시된 요구사항의 의미를 이해하고 이를 기반으로 설계 결정을 내리는 데 도움이 된다.
  • 이는 리스크 관리에도 도움이 된다. 소프트웨어 아키텍처는 위험과 실패 확률을 줄이는 데 도움이 된다.[25]
  • 비용 절감에 도움이 된다. 소프트웨어 아키텍처는 복잡한 IT 프로젝트에서 위험과 비용을 관리하는 수단이다.[26]

역사

[편집]

소프트웨어 설계와 (토목) 건축 간의 비교는 1960년대 후반에 처음 제기되었으나,[27] "소프트웨어 아키텍처"라는 용어는 1990년대에 들어서야 널리 사용되기 시작했다.[28] 컴퓨터 과학 분야는 형성 초기부터 복잡성과 관련된 문제에 직면해 왔다.[29] 초기의 복잡성 문제는 개발자들이 올바른 자료 구조를 선택하고, 알고리즘을 개발하며, 관심사 분리 개념을 적용함으로써 해결되었다. "소프트웨어 아키텍처"라는 용어는 업계에서 비교적 생소하지만, 이 분야의 기본 원칙은 1980년대 중반부터 소프트웨어 공학의 선구자들에 의해 산발적으로 적용되어 왔다. 시스템의 소프트웨어 아키텍처를 포착하고 설명하려는 초기 시도들은 부정확하고 무질서했으며, 종종 상자와 선으로 이루어진 다이어그램의 집합으로 특징지어졌다.[30]

개념으로서의 소프트웨어 아키텍처는 1968년 에츠허르 데이크스트라와 1970년대 초 데이비드 파나스의 연구에 뿌리를 두고 있다. 이 과학자들은 소프트웨어 시스템의 구조가 중요하며 올바른 구조를 갖추는 것이 결정적이라고 강조했다. 1990년대에는 아키텍처 스타일(패턴), 아키텍처 기술 언어, 아키텍처 설계 문서화, 정형 기법 등에 집중된 연구와 함께 이 분야의 근본적인 측면을 정의하고 체계화하려는 공동의 노력이 있었다.[31]

연구 기관들은 소프트웨어 아키텍처를 하나의 학문으로 발전시키는 데 두드러진 역할을 했다. 카네기 멜런의 메리 쇼와 데이비드 갈란은 1996년에 《Software Architecture: Perspectives on an Emerging Discipline》이라는 책을 저술하여 컴포넌트, 커넥터, 스타일과 같은 소프트웨어 아키텍처 개념을 홍보했다. 캘리포니아 대학교 어바인의 소프트웨어 연구소(ISR)의 노력은 주로 아키텍처 스타일, 아키텍처 기술 언어 및 동적 아키텍처에 집중되었다.

IEEE 1471-2000, "Recommended Practice for Architecture Description of Software-Intensive Systems"는 소프트웨어 아키텍처 분야의 첫 번째 공식 표준이었다. 이는 2007년에 ISO에 의해 ISO/IEC 42010:2007로 채택되었다. 2011년 11월에 IEEE 1471-2000은 ISO/IEC/IEEE 42010:2011, "Systems and software engineering – Architecture description"(IEEE와 ISO 공동 발행)으로 대체되었다.[16]

IEEE 1471에서 소프트웨어 아키텍처가 "소프트웨어가 시스템 전체의 설계, 구축, 전개 및 진화에 필수적인 영향을 미치는 모든 시스템"으로 정의된 "소프트웨어 집약적 시스템"의 아키텍처에 관한 것이었다면, 2011년판은 하드웨어와 소프트웨어뿐만 아니라 "인간, 프로세스, 절차, 시설, 재료 및 자연 발생 실체"까지 포함하는 ISO/IEC 15288 및 ISO/IEC 12207의 시스템 정의를 포함함으로써 한 단계 더 나아갔다. 이는 소프트웨어 아키텍처, 엔터프라이즈 아키텍처 및 솔루션 아키텍처 간의 관계를 반영한다.

아키텍처 활동

[편집]

아키텍처 결정을 내리는 것은 충분한 관련 정보를 수집하고, 결정에 대한 정당성을 제공하며, 결정과 그 근거를 문서화하고, 이를 적절한 이해관계자에게 효과적으로 전달하는 것을 포함한다.[4]

아키텍처 특성(일명 비기능 요건)을 비즈니스 요구사항과 일치시키는 것은 소프트웨어 아키텍트의 책임이다. 예를 들어:[4]

  • 높은 고객만족을 얻으려면 시스템에 가용성, 결함 허용, 보안, 테스트 가능성, 복구 가능성, 민첩성 및 성능이 필요하다.
  • 인수 합병(M&A)을 수행하려면 확장성, 확장 가능성, 적응성 및 상호 운용성이 필요하다.
  • 제약된 예산과 시간에는 타당성과 단순성이 필요하다.
  • 빠른 시장 출시 기간(time-to-market)에는 유지보수성, 테스트 가능성 및 전개 가능성이 필요하다.

소프트웨어 아키텍처 설계에는 네 가지 핵심 활동이 있다.[32] 이러한 핵심 아키텍처 활동은 시스템의 진화 과정뿐만 아니라 초기 소프트웨어 개발 수명 주기의 다양한 단계에서 반복적으로 수행된다.

아키텍처 분석은 제안된 시스템이 운영될 환경을 이해하고 시스템에 대한 요구사항을 결정하는 프로세스이다. 분석 활동에 대한 입력 또는 요구사항은 다수의 이해관계자로부터 올 수 있으며 다음과 같은 항목을 포함한다.

  • 시스템이 운영될 때 무엇을 할 것인가 (기능적 요구사항)
  • ISO/IEC 25010:2011 표준에 정의된 신뢰성, 운영성, 성능 효율성, 보안, 호환성과 같은 런타임 비기능 요건을 시스템이 얼마나 잘 수행할 것인가[33]
  • ISO 25010:2011 표준에 정의된 유지보수성 및 전이성과 같은 개발 시점의 비기능 요건[33]
  • 법적, 사회적, 금융적, 경쟁적, 기술적 우려 사항과 같이 시간이 지남에 따라 변할 수 있는 시스템의 비즈니스 요구사항 및 환경적 맥락[34]

분석 활동의 결과물은 소프트웨어 시스템의 아키텍처에 측정 가능한 영향을 미치는 요구사항들로, 이를 아키텍처적으로 유의미한 요구사항(architecturally significant requirements)이라고 한다.[35]

아키텍처 종합 또는 설계는 아키텍처를 생성하는 프로세스이다. 분석을 통해 결정된 아키텍처적으로 유의미한 요구사항, 현재의 설계 상태 및 평가 활동 결과를 바탕으로 설계를 생성하고 개선한다.[32][5]: 311–326 

아키텍처 평가는 현재의 설계 또는 그 일부가 분석 중에 도출된 요구사항을 얼마나 잘 충족하는지 결정하는 프로세스이다. 평가는 아키텍트가 설계 결정을 고려할 때마다 발생할 수 있고, 설계의 일부가 완료된 후에 발생할 수도 있으며, 최종 설계가 완료된 후 또는 시스템이 구축된 후에 발생할 수도 있다. 사용 가능한 소프트웨어 아키텍처 평가 기법으로는 ATAM(아키텍처 트레이드오프 분석 방법) 및 TARA 등이 있다.[36] 기법들을 비교하기 위한 프레임워크는 SARA 보고서[37] 및 Architecture Reviews: Practice and Experience 등에서 논의된다.[38]

아키텍처 진화는 요구사항과 환경의 변화에 맞추어 기존 소프트웨어 아키텍처를 유지 관리하고 적응시키는 프로세스이다. 소프트웨어 아키텍처가 소프트웨어 시스템의 근본적인 구조를 제공하므로, 그것의 진화와 유지 관리는 필연적으로 근본 구조에 영향을 미친다. 따라서 아키텍처 진화는 새로운 기능을 추가하는 것뿐만 아니라 기존 기능과 시스템 동작을 유지하는 것과도 관련이 있다.

아키텍처는 필수적인 지원 활동을 필요로 한다. 이러한 지원 활동은 핵심 소프트웨어 아키텍처 프로세스 전반에 걸쳐 일어난다. 여기에는 지식 경영 및 의사소통, 설계 추론 및 의사결정, 그리고 문서화가 포함된다.

아키텍처 지원 활동

[편집]

소프트웨어 아키텍처 지원 활동은 핵심 소프트웨어 아키텍처 활동 중에 수행된다. 이러한 지원 활동은 소프트웨어 아키텍트가 분석, 종합, 평가 및 진화를 수행하는 것을 돕는다. 예를 들어, 아키텍트는 분석 단계에서 지식을 수집하고, 결정을 내리며, 문서화해야 한다.

  • 지식 경영 및 의사소통은 소프트웨어 아키텍처를 설계하는 데 필수적인 지식을 탐색하고 관리하는 행위이다. 소프트웨어 아키텍트는 고립되어 일하지 않는다. 그들은 다양한 이해관계자로부터 입력, 기능적 및 비기능적 요구사항, 설계 맥락을 받고, 이해관계자에게 결과물을 제공한다. 소프트웨어 아키텍처 지식은 종종 암묵적이며 이해관계자의 머릿속에 보관된다. 소프트웨어 아키텍처 지식 경영 활동은 지식을 찾고, 전달하며, 유지하는 것에 관한 것이다. 소프트웨어 아키텍처 설계 이슈는 복잡하고 상호 의존적이므로 설계 추론의 지식 격차는 잘못된 소프트웨어 아키텍처 설계로 이어질 수 있다.[39][40] 지식 경영 및 의사소통 활동의 예로는 디자인 패턴 검색, 프로토타이핑, 숙련된 개발자 및 아키텍트에게 문의하기, 유사 시스템의 설계 평가하기, 다른 설계자 및 이해관계자와 지식 공유하기, 위키 페이지에 경험 문서화하기 등이 있다.
  • 설계 추론 및 의사결정은 설계 결정을 평가하는 활동이다. 이 활동은 세 가지 핵심 소프트웨어 아키텍처 활동 모두에 근본적이다.[10][41] 이는 결정을 내리기 전에 결정 맥락을 수집 및 연관시키고, 설계 결정 문제를 공식화하며, 솔루션 옵션을 찾고 트레이드오프를 평가하는 것을 수반한다. 이 프로세스는 유의미한 아키텍처 요구사항과 소프트웨어 아키텍처 결정을 평가하는 동안, 그리고 소프트웨어 아키텍처 분석, 종합 및 평가 과정에서 다양한 결정 세분화 수준에서 발생한다. 추론 활동의 예로는 요구사항이나 설계가 품질 속성에 미치는 영향 이해하기, 설계가 일으킬 수 있는 문제에 대해 질문하기, 가능한 솔루션 옵션 산정하기, 솔루션 간의 트레이드오프 평가하기 등이 있다.
  • 문서화는 소프트웨어 아키텍처 프로세스 중에 생성된 설계를 기록하는 행위이다. 시스템 설계는 시스템의 코드 구조를 보여주는 정적 뷰, 실행 중 시스템의 동작을 보여주는 동적 뷰, 그리고 실행을 위해 시스템이 하드웨어에 어떻게 배치되는지 보여주는 배포 뷰를 포함한 여러 뷰를 사용하여 설명된다. 크러첸의 4+1 뷰는 소프트웨어 아키텍처 문서화에 일반적으로 사용되는 뷰들에 대한 설명을 제안한다.[42] 《Documenting Software Architectures: Views and Beyond》에는 뷰 설명 내에서 사용될 수 있는 표기법의 종류에 대한 설명이 포함되어 있다.[1] 문서화 활동의 예로는 명세서 작성, 시스템 설계 모델 기록, 설계 근거 문서화, 관점 개발, 뷰 문서화 등이 있다.

소프트웨어 아키텍처 설계 전략

[편집]

소프트웨어 아키텍처는 본질적으로 불확실성을 다루며, 아키텍처 컴포넌트의 크기는 시스템의 결과에 긍정적으로든 부정적으로든 상당한 영향을 미칠 수 있다. 닐 포드와 마크 리처즈는 컴포넌트를 식별하고 적절한 크기를 정하는 과제를 해결하기 위해 반복적인 접근 방식을 제안한다. 이 방법은 팀이 시스템의 동작과 요구사항에 대해 더 미묘한 이해를 가짐에 따라 지속적으로 정제하는 것을 강조한다.[4]

이 접근 방식은 일반적으로 다음과 같은 몇 가지 단계의 주기를 포함한다.[4]

  • 상위 수준의 파티셔닝 전략이 수립되며, 종종 기술 기반 또는 도메인 기반으로 분류된다. 의미 있는 최소 배포 단위인 "퀀타(quanta)"에 대한 지침이 정의된다. 이러한 근본적인 결정은 초기에 내려지지만, 필요한 경우 나중에 주기를 돌며 재검토될 수 있다.
  • 수립된 전략에 따라 초기 컴포넌트들이 식별된다.
  • 식별된 컴포넌트에 요구사항이 할당된다.
  • 명확성을 보장하고 중복을 최소화하기 위해 각 컴포넌트의 역할과 책임을 분석한다.
  • 확장성, 결함 허용, 유지보수성 등 아키텍처 특성을 평가한다.
  • 개발 팀의 피드백을 바탕으로 컴포넌트가 재구성될 수 있다.

이 주기는 일반적인 프레임워크 역할을 하며 다양한 도메인에 맞춰 조정될 수 있다.

소프트웨어 아키텍처 주제

[편집]

소프트웨어 아키텍처와 애자일 개발

[편집]

소프트웨어 아키텍처가 특히 애자일 소프트웨어 개발 지지자들 사이에서 너무 많은 앞선 대규모 설계(big design up front)로 이어진다는 우려도 있다. 사전 설계와 민첩성의 트레이드오프 균형을 맞추기 위해 다수의 방법이 개발되었으며,[43] "기반" 단계 동안 "충분할 정도의" 아키텍처 기반을 닦을 것을 의무화하는 애자일 방법인 DSDM이 그 예이다. IEEE Software는 민첩성과 아키텍처 간의 상호작용에 관한 특집호를 다루기도 했다.

소프트웨어 아키텍처 침식

[편집]

소프트웨어 아키텍처 침식은 시간이 지남에 따라 소프트웨어 시스템의 의도된 아키텍처와 구현된 아키텍처 사이에 점진적인 간극이 생기는 것을 의미한다.[44] 소프트웨어 아키텍처 침식 현상은 1992년 페리와 울프가 소프트웨어 아키텍처에 대한 정의와 함께 처음 조명했다.[2]

소프트웨어 아키텍처 침식은 소프트웨어 개발 수명 주기의 각 단계에서 발생할 수 있으며 개발 속도와 유지보수 비용에 다양한 영향을 미친다. 소프트웨어 아키텍처 침식은 아키텍처 위반, 기술 부채의 축적, 지식의 기화 등 다양한 이유로 발생한다.[45] 아키텍처 침식의 유명한 사례는 모질라 웹 브라우저의 실패이다.[46] 모질라는 넷스케이프에서 만든 애플리케이션으로, 코드베이스가 복잡해 지속적인 변경으로 인해 유지보수가 어려워졌다. 초기 설계 부실과 커지는 아키텍처 침식 때문에 넷스케이프는 모질라 웹 브라우저를 재개발하는 데 2년을 소비했으며, 이는 비용이 많이 드는 수리와 프로젝트 지연을 방지하기 위한 선제적인 아키텍처 관리의 중요성을 보여준다.

아키텍처 침식은 소프트웨어 성능을 저하시키고, 진화 비용을 크게 증가시키며, 소프트웨어 품질을 떨어뜨릴 수 있다. 아키텍처 침식을 감지하기 위한 다양한 접근 방식과 도구가 제안되었다. 이러한 접근 방식은 주로 일관성 기반, 진화 기반, 결함 기반, 결정 기반 접근 방식의 네 가지 범주로 분류된다.[44] 예를 들어, 자동화된 아키텍처 준수 확인, 정적 코드 분석 도구, 리팩터링 기법 등은 침식을 조기에 식별하고 완화하는 데 도움이 된다.

또한, 아키텍처 침식을 해결하기 위해 사용되는 조치는 예방 조치와 구제 조치의 두 가지 주요 유형을 포함한다.[44] 예방 조치에는 아키텍처 규칙 강제, 정기적인 코드 리뷰, 자동화된 테스트가 포함되며, 구제 조치에는 리팩터링, 재설계 및 문서 업데이트가 포함된다.

소프트웨어 아키텍처 복구

[편집]

소프트웨어 아키텍처 복구(또는 재구축, 또는 역공학)는 구현 및 문서를 포함한 가용 정보로부터 소프트웨어 시스템의 아키텍처를 발견해내는 방법, 기법 및 프로세스를 포함한다. 아키텍처 복구는 종종 구식이 된 문서나 아키텍처 침식(구상된 아키텍처에서 벗어난 구현 및 유지보수 결정들)에 직면했을 때 정보에 입각한 결정을 내리기 위해 필요하다.[47] 정적 프로그램 분석으로서 소프트웨어 아키텍처를 복구하는 관행이 존재한다. 이는 소프트웨어 인텔리전스 관행에서 다루는 주제의 일부이다.

관련 분야

[편집]

설계

[편집]

아키텍처는 설계이지만 모든 설계가 아키텍처인 것은 아니다.[1] 실무에서 아키텍트는 소프트웨어 아키텍처(아키텍처 설계)와 세부 설계(비아키텍처 설계) 사이의 경선을 긋는 사람이다. 모든 경우에 들어맞는 규칙이나 지침은 없지만, 그 차이를 공식화하려는 시도는 있어 왔다. 의도/지역성 가설(Intension/Locality Hypothesis)에 따르면,[48] 아키텍처 설계와 세부 설계의 구분은 지역성 기준(Locality Criterion)에 의해 정의되는데,[48] 이에 따르면 소프트웨어 설계에 관한 진술이 비지역적(아키텍처적)일 조건은 오직 그것을 만족하는 프로그램이 그것을 만족하지 않는 프로그램으로 확장될 수 있을 때뿐이다. 예를 들어, 클라이언트–서버 스타일은 아키텍처적(전략적)인데, 이 원칙에 따라 구축된 프로그램은 클라이언트-서버가 아닌 프로그램으로 확장될 수 있기 때문이다(예: 피어 투 피어 노드 추가).

요구공학

[편집]

요구공학과 소프트웨어 아키텍처는 보완적인 접근 방식으로 볼 수 있다. 소프트웨어 아키텍처가 '솔루션 공간' 또는 '어떻게'를 목표로 하는 반면, 요구공학은 '문제 공간' 또는 '무엇'을 다룬다.[49] 요구공학은 요구사항 도출, 협상, 명세, 검증, 문서화 및 관리를 수반한다. 요구공학 및 소프트웨어 아키텍처 모두 이해관계자의 우려 사항, 요구 및 희망 사항을 중심으로 회전한다.

다섯 가지 산업용 소프트웨어 아키텍처 방법에 대한 연구에서 "입력(목표, 제약 등)은 보통 모호하게 정의되며, 아키텍처가 나타나기 시작함에 따라 비로소 발견되거나 더 잘 이해된다"는 점과 "대부분의 아키텍처 우려 사항은 시스템에 대한 요구사항으로 표현되지만, 강제된 설계 결정 또한 포함될 수 있다"고 결론지은 것에서 알 수 있듯이, 요구공학와 소프트웨어 아키텍처 사이에는 상당한 겹침이 존재한다.[32] 간단히 말해서, 요구되는 동작은 솔루션 아키텍처에 영향을 미치고, 이는 다시 새로운 요구사항을 도입할 수 있다.[50] 트윈 픽스(Twin Peaks) 모델과 같은 접근 방식은 요구사항과 아키텍처 간의 시너지 관계를 활용하는 것을 목표로 한다.[51]

다른 유형의 '아키텍처'

[편집]
컴퓨터 구조
컴퓨터 구조는 CPU(또는 프로세서), 버스, 메모리와 같이 협력하는 하드웨어 컴포넌트 측면에서 컴퓨터 시스템의 내부 구조를 목표로 한다.
서버리스 아키텍처
서버리스 아키텍처는 종종 서버가 없는 것으로 오해받는 클라우드 컴퓨팅 패러다임이다. 이는 본질적으로 서버 관리 책임을 개발자에서 클라우드 서비스 제공자로 옮긴다. 이를 통해 기업은 물리적 서버 관리의 필요성 없이 클라우드 인프라에서 백엔드 코드를 실행할 수 있다. 서버리스 아키텍처의 이벤트 기반 접근 방식은 요청에 따라 실행되는 소규모의 작업 중심 함수들에 의존한다. 이러한 함수들은 서비스로서의 함수(FaaS)로 알려져 있으며, 사용한 만큼 지불하는 과금 모델과 애플리케이션 수요에 따른 동적 리소스 확장을 통해 비용 효율성을 제공한다.[52]
시스템 아키텍처
시스템 아키텍처라는 용어는 원래 하드웨어와 소프트웨어 모두로 구성된 시스템의 아키텍처에 적용되어 왔다. 시스템 아키텍처가 다루는 주요 관심사는 완전하고 올바르게 작동하는 장치 내에서 소프트웨어와 하드웨어의 통합이다. 또 다른 일반적인(훨씬 광범위한) 의미에서 이 용어는 기술적, 사회기술적 또는 사회적 성격을 가질 수 있는 모든 복잡한 시스템의 아키텍처에 적용된다.
엔터프라이즈 아키텍처
엔터프라이즈 아키텍처의 목표는 "비즈니스 비전과 전략을 효과적인 기업으로 번역하는 것"이다. TOGAF 및 자크만 프레임워크와 같은 엔터프라이즈 아키텍처 프레임워크는 대개 서로 다른 엔터프라이즈 아키텍처 계층을 구분한다. 용어는 프레임워크마다 다르지만, 많은 프레임워크가 적어도 사업 계층, 애플리케이션(또는 정보) 계층, 테크놀로지 계층 사이의 구분을 포함한다. 엔터프라이즈 아키텍처는 주로 하향식(top-down) 접근 방식을 통해 이러한 계층 간의 정렬을 다룬다.

같이 보기

[편집]

각주

[편집]
  1. 1 2 3 Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford (2010). 《Documenting Software Architectures: Views and Beyond, Second Edition》 (미국 영어). Boston: Addison-Wesley. ISBN 978-0-321-55268-6.
  2. 1 2 Perry, D. E.; Wolf, A. L. (1992). 《Foundations for the study of software architecture》 (PDF). 《ACM SIGSOFT Software Engineering Notes》 17. 40쪽. CiteSeerX 10.1.1.40.5174. doi:10.1145/141874.141884. S2CID 628695.
  3. ↑ 《Head First Software Architecture》. O'Reilly Media. 2024. ISBN 978-1-0981-3435-8.
  4. 1 2 3 4 5 6 7 8 9 10 11 《Fundamentals of Software Architecture: An Engineering Approach》. O'Reilly Media. 2020. ISBN 978-1-4920-4345-4.
  5. 1 2 3 4 5 6 Bass, Len; Paul Clements; Rick Kazman (2012). 《Software Architecture in Practice, Third Edition》. Boston: Addison-Wesley. ISBN 978-0-321-81573-6.
  6. ↑ SEI (2006). “How do you define Software Architecture?”. 2012년 9월 12일에 확인함.
  7. ↑ Garlan & Shaw (1994). “An Introduction to Software Architecture” (PDF). 2012년 9월 13일에 확인함.
  8. 1 2 Fowler, Martin (2003). 《Design – Who needs an architect?》. 《IEEE Software》 20. 11–44쪽. Bibcode:2003ISoft..20e..11F. doi:10.1109/MS.2003.1231144. S2CID 356506.
  9. ↑ ISO/IEC/IEEE 42010: Defining "architecture". Iso-architecture.org. Retrieved on 2013-07-21.
  10. 1 2 Jansen, A.; Bosch, J. (2005). 〈Software Architecture as a Set of Architectural Design Decisions〉. 《5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05)》. 109쪽. CiteSeerX 10.1.1.60.8680. doi:10.1109/WICSA.2005.61. ISBN 978-0-7695-2548-8. S2CID 13492610.
  11. ↑ Ali Babar, Muhammad; Dingsoyr, Torgeir; Lago, Patricia; van Vliet, Hans (2009). 《Software Architecture Knowledge Management》. Dordrecht Heidelberg London New York: Springer. ISBN 978-3-642-02373-6.
  12. 1 2 George Fairbanks (2010). 《Just Enough Software Architecture》. Marshall & Brainerd.
  13. 1 2 《Fundamentals of Software Architecture: An Engineering Approach》. O'Reilly Media. 2020. ISBN 978-1-4920-4345-4.
  14. 1 2 Larman, Craig (2005). 《Design Patterns: Elements of Reusable Object-Oriented Software》. Pearson Deutschland GmbH. ISBN 978-0-201-63361-0.
  15. 1 2 《Patterns of Enterprise Application Architecture》. ISBN 978-0-321-12742-6.
  16. 1 2 ISO/IEC/IEEE (2011). “ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description”. 2012년 9월 12일에 확인함.
  17. ↑ Muller, Gerrit (2007년 8월 20일). “A Reference Architecture Primer” (PDF). 《Gaudi site》. 2011년 12월 19일에 원본 문서 (PDF)에서 보존된 문서. 2015년 11월 13일에 확인함.
  18. ↑ Angelov, S.; Grefen, P.; Greefhorst, D. (2009). 〈A classification of software reference architectures: Analyzing their success and effectiveness〉. 《2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture》. IEEE. 141–150쪽. doi:10.1109/WICSA.2009.5290800. ISBN 978-1-4244-4984-2.
  19. ↑ Brooks, Frederick P. Jr. (1975). 《The Mythical Man-Month – Essays on Software Engineering》. Addison-Wesley. ISBN 978-0-201-00650-6.
  20. ↑ Conway, Melvin. “Conway's Law”. 《Mel Conway's Home Page》. 2019년 9월 29일에 원본 문서에서 보존된 문서. 2019년 9월 29일에 확인함.
  21. ↑ “Software Architecture in Practice”. books.google.com. 2023년 11월 2일에 확인함.
  22. ↑ “Software Architecture Review and Assessment (SARA) Report” (PDF). pkruchten.files.wordpress.com. 2023년 11월 2일에 확인함.
  23. ↑ “Softwarearchitektur: Der ultimative Leitfaden”. tectrain.ch. 2023년 11월 2일에 확인함.
  24. ↑ “Foundations for the Study of Software Architecture” (PDF). users.ece.utexas.edu. 2023년 11월 2일에 확인함.
  25. ↑ “Just Enough Software Architecture: A Risk-driven Approach”. books.google.com. 2023년 11월 2일에 확인함.
  26. ↑ “RCDA: Architecting as a risk- and cost management discipline”. zenodo.org. 2023년 11월 2일에 확인함.
  27. ↑ P. Naur; B. Randell 편집 (1969). “Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968” (PDF). Brussels: NATO, Scientific Affairs Division. 2003년 6월 7일에 원본 문서 (PDF)에서 보존된 문서. 2012년 11월 16일에 확인함.
  28. ↑ P. Kruchten; H. Obbink; J. Stafford (2006). 《The past, present and future of software architecture》. 《IEEE Software》 23. 22쪽. Bibcode:2006ISoft..23b..22K. doi:10.1109/MS.2006.59. S2CID 2082927.
  29. ↑ University of Waterloo (2006). “A Very Brief History of Computer Science”. 2006년 9월 23일에 확인함.
  30. ↑ 《Introduction to the Special Issue on Software Architecture》. 《IEEE.org》. 2006. doi:10.1109/TSE.1995.10003.
  31. ↑ Garlan & Shaw (1994). “An Introduction to Software Architecture” (PDF). 2006년 9월 25일에 확인함.
  32. 1 2 3 Christine Hofmeister; Philippe Kruchten; Robert L. Nord; Henk Obbink; Alexander Ran; Pierre America (2007). 《A general model of software architecture design derived from five industrial approaches》. 《Journal of Systems and Software》 80. 106–126쪽. doi:10.1016/j.jss.2006.05.024.
  33. 1 2 ISO/IEC (2011). “ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models”. 2012년 10월 8일에 확인함.
  34. ↑ Osterwalder and Pigneur (2004). 〈An Ontology for e-Business Models〉 (PDF). 《Value Creation from E-Business Models》. 65–97쪽. CiteSeerX 10.1.1.9.6922. doi:10.1016/B978-075066140-9/50006-0. ISBN 978-0-7506-6140-9. S2CID 14177438. 2018년 11월 17일에 원본 문서 (PDF)에서 보존된 문서.
  35. ↑ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). 《Characterizing Architecturally Significant Requirements》. 《IEEE Software》 30. 38–45쪽. Bibcode:2013ISoft..30b..38C. doi:10.1109/MS.2012.174. hdl:10344/3061. S2CID 17399565.
  36. ↑ Woods, E. (2012). 《Industrial architectural assessment using TARA》. 《Journal of Systems and Software》 85. 2034–2047쪽. doi:10.1016/j.jss.2012.04.055. S2CID 179244.
  37. ↑ Obbink, H.; Kruchten, P.; Kozaczynski, W.; Postema, H.; Ran, A.; Dominick, L.; Kazman, R.; Hilliard, R.; Tracz, W.; Kahane, E. (2002년 2월 6일). “Software Architecture Review and Assessment (SARA) Report” (PDF). 2015년 11월 1일에 확인함.
  38. ↑ Maranzano, J. F.; Rozsypal, S. A.; Zimmerman, G. H.; Warnken, G. W.; Wirth, P. E.; Weiss, D. M. (2005). 《Architecture Reviews: Practice and Experience》. 《IEEE Software》 22. 34쪽. Bibcode:2005ISoft..22b..34M. doi:10.1109/MS.2005.28. S2CID 11697335.
  39. ↑ Kruchten, P. (2008). 《What do software architects really do?》. 《Journal of Systems and Software》 81. 2413–2416쪽. doi:10.1016/j.jss.2008.08.025.
  40. ↑ Babar, M.A.; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). 《Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition》. Springer. ISBN 978-3-642-02373-6.
  41. ↑ Tang, A.; Han, J.; Vasa, R. (2009). 《Software Architecture Design Reasoning: A Case for Improved Methodology Support》. 《IEEE Software》 26. 43쪽. Bibcode:2009ISoft..26b..43T. doi:10.1109/MS.2009.46. hdl:1959.3/51601. S2CID 12230032.
  42. ↑ Kruchten, Philippe (1995). 《Architectural Blueprints – The '4+1' View Model of Software Architecture》 (PDF). 《IEEE Software》 12. 42–50쪽. arXiv:2006.04975. doi:10.1109/52.469759. S2CID 219558624.
  43. ↑ Boehm, Barry; Turner, Richard (2004). 《Balancing Agility and Discipline》. Addison-Wesley. ISBN 978-0-321-18612-6.
  44. 1 2 3 Li, Ruiyin; Liang, Peng; Soliman, Mohamed; Avgeriou, Paris (2022). 《Understanding software architecture erosion: A systematic mapping study》. 《Journal of Software: Evolution and Process》 34. arXiv:2112.10934. doi:10.1002/smr.2423.
  45. ↑ Li, Ruiyin; Liang, Peng; Soliman, Mohamed; Avgeriou, Paris (2021). 〈Understanding architecture erosion: The practitioners' perceptive〉. 《The 29th IEEE/ACM International Conference on Program Comprehension (ICPC)》. 311–322쪽. doi:10.1109/icpc52881.2021.00037. ISBN 978-1-6654-1403-6.
  46. ↑ van Gurp, J. and Bosch, J.: 2002, Design erosion: Problems and causes, Journal of Systems and Software 61(2), 105–119.
  47. ↑ Lungu, M. "Software architecture recovery", University of Lugano, 2008. http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
  48. 1 2 Amnon H. Eden; Rick Kazman (2003). “Architecture Design Implementation” (PDF). 2007년 9월 28일에 원본 문서 (PDF)에서 보존된 문서.
  49. ↑ C. Shekaran; D. Garlan; M. Jackson; N.R. Mead; C. Potts; H.B. Reubenstein (1994). 〈The role of software architecture in requirements engineering〉. 《Proceedings of IEEE International Conference on Requirements Engineering》. 239–245쪽. doi:10.1109/ICRE.1994.292379. ISBN 978-0-8186-5480-0. S2CID 3129363.
  50. ↑ Remco C. de Boer, Hans van Vliet (2009). 《On the similarity between requirements and architecture》. 《Journal of Systems and Software》 82. 544–550쪽. CiteSeerX 10.1.1.415.6023. doi:10.1016/j.jss.2008.11.185.
  51. ↑ Bashar Nuseibeh (2001). 《Weaving together requirements and architectures》 (PDF). 《Computer》 34. 115–119쪽. doi:10.1109/2.910904. 2012년 9월 7일에 원본 문서 (PDF)에서 보존된 문서.
  52. ↑ Company, DashDevs | FinTech Software Development. “How to Use Serverless Architecture | DashDevs” (영어). 《How to Use Serverless Architecture | DashDevs》. 2023년 8월 28일에 확인함.

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=소프트웨어_구조&oldid=41666643"