개발 프로세스의 What이 아닌 how의 근본적인 변화에서
AI가 소프트웨어 개발에 미치는 영향은 단순한 생산성 향상을 넘어섭니다. 개발자가 빈 에디터 화면 앞에서 한 줄 한 줄 코드를 작성하던 시대는 빠르게 저물고 있습니다. 이제 개발자는 AI에게 의도를 전달하고, AI가 생성한 결과물을 검토하고 다듬는 방식으로 일하기 시작했습니다. 소프트웨어 요구사항 명세서의 초안을 AI가 작성하고, 상세 설계를 기반으로 AI가 구현 코드를 생성하며, 그 코드를 검증하기 위한 테스트 케이스마저 AI가 만들어 주는 것이 현실입니다.
효율화 관점에서 본다면, 이러한 변화를 거부할 이유가 없습니다. 그러나 여기서 우리가 간과해서는 안 되는 것이 있습니다. 차량용 소프트웨어는 웹 애플리케이션이나 모바일 앱과는 본질적으로 다른 맥락 위에 놓여 있다는 점입니다. 차량용 소프트웨어에는 사람의 생명과 직결되는 안전(Safety) 이라는 무게가 실려 있고, 문제가 발생했을 때 누가 책임을 지는가(Liability) 라는 질문이 반드시 뒤따릅니다. 조향 제어 소프트웨어의 한 줄의 코드가, 브레이크 시스템의 하나의 로직이 사람의 생사를 가를 수 있는 영역입니다. 따라서 “누가, 왜, 어떤 근거로 이렇게 개발했는가”에 대한 명확한 답이 항상 준비되어 있어야 합니다.
바로 이것이 Automotive SPICE®와 같은 개발 프로세스 모델이 존재하는 이유이기도 합니다. 이러한 프로세스를 통해 개발의 전 과정을 추적 가능하게 만들고, 각 단계에서의 판단과 결정에 대한 근거를 확보하는 것. AI 시대에도 이 본질은 변하지 않습니다. 다만, 그 본질을 지키는 방식이 달라져야 한다는 것이 지금 우리가 직면한 과제입니다.
AI 생성물과 ASPICE - 무엇이 달라지는가
Automotive SPICE®를 논의할 때 자주 간과되는 중요한 원칙이 하나 있습니다. ASPICE는 소프트웨어 개발에서 “무엇을(What)” 달성해야 하는지를 정의하는 프레임워크이지, “어떻게(How)” 수행해야 하는지를 강제하는 규칙집이 아니라는 것입니다. 이 원칙을 이해하면, AI 활용이 ASPICE와 본질적으로 충돌하지 않는다는 것을 알 수 있습니다. AI는 “어떻게”에 해당하는 수행 방법의 변화일 뿐, “무엇을”에 해당하는 프로세스의 목적을 부정하는 것이 아니기 때문입니다.
그렇다면 실질적으로 무엇이 달라지는 것일까요? 각 프로세스 영역에서 요구하는 Base Practice(BP)의 수행 증거를 확보하는 방식이 달라집니다. 이것을 주요 프로세스 영역별로 좀 더 구체적으로 살펴보겠습니다.
SWE.1 소프트웨어 요구사항 분석
ASPICE 관점에서 중요한 것은 “얼마나 정확하고 완전하며 추적 가능한가”입니다. AI가 도출한 요구사항의 완전성(Completeness)을 누가 검증했는지, 시스템 요구사항과 소프트웨어 요구사항 사이의 양방향 추적성(Bidirectional Traceability)이 올바르게 설정되어 있는지, 그리고 요구사항 간에 모순이나 중복은 없는지에 대한 일관성(Consistency) 검토가 이루어졌는지가 핵심입니다. AI가 초안을 아무리 훌륭하게 만들었더라도, 그것을 개발자가 기술적 관점에서 검토하고 승인했다는 기록이 없다면 BP 충족의 증거로 인정받기 어렵습니다.
SWE.3 소프트웨어 상세 설계 및 단위 구현
이 영역에서 특히 주의해야 할 부분은 AI가 생성한 코드의 설계 근거(Design Rationale) 입니다. 사람이 코드를 작성할 때는 “왜 이 방식을 선택했는가”에 대한 맥락이 개발자의 머릿속에 존재하고, 이것이 설계 문서나 리뷰 기록을 통해 자연스럽게 남게 됩니다. 반면 AI가 생성한 코드에는 이러한 의사결정의 맥락이 빠져 있는 경우가 많습니다. 코드 자체는 기능적으로 동작하더라도, 그 코드가 소프트웨어 아키텍처 및 상세 설계와 일치하는지, MISRA® C와 같은 코딩 표준을 준수하는지에 대한 확인이 반드시 수반되어야 합니다.
SWE.4 소프트웨어 단위 검증
테스트 영역에서 AI의 활용은 언뜻 보기에 가장 안전해 보입니다. 다만 AI가 생성한 테스트 케이스가 단순히 코드의 분기(Branch)를 커버하기 위한 목적으로만 설계되었는지, 아니면 실제로 요구사항 기반(Requirement-based)으로 도출된 의미 있는 검증인지를 구별해야 합니다. 커버리지 수치가 100%에 달하더라도, 경계값이나 이상값, 실패 시나리오에 대한 테스트가 누락되어 있다면 그것은 형식적인 검증에 불과합니다. 테스트 결과에 대한 합격과 불합격의 판정 기준이 요구사항에 근거하여 명확하게 정의되어 있는지도 중요한 확인 포인트입니다. 결국 AI가 만든 테스트라 하더라도, 그 테스트가 진정으로 소프트웨어의 품질을 보증하는 것인지에 대한 판단은 사람의 몫으로 남습니다.
SUP.8 형상 관리
AI 도입은 형상 관리의 범위를 눈에 띄게 확장시킵니다. 지금까지 형상 관리의 대상은 소스 코드, 문서, 바이너리 등 비교적 명확했습니다. 그러나 AI를 활용하는 환경에서는 새로운 유형의 관리 대상이 등장합니다. AI에 입력한 프롬프트(Prompt)와 설정 파라미터, AI 도구 자체의 버전 및 모델 정보, 그리고 생성 결과물에 대한 리뷰 및 수정 이력이 모두 형상 관리의 범위에 포함되어야 합니다. 이것이 중요한 이유는 재현성(Reproducibility) 때문입니다. 동일한 프롬프트를 입력하더라도 AI 모델의 버전이 달라지면 전혀 다른 결과물이 나올 수 있습니다. 따라서 AI 관련 아티팩트를 체계적으로 버전 관리하는 새로운 실무 관행이 필요합니다.
개발자의 역할 재정의 - 작성자에서 검증자로
앞서 살펴본 프로세스 영역별 변화를 관통하는 하나의 큰 흐름이 있습니다. 바로 개발자 역할의 근본적인 재정의입니다. 전통적인 개발 환경에서 개발자는 코드와 산출물의 작성자(Author) 였습니다. 요구사항을 분석하고, 설계를 수행하며, 코드를 한 줄 한 줄 작성하는 것이 개발자의 핵심 업무였습니다. 이 과정에서 개발자는 자연스럽게 자신이 만든 결과물에 대한 깊은 이해를 갖게 되었고, 그 이해 자체가 프로세스 준수의 암묵적 증거로 작동했습니다.
AI 시대에는 이 구도가 바뀝니다. 개발자의 핵심 역할은 검증자(Verifier)이자 승인자(Approver) 로 이동합니다. AI가 생성한 결과물이 기술적으로 올바른지, 설계 의도에 부합하는지, 안전 요구사항을 충족하는지를 판단하고 최종 승인하는 것이 개발자의 가장 중요한 책무가 됩니다.
이것은 단순한 직무 기술서의 변경이 아닙니다. Automotive SPICE®와 ISO 26262 모두 개발 결과물에 대한 기술적 이해와 책임을 요구하고 있으며, AI가 아무리 뛰어난 결과물을 만들어 내더라도 그 최종 책임은 반드시 사람에게 있어야 한다는 원칙은 변하지 않습니다.
“잘 안다”의 기준을 구체화해야 합니다
“개발자가 개발 내역을 잘 알아야 한다”는 원칙에는 대부분 동의합니다. 그러나 “잘 안다”는 것이 구체적으로 무엇을 의미하는지는 합의된 바가 거의 없습니다. AI 시대에 이 기준을 모호한 채로 둘 수는 없습니다.
실무적으로 “개발 내역을 충분히 이해하고 있다”는 것은 최소한 네 가지 수준으로 나누어 생각할 수 있습니다. 첫째, 설계 의도에 대한 이해입니다. 왜 이 구조로 구현되었는지를 설명할 수 있어야 하며, 이는 설계 리뷰 기록이나 리뷰 코멘트를 통해 확인할 수 있습니다. 둘째, 동작 원리에 대한 파악입니다. 입력에서 처리를 거쳐 출력에 이르는 흐름을 추적할 수 있어야 하고, 코드 워크스루 기록이 이를 뒷받침합니다. 셋째, 제약 조건에 대한 인지입니다. 타이밍, 메모리, 안전 요구사항과의 관계를 파악하고 있어야 하며, 요구사항 추적 매트릭스를 통해 이를 증명할 수 있습니다. 넷째, 변경 영향에 대한 판단 능력입니다. 특정 부분을 수정했을 때 어떤 영역에 영향이 미치는지 판단할 수 있어야 하고, 영향 분석 문서가 그 근거가 됩니다.
여기서 중요한 것은 개발자가 코드 100줄을 직접 한 줄씩 타이핑하지 않았더라도, 위 네 가지 기준에 대해 논리적인 근거를 명확히 제시하면, ASPICE Base Practice 수행의 증거들로 인정받을 수 있다는 점입니다. 반대로 말하면, AI가 생성한 결과물을 아무런 검토 없이 그대로 복사하여 사용했다면, 그것은 개발자가 직접 작성한 코드보다도 오히려 프로세스 준수에 취약한 상태가 됩니다.
ISO 26262와의 교차점 – 도구를 어디까지 신뢰할 것인가
ASPICE만으로는 AI 활용의 모든 측면을 다루기 어렵습니다. 특히 안전 관련 소프트웨어에서 AI를 활용하는 경우, ISO 26262가 요구하는 Tool Confidence Level(TCL) 평가를 함께 고려해야 합니다.
ISO 26262는 소프트웨어 개발에 사용되는 도구가 안전에 미치는 영향을 평가하도록 요구합니다. AI 코드 생성 도구를 소프트웨어 개발 도구로 본다면, 두 가지를 따져봐야 합니다. 하나는 Tool Impact(TI) 입니다. 즉, AI 도구의 출력이 안전 관련 소프트웨어에 직접 반영되는가 하는 점입니다. 다른 하나는 Tool Error Detection(TD) 으로, AI 도구가 만들어 낸 오류를 리뷰나 테스트 같은 후속 활동에서 충분히 탐지해 낼 수 있는가 하는 점입니다.
만약 AI가 ASIL-B 이상의 안전 관련 기능 코드를 생성하고, 그 코드에 대해 충분한 독립적 검증 활동이 수반되지 않는다면, AI 도구 자체에 대한 Tool Qualification(도구 검증) 이 필요할 수 있습니다. 도구 검증은 상당한 비용과 노력을 수반하는 작업입니다. 따라서 조직이 AI 활용 범위를 결정할 때, “어디에 AI를 쓰고 어디에는 쓰지 않을 것인가”라는 판단에 TCL 평가 결과가 중요한 기준이 되어야 합니다. 무조건적인 AI 확대가 아니라, 안전 등급과 검증 체계를 고려한 합리적인 적용 범위를 설정하는 것이 현명한 접근입니다.
실천 제안 - 조직이 지금 시작할 수 있는 것
지금까지의 논의가 다소 무겁게 느껴질 수 있습니다. 프로세스 재설계, 역할 재정의, 형상 관리 확장 등 해야 할 일이 산더미처럼 보이기도 합니다. 그러나 모든 것을 한꺼번에 완성할 필요는 없습니다. 중요한 것은 올바른 방향으로 첫 걸음을 내딛는 것이며, 다음 세 가지는 지금 당장 시작할 수 있습니다.
첫째, 조직 내 AI 활용 가이드라인을 수립하는 것입니다. 허용되는 AI 도구의 목록과 각 도구의 용도를 정리하고, 특히 안전 관련 코드에 대해서는 ASIL 등급에 따른 AI 활용 제한 기준을 설정하며, AI가 생성한 결과물에 대해서는 반드시 거쳐야 하는 리뷰 절차를 정의하는 것입니다. 처음부터 완벽한 가이드라인을 만들려고 하면 오히려 시작조차 하지 못하게 됩니다. 70%의 완성도로 먼저 만들어 적용하고, 실제 경험을 반영하여 지속적으로 개선해 나가는 접근이 훨씬 효과적입니다.
둘째, AI 생성물에 특화된 리뷰 체크리스트를 도입하는 것입니다. AI가 생성한 코드와 산출물은 사람이 작성한 것과는 다른 유형의 오류를 포함할 수 있습니다. 존재하지 않는 API를 호출하는 이른바 환각(Hallucination) 현상이나, 불필요하게 복잡한 구현, 또는 특정 플랫폼의 제약을 무시한 코드가 대표적입니다. 요구사항과의 일치성, 설계 제약 조건의 반영 여부, 코딩 표준 준수, 안전 및 보안 취약점 등을 체계적으로 점검하는 체크리스트를 만들어 활용한다면, 이 체크리스트의 존재와 적용 이력 자체가 ASPICE 심사에서 “AI 출력물을 체계적으로 관리하고 있다”는 강력한 증거가 됩니다.
셋째, 파일럿 프로젝트를 통해 먼저 검증하는 것입니다. 전사 적용에 앞서, 비안전(Non-Safety) 영역의 프로젝트를 선정하여 AI 도입을 시범 운영해 보는 것을 권장합니다. 이 과정에서 AI 활용에 따른 생산성 변화를 정량적으로 측정하고, 프로세스 상에서 어떤 변경이 필요한지를 식별하며, ASPICE 자체 심사(Self-Assessment)를 통해 준수성을 사전에 점검할 수 있습니다. 파일럿에서 발견된 문제점과 교훈을 가이드라인에 반영하면, 본격적인 확대 적용 시 시행착오를 크게 줄일 수 있습니다.
마무리
AI는 자동차 소프트웨어 개발의 풍경을 빠르게 바꾸어 놓고 있습니다. 이 변화 앞에서 우리가 던져야 할 질문은 “AI를 쓸 것인가, 쓰지 않을 것인가”가 아닙니다. AI를 쓰지 않는 선택은 이미 현실적이지 않습니다. 진짜 질문은 “AI를 어떻게 관리하며, 책임 있게 쓸 것인가” 입니다.
변하는 것은 프로세스의 수행 방식이고, 증거의 형태이며, 개발자에게 요구되는 역량의 무게중심입니다. 이 변화를 외면하고 기존 방식을 고수하는 것도, 반대로 AI에 대한 관리 체계 없이 무분별하게 확대하는 것도 바람직하지 않습니다. AI 시대에 맞게 프로세스를 재설계하고, 개발자의 역할을 재정의하며, 새로운 형태의 증거를 체계적으로 관리하는 조직만이 효율성과 안전성이라는 두 가지 가치를 모두 잡을 수 있을 것입니다.
지금 우리 조직의 프로세스는, AI 시대를 맞이할 준비가 되어 있습니까?