본문 바로가기

Defense

방산 소프트웨어 언어 지형도: C/C++는 유지되고, Rust가 주목받는 이유

방산 SW의 중심은 여전히 C와 C++, 그러나 새로운 변화가 시작됐다

방산·항공우주 시스템에서 소프트웨어의 비중이 커지면서 프로그래밍 언어의 선택도 단순한 개발 편의성의 문제가 아니게 되었습니다.

 

성능, 실시간성, 메모리 안전성, 보안성은 물론이고 개발 도구, 검증 방법, 인증 자료와 기존 시스템과의 연동까지 함께 고려해야 하기 때문입니다.

 

레이더, 항법, 비행제어, 무장제어, 전자전, 통신, C4I 등 시스템의 성격에 따라 사용하는 언어는 달라지지만, 오랫동안 방산 소프트웨어의 중심에는 C와 C++가 자리해 왔습니다.

 

최근에는 Rust와 같은 메모리 안전 언어가 주목받으면서 새로운 변화가 시작되고 있습니다.

 

그러나 이것을 단순히

"C/C++ → Rust"

라는 교체 구도로 보는 것은 현실과 거리가 있습니다.

 

실제 변화는 오히려 다음과 같은 모습에 가깝습니다.

 

기존 무기체계 C/C++ 유지 → 신규 개발에서 메모리 안전성 요구 증가 → Rust·Ada/SPARK 활용 확대

즉, 기존 자산을 한꺼번에 교체하기보다는 시스템의 특성과 인증 수준에 따라 여러 언어가 공존하는 방향입니다.

1. C: 하드웨어와 가장 가까운 방산 SW 언어

C는 임베디드 시스템과 방산 전자장비에서 오랫동안 핵심적인 역할을 해왔습니다.

프로세서, 메모리, I/O 장치 등을 직접 제어해야 하는 소프트웨어에서는 낮은 실행 오버헤드와 하드웨어 접근성이 중요한 장점입니다.

 

대표적인 활용 영역은 다음과 같습니다.

  • 항공전자장비 펌웨어
  • 센서 및 데이터 수집 장치
  • DSP 기반 신호처리
  • 통신 장비
  • 임베디드 제어 소프트웨어
  • FPGA 주변 프로세서 제어 SW

C가 계속 사용되는 또 하나의 이유는 오랜 기간 축적된 개발·검증 생태계입니다.

 

MISRA C와 같은 코딩 가이드라인, 정적 분석 도구, 테스트 도구, 컴파일러 및 디버거, 그리고 항공 소프트웨어 인증 경험이 광범위하게 축적되어 있습니다.

 

항공 분야에서는 DO-178C에 따라 소프트웨어 개발 프로세스와 검증 활동을 체계적으로 수행할 수 있는 기반도 오랫동안 마련되어 왔습니다.

하지만 C에는 구조적인 약점도 있습니다.

 

포인터, 버퍼, 메모리 관리 등을 개발자가 직접 다루기 때문에 버퍼 오버플로, Use-after-free, 잘못된 메모리 접근과 같은 오류가 발생할 가능성이 있습니다.

 

결국 C는 성능과 하드웨어 제어 측면에서는 매우 강력하지만, 메모리 안전성을 확보하기 위해 개발 규칙과 검증 활동에 상당한 노력이 필요한 언어라고 볼 수 있습니다.

2. C++: 대형 방산 시스템의 핵심 언어

C++는 C의 성능과 하드웨어 접근성을 유지하면서 객체지향 프로그래밍, 템플릿, 라이브러리 등을 활용할 수 있어 대규모 소프트웨어 개발에 적합합니다.

 

이 때문에 복잡한 방산 시스템에서 C++가 중요한 위치를 차지하고 있습니다.

 

대표적인 활용 분야는 다음과 같습니다.

  • 레이더
  • 전자전(EW)
  • 항법 시스템
  • 비행·임무 컴퓨터
  • 무기체계 제어
  • 전투체계
  • 시뮬레이션
  • 센서 융합
  • 미션 컴퓨팅

특히 방산 분야에서는 C++를 일반적인 범용 개발 방식처럼 자유롭게 사용하는 것이 아니라 프로젝트별 코딩 규칙과 허용된 언어 기능을 정해 사용하는 경우가 많습니다.

 

대표적인 사례로 잘 알려진 것이 JSF(Joint Strike Fighter) 프로그램의 C++ 코딩 표준입니다.

 

이러한 사례는 방산 분야에서 중요한 것이 단순히 "C++를 사용하는가"가 아니라,

"어떤 C++ 기능을 허용하고, 어떤 규칙으로 개발하며, 어떻게 검증하는가"

라는 점을 보여줍니다.

 

C++ 역시 언어 자체가 메모리 안전성을 보장하지는 않습니다.

따라서 코딩 규칙, 정적 분석, 코드 리뷰, 단위시험, 통합시험 등을 통해 위험을 관리합니다.

 

최근에는 MISRA C++:2023과 같은 현대적인 C++ 안전 코딩 가이드라인도 등장하면서 C++ 기반 안전·보안 소프트웨어 개발 방법론 역시 계속 발전하고 있습니다.

 

따라서 C++를 "안전하지 않기 때문에 사라질 언어"로 보는 것보다는, 높은 성능과 방대한 기존 개발자산을 유지하면서 안전성을 높이는 방향으로 발전하는 언어로 보는 것이 현실적입니다.

3. Java: 상위 정보체계에서는 유용하지만 하드 리얼타임 제어에는 제약

Java는 C/C++와는 다른 영역에서 의미가 있습니다.

 

JVM과 가비지 컬렉션을 사용하는 일반적인 Java 실행환경은 하드 리얼타임이 중요한 비행제어 또는 무기 제어의 핵심 제어 루프에 적합하지 않은 경우가 많습니다.

 

물론 실시간 Java 기술과 별도의 실시간 실행환경을 적용하려는 시도는 존재합니다.

 

그러나 방산 시스템 전체에서 보면 Java의 주요 활용 영역은 보다 상위의 정보체계에 가깝습니다.

  • C4I
  • 지휘통제 시스템
  • 지상통제소
  • GUI
  • 데이터 관리
  • 업무용 응용 프로그램
  • 서버 및 정보체계

따라서

"방산에서는 Java를 사용하지 않는다"

라고 표현하는 것은 정확하지 않습니다.

 

보다 정확하게는

"하드 리얼타임 결정성이 중요한 하위 제어 영역과 상위 정보체계는 요구조건이 다르기 때문에 사용하는 언어도 다르다"

라고 이해하는 것이 적절합니다.

4. Ada와 SPARK: 고신뢰·고무결성 소프트웨어의 전통적인 선택

Ada는 항공·방산 분야에서 오랫동안 사용되어 온 고신뢰성 소프트웨어 개발 언어입니다.

 

강력한 타입 체계와 안전성을 고려한 언어 구조를 갖고 있어 소프트웨어 오류가 시스템 안전과 직접 연결되는 분야에서 활용되어 왔습니다.

 

특히 주목할 부분이 SPARK입니다.

SPARK는 Ada의 안전한 부분집합을 기반으로 정형 검증을 적용할 수 있도록 만들어진 개발 방식으로, 특정 종류의 런타임 오류가 발생하지 않는다는 사실을 도구를 통해 검증하는 것을 목표로 합니다.

 

따라서 고무결성 소프트웨어에서는 여전히 중요한 선택지입니다.

 

다만 미국 국방부의 Ada 의무화 정책이 1990년대 후반 종료된 이후 방산 소프트웨어 전체가 Ada 중심으로 통일되는 흐름은 약해졌습니다.

그 결과 현재는 C, C++, Ada, SPARK 등이 시스템 요구조건에 따라 함께 사용되는 형태가 일반적입니다.

5. 모델 기반 개발: 실제 코드는 누가 작성하는가?

항공전자 소프트웨어를 이해할 때 놓치기 쉬운 부분이 하나 있습니다.

바로 "개발자가 직접 소스코드를 작성하지 않는 경우도 많다"는 것입니다.

 

비행제어와 같은 분야에서는 Simulink, SCADE 등의 모델 기반 개발 환경을 이용해 설계 모델을 작성하고, 코드 생성기를 통해 C 등의 소스코드를 생성하는 방식이 사용됩니다.

 

개념적으로 보면 다음과 같습니다.

요구사항 → 모델 → 자동 코드 생성 → 생성 코드 검증 → 통합 및 시스템 시험

 

이 과정에서는 단순히 "C를 사용한다"는 사실만으로 개발 방식을 설명하기 어렵습니다.

 

어떤 모델링 도구를 사용했는지, 어떤 코드 생성기를 사용했는지, 해당 도구의 개발·검증 프로세스가 어떻게 관리되는지 등이 중요합니다.

 

특히 항공 인증에서는 개발 도구와 검증 도구에 대한 도구 자격 및 신뢰성 문제가 중요한 고려사항이 됩니다.

 

따라서 새로운 프로그래밍 언어가 등장하더라도 단순히 컴파일러만 추가한다고 기존 항공 SW 개발환경에 바로 적용할 수 있는 것은 아닙니다.

 

이것이 Rust의 항공 분야 확산이 상대적으로 신중하게 진행되는 중요한 이유 중 하나입니다.

6. Rust: 왜 방산 SW에서 주목받는가?

Rust가 주목받는 가장 큰 이유는 메모리 안전성과 시스템 소프트웨어 수준의 성능을 함께 추구할 수 있다는 점입니다.

 

Rust는 가비지 컬렉터에 의존하지 않으면서 소유권(Ownership), 빌림(Borrowing), 라이프타임(Lifetime) 등의 개념을 통해 컴파일 단계에서 다양한 메모리 오류와 데이터 경쟁 문제를 방지하도록 설계되었습니다.

 

또한 no_std 환경을 지원하기 때문에 운영체제나 표준 라이브러리에 의존하지 않는 임베디드 소프트웨어 개발에도 활용할 수 있습니다.

 

이러한 특성 때문에 다음과 같은 분야에서 관심이 커지고 있습니다.

  • 보안 소프트웨어
  • 네트워크 프로토콜
  • 통신 소프트웨어
  • 임베디드 시스템
  • 무인체계
  • 시스템 소프트웨어
  • 신규 방산 소프트웨어 모듈

특히 중요한 것은 신규 개발뿐 아니라 기존 C/C++ 코드의 전환입니다.

 

기존 레거시 코드를 모두 사람이 다시 작성하는 것은 비용과 위험이 매우 큽니다.

 

이 때문에 기존 C 코드의 일부를 Rust로 전환하거나 자동 변환하는 연구도 진행되고 있습니다.

DARPA의 TRACTOR 프로그램은 이러한 문제를 다루는 대표적인 연구 사례로 볼 수 있습니다.

7. 미국 정부가 메모리 안전성을 강조하는 이유

Rust가 주목받는 배경에는 미국 정부와 사이버보안 기관들의 메모리 안전성에 대한 관심 증가도 있습니다.

NSA는 메모리 안전 소프트웨어 개발을 강조하는 자료를 발표했고, CISA와 FBI 등도 소프트웨어 제조사가 메모리 안전성 확보를 위한 로드맵을 마련할 것을 권고해 왔습니다.

 

또한 백악관 Office of the National Cyber Director(ONCD) 역시 메모리 안전 언어로의 전환을 사이버보안 강화 방안 가운데 하나로 제시했습니다.

 

여기서 중요한 점은 이러한 정책 방향을

"C와 C++를 당장 폐기하라"

는 의미로 해석해서는 안 된다는 것입니다.

 

실제 방산 시스템에는 이미 수십 년 동안 개발된 C/C++ 코드와 함께 시험자료, 검증자료, 인증자료, 개발도구, 전문인력 등이 축적되어 있습니다.

 

따라서 현실적인 방향은 기존 시스템을 모두 재작성하는 것보다 신규 개발 또는 중요 기능의 신규 모듈부터 메모리 안전 언어를 적용하는 것입니다.

8. 그런데 왜 Rust는 아직 방산·항공 SW의 주류가 아닌가?

Rust의 기술적인 장점과 실제 방산·항공 시스템에 적용하는 것은 별개의 문제입니다.

가장 큰 차이는 "언어의 성능"이 아니라 "인증 가능한 개발 생태계"입니다.

① 툴체인과 인증

항공 소프트웨어에서는 컴파일러와 개발·검증 도구가 인증 프로세스에서 중요한 역할을 합니다.

DO-178C 환경에서는 개발도구의 사용 목적과 영향도에 따라 도구 자격 평가가 필요할 수 있습니다.

 

Rust 역시 안전 관련 산업을 대상으로 하는 인증용 툴체인이 등장하고 있지만, 항공 분야에서는 C/C++와 Ada에 비해 적용 사례와 경험이 상대적으로 적습니다.

 

따라서 "Rust는 인증이 불가능하다"가 아니라 "항공 인증 생태계가 아직 기존 언어만큼 성숙하지 않았다"고 표현하는 것이 정확합니다.

② 언어와 컴파일러 생태계

C와 C++는 오랜 기간 국제 표준과 다양한 컴파일러, 정적 분석 도구, 개발환경이 구축되어 왔습니다.

 

Rust도 언어 사양과 관련 생태계를 발전시키고 있지만, 방산·항공 인증 관점에서는 단순한 언어 기능보다 컴파일러와 전체 툴체인의 신뢰성을 입증하는 것이 중요합니다.

③ unsafe와 C/C++ 연동

Rust의 안전성은 모든 코드가 무조건 안전하다는 의미는 아닙니다.

unsafe 코드와 C/C++ 라이브러리를 연결하는 FFI 영역에서는 별도의 검증이 필요합니다.

 

특히 방산 시스템에서는 기존 C/C++ 드라이버, RTOS, 하드웨어 라이브러리 등을 그대로 활용해야 하는 경우가 많기 때문에 Rust와 기존 코드 사이의 경계가 중요한 검증 대상이 됩니다.

④ 개발 표준과 정적 분석

C/C++에는 오랜 기간 축적된 안전 코딩 가이드라인과 정적 분석 도구가 존재합니다.

 

Rust 역시 관련 도구와 개발 방법론이 빠르게 발전하고 있지만, 방산·항공 인증 현장에서 축적된 경험과 자산에서는 아직 차이가 있습니다.

⑤ RTOS와 개발인력

방산 임베디드 시스템은 특정 RTOS와 하드웨어 플랫폼에 강하게 의존하는 경우가 많습니다.

 

기존 환경에서 C/C++ 개발자와 도구가 이미 구축되어 있다면 Rust를 도입하려면 개발환경, RTOS 지원, 라이브러리, 교육과 인력 확보까지 함께 고려해야 합니다.

 

결국 Rust의 가장 큰 장벽은 언어 자체의 성능이 아니라 "기존 방산 개발 생태계와 어떻게 연결할 것인가"에 있습니다.

9. 방산 SW 언어별 역할

C 임베디드·펌웨어·하드웨어 제어 성능, 하드웨어 접근성, 축적된 생태계 메모리 안전성 관리 필요
C++ 레이더·전투체계·미션 SW 대규모 시스템, 기존 개발자산 언어 기능 제한·정적 분석 등 필요
Java C4I·서버·상위 응용 개발 편의성, 풍부한 생태계 일반적인 환경에서는 하드 리얼타임 제약
Ada 고신뢰 항공·방산 SW 강한 타입 체계, 안전성 상대적으로 작은 개발 생태계
SPARK 고무결성 SW 정형 검증 지원 높은 개발·검증 난이도
Rust 신규 시스템·보안·임베디드 메모리 안전성, 네이티브 성능 인증·툴체인·인력 생태계 확대 필요

이 표에서 중요한 것은 "어떤 언어가 가장 좋은가"가 아닙니다.

어떤 시스템 요구조건을 만족시키기 위해 어떤 언어를 선택하는가가 핵심입니다.

10. 앞으로의 방산 SW는 멀티언어 구조가 될 가능성이 높다

방산 시스템을 하나의 프로그래밍 언어로 통일하는 것은 현실적으로 쉽지 않습니다.

 

오히려 다음과 같은 계층별 구조가 현실적인 방향입니다.

 

하드웨어 제어·기존 임베디드 SW → C/C++

대규모 미션·전투체계 → C++

고신뢰·고무결성 SW → Ada/SPARK

모델 기반 개발 → 모델 → 코드 생성기 → C 등

신규 보안·통신·시스템 SW → Rust 점진 확대

상위 정보체계·서버 → Java·C#·Go 등

 

따라서 앞으로의 방산 소프트웨어는 하나의 언어가 다른 언어를 완전히 대체하는 형태보다는 여러 언어가 각자의 장점을 살려 공존하는 형태가 될 가능성이 높습니다.

11. 결국 핵심은 "언어"보다 "개발 생태계"다

방산 SW에서 프로그래밍 언어를 선택할 때 단순히

"Rust가 C++보다 안전한가?"

라는 질문만으로는 충분하지 않습니다.

 

실제 사업에서는 다음과 같은 질문이 더 중요합니다.

  • 해당 언어를 지원하는 RTOS가 있는가?
  • 필요한 컴파일러와 디버거가 있는가?
  • 정적 분석 도구가 있는가?
  • 요구사항부터 코드까지 추적 가능한가?
  • 시험·검증 자동화가 가능한가?
  • 기존 C/C++ 라이브러리와 연동할 수 있는가?
  • 필요한 항공·방산 인증을 지원할 수 있는가?
  • 해당 언어를 다룰 수 있는 개발인력이 충분한가?
  • 장기간 유지보수가 가능한가?

결국 방산 SW에서 언어의 경쟁은 단순한 문법이나 실행속도의 경쟁이 아닙니다.

 

"얼마나 안전하게 개발할 수 있는가"

그리고

"그 안전성을 어떻게 검증하고 인증할 수 있는가"

의 경쟁입니다.

마무리

현재 방산 소프트웨어의 모습을 한 문장으로 정리하면 다음과 같습니다.

 

C/C++ 중심의 기존 방산 SW 생태계는 계속 유지되지만, 메모리 안전성에 대한 요구가 커지면서 Rust와 같은 메모리 안전 언어가 신규 개발 영역을 중심으로 점진적으로 확대되고 있다.

 

C는 여전히 하드웨어와 가까운 임베디드 영역에서 강력한 위치를 유지하고 있습니다.

C++는 대규모 미션·전투체계와 기존 방산 소프트웨어에서 중요한 역할을 계속할 가능성이 높습니다.

Ada와 SPARK는 고신뢰·고무결성 소프트웨어라는 특수한 영역에서 여전히 의미가 있습니다.

Java 등 범용 언어는 C4I와 서버, 상위 정보체계에서 역할을 담당합니다.

 

그리고 Rust는 메모리 안전성을 요구하는 신규 시스템 소프트웨어의 중요한 후보로 부상하고 있습니다.

 

따라서 앞으로의 질문은

"Rust가 언제 C/C++를 대체하는가?"

보다는

"어떤 방산 SW 영역부터 Rust를 적용할 수 있으며, 이를 뒷받침할 인증 가능한 툴체인과 개발 생태계를 얼마나 빨리 구축할 수 있는가?"

에 더 가까울 것입니다.

 

방산 SW의 미래는 C/C++의 갑작스러운 퇴출보다는

C/C++ 레거시 + Ada/SPARK 고신뢰 영역 + Rust 신규 개발 + Java 등 상위 정보체계

가 공존하는 멀티언어 구조로 발전할 가능성이 높습니다.

 

결국 방산 소프트웨어의 경쟁력은 "어떤 언어를 선택했는가"보다 그 언어를 이용해 얼마나 안전하고 검증 가능하며 장기간 유지할 수 있는 시스템을 만들어낼 수 있는가에 달려 있습니다.