seukseok의 개인 블로그

Linux 드라이버 채용 공고를 읽으면 보이는 것들, 요즘 BSP 엔지니어에게 실제로 필요한 기술

· tech

임베디드 리눅스 채용 공고를 보다 보면 어느 순간 비슷한 단어들이 반복해서 눈에 들어온다.

BSP, board bring-up, device tree, U-Boot, Yocto, kernel debug.

겉으로는 “리눅스 가능한 엔지니어”를 찾는 것처럼 보이지만, 공고를 조금만 뜯어보면 기업들이 보고 있는 사람은 훨씬 더 선명하다. 단순히 드라이버 API를 아는 사람이 아니라, 하드웨어가 처음 켜지는 순간부터 운영체제가 장치를 인식하고 안정적으로 동작할 때까지의 전체 경로를 책임질 수 있는 사람을 찾고 있다.

이 글은 2026년 4월 26일 기준으로 공개 확인 가능한 채용 공고와 공식 문서를 바탕으로, 요즘 Linux BSP 엔지니어 채용이 실제로 어떤 역량을 요구하는지 정리한 글이다.

결론 먼저

공고들을 쭉 읽고 나면 결론은 꽤 단순하다.

기업들은 “커널을 공부해본 사람”보다, 실제 보드를 부팅시키고 문제를 좁혀가며 제품 수준으로 안정화할 수 있는 사람을 찾고 있다.

그 과정에서 반복해서 등장하는 역량도 비슷하다.

채용 공고를 보면 역할 범위가 먼저 보인다

2026년 4월 26일 기준으로 확인한 공개 공고들을 보면, 회사는 달라도 요구하는 역할 범위는 꽤 비슷하다.

Samsung Careers, Linux BSP Engineer

Samsung Careers의 Linux BSP Engineer 공고는 ARM 기반 SoC 이해, bare-metal/firmware 개발, LPDDR5/HBM3 bring-up, Zebu emulation, post-silicon board bring-up, trace32 기반 디버깅을 핵심 역량으로 적고 있다.

여기서 보이는 건 단순한 드라이버 수정 역할이 아니다. 메모리 초기화, 보드 활성화, 실리콘 이후 검증, 디버깅 툴 숙련도까지 요구사항 안에 들어간다. 다시 말해, 커널 안쪽 코드만 보는 역할이 아니라 플랫폼이 실제로 살아 움직이게 만드는 역할에 가깝다.

GreenWave Radios, Lead Engineer Embedded Linux BSP

GreenWave Radios의 공고는 더 직접적이다. board bring-up, DDR training, FSBL, TF-A, U-Boot, DTS 작성, Yocto 기반 BSP, 커널 드라이버, JTAG/GDB/ftrace/perf 디버깅, secure boot와 OTA 지원까지 한 덩어리로 묶어 요구한다.

이쯤 되면 “Linux BSP”는 단일 모듈 개발이 아니라, 플랫폼 소프트웨어 전체를 제품 수준으로 끌고 가는 역할이라고 보는 편이 맞다.

BrightAI, Staff Embedded Software Engineer

BrightAI의 공고도 결은 같다. 기존 Yocto 기반 embedded Linux distribution을 유지·확장하고, BSP, bootloader, kernel, device tree, board bring-up, reliability, boot time, long-term support를 함께 다룰 수 있는 사람을 찾는다.

특히 인상적인 건 “새로 만드는 능력”보다, 운영 중인 시스템을 계속 버티게 만드는 능력에 더 무게가 실려 있다는 점이다.

Device Tree를 안다는 건 문법을 아는 게 아니다

Linux Kernel 공식 문서는 Device Tree를 운영체제가 하드웨어를 하드코딩 없이 이해하도록 만드는 데이터 구조로 설명한다. 중요한 건 이게 단순 설정 파일이 아니라, 커널과 하드웨어 사이의 계약서라는 점이다.

그래서 채용 공고에서 device tree가 나온다는 건 보통 이런 질문에 가깝다.

실무에서는 DTS 문법을 아는 것만으로는 부족하다. 왜 이 노드가 올라오지 않는지, 왜 드라이버가 bind되지 않는지, 왜 인터럽트가 안 터지는지를 설명할 수 있어야 비로소 실력이 된다.

U-Boot와 부트 체인을 모르면 “왜 안 켜지는지”를 설명하기 어렵다

U-Boot 공식 문서도 devicetree를 부트로더 설정의 핵심 구조로 다룬다. 이 말은 곧 BSP 엔지니어의 책임 범위가 커널 이후에만 머물지 않는다는 뜻이기도 하다.

실제로는 아래가 한 흐름으로 연결된다.

문제는 이 중 한 군데만 틀어져도 겉으로 보이는 증상은 비슷하다는 데 있다. “부팅이 안 된다”는 한 줄짜리 문제 뒤에 DDR training 실패, 잘못된 DTS, clock 설정 오류, bootargs 문제, rootfs mount 실패가 다 숨어 있을 수 있다.

그래서 좋은 BSP 엔지니어는 단순히 코드를 많이 쓰는 사람이 아니라, 부팅 실패를 단계별로 쪼개고 관찰 가능한 증상으로 바꿀 수 있는 사람인 경우가 많다.

요즘 공고에서 BSP는 드라이버 한 장이 아니라 플랫폼 유지 능력에 가깝다

BrightAI 공고에서 특히 눈에 띄는 지점은, “새 배포판을 한 번 만드는 일”보다 이미 운영 중인 Yocto 기반 배포판을 유지하고 확장하는 일에 초점을 맞춘다는 점이다.

Yocto Project 공식 문서도 Yocto를 임베디드 제품용 맞춤형 Linux 시스템을 만들기 위한 도구로 설명한다. 그래서 공고에 Yocto가 반복해서 등장한다는 건, 기업들이 단발성 bring-up보다 다음 하드웨어 리비전과 그다음 유지보수까지 같이 보는 사람을 원한다는 뜻에 가깝다.

요즘 BSP 역할은 대체로 아래를 함께 묶는다.

즉, BSP는 “처음 한 번 띄우는 사람”보다 다음 버전에서도 다시 재현 가능하게 만드는 사람 쪽으로 정의가 바뀌고 있다.

결국 차이는 무엇을 아느냐보다 어떻게 증명하느냐에서 난다

이런 공고들을 보면 공통적으로 좋아하는 흔적이 있다.

그래서 포트폴리오도 방향이 달라져야 한다.

단순히 “리눅스 드라이버를 공부했습니다”보다 아래가 훨씬 강하다.

  1. 어떤 보드 또는 타깃 환경이 있었는지
  2. 어떤 문제가 있었는지
  3. 원인을 어떻게 좁혔는지
  4. 무엇을 수정했는지
  5. 어떻게 재검증했는지

예를 들면 이런 식이다.

채용 공고가 요구하는 건 화려한 키워드의 양이 아니라, 시스템을 실제로 다뤄본 흔적이다.

이 흐름에서 지금 준비하면 좋은 것들

만약 지금 Linux BSP나 low-level embedded Linux 쪽을 준비하고 있다면, 아래처럼 정리하는 편이 훨씬 낫다.

1) 장치 하나를 끝까지 살려본 기록 만들기

USB, UART, I2C 센서, Ethernet MAC, display 중 하나라도 좋다. 중요한 건 “붙였다”가 아니라 왜 안 됐고, 어떻게 해결했는지가 남아 있어야 한다는 점이다.

2) DTS와 boot log를 같이 읽는 습관 만들기

이 영역은 코드만 보는 습관으로는 한계가 빨리 온다. dmesg, serial log, boot stage별 메시지를 같이 놓고 어디에서 무너졌는지 나눠서 보는 훈련이 중요하다.

3) Yocto를 빌드 도구가 아니라 운영 구조로 보기

bitbake를 한 번 돌려본 경험보다, layer를 어떻게 나누고 recipe를 어떻게 관리하고 이미지를 어떻게 재현 가능하게 유지하는지 설명할 수 있는 쪽이 훨씬 강하다.

4) 작은 CI라도 붙여두기

커널 전체 CI가 아니어도 된다. 빌드가 다시 되는지, 산출물이 유지되는지, 최소한 어떤 버전 조합에서 성공했는지를 남겨두면 인터뷰에서 설명력이 확 올라간다.

마무리

2026년 4월 26일 기준 공개 채용 공고들을 보면, Linux BSP/드라이버 영역은 여전히 꽤 명확한 언어를 갖고 있다.

핵심은 화려한 키워드가 아니다.

결국 이 분야에서 강한 사람은 “커널을 안다”에서 끝나지 않는다.

보드를 살리고, 로그를 읽고, 원인을 좁히고, 다시 재현할 수 있게 만드는 사람.

지금 BSP 채용 공고들이 반복해서 찾는 사람도 거의 정확히 그 사람이다.

참고 자료