(이 기사는 원래Forbes.com에 게재되었습니다.)

차량 수명 주기의 모든 단계는 서로 다른 소프트웨어를 사용합니다. 개발팀은 시뮬레이션 플랫폼을 사용하고, 테스트팀은 데이터 로거와 검증 도구를 사용합니다. 제조팀은 자체 전용 시스템에서 최종 생산 라인 테스트를 수행하고, 애프터서비스팀은 또 다른 진단 도구를 사용합니다. 각 팀은 자신들의 특정 영역에 맞는 소프트웨어를 개별적으로 선택합니다.

문제는 각 단계 내부에서 일어나는 일이 아니라, 단계 사이와 단계 간에 발생하는 일입니다. 기존의 차량 수명 주기를 계주 경주로 생각해 보세요. 개발 단계에서 테스트 단계로, 테스트 단계에서 생산 단계로, 생산 단계에서 서비스 단계로 바통이 넘겨집니다. 바통이 넘겨질 때마다 지식을 재구성하거나 새로 구축해야 합니다. 종종 상황은 이보다 더 심각합니다. 각 단계의 도구는 서로 지식이나 경험을 전혀 공유하지 않기 때문입니다. 이로 인해 세 가지 비용이 발생하며, 이 비용은 바통이 넘겨질 때마다 점점 더 커집니다:

  1. 시스템 유지보수에 드는 부담은 체인에 도구가 하나씩 추가될 때마다 라이선스를 취득하고, 통합하고, 패치를 적용하며, 지원해야 할 시스템이 하나씩 늘어나기 때문에 기하급수적으로 증가합니다.
  2. 신입 사원과 다기능 팀 구성원들이 담당하는 각 단계마다 서로 다른 도구를 익혀야 하기 때문에 교육에 드는 비용이 증가하고 있다.
  3. 무엇보다 중요한 점은 지식의 연속성이 단절된다는 것입니다. 엔지니어가 기능을 개발할 당시 가지고 있던 맥락이, 6개월 후 현장에서 해당 문제를 해결하는 담당자에게 제대로 전달되지 않습니다.

이 모든 것은 어느 한 팀의 실패가 아닙니다. 이는 설계, 개발, 테스트, 생산, 지원을 하나의 연속적인 프로세스가 아닌 다섯 가지 별개의 워크플로로 취급함으로써 발생하는 구조적인 비용입니다. OEM 업체의 경우, 이러한 비용은 각 단계에서 추가되는 시간으로 나타납니다. 즉, 개발 속도가 느려지고, 테스트 속도가 느려지며, 결함 조사 속도도 느려지는 것은 물론, 중복된 업무와 팀 간에 전달되지 못해 상실되는 조직적 지식까지 초래합니다.

과거에 통일이 비현실적이었던 이유는 무엇이었을까

소프트웨어 역사의 대부분 동안, 이러한 도구들을 통합하는 것은 현실적으로 불가능했습니다. 소프트웨어는 특정 목적을 위해 제작됩니다. 테스트 도구는 시스템이 정의된 조건 하에서 예상대로 작동하는지 검증하기 위해 설계된 반면, 진단 도구는 문제가 발생했을 때 결함의 근본 원인을 정확히 찾아내기 위해 만들어졌습니다. 한 도구를 다른 도구의 역할에 맞게 개조하려면 코드의 상당 부분을 다시 작성해야 합니다. 엔지니어가 버튼 위치를 이동하거나 워크플로를 변경하고자 한다면, 이는 개발 주기를 거치는 일이 됩니다.

AI 이러한 상황은 점차 바뀌고 있는데, 이는 각 단계에 걸쳐 제공되는 에이전트 기반 AI 솔루션들이 점점 더 동일한 기반을 공유하고 있기 때문입니다. 테스트 도구의 기반이 되는 대규모 언어 모델(LLM)은 근본적으로 현장 진단 도구의 기반이 되는 모델과 동일합니다. 출시 전 검증 테스트 케이스를 분석하든, 판매 후 고객 문제를 해결하든, 추론을 수행하는 AI 는 동일합니다. 달라지는 것은 주변 상황뿐입니다.

조직은 도메인마다 별도의 시스템을 구축하는 대신, 개발, 테스트, 서비스 전반에 걸쳐 동일한 기반 인텔리전스를 확장함으로써 매번 처음부터 시작할 필요 없이 각 팀의 상황에 맞게 적용할 수 있습니다. 이것이 바로 Sonatus Fastlane™ Platform, 라이프사이클의 한 단계에서 다음 단계로 차량 데이터와 지식을 전달하는 폐쇄형 루프 AI 플랫폼입니다. 비록 대부분의 조직이 이를 실천하는 데 아직 초기 단계에 머물러 있기는 하지만, 이는 업계가 지금까지 가지고 있던 접근 방식과는 의미 있게 다른 출발점입니다.

더 힘든 일은 조직적인 측면이다

업계 전반에서 이러한 조짐이 이미 나타나고 있으며, 현재 조직들이 이러한 조치 중 한두 가지만 시행하고 있는 경우에도 마찬가지입니다:​

  • 현장 고장 사례를 무선 업데이트 주기로 보다 직접적으로 연계하고, 다음과 같은 차량 내 AI 를 활용하여 Sonatus Fastlane™ Edge 문제 발생부터 수정 사항 배포에 이르는 전체 과정을 원활하게 연결하는 데 기여합니다.
  • 서비스 데스크의 지식을 다음 연식 모델의 설계 및 테스트 기준으로 다시 반영하는 데, 바로 이 과정에서 Fastlane™ Insight 와 같은 도구가 진단 결과를 엔지니어링 팀을 위한 실행 가능한 통찰력으로 전환할 수 있는 부분입니다
  • 생산 현장의 이상 데이터를 활용하여 공급업체별 부품 품질을 비교한다.
  • AI 를 통해 제공되는 차량 상황 정보를 바탕으로, 개발 단계의 검증 데이터가 차량과 함께 전송되어 서비스 개시 첫날부터 진단 속도를 높일 수 있는지 여부를 탐구합니다. Sonatus Fastlane™ Collector에서 제공하는 xml-ph-0000@deepl.internal 기반 차량 컨텍스트를 활용하여, 개발 단계의 검증 데이터가 차량과 함께 전송되어 서비스 개

아직 어느 곳에서도 이 문제가 완전히 해결된 것은 아니지만, 도구들이 작업 인계 시마다 초기화되는 일이 없어지면 업계가 어떤 방향으로 나아갈지 시사해 줍니다. ​

또한 이는 단순히 소프트웨어를 교체하는 문제만은 아닙니다. 라이프사이클 단계 전반에 걸쳐 도구를 통합한다는 것은 대개 수년 동안 독립적으로 운영되어 온 팀들 간의 소유권, 예산, 프로세스를 통합하는 것을 의미합니다. 이는 기술적인 문제만큼이나 변화 관리 측면에서도 큰 과제를 야기합니다. 이를 단순히 도구 선택의 문제로만 여기는 조직은 조직적인 측면에서 훨씬 더 큰 어려움을 겪게 될 가능성이 높습니다.

통일 전략 수립

제 경험에 비추어 볼 때, 이러한 유형의 조직 변혁은 대개 몇 가지 핵심 원칙을 따르는 경향이 있습니다:

  • 통합을 전사적 전략으로 채택하십시오. 데이터, 지식 및 AI 의 통합은 특정 팀이 주도하는 프로젝트가 아니라 경영진의 지침으로 추진되어야 합니다.
  • 프로세스의 각 단계별로 주도자를 지정하십시오. 이 작업에는 개발, 테스트, 제조 및 서비스 전 분야에 걸쳐 지지자들이 참여해야 합니다.
  • 공유 컨텍스트에 포함되어야 할 요소를 파악하십시오. 모든 데이터, 지식 또는 산출물이 단계 간에 전달될 필요는 없지만 , 적절한 신호는 전달되어야 합니다.
  • 먼저 한두 가지 사용 사례에 대해 ‘ AI ’ 솔루션을 도입하십시오. 한 번에 전면적으로 도입하기보다는, 라이프사이클 전반에 걸쳐 양방향 지식 흐름을 구체적으로 활용하는 사례들을 우선적으로 선정하십시오.
  • 초기 구현을 출발점으로 삼으세요. 이를 통해 배우고 , 반복하며, 확장해 나가세요.

이 일이 왜 미룰 수 없는지

이러한 도구들을 해결해야 한다는 압박이 커지고 있습니다. 차량이 점점 더 소프트웨어 중심으로 변모하고 반복 개발 속도가 빨라짐에 따라, 사일로화된 도구의 비용은 점점 더 커지고 있습니다. 단계별로 추가되는 도구 하나하나가 조직의 노하우가 갇히는 또 다른 지점이 되며, 유지 관리해야 할 또 다른 통합 지점이 되고, 문제가 발견된 시점과 수정 사항이 적용되는 시점 사이에 또 다른 지연 요인이 됩니다.

이러한 격차를 해소하는 방법은 모든 단계에서 동일한 도구, 혹은 적어도 동일한 기반 기술을 활용하는 것입니다. 설계, 개발, 테스트, 운영 및 지원을 별개의 다섯 가지 기능이 아닌 하나의 연속적인 시스템으로 관리하는 기업은 구조적인 경쟁 우위를 확보할 수 있습니다: ​

  • 한 단계에서 얻은 통찰이 다음 단계로 더 빨리 전달되므로 문제를 조기에 파악할 수 있습니다.
  • 데이터와 맥락이 그대로 이어지므로, 실제 테스트 차량의 수와 중복되는 검증 작업을 줄일 수 있습니다.
  • 실제 신호와 구현된 솔루션 간의 간격을 좁히기.