임베디드 개발자(리눅스, MCU)의 현실: 코드 몽키 업무와 성장 한계 [1편]

저번 포스팅에서는 코드 몽키의 미래에 대해 이야기했습니다. 그 포스팅을 읽고 종종 아래와 같은 질문을 주시는 분들이 있었어요.

 

   * 임베디드 개발에서 구체적인 코드 몽키적인 일이 무엇인가?

 

이 질문에 대한 생각을 조금 정리해 설명하겠습니다.

 

코드 몽키성 임베디드 개발 업무란

 

코드 몽키성 업무의 주요 특징으로는 다음과 같은 특징을 지녀요. 

 

   * 개발 업무를 매뉴얼화 할 수 있다

   * 업무의 난이도가 낮다

   * 일을 할 때 거의 막히는 부분이 없다.

 

지금 하고 있는 개발 업무가 위와 같은 범주 중 하나라고 느낀다면 “아, 내가 코드 몽키성 개발 업무를 하고 있구나”라고 여겨도 좋습니다. 이렇게 말씀드리는 이유는 임베디드 개발의 범위가 넓고 구체적으로 코드몽키성 업무에 대해 언급을 해도 공감이 안될 수 있기 때문입니다.

 

단순 설정 업무

 

많은 임베디드 개발자들이 리눅스 기반 환경에서 개발을 하시니 리눅스 드라이버를 예로 들어 설명하겠습니다. 

 

가장 먼저 설정 업무를 코드 몽키성 개발 업무라고 볼 수 있는데요. 한 가지 예를 들겠습니다. 현재 시스템에서 커널 로그가 제대로 출력되지 않습니다. 그런데 주위 동료가 CONFIG_PRINTK 라는 컨피그를 켜보라고 합니다. 그래서 CONFIG_PRINTK를 추가한 다음에 커널 드라이버를 빌드합니다. CONFIG_PRINTK 컨피그를 추가한 다음에 디바이스에 커널 이미지를 내려받은 후에 확인해보니 커널 로그가 제대로 출력이 됩니다. 스스로 뿌듯해 합니다.

 

   * 그래, 드디어 내가 해냈어.

 

하지만 CONFIG_PRINTK 컨피그를 키면 새롭게 어떤 함수들이 동작하는지, 어떤 원리로 커널 로그가 출력되는지 알려고 하지 않습니다. 그냥 설정 파일을 추가한 후 돌려 보는 것이죠. 생각보다 임베디드 리눅스를 개발할 때 이런 업무를 자주 수행하는데, 안타깝지만 이런 업무는 코드 몽키가 되는 지름길 중 하나입니다. 제가 언급한 코드 몽키성 업무의 주요 특징을 다음과 같이 바꾸어 볼 수 있거든요.

 

   * “개발 업무(CONFIG_PRINTK를 추가하는 것은)를 매뉴얼화 할 수 있다”

   * (CONFIG_PRINTK를 추가하는 것은)업무의 난이도가 낮다

   * (CONFIG_PRINTK를 추가하는)일을 할 때 거의 막히는 부분이 없다.

 

이처럼 뭔가 설정만 변경하는 코드는 셸 스크립트에서 디바이스 트리까지 확장됩니다. 코드 분석이나 동작 원리를 모른체 이런 업무만 반복하면 어떻게 될까요? 

 

   * 바로 코드 몽키, 저렴한 임베디드 개발자가 되는 겁니다.

 

사실 이런 코드 몽키성 업무를 시키면 대부분 개발자들은 싫어합니다. “내가 무슨 잡일 하러 왔나?”라고 자신도 모르게 불만을 토로하죠. 하지만 안타까운 건 이런 사실을 모른 체 이런 코드 몽키성 업무만 쫒아 다니는 개발자가 존재한다는 사실입니다.

 

패치 반영 후 테스트

 

프로젝트를 진행하다 보면 패치 코드가 전달되는 경우가 많습니다. 그런데 패치가 전달됐으니 패치 코드 5벌을 반영 한 후 테스트를 해보라고 합니다. 패치를 순서대로 반영한 후 빌드를 마무리해서 테스트를 수행합니다. 물론 패치의 내용이 뭔지 파악하지 않습니다. 그냥 패치를 반영할 뿐입니다. 

 

프로젝트가 숨가쁘게 돌아갈 때 갑자기 패치가 전달돼 패치를 바로 반영하고 테스트를 돌려야 할 때가 분명히 있습니다. 프로젝트가 바쁘지도 않은데 패치를 기계적으로 반영하고 테스트를 수행합니다. 패치 코드가 어떤 함수의 내용을 변경하는지 어떤 자료 구조가 바뀌는지 열어볼 생각을 하지 않습니다. 단순히 기계적으로 패치를 반영할 뿐입니다.

 

이번에도 위에서 언급한 코드 몽키성 업무의 주요 특징을 다음과 같이 바꾸어 볼 수 있습니다.

 

   * “개발 업무(패치를 반영하고 테스트를 돌리는 일)를 매뉴얼화 할 수 있다”

   * (패치를 반영하고 테스트를 돌리는 일)업무의 난이도가 낮다

   * (패치를 반영하고 테스트를 돌리는 일)일을 할 때 거의 막히는 부분이 없다.

 

패치를 기계적으로 반영하고 돌리는 것은 코드 몽키성 업무 중 하나입니다.

 

 

GIT Merge

 

GIT은 소프트웨어를 관리하는 사실 상 표준 프로그램이 된 지 오래입니다. 프로젝트를 진행하다 보니 다른 업체에서 아래와 같은 메시지를 전달합니다.

 

    * 현재 프로젝트의 리눅스 커널 버전이 4.4인데 4.9로 변경해야 합니다. 

      그래야 저희가 개발한 패치가 그대로 반영될 수 있습니다.

 

위와 같은 상황은 실전 프로젝트에서 종종 겪는 일입니다. 사실 최신 버전의 리눅스 커널이나 배포판 버전을 탑재한 상황에서 최신 패치를 쉽게 반영할 수 있습니다. 대부분 최신 패치들은 최신 배포판 버전에서 작성된 경우가 많거든요. 

 

이럴 때 GIT Merge를 하라고 합니다. 커널 4.4 버전에서 4.9 버전으로 GIT Merge를 해야 하는 상황입니다. 브랜치에서 소스를 내려받아 GIT Merge를 하는데 conflict이 발생합니다. conflict을 잡고 소스를 빌드한 다음에 제대로 동작하는지 확인합니다. 

 

물론 GIT Merge 도중에 하는 업무를 기계적으로 수행합니다. 커널 버전이 4.9 버전으로 변경돼 소스의 변경 사항이 많아 전체 소스가 변경된 내역을 확인하는 것은 사실 상 불가능합니다. 하지만 특정 세부 기능에서 대략 어떤 코드가 변경되고, 어떤 기능이 추가됐는지는 확인할 수 있습니다. 하지만 이런 과정을 거치지 않습니다. 기계적으로 GIT Merge를 수행할 뿐입니다.

 

이번에도 역시 언급한 코드 몽키성 업무의 주요 특징을 다음과 같이 바꾸어 볼 수 있습니다.

 

   * “개발 업무(GIT Merge)를 매뉴얼화 할 수 있다”

   * (GIT Merge)업무의 난이도가 낮다

   * (GIT Merge)일을 할 때 거의 막히는 부분이 없다.

 

GIT Merge 를 기계적으로 수행하는 것은 코드 몽키성 업무 중 하나입니다.

 

To be continued...