Arm Linux Kernel Hacks

회사 선배들 중에 CTS 개발자(퀄컴, 인텔, 엔비디아 기술 지원)로 일하는 분을 만나면 제조사 개발자들와 의사소통을 하는데 많은 시간을 보낸다고 합니다. “재현 경로는 뭔가요? 로그를 좀 더 추가해서 재현시켜 주세요. 공장에만 재현이 된다고요? 시에틀에서만 재현이 된다고요?”  사실 칩셋 벤더(퀄컴, 인텔, 엔비디아0에게 기술문의를 할 때는 영어로 칩셋 벤더가 만든 사이트에 문제를 업로드해야 합니다. 그런데 사실 제조사의 개발자들은 영어를 못하죠. 또한 아예 글을 쓰는 능력이 떨어지는 경우가 많아 명확히 이슈에 대한 설명을 못하는 경우가 많습니다.

그런데 가끔 자신의 책임을 전가하기 위해 일부러 재현경로를 다르게 칩셋벤더에게 공유하는 것을 본 적이 있습니다. 한국에서도 재현이 잘되는 이슈인데 보름 정도 놀면서 이슈를 썩혀 놓았다가 칫셉 벤더(퀄컴, 인텔 등등)에게 이슈를 문의합니다. 한국에서는 절대 재현이 안된다고 적습니다. 사실 100% 재현이 되는 데 말이죠. 미국에서만 재현이 된다고 합니다. 보름 동안 난 한국에서 재현을 시키느라고 고생을 했다고 이런 저런 가짜 정보를 적습니다.

이런 거짓말을 하는 이유는 사실 대부분 임베디드 관리자들이 칩셋 벤더 기술 문의 즉 이슈 tracking site 메일의 cc로 등록된 경우가 많기 때문입니다. 한국에서 100% 재현이 되는 이슈인데 보름 후에 칩셋 벤더에게 기술 문의를 한 것을 부서장이 알 수도 있죠. 결국 시간이 지나면 부하 직원이 일을 안하고 먹고 놀았다는 것 알게 되는 것이죠. 물론 관리자들이 이 사실을 알면 개박살을 내겠죠. 발길질에. 욕설에. 나가 죽어라, 소새끼 말새끼, 밥도 먹지 말아라 등등.

그래서 퀄컴에 기술 문의 사이트(Service Request)를 통해서 문의를 하면 대부분 퀄컴 CTS(Customer Technical Server)엔지니어들은 뭐 문의 내용에 답신은 하지 않고 RAM DUMP 달라고 합니다. RAM DUMP없다고 하면 이러 저렇게 하면 RAM DUMP 추출을 할 수 있으니 문제를 재현시켜서 RAM DUMP를 뽑아서 달라고 하죠. 퀄컴 개발자들은 RAM DUMP 없이는 거의 움직이지 않습니다. 왜냐하면 RAM DUMP에는 문제가 발생하였을 시에 snap shot을 그대로 뜬 것이라(어떤 문제가 생겨서 특정 프로세스에서 abort 즉 crash가 발생할 경우 그 코어의 handler에서 다른 프로세스에 irq를 바로 trigger하여 다른 각 프로세스를 suspend시키고 바로 cache를 flush시킴), RAM DUMP만 보면 어떤 이유로 타겟(폰 혹은 디바이스)에 문제가 발생 하였는지 바로 파악할 수 있기 때문이죠. 당연히 쓸때없이 서로 메일을 주고 받거나 전화 통화를 하는 시간을 줄일 수 있습니다. 램 덤프로 모든 디버깅 정보를 다 볼 수 있기 마련이죠.
제조사의 개발자가 SIM이 없는 상태였다, SDCARD가 없는 상태라고 거짓말을해도 RAM DUMP를 보면 다 나옵니다. Airplane 모드였다라고 뻥을 쳐도 디버그 용 변수를 까보면 다 들통이 나죠.

이렇게 일하는 것을 보면 칩셋 벤더가 제조사 개발자로부터 참 많이 골탕을 먹은 것 같습니다. 칩셋 업체에게 있는 그대로의 디버깅 정보를 공유하는 것은 상식인데 말이죠. 같은 개발자로써 기본적인 자존심과 지켜야 하는데 말이죠.

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

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

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

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

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

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

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

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