차량용 소프트웨어 개발 환경 4부

코로나 때문에 독일에서 재택근무를 하며 거의 집에만 있고 가끔 딸아이와 공원 산책만 점심에 하고 있다.

 

많은 Conference 들이 취소/연기되거나 Virtual로 진행되기도 한다. AGL도 필자 회사에서 하려고 하는 F2F 미팅이 취소되고 하와이에서 하려던 Summit도 취소되었다.

 

오랜만에 차량용 소프트웨어 개발 환경에 대해 AGL (Automotive Grade Linux)의 사례를 가지고 설명해보고자 한다.

 

회사 사례를 가지고 벤츠의 소프트웨어 개발 환경에 대해 자세히 설명하면 좋겠지만, 공개해도 될지 애매해 오픈 소스 사례를 가지고 설명해 보고자 한다. 도구들이 약간 다르고 방법론이 살짝 다르지만 전체적으로 지향하는 CI/CD의 목적은 동일하고 볼 수 있다.

AGL (Automotive Grade Linux)

AGL은 앞에서도 간단히 설명했지만 일본 OEM, 특히 도요타를 중심으로 만들어진 Linux Foundation 산하의 차량용 소프트웨어 개발 오픈 소스 프로젝트이다. Tizen IVI를 가지고 시작했다가 Yocto를 가지고 GENIVI의 meta-ivi 레이어를 사용하여 Distro를 구성하여 다시 재구성하였다. 이제는 GENIVI의 의존성에서 거의 벗어나 meta-ivi를 제거하고 AGL 컴포넌트로 대체하여 사용하고 있다.

 

Code First를 외치며, 개발 위주로 발전하고 있으며 Infotainment 로 시작하여 Cluster, Telematic, ADAS 등 자동차 소프트웨어 전 영역을 커버하려는 꿈을 꾸고 있다.

 

필자는 AGL AMM (All Member Meeting), F2F meeting, ALS (Automotive Linux Summit) 등을 참여해봤는데, 대부분 일본 개발자들이 많고 Maintainer는 독일 친구이며 Community Manager 와 General Manager는 미국 친구들로 구성되어 있어 시차 맞추기가 참 어렵게 구성되어 있다.

AGL 개발 환경

AGL은 상용 프로젝트에서도 많이 사용하는 Jira를 Issue, Bug, Task 관리 도구로 사용한다. 오픈 소스에 대해서는 Atlassian에서 무료로 사용할 수 있게 제공을 해준다. 코드 관리 도구는 Android에서 사용하는 Gerrit 을 사용하고 CI 도구는 Jenkins를 사용하며 Test Framework로는 Fuego와 LAVA를 사용하고 있다.

AGL workflow

Yocto Linux를 기반으로 Infotainment 시스템을 개발하고 있고 각 컴포넌트마다 Gerrit에 저장소를 가지고 있고 그 컴포넌트 저장소는 각 메인테이너들이 직접 관리는 한다.

 

1. Component 개발

각 컴포는트 저장소에 개발한 내용을 올리고 Peer Review 후 Merge를 한다. 여기서 Jenkins pipeline를 구성하지 않는다. 필자의 회사는 Devops 팀에서 Template을 제공하고 각 개발팀에서 Jenkins pipeline를 구성한다.

 

2. Yocto의 meta layer에 Gerrit review 요청

각 컴포넌트 마다 recipe 를 가지고 있고, 그 recipe의 SRCREV를 bump하는 요청을 한다. 이때는 자동으로 Jenkins CI가 돌고 이후 Fuego, LAVA로 셋업된 간단한 테스트가 자동으로 돌아간다. 최근에 더 Target과 TC가 추가되어 있는지 모르겠지만 1년 전에는 Raspberrypi에서 부팅 및 간단한 테스트가 돌아갔다. 그리고 동료들과 Maintainer의 Review가 있은 후 Maintainer에 의해 Merge가 된다.

 

3. 릴리스

6개월 단위의 Release가 이루어지고 이때는 Release branch가 생성된다. 각 컴포넌트에도 같은 이름으로 branch가 생기고 릴리스가 이루어 진다. 참고로 Yocto upgrade는 초반에 6개월에 한번씩 이루어졌다가 공수가 커서 이제는 필요할 때마다 정하고 이제는 Yocto LTS가 3.1부터 생겨서 이를 따라갈 것 같다. 필자의 회사는 master branch를 따라가는 것과 제품 개발에는 LTS를 추가하여 진행하려고 계획하고 있다.

 

4. 기타

기본적으로 모든 개발자들에게 Yocto 전체를 빌드하여 개발하도록 가이드하고 있다. 그래서 필자의 회사도 가능하면 개발 환경을 같이 하는 3rd party에게 전체 오픈을 하려고 노력하고 소스를 필자 회사의 환경에 올리라고 가이드를 한다. 하지만 어쩔 수 없는 경우 SDK를 제공하여 바이너리를 받아 올리기도 한다. 단 제품에서는 그렇게 하지만 플랫폼에는 소스를 무조건 올리려고 하고 있다.

 

이 외에도 개발이 잘 돌아가도록 툴이 개발되고 내부 프로세스가 훨씬 더 많이 필요하다. 그래서 필자회사에는 devops팀에서 Infra, 개발 도구 셋업/개발 등의 업무도 중요하게 생각하여 진행하고 있다. 프로세스는 만드는 것도 중요하지만 모든 개발자가 잘 지키도록 전파하는 것이 중요하다. 그런 측면에서 서로간의 의사소통 및 합의가 중요하다.

 

마지막으로 Quality의 중요성을 필자는 이야기하고 싶다. 초기 개발부터 Unit Test, System Test, Performance Test, Integration Test, UI Test 등의 TC를 함께 만들고 매일 나오는 이미지는 무조건 가능한 테스트를 진행하여 Quality를 확보하는 것이 좋다고 생각한다. 처음에는 개발 속도가 느리게 보이더라도 결국에는 Bug 잡는데 시간을 훨씬 더 줄일 수 있다고 생각하고 이미 필자가 경험을 했다. Management는 항상 뭔가 돌아가는 것을 보고 싶어하지만, 실제 양산은 다르다. 보여주는 것도 중요하지만 Management를 설득하여 Quality를 처음부터 잡아나가는 것이 중요하고, 필자의 회사에서는 그렇게 진행하고 있다.

 

다음 5부에서는 Test 에 대해서 간단히 알아볼 예정이다.

 

빨리 코로나가 지나가서 날씨 좋을 때 가족들과 밖에 놀러다니고 싶다. :)