SEBoK: 물리 아키텍처 (Physical Architecture)

물리 아키텍처 모델 개발은 “후보 아키텍처 모델 및 뷰 개발” 활동의 작업으로 사용되거나, 시스템 아키텍처 설계 정의 프로세스의 하위 프로세스로 사용될 수 있습니다.

 

물리 아키텍처 개발의 목적은 논리 아키텍처 모델을 수용하고 시스템 요구 사항을 충족시키며 트레이드오프를 조정하는 물리적, 구체적인 솔루션의 모델 및 뷰를 구체화하는 것입니다. 즉, 실제 시스템 실체화를 위해 필요한 사항들을 구체화하여 개발 과정에서 발생하는 여러 의사결정 과정을 통해 이해관계상 대립되는 문제점들을 해결하여, 실질적인 설계를 위한 모델 개발이 궁극적 목적이 됩니다.

 

이전 포스팅에서 정리한 논리 아키텍처 모델이 정의되면 기능적, 행동적, 시간적 특성뿐만 아니라 비기능적 시스템 요구 사항에서 유추된 예상 시스템 속성(예: 노후화 대체 제약 조건, 지속적인 제품 지원)을 지원할 수 있는 구체적인 물리적 요소들을 식별해야 합니다.

 

 

SEBoK: 논리 아키텍처 (Logical Architecture)

물리 아키텍처 모델은 시스템 엘리먼트와 물리 인터페이스와 같은 물리적 요소들을 나열하여, 제품, 서비스 또는 엔터프라이즈에 대한 솔루션을 제공합니다. 이는 논리 아키텍처 요소와 시스템 요구 사항 ISO/IEC/IEEE 26702 (ISO 2007)를 충족시키는 것을 목표로 하며, 기술적 시스템 엘리먼트를 통해 구현됩니다. 이때 시스템 요구 사항은 논리 아키텍처와 물리 아키텍처 모두에 할당됩니다. 

특히 여러 시스템을 공통된 물리 아키텍처 모델로 정의할 때, 물리 아키텍처 모델의 주요 요인 중 하나는 인터페이스 표준화일 수 있습니다. 물리적 인터페이스는 이러한 시스템에서 가장 중요한 고려 사항 중 하나가 될 수 있습니다. 이러한 인터페이스 표준은 시스템 요구 사항에서 반드시 준수해야 할 의무로 정의될 수 있습니다. 반면, 물리 아키텍처 모델 개발 중에 파생될 수도 있으며, 이는 시스템 간의 상호운용성, 개방형 시스템, 기술 도입 등 바람직한 엔지니어링 결과를 달성하는 데 중요한 역할을 할 수 있습니다. 예를 들어, 오늘날의 비디오, 하이파이, 컴퓨터 시스템은 모두 인터페이스 표준을 채택하여 혜택을 받았습니다. 이러한 예는 엔지니어링 분야 전반에서 볼 수 있으며, 나사와 볼트, 배관, 전기 설치, 철도 게이지, TCP/IP, IT 시스템 및 소프트웨어부터 모듈식 방위 및 우주 시스템까지 다양합니다.

1. 물리 아키텍처 개념 및 원칙 (Physical Architecture: Concept and Principles)

1.1 시스템 엘리먼트, 물리적 인터페이스 및 물리 아키텍처 모델

시스템 엘리먼트는 설계 속성을 충족하기 위해 구현될 수 있는 시스템의 개별적인 부분입니다. 시스템 엘리먼트는 하드웨어, 소프트웨어, 데이터, 인간, 프로세스(예: 사용자에게 서비스를 제공하는 프로세스), 절차(예: 운영자 지침), 시설, 재료, 자연 발생 요소(예: 물, 유기체, 광물) 또는 이들의 조합일 수 있습니다(ISO/IEC/IEEE 15288, ISO 2015). 물리적 인터페이스는 두 시스템 엘리먼트를 서로 연결하는 역할을 하며, 이는 링크나 커넥터와 유사합니다. 표 1에서는 시스템 엘리먼트와 물리적 인터페이스의 몇 가지 예를 제공합니다.

표 1 시스템 엘리먼트와 물리적 인터페이스 유형 (출처: SEBoK v2.10)

수천 개의 물리적 및/또는 무형의 부품으로 구성된 복잡한 시스템은 여러 계층의 시스템과 시스템 엘리먼트로 구성될 수 있습니다. 하나의 시스템 구조의 한 레벨에 있는 엘리먼트의 수는 시스템 정의 관리를 용이하게 하기 위해 제한되며, 일반적인 지침으로는 5개 ± 2개의 엘리먼트를 유지합니다(그림 1에 예시 참조).

그림 1. 시스템 계층와 시스템 엘리먼트 (출저: Faisandier 2012, SEBoK v2.10)

물리 아키텍처 모델은 시스템, 시스템 엘리먼트 및 이들 엘리먼트 간의 모든 필요한 물리적 인터페이스, 그리고 외부 엘리먼트(해당 레이어의 이웃 시스템 또는 지원 시스템과/또는 시스템 엘리먼트 및 관심 있는 글로벌 시스템의 문맥 내 관련 엘리먼트)로 구성됩니다(그림 2의 예시 참조).

그림 2. 물리 아키텍처 모델 표현 (출처: Faisandier 2012, SEBoK v2.10)

1.2 물리 아키텍처 설계 속성

설계 속성(Design Property)이란 무엇인가?

설계 속성은 시스템을 설계할 때 얻어지는 특성입니다. 이 속성은 비기능 요구사항을 시스템의 엘리먼트나 물리적 인터페이스와 연결지어서 분석하거나, 계산하고, 시뮬레이션을 통해 만들어집니다. 설계 속성이 요구사항에 맞는다면, 그 속성은 요구사항을 충족한다고 볼 수 있습니다. 하지만 맞지 않는다면, 요구사항이나 설계 속성 중 하나를 수정해야 합니다. 또한, 이 과정에서 생기는 차이를 찾아내는 것이 중요합니다.

 

이해관계자의 관심

이해관계자들은 시스템이 특정 환경, 조건 속에서 어떻게 작동하는지, 그리고 시스템의 전체 수명 동안 어떤 제약을 받을지에 관심을 가집니다. 이들의 요구는 시스템이 가져야 할 기능이나 성능으로 나타납니다. 예를 들어, 사용성, 보안성, 확장성 같은 특성들이 이에 포함됩니다.

 

설계자의 역할

설계자나 아키텍트는 요구사항에서 이런 필요한 기능을 찾아내고, 물리적인 구조(아키텍처)를 설계할 때 이를 고려합니다. 이때 도출되는 설계 속성에는 신뢰성, 유지보수성, 모듈성, 운용성, 그리고 크기 같은 것들이 포함됩니다. 이러한 속성들이 시스템의 실제 설계에 어떻게 반영되는지에 대한 자세한 논의는 시스템 공학과 품질 속성 관련 글에서 확인할 수 있습니다.

1.3 논리적 엘리먼트를 물리적 엘리먼트로 할당 및 분할

논리적 엘리먼트를 물리적 엘리먼트에 배치하고 나누기

시스템의 물리적 구조(물리 아키텍처)를 만들려면 먼저 논리 아키텍처에서 정의된 기능을 수행할 수 있는 시스템 엘리먼트를 찾아야 합니다. 논리 아키텍처는 시스템의 기능이나 작동 방식을 추상적으로 표현한 것이고, 물리 아키텍처는 이를 실제로 구현하는 것입니다. 또한, 입력-출력 흐름이나 제어 흐름을 처리할 수 있는 인터페이스도 찾아야 합니다. 여기서 중요한 점은 시스템 요구사항에 따라 설계 속성을 논리 아키텍처에 배치하는 것입니다.

 

분할과 배치 작업

분할(partitioning)은 기능을 쪼개고 모아서 더 쉽게 시스템 엘리먼트를 찾아낼 수 있도록 하는 작업입니다. 이때 배치(allocation)는 이렇게 나눈 기능을 적절한 시스템 엘리먼트에 할당하는 과정을 의미합니다. 즉, 필요한 기능을 제공할 수 있는 기존 엘리먼트가 있는지 찾거나, 새롭게 개발해야 하는지를 결정하는 과정입니다.

 

배치와 분할의 기준

시스템 엔지니어는 시스템 요구사항이나 설계 속성을 기준으로 기능을 배치하고 분할할 수 있는 엘리먼트를 찾습니다. 예를 들어, 비슷한 기술로 변환되는 기능, 비슷한 효율성을 갖는 기능, 같은 유형의 입력-출력 흐름(정보, 에너지, 물질)을 교환하는 기능 등을 기준으로 시스템 엘리먼트를 선택합니다. 또한, 중앙 집중식 제어, 분산 제어, 환경 저항성, 시스템 신뢰성 같은 조건들도 고려해야 합니다.

 

동시공학 접근 방식

물리 아키텍처 모델을 만들 때는 여러 기술과 지식을 동시에 사용해야 하는 경우가 많습니다. 특히, 기능을 여러 시스템 엘리먼트에 나누어 배치할 때는 호환성 문제나 새롭게 발생하는 특성들을 고려해야 합니다.

1.4 후보 물리 아키텍처 모델 개발

물리 아키텍처 모델 개발의 목표

물리 아키텍처 모델을 개발하는 목표는 시스템 요구사항을 가장 잘 충족하는 물리적 구조를 만드는 것입니다. 이를 위해 여러 후보 모델을 만들고, 그 중에서 가장 적합한 모델을 선택합니다. 즉, 여러 가능성을 시도해 보고, 가장 좋은 모델을 고르는 과정이라고 할 수 있습니다.

 

후보 물리 아키텍처 모델의 구성

후보 물리 아키텍처 모델은 시스템 엘리먼트와 물리적 인터페이스의 연결망을 구성합니다. 예를 들어, 시스템 엘리먼트를 어떻게 나누고, 모으고, 연결하고, 끊을지 결정하는 것이죠. 이 과정에서 사용되는 기준은 앞서 설명한 **분할(partitioning)**과 **배치(allocation)**의 기준과 같습니다.

 

물리 아키텍처 모델 개발 시 고려할 요소들

물리 아키텍처를 개발할 때는 다양한 측면을 고려할 수 있습니다. 예를 들어:

• 물리적 인터페이스의 수를 줄이는 것: 시스템 간의 연결점을 최소화해서 복잡성을 줄이는 것이 목표입니다.
• 개별적으로 테스트할 수 있는 시스템 엘리먼트: 각 엘리먼트가 따로 테스트될 수 있는지 고려합니다.
• 호환 가능한 기술: 모든 엘리먼트들이 기술적으로 잘 맞아야 합니다.
• 공간적으로 가까운 엘리먼트들: 엘리먼트들 간의 거리를 최소화해서 효율성을 높입니다.
• 취급 용이성: 무게나 부피가 다루기 쉽고, 운송이 용이한지 고려합니다.
• 자원의 최적화: 여러 엘리먼트가 자원을 효율적으로 공유할 수 있는지를 생각합니다.
• 모듈성: 엘리먼트 간의 상호 의존성을 줄여서 더 쉽게 교체하거나 업그레이드할 수 있도록 합니다.
• 회복력: 엘리먼트가 얼마나 신뢰성이 있고, 유지보수가 가능한지, 또는 교체가 용이한지를 평가합니다.

이 과정을 통해 최적의 물리 아키텍처 모델을 선택하게 됩니다.

1.5 후보 물리 아키텍처 평가 및 최종 선택

후보 물리 아키텍처 모델의 역할

후보 물리 아키텍처 모델은 논리 아키텍처에서 요구된 기능을 실제로 구현할 수 있도록 해줍니다. 하지만 설계 작업에서는 단순히 기능만 구현하는 것이 아니라, 설계 속성, 비용, 위험 등을 균형 있게 맞추는 것이 중요합니다.

 

비기능 요구사항이 중요한 이유

시스템 설계는 주로 비기능 요구사항에 의해 결정됩니다. 비기능 요구사항이란 성능, 안전성, 보안성, 환경 조건 같은 기능 외적인 요소들을 말합니다. 기능은 여러 가지 방법으로 구현할 수 있지만, 비기능 요구사항을 충족시키는 방법은 더 적기 때문에, 이 부분이 설계를 결정짓는 중요한 요소가 됩니다.

 

최적의 물리 아키텍처 모델 선택

최적의 물리 아키텍처 모델은 시스템 엘리먼트, 그 요소들 간의 물리적 관계, 그리고 인터페이스를 고려하여 선택됩니다. 이 모델은 시스템이 완전히 최적화되기 전의 상태일 수 있으며, 이후에 남은 트레이드 오프(상충하는 요구사항 간의 선택)를 처리하고, 시스템의 알고리즘이나 매개변수가 완전히 정해져야 합니다.

 

시스템 분석과 평가

시스템 설계의 최종 선택을 위해서는 여러 가지 분석이 필요합니다. 예를 들어, 효율성, 신뢰성, 비용, 위험 등을 분석하여 후보 모델이 시스템 요구사항을 얼마나 잘 충족하는지를 평가합니다. 이 과정은 시스템 분석이라고도 불립니다. 그리고 각 기술 영역(예: 기계공학, 전자공학, 소프트웨어, 안전성, 보안성)에서의 전문 지식이 필요하기 때문에, 다양한 전문가들이 각 분야에서 추가적인 분석을 수행하게 됩니다.

1.6 레거시 시스템과 시스템의 시스템(SoS: System of Systems)

레거시 시스템과 상호작용

대부분의 시스템은 다른 시스템과 연결되어 작동하게 됩니다. 이런 상호작용은 기존에 이미 사용 중인 시스템(레거시 시스템)이거나, 앞으로 그 시스템과 함께 사용될 예정인 시스템과 일어날 수 있습니다. 예를 들어, 자동차 시스템은 차량 내 다양한 다른 시스템들과 상호작용하거나, 정비 시스템과도 연결되어 작동합니다.

 

상호작용의 강도에 따른 설계 방식

시스템과 주변 시스템 간의 상호작용이 얼마나 강한지에 따라 설계 접근 방식이 달라집니다. 상호작용이 약하다면, 기술 표준과 같은 외부 인터페이스 요구사항을 정의하고 시스템 요구사항에 이 조건들을 반영하는 방식으로 처리할 수 있습니다. 하지만 상호작용이 강하고, 지속적으로 다른 시스템과 정보를 교환해야 하는 경우라면, 이를 시스템의 집합(SoS)으로 고려해야 합니다. 이는 더 복잡한 시스템 설계 접근 방식을 필요로 합니다.

 

기술 공유와 시스템 엘리먼트 재사용

시스템 설계에서 종종 다른 시스템과 기술을 공유하거나, 기존 레거시 시스템에서 사용하던 요소들을 재사용할 수 있습니다. 예를 들어, 자동차나 항공 산업에서는 동일한 기술이나 시스템 엘리먼트를 여러 모델에 걸쳐 재사용하는 경우가 많습니다. 이런 경우에는 상위에서부터 설계를 시작하거나, 중간 수준에서부터 요소들을 설계해 나가며 시스템이 요구사항을 충족하도록 조정합니다.

 

시스템의 집합(SoS)에서 사용하는 시스템 설계

만약 한 시스템이 여러 다른 시스템과 상호작용하거나 서비스 시스템의 일부로 사용될 예정이라면, 물리 아키텍처 설계가 그에 맞게 영향을 받습니다. 이런 시스템들은 다양한 다른 시스템과 연결 가능한 인터페이스를 가지고 있어야 하고, 시스템의 기능이 다른 시스템과 상호작용할 수 있도록 명확하게 정의되어 있어야 합니다.

 

시스템의 집합(SoS)의 물리 아키텍처 모델

SoS나 서비스 시스템의 상호작용을 다룰 때는 고수준의 물리 아키텍처 모델을 정의하게 됩니다. 이 모델은 시스템 간의 관계, 인터페이스, 제약 조건 등을 정의하며, 이를 기반으로 시스템 요구사항과 이해관계자의 요구를 처리합니다. 개발, 실현, 운영 과정에서도 프로젝트 간 커뮤니케이션을 통해 이 인터페이스와 요구사항을 관리해야 합니다.

2. 물리 아키텍처의 프로세스 접근법 (Physical Architecture: Process Approach)

2.1 목적

물리 아키텍처 모델 개발의 목표는 시스템이 제대로 작동할 수 있도록 논리 아키텍처 모델을 지원하는 물리적 구조를 정의하고 선택하는 것입니다. 이 모델은 시스템이 작동하는 환경적 문제나 이해관계자의 요구를 반영하고, 시스템 요구사항을 충족할 수 있는 속성을 가져야 합니다.

 

시스템의 진화

시간이 지남에 따라 시스템이 사용하는 기술이나 사용 환경이 변화할 수 있습니다. 이러한 변화에 따라 물리 아키텍처는 변화할 수 있어야 하며, 시스템이 계속해서 그 목적을 달성하도록 시스템 엘리먼트가 진화하는 과정을 거쳐야 합니다. 이때 변화가 논리 아키텍처 모델에 영향을 미치면, 시스템 엘리먼트에 할당된 기능도 변경될 수 있습니다. 즉, 시스템이 변함에 따라 설계도 계속해서 업데이트되어야 한다는 뜻입니다.

 

물리 아키텍처 모델의 설계 속성

물리 아키텍처 모델은 계속 변화하는 환경에 대응하기 위한 특정 설계 속성을 갖추고 있어야 합니다. 이러한 속성들은 시스템이 변화하는 상황 속에서도 계속해서 효율적으로 작동할 수 있도록 도와줍니다.

• 입력: 물리 아키텍처 모델을 개발할 때는 논리 아키텍처 모델, 시스템 요구사항, 설계자가 정의한 패턴과 속성, 그리고 시스템 분석 결과와 시스템 검증 및 확인에서 얻은 피드백을 참고합니다.
• 출력: 이 과정에서 최종적으로 선택된 물리 아키텍처 모델, 기능 요소와 물리적 요소의 할당 매트릭스, 시스템 요구사항과의 추적 매트릭스, 그리고 거부된 설계 솔루션 등이 도출됩니다.

한마디로 말해, 물리 아키텍처 모델은 시스템이 환경 변화에 대응하고, 이해관계자의 요구를 충족시키며, 시스템이 계속해서 제대로 작동할 수 있도록 설계된 물리적 구조라고 할 수 있습니다.

 

2.2 프로세스 활동

물리 아키텍처 모델 설계단계에서 수행해야 할 주요 활동과 작업은 다음과 같습니다:

단계	주요 활동
1. 기능 요소의 분할과 할당	• 시스템 엘리먼트나 기술 탐색: 시스템이 요구하는 기능을 수행할 수 있는 시스템 엘리먼트(기술이나 장비)를 찾고, 입력-출력 및 제어 흐름을 처리할 수 있는 물리적 인터페이스를 찾아야 합니다. 여기서 시스템 엘리먼트가 이미 존재하는지, 또는 새로 개발할 수 있는지를 평가합니다. 이 과정에서는 설계 속성(주로 비기능 요구사항에서 추출된)을 기준으로 잠재적인 시스템 엘리먼트들을 평가합니다. • 기능 요소 분할: 기능(작업, 시나리오, 입력-출력, 트리거 등)을 분할하고, 분할된 기능들을 시스템 엘리먼트에 할당합니다. 이는 동일한 기준으로 수행됩니다. • 분할된 기능과 맞는 시스템 엘리먼트가 없을 경우: 만약 분할된 기능에 맞는 시스템 엘리먼트를 찾을 수 없다면, 해당 기능을 더 작은 단위로 나누어 구현할 수 있는 시스템 엘리먼트를 찾아냅니다. • 기술 및 인터페이스의 호환성 확인: 선택된 시스템 엘리먼트들 간의 기술적 호환성과 인터페이스 호환성을 반드시 확인해야 합니다.
2. 후보 물리 아키텍처 모델 구성	• 시스템 엘리먼트 그룹화: 분할된 기능이 많아지면, 시스템 엘리먼트들도 많아지기 때문에 이를 더 큰 시스템 엘리먼트 그룹으로 묶습니다. 이를 서브시스템이라고 부르기도 합니다. • 여러 시스템 엘리먼트 그룹 구성: 서로 다른 조합으로 시스템 엘리먼트 그룹을 여러 개 구성하고, 각 그룹이 물리 아키텍처 모델을 형성하게 됩니다. • 물리 아키텍처 모델 표현: 각 시스템 엘리먼트 그룹을 물리적 인터페이스(입력-출력 흐름과 트리거를 처리하는 연결)로 연결해 물리 아키텍처 모델을 그림이나 도표로 표현합니다. 필요시, 외부 요소와의 인터페이스도 추가합니다. • 물리 아키텍처 개선: 모듈성, 확장성, 환경 적응성, 내구성 등과 같은 설계 속성으로 아키텍처를 개선합니다. 가능하다면, 하드웨어-소프트웨어(HW-SW) 시뮬레이션 프로토타입 등을 활용해 잠재적인 문제를 발견하고 수정합니다.
3. 후보 물리 아키텍처 모델 평가/선택	• 시스템 분석 수행: 시스템 분석을 통해 후보 모델을 평가합니다. 시스템 요구사항을 얼마나 잘 충족하는지, 비용이나 효율성, 위험 등을 종합적으로 분석합니다. • 결정 관리: 최종 선택을 돕기 위해 결정 관리 프로세스를 사용해 여러 후보 중에서 가장 적합한 모델을 선택합니다.
4. 선택된 물리 아키텍처 모델의 통합	• 물리적 요소 및 속성 공식화: 선택된 물리 아키텍처 모델의 물리적 요소와 속성을 구체적으로 정의하고, 시스템 요구사항을 충족시키는지 확인합니다. • 새로 생성된 요소 식별: 설계 과정에서 새롭게 도출된 물리적 요소와 기능 요소를 식별하고, 그에 맞는 시스템 요구사항을 정의합니다. • 추적 가능성 확보: 시스템 요구사항과 물리적 요소 간의 연관성을 추적하고, 기능 요소와 물리적 요소 간의 할당 매트릭스를 설정합니다.

 

 

2. 3 아티팩트, 방법 및 모델링 기법

물리 아키텍처 설명은 물리 아키텍처를 생성하고 표현하기 위해 다양한 모델링 기법을 사용합니다. 일반적인 물리적 모델로는 구조적 블록, 질량, 레이아웃 등 여러 모델이 있습니다. 사용될 수 있는 모델링 기법에는 다음과 같은 것들이 포함됩니다:

•  물리적 블록 다이어그램(PBD)
• SysML 블록 정의 다이어그램(BDD)
• 내부 블록 다이어그램(IBD) (OMG 2010)
• 실행 가능한 아키텍처 프로토타이핑
• 기타

사용 도메인(방위, 기업 등)에 따라, 아키텍처 프레임워크는 후보 아키텍처 간의 트레이드오프를 지원하는 설명을 제공할 수 있습니다. 

 

2.4 실무적 고려 사항

물리 아키텍처 모델 개발에서 자주 발생하는 주요 문제점은 다음과 같습니다.

 

(1) 하나의 시스템 블록에 너무 많은 수준의 분해

• 문제점: 시스템 블록이 너무 많은 레벨로 분해되어 있어 복잡해지는 경우가 있습니다. 이렇게 되면 전체 구조가 너무 세밀해져 관리하기 어려워집니다.
• 대책: 물리 아키텍처 모델에서는 시스템 블록이 하나의 레벨로 구성되어야 합니다. 즉, 너무 깊게 분해하지 말고, 적절한 수준에서 관리할 수 있는 하나의 레벨로 유지하는 것이 좋습니다.

(2)논리 아키텍처 모델 없이 바로 기술에 할당

• 문제점: 시스템 요구사항에서 곧바로 물리 아키텍처로 넘어가서 논리 아키텍처 모델을 설정하지 않는 경우가 있습니다. 특히, 이미 잘 알고 있는 반복적인 시스템이나 제품을 개발할 때 이 실수를 자주 합니다. 문제는 기능이 항상 특정 입력-출력 흐름과 연결된다는 것입니다. 만약 해당 기능이 사용되는 환경이 바뀌면, 그 기능의 성능도 유효하지 않게 될 수 있습니다.
• 대책: 논리 아키텍처를 먼저 설계하고, 그다음에 물리 아키텍처로 넘어가야 합니다. 시스템이 다양한 기술로 나뉘기 전에 논리 아키텍처와 물리 아키텍처를 교차하면서 적절한 수준으로 분해하는 것이 중요합니다. 마지막 단계에서 하드웨어나 소프트웨어 같은 기술적인 요소로 기능을 할당하는 것이 바람직합니다.

또한 물리 아키텍처 개발에서 효과적인 실천 방법에 대해서는 다음과 같습니다.

 

(1) 모듈성 (Modularity)

• 설명: 시스템 엘리먼트들 간의 상호작용을 줄이고, 시스템 설계를 할 때 모듈성 원칙을 따르는 것이 중요합니다. 모듈성이란 시스템 내부 요소들은 일관성을 유지하면서, 외부와 연결되는 물리적 인터페이스는 최소화하는 설계 방식을 말합니다. 이렇게 하면 시스템을 더 쉽게 관리할 수 있고, 유지보수나 확장이 용이해집니다.
• 핵심 포인트: 시스템 내부의 일관성을 최대화하고, 외부와의 물리적 연결은 최소화하여 시스템을 설계하는 것이 바람직합니다.

(2) 인터페이스에 집중 (Focus on Interfaces)

• 설명: 시스템 엘리먼트들 자체보다는 인터페이스에 집중하는 것이 효과적인 설계 방법입니다. 시스템 엘리먼트들은 각기 다른 부분들이지만, 이들이 어떻게 연결되고 상호작용하는지(즉, 인터페이스)가 전체 시스템의 성공적인 설계에 큰 영향을 미칩니다. 특히 시스템의 추상적 수준에서 인터페이스에 집중하는 것이 중요합니다.
• 핵심 포인트: 시스템 엘리먼트보다는 그 요소들 간의 인터페이스에 초점을 맞추어 설계하는 것이 성공적인 시스템 아키텍처의 핵심입니다.