Make Yourself Redundant: Stellantis 엔지니어링이 AI로 개발을 줄이면서 설계는 사람이 쥐는 방식

Stellantis 엔지니어들은 AI 도구로 핸즈프리 주행 시스템을 6주 만에 만들었고 결함 수정 기간도 2~3주에서 2~3일로 줄였습니다. 그러면서도 안전에 직결되는 시스템 아키텍처는 사람이 짭니다. AI 점검을 완전히 믿기까지 제품 주기 한 번(약 4년)을 더 지켜보겠다고 합니다. 따라 하려면 AI가 채울 일과 사람이 끝까지 쥘 일을 먼저 가른 뒤 시스템마다 책임자 한 명을 정해야 합니다.

요약

Fortune의 Nick Lichtenberg 기자는 Stellantis 북미 엔지니어링의 본거지인 Chrysler Technology Center를 찾아 엔지니어와 관리자들을 인터뷰했습니다. 회사 사정은 빠듯합니다. Stellantis는 차량 개발 기간을 4년에서 24개월로 줄이려 하며 2027년 두 차종부터 시작합니다. 2026년 2분기 조정 영업이익률은 1.8%였고 Antonio Filosa CEO는 2030년 7%를 목표로 잡았습니다. 2월에는 약 222억 유로를 상각했습니다. 기사는 이런 상황에서 AI가 코드 작성과 결함 수정, 공력 해석, 시뮬레이터 데이터 분석, 설계 관행 점검에 어떻게 들어갔는지를 현장 담당자의 말로 보여 줍니다.

결과는 기간에서 드러납니다. L2++ 핸즈프리 주행 시스템 담당 Joydip Saha의 팀은 AI 도구로 시스템을 6주 만에 만들었습니다. 예전에는 비슷한 과제에 1년에서 18개월이 걸렸습니다. 소프트웨어 팀에서는 결함 수정이 2~3주에서 2~3일로 줄었습니다. 공력 팀은 설계 변경 하나의 항력 추정을 14~24시간 걸리던 전체 시뮬레이션 대신 약 3분 만에 받습니다. 그래도 사람의 몫은 남겨 둡니다. Saha는 AI로 시스템 아키텍처를 짜지 못하게 합니다. Alison Rahm은 AI가 설계 관행 약 1,000개를 점검해도 제품 주기 한 번은 더 지켜봐야 한다고 봅니다. Ned Curic 최고 엔지니어링·기술 책임자(CETO)는 소규모 팀과 시스템별 단일 책임자 체제를 들여왔습니다. 올해는 엔지니어를 수백 명 더 뽑습니다. 아래에서는 이 분업이 어떻게 작동하는지 다섯 가지 메커니즘으로 풀고, 따라 할 때 필요한 기술·현업 디테일을 붙입니다.

핵심 메커니즘

Agentic Coding: 코드 작성과 결함 수정을 AI 도구에 맡기기

무엇인가. agentic coding 도구(목표를 받으면 스스로 코드를 읽고 고치고 실행하는 AI 코딩 도구)로 기능 개발과 결함 수정의 반복 작업을 맡기는 방식입니다.

어떻게 작동하나. 엔지니어가 만들 기능이나 고칠 결함을 정하면 AI 도구가 코드 초안과 수정안을 냅니다. 엔지니어는 그 결과를 빌드해 시험하고 다음 지시를 줍니다. 사람이 손으로 쓰던 시간이 줄면서 한 바퀴가 빨라집니다. Saha는 새 소프트웨어 빌드를 모두 직접 시험하며 주 최대 2회씩 돌립니다.

원문의 예. 핸즈프리 주행 시스템은 6주 만에 나왔습니다. 소프트웨어 엔지니어링 매니저 Ben Zawodni의 관측(observability, 시스템 상태를 지표·로그로 들여다보는 기능) 개념 증명은 1주가 걸렸습니다. 그는 agentic coding 도구가 없었다면 6개월이 걸렸을 것으로 봅니다. 결함 수정도 2~3주에서 2~3일로 줄었습니다.

언제 쓰고 언제 안 쓰나. 경계가 정해진 모듈 안의 코드, 테스트, 결함 수정에 씁니다. 모듈을 어떻게 나누고 이을지 정하는 일에는 쓰지 않습니다(다음 메커니즘).

Human-Owned Architecture: 안전 핵심 시스템의 설계는 사람이 짜기

무엇인가. 안전에 직결되는 시스템에서 아키텍처(모듈 구성과 연결 방식)는 사람이 직접 짜고, AI는 그 안을 채우는 데만 쓰는 규칙입니다.

어떻게 작동하나. 사람이 모듈 경계와 인터페이스를 정하면 AI가 각 모듈 안의 코드를 씁니다. 결과는 사람이 다시 시험합니다. Saha가 이 규칙을 두는 이유는 “they will forget how to debug stuff”라는 한마디에 담겨 있습니다. AI가 아키텍처를 짜면 엔지니어가 디버깅하는 법을 잊는다는 뜻입니다. 안전 핵심 업무의 엔지니어는 어떤 질문에도 답할 수 있어야 한다는 것이 그의 기준입니다.

원문의 예. Zawodni는 기능을 덧붙여 온(bolting on) 수백 개의 전자 제어 장치(ECU)를 중앙 컴퓨터 STLA Brain으로 합치고 있습니다. 그는 엔지니어들이 핵심 역량을 잃을까 걱정한다고 전합니다. 그래서 이들이 아키텍트가 되기를 바랍니다.

작은 예시(가상 예시). 브레이크 신호를 받는 모듈의 입출력 형식은 담당 엔지니어가 정합니다. AI는 그 형식에 맞는 파싱 코드와 단위 테스트를 씁니다.

AI Drag Estimate: 전체 시뮬레이션 전에 3분 만에 항력을 가늠하기

무엇인가. 설계를 바꿀 때마다 오래 걸리는 전체 공력 시뮬레이션을 돌리지 않고, AI로 항력(공기 저항)을 먼저 추정하는 방식입니다.

어떻게 작동하나. 엔지니어가 형상을 바꾸면 AI가 몇 분 안에 항력 추정값을 냅니다. 그 값으로 후보를 많이 걸러 낸 뒤, 추린 안만 전체 시뮬레이션과 풍동 시험으로 보냅니다. 풍동은 보통 하루에 차 1대를 시험하므로 가장 비싼 확인 단계입니다.

원문의 예. 공력 매니저 Arturo Guzman은 약 5년 전부터 AI를 들였습니다. Ram 픽업의 프런트 스플리터를 바꾸면 약 3분 만에 항력 추정이 나옵니다. 전체 시뮬레이션은 14~24시간이 걸렸습니다. 그는 AI를 인턴에 비유합니다. 그의 팀은 이제 가이드라인을 쓰고 사내 요청을 받으며 시뮬레이션 데이터에서 특허 거리를 찾습니다. 풍동 쪽 Todd Lounsberry는 최근 20회 시험 데이터를 AI에 넣습니다. 캐나다 Windsor의 주행 시뮬레이터를 맡은 Mohammed Malik은 가상 요철을 지난 뒤 수천 개 데이터 채널 가운데 무엇을 볼지 AI로 고릅니다.

Design Practice Check: 설계 관행 약 1,000개를 AI로 대조하기

무엇인가. 회사가 쌓아 온 엔지니어링 설계 관행 약 1,000개를 AI가 설계에 하나하나 대조하는 점검입니다.

어떻게 작동하나. 규칙 목록과 설계 자료를 넣으면 AI가 규칙마다 지켰는지 확인합니다. 반복 대조를 AI가 맡으니 엔지니어는 규칙 자체가 지금도 맞는지 따질 시간을 얻습니다. 중형·대형 SUV 수석 차량 엔지니어 Alison Rahm의 설명입니다.

신뢰는 주기 단위로 쌓습니다. Rahm은 가정이 맞았는지 스스로 확인하려면 제품 주기가 한 번 더 필요하다고 봅니다. 약 4년, 곧 2030년 무렵입니다. 가상 충돌 시험이 나온 뒤에도 실제 차를 벽에 부딪치는 시험을 몇 년 더 이어 간 경험을 근거로 듭니다.

언제 쓰나. 규칙이 글로 정리돼 있고 위반 여부를 설계 자료에서 확인할 수 있을 때 씁니다. 판단이 필요한 규칙은 AI 결과를 사람이 다시 봅니다.

Two-Pizza Team·Single System Owner: 작은 팀과 시스템별 책임자 한 명

무엇인가. 피자 두 판으로 끼니를 해결할 만큼 작은 팀(two-pizza team)으로 일하고, 시스템마다 책임자 한 명(single system owner)을 두는 조직 원칙입니다.

어떻게 작동하나. Curic은 Amazon에서 two-pizza 규칙을, Toyota에서 단일 시스템 책임자 방식을 가져왔습니다. 엔지니어끼리 서로 탓하지 못하게 하려는 것입니다. 책임자가 “내가 맡는다”고 말하는 구조라 AI가 낸 결과도 누가 받아 판단할지가 분명해집니다. Curic은 화면 5개와 약 350개 기능을 단 차를 비판했습니다. 회사 조사에서는 운전자 다수가 화면 버튼보다 기계식 레버를 더 좋아했다고 전합니다.

사람과 채용. Curic은 자기 일을 필요 없게 만드는 것이 경력에 가장 좋다고 말합니다. 그 자신도 여러 번 그렇게 했다고 합니다. 그러면서도 10월 파리 모터쇼에서 Bloomberg에 올해 유럽과 미국에서 엔지니어를 수백 명 더 뽑는다고 밝혔습니다.

통념과 다른 주장

기사에 나온 사례

사례	상황	한 일	결과	연결
핸즈프리 주행 시스템	비슷한 과제에 1년~18개월	AI 도구로 개발, 빌드마다 담당자가 직접 시험(주 최대 2회)	6주	Agentic Coding, Human-Owned Architecture
관측 개념 증명	agentic 도구 없이 약 6개월로 추정	agentic coding 도구 사용	1주	Agentic Coding
결함 수정	2~3주 소요	AI 도구 사용	2~3일	Agentic Coding
Ram 프런트 스플리터	전체 시뮬레이션 14~24시간	AI로 항력 추정	약 3분	AI Drag Estimate
설계 관행 점검	관행 약 1,000개	AI가 대조, 엔지니어는 규칙 자체를 질문	완전한 신뢰까지 약 4년 예상	Design Practice Check
요구사항·BOM 수집	지역별 시스템이 서로 연결되지 않음	AI로 요구사항과 부품 목록(BOM)을 끌어옴	효과 수치는 원문에서 밝히지 않음	Design Practice Check의 입력

기술 디테일: 실제로 돌릴 때 필요한 것

Agentic Coding을 결함 수정에 돌리려면 입력과 수정 범위를 먼저 고정합니다. agent에 결함 티켓, 재현 로그, 관련 모듈 코드, 기존 회귀 테스트를 줍니다. 순서는 재현 테스트를 먼저 쓰게 한 뒤 고치게 하는 것입니다. 수정 범위는 티켓에 적힌 모듈 디렉터리 안으로 묶습니다. 인터페이스 파일(헤더, 메시지 정의)을 바꾸려 하면 멈추고 사람에게 묻게 합니다. 같은 결함을 3회 독립 실행해 수정안이 서로 다르면 원인을 아직 못 잡은 신호로 보고 사람이 봅니다. 결과는 아래처럼 구조화해 받습니다.

{
  "defect_id": "SW-4821",
  "module": "adas/lane_keep",
  "repro_test": "test_lane_keep_curve_exit.py",
  "patch_files": ["adas/lane_keep/controller.c"],
  "touches_interface": false,
  "sil_regression": "pass",
  "runs_agreeing": 3,
  "owner_review": "pending"
}

검증은 SIL(software-in-the-loop, 소프트웨어만으로 돌리는 시험) 회귀를 먼저 통과시키고 HIL(hardware-in-the-loop, 실제 제어기를 물린 시험)로 넘깁니다. 마지막은 담당자의 실차 빌드 시험입니다. Saha처럼 빌드마다 사람이 직접 시험하는 단계를 파이프라인 끝에 고정해 둡니다. 위 필드값과 경로는 모두 가상 예시입니다.

Human-Owned Architecture를 저장소 규칙으로 만들려면 아키텍처 결정을 사람이 쓴 문서(ADR, architecture decision record)로 남기고, 모듈 경계와 인터페이스 파일에 CODEOWNERS(파일별 필수 승인자 지정)를 겁니다. agent가 낸 변경이 이 파일을 건드리면 시스템 책임자의 승인 없이는 병합되지 않습니다. agent 지시문에도 “인터페이스는 바꾸지 말고 제안만 하라”를 넣어 두 겹으로 막습니다. 엔지니어의 디버깅 감각을 지키려면 분기마다 AI 없이 결함 하나를 처음부터 추적하는 연습을 일정에 넣습니다.

AI Drag Estimate를 따라 만들려면 과거 전체 시뮬레이션 결과(형상 변수와 항력 계수 Cd의 쌍)로 빠른 추정 모델을 학습시킵니다. 흔히 대리 모델(surrogate model)이라고 부르는 방식이며, 기사는 Stellantis가 어떤 모델을 쓰는지 밝히지 않았습니다. 모델은 추정값과 함께 불확실성 범위를 내게 합니다. 새 형상이 학습 데이터 범위를 벗어나거나 불확실성이 커지면 결과를 쓰지 않고 전체 시뮬레이션으로 넘깁니다. 매달 풍동 결과와 추정값의 차이를 기록해 두고 차이가 커지면 재학습합니다. Lounsberry처럼 최근 20회 시험 데이터를 넣는 식으로 기준 기간을 정해 두면 비교가 쉬워집니다.

Design Practice Check를 돌리려면 먼저 관행 목록을 규칙 하나당 한 줄의 레코드로 바꿉니다. 필드는 rule_id, rule_text, applies_to(차종·부품군), evidence_needed(어느 도면·사양 항목을 봐야 하나), severity, owner입니다. AI는 규칙마다 pass·fail·needs_review 중 하나와 근거 위치(문서 이름·페이지·항목)를 내야 하며, 근거가 없으면 needs_review로 둡니다. temperature는 0으로 두고 같은 설계를 3회 점검해 결과가 갈리는 규칙은 사람에게 보냅니다. 요구사항과 BOM이 지역 시스템에 흩어져 있다면 Amanda French의 사례처럼 AI로 먼저 끌어모으되, 끌어온 항목마다 원천 시스템과 추출 날짜를 붙입니다. Roberts의 조사 도구 사례처럼 출처가 10~15개씩 나오면 확인한 출처만 남깁니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	맡는 일
CTO·엔지니어링 총괄	AI에 맡길 범위와 사람이 쥘 범위 승인, 채용 계획
시스템 책임자(시스템당 1명)	아키텍처 결정, AI 결과 최종 승인, 빌드 직접 시험
소프트웨어 리드	agent 파이프라인 운영, 재현 테스트 규칙, 결함 수정 지표
해석(CAE)·공력 엔지니어	과거 해석 데이터 정리, 추정 모델 검증, 풍동 대조
설계 품질·표준 담당	설계 관행 목록 구조화, 섀도 점검 판정
HR·교육	아키텍트 역할 정의, AI 없이 디버깅하는 연습 일정

준비물. 최근 6개월 결함 티켓과 티켓별 수정 소요 일수, 모듈 구성도와 인터페이스 목록, 과거 공력 해석 결과와 풍동 기록, 설계 관행 목록 원본, 시스템별 책임자 명단이 필요합니다. 결함 수정 기준선은 시작 전 4주 동안 실측해 잡습니다.

기간	할 일	산출물
1~2주	시스템 책임자 지정, 인터페이스 파일에 CODEOWNERS 적용, 관행 목록 레코드화	책임자 명단, 보호 파일 목록, 규칙 표
3~4주	결함 수정 agent와 설계 점검을 섀도 모드로 병행	사람 결과와의 일치율, 불일치 유형
5~6주	저위험 모듈 결함부터 agent 수정안 실제 병합	수정 소요 일수, 회귀 실패 건수
7~8주	확대 여부 판정, 공력 추정 모델 착수 결정	판정 보고서, 다음 범위

현업에 물을 것.

1. 지금 결함 하나를 고치는 데 평균 며칠이 걸리고, 누가 그 숫자를 재나요?
2. 시스템마다 “내가 맡는다”고 말할 책임자 한 명이 정해져 있나요?
3. 모듈 경계와 인터페이스는 문서로 남아 있나요, 사람 머릿속에만 있나요?
4. 설계 관행 가운데 설계 자료만 보고 지켰는지 알 수 있는 규칙은 몇 개인가요?
5. 풍동이나 실물 시험 슬롯은 하루 몇 대이고, 어떤 기준으로 순서를 정하나요?

진행 판정 기준(예시). 5~6주에 병합한 agent 수정안의 회귀 실패가 사람 수정안보다 많지 않아야 합니다. 결함 수정 소요 일수가 기준선보다 절반 이하로 줄어야 합니다. 설계 점검 섀도 결과는 사람 판정과 90% 이상 일치하고, 불일치는 모두 원인이 적혀 있어야 합니다. 셋 중 하나라도 못 채우면 범위를 넓히지 않고 2주를 더 봅니다. 신뢰 판단은 이 8주로 끝내지 않고, Rahm의 말처럼 제품 주기 단위로 다시 봅니다.

AX 적용 제언. 자동차·기계·전자처럼 안전 인증이 걸린 제품을 만드는 R&D 조직이라면 AI를 “어디까지 맡길지”보다 “어디부터 사람이 쥘지”를 먼저 정하는 편이 낫습니다. 순서는 시스템 책임자 지정, 인터페이스 보호, 결함 수정 agent, 설계 관행 점검, 해석 추정 모델입니다. 앞의 두 가지는 비용이 거의 들지 않고 이후 AI 결과를 누가 받을지를 정해 줍니다. 해석 추정 모델은 과거 해석 데이터가 정리된 조직만 착수합니다. 채용과 교육은 AI 도입과 같은 계획서에 넣어, 줄어든 수작업 시간을 아키텍처와 검증 역량으로 옮긴다고 밝혀 두는 것이 Stellantis 사례와 맞습니다.

원문 사례

항목	내용
기사	Fortune, Nick Lichtenberg(Business Editor), 2026.11.01 게재
장소	Chrysler Technology Center(1991년 헌정, 약 10억 달러, 연면적 540만 제곱피트), Stellantis 북미 엔지니어링 운영
회사 목표	차량 개발 4년 → 24개월(2027년 두 차종부터), 2030년 영업이익률 7%
실적	2026년 2분기 조정 영업이익률 1.8%, 2월 약 222억 유로(약 265억 달러) 상각
핸즈프리	Joydip Saha 팀, AI 도구로 6주(이전 1년~18개월), 빌드마다 직접 시험(주 최대 2회), AI 아키텍처 금지
소프트웨어	Ben Zawodni, ECU 수백 개를 STLA Brain으로 통합, 관측 PoC 1주(이전 추정 6개월), 결함 수정 2~3주 → 2~3일
플랫폼	Amanda French, STLA One(30개 이상 차종, 2035년까지 200만 대 이상 목표), AI로 요구사항·BOM 수집
공력·시험	Arturo Guzman, 항력 추정 약 3분(전체 시뮬레이션 14~24시간), 풍동 보통 하루 1대, 최근 20회 시험 데이터 활용, 시뮬레이터에서 데이터 채널 선별
설계 점검	Alison Rahm, 설계 관행 약 1,000개 AI 점검, 신뢰까지 약 4년(2030년 무렵)
조직	Ned Curic CETO, two-pizza 규칙(Amazon)과 단일 시스템 책임자(Toyota), 올해 엔지니어 수백 명 추가 채용
연구	Anne Laliron, 약 400명 기술 연구 조직, 매년 과제 약 10% 정리

핵심 개념

L2++

운전자가 감독하는 조건에서 손을 떼고 달릴 수 있는 운전 보조 단계. 기사 속 시스템은 출발지에서 목적지까지 감독형 핸즈프리 주행을 지향합니다.

STLA Brain

여러 전자 제어 장치를 하나의 중앙 컴퓨터로 합치는 Stellantis의 차량 소프트웨어 구조.

STLA One

소형 B세그먼트부터 중형 D세그먼트까지 덮는 Stellantis의 새 차량 플랫폼.

ECU

electronic control unit. 차량 기능 하나하나를 제어하는 전자 장치입니다.

front splitter

차량 앞 범퍼 아래에 붙여 공기 흐름을 나누는 부품. 항력과 다운포스에 영향을 줍니다.

kill switch

시험차에서 운전 보조 모듈을 즉시 끊는 장치. 업계 표준 안전 장비입니다.

BOM

bill of materials. 제품 하나에 들어가는 부품 목록입니다.

내 메모

TODO: 내 생각 추가

원문은 Fortune에 실린 Nick Lichtenberg 기자의 「‘The best thing that you can do for your career is to make yourself redundant’: Inside Stellantis’ AI push after the ‘starting gun went off’」(2026.11.01 게재)입니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례, 원문 사례 표는 기사에 실린 Stellantis 엔지니어·관리자의 설명을 AX Review가 다시 정리했습니다. 기술 디테일, 현업 실행 디테일, JSON 예시, 일정표, 판정 기준, 인포그래픽은 실제로 돌릴 때 필요한 내용을 새로 작성했으며 가상 예시는 그렇게 밝혔습니다. 기사는 사용한 AI 모델이나 벤더 이름을 밝히지 않았습니다. 전체 내용은 원문에서 볼 수 있습니다.