SEBoK: 기능 아키텍처 (Functional Architecture)

 

 

 

1. 기능 아키텍처 개요 (Functional Architecture Overview)

시스템의 기능 아키텍처는 시스템이 외부 또는 내부 소스로부터 입력을 받아 임무 목표 달성을 지원하는 출력을 생성하기 위해 수행하거나 수행할 수 있는 상호 관련된 변환 과정과 목적에 맞는 입력-출력 작업(즉, 기능)들의 집합을 의미합니다. 더 간단히 말해, 기능 아키텍처는 시스템이 특정 목표를 지원하기 위해 수행할 수 있는 다양한 작업과 그 작업들이 서로 어떻게 관련되는지를 정의하여, 이러한 작업들이 결합되어 시스템이 목표를 달성할 수 있는 적절한 역량을 갖추도록 합니다. 내부 입력과 출력(예: 하위 기능들 간에 생성되고 전달되는 것들)의 처리는 기능 아키텍처에 포함됩니다.

 

기능 아키텍처는 변환 기능들과 그 입력/출력에 관련된 시스템을 정의할 뿐, 시스템 설계의 모든 측면을 완전히 정의하는 것은 아닙니다. 따라서 기능 아키텍처는 전체 시스템 아키텍처의 독립적인 하위 단위라기보다는 아키텍처의 “뷰(view)” 또는 “관점(perspective)“으로 간주됩니다. 논리적 아키텍처나 물리적 아키텍처와 같은 다른 시스템 아키텍처 뷰는 특정 시스템의 기능 아키텍처에 대한 제한된 맥락을 제공할 수 있지만, 전체 시스템 아키텍처의 모든 측면을 검토할 필요는 없습니다.

 

기능 아키텍처는 일반적으로 시스템의 특성과 행동을 문서화하거나 정의하는 데 사용될 때 추상적 시스템 모델을 통해 표현됩니다. 시스템의 기능 아키텍처를 캡처하는 것은 시스템 아키텍처 설계 정의의 핵심 부분이며, 일반적으로 시스템 생애 주기의 초기 단계에서 수행됩니다. 기능 아키텍처 모델링은 보통 시스템 개발 작업에 앞서 동시에 수행되지만, 자연 시스템 연구와 같은 경우에는 이미 운영 중인 시스템의 기능 아키텍처를 문서화하는 데 관심을 가질 수도 있습니다. 기능 아키텍처 모델이 개발되면, 이는 이해관계자들에게 시스템의 능력과 행동을 뒷받침하는 과정을 명확히 설명하는 데 유용하며, 시스템 생애 주기 후반에도 검증 및 확인(V&V) 작업이나 시스템 설계 검토 활동을 지원하는 데 사용될 수 있습니다.

 

이 글에서는 기능 아키텍처가 시스템 아키텍처의 다른 측면들과 개념적으로 어떻게 연관되는지 설명하며, 기능 아키텍처 개발과 문서화와 관련된 핵심 원칙들을 논의합니다.

 

2. 기능 아키텍처의 목적 (Purpose of Functional Architecture)

기능 아키텍처의 목적은 이름 그대로 명시되어 있습니다. 즉, 시스템(SoI) 내에서 어떤 기능과 하위 기능이 존재하는지, 그리고 이러한 기능들이 어떻게 연결되거나 상호 관련되는지에 대한 구조적 배치 또는 아키텍처를 정의하는 것입니다. 구체적으로, 이러한 기능 정의에는 시스템의 입력과 출력(주요한 것과 중간적인 것 모두)을 식별하고, 시스템 활동을 해당 입력을 출력 요소나 행동 결과로 변환하는 작업, 또는 보조 시스템 프로세스와의 연관 작업으로 표현하는 것이 포함됩니다(ISO/IEC/IEEE 15288:2023). 기능이라는 개념은 기능 아키텍처의 맥락에서는 수학에서 사용되는 방식(“y는 x의 함수이다”)이나 컴퓨터 프로그래밍에서의 기능에 더 가깝습니다. 이는 시스템 엔지니어링의 다른 측면에서 “기능”이 원하는 결과를 달성하기 위한 일련의 작업을 의미하며, 입력-출력 변환에 직접적으로 연관되지 않는 더 포괄적인 정의를 갖는 것과는 차이가 있습니다(Hitchins 2008).

 

3. 행위 아키텍처와의 관계 (Relation  to the Behavioral Architecture)

기능 아키텍처는 행동 아키텍처와 밀접하게 관련된 개념이지만, “행동”과 “기능”이라는 용어의 유사한 기술적 의미 때문에 쉽게 혼동될 수 있습니다. 기능 아키텍처와 행동 아키텍처는 모두 주어진 시스템이 수행하는 목적 있는 행동과 이러한 행동이 시스템 모드와 모드 전환과 같은 관찰 가능한 특성을 어떻게 생성하는지를 다루지만, 시스템의 작업을 보는 관점에서 차이가 있습니다.

 

기능 아키텍처는 입력-출력 변환에 중점을 둡니다. 즉, 시스템이 자신을 둘러싼 환경, 사용자, 다른 엔터티들로부터 받는 무형 또는 유형의 입력을 출력으로 변환하는 방식에 초점을 맞춥니다. 반면, 행동 아키텍처는 시스템 행동의 순서와 실행에 더 중점을 둡니다. 즉, 시스템 행동이 체크포인트 조건과 상호작용하고, 다른 시스템 작업의 시작/완료와 어떻게 연결되는지를 통해 행동을 생성하는 방식에 관심을 둡니다.

 

4. 기능 아키텍처 적용 (Application in Practice)

전체적인 시스템 아키텍처는 시스템 생애 주기 초기에 정의되는 경우가 많으며, 이는 시스템 개념 정의를 실행 가능한 시스템 설계로 전환하는 데 중요한 역할을 합니다(INCOSE 2023). 기능 아키텍처는 시스템 아키텍처의 여러 “뷰(view)” 중 하나로, 시스템을 고려하는 렌즈를 제공하여 시스템 아키텍처의 핵심 요소가 빠지거나 간과되지 않도록 하고, 기능적 뷰의 범위 밖에서 정의된 시스템 아키텍처의 다른 측면에서 발생한 변화가 시스템의 기능성과 충돌하거나 문제를 일으키지 않도록 보장합니다.

 

완성된 시스템 아키텍처의 기능 아키텍처 뷰는 최소한 다음을 정의해야 합니다:

 

1. 시스템이 임무 목표를 달성하고 이해관계자의 요구를 충족하기 위해 사용하는 기능적 역량,

2. 시스템 기능에 필요한 입력과 출력,

3. 제공된 입력을 원하는 출력으로 변환하는 단계,

4. 하위 기능이 사용될 경우, 해당 단계들을 독립적으로 실행 가능한 하위 기능으로 그룹화하고, 하위 기능에 대한 입력과 출력을 정의,

5. 시스템이 여러 모드를 가질 경우, 각 시스템 모드에 따라 입력, 출력, 기능/하위 기능의 실행 방식의 변화,

6. 각 정의된 기능, 하위 기능, 보조 기능에 대해 입력과 출력 흐름을 가능하게 하는 내부 및 외부 인터페이스.

 

기능 아키텍처는 전체 시스템 아키텍처의 일부 뷰일 뿐이므로, 기능 아키텍처를 다른 아키텍처적 뷰와 함께 고려하는 것이 좋습니다. 논리적 아키텍처, 물리적 아키텍처, 기능 아키텍처는 자주 함께 논의되며(Pineda와 Smith 2010; Borky와 Bradley 2019; Stief et al. 2018), 이는 주어진 시스템 설계에서 시스템 역량이 어떻게 구현되는지를 설명하는 독립적이지만 상호 관련된 관점을 제공합니다(Broy et al. 2009). 이 세 가지를 함께 고려하면 전체 시스템 아키텍처에 대한 비교적 포괄적인 그림을 제공하며, 새로운 시스템 설계 개념을 개발하거나 기존 시스템의 아키텍처를 검토하는 데 중요한 렌즈 역할을 할 수 있습니다. 그림 1은 시스템 설계 모델 내에서 기능 아키텍처의 관점(viewpoint)과 뷰(view)를 보여줍니다.

그림 1. SysML로 표현된 기능 아키텍처 뷰포인트와 뷰 (출처: SEBoK v2.10)

 

5. 기능 아키텍처 모델링 (Functional Architecture Modeling)

시스템의 기능 아키텍처는 추상적인 개념입니다. 따라서 기존 시스템의 기능 아키텍처를 관찰과 테스트를 통해 추론할 수는 있지만(자연 시스템을 분석하거나 문서화할 때처럼), 이는 대개 간단하지 않고 많은 시간이 소요됩니다. 이 때문에 시스템의 기능 아키텍처 모델을 통해 관련 당사자들이 시스템의 기능을 이해하고 상호작용할 수 있는 수단을 제공하는 것이 유용합니다. 하지만, 기능 아키텍처 모델은 시스템의 기능 아키텍처 자체와 동일하지 않다는 점을 유념할 필요가 있습니다. 시스템의 기능 아키텍처는 시스템이 입력을 출력으로 변환하는 방식에 대한 개념적 아이디어를 말하며, 기능 아키텍처 모델은 이 개념을 표현하거나 이해를 전달하는 도구입니다. 모든 모델과 마찬가지로, 기능 아키텍처 모델은 모델링 대상의 모든 세부 사항을 포착하지 않을 수 있습니다. 또한, 시스템 요구 사항 등 시스템 기능성에 영향을 미친 모든 정보를 완전히 알지 못한 상태에서 시스템의 기능 아키텍처를 모델링하려는 경우(자연 시스템이 여기에 해당할 수 있음), 모델이 실제 시스템의 기능 아키텍처와 일치하지 않을 가능성도 있습니다. 따라서 “기능 아키텍처 뷰”와 “기능 아키텍처 모델”이라는 용어는 상호 교환하여 사용해서는 안 됩니다. 전자는 아이디어(전체 시스템 아키텍처의 특정 측면)를 의미하며, 후자는 그 아이디어의 주요 측면을 전달하기 위한 표현 도구로, 불완전하거나 부정확할 수 있습니다.

 

기능 아키텍처를 모델 형태로 표현하는 방법은 여러 가지가 있습니다. 특정 시스템의 기능 아키텍처를 표현하기에 가장 적합한 모델 유형은 시스템과 모델의 사용 범위에 따라 개별적으로 평가하는 것이 좋습니다. 예를 들어, 텍스트 기반 설명 모델은 몇 가지 기능과 입력/출력만을 포함하는 간단한 기능 아키텍처를 가진 시스템에 적합합니다. 이러한 아키텍처는 텍스트로 쉽게 설명할 수 있기 때문입니다. 반면, 조건부 작업이 많거나 상호 연결된 프로세스가 복잡한 경우, 시각적 다이어그램 기반 모델(Youngs et al., 1999)이나 디지털 소프트웨어 모델(Lemazurier, Chapurlat, and Grossetête, 2017; Brinkkemper and Pachidi, 2010)이 텍스트 기반 설명보다 더 선호될 수 있습니다. 이러한 모델은 시스템의 모든 기능성을 정확하게 표현하면서도, 불필요한 노력을 들이지 않고 정보를 추출할 수 있는 방법을 제공합니다(Nowodzienski and Navas, 2023; Younse, Cameron, and Bradley, 2021).

 

모델 기반 시스템 엔지니어링(MBSE) 원칙은 품질 높은 시스템 아키텍처 모델을 개발하는 데 유용하며, 다양한 상황에서 아키텍처 모델링을 수행할 때 이러한 원칙을 적용하는 것이 권장됩니다(Estefan, 2007; Kaslow et al., 2017). 디지털 MBSE 모델을 생성하는 소프트웨어 패키지에는 모델에서 오류를 자동으로 검사하는 도구가 포함되어 있는 경우가 많습니다(예: 잘못 표현된 데이터 흐름), 이는 시스템 기능을 통한 정보 흐름을 모델링할 때 유용할 수 있습니다.

 

통합 모델링 언어(UML), 시스템 모델링 언어(SysML), 또는 기타 표준화된 그래픽 모델링 접근 방식을 사용하는 사람들은 기능 아키텍처와 행동 아키텍처 뷰를 종종 함께 고려하고 평가합니다. 이는 SysML 다이어그램에서 두 아키텍처가 조화롭게 표현되기 때문입니다. 그림 2-5는 SysML 모델의 기능 아키텍처 뷰에서 관련된 몇 가지 다이어그램 유형을 설명하기 위한 예시로 제공됩니다. 여기에는 시스템에 대한 사용 사례 다이어그램(그림 2), 계층적 시스템 기능을 설명하는 블록 정의 다이어그램(그림 3), 개별 시스템 기능을 설명하는 활동 다이어그램(그림 4), **전체 시스템 상태 기계 다이어그램(그림 5)**이 포함됩니다. 이 다이어그램들은 자동차 파워트레인 애플리케이션의 예시 맥락에서 제공됩니다.

그림 2. 자동차 시스템에 대한 SysML로 작성된 Use Case Diagram 예 (출처: SEBoK v2.10)

그림 3. 자동차 시스템에 대한 계층형 구조를 갖는 기능에 대한 SysML로 작성된 블록 다이어그램 예 (출처: SEBoK v2.10)

그림 4. 자동차 시스템에서 차량 가속 제어 기능에 대한 SysML Activity Diagram 예 (출처: SEBoK v2.10)

그림 5. 자동차 시스템에서 SysML 기반 상태 기계 다이어그램 예 (출처: SEBoK v2.10)