증거, 검증, 그리고 모델보다 툴체인이 더 중요한 이유.
속도가 제약 요인이 아닙니다. 증거가 제약 요인입니다.
AI 코딩 어시스턴트는 한 명의 개발자가 아침 시간 동안 만들어낼 수 있는 결과물의 양을 바꿔 놓았습니다. 예전에는 구상하는 데만 몇 시간이 걸리던 코드가 이제는 몇 초 만에 생성됩니다. 탐색적 작업과 신속한 프로토타이핑의 경우, 생산성 향상 효과는 실로 뚜렷합니다.
하지만 규제가 적용되는 임베디드 개발 분야, 즉 ISO 26262를 준수하는 자동차 소프트웨어, IEC 62304를 준수하는 의료 기기, IEC 61508을 준수하는 산업용 제어 시스템의 경우, 속도는 결코 병목 요인이 아니었습니다. 진정한 제약은 ‘증거’입니다. 코드가 실행된다는 증거가 아니라, 정의된 관행에 따라 생성되었고, 적절한 표준에 맞춰 검증되었으며, 요구사항부터 테스트까지 추적 가능하다는 증거가 필요합니다.
이것이 일반적으로 도입된 AI 지원에 대한 불편한 진실입니다. AI는 애초에 문제가 되지 않았던 부분, 즉 코드 작성 속도를 가속화하는 한편, 이미 많은 비용이 소요되던 검증, 유효성 확인, 규정 준수 입증 과정에 부담을 가중시킵니다.
AI는 코드를 생성합니다. 규정 준수를 생성하지는 않습니다.
현대적인 AI 도구는 정말로 뛰어난 능력을 갖추고 있습니다. 구현 방안을 제안하고, 함수를 완성하며, 테스트 뼈대를 생성할 수 있습니다. C 언어로 RPM 계산을 요청하면, 구문적으로는 정확하고 논리적으로도 타당한 결과를 얻을 수 있습니다.
하지만 그 출력물에는 규정 준수가 담기지 않습니다.
AI가 생성한 간단한 함수는 처음 읽었을 때 괜찮아 보일 수 있습니다. MISRA C 2012 규칙 10.3을 적용하는 정적 분석기는 암시적 형 변환을 결함으로 표시할 것이며, 이 결함은 코드가 검증된 요구사항으로 추적되기 전에 반드시 해결되어야 합니다.
이러한 패턴은 임베디드 팀이 준수하는 모든 표준에서 반복됩니다:
-
MISRA C/C++: 안전이 중요한 C 및 C++ 개발의 기준입니다. 언어를 명확하게 정의된 하위 집합으로 제한함으로써, 자동차, 산업 및 의료 분야에서 절대 타협할 수 없는 정의되지 않은 동작의 위험을 최소화합니다. AI 도구가 더 많은 C 및 C++ 출력을 생성함에 따라, MISRA 준수 여부는 코드베이스에 포함되는 모든 코드에 대한 중요한 관문이 됩니다.
-
CERT C/C++: 공격자가 악용하는 코딩 패턴을 방지하는 데 중점을 둡니다. MISRA가 안전성을 목표로 하는 반면, CERT C/C++는 보안을 목표로 하며, 연결된 임베디드 시스템에서 이 두 가지 관심사는 점점 더 중첩되고 있습니다.
-
CWE: 다양한 코드베이스에서 반복적으로 나타나는 소프트웨어 취약점 목록입니다. AI가 생성한 코드를 검토하는 팀에게 CWE는 모델이 훈련 데이터에서 무의식적으로 재현할 수 있는 취약점을 식별하기 위한 체계적인 용어집을 제공합니다. 모델은 규정을 준수하는 데이터와 그렇지 않은 데이터를 가리지 않고 모든 데이터로부터 학습하기 때문입니다.
이러한 표준 중 어느 것도 모델에 의해 강제 적용되지는 않습니다. 이는 적절한 툴체인의 지원을 받아 개발자가 책임져야 할 부분입니다.
검증의 병목 현상
안전이 중요한 프로그램에서 검증 및 확인 작업은 이미 연구개발(R&D) 비용의 40% 이상을 차지하고 있습니다. 이는 비효율성이 아니라, 규제 기관과 인증 기관이 요구하는 증거 체인을 구축하는 데 드는 비용입니다.
AI가 코드 작성을 가속화하지만 증거 체인은 그대로 둔다면 어떻게 될까요? 더 많은 코드가 검증 파이프라인으로 유입됩니다. 병목 현상은 더욱 심화됩니다. 선임 안전 엔지니어는 더 방대한 추적 매트릭스를 검토해야 합니다. 출시 시점은 여전히 제자리걸음입니다.
AI 도구는 개발 곡선 중 결코 제약 요인이 아니었던 부분을 공략합니다. 진정한 제약 요인은 항상 후반부, 즉 정적 분석, 동적 테스트, 커버리지 측정, 추적성, 그리고 사인오프였습니다. 이 후반부를 해결하지 않은 채 코드 작성만 가속화하는 것은 인증된 펌웨어를 출시하는 팀의 생산성 향상이 아닙니다. 이는 이미 과부하 상태인 프로세스에 가해지는 상류 단계의 압박일 뿐입니다.
품질이 실제로 자리 잡은 곳
이 격차를 해소한다는 것은 정적 분석, 동적 분석, 커버리지 측정을 개발 루프에 통합하는 것을 의미합니다. 이는 하류 단계의 감사 과정이 아니라, 지속적인 인라인 활동으로 수행되어야 합니다. 올바른 워크플로는 코드 생성과 규정 준수 검사를 분리하지 않고, 두 가지를 통합합니다.
빌드와 연동된 정적 분석
IAR 툴체인의 일부인 C-STAT은 코드가 검토 위원회나 인증 감사에 도달하기 전, 코드 입력 시점에서 MISRA C, MISRA C++, CERT C 및 CWE 위반 사항을 표시합니다. AI가 제안하고, 개발자가 검토하며, C-STAT이 검증합니다.
이미지: 실제 임베디드 프로젝트에서 MISRA C 2012 및 CERT C 검사 항목에 대한 위반 사항을 보여주는 C-STAT 분석 보고서
디버그 세션에서의 동적 분석
C-RUN은 디버그 세션 중에 코드를 계측하여 메모리 누수, 경계 위반, 정수 오버플로, 처리되지 않은 switch 문 등을 감지합니다. 이러한 결함은 실행 상태에 따라 달라지기 때문에 정적 분석만으로는 항상 포착할 수 없는 경우가 많습니다. 생성된 코드가 구조적으로는 올바르지만 동작 면에서 예상치 못한 결과를 보일 수 있는 AI 지원 워크플로우에서는 런타임 계측이 필수적입니다.
이미지: 디버그 시점에 힙 오류 및 경계 위반을 검사하는 C-RUN 런타임
모델이 제안하고, 개발자가 판단합니다.
이 모든 것이 AI에 대한 반론은 아닙니다. 생산성 향상은 분명합니다. 숙련된 개발자가 부족하고 프로젝트의 복잡성이 증가하는 임베디드 소프트웨어 분야에서, 코드 작성을 가속화하는 도구는 그 자체로 진정한 가치를 지닙니다.
하지만 AI 지원 워크플로우에서는 개발자의 역할이 코드 작성자에서 품질 관리자로 전환됩니다. 개발자의 전문성은 사라지는 것이 아니라 방향이 재조정되는 것입니다. 모든 함수를 처음부터 직접 작성하는 대신, 개발자는 도메인 지식을 바탕으로 AI의 제안을 평가하고, 분석 도구를 통해 이를 검증하며, 어떤 모델도 내릴 수 없는 판단을 내립니다. 즉, 논리가 안전 의도와 일치하는지, 테스트 스위트가 올바른 시나리오를 포괄하는지, 아키텍처가 일관성을 유지하는지 등을 판단하는 것입니다.
바로 이러한 판단 단계가 생성된 코드를 검증된 코드로 만들어 줍니다. 검증된 코드는 규제 산업에서 요구하는 필수 요소입니다.
CI/CD: 증거의 자동화
인라인 툴링은 워크스테이션에서 문제를 포착합니다. 하지만 팀 환경에서는 워크스테이션 수준의 점검만으로는 충분하지 않습니다. 파이프라인이야말로 규정을 적용하는 지점입니다. 여기서 코드가 어떻게 생성되었는지와 관계없이, 모든 커밋은 조직이 준수하기로 한 표준에 따라 자동으로 테스트됩니다.
한 개발자의 세션만으로도 지난주 전체 생산량보다 더 많은 코드가 생성될 수 있는 상황에서, 품질 검사를 수동으로 실행하는 방식은 확장성을 잃게 됩니다. 검사는 모든 푸시 시 자동으로 실행되어야 합니다.
IAR Build Tools는 IAR Embedded Workbench에서 사용되는 것과 동일한 컴파일러, 링커 및 툴체인을 제공하며, CI 환경에서 헤드리스 실행이 가능하도록 패키징되어 있습니다. 파이프라인이 Jenkins, GitHub Actions 또는 Azure DevOps에서 실행되든 상관없이, CI에서의 빌드는 개발자 머신에서의 빌드와 동일합니다. ISO 26262와 IEC 62304는 모두 릴리스 아티팩트를 생성하는 데 사용된 도구 구성이 문서화되고 재현 가능해야 한다고 규정합니다. IAR Build Tools는 이를 입증할 수 있게 해줍니다.
C-STAT은 CI 환경에서 헤드리스 모드로 실행됩니다. 위반 사항은 빌드 출력물로 보고되며, 커버리지 추세는 시간 경과에 따라 추적됩니다. 아키텍처 편차는 즉시 파악할 수 있습니다. 규정 준수 증거는 릴리스 시점에 따로 수집할 필요가 없으며, 프로젝트 진행 과정 전반에 걸쳐 축적됩니다.
이 모든 것을 뒷받침하는 플랫폼
위에서 언급한 도구들은 관리되는 개발 플랫폼 내에 배치될 때 그 가치가 배가됩니다. 이 플랫폼에서는 빌드가 재현 가능하고, 도구 검증 결과가 문서화되며, 소스 코드부터 인증 아티팩트에 이르는 증거 체인을 재구성할 수 있습니다.
IAR 플랫폼은 이러한 요구 사항을 중심으로 설계되었습니다. 도구 검증 지원은 ISO 26262(TÜV SÜD 인증), IEC 61508 및 IEC 62304를 포괄합니다. C-STAT과 C-RUN은 해당 환경에 직접 통합되므로, 규정 준수 검사가 빌드와 동일한 컨텍스트에서 실행됩니다.
이것이 바로 생산성 이야기와 규정 준수 이야기의 차이점입니다. AI가 아니라, 플랫폼과 그 기반이 되는 툴체인입니다.
AI는 코드를 작성합니다. 툴체인은 인증을 획득합니다. IAR은 두 가지를 모두 제공합니다.
다음 단계는 무엇일까요?
IAR 플랫폼이 실제 환경에서 어떻게 작동하는지 확인하고 싶으시다면, 대화형 데모를 통해 안전 인증 컴파일러, 코드 분석, CI/CD 통합을 통한 규정 준수 과정을 단계별로 살펴보실 수 있습니다.
안전이 중요한 개발 분야에서 AI 지원 워크플로우에 대해 더 자세히 알아보시려면, 실습 데모가 포함된 온디맨드 웨비나“100M 라인의 함정에서 벗어나기”를 시청해 보십시오.
혹은 산업 자동화 분야를 다루고 계신다면,“스마트 산업의 병목 현상 타파(Breaking the Smart Industry Bottleneck)” 웨비나를 통해 IEC 61508 인증 기반이 스마트 산업 이니셔티브를 저해하는 검증 부담을 어떻게 해소하는지 확인해 보세요.
