ARM Linux Kernel Hacks

rousalome.egloos.com

포토로그 Kernel Crash


통계 위젯 (화이트)

199239
1625
172596


[임베디드] 관리자들이 가장 많이 하는 거짓말(1) - 문제를 넓게 봐라 임베디드 에세이

임베디드 개발 업체의 관리자가 가끔 이런 소리를 합니다.

   * 문제를 보는 시야가 좁아. 서과장은 조금 더 시야를 넓히는 게 좋을 것 같아.

이 글을 읽는 임베디드 개발자(드라이버, BSP) 여러분. 여러분도 혹시 이런 소리를 들어 본 적이 있나요? 관리자들이 무슨 소리를 하는지 모르겠다고요? 그렇다면 이런 말을 하는 관리자의 속마음을 컴파일 해볼까요?

(소스 코드)
문제를 보는 시야가 좁아. 서과장은 조금 더 시야를 넓히는 게 좋을 것 같아.

(컴파일러)
난 체계적을 관리하기 싫고 문제가 나오면 그냥 너한테 던지고 싶어. 그러니 개발자인 네가 문제를 분류해주고 알아서 관리까지 해 줬으면 좋겠어.

그러니 내가 문제를 던지면 내가 다 받았으면 좋겠어. 따라서 문제를 보는 시야를 넓혔으면 좋겠어.

관리자는 여기까지 이야기하면 조금 찝찝합니다. 뭔가 교훈이 될만한 조언을 해주고 싶습니다.
그래서 개발자에게 자신의 생각을 조금 더 말합니다.

   * 문제를 넓게 보게 되면 그 시간이 쌓여서 결국 전문성을 키울 수 있어. 소프트웨어의 구조를 조금 더 넓게 봐.

중요한 포인트는 이때 관리자는 정말 진지한 표정을 보여야 합니다. 그래야 뭔가 있어 보이죠.
사실, 이런 지시를 내리는 관리자는 자신이 무슨 소리를 했는지도 모릅니다.

이번에는 관리자의 마음을 디버깅해볼까요?

(소스 코드) 문제를 넓게 보게 되면 그 시간이 쌓여서 결국 전문성을 키울 수 있어. 소프트웨어의 구조를 조금 넓게 봐.

(디버깅) 네가 실력과 전문성을 키우고 싶다는 사실을 알고 있어. 하지만 난 그 전문성이 뭔지도 모르겠고 그게 왜 중요한지 모르겠어. 또한 난 개발자가 전문성을 어떻게 키워나가야 하는지도 몰라. 하지만 내가 던지는 문제로 인해 전문성이 키워졌으면 하는 바램은 조금은 있어. 그래야 내가 문제를 던지면 네가 잘 받아서 일을 할꺼니까! 그래서 이런 소리를 하는 거야. 

개발자 여러분! 

만약 관리자로부터 이런 소리를 듣고 문제를 던지는데로 받아서 꾸역 꾸역 해결해 나가면 과연 여러분의 개발 능력이 업그레드 될까요? 물론 업그레이드 된 분도 있을 것입니다. 만약 그런 분이 있다며 박수를 보내고 싶습니다.

하지만 제 주위에서 본 현실은 이렇습니다. 

   * 대부분 전문성을 키울 수 없게 되어 캐리어에 데미지를 받는 경우가 많습니다. 

이 구절까지 읽은 분이 개발자이면 '어! 이거 내 이야기를 써놨네?'란 생각이 들 것입니다. 또한 "어, Austin 이란 개발자가 혹시 나를 아는 것 아니야?"라고 스스로 말할 지도 모릅니다. 

만약 이 글을 읽는 분이 '관리자'라면 여기까지 읽고 불쾌해질 가능성이 높습니다. 불쾌감이 높을수록 여기에 써 놓은 관리자와 자신이 비슷한 유형이란 사실을 알았으면 좋겠습니다.

그런데 사실 이 포스팅에서 언급한 임베디드 리눅스 BSP 관리자 이외에도 정말 리더십이 있는 분이 있을 수 있습니다. (솔직한 마음으로 이 세상에 존재하기를 바랍니다.) 그런 분이 세상에 존재하고 있다고 가정하고 조금 더 말씀을 드리겠습니다.

이런 관리자 분들께서 진정으로 다음과 같은 고민에 빠질 수 있습니다.

   * '난 진정으로 후배 개발자들이 문제나 코드를 넓게 보면서 실력이 업그레이드 됐으면 좋겠다.'

음, 정말 그렇게 생각하신다면 저도 박수를 보내고 싶은데요. 그런데 이를 실현하기 위해서는 약간의 프로세스가 필요하다고 생각합니다.
  
프로세스 1: 구체적으로 무엇을 넓게 보고 넓게 보면 어떤 능력이 업그레이드 되는지 자세하고 명확하게 설명해야 합니다.

개발자들은 자신이 개발하는 분야에서 어느 정도 전문성을 확보 싶은 생각이 강합니다. 특히 초년 개발자들은 이런 의지가 강하죠. 이런 분들에게 조금 더 구체적으로 설명을 해줄 필요가 있습니다.

몇 가지 예를 들어볼까요?

* 부트 로더에서만 메모리 컨트롤러를 제어하는 개발자에게 '커널에서 메모리 컨트롤러를 액세스를 하는 부분을 조금 더 봤으면 좋겠다.' 이런 조언을 할 수 있겠죠.

* XFS 파일 시스템 개발자에게는 XFS 파일 시스템은 가상 파일 시스템과 연동되서 동작하니 가상 파일 시스템 계층의 코드도 같이 봤으면 좋겠다.

* 네트워크 패킷은 태스크릿에서 동작하니 네트워크 패킷의 성능을 개선하기 위해서는 태스크릿의 구조도 함께 봤으면 좋겠다.

이렇게 구체적인 기술 기능과 기법을 언급하면서 시야를 넓히라는 이야기를 해야 그나마 개발자들과 소통을 할 수 있습니다.

프로세스 2: 이런 설명은 프로젝트 초반에 해야 합니다.

프로젝트 중반에 갑자기 자신이 담당하지 않는 업무에서 나온 문제를 해결하라고 하면 대부분의 개발자들은 왕짜증을 냅니다. 예를 들어 볼까요? 

   * 파일 시스템만 보는 개발자에게 갑자기 소모 전류나 오디오 노이즈 문제를 해결하라.
   * 부트 로더에서 어셈블리 코드로 메모리를 초기화를 하거나 트러스트 존(Trust Zone)을 제어하는 담당자에게 네트워크 패킷이 손실되는 문제를 해결하라.

그래서 프로젝트 초반 단계에서 개발자에게 미리 준비해야 할 드라이버나 BSP 분야에 대해 알려줘야 합니다.

이런 프로세스를 갖추기 위해서는 관리자는 공부를 열심히 해야 합니다. 그래야 개발자들과 기술 언어로 소통할 수 있습니다. 개발자가 느끼기에 관리자가 기술적인 배경 지식이 부족하다는 사실을 느끼면 속으로 바보 취급을 합니다. 물론 겉으로는 바보 취급을 하지는 않겠죠.

뛰어난 관리자가 되기란 참 어렵고 이런 분을 만나기도 쉽진 않는 것 같습니다.



















덧글

댓글 입력 영역