임베디드기사 실기 06 — 임베디드 OS 이해·포팅 (커널 빌드·부트로더·교차개발·크로스 컴파일)

임베디드기사 실기 06 — 임베디드 OS 이해·포팅 (커널 빌드·부트로더·교차개발·크로스 컴파일)

출제기준 2-2: 임베디드 OS 이해 및 포팅하기
교차개발 환경은 11회차 중 6번 나온 최빈출 개념이에요.
"개발 환경과 실행 환경이 다르다" 한 줄만은 확실하게!

---

📎 필기 시리즈의 OS 포팅 편과 함께 보면 좋아요. (링크 추가 예정)

---

실기 출제 포인트 ⭐⭐⭐

키워드	핵심 내용	빈도	기출
교차 개발 환경	호스트와 타깃이 서로 다른 플랫폼	⭐⭐⭐	2016 Q4, 2017 Q16, 2019 Q9, 2020 Q10, 2021 Q9, 2023 Q2
크로스 컴파일러	다른 플랫폼용 코드를 생성하는 컴파일러	⭐⭐⭐	2016 Q4, 2020 Q10, 2023 Q2
크로스 컴파일 옵션	-c(오브젝트까지), -o(출력 이름)	⭐	2025 Q17
커널 구성	defconfig, Kconfig, .config	⭐⭐	2019 Q15
커널 디버깅 옵션	CONFIG_DEBUG_*	⭐	2018 Q16
빌드 과정	전처리 → 컴파일 → 어셈블 → 링킹	⭐⭐	2024 Q17
부트로더	U-Boot, GRUB / 커널 적재·제어 이양	⭐⭐	2018 Q7, 2019 Q13
TFTP	UDP 69, 부트로더에서 커널 이미지 전송	⭐	2017 Q9
원격 디버깅	gdb 원격 접속	기출 없음	보강

 

 

키워드 박스 — 답안에 반드시 들어가야 할 단어

교차 개발 환경 : 호스트(PC)와 타깃(임베디드 보드)이 서로 다른 플랫폼 / 개발 환경 ≠ 실행 환경
크로스 컴파일러 : 컴파일하는 컴퓨터와 실행하는 컴퓨터의 기종이 다를 때 사용
defconfig      : 보드별 기본 설정 모음
Kconfig        : 메뉴 구성과 의존 관계 정의
.config        : 최종 커널 설정 파일 (빌드가 읽는 파일)

---

교차 개발 환경과 크로스 컴파일러 ⭐⭐⭐

임베디드 보드는 자원이 작아서 보드 안에서 직접 컴파일하기 어려워요.

그래서 PC에서 코드를 만들고 보드로 옮겨 실행하는데, 이 구조가 교차 개발이에요.

호스트 시스템 (PC, 워크스테이션)  ──크로스 컴파일──▶  타깃 시스템 (임베디드 보드)
  x86, 개발 도구가 있는 환경                         ARM 등, 프로그램이 실행되는 환경

 

개념 구분 (문제 표현이 다르니 꼭 구분!)

질문 표현	정답
"호스트 시스템과 타깃 시스템이 서로 다른 플랫폼일 때의 개발환경"	교차 개발 환경 (Cross Development Environment)
"교차개발환경이란?"	개발 환경과 실행 환경이 상이하다
"번역하는 컴퓨터와 실행하는 컴퓨터가 서로 다른 기종일 때 사용하는 컴파일러"	크로스 컴파일러 (Cross Compiler)
"컴파일러가 실행되는 플랫폼이 아닌 다른 플랫폼에서도 실행 가능한 코드를 생성하는 컴파일러"	크로스 컴파일러

 

기출 (2017 Q16 = 2019 Q9 동일) 프로그램을 개발하는 호스트 시스템과 실행되는 타깃 시스템이 서로 다른 플랫폼일 때, 이러한 개발환경은?
→ 교차 개발 환경 (Cross Development Environment)

 

기출 (2020 Q10 = 2023 Q2 동일) 원시 프로그램의 번역이 이루어지는 컴퓨터와 번역된 기계어가 쓰이는 컴퓨터가 서로 다른 기종일 때 사용하는 컴파일러는?
→ 크로스 컴파일러 (Cross Compiler)

 

⚠️ 함정: "환경"을 묻는데 "크로스 컴파일러"라고 쓰거나, "컴파일러"를 묻는데 "교차 개발 환경"이라고 쓰면 오답이에요. 끝말(환경/컴파일러)을 꼭 확인!

 

크로스 컴파일 옵션

기출 (2025 Q17) 리눅스에서 크로스 컴파일할 때, 오브젝트 파일을 생성하는 옵션과 링크된 실행 파일까지 생성하는 옵션은?
→ -c 옵션 / -o 옵션

arm-linux-gcc -c main.c                       → main.o  (링크 안 함)
arm-linux-gcc main.o driver.o -o firmware     → firmware (링크해서 실행 파일)
arm-linux-gcc main.c driver.c -o firmware     → 컴파일+링크를 한 번에

 

⚠️ 엄밀히 -o는 출력 파일 이름을 지정하는 옵션이에요.

링크까지 수행하는 건 -c를 쓰지 않았기 때문이고, 시험 답안은 "-c / -o" 로 쓰면 됩니다.

 

컴파일 과정

기출 (2024 Q17) 고급언어로 작성된 프로그램을 기계어로 번역하는 과정은?
→ 컴파일 (Compilation)

전처리(Preprocessing) → 컴파일(Compilation) → 어셈블링(Assembling) → 링킹(Linking)

---

커널 포팅 과정 ⭐⭐

커널 포팅은 내 보드에 맞게 커널을 설정하고 빌드하고 올리는 일이에요. 큰 흐름은 이렇습니다.

1. 호스트 PC에 크로스 툴체인 준비
2. 보드용 기본 설정 불러오기      → make <board>_defconfig
3. 필요하면 설정 수정             → make menuconfig  (메뉴는 Kconfig가 정의)
4. 최종 설정 파일 생성            → .config
5. 커널 빌드                     → make  →  zImage / uImage
6. 부트로더로 보드에 이미지 적재·실행

 

커널 설정 파일 3종 세트

기출 (2019 Q15) 커널 빌드 프로세스 흐름도의 빈칸 A, B, C를 채우시오.

Target Board Default Config ( A ) ──▶ Kernel Menu Structure ( B ) ──▶ Generated Main Configuration ( C )
                                                                              │ make
                                                                              ▼
                                                                        zImage / uImage

A. defconfig (_defconfig) / B. Kconfig / C. .config

파일	역할	위치/특징
defconfig	특정 보드·칩셋에 맞춘 기본 설정 값 모음	arch/arm/configs/ 등
Kconfig	menuconfig에 보이는 메뉴 구성과 드라이버 간 의존 관계 정의	각 디렉터리에 존재
.config	최종 커널 설정 파일	커널 최상위 디렉터리, 빌드 시 CONFIG_XXX=y/m 값을 읽음

 

⚠️ 이 문제는 "예상문제" 형태로 정리돼 있어서 빈칸 위치가 바뀌어도 풀 수 있게 세 파일의 역할을 구분해서 외우세요.

 

커널 디버깅 옵션 (2018 Q16)

리눅스 커널 원자성 디버깅 강화 파라미터를 설명하는 문제예요.

옵션	설명
CONFIG_DEBUG_PREEMPT	선점(Preemption) 관련 코딩 오류 감지
CONFIG_DEBUG_KERNEL	커널 디버깅 옵션들의 최상위 스위치
CONFIG_DEBUG_KALLSYMS	디버깅용으로 커널 심볼 정보를 상세 유지
CONFIG_DEBUG_SPINLOCK_SLEEP	스핀락을 잡은 상태에서 sleep 유발 코드 호출 검사

---

부트로더 ⭐⭐

기출 (2018 Q7 / 2019 Q13) 압축된 커널 이미지를 RAM에 올리고 커널로 실행을 넘기는 것은?
→ 부트로더

부트로더 종류 : U-Boot, GRUB, BLOB, BOOTLDR
역할          : CPU·메모리 초기화 → 커널 이미지를 RAM으로 복사 → 커널로 점프

 

TFTP (Trivial File Transfer Protocol)

기출 (2017 Q9) UDP를 기반으로 하며 인증 기능 없이 간단한 파일 전송만 지원하는 가벼운 프로토콜은?
→ TFTP (UDP 69번 포트)

 

임베디드 개발에서는 호스트 PC의 TFTP 서버에서 부트로더가 커널 이미지를 받아오는 방식이 흔해서 이 단원과 함께 외워두면 좋아요.

호스트 PC (TFTP 서버, 커널 이미지) ──UDP 69──▶ 타깃 보드의 부트로더(U-Boot) ──▶ RAM에 적재 ──▶ 커널 실행

---

기출 없음 — 개념 보강 📌

원격 디버깅 : 호스트의 gdb가 타깃 보드의 gdbserver(또는 JTAG)에 접속해서
              소스 레벨로 디버깅. 크로스 환경에서는 타깃용 gdb(arm-linux-gdb 등)를 사용

---

기출 문제 모음

Q. 호스트 시스템과 타깃 시스템이 서로 다른 플랫폼일 때의 개발 환경은? (2017·2019)
A. 교차 개발 환경

 

Q. 번역하는 컴퓨터와 실행하는 컴퓨터가 서로 다른 기종일 때 사용하는 컴파일러는? (2020·2023)
A. 크로스 컴파일러

 

Q. 교차개발환경이란? (2021 Q9)
A. 개발 환경과 실행 환경이 상이하다

 

Q. 크로스 컴파일에서 오브젝트 파일 생성 옵션과 실행 파일 생성 옵션은? (2025 Q17)
A. -c / -o

 

Q. 커널 빌드 흐름의 defconfig → ( B ) → ( C ) 에서 B, C는? (2019 Q15)
A. B = Kconfig, C = .config

 

Q. UDP 기반으로 인증 없이 파일만 전송하는 프로토콜은? (2017 Q9)
A. TFTP

---

💡 실무에서는?

• 교차개발 — ARM 서버·엣지 장비용 바이너리를 x86 빌드 서버에서 만드는 크로스 빌드(예: CI에서 멀티 아키텍처 빌드)가 실무의 같은 개념이에요.
• TFTP/PXE — 서버 대량 배포에서 PXE 부팅이 DHCP + TFTP로 부트로더와 커널을 내려받는 방식이라, 임베디드 개발의 TFTP 부팅과 구조가 같습니다.
• 커널 설정 — 서버 커널 튜닝·보안 하드닝에서 .config의 CONFIG_ 옵션을 켜고 끄는 일이 자주 있어요.
• 보안 관점 — 부트로더·커널 이미지의 무결성(서명) 검증은 보안 시스템 구축에서 신뢰의 시작점(Root of Trust)이 됩니다.

---

핵심 정리

✅ 교차 개발 환경 = 호스트와 타깃이 다른 플랫폼 (개발 환경 ≠ 실행 환경)
✅ 크로스 컴파일러 = 다른 기종에서 실행할 코드를 생성하는 컴파일러
✅ 크로스 컴파일 옵션: -c (오브젝트 파일까지) / -o (출력 이름 지정)
✅ 컴파일 4단계: 전처리 → 컴파일 → 어셈블 → 링킹
✅ 커널 설정: defconfig(보드 기본값) → Kconfig(메뉴·의존성) → .config(최종) → make → zImage/uImage
✅ 부트로더 = 커널 이미지를 RAM에 복사하고 점프 (U-Boot, GRUB)
✅ TFTP = UDP 69, 인증 없는 간단한 파일 전송 (커널 이미지 전송에 사용)

 

다음 편에서는 디바이스 드라이버 작성(출제기준 2-3)으로 이어갑니다!

 

궁금한 점은 댓글로 남겨주세요!