독일 자동차 소프트웨어 개발자

Yocto 기반으로 임베디드 리눅스를 개발할때 일반적으로 많이 사용하는 개발 환경을 소개하고자 한다. 다들 알고 글을 읽고 있겠지만 간단히 Yocto에 대해서 다시 소개하자면 하드웨어 아키텍처와 무관하게 커스텀 임베디드 리눅스를 만들기 위한 빌드 프레임워크이다. 자세한 내용은 https://www.yoctoproject.org/ 를 방문해서 문서와 함께 살펴보면 된다. Yocto 기반으로 개발을 해본 분들은 알고 있겠지만 일단 Yocto 자체를 배우는 것에 대한 시간이 소요된다. 오죽하면 "욕나오고 토나온다고 해서" 욕토라고 하겠는가? :) 물론 Yocto 원어는 10의 -24승, 아주 작은 단위를 말한다. 이유야 어찌되었건 그만큼 Yocto 환경에서 개발하는데 어렵다는 의미이다. 그럼 왜그렇게 다들 어..

지금 Mercedes-Benz 본사가 있는 Sindelfingen에 이틀 동한 UI 통합 관련 워크샾을 하러 가는 길이다. 새벽같이 일어나 공항에서 대기하는 도중 간단히 정리도 할 겸 블로그를 열었다. 차량용 인포테인먼트 소프트웨어 통합은 정말로 복잡하고 어렵다. 앞의 글에서 테스트에 대해서 이야기 했다시피 여러가지 장벽이 많다. 통합과정 중 테스트는 가장 중요한 핵심 요소 중에 하나이다. 테스트 부분은 빙산의 일각일 뿐이다. 회사 전체의 화두 중 하나도 소프트웨어 통합이다. 통합 관련 VSM (Value Stream Mapping) 워크샾도 여러번 진행을 하면서 전체 개발 과정을 펼쳐놓고 어느 부분이 bottleneck이고 어떻게 하면 조금 더 효율적으로 해결할 수 있는 지 등등을 이야기 했다. 여러번..

어제 회사 Summer Party에서 동료와 승진 과정 및 조건에 대한 주제가 나와서 간단히 글을 적어보고자 한다. 지금 기준인 지금 필자가 있는 회사기준이고 모든 독일회사가 동일하지는 않다. 그리고 Staff, Principal 엔지니어에게 요구되는 덕목(?)도 요즘에 많은 고민을 하고 있고 관련된 서적도 읽고 있어서 그 책을 다 읽고 이와 비슷한 이야기를 다시 적고자 한다. 위의 그림은 일반적인 커리어 패스에 대해서 개발 패스와 매니저 패스로 나눠서 체계를 잘 적어놓았고 필자의 회사와 완벽하게 포지션 명까지는 일치하지 않지만 대략 비슷하다. 대부분 경력 10-15년차정도 되는 개발자들은 위의 그림 기준으로 시니어 소프트웨어 엔지니어가 된다. 필자의 회사에서도 시니어 소프트웨어 엔지니어는 엔니지어링 매..

Yocto 프로젝트에서는 CI와 연동하여 QEMU에서 자동화 테스트를 할 수 있는 image test framework인 oeqa를 제공을 한다. 이 테스트는 ssh를 통해 타깃 시스템에서 실행이 되고 테스트 스크립트를 파이썬으로 작성이 된다. 이 테스트의 구현 사항은 testimage.bbclass에 구현이 되어 있다. 위의 그림은 Yocto QEMU 이미지 빌드후 QEMU를 실행하는 과정이다. Yocto 자동화 테스트를 하려면 테스트 환경 설정 및 테스트 케이스를 파이썬 스크립트로 작성해야 한다. 테스트 케이스 구현 테스트 케이스는 일반적으로 /lib/oeqa/runtime/cases 에 위치를 한다. Poky의 테스트 케이스를 참고하려면 다음 링크를 가서 하나씩 살펴보면 된다. 아래 예제는 conn..

소프트웨어 개발 과정중에 테스트는 구지 꺼내어 이야기할 필요도 없을 정도로 기본이고 중요하다. 그 테스트 종류는 단위 테스트, 통합 테스트, 시스템 테스트, 사용자 시나리오 테스트 등등 다양하다. 현재 2024년도 벤츠 E Class 최종 막바지 작업과 차세대 프로젝트 등 동시에 진행중에 있으며 테스트 및 통합 관련 이야기는 프로젝트 시작부터 지금까지 계속 중요한 주제 중 하나로 다루어지고 있다. 통합 이야기는 다른 글에서 이야기하고 하고 이 글에서는 테스트 이야기를 조금 더 해보기로 한다. 개발 과정중에 단위 테스트, 컴포넌트 테스트, 도메인 테스트 등 다양한 테스트를 개발자 및 개빌 팀, 도메인 팀에서 진행을 한다. 하지만 통합 직전에 하는 테스트에서 문제는 끊임없이 계속 반복이 된다. 심지어 그 도..

소프트웨어 개발에서 Automation (자동화)에 대한 이야기를 많이 한다. 자동화는 여러군데에서 적용하여 실행을 할 수 있고 실제로 많은 도움을 주어 잡다한 일들을 해소시켜준다. 하지만 역으로 자동화를 구현, 관리하고 유지보수하는데 경우에 따라서는 많은 노력이 든다. 특히 임베디드 기기와 연결을 하거나 하면 더 그럴 수 있다. 하지만 많은 개발자들이나 매니저들은 자동화를 마치 신인 것처럼 계속 외치고 있다. 물론 좋다. 이상적으로 동작할 경우에는 100% 찬성한다. 하지만 매뉴얼 테스트하고 플래싱하는데도 하드웨어에서 문제가 생기고 소프트웨어에서 문제가 생기는데 무슨 자동화... 병행은 한다만 무조건 만능이고 모든 문제를 해결해 줄 것이라는 기대를 버리라고 하고 싶다. 실체를 제대로 파악하고 어느 분야..