- 1 -

C4I체계 개발을 위한

아키텍처 실제(Architecture Practice) 연구

Architecture Practice Study for C4I Systems Development

원제 : Architecture Practice Study for C4I Systems

Development

저자 : Pin Chen, Abdel El-Sakka, Jennie Clothier

출처 : 호주 국방부 DSTO C3 Research Centre

내용 : C4I체계 아키텍처 개발 방법론

번역 : (예) 대령 김혁래

요약

복합체계 개발을 위한 아키텍처라는 개념은 아직까지 완전히 성숙되지 않고 있

다. 대부분의 조직들은 단편화된 아키텍처 개발 접근법을 가지고 있다. 본 논문

에서 우리는 아키텍처 실제(architecture practice)의 수행에 대해 중점적으로 다루

며, 조직이 아키텍처 접근법을 이행할 수 있는 능력을 평가하기 위한 전반적인 모

델을 제안한다.

1. 서론

대규모 조직에 있어서 대부분의 정보체계 개발과 마찬가지로, C4I체계의 개발은

정보체계를 획득, 변경, 재개발하기 위한 전통적인 절차와는 다르게 수행되고 있

다. 현재의 정보체계 개발은 부적절하고 지원면에서도 부족한 점이 많아서, 미래

체계의 복잡성 증가를 해결하기에 적당하지 않은 것으로 생각된다. 과거의 경험

및 기존 체계를 철저히 조사한 결과, 정보기술 실제에 대한 절차의 혁신 및 개선

이 요구되는 현상들이 나타나고 있다.

C4I체계 실무요원 및 연구요원들은 지식기반 전투수행능력의 진화적 획득을 위

해 상당한 개발노력을 창출하기 위한 여러 가지 방법을 시도하고 있는 중이다.

지금까지 수행된 알아 볼 수 있을 정도로 두드러진 몇 가지 연구는 아키텍처

[CAWG, 1997(1)], [Zachman, 1996], [Microsoft, 1999], [SEI, 1999], [IAWG, 1998]

와 같은 동일한 개념에 기반을 두고 있다.

본 논문에서는 C4I체계 개발의 특징에 덧붙여 아키텍처 분야 연구개발 노력에

- 2 -

대해 간략히 검토해 본다. 아키텍처의 3가지 주요 역할에 기초한 아키텍처에 대

한 종합적인 정의는 전체적으로 아키텍처 실제 분야에서 보다 많은 주의가 필요

하다는 것을 상기시키기 위해 도입되었다.[Chen 외, 1998년] 아키텍처 실제의 이

론적 근거 및 관리는 정보기술에 있어서 조직의 개발능력에 대한 성숙도 수준을

결정하는데 대단히 중요한 요소이다. 여러 가지 C4I체계 개발 측면에서 아키텍처

문제가 점점 더 복잡해짐에 따라, 어떤 단일 아키텍처 산물이나 구조(또는 접근

법)에 초점을 두기보다는 복잡성을 관리하기 위한 전략적인 의도를 가지고 아키

텍처 실제를 연구할 필요가 있다. 중요한 학문분야로서 아키텍처 실제는 더 많은

관심을 가질만하며, 대규모 조직의 정보기술 개발능력을 향상시키는데 있어서 커

다란 잠재력을 가지고 있다.

특히, 본 논문에서는 호주방위기구(ADO : Australian Defence Organization)를

위해 제안된 아키텍처 실제에 대해 논하고자 한다. 이 아키텍처 실제는 다양한

아키텍처 구조 또는 다양한 목적을 수용할 수 있으며, 잘 정의된 실제 배경 내에

서 구조들 간에 상호관계를 명확화 및 합리화함으로써 적절한 조정안을 제공할

수 있다.

2. C4I체계 개발의 특징

정보기반 C4I능력의 정교화 수준은 어떤 발전된 기술이 사용되고 있는지, 그리

고 C4I업무가 정보 및 지식과정에서 효율성 및 효과성 측면에서 어떻게 지원되고

있는지, 바꾸어 말해서 기술이 C4I를 위해 얼마나 스마트하게 사용되고 있는지에

의해 결정된다. 성공적으로 C4I체계를 개발하기 위해 조직은 다음과 같은 도전적

인 문제를 처리할 수 있어야 한다.

가. 진화적 개발

C4I 정보기반능력에 대한 진화적 개발은 국방 조직이 직면하고 있는 현실이다.

이와 같은 개발에 있어서 주 난제 중의 하나는 통합 또는 상호운용성인데, 그 이

유는 각개 C4I체계들이 종종 다양한 기술을 사용하여 다양한 사람들에 의해 개발

되기도 하기 때문이다. C4I 상호운용성을 위해서는 하나의 통합형 구조와 일괄적

인 명확한 구현지침이 필요하다. [NRC, 1999]에서 언급한바와 같이, C4I 상호운

용성 달성은 기술적 쟁점을 해결하는 분야에 대한 문제이기 보다는 주로 관리, 설

계, 구현 분야에 대한 문제이다.

나. 복합체계(SOS)

C4I에 대한 전략적 사고 및 체계 공학은 조직, 사업, 지리적 경계에 걸쳐 대규

모로 복잡하며 분산되어 있는 복학체계(SOS : Systems of Systems)라는 개념에

- 3 -

기초하고 있다. 따라서 복합체계 개발문제에 대해 명확히 이해하는 것이 현행 체

계를 개발하는 데에 대단히 중요할 뿐만 아니라, 미래 조직에 대한 계획수립에도

대단히 중요하다. 대부분의 대규모 조직에 있어서 복합체계를 다룰 수 있는 능력

은 제대로 개발되어 있지 않다.

다. C4ISR 능력 개발을 정보기술 실제와 통합

C4I체계의 개발능력 성숙도에 대한 중요한 척도는 C4ISR 능력개발절차와 조직

의 정보기술 실제의 통합이다. 비록 전문적으로 및 체계적으로 연구되지 않았지

만, C4ISR에 대한 정보기술 개발능력에 대한 요구사항은 고수준에 있는 것으로

예상된다. 예를 들면, 정보기술 계획수립능력은 지휘관이 정보기술능력의 가용성

과 군사작전 과정에서 상호운용성을 충분히 알 수 있도록 보장하기 위한 군사작

전 설계의 중요한 부분이 되고 있다.

라. C4I체계 개발을 위한 지식체계

C4I체계 개발은 국방조직의 많은 다양한 분야와 관련되어 있다. 이러한 분야에

전반에 사용되는 지식은 능력의 효과적인 창조, 기술, 구축, 통합, 관리, 재사용,

진화에 핵심적인 요소이다. 지식은 조직의 자산이며, 그러한 지식의 효과적인 산

출 및 관리는 정보기술 개발능력의 중요한 측면이다.

C4I체계의 진화적 개발에서는 많은 활동들이(추론적은 물론 종합적인) 복잡한

상황에서 수행되어야 한다. 이러한 활동을 통해 다음 사항을 포함하는 일련의 결

정에 이르게 된다. : 공학 및 기술 결정, 사업관리결정, 군사작전업무 결정, 그

리고 개발과정 최종 애플리케이션에 있어서 전체 이해당사자들을 대표하는 기

타 형태의 결정. 각각의 결정 시에는 해결되어야 할 문제와 제안된 해결체계 대

한 이론적 근거를 이해해야 한다. 이렇게 이해할 수 있도록 하는 것이 이러한 지

식체계인데, 이러한 지식체계에서는 추론을 위한 맥락을 제공하고, 계획 및 후속

개발이 성공할 것인지 그렇지 않은지에 대한 여부를 주로 결정한다. 그 결과,

C4I체계개발과 관련된 다양한 분야에서 의사결정을 위해, 그리고 지식체계의 유지

를 위해, 일련의 종합적인 지원환경을 개발하는 것이 필요하게 되었다.

C4I체계 개발에 있어서 과거의 경험에 의하면, 문제점과 어려운 점이 주로 정보

기술 실제에 있어서 조직의 미숙한 개발능력에 의해 야기된다는 것이다. 이러한

능력은 전통적으로 공급업체 기반의 실제 또는 기술적 해결책에 의해 결정되는데,

이러한 것으로는 어려운 점을 극복하는데 요구되는 능력 측면에서 제한이 되는

것으로 증명되었다. 비록 여러 가지 기술 및 도구의 개발을 통해 어느 정도 개발

능력을 향상시킬 수는 있지만, 상당한 성숙은 조직 스스로 정보기술 개발능력이

- 4 -

소용되는 분야와 정보기술 실제의 문화 및 관리에 도입되어야 할 변화의 종류에

대한 이해 여부에 달려있다.

C4I체계 개발 분야에서 정보기술 개발능력을 향상시키기 위해 제안된 많은 해

결책들은 아키텍처 개념과 관계가 있다. 현재 가장 유망한 해결책은 조직의 전체

적인 정보기술 실제에 적합한 기업규모의 아키텍처 접근법을 산출 및 채택하는

것이라는 것을 알고 있다.[CAWG, 1997 (1)], [Zachman, 1996], [Meta Group,

1999]

3. 아키텍처 실제 개관

“아키텍처(architecture)”라는 개념은 새로운 개념이 아니라, 다양한 이해관계를

위한 아키텍처에 대해 의견 불일치와 과도한 사용으로 인해 많은 대규모 조직으

로서는 희망, 혼동, 이해, 실망이 혼재되어 있는 개념이다. 대규모 조직 내의 아

키텍처에 대한 복잡성은 2가지 이유로 급속히 증대되고 있다. 첫째, [CAWG,

1997 (1)], [Martin 외, 1994], [Bass 외, 1998], [Zachman, 1996], [Microsoft,

1999], [SEI, 1999], [OIC, 1997], [IAWG, 1998], [ISO 1996], [Pirokla, 1995],

[DISA, 1996], [El-Sakka 외, 1999]와 같이 다양한 목적을 위해 도입된 여러 가지

아키텍처 정의와 관련하여 다양한 아키텍처 산물들이 있다. 둘째, 복잡한 배경을

가진 혼합된 개발 시나리오가 그림 1에 묘사된바와 같이 실재한다.

가. 단일형 및 독립형 체계개발

이러한 형태의 체계개발은 다른 체계와 관련하여 정보기술 애플리케이션을 개

발하기 위해서 전통적으로 사용된 방식이다. 이러한 애플리케이션에 대한 개발을

지원하는데 필요한 아키텍처 문제들은 다음과 같다. : 데이터 아키텍처, 기능 아

키텍처, 프로그래밍 아키텍처, 기타. 이러한 아키텍처는 이러한 단일형 애플리

케이션 각각에 대해 아무런 사전 준비없이 명확하게 개발된다. 이러한 아키텍처

들은 보통 독립형으로서, 데이터도 기능도 공유하지 않으며, 다른 체계와 연동하

지도 않는다.

- 5 -

단일형, 독립형 체계개발

복합체계 관점에서 단일형 체계 개발

복합체계의 진화적 개발

- 데이터 구조- 기능 아키텍처- 프로그래밍 아키텍처- 시스템 아키텍처

- 통합 데이터 모델- 엔터프리이즈 통합

해결책- 플랫폼 통합 해결책- 네트워킹- 아키텍처 프레임워크

- 엔터프라이즈 데이터 모델링- 상호운용성- 공통운용환경(COE)- 통합 지원 메커니즘- 표준- 변경관리- 미래체계 계획수립 및 설계- 기술 아키텍처 프레임워크- 기업 아키텍처 프레임워크

그림 1. 아키텍처 복잡성 문제 증대

나. 복합체계 관점에서 단일형 체계 개발

이러한 형태의 체계 개발은 다른 체계와 제한된 연결상태로 체계를 개발하기

위해 전통적으로 사용되는 방법이다. 이와 같은 체계에 대한 개발을 지원하는데

필요한 아키텍처 문제는 단일형 체계의 아키텍처 문제와 다음과 같은 아키텍처

문제가 추가된다. : 통합 데이터 모델, 엔터프라이즈 통합 해결책, 플랫폼 통합

해결책, 네트워킹, 기타. 아키텍처의 수 및 복잡성 문제가 증대함에 따라 이와

같은 체계들이 또 다른 체계의 데이터든 기능이든 상호 연동해야 할 때에 명백히

드러나게 된다.

다. 복합체계의 진화적 개발

복합체계는 초대형 체계로서, 다수의 컴포넌트(component)로 구성되어 있다.

각 컴포넌트는 본질적으로 하나의 체계이다. 컴포넌트는 한데 합쳐져 고유한 기

능을 수행할 수 있는 초대형 체계를 구성하며, 개별 컴포넌트는 그 스스로 수행할

수 없다. 복합체계의 개발을 지원하는데 필요한 아키텍처 문제는 이전의 2가지

형태의 체계의 아키텍처 문제와 다음과 같은 추가적인 아키텍처 문제를 망라한다.

: 엔터프라이즈 데이터 모델, 상호운용성, 공통운용환경(COE : common

operating environment), 표준, 기술 아키텍처, 기타. 수적 및 복잡성이 증대

하고 있는 아키텍처 문제는 복합체계가 상호간에 그리고 고수준의 상호운용성으

로 국부 및 범세계 영역에 있는 모든 체계와 통신해야 할 때에 명백히 드러난다.

- 6 -

이로 말미암아, 다양한 개발 상황 하에 있어서 아키텍처의 이해관계, 초점, 해결

책은 다양해지는데, 그 이유는 다양한 이해당사자들이 다양한 관심이나 책임을 가

지고 정보기술 개발 능력의 다양한 측면에 기여하기 때문이다. 여러 가지 아키텍

처 정의와 이러한 정의가 도입된 배경을 조사함으로써, 저자들은[Chen 외, 1998,

El-Sakka 외, 1999] “아키텍처”라는 개념에 대한 포괄적이고 종합적인 설명을 전

개하였다.

기본적으로 말해서, 어떤 체계나 개체의 아키텍처는 일련의 관점에 의해 기술되

고 표현되는 그러한 체계에 대한 지식으로 정의되며, 그러한 체계의 이해당사자들

의 관심사와 요구사항을 종합적으로 반영한다. 아키텍처는 다음과 같은 3가지

구별되는 특징/역할을 가지고 있다고 볼 수 있다. : 청사진(새로운 체계를 획득

하기 위한 근거) ; 현행 상황도(기존 체계를 이해하기 위한 근거) ; 로드맵(첫

2가지 특징에 대한 실현을 지원하기 위한 근거)

아키텍처 실제는 신생 및 근본적인 학문분야로서, 아키텍처의 개발, 관리, 사용

에 대한 원칙을 체계적으로 다룸으로써 대규모 조직의 정보기술 개발능력을 향상

시킬 잠재력을 가지고 있다. 이와 같은 실제를 통해 여러 가지 조직의 지식 및

지식체계가 다양한 목적을 위해 구축될 수도 있다.

대부분의 대규모 조직을 위한 아키텍처 실제가 잘 계획 및 관리되지 않음으로

인해, 많은 아키텍처에 의한 접근법을 사용함으로써 얻어지는 아키텍처의 잠재력

은 획득할 수 없다. 이러한 상황은 대부분의 아키텍처 활동에서 일어나는 3가지

공통적인 문제점, 즉 불완전성, 불일치성, 혼란으로 인해 일어난다. 일부 대규

모 조직이나 C4I와 같은 어떤 업무영역에서는 아키텍처 문제가 복잡해짐으로 인

해 심지어 매우 혼란한 상황에 처해 있을 수도 있는데, 이는 놀랄 일도 아니다.

아키텍처 실제의 복잡성은 그러한 실제가 보다 많은 분야를 망라하거나 더욱

다양한 할동들을 포함함에 따라 증대하고 있다. 복잡성 증대에 원인이 되는 여러

가지 요인들이 있다.

- 활동의 다양성

다양한 활동에서 다루어지는 아키텍처 문제는 그림 2에 제시된바와 같이 그들

의 성격 및 성과 측면에서 3가지 주요 분야로 분류하였다.

- 활동과 성과 간의 상호관계

아키텍처 문제에 대해 상세히 조사한 결과 복잡성이 증대하는 것은 아키텍처

- 7 -

활동과 아키텍처 성과 간에 상호관계에 의해 직접적으로 야기된다는 것이 밝혀졌

다. 아키텍처 활동에 의해 만들어진 개별 아키텍처의 역할이든 기여사항의 역할

이든 정보기술 실제에 있어서 다른 산물이나 활동에 영향을 미친다. 기존의 정보

기술 분야에는 이와 같은 상호관계를 명확히 할 수단이 없다.

분야 실례 특징 문제

아키텍처

프레임워크

(접근법)

- Zachman- C4ISR AF- 마이크로소프트 솔루션- RM-ODP- 정보기술 아키텍처- 기타

아키텍처 구축 과정 지도

다양한 프레임워크간 조정

서술적 표현

- 소프트웨어 아키텍처- 엔터프라이즈 아키텍처- 시스템 아키텍처- 아키텍처 저장소- 기타

- 아키텍처에 대한 서술적 산물

아키텍처 산물 관리

지원 환경

- 기술 아키텍처 프레임워크

- 공통운용환경(COE)- 표준/지침- 상호운용성 명세서- 참조 아키텍처- 기타

아키텍처 보조 산물

그림 2. 아키텍처 문제의 다양성

- 활동의 지속성과 병행성

아키텍처 활동의 지속성은 그러한 활동의 성격에 따라 변한다. 전통적인 아키

텍처 구축 실제는 설계자의 업무에 의해 특징이 정해져 구현이 시작되기 전에 종

료된다. 이러한 업무는 기본적으로 사업 전체의 실제가 된다. 그러나 기술 아키

텍처 프레임워크는 그들의 타당성을 유지하기 위한 계속적인 노력이 필요하다.

아키텍처의 병행성은 사업이 통상적으로 복합체계 개발을 위해 병행하여 수행될

때에 명확히 알 수 있다. 따라서 시간 차원은 그 이상으로 구조 문제를 복잡하게

만든다.

- 이러한 실제에 관련된 인원 수

아키텍처 실제는 아마도 다양한 기관 및 공급업체를 위해 일을 하는 사람들이

들어오고 나가는 단체에 있어서 일종의 진행 중인 절차이다. 이와 같은 실천단체

에 있어서, 의사소통 촉진, 지식 공유 및 통합, 지식 관리 및 재사용, 지식 보

존 및 발전은 대규모 조직에 있어서 방법론적으로 필수적이다.

- 8 -

- 정적 산물과 동적 산물의 혼합

개인의 아키텍처 활동은 제한된 관리를 요하는데, 그 이유는 이러한 활동들이

종종 정적(설계와 같은)이든 동적(기술 아키텍처 프레임워크와 같은 살아 있는 문

서)이든 그들 자신의 산물들을 생산하기 때문이다. 그러나 아키텍처 실제는 활동

과 산물들에 대한 상당한 분량의 범 조직적 관리 및 협조를 필요로 한다. 아키텍

처 산물들의 진화는 많은 개인 아키텍처 활동에 있어서 또 다른 난제이다.

저자가 저술한[Chen 외, 1998] 이전의 논문에서는 아키텍처 개발배경이 조직이

자신의 정보기술 개발능력을 조사 및 이론적으로 설명할 수 있는 토대를 제공한다.

복잡도 수준

아키텍처 실제 관리아키텍처 기반 개발 환경

정의된 절차 + 아키텍처 분석 및 추론

지식관리 : 아키텍처 저장소+영역 공학+소프트웨어 아키텍처아키텍처 기반 개발 환경

정의된 절차 + 아키텍처 분석 및 추론

아키텍처에 의한 접근법/아키텍처 프레임워크 : 일련의 관점 + 지침

정의된 절차 + 아키텍처 분석 및 추론

아키텍처 실제 : 분산체계의 개방 및 확장 설계

아키텍처 실제 : 단일 관점의 표현

개별 체계(사업 기반 실제)

복합체계(기업전체 실제)

그림 3. 아키텍처 실제의 복잡성

아키텍처 실제에 관한 체계적인 연구에는 다음과 같은 사항들이 포함된다. : 1)

아키텍처 산물 ; 2) 산물을 생산하기 위한 절차 또는 방법 ; 3) 보다 효과적이

고 효율적으로 작동하는 절차 및 방법을 만드는 지원 환경. 이와 같이, 아키텍

처 실제 연구는 실제의 이론적 근거 및 관리를 다루어야 하며, 또한 조직이 자신

- 9 -

의 정보기술 개발능력을 향상시키기 위해서 채택해야하는 전략을 다루어야 한다.

Zachman 프레임워크, Microsoft 솔루션 프레임워크, TOGAF, C4ISR 아키텍처

프레임 워크 등과 같은 대부분의 아키텍처 프레임워크나 접근법과 아키텍처 실제

를 구별하는 것이 중요하다. 아키텍처 프레임워크나 아키텍처에 의한 접근법은

아키텍처 실제의 진정한 부분인 어떤 아키텍처 관련 활동에 대한 구체적인 관점

에서 일련의 원칙을 통상적으로 제안하고 있다. 아키텍처 실제는 다수의 아키텍

처 프레임워크나 접근법이 정보기술 실제의 다양한 측면을 위해 사용될 수 있는

기업 전체적인 맥락에서 작동한다. 아키텍처 실제는 조직이 모든 아키텍처 관련

활동을 조정, 통합, 관리하는데 도움을 줄 수 있다.

우리는 아키텍처 실제를 정보기술 애플리케이션과 미래 업무개발을 지원하는

일종의 “과학”으로 보는데, 이는 컴퓨팅, 정보체계, 지식공학, 조직연구를 포함하

여 다수의 기타 학문분야와 관련되어 있다. 그러므로 아키텍처에 대한 연구는 다

음과 같은 주요 쟁점을 다룰 방법론을 필요로 한다. :

- 아키텍처 이면의 이론적 근거는 무엇인가?

- 아키텍처 실제는 조직에 의해 요구되는 정보기술능력과 어떻게 관련되어 있

는가?

- 아키텍처 실제는 아키텍처 개념의 잠재력을 획득하기 위해 어떻게 계획, 조

정, 관리될 수 있는가?

- 어떤 종류의 아키텍처 실제 지원 환경이 특정 조직을 위해 개발되어야 하는

가?

- 아키텍처 실제는 다른 관련된 학문분야와 어떻게 관련되어 있는가?

아키텍처 문제에 대한 공통된 이해를 발전시키는데 있어서, 초점을 아키텍처로

부터 아키텍처 실제로 전환하는 것이 아키텍처의 정의와 관련된 일부 혼동을 소

멸케 하는 결과를 가져오며, 또한 다양한 아키텍처 산물 및 절차를 관련시키기 위

한 배경 프레임워크를 제공한다는 것을 알 수 있다.

4. C4I체계 개발을 위한 아키텍처 실제 요구사항

미 국방부는 CI4SR에 대한 아키텍처 실제를 주도해왔다. 미 국방부의 경험 및

성과는 C4I체계 개발에 있어서 연구요원 및 개발요원들에게 건전한 배경 및 풍부

한 정보 출처를 제공해 왔다.

아키텍처라는 개념은 C4I체계 개발의 주요 특징을 다루는데 있어서 광범위하게

- 10 -

사용되어 왔다. 아키텍처를 통해 체계 설계를 정의 및 분석할 수 있는 능력 ;

아키텍처 수준에서 변경사항을 명세서에 기록 및 분석할 수 있는 능력 ; 조직

의 자산 전체에 걸쳐 아키텍처를 창조 및 유지할 수 있는 능력은 조직이 자신

의 정보기술 능력을 발전시키는데 있어서 성공을 위해 대단히 바람직한 사항들

이다. 이와 같은 광범위한 활동을 수행하기 위해서는 통합되고 잘 계획된 아키텍

처 실제가 필요하다.

미 국방부 아키텍처 실제에 대한 연구로부터 얻은 가징 중요한 이점 중의 하나

는 그러한 아키텍처 실제가 대부분의 현행 아키텍처 프레임워크나 접근법에 대한

제한사항을 이해할 수 있는 좋은 기초를 제공한다는 점이다.

가. 엔터프라이즈 규모의 난제

C4I체계 개발에 대한 아키텍처 문제는 전체적으로 국방조직에 도전을 제기하고

있다. 아키텍처 실제에 대한 전반적인 지침에 도달하기 위한 결합도거나 통합된

노력은 성공을 위해 필수적일 뿐만 아니라 대단히 중요하다. 이러한 난제의 해결

은 어떤 단일 아키텍처 프레임워크도 특정 아키텍처 해결책도 아닐 수 있다. 이

들은 유도된 엔터프라이즈 아키텍처 실제로부터 생성되어 그 내에서 작동되어야

만 한다.

나. 정보기술 개발능력 향상

정보기술 개발능력에 대한 수준은 업무 및 기술 계획수립, 설계, 획득, 구현, 유

지보수, 진화 등을 포함하여 정보기술 실제의 다양한 많은 분야의 능력에 의해 결

정된다. 현행 실제는 산물을 다룰 뿐만 아니라 절차를 다루는 여러 이해당사자

및 개발요원들을 수반한다. 일부 아키텍처 프레임워크는 현상유지를 개선할 잠재

력을 보여주고 있다. 아키텍처 실제는 훨씬 광범위한 범위를 가지고 있으며, 조

직이 자신의 능력을 조사 및 향상시킬 수 있는 의미있는 배경을 제공할 수 있다.

모델링 및 시뮬레이션은 효과적이고 강건한 C4ISR 체계의 인도를 보장하기 위해

서 수행될 필요가 있는 대단히 바람직한 활동이다. 이러한 활동들은 차례로 정보

기술 개발 능력의 중추를 형성하는 아키텍처 실제에 의해 잘 통합 및 지원될 필

요가 있다.

다. 운용 아키텍처(운용구조)

미 국방부의 아키텍처 실제에서 사용되는 중요한 개념은 “운용 아키텍처(운용

구조 : Operational Architecture)”이다. 많은 다른 아키텍처 접근법이 C4I체계 개

발의 요구사항을 충족시킬 수 없는 이류를 설명하는 것이 이 개념이다. 국방조직

의 핵심 업무능력은 시간, 상호운용성, 보안, 기타 동적인 특징 분야의 우수성

- 11 -

측면에서 정보기술의 요구사항에 대한 특성을 기술하는 “운용”이란 개념에 의거

구축된다. 운용 아키텍처는 군사작전을 계획하는데 뿐만 아니라 임무를 위해 요

구되는 정보기술 능력의 최초 요구사항을 약술하는데 사용되는 핵심 수단이다.

라. 지식 진화

국방조직이 조직의 경험 및 모범사례를 확정 및 이용하기 위한 방법으로서 체

계적인 모델링에 대한 가치를 인식하는 것이 중요하다. 정보기반 능력개발은 급

속한 속도로 발전하는 공학분야 중에서 독특한 “소프트웨어”에 주로 의존한다.

진화를 무시하는 영역 모델링 또는 소프트웨어 재사용에 대한 접근법은 실패할

수밖에 없다. 잘 관리되고 잘 계획된 아키텍처 실제는 조직의 정보기술 실제에

있어서 조직의 지식획득을 향상시킬 수 있다.[El-Sakka 외, 1999]. 개별 아키텍처

기반 활동이 다양한 단계의 지식획득을 지원할 수도 있지만, 종합적인 아키텍처

실제는 하나의 통합된 아키텍처 업무주기(ABC : architecture business cycle)를

달성하는데 도울 수 있다.(그림 4에 예시된 바와 같이) 아키텍처 업무주기(ABC)

는 아키텍처 관련 활동을 통합하고, 작성, 기술, 동시화, 저장, 재사용을 포함하여

획득주기의 모든 단계에 걸쳐 지원을 제공함으로써 조직의 지식 보존을 촉진한다.

요약하면, C4I체계에 대한 아키텍처 실제는 다음과 같은 주요 목적을 달성해야

한다. :

- “운용(Operation)”이란 개념, 특히 합동작전에서 이러한 개념에 대한 이용을

지원

- 전력 능력으로부터 정보기술 지원능력으로 전역설계절차를 지원

- 조직 모두를 위한 전반적인 지침과 함께 실제를 획득

- 능력개발의 모든 단계에서 지식 획득 및 관리를 개선

- C4I의 모든 수준 및 영역을 위한 기능을 포함하여 정보관리 플랫폼이라고 하

는 아키텍처 실제 지원환경을 달성

5. 호주방위기구(ADO)에 아키텍처 실제 건의

그림 4에 제시된 아키텍처 실제는 다음과 같은 4가지 주요 고려사항을 가지고

있다. :

- C4I 능력개발과 협력하여 정보기술 개발능력을 조사 및 개선하기 위한 프레

임워크를 개발

- 정보체계의 지식을 조직의 자산으로 설계

- 정보기술 실제 분야를 통합 및 관리하기 위한 프레임워크를 달성

- 12 -

- 아키텍처 산물, 아키텍처 구축 절차, 지원 환경을 정의, 개발, 관리를 위한 명

확한 전략적 방향을 가지고 실제를 수행

새로운 체계 기존 체계

아키텍처(청사진) 아키텍처(연관된)

아키텍처구축과정

체계지식 보존

아키텍처 업무주기(ABC)

엔터프리이즈 아키텍처 구축과정

아키텍처 실제 지원 환경

엔터프라이즈 지원 요소 엔터프라이즈 저장소

그림 4. 건의된 아키텍처 실제

예시된 이러한 아키텍처 실제는 다음을 통해 달성된 종합적인 이해에 기반을

둔 것이다. : 1) 아키텍처 역할 조사 ; 2) 미 국방부 아키텍처 실제에 대한 연

구 ; 3) 다양한 아키텍처 방법론 비교. 이 아키텍처 실제는 대규모 조직에 대한

일반적인 절차 지침으로서 사용될 수 있으며, 호주방위기구(ADO)의 아키텍처 실

제를 계획 및 개선하기 위한 출발점으로 제시하였다.

그림 4에 있어서, 제안된 아키텍처 실제는 다음과 같은 2가지 아키텍처 구축

절차를 가지고 있다. : 1개는 청사진 구축절차, 다른 1개는 상황도 구축절차.

이러한 절차 모두는 적합한 아키텍처 프레임워크나 접근법의 사용을 필요로 한다.

예를 들면, 미 국방부의 현행 실제에 있어서, C4ISR 아키텍처 프레임워크[CAWG,

1997 (1)]는 모든 미래 C4ISR체계를 위한 체계 아키텍처 구축절차(SACP :

system architecture construction process)로 아키텍처(청사진)을 개발하기 위해

우선적으로 사용되도록 의무화되어 있다.

아키텍처 관련 분야 [DARPA, 1997], [LM, 1996], [Horowitz, 1994]에 있어서 미

- 13 -

국방부의 기타 구상을 연구한 결과, 우리는 체계 아키텍처 구축절차가 다른 구성

요소와는 격리되지 않았다고 생각한다. 미 국방부에 의해 개발된 JTA, JOA,

LISI, CADM, 기타와 같은 범용 참고사항은 C4I체계 개발을 위한 엔터프라이즈

지원요소의 전형적인 실례들이다. 기존 정보기술능력에 대한 현재 상황도를 입중

하기 위한 엔터프라이즈 구축절차를 포함시킴으로써, 건의된 실제는 엔터프라이즈

지식 보존 및 재사용을 위한 보다 완벽한 측면에서 그러한 배경을 마련해 준다.

건의된 실제와 아키텍처에 의한 접근법(또는 아키텍처 프레임워크) 간의 주

요 차이점은 다음과 같다. :

- 대부분의 아키텍처 접근법은 아키텍처 실제의 일정한 측면에 초점을 두는 아

키텍처 관련 활동을 지도하기 위해서 개발 및 사용된다.

- 아키텍처 실제는 모든 아키텍처 관련 산물, 접근법, 문제, 활동에 대한 배경관

리 원칙에 초점을 둔다. 아키텍처 실제는 아키텍처 프레임워크를 선택하는 방법

과 지원환경 및 체계 아키텍처에 대한 요소를 개발하는 방법에 관한 합리적인 제

안 및 지침을 제공할 수 있다.

아키텍처 실제의 주 특징 중의 하나는 개발요원들이 다른 개발요원들에 의해

생성된 자원을 가장 잘 사용할 수 있도록 자신들의 업무를 계획 및 수행할 수 있

는 잘 정의된 배경 제공이다. 실제는 배경에 적합하도록 조정될 수 있는 한 다양

한 프레임워크 간에 조정을 용이하게 한다.

엔터프라이즈 아키텍처 구축절차(EACP : enterprise architecture construction

process)는 조직의 지식보존을 달성하는데 도움을 준다. 이러한 절차는 전통적인

소프트웨어 공학 분야에 의해 고려되지 않는바, 기본적으로 특정 체계를 개발하는

데 있어서 개발요원들을 지도한다. 이와 같은 지침은 C4I체계의 진화적 개발이라

는 현실에 의해 도전을 받는데, 그 이유는 지침이 정보기술 능력을 획득하는데 있

어서 조직의 장기적 이익과 공급업체의 이익이나 사업기반 이익 간에 구별할 수

없기 때문이다.

미 국방부의 합동 C4ISR 아키텍처 계획수립/분석체계(JCAPS : Joint C4ISR

Architecture Planning/Analysis System)는 아키텍처 실제 지원 환경을 계획 및

개발하는 방법에 대한 일부 통찰사항을 제공한다. 이러한 환경은 능력개발의 다

양한 분야에 다양한 인터페이스 요소나 서비스를 제공한다.

기능분야(사용자들)와 연관된 인터페이스 요소(서비스)들은 여러 아키텍처 관련

활동에서 다양한 기관에 의해 만들어진 동일한 정보 및 지식 자원을 공유 및 사

- 14 -

용한다. 다시 말해서, 동일한 자원에 기반을 둔 일련의 다양한 지원 기능은 다양

한 애플리케이션 시나리오에 맞게 개발될 수 있다.

아키텍처 실제 지원환경(APSE : Architecture Practice Supporting

Environment)은 아키텍처 실제의 중심에 있다. 지원요소 및 그 저장소는 요소

또는 자원 전체에 걸쳐 아키텍처 계획수립 및 분석을 위한 접근성 및 기능을 제

공하기 위해서 통합될 수 있다. 그 이상의 연구에서는 APSE에 의해 지원될 관

점에 대한 설계 및 개발에 대해 다룰 것이다.

엔터프라이즈(체계) 아키텍처 저장소(EAR : Enterprise Architecture

Repository)는 엔터프라이즈 아키텍처 구축절차(EACP)에 의해 생성되는 정보의

저장소이다. EAR는 항상 기존 정보기술 능력의 확실한 상황도이다. 이러한 정

보는 구현 이전에 다양한 방법이나 표현을 사용하여 생성된 체계 아키텍처(청사

진)과는 다르다. EAR는 일관성 있는 표시법을 사용함으로써 동시화된 형식으로

표현된다. 표기법은 필요한 정보만을 포착하기 위해서 그리고 EAR의 일부로서

유지되지 않는 경우에 청사진을 포함하는 기타 연관된 자원을 참조하기 위해서

사용된다.

사용자

서비스

시설

자원

기여기관

공급업체

항법/분석/시뮬레이션/...../도구

엔터프라이즈 관점 관리

지원 요소 아키텍처 저장소

공급업체

그림 5. 호주방위군(ADO)에 대한 권장 아키텍처실제 지원환경(APSE)

아키텍처실제 지원환경(APSE)을 수행하는 비용은 너무 비싸지 않은가? 그 대

답은 사용된 기호법과 정의된 절차에 따라 “다르다.” 기존 체계에 대한 현재 상

- 15 -

황도는 미래 개발을 위해 이용할 수 있어야 한다.

지원환경을 사용하는 것에 대한 중요성은 권장 실제에 의해 다루어질 수 있는

C4I체계 개발의 그러한 특징을 조사함으로써 정당화될 수 있다.

- 진화적 개발은 혼란스러운 실제로부터 적절한 지원없이 다루기 쉬운 절차로

바뀔 것이다. 상호운용성은 지원 환경에 의해 통합되고 접근 가능한 아키텍처 산

물들을 사용하여 다루어질 것이다.

- 정보기술 개발능력은 체계 아키텍처 구축절차(SACP)를 위해 적합한 아키텍

처 프레임워크를 채택함으로서 향상될 것이다. 엔터프라이즈 아키텍처 저장소는

현재 상황도로서 역할을 할 것이며, 엔터프라잊 지원 요소들은 조직이 복합체계를

다룰 수 있도록 로드맵으로서 역할을 할 것이다. 지원환경은 체계 아키텍처 구축

절차(SACP)를 지원하기 위해서 가용한 복합체계에 대한 모든 지식을 이용하고

모델링 및 시뮬레이션과 같은 유용한 기능을 제공할 것이다.

- 관련된 능력개발 분야에서 기능과 자원의 통합은 달성 가능하게 된다. 권장

실제에 있어서 모든 관련 기관들은 지원환경에 기여해야 하며, 또한 타당성을 유

지할 책임이 있다.

- 지식 획득, 관리, 진화에 대한 지원[El-Sakka 외, 1999년]은 조직이 자신의

지적 투자를 보존하고 자신의 업무를 보다 효율적 및 비용 효과적으로 운용하는

데 도움을 줄 것이다.

따라서 아키텍처 실제를 연구하는 이점은 다음과 같다. :

- 아키텍처 실제가 정보기술 개발능력에 있어서 조직의 기대에 대비하여 어떤

아키텍처 실제가 제공되어야 하는지에 대해 보다 잘 종합적으로 이해할 수 있다.

- 국방조직의 신생 및 중요 능력으로서 C4I체계에 대한 수명지원을 통해

- 조직의 지식 획득을 개선하고 보다 나은 재사용을 보장한다.

6. 아키텍처 실제 성숙도(APM)

아키텍처 실제는 중요하며 상당한 잠재력을 가지고 있다. 하지만, 계획 없이

격리된 아키텍처 관련 활동을 수행하는 것으로는 성공적인 아키텍처 실제를 보장

하기에 충분하지 않다는 것을 깨달아야 한다.

일반적으로 말해서 아키텍처 실제 성숙도(APM : Architecture practice

maturity)는 다음과 같은 2개 요소에 의해 결정된다. : 개별 요소의 관장범위 및

성숙도, 실제에 있어서의 활동. 그림 3에서 보는바와 같이, 아키텍처 실제 성숙

- 16 -

도(APM)는 그 자체의 복잡도와 관계가 있다. 높은 수준의 아키텍처 실제의 성

숙도 수준은 높은 수준의 복잡도를 수반한다. 그러나 아키텍처 실제에 있어서 높

은 수준의 복잡도는 높은 수준의 성숙도를 보장할 수 없는데, 그 이유는 개별 노

력, 산물, 관리 및 협조의 성숙도 수준 모두가 중요한 요소이기 때문이다.

아키텍처 실제 성숙도(APM)란 개념을 다루기 위한 충분하고 체계적인 연구가

수행되지 않았다. SEI 모델을 사용하여 메타 그룹[Meta Group, 1999년]에 의해

이루어진 아키텍처 실제 성숙도 수준을 분류함에 있어서 노력은 흥미로운 일이나,

오로지 어떤 일정한 측면, 주로 엔터프라이즈 규모 기술 아키텍처(EWTA :

enterprise-wide technical architecture)와 “저장소”로 불리는 산물만을 망라하고

있다.

아키텍처 실제를 개선하기 위해 사용된 사항은 조직들 간에 다를 수도 있다.

그러나 아키텍처 실제의 주목적에 이르기 위해서는 일정한 문제와 난제들이 대부

분의 대규모 조직에 보편적이어야 한다.

- 전략적 계획수립 및 관리 결정

- 실제의 배경 정의

- 적합한 프레임워크 및 접근법 선정 또는 개발

- 지원 요소를 포함하여 아키텍처 실제 지원환경(APSE)을 정의 및 개발

대규모 조직에 있어서 아키텍처 실제의 급속한 성장은 다음 세기 10년 동안에

두드러진 추세가 될 것이다.[Meta Group, 1999년] 이는 보다 나은 실제를 달성하

는 측면에서 연구요원을 물론 실무요원들 모두에게 도전적인 일이다. 아키텍처

실제가 성장해야 하는 이유 및 방법과 같은 질문은 과학, 기술, 관리를 포함하여

다양한 관점에서 다루어질 필요가 있다.

그러나 C4I체계 개발에 있어서, 다양한 임무 지향 작전을 위해 여러 수준의 군

사계층에 있어서 “운용(operation)”이란 개념을 다룰 수 있는 능력은 그러한 능력

의 지원환경을 다른 일반적인 정보기술 아키텍처 실제 지원환경과 차이가 난다.

방위작전과 연관된 지식체계를 관리하기 위해서 전력 명세서 및 운용 참조아키

텍처와 같은 다수의 중요한 개념들을 정의하는 것은 C4I 능력개발 및 정보기술

실제의 성공적인 통합을 위해 필요한 조치이다. 이러한 개념들과 연관된 적절한

아키텍처 산물들에 대한 성공적인 개발이 없으면, 아키텍처 실제는 성숙하지 못할

것이다.

- 17 -

비록 일부 활동들이 외부 역할수행자들에 의해 수행될 수 있을 지라도 아키텍

처 실제는 모조리 하청을 주지 말며 주어서도 안 된다. 아키텍처 실제가 하청되

는 정도는 문제가 될 수 있는데, 조직의 특성에 좌우될 것이다. C4I체계 획득은

거의 항상 산업계를 포함한다. 따라서 공급업체의 아키텍처 활동에 대한 지도 및

감독은 체계 아키텍처 구축절차(SACP)와 아키텍처 실제 지원환경(APSE)을 통해

다루어지고 구현되어야만 한다.

아키텍처 실제에 대한 계획수립 및 합리와는 쉬운 과업이 아니다. 아키텍처 실

제 성숙도는 대규모 조직은 물론 산업계에게 있어서도 도전적인 문제이다. 아키

텍처 실제에 대한 기회가 조직은 물론 산업계에 의해 실현되는 경우, 그 때에는

정보기술 실제의 문화 및 절차에 있어서 상당한 변화가 될 것이다. 변화는 보다

관리하기 쉬운 환경으로 이어져야 한다.

7. 결론

C4I체계를 개발하기 위해서는 국방조직이 단지 개별 아키텍처 산물들 보다 조

직의 아키텍처 실제에 더 많은 관심을 가져야 한다. 아키텍처 실제에 대한 정교

한 이해와 효과적인 관리 없이 조직은 고수준의 정보기술 개발 능력을 달성하기

어렵다. 아키텍처 실제의 명확한 측면을 다루기 위해 많은 개별 아키텍처 산물들

이나 아키텍처 접근법이 개발될 수 있다는 것을 알아야 한다. 개인의 노력과 이

러한 노력들 사이의 효과적인 협조가 결합되는 것이 중요한바, 잘 계획되고 잘 관

리된 아키텍처 실제를 통해 달성되어야만 한다. 오로지 잘 계획되고 잘 관리된

아키텍처 실제만이 아키텍처의 완전한 잠재력을 실현할 수 있다.

8. 참고문헌

[AFRL, 1998] Air Force Research Lab. (AFRL), Joint C4ISR Architecture

Planning/Analysis System (Concept of Operations), 1998.

[Bass et al., 1998] L. Bass, P. Clements and R. Kazman, Software Architecture

in Practice, Addison-Wesley Longman, 1998.

[CAWG, 1997 (1)] The C4ISR Architecture Working Group (AWG), C4ISR

Architecture Framework (Version 2.0), December 1997.

[CAWG, 1997 (2)] The C4ISR Architecture Working Group (AWG), C4ISR

Core Architecture Data Model, Version 1 (CADM), September 1997.

- 18 -

[CAWG, 1997 (3)] The C4ISR Architecture Working Group (AWG), Levels of

Information Systems Interoperability (LISI), March 1998.

[Chen et al., 1998] Pin Chen, Abdel El-Sakka, and Jennie Clothier, Context

Analysis of Architecture Practice within Large Organizations, Proceedings of

the Australasian Workshop on Software Architectures, pp 2-13, Melbourne,

November, 1998.

[DARPA, 1997] Information Technology Office (ITO), DARPA, Evolutionary

Design of Complex Software, Technology Showcase, 1997.

[DISA, 1996 (1)] Defence Information Systems Agency (DISA), US DoD,

Defence Information Infrastructure (DII), Common Operating Environment

(COE), 20 March 1998.

[DISA, 1996 (2)] Defence Information Systems Agency (DISA), US DoD,

Technical Architecture Framework for Information Management (TAFIM),

V3.0, 30 April 1996.

[El-Sakka et al., 1999] Abdel El-Sakka, Pin Chen and Jennie Clothier,

Knowledge Acquisition Improvement through Enterprise Architetcure

Practice, Proceedings of the Software Engineering Australia 1999 (SEA’99),

Canberra, April, 1999.

[IAWG, 1998] IEEE Architecture Working Group (AWG), IEEE Recommended

Practice for Architectural Description, IEEE Std 1471, Draft Version 3.0, 3

July 1998.

[ISO, 1996] Information Standards Organization (ISO), Open Distributed

Processing . Reference Model (ODP-RM), ISO/IEC DIS 10746-2, and

ISO/IEC DIS 10746-3, 1996.

[Horowitz, 1996] B. M. Horowitz, The Importance of Architecture in DoD

Software, Guidelines for Successful Acquisition and Management of

Software-Intensive Systems, June 1996.

- 19 -

[LM, 1996] Lockheed Martin (LM) Tactical Defense Systems, Organization

Domain Modeling (ODM) Guidebook (Version 2.0), 1996.

[Martin et al., 1994] E. W. Martin, D. W. DeHayes, J. A. Hoffer and W. C.

Perkins, Managing Information Technology, Prentice Hill, International

Edition, 1994.

[Meta Group, 1999] Meta Group, Enterprise Architecture Strategies (EAS),

Meta Delta, 31 March 1999.

[Microsoft, 1999] Microsoft, Glossary and Acronym,

http://www.microsoft.com/hwdev/glossary.htm, 1999.

[NRC, 1999] National Research Council (NRC), Realising the Potential of C4I:

Fundamental Challenges, National Academy Press (Prepublication Draft),

1999.

[OIC, 1997] Object Ideas Corporation (OIC), Enterprise Architecture Modelling,

October 1997, http://www.object-ideas.com/eamdl/tsld001.htm.

[Pirkola, 1995] Gary Pirkola, An Information Technology (IT) Architecture for

Information

Technology Division, University of Michigan, August 1995,

http://www-personal.umich.edu/~gpirkola/IT_arch_doc/Phase1Doc.html.

[SEI, 1999] Software Engineering Institute (SEI), Definitions on Architecture,

http://www.sei.cmu.edu/architecture/definitions.html, 1999.

[Zachman, 1996] J. Zachman, Enterprise Architecture: The Issue of the

Century, http://www.zifa.com/zifajz01.htm., 1996.