Anduril를 통해 배우는 기술적 교훈 (3)

Anduril의 두번째 기술적 키워드는 “기술을 빠르게 적용하기”, 즉 agility입니다. 2001년 2월 유타주의 스키장에서  Kent Beck, Martin Fowler 등 17명의 유명 소프트웨어 개발자들이 모여서 문서중심의 무거운 개발 프로세스를 개선하고자 “애자일 소프트웨어 개발” 선언문을 발표하였습니다. 바로 이 정신을 계승하고자 하는 것이 아닌가 생각합니다. 

그러나 consumer 제품을 만드는 B2C와 달리 B2G와 같은 특정 목적의 사용자를 위한 시스템 개발에도 agile 방법론의 적용이 가능할까요? 특히 업체봐주기, 감사, 계약방법의 한계를 갖고 있는 경우 이를 적용하기란 그리 쉽지가 않습니다. 이러한 이유로 Anduril은 직접 제품을 기획하고 스스로 제품을 만드는 것을 택한 것 같습니다. B2C의 비지니스 모델을 택한 것일 것입니다.   

 

다양한 개발 수명주기 모델(Life-cycle Model)의 적용

 

agile 수명주기 모델을 적용하여 개발을 하는 것은 매우 중요한 방향입니다. 그러나 SCRUM과 같은 agile 기반의 모델을 무조건 적용하는 것이 모든 문제를 해결하는 것은 아니라고 생각합니다. 소트프웨어의 종류는 바라보는 관점에 따라 다양합니다. 소프트웨어라도 다 같은 소프트웨어가 아니라는 의미입니다. 예를 들어 적용분야에 따라, 크기에 따라, 처리하는 업무에 따라 그 성격이 상이합니다. 즉 하나의 동일한 방법으로 모든 소프트웨어를 개발한다는 것은 무리가 있습니다. 그렇다고 아래 그림의 소프트웨어 분류마다 다른 방법을 적용하는 것도 어렵습니다.

 

 

다양한 소프트웨어 분류를 통해 수명주기 모델을 결정하기 위해 영향을 주는 요인을 소프트웨어시스템의 요구사항과 관련이 있을 것입니다. 따라서 이러한 요구사항을 특징을 아래 그림과 같이 3차원으로 정리하였습니다.

 

 

첫번째, 규모는 소프트웨어의 요구사항의 크기를 의미하며 구현될 소프트웨어 코드의 양과 비례한다고 볼 수 있습니다. 소프트웨의 크기를 요구사항을 기반으로 예측하기 때문입니다. 두번째는 복잡도입니다. 복잡도는 요구사항을 결정하는 정도를 의미합니다. 요구사항의 결정이 쉬운 시스템이 있고 어려운 시스템이 있을 수 있습니다. 시스템과 관련한 액터의 수와 성격에 따라 요구사항의 복잡도가 결정됩니다. 세번째, 난이도는 요구사항을 구현하기 어려운 정도를 의미합니다. 특정한 전문지식이 요구되는 계산중심의 시스템과 단순히 입출력만 수행하는 시스템과는 난이도가 많이 차이가 납니다.

 

따라서 규모가 크다 하더라도 요구사항의 복잡도와 난이도가 낮은 경우라면(물론 규모가 크면 클 수록 요구사항의 복잡도가 높아집니다), 요구사항이 명확한 경우에는 전통적인 water-fall model을 개발을 해도 agile로 개발하는 것과 크게 다르지 않을 것입니다. 난이도가 높아도, 복잡도가 낮고  시스템의 규모가 매우 작은 경우는 agile로 개발하는 것이 매우 유리합니다. 

수명주기모델은 water-fall, agile만 존재하는 것이 아니라, spiral model, iterative model 그리고 이들을 조합하는 형태로도 가능합니다.  방산의 경우는 대부분이 요구사항을 결정하는 것이 어렵기 때문에 water-fall model을 가능한 지향해야 한다고 생각합니다. 따라서  그 중간 형태의 spiral model이나 iterative model 또는 이들을 적합하게 조합한 모델을 프로젝트의 유형에 따라 결정하는 것이 중요합니다. 

결론적으로 agile방법론이 중요한 것이 아니라 agile 정신인 “품질 좋은 소프트웨어를 빨리 만드는 것”이 중요하다는 것을 잊지는 말아야 할 것입니다. 개인적으로는 prototyping 기반의 iterative model을 채택해서 개발하는 것을 권장하고 있습니다.

 

시스템개발에 계속적인 DX를 구현

 

agility를 제고하는 중요한 요소의 하나가 System 개발을 위한 제반환경을 개선하기 위해 DX를 계속적으로 적용해야 합니다. 무엇을 만들것인가도 중요하지만 이제부터는 어떻게 만들것인가에도 우선순위를 높여야 합니다. 어떻게 요구사항을 빨리 결정할 수 있는가? 어떻게 해야 좀 더 빨리 만들수 있는가? 어떻게 해야 품질이 우수한 제품을 만들 수 있을 것인가? 다른 의미로 CMMi의 인증을 획득하는 것이 목표가 아니라 CMMi의 인증을 받을 수 있는 실력을 키우는 것이 목표가 되어야 합니다. 형식만 있고 내용이 없는 꼴이 되어서는 안됩니다.

소프트웨어시스템의 경우 agile을 통해 빨리 소프트웨어 코드를 개발하는 것이 가장 좋은 방법입니다. 그러나 상술한 것처럼 방산에서는 이것이 매우 어려운 숙제입니다. 따라서 하드웨어 중심의 Engineering system 개발시 수행하는 Modeling & Simulation 처럼 소프트웨어 시스템도 Modeling & Simulation에 의해 개발하는 Model-Based System Engineering(MBSE) 환경을 구축하고 적용할 수 있는 개발환경을 구축해야 합니다.

MBSE는 개발한 시스템의 요구사항을 신속히 가시화하고 이를 검증할 수 있도록 하여 전체적인 개발주기를 단축하므로써 기술부채를 최소화할 수 있습니다. 그리고 개발 프로세스에 AI 등과 같은 DX을 적용하여 자율성을 높일 수 있는 방향으로 개발환경을 계속적으로 개선(Continual Imporvement) 해야 합니다.

 

 

소트프웨어의 재사용성 제고 및 자산화

 

Lattice OS는 Anduril의 모든 제품에 공통적으로 적용하는 일종의 OS를 포함한 소프트웨어 플랫폼입니다. 소프트웨어의 layer architecture상 가장 최하위에 존재합니다. 따라서 모든 제품에 적용이 가능하여 재사용성을 극대화합니다. 재사용성은 이번 글의 최종 주제이기도 합니다. agile의 기본 정신은 “고객이 원하는 좋은 소프트웨어를 빨리 만드는 것”이라고 했습니다. 우리가 NSFW를 개발하는 것도 이러한 목적이 있는 것입니다.

미국방성은 Ada라는 프로그래밍언어를 표준으로 개발했습니다. 또 Software Engineering Institute를 설립하여 Software Product Line이라는 개념을 개발하고 미군에 공통적으로 무기체계 개발에 적용하고 있습니다. 미 해군은 Open Architecture를 구축하고 모든 소프트웨어를 자산화하여 관리하고 있습니다. 이 모든 노력이 바로 “재사용성을 높이기” 위해서 입니다. 소프트웨어의 “품질과 개발생산성을 높이는 방법”이 결국 재사용성을 높이는 것이라는 결론에 도달한 것입니다. 재사용성은 소프트웨어 자체, 소프트웨어 개발방법론 및 개발환경, 개발 조직 등 모든 영역에 적용하는 가장 중요한 원칙을 의미하는 용어입니다.

 

 

재사용성을 극대화하기 위해서는 모든 소프트웨어를(기술문서 및 소프트웨어 프로그램) 자산화해야 합니다. 개발자 개인이 마음대로 개발하고 묻어두는 것이 아니라 회사의 자산으로 관리해야 한다는 의미입니다. 개별조직에서 실무자가 임의로 관리하는 것이 아니라 회사의 공통자산이라는 개념을 가지고 관리해야 합니다.  소프트웨어 플랫폼 및 구조를 표준화하는 일, ALM(Application Life-cycle Managment)을 기반으로 digitalization하여 관리하고, 분석하는 일, 모든 사람이 이러한 소프트웨어의 형상을 공유하는 일 등, 공유와 협업의 기반한 소프트웨어 자산화를 통해 재사용성을 극대화해야 합니다.