모바일 SDK vs Hivemind SDK vs Anduril Lattice SDK

방산 소프트웨어 생태계는 어떻게 변하고 있는가?

최근 방위산업에서 가장 큰 변화 중 하나는 무기체계의 중심이 하드웨어에서 소프트웨어와 자율성으로 빠르게 이동하고 있다는 점입니다.

 

과거에는 새로운 성능을 확보하려면 새로운 항공기, 레이더, 임무컴퓨터와 같은 하드웨어를 개발하는 것이 중요했습니다.

하지만 이제는 다른 접근이 등장하고 있습니다.

 

기존 플랫폼은 그대로 유지하면서 새로운 소프트웨어를 빠르게 추가하고 교체하는 것

입니다.

 

이러한 변화를 이해하기 위해 가장 익숙한 사례가 바로 스마트폰입니다.

스마트폰은 하나의 하드웨어 위에서 수많은 앱이 실행됩니다.

새로운 앱이 출시되었다고 스마트폰 전체를 다시 만드는 것은 아닙니다.

 

방산 분야에서도 이와 비슷한 방향의 소프트웨어 생태계가 만들어지고 있습니다.

대표적인 사례가 Shield AI의 Hivemind와 Anduril의 Lattice입니다.

1. 세 가지 SDK를 한눈에 비교하면

가장 쉽게 이해하는 방법은 일반적인 모바일 SDK와 방산 AI SDK를 비교하는 것입니다.

핵심 목적	앱 개발	자율성 및 AI Pilot 개발	전장 데이터·C2·자율 시스템 통합
주요 대상	스마트폰 앱	무인 플랫폼과 자율 시스템	센서·플랫폼·로봇·C2 시스템
중심 기능	UI, API, 데이터 처리	Perception, Cognition, Action, Mission Autonomy	Entities, Tasks, Objects, Video
주요 실행 위치	스마트폰/클라우드	플랫폼의 Edge	분산된 전술 Edge 및 Lattice 환경
핵심 개념	App	AI Pilot	전장 데이터·임무 통합 플랫폼
통신 방식	REST, HTTP 등	플랫폼·자율성 인터페이스	gRPC / REST
대표 효과	앱 생태계	플랫폼 자율화	다수 시스템의 연결·통합
비유	스마트폰 앱 개발도구	AI 조종사	전장 OS + 데이터 플랫폼

여기서 중요한 점은 Hivemind와 Lattice가 같은 역할을 하는 SDK가 아니라는 것입니다.

 

Hivemind는 자율성 소프트웨어 개발 및 운용에 초점을 두고 있고, Lattice SDK는 전장에 존재하는 다양한 데이터와 시스템을 Lattice 환경에 연결하고 활용하는 데 초점을 둡니다.

2. Shield AI Hivemind는 "AI Pilot"에 가깝다

Shield AI는 Hivemind를 AI Pilot 및 자율성 소프트웨어 생태계로 설명하고 있습니다.

 

Hivemind는 무인 시스템이 사람이 직접 계속 조종하지 않아도 임무를 수행할 수 있도록 자율성 기능을 개발·시험·배치하는 데 사용됩니다.

 

Shield AI가 공개한 Hivemind 구조에는 크게 다음과 같은 요소가 포함됩니다.

Perception, 주변 환경과 센서 정보를 이해 → Recognition, 상황을 판단하고 의사결정 → Action, 실제 플랫폼의 행동을 결정

 

여기에 인간-기계 인터페이스와 개발·시험·분석 도구가 함께 구성됩니다.

 

따라서 Hivemind를 가장 쉽게 표현하면

"무인체계에 탑재되는 AI Pilot을 개발하고 운용하기 위한 소프트웨어 생태계"

라고 볼 수 있습니다.

 

Shield AI 역시 Hivemind를 플랫폼 독립적인 자율성 소프트웨어로 설명하고 있으며, 여러 종류의 플랫폼에 적용하고 있습니다.

3. Anduril Lattice는 "전장 OS"에 가깝다

Anduril의 Lattice는 조금 다른 방향으로 접근합니다.

 

Anduril은 Lattice를 소프트웨어 정의 무기체계를 지원하는 소프트웨어 플랫폼으로 설명하며, 제3자 및 정부 소유 시스템과의 통합을 강조하고 있습니다.

 

쉽게 표현하면,

센서

• 레이더
• 무인기
• 무인차량
• 무인정
• C2
• 임무 소프트웨어

를 하나의 분산된 데이터 환경에서 연결하는 것입니다.

 

그래서 Lattice를 기술적으로는

"전장 데이터를 연결하고, 임무를 전달하고, 자율 시스템을 통합하는 소프트웨어 플랫폼"

으로 이해하는 것이 더 정확합니다.

 

"전장 OS"라는 표현은 이러한 역할을 쉽게 설명하기 위한 비유입니다.

4. Lattice SDK의 핵심은 4개의 데이터 모델

Lattice SDK를 이해하기 위해서는 Anduril이 공식적으로 제공하는 네 가지 API 개념을 이해해야 합니다.

① Entities

전장에서 의미 있는 모든 객체를 표현합니다.

예를 들어

• 항공기
• 무인기
• 차량
• 선박
• 센서
• 표적
• 위치정보

등을 하나의 Entity로 표현할 수 있습니다.

Anduril의 공식 문서에서는 Entity를 운영자에게 의미가 있는 세계의 대상을 모델링하는 데이터 구조로 설명합니다.

② Tasks

Task는 시스템이나 플랫폼에 수행할 임무를 전달하기 위한 모델입니다.

예를 들어

"이 지역을 정찰하라."

"이 위치로 이동하라."

"이 표적을 조사하라."

와 같은 임무를 Task로 표현할 수 있습니다.

Lattice의 Tasks API는 Task를 생성하고, 라우팅하고, 상태를 관리하고, 실행하도록 지원합니다.

 

즉,

Entity = 무엇이 존재하는가

Task = 무엇을 해야 하는가

라고 이해하면 쉽습니다.

5. Objects와 Video

Lattice에는 Entity와 Task 외에도 Objects와 Video가 있습니다.

Objects

이미지, 파일 등과 같은 바이너리 데이터를 다루는 구조입니다.

예를 들어 무인기가 촬영한 이미지의 썸네일이나 선박 관련 문서 등을 Entity와 연결하여 활용할 수 있습니다.

Anduril은 Objects API를 Lattice Mesh에 분산된 데이터 저장·전달 구조로 설명하고 있습니다.

Video

센서나 카메라에서 발생하는 실시간 영상 및 센서 피드를 Lattice로 연결하는 기능입니다.

따라서 Lattice를 단순한 "통신 API"라고 보기보다는

Entity + Task + Object + Video

라는 공통 데이터 모델을 통해 전장의 다양한 시스템을 연결하는 플랫폼으로 이해하는 것이 좋습니다.

6. Lattice SDK의 gRPC와 REST

Lattice SDK의 또 하나의 특징은 gRPC와 REST를 모두 지원한다는 점입니다.

Anduril 공식 개발자 문서에 따르면 Lattice SDK는 gRPC와 REST를 모두 주요 프로토콜로 지원합니다.

쉽게 보면 다음과 같습니다.

REST

웹 애플리케이션이나 대시보드와 같은 시스템에 적합합니다.

HTTP/JSON 기반의 익숙한 개발환경을 제공합니다.

gRPC

고주기 텔레메트리나 하드웨어 통합처럼 효율적인 데이터 전달이 필요한 경우 활용할 수 있습니다.

Lattice는 내부적으로 Protobuf 기반의 gRPC 통신을 활용하며, 공식 문서는 Protobuf의 바이너리 인코딩이 JSON 대비 데이터 크기를 줄이는 장점을 설명하고 있습니다.

 

따라서 구조적으로 보면

Application → REST / gRPC →  Lattice SDK → Lattice →  Entities / Tasks / Objects / Video

와 같은 형태로 이해할 수 있습니다.

7. Lattice Mesh가 중요한 이유

전장에서는 일반적인 인터넷 환경처럼 항상 안정적인 네트워크를 사용할 수 있는 것이 아닙니다.

통신이 끊기거나 지연되거나 대역폭이 제한될 수 있습니다.

 

이러한 환경을 DDIL(Disrupted, Disconnected, Intermittent, Low-bandwidth) 환경이라고 부릅니다.

Anduril은 Lattice를 이러한 전술적 Edge 환경을 고려한 분산형 구조로 개발하고 있습니다.

 

Lattice SDK의 개발 원칙에서도 Local-first가 강조됩니다.

 

즉,

"네트워크가 항상 정상이라고 가정하지 말라."

는 접근입니다.

 

Lattice Mesh에서는 각 노드가 데이터를 공유하면서 분산된 환경에서 정보를 활용할 수 있습니다.

Anduril은 실제 사례에서 Lattice Mesh를 이용해 분산된 C2 노드와 센서, 시스템을 연결하고 DDIL 환경에서 데이터를 공유하는 구조를 시연해 왔습니다.

8. Hivemind와 Lattice의 차이를 가장 쉽게 이해하는 방법

두 기술을 자동차에 비유해 보겠습니다.

Hivemind

자동차를 스스로 운전하는 "AI 운전사" 에 가깝습니다.

주변을 인식하고 → 상황을 판단하고 →  경로를 계획하고 →  차량을 움직입니다.

Lattice

여러 차량과 교통센서, 지휘센터를 연결하는 "도로망 + 교통정보 시스템 + 관제 플랫폼"에 가깝습니다.

 

어떤 차량이 어디에 있는지 파악하고, 어떤 임무를 수행해야 하는지 전달하고, 센서 데이터를 공유하고,

여러 시스템을 하나의 공통 상황정보로 연결합니다.

 

따라서

Hivemind = 플랫폼 내부의 자율성

Lattice = 여러 플랫폼과 데이터를 연결하는 전장 소프트웨어 플랫폼

이라는 구분이 가장 이해하기 쉽습니다.

9. 그런데 2026년 CCA 시험에서 두 기술이 만났다

이 차이를 보여주는 매우 흥미로운 사례가 있습니다.

2026년 2월 24일, Anduril의 YFQ-44A CCA가 한 비행에서 Shield AI의 Hivemind와 Anduril의 Lattice for Mission Autonomy를 순차적으로 사용한 시험이 공개되었습니다.

 

Air & Space Forces 보도에 따르면 항공기는 먼저 Hivemind를 사용해 시험 항목을 수행한 뒤 착륙하지 않고 Anduril의 Lattice for Mission Autonomy로 전환해 동일한 시험 항목을 수행했습니다.

 

이 사례가 중요한 이유는 단순히

"AI가 무인기를 조종했다"

는 것이 아닙니다.

 

더 중요한 것은 서로 다른 업체의 mission autonomy 소프트웨어를 동일한 항공 플랫폼에서 운용할 수 있는 구조가 실제 시험으로 시연되었다는 점입니다.

 

이 과정에는 미 공군이 추진한 Autonomy Government Reference Architecture(A-GRA)의 역할이 중요했습니다. A-GRA는 비행 기능과 임무 자율성을 분리해 서로 다른 임무 소프트웨어가 항공 플랫폼의 비행 소프트웨어와 연결될 수 있도록 하는 방향을 제공합니다.

10. 이것이 바로 MOSA와 연결되는 지점이다

앞서 살펴본 MOSA의 핵심은 다음과 같습니다.

 

플랫폼 → 표준화된 인터페이스 → 모듈

입니다.

 

CCA 사례를 이러한 관점에서 보면 다음과 같이 이해할 수 있습니다.

YFQ-44A 플랫폼 →  A-GRA 기반 인터페이스 → Mission Autonomy → Hivemind 또는 Lattice for Mission Autonomy

 

이러한 구조가 가능해지면 항공기 플랫폼과 임무 자율성 소프트웨어를 어느 정도 분리할 수 있습니다.

 

즉,

기체를 새로 개발하지 않고도 자율성 소프트웨어를 발전시킬 수 있는 구조

를 목표로 할 수 있습니다.

 

이것이 MOSA와 A-GRA가 실제 무기체계 소프트웨어에 적용되는 대표적인 모습입니다.

11. 모바일 앱 생태계와 비교하면 더욱 쉽다

스마트폰을 생각해 보겠습니다.

스마트폰 하드웨어 → 운영체제 → SDK → 앱

사용자는 새로운 앱을 설치한다고 스마트폰을 다시 만들 필요가 없습니다.

방산 분야도 비슷한 방향으로 발전하고 있습니다.

미래 무기체계

항공기 / 무인기 플랫폼 → 개방형 인터페이스 → 자율성 SDK → Mission Autonomy → 새로운 AI 알고리즘

새로운 자율성 기술이 등장할 때마다 항공기 전체를 다시 개발하는 것이 아니라 소프트웨어를 교체하고 업그레이드하는 방향입니다.

12. 세 가지 SDK를 다시 비교하면

이제 세 가지를 하나의 그림으로 정리할 수 있습니다.

모바일 SDK

Hardware →  Operating System → Mobile SDK → App → User

목적은 앱 생태계입니다.

Hivemind SDK

Aircraft / Robot → Flight & Platform Systems → Hivemind → Perception → Cognition → Action → Autonomous Mission

목적은 플랫폼 자율성입니다.

Lattice SDK

Sensors, Aircraft, Vehicles, Robots, C2 → Lattice SDK → Entities, Tasks, Objects, Video → Lattice Mesh →

Common Operational Picture / C2 / Mission Applications

목적은 분산된 전장 시스템의 연결과 데이터·임무 통합입니다.

13. 결국 "AI Pilot"과 "전장 OS"의 차이

세 가지를 한 문장으로 정리하면 매우 쉽습니다.

모바일 SDK → 스마트폰에서 앱을 만드는 개발환경

Hivemind SDK → 무인 플랫폼의 AI Pilot을 만드는 개발환경

Lattice SDK → 여러 센서·플랫폼·임무체계를 연결하고 데이터를 활용하는 전장 소프트웨어 개발환경

 

따라서 Lattice를 단순히 "AI 조종사"라고 보는 것은 정확하지 않습니다.

Lattice에도 Mission Autonomy 기능이 있지만, Lattice SDK의 공개 문서가 보여주는 핵심 개발 모델은 Entities, Tasks, Objects, Video와 이를 연결하는 분산형 데이터·서비스 구조입니다.

14. 미래 MUM-T에서는 어떻게 연결될까?

앞서 살펴본 MUM-T와 연결하면 더욱 흥미로운 구조가 만들어집니다.

유인 전투기 → 조종사 → MUM-T Mission Management → Lattice / C2 → CCA, ISR UAV

→ 각 플랫폼의 Hivemind / Lattice / 기타 Autonomy → 센서 / 임무장비 / 비행제어

 

이 구조에서 Lattice는 여러 플랫폼과 데이터를 연결하고 임무를 분배하는 역할을 수행할 수 있고,

각 플랫폼에서는 Hivemind와 같은 자율성 소프트웨어가 실제 임무 수행을 담당할 수 있습니다.

 

결국

Lattice = 여러 시스템을 연결

Hivemind = 플랫폼이 자율적으로 행동

이라는 역할 분담이 가능합니다.

15. 방산 소프트웨어의 새로운 생태계

이러한 변화를 보면 미래의 방산 산업 구조도 달라질 수 있습니다.

과거에는

플랫폼 업체 가 하드웨어와 소프트웨어를 대부분 함께 개발했습니다.

 

하지만 개방형 구조에서는

플랫폼 업체, Mission Autonomy 업체, AI 업체, Sensor 업체, C2 업체, Data / Software 업체

가 하나의 생태계를 구성할 수 있습니다.

 

이것은 스마트폰 산업과 상당히 비슷합니다.

스마트폰 제조사가 모든 앱을 직접 개발하지 않는 것처럼, 미래의 무기체계 플랫폼 업체가 모든 자율성 소프트웨어와 임무 애플리케이션을 직접 개발할 필요가 줄어들 수 있습니다.

16. MOSA에서 중요한 것은 "교체 가능성"

이러한 구조에서 진정한 MOSA의 가치는 단순히 개방형 API가 있다는 데 있지 않습니다.

핵심은 실제로 교체가 가능한가입니다.

 

예를 들어, Autonomy A → A-GRA / 표준 인터페이스 → Platform 그리고 이후 Autonomy B

→  동일한 인터페이스 → Platform

으로 교체할 수 있다면 소프트웨어 생태계가 훨씬 유연해집니다.

 

2026년 YFQ-44A의 Hivemind → Lattice for Mission Autonomy 전환 시험은 바로 이 개념을 보여주는 대표적인 사례로 볼 수 있습니다.

17. 결론

방산 소프트웨어의 변화는 단순히 "AI를 무기체계에 넣는다"는 수준을 넘어가고 있습니다.

 

이제는

플랫폼, 자율성, C2, 센서, 데이터, AI

를 서로 분리하고 다시 연결할 수 있는 소프트웨어 생태계가 중요해지고 있습니다.

 

이를 스마트폰에 비유하면 다음과 같습니다.

스마트폰 → Hardware → OS → SDK → App

 

반면 미래의 무기체계는

무기 플랫폼 → Open Architecture → Autonomy SDK → Mission Software → AI Application

과 같은 방향으로 발전할 수 있습니다.

 

여기에서

Shield AI Hivemind

는 "AI Pilot과 자율성 개발 생태계",

Anduril Lattice

는 "분산된 전장 데이터·C2·임무 시스템을 연결하는 소프트웨어 플랫폼",

그리고 MOSA/A-GRA

는 이러한 소프트웨어와 플랫폼을 분리하고 상호운용성을 높이는 아키텍처적 기반

으로 이해할 수 있습니다.

 

결국 미래 방산의 경쟁력은 단순히 누가 더 좋은 기체를 만드는가에서

누가 더 빠르게 새로운 소프트웨어와 AI를 무기체계에 연결하고 교체할 수 있는가

로 이동하고 있습니다.

 

그리고 2026년 CCA 시험에서 Hivemind와 Lattice for Mission Autonomy가 한 비행에서 순차적으로 운용된 사례는 이러한 "소프트웨어가 플랫폼보다 빠르게 진화하는 무기체계"라는 변화가 실제 시험 단계에 들어섰음을 보여주는 사례입니다.