[Yocto 시리즈 1] Yocto란 무엇인가 — Poky·BitBake·OpenEmbedded 이해
by khd08012026. 7. 21.
반응형
임베디드 리눅스 개발을 하다 보면 반드시 Yocto라는 이름을 만나게 돼요. 반도체 벤더의 BSP도, 사내 플랫폼 빌드 시스템도 결국 Yocto 위에서 돌아가는 경우가 대부분이거든요. 그런데 처음 접하면 Poky, BitBake, OpenEmbedded 같은 이름이 뒤섞여서 "그래서 Yocto가 뭔데?"라는 질문에 답하기가 의외로 어렵습니다. 이 글은 20회 연재의 첫 편으로, 그 관계를 한 번에 정리해 볼게요.
핵심은 Yocto가 Ubuntu나 Debian 같은 리눅스 배포판이 아니라, 임베디드 제품에 맞는 커스텀 리눅스 배포판을 '만들어 내는' 도구와 메타데이터의 모음이라는 점이에요. 여러분이 Yocto로 얻는 최종 산출물은 "Yocto 리눅스"가 아니라, 여러분 보드에서 부팅되는 여러분만의 리눅스 이미지입니다.
1.1 임베디드에서 왜 커스텀 리눅스가 필요한가
데스크톱이나 서버라면 Ubuntu를 설치하고 필요한 패키지를 얹으면 끝나요. 하지만 임베디드는 사정이 다릅니다. 저장 공간이 수십~수백 MB뿐인 보드도 많고, CPU 아키텍처도 ARM, RISC-V 등 제각각이고, 부팅 시간·보안·라이선스 요건까지 제품마다 달라요. 범용 배포판을 잘라내서 맞추는 것보다, 필요한 것만 골라 처음부터 빌드하는 쪽이 오히려 통제 가능합니다.
1.2 Yocto Project가 해결하는 문제
Yocto 이전에는 팀마다 크로스 컴파일 스크립트를 손수 유지했고, 커널·라이브러리·툴체인 버전 조합이 어긋나면 빌드가 깨지기 일쑤였어요. Yocto는 이 조합 전체를 레시피(recipe)라는 형태로 기술하고, 재현 가능한 빌드로 만들어 줍니다. 공식 문서가 꼽는 강점 중 실무에서 특히 체감되는 것은 이 네 가지예요.
아키텍처 독립: Intel, ARM, MIPS, AMD, PPC, RISC-V 모두 같은 방식으로 빌드
필요한 것만 담기: 이미지에 "exactly what you need"만 포함 — IoT·소형 기기에 유리
부분 재빌드: Shared State Cache(sstate) 덕분에 바뀐 패키지만 다시 빌드
라이선스 추적: 이미지에 들어간 오픈소스 라이선스 매니페스트 자동 생성
2. 핵심 구성요소 — BitBake, OE-Core, Poky
2.1 BitBake — 태스크 실행 엔진
BitBake는 빌드의 엔진이에요. 공식 정의는 "a generic task execution engine that allows shell and Python tasks to be run efficiently and in parallel while working within complex inter-task dependency constraints"입니다. make에 비유하면 이해가 빨라요 — Makefile 대신 레시피(.bb)를 읽고, 수천 개 태스크의 의존 관계를 풀어서 병렬 실행합니다. 우리가 매일 치게 될 명령이 바로 bitbake <이미지이름>이에요.
2.2 OpenEmbedded-Core — 검증된 메타데이터의 핵심
OpenEmbedded-Core(OE-Core)는 "a common layer of metadata (i.e. recipes, classes, and associated files)"로, 어떤 임베디드 리눅스에나 공통으로 필요한 기본 레시피들의 품질 관리된 핵심 집합입니다. glibc, busybox 같은 기초 패키지의 빌드 방법이 여기 들어 있어요. 저장소 이름으로는 openembedded-core, 레이어 이름으로는 meta입니다.
2.3 Poky — 레퍼런스 배포판 (제품용 아님)
Poky는 Yocto Project의 레퍼런스 배포판(Reference OS Kit)이에요. BitBake + OE-Core + 배포판 설정(meta-poky)을 한 저장소에 묶어서 "이대로 빌드하면 일단 돌아가는" 출발점을 제공합니다. 단, 공식 문서의 경고를 기억해 두세요.
"While Poky is a 'complete' distribution specification and is tested and put through QA, you cannot use it as a product 'out of the box' in its current form." — 같은 문서
즉 Poky는 학습·출발점용이지 제품이 아닙니다. 실제 제품은 Poky를 참고해 자기 배포판 설정을 만드는 게 정석이에요.
📌 실무 팁 — 면접이나 회의에서 "Yocto = Poky?"라는 혼동을 자주 봅니다. 정리하면: Yocto Project는 우산 프로젝트 이름, BitBake는 빌드 엔진, OE-Core는 공통 레시피 모음, Poky는 이들을 묶은 레퍼런스입니다. "Yocto로 빌드한다"는 말은 보통 "Poky 기반 환경에서 BitBake를 돌린다"는 뜻이에요.
3. 레이어 모델 — Yocto 확장성의 핵심
3.1 레이어란 무엇인가
레이어는 "관련된 빌드 지시들을 모아 둔 저장소"예요. 커널·부트로더처럼 보드에 종속적인 것은 BSP 레이어(예: meta-raspberrypi), 그래픽 스택은 GUI 레이어, 배포판 정책은 Distro 레이어(예: meta-poky), 우리 회사 애플리케이션은 Application 레이어 — 이런 식으로 역할별로 나눠 쌓습니다. 관례상 레이어 이름은 meta-로 시작해요 (필수는 아니고 "commonly accepted standard").
3.2 레이어를 나누는 이유
공식 문서의 표현을 빌리면 "Isolating information into layers helps simplify future customizations and reuse" — 격리와 재사용이 목적이에요. 보드가 바뀌면 BSP 레이어만 교체하면 되고, 애플리케이션 레이어는 그대로 재사용됩니다. 다른 레이어의 레시피를 고치고 싶을 때도 원본을 건드리지 않고 내 레이어에서 .bbappend 파일로 덮어쓰는 방식이라, 벤더 코드와 우리 코드가 섞이지 않아요.
📌 실무 팁 — 실리콘 벤더(NXP, TI, 라즈베리파이 등)가 제공하는 BSP 레이어를 최대한 그대로 쓰는 게 공식 권장이에요. 필요한 레이어는 OpenEmbedded Layer Index에서 검색할 수 있습니다.
4. 빌드는 어떻게 흘러가나 — 큰 그림
4.1 여섯 단계 워크플로우
공식 문서가 설명하는 큰 흐름은 이렇습니다: ① 개발자가 아키텍처·정책·패치·설정을 기술하면 ② 빌드 시스템이 소스를 내려받고(tarball, Git 등) ③ 압축을 풀고 패치를 적용한 뒤 설정·컴파일하고 ④ 임시 영역에 설치해 RPM/DEB/IPK 형식으로 패키징하고 ⑤ QA 검사를 거쳐 ⑥ 패키지들을 조합해 루트 파일시스템 이미지를 만들어요. 필요하면 같은 재료로 크로스 개발용 SDK도 함께 생성됩니다. 각 단계의 내부는 3회차(태스크 파이프라인과 sstate)에서 자세히 열어볼게요.
4.2 장점과 도전과제 — 솔직한 이야기
공식 문서도 도전과제를 숨기지 않아요: 학습 곡선이 가파르고, 같은 일을 하는 방법이 여러 가지라 처음엔 뭘 골라야 할지 모르겠고, 데스크톱 개발과 워크플로우가 달라 혼란스럽고, 첫 빌드는 모든 패키지를 컴파일하느라 오래 걸립니다. 10년 넘게 임베디드를 하면서 느낀 걸 덧붙이면 — 이 학습 비용은 "보드 하나, 제품 하나"일 때는 커 보이지만, 제품 라인이 둘만 돼도 레이어 재사용으로 회수됩니다. 이 연재가 그 학습 곡선을 낮추는 지름길이 되면 좋겠어요.
5. 버전과 릴리스 — 어떤 버전으로 시작할까
Yocto는 매년 4월·10월, 6개월 주기로 릴리스돼요. 2026년 7월 현재 공식 문서 기준 지원 릴리스는 5.0 (scarthgap)과 6.0 (wrynose) 두 계열입니다. scarthgap은 LTS(장기 지원) 릴리스라 실무 프로젝트의 주류이고, 이 연재도 scarthgap 5.0 기준으로 설명할게요. (6.0의 LTS 여부·정확한 지원 종료 시점은 릴리스 페이지에 명시돼 있지 않아 미확인입니다.)
⚠️ 6.0에서 달라진 점 — docs.yoctoproject.org 기본 화면은 개발판(6.0-tip) 문서예요. 6.0부터는 첫 빌드 절차가 기존 git clone poky + oe-init-build-env 방식에서 bitbake-setup이라는 새 도구 중심으로 바뀌었습니다. 회사에서 접할 환경은 대부분 구 방식이므로 이 연재는 구 방식을 기본으로, 6.0 변경점은 이렇게 참고 박스로 짚고 넘어갈게요. 문서를 볼 때는 좌측 상단에서 버전을 5.0으로 맞추는 걸 추천해요.
# 1. Poky 저장소 클론 (scarthgap = 5.0 LTS 브랜치)
git clone -b scarthgap https://git.yoctoproject.org/poky
cd poky
# 2. 오늘 배운 구성요소를 눈으로 확인
ls # bitbake/, meta/, meta-poky/, meta-yocto-bsp/, oe-init-build-env ...
ls bitbake/bin # 빌드 엔진 BitBake 실체
ls meta/recipes-core # OE-Core의 핵심 레시피들
ls meta-poky/conf # Poky 배포판 설정
# 3. 빌드 환경 초기화 후 BitBake 버전 확인 (build/ 디렉터리가 생성됩니다)
source oe-init-build-env
bitbake --version
⚠️ 프로토콜 주의 — 공식 Quick Build 문서는 아직 git://git.yoctoproject.org/poky로 안내하지만, 지금은 이 주소로 연결되지 않습니다. git://는 9418 포트를 쓰는 git 전용 프로토콜인데 git.yoctoproject.org가 CDN 뒤로 옮겨지면서 해당 포트를 받지 않게 됐고, 그래서 Connection timed out으로 실패해요. 위처럼 https://로 받으면 정상 동작합니다. 사내 방화벽 문제가 아니라 서버 쪽 구성 변화이니, 문서에서 git://를 만나면 습관적으로 https://로 바꿔 읽으세요.
기대 결과: 1번에서 저장소가 받아지고, 2번에서 bitbake(엔진)·meta(OE-Core)·meta-poky(레퍼런스 배포판 설정)가 각각 실제 디렉터리로 보이면 오늘 내용을 눈으로 확인한 거예요. 3번은 셸 환경을 바꾸고 build/ 디렉터리를 만듭니다 — 상세한 의미는 5회차에서 다뤄요.
✍️ 내 실행 결과 1. poky 저장소 클론 2. 구성 요소
3. 빌드환경 초기화 후 Bitbake 버전 확인
마무리
오늘은 Yocto Project가 배포판이 아니라 커스텀 배포판을 만드는 도구·메타데이터의 모음이라는 것, 그리고 BitBake(엔진)·OE-Core(공통 레시피)·Poky(레퍼런스 묶음)의 관계와 레이어 모델을 정리했어요. 다음 2회차에서는 오늘 이름만 나온 레시피·레이어·메타데이터의 실체 — .bb, .bbappend, .conf, .bbclass 파일이 각각 무엇인지 — 를 파일 단위로 뜯어봅니다.
댓글