한국 개발업체에서 절대 리눅스 전문가가 될 수 없는 이유(1)

AustinKim 2023. 5. 10. 14:26

임베디드 리눅스 개발 업체에서 실제 있었던 일이다.

조직 책임자가 한 가지 명령을 내렸다.

| 업무 시간에 리눅스 커널 소스 코드를 보지 말아라

리눅스 커널 소스 코드는 개인 시간을 할애하면서 분석하는데 뭘 업무시간에 그런 걸 보냐는 소리다.

이게 임베디드 리눅스 프로젝트를 개발하는 부서장이 하는 소리다. 이 밖에 평소에 이 임베디드 리눅스 업체 관리자가 뇌깔리는 소리는 다음과 같다.

1. 리눅스 커널은 안정화된 코드이기 때문이 다 가져다 쓴다.

그러니 리눅스 커널을 보드에 잘 돌리는 기술만 익히면 된다. 이게 최근 임베디드 리눅스 개발의 추세다.

2. 리눅스 커널은 디바이스 드라이버가 지나다니는 통로일 뿐이다.

그 제반 기술을 익혀서 뭘하나? 문제가 나오지도 않는데 말이야.

3. 빌드 스크립트나 컴파일 환경을 잘 익혀서 다른 보드에 리눅스를 빨리 올리는 기술을 습득해라.

만약 리눅스 프로젝트 개발 도중 문제(커널 크래시, 스톨)가 발생하면 어떻게 하나? 관리자는 다음과 같이 주장한다.

" 커널 로그를 보고 리눅스 메일링 리스트에서 유사한 패치를 적용해라."

커널 로그를 보고 리눅스 메일링 리스트에서 유사한 패치를 적용하라고 한다.

물론 깊이 있는 문제 분석을 하지는 않는다.

안타깝지만 이 과정에서 깊이 있는 문제 분석을 하지는 않는다. 대신 커널 크래시가 발생했을 때 커널 로그만 보고 여러 가지 소설을 쓴다.

이건 메모리 불량일꺼야?

갑자기 전원에 문제가 생겼을 것이야?

물론 아무런 근거도 없다. 크래시 유틸리티나 T32와 같은 크래시 디버깅 툴을 쓸 생각 조차 하지 않는다.

문제가 발생하면 깊이 있는 분석을 할 능력이 없다.

그래도 문제가 발생했으니 안심 패치를 적용해야 고객사에게 그래도 정신적인 평온감을 주지 않을까?

그래서 리눅스 커널 패치 아무거나 반영하고 문제를 해결했다고 거짓말을 한다.

이런 방식으로 개발을 하는 이유가 뭘까?

임베디드 리눅스 개발 프로젝트 자체가 대부분 도전적이지 않고, 유지 보수만 하는 수준이기 때문에 커널 크래시나 스톨과 같은 문제가 거의 나오지 않는다. 혹시 이런 문제가 나온다고 해도 이런 방식으로 문제를 접근한다.

개발 문화

대부분 한국의 소프트웨어 개발 업체 문화가 이렇다.

"잘 되어 있는 소프트웨어를 가져다 쓴다."

소프트웨어를 새롭게 구현하고 개발하려는 생각이 없다. 즉, 소프트웨어에 대한 원천 기술 연구 개발 의지가 거세돼 있는 것이다.

그냥 잘 돌아가는 소프트웨어를 잘 가져다가 쓰면 된다란 수준에 머물러 있다.

디바이스 트리나 디바이스 드라이버 소스 트리만 바꾸어가면서 보드에 리눅스 커널을 올리는 수준의 역할만 반복하는 것이다.

한국 임베디드 리눅스 개발 업체에서 리눅스 커널 코드를 깊히 있게 들여다 보는 개발자가 얼마나 있을까? 내가 리눅스 커뮤니티에서 만나본 많은 개발자들과 대화를 통해서 알아본 바로는 거의 없다고 봐야 한다.

이런 나의 예상이 틀리길 바란다.

그래도 난 내 예상보다 전문성을 키워나가면서 제대로 임베디드 리눅스를 개발하는 개발자가 많기를 바란다.

이런 방식으로 오랫동안 개발 경력을 쌓으면 필드에서 임베디드 리눅스 전문가라고 인정 받을 수 있을까?

난 절대 아니라고 본다. 이들은 임베디드 리눅스 개발자가 아니라 리눅스 코드 몽키라고 부르고 싶다.

돈 몇 만원 주면 메뉴얼대로 코드를 짜는 코드 몽키와 같이 이런 저런 보드에 리눅스만 올려대는 리눅스 코드 몽키지 않는가?

"이 포스팅이 유익하다고 생각되시면 댓글로 응원해주시면 감사하겠습니다.

To be continued...

# Reference: 리눅스 커널

디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 1

디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 2