차량용 (Infotainment) 소프트웨어 개발 과정 중 통합 1부

지금 Mercedes-Benz 본사가 있는 Sindelfingen에 이틀 동한 UI 통합 관련 워크샾을 하러 가는 길이다. 새벽같이 일어나 공항에서 대기하는 도중 간단히 정리도 할 겸 블로그를 열었다.

 

 

차량용 인포테인먼트 소프트웨어 통합은 정말로 복잡하고 어렵다. 앞의 글에서 테스트에 대해서 이야기 했다시피 여러가지 장벽이 많다. 통합과정 중 테스트는 가장 중요한 핵심 요소 중에 하나이다. 테스트 부분은 빙산의 일각일 뿐이다.

 

회사 전체의 화두 중 하나도 소프트웨어 통합이다. 통합 관련 VSM (Value Stream Mapping) 워크샾도 여러번 진행을 하면서 전체 개발 과정을 펼쳐놓고 어느 부분이 bottleneck이고 어떻게 하면 조금 더 효율적으로 해결할 수 있는 지 등등을 이야기 했다. 여러번 진행했다는 이야기는 그만큼 복잡하고 다루어야 할 이야기 많다는 의미이다.

 

그러면 왜이렇게 복잡하고 어려울까? 이전에 개발했던 단일 임베디드 기기 (예, TV, Wearable) 등은 나름 어려웠지만 지금 인포테인먼트에 비하면 아무것도 아니다. 다음 같은 이유가 있을 것 같다.

 

• 소프트웨어 복잡도: 하드웨어 아키텍처 구조 집중화로 인해 하이퍼바이저 위에 여러개의 Guest OS를 올려 서로간의 의존성 문제
• 프로세스 복잡도: 통합 프로세스가 복잡하고 자주 변하기 때문에 개발자 또는 리뷰어가 항상 최신을 따라가지 못함
• 컴포넌트 복잡도
  • 단일 Linux Guest OS에서도 수백개, 수천개의 컴포넌트가 존재
  • 레거시를 많이 받아들여 많은 소프트웨어 아키텍처 부채
• 수천명의 개발자
  • 하나의 프로젝트에 수천명의 개발자가 있다보니 의사소통 문제
  • 새로 배워야하는 프로세스 문제가 발생함
  • 개발자의 성숙도 (정말 심한 경우 git에 대한 이해를 시켜야함)
  • 리뷰어에 리뷰가 집중되고 가끔 사소한 것을 리뷰하면 block한다고 비난 받음
• 테스트 복잡도: 앞에서 이야기한 테스트 장비 문제, 테스트 케이스의 표준화 부재
• 오픈화: 모든 개발 플랫폼에 쉽게 접근 가능하고 새로 편하게 만들 수 있는 권한을 팀에 주어져 전체 팀에 문제가 발생시키는 작업이 간혹 일어남
• 인프라 성숙도: 인프라 뿐 아니라 인프라를 실제 관리하는 관리자의 성숙도 부재

 

간단히 생각나는 것만 적어봤는데도 저만큼이다. 실제 요즘은 양산 막바지라 더 전쟁터같고 다양한 큰 업그레이드가 걸려있어 더 어려운 상황이다. 그래서 여러가지 아이디어를 하나씩 적용시켜 개선 중이고 이와 관련하여 하위 서브 시스템으로 나누어 통합을 하자는 아이디어 등 다양한 것을 구상중에 있다. 

 

지금 2일동안 하는 워크샾도 UI 통합을 조금 더 빠르고 원활하게 하자는 취지가 있다. UI 개발자들만도 수백명이고 그 개발 결과를 전체 산출물에 통합시키는데만 오랜 시간이 걸리기 때문이다. 심지어 UI 통합팀이 따로 있는데도 말이다.

 

이 글에서는 문제의 원인에 대해서 조금 짚어보았고 다음 글에서는 어떻게 하면 개선할 수 있을까라는 주제로 또 글을 써볼까 한다.