Notice
Recent Posts
Recent Comments
Link
Douglas' Space
Anduril를 통해 배우는 기술적 교훈 (2) 본문
Anduril의 기술적 접근중 중요한 키워드 중 하나는 Software Defined Warfare라고 했습니다. 조금 더 좁혀서는 Software Defined Weapon이라고도 할 수 있습니다. Software Defined Weapon은 어떠한 의미로 해석해야 할까요? Anduril은 기존의 방산업체들이 software engineering과 computing의 발전보다 조선 및 항공기 설계에 의존적이었다고 이야기하면서, 하드웨어중심이 아닌 소프트웨어 중심으로 발전해야 한다고 말합니다. 특별히 Lattice OS라는 것을 크게 부각시키고 있습니다.
Hardware와 Software의 분리
시스템 설계의 핵심은 시스템구성요소(System elelements)를 식별하고 각 구성요소에 시스템 요구사항을 할당하는 것입니다. 일반적으로 시스템은 크게 하드웨어, 소프트웨어, 사람 등으로 구성된다고 할 수 있습니다. software defined weapon은 하드웨어가 수행하던 기능 요구사항을 소프트웨어로 수행하도록 설계하는 것입니다. 최신 DoD WBS 표준(MIL-STD-881E, 부록B)에도 이러한 software의 분리의 개념이 반영되어 있습니다. software-defined network, software-defined radio 등이 그 예입니다.
모든 기능을 소프트웨어가 수행하고, 하드웨어는 단지 소프트웨어를 실행하는 일만 하는 시스템을 software system이라고 합니다. software system은 하드웨어에 종속적으로 소프트웨어를 설계하는 것이 아니라 하드웨어와 독립적으로 설계하고 소프트웨어가 하드웨어에 배치될 수 있도록 설계되어야 합니다.
그러나 현재 방산에서는 하드웨어에 종속된 소프트웨어를 설계하므로써 소프트웨어 컴포넌트의 중복성이 존재하게 되고, 이를 통해 자원의 낭비와 유지보수의 어려움이 존재하게 됩니다. 다시 말해 시스템의 컴포넌트의 기능이 하드웨어가 아니라 소프트웨어에 의해 결정된다고 할 수 있습니다.
Linux Docker 기반의 Open Architecture
Lattice OS는 CoreOS Linux기반으로 Anduril에서 자율성과 유지보수용이성을 제고하기 위해 개발한 Open Source Platform인 것으로 이해됩니다. Linux라는 OS로 촉발된 Open Source 운동은 전세계를 하나의 컴퓨팅 플랫폼으로 거의 통일화 시켰습니다. 거의 모든 클라우드 서비스는 Linux로 돌아갑니다. Starlink의 거의 90%이상이 Linux 컴퓨터로 운영됩니다.
open architecture는 open source와는 다른 개념입니다. open architecture는 인터페이스가 개방된, 다시말해 표준화된 소프트웨어 컴포넌트들을 기반으로한 소프트웨어의 구조를 의미합니다. 보통 open source 프로젝트의 소프트웨어들이 거의 표준적으로 사용되기는 하지만 반드시 그렇지는 않습니다.
앞으로 설계하는 우리의 시스템들도 가능한 Linux-Docker 기반의 open architecture를 지향해야 합니다 (Docker는 Linux상에 동작하는 응용프로그램의 이식성, 재사용성, 유지보수용이성을 극대화하기 위해 개발된 Linux에서 동작하는 일종의 가상화 엔진임). 이러한 연구개발 전략은 특정 프로젝트 만이 아니라 전사 차원의 전략으로 추진해야 합니다. MUM-T 참조 아키텍처의 가장 첫번째 design decision이 바로 이 Linux-Docker의 사용입니다.
Software에 의한 무기체계 성능개량 (유지보수)
사실 상술한 2가지 설계 전략이 바로 체계의 유지보수를 용이하게 하기 위해 적용하는 기술이라고 생각됩니다. 통계적으로 무기체계를 유지하는 총소유비용중 유지보수 비용이 상대적으로 높기 때문에 체계 개발은 항상 유지보수 용이성을 고려하여 개발을 해야 합니다. 총소유비용 뿐만 아니라 더 중요한 것은 기술부채(Technical Debt)를 줄여 최고의 무기체계를 유지할 수 있어야 합니다.
유지보수는 4가지의 형태가 존재합니다. 결함을 수정하기 위한 유지보수(corrective maintenace), 기능 개선을 위한 유지보수(enhansive maintenance), 환경 변화에 적응을 위한 유지보수(adaptive maintenance), 그리고 마지막으로 체계의 선제적 개선을 위한 유지보수(preventive maintenance)가 있습니다. corrective maintenence는 사람의 에러에 의해 발생되는 유지보수이기 때문에 특별히 어쩔 수 없지만 나머지 세개 유형의 유지보수를 고려하며 설계해야 합니다.
무기체계가 software defined weapon으로 변화한다면 DevOps, OTA와 같은 개념으로 무기체계의 성능 개선이 수시로 가능한 환경이 구축될 수 있습니다. 우-러 전쟁에서 보았듯이 starlink의 사비어공격에도 소프트웨어 업데이트를 통해 생존성을 높일 수 있었던 것이 그 중요한 예가 될 것입니다. 벤츠 회장이 “자동차는 이제 기름으로 달리는 것이 아니라 소프트웨어로 달린다”라는 말을 한 것이 벌써 10년이 흘러갑니다. 무기체계 연구개발 문화 및 환경에 대한 강력한 변혁이 필요한 시기입니다. 앞으로의 10년이 골든타임이 아닐까 생각됩니다.

'Thinking Diary > Enterprise' 카테고리의 다른 글
Palantir로 부터 배우는 기술적 교훈(2) (0) | 2023.02.26 |
---|---|
Palantir를 통해 배우는 기술적 교훈(1) (0) | 2023.02.19 |
Anduril를 통해 배우는 기술적 교훈 (4) (0) | 2022.07.12 |
Anduril를 통해 배우는 기술적 교훈 (3) (0) | 2022.07.10 |
Anduril를 통해 배우는 기술적 교훈 (1) (0) | 2022.07.07 |
Comments