훌륭한 임베디드 관리자 및 부서장이 되기 위한 조건(1)

훌륭한 임베디드 관리자 및 부서장이 되기 위한 조건에 대해서 살펴보도록 하자.

임베디드 부서의 부서장들은 개발자를 기술적으로 리드할 줄 알아야 한다. 기술적인 내용을 개발자보다 많이 알아야 된다는 의미는 아니다. 개발자들과 개발자들의 언어로 충분히 의사소통을 할 수 있는 능력과 더불어 개발자들이 보지 못하는 프로세스적인 관점으로 문제를 잘 해결할 수 있도록 만들어주는 환경을 만들어 주는 것을 말한다.

기본적으로 부서원들의 기술적인 내용이 담긴 보고를 명확히 이해를 해야 하는 것은 기본이다. 최소한 모듈의 개발자만큼 깊이 있게 기술적인 내용을 파악하지 못하더라도 담당자에게 몇 가지 질문을 던지면서 이해를 해야 한다. 기술적 배경 지식은 관리자들이 정말로 알기 힘든 자신의 아킬레스 건이라고도 할 수도 있고 혹은 가장 쉽게 키울 수 있는 역량이라고도 할 수 있다. 기술적인 내용은 자신의 노력으로 예를 들면 시간을 내어 짬짬이 메일이나 코드를 분석을 통해 알아내고 이해할 수 있기 때문이다.

개발자들은 관리자들이 기술적인 내용을 이해 못해서 딴 소리를 하는 순간은 정확히 알아챈다. 또한 그런 관리자를 저열한 관리자로 바라본다. 임베디드 개발자들은 기술 지식의 내공에 대한 프이드도 높고 어찌보면 고지식한 놈들이 많기 때문이다.  이럴 때 개발자들 사이에서 조용히 소문이 퍼진다. “누구 누구 허접이래”.
난 컨퍼런스 콜이나 회의에서 임베디드 기술적 지식이 부족한 관리자가 여러 개발자 앞에서 딴소리(ex: 와이 파이 콜은 시스템 콜에서 어떻게 불려요?)를 할 때 개발자들의 눈빛이 갑자기 바뀌는 순간을 선명하게 기억한다. 황당한 눈빛이다. 정말로 개발자들에게 개망신을 당하지 않기 위해서는 임베디드 개발실 부서장들은 쉬지 않고 기술적인 내용에 대해 필사적으로 공부를 해야 한다. (개발자인 나는 당연히 죽을 정도로 공부를 해야 한다.)

어떤 소프트웨어 공학 교재에서 소프트웨어 관리자는 기술적인 내용에 대해서 자세히 몰라도 된다는 내용을 본 적이 있다. 큰 그림으로 개발 과정을 이끌어가는 것이 중요하다고 지적한 것이다. 사실 소프트웨어란 분야가 바다와 같이 너무나도 범위가 넓고 또한 경계를 나누기도 애매하다. 하지만 임베디드 소프트웨어의 세계에서는 이런 룰이 절대 통하지 않는다.

며칠 동안 진행이 안 되는 이슈 때문에 다른 업체와 함께했던 컨퍼런스 콜이나 회의를 기억해 보자. 임베디드 소프트웨어라는 세례를 받은 개발자들은 정말 수 많은 기술적인 분석과 코드를 방언 터지듯 말한다.
프로세스, 워크 큐, MMU, 유저 스페이스 공간의 주소, 와치독, 캐패시터, 볼테이지 드롭(voltage drap), ADC(Analog to Digital), 캐시 플러쉬, 메모리 커럽션(memory corruption), 스택 오버런(stack overrun), 웜 리셋(warm reset), 벅스(bucks), 파워 레일(power rail), 캡(capacitor), 지피아이오(GPIO), 메모리 콘트롤러, 시스템 패브릭스 및 버스 기타 등등.

위에서 언급된 용어는 임베디드 세상에서 기본적으로 사용되는 언어이다. 이런 단어들에 대해서 정확하게 알지 못하면 관리를 할 수가 없다. 기본적으로 위의 용어들에 대해서는 기본 개념을 정확히 파악하고 있어야 하며 지금 개발 중인 디바이스에서 어떻게 구현이 되어 있는 지도 알아야 한다. 예를 들면, 100분 토론의 진행자인 손석희 같이 회의의 진행 흐름을 파악함과 동시에 정곡을 찌르는 질문도 해야 할 수준이 되어야 하는 것이다.

누가 위의 글을 읽으면 너무 임베디드 개발 관리자에게 가혹하면서 과중한 능력을 요구하느냐고 반문할지도 모르겠지만, 이게 임베디드 세상의 현실인 것 어떻하나?