Yocto를 공부하겠다고 마음먹은 분들이 의외로 첫 빌드보다 먼저 좌절하는 지점이 있어요. 바로 개발 환경 준비입니다. 디스크가 모자라서 빌드가 중간에 죽고, 배포판 기본 도구 버전이 낮아서 알 수 없는 에러를 만나고, 패키지 하나가 빠져서 몇 시간을 헤매는 일이 실제로 흔합니다. 이번 회차에서는 공식 문서의 시스템 요구사항을 기준으로, 빌드 호스트를 제대로 준비하고 poky 소스를 받는 데까지를 차근차근 정리할게요.
3회차에서 봤듯이 Yocto 빌드는 단순한 애플리케이션 컴파일이 아니라, 크로스 툴체인부터 커널·루트파일시스템까지 배포판 전체를 소스에서 빌드하는 작업이에요. 수백 개의 레시피가 각각 fetch·compile·package 태스크를 거치니, 디스크와 CPU를 어마어마하게 소비합니다. 실무에서 빌드 서버 사양 산정을 잘못하면 팀 전체의 빌드 대기 시간이 늘어나고, 개인 노트북에서는 디스크 풀로 빌드가 중간에 죽는 사고가 잦아요. 그래서 공식 문서도 매뉴얼 첫머리에서 시스템 요구사항부터 다룹니다.
다행히 준비물 자체는 단출해요. 이 시리즈의 실습은 실제 보드 없이 QEMU(에뮬레이터) 타깃으로 진행할 수 있어서, 사양을 충족하는 리눅스 PC 한 대면 충분합니다. 타깃 하드웨어가 없어도 5회차의 첫 빌드와 부팅까지 전부 따라 할 수 있어요.
RAM은 "4코어 구형 시스템에서 8GB 정도로도 core-image-sato 빌드가 가능하다"고 안내해요. 다만 이건 어디까지나 하한선입니다. 빌드는 코어 수만큼 병렬로 돌기 때문에 코어가 많을수록, RAM이 넉넉할수록 빌드 시간이 눈에 띄게 줄어요. 디스크도 이미지 몇 종을 빌드하고 sstate 캐시(3회차 참고)가 쌓이기 시작하면 90GB는 금방 찹니다.
CPU는 "몇 코어 이상"이라는 명시적 하한이 없는 대신, 코어 수가 빌드 시간을 사실상 결정해요. BitBake는 서로 의존성이 없는 태스크들을 동시에 실행하고(BB_NUMBER_THREADS), 개별 레시피의 컴파일도 make -j 방식의 병렬 빌드(PARALLEL_MAKE)로 돌기 때문이에요. 두 변수의 기본값은 호스트 코어 수를 따라가므로 코어가 많은 만큼 그대로 이득을 봅니다(상세 설정은 6회차에서 다뤄요). 스토리지는 작은 파일을 대량으로 만들고 지우는 워크로드 특성상 HDD보다 SSD에서 체감 차이가 큽니다.
ℹ️ 버전 참고 — 최신 개발판(6.0-tip, 릴리스 6.0.2 "Wrynose") 문서는 같은 문장에서 디스크 140GB, RAM 32GB로 기준을 올려 잡았어요. 세대가 갈수록 빌드 대상이 커진다는 뜻이니, 새로 장비를 준비한다면 여유 있게 잡는 편이 안전합니다.
1.3 Windows 사용자라면 — WSL 2와 가상 머신
Yocto 빌드 호스트는 리눅스여야 해요. Windows에서 작업하는 분이라면 WSL 2가 현실적인 선택지인데, 공식 문서도 이를 언급하고 있습니다.
"You may use Windows Subsystem For Linux v2 to set up a build host using Windows 10 or later, or Windows Server 2019 or later, but validation is not performed against build hosts using WSL 2." — System Requirements
즉 WSL 2로 빌드는 가능하지만, Yocto 프로젝트가 공식 검증(validation)을 수행하는 환경은 아니에요. 회사 CI나 팀 공용 빌드는 네이티브 리눅스 서버로 두고, WSL 2는 개인 학습·간단한 검증 용도로 쓰는 구분이 실무적으로 무난합니다. WSL 2 안에서도 이 글의 디스크·패키지·도구 버전 체크리스트는 그대로 적용되니, 아래 2장의 절차를 동일하게 따라 하면 돼요. WSL 2 사용 시 추가 주의점은 Development Tasks Manual의 "Setting Up to Use Windows Subsystem For Linux (WSL 2)" 섹션에 따로 정리되어 있어요.
가상 머신(VMware·VirtualBox 등)도 마찬가지로 사용할 수는 있지만, 디스크 I/O가 병목이 되기 쉬운 워크로드라 네이티브 설치 대비 빌드 시간 손해를 감안해야 합니다. 어느 쪽이든 "리눅스 환경 + 요구 사양 충족"이라는 원칙은 같아요.
2. 지원 배포판과 필수 패키지 설치
2.1 어떤 배포판을 쓰는 게 좋은가
Yocto는 임의의 리눅스에서 돌 수도 있지만, 프로젝트가 공식적으로 테스트하는 배포판 목록이 릴리스마다 정해져 있어요. LTS(scarthgap) 문서의 지원 목록에는 대표적으로 Ubuntu 22.04 LTS·24.04 LTS, Debian 11·12, Fedora 39·40·41, AlmaLinux 8·9, Rocky Linux 8·9, CentOS Stream 9가 올라 있습니다(전체 목록은 참고 링크의 문서에서 확인하세요). 목록에 없는 배포판에서도 빌드가 되는 경우는 많지만, 문제가 생겼을 때 "지원 배포판에서 재현되는가"부터 물어보는 게 커뮤니티의 관례예요.
실무에서 특별한 이유가 없다면 Ubuntu LTS를 권해요. 사용자가 가장 많아 검색으로 해결되는 문제가 많고, BSP 벤더들의 문서도 대부분 Ubuntu 기준으로 쓰여 있기 때문입니다. 팀 단위로 일한다면 빌드 호스트 배포판을 하나로 통일하는 것도 중요해요. 호스트마다 도구 버전이 제각각이면 native 도구 재빌드가 늘어나는 등 빌드 결과에 미묘한 편차가 생겨서, "내 자리에서는 되는데" 류의 소모적인 디버깅으로 이어지기 쉽습니다.
2.2 필수 도구 최소 버전
빌드 호스트에는 아래 도구들이 최소 버전 이상으로 설치되어 있어야 해요(scarthgap 기준).
Git 1.8.3.1 이상
tar 1.28 이상
Python 3.8.0 이상
GCC 8.0 이상
GNU make 4.0 이상
이 다섯 가지가 굳이 콕 집혀 있는 데에는 이유가 있어요. BitBake 자체가 Python 프로그램이고, 소스 코드 대부분을 Git과 tar(아카이브 해제)로 가져오며, 크로스 툴체인을 만드는 첫 단계는 호스트의 GCC와 make로 부트스트랩되기 때문이에요. 즉 이 도구들은 "있으면 좋은 것"이 아니라 빌드 시스템이 딛고 서는 뼈대입니다.
요즘 배포판이라면 대부분 충족하지만, 회사에서 오래 쓰는 빌드 서버(구형 CentOS 등)는 걸리는 경우가 있어요. 버전 확인은 각 도구에 --version을 붙여 보면 됩니다. 미달이어도 방법이 있으니(3장 buildtools) 호스트 OS를 갈아엎을 필요는 없어요.
ℹ️ 버전 참고 — 6.0-tip 기준으로는 Python 3.9.0, GCC 10.1로 요구 버전이 올라갔어요. Git·tar·make 기준은 동일합니다.
2.3 Ubuntu/Debian 패키지 설치와 로케일
지원 배포판을 골랐다면 빌드에 필요한 호스트 패키지를 설치합니다. Ubuntu/Debian 기준 공식 명령은 이거예요.
목록을 잠깐 뜯어보면 성격이 보여요. build-essential·gcc는 native 도구를 빌드할 호스트 컴파일러, python3-git·python3-jinja2 같은 python3-* 계열은 BitBake와 지원 스크립트가 쓰는 라이브러리, xz-utils·zstd·liblz4-tool은 소스 아카이브와 sstate 캐시에 쓰이는 압축 도구입니다. 하나쯤 빠져도 빌드 어딘가에서 반드시 티가 나니, 목록을 골라내지 말고 전체를 그대로 설치하는 걸 권해요.
한 가지 놓치기 쉬운 게 로케일이에요. 빌드 시스템은 en_US.utf8 로케일이 필요해서, 최소 설치한 서버라면 아래처럼 확인하고 없으면 활성화해야 합니다.
Fedora·openSUSE·AlmaLinux는 패키지 이름 체계가 달라서 설치 명령이 각각 달라요. 아래는 공식 문서 "Required Packages for the Build Host"에 실린 배포판별 명령 전문입니다. Ubuntu 목록과 비교해 보면 차이가 눈에 들어와요 — RPM 계열 목록에는 perl-Data-Dumper 같은 perl 모듈들이 개별 패키지로 나열되어 있고, 압축 도구도 xz-utils 대신 xz처럼 이름이 다릅니다. 자기 배포판 목록을 그대로 전부 설치하면 됩니다.
사내 빌드 서버가 구형 배포판이라 Python이나 GCC 버전이 요구사항에 못 미치는 상황, 임베디드 현장에서는 드물지 않아요. 이럴 때 호스트 OS를 업그레이드하는 대신 쓰라고 Yocto가 제공하는 것이 buildtools tarball입니다. 요구 버전을 충족하는 Git·tar·Python 등의 도구 모음을 홈 디렉터리 아래에 설치하고, 환경 스크립트를 source하면 그 셸에서만 새 도구들이 PATH 앞에 잡히는 방식이에요. 호스트 시스템을 건드리지 않으니 다른 업무와 충돌할 걱정이 없습니다.
GCC까지 포함한 확장판은 buildtools-extended tarball이라고 불러요. 컴파일러 버전이 걸리는 경우에는 이쪽을 설치합니다. 설치 경로도 여러 가지예요 — poky에 포함된 install-buildtools 스크립트로 자동 설치하는 방법(아래에서 소개, 권장), downloads.yoctoproject.org 릴리스 페이지에서 사전 빌드된 tarball을 직접 받아 실행하는 방법, 그리고 요구사항을 충족하는 다른 머신에서 bitbake buildtools-tarball로 직접 만들어 배포하는 방법이 있어요. 결과물이 자기 완결적인 설치 스크립트(.sh)라서, 외부망이 막힌 폐쇄망 빌드 서버에도 파일 복사만으로 넣을 수 있다는 점이 실무에서 특히 유용합니다.
3.2 install-buildtools 스크립트 사용법
poky 소스를 받았다면(4장) 그 안의 스크립트로 간단히 설치할 수 있어요. 공식 문서의 명령을 그대로 옮깁니다.
⚠️ 공식 문서와 다른 점 — 프로토콜은 반드시 https:// — Quick Build 문서는 이 명령을 git clone git://git.yoctoproject.org/poky로 싣고 있지만, 그대로 실행하면 지금은 실패합니다. git://는 HTTP가 아니라 git daemon 전용 프로토콜(9418 포트)인데, git.yoctoproject.org가 CDN 뒤로 이동하면서 이 포트를 더 이상 받지 않기 때문이에요. 증상은 아래처럼 응답 없는 타임아웃입니다.
fatal: unable to connect to git.yoctoproject.org: git.yoctoproject.org[0: 104.18.1.115]: errno=Connection timed out
실패한 IP가 CDN 대역(104.18.x.x)이라는 점이 단서예요. 사내 방화벽이 막아서가 아니라 목적지에 그 포트로 응대할 서비스가 없어서 생기는 현상이라, 프록시 설정으로는 해결되지 않고 https://로 바꿔야 합니다. 뒤이어 나오는 Network is unreachable 줄은 IPv6 주소로도 시도했다가 IPv6 경로가 없어 즉시 실패한 것으로, 원인과는 무관해요.
여기서 중요한 건 두 번째 명령이에요. clone 직후의 기본 브랜치는 최신 개발 브랜치라서, 그대로 빌드하면 검증이 덜 된 코드를 쓰게 됩니다. 실무에서는 반드시 릴리스 브랜치(여기서는 LTS인 scarthgap)를 체크아웃해서 시작하세요. -t origin/scarthgap은 원격 브랜치를 추적하는 로컬 브랜치(my-scarthgap)를 만드는 옵션이라, 이후 git pull로 해당 릴리스의 버그 수정만 안전하게 받아올 수 있어요.
브랜치 이름은 릴리스 코드네임과 같아요. 이 시리즈가 기준으로 삼는 scarthgap(5.0)은 LTS 릴리스라 일반 릴리스보다 훨씬 긴 기간 버그·보안 수정을 받습니다. 수년을 유지보수해야 하는 제품이라면 시작 시점에 LTS 브랜치를 고르는 것이 기본기예요. 참고로 사내망에서는 https://조차 프록시를 거쳐야 하는 경우가 있는데, 그때는 git config --global http.proxy로 프록시를 지정하면 됩니다(빌드 중 소스 다운로드에도 프록시 설정이 필요하니, Yocto Project Wiki의 "Working Behind a Network Proxy" 문서를 함께 참고하세요).
4.2 받아진 디렉터리 훑어보기
clone이 끝나면 poky 최상위가 이렇게 생겼어요. 2회차에서 다룬 레이어 개념이 디렉터리로 그대로 보입니다.
2회차에서 "레이어는 메타데이터 묶음"이라고 정리했는데, meta/·meta-poky/·meta-yocto-bsp/가 바로 그 레이어들이에요. poky가 어떤 특별한 프로그램이 아니라 "BitBake + 레이어 몇 개를 한 저장소에 모아 둔 것"이라는 사실이 디렉터리 구조에서 그대로 드러납니다. 앞으로 벤더 BSP 레이어나 우리 팀의 커스텀 레이어를 추가할 때도, 이 구조 옆에 meta-무언가가 하나 더 늘어나는 그림을 떠올리면 돼요.
ℹ️ 버전 참고 — 6.0-tip의 Quick Build 문서는 poky를 직접 clone하는 대신 bitbake-setup init이라는 새 도구로 환경을 구성하는 방식으로 전면 개편됐어요(git clone https://git.openembedded.org/bitbake 후 ./bitbake/bin/bitbake-setup init). 기존 수동 방식도 여전히 지원되며, 새 방식은 다음 회차(첫 빌드)에서 병기해 소개할게요.
📌 실무 팁 — 빌드 디스크는 공식 최소치(90GB)의 두 배쯤 잡는 걸 권해요. 이미지 두세 종만 빌드해도 tmp/와 sstate 캐시가 순식간에 불어나고, 디스크 풀로 죽은 빌드는 원인 파악에 시간을 잡아먹기로 악명이 높습니다. 또 하나 — 다운로드 소스(DL_DIR)와 sstate 캐시(SSTATE_DIR)를 빌드 디렉터리 밖의 별도 경로에 두면, 빌드 디렉터리를 지워도 재다운로드·재빌드를 피할 수 있어요. 이 설정은 6회차(local.conf)에서 자세히 다룹니다.
여유 디스크와 메모리 확인: df -h . / free -h — 빌드에 쓸 파티션의 여유 공간이 90GB 이상, RAM이 8GB 이상인지 확인. 부족하면 1.2절의 요구사항을 다시 점검하세요.
도구 버전 확인: git --version; tar --version; python3 --version; gcc --version; make --version — 출력된 버전을 2.2절의 최소 버전(Git 1.8.3.1 / tar 1.28 / Python 3.8.0 / GCC 8.0 / make 4.0)과 비교. 하나라도 미달이면 3장의 buildtools를 적용합니다.
필수 패키지 설치: 자기 배포판에 맞는 절(2.3 Ubuntu/Debian, 2.4 Fedora·openSUSE·AlmaLinux)의 명령 실행 — 이미 설치된 패키지는 자동으로 건너뛰니 전체 목록 그대로 실행해도 안전해요.
로케일 확인: locale --all-locales | grep en_US.utf8 — 한 줄이라도 출력되면 통과. 아무것도 안 나오면 sudo dpkg-reconfigure locales로 en_US.UTF-8을 활성화합니다.
poky 클론: git clone https://git.yoctoproject.org/poky; cd poky; git checkout -t origin/scarthgap -b my-scarthgap — 완료 후 git branch로 현재 브랜치가 my-scarthgap인지, ls로 4.2절의 디렉터리들(bitbake, meta, meta-poky, oe-init-build-env 등)이 보이는지 확인하세요.
✍️ 내 실행 결과 — 1. 여유 디스크와 메모리 확인 2. 도구 버전 확인
3. 필수 패키지 설치
4. 로케일 확인
5. poky 클론
마무리
이번 회차에서는 빌드 호스트의 하드웨어 요구사항(디스크 90GB·RAM 8GB 이상, 여유 있게), 지원 배포판과 필수 패키지 설치, 도구 버전 미달 시의 buildtools, 그리고 poky 클론과 릴리스 브랜치 체크아웃까지 — 첫 빌드 직전까지의 준비를 마쳤어요. 요구사항 확인을 대충 넘기지 않는 것이 이후 몇 시간짜리 빌드 실패를 예방하는 가장 싼 보험입니다.
체크리스트로 요약하면 이래요. ① 지원 배포판(권장: Ubuntu LTS) 위에서 ② 디스크·RAM 여유 확인, ③ 배포판별 필수 패키지 설치와 en_US.utf8 로케일 활성화, ④ Git·tar·Python·GCC·make 버전 점검(미달 시 buildtools), ⑤ poky를 clone하고 릴리스 브랜치(scarthgap) 체크아웃. 여기까지 끝났다면 여러분의 머신은 이미 Yocto 빌드 호스트입니다.
다음 5회차에서는 드디어 source oe-init-build-env로 빌드 환경을 만들고, bitbake core-image-minimal로 첫 이미지를 빌드해 QEMU로 부팅까지 해볼 거예요. 6.0에서 도입된 bitbake-setup 방식도 함께 소개합니다.
