A Dynamic Orchestration Framework for Supporting Sustainable Services in IT Ecosystem

전체 글

(1)IT 생태계의 지속적인 운영을 위한 동적 오케스트레이션 프레임워크 549. KIPS Tr. Software and Data Eng. Vol.6, No.12 pp.549~564 pISSN: 2287-5905. https://doi.org/10.3745/KTSDE.2017.6.12.549. A Dynamic Orchestration Framework for Supporting Sustainable Services in IT Ecosystem †. Park Soo Jin. ABSTRACT Not only services that are provided by a single system have been various with the development of the Internet of Things and autonomous software but also new services that are not possible before are provided through collaboration between systems. The collaboration between autonomous systems is similar to the ecosystem configuration in terms of biological viewpoints. Thus, it is called the IT Ecosystem, and this concept has arisen newly in recent years. The IT Ecosystem refers to a concept that achieves a mission of each of a number of heterogeneous systems rather than a single system utilizing their own autonomy as well as achieving the objectives of the overall system simultaneously in order to meet a single common goal. In our previous study, we proposed architecture of elementary level and as well as basic several meta-models to implement the IT Ecosystem. This paper proposes comprehensive reference architecture framework to implement the IT Ecosystem by cleansing the previous study. Among them, a utility function based on cost-benefit model is proposed to solve the dynamic re-configuration problem of system components. Furthermore, a measure of using genetic algorithm is proposed as a solution to reduce the dynamic re-configuration overhead that is increased exponentially according to the expansion of the number of entities of components in the IT Ecosystem. Finally, the utilization of the proposed orchestration framework is verified quantitatively through probable case studies on IT Ecosystem for unmanned forestry management. Keywords : IT Ecosystem, Orchestration, Cost-Benefit Model, Genetic Algorithm, Self-Adaptive Software. IT 생태계의 지속적인 운영을 위한 동적 오케스트레이션 프레임워크 †. 박 수 진. 요. 약. 자율성을 가지는 소프트웨어와 사물 인터넷 기술 등의 발달로 단일 시스템이 제공하는 서비스들이 다양해짐은 물론, 기존에는 상상하지 못 했던 새로운 서비스들이 시스템간의 협업을 통해 제공되고 있다. 자율성을 가지는 시스템 간의 협업은 마치 생물학적 관점에서의 생태계 구성 과 닮아 있다는 점에서 IT 생태계의 개념이 근래 들어 새롭게 대두되었다. IT 생태계란 단일 시스템이 아닌 다수개의 이기종 시스템들이 하나 의 공통된 목적을 달성하기 위해 각자의 자율성을 활용하여 자신의 미션을 달성하는 동시에 전체 시스템 그룹의 목적을 이뤄나가는 개념이다. 우리는 앞선 연구에서 IT생태계 구현을 위한 기본적인 몇 가지 메타모델과 초보적인 수준의 아키텍처를 제안한 바 있다. 본 논문은 이러한 선 행연구를 정제하여 IT생태계 시스템 구현을 위한 참조 아키텍처 프레임워크를 제안하고 있다. 제안된 프레임워크는 시스템 구성원의 동적 재구 성 문제에 비용-혜택 모델을 기반으로 하는 유틸리티 함수와 IT생태계 구성원의 개체 숫자 확장에 따라 기하급수적으로 증가하는 동적 재구성 오버헤드를 감소시킬 수 있는 해결책으로서의 유전자 알고리즘 활용 방안을 포함하고 있다. 무인삼림관리를 위한 IT 생태계 시스템이라는 개연 성 있는 사례 연구를 통해 제안된 프레임워크의 효용성을 정량적으로 검증하고 있다. 키워드 : IT 생태계, 오케스트레이션, 비용-혜택 모델, 유전 알고리즘, 자가적응형 소프트웨어. 1. 서 론. 일상을 둘러 싼 기기들 중 상당수는, 정도의 차이는 있으나,. 우리는 대부분의 시간을 소프트웨어 어플리케이션이 탑재. 한, 클라우드 컴퓨팅이나 사물인터넷(Internet of Things:. 된 다양한 형태의 기기들을 접하며 생활하고 있다. 우리의. IoT)과 같은 새로운 시스템 운영 패러다임의 출현은 일상에. 1). 스스로 생각하고 판단하는 능력을 이미 탑재하고 있다. 또. 서 접하는 소프트웨어 제품들이 더 이상 단일 시스템에 탑 †종신회원 : 서강대학교 기술경영전문대학원 조교수 Manuscript Received : September 8, 2017 Accepted : September 14, 2017 * Corresponding Author : Park Soo Jin([email protected]). 재되어 서비스를 제공하는 것이 아니라, 다양한 이기종 시 스템간의 협업을 기반으로 구동되는 복합시스템, 혹은 복합 서비스의 형태로 전환되고 있음을 시사한다..

(2) 550. 정보처리학회논문지/소프트웨어 및 데이터 공학 제6권 제12호(2017. 12). 최근 들어, 이 같은 기술적 변화를 배경으로 제안된 시스. 범위로 확장시키고자 하였다.. 템 운영 개념 중 하나가 IT생태계(IT Ecosystem) [1] 운영. 우리는 이미 선행연구[8]에서, IT 생태계를 모델링하기. 개념이다. IT 생태계는 지역적인 적응성(local adaptiveness). 위해 주요한 몇 가지의 메타모델을 제시하고, 그에 따라 명. 를 가지는 개별 시스템들이 상호 작용하면서 협업해 나가는. 세된 IT 생태계 구축을 위한 개념적 아키텍처(conceptual. 하나의 복합 시스템 운영 개념을 일컫는다. 생태계 공동의. architecture)를 제안한 바 있다. 또한, 제안된 개념적 아키텍. 목표 달성을 위해, 구성원들의 형상을 변경해 나가면서 주. 처를 기반으로, 시뮬레이션 환경에서 동작 가능한 IT생태계. 어진 환경에 적응해 나가는 모습이 생물학적 측면에서의 생. 사례도 개발하였다[9]. 본 논문에서는 이와 같은 선행 연구 결. 태계 진화 과정과 유사하여, IT 생태계라 명명되었다. IT 생. 과를 토대로 설계된 IT 생태계 운영을 위한 하나의 일반적인. 태계 운영의 주요 이슈는 생태계에 참여하는 단일 시스템들. 참조 아키텍처 프레임워크(a generic reference architecture. 의 자율성을 확보하는 것과 동시에, 전체 IT 생태계가 지속. framework)를 제안하고, 제안된 일반적인 참조 아키텍처 프. 적으로 생존해 나가기 위한, 보이지 않는 제어 메커니즘을. 레임워크를 사례 연구 대상인 무인삼림관리를 위한 IT 생태. 확보하는 데 있다.. 계 도메인으로 개체화(instantiation)해 나가는 과정을 통해,. 우리는 IT 생태계의 지속적인 생존을 위한 제어 장치로. 프레임워크에 포함된 동적 형상 재배치 메커니즘을 설명해. 자가적응형 소프트웨어(self-adaptive software) 관련 연구분. 나간다. 제안된 프레임워크는 IT 생태계의 구성 멤버인 개. 야에서 제안하는 컴포넌트의 동적 재배치 기법을 선택하였. 별 시스템이 적절한 서비스를 제공하는 데 필요한 지역 적. 다. 자가적응형 소프트웨어 분야에서 최근까지 발표되어 온. 응(local adaptation)과 IT 생태계 전체의 협업 성능을 스스. 주목할만한 연구들[2-4]은 주로 MAPE-K(Monitor-Analyze-. 로 유지해 나가기 위한 전역 적응(global adaptation)을 구동. Plan-Execute plus Knowledge) loop[5]를 다양한 분야의 도. 시키기 위한 메커니즘을 모두 포함하고 있다. 그러나, 본 논. 메인 어플리케이션에 적용하고, 그 결과에 대해 논의하고. 문에서는 두 가지 적응 메커니즘 중, IT 생태계 전체의 형상. 있다. MAPE-K loop란, 소프트웨어 시스템이 스스로 시스. 을 변경시켜 나가기 위한 전역 적응 메커니즘, 즉 IT 생태계. 템 내외부의 문맥(context) 변화를 모니터링하여(M), 분석. 를 아우르는 오케스트레이션 메커니즘에 초점을 맞추고 있. (A)한 결과, 소프트웨어가 변화되어야 한다고 판단되는 경. 다. 기존 연구들과 비교하여 본 논문에서 제시하는 연구 결. 우, 적절한 시스템 형상 재배치 계획을 수립하고(P), 실행. 과가 가지는 차별성은 실질적으로 동작하는 IT 생태계 사례. (E)하기까지 4단계 프로세스로 이뤄진 피드백 loop와 각 단 계를 수행하는 컴포넌트, 그리고 구성 컴포넌트들 사이의 공유 지식(K)까지를 포함하는 하나의 아키텍처를 일컫는다. MAPE-K loop가 개념적으로 소프트웨어의 자가 적응 행위 구현을 지원하는 데 있어서 효과적인 참조 아키텍처라는 것 에 이견은 없으나, 기존의 MAPE-K관련 연구 결과들은 적 응의 구현 범위를 단일 시스템 내부의 컴포넌트의 구성이나 내부 컴포넌트가 가지는 역량을 동적으로 변경시키는 데 국 한시키고 있다는 한계가 있었다. 본 연구는 MAPE-K를 기반으로 하는 적응의 범위를 단 일 시스템에서 복합시스템의 영역으로 확장시켜, IT 생태계 에 참여하는 구성 시스템 그룹이 환경 변화에 대응하면서도 일정한 품질의 협업 서비스를 제공하도록 하는 방안을 제시 하고자 한다. IT 생태계 구축과 관련된 연구 결과들[1, 6, 7]. 에 제안된 메커니즘을 적용하고, 그와 같은 통해 검증한 정 량적 실험 결과 분석을 제시함으로써, 제안된 아키텍처 프레 임워크의 효용성을 입증하고 있다는 점에서 찾을 수 있다. 본 논문의 이후 구성은 다음과 같다. 먼저, 2장에서는 개 념적인 측면의 참조 아키텍처를 설명한다. 3장에서는 사례 연구의 대상 어플리케이션인 무인삼림관리를 위한 IT 생태 계 시스템의 동작환경에 대해 간략히 소개하고, 4장에서는 2 장에서 소개한 참조 아키텍처를 기반으로 개체화시킨 실질 적인 아키텍처 프레임워크의 구성 컴포넌트들에 의한 IT 생 태계의 동적 재구성 메커니즘을 소개한다. 5장은 제안된 아 키텍처 효용성 검증 결과에 대한 정량적 분석 자료들을 제 시하고, 6장에서는 기존의 자가 적응형 메커니즘 관련 연구 들을 간단히 비교한 후, 마지막 7장에서 본 연구의 결론과 향후 연구계획을 밝히고 있다.. 에서도 생태계 운영을 위한 다양한 형태의 프레임워크들을 제안하고 있기는 하나, 대부분이 현재까지는 실질적으로 구. 2. IT 생태계를 위한 참조 아키텍처. 동 가능한 것이라기 보다는, IT 생태계 개념 적용이 가능한 도메인 시스템 운영 시나리오들을 제시한다거나, 개념적인. 우리는 선행 연구[8]를 통해, Organization-based Multi-agent. 레벨에서의 참조 아키텍처를 제안하는 데 머무르고 있다.. System Engineering (O-MaSE) [10]을 기반으로 참여 시스. 따라서, 우리는 본 연구를 통해, 기술적인 측면에서는 자가. 템(Participants)들간의 협업과 시스템 범위의 목표(goal)들. 적응형 소프트웨어 개발 기술과 IT 생태계 개념의 접점 위. 을 명세함으로써, IT 생태계를 규정하기 위한 메타모델을. 치에서, 자가 적응형 소프트웨어 기술의 동적 재배치 메커. 제안하였으며, 이를 수정 보완하여 Fig. 1에서 보이는 바와. 니즘을 단일 시스템의 내부로부터 전체 IT 생태계 운영의. 같은 메타모델을 완성하였다..

(3) IT 생태계의 지속적인 운영을 위한 동적 오케스트레이션 프레임워크 551. Fig. 2. Example of Hierarchical Control Pattern [11]. 조 아키텍처 모델은 Fig. 3과 같다. 전체적인 구조는 IT 생 Fig. 1. Metamodel for IT Ecosystem. 태계의 오케스트레이션 목표를 성취하기 위한 MAPE-K loop 하나와 서비스 목표 달성을 위한 N개의 MAPE-K loop가 상하위 계층을 구성하고 있는 형태이다. N개의 참여. Fig. 1의 메타모델을 살펴보면, IT 생태계에서 달성해야. 시스템 각각은 각자의 역할 수행을 위해 스스로의 서비스. 할 목적은 IT 생태계에 참여하는 각각의 자율성을 가지는. 수행 상태를 평가하기 위한 항목들을 정의하고 평가 항목에. 시스템(participant)에 대한 요구사항들을 명세하기 위한 서. 따라 수집된 정보들은 로컬 시스템에 저장한다. 이렇게 저. 비스 목표(service goal)와 전체 IT 생태계의 운영 성능과. 장된 로컬 지식 중 전역 지식(global knowledge)에 반영되. 품질을 명세하기 위한 요구사항인 오케스트레이션 목표. 어야 할 정보들은 전역지식 저장소에 주기적으로 업데이터. (orchestration goal), 두 가지로 분류된다. 각 참여 시스템. 하여, IT 생태계 구성원들간의 정보를 공유해 나간다. 이 같. (participant)는 하나 이상의 역할(role)을 수행하며, 각각의. 은 일련의 작업은 팀멤버<<Role>> TeamMember 역할을. 역할 수행을 위해서 필요로 하는 역량(capability) 집합이 정. 맡은 시스템들에 탑재되는 서비스 계층에서 수행된다.. 의되어 있다. 각각의 역량은 특정한 계획(plan)수행과 관련 된 행위(action) 집합으로 정의된다.. 오케스트레이션 층에서 구동하는 MAPE-K loop은 현재 협업에 참여중인 시스템들의 협업상태나 가용성 등을 측정. Fig. 1의 메타모델에 의해 명세 가능한 IT 생태계를 운영. 하기 위한 별도의 평가 항목을 정의하여 지속적으로 모니터. 하기 위한 일반적인 개념모델(generic conceptual model)로. 링(M)해 나간다. 측정된 협업 성능이 IT 생태계 운영을 위. 서의 참조 아키텍처를 구성하기에 앞서, 참조 아키텍처가. 한 목표치를 상회하지 못할 경우, 그 원인을 분석하여(A),. 만족시켜야 할 두 가지 요구사항을 정의하였다. 첫째, 아키. 기존에 문제가 되는 참여 시스템을 협업에서 제외시키거나. 텍처는 각각의 참여 시스템에게 주어지는 서비스 목표 달성. 새로운 후보 시스템을 협업에 참여시키는 등의 계획을 수립. 을 위한 N개의 MAPE-K loop와 전체 IT 생태계의 오케스. 하고(P), 이를 실행한다(E). 오케스트레이션 목표 성취를 위. 트레이션 목표 달성을 위한 하나의 MAPE-K loop 간의 관. 한 MAPE loop는 팀리더<<Role>> Team Leader 역할을. 계를 설명하여야 한다. 둘째, 두 가지 서로 다른 목표 모델. 맡은 시스템에 탑재되는 오케스트레이션 계층의 컴포넌트들. 을 성취하기 위한 MAPE-K loop을 수행하는 참여시스템들. 에 의해 수행된다.. 의 역할이 명백히 정의되어야 하며, 각 역할자들 사이의 협 업을 위한 프로토콜이 명시되어야 한다.. Fig. 3의 오른쪽에 도식화된 오케스트레이션 목표 모델과 서비스 목표 모델은 3장에 소개할 무인삼림관리를 위한 IT. 우리는 두 가지 요구사항을 만족시킬 아키텍처 프레임워. 생태계를 대상으로 한 모델의 일부분을 단편적으로 보여준. 크의 베이스 패턴으로, [11]에서 제안하는 몇 가지 다중. 다. “최적의 참여 시스템 조합을 운영한다”와 같이 전체 IT. MAPE-K loop 분산 패턴들 중에서, 계층적 제어 패턴(Fig.. 생태계에 적용되는 포괄적인(generic) 목표들이 오케스트레. 2)을 선택하였다. 계층적 제어 패턴은 여러 개의 지역적으로. 이션 목표 설정의 예가 될 수 있다. 반면, “화재를 진압한. 다른 공간에 존재하는 다수 개의 자가 적응형 시스템들이. 다”와 같이 참여 시스템들에 탑재된 역량을 바탕으로 이뤄. 하나의 생태계 구성원과 같이 협업해 나가는 IT 생태계의. 지는 기능적인 협업의 결과 성취되는 목표들이 서비스 목표. 맥락에 가장 적합하다. Fig. 2에 도식화된 패턴을 살펴보면,. 모델에 명세된다. “화재를 진압한다”는 상위 목표를 성취하. N개의 MAPE-K loop들은 독자적으로 수행되고 있지만, 각. 기 위해 정의된, 화재 상황을 발견하거나, 진입도로를 확보. 각의 MAPE-K loop에서 모니터링 하는 모듈(M)들과 실제. 하거나, 실제 진화 작업을 하는 등의 하위 서비스 목표를. 감지된 환경변화에 대응하는 수행을 담당하는 모듈(E)들은. 어떤 참여시스템이 담당할 것인지는 각 참여시스템이 가지. 로컬 정보를 공유하거나, 각 시스템의 역량을 공유하는 형. 는 역량에 의해 결정된다.. 태로 연결되어 있음을 확인할 수 있다. 이를 바탕으로 정제한 IT 생태계 운영을 위한 개념적 참. 예를 들어, Fig. 1의 메타모델을 개체화하여 명세한 무인 헬기 타입의 개체들은 <<capability>> 요소로는 센서와 액.

(4) 552. 정보처리학회논문지/소프트웨어 및 데이터 공학 제6권 제12호(2017. 12). Fig. 3. A Conceptual Architecture of IT Ecosystem for Accomplishing Two Different Goal Models: Service Goal and Orchestration Goal: M (Monitor), A (Analyze), P (Plan), E (Execute), App. (Application), S (Sensor), A (Actuator). 츄에이터를 각각 하나씩 탑재하고 있으며, 수행 가능한 행. 헬기 타입의 참여 시스템은 화재 진압이라는 서비스 목표의. 위로는 GetStatus와 Sensing이 구현되어 있음을 Fig. 4의. 하위 목표인 “화재 식별(Detect Fire)”을 성취하는데 필요한. 모델을 통해 확인할 수 있다. 이런 속성들을 고려하면, 무인. 역량을 가지고 있는 것으로 판단 가능하다. 팀리더 역할을 수행할 참여 시스템은 IT생태계 참여 시스 템 중에서 선출된다. 팀리더 시스템의 선출은 역량 면에서 가 장 우수한 시스템, 혹은 현재 가장 높은 가용성(availability) 을 가지는 시스템 등과 같이 미리 정의된 선출전략에 따른 다. 팀리더로 선정된 시스템은, 클라우드에서부터 오케스트 레이션 계층에 속하는 MAPE 관련 컴포넌트들을 검색한 후 그것들을 시스템에 바인딩하여 전체 IT 생태계의 형상을 제 어하는 역할을 수행한다. Fig. 5는 “최적기기조합운영(Run Optimal Participants)” 이라는 오케스트레이션 목표 달성을 위해 팀리더 시스템의 초기화 이후부터 수행되는 팀리더 시스템과 팀멤버 시스템 간의 협업 프로토콜을 정의하고 있다. 팀리더는 정해진 주 기에 따라 팀멤버들의 상태를 모니터링한다. 현재 팀멤버 역할을 담당하는 다양한 참여 시스템에 탑재된 센서와 액츄 에이터로부터 수집된 자료들을 기반으로 협업 성능의 지표 가 되는 협업점수(collaboration score)를 산정한다. 산정된 협업점수가 기준값 이하일 경우, 새로운 최적의 참여시스템 조합을 재구성한다. 이때, 협업점수는 일종의 유틸리티 함수 값이다. IT 생태계가 만족시켜야 하는 오케스트레이션 목표 나 서비스의 종류에 따라 유틸리티 함수에서 사용하는 평가. Fig. 4. An Example of Participant System: Helicopter. 항목은 상이하다..

(5) IT 생태계의 지속적인 운영을 위한 동적 오케스트레이션 프레임워크 553. Fig. 5. Collaboration Protocol Between Team Leader and Team Member in IT Ecosystem[9]. 3. 사례연구: 무인삼림관리를 위한 IT 생태계. Fig. 6. Conceptual Model for the UFM IT Ecosystem: (a) Service Goal Model and (b) Role Model. 우리는 선행연구[9]부터 제안하는 아키텍처 프레임워크의 적용 어플리케이션으로, 시뮬레이션된 환경에서의 무인삼림. 공하는 외부 환경에 관해 명세한 내용들이다. 협업 대상 환. 관리 IT 생태계 시스템을 활용해 왔다. 시뮬레이션된 무인. 경은 사람이 관리할 수 없는 넓은 크기의 9개의 임야 지역. 삼림관기 IT 생태계에 참여 가능한 후보 시스템은 총 12대. 이다. Fig. 7(a)의 환경모델은 각 환경 구역(Zone)들이 가지. 의 무인항공기, 무인 헬기, 무인 자동차와 같은 자율성을 가. 는 속성 항목이 무엇인지를 설명한다. 각각의 구역은 흐림,. 지는 무인 이동수단 시스템들이며, 각각의 무인 시스템에는. 비, 안개 등으로 기술되는 날씨 정보, 가시거리, 풍속, 삼림. 몇 가지 종류의 센서와 액츄에이터들이 탑재되어 있다.. 조밀도, 강이나 호수를 포함한 지형인지, 일반적인 삼림 지. 이미 Fig. 3에 일부가 소개된 바 있으나, Fig. 6(a)는 무인 삼림관리 IT 생태계가 달성해야 할 전체 서비스 목표 모델. 형인지를 나타내는 지형타입, 구역의 세로길이, 가로 넓이 등과 같은 속성 항목을 가진다.. 을 도식화하고 있다. 자율성을 가지는 무인 기기들은 자신. Fig. 7(b)는 정의된 속성 항목에 따라 모니터링된 9개의. 이 가지는 역량에 따라, 화재를 진압하거나 조난자를 구하. 임야 지역의 상태 값들을 보여준다. 시뮬레이션된 환경에서. 거나 식수작업을 하는 등의 서비스를 단독으로 제공하거나. 는 삼림구역의 사이즈를 동일하게 가로 10km, 세로 10km의. 혹은 협업을 통해 제공한다. 앞서 참조 아키텍처에 포함된. 2 100km 로 동일한 사이즈로 정의하였다. 따라서, 구역의 가. 메타모델에 정의된 팀리더 역할은 ChiefGardner 타입이, 팀. 로, 세로 사이즈는 상수로 처리되어, 속성값에 명시되지 않. 멤버 역할은 Gardener와 Surveillant 타입이 각각 상속받고. 았다. 각 구역의 속성 값 중에서, 삼림 조밀도나 지형타입. 있음을 Fig. 6(b)를 통해 알 수 있다. Fig. 6(b)의 클래스 다. 등의 속성은 상당 시간이 지나도 변하지 않는 고정된 값이. 이어그램은 도메인에서 개체화된 각 역할들이 팀리더와 팀. 지만, 무인 시스템 배치시 제약조건으로 작용할 수 있다. 예. 멤버 역할에 정의된 역량<<capability>>들을 상속받아 어. 를 들면, 삼림조밀도가 매우 높은 지역은 무인차량을 투입. 떤 목표를 성취<<achieve>>하여야 하는 지에 대해서도 명. 하여 작업하는 것이 어려울 수 있으며, 강이나 큰 호수가. 세하고 있다.. 포함된 지형 역시 무인 차량 투입은 적절하지 않다. 반면,. Fig. 7은 무임삼림관리 IT 생태계 시스템이 서비스를 제. 날씨나 가시 거리, 풍속 등은 짧은 시간에도 변화가 발생할.

(6) 554. 정보처리학회논문지/소프트웨어 및 데이터 공학 제6권 제12호(2017. 12). Fig. 7. Environment Model and Participant Profile for the Unmanned Forest Management IT Ecosystem. 수 있는 요소들로 무인기기의 재배치를 유발시키는 요인이. 4. 무인삼림관리 IT 생태계를 위한 아키텍처. 된다. 예를 들면, 갑자기 안개가 짙어져서 가시거리가 기준 치 이하가 될 경우, 해당 지역에서 서비스를 수행하던 무인 헬기나 무인 항공기 등의 작업이 불가능하게 된다.. 본 장에서는 2장에서 제시한 참조 아키텍처(reference architecture)를 개체화하여 3장에서 소개한 무인삼림관리를. Fig. 7(c)에 도식화된 무인 헬기에 대한 모델링은 이미. 위한 IT 생태계를 구축해 나가는 과정을 통해, 아키텍처가. Fig. 4에 언급된 바 있다. IT 생태계 참여가 가능한 시스템. 포함하고 있는 오케스트레이션 메커니즘의 작동 원리를 설. 의 타입이 가지는 속성은 Fig. 7(c)와 같은 클래스 다이어그. 명하고 있다. Fig. 8은 무인삼림관리를 위한 IT 생태계의 팀. 램 형태로 정의된다. Fig. 7(c)의 무인 헬기가 가지는 속성. 리더 역할자인 ChiefGarder역할을 맡은 시스템 내부의 모습. 들 중, <<cost>>나 <<benefit>>스테레오 타입으로 표시된. 을 도식화하고 있다.. 속성들은 각 시스템 개체를 IT 생태계 내에서 운영할 때 소. 무인삼림관리를 위한 IT 생태계에 참여하는 시스템의 최. 요되는 단위시간당 비용과 운영 결과 얻을 수 있는 단위시. 하부 계층은 안드로이드 플랫폼 계층이다. 안드로이드 플랫. 간당 혜택을 측정하는 속성들이다.. 폼 계층과 Felix 계층은 참여 시스템의 역할에 상관없이 모. Fig. 7(d)의 표는 비용과 혜택 관점에서의 무인 시스템. 든 시스템에 항상 디폴트로 탑재되어 있다. 우리는 시스템. 개체별 프로파일링 데이터를 보여준다. 프로파일링 요소는. 에서 실제로 동작하는 어플리케이션의 상태를 모니터링하기. 크게 A～G까지는 해당 기기를 운영하기 위한 비용(cost) 요. 위한 목적으로, 안드로이드 플랫폼 상에 두 가지 특별한 컴. 소, H~N까지는 해당기기에 탑재된 센서들의 성능치로 대변. 포넌트를 이식하였다. 첫 번째 컴포넌트는 Prob이다. Probe. 되는 혜택(benefit) 요소들이 포함되며, O항목은 남아있는. 개념은 MAPE-K loop를 지원하는 가장 대표적인 참조 아. 연료량, P 항목은 현재 가용한 리소스의 양을 나타내는 수. 키텍처 중 하나인 Rainbow[12] 에서 제안한 개념과 동일하. 치 등도 포함되어 있다. 각 항목 값들은 4.2절에서 설명할. 다. 즉, 안드로이드 플랫폼상에서 실행 중인 어플리케이션의. 예정인, 협업점수 산정 함수시 입력 값으로 활용된다.. 상태를 평가하기 위한 속성 정보들을 주기적으로 읽어 들이.

(7) IT 생태계의 지속적인 운영을 위한 동적 오케스트레이션 프레임워크 555. Fig. 8. Instantiated Architecture for Unmanned Forest Management IT Ecosystem. 기 위한 하나의 채널 역할을 담당한다. Probe를 통해 파악. 형상 정보를 ConfigurationManager를 통해 획득하여,. 해야 할 시스템 상태 평가항목(metric) 들은 도메인에 따라. 현재의. 협업성능을. 측정하는. 데. 필요한. 정보를. 달라질 수 있다. 무인삼림관리를 위한 IT 생태계에서 Probe. CollaborationAnalyzer에게 넘겨주는 역할을 담당한다.. 로 사용되는 데이터 항목은 연료 게이지나 GPS위치정보와. • CollaborationAnaylzer: CollaborationMonitor로부터 넘겨. 같이 시스템에 탑재된 센서를 통해 수집 가능한 자료들이. 받은 모니터링된 값들을 입력으로, 협업점수(collaboration. 다. Probe를 통해 수집된 자료들은 일단 해당 시스템 내의. score)를 계산한다. 오케스트레이션 성능 정도를 표시. 지역 환경 정보(local environment) 저장소에 저장된다.. 하는 협업점수 산정 방법은 4.2절에서 자세히 기술할. 안드로이드 플랫폼 상에 이식해 놓은 또 하나의 컴포넌트. 예정이다. 산정된 협업점수가 미리 정의해 둔 기준값. 인 Effector는 Felix 계층에 위치한 ConfigurationManager를. (threshold) 미만일 경우, CollaborationAnalyzer는 환경. 통해 획득한 새로운 형상 정보에 따라 시스템에 탑재된 센. 과 시스템간의 조합에 있어서의 문제점을 분석하여,. 서와 액츄에이터, 혹은 그 외 시스템 내부의 컴포넌트들을. CollborationPlanner에게 전달한다.. 추가하거나 삭제하는 역할을 담당한다.. • CollaborationPlanner: CollaborationAnalyzer로부터 현. Apache Felix[13]는 안드로이드 플랫폼과 MAPE Core Bundle. 재의 형상과 형상내의 문제점을 전해 받아, 다음 번 협. 계층 간의 인터페이스 용도로 활용된다. Felix Service Client가. 업을 위한 최적 형상을 선택한다. 시스템 배치시의 제. Felix 서비스를 사용하는 AdaptationBundleActivator를 구동시. 약 조건을 거스르지 않는, 모든 가능한 형상조합을 대. 키면, AdaptationBundleActivator는 클라우드 상에 위치한. 상으로 협업점수를 산정하여, 가장 높은 점수를 가지는. BundleRegistry정보를 검색(look up)하여, 필요한 컴포넌트들을. 형상조합을 다음 번 협업의 최적 형상으로 선택한다.. MAPE Core Bundle 계층에 동적으로 바인딩시킨다. MAPE Core Bundle 계층에 있는 컴포넌트들은 OSGi[14]. 다음 번 최적 형상 실현을 위해 특정 무인시스템을 해 당 서비스 구역에서 철수하거나, 새로운 무인시스템을. 가 제공하는 생명주기관리(life cycle management)서비스에. 투입하거나 혹은 기존 무인시스템에 탑재되지 않은 역. 의해 관리된다. MAPE Core Bundle 계층에 동적 바인딩되. 량을 추가하여 센서나 액츄에이터를 구동하도록 하는. 는 컴포넌트 집합은 해당 시스템의 역할에 따라 다르다.. 등의 명령어 시퀀스들로 이뤄진 형상재배치 계획을 수. Fig. 8과 같이 팀리더 역할자인 ChiefGardner로 선정된 시. 립한 후, AdaptationExecutor에게 전달한다.. 스템 상에는 실제로 오케스트레이션 계층의 컴포넌트들이. • AdaptationExecutor: AdaptationExecutor는 Adap-. 바인딩된다. 오케스트레이션 계층에서 작동하는 각 MAPE. tationPlanner로부터 전달된 재배치 계획 중에서 ChiefGarder. 구현 컴포넌트들에 대한 설명은 다음과 같다.. 시스템의 로컬 컴포넌트의 형상을 수정하는 명령어들. • CollaborationMonitor: Global ITE Knowledge에 속한. 을 식별하여 Felix 층에 위치한 ConfigurationManager. 전역형상(global configuration) 저장소에 저장된 현재의. 에게 전달한다. 전달된 명령어들은 Local Configuration.

(8) 556. 정보처리학회논문지/소프트웨어 및 데이터 공학 제6권 제12호(2017. 12). 상에 업데이트되고, 안드로이드 플랫폼상의 Effector가. 없다. CollaborationAnalyzer는 이러한 제약조건들과 규. 이러한 업데이트된 명령어 정보를 주기적으로 획득하. 칙을 위배하고 있는 환경과 참여시스템 데이터 쌍이 없. 여 어플리케이션 내부 컴포넌트의 변경을 수행한다.. 는지를 전체 형상 데이터로부터 분석해 낸다. Table 1. ChiefGarder 내부의 형상변경 외에 다른 팀멤버 시스템. 은 무인삼림 감시를 위한 무인 시스템의 서비스 구역. 들에게 전달되어야 하는 재배치 명령어들은 Collaborative. 배정시 체크해야 할 제약조건들을 정의하고 있다.. Communication 계층을 통해 각각의 팀멤버 시스템에 전 달된다. 팀멤버에게 전달된 명령어에 따라 IT생태계 시스. Table 1. Constraints in UFM IT Ecosystem. 템의 전체 형상이 다음 스텝으로 옮겨가면, 변화된 형상 정보는 ITEConfigurationManager에 의해 전역 형상 저 장소에 업데이트 된다. IT 생태계 시스템의 환경 변화에 대응하는 적응 행위는 앞서 설명한 MAPE loop를 구현하는 4개의 컴포넌트의 품 질에 의해서도 영향을 받지만, 공유 지식(Knowledge)의 품 질에 의해 상당 부분 영향을 받는다. IT 생태계 내의 지식 정보저장소는 크게 IT 생태계 전체의 형상과 형상에 대한 변경이력정보를 관리하기 위한 Global ITE Knowledge 저 장소와 개별적인 시스템의 적응 행위 수행시 활용되는 자료 들을 관리하기 위한 Local Environment 저장소로 구분되어 있다. Local Environment 저장소는 안드로이드 플랫폼상에 위치한다. 반면, Global ITE Knowledge 저장소는 Fig. 8에 서는 표현의 편이상 함께 표시하였으나, 클라우드 상에 위 치하도록 하였다. Global ITE Knowledge 저장소에 저장되는 정보들은 다 음과 같다.. 4.1 오케스트레이션 메커니즘의 동작 사례: 가뭄 모니터링 본 절에서는 앞서 소개한 무인삼림관리를 위한 IT 생태 계 아키텍처를 구성하고 있는 컴포넌트들의 동작 메커니즘 을 가뭄 모니터링(“Monitoring Drought”)이라는 특정한 오 케스트레이션 목표 수행 시나리오와 함께 설명해 나간다. Fig. 9는 가뭄 모니터링 목표 수행 중 발생 가능한, IT생. • 환경모델(Environment Model)정보: 시간이 지남에 따. 태계의 전체 협업 성능을 저하시키는 하나의 사례를 도식화. 라 상태가 변화하는 환경 요소들을 정의하는 모델들. 하고 있다. 삼림 구역 zone[0][2]에서 무인헬기 HE2가 배치. (Fig. 7(a) 참조), 정의된 모델에 의해 명세된 환경 명. 되어 가뭄 모니터링 작업을 수행하던 중, 해당 지역에 갑자. 세 데이터(Fig. 7(b)참조)들이 포함된다. 환경모델 자체. 기 초속 20m/s 이상의 강풍이 불기 시작하였다. 이러한 날. 는 설계시에 정의된 이후 변하지 않는 정보이지만, 환. 씨변화는 HE2에 탑재된 센서에 의해 감지되어 서비스 계층. 경 명세 데이터들은 다양한 센서들을 통해 주기적으로 수집하여 업데이트되는 자료들이다. • 참여시스템에 대한 프로파일링(Participants Profiling) 정보: Fig. 7(c)에서 보이는 바와 같이, IT 생태계에 참 여 가능한 시스템의 타입별 모델 정의에 따라 IT생태 계에 현재 참여하고 있는 시스템 운영시 소요되는 비 용과 기대되는 혜택 값에 대해 프로파일링한 자료를 관리한다. • 제약조건 및 규칙(Constraints and Rules): IT 생태계를. 의MAPE loop가 구동된다. HE2는 자신이 작업 가능한 상황 이 아니라는 것을 판단하고, 현재의 구역을 벗어나 복귀하 는 프로세스를 수행한다. 이러한 일련의 프로세스는 각 팀 멤버 역할을 담당하는 참여 시스템의 서비스 계층의 MAPE loop에 의해 수행되는 지역적응 메커니즘으로, Fig. 8에서는 표현되지 않은 사항들이다. 본 논문에서 초점을 맞추고 있는, 무인헬기 HE2의 지역 적응 결과 연쇄적으로 구동되는IT 생태계 시스템 전반에 걸 친 전역 적응(global adaptation)의 과정은 다음과 같다. 먼 저, CollaborationMonitor는 모니터링 주기가 도래하면 ITE. 구성하는 데 있어서 반드시 고려되어야 할 제약조건이. ConfigurationManager를 통해 GlobalConfiguration저장소로. 나 규칠들도Global ITE Knowledge 저장소에 저장된다.. 부터 9개의 삼림구역에서 작업하고 있는 무인 시스템이 수집. 무인삼림관리 IT 생태계의 경우에는 참여시스템의 속성. 한 현재의 환경상태 정보와 9대의 서비스 참여시스템의 프로. 타입별로 서비스가 가능한 삼림지역과 불가능한 지역이. 파일링 자료를 읽어와서, CollaborationAnalyzer에게 분석을. 존재한다. 예를 들어, 풍속이 20m/s 이상인 지역에는 상. 의뢰한다. CollaborationAnalyzer는 이를 바탕으로 현재의 협. 공에서 작업하는 무인헬기나 무인항공기, 그리고 일반. 업성능을 평가하기 위한 협업점수를 산정한다. 이미 HE2는. 비행기는 삼림감시 서비스를 제공하기 위해 배치할 수. 서비스 제공을 멈추기 시작한 상태이므로, 협업점수는 미리.

(9) IT 생태계의 지속적인 운영을 위한 동적 오케스트레이션 프레임워크 557. Fig. 9. Orchestration Mechanism for Achieving an Orchestration Goal: “Monitoring Drought”. 정한 기준 값을 패스하지 못한다. CollaborationAnalyzer는. 대응되는 실제적인 협업점수 산정 과정을 보이고자 한다.. Global ITE Knowledge 저장소에 있는 환경상태 데이터와 상태. 우리는 IT 생태계에 참여하여 서비스를 제공하는 무인시스. 정보, 그리고 제약조건과 규칙들을 비교하여, zone[0][2]에서 2번. 템간의 협업 정도를 가늠하기 위한 하나의 일반적인(generic). 제약조건(Table 1)에 위배되는 상황이 발생하였으며, 이로 인해. 비용-혜택(Cost-Benefit) 모델을 정의하였다. 비용-혜택 모. zone[0][2]에 새로운 무인시스템을 재배치해야 한다는 분석결과. 델의 평가항목(metric) 집합은 IT 생태계의 도메인에 따라. 를 CollaborationPlanner에게 패스한다. CollaborationPlanner는. 달라질 수 있지만, 무인삼림 관리를 위한 비용과 혜택평가. 현재 가용한 무인시스템과 9개의 삼림구역간에 가능한 모든 형. 항목 집합은 Table 2에 나열된 바와 같다. Table 2에 나열. 상에 대한 협업점수를 산정하여, 가장 높은 협업점수가 산정된. 된 항목들은 무인삼림관리를 위한 IT 생태계라는 도메인에. 형상을 실현하기 위한 적응 계획을 수립한다. Fig. 9는 zone[0][2] 지역에 다음 번 협업시 배치될 최적 시스템을 선택하는 과정 중의 일부분을 단편적으로 묘사하 고 있다. zone[0][2] 지역에 배치 가능한 후보 무인시스템은 UAV1과 JE4이다. zone[0][2]의 현재 상태와 재배치 후보가 된 두 대의 무인시스템의 상태 값을 기반으로 산정한 협업 점수는UAV1를 배치하는 경우가 JE4를 배치하는 경우보다 더 높은 값이 산정되었다. 따라서, 다음 번 협업형상에는 Zone[0][2] 구역에 배치될 무인 시스템으로는 UAV1이 선택 된다. 새로운 형상 구현을 위해 CollaborationPlanner는 적응 계획에UAV1을 zone[0][2]에 배치하여 서비스를 제공하도록 하는 데 필요한 명령어 시퀀스를 포함시킨다. 명령어는 AdaptationExecutor와 ITEBridgeService를 통해 UAV1 시스 템에 전달된다. zone[0][2] 구역에 새로운 무인시스템인 UAV1이 가뭄 모니터링 서비스를 시작하면, ITEConfigurationManager는 zone[0][2]구역에 UAV1이 배치되었음을 Global Configuration 저장소에 업데이트 한다. 4.2 최적 기기 조합 산정을 위한 비용-혜택 모델 IT 생태계 시스템의 전역 적응을 위한 오케스트레이션 과 정 중에는 CollaborationAnalyzer가 모니터링 주기마다 협업의 성능을 평가하기 위해 협업점수(collaboration score)산정 과정 이 포함되어 있다. 협업점수 산정 함수는 CollaborationPlanner 가 다음 협업의 최적형상을 결정하는 시점에서도 사용된다. 본 절에서는 협업점수 산정시의 입력 자료와 협업점수 산정 공식을 설명하고, Fig. 9에서 제시한 단편적인 재배치 상황에. 서 협업 성능을 가늠하기 위해 선정된 항목들이다. 각 참여 시스템의 구동 및 운영에 소요되는 경제적인 비용과 관련한 항목들이 비용 요소로, 협업의 정확도(correctness)와 완성도 (completeness)를 평가하기 위한 항목들이 혜택 요소로 선 택되었다. 이러한 평가항목 집합(metric set)은 도메인에 따 라 달리 정의하여 사용한다. 먼저, 비용을 결정짓는 요소로는 무인시스템의 운영을 위 한 시간당 인건비, 무인시스템의 시간당 감가상각비, 무인 시스템 구동에 필요한 시간당 연료소모량, 그리고 무인 시 스템에 탑재되는 광학센서, 비전, 적외선센서, GPS 센서들에 대한 시간당 감가상각비 등이 포함된다. 무인시스템을 운영 을 위한 시간당 인건비를 포함시킨 이유는 자가 적응형 시 스템이라 하더라도 산불진압과 같은 위급한 순간에 사람의 Table 2. Cost-benefit Factors for Collaboration to Obtain "Monitor Drought" Service Goal.

(10) 558. 정보처리학회논문지/소프트웨어 및 데이터 공학 제6권 제12호(2017. 12). 조작이 필요한 경우가 있기 때문이다. 시간당 인건비 요소. 협업점수는 위의 Equation (1)～(4)의 결과 값인 비용 값. 가 0인 무인시스템들은 이러한 사람의 조작 개입 확률이 전.   와 혜택 값     으로부터 산정한다. 비. 혀 없는 시스템임을 뜻한다. 비용은 IT 생태계의 협업에 참. 용 요소와 혜택 요소가 중요도 면에서 차이가 있을 경우 적. 여하는 시스템 개체 별로 합산하여 산정한다.. 절한 가중치를 적용할 수 있다. 특별히 중요도 차이가 없을. 특정 시스템이 특정 환경에 서비스를 제공할 때 얻을 수. 경우, Equation (5)와 같이 ROI(Return On Investment)개념. 있는 혜택 정도는 상이하다. 즉, 혜택 요소 값은 시스템 개체. 을 적용하여 혜택 값과 비용 값의 차를 협업점수로 산정한. 에 종속적인 것이 아니라, 특정 무인 시스템과 서비스 제공. 다. 전체 형상  에 속하는 모든 데이터 쌍     들. 구역간의 매핑에 종속적이다. 따라서, 비용 항목 값들은 후보. 에 대한 협업점수의 합이 특정 시점에서의 형상  에. 시스템이 정해지면 결정되지만, 혜택 항목 값들은 실제 시스 템이 특정 지역에 배치되어 협업을 실행했을 때 측정가능하 며, 지속적인 모니터링 결과를 통해 수집된 실측 값들의 평 균치를 사용한다. “가뭄 모니터링”을 위해 사용되는 혜택 요 소는 시스템에 탑재된 광학센서, 비전, 적외선 센서, GPS 센 서의 감도 등과 같이, 주로 시스템에 탑재된 센서들의 성능. 대한 전체 협업점수이다. CollaborationScore        ×        ×       where ∑     ∏   . (5). 항목들이 포함된다. 모니터링 감도 외에 단위 시간당 모니터 링 영역의 넓이(km/h)도 혜택 요소로 포함된다. 모니터링 커. 다음의 Equation (6)～(8)은 위에서 정의한 규칙에 따라,. 버리지의 경우, 같은 구역에 같은 시스템이 배치되었다 하더. UAV1을 zone[0][2]구역에 배치할 경우의 CollaborationScore. 라도 날씨 상태에 따라 다른 값을 가질 수 있다.. (UAV1, zone[0][2])를 산정하는 과정을 보여준다. “가뭄 모. 다음은 협업점수 산정 함수에 대한 설명이다. 협업점수. 니터링”이라는 서비스 목표를 수행하는데 있어서 무인 시스. 산정시 입력 값은 특정 환경 구역   에 특정 무인시스템 . 템 UAV1을 구동시키는데 필요한 UAV1 자체의 감가상각. 가 할당되었음을 표시하는 데이터 쌍    들의 집합 형. 비, 연료 소모량, 탑재된 센서들의 감가상각비에는 동일하게. 태로 정의되는 형상  이다.. 1/3씩의 가중치를 적용하였다. 협업의 정확도 평가 항목인. 비용   값은 앞서 설명한 바와 같이, 무인시스템  에만 종속적인 값이다. 비용   값은 Table 2에 나 열된 각 비용 항목에 대한 후보 무인 시스템들이 가지는 값 을 노말라이즈한 값  를 합산하여 산정한다. 이때, 비용. 센서들의 감도보다는 협업의 완성도 평가 항목인 모니터링 커버리지 항목에 조금 더 높은 가중치를 적용하여, 각각 0.3 과 0.7의 가중치를 각각 적용하였다. 아래 수식들에서 각 항 목 값들은 Fig. 7(d)의 표에 명세된 값들을 대입한 결과이다.. 항목별로 중요도를 반영하는 가중치  를 적용한다, 적용된 가중치  의 합은 1이 되어야 한다.        . (1). (6).    ⋯     ∑  ×    ∑   . (2). 특정 환경 구역  에 특정 무인시스템  가 할당되었을 때 예상되는 혜택 값     은    산정방식. (7). 과 마찬가지로, 혜택 항목별로 노말라이즈한 값  에 가 중치  를 적용한 값을 합산하여 산정한다.        . (8) (3) 현재 형상  집합에 속하는 나머지 8개의 데이터.    ⋯. 쌍에 대한 협업점수도 위의 동일한 공식에 따라 산정한 후,       ∑  ×    ∑  . (4). 합산하여 각각의 후보 형상에 대한 전체 협업점수를 산정한 다. 이렇게 산정된 형상별 전체 협업점수를 비교하여, 가장 높은 전체 협업점수 값을 가지는 형상이 다음 번 협업의 최.

(11) IT 생태계의 지속적인 운영을 위한 동적 오케스트레이션 프레임워크 559. 적형상으로 선택된다. Fig. 10은 안드로이드 플랫폼 기반의 모바일 단말에 출력 된 협업 형상 결과를 보여주는 화면이다. 현재 선택된 형상 의 배치 모습과 전체 선택된 형상의 전체 협업점수가 4.48. 된다. 이에 대한 해결책으로, 우리는 유전 알고리즘(genetic algorithm)을 선택하여, 협업점수 산정 대상이 되는 형상의 개수를 한정시키는 전략을 사용하였다. 유전 알고리즘은 주어진 문제에 대한 전역 최적 해법. 이라는 것을 확인할 수 있다. 최적형상으로 선택된 형상 외. (global optimal solution)을 찾고자 할 때 적용하는 잘 알려. 에도, 배치 가능한 후보 형상에 대한 정보가 화면 하단에. 진 알고리즘 중 하나이지만[15], 모든 최적화 문제에 적용. 함께 제공된다.. 가능한 것은 아니다. 유전 알고리즘을 적용하여 주어진 문 제의 최적해를 구하기 위해서는 두 가지 요건이 만족되어야 한다. 첫 번째는 최적해가 비트 배열인 유전자(chromosome) 형태로 표현 가능하여야 한다. 비트 형태의 표현이 필요한 이유는, 현재의 최적해를 나타내는 유전자를 교차(crossover) 와 변이(mutation)등의 변형 함수를 통해 변형하여 다음 번 최적해의 후보군을 생성(propagation)하기 때문이다[16]. 유 전자 알고리즘 적용에 필요한 두 번째 요건은 생성된 각각 의 유전자가 환경에 적합한지를 평가하기 위한 적합성 함수 (fitness function)가 정의되어야 한다는 것이다. 먼저, 유전 알고리즘을 IT 생태계의 최적 형상을 선택하 는 문제에 적용하기 위해, 특정구역과 특정 무인시스템간의 매핑을 나타내는 데이터 쌍의 집합으로 이루어진 형상을 Fig. 11(a)에서 나타내는 바와 같이, 하나의 비트 배열 형태 로 표현하였다. 각각의 삼림 구역의 속성과 해당 구역에 배 치되는 무인 시스템의 속성은 모두 비트 형태로 인코딩하여. Fig. 10. An Example of Newly Selected Optimal Configuration Which has the Biggest Total Collaboration Score. 4.3 협업점수 산정 오버헤드 감소를 위한 유전 알고리즘 적용 메커니즘 최적의 형상을 선택하기까지 협업점수 산정 함수의 수행 횟수는 IT 생태계가 n개의 참여 후보 시스템과 m개의 환경 구역을 가질 경우, 총 nPm 번 수행된다. 시뮬레이션 된 무 인삼림관리를 위한 IT생태계를 구성하는 참여 후보 시스템 은 총 12개 중, 하나의 시스템은 팀리더로 선정되어 IT 생 태계 전체의 오케스트레이션 목표를 수행한다. 나머지 11개 의 후보 시스템을 서비스를 제공할 삼림구역의 개수는 9개 에 배치하는 최적의 형상을 찾기 위한 후보 형상의 개수는 총 19,958,400 (11P9)개이고 이 개수는 곧 협업점수 산정 함 수의 수행횟수가 된다. 협업점수 산정은 매 모니터링 주기 마다 수행되어야 하고, IT생태계 참여 시스템들은 데스크탑 이나 서버급의 PC가 아닌 임베디드 시스템임 점을 고려할 때, 협업점수 산정에 따른 컴퓨팅 오버헤드는 IT 생태계 운 영에 리스크 요소가 된다. 더군다나, 참여 시스템의 개수가 증가하거나 서비스 환경 구역의 개수 증가할 경우, 협업점 수 산정에 소요되는 오버헤드는 기하급수적으로 증가하게. Fig. 11. Applying Genetic Algorithm for Propagation the Next Candidate Configurations.

(12) 560. 정보처리학회논문지/소프트웨어 및 데이터 공학 제6권 제12호(2017. 12). 배열 형태로 표현함으로써, IT생태계의 매 모니터링 시점마. 없는 날씨 변화가 IT 생태계의 진화를 일으키는 외부 요인. 다의 협업 형상은 하나의 유전자 형태로 변환 가능하다.. 으로 작용한다. 날씨 변화의 경우, 바람의 세기나 비의 이동. CollaborationPlanner는 최적 형상을 나타내는 유전자 배. 경로, 안개와 구름의 위치 등을 9개의 삼림 구역에서 가로. 열을 교차나 변이와 같은 진화 연산들을 통해 변형시킴으로. 지르며 일정한 속도와 방향으로 진행되도록 시뮬레이션하였. 써, 다음 세대의 유전자 집합을 생성한다. 생성된 다음 번 형. 다. 이러한 환경 변화에 대응하여, 오케스트레이션 메커니즘. 상의 후보들 중, 형상 구성시의 제약조건들(Table 1)을 위반. 을 적용하지 않은 경우와 적용한 경우에 측정되는 각 IT생. 하는 시스템과 삼림구역간의 데이터 쌍을 포함한 유전자 배. 태계 형상들에 대한 비용, 혜택, 협업점수 값들을 비교하여. 열은 후보군에서 도태시킨다. 도태되지 않은 유전자 배열들. 제안된 메커니즘의 적용 효과를 보이고자 하였다. 또한, 날. 은 적합성 함수를 통해 비교하여 가장 적합한 최적 유전자를. 씨변화의 정도에 차등을 두어 시뮬레이션함으로써, 제안된. 선택한다. 무인삼림관리를 위한 IT 생태계에서 유전 알고리. 오케스트레이션 메커니즘이 급격한 환경 변화시에도 IT생태. 즘 적용을 위한 두 번째 요건인 적합성 함수는 이미 4.2절에. 계 시스템이 일정한 성능의 협업서비스를 제공하도록 하는. 소개된 비용-혜택 기반의 협업점수 산정 함수이다. 협업점수. 지를 확인하고자 하였다.. 산정 결과, 가장 큰 값을 가지는 유전자 배열이 다음 스텝에 서의 IT 생태계를 구성하는 형상으로 최종 선택된다.. 무인삼림관리 IT 생태계 시스템에서 외부 환경 요소의 변화 외에도, 참여 시스템들의 서비스 불능 상태를 야기하. 다음 번 최적 해를 찾는 과정 중에 생성되는 차세대 유전. 는 내부 인자로 연료소모가 있다. 무인 기기마다 단위 시간. 자의 개체 수는 적용하고자 하는 문제의 성격에 따라 제한. 당 연료소모량을 정의하여, 시간이 지남에 따라 무인시스템. 할 수 있다. IT 생태계 구동 이후 최초의 최적 형상 선택시. 의 타입에 따라 일정한 속도로 연료소모량이 줄어들도록 시. 에는, 최악의 경우, 유전 알고리즘을 적용하지 않을 때와 마. 뮬레이션 하였다. 따가서, 연료고갈에 땨른 시스템 서비스. 찬가지의 횟수의 협업점수 산정 작업을 필요로 할 수 있다.. 중단이 또 하나의 동적 재배치 메커니즘의 동인(動因)으로. 그러나, 일단 최적해에 해당하는 첫번째 유전자가 선택된. 작용한다.. 이후부터는 다음 세대 유전자 집합의 크기를 고정시킬 수. Fig. 12의 그래프들은 모니터링 주기마다 Collaboration-. 있다는 유전 알고리즘의 특성에 따라, 협업점수 산정의 횟. Analyzer가 산정한 무인삼림관리를 위한 IT 생태계의 협업. 수 역시 고정 가능하다. 이러한 유전 알고리즘의 특성은 결. 성능의 변화 추이를 보여준다. 좌측의 그래프 (a)(c)는 제안. 과적으로, IT 생태계의 참여 시스템 수나 서비스 제공 지역. 된 프레임워크의 오케스트레이션 층의 MAPE loop를 구동. 의 개수 증가 시, 기하급수적으로 증가하는 동적 재배치 오. 시키지 않았을 때의 협업성능 모니터링 결과값들을 표시하. 버헤드의 상당 부분을 감소시키는 효과를 가져온다. 과연. 고, 우측의 그래프 (b)(d)는 구동시켰을 때의 결과값들을 표. 유전 알고리즘 적용으로 인해 어느 정도의 오버헤드 감소가. 시하고 있다. 그래프의 가로축은 수행된 모니터링 회차를. 가능한 지는 5장에서 제시하는 정량적인 실험결과와 함께. 표시한다. 세로축은 모니터링 시점의 협업 형상에 대한 비. 논의될 예정이다.. 용값, 혜택값, 협업점수값을 표시한다. 오케스트레이션 메커 니즘을 작동시키지 않은 경우, 날씨 변화의 급격한 정도와. 5. 검 증 5장에서는 본 논문에서 제안하는 동적 오케스트레이션을 지원하는 아키텍처 프레임워크가 IT생태계에 기여하는 바를 정량적으로 검증한 결과를 논의하고자 한다. 우리는 먼저, 검증하고자 하는 두 가지의 질문을 정리하였다. 1. 제안된 프레임워크는 전체 IT 생태계가 처한 내/외부. 상관없이 15회차 모니터링 시점에서 9개의 구역에 배치된 모든 무인시스템의 서비스가 중지되는 것이 확인되었다. 따 라서, 15회차 이후의 모니터링 결과는 무의미하여 그래프에 반영하지 않았다. 오케스트레이션 메커니즘을 작동시키지 않고, 완만한 날 씨 변화를 외부에서 시뮬레이션 한 경우(Fig. 12(a)), 6회 차 모니터링 시점부터 서서히 참여 시스템이 서비스 목표를 수. 환경변화에 적응해 나가면서 지속적인 서비스를 제공. 행하지 못하는 구역이 발생함에 따라, 혜택 값과 협업점수. 함을 보장할 수 있는가?. 가 감소하기 시작하고, 8회차 모니터링 시점을 기점으로 그. 2. IT 생태계의 형상 재배치에 소요되는 오버헤드는 수용. 값은 급격히 감소한다. 결국 14회차 모니터링 시점에서는. 할 만한 정도인지, 그리고 IT생태계 확장에 따른 기하. 거의 모든 서비스 지역에서의 무인 시스템이 불능 상태가. 급수적인 증가 양상을 보이지는 않는가?. 되어 혜택 값이 0에 수렴하게 된다. 오케스트레이션 메커니 즘 작동 없이, 급격한 날씨 변화를 시뮬레이션한 경우(Fig.. 먼저, 첫 번째 검증 포인트인 IT생태계의 지속성 유지 여. 12(c)), 완만한 날씨 변화가 일어난 경우보다 훨씬 빠른 시. 부에 대한 검증 결과이다. 사례 연구 대상인 무인삼림관리. 점인 2회차 모니터링 시점부터 무인시스템의 서비스 불능. IT 생태계에서는 비록 시뮬레이션된 환경이긴 하지만, 끊임. 상태가 발생하기 시작하였다. IT생태계가 완전히 서비스를.

(13) IT 생태계의 지속적인 운영을 위한 동적 오케스트레이션 프레임워크 561. Fig. 12. Monitored Cost-Benefit Values and Collaboration Scores in Unmanned Forest Management IT Ecosystem. 멈추게 되는 시점은 동일하게 14회차 모니터링 시점이었으 나, 평균 협업산정 점수 값은 완만한 날씨 변화가 있었던. 한 오버헤드가 허용 가능한 정도인지를 검증한 결과이다. 사례연구 대상인 무인삼림관리를 위한 IT생태계가 12대. 경우의 -1.09보다 훨씬 낮은 -3.3이었다. 예상 가능하듯이,. 의 무인 시스템을 9개의 서로 다른 구역에 배치하여 “가뭄. 외부 변화의 정도가 급격할 경우, 협업의 성능의 감소폭은. 모니터링” 서비스를 제공할 경우, 유전 알고리즘을 적용하기. 훨씬 더 크게 나타났다.. 이전에 측정된 최적 형상 조합 선택의 평균 소요시간은 약. 제안된 프레임워크가 제공하는 동적 형상 재배치 메커니. 4.24초였다. 동일한 상황에서 유전 알고리즘을 단일 쓰레드. 즘이 작동할 경우에 측정된 결과치를 나타내는 우측의 두. 로 실행하여 후보 형상집합을 생성하여 협업점수를 산정하. 그래프들은 확연히 다른 양상을 보이고 있다. Fig. 12의 그. 는 방식으로 최적 후보를 선택한 경우, 측정된 평균 소요시. 래프 (a)와 (b)의 측정치들을 살펴보면, 재배치 메커니즘이. 간은 2.77ms에 불과했다. 이 결과는 유전 알고리즘 적용시. 구동되지 않았던 그래프(a)의 측정치들은 6회차 모니터링. 생성되는 차세대 집합의 크기를 200개로 한정하여 얻은 효. 시점부터 하강 곡선을 보였으나, 동적 재배치 메커니즘이. 과로 해석 가능하다.. 동작될 때의 측정치를 나타내는 그래프 (b)는 15회차 모니. 동일한 상황에서의 최적 형상 조합 선택의 소요 시간 감. 터링 시점까지 IT 생태계 운영에 따른 비용, 혜택, 협업점수. 소가 확인되었다면, IT 생태계의 범위가 확장될 경우의 오. 가 일정한 값을 유지하고 있다. 급격한 외부변화가 발생할. 버헤드 증가분이 어떠한 양상을 보이는지 확인하고자 하였. 경우의 측정치를 표시하고 있는 하단의 그래프 (c)와 (d)를. 다. 유전 알고리즘을 적용하지 않은 상태에서, 협업참여 후. 다시 비교해 보면, 동적 재배치 메커니즘이 IT 생태계 시스. 보 시스템을 13개로 하나만 증가시켜 운영할 경우, 기본 사. 템의 지속적인 서비스 성능 유지에 미치는 효과를 더욱 극. 양의 데스크 탑 PC에서 측정된 최적형상 선택에 소요되는. 명하게 알 수 있다. 따라서, Fig. 12의 그래프들에 나타난 이. 시간은 평균 약 14분 가량으로 약 800배 이상 증가되었으며,. 같은 검증결과는 제안된 오케스트레이션 프레임워크가 IT생. 14개로 다시 하나를 더 증가시킨 경우부터는 결과치를 얻을. 태계가 내외부 환경변화에 대응하여, 적절히 형상을 동적. 수 없었다.. 재배치함으로써 IT생태계를 지속시켜 나가는 것에 기여하고 있음을 입증하고 있다.. 반면, 유전 알고리즘을 적용할 경우, 동일한 조건에서 IT 생태계 협업에 참가 가능한 후보 시스템의 개수를 11개. 다음은 두 번째 검증 포인트로, 오케스트레이션 층에 구현. 부터 20개까지 증가시켰을 때 측정된 최적 형상 선택에 소요. 된MAPE-K loop에 의한 동적 재배치 메커니즘 구동으로 인. 된 시간은 Fig. 13의 그래프에 표시된 것과 같이, 약 2.10ms.

(14) 562. 정보처리학회논문지/소프트웨어 및 데이터 공학 제6권 제12호(2017. 12). 있으나, 미리 상황에 특정된 행위 규칙들만이 작동 가능하 다는 한계점을 가지고 있다. MUSIC은 모바일 환경에서 동적으로 변경되는 요구사항 들에 대응하기 위해, 컴포넌트 기반의 개발 방식과 서비스 지향 아키텍처(SOA: Service Oriented Architecture)를 결합 한 형태의 해결책을 제시하고 있다. 모든 필요로 하는 컴포 넌트들을 비즈니스 로직, 문맥 인식, 그리고 적응시의 관심 사가 무엇인지 등의 범주에 따라 분류하고, 주어진 상황에 가장 알맞은 컴포넌트들을 조합해 나가는 방식으로 적응 이 슈를 해결하고 있다. MUSIC의 경우에는 프레임워크의 MAPE-K 적응 목표에 대한 모델을 제시하고 있지 못하기 Fig. 13. The Trend of Elapsed Time with Applying Genetic Algorithm in Unmanned Forest Management IT Ecosystem. 때문에, 경우에 따라서는 적응 계획을 수작업으로 업데이트. 에서 5.37ms로 증가하는 것을 확인할 수 있다. 이러한 최. 를 제안한다기 보다는, 자가 적응형 시스템을 개발하거나. 하거나 교체해야 한다는 단점이 있다. DiVA는 적응 소프트웨어의 하부 구조에 대한 아키텍처. 적형상선택 소요시간의 증가 양상은 세로축의 단위를 ms. 자가 적응형 시스템의 가변성(variability)를 관리하기 위한. (millisecond)가 아니라 초(sec) 단위로 환산할 경우 거의 일. 방법론과 프레임워크를 제공하는 데 초점을 맞추고 있다.. 직선에 가까운 기울기로 표현된다. 차기 최적 형상의 후보. DiVA의 아키텍처는 영역 지향 프로그래밍(AOP: Aspect-. 집합의 크기를 항상 일정한 숫자로 한정하고 있음에도 불구. Oriented Programming)을 기반으로 하고 있으며, 플러그인. 하고, 매우 미미하지만, 증가하는 추세를 보이는 이유는 첫. 형태로 필요한 영역(aspect)들을 동적으로 추가해 나가는 방. 번째 최적형상 선택 시간이 참여 시스템 개수 증가에 비례. 식의 자가 적응을 지원하고 있다.. 하여 증가하기 때문이다. 그러나, 유전 알고리즘 적용 이전. 위에서 언급된 연구결과들이 각자의 장단점을 내포하고. 의 실험 결과에서 발견된 최적형상선택 소요 시간의 기하급. 있지만, 현재까지 발표된 대부분의 자가 적응형 시스템을. 수적인 증가는 발생하지 않았다. 이같은 검증 결과는 비록. 기반으로 하는 프레임워크들은 단일 시스템 내부에서 일어. 시뮬레이션된 환경에서 측정한 제한된 실험의 결과이기는 하. 나는 지역적 적응을 연구 대상으로 하고 있다. System of. 나, 본 논문에서 제안하는 프레임워크가 IT 생태계의 지속성. Systems 연구 분야나 IT 생태계 관련 연구분야에서도 다양. 을 지원함은 물론, IT 생태계 자체의 확장성(scalability)과. 한 도메인을 대상으로 사례연구들을 발표하고 있으나, 제안. 관련한 이슈 역시 해결하고 있음을 입증하고 있다.. 하는 프레임워크들이 아직까지는 개념적인 참조 아키텍처 레벨에만 머무르고 있으며, 프레임워크를 실질적으로 동작. 6. 관련 연구. 가능한 도메인에 적용하여 그 효과를 수치적으로 검증한 연 구 결과는 발표된 바가 거의 없는 실정이다.. 자가적응형 시스템을 지원하는 프레임워크 중 몇 가지 주 목할 만한 연구결과들은 Rainbow[12], MUSIC[17], DiVA. 7. 결론 및 향후 연구계획. [18] 등이 있다. 이 같은 프레임워크들은 모두 MAPE-K loop를 실현하기 위해 제안된 것으로, 런타임에 소프트웨어. 본 논문에서는 IT 생태계가 지속적인 서비스를 제공하는. 시스템 내외부에서 감지되는 환경 데이터들을 소프트웨어. 데 핵심 중인 요건 중 하나인 동적 오케스트레이션 메커니. 스스로가 수집하여 분석하여, 의미있는 환경적인 변화가 감. 즘을 지원하는 프레임워크를 제안하고 있다. 선행 연구에서. 지될 경우 이에 대응하기 위한 계획을 수립하고, 수립된 계. 이미 정의했던 메타 모델을 보완하고 개체화하여, 안드로이. 획을 실행에 옮기는 각자의 메커니즘을 제안하고 있다.. 드 플랫폼 기반의 시뮬레이션된 환경에서 무인 삼림관리 서. Rainbow 프레임워크는 어플리케이션 로직과 적응 로직을. 비스를 제공하는 IT 생태계를 지원하는 프레임워크를 설계. 분리시킨 재사용 가능한 하부구조(infrastructure)를 체계적. 하였다. 제시된 프레임워크는 IT 생태계 시스템이 생물학적. 으로 제안한 첫 번째 사례라는 점에서 의미를 갖는 프레임. 인 관점에서의 생태계와 마찬가지로 환경 변화에 적응하며. 워크이며, 이후 많은 연구들이 Rainbow 프레임워크를 원형. 진화해 가듯이, 지속적인 모니터링을 통해 환경 변화를 인. 으로 다양한 형태의 적응형 소프트웨어를 제안해 오고 있. 지하고 변화된 환경에 최적인 시스템 협업 형상을 선택해. 다. 재사용 가능한 하부구조를 가진다는 점에서 비교적 적. 나가도록 하는 오케스트레이션 메커니즘을 제공한다. 제안. 은 비용과 노력으로 자가 적응을 실현할 수 있다는 장점이. 된 프레임워크는 IT 생태계의 확장으로 인한 오버헤드 이슈.

(15) IT 생태계의 지속적인 운영을 위한 동적 오케스트레이션 프레임워크 563. 해결을 위해 유전 알고리즘을 적용하여 최적 형상의 후보. [3] V. E. S. Souza, A. Lapouchnian, W. N. Robinson, and J.. 집합을 선정하는 방식을 취한다. 선정된 형상 후보들 중 최. Mylopoulos, “Awareness requirements for adaptive systems,”. 적의 형상을 선택하기 위한 평가함수로, 무인기기간 협업. in Proceedings of the 6th International Symposium on. 성능을 비용과 혜택 요소로 정량화하여 협업점수를 도출하. Software Engineering for Adaptive and Self-Managing. 는 함수를 정의하고 있다.. Systems (SEAMS ’11), New York, 2011, pp 60-69.. 현재까지, 적응형 시스템 관련 연구 결과들에서 이미 다 양한 형태의 적응형 소프트웨어 프레임워크와 하부구조들을 제안해 오고 있으나, 아직까지는 단일 시스템 내부의 구성 컴포넌트의 자가 적응 기술에 집중되어 있다. 그 외에 IT 생태계를 비롯하여, 그와 유사하게 사물 인터넷 개념을 바 탕으로 하는 System of Systems 관련 연구들이 있으나, 실 제적으로 구현 가능한 사례 적용 결과라기 보다는 개념적인 아키텍처들을 제안하는 데 그치고 있다.. [4] L. Sabatucci and M. Cossentino, “From Means-End Analysis to Proactive Means-End Reasoning,” in Proceedings of the 10th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS ’15), Florence, 2015, pp.2-12. [5] J. O. Kephart and D. M. Chess, “The vision of autonomic computing,” IEEE Computer, Vol.36, No.1, pp.41-50, 2003. [6] K. Schneider, S. Meyer, M. Peters, F. Schliephacke, and J. A. L. Mörschbach, “Feedback in context: Supporting the. 이와 비교하여, 비록 시뮬레이션 환경이긴 하나, 실제 그. evolution of IT-ecosystems,” Lecture Notes in Computer. 동작 모습을 확인할 수 있는 실질적인 서비스 사례에 적용. Science (including subseries Lecture Notes in Artificial. 한 정량적인 검증 결과를 통해, 제안하는 프레임워크의 실. Intelligence and Lecture Notes in Bioinformatics), Vol.6156,. 효성을 입증하고 있다는 데에 본 연구의 차별성이 있다. 정. pp.191-205, 2010.. 량적인 검증 결과를 분석해 보면, 제안된 프레임워크는 IT. [7] S. Herold, H. Klus, D. Niebuhr, and A. Rausch, “Engineering. 생태계 시스템이 빈번하게 발생하는 내/외부 환경변화에 적. of IT Ecosystems: Design of ultra-large-scale software-. 절히 대응하는 새로운 형상을 스스로 재구성하여 실현함으. intensive systems,” in Proceedings of the 2nd International. 로써 지속적인 서비스를 유지해 나감을 확인할 수 있다. 또. Workshop on Ultra-large-scale Software-intensive Systems. 한, 유전 알고리즘을 활용하여 후보 형상 집합의 사이즈를 한정시킴으로써, IT 생태계 시스템의 확장에 따른 동적 형. (ULSSIS ’08), New York, 2008, pp.49-52. [8] D. Ko and S. Park, “A Dynamic Framework for IT. 상 재배치 오버헤드의 기하급수적인 증가 문제를 해결하고. Ecosystem,” in Proceedings of the Korea Conference on. 있음도 실험 결과를 통해 입증하고 있다.. Software Engineering, PyeongChang, 2014, pp.150-153.. 지금까지의 진행된 연구가 IT 생태계 지속을 위한 최적 의 생태계 구성원을 선택해 나가는 문제 해결에 초점이 맞 추어져 있다면, 향후 연구를 통해서는, 이미 선택된 최적의 시스템 조합에 내재된 취약점들을 협업 실행 이전에 식별하 는 기법 연구에 초점을 맞추어 진행하고자 한다. 이를 위해, 협업시 취약점으로 작용할 수 있는 참여 시스템들 간의 잠 재적인 충돌요소들을 정형 모델 기반 검증을 통해 식별해 내는 기법들을 연구해 나갈 계획이다.. [9] D. Ko and S. Park, “Android Platform Based Self-Adaptive Framework for IT Ecosystem: Unmanned Forest Management System,” in Proceedings of the Korea Conference on Software Engineering, PyeongChang, 2015, pp.335-338. [10] S. A. DeLoach and J. C. Garcia-Ojeda, “O-MaSE: a customisable approach to designing and building complex, adaptive multi-agent systems,” International Journal of Agent-Oriented Software Engineering, Vol.4, No.3, pp. 244-280, 2010. [11] D. Weyns, et al, “On Patterns for Decentralized Control in Self-Adaptive Systems,” Lecture Notes in Computer Science. References. (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), Vol.7475, pp.76-107,. [1] A. Rausch, J. Muller, D. Niebuhr, S. Herold, and U. Goltz,. 2013.. “IT Ecosystems: A new paradigm for engineering complex. [12] D. Garlan, S. Cheng, A. Huang, B. Schmerl, and P. Steenkiste,. adaptive software systems,” in Proceedings of the 2012 6th. “Rainbow: architecture-based self-adaptation with reusable. IEEE International Conference on Digital Ecosystems and Technologies, Campione d'Italia , 2012, pp.1-6. [2] P. Vromant, D. Weyns, S. Malek, and J. Andersson, “On interacting control loops in self-adaptive systems,” in Proceedings of the International symposium on Software engineering for adaptive and self-managing systems (SEAMS ’11), New York, 2011, pp. 202-207.. infrastructure,” Computer, Vol.37, No.10, pp.46-54, 2004. [13] APACHE Felix, Welcome to Apache Felix [Internet] http://felix. apache.org. [14] OSGi Alliance, Specification-OSGi [Internet], http://www. osgi.org/Specifications/HomePage. [15] J. H. Holland, “Adaptation in Natural and Artificial Systems,” MA: University of Michigan Press, 1992..

(16) 564. 정보처리학회논문지/소프트웨어 및 데이터 공학 제6권 제12호(2017. 12). [16] C. Ferreira, “Gene Expression Programming: A New Adaptive. 박 수 진. Algorithm for Solving Problems,“ Complex Systems, Vol.139,. http://orcid.org/0000-0002-5935-9523. No.2, pp.87-129, 2002.. e-mail : [email protected]. [17] S. Hallsteinsen, K. Geihs, N. Paspallis, F. Eliassen, G. Horn,. 1995년 경북대학교 컴퓨터공학과(학사). J. Lorenzo, A. Mamelli, and G. A. Papadopoulos, “A. 2000년 서강대학교 정보통신대학원(석사). development framework and methodology for self-adapting. 2008년 서강대학교 컴퓨터공학과(박사). applications in ubiquitous computing environments,” Journal of Systems and Software, Vol. 85, No.12, pp.2840-2859, 2012. [18] M. Al-Zinati, F. Araujo, D. Kuiper, J. Valente, and R. Z. Wenkstern, “DIVAs 4.0: A Multi-Agent Based Simulation Framework,” in Proceedings of the 2013 IEEE/ACM 17th International Symposium on Distributed Simulation and Real Time Applications, Delft, 2013, pp.105-114.. 1995년～1999년 (주)LG-CNS 근무 2000년～2002년 한국래쇼날 소프트웨어 선임 컨설턴트 2010년～2012년 서강대학교 서강미래기술원 조교수 2012년～현 재 서강대학교 기술경영전문대학원 조교수 관심분야 : 요구공학, 소프트웨어 아키텍처, 자가 적응형 소프트웨어.

(17)