미 국방부는 새로운 체계의 획득을 지원하기 위해 아키텍처를 활용할 방침을 수립하였다.1) 그 일환으로 미 국방부는 DoDAF에 제시된 원칙과 지침에 따라 아키텍처 산출물을 작성하도록 지시했다.2) 아키텍처 산출물은 새로운 체계가 임무수행능력에 기여하는 정도를 평가하여 효과적인 소요를 설정하고, 이를 통해 전력투자의 효율성을 향상시키고자 하는 데 주요 목적이 있다.

우리 국방부와 합동참모본부(이하 ‘합참’이라 함)도 2006년부터 4년간에 걸쳐 자원관리와 전장 분야에 대해 각각 아키텍처 산출물을 작성하였다. 특히, 전장아키텍처 산출물은 우리 군의 전장(작전) 수행능력 분석을 통한 현행 및 목표 상태의 능력차이 식별, 전투발전요소의 대안 수립, 상호운용성 및 체계성능 평가를 통한 대안 선정 등을 목적으로 작성되었다. 그러나 아키텍처 산출물은 운용활동과 체계기능이 어떤 정보를 이용하고, 어떤 정보를 산출하는가를 나타낼 뿐이다. 아키텍처는 운용활동과 체계기능의 순차적 또는 동시적 흐름, 정보를 이용하고 산출하는 규칙과 조건, 이에 사용된 자원(인력 또는 물자)에 대한 세부 사항이 없는 정적인 표현만을 하고 있다. 따라서 아키텍처 산출물로는 운용활동이나 체계기능이 어떻게 상호 작용하는지에 대한 동적인 분석을 수행할 수가 없다.

이러한 아키텍처 산출물의 정적인 한계를 극복하여 동적인 분석을 수행하려면, 운용활동, 정보, 자원 등에 대해 모델링을 하고, 이를 시뮬레이션으로 변환하여 실행할 수 있어야 한다. 즉, 아키텍처 산출물에 대한 모델링과 시뮬레이션(M&S)이 요구되는데, 이를 통해 산출된 결과가 실행아키텍처(xA)이다. 실행아키텍처는 아키텍처 산출물의 원래 목적을 달성하는 것뿐만 아니라 다양한 임무시나리오, 운용개념 등을 체계적으로 분석하는 것을 지원할 수 있다.

실행아키텍처는 신규 무기체계의 획득이나 기존 무기체계의 성능개량에 적용할 수 있다. 과거에는 신규 무기체계 자체의 성능이나 운용개념만을 검토하였다. 그러나 현대전의 대표적인 특징으로 참조되고 있는 네트워크중심전(NCW) 개념하에서는 신규 무기체계가 다른 무기체계와 통합하여 복합체계(SoS)의 개념으로 합동임무를 수행하게 될 것이므로, 신규 무기체계가 참여하는 합동임무의 수행능력이 얼마나 향상되는가를 검토해야 한다. 이는 아키텍처 기반의 M&S, 즉 실행아키텍처를 통해 가능하게 될 것이다. 실행아키텍처는 신규 무기체계의 성능을 조정하였을 경우 임무능력의 향상 정도와 소요 비용을 분석하고, 그 결과 비용효과적인 ROC를 설정하는 데 도움이 될 것이다. 또한, 다양한 운용개념을 적용하여 임무능력의 향상 정도를 분석함으로써 신규 무기체계의 운용개념을 재정립하는 데에도 도움이 될 것이다.

미래에 또 다른 신규 무기체계를 획득할 경우에도 기존 실행아키텍처를 재사용하여 위와 같은 과정을 반복함으로써 분석 노력을 경감할 수 있을 뿐만 아니라 기존의 방법론과 동일한 방법으로 임무수행 능력의 향상 정도를 판단함으로써 분석의 일관성도 기할 수 있다. 무기체계의 성능개량도 신규 획득의 경우와 동일한 과정을 통해 분석할 수 있다.

실행아키텍처에 대한 연구는 미 국방부를 비롯하여 미국의 연구기관이나 기업체에서 활발하게 진행되고 있다. 그렇지만 우리 국방부와 합참은 아키텍처 산출물을 구축한 이후 일부 임무에 대해서만 체계공학(SE) 도구인 CORE의 제한된 기능을 활용하여 매우 제한된 분석결과를 도출할 수 있는 수준이다.3) 그 결과 우리 군의 일각에서는 아키텍처는 물론 실행아키텍처에 대한 무용론까지 대두되고 있는 실정이다. 우리 군도 이제 미국의 실행아키텍처의 개념과 방법론을 참고로 하여, 아키텍처를 적극 활용하는 방법을 모색하고 그 결과를 적용해야 할 시점에 와 있다.

참고문헌에서 다양하게 제시된 아키텍처 활용방법은 크게 실행모델 기반 분석방법과 논리적 모델 기반 분석방법의 2가지로 구분된다. 논리적 모델 기반 분석은 수학적 분석, 체계공학 도구 적용, 전투 모델(combat model) 활용의 3가지 형태가 있다. 논리적 모델 기반 분석은 이와 같이 실행모델에 기반을 두지 않으므로, 본고에서는 다루지 않는다.

본고에서는 먼저, 참고문헌에서 다양하게 제시된 아키텍처에 관련된 용어와 실행모델 기반 분석방법에서 핵심적 역할을 수행하는 분석모델의 종류를 종합적으로 검토하여, 용어와 방법론에 대한 개념을 정립한다. 이를 바탕으로 아키텍처의 동적 모델링 결과인 실행모델이 왜 필요한지를 살펴보고, 아울러 그 역할을 제시한다. 이를 바탕으로 아키텍처의 M&S 결과인 실행아키텍처로의 변환기법과 구현방법을 제시한다. 마지막으로 이러한 방법을 적용하여 우리 군이 미군과 유사한 형태의 실행아키텍처를 구축하기 위한 방안을 제시한다.

1)Deputy Secretary of Defense Memorandum(OSD 03246-04), “Information Technology Portfolio Management,” (2004. 3.). 체계의 범주에는 기동, 화력, 항공, C4I, 통신 등의 무기체계와 비무기체계에 속하는 정보체계가 포함됨  2)미 국방부의 DoDAF는 C4ISRAF를 대체한 것이다.  3)CORE는 미국 Vitech사에서 개발하였으며, 요구사항 분석부터 검증 및 확인까지의 전 과정을 지원하는 모델기반 시스템엔지니어링 방법론을 기반으로 하는 체계공학 도구이다.

문헌 조사에 따르면 아키텍처, 모델, 시뮬레이션이 통합아키텍처(iA), 실행아키텍처, 정적 모델, 동적 모델, 실행 모델, 실행시뮬레이션 등과 같이 다양한 형태의 혼합된 용어로 언급되고 있다. <그림 1>은 아키텍처 관련 용어의 혼재된 관계를 보여주고 있다. 또한, 분석모델도 CPN 모델, BPM, UML 모델, SysML 모델, IDEFx 모델, 수학적 분석모델 등으로 다양하게 제시되어 있다. 어떤 경우에는 이러한 모델이 전투 모델이나 네트워크 모델과 연동되기도 한다.

Ring, Nicholson & Harris(2006)에 따르면 실행아키텍처는 정보의 생성 및 활용을 목적으로 자원(인력, 물자)을 사용하여, 운용노드에서 수행되는 (조직 내)직무(역할)의 운용활동들과 그에 관련된 일련의 사건(event)들에 대한 동적 모델로 정의된다.4) 이러한 정의는 아키텍처에 대한 다양한 용어나 분석모델이 상호 어떻게 연관되는지를 명확히 함으로써 보다 확실하게 될 것이다. 그러면 실행아키텍처의 구현방법도 분석모델을 어떻게 적용해야 하는가를 통해 정립할 수 있을 것이다.

<그림 2>의 윗부분은 원 체계(source system), 모델링을 통해 수립된 모델, 모델을 운영 가능한 형태로 변환한 시뮬레이터의 3가지 엔티티(entity)의 관계를 제시하고 있다. 이는 Zeigler, Praehofer와 Kim(2000) 등이 제안한 M&S 프레임워크이며, 이를 아키텍처에도 적용할 수 있을 것이다.

<그림 2>의 아래 부분은 이러한 결과를 도시한 것이다. 엔티티는 통합아키텍처(iA), 중간아키텍처(mA), 실행모델(xM)과 실행모델 시뮬레이션(xS)이다. 엔티티는 모델링 관계(M_R), 동적 관계(D_R)와 시뮬레이션 관계(S_R)로 연결된다. 여기서 관계(relation)는 수학적인 개념으로서, 두 객체 간의 연관성을 명확히 정의한 함수의 개념보다 더 넓은 개념이다. 여기서는 관계가 엔티티의 변환기법에 해당한다.

<그림 2>는 통합아키텍처가 M_R을 통해 중간아키텍처로 우선 변환되는 것을 나타내고 있다. 그 다음 중간아키텍처는 D_R을 통해 실행모델로 변환된다.

통합아키텍처를 바로 실행모델로 변환하는 것이 어려우므로 일단 중간아키텍처로 변환하는 것이다. 정적인 모델에 해당하는 중간아키텍처는 동적 개념에 필요한 사항을 추가하여 동적인 형태인 실행모델로 변환된다.

실행모델은 분석목적에 맞게 S_R을 통해 시뮬레이션 프로그램으로 변환･운영된다. 따라서 실행아키텍처는 통합아키텍처에 대한 M&S 결과로서 실행모델과 시뮬레이션을 총칭하는 개념이라 할 수 있다. 엔티티의 관계를 식으로 나타내면 다음과 같다.

4)a dynamic model of Activities and their event sequencing performed at an Operational Node by Roles (within Organizations) using Resources (Systems) to produce and consume Information

실행모델은 실행아키텍처에서 중심적인 역할을 한다. 일단 실행모델이 수립되면, 시뮬레이션 프로그램으로 변환하는 것은 정해진 S_R을 통해 수행하기만 하면 되고, 이는 비교적 용이한 일이기 때문이다. 본 절에서는 이러한 실행모델이 왜 필요한지, 즉 아키텍처를 왜 실행모델로 변환해야 하는가를 정책적인 관점과 기술적인 관점에서 살펴보고자 한다.

NCW는 플랫폼 중심의 아키텍처로부터 네트워크 중심의 아키텍처로의 변화를 요구한다. 각 플랫폼은 센서, 프로세서, 타격무기를 모두 또는 그중 일부를 장착한다. 플랫폼 중심 작전은 분할된 전장공간(sectored battlespace)에 대해 각 자의 플랫폼을 운용하여 적 위협에 대응하는데, 이를 도식적으로 나타내면<그림 3>의 왼쪽 그림과 같다(Dickerson & Mavris, 2009, p. 239). <그림 3>의 오른쪽 그림은 플랫폼들이 네트워크를 통해 통합하여 적 위협에 대응하는 NCW의 기본개념을 보여주고 있다. 플랫폼들은 상호 간의 협조를 통해 적 위협에 대응함으로써 임무수행 효과가 향상될 것이다. 플랫폼들의 다양한 센서에서 수집된 데이터를 실시간으로 융합함으로써 전장정보를 공유하는 것이 NCW에서 적 위협에 대응하는 기본개념이 된다.

M&S 기반 획득관리에 해당하는 SBA는 기본적으로 체계공학(SE)을 배경으로 하고 있다. SBA에서 적용하는 체계공학의 목적은 획득 전 과정에 걸쳐 M&S와 관련 정보를 협력적, 통합적으로 활용함으로써 성능은 우수하게, 개발기간은 짧게, 획득비용은 최소화하는 데 있다(최상영, 2007, p. 7). 특히, 소요기획 단계에서는 합동실험/전투실험 과정에서 M&S를 통해 미래 전력소요에 대한 분석, 체계개념 분석, 획득대안 분석과 ROC 분석을 수행한다. 최종적으로 설정된 ROC는 체계설계에 반영된다. 이때 사용되는 M&S 도구로는 전역모델, 임무/전투 모델, 교전모델, 공학모델과 비용추정모델 등이 있다.

그렇지만 다양하게 많은 플랫폼 또는 체계가 네트워크를 통해 끊김 없이 통합되어야만 요구하는 능력을 발휘할 수 있는 SoS는 고전적인 플랫폼 중심의 체계공학에 의해서는 그 복잡한 개념을 효과적으로 평가할 수 없게 되었다. 아키텍처 중심의 체계공학은 네트워크 중심의 SoS 개념을 정의하고 상호운용성을 통해 달성 가능한 능력을 평가하기 위해 등장하였다(Rodriguez, 2005).

이러한 아키텍처 중심의 체계공학 프로세스를 수정된 V-모델로 나타내면 <그림 4>와 같다.5) V-모델의 왼쪽 하향부분은 시나리오와 운용개념에 의한 정적인 모델과 동적인 모델(실행모델)을 작성하고, 이를 기반으로 실행 가능한 시뮬레이션을 통해 실험(experimentation)을 수행하는 것이다. 실험을 통하여 새로운 체계가 기존 체계와의 맥락에서 성능(measure), 비용(TOC), 효과(ROI)가 어떻게 변화하는가를 파악하게 된다. 체계설계 단계에서는 아키텍처의 변화를 통해 시간과 예산 범위 내에서 요구능력을 효과적으로 달성할 수 있는 SoS를 구현할 수 있게 된다. 오른쪽 상향 부분은 SoS에 대한 통합 솔루션을 구현하는 것이다. 결국 이러한 실험을 가능하게 하려면 정적 아키텍처에 대한 실행 가능한 모델이 필요한 것이다.

국방아키텍처 프레임워크(DoDAF/MNDAF)에 기반을 둔 아키텍처는 체계 간의 상호운용성과 인터페이스를 파악하기 위해 사용되는 것으로 알려져 있다. 그렇지만 아키텍처 기반의 분석과 평가를 위해서는 정적인 개념의 아키텍처가 동적인 개념의 실행모델로 변환되어야 한다.

실행모델로 변환하는 과정에서 우선 정적인 개념의 아키텍처 산출물의 일관성과 충분성을 검토해야 한다. 일관성을 보장하기 위해서 AV-2를 적용할 수 있는 아키텍처 작성도구가 필요하다. 운용구조(OV)와 체계구조(SV)의 연관성은 다음과 같이 보장되어야 한다.6)

<그림 5>는 이러한 산출물 간의 관계를 도시하고 있다. 또한, 아키텍처의 일관성과 충분성은 실행모델을 구현하는 과정에서도 식별된다. 이러한 일관성과 충분성을 유지한 아키텍처가 통합아키텍처이며, 실행모델 구현의 근거가 된다.

실행모델은 아키텍처 자체의 타당성을 평가하는 데 사용될 수도 있지만, 새로운 체계를 분석하는 데 중점을 둔다. 먼저, 실행모델은 새로운 체계의 설계가 타당한지, 그를 통하여 원하는 능력을 달성할 수 있는지를 판단하는 데 사용된다. 이는 실행모델이 체계 획득과 능력기반 소요를 다루는 데 있어서 매우 적합한 방법이라는 것을 의미한다.

실행모델은 체계 획득에 따른 성능과 관련 운용활동을 평가할 수 있을 정도로 상세해야 한다. 즉, 실행모델의 수행 결과는 체계 획득단계 초기의 트레이드오프(tradeoff) 분석을 지원할 수 있어야 한다. 수행결과는 체계 설계과정의 초기단계에 사용될 수 있으며, 아키텍처 자체에 대한 수정도 수반할 수 있다.

다음으로, 실행모델은 아키텍처 자체의 문제를 발견하는 데에도 사용된다. 아키텍처는 실행모델의 구현에 필요한 산출물을 정확하고 충분하게 묘사해야 한다. 만약, 아키텍처 산출물이 부정확하거나 충분하지 않다면, 이는 실행모델의 구현과정에서 누락된 사항으로 탐지될 것이다. <그림 6>은 이상에서 설명한 실행모델의 역할을 도시한 것이다.

실행모델은 체계와 체계기능이 운용활동에 미치는 영향을 판단하여 운용활동의 성과를 산출물로 제시한다. 운용활동과 운용노드는 OV 산출물에, 체계와 체계기능은 SV 산출물에 나타난다. Hartt가 제시한 <그림 7>에서 보는 바와 같이 임무수행 능력(C)은 임무에 관련된 운용활동(A1, A2, A3)의 성과를 종합하여 산출된다(Kimura, Carden & North, 2008). 따라서 실행모델은 아키텍처에 기반을 둔 능력 평가에 사용된다. 체계 획득소요, 인원 소요, TTP 변화 등이 체계, 체계노드, 운용활동에 영향을 미치며, 그 결과는 비용 데이터에 반영된다.

하나의 예로서 <그림 7>이 전구 탄도탄방어체계(TBMD)의 아키텍처를 나타낸다고 가정하면, 최상위 운용활동인 A1은 전장인식(sense), A2는 지휘통제(C2), A3는 전력운용(act)이 된다. 최상위 운용활동과 하위 운용활동은 미군 UJTL에, 한국군은 JCA의 능력이나 JTL에 제시된 과제에 해당한다(Wagenhals & Levis, 2008). 새로운 체계로서 S1을 획득하려고 할 경우, S1의 획득비용을 고려한다. S1에 포함된 체계노드에 S1로 인해 운용인원이 추가로 소요될 수도 있다. TTP의 변화는 운용활동 A2.2에 영향을 미치게 된다는 것을 나타낸다.

5)Spitz(2011)와 Williamson(2012)의 내용을 종합하여 새로운 V-모델을 구성함  6)AV-2: 통합사전, OV-1: 운용개념도, OV-2: 운용노드연결기술서, OV-3: 운용정보교환목록, OV-4: 조직단계도, OV-5: 운용활동모델, OV-6a: 운용규칙모델, OV-6b: 운용상태전이기술서, OV-6c: 운용사건추적기술서, OV-7: 논리적데이터모델, SV-1: 체계인터페이스기술서, SV-2: 체계통신관계도, SV-3: 체계관계추적상관표, SV-4: 체계기능기술서, SV-5: 운용활동대체계기능추적상관표, SV-6: 체계데이터교환목록, SV-7: 체계성능요소목록, SV-8: 체계진화기술서, SV-9: 체계기술예측목록, SV-10a: 체계규칙모델, SV-10b: 체계상태전이기술서, SV-10c: 체계사건추적서, SV-11: 물리구조모델, SV-12: 체계기반구조기술서, SV-13: 체계보안기술서, TV-1: 기술표준프로파일

본장은 통합아키텍처를 중간아키텍처로 변환하는 모델링 기법(M_R), 중간아키텍처를 실행모델로 변환하는 동적변환 기법(D_R)과 실행모델을 시뮬레이션으로 변환하는 시뮬레이션 기법(S_R)을 설명한다. 이를 기반으로 실행아키텍처를 구현하는 방법과 다양한 구현방법에 대한 비교 결과를 제시한다.

가. 통합아키텍처와 중간아키텍처 간의 모델링 관계(M_R)

통합아키텍처와 중간아키텍처의 모델링 관계, 즉 통합아키텍처를 중간아키텍처로 모델링하는 기법(M_R)으로는 <그림 8>에서와 같이 CPN, DES, SysML/UML 등이 있다.

모델링 기법은 각각 장단점이 있으며, 분석대상에 따라 다양하게 적용되고 있다. CPN은 체계의 동적인 특성을 이해하는 데 유용한 도구이다. 그렇지만 CPN은 교전규칙(ROE)이 변화하거나, 적군의 전투 모델이 학습하면서 진화하는 전장환경을 모델링하기에는 제한이 있다(DeStefano, 2004).7) DES는 특정한 시점에서만 상태가 변화하는 체계를 분석하기 위해 수치해석을 사용한다. 이는 대기행렬(queue)을 모델링하는 데 주로 사용된다. SysML/UML은 업무흐름, 정보교환 등을 도표로 표현하는 것이다.

나. 중간아키텍처와 실행모델 간의 동적변환 관계(D_R)

중간아키텍처와 실행모델의 모델링 관계, 즉 정적인 형태의 중간아키텍처를 동적인 형태의 실행모델로 변환하는 기법(D_R)으로는 <그림 9>에서와 같이 업무흐름모델(BPM), MATLAB/Simulink, DEVS 등이 있다. D_R은 중간아키텍처에 사건(event) 발생시간, 사건의 우선순위, 사건 수행순서 등을 반영하고, 인력 수의 변화, 체계 수량의 변화, 체계 성능대안 등을 반영할 수 있는 형태로 모델링하는 것이다. 그 결과 실행모델은 BPM, MATLAB/Simulink 모델, DEVS 모델의 3가지 형태로 구현된다. 특히, UML2로 모델링한 중간아키텍처는 자동화된 도구를 통해 DEVS 모델로 변환될 수 있다.

다. 실행모델과 시뮬레이션 간의 시뮬레이션 관계(S_R)

실행모델과 시뮬레이션의 시뮬레이션 관계, 즉 실행모델을 시뮬레이션으로 변환하는 기법으로는 <그림 10>에서와 같이 연동(federation), 시뮬레이션 SW, MATLAB/Simulink, DEVS 등이 있다.

MATLAB은 수치해석, 행렬 연산, 신호처리, 간편한 그래픽 기능 등을 통합하여 고성능의 수치해석 및 결과의 가시화 기능을 제공하는 프로그램밍 언어이다. DEVS는 이산사건 시스템에 대한 시뮬레이션을 지원하는 명세화 방법론으로서 재사용성과 재구성(composability) 가능성이 좋은 특성을 가지고 있다.

일부 실행모델은 동일한 도구 내에서 자동으로 시뮬레이션으로 변환된다. MATLAB/Simulink 형태의 실행모델은 MATLAB/Simulink의 시뮬레이션으로, DEVS 형태의 실행모델은 DEVS 시뮬레이션으로 자동 변환된다. BPM 실행모델은 전투 모델이나 통신모델을 HLA/RTI 방식으로 연동한 형태의 시뮬레이션으로 변환된다.

시뮬레이션 소프트웨어(SW)는 CPN 모델이나 SysML 모델의 중간아키텍처를 곧바로 시뮬레이션으로 변환하는 데 사용되며, 이는 다음 절에서 설명된다.

본 절은 실행아키텍처 변환기법을 기반으로 실행아키텍처를 구현하는 방법과 다양한 구현방법에 대한 비교 결과를 제시한다.

실행아키텍처는 <그림 11>과 같이 모델링 기법(M_R), 동적변환 기법(D_R)과 시뮬레이션 기법(S_R)의 연속적인 적용을 통해 구현된다. 문헌 조사를 통해 살펴본 바에 따르면, 실행아키텍처의 구현은 다음과 같은 변환기법의 조합을 통해 이루어진다.

가. 방법 1: CPN → BPM → 연동

방법 1은 CPN로 모델링된 중간아키텍처(이하 ‘CPN 모델’이라 함)를 BPM 형태의 실행모델로, 그리고 BPM 실행모델은 전투 모델이나 통신모델과 연동을 통해 시뮬레이션으로 변환하는 방법이다. 통합아키텍처의 OV 산출물은 CPN 모델의 구성요소로 대응된다. Beal, et al.(2005, p. 2-57)이 제시한 <그림 12>에서 OV-5의 운용활동은 트랜지션(transition)으로, OV-5 운용활동의 ICOM과 OV-6a는 플레이스(place)로, OV-7의 속성은 토큰(token)으로 각각 대응된다.

그러나 CPN 모델은 적이 자신의 아키텍처를 가지고 있는 전투환경에서 아군 미래 체계의 군사적 가치를 평가하기에는 적합하지 않다. CPN 모델은 체계기능의 수행과정을 모델링한 것으로서, 체계기능을 통해 데이터가 어떻게 흘러가는지는 분석할 수 있으나 수행과정에 걸리는 시간은 판단할 수가 없다(Zinn, 2004). 또한, CPN 모델은 체계 성능이나 통신체계의 변화가 미치는 영향이나, 적 운용 개념(CONOPs)에 대응한 아군의 운용개념의 변화가 미치는 영향을 판단하기도 어렵다. 이러한 문제를 극복하기 위해 CPN 모델은 동적인 특성을 반영할 수있는 BPM으로 변환된다. BPM은 단독으로는 다양한 수준의 분석을 하는 데 제한이 되므로 다른 패러다임의 시뮬레이션과의 연동을 필요로 한다(Zinn, 2004: DeStefano, 2004).

다른 패러다임의 시뮬레이션으로는 전투 모델과 네트워크 모델이 사용된다. 전투 모델은 결정형 모델(DCM)과 확률적 모델이 있는데, 결정형 모델은 확률적 모델만큼 유용한 결과를 제시하기에는 한계가 있다. 결정형 모델로는 미 육군의 Eagle을, 확률적 모델로는 미 공군의 에이전트 기반 시뮬레이션 모델(ABS)을 사용할 수 있다. 네트워크 모델은 OPNET이나 NS2를 사용할 수 있다.

한 가지 사례에 따르면, BPM을 중심으로 결정형 전투 모델인 Eagle과 네트워크 모델인 NS2가 HLA/RTI 기반으로 연동된다(Pawlowski, Barr & Ring, 2004). 연동은 엔티티뿐만 아니라 엔티티 간의 관계도 상호매핑(mapping)하는 것을 의미한다. 연동이 이루어지면 3개 모델은 HLA/RTI 기반으로 운영된다.

이러한 연동개념은 확률적 전투 모델에도 똑같이 적용된다. 미 공군은 ABS의 일환으로 SEAS를 개발하였다. SEAS는 작전 시나리오하에서 C4ISR 체계의 군사적 유용성을 평가하기 위해 개발된 모델이다. 미 해군의 NSS는 전단의 전투훈련을, 해병대의 JIVES는 시가전을 모의한 것으로서 NCW와 EBO의 개념을 분석하는 데 적합한 모델이다.

이상의 내용을 합동근접항공지원(JCAS)체계의 아키텍처에 대해 예시하면, 통합아키텍처는 JCAS_iA로, 중간아키텍처는 JCAS_CPN으로, 실행모델은 JCAS_BPM으로 <표 1>과 같이 나타낼 수 있다.8) 실행모델 시뮬레이션은 실행모델과 전투 모델/통신모델이 연동된 형태로 <표 1>과 같이 나타낼 수 있다. 3개 모델 간의 연동개념은 <그림 13>에 제시되어 있다.

이러한 시뮬레이션은 임무 시나리오를 반영한 전투 모델, 네트워크를 통한 정보흐름을 반영한 통신모델을 사용함으로써 노드(조직) 업무 부담, 인력/체계 할당, 통신 능력, 네트워크 고장 영향, 특히 임무 성공 여부 등을 동적으로 측정할 수 있다는 이점이 있다. 반면, BPM 실행모델에 전투 모델과 통신모델을 통합하는 것은 앞에서 언급한 엔티티 간의 연동과 엔티티의 관계에 대한 연동을 하는 것이다. 이는 BPM 실행모델과 통신모델이 전투 모델의 결과를 반영하기 위해 모델 자체가 수정되어야 함을 의미한다. 또한, BPM 실행모델의 임무운용절차는 전투 모델의 주요 사건과 연동되어야 한다. 즉, 전투 모델의 어떤 사건이 BPM 실행모델의 어떤 운용절차를 유발하는지를 판단해야 한다. 그 운용절차가 완료되며, 그것이 전투 모델의 어떤 사건과 연계되는지도 판단해야 한다. Pawlowski, et al.(2004)이 제시한 <그림 14>에서 전투 모델의 사건 E1은 BPM 실행모델의 운용활동 A1을 유발하고, 실행모델의 운용활동 A3은 전투 모델의 사건 R1과 연계되는 것을 보여 주고 있다.

전투 모델에서 엔티티 속성이 변화하면 이는 실행모델이나 통신모델에 반영되어야 한다. 전투 모델의 어떤 엔티티가 통신모델의 노드에 해당될 경우, 그 엔티티의 상태와 위치가 통신모델에 반영되어야 한다. <그림 14>에서 전투 모델의 사건 R2는 통신모델의 재구성으로 반영되는 것을 보여 주고 있다. 전투 모델의 어떤 엔티티가 BPM 실행모델의 운용활동에 해당될 경우에는, 그 엔티티의 상태가 BPM 실행모델에 반영되어야 한다. 만약 어떤 운용활동을 수행하는 엔티티가 피해를 받으면, 그 운용활동은 더 이상 수행할 수 없도록 BPM 실행모델을 조정해야 한다.

나. 방법 2: SysML/UML → MATLAB/DEVS → MATLAB/DEVS

통합아키텍처의 모든 OV와 SV 산출물은 UML 요소를 사용하여 변환될 수 있다. UML 요소로는 유스케이스 도표(use-case diagram), 업무활동순서 도표(activity sequencing diagram) 등이 있다. 아키텍처 산출물과 UML 요소의 변환 관계는 Mittal(2006)에 제시되어 있다.9)

SysML은 UML의 일부분을 확장한 것으로서 체계공학의 체계소요, 체계구조, 수행 기능, 주요 성능 요소 등을 규정하기 위해 설계된 모델링 기법이다. <그림 15>에서 보는 바와 같이 두 원의 교집합은 SysML에서 재사용하는 UML을 나타낸다. SysML 요소로는 맥락 도표(context diagram), 유스케이스 도표(use-case diagram), 소요 도표(requirement diagram), 업무활동 도표(activity diagram) 등이 있다. 아키텍처 산출물과 SysML 요소의 변환 관계는 Ruegger(2008, p. 39)에 제시되어 있다.

SysML/UML 요소로 나타낸 중간아키텍처는 M&S에 필요한 정보를 전달해주는 매개체 역할을 할 뿐 동적인 특성을 가지고 있지 않다. 따라서 SysML/UML형태의 중간아키텍처로부터 유용한 분석결과를 도출하려면 동적인 개념의 실행모델로 변환해야 한다.

SysML/UML 형태의 중간아키텍처는 MATLAB/Simulink를 통해 실행모델로 변환된다. 먼저, SysML/UML의 요소(엔티티)는 MATLAB/Simulink의 엔티티와 유사한 관계를 가지고 있기 때문에 MATLAB/Simulink로 변환하는 것이 가능하다.10)

SysML/UML 형태의 중간아키텍처는 DEVS를 통해 실행모델로 변환되기도 한다. DEVS 모델은 사건에 의해 상태가 전이되거나, 시간의 흐름에 따라서 내부적으로 전이가 가능한 기법이다. 이는 해군, 공군, 해병대의 훈련모델과 해군의 분석모델에 사용되었다. 특히, UML2로 모델링한 중간아키텍처는 자동화된 도구를 통해 DEVS 모델로 변환될 수 있다.

MATLAB/Simulink 실행모델과 DEVS 실행모델은 동일한 도구 내에서 자동으로 시뮬레이션으로 변환된다.

이상의 내용을 JCAS 아키텍처에 대해 예시하면, 통합아키텍처는 JCAS_iA로, 중간아키텍처는 JCAS_UML/JCAS_SML로, 실행모델은 JCAS_UMAT, JCAS_UDEVS/JCAS_SMAT, JCASSDEVS로 <표 2>와 같이 나타낼 수 있다. 실행모델 시뮬레이션도 유사한 방법으로 표기하여 <표 2>와 같이 나타낼 수 있다.

다. 방법 3: CPN/SysML → 시뮬레이션 SW (D_R 미적용)

CPN 모델과 SysML 형태의 중간아키텍처는 D_R을 거치지 않고 직접 시뮬레이션 SW로 변환될 수 있다.

Arena 시뮬레이션은 CPN 모델에서 사용하는 계층구조를 유사하게 사용하는 시뮬레이션 SW이다. 즉, CPN 모델의 토큰은 Arena 엔티티로, 트랜지션은 Arena 블록으로 매핑하되, 조직은 Arena 자원으로 모델링한다. 이러한 Arena 시뮬레이션은 시나리오의 변화, 자원의 변화 등을 반영할 수 있다. 미 공군은 CPN 모델을 Arena 시뮬레이션으로 변환한 사례를 발표하였다(Beal, et al., 2005).

Extend 시뮬레이션은 SysML에서 표현하는 정보의 흐름을 중심으로 변환하는 시뮬레이션 SW이다.

이상의 내용을 JCAS 아키텍처에 대해 예시하면, 통합아키텍처는 JCAS_iA로, 중간 아키텍처는 JCAS_CPN과 JCAS_SML로, 시뮬레이션은 JCAS_Arena와 JCAS_Extend로 <표 3>과 같이 나타낼 수 있다.

실행아키텍처는 3가지 방법으로 구현됨을 살펴보았다. 3가지 방법은 전장 기능이나 요소에 대해 상세한 모의를 할 수 있는지에 있어서 차이가 있다.

방법 1은 전투, 통신, 군수 등의 전장기능을 실행모델과 연동하여 사용하는 방법이다. 이는 기존에 운영하고 있는 기능모델(전투 모델, 통신모델, 군수모델 등)을 사용하는 것이며, 그 결과 해당 전장기능에 대해 상세한 모의가 가능하게 된다. 그렇지만 이 방법은 실행모델과 기능모델의 연동을 요구하는데, 모델 간의 연동업무는 관련 모델 모두에 대한 전문성을 필요로 한다. 특히, 기능모델에 대한 전문성이 없으면, 이 방법은 적용하기가 불가능하다고 할 수 있다. 전문성이 있다고 하더라도, 연동업무는 상당한 시간을 필요로 한다.

방법 2와 방법 3은 전투, 통신, 군수 등의 전장기능을 실행모델 내부에 구현하는 방법이다. 이는 방법 1에 비해 상대적으로 용이하며, 구현에도 많은 시간을 필요로 하지 않는다. 3가지 방법의 변환기법과 구현형태를 요약하면 <표 4>와 같다.

7)a combat environment where the rules of engagement are changing and the enemy model is learning and evolving  8)합참의 여러 임무 중의 하나인 JCAS를 예로서 선정함. 다른 임무도 동일하게 표시 가능함.  9)OV 산출물은 Mittal(2006)의 <표 3>에, SV 산출물은 Mittal(2006)의 <표 9>에 나타나 있음  10)Simulink와 UML 엔티티의 관계는 Ryan & Hanoka(2012)의 <그림 3>에 나타나 있음

가. 구축목표

아키텍처는 통합아키텍처, 중간아키텍처와 실행아키텍처를 대상으로 현행과 미래에 대해 3가지 목표를 가지고 구현해야 한다. 첫째, 현행 아키텍처는 미래아키텍처를 구현할 경우 변화된 부분을 제외하고는 재사용될 수 있어야 한다. 즉, 미래 아키텍처는 현행 아키텍처에서 변화된 부분을 새로운 것으로 교체, 재구성될 수 있어야 한다. 둘째, 아키텍처의 상세 정도는 실행아키텍처의 분석대상에 따라 탄력적으로 적용할 수 있어야 한다. 즉, 상세한 아키텍처는 기존 아키텍처의 하위 아키텍처로 세분화되는 형태로 되어야 한다. 셋째, 아키텍처는 운용활동이나 체계기능을 중심으로 임무별로 구현된다. 운용활동은 합참에서 설정한 JTL로 구성되므로, 동일한 JTL에 대한 아키텍처는 모든 임무에서 동일하게 적용할 수 있어야 한다.

이렇게 구현된 아키텍처는 체계적으로 관리하고, 분석대상에 활용할 수 있도록 해야 한다. 따라서 모든 아키텍처(산출물)는 공유 저장소에 수록해야 한다.

나. 구축개념

NCW 환경에서는 <그림 16>에 나타난 바와 같이 새롭게 도입되는 체계(플랫폼)가 기존 체계(플랫폼)와 네트워크로 통합되어 복합체계(SoS)로 운용된다. 그 결과 새로운 체계는 SoS로 운용되는 전체 맥락(context)에서 성능이나 효과를 평가해야 한다. 이러한 SoS의 평가는 아키텍처 기반의 체계공학을 적용해야 가능함을 Ⅲ장에서 언급하였다. 이는 새로운 체계의 도입 효과는 SoS의 운용시나리오 하에서 아키텍처 기반의 M&S를 통해 분석할 수밖에 없다는 것을 의미한다.

아키텍처 기반 M&S는 MOP와 MOE로 2가지 형태의 분석 결과를 제공한다. MOP는 각각의 운용활동 또는 체계기능이 전장환경에서 얼마나 잘 수행되는가를 평가하는 척도이며, MOE는 SoS가 임무 목적을 성공적으로 달성하는 정도를 평가하는 척도이다.

평가 결과는 새로운 체계가 수행할 기능의 성과(performance)와 임무수행능력에 대한 기여도를 명확하게 파악하는 데 도움이 될 것이다. 이를 통해 새로운 체계의 기능에 대한 ROC가 역으로 검증되거나 도출될 수 있다. 또한 새로운 체계의 기능이 운용활동에 미치는 효과를 판단하여 새로운 TTP를 수립할 수 있다. 새로운 체계가 임무수행에 기여하는 능력 평가를 통해 새로운 체계의 도입효과도 판단할 수 있다.

다. 구축단계

아키텍처 구축은 2단계로 구분하여 수행되어야 한다. 1단계는 재사용이 가능한 상위 수준에서 구현해야 한다(Behre). 이는 기 작성된 현행 아키텍처 산출물을 검토, 수정하는 방향으로 수행된다. 대상 산출물은 AV-1(상위수준), OV-1, OV-4, OV-5, SV-1이다.

MOP와 MOE도 상위 수준에 맞게 설정되며, 이를 산출하기 위한 실행모델이 구현된다. 실행모델 구현을 위해 합동임무흐름(JMT)을 작성한다. 이는 아키텍처 산출물을 기반으로 하여, 운용활동과 체계의 합동임무 수행과정을 나타낸 것이다. CAS 임무의 JMT는 <그림 17>과 같다(Behre).

2단계는 특정한 이슈나 문제를 해결하는 데 필요한 수준에서 구현해야 한다(Behre). 이는 기 작성된 현행 아키텍처 산출물을 검토, 수정하는 방향으로 수행된다. 대상 산출물은 AV-1(특정수준), OV-2, OV-3, OV-4, OV-5, OV-6, SV-1, SV-3, SV-5, SV-6, SV-10이다. 대상 산출물 중에서 SV-1는 전술적 수준까지 구현되는데, <그림 18>은 미 해병대의 전술수준 UJT인 TA3.2.2(CAS 수행)에 대해 예시한 것으로서, MAGTF FFCC, 사단 GCE FSCC 등의 지휘통제 노드와 AFATDS, ADSI 등의 체계를 보여주고 있다. 체계 간의 통신은 비밀유선망(SIPRNET)이나 무선망(RF)을 통해 이루어진다.

MOP/MOE도 특정 수준에 맞게 설정되며, 이를 산출하기 위한 실행모델이 구현된다. 2단계 실행모델 구현을 위해서는 고유한 JMT를 작성한다. 여기에는 군 고유의 TTP 또는 운용개념(CONOPs)을 적용하고, 특정 책임지역(AOR)을 설정할 수 있다. JMT에는 각 노드에 대한 특정 자원(인력/체계), 메시지 순서/내용, 시간/분포, 결심과정, 체계속성, 체계기능, 체계능력, IER, 상호운용성 등을 설정, 포함시킨다. 미군의 체계기능은 합동공통체계기능목록(JCSFL)에 따라 설정한다.

라. 구축방법

실행아키텍처는 3가지 방법으로 구현할 수 있다. 본 연구에서는 방법 2에 해당하는 UML2와 DEVS를 적용할 것을 제안한다. 왜냐하면, DEVS는 재사용성, 재구성 가능성과 연동성이 용이한 특성이 있으며, UML2로 모델링된 결과는 DEVS로 자동적으로 변환할 수 있기 때문이다. 특히 국내(예: 한국과학기술원)에서 이러한 변환기법을 보유하고 있으며, 해군의 청해모델, 공군의 창공모델, 해병대의 천자봉모델 등의 훈련모델에 DEVS를 이미 성공적으로 적용하고 있기 때문이다.11)

또한, 국내(한국과학기술원)에서 개발한 장보고-Ⅲ 전투체계 효과도 분석, 해양전투실험 등에도 DEVS가 적용되었다. 그 결과 구현된 DEVS 모델은 ROC 분석과 이를 통한 ROC 보완 등에 사용되고 있다.

구축형태는 비연동모델과 연동모델의 2가지 형태가 있는데, 소요기간과 관련 모델의 전문성을 고려하여 1단계로는 비연동모델을, 2단계로는 연동모델을 구축할 것을 제안한다. 연동모델로는 특정 이슈에 적합한 전투 모델과 OPNET 통신모델을 선정, 적용할 것을 제안한다.

마. 추진체계

추진계획은 구축단계와 구축형태를 고려하여 <표 5>와 같이 수립한다. 재사용 가능한 수준의 비연동모델은 단기적으로 추진한다. 특정 이슈를 해결하기 위한 수준의 비연동모델은 중･단기적으로, 특정 이슈를 해결하기 위한 수준의 연동모델은 중･장기적으로 추진한다.

사업은 합참이 주관하며, KIDA는 합참을 지원한다. KIDA는 사용자의 운용개념과 획득 대상 무기체계의 기능이 아키텍처에 제대로 반영하였는지를 확인(verification)하고, 실행아키텍처의 수행결과가 타당한지를 사용자와 함께 검증(validation)하는 역할을 수행한다. 사업 수행은 국내 대학이나 연구소가 맡는 것이 바람직하다. 필요하다면, 미국 연구소와 협력하여 수행하는데, 이 경우에는 국방부나 합참 차원의 지원이 필수적이다.

미국과의 공동연구를 위해서는 한미정보교환협정(IEA)과 한미자료교환협정(DEA)을 활용할 필요가 있다. 미국의 한 연구소와 토의한 결과에 의하면, 제공가능한 서비스에 대해서는 미 정부의 수출허가(export license)가 전제되어야 한다. 계약형태는 FMS보다는 DCS를 권고하였다.

사업 방식은 시범체계를 개발한 후에 체계개발을 수행하거나, 아니면 바로 체계개발을 수행할 수 있을 것이며, 이것은 합참이 결정해야 할 것이다.

바. 아키텍처 관리/활용

아키텍처는 관리와 재사용을 위해 저장소에 수록되어야 한다(Chivis, 2010). 저장소에는 아키텍처 산출물, 실행모델과 분석결과가 저장된다(<그림 19> 참조). 아키텍처의 재사용은 소요분석의 일관성을 기하고, 운용개념의 발전을 연속적으로 반영할 수 있는 계기가 된다. 신규 무기체계 획득을 고려할 경우, 과거와 같이 매번 새로운 분석방법을 적용하지 않고 기존 분석방법의 연장선상에서 임무수행능력의 한계적 향상 정도를 산정할 수 있다.

우리 군은 기 수립된 임무별 전장관리 아키텍처 산출물을 사용하여 위에서 언급한 ROC 검증/식별, 운용개념 재정립, 능력기반평가(CBA) 등을 가능케 하는 실행아키텍처를 구축해야 하는 시점에 와 있다. 그러면 우리 군은 실행아키텍처를 구축하기 위해 무엇을 어떤 절차로 해야 하는가를 제시하고자 한다.

절차 2는 현행 아키텍처가 모든 합동임무에 대해 작성되어 있지만, 일관성과 충분성 관점에서 보완해야 할 것을 의미한다. 이러한 아키텍처의 보완은 별도 사업을 통해 일률적으로 수행하는 것보다는 실행아키텍처를 구현하는 사업을 통해 임무별로 하는 것이 바람직할 것이다. 왜냐하면 현행 아키텍처가 가능한 모든 운용시나리오를 미리 반영하여 수립하기란 불가능하기 때문이다.

아키텍처의 작성은 원래 실행모델을 바로 작성하는 것이 바람직하다. 왜냐하면, 실행모델은 체계가 어떻게 상호작용하는지에 대한 동적인 기능거동분석(dynamic behavior analysis)을 가능하게 하며, 이를 통해 체계의 운영성과(performance)를 판단할 수 있기 때문이다. 그렇지만, 실행모델의 작성은 상당히 어려운 일이기 때문에, 정적인 개념의 아키텍처를 프레임워크에 맞춰서 작성하도록 규정하였다. 즉, 현행 아키텍처는 실행모델을 구현하기 위한 이전 단계에 해당하므로, 상호운용성, 체계의 운영성과, 임무 수행능력 등을 분석하기 위해 실행모델은 반드시 구현해야 한다.

절차 6의 미래 아키텍처도 현행 아키텍처와 유사하다. 미래 아키텍처는 새로운 체계가 획득되는 경우에 참여 가능한 모든 임무에 대해 임무별로 작성해야 한다. 왜냐하면 미래 아키텍처가 획득 가능한 모든 체계를 미리 반영하여 수립하기란 불가능하기 때문이다.

절차 5는 새로운 체계의 유형에 따라 분석의 유형도 달라진다는 것을 의미한다. 유형 A는 새로운 1개 체계에 대해 여러 가지 대안을 고려, 분석하는 것이다. 가령, 차세대 전투기로 고려하고 있는 유로파이터, F-15SE, F-35에 대해 수행임무를 선정하고, 각 임무의 수행능력을 분석하는 것이다. 그 결과 각 대안이 요구능력을 얼마나 충족하는가를 판단하게 된다. 임무 수행능력과 획득 비용을 함께 고려하면 각 대안에 대해 비용 대 효과를 비교할 수 있다.

유형 B는 기존 체계의 성능개량 여부를 분석하는 것이다. 가령, KF-16에 Link-16을 탑재하는 것이 관련 임무의 수행능력을 얼마나 향상시키는가를 분석하는 것이다. 그 결과 성능개량이 요구능력을 충족하는가를 판단하게 된다. 임무수행능력과 성능개량 비용을 함께 고려하면 성능개량의 비용 대비 효과의 적절성을 판단할 수 있다.

유형 C는 다수의 기존 체계의 성능개량을 분석하는 것이다. 이는 주로 통신체계를 기존 체계에 탑재하는 범위를 판단하는 것이다. 가령, Link-16을 어떤 체계에 탑재하는 것이 효율적인가를 분석하는 것이다. 이는 Link-16을 통해 수행 가능한 임무와 임무별 참여 체계를 선정하고, 어느 체계에 탑재하는 것이 임무 수행능력을 어느 정도 향상시키는지를 분석하는 것이다. 그 결과 각 탑재 대안이 요구능력을 충족하는가를 판단하게 된다. 임무 수행능력과 획득 비용을 함께 고려하면 각 대안에 대해 비용 대 효과를 비교할 수 있다.

이상에서 살펴본 바에 따르면, 유형 A와 유형 B는 대안 분석(AoA)에, 유형 C는 포트폴리오 분석에 해당한다. 대안 분석은 적용가능한 조합을 사전에 설정, 분석하는 것이며, 포트폴리오 분석은 가능한 모든 조합에 대해 분석하는 것이다. 새로운 2개 체계를 동시에 고려할 경우에는 2개 체계가 참여하는 임무를 식별하여 동일한 절차를 적용하면 된다.

현행 아키텍처에 대한 실행모델은 로드맵에서 제시한 변환기법을 적용, 구현한다. 미래 아키텍처에 대한 실행모델은 현행 아키텍처의 실행모델을 재사용하고 재구성하여 구현할 수 있어야 한다. 미래에 예상되는 새로운 체계는 아키텍처의 변화를 일부 초래하므로, 매번 실행모델을 새롭게 구현하는 것은 시간과 노력의 낭비뿐만 아니라, 분석의 일관성에도 지장을 주게 된다. 새로운 체계가 발휘하는 기능과 운용활동이 기존 기능/운용활동을 대체하면서 현행 실행모델 내에 재구성하고, 기존 기능/운용활동의 실행모델은 그대로 재사용할 수 있어야 한다.

합참은 임무별로 기준 실행모델을 지정하고, 새로운 모델에 대해서는 버전을 관리해야 한다. 기준 실행모델은 전력구조의 발전에 따라 변화하면서, 새로운 버전의 실행모델로 대체될 것이다.

<그림 20>은 이상의 내용을 JCAS 임무에 대해 도시한 것이다. 참여 체계는 X, Y, Z이며, 체계 간 상호운용성 수준은 선의 종류로 표시하였다. 점선은 상호운용성 수준이 낮은 것을, 단선은 상호운용성 수준이 중간인 것을, 겹선은 상호운용성 수준이 높은 것을 나타낸다. 유형 A는 새로운 체계 N이 획득대상이며,그 결과 N-X, N-Y의 상호운용성이 향상된 것을 겹선으로 표시한 것이다. 유형 B는 X'가 X의 성능개량 체계이며, 그 결과 X'-Y, X'-Z의 상호운용성이 향상된 것을 겹선으로 표시한 것이다. 유형 C는 X", Y", Z"이 X, Y, Z에 새로운 통신체계를 탑재, 성능을 개량한 체계이며, 그 결과 모든 체계 간의 상호운용성이 향상된 것을 겹선으로 표시한 것이다. 정적인 아키텍처와 실행아키텍처의 버전은 아래 첨자로 표시하였다. 현행 아키텍처에 대해서는 0으로, 유형별 아키텍처에 대해서는 각각 1, 2, 3으로 나타냈다. 미래 아키텍처는 현행 아키텍처를 재사용하여 재구성하는 형태가 되며, 이는 아키텍처 버전 간에 수직선으로 표시하였다.

11)그 결과 한국군의 훈련모델이 미군 훈련모델과 쉽게 연동하여 연합훈련에 사용되고 있다.

실행아키텍처는 정보의 생성 및 활용을 목적으로 자원(인력, 물자)을 사용하여 운용노드에서 수행되는 직무(역할)의 운용활동들과 그에 관련된 일련의 사건(event)들을 모델링하여 시뮬레이션 실행이 가능하도록 구축된 아키텍처이다. 이상적인 경우는 대상 체계에 대한 실행아키텍처를 직접 구현하는 것이 바람직하나 이를 지원하는 도구나 수단을 지정할 수 없으므로, 현재는 정적인 아키텍처산출물을 먼저 만들고 이것으로부터 실행아키텍처를 구현하는 과정을 거치도록 하고 있다.

통합아키텍처로부터 실행모델을 구현하고, 또 실행모델로부터 시뮬레이션을 구현하는 일련의 과정은 체계적이고 분석적인 작업을 거쳐야 한다. 실행모델과 시뮬레이션, 즉 실행아키텍처가 임무 수행능력의 타당성을 새로운 방법으로 평가하는데 필수적이라는 것은 많은 적용 사례에서 보여주고 있다(Beal, et al., 2005: DeStefano, 2004; Rodriguez, 2005; Ryan & Hanoka, 2012; Spitz, 2011; Zinn, 2004).

실행아키텍처의 구현방법에 대한 연구는 계속 진행되고 있다. 구현방법은 다양한 형태를 나타내고 있으며, 분석 목적이나 분석가의 전문성에 따라 특정한 기법을 적용하고 있다. 이는 실행아키텍처를 구현하기 위해 명확한 기준이나 표준 절차가 아직까지 정립되지 않았다는 것을 의미한다.

전투 모델은 실행아키텍처가 구현되기 이전부터 독립적으로 발전해 왔다. 최근에는 전투 모델이 아키텍처 기반의 실행모델과 연동하는 방향으로 종종 사용되고 있다. 하지만, 연동의 어려움과 한계로 인하여 2개 모델이 하나로 수렴하는 방안을 제안하고 있다. 즉, 전투 모델이 아키텍처를 반영, 발전해야 한다는 것이다. 이는 단기간에 달성하기는 어려운 과제이며, 중･장기적으로 가능성과 유용성에 대한 검토를 통해 추진할 과제이다.

아키텍처 기반 분석은 특정한 임무를 설정하고, 그에 대한 현행 아키텍처를 기준으로 설정한다. 이러한 기준에 새로운 체계가 추가되거나 또는 기존 체계의 성능이 개량되면, 이를 반영한 미래 아키텍처를 작성한다. 실행모델은 현행 아키텍처와 미래 아키텍처에 대해 구현한다. 실행모델은 시뮬레이션 프로그램을 통해 운영되며, 이를 통하여 아키텍처 기반의 능력 평가를 수행할 수 있게 된다. 새로 획득된 체계나 성능개량된 체계는 운용과정이나 절차의 일부분을 변경 또는 개선하여 결심 주기를 단축시킴으로써 임무수행의 효율성 즉, 임무 수행능력을 향상시킬 것이며, 그 향상 정도는 실행모델에 대한 시뮬레이션 프로그램을 통해 도출된다. 시뮬레이션 프로그램은 실행모델보다 더 상세한 경향이 있다. 그에 따라 시뮬레이션 프로그램은 더 많고 더 정확한 데이터나 정보를 필요로 한다.

새로운 체계의 획득이나 기존 체계의 성능개량에 필요한 비용도 산출할 수 있다. 체계로 인해 운용인원이 추가로 필요하거나, TTP의 변화로 운용활동이 영향을 받는 경우, 이에 수반되는 비용도 고려한다. 그 결과, 획득대안이나 획득 포트폴리오에 대해 임무 수행능력의 향상 정도와 그에 수반되는 투입 비용을 고려하여 비용효과적인 대안이나 포트폴리오를 판단할 수 있다.

실행모델과 시뮬레이션은 다양한 방법을 통해 구현될 수 있지만, 난이도가 높거나 구현에 오랜 시간이 걸리는 방법은 단기간에 적용하기는 힘들다. 우리 군은 훈련모델이나 분석모델에 UML2와 DEVS를 적용하고 있다. 따라서 실행모델과 시뮬레이션도 유사한 방법을 적용하는 것이 바람직한 방안일 것으로 보인다. 이와 병행하여, 미국이나 유럽의 연구기관과 협조하여, 시범임무에 대한 실행모델과 시뮬레이션을 공동으로 구현하는 방안을 통해 시행착오를 줄이는 것도 필요하다.

단기적으로는 재사용이 가능한 아키텍처 산출물을 대상으로, 중･단기적으로는 특정 이슈를 해결할 수 있는 수준까지 아키텍처 산출물을 작성하여 비연동모델 형태로 실행아키텍처를 구현할 것을 제안한다. 중･장기적으로는 특정 이슈에 대한 아키텍처 산출물을 작성하여 연동모델 형태로 실행아키텍처를 구현할 것을 제안한다.