한국 개발업체에서 절대 리눅스 전문가가 나올 수 없는 이유

AustinKim의 이미지

<< 원천 SW를 개발하지 않으려는 문화 >>

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

조직 책임자가 한 가지 명령을 내렸다.
"업무 시간에 리눅스 커널 소스 코드를 보지 말아라."

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

이게 임베디드 리눅스 프로젝트를 개발하는 부서장이 하는 소리다. 이 밖에 평소에 이 임베디드 리눅스 업체 관리자가 뇌깔리는 소리는 다음과 같다.
1. 리눅스 커널은 안정화된 코드이기 때문이 다 가져다 쓴다.
그러니 리눅스 커널을 보드에 잘 돌리는 기술만 익히면 된다. 이게 최근 임베디드 리눅스 개발의 추세다.

2. 리눅스 커널은 디바이스 드라이버가 지나다니는 통로일 뿐이다.
그 제반 기술을 익혀서 뭘하나? 문제가 나오지도 않는데 말이야.

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

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

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

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

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

커널 로그를 보고 리눅스 메일링 리스트에서 유사한 패치를 적용하라고 한다.
물론 깊이 있는 문제 분석을 하지는 않는다.

안타깝지만 이 과정에서 깊이 있는 문제 분석을 하지는 않는다. 대신 커널 크래시가 발생했을 때 커널 로그만 보고 여러 가지 소설을 쓴다.
"이건 메모리 불량일꺼야?"
"갑자기 전원에 문제가 생겼을 것이야?"

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

문제가 발생하면 깊이 있는 분석을 할 능력이 없다.
그래도 문제가 발생했으니 안심 패치를 적용해야 고객사에게 그래도 정신적인 평온감을 주지 않을까?
그래서 리눅스 커널 패치 아무거나 반영하고 문제를 해결했다고 거짓말을 한다.

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

대부분 한국의 소프트웨어 개발 업체 문화가 이렇다.
"잘 되어 있는 소프트웨어를 가져다 쓴다."

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

그냥 잘 돌아가는 소프트웨어를 잘 가져다가 쓰면 된다란 수준에 머물러 있다.
디바이스 트리나 디바이스 드라이버 소스 트리만 바꾸어가면서 보드에 리눅스 커널을 올리는 수준의 역할만 반복하는 것이다.

한국 임베디드 리눅스 개발 업체에서 리눅스 커널 코드를 깊히 있게 들여다 보는 개발자가 얼마나 있을까? 내가 리눅스 커뮤니티에서 만나본 많은 개발자들과 대화를 통해서 알아본 바로는 거의 없다고 봐야 한다.
이런 나의 예상이 틀리길 바란다.
그래도 난 내 예상보다 전문성을 키워나가면서 제대로 임베디드 리눅스를 개발하는 개발자가 많기를 바란다.

이런 방식으로 오랫동안 개발 경력을 쌓으면 필드에서 임베디드 리눅스 전문가라고 인정 받을 수 있을까?
난 절대 아니라고 본다. 이들은 임베디드 리눅스 개발자가 아니라 리눅스 코드 몽키라고 부르고 싶다.

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

<< 고참 개발자에게 관리를 시키는 문화 >>

운이 좋게 개발 능력을 키워가는 고참 개발자가 보이면 한국 개발 업체 조직 책임자들은 투명 완장을 채워준다.
개발과 관리를 동시에 하라는 것이다.

고참 개발자가 조직 책임자에게 개발만 집중하고 싶다라고 말하면 조직 책임자는 다음과 같이 불평을 한다.

"업무의 폭이 좁다."
"고참 개발자는 개발과 관리를 하면서 프로젝트를 이끌어 가야 한다."

업무의 폭이라? 고참 개발자가 되면 개발과 관리를 동시에 진행해서 프로젝트를 리딩해야 한다는 소리다.

그럼 고참 개발자에게 관리를 시키는 이유가 뭘까? 그 이유는 간단한다.
고참 개발자에게 관리 업무를 시키면 그 위 조직 책임자는 편하게 일할 수 있기 때문이다.
고참 개발자가 관리를 하면 우선 자신은 최신 기술에 대해 파악할 필요가 없다.

고참 개발자에게 투명 완장을 채워 준 다음 그 고참 개발자가 차려 주는 보고만 받아 먹으면 되기 때문이다.
얼마나 편한가? 고참 개발자가 차려 주는 밥상을 조직 책임자는 받아 쳐 먹기만 하면 되니까 말이다.

개발자들과 그 어려운 용어를 섞으면서 대화를 할 필요도 없고, 혹시 내가 기술을 잘 이해 못해서 이런 저런 질문을 하면 "개발자들은 정신 나간 관리자라고 얼마나 욕을 할까?" 란 생각도 할 필요가 없다.

그런데 개발과 관리를 동시에 해내야 한다? 과연 이런 개발자가 존재할까?
정말 이 세상에 개발과 관리를 동시에 잘 해내는 사람이 정말 있을까?

개발과 관리를 동시에 해내지 못하면 능력이 떨어진다고 봐야 할까?
이건 미친 개소리다. 이런 생각을 하는 관리자는 개발도 관리도 전혀 모를 가능성이 높을 인간들이다.

글로벌 소프트웨어 업체에서는 개발과 관리 트랙을 따로 구분해서 개발자와 관리자들을 육성한다.

개발이나 관리도 전문 분야이기 때문에 서로 집중해야 하는 업무 스킬과 능력이 다른 것이다.
소프트웨어 프로젝트 관리가 얼마나 많은 전문적인 스킬을 요구하는 힘든 전문 업무인가?

위에 있는 관리자들에게 쳐 맞고 개발자들을 잘 달래가면서 프로젝트를 잘 이끌어 나가야하는 엄청난 인내심과 끈기를 요구하는 일이다. 그리고 고객사와 관계, 커뮤니케이션, 업무 갈등이 생겼을 때 최적의 솔류션을 찾아 내는 능력..

그리고 기술 변화는 얼마나 더 심한가? 개발자가 관리자와 대화를 할 때 관리자가 기술에 대한 이해력이 떨어져 보고 내용을 못 알아들으면 대부분 개무시를 한다. 그래서 관리자도 끊임없이 공부를 해서 뒤쳐지지 않으면 안된다.
서과장: 김부장님, 이 문제는 시스템 콜을 처리하는 vfs_write() 함수에서 메모리를 GFP_KERNEL 옵션으로 줬기 때문에 발생하는 것입니다.

김부장: 시스템 콜이라고? 와이 파이 콜은 잘 되는데 왜 시스템 콜이 문제라는 거지?

서과장: (황당...) ... (표정 관리)

그런데 고참 개발자에게 관리 업무를 시키면 위 조직 책임자는 이런 상황을 면할 수 있다.
고참 개발자가 관리를 하면 우선 자신(조직 책임자)은 최신 기술에 대해 파악할 필요가 없기 때문이다.

고참 개발자에게 투명 완장을 채워 준 다음 그 고참 개발자가 차려 주는 보고를 받아 먹으면 되기 때문이다.
얼마나 편한가?

그럼 고참 개발자는 개발과 관리를 동시에 진행할 수 있을까?

우선, 대부분 관리와 개발을 동시에 진행하는 고참 개발자는 대부분 많은 스트레스를 받기 마련이다.
로그나 코드를 볼 시간이 현저히 줄어 들기 때문이다.

프로젝트 관리를 하다 보면 얼마나 전화가 많이 오나? 고참 개발자가 코드를 보다가 전화가 와도 잘 받아야 한다.
관리자 업무 중 전화 통화가 중요한 비중을 차지하기 때문이다.

따라서 집중하면서 코드나 로그를 볼 수 있는 시간이 현저히 줄어든다.

그리고 첨예한 의견 대립으로 진행되는 회의에 들어갔다 오면 바로 집중해서 코드나 로그를 볼 수 있나? 관리와 개발 업무를 할 때 쓰는 두뇌 자체가 다르기 때문에 이런 상황에서 바로 집중하기 매우 어렵다.

또한, 관리를 한다고 해도 기존에 개발했던 개발 경험치를 활용해서 문제를 짐작하면서 방향을 찾는 경우가 많다.
고참 개발자가 최근 까지 개발에 많은 시간을 투자했다고 이런 경험치는 잘 들어맞을 가능성이 높다.

하지만 시간이 흘러 코드나 로그를 볼 수 있는 시간이 줄어들면 결국 개발 능력을 떨어지고, 도태될 가능성이 매우 높아진다.

만약 고참 개발자가 개발과 관리를 동시에 진행하다가 개발 능력이 떨어지면 아예 관리로 들어서는 경우가 많다.

이런 상태 고참 개발자들을 위 조직 책임자는 기가 막히게 알아 차린다.
이런 고참 개발자가 개발이 아닌 관리를 본격적으로 하려고 하면 조직 책임자는 크게 2가지 태도로 분류할 수 있다.
1. 양심이 있는 조직 책임자들은 이런 고참 개발자들을 적절히 자신의 라인에 끼워서 관리 트랙에 올라 타도록 이끌어 준다. 이 정도 되는 조직 책임자들을 누가 욕하나?

2. 그냥 쓰다가 버린다.

"음식물 쓰레기를 버리거나 변기통에 똥이 막혀 있으면 뚫어야 하는 누군가는 해야 하나 정말 짜증나는 관리
만 맡긴다."

개발 능력이 떨어져 퇴물이 된 고참 개발자는 방법이 있나? 이런 일이라도 해야지.

이런 과정을 반복하는 고참 개발자들은 체력도 떨어져 몸도 망가지고 회사에서는 이용만 당하는 처량한 신세가 될 가능성이 높다.

이런 상황에서 전문 개발자가 될 수 있을까?

(개인블로그)
http://rousalome.egloos.com/

Hodong Kim@Google의 이미지

이런 글을 작성할 정도로 많은 스트레스를 받았으리라 생각합니다. 저야 전직 개발자도 아니고 현직 개발자도 아니지만 다소 공감합니다. 밥줄 만큼 중요한게 없다는 걸 잊지 마시고 원만히 해결되길 바랍니다.

AustinKim의 이미지

공감해주셔서 감사합니다. ^^
그래도 시간이 흘르면서 소프트웨어 개발 문화가 점점 개선되는 것 같습니다.

(개인블로그)
http://rousalome.egloos.com

rexos33의 이미지

좀 제대로된 연구/개발 조직을 갖춘 회사라면 많은 부분 본 글에서 언급하는 악폐습은 제거됩니다.
문제는 제대로된 조직을 갖고 있는 회사들이 적다는 것이겠죠. 그러니 면접때 잘 파악하고 궁금한 것들 꼼꼼하게 잘 물어봐야 합니다.

모두들 행복하세요~

AustinKim의 이미지

좀 제대로된 연구/개발 조직을 갖춘 회사 혹은 정상적인 조직이라면 이런 일은 일어나지 않을 것입니다.

(개인블로그)
http://rousalome.egloos.com

rexos33의 이미지

생각보다 괜찮은 사람들이 여전히 많고, 이런 사람들이 넷상에서 워낙 조용하게 지내다보니 들어나지 않아서 그렇지 아예 존재하지 않는 사람들 처럼 느껴질 수도 있겠다고 해서 그저 뻔~한 이야기를 썼네요.

저 또한 20년가까이 리눅스만 사용하고 있고, 리눅스 기반의 임베디드 제품을 만들고 있는 사람입니다. 제 주변에는 거의 모두가 리눅스 환경에서 개발하고 있고, 과제 및 연구도 많이하므로 리눅스 커널 관련하여 심층 공부하겠다는 사람들이 있다면 좋은 일이고 또 적극적으로 지원해주거든요.

개인적으로 리얼타임 OS를 만드는 사람도 있고, 초저전력 노드 통신용 커널 만드는 사람들도 있고 찾아보면 상당히 실력있는 조용한 분들은 많이 있답니다.

모두들 행복하세요~

AustinKim의 이미지

좋은 정보 감사합니다.

> 제 주변에는 거의 모두가 리눅스 환경에서 개발하고 있고, 과제 및 연구도 많이하므로
> 리눅스 커널 관련하여 심층 공부하겠다는 사람들이 있다면 좋은 일이고 또 적극적으로 지원해주거든요.

부럽습니다. 저도 이런 환경에서 개발했으면 좋겠습니다.

(개인블로그)
http://rousalome.egloos.com

hirameki의 이미지

전에있던 회사가 비슷한 문화긴 했습니다.

개발자들도 전문 용어를 모르는 사람들이 이해하기 쉽게 설명할줄 알아야 하기도 합니다만
관리+개발을 바라는것은 시간이라는 한정된 리소스를 사용하는데 개인의 모든 시간을 추가투입하라는 것을 은연중에 강요하는 일이죠.

지금 회사는 코딩은 안하더라도 조금은 코드를 읽을 줄 알고, 동작원리를 아는 사람이 위에 유지되는 상태인지라
문제가 생겨도 상의하기 쉽고, 개발자 출신들도 관리로 전환하는 사람들도 있습니다.
무엇보다도 중요한것은 관리도 시간이 들어가고 기술도 시간이 들어간다는 사실을 당연히 인정받는 분위기라는 점입니다.
(실제 처해있는 상황이 힘들더라도 이걸 인정하는 분위기와 그렇지 않은 분위기는 텐션에 상당히 영향을 주더군요)

--

LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Hirameki --X-
Mail : hirameki_krjp@yahoo.co.jp
God is not customer center. Do it yourself
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL