S-CORE의 진짜 시험대: 누가 10~15년을 책임지는가

 

“안전과 보안에 대한 최종 책임은 누가 질까요? 10~15년 동안 아키텍처를 누가 유지·진화시킬까요?”

Automotive World 2026의 마지막 날, 도쿄 빅사이트에서 가장 높은 곳 컨퍼런스 타워. 
지난해 6월 S-CORE 출범부터 라스베이거스 CES에서의 두 번째 MoU, 그리고 이번 VDA·Qorix·Accenture 패널 토론까지 지켜봐 온 Eclipse SDV와 S-CORE의 전개는 단지 ‘오픈소스가 필요하다’는 선언을 넘어 양산의 순간에 점점 더 가까워지고 있었다.
SDV 시대의 공통 기반을 만들겠다는 말은 새롭지 않다. 하지만 그것이 양산 프로그램의 언어로 번역되는 순간 이야기는 달라진다. 제품 일정과 감사, 증빙과 책임 분리, 그리고 세대를 건너는 유지의 문제는 ‘좋은 코드’만으로는 해결되지 않는다.
Qorix의 캐롤린 파스티안(Caroline Pastian)과 헤어질 때, “당신이 왜 이곳에 왔는지 이제 이해했어요”라고 말했다. 
그녀가 던진 질문과 그에 대한 답은, S-CORE가 진짜 시험대에 올랐음을 보여줬다.
오픈소스 코어는 출발점일 수 있다. 그러나 OEM 프로그램이 요구하는 것은 출발점이 아니라 완주하는 방식이다. 그리고 그 완주의 방법은 결국 책임과 유지, 그리고 자동차급 실행(automotive-grade execution)으로 구성된다.


 
VDA의 마틴 슐라이허(Martin Schleicher)는 SDV를 고객 경험을 소프트웨어로 정의해 지속적으로 ‘좋은 경험’을 제공하기 위한 엔에이블러로 정리했다. 기능 추가만이 아니라 사이버보안 업데이트, 나아가 제3자 애플리케이션이 차에서 동작하는 생태계까지 차량의 라이프사이클 전체를 소프트웨어가 관통하는 시대라는 전제였다.
그가 강조한 것은 ‘오픈소스의 장점’ 자체가 아니라, 자동차에서 통하는 오픈소스의 작동 조건이었다. 핵심은 문서, 스펙이 아니라 코드가 단일 기준(single source of truth)이 되는 개발 방식이다. 전통적인 방식은 거대한 스펙을 만들고 구현한 뒤 통합 단계에서 문제를 뒤늦게 발견하지만, 코드 중심으로 전환하면 학습과 수정의 속도가 앞당겨지고, 검증과 품질의 부담도 더 이른 단계로 이동한다.
여기서 S-CORE가 밀어붙인 또 하나의 축은 툴 체인이었다. ‘docs-as-code’를 포함한 자동화된 워크플로로 스펙 - 코드 - 테스트를 연결하고, 추적성(Traceability)을 전제로 굴러가게 만든다. 기능안전성과 사이버보안 같은 요구는 ‘나중에 덧붙이는 옵션’이 아니라, 처음부터 개발 체계 안에 들어가 있다. 이런 조건들이 충족될 때, 오픈소스는 속도와 품질을 동시에 얻을 수 있다. 
“자동차 개발에서 실제 가장 큰 비중을 차지하는 것은 ‘통합과 검증’입니다. 원래는 함께 잘 동작해야 하는 것들이 새로운 시스템에서 함께 동작하게 만드는 데 엄청난 노력이 들어갑니다. 소스코드를 투명하게 볼 수 있고, 각 분야 전문가가 같은 공간에서 이슈를 확인하고 함께 해결할 수 있으면 문제를 더 빨리 찾고 빨리 고칠 수 있습니다. 품질과 속도를 동시에 끌어올릴 수 있습니다.” 슐라이허가 이렇게 말했다.
다만 여기부터 질문이 시작된다. 속도와 개방성이 올라갈수록, 그리고 더 많은 회사가 같은 코드를 만질수록, 양산 프로그램이 요구하는 책임 구조는 어디에 걸리는가?


 

 
“Qorix가 오픈소스 코어를 오토모티브 그레이드 소프트웨어 플랫폼으로 어떻게 바꾸는지를 말씀드리겠습니다. 오늘의 표현으로 말하자면, Qorix는 오픈소스 코어를 양산 가능한(automotive-grade) 소프트웨어 플랫폼으로 전환합니다. 우리는 이를 ‘Performance Stack’이라고 부릅니다.” 

캐롤린은 이렇게 발표를 시작했다. S-CORE를 ‘공통의 기술 언어, 투명성, 협업’의 기반으로 인정하면서도 OEM 관점에서 끝내 남는 질문을 숨기지 않았다. 
“안전과 사이버보안에 대해 최종 책임은 누가 집니까?” “10~15년 동안 아키텍처를 누가 유지·진화시키고, 여러 세대 차량에서 기능을 누가 보장합니까?”
오픈소스는 잠재력을 만든다. 그러나 그 잠재력만으로는 ‘자동차급 실행’이 되지 않는다. 즉, ‘코드가 있다’는 사실과 ‘프로그램에 넣어 양산한다’는 것 사이에는 산업이 요구하는 층위가 하나 더 있다. 이 층위는 기술 스펙이 아니라 책임과 증빙, 장기 유지의 운영으로 정의된다. 오픈소스가 기반을 제공한다면 자동차급 실행은 그 기반을 양산 프로그램의 언어로 고정시키는 작업이다.
캐롤린은 그 층을 Qorix의 역할로 말했다.
“Qorix는 S-CORE 생태계 안에서 기여자(Contributor)이자 유지관리자(Maintainer)로 참여하고, 생태계 밖에서는 배포자(Distributor) 역할을 수행합니다.”
기여자는 단순히 코드를 올리는 수준이 아니라, 기능과 모듈을 제공하고 문서와 API까지 포함해 지속 가능하게 플랫폼을 형성하는 역할이다. 유지관리자는 코어를 장기적으로 안정화하고 진화시키는 역할이다. 그리고 제품화 주체로서의 배포자는 커뮤니티에서 나온 코드를 ‘그대로’ 나르는 것이 아니라, OEM 프로그램이 요구하는 형태로 바꿔 제공한다.
“우리는 이것을 어떻게 할까요? 개발 워크플로는 내부 R&D 프로세스와 오픈소스 생태계를 결합합니다. 우리는 정기적으로 S-CORE의 최신 변경 사항을 리뷰하고 이를 내부 기능 개발과 결합하며, OEM의 요구사항을 커버하고, 타깃 하드웨어에 맞게 테일러링합니다. 그리고 필요한 경우, 변경 사항을 커뮤니티로 업스트림하기도 합니다. 최종적으로 우리는 생산 준비가 된(production-ready) 소프트웨어 솔루션을 제공합니다.”
그녀가 실제 강조한 단어는 ‘코드’가 아니라 안전 산출물(safety work products), 문서화된 증빙, 감사 대비(audit-ready) 아티팩트, 그리고 프로그램 지원이다. 이 구성요소가 OEM이 두려워하는 블로킹 리스크 - 통합 노력, SOP까지의 시간, 그리고 ‘깨졌을 때 누가 책임질지’를 줄이는 방식이다.
Q&A에서 나온 질문도 이를 한 번 더 고정했다. “다운로드해 수정하고 제품에 넣어도 되나?”란 질문에 패널은 Apache 2.0 라이선스를 근거로 가능하다고 답했다. 다만 곧바로 단서를 붙였다. 중요한 것은 ‘허용’의 문제가 아니라 ‘책임’의 문제라는 것. 허용은 라이선스가 만들지만, 책임과 증빙은 누군가의 역할로 만들어진다. 캐롤린의 질문은 바로 그 지점을 겨냥하고 있었다.


 

 
캐롤린은 기술로도 메시지를 고정했다. SDV로의 전환이 가속화될수록 HPC에서 미들웨어는 늘어나는 복잡성을 관리하는 결정적 엔에이블러가 된다. 그러나 기존의 proprietary 스택은 개방성, 확장성, 상호운용성에서 한계를 드러내기 쉽다. 반면 S-CORE 같은 공통 기반은 공유 플랫폼을 만들고, 엔지니어링 중복을 줄이며, 시간 단축을 가능하게 한다. 따라서 이제 질문은 ‘오픈소스가 필요한가’가 아니라, ‘오픈소스가 수십 년 동안 자동차 등급 기대를 어떻게 만족시키는가’로 바뀐다.
이에 대해 Qorix가 제시한 기술적 표현은 세 가지 축으로 정리된다.
첫째, SoC와 운영체제 환경 전반에서의 모듈러 아키텍처다. 현대 차량은 서로 다른 SoC와 OS를 사용하고 성능 프로파일도 다르다. 모듈러 아키텍처는 이런 변형(variation)들을 흡수하며 확장성을 만든다.
둘째, mixed criticality를 다루는 방식이다. 하나의 HPC에서 안전 크리티컬 워크로드와 비크리티컬 애플리케이션, 고처리량 데이터 처리가 동시에 돌아간다. 이때 핵심은 ‘같은 시스템에 같이 올린다’가 아니라, 같이 올려도 흔들리지 않게 만드는 규칙이다. 캐롤린이 강조한 표현은 deterministic runtime orchestration, 예측가능한 동작, 통제된 자원 사용, 그리고 안전 크리티컬 기능을 위한 간섭으로부터의 자유(freedom from interference)였다. 즉 안전이 필요한 기능이 다른 기능의 부하나 스케줄링 변화에 휘둘리지 않도록, 런타임 수준에서 ‘질서’를 강제하는 것이다.
셋째, 이것이 데모가 아니라 ‘양산 하드웨어에서의 일관성’으로 증명돼야 한다는 주장이다. 캐롤린은 이렇게 말했다.
“이것은 단지 비전이 아니라 우리가 여러 행사에서 이미 보여준 것입니다. 우리는 하나의 기반을 통해 여러 데모 시나리오를 제공합니다. 하나는 고성능 ECU 위에서 멀티 환경을 통합(consolidation)하는 시나리오입니다.”
이어 그녀는 같은 기반 위에서 ‘line/space SDV platform’과 ‘safety-informed SDV platform’에서의 mixed criticality 시나리오를 예로 들었다. 
“즉, 양산 하드웨어에서 예측 가능한 동작을 보여주고, 우리의 어댑티브/런타임/오케스트레이션 역량을 결합해, 여러 ECU 아키텍처에서 일관된 동작을 제공한다는 것입니다.”
결국 이 도착점은 다시 책임 구조로 돌아온다. mixed criticality를 다루는 능력은 기술이지만, 그 기술이 제품이 되는 조건은 장기 유지, 증빙, 감사 대응이라는 OEM 언어로 고정될 때 완성된다.


 

 
영상으로 참여한 Accenture의 크리스토프 혼(Christoph Horn)은 관점을 한 단계 위로 올렸다. 
그가 강조한 핵심은 ‘지금은 시스템이 아니라 플랫폼이 더 중요해지는 전환’이라는 진단이었다. 플랫폼은 한 차량에만 머무르지 않고 여러 세대와 라인업으로 퍼져 재사용된다. 그리고 OEM들의 아키텍처는 레이어와 API로 분리되면서 점점 닮아간다. 그렇다면 고객이 보지 않는 레이어, 고객 비가시 영역, 비차별 영역을 공유할 기회가 생긴다.
특히, 오픈소스를 성공시키려면 스택 자체만이 아니라 프로세스·방법론·툴을 함께 구축해야 한다. 과거의 표준화가 요구사항 문서와 합의 중심으로 느려졌다면, S-CORE는 처음부터 코드 중심으로 출발했고 여기에 툴링을 결합해 “진지하게 개발할 수 있는 기반”임을 증명한다. 다시 말해 플랫폼화는 코드만의 문제가 아니라 개발 체계의 문제이며, 이 체계가 갖춰질 때 공유는 비용 절감이 아니라 속도와 품질의 확률을 올리는 선택이 된다.


 
패널의 질의응답은 거창한 비전보다 “진짜 가져다 써도 되나?”라는 실무 질문이 많았다. 
결론은 단순했다. 저장소는 공개돼 있고 누구나 내려받아 확인할 수 있다. 라이선스는 Apache 2.0이라 상용 소프트웨어와 결합해 사용하는 것도 가능하다. 수정한 코드를 커뮤니티로 다시 업스트림하는 것도 가능하지만, 강제는 아니다.
다만 이 실무 포인트는 곧바로 핵심 논점으로 연결된다. 오픈소스를 ‘무료’로 오해하지만, 자동차에서는 그 오해가 성립하지 않는다. 자동차급 품질과 안전·보안 요구를 충족하려면 숙련된 엔지니어와 체계가 필요하다. 비용 구조는 라이선스에서 서비스나 오픈코어, 제품화 지원으로 이동할 수 있지만, “공짜로 굴러가는 플랫폼”은 존재하지 않는다. 그리고 바로 이 지점에서 캐롤린의 질문 “누가 책임지고, 누가 유지하는가”가 다시 돌아온다.


 

 

이번 패널을 한 문장으로 압축하면 이렇다. 오픈소스 코어는 출발점이고, OEM 프로그램은 책임 구조로 완성된다. VDA가 제시한 S-CORE의 작동 조건은 코드 중심과 툴체인, 그리고 글로벌 협업의 방식이었다. Accenture는 이를 시스템에서 플랫폼으로 이동하는 산업 전환의 프레임 속에 위치시켰다. 그러나 세션의 결정적인 문장은 Qorix에서 나왔다.
“누가 안전과 보안을 책임지는가?”
“누가 10~15년을 유지하는가?”
이 질문은 조달과 SOP를 좌우하는 프로그램 질문이다. Qorix는 기여자·유지관리자·배포자라는 3역 구조, 그리고 안전 산출물·감사 대응·프로그램 지원 같은 자동차급 아티팩트를 통해 그 질문에 답의 구조를 제시했다. 즉, 글로벌 SDV에서 S-CORE가 의미를 갖는 이유는 오픈소스를 둘러싼 논쟁이 이제 ‘필요성’에서 실행과 책임으로 이동했기 때문이다.
마틴은 발표 직후, S-CORE는 오픈소스이며 누구나 리뷰할 수 있고 QR 코드로 메인 페이지에 들어가 소스코드를 내려받아 직접 확인할 수 있다고 덧붙였다. “관심이 있으면 직접 보고 판단해 달라”는 말은, 이 이니셔티브가 지금 어디까지 왔는지를 가장 간단하게 보여주는 문장이기도 했다. 일정도 구체화됐다. 연말에는 버전 1.0이 계획돼 본격적인 개발이 가능해질 것으로 보고 있다. 타깃 SOP는 2030년이지만 일부 컴포넌트는 그 이전에도 시장에서 모습을 드러낼 수 있다. 결국 다음 장면은 S-CORE란 공통 코어 위에 Qorix 같은 상용 ‘자동차급’ 스택이 올라가며, 책임과 유지의 언어가 실제 공급망으로 흘러 들어가는 순간이다.


 

---

현장 Q&A: S-CORE를 ‘지금’ 만져보려는 사람을 위한 체크리스트

Q. 누구나 다운로드할 수 있나?
A. 가능하다. GitHub에 공개돼 있고, 회원 가입 없이도 접근 가능하다는 설명이 나왔다.
Q. 수정해서 내부 테스트용으로 써도 되나?
A. 가능하다. 다만 변경을 커뮤니티로 올릴지(업스트림)는 선택이다.
Q. 수정한 코드를 우리 제품에 넣는 것도 되나?
A. Apache 2.0 라이선스 기반에서 상용 소프트웨어와 결합이 가능하다는 답이 제시됐다.
Q. 오픈소스면 무료 아닌가?
A. 자동차급 품질·안전·보안 요구는 비용 구조가 필요하다. 모델은 라이선스에서 서비스/오픈코어/제품화로 이동할 수 있지만 ‘공짜 플랫폼’은 성립하기 어렵다는 취지였다.
Q. 프로그래밍 언어는 하나로 통일되나?
A. 다언어 공존. 일부 컴포넌트는 필요에 따라 Rust 같은 언어가 활용된다는 언급이 있었다.
Q. 레거시를 전부 대체하나?
A. 프로젝트 의사결정에 달려 있다. 대체가 아니라 표준화·상호운용성·중복 제거가 핵심이라는 방향이 제시됐다.

AEM(오토모티브일렉트로닉스매거진)

---