임베디드 개발자들이 야근을 하는 이유는 무엇일까요? 이번 포스팅에서는 이 주제로 이야기를 해보려고 합니다.
사실 임베디드 분야의 개발자만 야근을 하는 아니고요. 다른 IT 분야도 마찬가지이긴 하거든요.
여기서 말하는 야근은 6개월 동안 11시 퇴근과 같은 성격의 야근은 아니고요. 돌발 상황으로 인한 야근을 말합니다.
하드웨어 부품이 조금만 바뀌어도 예상치 못한 문제를 겪는다.
임베디드 개발자는 기본으로 하드웨어를 프로그래밍을 하는 경우가 많아요. 그런데 운영체제나 드라이버가 같아도 하드웨어 부품이 교체되면 다음과 같은 상황을
겪게 되요.
* 기존에 못 봤던 이슈를 겪는다.
A란 프로젝트를 잘 마무리한 다음 A란 프로젝트에서 다른 메모리로만 교체한다고 가정해볼께요. 매니저들은 별 문제가 없으리라 예상할 수 있습니다.
부품 하나만 교체를 하면 별 문제가 없을 것이라 예상하고 리소스를 할당해 놓지 않는 것이죠.
어느 IT 업체나 마찬가지지만, 별 문제 없이 잘 될 것이라는 근거없는 장미빛 희망은 개고생으로 이어지는 경우가 많습니다.
부품을 교체했는데 예상치 못한 문제가 터지면 결국 임베디드 개발자들의 야근으로 이어지는 경우가 많습니다.
가끔은 하드웨어 팀에서 부품을 교체했는데 임베디드 개발자팀에게 이런 중요한 정보를 공유를 하지 않는 경우도 있습니다. 어제까지 잘 동작했는데 새로운 리비전의 보드에선 이상 동작을 하게 되는 겁니다.
임베디드 개발자가 잡아야 할 버그는 크리티컬한 경우가 많다.
프로젝트를 진행하는 도중에 임베디드 개발자가 잡아야 하는 버그가 크리티컬한 경우가 많습니다.
예를 들어볼까요?
* 갑자기 화면이 꺼지고 아무런 반응이 없다.
* 크래시가 발생한다. 그것도 가끔.
* 보드가 타버린다.
* 오디오 스피커로 굉음이 들린다.
프로젝트를 진행하면 SW의 안정성을 테스트하기 위해 인증 프로세스를 거쳐야 경우가 많습니다.
자격증 같은 건데요. 제품을 남품하기 전에 받아야 하는 인증서와 같은 것이에요.
많은 IT 업체에서는 자체 인증 부서를 구성해 버그를 잡는 Q/A 개발자를 육성하기도 합니다.
인증 프로세스이던 자체 QA 부서이던 제품의 안정성을 위해 여러 가지 테스트를 거치는데 이 과정에서 버그가 레포트됩니다.
임베디드 개발자가 버그를 잡을 시간을 충분히 주지 않는다.
그런데 문제는 임베디드 개발자에게 리포트 되는 버그는 위에서 설명한 바와 같이 프로젝트의 품질을 결정짓는 S급 버그인 경우가 많습니다.
그래서 반드시 이런 버그를 잡아야 하야 하는 거죠. 안타까운 현실은 이런 심각한 버그를 잡을 시간을 임베디드 개발자에게 주지 않는다는 것입니다.
* 그래서 야근을 할 수 밖에 없는 거죠.
아직 임베디드 개발을 시작하지 않은 분들은 이런 이야기를 들으면 좀 겁을 먹을 수 있는데요.
제 개인적인 의견을 조금 말씀드리면 이런 버그를 잡는 과정에서 많은 걸 배울 수 있어요.
군사 전략이나 무기가 전쟁이 일어날 때 많이 발전되듯, 위에 언급된 심각한 버그를 해결하는 과정에서 창의적인 디버깅 방법을 통해 문제를 해결하는 방법을 터득하는 경우가 많습니다. 그러니 너무 부정적으로 생각하지 않았으면 좋겠습니다.
브링업을 할 때 충분한 개발 시간이 주어지지 않는다!
임베디드 개발은 워낙 분야가 다양해 정의를 내리기는 어렵습니다. 하지만 프로젝트를 개발하는 관점으로 보면 프로젝트의 개발 단계는 다음과 같이 분류할 수 있는데요.
* 브링업 - 드라이버 안정화 - 출시 - 유지 보수
프로젝트의 첫 단계로 보드를 브링업을 하거나 보드에 탑재되는 부품을 브링업하게 됩니다.
여기서 말하는 브링업(Bring-up)은 뭐 '보드를 살린다', '보드를 눈 띄운다'라고 말하거나, 조금 더 고상하게, '보드에 생명을 불어 넣는다'라 말하는데요.
그런데 브링업을 할 때 매니저들은 충분히 시간을 주지 않는 경우가 많습니다. 특히 보드 브링업인 경우 더 심하거든요.
특히 보드 브링업이 마무리되서 해당 보드가 기본 동작을 하는 수준까지 진행돼야 다른 개발자(어플리케이션, 미들웨어 개발자)들이 일을 시작할 수 있거든요.
그래서 매니저들은 브링업을 할 때 까지 충분히 기다려 주지 않는 경우가 많습니다.
* 결국 야근으로 이어질 가능성이 높은 것이죠.
이처럼 야근을 할 가능성이 높아 브링업을 진행하는 과제를 싫어하는 임베디드 개발자도 꽤 있는 것 같습니다.
# Reference: For more information on 'Linux Kernel';
디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 1
디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 2
최근 덧글