기사 공유하기

이 글은 2022년 2월 공개된 미국 국방부(DoD)의 소프트웨어 현대화 전략(Software Modernization Strategy, 2021. 11.)을 분석한 것이다.1) 이 전략의 버전 1.0을 최초 발표한 것은 2021년 11월이며, 내부 검토를 거쳐 2022년 2월 일반에 공개했다. 소프트웨어 현대화 전략은 DoD의 디지털 현대화 전략의 중요한 한 축이며, 더 범위를 확대하면 미국 정부의 소프트웨어 현대화 전략과 맥을 같이한다고 볼 수 있다.

미국 국방부(DoD)의 소프트웨어 현대화 전략(Software Modernization Strategy, 2021)

이를 통해 현재 우리나라 국방부에서 추진하고 있는 디지털 전환 전략에서 상용 클라우드 활용이 왜 중요한지, 그리고, 이를 통해 지향하고자 하는 목표, 이러한 목표를 달성하기 위한 원칙, 이의 구현을 위한 기본적인 아키텍처는 어떻게 구성해야 하는지 등 다양한 영역에서의 인사이트를 얻을 수 있다.

전략서의 내용을 문장 단위로 이해하는 것도 필요하지만, 이런 소프트웨어 현대화 전략이 필요하게 된 배경, 이를 위해 제시된 원칙 및 프레임워크를 통해 강조하고자 하는 부분이 무엇인지를 분석해 보는 것이 중요하다. 이 글에서는 후자의 관점에서 의미를 찾아보려 한다.

1. 왜 소프트웨어 현대화가 필요한가?

현대전의 양상은 전장에서의 전투뿐만 아니라 주요 인프라 및 주요 방어자원에 대한 공격에 더 큰 비중을 두고 있다. 이러한 공격에 대비하기 위해서는 다양한 첨단 기능을 갖춘 장비들이 적시에 제대로 작동함과 동시에, 실제 전장에서 전투를 수행하는 자원과 긴밀한 연계도 필요하다. 따라서 적은 이런 ‘연계’를 깨뜨리고, 방어자원을 무력화시키기 위한 노력을 끊임없이 경주하게 된다. 상대의 빈틈을 겨냥한 사이버 공격이 이러한 노력의 대표적인 예이다.

이런 공격 패턴은 성공할 때까지 계속 ‘소프트웨어’로 업데이트된다. 이런 새로운 공격 시도를 알아채고 이에 대비하는 것은 그야말로 ‘속도전’, 즉 누가 먼저 새로운 기능을 탑재한 소프트웨어를 만들어 가동하느냐에 그 성패가 달려있다고 해도 과언이 아니다. 특히 방어와 공격의 경계가 불분명한 현대전에서의 전투 능력은 결국, 소프트웨어에 의해 구동되는 공격 및 방어자원의 성능에 달려있다.

출처: 미 국방부

국방 분야는 공공부문에서도 가장 최신 기술을 먼저 개발하고 적용하는 것으로 일반적으로 알려져 있다. 하지만 실제로 새로운 기술을 완성하여 이를 필드에 적용하기까지의 라이프 사이클 기간이 매우 긴 것도 사실이다. 새로운 기술을 무기화하고 이를 실전에 배치하기까지 오랜 기간의 시험과 검증이 필요하기 때문이다. 이런 관행이 소프트웨어 개발 분야에서 그대로 이어진다면 국방 분야에서의 전력 우위를 절대 담보할 수 없다. 전 세계 주요 소프트웨어 및 서비스 시장에서 우위를 차지하고 있는 미국 기업의 소프트웨어 역량을 국방 분야에서도 적극적으로 활용하는 것이 필요하다는 공감대가 형성될 수밖에 없다.

이에 상용 클라우드를 최대한 활용하기 위한 프로젝트로 JEDI가 추진되었으나, 단일 기업과 계약하는 구조상 많은 잡음을 내며 좌초했다. 뒤이어 출범한 프로젝트가 JWCC(Joint Warfighting Cloud Capability)이다. JEDI와 JWCC 모두 상용 클라우드를 활용하여 기민하게 소프트웨어 요구사항에 대응하는 것을 목표로 한다. 여기에는 전장에서 필요한 컴퓨팅 자원의 효율적 배치 및 활용뿐만 아니라, 언제든지 빠르고 유연하게 소프트웨어를 필요에 맞게 개발하여 투입하는 것을 포함한다.

출처: 미 국방부

이러한 목표를 성공적으로 달성하기 위해서는 기존 국방 분야에서의 소프트웨어 개발 방식을 혁신해야 한다. 민간 소프트웨어 기업에서 이미 정착되어가고 있는 애자일 개발 방법론, 데브옵스 자동화와 같은 방식을 국방 분야에서도 활용할 수밖에 없다. 이에 따라 ‘소프트웨어 현대화 전략’이 등장한다.

소프트웨어 현대화 비전을 담은 슬로건을 원어로 그대로 옮기면 다음과 같다.

“Deliver Resilient Software Capability at the Speed of Relevance”

탄력적(Resilient)이란 단어에는 고품질의, 안전한(secure), 그리고 극한 상황에서도 잘 버티고 또 회복할 수 있는 능력 모두를 포함하고 있다. 한편 “Speed of Relevance”는 우리말로 딱 맞는 표현을 찾기가 쉽지 않지만, 대략 “적절한 수준의 빠른 속도” 정도로 해석할 수 있을 것 같다. 무조건 “빠른 것”이라고 해석하기에는 고품질이나, 보안성과 거리가 멀다는 뉘앙스를 줄 수 있을 것 같고, 상대적 우위를 늘 유지할 수 있는 수준의 빠른 대응 정도로 해석하는 것이 바람직하다. 즉, 국방부 내부 및 모든 파트너가 앞선 소프트웨어 기업의 개발 프로세스 수준을 갖춤으로써 경쟁력을 확보하는 것이라 볼 수 있다.

국방부 문서에서는 직접 언급되지 않았지만, 소프트웨어 현대화는 향후 진행될 JWCC 프로젝트와도 긴밀하게 연결되어 있다고 분석할 수 있다. JWCC의 경우 이미 폐기된 JEDI와는 달리 아마존, 마이크로소프트, 구글, 그리고 오라클 이렇게 4개의 회사와 계약하게 된다. 90억 달러에 달하는 대형 프로젝트이지만, 각 회사가 구체적으로 어떤 태스크를 수행할 것인지는 계약 시점에 확정하지 않는다. 그 대신 수시로 새로운 태스크가 생성되면, 이들 4개 사가 경쟁하여 이를 수주하는 방식이 될 것으로 알려져 있다.

아직 우리나라 공공 기관 조달방식에는 없는 IDIQ(Indefinite Delivery, Indefinite Quantity) 계약이 활용된다고 한다. 이러한 계약을 소프트웨어 개발 또는 클라우드서비스 오퍼링(CSO)에 적용하기 위해서는 태스크 생성부터 업체선정, 개발/완료까지 매우 짧은 사이클로 이루어져야 한다. 비전에서 담은 “Speed of Relevance”가 떠오르는 대목이다. 이는 단순히 비전 선언만으로 되는 것은 물론 아니며, 이를 뒷받침할 수 있는 원칙과 이에 기반한 프레임워크가 필요하다.

2. 통합 원칙(Unifying Principles)의 의미

미 국방부는 소프트웨어 현대화 전략에서 제시하는 기본 원칙을 ‘통합 원칙’이라는 타이틀로 제시하고 있다. 소프트웨어 현대화에 따른 다양한 분야에서의 변화와 혁신이 일어나게 되는데, 어떤 경우든 반드시 ‘짚고 넘어가야 할’ 기본 수칙이라고 볼 수 있다. 여기에 ‘통합’이란 수식어를 붙인 이유는 다음과 같이 해석할 수 있다.

각 분야에서 소프트웨어 현대화에 따른 변화와 혁신이 중장기적으로 이루어지다 보면, 분야의 특성에 맞도록 유연하게 진화할 가능성이 있다. 물론 이런 유연성은 한편으로는 매우 바람직한 현상이다. 그러나 이러한 유연성이 지나치다 보면 원래 소프트웨어 현대화를 통해 거시적으로 이루고자 하는 비전을 특정 분야에서 훼손하거나 일부 포기해야 할 수도 있다. 따라서 전체적으로(holistic) 아우를 수 있는 지침을 통해 비전에 도달할 수 있도록 해야 한다. 하지만 이러한 지침으로 인해 신기술을 유연하게 도입하거나, 새로운 경험을 시도하는 것이 막혀서는 더더욱 안 된다. 통합 원칙이 제시되는 이유는, 오히려 다양하게 혁신을 이룰 수 있는 기본 토대를 제공하기 위함이다.

DoD 소프트웨어 현대화 전략에서 제시하는 통합 원칙은 매우 간결하면서도 명확하게 정의하고 있다. 그 다섯 개 항목은 다음과 같다.

  1. 그 첫 번째는 보안 및 안정성, 품질, 그리고 속도와 같이 각기 다른 속성, 또는 간혹 모순될 수 있는 속성에 대한 우선순위의 설정 원칙을 제시하고 있다.
  2. 두 번째는 클라우드와 데이터의 중요성을 강조하고 있으며,
  3. 세 번째는 기업의 상용 기술을 우선 활용하는 것을 제시하고 있다.
  4. 네 번째는 조직과 사람, 리더십의 중요성이다.
  5. 다섯 번째는 소프트웨어 코드를 개발하는 것뿐만 아니라 정책과 프로세스 표준 등 아이디어가 실현되기 위해 필요한 요소들을 열거하고 있다. 구체적인 내용은 국방부 문서를 참고하기를 바란다.

우리나라 국방부도 유사한 도전에 직면해 있다. 클라우드로의 전환, 특히 민간클라우드를 적극적으로 도입하기 위한 전략 수립에 많은 고민이 있는 것으로 알고 있다. DoD의 소프트웨어 현대화 원칙에도 이 부분은 두 번째 및 세 번째 항목에 명시되어 있다. 이를 단순히 ‘민간 클라우드 도입 활성화’를 목표로 진행하는 것은 바람직하지 않다. 앞서 소프트웨어 현대화 비전에 대한 분석에서도 언급했듯이, “왜” 해야 하는가에 대한 공감대가 있어야 한다.

이는 국방부만의 공감대가 아니라 국가 전체의 디지털 전략과도 일관성이 있어야 한다. 지금 살펴보고 있는 DoD 소프트웨어 현대화 전략도 바이든 정부에서 끊임없이 나오고 있는 IT 현대화, 사이버 보안 현대화 등 소프트웨어 기술 경쟁력 강화 정책과 일맥상통하고 있다. ‘왜?’에 대한 공감대가 형성되면 그다음에 기본 원칙이 나오는 것이 순서다. 모호함을 최대한 배제하며, 멋있고 함축성 있는 문구가 아닌, 누가 읽어도 그 의미를 똑같이 해석할 수 있도록 명확한 단어를 이용해 구체적으로 기술하여야 한다.

3. 소프트웨어 현대화 프레임워크

소프트웨어 현대화가 ‘왜; 필요한가에 대한 공감대 바탕에서 이를 추진하면서 반드시 짚고 가야 할 기본 원칙을 만들었다면 이제 실행 전략이 등장할 순서다. 이를 “소프트웨어 현대화 프레임워크”로 전략서에서 설명하고 있다. 여기에는 전 과정에 필요한 기술적 요소, 프로세스, 그리고 이를 통해 얻는 성과 등이 망라되어 있다. (아래 도표 참조)

소프트웨어 현대화 프레임워크

프레임워크라 불리는 이유는 이를 일종의 기초 설계도로 볼 수 있기 때문인데, 이를테면, 내 분야에서 소프트웨어 현대화를 위한 다양한 기술을 도입하고, 조직을 만들며, 조직원들을 양성할 때 여기서 제시된 프레임워크를 참조하여 자신의 필요에 맞게 적용할 수 있기 때문이다.

3.1 기술 요소

기술 요소에는 소프트웨어 현대화를 위해 직접 적용되는 기술 및 직간접적으로 연결될 수 있는 주요 기술들을 망라하고 있다. 기술 이네이블러(Enabler)로는 다음과 같은 것을 들고 있다.

  • DoD 엔터프라이즈 클라우드 환경: 멀티-벤더, 멀티-클라우드를 환경을 의미한다. JWCC를 겨냥한 클라우드 생태계를 지향하는 것으로 해석할 수 있다. 소프트웨어 현대화의 가장 근본이 되는 이네이블러라고 봐도 과언이 아니다.
  • 디자인 패턴: 빈번히 반복되어 발생하는 문제를 해결하는데 디자인 패턴을 활용하여 소프트웨어를 재사용함으로써 탄력적으로 속도감 있게 대응하기 위한 것으로 풀이된다. 여기서 말하는 디자인 패턴과 객체지향 소프트웨어에서 얘기하는 디자인 패턴은 다소 다른 의미로 이해된다. 둘 다 유사한 목적이기는 하지만, 본 소프트웨어 전략서에서 얘기하는 디자인 패턴은 개발과정에서 반복 활용되는 부분을 최대한 잘 활용하기 위한 가상 환경 및 템플릿을 제공하는, 즉 프로세스 자동화에 더 가까운 것으로 분석된다. 이를 활용하여 일관성 있는 아키텍처 및 형상 관리를 할 수 있으며 이는 곧 고품질의 소프트웨어 생산에 도움이 될 수 있다는 뜻이다.
  • 데브섹옵스 및 도구 활용: 국방부의 소프트웨어 현대화 전략에서 가장 핵심 부분이라고 판단된다. 소프트웨어 개발 모든 과정에 데브섹옵스 파이프라인을 적용함으로써, 첫째 애자일 방식의 소프트웨어 개발이 가능해지며, 둘째는 전 과정에 걸쳐 보안 위협 요소를 검토함으로써 안전한 소프트웨어 생산이 가능하며, 셋째 이러한 전 과정이 자동화되어 배포됨으로써 전장 등 현장에서의 수요에 신속하게 대응할 수 있다. 이 역시 향후 JWCC가 가동되면 매우 중요한 역할을 한다. 신속하게 태스크 오더를 내고, 이를 담당할 기업을 선정하며, 이를 개발, 검증, 배포하는 전 과정을 데브섹옵스를 통해 자동화함으로써 딜리버리 기간을 단축할 수 있을 뿐만 아니라, 배포 및 사후 관리도 데브섹옵스 파이프라인 안에서 행해진다. 이는 배포 후 문제 발생 시 다시 데브섹옵스 파이프라인을 반복적으로 거침으로써 상시 개선이 가능하고, 예기치 못한 상황에서도 기민하게 대응할 수 있다는 뜻이다. 즉, 전장 및 모든 국방 분야에서 경쟁적 우위를 지키기 위해 매우 중요한 역할을 한다고 볼 수 있다.
데브옵스(DevOps; 개발과 운영 자동화)에 ‘보안'(Sec)이 더해진 데브섹옵스 툴체인 (출처: DyanaTrace)
  • 엔터프라이스 서비스: 바로 사용할 수 있는 상용 서비스를 활용하는 것을 의미한다. 다양한 서비스가 가능하다. 예를 들면, 보안관제, 신원 관리(Identity Management) 등 이미 상용으로 제공되는 서비스들을 환경에 맞게 적용할 수 있다. 특정 기능만 API(Application Programming Interface) 호출을 통해 활용함으로써 다른 소프트웨어에 해당 기능을 통합할 수도 있다.

이 밖에도 직간접적으로 활용되는 기술, 신기술, 관련 인프라 기술 등을 테크 포스 멀티플라이어(Tech Force Multiplier)로 열거하고 있다. 이는 국방부의 CIO가 관리해야 하는 기술 자산 로드맵에 포함될 수 있다. 매년 이러한 로드맵의 검토 및 수정이 수반될 수 있다.

3.2 프로세스 전환(Transformation)

앞서 언급된 기술 요소들이 소프트웨어 현대화를 위한 다양한 업무에 적용됨으로써 프로세스의 전환을 가져올 수 있다. 프로세스 전환은 소프트웨어 현대화의 비전을 실현하는 방향으로 점진적으로 이루어지는 것이 일반적이다. 이런 전환의 과정에서 소프트웨어 현대화를 위한 통합 원칙이 고려되어야 함은 물론이다.

소프트웨어 현대화 성과를 극대화하기 위한 프로세스 전환이 필요한 경우, 또는, 그 반대로 이러한 현대화가 성과로 나타나는 프로세스 전환 모두 있을 수 있다. 예를 들어, 조직의 개편, KPI 재설정, 인센티브 시스템, 정책 및 규정 제정과 같은 전반적인 비즈니스 관행상의 프로세스 전환이 필요할 수 있다. 반면 소프트웨어 획득(Acquisition) 프로세스 같은 경우 일부 전환의 필요성도 있지만, 소프트웨어 현대화의 성과로 획득 기간이 획기적으로 단축될 수 있다. 즉 성과로 바로 연결되기도 한다.

프로세스의 전환은 상당 부분 자동화에 의한 영향이 크다. 다시 한번 데브섹옵스를 언급하지 않을 수 없는데 소프트웨어 획득 및 보안, 테스트 프로세스는 데브섹옵스 파이프라인과 연계되어 동작해야 한다. 특히 사이버 생존 가능성(Cyber Survivability)은 실시간으로 데브섹옵스 파이프라인 전 과정에서의 보안 활동에 전적으로 달려있다. 개발 및 테스트 과정에서 정적 분석 및 동적 분석, 배포 이후의 실시간 감시 및 위협 탐지 활동이 자동화되어 문제 발생 시 즉각 대응할 수 있어야 한다. 얼마나 빨리 탐지하고 조치를 취할 수 있느냐가 생존의 관건이기 때문이다.

프로세스의 전환은 당연히 내부 인력의 업무에도 영향을 미친다. 자동화를 포함한 재편된 프로세스에서는 관련 인력의 요구 역량에 변화를 가져올 수도 있다. 특히 소프트웨어 현대화 과정에서 필요로 하는 소프트웨어 개발 역량의 변화는 적지 않을 것이다. 몇 가지 예를 들면, 인공지능 기반 애플리케이션이 개발 역량, 초연결된 장비들로부터 데이터를 주고받기 위한 대규모 데이터 처리 역량, 소프트웨어적으로 인프라를 구성할 수 있는 역량, 클라우드 네이티브 컴퓨팅을 위한 아키텍처 및 도구 활용 역량 등 새로운 역량을 갖춘 인력이 있어야 한다. 이를 위한 인력 개발을 절대 간과할 수 없다. 소프트웨어 현대화가 성숙해질수록 내부 인력의 역량이 더욱 중요해진다. 전체 프로세스가 내/외부 구분 없이 파이프라인을 타고 돌아가는 상황에서 각각의 역할을 명확하게 구분하여 책임을 묻는 방식은 제대로 동작하기 어렵기 때문이다.

3.3 소결

소프트웨어 현대화 프레임워크에서 “결과”를 명시한 것은 궁극적으로 추구하는 목표이기도 하지만, 그보다는 현대화 과정의 성과 평가를 위한 템플릿으로 볼 수도 있다. 강화된 데이터 우위 (Strengthened Data Advantage), 능동적인 사이버 방어 개선(Better Active Cyber Defense), 오퍼레이션 자동화 확대(Greater Automation in Business Ops), 미션 달성을 위한 신속한 소프트웨어 개발 능력(Faster Software to Mission Capabilities), 이 네 가지 척도에서의 성과를 통해 전장에서의 전투 능력 및 국방 전반에 걸친 결과에 미칠 영향을 분석할 수 있다.

여기서 중요한 점은, 이러한 결과 분석이 일회성으로 끝나는 것이 아니라, 동일한 태스크 혹은 미션에 대해서, 기술 요소의 적용, 프로세스 전환 등 전 과장이 수시로 반복할 수 있다는 것이다. 이러한 실행이 정착됨으로써 소프트웨어에 기반한 더욱 기민한 국방체계를 만들어가는 것이 궁극적인 소프트웨어 현대화 전략의 목표일 것이다.

4. 최종 지향점은 무엇인가?

소프트웨어 현대화의 최종 지향점은 앞서 언급한 “비전”에 함축적으로 담겨있다. 이를 위한 여정에서 일종의 중간 기착지, 혹은 손에 잡을 수 있는 몇 가지 목표를 제시하고 있다.

  • 목표 1. DoD 엔터프라이즈 클라우드 환경: 소프트웨어 현대화의 가장 중요한 기반을 마련하는 것이다. JWCC 프로젝트도 이에 포함된다고 볼 수 있으며 클라우드 포트폴리오, 데이터 보안, 자동화, 그리고 OCONUS(Outside the Continental United States) 클라우드 구축이 포함된다.
  • 목표 2. 소프트웨어 팩토리 기반 생태계: 안전한 고품질의 소프트웨어를 신속하게 만들 수 있는 역량 확보를 위해 소프트웨어 팩토리 개념을 도입한 생태계를 구축하는 것이다. 데브섹옵스와도 밀접한 연관이 있으며, 학계, 민간 기업과도 연계하는 커뮤니티의 역량을 최대한 활용하여 새로운 환경 및 기술에 대한 대응을 빠르게 대규모로 실행할 수 있도록 하는 것이 목표다. 이는 다음 기회에 좀 더 상세히 살펴보려 한다.
  • 목표 3.  탄력성과 신속함을 위한 프로세스 전환: 우선 제반 정책 및 규정, 표준이 수정되거나 새로 마련되어야 한다. 특히, 조달 및 예산 운영 절차가 애자일 방식에 적합하도록 재개편되는 되는 것이 중요하다. 즉시 사용할 수 있는 상용 소프트웨어를 최대한 활용하여 기술 경쟁력을 확보해야 한다. 이에 이런 상용 제품과 새로 개발하는 소프트웨어와의 효율적인 상호운용을 위한 관리 방식을 도입해야 한다. DoD 내부 혹은 협력 파트너에게 최대한 기술 권한을 부여하여 이들을 통한 소프트웨어 기술 경쟁력을 강화하는 것도 필요하다. 물론 이렇게 기여하는 것에 대한 인센티브 제도도 정비되어야 한다.

맺으며: 전체를 관장하는 ‘거버넌스 체계’ 

DoD의 소프트웨어 현대화 전략은 트럼프 정부부터 시작된 클라우드 스마트 전략, 바이든 정부가 줄곧 진행하고 있는 IT 현대화 전략과 맥락을 같이하고 있다. 최근에도 바이든 정부에서는 업데이트된 IT 계획을 발표하기도 했다. 아마도 DoD 소프트웨어 현대화 전략의 세부 목표와 프레임워크도 일부 업데이트할 것이다. 중요한 것은, 이런 전략에 대한 명확한 비전을 제시하고, 이 비전을 향한 목표가 서로 잘 맞춰져 있는가이다. 상황에 따라 목표의 우선순위가 바뀔 수도 있고 그에 따라 전략의 수정이 불가피할 수 있다. 전체를 관장하는 거버넌스 체계만 잘 갖춰져 있다면 아무 문제 없다.

DoD 소프트웨어 현대화 전략에서도 뒷부분에 거버넌스 체계에 대한 언급이 있다. DoD CIO뿐만 아니라 관련 차관급 인사, 조정 위원회 등을 통해 DoD 소프트웨어 현대화를 관장한다. 이들의 전문성이 DoD 소프트웨어 현대화 성패를 좌우하게 될 것이다. 앞으로 이들의 활동을 주시하면서 이제 막 본격적으로 논의되기 시작한 우리나라 국방부의 클라우드 활용 포함 전반적인 소프트웨어 전략 수립이 올바른 방향으로 가는지 가늠해 볼 수 있을 것이다.

미 국방부가 추진하는 총 100억 달러 예산, 10년간 단일 벤더가 사업을 독점하는 ‘제다이'(JEDI: Joint Enterprise Defense Infrastructure, 합동 방어 인프라) 프로젝트는 인공지능과 무기, 클라우드와 군대의 만남이라고 할 수 있다. 2019년 10월 제다이 프로젝트는 마이크로소프트가 수주했다. 하지만… 결국 폐기됐다.

 

[divide style=”2″]

[box type=”note”]

본 글은 한국지능정보사회진흥원의 지원을 받아 작성되었으며, 디지털서비스 이용지원시스템에 동시 게재합니다.

[/box]

관련 글