# 아마 Yocto가 필요 없을 것이고, 그래도 괜찮다 > Clean Markdown view of GeekNews topic #30003. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30003](https://news.hada.io/topic?id=30003) - GeekNews Markdown: [https://news.hada.io/topic/30003.md](https://news.hada.io/topic/30003.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-30T09:11:17+09:00 - Updated: 2026-05-30T09:11:17+09:00 - Original source: [sigma-star.at](https://sigma-star.at/blog/2026/05/you-probably-dont-need-yocto-and-thats-fine/) - Points: 1 - Comments: 1 ## Topic Body - **Yocto**는 배포판이 아니라 자체 Linux 배포판을 조립하는 도구이며, 필요한 제어가 없다면 기본 선택지로 삼기 어려움 - 자체 배포판은 **자체 유지보수**를 뜻하며, CRA 같은 규제와 제품 수명 동안의 보안 업데이트 책임까지 함께 따라옴 - Yocto 도입에는 수 시간 빌드, 100GiB 이상 빌드 디렉터리, 몇 주짜리 학습 곡선, 품질이 들쭉날쭉한 **BSP 레이어**가 포함됨 - 애플리케이션 실행용 견고한 Linux 기반이면 **Debian**과 mkosi·ELBE·debos 같은 이미지 도구가 훨씬 적은 프로젝트별 작업으로 충분할 수 있음 - 강한 맞춤화, 크기·부팅 시간 제약, 라이선스 제외, 견고한 벤더 Yocto 지원이 있을 때만 Yocto가 이기며, 의심스럽다면 기존 배포판이 낫다 --- ### Yocto의 실제 성격과 기본 선택지가 되는 이유 - **Yocto**는 “Yocto Linux 배포판”이 아니라 자체 Linux 배포판을 만들기 위한 도구 모음임 - Yocto Project는 `bitbake`, `openembedded-core`, `meta-yocto`로 만든 참조 배포판 **Poky**를 함께 제공함 - Yocto는 임베디드 프로젝트에 필요한 Linux 시스템을 세밀하게 조립할 수 있게 해줌 - 전체 사용자 공간을 대상 CPU용으로 컴파일 가능함 - 어떤 컴포넌트에도 패치를 적용할 수 있음 - 각 레시피의 기능을 켜거나 끌 수 있음 - 모든 버전을 고정하거나 변경할 수 있음 - 많은 **SoC 벤더**와 하드웨어 파트너가 바로 사용할 수 있는 BSP(Board Support Package) 레이어를 제공해 실제 하드웨어에서 동작하는 출발점을 만들어줌 - 유연성과 벤더 지원의 조합 때문에 Yocto가 기본 선택지가 되지만, 그만큼의 제어가 필요하지 않다면 부담이 더 커질 수 있음 ### 자체 배포판은 자체 유지보수를 뜻함 - **Cyber Resilience Act(CRA)** 같은 규제는 제품 공급자가 배포한 소프트웨어를 안전하게 유지하고 제품 수명 동안 보안 업데이트를 제공하도록 요구함 - 일반 Yocto 릴리스는 다음 릴리스가 나올 때까지 약 **7개월**만 유지됨 - Yocto 5.0 **Scarthgap**부터 현재 정책상 LTS 릴리스는 최대 **4년** 업데이트를 받음 - Yocto 릴리스는 특정 버전과 메타데이터를 가진 `bitbake` 레시피 집합, 그리고 참조 배포판 Poky로 구성됨 - 유지보수 기간 동안 Yocto 유지관리자는 컴포넌트와 Poky에 버그 및 보안 수정사항을 적용하며, 소프트웨어 컴포넌트 수정은 보통 최신 업스트림 버전에서 백포트됨 - 실제 제품에서는 Yocto를 그대로 쓰기보다 다음과 같은 변경이 들어가기 쉬움 - 일부 컴포넌트에 **비단순 패치**나 로컬 변경 적용 - Yocto가 제공하지 않는 추가 컴포넌트 포함 - 수정사항을 받거나 알려진 양호 상태를 유지하기 위한 버전 업그레이드 또는 고정 - Yocto 유지보수 릴리스가 나올 때마다 로컬 변경이 새 상태 위에 깨끗하게 적용되는지 확인해야 함 - 추가하거나 고정한 컴포넌트는 Yocto 유지관리자가 알 수 없으므로, 해당 컴포넌트가 계속 수정사항을 받고 있는지도 직접 확인해야 함 - Poky를 거의 변경하지 않고 쓴다면, Yocto가 필요한 이유를 다시 따져봐야 함 ### Linux 커널과 벤더 의존성 - Yocto는 각 릴리스의 일부로 **Linux 커널**을 제공하고 유지하지만, 실제 제품에서 이를 수정 없이 쓰는 경우는 드묾 - 보통 최소한 벤더 패치를 적용해야 하고, 필요한 드라이버와 수정사항이 들어간 충분히 새로운 커널을 사용해야 함 - CVE 추적까지 포함하면 커널만으로도 Yocto 사용 여부와 관계없이 큰 유지보수 부담이 됨 - 유지보수 부담을 제어하려면 [kernel.org](https://www.kernel.org/category/releases.html)의 **LTS 커널** 위에 구축하고 모든 변경을 정돈된 패치 큐로 유지하는 방식이 권장됨 - 보안 수정사항을 따라가려면 새 stable 릴리스로 이동한 뒤 패치 큐를 다시 적용함 - kernel.org는 LTS 커널을 여러 해 유지하므로, 보통 패치 큐는 깨끗하게 적용되고 새 LTS 릴리스로 넘어갈 때만 실질적인 작업이 필요함 - 설정과 보안 요구사항에 따라 **부트로더**에도 같은 원칙이 적용되며, 부트로더 역시 보통 벤더 특화 요소가 큼 - 벤더가 제공하는 커널을 그대로 유지하는 방식은 대체로 좋지 않음 - vendor kernel은 kernel.org보다 수년 뒤처져 있는 경우가 많음 - 업데이트를 거의 받지 않음 - 대부분의 보안 수정사항을 놓침 ### Yocto 도입 비용 - 자체 배포판을 만든다는 선택은 실제 엔지니어링 시간을 요구함 - ## 빌드 시간 - Yocto는 사실상 모든 것을 소스에서 컴파일함 - 복잡하지 않은 수준을 넘는 이미지의 클린 빌드도 빠른 워크스테이션에서 **수 시간** 걸림 - `sstate-cache`와 공유 `DL_DIR`은 반복 빌드를 빠르게 만들지만, 작은 레시피 변경만으로도 캐시의 큰 부분이 무효화될 수 있음 - ## 디스크와 CI 비용 - Yocto 빌드 디렉터리는 쉽게 **100GiB 이상**까지 커짐 - CI 러너에는 충분한 스토리지와 작업 간 `sstate` 공유 방식이 필요함 - `sstate`와 `DL_DIR`를 미러링하면 고통을 줄일 수 있지만, 그 인프라는 직접 운영해야 함 - ## 학습 곡선 - `bitbake` 레시피, 레이어, 동적 레이어, 클래스, 오버라이드, `bbappend` 파일, `PACKAGECONFIG`, `DEPENDS`와 `RDEPENDS`의 차이 등 익혀야 할 항목이 많음 - 엔지니어가 Yocto 코드베이스에 온보딩되는 데는 며칠이 아니라 **몇 주**가 걸림 - ## BSP 레이어 품질 편차 - 일부 SoC 벤더는 깨끗하고 잘 유지되는 BSP 레이어를 제공함 - 다른 벤더는 5년 된 커널이나 부트로더를 고정하고, 머신별 레시피를 잘못된 레이어에 하드코딩하며, Poky를 올릴 때마다 깨지는 `meta-vendor` 레이어를 제공하기도 함 - 좋은 출발점처럼 보이는 BSP가 빌드에서 가장 나쁜 부분이 될 수 있음 - 이런 요소들은 Yocto를 피해야 할 이유가 아니라, 도입 전에 실제로 필요한지 확인해야 할 이유임 ### 대안: 검증된 배포판 재사용 - 애플리케이션을 실행할 견고한 Linux 기반만 필요하다면 [Debian GNU/Linux](https://www.debian.org/) 같은 기존 배포판이 같은 문제의 상당 부분을 프로젝트별 작업량을 훨씬 줄여 해결함 - Debian은 현재 약 **70,000개 바이너리 패키지**를 제공함 - 지원 아키텍처에는 `amd64`, `i386`, `arm64`, `armhf`, `riscv64`, `ppc64el` 등이 포함됨 - 많은 SoC는 재컴파일 없이 Debian 바이너리를 직접 실행할 가능성이 높음 - Debian은 `systemd`, `udev`, `dbus`가 포함된 현대적인 사용자 공간만 제공하는 배포판이 아님 - 아카이브에는 SysV 스타일 init이나 BusyBox 기반의 작은 Linux 시스템을 만들기 위한 요소도 포함됨 - 얇은 기반을 선택하고 제품에 필요한 패키지만 설치하면서도 Debian 패키지 유지관리자의 작업을 활용할 수 있음 ### Debian 유지보수 모델 - Debian stable은 Debian Security Team으로부터 약 **3년** 동안 보안 업데이트를 받음 - 이후 커뮤니티 기반 [Debian LTS](https://wiki.debian.org/LTS) 프로젝트가 일반 아키텍처에서 약 **2년** 더 지원을 연장함 - 실제로 릴리스당 약 **5년** 지원이 가능해 Yocto LTS와 비슷한 수준이지만, 프로젝트별 작업은 훨씬 적음 - 최신 수정사항을 받으려면 최신 Debian 패키지를 가져와 이미지를 다시 만들면 됨 - Yocto에서 업스트림 패치를 직접 백포트하거나 로컬 변경이 유지보수 릴리스 위에 계속 적용되는지 다시 확인하는 방식과는 작업 성격이 크게 다름 ### 임베디드 이미지 구성 방식 - Debian 기반 임베디드 이미지는 SoC에서 USB 플래시 드라이브로 부팅해 Debian 설치 프로그램을 실행하는 방식이 아님 - 빌드 호스트에서 플래시 가능한 이미지를 생성하고 이를 장치에 기록하는 방식임 - 필요한 구성 요소는 다음과 같음 - 보통 SoC 특화인 **부트로더** 예: `u-boot` - 보통 SoC 특화인 **Linux 커널** - Debian에서 바로 가져온 Linux 사용자 공간 기반 **루트 파일시스템** - 세 요소를 플래시 가능한 이미지로 결합하는 이미지 조립 도구 - 이미지 조립 도구의 일반적인 선택지는 [`mkosi`](https://github.com/systemd/mkosi), [`ELBE`](https://elbe-rfs.org/), [`debos`](https://github.com/go-debos/debos)임 - 세 도구는 모두 자유 소프트웨어이며, 하드웨어에 플래시할 수 있는 결정적 이미지를 생성함 - 유지보수 작업은 크게 줄어들며, 대부분의 업데이트는 레시피 재작성보다 이미지 안 패키지를 `apt` 방식으로 새로고침하는 일이 됨 ### debos 기반 Debian 빌드 예시 - `debos`는 YAML **레시피**를 읽음 - 레시피는 명령 실행, 루트 파일시스템 생성, 설정된 소스에서 Debian 패키지 설치 같은 **액션** 목록으로 구성됨 - 기본 흐름은 다음과 같음 - [`aptly`](https://www.aptly.info/)로 필요한 모든 Debian 패키지의 사본을 담는 로컬 Debian 미러를 운영함 - Linux 커널과 필요하면 부트로더를 Debian 패키지로 빌드해 미러에 추가함 - 미러 스냅샷을 만들고 태그를 붙임 - 이 태그가 릴리스가 됨 - `debos`가 해당 미러를 사용하도록 설정하고 대상 이미지를 만드는 레시피 액션을 작성함 - 필요하면 Debian 소스 패키지와 이미지의 SBOM(Software Bill of Materials)을 이미지와 함께 보관함 - 소스 패키지와 SBOM 보관은 GPL 소스 제공 의무와 CRA의 자재 명세 요구사항을 지키는 데 도움이 됨 - [`debsbom`](https://siemens.github.io/debsbom) 같은 도구는 Debian 시스템에서 직접 SBOM을 생성함 ### Yocto를 선택해야 하는 경우 - **강하게 맞춤화된 배포판**이 필요할 때 Yocto가 적합함 - 맞춤 사용자 공간 - 맞춤 컴파일 플래그 - 기반 컴포넌트에 대한 깊은 변경 - 기성 배포판으로 충족할 수 없는 엄격한 **크기 또는 부팅 시간 제약**이 있을 때 적합함 - 일반적인 라이선스 범주를 제외해야 하는 라이선스 제약이 있을 때 적합함 - 의료기기, 자동차, 일부 방산 작업 등 일부 산업에서는 GPLv3 컴포넌트를 배포하지 않음 - Yocto의 `INCOMPATIBLE_LICENSE` 메커니즘은 이미지 전체에서 특정 라이선스 계열을 제외하기 쉽게 만듦 - 일반 Debian 기반에서는 패키지를 직접 감사하고 줄여야 함 - SoC 벤더의 공식 지원 경로가 Yocto이고 BSP 품질이 견고할 때 적합함 ### Yocto를 피해야 하는 경우 - 애플리케이션을 올려 실행할 현대적인 Linux만 필요하다면 Yocto가 필요하지 않을 수 있음 - 스토리지와 메모리 예산이 일반 Debian 기반 이미지를 감당할 수 있다면 Yocto의 이점이 줄어듦 - 예시 기준은 수백 MB 플래시와 **256MB 이상 RAM**임 - 제품 수명이 길고 자체 유지보수보다 Debian Security Team에 의존하는 쪽이 낫다면 Yocto를 피하는 편이 맞음 ### Debian을 피해야 하는 경우 - Debian 패키지를 많이 수정하거나 다시 빌드해야 한다면 Debian이 불리함 - 몇 개 패키지 재빌드는 관리 가능함 - 각 재빌드 패키지는 직접 떠안는 유지보수 작업이 됨 - 수십 개 업스트림 패키지를 패치하면 Debian 유지관리자가 대신하던 작업을 다시 만드는 셈임 - 이 규모에서는 Yocto의 레시피 모델이 더 깔끔하게 처리함 - `musl`이나 `uClibc` 같은 **비-glibc libc**가 필요하면 Debian이 맞지 않음 - Debian의 메인 아카이브는 전반적으로 glibc를 사용함 - 이를 교체하려면 아카이브 대부분을 직접 다시 빌드해야 함 - Debian stable이 제공하는 것보다 훨씬 최신 소프트웨어가 필요하면 Debian이 불리함 - backports가 일부 패키지에는 도움이 됨 - 최근 컴파일러나 최근 런타임이 제품에 필요하면 Debian stable과 충돌함 - Debian testing은 프로덕션 대상이 아님 ### 결정 원칙과 결론 - Yocto 여부는 의식적으로, 제품 초기에 결정해야 함 - 이 선택은 제품이 현장에 배포된 뒤 되돌리기 어려운 기반 선택임 - 의심스럽다면 기존 배포판에서 시작하는 편이 나음 - 실제 이유가 생긴 뒤 나중에 Yocto로 이동하는 비용은, 프로젝트 중간에 실질적 이익 없이 수년의 유지보수 작업을 떠안았음을 발견하는 것보다 훨씬 낮음 - Yocto는 필요한 Linux 시스템을 정확히 만들 수 있게 해주는 뛰어난 엔지니어링 산물이지만, 바로 그 정확한 제어가 필요하지 않을 때 문제가 됨 - Buildroot 같은 다른 소스 기반 빌드 도구에도 같은 논리가 거의 그대로 적용됨 - 자체 배포판을 조립하는 순간 그 유지보수 책임도 직접 소유하게 됨 - 핵심 결론은 명확함 - “자체 배포판”은 실제로 **자체 유지보수**를 뜻함 - CRA와 유사 규제는 그 비용을 실제 부담으로 만듦 - 크게 수정된 Yocto 빌드는 업스트림 수정사항을 공짜로 상속하지 않음 - 각 유지보수 릴리스는 검토와 재작업이 됨 - `mkosi`, `ELBE`, `debos`로 이미지화한 Debian 같은 기존 배포판은 일반적인 경우를 훨씬 적은 프로젝트별 노력으로 처리함 - 시스템을 외과적으로 제어해야 할 때는 Yocto가 이김 - 그렇지 않을 때 Yocto를 고르는 것은 존재하지 않는 문제를 길고 비싸게 푸는 방식이 됨 ## Comments ### Comment 58594 - Author: neo - Created: 2026-05-30T09:11:18+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/jp3nva/you_probably_don_t_need_yocto_s_fine) - SoC 벤더의 공식 지원 경로가 **Yocto**라면 BSP가 탄탄하지 않더라도, 대체로 품질이 낮은 Ubuntu 포팅보다 낫다고 봄 Ubuntu 포팅은 RAUC 통합이나 루트 파일시스템 불변화 같은 작업을 번거롭게 만듦. Yocto와 그 변형된 bash/python 방언은 정말 싫지만, 결국 거기에 묶여 있음 - Yocto 컨설팅을 많이 하지만, 글에서 한탄하는 문제는 겪어본 적이 거의 없음. 보통은 반대로, Yocto가 최선인 상황에서도 고객이 굳이 피하려고 해서 경영진을 설득해야 하는 경우가 많음 다만 **Yocto가 미움받는 건 이해됨**. 어렵고, 헷갈리고, 느리고, 도구도 더 나아질 수 있음. 그래도 실질적인 대안이 있는지 모르겠고, BSD 쪽에도 비슷한 게 있는지 궁금함 - Yocto와 얼마나 비슷한지는 모르겠지만, FreeBSD에서 임베디드 시스템 이미지를 만드는 일반적인 방식은 **NanoBSD**임 https://docs.freebsd.org/en/articles/nanobsd/ - 실전에서 깊게 써보진 않았고 Yocto보다 덜 완성됐을 수는 있지만, **[buildroot](https://buildroot.org/)** 에는 꽤 괜찮은 것들이 들어 있음 주로 **[Nerves](https://nerves-project.org/)** 맥락에서 써봤는데, Nerves는 기본적으로 buildroot + [fwup](https://github.com/fwup-home/fwup) + Erlang VM과 지원 소프트웨어 조합임. 임베디드 Linux 시스템을 개발하고 패키징/배포하기에 꽤 편했음 - 임베디드 Linux/BSD 시스템을 직접 다루진 않지만, NetBSD를 써본 입장에선 빌드 시스템인 **build.sh**만으로도 충분해 보임 커널과 사용자 공간을 쉽게 교차 컴파일할 수 있음. 마지막에 pkgsrc 애플리케이션을 추가하거나 생성 이미지에 u-boot 같은 부트로더를 넣어야 하면 스크립트가 좀 필요할 수는 있음. 애플리케이션에 맞게 바로 커스터마이즈 가능한 완성된 흐름은 아닐 수 있지만, 기반으로는 괜찮음 - **NetBSD**는 제한된 환경을 대상으로 교차 컴파일하기 좋게 구성돼 있고, 한번 감을 잡으면 꽤 쾌적함 - 임베디드 쪽의 끔찍함을 조금 겪어본 한정된 경험으로는, 이런 용도에는 **NixOS**가 꽤 잘 맞았고 빌드 도구도 Yocto보다 훨씬 좋았음 - ARM 장치에서도 그런지 궁금함. **NixOS 생태계**는 그런 기기에는 아직 조금 이른 줄 알았음 - 마침 회사에서 Rockchip 기반 장치용 **커스텀 Linux 커널과 배포판**을 계획하고 만들기 시작했는데, 시기적절한 글임 BSP는 유지보수할 게 꽤 많아 보이고, Debian을 “그냥 쓰는” 편이 내가 엉망으로 작성한 bitbake 작업보다 훨씬 관리 가능해 보임. 그래도 Yocto 생태계 자체는 꽤 괜찮고, 시작을 쉽게 해주는 [kas](https://kas.readthedocs.io/en/1.0/)나 [isar](https://github.com/ilbers/isar) 같은 도구가 있음 - isar README를 보면 Yocto가 아니라 **Debian 기반**으로 보임. 둘을 섞어 쓰는 게 흔한지 궁금함 글에서는 Yocto 아니면 Debian처럼 말하지, 둘을 합친 방식은 아닌 것 같음