본문으로 건너뛰기

ISO/IEC/IEEE 42010

개념

ISO/IEC/IEEE 42010은 소프트웨어·시스템·엔터프라이즈의 아키텍처 기술에 필요한 개념, 구조 및 적합성 요구사항을 규정하는 국제 표준이다.

ISO/IEC/IEEE 42010은 소프트웨어, 시스템, 엔터프라이즈를 비롯한 여러 종류의 대상에 대해 아키텍처 기술서(architecture description, AD)를 작성하고 표현하는 방법의 공통 개념과 요구사항을 규정하는 국제 표준이다. 현행 판은 2022년 11월에 발행된 제2판 ISO/IEC/IEEE 42010:2022, Software, systems and enterprise — Architecture description이다.

이 표준의 직접적인 대상은 아키텍처 자체가 아니라 아키텍처를 표현하는 산출물인 아키텍처 기술서이다. 표준은 아키텍처와 아키텍처 기술서를 구분하고, 아키텍처 기술서가 이해관계자와 관심사, 아키텍처 관점과 뷰, 뷰 구성요소, 대응관계, 아키텍처 결정과 근거 등을 일관된 관계로 나타내도록 요구한다.

항목 내용
표준 번호 ISO/IEC/IEEE 42010:2022
표준명 Software, systems and enterprise — Architecture description
제2판
발행 2022년 11월
표준화 기관 ISO, IEC, IEEE
담당 위원회 ISO/IEC JTC 1/SC 7 및 IEEE Computer Society 관련 표준 위원회
적용 대상 소프트웨어, 시스템, 엔터프라이즈, 시스템군, 제품·서비스, 기술, 사업 영역 등
주요 적합성 대상 아키텍처 기술서, 아키텍처 기술 프레임워크, 아키텍처 기술 언어, 아키텍처 관점, 모델 종류

범위

ISO/IEC/IEEE 42010은 관심 대상(entity of interest, EoI)의 아키텍처를 표현하는 아키텍처 기술서의 구조와 표현에 관한 요구사항을 규정한다. 관심 대상에는 소프트웨어, 시스템, 엔터프라이즈, 시스템 오브 시스템, 시스템군, 제품과 서비스, 제품군, 서비스군, 기술 및 사업 영역 등이 포함될 수 있다.

표준은 다음 대상을 규정한다.

  • 아키텍처 기술서의 개념 구조와 필수 구성
  • 아키텍처 기술 프레임워크(architecture description framework, ADF)
  • 아키텍처 기술 언어(architecture description language, ADL)
  • 아키텍처 관점(architecture viewpoint)
  • 모델 종류(model kind)
  • 이들 대상에 대한 적합성 선언의 기준

반면 다음 사항은 규정하지 않는다.

  • 관심 대상이나 그 환경이 충족해야 할 요구사항
  • 특정한 아키텍처 개발 프로세스나 설계 방법론
  • 특정한 모델, 표기법, 분석 기법 또는 도구
  • 아키텍처 기술서를 기록하는 파일 형식이나 매체
  • 모든 분야에 공통으로 사용해야 하는 고정된 관점 또는 뷰의 목록

따라서 ISO/IEC/IEEE 42010은 특정 개발 방법이나 모델링 언어를 채택하도록 요구하는 표준이 아니다. 문서 중심 방식과 모델 기반 방식 모두에 적용할 수 있는 상위 수준의 개념 체계와 산출물 요구사항을 제공한다.

개념적 기초

아키텍처와 아키텍처 기술서

표준에서 아키텍처는 관심 대상과 그 환경에 관한 근본적인 개념 또는 속성, 그리고 그 대상의 실현과 진화를 지배하는 원칙으로 다루어진다. 아키텍처는 추상적인 개념인 반면, 아키텍처 기술서는 아키텍처를 이해관계자에게 표현하기 위해 만들어진 유형의 작업 산출물이다.

하나의 아키텍처는 하나 이상의 아키텍처 기술서로 표현될 수 있다. 반대로 여러 대안 아키텍처를 각각 별도의 기술서로 표현하여 비교하거나, 서로 다른 목적과 독자를 위해 같은 아키텍처를 여러 기술서로 나누어 나타낼 수도 있다.

이해관계자, 관점과 관심사

이해관계자(stakeholder)는 관심 대상이나 그 아키텍처에 이해관계를 가진 개인, 집단 또는 조직이다. 이해관계자는 관심 대상을 특정한 방식으로 바라보며, 이 사고방식은 이해관계자 시각(stakeholder perspective)으로 표현된다. 이해관계자 시각에서 중요하게 다루어지는 문제가 관심사(concern)이다.

관심사는 기능이나 구조에 한정되지 않는다. 목적, 비용, 일정, 운용, 보안, 안전, 성능, 규제 준수, 유지보수성, 진화 가능성, 환경 영향 등 관심 대상의 생명주기에 영향을 주는 여러 사안이 포함될 수 있다.

2022년 판은 이해관계자 시각측면(aspect)을 명시적인 개념으로 다룬다. 이해관계자 시각은 이해관계자가 관심 대상을 생각하는 방식을 나타내며, 측면은 관심 대상의 성격이나 본질을 구성하는 부분을 나타낸다. 두 개념은 아키텍처를 표현하기 위한 규약인 아키텍처 관점과 구별된다.

뷰와 관점

아키텍처 관점은 하나 이상의 관심사를 다루기 위해 아키텍처 뷰를 생성하고 해석하며 사용하는 데 적용되는 규약의 집합이다. 관점은 어떤 정보를 포함할지, 어떤 모델 종류와 표기법을 사용할지, 뷰를 어떻게 해석하고 분석할지 등을 정한다.

아키텍처 뷰는 특정 관심 대상의 아키텍처를 실제로 표현하는 아키텍처 기술서의 일부이다. 뷰는 관점의 규약에 따라 작성되며, 해당 관점이 프레이밍한 관심사를 다룬다.

관점과 뷰의 관계는 프로그래밍 언어의 타입과 인스턴스 관계와 유사하게 설명되기도 하지만, 표준 자체는 이를 특정 구현 형식으로 제한하지 않는다. 관점은 재사용 가능한 기술 규약이고, 뷰는 특정 관심 대상에 대해 그 규약을 적용한 정보 산출물이다.

뷰 구성요소, 모델 종류와 범례

2022년 판은 2011년 판의 아키텍처 모델 개념을 더 넓은 아키텍처 뷰 구성요소(architecture view component)로 대체하였다. 뷰 구성요소는 하나 이상의 뷰에서 분리 가능한 부분이며, 모델 기반일 수도 있고 모델에 기반하지 않을 수도 있다.

모델 기반 뷰 구성요소는 모델 종류의 규약을 따른다. 모델 종류는 주요 특성과 모델링 규약에 따라 구분되는 모델의 범주이다. 구조 모델, 행위 모델, 정보 모델, 성능 모델, 비용 모델 등이 모델 종류의 예가 될 수 있다.

범례(legend)는 뷰 구성요소에 사용된 기호, 표기 또는 해석 규칙을 설명한다. 모델이 아닌 서술문, 목록, 표와 같은 구성요소도 범례나 설명 규칙을 통해 그 의미를 명확히 할 수 있다.

대응관계

대응관계(correspondence)는 아키텍처 기술서 요소 사이 또는 서로 다른 아키텍처 기술서 사이에 식별된 관계이다. 대응관계는 서로 다른 뷰나 모델에서 같은 개념이 어떻게 연결되는지 나타내고, 중복이나 불일치의 관리에 사용된다.

대응관계 방법(correspondence method)은 대응관계를 설정하고 해석하는 규칙을 제공한다. 예를 들어 논리적 구성요소와 배치 노드의 할당 관계, 요구사항과 이를 실현하는 설계 요소의 추적 관계, 서로 다른 대안 아키텍처 사이의 비교 관계를 정의할 수 있다.

표준은 대응관계의 목적과 구조를 규정하지만, 모든 아키텍처 기술서에 동일한 종류의 대응관계를 사용하도록 요구하지는 않는다. 필요한 대응관계는 적용 분야, 이해관계자 관심사, 사용한 관점과 모델 종류에 따라 달라진다.

아키텍처 결정과 근거

아키텍처 기술서는 중요한 아키텍처 결정과 그 근거(rationale)를 기록할 수 있다. 근거에는 결정의 이유, 고려한 대안, 선택 기준, 절충 사항, 예상 결과 및 관련 자료가 포함될 수 있다.

결정과 근거는 아키텍처 요소가 왜 현재 형태를 갖게 되었는지 설명한다. 이는 특정 시점의 설계 상태만 표현하는 뷰를 보완하고, 이후의 변경·평가·유지보수에서 결정의 배경을 재검토할 수 있게 한다.

주요 개념의 관계

flowchart TD
    E["관심 대상(EoI)"] -->|아키텍처를 가짐| A["아키텍처"]
    AD["아키텍처 기술서(AD)"] -->|표현| A
    AD -->|포함| V["아키텍처 뷰"]
    S["이해관계자"] -->|가짐| C["관심사"]
    P["이해관계자 시각"] -->|관심사를 형성| C
    VP["아키텍처 관점"] -->|프레이밍| C
    VP -->|규약으로 지배| V
    V -->|다룸| C
    V -->|구성됨| VC["뷰 구성요소"]
    MK["모델 종류"] -->|모델 기반 구성요소를 지배| VC

이 관계에서 아키텍처 기술서는 아키텍처를 직접 대체하지 않는다. 기술서는 이해관계자의 관심사를 선택하고, 그 관심사를 다루는 관점과 뷰를 통해 아키텍처에 관한 정보를 표현한다.

아키텍처 기술서의 구성

2022년 판의 규범적 구조는 아키텍처 기술서가 다음 정보를 식별하거나 포함하도록 구성한다.

구성 역할
식별 및 개요 정보 기술서의 대상, 범위, 상태, 버전과 관리 정보를 명확히 한다.
이해관계자 아키텍처에 이해관계를 가진 주체를 식별한다.
이해관계자 시각 이해관계자가 관심 대상을 바라보는 사고방식을 나타낸다.
관심사 아키텍처 기술서가 다루어야 할 중요 사안을 식별한다.
측면 관심 대상의 성격이나 본질을 구성하는 관련 부분을 식별한다.
아키텍처 관점 뷰의 생성·해석·사용에 적용되는 규약을 제공한다.
아키텍처 뷰 관점에 따라 아키텍처를 구체적으로 표현한다.
뷰 구성요소 뷰를 이루는 모델 기반 또는 비모델 기반 정보 부분을 제공한다.
대응관계와 대응관계 방법 기술서 요소와 뷰 사이의 관계 및 일관성 규칙을 나타낸다.
아키텍처 결정과 근거 주요 선택과 그 이유, 대안 및 절충을 기록한다.

이 구성은 특정 문서 목차를 강제하는 것이 아니다. 각 정보는 하나의 문서, 여러 문서, 모델 저장소, 데이터베이스 또는 이들을 조합한 형태로 기록할 수 있다. 표준이 요구하는 것은 매체가 아니라 필요한 정보와 개념 사이의 관계이다.

아키텍처 기술 프레임워크와 언어

아키텍처 기술 프레임워크

아키텍처 기술 프레임워크(ADF)는 특정 적용 분야 또는 이해관계자 공동체에서 아키텍처를 기술하기 위해 확립한 규약, 원칙과 실무를 체계화한 것이다. ADF는 반복적으로 사용할 관점, 모델 종류, 대응관계 방법, 기술 규칙 및 관련 지침을 묶을 수 있다.

2022년 판은 2011년 판의 아키텍처 프레임워크라는 용어를 아키텍처 기술 프레임워크로 변경하였다. 이는 아키텍처 평가 프레임워크와 같이 다른 목적의 프레임워크와 구별하기 위한 것이다.

아키텍처 기술 언어

아키텍처 기술 언어(ADL)는 아키텍처를 표현하기 위한 구문과 의미론, 표현 형식, 규약 및 관련 규칙의 집합이다. ADL은 그래픽 언어, 텍스트 언어 또는 둘을 결합한 형태가 될 수 있다.

표준은 ADL의 예로 AADL, ArchiMate, UML, SysML 및 UAF Profile 등을 제시하지만, 특정 언어의 사용을 의무화하지 않는다. 또한 어떤 언어를 사용했다는 사실만으로 해당 아키텍처 기술서가 자동으로 ISO/IEC/IEEE 42010에 적합해지는 것은 아니다. 기술서가 표준의 개념 관계와 필수 정보를 충족하는지는 별도로 확인해야 한다.

관점과 모델 종류의 재사용

관점과 모델 종류는 특정 기술서 내부에서 정의할 수도 있고, 조직이나 분야의 ADF 또는 ADL에서 가져와 사용할 수도 있다. 외부에서 정의된 규약을 사용할 때도 기술서는 어떤 관점과 모델 종류를 적용했는지 식별하고, 필요한 경우 적용 범위나 수정 사항을 기록해야 한다.

적합성

ISO/IEC/IEEE 42010:2022는 다음 다섯 종류의 대상에 대해 적합성 요구사항을 구분한다.

적합성 대상 적합성의 초점
아키텍처 기술서 이해관계자, 관심사, 관점, 뷰, 구성요소, 대응관계, 결정과 근거 등의 식별과 관계
아키텍처 기술 프레임워크 기술서 작성을 지원하는 관점, 모델 종류, 규약과 실무의 명세
아키텍처 기술 언어 아키텍처 표현에 필요한 구문, 의미론, 표현 및 규칙의 명세
아키텍처 관점 다루는 관심사와 뷰 작성·해석·사용 규약의 명세
모델 종류 모델의 특성, 모델링 규약과 사용 조건의 명세

표준의 적합성은 관심 대상의 아키텍처가 우수한지, 시스템이 목적을 달성하는지 또는 구현이 정확한지를 직접 판정하는 것이 아니다. 표준의 범위는 아키텍처 기술에 사용되는 산출물과 기술 규약의 구조 및 표현이다.

표준은 아키텍처 기술서에 포함할 개별 요소의 완전성이나 정확성을 일괄적으로 보장하지 않는다. 다만 요소 사이의 일관성, 뷰에 표현된 관계, 대응관계 규칙 및 명세의 검증 가능성을 통해 기술서의 완전성과 정확성을 부분적으로 점검할 수 있다고 설명한다.

활용

아키텍처 기술서는 관심 대상의 생명주기 전반에서 사용될 수 있다. 대표적인 활용은 다음과 같다.

  • 이해관계자 사이의 의사소통과 협업
  • 설계와 개발 방향의 전달
  • 아키텍처 분석, 검토와 평가
  • 대안 아키텍처의 비교와 절충 분석
  • 위험 식별과 완화
  • 유지보수와 진화 계획
  • 의사결정과 승인 지원
  • 후속 시스템 또는 소프트웨어 명세의 입력
  • 교육, 훈련 및 조직 지식의 보존
  • 도구와 모델 저장소 사이의 정보 교환 기준 제공

이러한 활용은 표준이 특정 분석법이나 개발 절차를 제공한다는 뜻은 아니다. 분석, 평가 또는 프로세스 수행에는 별도의 방법론이나 관련 표준을 함께 사용할 수 있다.

판본과 역사

ISO/IEC/IEEE 42010의 계보는 소프트웨어 집약적 시스템의 아키텍처 기술을 표준화한 IEEE 1471에서 시작되었다.

연도 판본 주요 내용
2000 IEEE Std 1471-2000 소프트웨어 집약적 시스템의 아키텍처 기술을 위한 권고 실무로 발행되었다.
2007 ISO/IEC 42010:2007 IEEE 1471-2000의 내용을 국제 표준으로 채택하였다.
2011 ISO/IEC/IEEE 42010:2011 ISO, IEC, IEEE 공동 표준으로 개정되었으며 시스템 아키텍처 기술의 개념 모델과 요구사항을 확장하였다.
2022 ISO/IEC/IEEE 42010:2022 적용 범위를 소프트웨어·시스템·엔터프라이즈로 넓히고 개념 및 적합성 대상을 개정한 제2판이다.

2022년 판의 주요 변경

2022년 판은 2011년 판을 기술적으로 개정하여 다음 사항을 반영하였다.

  • 관심 시스템(system of interest)을 관심 대상(entity of interest)으로 변경하여 비시스템 대상에도 적용할 수 있게 하였다.
  • 아키텍처 프레임워크아키텍처 기술 프레임워크로 변경하여 다른 종류의 아키텍처 관련 프레임워크와 구별하였다.
  • 아키텍처 기술서 요소를 식별되거나 이름 붙은 기술서의 부분으로 명시적으로 정의하였다.
  • 이해관계자 시각과 측면을 독립된 개념으로 정의하였다.
  • 서로 다른 아키텍처 기술서 사이에도 대응관계를 설정할 수 있음을 명확히 하였다.
  • 2011년 판의 아키텍처 모델을 더 포괄적인 뷰 구성요소로 대체하였다.
  • 모델 기반 구성요소와 비모델 기반 구성요소를 모두 다룰 수 있게 하였다.
  • 모델 종류를 별도의 적합성 대상으로 추가하였다.
  • 하나의 아키텍처 관점이 하나 이상의 뷰를 지배할 수 있도록 개념을 조정하였다.
  • 개념도 표기를 UML 클래스 다이어그램에서 비형식적 개체-관계 표기로 변경하였다.

관련 표준

ISO/IEC/IEEE 42020

ISO/IEC/IEEE 42020, Architecture processes는 아키텍처의 거버넌스, 관리, 개념화, 평가와 구체화를 위한 프로세스를 다룬다. ISO/IEC/IEEE 42010이 아키텍처 기술서의 구조와 표현을 규정한다면, ISO/IEC/IEEE 42020은 아키텍처 활동을 수행하는 프로세스 측면을 다룬다.

ISO/IEC/IEEE 42030

ISO/IEC/IEEE 42030, Architecture evaluation framework는 아키텍처 평가를 조직하고 기록하기 위한 프레임워크를 규정한다. 평가의 목적에는 이해관계자 관심사의 반영 여부, 목적 적합성, 가치, 위험과 기회 및 의사결정 지원 등이 포함된다.

ISO/IEC/IEEE 15288와 ISO/IEC/IEEE 12207

ISO/IEC/IEEE 15288은 시스템 생명주기 프로세스를, ISO/IEC/IEEE 12207은 소프트웨어 생명주기 프로세스를 규정한다. ISO/IEC/IEEE 42010의 아키텍처 기술서는 이러한 생명주기 프로세스에서 생성되거나 사용되는 정보 산출물로 배치될 수 있다.

용어 구분

용어 의미
아키텍처 관심 대상과 환경에 관한 근본 개념·속성 및 실현·진화 원칙
아키텍처 기술서 아키텍처를 표현하는 유형의 작업 산출물
이해관계자 시각 이해관계자가 관심 대상을 바라보는 사고방식
관심사 이해관계자에게 중요한 사안
아키텍처 관점 뷰를 만들고 해석하고 사용하는 규약
아키텍처 뷰 특정 관심 대상에 관점을 적용해 만든 실제 표현
뷰 구성요소 뷰를 이루는 분리 가능한 정보 부분
모델 종류 주요 특성과 모델링 규약으로 구분되는 모델 범주
ADF 특정 분야나 공동체의 아키텍처 기술 규약과 실무 체계
ADL 아키텍처 표현을 위한 구문·의미론·표현·규칙의 체계
대응관계 기술서 요소 또는 기술서 사이의 식별된 관계
근거 아키텍처 결정의 설명, 정당화와 추론 기록

흔한 오해

표준이 아키텍처 문서의 고정 목차를 제공한다

표준은 필요한 정보와 개념 관계를 규정하지만, 단일한 문서 목차나 템플릿을 의무화하지 않는다. 조직은 요구사항을 충족하는 범위에서 문서, 모델, 저장소 및 기타 매체를 선택할 수 있다.

관점과 뷰는 같은 개념이다

관점은 뷰를 만드는 규약이고, 뷰는 그 규약을 특정 관심 대상에 적용한 결과이다. 같은 관점을 여러 기술서나 여러 뷰에서 재사용할 수 있다.

UML이나 SysML을 사용하면 자동으로 적합하다

모델링 언어는 아키텍처 정보를 표현하는 수단이다. ISO/IEC/IEEE 42010 적합성은 사용한 언어의 이름이 아니라 기술서가 요구된 개념과 관계를 충족하는지에 따라 판단된다.

표준은 좋은 아키텍처를 판정한다

표준은 아키텍처 자체의 품질이나 구현 성공을 직접 보증하지 않는다. 아키텍처 기술서의 구조와 표현, 그리고 이를 지원하는 프레임워크·언어·관점·모델 종류의 요구사항을 다룬다.


참고 자료

  • ISO; IEC; IEEE (2022), ISO/IEC/IEEE 42010:2022, Software, systems and enterprise — Architecture description, 2nd edition.
  • IEEE Standards Association (2022), IEEE/ISO/IEC 42010-2022, International Standard for Software, systems and enterprise — Architecture description.
  • ANSI (2022), Preview of ISO/IEC/IEEE 42010:2022.
  • ISO/IEC/IEEE 42010 Working Group, ISO/IEC/IEEE 42010: Conceptual Model.
  • IEEE (2000), IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems.
  • ISO; IEC (2007), ISO/IEC 42010:2007, Systems and software engineering — Recommended practice for architectural description of software-intensive systems.
  • ISO; IEC; IEEE (2011), ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description.
  • ISO; IEC; IEEE (2019), ISO/IEC/IEEE 42020:2019, Software, systems and enterprise — Architecture processes.
  • ISO; IEC; IEEE (2019), ISO/IEC/IEEE 42030:2019, Software, systems and enterprise — Architecture evaluation framework.