# F-35에 사용된 C++ 표준 - 전투기는 왜 C++ 기능의 90%를 금지하는가 > Clean Markdown view of GeekNews topic #24920. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24920](https://news.hada.io/topic?id=24920) - GeekNews Markdown: [https://news.hada.io/topic/24920.md](https://news.hada.io/topic/24920.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-09T00:35:09+09:00 - Updated: 2025-12-09T00:35:09+09:00 - Original source: [youtube.com](https://www.youtube.com/watch?v=Gv4sDL9Ljww) - Points: 30 - Comments: 8 ## Summary 전투기와 로켓의 비행 제어 소프트웨어는 **예측 불가능한 동작을 원천 차단하기 위해 C++ 기능의 90%를 금지**한다고 합니다. F-35 개발 과정에서 만들어진 JSF C++ 표준은 예외, 재귀, 동적 메모리 할당을 없애고 반환 코드와 반복 루프만 허용해, 코드가 언제나 같은 시간 안에 같은 결과를 내도록 설계되었는데요. 이 접근은 이후 **NASA F‑Prime·MISRA·AutoSAR** 같은 안전성 표준의 기반이 되었으며, 오늘날에도 “무엇을 추가할지보다 무엇을 제거할지”가 안전한 시스템 설계의 출발점임을 보여줍니다. ## Topic Body - 마하 1의 속도에서 **한 줄 버그가 치명적 결과**로 이어지는 **전투기·로켓 소프트웨어**가 왜 C++ 기능의 대부분을 제거해 예측 가능한 코드만 남기는지 설명하는 영상 - F-4의 기계식 폭격 컴퓨터, 비공개 F-14 마이크로프로세서, **Jovial·CMS-2·Ada**로 이어지는 군용 언어 전쟁과 코드 폭증이 단일 안전 언어와 엄격한 표준을 요구하게 된 역사를 정리 - F-35 개발 과정에서 Lockheed가 Ada 대신 C++ 사용을 설득하며 만든 **JSF C++ 표준**이 예외, 재귀, 동적 메모리 할당을 금지하고, 반환 코드·반복 루프·사전 메모리 예약 등으로 대체하는 방식등을 실제 코드로 시연 - 초기 F-35 미션 컴퓨터가 **PowerPC 계열 아키텍처**를 사용했다는 점과 함께, X-Plane 12와 자체 제작 MFD를 연결해 JSF 규칙을 어기는 코드와 준수 코드가 실제로 비행 중 어떻게 다른지 비교함 - JSF 표준이 이후 **NASA F-Prime·MISRA·AutoSAR** 같은 안전성 표준으로 이어졌고, 지금은 그 유산 위에서 **C++ Core Guidelines와 현대 C++** 를 사용하는 방향이 더 적합하다는 결론을 제시 --- ### 발표자 소개 - 항공우주 시스템용 C++ 코드를 작성하며 **공군 대상 시연**을 하던 경험이 있는 개발자 - 실제로 안전성 요구가 높은 시스템에서 C++를 사용한 경험을 바탕으로 설명 진행 - X-Plane 12와 웹 API, Python UI, C++ 백엔드로 구성된 **직접 제작 MFD(다기능 디스플레이)** 를 데모 환경으로 사용함 ### 비행 소프트웨어와 실패가 허용되지 않는 환경 - 일반 애플리케이션에서 크래시는 재시작으로 끝나지만, **마하 1 전투기·로켓**에서는 한 번의 실패가 곧 재난이 되는 환경임 - **“마하 1에서는 가비지 컬렉터를 기다릴 시간이 없다”** 는 문장으로 실시간성 요구를 강조 - 한 줄의 잘못된 코드가 치명적 결과로 이어지는 상황에서 언어 기능 선택 자체가 안전 장치가 되어야 함 - 1996년 **Ariane 5 폭발 사고**를 대표 사례로 제시 - 수평 바이어스 64비트 부동소수점 값을 16비트 정수로 변환하는 과정에서 예외가 발생했고, 이 예외가 처리되지 못함 - 언어는 규격대로 오류를 발생시켰지만, 시스템이 이 예외를 처리하지 못해 **5억 달러에 달하는 로켓이 즉시 파괴**되는 결과로 이어짐 - 이 사례를 기준점으로 F-35 설계팀은 같은 실수를 반복하지 않기 위해 **언어 기능 자체를 잘라내는 접근**을 택함 ### 군용 소프트웨어의 역사와 언어 전쟁 - 초기 전투기인 **F-4 Phantom** 시절에는 사실상 소프트웨어가 없었음 - 폭격 컴퓨터는 기어와 캠으로 구성된 정밀 기계장치에 가까웠고, “코드”는 금속 캠의 형태 자체였음 - 기밀 프로젝트였던 해군 공중우세기 **VFX(F-14 Tomcat)** 에서 상황이 바뀜 - 교과서에서 “최초의 마이크로프로세서”로 알려진 Intel 4004보다 앞서, Garrett AiResearch가 F-14용 마이크로프로세서를 설계했다는 사실이 뒤늦게 공개됨 - F-14의 가변익(swing wing)을 최적 제어하기 위해 고성능 마이크로프로세서가 필요했고, 여기에 **약 2500줄 수준의 마이크로코드**가 태워져 다항식 계산을 수행함 - 이후 각 군이 서로 다른 언어를 채택하며 **언어 난립**이 시작됨 - 공군은 ALGOL 계열인 **Jovial(Jules Own Version of the International Algorithmic Language)** 를 사용함 - 해군은 공군 언어를 쓰지 않겠다며 F-18에 **CMS-2**를 채택함 - 서로 다른 언어·하드웨어 아키텍처를 쓰면서 코드 재사용과 검증이 거의 불가능한 상태가 됨 - 동시에 항공기당 소프트웨어 규모가 **지수적으로 증가**함 - F-16A 약 12.5만 라인, B-1 약 100만 라인, 현대 F-35는 약 900만 라인 수준으로 증가했다고 수치 예시를 제시함 - 국방부 조사에서 **450개가 넘는 프로그래밍 언어**가 사용 중이고, 제대로 된 표준을 가진 언어는 거의 없었다는 보고가 나옴 ### Ada 강제와 그 한계 - 이런 난립을 해결하기 위해 국방부는 단일 고급 언어 **Ada**를 만들고 강력한 사용 의무를 부과함 - 새 프로젝트에서 Ada를 쓰지 않으려면 **“왜 Ada로는 불가능한지”를 입증**해야 했고, 그렇지 않으면 **계약을 따낼 수 없는 구조**였음 - Ada는 안전·신뢰성이 중요한 분야에는 매우 적합한 언어로 소개됨 - 항공우주 같은 안전 중요 시스템에서 메모리·타입 안정성을 보장하기 위한 설계가 강조됨 - 하지만 90년대에 들어 **현실과 괴리**가 드러나기 시작함 - 한편에서는 인터넷, Windows 95, C++ 기반 상용 게임들이 주류를 형성함 - 학생·개발자들은 비싼 Ada 컴파일러 대신, **무료 GCC와 C++** 에 자연스럽게 몰림 - Ada 컴파일러는 수천 달러에 달해 개인이 접하기 어려웠고, 결과적으로 Ada 전문 인력 풀도 줄어드는 흐름을 보임 ### F-35와 JSF C++ 표준의 탄생 - **F-35(공동타격전투기, Joint Strike Fighter)** 는 처음부터 소프트웨어 비중이 매우 큰 기체로 설계됨 - 센서 융합(sensor fusion) 같은 복잡한 계산이 기체 운용 핵심으로 자리 잡음 - Lockheed Martin은 이런 요구를 위해 **C++ 사용 허용**을 국방부에 제안함 - 기존 Ada 강제 정책을 사실상 “깨달라”는 요청이었고, 이를 설득하려면 C++의 위험을 통제할 방법이 필요했음 - 이 과정에서 C++ 창시자 **Bjarne Stroustrup**도 조언자로 참여해 JSF C++ 규칙 설계에 관여했다고 언급함 - 직접적으로 JSF 규칙 작성에 손을 보탰다고 밝혔고, 그만큼 이 표준에 대해 “편향이 있을 수 있다”고 스스로 언급함 - 핵심 아이디어는 **“remove before flight”** 태그와 같은 발상임 - 비행 전 제거해야 하는 태그처럼, C++에서 위험한 기능들을 언어 차원에서 제거해 **예측 가능한 서브셋**만 사용하는 방식임 - 이로써 Ada 수준의 안전성을 확보하면서도, 개발자는 C++의 표현력을 일정 부분 활용할 수 있게 됨 ### 실제 하드웨어와 GameCube 비유 - 초기 F-35 블록은 **Motorola G4 PowerPC 프로세서 기반 미션 컴퓨터**를 사용했음 - 이 정보는 2003년 Aviation Today 기사 등에서 공개된 내용 - GameCube 역시 PowerPC 계열 프로세서를 사용하기 때문에, **명령어 집합 수준에서 유사한 세대의 하드웨어**라는 점에서 재미있음 - 보다 정확한 세대 일치를 위해서는 다른 콘솔이 더 가깝지만, 원리를 이해하는 데에는 GameCube 비유로 충분 ### JSF C++ 데모 환경: X-Plane 12 + MFD - X-Plane 12를 기반으로 F-35B 애드온(AOA Simulations)을 사용해 **비행 시뮬레이터 환경**을 구성함 - X-Plane의 새로운 웹 API로 실시간 비행 데이터를 구독하고, 이를 MFD에 표시하는 구조 - 프런트엔드는 Python으로 구성되고, **백엔드는 C++ 플러그인**으로 작성되어 JSF 규칙을 따르거나 위반하는 코드들을 비교 시연 - 고도, 속도, 바람, 비행 엔벨로프, 네비게이션 데이터 등 각종 정보를 C++ 계산 결과로 표시함 - 비행 중 의도적으로 **예외를 던지는 비표준 C++ 코드**를 실행해 MFD가 죽고, 비행에 문제가 생기는 상황을 보여준 뒤, JSF 규칙을 적용해 이를 해결하는 과정을 단계적으로 보여줌 ### JSF의 세 핵심 제약: 예외, 재귀, 동적 메모리 - JSF C++ 표준에서 강조하는 세 가지 핵심 제약은 **예외(Exception), 재귀(Recursion), 동적 메모리 할당**임 - 여기에 더해 함수의 **Cyclomatic Complexity(분기 복잡도)** 상한도 명시됨 #### 1) 예외 금지 – AV Rule 208 - JSF AV Rule 208: **“예외는 사용하지 않는다(exceptions shall not be used)”** - try, catch, throw 등 예외 관련 키워드를 전면 금지함 - 핵심 이유는 **제어 흐름의 비결정성** 때문임 - Ariane 5처럼 예외가 발생했을 때, 핸들링이 누락되거나 타이밍이 어긋나면 시스템 전체가 예측 불가능하게 무너질 수 있음 - Bjarne는 현대 C++ 예외 처리에 우호적이지만, JSF가 설계될 당시에는 **도구 성숙도와 실시간성 보장 문제** 때문에 예외를 지원할 수 없는 상황이었다고 설명함 > “JSF++는 하드 실시간·안전 중요 애플리케이션(비행 제어)용이기 때문에, 계산이 너무 오래 걸리면 사람이 죽을 수 있고, 예외로는 응답 시간을 보장할 수 없다” - JSF에서는 예외 대신 **반환 코드(return code)** 를 활용함 - 밀도고도(density altitude) 계산 예시에서, 오류 상황마다 서로 다른 반환 코드를 설정하고 호출자가 이를 해석해 처리하게 구성함 - 계산 실패나 시간 초과가 발생해도, 프로그램 전체가 죽지 않고 호출 측에서 “에러 상태”를 안전하게 표현할 수 있음 #### 2) 재귀 금지 – AV Rule 119 - AV Rule 119는 함수가 **직접·간접으로 자기 자신을 호출하는 것**, 즉 재귀를 금지함 - 재귀 호출마다 새로운 스택 프레임이 쌓이고, 최대 깊이 상한을 알기 어려워 **스택 오버플로** 위험이 커지기 때문 - 비행 계획 중 대체 공항 계산에 쓰는 **이항계수(binomial coefficient)** 를 예시로 듬 - 비표준 버전에서는 `C(n, k) = C(n-1, k-1) + C(n-1, k)` 형태의 재귀 구현을 사용함 - 이는 호출 깊이가 입력에 따라 달라져, 메모리 상한을 예측하기 어렵다는 문제가 있음 - JSF 준수 버전에서는 같은 계산을 **반복문 기반의 반복적(iterative) 구현**으로 변경함 - 코드는 길고 덜 우아하지만, 자기 자신을 호출하지 않기 때문에 재귀 없이 동일한 결과를 제공함 - 이렇게 하면 함수 호출 깊이와 메모리 사용 상한을 정적으로 추론하기 쉬워짐 #### 3) 동적 메모리 할당 금지 – AV Rule 206 - AV Rule 206: **초기화 이후에는 메모리 할당·해제를 하지 않는다** - 실행 중 `new`, `delete`, 스마트 포인터를 통한 내부 `new` 등 힙 할당을 금지함 - 이유는 두 가지 주요 문제 때문임 - 힙 할당에는 얼마가 걸릴지 모르는 **시간 비결정성**이 존재함 - 힙이 조각화(fragmentation)되면, 총 용량이 남아 있어도 큰 연속 블록을 찾지 못해 할당 실패가 발생할 수 있음 - 예시로, 돌풍(gust) 계산을 위해 **IAS(지시대기속도) 이력 버퍼**를 `std::unique_ptr` + 동적 배열로 만드는 비표준 코드를 보여줌 - 실행 중 새로운 배열을 할당해 JSF 규칙을 어기는 형태임 - JSF 준수 버전에서는 **최대 크기를 상수로 정의한 고정 크기 배열**을 사용함 - `MAX_IAS_HISTORY`와 같이 상수를 정의하고, 초기화 시 한 번만 메모리를 잡은 뒤 인덱스만 회전시키는 방식으로 운용함 - 이렇게 하면 실행 중에는 어떤 추가 할당도 일어나지 않아 시간·메모리 측면에서 예측 가능성이 확보됨 #### 4) Cyclomatic Complexity 상한 – AV Rule 3 - AV Rule 3은 함수의 **Cyclomatic Complexity(분기 복잡도)** 가 20을 넘지 않아야 한다고 규정함 - 함수 선언 자체 1점, if·while·for·switch·논리 AND/OR 등이 모두 복잡도에 1씩 더해짐 - 이항계수 반복 구현을 예시로, 각 if·논리 연산·for 루프가 복잡도 포인트를 어떻게 증가시키는지 보여줌 - 복잡도가 높아질수록 테스트·검증·분석이 어려워지기 때문에, 일정 상한 이하로 유지하는 것이 표준 목표임 ### JSF 유산: NASA F-Prime, MISRA, AutoSAR - JSF C++ 표준의 아이디어는 이후 다른 안전 중요 분야로 퍼져 나감 - NASA의 비행 소프트웨어 프레임워크 **F-Prime**은 2017년에 공개되었고, **동적 메모리 할당 금지, 예외 금지, 재귀 금지** 같은 규칙을 공유함 - 자동차 산업에서도 비슷한 흐름이 이어짐 - **MISRA C++**, **AutoSAR(Automotive Open System Architecture)** 같은 표준이 등장해 자동차 소프트웨어 안전 규칙을 제시함 - AutoSAR C++14 가이드는 JSF를 명시적으로 참고했다고 언급되며, JSF의 영향력이 자동차 소프트웨어까지 이어졌음을 보여줌 - 현대 자동차는 사실상 **“바퀴 달린 컴퓨터”** 에 가까운 만큼, 이런 언어 서브셋·코딩 규칙이 안전을 지탱하는 핵심 기반이 됨 ### 결론: 오늘 C++를 쓴다면 무엇을 따라야 하는가 - JSF C++ 표준은 당시 기준으로 **복잡한 언어를 예측 가능한 서브셋으로 축소해, 전투기 비행 제어 수준의 안전성을 확보한 엔지니어링 성과**로 제시됨 - 동시에 Bjarne Stroustrup는 오늘날 개발자에게 **C++ Core Guidelines**와 현대 C++를 따를 것을 권장함 - C++ 언어와 툴체인이 지난 수십 년간 발전했고, 예외·스마트 포인터 같은 기능도 안전하게 쓸 수 있는 환경이 많이 마련되었기 때문임 - 그럼에도 JSF는 여전히 **언어를 추가가 아니라 “제거”로 통제하는 사고방식**의 중요한 사례로 남음 - 무엇을 넣을지보다, 무엇을 **remove before flight** 리스트에 올릴지가 **안전 중요 시스템 설계의 핵심**이라는 메시지로 마무리 ## Comments ### Comment 47522 - Author: lostid - Created: 2025-12-10T15:23:00+09:00 - Points: 1 군사목적이기 때문에 낮은 하드웨어 스펙과 고급기능 사이에 균형잡기의 결과가 c++이 되지 않았을까 싶기도 합니다. ### Comment 47486 - Author: regentag - Created: 2025-12-10T09:41:46+09:00 - Points: 1 1. Ada는 gcc 베이스로 한 GNAT이라는 오픈소스 컴파일러가 있습니다. 요즘엔 llvm 베이스의 gnat-llvm도 있죠. 오픈소스 IDE도 제공되고요. 학생과 개발자들은 국방부 언어이고 수요가 적어서 안 배운거지 툴이 비싸서는 아닐거에요. 2. "통제된" Cpp보다는 Ada를 쓰는게 목적에 맞지 않을까 싶어요. 특히 Safety-Critical한 곳에서 Cpp는 너무 실수할 여지가 많아보여요. ### Comment 47504 - Author: iepics - Created: 2025-12-10T11:31:32+09:00 - Points: 1 - Parent comment: 47486 - Depth: 1 1. 개발 당시의 상황은 달랐을 수도요. ### Comment 47450 - Author: m00nny - Created: 2025-12-09T15:15:26+09:00 - Points: 1 전반적으로 예측 가능한 코드를 쓰는 기법에 관한 내용이군요. C++이 사례로 되어있을 뿐, GC같이 다른 언어에서는 더 문제가 되는 부분도 동일한데 C++의 한계를 논하는 것 처럼 이해될 수 있는 점은 아쉽습니다. C++의 동적할당이나 예외처리의 기법을 사용하지 않을 것이라면, C를 사용해서 위 원칙으로 작성하는 것이 훨씬 쉽고 빠르지 않은가, 하는 의문이 남네요. ### Comment 47465 - Author: ndrgrd - Created: 2025-12-09T21:08:00+09:00 - Points: 1 - Parent comment: 47450 - Depth: 1 그러게요 무엇 때문에 C가 아니라 C++인지 모르겠네요 ### Comment 47440 - Author: tsboard - Created: 2025-12-09T13:19:48+09:00 - Points: 1 현대적인 C++은 정말 안정적이지만, 꼭 C++ 일 필요가 없다면 더 안정적인 다른 언어를 고려해보는 게 어떨까 싶긴 합니다. ### Comment 47436 - Author: coremaker - Created: 2025-12-09T11:05:03+09:00 - Points: 1 RUST 문법을 STRICT 하게 쓰자! ### Comment 47414 - Author: neo - Created: 2025-12-09T00:35:10+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46183657) - F-35의 C++ 코딩 표준 문서가 [여기](https://www.stroustrup.com/JSF-AV-rules.pdf)에 있음 142페이지짜리로, 실제 항공기 소프트웨어 개발에서 어떤 제약이 있는지 볼 수 있음 - 몇 장 훑어봤는데 꽤 **합리적인 규칙들**로 보임 다만 “shall” 규칙의 예외가 궁금함. 이런 대규모 프로젝트에서는 예외 케이스가 표준의 실효성을 보여줌 - 실시간 시스템에서는 **운영 중 동적 메모리 할당 금지** 규칙이 있음 2005년 당시에는 괜찮았겠지만, 요즘 **AI 기반 드론** 같은 환경에서는 어떻게 적용될지 궁금함 - 이런 규칙을 **정적 분석 도구**로 강제하는지, 아니면 개발자들이 직접 숙지해야 하는지 궁금함 - 임베디드나 저사양 기기용 소프트웨어에도 이런 규칙이 유효한지 고민됨 특히 `stdio.h` 금지 같은 부분은 낯설지만, 읽다 보면 “그래, 맞는 말이네” 싶음 - 이 문서를 처음 봤을 때, 누군가가 “Arduino Uno용 C++도 여전히 C++이다”는 예시로 들었음 - 실제 MISRA 코드에서 본 적 있는 `a = a;` 같은 구문이 떠오름 사용되지 않는 파라미터를 제거하지 않기 위한 꼼수인데, 이런 규칙이 **좋은 코드 품질**을 보장하는지는 의문임 - MISRA 관련 연구를 보면 일부 규칙은 결함을 줄이지만, 일부는 오히려 결함을 늘림 JSF 가이드라인은 2005년 문서라 시대적 한계가 있음 Bjarne Stroustrup이 최근 “C++ 프로파일” 개념을 제시한 것도 흥미로움 결국 이런 스타일 가이드는 **미적 취향**의 문제일 수도 있음 - C에서는 변수를 참조만 할 때 `(void)a;`로 처리하는 게 표준적인 방식임 - 실제로 **안전 필수 코드**를 많이 작성해봤는데, 코딩 규칙이 전체 품질을 떨어뜨리는 경우도 많았음 진짜 안전을 보장하는 건 **설계 품질과 페일세이프 구조**임 - Zig에서는 `_ = a;`로 명시적으로 처리함 [관련 이슈](https://github.com/ziglang/zig/issues/335)도 있음 - 이런 표준은 코드 리뷰를 대체하지 않음 오히려 리뷰 시 참고할 **공통 기준**을 제공하는 역할임 - 위성 소프트웨어도 비슷하게 **STL 사용이 금지**되어 있음 핵심은 **미션 보증(mission assurance)** 임 스택이나 힙을 쓰면 변수의 메모리 주소가 바뀌는데, 특정 셀이 고장 나면 문제가 생김 모든 변수가 고정 주소를 가지면, 고장난 셀만 패치로 옮겨서 임무를 계속할 수 있음 - 하지만 C++에서 스택을 완전히 안 쓰는 건 불가능함 지역 변수, 매개변수, 반환 주소 등은 결국 스택에 필요함 재귀도 불가능해지고, 임시 변수도 제한됨 그래서 이 주장은 **현실적이지 않음** - 이런 수동적 접근보다는 **ECC 메모리**나 **Reed-Solomon 코딩** 같은 자동화된 방법이 더 효율적임 - 그렇다면 변수는 전역으로 두는 건가? 그리고 **메모리 셀 오류 감지**는 어떻게 하는지 궁금함 - 실제로는 스택을 사용함. 힙은 제한되지만 **메모리 풀**을 사용함 스택과 힙의 주소 범위를 고정할 수는 있지만, 이게 설득력 있는 이유인지는 의문임 - 그렇다면 함수의 in/out 파라미터는 어떻게 처리하는지도 궁금함 - “모든 if, else if에는 반드시 else나 주석이 있어야 한다”는 규칙이 있음 나도 비슷하게 “이 경우는 절대 발생하지 않아야 함” 같은 로그를 남김 대규모 시스템에서는 이런 **예외 상황 로깅**이 디버깅에 매우 유용함 - Rust의 **match 문**이 이런 점에서 좋음 모든 경우를 명시적으로 처리해야 해서, enum 값이 추가되면 컴파일러가 경고해줌 - 나는 여기에 `_STOP`이나 `_CRASH` 매크로를 추가해서 즉시 디버그 중단시키기도 함 문제를 바로 수정하도록 강제하는 효과가 있음 - Ada 대신 C++을 선택한 이유를 설명한 [엔지니어링 리드의 글](https://web.archive.org/web/20111219004314/http://journal.thedacs.com:80/issue/53/158)이 있음 요약하면 “Ada 개발자와 툴체인이 부족했다”는 이유였음 하지만 지금은 **언어 다양성에 대한 개방성**이 커져서 Ada가 더 받아들여질 수 있을 것 같음 NVidia가 SPARK를 채택한 것도 Ada의 **부활 조짐**으로 보임 - “Ada 개발자가 부족하다”는 논리는 싫어함 DoD가 Ada를 강제했다면, 대학과 기업이 따라왔을 것임 결국 **언어 학습은 가능**하고, Ada를 썼다면 F-35의 신뢰성도 더 높았을 것임 - 지금도 Ada 컴파일러를 파는 업체가 7곳이나 있음 [AdaCore](https://www.adacore.com/), [GHS](https://www.ghs.com/products/ada_optimizing_compilers.html), [PTC ApexAda](https://www.ptc.com/en/products/developer-tools/apexada), [DDC-I](https://www.ddci.com/solutions/products/ddci-developer-suite), [Irvine](http://www.irvine.com/tech.html), [OC Systems](http://www.ocsystems.com/w/index.php/OCS:PowerAda), [RR Software](http://www.rrsoftware.com/html/prodinf/janus95/j-ada95.htm) 등임 과거에는 Ada 컴파일러가 **유료 옵션**이었고, C/C++은 기본 제공이라 학교나 기업이 C++을 택했음 AdaCore가 ISO 표준화와 오픈소스 확산에 큰 기여를 했음 - 나도 Ada가 다시 **부흥**하길 바람 예전엔 과도하게 비판받았지만, 지금은 오히려 매력적으로 느껴짐 - 하지만 실제로 Ada를 써보니 문법이 마음에 들지 않았음 파일 구조나 빌드 플래그가 복잡했고, [RedMonk 언어 순위](https://redmonk.com/sogrady/2025/06/18/language-rankings-1-25/)에도 Ada가 없었음 일부 기능은 흥미로웠지만, **Rust처럼 현대적인 언어 경험**은 아니었음 - 항공전자 분야가 MISRA C/C++을 따르는지 궁금했음 - 코딩 표준은 일부일 뿐이고, 핵심은 **감사 가능한 프로세스 문서화**임 DO-178C 같은 인증 체계가 중요함 - 회사마다 다름. 어떤 곳은 **Matlab/Simulink 오토코드**로 생성된 C를 그대로 씀 오히려 이게 **고신뢰성 코드** 작성의 올바른 방식일 수도 있음 - 지역별로도 다름. 미국은 MIL 표준, 유럽은 ECSS, 항공은 DO-178C, 그리고 MISRA가 널리 쓰임 - LaurieWired의 유튜브 채널이 정말 훌륭함 - 특히 **ARM 어셈블리 튜토리얼 시리즈**가 뛰어남 - Laurie의 다른 영상들도 추천함 **리버스 엔지니어링**, **난독화**, **컴파일러** 등 다양한 주제를 다룸 - “널 포인터를 역참조하지 말라”는 규칙(AV Rule 174, MISRA Rule 107)을 보고 이런 것도 굳이 명시해야 하나 싶었음 - 실제 F-35 코드 빌드에 어떤 **컴파일러**를 쓰는지도 궁금함 LM이 직접 만든 건지, 상용 제품인지 알고 싶음