많은 사람들이 다음과 같이 말한다.
* 리눅스 커널은 중요하다. 리눅스 커널을 잘 알아야 한다.
그렇다면 리눅스 커널은 잘 알아야 할까? 이번에는 리눅스 커널을 왜 공부해야 하는지 이야기해보자.
문제 해결 능력
리눅스 커널을 알아야 하는 이유는 정말 간단하다.
* 디바이스 드라이버 담당자로써 문제 해결 능력을 키울 수 있기 때문이다.
처음 임베디드 리눅스 개발자로 일을 시작하면 보통 어떤 개발 업무를 맡을까?
대부분 드라이버를 맡는 경우가 많다. 예를 들어 스토리지, 네트워크, 모뎀 등등 디바이스 종류는 무궁무진하다.
그런데 디바이스 드라이버 코드는 누구나 작성할 수 있다. 리눅스 커널에 얼마나 많은 디바이스 드라이버 예제 코드가 많은가? 예제 코드를 활용해서 해당 디바이스에 대한 데이터 시트만 있으면 그리 어렵지 않게 드라이버를 구현할 수 있다.
그럼 리눅스 커널을 잘 아는 개발자와 잘 모르는 개발자의 차이점은 무엇인가?
* 문제 해결 능력이다.
그렇다. 리눅스 커널을 잘 알면 알 수로 문제 해결 능력을 키울 수 있다.
그 이유는 간단하다. 디바이스 드라이버 코드는 모두 리눅스 커널 함수로 구성돼 있기 때문이다.
한 가지 예를 들어보자. 대부분 디바이스 드라이버는 인터럽트 핸들링하는 인터럽트 핸들러로 하드웨어와 인터페이싱한다. 이 때 무슨 함수를 호출해야 할까? request_irq() 함수다.
만약 인터럽트 핸들러를 request_irq() 함수를 써서 등록하면 인터럽트 핸들러가 호출될 것이다. 그런데 만약 인터럽트 핸들러가 가끔 호출되지 않을 때 어떻게 해야 할까?
이럴 때 "하드웨어에서 인터럽트를 제대로 올려주지 않아서 생긴 문제일까?"란 의문이 생긴다. 그래서 다음과 같이 결심한다.
* "그래! 하드웨어 담당자에게 문제를 던지자!"
하드웨어 담당자게게 인터럽트 신호를 점검해 달라고 했더니 인터럽트 신호가 제대로 올라온다고 한다. 이 사실을 알려주는 하드웨어 담당자 표정이 별로 좋지 않다.
이제 문제를 어떻게 해결해야 할까? 멘붕 시작이다.
"이럴 때 어떻게 해야 할까? 이럴 때 리눅스 커널 문제라고 해야 할까?"
* "맞아, 난 아무런 문제가 없어."
제대로 인터럽트 핸들러를 등록했는데 커널에서 인터럽틀 핸들러를 호출 안 한 거야."
리눅스 커널을 전혀 모르는 개발자는 하루 종일 구글링을 하면서 비슷한 예를 검색할 가능성이 높다.
이 과정에서 일찍 퇴근할 수 있을까? 아마 관리자는 눈을 독수리 같이 뜨면서 개발자를 쪼면서 퇴근 시간을 모니터링할 것이다.
같은 문제를 겪어도 리눅스 커널을 잘 아는 개발자는 문제 분석을 시작할 수 있다. 이게 개발자 실력 차이가 아닐까?
인터럽트를 커널이 어떻게 처리하는지 대략적이라도 아는 개발자는 어떻게 이런 문제를 대응할까?
* 먼저 인터럽트 핸들러를 호출하는 리눅스 커널 함수와 커널 트레이서인 ftrace에서 irq_handle_enter 이벤트를 키고 언제부터 인터럽트가 안 올라오는지 확인할 것이다.
로그를 차근 차근 보면서 어디서 부터 인터럽트가 안 올라오는지 확인하고 의심가는 코드에 적절히 디버깅 코드를 추가해서 문제를 좁혀 나갈 것이다.
결국, 인터럽트 발생 빈도가 높은데 인터럽트에 대한 ACK를 늦게 디바이스에 전달해서 발생한 문제로 판명이 났다.
인터럽트 발생 후 바로 인터럽트 후반부 처리를 할 수 있는 태스크릿을 썻더니 문제가 사라졌다.
임베디드 리눅스 코드 몽키
리눅스 커널에 대한 지식이 부족한 디바이스 드라이버 개발자는 어떤 길을 걷게 될까?
* 대부분 코드 몽키로 전락할 가능성이 높다.
조금은 자극적인 말이고, 도그마적인 문장이기도 하다.
코드 몽키는 소프트웨어 동네에서 쓰는 용어인데 돈 천 원 주면 간단한 코드를 작성해 주는 낮은 수준의 일을 반복하는 개발자를 낮게 부르는 용어다. 코드 몽키라. 코드 몽키 앞에 리눅스를 붙혀서 리눅스 코드 몽키라고 하면 사람들이 그 뜻을 잘 이해할까?
생각보다 개발 현장은 냉혹하다. 회사에서 어떤 임베디드 리눅스 개발자가 문제 해결 능력이 떨어진다고 판단하면 크게 2가지 방향으로 관리를 한다.
1. 짤라 버린다.
2. 시간을 갈아 넣고 개발자를 굴릴 수 있는 일을 시킨다.
한국 소프트웨어 회사는 HR부서에서 개발자에게 조용히 나가달라고 하면서 히드라가 툭툭 침을 뱉듯 자존심에 침을 뱉는 소리를 한다고 한다. 이럴 때 대부분 개발자들은 몇 달 버티다가 퇴사를 한다.
그런데 외국계 회사는 좀 다르다.
* 그냥 "You are fired!"라고 통보를 한다고 한다.
시간을 갈아 넣는 소모적인 일은 무엇일까? 예를 들어볼까?
* 디바이스 스트레스 테스트 및 보고서 작성
* git 머지
* 커널 빌드 스크립트만 작성
* 고객사 디바이스(서버) 문제가 생겼을 때 온사이트 지원
: 전화 받고 고객 서버 있는 곳에 가서 욕 먹는 일(욕받이)
안타까운 현실은 위와 같은 소모적인 일은 아무리 열심히 해도 개발 능력이 늘지 않는다는 것이다. 말 그대로 시간을 갈아 넣으면서 몸으로 뛰는 몸빵인 것이다.
* 일을 열심히 하면 할 수록 바보가 된다!!
나와 친한 어떤 후배가 했던 말이다. 아무리 위와 같은 일을 열심히 해도 결국 연차만 올라가지 경력으로 내밀 것은 하나도 없는 경우가 많다. 체력이 떨어지면 다른 개발자로 교체될 수도 있다. 시간만 갈아 넣으면 되는 일이기 때문이다.
꼰대 고참 개발자
대부분 임베디드 리눅스를 만지는 개발 부서나 회사에서는 리눅스 커널 역량 강화에 많은 신경을 쓴다.
리눅스 커널 관련 교육에 자주 다녀오라고 하고 세미나도 하라고 한다.
* 리눅스 커널 역량 강화는 회사나 개발실의 문제 해결 능력에 직접적인 영향을 끼치기 때문이다.
그런데 가끔 꼰대 고참 개발자 중에 한 분은 소리를 지르며 다음과 같이 주장한다.
* 리눅스 커널은 잘 알 필요가 없다.
리눅스 커널 자체는 안정화된 코드이니 스크립트나 디바이스 드라이버 코드에 집중하면 된다는 것이다.
이 포스팅을 읽는 개발자들이 일하는 개발자 분들 주위에 이런 놈이 있을까? 생각이 들지 모르겠지만 실제 난 이런 개발자와 잠깐 일해본 적이 있다. 물론 이 꼰대 고참 개발자가 리눅스 커널을 잘 안다면 나름대로 이런 소리를 할 자격이 있다고 볼 수도 있겠다.
* 하지만 이 꼰대 개발자는 리눅스 커널에 대해서 1도 모르는 허접 퇴물 개발자였다.
이 꼰대 개발자가 자주 뇌깔리는 소리가 있다.
"리눅스 커널은 디바이스 드라이버가 지나다니는 통로다."
난 이 소리를 듣고 어이가 없어 실소를 금치 못했다.
리눅스 커널 이야기만 나오면 "난 토발즈가 아니에요." 이런 소리를 한다. 난 이 꼰대 개발자에게 이런 말을 했다.
* "누가 당신 보고 리눅스 커널을 개발하라고 했나?",
* "리눅스 커널에 대해 잘 알면 리눅스 개발 도중 만나는 다양한 문제를 빨리 해결할 수 있지 않은가?"
물론 그 꼰대 개발자는 소리를 지르며 "너나 리눅스 커널 공부해라!"라면서 내 말을 듣지 않았다.
물론 회사나 개발 일이 급해서 리눅스 커널에 대해 깊히 있게 스터디를 못할 수도 있다. 빨리 패치를 긁어 모아서 솔루션을 찾아야 하는 경우도 있고 스트레스 테스트를 통해서만 해결할 수 있는 상황도 겪을 수 있다.
내가 말하는 것은 임베디드 리눅스 개발 부서에 있는 꼰대 개발자나 관리자가 리눅스 커널은 잘 몰라도 된다고 말하는 경우다.
가끔 여러분들이 회사에서 이런 꼰대 개발자나 중간 관리자를 만나면 조심해야 한다. 이런 사람들 말을 듣고 개발을 하면 결국 코드 몽키로 변해 있는 자신을 발견할 것이다.
소프트웨어 어느 분야던 마찬가지다. 오랫동안 갈고 닦아서 다른 사람이 쉽게 따라오지 못할 기술에 시간을 투자하자.
잔기술에 시간을 몰빵하는 개발자는 수명이 길 수가 없다.
>
>
>
> Reviewed: 09/29, 2019
>
>
# Reference: For more information on 'Linux Kernel';
디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 1
디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 2
최근 덧글