자동차 업계에서 배우는 AI 결과물과의 마주하기

Claude Code나 Codex와 같은 AI 코딩 에이전트 (AI Coding Agent)를 사용하다 보면, 코드를 작성하는 것 자체는 점점 더 편해지고 있습니다. 반면, 시간이 조금 지난 코드를 다시 보았을 때 "이거 왜 만들었었지?", "어떤 요구사항과 관련이 있지?", "어떤 테스트로 보호되고 있었지?"라는 질문이 즉각 떠오르지 않는 상황도 늘어나고 있습니다.

직접 손을 움직여 작업했을 때는 작성한 기억과 함께 "왜"라는 이유도 남았지만, AI에게 맡기는 양이 늘어나면 그 "왜"가 빠지기 쉽습니다. 이 과제를 생각하는 데 있어 자동차 업계의 개발 프로세스가 참고가 될 것 같습니다.

이 기사는 AI 시대의 과제를 "코드를 만드는 것"보다 "결과물 사이의 관계성을 파악하는 것"으로 파악하고, 자동차 업계의 ASPICE나 최근의 AI 에이전트 (AI Agent) 흐름과 겹쳐서 정리하는 메모입니다.

이 기사에서 다루는 내용은, AI가 코드, 테스트, 설계서를 생성할 수 있게 될수록 요구사항·설계·구현·테스트의 연결이 중요해진다는 이야기입니다. 자동차 업계에서는 이전부터 이 관계성을 강력하게 관리해 왔습니다. Web이나 업무 시스템 개발에서도 AI에게 올바른 문맥 (Context)을 전달하기 위한 기반으로서, 이와 유사한 사고방식의 가치가 높아질 것이라고 생각합니다.

AI가 코드도 테스트도 설계서도 생성하게 되면, 결과물의 양은 점점 늘어납니다. 늘어나는 것 자체는 좋지만, 각각이 "왜 이 기능을 만들었는지", "어떤 요구사항으로부터 생성되었는지", "어떤 테스트로 보증되고 있는지"라는 관계성을 유지한 채 늘어난다는 보장은 없습니다.

따라서 AI 시대의 과제는

생성된 결과물 사이의 관계성을 파악하는 것

이라고 생각합니다.

자동차 업계에서는 소프트웨어의 결함이 사고나 리콜로 직결됩니다. 그래서 "작동하는 소프트웨어가 만들어졌습니다"만으로는 부족하며, 요구사항·설계·구현·테스트가 어떻게 연결되어 있는지를 추적할 수 있어야 합니다.

요구사항
↕
설계
...

요구사항이 바뀌었을 때, 어떤 설계에 영향을 미치고, 어떤 코드를 고쳐야 하며, 어떤 테스트를 재검토해야 하는지를 추적할 수 없다면 안전성이나 품질을 유지할 수 없습니다. 이 사고방식을 뒷받침하는 것이 Automotive SPICE (ASPICE)입니다.

ASPICE는 "자동차 소프트웨어 개발 프로세스의 성숙도를 평가하는 프레임워크"로 알려져 있지만, 현장에서 효과를 발휘하는 것은 성숙도 점수 그 자체보다,

요구사항부터 테스트까지의 결과물 관계성을 유지하는 것

이라고 이해하고 있습니다. 실제로 추적성 (Traceability)은 자동차 소프트웨어 개발의 중요한 활동이며, 많은 규격과 개발 프로세스의 기반이 된다고 합니다. (arXiv)

자동차 소프트웨어 품질에 AI 에이전트 (AI Agent)를 사용하는 논의에서는 요구사항 분석, 테스트 생성, 추적성 관리 등이 대상이 되고 있습니다. (LinkedIn)

AI가 다루고 있는 것은 ASPICE가 이전부터 대상으로 삼아온 요구사항, 설계, 구현, 테스트와 같은 결과물입니다.

요구사항
↓
설계
...

요구사항에서 설계, 구현, 테스트로 진행되는 흐름 자체는 변하지 않습니다. 변하는 것은 그 결과물을 인간뿐만 아니라 AI도 생성하게 된다는 점입니다.

Walid Negm 씨의 "Reinventing Automotive Software Quality with AI Agents"라는 기사에서는, 자동차 소프트웨어 품질의 기반으로서 가장 먼저 **End-to-end Traceability (종단 간 추적성)**가 언급되었습니다. 기사 안에서는 Traceability Agent, Requirements Analysis Agent, Test Generation Agent와 같은 역할도 제안되고 있습니다. (LinkedIn)

여기서 주목해야 할 것은,

코드를 생성하는 AI

뿐만 아니라,

요구사항과 설계를, 설계와 테스트를, 테스트와 릴리스를 연결하는 AI

라고 파악했습니다.

AI가 구현을 빠르게 하면 할수록, 이 코드가 어떤 요구사항에서 태어났는지, 이 테스트는 무엇을 보증하는지, 이 변경은 어디에 영향을 미치는지 파악하는 중요성은 오히려 올라갑니다. 서두에 언급한 저의 고민과 그대로 겹칩니다.

최근 연구에서도 요구사항 분석·설계·테스트 생성·추적성 관리를 여러 AI 에이전트 (AI Agent)로 수행하려는 움직임이 있으며, 공통의 지식 그래프 (Knowledge Graph)로 결과물 사이의 관계성을 유지하는 것이 중요하다는 점이 지적되고 있는 듯합니다. (arXiv)

동일한 흐름이 Web 업계에서도 보이기 시작했습니다. Atlassian은 팀, 작업, 앱을 연결하는 데이터 계층으로서 「Teamwork Graph」를 정의하고, 그 위에서 Rovo의 검색, 채팅, Agent를 전개하고 있습니다. (Atlassian)

업계는 다르더라도 과제의 형태는 매우 유사합니다.

AI가 우수해질수록,

Intent (의도)
↓
Requirement (요구사항)
...

와 같은 흐름의 상류에 있는 정보가 중요해집니다. 최근의 AI 에이전트 (AI Agent) 개발 논의에서도, 단순한 티켓 구동(Ticket-driven) 방식이 아니라 사양(Specification)이나 아키텍처 (Architecture), 시스템 전체의 문맥 (Context)을 명시하는 것의 중요성이 이야기되고 있습니다. (LinkedIn)

AI는 코드 생성 (Code Generation)에 능숙합니다. 다만, 왜 그 기능이 존재하는지, 어떤 요구사항을 충족하는지, 어떤 테스트로 보장되는지를 지속적으로 유지하는 것은 여전히 인간, 혹은 이를 묶어주는 메커니즘의 업무로 남을 것으로 보입니다.

지금까지 감사나 품질 보증 (Quality Assurance)을 위한 메커니즘으로 다뤄져 왔던

• 요구사항 관리 (Requirement Management)
• 추적성 (Traceability)
• 아키텍처 (Architecture)
• 변경 관리 (Change Management)

가, AI 에이전트에게 올바른 컨텍스트 (Context)를 제공하기 위한 기반으로 변하고 있다고 생각합니다.

하지만 솔직히 Web이라고 불리는 업계에서 어디까지 추적성 (Traceability)을 의식해야 할지는 미지수이며, ASPICE의 무게감을 그대로 가져오는 것은 과하다고 생각합니다. 「지식 그래프 (Knowledge Graph)로 관계성을 유지한다」는 것도 말하기는 쉽지만 운용은 별개의 문제입니다.

따라서 이 기사는 「자동차 업계의 방식을 그대로 모방하자」가 아니라, 「사고방식의 선행 사례로서 보면 배울 점이 있다」 정도의 스탠스가 적절할 것 같습니다.

AI에 의해 코드 생성은 점점 더 쉬워질 것입니다. 다만, 결과물이 늘어나면 늘어날수록 그것이 왜 존재하는지, 무엇과 연결되어 있는지, 무엇을 변경하면 영향을 받는지 파악할 필요가 생깁니다. 이는 AI가 빨라질수록 더욱 중요해집니다.

자동차 업계는 이 과제와 이전부터 마주해 온 업계입니다. ASPICE는 AI가 대량의 결과물을 만들어내는 시대에,

결과물 간의 관계성을 어떻게 유지하고, 어떻게 활용할 것인가

를 고민하기 위한 선행 사례로 볼 수 있다고 생각합니다.

변화가 빠른 AI 코딩 개발에서 이것들을 어느 정도 중요하게 여겨야 할지, 비슷한 생각을 하고 계시거나 실무에서의 다른 관점이 있다면 꼭 댓글 등으로 알려주세요.