Yocto intro

Sat, Jan 23, 2021 3-minute read

x86는 Intel과 AMD의 프로세서에서 널리 사용되는 CPU 아키텍처로 범용성이 좋아 많은 운영체제와 소프트웨어가 이를 지원하고 있으며 많은 개발자와 일반 사용자들이 폭넒게 사용하고 있다. 이 유명세에 힘입어 대부분의 배포판 리눅스들은 대부분 x86 아키텍처를 기반으로 개발되고 지원되고 최적화되어 있다.

하지만 임베디드 제품 환경에서는 상황이 다르다. 임베디드 제품에는 다양한 CPU 아키텍쳐들이 전천후로 사용된다. 따라서 당연히 x86 아키텍처을 주력으로 하는 배포판 리눅스는 임베디드 환경에서 사용하기 어렵다. 그래서 임베디드 리눅스 환경의 개발은 배포판을 사용하는 대신 Bottom-Up으로 진행된다. Bootloader, Kernel의 선택부터 필수적인 Package, User Application의 추가, 그리고 이를 Build, Install, Packaging하는 과정까지 개발자가 세세하게 관리하며 원하는 최적의 Customized 리눅스를 만들어 내는 것이다.

리눅스 임베디드 그룹은 이러한 과정을 효율적으로 관리하기 위한 도구를 개발하기로 결정했다. 초기 버전인 2010년 Yocto Project는 OpenEmbedded와 BitBake를 완성하여 임베디드 리눅스 개발을 위한 기본 도구와 문서를 제공했고, 다음년도에는 Poky라는 완전한 리눅스 시스템 이미지 생성 기능을 추가하여 현재의 Yocto Project의 기본 형태를 완성했다. 이후에 디버깅 기능을 추가, 하드웨어 아키텍처 지원 확장, 빌드 시스템 개선과 같은 추가 업데이트가 이뤄졌지만 제일 중요한 기능은 OpenEmbedded, BitBake, Poky 이 3가지라고 말할 수 있다. 비유하자면 아래와 같다.

Poky는 Yocto Project의 임베디드 리눅스 시스템을 구축하기 위한 기본 설정과 패키지들를 제공한다. Poky는 건축가가 건물을 디자인하는 도면과 설계도와 같다. 건축가가 도면을 기반으로 건물의 구조와 기능을 결정하고 설계하듯 개발자는 Recipe를 통해 내가 만들 무언가를 구성할 내용들을 정해진 양식을 따라 다양하게 정의할 수 있다.
bitbake는 빌드 및 패키지 관리 도구로 Yocto Project에서 Recipe를 읽은 후 이 Recipe대로 산출물을 빌드하고 이미지를 생성하는 역할을 한다. 비유를 한다면 Bitbake는 건축 현장에서 작업하는 공사 인부라고 할 수 있다. 건축가가 설계한 도면을 기반으로 공사 인부는 재료를 조합하고 구조물을 건설한다.
설계도도 있고 일할 사람도 있고… 이제 재료가 필요하다. OpenEmbedded는 Yocto Project의 빌드 시스템으로 리눅스 기반 시스템에 필요한 다양한 패키지와 컴포넌트를 관리한다. 역시 예를 들자면 OpenEmbedded는 건축 현장의 자재 장부와 같다. 다양한 종류의 건축 자재와 도구를 보유 혹은 정보를 관리하고 있으며 필요한 자재를 (혹은 자재 정보를) 공사 인부에게 제공한다.

위에서 언급한 Poky는 소프트웨어 패키지의 추가, 의존성 관리, 커스텀 레이어 생성 등등 정말 다양한 기능을 지원하여 개발자가 원하는 방식으로 시스템을 구축할 수 있도록 도와준다. 지원하는 항목이 너무 다양해 이를 설명하는 메뉴얼의 이름도 메가 메뉴얼일 정도이다. (https://docs.yoctoproject.org/singleindex.html)

물론 이 도구가 완벽한 것만은 아니다. 기능의 방대함으로 역으로 오는 관리의 어려움이 있다. Yocto는 결국 도구일 뿐이며 이를 운영하는 조직이나 사람에 따라 천차만별의 효율로 쓰일 수 있는데 레시피의 관리, 개발 프로세스의 관리 등을 상황에 따라 잘 고려해야 한다. 수십여개의 Recipe에서 각각의 개별 저장소를 다운받는 것으로부터 빌드가 시작되니까 소스코드 혹은 배포 산출물을 저장할 수 있는 충분한 공간이 필요하다. 간단한 시스템이면 모르겠지만 다양한 Recipe를 다루는 빌드를 진행할 경우 어마무시한 용량을 사용하게 된다. 내가 지금 회사에서 개발하는 Yocto base 프로젝트는 빌드 한 번에 50G를 훌쩍 넘는 공간 가용량을 필요로 한다. 용량적인 측면 말고 빌드 시간에 대한 효율성도 생각해야 한다. 저장소를 다운받는 시간이 필요하고, 컴포넌트 빌드가 필요한 경우 이를 진행되어야 한다. (Yocto는 다양한 플랫폼에서 포팅되는 것을 목표로 하기 때문에 이미 빌드 된 산출물을 Install만 진행해 사용하는 예가 드물다.) 몇 십개, 몇 백개의 Recipe에 대해 이런 과정들을 모두 진행되어야 하니 전체 빌드 시간이 무척 오래 걸리게 된다. 개선할 수 있는 방법은 있지만 Yocto의 구조적인 부분 때문에 개선 가능한 한계가 있다. (이건 나 한정… 다른 분들은 잘나서 그런지 이런 코멘트나 고민을 본 적이 없어서…) 빌드에 문제가 있는 경우 가끔씩 Bitbake python코드를 디버깅 할 일이 있었는데 변수나 함수의 이름들이 너무 간략하게 정의되어 있고 너무 중복적으로 나타나서 코드를 분석하는데 어려움을 겪었다.

나는 Yocto 없는 리눅스 제품 개발을 해본적이 없어 정확한 비교를 하긴 힘들지만, 위와 같은 점들을 감안하더라고 임베디드 리눅스를 개발하는 어렵지만 가장 쉬운 길은 Yocto라고 생각한다. Yocto없이 이에 해당하는 작업들을 일일히 직접 관리하고 포팅한다고 가정하면 생각만으로 머리가 지끈하다.