AdSense 728x90




자체기술로 패트리어트 연동 성공한 우리 공군 military/politics

호사가들에게 체계통합(SI: System Integration)이란 참 심심한 소재다. 수백억을 들인다 한들 휘황찬란한 볼거리를 제공해 주지는 못하기 때문이다. 그래서인지 MCRC와 패트리어트의 연동이 우리 공군이 자체적으로 개발한 소프트웨어에 의해 성공했다는 소식은 그다지 큰 반향을 울리지 못했다. 백억 원이 넘는 예산을 절감하고 전력화 시기를 앞당겼다는 성과보다도 더욱 중요한 것은, 우리 공군이 향후 네트워크중심전 수행에 필수적인 원천기술을 확보하고 있음을 확인한 것이라 할 수 있다.

국방부가 10월 24일 미국에서 열린 한미연례안보협의회(SCM)에서 패트리어트 PAC-3 도입을 공식화하면서 다시금 북한 탄도미사일 위협과 우리 군의 대책에 대한 관심이 높아졌다. 때맞추어 공개된 "현재 한국군의 PAC-2 체계로는 탄도미사일 요격 능력이 40% 이하"라는 한국국방연구원(KIDA)과 미국 미사일방어국(MDA)의 연구 결과 또한 이에 대한 논란을 부추겼다. 분명 PAC-3를 도입하면 지금보다 탄도미사일에 대한 방어 능력은 높아지기는 할 것이다.


그러나 우린 무기체계는 도입하고 난 이후부터가 진정한 시작이라는 사실을 종종 잊는다. 우리는 지금까지 도입 자체에만 매달려 군수 지원 등을 비롯한 후속 조치의 부실로 국민의 혈세를 들여 도입한 무기를 제대로 활용하지 못하는 꼴을 많이 목격했다. 기존의 무기체계들과 제대로 통합을 시키지 못해 곤욕을 치르는 경우도 있었다. 과연 패트리어트는 우리 군의 방공무기체계와 잘 융화될 수 있을까? 미국에서 개발하고 미군이 운용하던 무기체계이니 당연히 잘 되지 않겠느냐고 막연하게 여기기 쉽다.

미군과 우리 군 작전환경의 차이

안타깝게도 문제는 그리 단순하지가 않다. 미군이 방공작전을 수행하는 환경과 우리 군이 방공작전을 수행하는 환경은 많이 다르기 때문이다. 미군은 지속적으로 이동을 하는 가운데 주둔하고 있는 지역을 탄도미사일과 적 항공기의 위협으로부터 보호해야 하기 때문에 방공작전에서 기동성을 고려하는 것이 기본이다. 걸프전이나 이라크전을 떠올려 보라. 포대는 신속하게 전개 또는 이동을 준비할 수 있어야 한다. 따라서 모든 장비는 차량에 탑재되어 있거나 적어도 차량으로 수송이 가능해야 한다. 이는 호크부터 패트리어트, 그리고 현재 개발 중이나 결국 실전 배치가 안 되는 비운에 빠질 것으로 보이는 MEADS까지, 대부분의 미국 방공무기체계에서 항시 고려되어 왔던 사항이다.


그렇기 때문에 미군의 방공무기체계는 주로 대대 단위로 작전을 수행한다. 이는 미군의 작전환경에 따른 것으로 문제가 될 이유가 전혀 없다. 그러나 이를 우리 작전환경에 그대로 적용하려고 할 때 문제가 발생한다. 우리는 MCRC(Master Control and Reporting Center: 중앙방공통제소)를 중심으로 통합 방공작전을 수행하고 있기 때문이다. 차기유도무기(SAM-X) 사업으로 패트리어트 무기체계가 처음으로 우리나라에 소개되었을 때에도 개발업체인 레이시온(Raytheon)이 제시한 한국형 체계 배치도에서는 패트리어트 대대와 MCRC가 서로 직접 연결되어 있지 않았다.


패트리어트 작전통제 체계는 크게 대대급 작전통제소인 ICC(Information Coordination Central)와 포대의 교전통제소인 ECS(Engagement Control Station)으로 나눌 수 있다. 여기서 대대급 통제소인 ICC와 우리 MCRC를 연동시키는 것이 우리 작전환경에 적합한 체계 통합을 위한 중대 과제가 되었다. 그러나 이는 고난도의 기술을 필요로 하는 데다가 우리 군에서는 이러한 연동을 해본 경험이 전무했다. 그리하여 방위사업청은 2011년 2월, MCRC와 ICC 연동을 위한 소프트웨어 개조를 미국 정부측에 요청했다. 이를 위한 예산으로는 약 129억 원이 책정되었다. 그러나 여기에서도 난관이 발생했다.


우리의 작전정보와 노하우를 누출시킬 것인가

수차례 회의를 거치고 미국 정부와 업체(레이시온)는 2011년 6월경 우리 MCRC 체계의 핵심 소프트웨어의 소스코드(source code)를 제공할 것을 요구하였다. 소스코드란 소프트웨어를 실제로 개발할 때 사용한 명령어들이 담긴, 일종의 설계도라 할 수 있다. 이는 MCRC와 패트리어트 ICC를 연동시키기 위해서는 자연스러운 요구였다. 그러나 MCRC 소프트웨어에는 우리 군의 주요 작전정보는 물론이고 수년간 MCRC를 운용하면서 발전시킨 여러 가지 기술적인 노하우가 담겨 있었다. 아무리 우방국인 미국이라지만 이러한 정보와 기술을 그대로 넘겨줄 수는 없는 일이었다.


그 이후로도 3개월 가까이 소프트웨어 제공방식에 대한 회의가 여러 차례 열렸다. MCRC 소프트웨어의 전부를 제공할 수는 없는 노릇이었기에 결국 소프트웨어의 일부만을 미국 측에 제공하고 그것을 토대로 미국 측에서 개발한 부분적인 소프트웨어를 다시 우리 MCRC에 이식하기로 하는 절충안이 나왔다. 그러나 이는 작전정보와 노하우의 유출은 최소화시킬 수 있는 반면, 작전 측면에서 신뢰도를 떨어뜨릴 수 있었다. 소프트웨어의 전반적인 구조를 모른 채 일부만 개조를 하면 그 사이에서 충돌이 발생할 여지가 있다. 혹여나 문제가 발생하면 MCRC 시스템 전체가 마비될 수 있다. 대한민국의 영공 방위를 책임지는 MCRC에서 이러한 상황이 용납될 리 만무했다. 그야말로 이러지도 저러지도 못하는 딜레마에 빠진 것이었다.

작전정보통신단 "독자 개발 추진" 제안

한편, 당시 공군 내에서 MCRC와 패트리어트 체계의 연동을 독자적으로 수행할 수 있는 가능성을 검토하고 있는 조직이 있었다. 항공우주작전과 IT의 융합을 통해 네트워크중심전(NCW) 환경을 조성하고 공세적인 항공우주작전 수행을 지원하기 위해 2010년 5월 창설된 공군 작전사령부 소속의 작전정보통신단이었다. 당시 창설된 지 1년을 조금 넘긴 상태였으나 부대 요원들은 과거 MCRC 체계 전력화 당시 2년간 전문교육을 받았던 소프트웨어 개발요원을 포함하여 조종, 항공통제, 방공포병, 정보통신 등의 항공우주작전에 필요한 모든 병과가 모여 있어 높은 전문성을 갖추고 있었다.


부대장이 전술데이터링크와 무기체계 연동기술을 주제로 한 세미나에 연구자 및 발표자로 직접 참가하는 등 무기체계 연동에 대해 심도 있는 연구로 전문적인 기술을 축적하고 있던 작전정보통신단은 곧 공군 본부에 연동 소프트웨어를 자체 개발할 수 있다는 의견을 제시했다. 당연히 공군 본부와 방공포병사령부에서는 논란이 일었다. 자체개발 착수를 위해 공군 참모총장 보고자료를 준비하던 당시를 회상하며 작전정보통신단장(대령 구정, 공사 30기)은 이렇게 말했다.


"많은 분들이 '과연 작전정보통신단이 할 수 있을까?' '누구도 해본 적 없는 대형 프로젝트를 공군이 독자적으로 수행할 수 있을까?'라며 걱정과 우려를 보였던 것이 사실이다. 그러나 우리는 그동안 쌓아온 연구개발 성과들을 믿을 수밖에 없었다."

일각에서 제기한 우려는 상당했다. MCRC와 패트리어트를 연동시키는 소프트웨어를 개발한다는 것은 우리 군이 지금까지 시도해 본 적이 없는 대형 사업이었다. 만일 개발이 실패로 끝날 경우, 그만큼 패트리어트의 온전한 전력화는 늦어질 수밖에 없었다. 패트리어트의 조기 전력화를 최우선으로 여기고 있던 관계자들이 가장 우려한 부분이 바로 이것이었다. 작전정보와 기술 누출의 우려와 조기 전력화 실패에 대한 우려. 어느 쪽도 쉽게 선택할 수 없는 일이었다. 공군은 고민에 빠졌다.


<더 읽기_한겨레 디펜스21로 넘어갑니다>


덧글

  • shaind 2012/12/23 09:44 #

    근데 패트리어트 icc와 bcp 모두 링크 16을 사용하고, mcrc(제2 mcrc)도 링크 16을 사용하는 것 아니었나요?

    둘 사이를 si하는 건 물론 중요한 업적이긴 하지만 딱히 인상적인 건 아니네요.

    사실은 제2 mcrc랑 패트리어트가 도입된지가 벌써 몇년째인데 이제야 그게 되었다는게 한심한 것일지도.


AdSense 300x250