맨위로가기

소프트웨어 구조

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

소프트웨어 구조는 소프트웨어 시스템의 설계, 구성, 구조를 의미하며, 1990년대부터 널리 사용되었다. 소프트웨어 아키텍처는 시스템의 추상화, 컴포넌트 간의 상호 작용, 아키텍처 스타일 등을 포함하며, 다양한 이해 관계자의 요구를 충족하고 복잡성을 줄이는 데 중점을 둔다. 주요 특징으로는 다수의 이해 관계자, 관심사 분리, 품질 중심, 반복적인 스타일, 개념적 무결성, 인지적 제약 등이 있다. 소프트웨어 아키텍처는 분석, 합성, 평가, 진화의 핵심 활동을 포함하며, 지식 관리, 설계 추론, 문서화 등의 지원 활동을 수행한다. 또한, 아키텍처 기술 언어, 아키텍처 관점, 아키텍처 프레임워크, 아키텍처 스타일 및 패턴과 같은 다양한 기술과 주제를 다룬다. 소프트웨어 아키텍처는 애자일 개발과의 균형을 맞추는 것이 중요하며, 아키텍처 침식 및 복구와 같은 문제도 다룬다. 설계, 요구사항 공학, 컴퓨터 구조, 서버리스 아키텍처, 시스템 아키텍처, 전사적 아키텍처 등 관련 분야와도 밀접한 관련이 있다.

더 읽어볼만한 페이지

  • 에츠허르 데이크스트라 - 교착 상태
    교착 상태는 둘 이상의 프로세스가 자원을 점유하고 서로의 자원을 요청하여 더 이상 진행할 수 없는 상태를 의미하며, 상호 배제, 점유 대기, 비선점, 순환 대기 네 가지 조건이 모두 충족되어야 발생하고, 운영 체제는 이를 예방, 회피, 무시, 발견하는 방법으로 관리한다.
  • 에츠허르 데이크스트라 - 세마포어
    세마포어는 데이크스트라가 고안한 정수 변수로, P/V 연산을 통해 자원 접근을 제어하고 동기화 문제를 해결하며, 계수 세마포어와 이진 세마포어로 나뉘어 멀티스레드 환경에서 자원 관리 및 스레드 동기화에 기여한다.
  • 소프트웨어 개발 프로세스 - 버전 관리
    버전 관리는 파일 변경 이력을 체계적으로 관리하는 시스템이며, 다양한 구조와 소스 관리 모델을 통해 협업을 지원하고, 비즈니스 등 다양한 분야에서 활용된다.
  • 소프트웨어 개발 프로세스 - 소프트웨어 개발 수명 주기
    소프트웨어 개발 수명 주기(SDLC)는 시스템 설계자와 개발자가 따르는 일련의 단계로, 예비 분석부터 폐기까지 여러 단계를 거치며, 폭포수 모델, 시스템 분석 및 설계(SAD), 객체 지향 분석 및 설계(OOAD) 등 다양한 방법론을 포함한다.
  • 소프트웨어 구조 - Ajax
    Ajax는 웹 페이지 전체를 새로고침하지 않고 비동기적으로 서버와 통신하여 웹 애플리케이션의 일부를 업데이트하는 웹 개발 기술로, XMLHttpRequest 객체의 등장으로 가능해졌으며 HTML, CSS, DOM, JavaScript, JSON 등의 기술을 통합하여 동적인 사용자 인터페이스를 구현한다.
  • 소프트웨어 구조 - 멀티테넌시
    멀티테넌시는 단일 애플리케이션 인스턴스로 여러 고객에게 서비스를 제공하여 SaaS 및 클라우드 환경에서 비용과 관리 효율성을 높이고 데이터 활용 가치를 창출하는 소프트웨어 아키텍처 방식이다.
소프트웨어 구조
소프트웨어 아키텍처
정의소프트웨어 시스템의 기본 구조
관련 분야소프트웨어 공학
목적요구사항 충족, 품질 속성 확보, 이해관계자 간의 의사소통 촉진
개요
설명시스템의 구성 요소, 구성 요소 간의 관계, 환경과의 관계, 설계 및 진화 원칙을 포함하는 개념적 청사진
시스템의 비즈니스 목표 달성을 위한 전략적 결정과 기본 원칙을 정의
역사
기원1960년대 후반
발전1990년대 이후 중요성 부각, 다양한 스타일과 패턴 등장
주요 관심사
품질 속성성능
보안
가용성
확장성
유지보수성
아키텍처 스타일
종류계층형 아키텍처
마이크로커널 아키텍처
이벤트 기반 아키텍처
마이크로서비스 아키텍처
클라이언트-서버 아키텍처
파이프-필터 아키텍처
아키텍처 패턴
종류MVC (모델-뷰-컨트롤러) 패턴
팩토리 패턴
싱글톤 패턴
프록시 패턴
옵저버 패턴
중요성
이점시스템 개발의 복잡성 감소
재사용성 및 유지보수성 향상
품질 속성 충족
이해관계자 간의 의사소통 개선
역할
아키텍트시스템 아키텍처 설계 및 문서화
기술적 의사 결정 주도
개발팀 지원
기타
관련 기술UML (통합 모델링 언어)
아키텍처 설명 언어 (ADL)
참고 자료SWEBOK (Software Engineering Body of Knowledge)
IEEE 1471

2. 역사

소프트웨어 설계와 건축 간의 비교는 1960년대 말에 처음 나타났으며,[59] 소프트웨어 아키텍처라는 용어는 1990년대에 널리 사용되기 시작했다.[60] 컴퓨터 과학 분야는 초기부터 복잡성 문제를 겪었는데, 이는 자료 구조 선택, 알고리즘 개발, 관심사 분리 개념 적용 등을 통해 해결되었다. 1980년대 중반부터 소프트웨어 공학 선구자들은 소프트웨어 아키텍처의 기본 원칙을 적용해 왔지만, 초기 시도는 부정확하고 체계적이지 않은 다이어그램으로 표현되는 경우가 많았다.[23]

에츠허르 데이크스트라(1968년)와 데이비드 파르나스(1970년대 초)의 연구는 소프트웨어 아키텍처의 기원으로, 이들은 소프트웨어 시스템의 구조가 중요하며 올바른 구조를 갖는 것이 필수적이라고 강조했다. 1990년대에는 아키텍처 스타일(패턴), 아키텍처 기술 언어, 아키텍처 문서, 형식 기법 등 소프트웨어 아키텍처의 기본 요소를 정의하고 체계화하는 연구가 집중적으로 이루어졌다.[24]

카네기 멜론 대학교와 캘리포니아 대학교 어바인 등 연구 기관들은 소프트웨어 아키텍처를 학문 분야로 발전시키는 데 중요한 역할을 했다. 메리 쇼와 데이비드 갈란은 1996년에 ''소프트웨어 아키텍처: 떠오르는 분야에 대한 관점''이라는 책을 통해 컴포넌트, 커넥터, 스타일 등 소프트웨어 아키텍처 개념을 제시했다. 캘리포니아 대학교 어바인의 소프트웨어 연구소(Institute for Software Research)는 아키텍처 스타일, 아키텍처 기술 언어, 동적 아키텍처 분야를 중심으로 연구를 진행하고 있다.

IEEE 1471-2000 ("소프트웨어 집약 시스템의 아키텍처 기술을 위한 권장 실무")은 소프트웨어 아키텍처 분야의 최초 공식 표준이었다. 이는 2007년에 ISO에서 ISO/IEC 42010:2007로 채택되었고, 2011년 11월에는 ISO/IEC/IEEE 42010:2011 ("시스템 및 소프트웨어 공학 – 아키텍처 기술", IEEE와 ISO 공동 발행)로 대체되었다.[25]

3. 범위

소프트웨어 아키텍처의 범위에 대한 의견은 다음과 같이 다양하다:[8]


  • '''거시적인 시스템 구조''': 계산 ''컴포넌트''의 집합과 이러한 컴포넌트 간의 상호 작용을 설명하는 ''커넥터''로 구성된 소프트웨어 시스템의 더 높은 수준의 추상화를 아키텍처로 지칭한다.[9]
  • '''중요한 것들—그것이 무엇이든''': 소프트웨어 아키텍트는 시스템과 이해 관계자에게 큰 영향을 미치는 결정에 관심을 가져야 한다는 것을 의미한다.[10]
  • '''환경 내에서 시스템을 이해하는 데 근본적인 것'''[11]
  • '''사람들이 변경하기 어렵다고 인식하는 것''': 아키텍처 설계는 소프트웨어 시스템의 수명 주기의 시작 부분에서 이루어지므로 아키텍트는 처음부터 "올바르게" 해야 하는 결정에 집중해야 한다. 이러한 사고방식에 따르면, 아키텍처 설계 문제는 일단 그 가역성을 극복할 수 있게 되면 아키텍처가 아닌 문제가 될 수 있다.[10]
  • '''일련의 아키텍처 설계 결정''': 소프트웨어 아키텍처는 단순히 일련의 모델이나 구조로 간주되어서는 안 되며, 이러한 특정 구조로 이어지는 결정과 그 결정의 근거를 포함해야 한다.[33] 이러한 통찰력은 소프트웨어 아키텍처 지식 관리에 대한 상당한 연구로 이어졌다.[12]


소프트웨어 아키텍처와 설계, 요구 사항 엔지니어링 사이에는 뚜렷한 구분이 없다. ( 관련 분야 참조) 이들은 모두 높은 수준의 의도에서 낮은 수준의 세부 사항에 이르는 "의도 사슬"의 일부이다.[13]

4. 특징

소프트웨어 아키텍처는 다음과 같은 특징을 가진다.


  • '''다수의 이해 관계자:''' 소프트웨어 시스템은 비즈니스 관리자, 소유주, 사용자, 운영자와 같은 다양한 이해 관계자를 만족시켜야 한다. 이들은 모두 시스템에 대한 고유한 관심사를 가지고 있으며, 이러한 관심사의 균형을 맞추는 것이 시스템 설계의 일부이다.[7] 이는 소프트웨어 아키텍처가 광범위한 관심사와 이해 관계자를 다루는 다학제적인 성격을 띤다는 것을 의미한다.

  • '''관심사 분리:''' 소프트웨어 아키텍처는 복잡성을 줄이기 위해 설계를 추진하는 관심사를 분리한다. 아키텍처 문서는 모든 이해 관계자의 관심사가 다양한 이해 관계자의 관심사와 관련된 별도의 관점에서 아키텍처를 모델링하고 설명함으로써 해결됨을 보여준다.[25] 이러한 별도의 설명을 아키텍처 뷰라고 한다(예: 4+1 아키텍처 뷰 모델).

  • '''품질 중심:''' 기존의 소프트웨어 설계 방식은 요구되는 기능과 시스템을 통한 데이터 흐름에 의해 주도되었지만, 현재는 소프트웨어 시스템의 아키텍처가 결함 허용력, 하위 호환성, 확장성, 신뢰성, 유지 보수성, 가용성, 보안, 유용성 등과 같은 품질 속성과 더 밀접하게 관련되어 있다는 인식이 있다.[7] 이해 관계자의 관심사는 이러한 품질 속성에 대한 요구 사항으로 번역되며, 이는 비기능적 요구 사항, 추가 기능 요구 사항, 동작 요구 사항 또는 품질 속성 요구 사항이라고 불린다.

  • '''반복적인 스타일:''' 건축 아키텍처와 마찬가지로 소프트웨어 아키텍처 분야는 반복적인 관심사를 해결하기 위한 표준적인 방법을 개발했다. 이러한 "표준적인 방법"은 아키텍처 스타일,[13] 전술,[7] 참조 아키텍처, 아키텍처 패턴 등 다양한 수준의 추상화에서 다양한 이름으로 불린다.[14][15]

  • '''개념적 무결성:''' 프레드 브룩스가 1975년 저서 ''신화적 맨먼스''에서 소개한 용어로, 소프트웨어 시스템의 아키텍처가 시스템이 무엇을 해야 하고 어떻게 해야 하는지에 대한 전체적인 비전을 나타낸다는 개념이다. 이 비전은 구현과 분리되어야 하며, 아키텍트는 시스템에 대한 추가 사항이 아키텍처와 일치하도록 보장하여 개념적 무결성을 유지하는 "비전의 관리자" 역할을 한다.[16]

  • '''인지적 제약:''' 1967년 컴퓨터 프로그래머 멜빈 콘웨이의 논문에서 처음 언급된 관찰로, 시스템을 설계하는 조직은 해당 조직의 커뮤니케이션 구조를 복사한 설계를 생성하도록 제약을 받는다는 것이다.[17] 프레드 브룩스는 해당 논문과 아이디어를 ''신화적 맨먼스''에서 인용하면서 이를 콘웨이의 법칙이라고 부르며 더 많은 사람들에게 소개했다.

5. 동기

소프트웨어 아키텍처는 복잡한 시스템을 지적으로 이해할 수 있게 해주는 추상화이다.[61] 이러한 추상화는 다음과 같은 여러 가지 이점을 제공한다.


  • 분석 기반 제공: 소프트웨어 시스템을 구축하기 전에 동작을 분석하여, 이해 관계자의 요구사항 충족 여부를 확인할 수 있다. 이를 통해 비용 절감 및 위험 감소 효과를 얻을 수 있다.[62] 효과적인 아키텍처는 요구 사항을 충족할 뿐만 아니라 향후 확장성 및 유지보수도 용이하게 해준다.[63]
  • 재사용성: 전체 아키텍처 또는 개별 요소, 솔루션 등을 재사용하여 설계 비용 절감 및 오류 위험을 줄일 수 있다.[64]
  • 초기 설계 결정 지원: 시스템 개발, 배포, 수명에 영향을 미치는 초기 설계 결정을 지원하여 일정 및 예산 초과를 방지한다.
  • 이해 관계자와의 커뮤니케이션 용이: 이해 관계자의 관점에서 시스템 정보를 제시하여 요구사항 이해 및 설계 결정에 도움을 준다.
  • 위험 관리 및 비용 절감: 소프트웨어 아키텍처는 복잡한 IT 프로젝트에서 위험과 비용을 관리하는 수단이다.[66]

6. 아키텍처 활동

소프트웨어 아키텍트는 프로젝트 관리자와 협력하여 아키텍처적으로 중요한 요구사항을 논의하고, 소프트웨어 아키텍처를 설계, 평가하며, 설계자와 관계자 간의 소통을 돕고, 아키텍처 설계를 문서화하는 등 다양한 활동을 수행한다.[26]

소프트웨어 아키텍트는 아키텍처 특성(비기능 요구사항)을 비즈니스 요구사항과 일치시키는 책임을 진다.[5] 예를 들어, 높은 고객 만족도를 위해서는 시스템의 가용성, 내결함성, 보안 등이 필요하고, 합병 및 인수(M&A)를 위해서는 확장성, 상호 운용성 등이 필요하다. 제한된 예산과 시간은 타당성과 단순성을, 빠른 시장 출시 시간은 유지보수성, 테스트 용이성 및 배포 가능성을 요구한다.

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


  • '''아키텍처 분석''': 시스템이 작동할 환경을 이해하고 요구사항을 결정하는 과정이다. 다양한 관계자로부터 기능 요구사항, 런타임 및 개발 시간 비기능 요구사항, 비즈니스 요구사항 및 환경적 맥락 등을 수집한다.[27][28] 분석 결과, 아키텍처에 큰 영향을 미치는 요구사항이 도출된다.[29]
  • '''아키텍처 합성''': 분석을 통해 결정된 요구사항과 현재 설계 상태, 평가 결과를 바탕으로 아키텍처를 생성하고 개선하는 과정이다.[46][7]
  • '''아키텍처 평가''': 현재 설계가 요구사항을 얼마나 잘 충족하는지 평가하는 과정이다. 아키텍처 상쇄 분석 방법(ATAM) 및 TARA와 같은 평가 기법을 활용할 수 있다.[30]
  • '''아키텍처 진화''': 요구사항과 환경 변화에 맞춰 기존 아키텍처를 유지 관리하고 조정하는 과정이다.

6. 1. 아키텍처 지원 활동

소프트웨어 아키텍처 지원 활동은 핵심 소프트웨어 아키텍처 활동 중에 수행된다. 이러한 지원 활동은 소프트웨어 아키텍트가 분석, 합성, 평가 및 진화를 수행하는 데 도움을 준다. 예를 들어, 아키텍트는 분석 단계에서 지식을 수집하고, 결정을 내리고, 문서를 작성해야 한다.[26][32]

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

7. 소프트웨어 아키텍처 주제

소프트웨어 아키텍처는 컴퓨터 과학 분야에서 초창기부터 복잡성과 관련된 문제를 다루어 왔다.[51] 초기 복잡성 문제는 개발자가 올바른 자료 구조를 사용하고, 알고리즘을 개발하며, 문제를 분할하는 기법을 사용하여 해결했다. 1990년대에는 소프트웨어 아키텍처의 근본적인 기술 방법을 문서화하는 작업이 집중적으로 이루어졌으며, 초기 디자인 패턴, 모범 사례, 기술 언어, 형식 기법 등이 개발되었다.

소프트웨어 아키텍처는 주로 추상화와 문제 분할을 통해 복잡성을 줄이는 데 중점을 둔다. 그러나 "소프트웨어 아키텍처"라는 용어에 대해 만인이 합의한 엄격한 정의는 아직 존재하지 않는다.[53]

소프트웨어 아키텍처는 시스템이 갖춰야 할 여러 통찰력의 혼합이다. 시스템의 요구 사항은 기능 사양이 아닌 결함 허용, 호환성, 확장성, 신뢰성, 유지 보수성, 가용성, 정보 보안, 사용성 등 품질 수준으로 기술되는 경우가 많다.[54]

개념으로서의 소프트웨어 아키텍처는 1968년 에츠허르 데이크스트라의 연구와 1970년대 초 데이비드 파르나스의 연구에서 비롯되었다. 1990년대 초에는 이 분야의 연구가 활발해져, 아키텍처 스타일(패턴), 아키텍처 기술 언어, 아키텍처 문서화, 형식 기법 등이 주로 연구되었다.[56] 카네기 멜론 대학교와 캘리포니아 대학교 어바인(UCI) 등 다수의 연구 기관에서 소프트웨어 아키텍처 연구를 진행하고 있다.

''ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software-Intensive Systems''(소프트웨어 시스템의 아키텍처 기술을 위한 지침)는 소프트웨어 아키텍처 분야의 세계 최초 표준이며, 최근 ISO에 의해 ''ISO/IEC DIS 25961''로 채택되었다.

7. 1. 소프트웨어 아키텍처 기술

아키텍처 기술 언어(ADL)는 소프트웨어 아키텍처를 기술하기 위한 언어이다. 여러 ADL이 각기 다른 조직에 의해 개발되어 왔다. 예를 들어, 카네기 멜론 대학교의 Wright, Acme, 캘리포니아 대학교 어바인의 xADL, 임페리얼 칼리지 런던의 Darwin, 말라가 대학교의 DAOP-ADL 등이 있다. ADL의 기본 요소로는 컴포넌트, 커넥터, 구성 등이 있다.

7. 2. 아키텍처 기술 언어 (ADL)

아키텍처 기술 언어(ADL)는 소프트웨어 아키텍처를 설명하는 데 사용되는 모든 표현 수단이다. (ISO/IEC/IEEE 42010).

1990년대 이후 많은 특수 목적 ADL이 개발되었는데, 여기에는 다음이 포함된다.

  • AADL (SAE 표준)
  • Wright (카네기 멜론 대학교 개발)
  • Acme (카네기 멜론 대학교 개발)
  • xADL (UCI 개발)
  • Darwin (임페리얼 칼리지 런던 개발)
  • DAOP-ADL (말라가 대학교 개발)
  • SBC-ADL (국립 쑨원 대학 개발)
  • ByADL (이탈리아 라퀼라 대학교)


ADL의 기본 요소로는 컴포넌트, 커넥터, 구성 등이 있다.[55][56]

7. 3. 아키텍처 관점 (뷰)

4+1 아키텍처 뷰 모델


소프트웨어 아키텍처 설명은 일반적으로 뷰로 구성되며, 이는 건축 아키텍처에서 만들어지는 다양한 유형의 청사진과 유사하다. 각 뷰는 시스템의 일련의 관심사를 다루며, 해당 ''관점''의 규칙을 따른다. 여기서 관점은 특정 이해 관계자 및 그들의 관심사 관점에서 문제의 아키텍처를 표현하는 뷰에서 사용할 표기법, 모델링 및 분석 기법을 설명하는 사양이다.(ISO/IEC/IEEE 42010)[57] 관점은 프레이밍된 관심사(즉, 다루어야 할)뿐만 아니라 표현, 사용되는 모델 종류, 사용되는 규칙 및 다른 뷰와 일관성을 유지하기 위한 모든 일관성(대응) 규칙을 지정한다.

소프트웨어 아키텍처는 시스템이 갖춰야 할 여러 통찰력의 혼합이며, 소프트웨어 개발이 구체화되기 전에 소프트웨어 아키텍처를 만드는 것의 정당성을 보여준다. 소프트웨어 아키텍처는 일반적으로 여러 뷰(Views)로 구성되며,[57] 이는 건축에서 여러 다양한 설계도를 사용하는 것과 유사하다. ANSI/IEEE 1471-2000에 따르면, 뷰는 뷰포인트(viewpoints, 관점)의 인스턴스이며, 뷰포인트는 해당 시스템의 관계자가 각자의 입장에서 필요로 하는 아키텍처를 설명한 것이다.

다음과 같은 뷰(1471에서는 뷰포인트)가 있다.

  • 기능/로직 뷰
  • 코드 뷰
  • 개발/구조 뷰
  • 병렬성/프로세스/스레드 뷰
  • 물리/배치 뷰
  • 사용자 행동/피드백 뷰


소프트웨어 아키텍처를 기술하기 위한 언어는 몇 가지 고안되었지만, 널리 받아들여지지는 않았다.

7. 4. 아키텍처 프레임워크

아키텍처 프레임워크는 "특정 응용 분야 및/또는 이해 관계자 커뮤니티 내에서 구축된 아키텍처 설명에 대한 규칙, 원칙 및 관행"을 포착한다(ISO/IEC/IEEE 42010). 프레임워크는 일반적으로 하나 이상의 뷰포인트 또는 ADL(아키텍처 기술 언어)로 구현된다.[55]

아키텍처 프레임워크의 예시는 다음과 같다.

  • 국방부 아키텍처 프레임워크(DODAF)
  • MODAF
  • 오픈 그룹 아키텍처 프레임워크(TOGAF)
  • 자크만 프레임워크
  • 연방 기업 아키텍처(FEA)

7. 5. 아키텍처 스타일 및 패턴

소프트웨어 아키텍처 패턴은 주어진 맥락 내에서 소프트웨어 아키텍처에서 일반적으로 발생하는 문제에 대한 일반적이고 재사용 가능한 솔루션이다. 아키텍처 패턴은 종종 소프트웨어 디자인 패턴으로 문서화된다.

'소프트웨어 아키텍처 스타일'은 눈에 띄게 만드는 특징으로 특징지어지는 특정 구축 방식이다(아키텍처 스타일).

다음은 다양한 아키텍처 패턴과 스타일들이다.

일부에서는 아키텍처 패턴과 아키텍처 스타일을 동일하게 취급하며,[38] 일부에서는 스타일을 패턴의 특수화로 취급한다.

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

소프트웨어 아키텍처는 애자일 소프트웨어 개발 옹호자들 사이에서 과도한 사전 설계를 초래한다는 우려가 제기되기도 한다. 사전 설계와 민첩성 간의 균형을 맞추기 위해 여러 방법이 개발되었는데,[39] 그중 하나는 "적절한 수준"의 아키텍처 기초를 마련하는 "Foundations" 단계를 의무화하는 애자일 방법인 DSDM이다. ''IEEE 소프트웨어''는 민첩성과 아키텍처 간의 상호 작용에 대한 특별호를 할애하기도 했다.

9. 소프트웨어 아키텍처 침식

소프트웨어 아키텍처 침식은 시간이 지남에 따라 소프트웨어 시스템의 의도된 아키텍처와 구현된 아키텍처 간의 점진적인 격차를 의미한다.[40] 이 현상은 1992년 페리와 울프가 소프트웨어 아키텍처를 정의하면서 처음으로 밝혀졌다.[3]

소프트웨어 아키텍처 침식은 소프트웨어 개발 수명 주기의 각 단계에서 발생할 수 있으며 개발 속도와 유지 보수 비용에 다양한 영향을 미친다. 이는 '아키텍처 위반', '기술 부채의 축적', '지식 증발' 등 다양한 이유로 발생한다.[41] 아키텍처 침식의 유명한 사례는 모질라 웹 브라우저의 실패이다.[42] 모질라는 복잡한 코드베이스를 가진 넷스케이프에서 만든 응용 프로그램으로, 지속적인 변경으로 인해 유지 관리가 더 어려워졌다. 초기 설계 불량과 아키텍처 침식이 심화되면서 넷스케이프는 모질라 웹 브라우저를 재개발하는 데 2년의 시간을 보냈는데, 이는 광범위한 수리 노력, 시간 및 비용 손실을 피하기 위해 아키텍처 침식을 관리하는 것이 얼마나 중요한지를 보여준다.

아키텍처 침식은 소프트웨어 성능을 저하시키고, 진화 비용을 실질적으로 증가시키며, 소프트웨어 품질을 저하시킬 수 있다. 아키텍처 침식을 감지하기 위해 다양한 접근 방식과 도구가 제안되었다. 이러한 접근 방식은 주로 일관성 기반, 진화 기반, 결함 기반 및 결정 기반 접근 방식의 네 가지 범주로 분류된다. 또한 아키텍처 침식을 해결하기 위해 사용되는 조치는 예방 조치와 치료 조치의 두 가지 주요 유형을 포함한다.

10. 소프트웨어 아키텍처 복구

소프트웨어 아키텍처 복구(또는 재구성, 리버스 엔지니어링)는 구현 및 문서를 포함하여 사용 가능한 정보를 바탕으로 소프트웨어 시스템의 아키텍처를 파악하는 방법, 기술 및 프로세스이다. 아키텍처 복구는 종종 구식이거나 최신 정보를 벗어난 문서와 아키텍처 침식(구현 및 유지보수 결정이 예상된 아키텍처에서 벗어나는 상황)에 직면하여 정보에 입각한 결정을 내리는 데 필요하다.[43] 정적 프로그램 분석과 같이 소프트웨어 아키텍처를 복구하는 방법이 있으며, 소프트웨어 인텔리전스 분야에서 다루는 내용의 일부이다.

11. 관련 분야

소프트웨어 아키텍처는 컴퓨터 과학의 한 분야로, 1960년대 후반 소프트웨어 설계와 (토목) 건축의 비교에서 시작되었다.[20] 1990년대에 들어서야 "소프트웨어 아키텍처"라는 용어가 널리 사용되기 시작했다.[21]

초기에는 자료 구조 선택, 알고리즘 개발, 관심사 분리 등의 개념을 통해 소프트웨어의 복잡성 문제를 해결했다.[22] 1980년대 중반부터 소프트웨어 공학 선구자들에 의해 소프트웨어 아키텍처의 기본 원칙이 적용되기 시작했지만, 초기에는 다이어그램을 이용한 부정확하고 체계적이지 않은 방식으로 표현되었다.[23]

1990년대에는 아키텍처 스타일(패턴), 아키텍처 기술 언어, 아키텍처 문서 등에 대한 연구가 진행되면서 소프트웨어 아키텍처 분야가 체계화되기 시작했다.[24] 카네기 멜론 대학교와 캘리포니아 대학교 어바인 등의 연구 기관이 소프트웨어 아키텍처를 학문으로 발전시키는 데 중요한 역할을 했다.

IEEE 1471-2000은 소프트웨어 아키텍처 분야의 최초 공식 표준이었으며, 2007년 ISO/IEC 42010:2007로 채택되었다. 2011년에는 ISO/IEC/IEEE 42010:2011로 대체되었다.[25]

IEEE 1471에서는 소프트웨어 아키텍처를 "소프트웨어 집약 시스템"의 아키텍처로 정의했지만, 2011년 판에서는 ISO/IEC 15288 및 ISO/IEC 12207의 시스템 정의를 포함하여 하드웨어, 소프트웨어뿐만 아니라 사람, 프로세스, 절차 등까지 포괄하는 더 넓은 의미로 확장되었다. 이는 소프트웨어 아키텍처, 전사적 아키텍처, 솔루션 아키텍처 간의 관계를 반영한다.

소프트웨어 아키텍처는 요구사항 공학과 상호 보완적인 관계를 가지며, 전사적 아키텍처 등 다른 아키텍처 유형과도 관련이 있다.

11. 1. 설계

아키텍처는 설계의 일종이지만, 모든 설계가 아키텍처인 것은 아니다.[1] 아키텍처 설계와 상세 설계의 구분은 ''지역성 기준''에 의해 정의된다.[44] 이에 따르면 소프트웨어 설계에 대한 명제가 이를 만족하는 프로그램이 그렇지 않은 프로그램으로 확장될 수 있는 경우에만 비지역적(아키텍처)이다. 예를 들어, 클라이언트-서버 스타일은 이 원칙을 기반으로 구축된 프로그램이 P2P 노드를 추가하는 방식으로 클라이언트-서버가 아닌 프로그램으로 확장될 수 있기 때문에 아키텍처적(전략적)이다.

11. 2. 요구사항 공학

요구사항 공학과 소프트웨어 아키텍처는 상호 보완적인 접근 방식이다. 소프트웨어 아키텍처는 '솔루션 공간' 또는 '어떻게(how)'에 초점을 맞추는 반면, 요구사항 공학은 '문제 공간' 또는 '무엇(what)'을 다룬다.[45] 요구사항 공학은 도출, 협상, 명세, 검증, 문서화, 관리를 포함하며, 이 둘 모두 이해 관계자의 관심사, 요구 사항 및 희망 사항을 중심으로 한다.

요구사항 공학과 소프트웨어 아키텍처 사이에는 상당한 중복이 있다. 다섯 가지 산업용 소프트웨어 아키텍처 방법을 연구한 결과, ''"입력(목표, 제약 조건 등)은 대개 불분명하며, 아키텍처가 나타나기 시작하면서 발견되거나 더 잘 이해된다"''고 결론 내렸고, ''"대부분의 아키텍처 관련 사항은 시스템에 대한 요구사항으로 표현되지만, 필수적인 설계 결정도 포함될 수 있다"''.[46] 간단히 말해, 요구되는 동작은 솔루션 아키텍처에 영향을 미치고, 이는 다시 새로운 요구사항을 도입할 수 있다.[47] 상승 작용 관계를 활용하는 것을 목표로 하는 트윈 피크스 모델과 같은 접근 방식도 있다.[48]

11. 3. 기타 "아키텍처" 유형

;컴퓨터 구조

:컴퓨터 구조는 CPU 또는 프로세서, 버스 및 메모리와 같은 협업 하드웨어 구성 요소 측면에서 컴퓨터 시스템의 내부 구조를 목표로 한다.

;서버리스 아키텍처

:서버리스 아키텍처는 서버가 없는 것으로 오해되는 경우가 많은 클라우드 컴퓨팅 패러다임이다. 본질적으로 서버 관리 책임을 개발자에서 클라우드 서비스 제공업체로 이전한다. 이를 통해 기업은 클라우드 인프라에서 백엔드 코드를 실행하여 물리적 서버 관리가 필요 없다. 서버리스 아키텍처의 이벤트 중심 방식은 온디맨드로 실행되는 작고 작업별 기능에 의존한다. 이러한 기능은 FaaS(Function as a Service)로 알려져 있으며 종량제 요금 모델과 애플리케이션 수요에 따른 동적 리소스 확장을 통해 비용 효율성을 제공한다.[49]

;시스템 구조

:시스템 구조라는 용어는 원래 하드웨어와 소프트웨어로 구성된 시스템의 구조에 적용되었다. 그런 다음 시스템 아키텍처에서 해결해야 할 주요 관심사는 완전하고 올바르게 작동하는 장치에서 소프트웨어와 하드웨어의 통합이다. 또 다른 일반적인 의미, 즉 훨씬 더 광범위한 의미에서 이 용어는 기술적, 사회 기술적 또는 사회적 성격을 띨 수 있는 모든 복잡한 시스템의 구조에 적용된다.

;전사적 아키텍처

:전사적 아키텍처의 목표는 "비즈니스 비전과 전략을 효과적인 엔터프라이즈로 변환"하는 것이다. TOGAF 및 Zachman Framework와 같은 전사적 아키텍처 아키텍처 프레임워크는 일반적으로 서로 다른 전사적 아키텍처 계층을 구분한다. 용어는 프레임워크마다 다르지만 많은 프레임워크는 최소한 ''비즈니스 계층'', ''애플리케이션''(또는 ''정보'') ''계층'' 및 ''기술 계층'' 간의 구분을 포함한다. 전사적 아키텍처는 일반적으로 하향식 방식으로 이러한 계층 간의 정렬을 다룬다.

참조

[1] 서적 Documenting Software Architectures: Views and Beyond, Second Edition Addison-Wesley
[2] 웹사이트 Software Architecture https://www.sei.cmu.[...] 2018-07-23
[3] 논문 Foundations for the study of software architecture http://users.ece.ute[...]
[4] 서적 Head First Software Architecture O'Reilly Media
[5] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
[6] 서적 Fundamentals of Software Architecture An Engineering Approach O'Reilly Media
[7] 서적 Software Architecture in Practice, Third Edition Addison-Wesley
[8] 웹사이트 How do you define Software Architecture? http://www.sei.cmu.e[...] 2012-09-12
[9] 웹사이트 An Introduction to Software Architecture https://www.cs.cmu.e[...] 2012-09-13
[10] 논문 Design – Who needs an architect?
[11] 웹사이트 ISO/IEC/IEEE 42010: Defining "architecture" http://www.iso-archi[...] Iso-architecture.org 2013-07-21
[12] 서적 Software Architecture Knowledge Management Springer
[13] 서적 Just Enough Software Architecture Marshall & Brainerd
[14] 웹사이트 A Reference Architecture Primer http://www.gaudisite[...] 2007-08-20
[15] 서적 2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture https://ieeexplore.i[...] IEEE 2023-12-15
[16] 서적 The Mythical Man-Month – Essays on Software Engineering Addison-Wesley 1975
[17] 웹사이트 Conway's Law http://www.melconway[...] 2019-09-29
[18] 웹사이트 Software Architecture Review and Assessment (SARA) Report https://pkruchten.fi[...] 2002-02-06
[19] 논문 RCDA: Architecting as a risk- and cost management discipline https://zenodo.org/r[...] 2012-09
[20] 간행물 Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968 http://homepages.cs.[...] NATO, Scientific Affairs Division 2012-11-16
[21] 논문 The past, present and future of software architecture
[22] 웹사이트 A Very Brief History of Computer Science http://www.cs.uwater[...] 2006-09-23
[23] 논문 Introduction to the Special Issue on Software Architecture
[24] 웹사이트 An Introduction to Software Architecture https://www.cs.cmu.e[...] 2006-09-25
[25] 웹사이트 ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description http://www.iso.org/i[...] 2012-09-12
[26] 논문 What do software architects really do?
[27] 웹사이트 ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models http://www.iso.org/i[...] 2012-10-08
[28] 서적 Value Creation from E-Business Models
[29] 논문 Characterizing Architecturally Significant Requirements
[30] 논문 Industrial architectural assessment using TARA
[31] 논문 Architecture Reviews: Practice and Experience
[32] 서적 Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition Springer
[33] 논문 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05)
[34] 논문 Software Architecture Design Reasoning: A Case for Improved Methodology Support
[35] 논문 Architectural Blueprints – The '4+1' View Model of Software Architecture http://www.cs.ubc.ca[...]
[36] 서적 Software architecture: perspectives on an emerging discipline Prentice Hall 1996
[37] 웹사이트 UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles http://www.isr.uci.e[...] 2013-07-21
[38] 웹사이트 Chapter 3: Architectural Patterns and Styles http://msdn.microsof[...] 2013-07-21
[39] 서적 Balancing Agility and Discipline Addison-Wesley
[40] 간행물 Understanding software architecture erosion: A systematic mapping study https://onlinelibrar[...]
[41] 서적 The 29th IEEE/ACM International Conference on Program Comprehension (ICPC) https://ieeexplore.i[...]
[42] 문서 Design erosion: Problems and causes 2002
[43] 문서 Software architecture recovery http://www.slideshar[...] University of Lugano 2008
[44] 웹사이트 Architecture Design Implementation http://www.eden-stud[...]
[45] 서적 Proceedings of IEEE International Conference on Requirements Engineering
[46] 간행물 A general model of software architecture design derived from five industrial approaches
[47] 간행물 On the similarity between requirements and architecture
[48] 간행물 Weaving together requirements and architectures http://oro.open.ac.u[...]
[49] 웹사이트 How to Use Serverless Architecture {{!}} DashDevs https://dashdevs.com[...] 2023-08-28
[50] 웹사이트 ソフトウェアアーキテクチャとは？ソフトウェアアーキテクチャの基本を解説！ https://cmc-japan.co[...] 2024-02-09
[51] 웹사이트 A Very Brief History of Computer Science http://www.cs.uwater[...] 2006-09-23
[52] 웹사이트 Introduction to the Special Issue on Software Architecture http://csdl2.compute[...] 2006-09-23
[53] 웹사이트 How do you define Software Architecture? http://www.sei.cmu.e[...] 2006-09-23
[54] 웹사이트 Intro to Software Quality Attributes http://www.softwarea[...] 2006-09-23
[55] 웹사이트 Origins of Software Architecture Study http://www.sei.cmu.e[...] 2006-09-25
[56] 웹사이트 An Introduction to Software Architecture https://www.cs.cmu.e[...] 2006-09-25
[57] 서적 Documenting Software Architectures: Views and Beyond Addison-Wesley 2003
[58] 웹사이트 The Clean Architecture https://blog.cleanco[...] 2012
[59] 웹인용 Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968. http://homepages.cs.[...] NATO, Scientific Affairs Division, 2012-11-16
[60] 웹인용 The past, present and future of software architecture http://dx.doi.org/10[...] 2012-11-12
[61] 웹인용 Software Architecture in Practice https://books.google[...] books.google.com 2023-11-02
[62] 웹인용 Software Architecture Review and Assessment (SARA) Report https://pkruchten.fi[...] pkruchten.files.wordpress.com 2023-11-02
[63] 웹인용 Softwarearchitektur: Der ultimative Leitfaden https://tectrain.ch/[...] tectrain.ch 2023-11-02
[64] 웹인용 Foundations for the Study of Software Architecture https://users.ece.ut[...] users.ece.utexas.edu 2023-11-02
[65] 웹인용 Just Enough Software Architecture: A Risk-driven Approach https://books.google[...] books.google.com 2023-11-02
[66] 웹인용 RCDA: Architecting as a risk- and cost management discipline https://zenodo.org/r[...] zenodo.org 2023-11-02


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com