[Yocto 시리즈 2] 레시피·레이어·메타데이터 — .bb, .bbappend, .conf, .bbclass 해부
khd0801
2026. 7. 14. 22:53
반응형
지난 1회차에서 Yocto가 "배포판을 만드는 도구"라는 큰 그림을 봤다면, 이번엔 그 도구를 실제로 움직이는 재료를 뜯어볼 차례예요. Yocto 작업 디렉터리를 열면 .bb, .bbappend, .conf, .bbclass 네 가지 확장자가 끝없이 나오는데, 이 넷의 역할 구분이 서면 Yocto 코드 읽기가 갑자기 쉬워집니다. 실무에서 벤더 BSP를 분석하거나 빌드 에러의 원인 파일을 추적할 때 매일 쓰게 되는 지식이에요.
"A key element of the Yocto Project is the Metadata that is used to construct a Linux distribution and is contained in the files that the OpenEmbedded Build System parses when building an image." — Yocto Project Reference Manual, Terms
즉 메타데이터는 "리눅스 배포판을 어떻게 만들지"를 기술한 파일 전체를 가리키는 말이에요. 1회차에서 본 BitBake(엔진)가 이 메타데이터를 파싱해서 빌드를 실행하고, 레이어는 이 메타데이터를 역할별로 묶어 두는 폴더 구조입니다. 그리고 메타데이터의 실체가 바로 오늘의 네 파일 — 레시피(.bb), 어펜드(.bbappend), 클래스(.bbclass), 설정(.conf)이에요.
1.2 파일 확장자로 보는 메타데이터 지도
2. 레시피(.bb) — 패키지 하나의 빌드 설명서
2.1 레시피가 담는 것
"A set of instructions for building packages. A recipe describes where you get source code, which patches to apply, how to configure the source, how to compile it and so on." — 같은 용어집
레시피 하나는 소프트웨어 하나의 빌드 방법 전체를 담아요: 소스를 어디서 받는지, 어떤 패치를 적용하는지, 어떻게 configure/compile 하는지, 결과물을 어떻게 패키징하는지까지. busybox의 레시피, 커널의 레시피, 여러분이 만든 앱의 레시피가 각각 존재하고, 이미지는 결국 수백 개 레시피의 빌드 결과를 모은 것입니다.
2.2 파일명이 곧 정보 — 이름_버전.bb
레시피 파일명은 규칙이 있어요. 공식 문서의 예시로 matchbox-desktop_1.2.3.bb라면 밑줄 앞부분(matchbox-desktop)이 패키지 이름, 뒷부분(1.2.3)이 버전이 됩니다. BitBake는 이 파일명에서 이름(PN)과 버전(PV) 변수를 자동으로 뽑아내요. 그래서 bitbake busybox라고 치면 BitBake가 busybox_*.bb를 찾아 빌드하는 것이죠. 레시피 내부 문법(SRC_URI, 태스크 함수 등)은 9회차에서 한 줄씩 뜯어봅니다.
📌 실무 팁 — 빌드 에러 메시지에 나오는 busybox-1.36.1-r0 같은 문자열은 이름-버전-리비전(PN-PV-PR) 조합이에요. 이 이름만 보고 find . -name "busybox_*"로 해당 레시피 파일을 바로 찾아가는 것이 Yocto 디버깅의 첫걸음입니다.
3. 클래스(.bbclass) — 반복을 없애는 상속
3.1 한 번 정의하고 여러 레시피에서 재사용
"Files that provide for logic encapsulation and inheritance so that commonly used patterns can be defined once and then easily used in multiple recipes." — 같은 용어집
세상의 오픈소스 대부분은 몇 가지 정형화된 빌드 방식(GNU Autotools, CMake 등)을 따라요. 그 공통 절차를 레시피마다 복사해 넣는 대신, 클래스 파일에 한 번 정의하고 레시피에서 inherit로 가져다 쓰는 구조입니다. 예를 들어 레시피에 inherit autotools 한 줄을 쓰면 ./configure && make && make install에 해당하는 전 과정이 자동으로 붙어요.
3.2 자주 만나는 클래스들
공식 문서(Concepts)가 예시로 드는 클래스만 봐도 역할이 그려져요: autotools*(Autotools 빌드 공통 절차), deploy(산출물 배포), insane(패키지 품질 QA 검사), testimage(이미지 테스트), sstate(공유 상태 캐시 처리). 나중에 커스텀 이미지를 만들 때도 inherit core-image 식으로 클래스 상속이 계속 등장하니, "클래스 = 공통 빌드 로직의 부품"이라는 감각만 잡아두면 됩니다.
build/conf/local.conf — 사용자 설정. MACHINE(타깃 보드), DL_DIR(소스 캐시), PACKAGE_CLASSES(RPM/DEB/IPK) 같은 내 빌드 환경 결정
build/conf/bblayers.conf — "이번 빌드에 어떤 레이어들을 쓸 것인가"의 목록
conf/machine/*.conf (BSP 레이어 안) — 프로세서·부트로더·커널 등 하드웨어 설정
conf/distro/*.conf (Distro 레이어 안) — 배포판 정책 (예: meta-poky/conf/distro/poky.conf)
conf/layer.conf (모든 레이어 안) — 레이어 자신의 등록 정보와 우선순위
4.2 누가 이기는가 — 로딩 순서와 우선순위
같은 변수를 여러 곳에서 정의하면 어떻게 될까요? 공식 문서는 설정 파일이 site.conf → auto.conf → local.conf 순서로 읽히고, 뒤에 읽힌 값이 덮어쓴다고 설명해요. 또 하나 중요한 규칙 — 배포판 정책 파일의 설정은 local.conf의 같은 설정을 이깁니다:
"Settings you provide in conf/distro/distro.conf override similar settings that BitBake finds in your conf/local.conf." — 같은 문서
"local.conf에서 바꿨는데 안 먹힌다"는 단골 증상의 원인이 대부분 여기 있어요. 6회차(local.conf·bblayers.conf)에서 변수 단위로 자세히 다룹니다.
5. .bbappend와 레이어 우선순위 — 원본을 안 건드리는 수정
5.1 .bbappend의 병합 동작
벤더 레이어의 레시피에 패치 하나만 추가하고 싶을 때, 원본 .bb를 직접 고치면 벤더 업데이트 때마다 충돌 지옥이 열립니다. 대신 내 레이어에 같은 이름의 .bbappend 파일을 만들면 BitBake가 원본 레시피를 읽은 뒤 그 내용을 이어 붙여요.
"Files that append build information to a recipe file." — 같은 용어집
파일명 규칙은 원본과 같은 루트 이름이어야 해요. 버전 자리에 % 와일드카드를 쓴 busybox_%.bbappend는 busybox의 어느 버전 레시피에든 적용됩니다 — 벤더가 버전을 올려도 append가 계속 따라붙게 하는 실무 표준 패턴이에요.
5.2 여러 레이어가 겹치면 — BBFILE_PRIORITY
같은 레시피에 여러 레이어가 .bbappend를 붙이면 레이어 우선순위(BBFILE_PRIORITY, 각 레이어의 layer.conf에 정의) 순서대로 차례차례 적용돼요. 숫자가 클수록 우선순위가 높아 나중에 적용되고, 최종 값을 결정합니다.
📌 실무 팁 — "내 bbappend가 안 먹는다" 싶으면 십중팔구 ① 파일명 루트가 원본과 다르거나 ② 다른 레이어가 더 높은 우선순위로 같은 변수를 덮은 경우예요. bitbake-layers show-appends (8회차 예정)로 어떤 append들이 어떤 순서로 붙는지 즉시 확인할 수 있습니다.
6. 🧪 직접 해보기
1회차에서 클론한 poky 트리에서 오늘 배운 네 가지 파일을 전부 눈으로 찾아봅시다. 파일 위치는 공식 문서 Yocto Project Concepts의 표준 레이어 구조 설명을 따른 것이에요.
cd poky
# 1. 레시피(.bb) — busybox의 빌드 설명서 찾기
ls meta/recipes-core/busybox/
# busybox_x.y.z.bb 파일명에서 이름_버전 규칙 확인
# 2. 클래스(.bbclass) — 공통 로직 부품 창고
ls meta/classes*
# autotools.bbclass, cmake.bbclass 등이 보이는지 확인
# 3. 설정(.conf) — 배포판 정책과 레이어 등록 정보
head -30 meta-poky/conf/distro/poky.conf # Poky 배포판 정책
cat meta-poky/conf/layer.conf # BBFILE_PRIORITY 항목 찾아보기
# 4. 어펜드(.bbappend) — 원본을 안 건드리는 수정의 실례
find . -name "*.bbappend" | head
기대 결과: 1번에서 busybox_버전.bb 파일명 규칙을, 2번에서 클래스 파일들을, 3번의 layer.conf에서 BBFILE_PRIORITY_yocto 같은 우선순위 정의를, 4번에서 실제 .bbappend 파일 경로들을 확인하면 오늘 배운 네 파일을 모두 실물로 본 것입니다.
✍️ 내 실행 결과
busybox 레시피
bbclass
poky.conf 배포판 정책
.bbappend 파일
마무리
오늘은 Yocto 메타데이터의 네 기둥을 정리했어요 — 레시피(.bb)는 패키지 하나의 빌드 설명서, 클래스(.bbclass)는 inherit로 재사용하는 공통 로직, 설정(.conf)은 위치에 따라 역할이 나뉘는 전역 변수, 어펜드(.bbappend)는 원본을 건드리지 않는 수정 수단. 다음 3회차에서는 이 재료들이 실제로 빌드될 때 내부에서 무슨 일이 벌어지는지 — 태스크 파이프라인(fetch→unpack→patch→…)과 sstate 캐시 — 를 따라가 봅니다.
