임베디드 디자이너들이 펌웨어를 작성하는 이유

이 기사는 후배의 패이스북의 포스팅에서 발견한 것입니다. 펌웨어 프로그래밍을 할 때 비용관련 중요 자료가 될 것같아 기록해둡니다.

임베디드 디자이너들이 펌웨어를 작성하는 이유

게재: 2012년10월02일 

키워드：임베디드  펌웨어  어셈블리  언어  디버깅 

Jack Ganssle
EE Times

키보드의 유혹은 너무도 많은 임베디드 프로젝트들을 무너뜨리고 말았다. 코드를 작성하는 일은 재미있다. 그리고 만족감을 준다. 프로젝트를 진전시키고 있다는 느낌을 준다. 펌웨어 작성의 미묘한 뉘앙스에 대해 무지한 경우가 태반인 우리의 상사들은 흐뭇한 표정으로 바라보면서 미소 짓는다. 우리가 뭔가 가치 있는 일을 해내고 있는 게 틀림없다고 생각하기 때문이다.

어셈블리 언어 기반의 시스템을 작업하는 젊은 개발자이던 당시, 필자는 기나긴 디버깅 세션을 당연히 예상하게끔 되었었다. 뭔가 코드를 작성해 놓은 다음에는 그게 제대로 동작하게 만들기 위해 수 개월을 소요했다. 디버깅은 힘든 작업이었기에 프로젝트 기간의 50 퍼센트를 문제 해결에 할당하게끔 되었다.

몇 년 뒤, 에뮬레이터의 제작 및 판매 일을 하면서 이러한 패턴이 끊임없이 반복되는 모습을 보게 되었다. 내가 함께 일했던 거의 모든 업체들에서! 사실 펌웨어 제작에 대한 바로 이 같은 접근 방식이야말로 툴 업체들에게는 하늘이 내려주신 선물이 아닐 수 없다. 이들의 사업이 번창하고 있는 것은 모두가 개발자들의 형편없는 관행과 그로 인한 버그 투성이 결과물 덕분이기 때문이다.

내 자신의 첫 개발 프로젝트가 실패로 끝난 지 25년이 지난 지금도 임베디드 디자이너들에게 강의를 하러 다니다 보면 이러한 패턴이 여전히 반복되고 있음을 보게 된다. 코드를 서둘러 작성하려는 조급함이 모든 상식을 압도하고 있는 것이다.

남용되고 있는 단어인 "프로세스"(물론 남용되고 있는 것은 단어 뿐으로서, 개념 자체는 펌웨어 분야에서 애석하게도 등한시되고 있다는 점에 주목하자)가 많은 주목을 받으면서 일부 개발자들은 소프트웨어 작성을 위한 합리적인 방법을 제도화했다고 주장하고 있다. 그러나 자세히 물어보면 이들 대부분이 그 같은 원칙들을 무계획적인 방식으로 적용하고 있음을 시인하고 만다.

압박이 거세지면(바로 이 때야말로 제대로 된 결과를 내놓는 시스템의 고수가 가장 요구되는 시점이다) 대부분은 시스템을 포기하고 그저 코드를 마구잡이로 작성해내려는 유혹에 굴복하고 만다.

코드는 바보라도 작성할 수 있다!

Peopleware의 공동저자인 Tom DeMarco 씨와 Tim Lister 씨는 프로그래머의 생산성에 대한 자신들의 연구에서, 모든 조건이 동일할 경우 경력이 6개월에 불과한 프로그래머라도 대개는 경력이 일 년이나 십 년 혹은 그 이상인 프로그래머 못지 않게 일을 해낼 수 있음을 알아냈다.

우리들 개발자들은 나이가 들어감에 따라 경험이 쌓여간다. 하지만 이는 대개 똑 같은 경험이 수없이 반복된 것뿐이다. 경력이 쌓여감에 따라 상승하는 급여는 외견상 높아지는 듯 보이는 지혜와 효율성 때문이라고 우리는 정당화한다. 그러나 이러한 경륜의 가치란 근거 없는 믿음에 불과하다고 데이터는 암시하고 있다.

펌웨어 작성을 위한 새롭고 보다 나은 방법들을 찾아낼 준비가 되어 있지 않는 한, 그리고 이러한 개선된 방법들을 구현하게 되기 전에는 우리도 정크 푸드로 연명하며 놀라울 정도로 많은 양의 코드를 쏟아내는 무모한 십대의 '전문가들'이나 별반 다를 게 없다.

코드는 어떠한 바보라도 작성할 수 있지만, 진정한 전문가라면 고품질의 소프트웨어를 적시에 예산 내에서 일관성 있게 작성할 수 있는 방법들을 찾아내야 한다.

세상에서 가장 비싼 것이 펌웨어

록히드 마틴(Lockheed Martin)사의 전임 CEO인 Norman Augustine 씨는 방위산업 분야에서 직면했던 문제에 대한 흥미로운 얘기를 들려주고 있다. 고성능 전투기는 연료당 항속거리 대 성능, 속도 대 무게와 같이 상충되는 요건들 간에 섬세한 균형을 이루고 있는 장치다.

1970년대 후반 경에 이르자 전투기는 이미 무거워질 대로 무거워져 있었다. 끊임없이 보다 큰 수익을 추구하고 있던 군수 하청업체들은 비용이 많이 들면서도 무게는 전혀 나가지 않는 추가 항목은 없을까 하고 헛되이 찾고 있었다.

전투기 비용에서 항공 전자기기용 펌웨어 비용은 계속해서 증가하고 있다.

그 해답이 바로 펌웨어였다. 비용은 끝없이 들면서도 중량은 전혀 나가지 않는! 이제 항공 전자기기는 전투기 비용 가운데 40 퍼센트 이상을 차지하게 되었다.

20년이 지난 오늘날에도 달라진 것은 아무 것도 없다. 펌웨어 비용이 더욱 높아졌다는 것 말고는.

현실 속의 펌웨어 비용은?

Bell Labs에서는 자신들이 코드 1,000 라인당 1~2 개의 결함률을 달성하기 위해 월 150~300 라인을 작성하고 있음을 알아냈다. 이는 급여와 경상비에 따라서는 코드 1 라인당 25~50 달러 정도에 해당하는 비용이다.

IBM의 우주 셔틀 제어 소프트웨어는 언론으로부터 부당한 질타를 수없이 받았지만 사실은 놀라울 정도로 오류가 없는 프로그램으로서, 어쩌면 이제까지 작성된 것들 가운데 최상의 펌웨어일지도 모른다. 그 비용이 얼마냐고? 명령문(statement) 하나당 1,000 달러로서, 그 결함률은 1만 라인당 한 개에 불과하다.

임베디드 시스템에 대한 연구결과는 거의 존재하지 않는다. 펌웨어의 라인당 비용이 얼마냐고 물어보면 대개는 멍한 눈으로 쳐다보다가 말도 안되게시리 낮은 수치로 대답하는데, "아마도 라인당 2 달러 정도"라는 대답이 일반적이다. 하지만 조금만 더 물어보면 (개발인원은? 개발 시작에서부터 출하에 이르기까지 걸리는 시간은?) 실제 비용은 그 수십 배에 달한다는 것이 드러나고 만다.

그 증거 삼아 한 가지 일화를 현실에 맞게 조금만 각색해 얘기해 본다면, 자사의 코드 작성 비용이 라인당 5 달러라고 말한다면 그것은 거짓말이라는 것이다. 아니면 그 코드가 쓰레기이거나! 반면에 라인당 100 달러라면 그 소프트웨어는 거의 미 국방부(DoD) 수준이다. 대부분의 임베디드 프로젝트들은 그 중간의 어디쯤인 20~40 달러 범위에 해당되게 마련이다.

물론 이보다 훨씬 저렴한 비용으로 고품질의 코드를 일관성 있게 작성해내는 몇몇 전문가들도 분명 있기는 하지만, 그들은 종형 곡선의 1 퍼센트 점근선 상에 있는 이들이다.

자신이야말로 바로 그러한 인물이라고 생각한다면(우리 모두가 그런 착각 속에 산다) 1~2년간 데이터를 수집해 보라. 그리고 나서는 프로젝트의 시작에서부터 완료에 이를 때까지 소모된 시간을 재서 이를 프로그램의 크기로 나눈다.

여기에 받은 급여(대개는 봉급 명세서 상에 적힌 수치의 두 배 정도)를 적용해 보라.

아마도 그 결과에 깜짝 놀라고 말 것이다.