SDV, 개발은 이미 빠르다, 증명이 느릴 뿐

좌측부터 막스 파빙거 공동창업자 겸 CSO, 데이얼 보스테(Daniel Woste) 공동창업자 겸 CEO, 마르코 하인만(Marco Heinemann) 공동창업자 겸 CTO. 

자동차 소프트웨어 개발 현장에서 엔지니어들은 두 개의 세계 사이에 끼어 있다. Git과 IDE를 중심으로 하루에도 수십 번씩 코드를 커밋하는 세계와, DOORS·Polarion·수백 페이지의 문서와 감사 준비로 돌아가는 세계다. useblocks의 막스 파빙거는 이 간극을 도구의 문제가 아니라 패러다임의 문제로 읽는다. 엔지니어들은 이미 빠르게 움직이고 있다. 다만 그것이 안전하고 규정을 충족한다는 사실을 증명하는 구조가 과거에 머물러 있을 뿐이다.





먼저 useblocks의 출발점에 대해 묻고 싶습니다. 자동차 소프트웨어 개발은 오랫동안 DOORS, Polarion, Teamcenter, Codebeamer와 같은 도구를 중심으로 이뤄져 왔습니다. 그런데 useblocks는 그 환경에서 다소 다른 접근을 제안하는 것처럼 보입니다. 기존의 PLM/ALM 중심 개발 모델에서 가장 큰 문제나 한계는 무엇이라고 보셨습니까? 그리고 “이건 정말 바뀌어야 한다”라고 느끼게 된 결정적인 계기는 무엇이었습니까?  
Pabinger        useblocks는 매우 구체적인 문제에서 출발했습니다. 당시 저희는 BMW 프로젝트에서 순수 엔지니어들만으로 구성된 팀이었고, ISO 26262 환경 아래에서 개발을 진행하고 있었습니다. 이 말은 곧 추적성이 선택사항이 아니라 반드시 충족해야 하는 엄격한 요구사항이라는 뜻이었습니다. 우리는 언제 어떤 시점이든 작성된 코드가 어떤 요구사항으로부터 비롯되었는지, 그리고 그 요구사항이 다시 어떤 안전 목표와 연결되는지를 명확히 입증할 수 있어야 했습니다. 바로 거기서 저희는 기존의 툴체인이 개발자들의 실제 작업 방식과 맞지 않는다는 사실을 절감하게 됐습니다.
DOORS, Polarion, Codebeamer는 요구사항 엔지니어들에게는 훌륭한 도구입니다. 이들 도구는 요구사항이 중앙집중형 데이터베이스 안에 저장되고 변경 주기가 수개월 단위로 흘러가며 전담 툴 관리자(tool administrator)가 엔지니어와 시스템 사이를 중개하는 세계를 전제로 설계됐습니다. 하지만 오늘날 SDV 환경에서 우리가 마주하는 빠르게 움직이는 소프트웨어의 세계, 그리고 그 안에서 일하는 엔지니어들을 위해 설계된 도구는 아니었습니다. 저희가 함께 일했던 엔지니어들은 IDE와 Git 안에서 살아가는 사람들이었습니다. 그들은 하루에도 수십 번씩 코드를 커밋했습니다. 그런데 그들의 작업 방식과 컴플라이언스 도구가 요구하는 작업 방식 사이의 간극은 단순한 불편함이 아니라 구조적인 장애물이었습니다.
요구사항은 점점 코드와 멀어지기 시작했습니다. 버전 이력은 자신이 원래 통제해야 할 아티팩트들과 분리돼 있었습니다. 그리고 모든 것이 각각 따로 떨어진, 폐쇄적이고 독점적인 시스템 안에 존재하다 보니 현대적인 CI/CD 파이프라인이 요구하는 컴플라이언스 검증 자동화는 사실상 불가능했습니다. 감사(audit) 과정은 늘 고고학적 발굴 작업처럼 변해버렸습니다. 팀들은 몇 달 전에 이미 끝난 작업에 대해 추적성 근거를 다시 재구성하느라 몇 주씩 시간을 써야 했습니다. 통합도 없었고, 자동화도 없었으며, 모두가 함께 신뢰할 수 있는 단일한 진실의 원천도 없었습니다.
결정적인 깨달음은, 문제를 해결하는 방법이 더 나은 데이터베이스를 만드는 데 있지 않다는 사실을 보았을 때 찾아왔습니다. 필요한 것은 완전히 다른 패러다임이었습니다. 아티팩트를 코드 안으로 가져와야 했습니다. 요구사항, 명세서, 테스트 케이스, 아키텍처 의사결정을 구조화된 텍스트로 저장하고, 그것들을 Git 안에서 소스코드와 함께 버전 관리하며, 동일한 파이프라인을 통해 처리해야 했습니다. 추적성을 엔지니어링 워크플로 바깥에서 별도로 떠안아야 하는 행정적 부담으로 둘 것이 아니라, 엔지니어의 일하는 방식 속에서 자연스럽게 생성되는 결과물로 만들어야 했습니다.
그게 바로 Sphinx-Needs로 이어졌습니다. 그리고 저희가 지금까지 이 길을 계속 걸어올 수 있었던 이유는, GitHub Shift 행사에서 클레이 넬슨(Clay Nelson)이 “여러분은 이미 빠릅니다. 다만 그것을 입증하지 못할 뿐입니다”라고 아주 정확하게 표현한 한 문장과도 연결돼 있습니다. 이 산업에 부족한 것은 속도가 아닙니다. 부족한 것은 입증입니다. 엔지니어들은 이미 빠르게 움직이고 있습니다. 다만 자신들이 만든 것이 안전하고, 추적가능하며, 규정을 충족한다는 사실을 제대로 보여줄 수 없을 뿐입니다. 바로 그 간극을 메우는 것이 저희가 존재하는 이유입니다.





 
비슷한 질문이 될 것 같네요. 자동차 소프트웨어 개발 환경에서, 엔지니어들은 실제로 어디에 가장 많은 시간과 에너지를 쓰고 있습니까?
요구사항 관리, 인증, 규제 대응, 팀 간 협업 등 여러 요소가 얽혀 있습니다. 일반적인 엔지니어링 워크플로 안에서 어떤 작업이 가장 반복적으로 많은 시간을 소모한다고 보십니까?
Pabinger        저희가 현장에서 끊임없이 목격하는 패턴은 매우 분명합니다. 프로젝트 전체를 머릿속에 가장 잘 그리고 있는, 다시 말해 시스템의 전반적인 맥락과 연결 구조를 가장 깊이 이해하고 있는 가장 숙련된 엔지니어가 정작 시스템을 설계하는 데 시간을 쓰지 못하고 있다는 점입니다. 그들은 리뷰를 앞두고 수작업으로 추적성 그래프를 따라가고 있고, 감사를 앞두고는 컴플라이언스 근거를 다시 하나하나 재구성하고 있으며, 어떤 규제가 바뀌었을 때 그 변화가 어느 요구사항에 영향을 미치는지를 직접 파악하는 일에 매달리고 있습니다.
이것은 두 가지 측면에서 매우 큰 비용을 발생시킵니다. 
첫 번째는 누구나 쉽게 떠올릴 수 있는, 보다 직접적인 비용입니다. 새로운 기능을 만들어내지도 못하는 일에 시니어 엔지니어의 시간이 몇 주씩 투입된다는 점입니다. 가장 값비싼 인력이 제품을 앞으로 나아가게 하는 일보다 기존 시스템의 정당성과 완결성을 입증하는 작업에 붙잡혀 있는 것입니다. 그것만으로도 이미 큰 손실입니다.
하지만 더 위험한 것은 두 번째입니다. 시스템이 왜 완전한지, 왜 지금 이 상태가 성립하는지에 대한 지식이 시스템 안에 구조적으로 남아 있는 것이 아니라, 특정 개인의 머릿속에만 존재하게 된다는 점입니다. 다시 말해, 완결성에 대한 이해와 설명 가능성이 조직의 자산으로 축적되는 것이 아니라 개인에게 귀속돼 버립니다. 그리고 그 사람이 다른 프로젝트로 이동하는 순간, 팀은 같은 일을 다시 해야 합니다. 다만 이번에는 더 느리게, 더 낮은 확신을 가진 상태에서 다시 시작하게 됩니다.
그 밖의 상당한 오버헤드는 결국 조율에서 발생합니다. 안전 팀은 안전 팀의 도구 안에서 일하고, 사이버보안 팀은 또 다른 도구 안에서 일하며, 개발 팀 역시 자신들만의 별도 환경에서 움직입니다. 그런데 이들 사이에는 공통으로 바라볼 수 있는 단일한 표현 체계가 없습니다. 그래서 한 영역에서 어떤 변경이 발생하면, 그 변화가 누구에게 어떤 영향을 주는지를 확인하기 위해 관련 팀들이 다시 수작업 회의를 열어야 합니다. 우선 영향을 받는 사람이 누구인지부터 확인해야 하고, 각 팀이 자기 영역의 정보를 따로 끌고 와서 맞춰봐야 합니다. 문제는 엔지니어들이 느리다는 데 있지 않습니다. 문제는 도구와 구조가 그들로 하여금 그렇게 일할 수밖에 없도록 만든다는 데 있습니다.


안전, 환경 규제, 전반적인 컴플라이언스를 포함해, 자동차 산업에서는 특히 추적성이 매우 중요하게 강조됩니다. 자동차 개발에서는 요구사항 → 설계 → 코드 → 테스트 → 인증으로 이어지는 추적성이 강하게 요구됩니다. 다른 소프트웨어 산업에 비해 자동차 분야에서 이렇게까지 광범위한 추적성이 요구되는 이유는 무엇이라고 보십니까? 또 안전, 책임, 규제 중에서 어떤 요소가 가장 큰 역할을 한다고 생각하십니까? 그리고 이러한 요구사항은 실제 개발 환경과 개발 방식에 어떤 영향을 미치고 있습니까?  
Pabinger        추적성은 자동차 산업에만 국한된 개념이 아닙니다. 소프트웨어가 사람의 생명에 직접적인 영향을 미칠 수 있는 모든 영역, 예를 들어 항공우주, 의료, 로보틱스, 그리고 자동차와 같은 분야에서는 공통적으로 중요하게 요구됩니다. 그 근본적인 논리는 동일합니다. 실패가 치명적인 결과로 이어질 수 있는 환경에서는 언제 어떤 시점이든 자신이 위험을 제대로 이해하고 있었는지, 그리고 그 위험을 줄이기 위해 가능한 모든 합리적인 조치를 취했는지를 입증할 수 있어야 합니다.
세 가지 요소 가운데 가장 근본적인 동인은 안전이라고 생각합니다. 책임과 규제는 사회가 안전 기준을 강제하기 위해 사용하는 수단입니다. 즉, 그것들은 원인이 아니라 결과에 가깝습니다. 만약 추적성을 단순한 컴플라이언스 활동으로 접근하게 되면, 감사를 통과하기 위한 문서는 만들어질 수 있지만, 실제로 시스템을 더 안전하게 만드는 데에는 기여하지 못하게 됩니다. 반대로, 출발점을 진정한 안전에 대한 의지로 설정하게 되면, 추적성은 외부에 무언가를 증명하기 위한 도구가 아니라, 스스로 자신의 시스템을 이해하기 위한 도구로 기능하게 됩니다.
제가 흥미롭게 생각하는 지점은, “과연 그것을 입증할 수 있는가?”란 질문이 사실 보안, 안전, 품질이라는 서로 다른 영역 모두에서 동일하게 적용된다는 점입니다. 보안에서는 “공격 가능한 경로가 존재하지 않는다는 것을 입증할 수 있는가?”란 질문으로 나타나고, 안전에서는 “모든 요구사항이 빠짐없이 반영되었음을 입증할 수 있는가?”란 질문으로 나타납니다. 그리고 품질에서는 “개발 프로세스가 완전하다는 것을 입증할 수 있는가?”란 질문으로 이어집니다. 세 개의 영역이지만, 결국 하나의 질문이 됩니다.
문제는 대부분의 경우, 이 질문에 대해 “수작업으로 다시 검증하지 않고서는 입증할 수 없다”는 답이 나온다는 점입니다. 시스템이 왜 완전한지에 대한 지식이 시스템 자체에 구조적으로 남아 있는 것이 아니라, 특정 개인의 머릿속에 존재하고 있기 때문입니다. 보안 분야에서는 이를 단일 실패 지점(single point of failure)이라고 부릅니다. 이런 인식이 저희가 제품을 설계하는 모든 방향에 영향을 주었습니다.
useblocks의 목표는 바로 이 간극을 줄이는 데 있습니다. 안전이 중요한 개발 환경에서 발생하는 행정적 부담을 줄이면서도, 그 엄격함 자체는 결코 낮추지 않는 것입니다. 다시 말해, 컴플라이언스를 별도로 덧붙여야 하는 부가적인 활동이 아니라, 좋은 엔지니어링을 수행했을 때 자연스럽게 따라오는 결과로 만드는 것이 저희가 지향하는 방향입니다.


 
ADAS와 자율주행 기술이 발전하면서 자동차 소프트웨어는 점점 더 복잡해지고 있습니다. 이런 복잡성과 함께 요구사항 관리, 테스트, 인증, 검증, 업데이트, 추적성과 같은 프로세스는 더욱 중요해지는 것처럼 보입니다. ADAS와 자율주행 기술은 자동차 소프트웨어 개발 방식에 어떤 새로운 기준이나 기대를 가져오고 있다고 보십니까?
Pabinger        저에게 진정한 전환점은 ADAS 자체라기보다 SDV였습니다. 단순히 복잡성이 더 높아졌다는 차원을 넘어, 누가 누구와 협업해야 하는지, 그리고 그 협업이 어떤 속도로 이뤄져야 하는지를 근본적으로 바꾸어 놓았기 때문입니다. 전통적인 차량 개발 프로그램은 비교적 더 분리돼 있었고, 각 영역은 자신만의 툴체인과 릴리스 주기를 중심으로 움직였습니다. 하지만 SDV는 그 구조를 무너뜨립니다. 이제 하나의 소프트웨어 업데이트가 동시에 여러 도메인에 영향을 미치게 됐습니다. 여기에 OTA까지 더해지면서, 이미 시장에 나가 있는 차량조차 더 이상 고정된 시스템으로 남아 있지 않게 됐습니다.
이 변화가 가져온 결과는 분명합니다. 데이터 사일로는 이제 생산성과 파트너 간 협업을 갉아먹는 핵심 요인이 되고 있습니다. 요구사항 팀, 테스트 팀, 개발 팀이 각각 서로 다른 도구 안에서 일하고 있고, 시스템을 함께 바라볼 수 있는 공통의 표현 체계가 없다면, 문제는 컴퓨팅 파워에서도, 개발자의 역량에서도 생기지 않습니다. 진짜 문제는 조율 그 자체에서 발생합니다. 누가 무엇을 바꿨는지, 어떤 영향이 어디까지 이어지는지, 그리고 무엇을 다시 검증해야 하는지를 확인하는 과정이 개발의 속도를 결정하게 되는 것입니다.
그리고 ADAS는 여기에 완전히 새로운 종류의 요구사항까지 추가합니다. 확률적으로 나타나는 동작, 시나리오 커버리지, AI 모델 거버넌스와 같은 문제들입니다. 이런 요소들은 전통적인 V-모델 구조가 애초에 다루도록 설계된 대상이 아니었습니다. 다시 말해, 자동차 소프트웨어 개발은 단순히 더 복잡해진 것이 아니라, 기존 개발 구조가 전제하고 있던 질서 자체를 넘어서는 새로운 성격의 문제를 떠안게 된 것입니다.


 
제가 이해한 바로는, useblocks는 요구사항, 문서, 테스트, 코드 사이의 연결을 더 명확하게 만들고, 개발 과정을 보다 투명하게 만드는 것을 목표로 하는 것 같습니다. 비전문가의 시각에서 궁금한 점이 있습니다. useblocks는 실제 개발 환경에서 이런 문제를 어떻게 해결합니까? 예를 들어, useblocks의 접근 방식은 기존 도구를 대체하려는 것입니까, 아니면 서로 연결하려는 것입니까? 혹은 Git 기반 엔지니어링 모델과 같은 새로운 워크플로를 도입하려는 것입니까?
Pabinger        핵심 개념은 저희가 X-as-Code라고 부르는 방식입니다. 다시 말해, 요구사항, 명세서, 테스트 케이스, 아키텍처 의사결정과 같은 모든 엔지니어링 아티팩트를 소스코드와 나란히 두고, 구조화된 텍스트 형태로 저장하며, Git 안에서 버전 관리하고, 코드와 동일한 CI/CD 파이프라인을 통해 처리하는 것입니다. 텍스트 중심이어야 하고, 스키마를 인식할 수 있어야 하며, 버전이 관리돼야 하고, 누구의 작업인지 귀속이 가능해야 합니다. 그렇게 되면 하나의 아티팩트는 단지 무엇이 만들어졌는지만 담는 것이 아니라, 왜 그것이 존재하는지, 어떤 요구사항을 충족하는지, 그리고 어떤 규제와 연결되는지까지 함께 담게 됩니다.
실제 개발 환경에서는 엔지니어가 IDE를 열었을 때, 자신이 작업하고 있는 기능과 연결된 요구사항을 바로 확인할 수 있습니다. 그리고 변경을 수행한 뒤 커밋을 하면, 그 과정의 일부로 추적성이 자동으로 갱신됩니다. 별도로 로그인해야 하는 다른 도구가 있는 것도 아니고, 수동으로 동기화하는 단계가 따로 필요한 것도 아닙니다.
저희는 DOORS나 Polarion을 대체하려는 것이 아닙니다. 오히려 그것들과 통합하려고 합니다. 다만 주된 작업 공간, 즉 엔지니어가 실제로 일하는 중심 환경을 개발자 자신의 작업 환경 안으로 옮기려는 것입니다. 그렇게 되면 컴플라이언스는 코드를 작성한 뒤 따로 덧붙여야 하는 행정적 절차가 아니라, 코드를 작성하는 행위 자체에서 자연스럽게 따라오는 부산물이 됩니다. 저희의 오픈소스 기반인 Sphinx-Needs는 현재 월 30만 회가 넘는 다운로드 수를 기록하고 있습니다. 이런 접근 방식이 실제로 작동한다는 점은 이미 커뮤니티 차원에서 충분히 검증되고 있다고 생각합니다.


자동차 산업은 오랫동안 문서 중심의 개발 모델에 의존해 왔지만, 보다 넓은 소프트웨어 산업은 Git과 DevOps 기반 워크플로로 이동해 왔습니다. SDV가 부상하면서 자동차 산업에서도 이런 접근 방식에 대한 관심이 커지고 있는 것 같습니다. 자동차 개발 역시 결국 DevOps 스타일의 워크플로에 더 가까워질 것이라고 보십니까? 아니면 안전 규제와 인증 요구사항 때문에 자동차 산업은 본질적으로 다른 개발 모델을 계속 유지하게 될 것이라고 보십니까?
Pabinger        방향은 이미 정해져 있다고 생각합니다. 이제 남아 있는 질문은 그 전환에 얼마나 시간이 걸리느냐일 뿐입니다. 오늘날의 차량은 더 이상 단순한 기계 제품이 아니라 소프트웨어 플랫폼이 되고 있습니다. 그리고 그 플랫폼을 만드는 엔지니어들은 Git이 기본값이고, CI/CD가 출발선인 산업에서 온 사람들입니다.
이 전환을 훨씬 더 강하게 가속하는 또 하나의 힘이 있습니다. 바로 AI입니다. 그리고 많은 사람들이 놓치고 있는 중요한 지점도 여기에 있습니다. 모든 엔지니어링 아티팩트를 구조화되고 추적가능한 텍스트 형태로 저장소 안에 함께 두는 것은 단지 좋은 개발 방식이라는 수준에 그치지 않습니다. 그것은 AI 에이전트를 위한 거의 이상적인 인프라가 됩니다. 요구사항, 명세서, 테스트 케이스가 기계가 읽을 수 있는 형태로 존재하고 서로 연결돼 있다면, 특정 코드 조각이 왜 존재하는지, 어떤 규제와 연결되는지, 그리고 어떤 제약조건을 만족해야 하는지를 포함한 전체 맥락을 에이전트에게 제공할 수 있습니다. 바로 그런 방식이어야만 안전이 중요한 환경에서도 실제적인 가드레일을 갖춘 상태로 AI를 도입할 수 있습니다. 단순히 워드 문서 위에 채팅 인터페이스를 덧붙이는 방식이 아니라, 아티팩트 그래프 자체를 에이전트가 추론하는 기반으로 만드는 것이 핵심입니다.
이것이 바로 useblocks가 지향하며 구축하고 있는 방향입니다. 그리고 지금 이 흐름은 실제로 힘을 받고 있습니다. Microsoft 및 GitHub와의 협업은 이 분야에 엄청난 가시성을 가져오고 있습니다. 이런 조직들이 텍스트 기반이면서도 추적가능한 엔지니어링을 AI 보조 개발의 올바른 기반으로 지목하고 있다는 사실은, 저희가 가고 있는 방향이 맞다는 점을 강하게 뒷받침해 줍니다. 동시에, 이로 인해 업계 전반의 도입 속도 역시 과거 같았으면 몇 년이 더 걸렸을 변화를 훨씬 빠르게 앞당기고 있다고 생각합니다.




4월, useblocks는 최근 사용자 그룹 미팅에서 50명의 엔지니어와 함께 2시간 안에 Park Assist 시스템을 구현하는 실험을 진행했다. Sphinx-Needs, ubCode, Pharaoh, GitHub Copilot, 실제 하드웨어를 결합한 이 세션은 구조화된 명세와 추적성이 AI 기반 안전중요 개발의 핵심 인프라가 될 수 있음을 보여줬다.


 
useblocks는 Eclipse SDV 커뮤니티에서도 활발하게 활동하고 있습니다. 현재 어떤 프로젝트들에 참여하고 계시며, 그 안에서 어떤 목표를 갖고 계십니까? 또 Eclipse SDV 생태계 안에서 useblocks는 어떤 역할을 맡게 될 것이라고 보십니까? 참여자들 사이에서는 어떤 공감대나 공동의 비전이 형성되고 있습니까?
Pabinger        현재 저희는 S-CORE 프로젝트에 적극적으로 참여하고 있습니다. 하지만 저희의 활동 범위는 거기에만 머물지 않습니다. Eclipse SDV 안에 있는 오픈소스 프로젝트들, 예를 들어 OpenBSW와 같은 프로젝트들에서도 이미 저희 툴체인이 실제로 사용되고 있습니다.
저희는 useblocks를 SDV 툴체인 안에서 추적성과 컴플라이언스를 담당하는 레이어로 보고 있습니다. S-CORE와 같은 공유 미들웨어 플랫폼이 점점 성숙해질수록 다수의 기여자가 함께 참여하는 코드베이스 전반에서 요구사항을 어떻게 관리할 것인지, 안전 속성을 어떻게 검증할 것인지, 그리고 감사를 위한 근거를 어떻게 만들어낼 것인지가 점점 더 핵심적인 과제가 됩니다. 바로 이 부분이 저희가 집중하고 있는 문제 영역입니다. 저희에게 특히 중요한 가치 가운데 하나는, 이런 활동을 통해 가시성이 생긴다는 점입니다. 사람들이 앞으로 툴체인이 어떤 방향으로 진화하고 있는지를 바라볼 때, 추적성과 컴플라이언스를 부가적인 요소가 아니라 기반 레이어로 인식하게 되고, 그 자리에 저희의 솔루션이 놓여 있다는 점을 자연스럽게 보게 된다는 의미입니다.
커뮤니티 안에서 점점 더 분명해지고 있는 공통된 확신은, 차별화 요소가 아닌 인프라 영역에서는 경쟁 이전의 협력, 즉 pre-competitive collaboration이 모두에게 순이익이라는 점입니다. 어떤 OEM도 독자적인 요구사항 포맷을 갖고 있다고 해서 경쟁 우위를 얻지는 못합니다. 진정한 차별화는 사용자 경험의 층위에서 발생합니다. 반면, 개방된 추적성 표준은 생태계 전체를 더 빠르게 만들고, 동시에 더 안전하게 만듭니다.


자동차 소프트웨어 툴링 시장에는 이미 많은 큰 기업들이 존재합니다. 그럼에도 불구하고 useblocks는 상당히 독특하고 특화된 접근을 하고 있는 것처럼 보입니다. useblocks를 기존 플레이어들과 가장 강하게 구분 짓는 요소는 무엇이라고 보십니까? 또 이런 접근을 하는 기업이 지금까지 상대적으로 드물었던 이유는 무엇이라고 생각하십니까? 
Pabinger        기존의 플레이어들은 이미 충분히 성숙하고, 높은 기능성을 갖춘 도구들을 만들어 왔으며, 실제 산업의 요구를 충실히 충족해 왔습니다. 차이는 기능 자체에 있다기보다, 출발점에 있다고 생각합니다. 기존 도구들은 중앙집중형 데이터베이스와 전담 툴 관리자라는 구조를 중심으로 설계됐습니다. 반면 저희의 출발점은 엔지니어였습니다. 엔지니어가 실제로 일하는 IDE, Git 기반 워크플로, 그리고 CI/CD 파이프라인이 저희 설계의 중심이었습니다.
이런 개발자 중심 철학은 모든 것에 영향을 미칩니다. 컴플라이언스가 엔지니어가 실제로 일하는 환경 안에 존재하게 되면, 엔지니어는 그것을 자연스럽게 사용하게 됩니다. 그렇게 되면 데이터는 항상 최신 상태를 유지하게 되고, 추적성 역시 감사 직전에 사후적으로 끼워 맞춘 결과물이 아니라, 실제 개발 과정에서 자연스럽게 형성된 것이 됩니다. 반복하지만, 저희의 오픈소스 기반인 Sphinx-Needs가 월 30만 회 이상의 다운로드를 기록하고 있다는 사실은 이런 접근 방식이 커뮤니티 전반에 걸쳐 공감을 얻고 있다는 것을 보여준다고 생각합니다.
두 번째로 중요한 차별화 요소는 AI 대응력입니다. 저희의 아티팩트는 구조화돼 있고, 기계가 읽을 수 있는 텍스트 형태로 Git 안에서 버전 관리됩니다. 이러한 구조는 AI 기반 워크플로와 매우 잘 맞습니다. 이 환경에서 동작하는 에이전트는 하나의 요구사항을 읽고, 그것이 어떤 규제와 연결돼 있는지를 따라가며, 관련 명세와 테스트를 확인한 뒤, 전체 맥락을 이해한 상태에서 변경안을 제안할 수 있습니다. 그리고 이 모든 과정이 엔지니어가 이미 사용하고 있는 동일한 워크플로 안에서 이뤄집니다. 이런 방식의 안전하고 맥락을 이해하는 AI 지원은 저희가 처음부터 툴체인을 설계해 온 방향과 자연스럽게 맞아떨어집니다.
이런 접근을 가진 기업이 지금까지 드물었던 이유에 대해서는 현실적인 이유도 있습니다. 소규모 기업이 자동차 산업의 조달 구조 안으로 진입하는 것은 실제로 매우 어렵습니다. 의사결정 주기는 길고, 요구되는 인증과 검증 수준은 매우 높으며, 기존 공급업체들과의 관계 역시 깊게 자리 잡고 있습니다. 저희 역시 그 과정을 직접 경험해 왔습니다.


 


최근 많은 자동차 기업들이 소프트웨어 개발 속도를 높이려 하고 있습니다. 동시에 추적성, 인증, 규제 대응과 같은 요구사항은 개발 속도를 늦추는 요소처럼 보이기도 합니다. 더 빠른 개발과 엄격한 규제 준수를 동시에 달성하는 것이 가능하다고 보십니까? 그리고 이 두 가지를 균형 있게 달성하기 위해 업계가 가장 먼저 바꿔야 할 것은 무엇이라고 생각하십니까?
Pabinger        그렇습니다. 그리고 그 시급성은 매우 현실적입니다. 기존 자동차 산업의 플레이어들은, 전통적인 업계가 한 번도 경험해 보지 못한 속도로 소프트웨어를 출시하고 있는 중국 경쟁사들의 개발 속도에 맞춰야 한다는 압박을 받고 있습니다. 그렇다고 해서 해법이 안전 기준을 낮추는 데 있을 수는 없습니다. 해법은 컴플라이언스를 더 빠르게 만드는 데 있어야 합니다. 그리고 그 출발점은, 이 산업이 속도의 문제를 안고 있는 것이 아니라 입증의 문제를 안고 있다는 사실을 인식하는 것입니다. 팀들은 이미 빠르게 움직이고 있습니다. 다만 자신들이 만든 것이 안전하고 규정을 준수하고 있다는 점을 지속적이고 자동화된 방식으로 입증하지 못하고 있을 뿐입니다.
네, 두 가지를 동시에 달성하는 것은 가능하다고 생각합니다. 추적성이 지속적으로 유지되는 구조라면, 다시 말해 모든 커밋이 아티팩트 간 연결을 자동으로 갱신하고, CI/CD 파이프라인이 커버리지 점검을 강제하며, 컴플라이언스 상태가 실시간으로 가시화되는 환경이라면, 감사 직전에 벌어지는 급박한 대응은 사라지게 됩니다. 몇 주에 걸쳐 근거를 다시 재구성하는 대신, 엔지니어링 워크플로의 자연스러운 산출물로서 지속적으로 갱신되는 증거 체계를 갖게 되는 것입니다. 그렇게 되면 속도와 엄격함은 더 이상 서로 충돌하는 관계가 아니라, 동일한 기반 위에 놓인 두 가지 결과가 됩니다.
업계가 먼저 바꿔야 하는 것은 툴링, 그리고 그 변화를 실제로 수용하겠다는 의지입니다. 이는 컴플라이언스를 개발 사이클의 마지막 단계에서 덧붙이는 활동으로 여기는 방식에서 벗어나, 추적성이 수작업이 아니라 구조적으로 내장된 툴체인에 투자해야 한다는 뜻입니다. 그러기 위해서는 보다 과감한 결정이 필요합니다. 아티팩트를 어떻게 저장할 것인지, 파이프라인을 어떤 방식으로 구성할 것인지, 그리고 컴플라이언스 근거를 어떻게 생성할 것인지를 다시 생각해야 합니다. 이를 가능하게 하는 기술은 이미 존재합니다. 더 어려운 부분은, 그 기술을 실제로 활용하는 방향으로 조직이 스스로를 전환하는 일이라고 생각합니다.


한국에는 현대자동차그룹, 삼성, LG, 그리고 많은 티어 1 공급업체를 포함한 강력한 자동차 산업 생태계가 있습니다. useblocks는 한국 자동차 산업을 어떻게 보고 있습니까?  또 한국 기업들이 소프트웨어 개발과 전환에 접근하는 방식에 대해서는 어떤 인상을 갖고 계십니까? 한국 기업들과의 협업 가능성도 보고 계십니까?  
Pabinger        한국의 자동차 산업 생태계는 세계적으로도 가장 인상적인 수준에 속한다고 생각합니다. 완성차 업체들의 높은 의지와 야심, 반도체 분야에서의 리더십, 소비자 전자 분야에서 축적된 전문성, 그리고 티어 1 공급업체들이 보여주는 정밀한 제조 역량이 결합돼 있다는 점은 전 세계적으로도 소수의 국가만이 갖고 있는 매우 독특한 강점입니다.
저희가 관찰하는 바에 따르면, 한국 기업들은 SDV 전환을 주도할 수 있을 만큼의 시급성과 기술적 정교함을 모두 갖추고 있습니다. 물론 이들이 마주하고 있는 과제는 글로벌 시장의 다른 기업들과 크게 다르지 않습니다. 전통적인 자동차 엔지니어링 문화와 현대적인 소프트웨어 개발 방식을 어떻게 연결할 것인지, 다수의 공급업체가 얽혀 있는 복잡성을 어떻게 관리할 것인지, 그리고 SDV의 빠른 전달 속도에 맞춰 컴플라이언스 근거를 어떻게 만들어낼 것인지가 핵심 과제로 남아 있습니다. 한국의 엔지니어링 팀들은 매우 체계적이고 품질 중심적인 성향을 가지고 있는데, 바로 그런 환경에서 저희의 툴링이 가장 큰 가치를 만들어낼 수 있다고 생각합니다. 저희는 한국 기업들과 보다 깊이 있는 협업을 하는 데 매우 열려 있습니다.

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

---