소프트웨어 개발 과정중에 테스트는 구지 꺼내어 이야기할 필요도 없을 정도로 기본이고 중요하다. 그 테스트 종류는 단위 테스트, 통합 테스트, 시스템 테스트, 사용자 시나리오 테스트 등등 다양하다. 현재 2024년도 벤츠 E Class 최종 막바지 작업과 차세대 프로젝트 등 동시에 진행중에 있으며 테스트 및 통합 관련 이야기는 프로젝트 시작부터 지금까지 계속 중요한 주제 중 하나로 다루어지고 있다.
통합 이야기는 다른 글에서 이야기하고 하고 이 글에서는 테스트 이야기를 조금 더 해보기로 한다.
개발 과정중에 단위 테스트, 컴포넌트 테스트, 도메인 테스트 등 다양한 테스트를 개발자 및 개빌 팀, 도메인 팀에서 진행을 한다. 하지만 통합 직전에 하는 테스트에서 문제는 끊임없이 계속 반복이 된다. 심지어 그 도메인에 통합 팀(테스트 인력 포함)이 있는데도 불구하고 말이다. 당연히 논리적으로는 개발 팀에서 개발 과정중에 테스트를 다 하고 통합을 요청을 했으면 통합 과정중에 거의 문제가 안나야지 정상이다. 하지만 서로 다른 영역에서 끊임없이 문제가 나오고 분석을 하고 통합을 하는 반복적인 일을 하고 있다.
개발팀과 인터뷰를 하면서 근본원인이 무엇이고 어떻게 하면 완화시킬 수 있을까라는 고민을 하기 시작했고 답이 나오진 않았지만 그 원인과 현상이라도 공유를 하고자 블로그를 열었다.
왜 지속적으로 이런 어려운 통합과정을 거쳐야하는가? 개발자들의 의견과 필자의 의견을 합쳐서 간단히 적어보고자 한다.
- 복잡한 개발 환경: 차량에 들어가는 개발코드가 다른 어느 임베디드 제품이나 소프트웨어보다 크다고 알고 있다. 수십, 수백개의 ECU (Electric Control Unit)가 원활한 통신이 되고 유기적으로 결합이 되어야 한다. 또한 차량의 변형(variant)이 많고 디스플레이나 센서의 종류도 사용하는게 각기 다르다. 표준화가 덜 되어 있다. 다행이도 필자의 회사는 하나의 SoC 업체에서 같은 제품을 사용한다. 그럼에도 불구하고 이슈는 계속 나온다.
- 테스트 장비 부족: QEMU 가상환경에서 일부 팀은 테스트하고 하드웨어 관련 컴포넌트 팀은 테스트 벤치에서, 그리고 최종적으로 차량 테스트가 필요하면 차량에서 테스트를 한다. 가상환경을 제외한 테스트 벤치 및 차량은 절대적으로 부족하다. 개발 인원은 몇천명이고 개발팀은 몇백팀인데 그에 비해 HW는 절대적으로 부족하다. 또한 고가의 HW는 B,C,D 샘플로 바뀌고 그 안에서도 하위 버전의 샘플이 계속 나온다. 고가이기 때문에 많이 찍어서 배포하기도 어렵고 배포 시간을 맞추기도 어렵다.
- 테스트 벤치와 차량의 다른 환경: 테스트 벤치에서 문제가 안나오지만 간혹 차량에서 문제가 발생하는 경우도 많이 있다. 서로 다른 센서 장비 및 하드웨어 문제, 다른 ECU와의 통신이 필요한 문제 등 여러가지 원인이 있다.
- 테스트 환경 및 인력: 테스트 환경 및 케이스에 대한 표준화가 계속 이루어 지고 있음에도 불구하고 더 노력이 필요하며 테스트 인력의 교육도 지속적으로 필요하다. 기본적으로 테스트 인원들은 기본 차량의 기능을 모두 다 알고 테스트를 진행해야하고 더 나아가 기본적인 아키텍처까지 알면 문제가 발생했을 때 어느 컴포넌트가 원인이라는 것을 1차적으로 진단할 수 있어 프로젝트에 큰 도움이 된다.
- 아키텍처 복잡도: 인포테인먼트 내에서도 하이퍼바이저를 쓰고 그 각각의 OS 내에서도 아키텍처의 복잡도가 커서 서로간의 의존성 등의 문제로 인해 테스트가 완벽히 이루어지지 않는 경우가 있다. 또한 경우에 따라 다른 개발팀과의 소통부재가 문제가 될 수도 있다. 가능하면 아키텍처 부채 및 복잡도를 해결하고 조직도의 구성을 의존성을 생각해서 만드는 것도 좋을 듯 하다. 물론 말이 쉽지 실제로 하기는 정말 어렵다.
이런 저런 이유들로 테스트가 잘 되었다고 계속 개발팀은 주장해도 통합 직전에 문제는 많이 발생하고, 이런 문제들은 계속 숙제로 남겨지고 하나씩 해결하고 있다. 아직 완벽한 솔루션은 없고 이런 모든 내막을 모르는 매니저들은 왜 안되냐는 이야기만 하고 있다. 각 도메인 테스트 리드들과 워크샾을 만들어서 하던 한명씩 만나서 개별 인터뷰를 하던 서로의 상황을 이해하고 문제를 해결하기 위한 아이디어를 도출을 해야겠다.
시뮬레이터/에뮬레이터에서 테스트하는 방만도 오래전부터 진행이 되고 있고 여전히 진행중인 것으로 알고 있고 많은 도움은 되지만 그마저도 안정이 안되어 있다. 첫 In-house 제품이 곧 출시한다. 정말 의미있는 과정이고 결과물이다. 하지만 다음 프로젝트에는 더 많은 차량을 지원하고 변형관리 등등을 해야하는 입장에서 많은 부분에서 개선이 필요하다.
이전에 통합이라는 주제에 대해서 다뤄본 것으로 기억하지만 다시 그 글을 읽어보고 조금 더 자세한 내용으로 다음글에서는 들어가볼까 생각중이다.
'Automotive' 카테고리의 다른 글
차량용 (Infotainment) 소프트웨어 개발 과정 중 통합 2부 (0) | 2023.09.25 |
---|---|
차량용 (Infotainment) 소프트웨어 개발 과정 중 통합 1부 (0) | 2023.09.18 |
BMW의 소프트웨어 플랫폼 (node0) (0) | 2023.08.30 |
소프트웨어 플랫폼에 대해서 - 3부 (Delivery 조직) (0) | 2023.06.29 |
소프트웨어 플랫폼에 대해서 - 2부 (벤츠 MB.OS) (0) | 2023.05.29 |