HOME > 와이드안보 > 학술정보 > 한국국방연구원

국방정보체계 소프트웨어의 효과적인 개발전략

기사입력 2019. 12. 12   09:43 최종수정 2019. 12. 12   09:52

국방논단 1781호(한국국방연구원 발행)

김의순
한국국방연구원 군사발전연구센터
eskim@kida.re.kr
   
이 글은 국방 정보체계 소프트웨어의 유용성이나 활용성이 저하되는 문제를 지적하고, 이를 개선하기 위한 개발전략을 제시한 것이다. 사용자 요구내용을 지속적으로 확인해 유연하게 개발하는 방식과 업무 프로세스 분석·설계의 중요성을 강조했고, MDD(Model Driven Development), SOA(Service-Oriented Architecture)와 같은 최신의 방법론과 도구를 적극적으로 활용할 것을 주문했다. 마지막으로 국방 분야에도 클라우드 환경을 구축하기 위한 논의를 촉구했다.

  
소프트웨어를 개발한다고 할 때 쉽게 떠오르는 절차는 이렇다. 먼저 요구사항을 분석하고, 코딩을 해서 구현하고, 시험한 후, 통합 단계를 거쳐, 유지보수에 이르는 것이다. 흔히 얘기하는 일괄 개발 방식(waterfall model)이다. 국방정보체계의 소프트웨어 개발은 모두 이런 방식을 따라 왔다. 개발의 흐름이 한 단계, 한 단계 순차적으로 진행되어야 한다. 요구사항을 파악, 확정하지 않으면 다음 단계인 설계를 진행할 수 없다. 그러므로 설계가 시작되기 전에 요구사항을 명확하게 확정하는 데 공을 들이고 많은 시간을 소모한다.

일괄 개발방식은 요구사항이 안정적인 하드웨어, 또는 정형화된 소프트웨어의 개발에 적합하다. 그렇지만 요구사항이나 문제 자체의 양상이 지속적으로 변화하는 상황에서는 개발 이후 많은 수정과 변경 요청을 유발할 수밖에 없다.

스티브잡스는 1998년 5월 iMac 출시와 관련한 비즈니스위크와의 인터뷰에서, “포커스 그룹에 맞춰 제품을 디자인하는 건 진짜 어려운 일이다. 대부분 사람들은 제품을 보여주기 전까진 자신들이 원하는 게 무엇인지도 정확히 모른다”다고 했다. 즉, 일반 사용자는 앞으로 무엇이 일어날지, 현재 내가 무엇이 필요하고, 무엇을 원하는지 잘 모르고, 말로 표현하기도 어려운 경우가 많다. 소프트웨어 요구사항은 유동적으로 변화하고 예측하기 힘들다. 일괄 개발방식으로 대처할 수 없는 이유다.

그래서 나온 아이디어들이 있다. 그 중 하나가 애자일 개발방식(agile model)이다. 요구사항을 예측해 개발하는 것이 아니라, 일정한 주기를 가지고 끊임없이 프로토타입을 만들어내며, 그때 그때 필요한 요구사항을 더하고 수정해 하나의 커다란 소프트웨어를 개발해 나가는 반복적인 개발방식이다. 모델 주도 개발(MDD: Model Driven Development), 서비스 지향 구조(SOA: Service-Oriented Architecture), 클라우드 환경도 중요하다. 이 글에서 논의하려는 주제다. 먼저 소프트웨어 개발방식이 어떻게 발전해 왔고, 이를 통해 비즈니스가 어떻게 변화했는지 살펴보는 것으로 시작한다.
   
■ 소프트웨어 개발방식과 비즈니스의 변화

소프트웨어산업은 미국에서 1950년대부터 시작되었다고 보는 것이 정설이니 약 70년 된 산업이다. 초기인 1950년대 초에서 1960년대 말까지는 특별한 방법론이 없이 개인의 능력(craftsmanship)만으로 개발했다. 소프트웨어 규모가 커지고 복잡해짐에 따라 이러한 개발방법은 잦은 실패를 가져 왔다. 무기체계의 경우 미국 국방부도 많은 개발 실패를 경험했다. 그 결과 미국을 비롯한 선진국은 1970년대 이후 소프트웨어공학을 도입하게 되었고, 지금까지 빠른 속도로 발전해 왔다. <그림 1>은 이러한 소프트웨어공학의 발전과정과 이에 힘입어 소프트웨어산업이 자동화 정보처리 비즈니스로부터 IT 기반 디지털 비즈니스로 변화한 것을 보여 준다.


선진국은 1950년대부터 1970년대까지의 배치 컴퓨팅(Batch Computing)을, 1970년대부터 1980년대까지의 온라인 컴퓨팅 (Online Computing)을 통해 사람이 할 수 있는 모든 분야에서 정보처리를 자동화했다. 그런데 자동화 대상 분야가 더이상 생겨나지 않음에 따 라 IT 투자의 수익성이 악화되기 시작했다. 1980년대 미국의 산업생산성은 1%밖에 오르지 않았는데, 여기에 조차 IT가 기여한 것은 미미했다. 많은 전문가들 간에 IT 무용론이 거론되면서, 1980년대 후반까지 암흑기가 지속되었다.

Michael Hammer와 James Champy는 ‘Reengineering the Corporation’을 통해 IT 환경에서 최적의 업무 프로세스를 찾아내는 것, 즉 ‘업무프로세스 리엔지니어링(BPR: Business Process Reengineering)’을 제시했다. 이 방법은 새로운 IT 기술을 활용해 정보체계를 구축할 때 종전과 달리 현행 업무를 전산화하는 것이 아니고, 현행 업무를 근본적으로 재설계해 이를 정보체계로 구현하는 것이다. 1980년대 후반 이후 미국의 산업과 정부에서 대대적으로 이를 적용했는데, 1987~1991년간 미국의 IT 투자수익률(Return on Investment)이 제조업 평균 54%, 서비스업 평균 68%로 급증했다. 그 결과 소프트웨어가 암흑시대를 탈출해 다시 기업성장의 원동력이 되었다고 본다. 1990년대부터는 본격적인 정보화시대에 진입했는데 현행 업무 프로세스의 분석을 바탕으로 미래 업무 프로세스를 새롭게 설계하고, 이를 정보체계로 구현하는 것이 정석이 되었다.

BPR은 1990년부터 1995년까지는 클라이언트/서버 컴퓨팅을, 1995년부터 2005년까지는 IT 표준화와 엔터프라이즈 아키텍처(EA: Enterprise Architecture) 기반 프로세스 통합을 통해 E-비즈니스를, 2005년부터 2015년까지는 업무 프로세스 모델(BPM: Business Process Model)과 SOA 기반의 프로세스 통합(Process Orchestration), 그리고 클라우드(Cloud) 서비스를 통해 모바일 클라우드 컴퓨팅을, 2015년부터는 IoT, MSA(Microservice Architecture)와 클라우드 기반의 디지털경제를 가져왔다.
     
모델주도 개발방식(MDD:ModelDrivenDevelopment)

우리나라 소프트웨어산업은 1990년대부터 시작했다고 할 수 있다. 그간 미국 등 선진국이 구현한 것을 모방해 왔으며, 이를 통해 일부 성과를 달성했기에 소프트웨어공학의 필요성을 느끼지 못했다. 현재는 UI(User Interface) 중심으로 개발하고 있다. UI를 먼저 설계하고 이에 대한 데이터를 찾아내는 것인데, 프로세스의 분석과 재설계는 심각하게 고려하지 않는 것으로 보인다. 즉, 정보체계의 업무 프로세스에 관련된 활동이나 기능에 대해 UI를 띄우고, 사용자로부터 필요한 데이터나 텍스트를 입력하게 하고 있다. 특히, 텍스트 내용은 사용자가 보고 확인하는 정도로만 사용되고 있으며, 다른 활동이나 기능에서 데이터로 활용되지 않는다.

MDD는 UI 중심의 코드 개발방식과 달리 정형화된 모델을 중심으로 업무 요구사항을 분석, 설계하고 소스 코드와 산출물을 자동 생성하는 소프트웨어 개발방법이다. 소프트웨어 개발을 위해 MDD는 우선 업무 프로세스를 분석, 설계하는 것을 요구한다. 조직의 디지털 혁신(Digital Transformation)을 위해서는 업무프로세스 모델, 즉 BPM을 정립하는 것이 중요하기 때문이다. 다음으로는 업무 프로세스와 관련된 데이터를 분석, 설계해야 한다. 이를 도메인 모델(DM: Domain Model)이라고 한다. BPM에서 정의된 프로세스와 DM의 데이터들 간의 상호연관성을 분석해 서비스 지향 구조(SOA: Service-Oriented Architecture) 서비스를 도출한다. SOA는 프로세스상의 업무에 해당하는 소프트웨어 기능을 서비스로 판단하고, 그 서비스를 네트워크상에 연동하여 정보체계를 구축해 나가는 방법론이다.

BPM과 DM의 요소들 간의 상호연관성을 쉽게 파악할 수 있도록 소프트웨어공학 방법론에 기반한 선진 모델링 도구들이 많이 나와 있다. 이는 누구나 쉽게 이해할 수 있는 도형들을 사용해 내용을 시각화해 보여주기 때문에 관계자들과의 토의와 검토를 통해 업무 프로세스를 확정하는 데 도움이 된다(<그림 2> 참조). 가령, 업무 프로세스의 변화는 끌어놓기(drag and drop) 기능을 사용해 간단하게 반영할 수 있다. BPM이 완료되면 개발자는 사용자와 협조해 참가 객체의 데이터 항목(entity)과 속성, 데이터 항목의 관계를 표시한 DM을 작성한다. 이 또한 모델링 도구를 통해 자동 생성된다. 여기서 중요한 점은 모델링 도구로 작성된 BPM과 DM은 시각화를 통한 대화 수단으로만 활용되는 것이 아니라 코딩과 직접 연결된다는 것이다. 최소한의 코드 또 는 코드가 전혀 들어가지 않는 (low-code/ no-code: LCNC) 환경에서 정보체계 구현이 이루어지는 것이다.

 
애자일개발방식(agilemodel)

대표적인 사례로 자주 인용되는 것은 미국 FBI의 정보공유자동화체계(Electronic Information Sharing System)다. 처음에는 일괄 개발방식을 적용했다. 2001년부터 2005년까지 수행되었으나 실패로 끝났고, 2006∼2009년에 걸쳐 2차 사업을 시도했다. 2차 사업은 사용자 요구사항을 충족시켰음에도 불구하고 결국에는 채택되지 않는 것으로 결정되었다. 두 차례에 걸친 사업에 모두 6억 달러의 예산이 투입된 것으로 알려졌다. 사업을 다시 시작하면서 애자일 방식을 적용했다. 3년간에 걸쳐 요구사항을 개발하고 개선내용을 반영하는 과정을 반복해 체계개발을 완료했고 결국 채택되었다. 투입된 사업비는 0.99억 달러에 불과했다. 9년의 기간과 6억 달러의 개발비를 들여 실패한 사업을 개발 기간은 1/3로, 예산은 1/6 수준으로 성공한 것이다.

앞에 소개한 것처럼 애자일 개발방식은 소프트웨어 개발 방법론의 하나로 사용자 소요를 반복적으로 반영하고 개발대상을 소규모 배치(batch) 단위로 분할해 하나의 반복주기 내에 설계, 개발, 시험해 통합하는 것이다(<그림 3> 참조). 하나의 반복 기간은 프로젝트마다 다르지만, 일반적으로 1주에서 4주 정도인 경우가 많다. 이 반복 주기를 계속해 나가며 하나씩 배치를 추가 개발하는 것이다.


애자일 방식은 기존의 일괄 개발방식과는 달리 프로젝트 관계자 사이에서 필요할 때 얼굴을 직 접 맞대고 즉각적으로 의사소통할 것을 강조한다. 개발자와 요구사항 을 정의하는 사용자, 시험평가자, 사용자 인터페이스 설계자, 기술문서 기록자 등이 애자일 개발팀을 구성한다. 애자일 팀은 결함을 조기에 식별하기 위해 개발 초기부터 강화된 시험평가를 수행하며, 자동화된 시험평가 및 배포 환경을 구축함으로써 지속적인 통합을 수행한다. 이와 같이 애자일 방식은 단기간에 애플리케이션(앱)을 개발하고, 빠르게 피드백을 받아 이를 변경하고 수정할 수 있어 개발과 배포 속도가 빨라지게 한다. 이는 앞서 말한 LCNC 플랫폼에서 제공하는 모델링 도구를 통해 가능하게 된다.
  
서비스지향구조(SOA:Service-OrientedArchitecture)

과거의 정보체계는 업무수행을 담당하는 컴포넌트(Comp)가 상세하게 규정된 인터페이스를 통해 상호 단단하게 결합(tightly coupled)되어 있으며, 업무수행 절차에 따라 최적화된 순서로 연결되어 있었다. 그 결과 정보체계는 컴포넌트 하나를 변경할 경우, 다른 수많은 컴포넌트에 영향을 미치게 되었다. <그림 4>는 컴포넌트 1∼6이 밀착 결합된 상태에서 컴포넌트 1의 변경이 요구될 때를 보여주고 있다. 만약 사용자가 새로운 데이터를 요구하면, 새로운 컴포넌트를 추가 또는 기존 컴포넌트를 변경해 관련된 모든 컴포넌트와 결합해야 하는데, 이 작업이 대개 1~2년이 걸리는 상황이었다. 개발자는 새로운 컴포넌트와 기타 컴포넌트에 대해 인터페이스를 개발하고, 이를 통해 데이터가 상호 전송, 공유되는 것을 확인해야 했다.


그 결과 컴포넌트로 구성된 정보체계의 소프트웨어, 즉 앱은 <그림 5>의 왼쪽 부분과 같이 물리적 인터페이스 또는 DB 인터페이스를 통해 단단한 결합으로 연동하면서 순차적으로 수행되어야만 한다.

이러한 문제점을 해결하는 방법은 컴포넌트를 잘 정의된 인터페이스(Application Program Interface: API)를 갖 춘 독립적이고 재사용 가능한 모듈인 ‘서비스’(services)로 변환하는 것이었다. 이런 방식이 SOA다. 이렇게 ‘서비스’를 기본으로 구축하면 정보체계 소프트웨 어(앱)는 상세한 상호 인터페이스 없이도 <그림 5>의 오른쪽 하단에서와 같이 데이터를 통해 연동할 수 있게 된다. 데이터 연동은 기반서비스인 NCES(Net-Centric Enterprise Services)를 통해 수행된다. 이제 정보체계 소프트웨어는 다양한 데이터베이스로부터 추출된 데이터를 신속하게 얻고, 다양한 형태로 전송할 수 있게 된다.

<그림 6>은 긴급표적타격(Time-Sensitive Target: TST) 작전 수행을 위해 미국에서 정보체계 소프트웨어 개발에 SOA를 적용한 사례다. TST 작전은 탐색(Find), 식별(Fix), 추적(Track), 표적선정(Target), 교전(Engage), 평가(Assess)의 6개 업무를 연속적으 로 거치며 수행된다. 각 업무에 대해 공간지리정보검색 서비스, 운용맥락 서비스, 공격분석 서비스, 무기-표적할당 서비스와 UAV 비디오 서비스가 담당하도록 만들었다. 모두 독립적이고 재사용 가능한 모듈로 데이터를 통해 연동되는 것이다.

 
클라우드환경도입

앞서 말한 SOA는 레고 블록을 조립해 원하는 모양으로 만드는 것에 비유할 수 있다. 여기서 중요한 점은 SOA를 적용하는 개발자는 클라우드 환경이 있어야 서비스를 공유하고 협업해 자유롭게 앱을 개발할 수 있다는 점이다. 개발에 드는 시간과 비용이 절감되고 유지보수도 용이하다. BPM, MDD와 애자일 방식을 지원하고 코딩을 적게 하는 플랫폼인 LCDP(Low Code Development Platform)도 클라우드 환경에서 제공된다. 이를 PaaS(Platform as a Service)라고 한다. LCDP는 직접 코딩을 하는 대신 시각적인 그래픽과 형상을 통해 앱을 개발하는 환경을 제공하는 소프트웨어를 의미한다.

미 국방부는 2012년 7월에 클라우드 컴퓨팅전략(Cloud Computing Strategy)을 발표했다. 여기서 제시한 비전은 ‘정보보호를 받는(assured) 국방 클라우드 환경을 제공’하는 것이다. 2017년 3월에는 클라우드 컴퓨팅 정보보호 요구사항 지침(Cloud Computing Security Requirement Guide)을 제시했다. 미 국방부는 클라우드 환경을 도입하는 목적을 다음과 같이 말하고 있다.

“미국 정부는 IT 체계의 민첩성(agility)을 높이려 애쓰고 있다. 그러나 민첩성은 오픈 소스를 쓰든, 다른 것을 쓰든, 코딩을 더 하는 것으로는 달성되지 않는다. 민첩성은 코딩을 하지 않음으로써 이루어질 것이다.”

미 국방부 국방정보체계국(Defense Information System Agency)은 2014년부터 모바일앱스토어 (Mobile Application Store: MAS)를 운영하고 있는데, 여기에 BPM 중심의 LCDP 제품으로 ‘Appian’이 추천되어 있다. 코드-프리(code-free) 앱 구성을 통해 미 국방부의 모든 부서에서 다양한 업무 프로세스에 대해 새로운 앱을 가장 빠르게 배치할 수 있게 하는 도구이다. Appian의 모바일 BPM 능력은 최신 모바일 기기에서 프로세스와 시스템을 빠르게 최신화하며, 그 결과 사용자로 하여금 언제, 어디서나 중요한 임무결심과 활동을 하게끔 한다고 설명하고 있다.
  
맺음말

그동안 우리는 사용자 요구사항을 예측해 국방 소프트웨어를 일괄 개발해 왔다. 그 결과 국방정보체계의 유용성이나 활용성이 저하되는 문제가 항상 지적되어 왔다. 사용자가 처음에 요구한 것이 분명하지 않고, 변화에 유연하게 대처할 수 없는 방식을 고수했기 때문이다. 사용자 요구내용을 지속적으로 확인해 그에 맞춰가는 방식으로 바꿔나가야 한다. 보다 근본적으로는 업무 프로세스 분석과 설계를 통해 요구사항 자체를 정립하는 것이 필요하다.

이제 우리 군의 정보체계 소프트웨어 개발전략을 개선할 시점에 와 있다. 이 글에서 제시한 MDD, 애자일 개발, SOA 등과 같은 최신의 방법론과 도구를 적극적으로 활용해야 한다. 그렇게 하려면 국방에도 클라우드 환경을 도입하는 것이 필수다. 미국이 국방분야에서 클라우드 전략을 수립하고 정보보호 지침을 제정하는 의미를 잘 생각해봐야 한다. 로드맵을 준비하고, 클라우드 아키텍처를 수립하는데 더 많은 관심과 논의를 촉구한다.

 
  
※ 본지에 실린 내용은 집필자의 개인적 의견이며, 본 연구원의 공식적 견해가 아님을 밝힙니다.


<무단전재 재배포 금지. 국방일보> 






< 저작권자 ⓒ 국방일보, 무단전재 및 재배포 금지 >