◆임베디드 소프트웨어 개발의 현실
최근의 임베디드 소프트웨어 개발 환경을 과거의 모습과 비교해 보면, 가장 큰 차이는 역시 개발 팀의 규모가 커지고, 지역적인 분포도 넓어졌다는 것이 아닐까 싶다. 예를 들어, 시스템의 스펙은 한국에서 제시되고, 개발자들은 인도에서, 중국에서, 한국의 각지에서 작업하게 되는 경우가 빈번해진 것이다. 더이상 임베디드 시스템이 작다는 생각을 갖을 수 없을 정도로 다양하고 복잡한 기능들이 요구되고, 치열한 시장 경쟁을 위해 가능한 빨리 목표 제품을 만들어야만 하는 현실 때문일 것이다.
이런 환경에서 목표 제품의 time‐to‐market과 만족스러운 품질의 가장 큰 걸림돌은 무엇일까? 이에 대해 다수의 학자들과 컨설팅 단체들이 이미 다양한 조사와 연구를 진행하여 어느 정도의 결론을 내리고 있는 중인데, 그 중 가장 구체적이고 의미있는 데이터로 평가되는 것 중의 하나가 바로 EMF의 보고서이다.
임베디드 마켓 관련 대표적 컨설팅 기관인 EMF (Embedded Market Forecasters, http://embeddedforecast.com/) 가 2007년도에 전세계 임베디드 산업 관련 종사자 (하드웨어 엔지니어, 소프트웨어 엔지니어, 시스템 엔지니어, 매니저 중 e‐mail 을 통한 설문 조사에 유효하게 응답한 자)들을 대상으로 한 연구 조사는 40 % 이상의 소프트웨어 관련 프로젝트들이 지연되거나 아예 실패로 끝나게 되며, 관련된 손해는 기업당 1년에 평균 4천만달러에 육박한다고 밝혔다.
본 보고서를 자세히 들여다 보면, UML을 사용한 모델링을 수행하는 그룹과 코드 기반의 개발을 고수하는 그룹 사이에 프로젝트 성공률과 지연 빈도에 상당한 차이가 있음을 알 수 있는데, 이는 개발자 당 생성해 내는 수동 코드의 양과 밀접한 관계가 있음을 확인할 수 있다.
즉, 개발자 당 수동으로 생산해야 하는 코드가 많아질수록, 프로젝트의 지연 확률이 높았고, 당연히 실패 확률도 높아진다는 결과였다. 반면 UML을 통한 설계와, 그 설계에서 자동 코드 생성 기능을 사용하여 개발자 당 수동 생산 코드를 반으로 줄인 곳은 프로젝트 지연 확률이 10%(35.1% vs. 46.2%) 이상 떨어지며, 지연된다 하더라도 그 기간은 반으로 줄어든다는 조사 결과였다.
왜 이런 현상이 발생하는 것일까? 조사 대상에 있는 개발자들의 개발 능력이 떨어져서 일까? 이러한 설문에 응답할 정도의 영향력 있는 개발자들이라면 절대 개발 능력의 저하로 프로젝트에 걸림돌이 될 리는 없을 것이다. 문제는 같은 팀내 개발자들간에도 시스템에 대한 이해가 서로 다르기 때문에, 각 개발자들이 생성해 낸 모듈간 연동을 통해 완성되는 시스템의 품질을 떨어뜨리고, 결국 제시간에 목표 제품으로 조합되지 못하기 때문인 것이다.
설계 기간에 제대로 된 모델링 툴로 시각적인 설계를 진행했더라면, 그 설계 내용을 바탕으로 구체적인 구현을 채워 갔더라면, 그리고 구체적인 구현 부분을 시뮬레이션을 통해 특정한 하드웨어 없이도 바로 검증(Fast prototyping)할 수 있었더라면…, 그랬다면 대부분의 문제점이 발견되는 시스템 연동 테스트 기간이 훨씬 수월하게 지나가지 않았을까?
◆해결책은 MDD. 하지만 제대로 된 tool chain이 아니라면 ?
본 보고서에 나오는 또 다른 흥미로운 조사는 실제로 모델링을 수행하는 그룹내에서도 어떤 툴을 쓰느냐에 따라 결과의 차이가 커진다는 사실이다. 이를 제대로 표현하기 위해 초기 설계 모습과 최종 목표 제품과의 일치성 (Design accuracy)를 지표로 삼았으며, 대표적 설계 툴인 Simulink(MathWorks), Rhapsody, RoseRT (이상 IBM), VxWorks(WindRiver) 외 기타 등등을 대상으로 조사하였다.
결과는 UML 모델의 class, sequence, state transition diagram 등으로 fast‐prototyping 기반 simulation 이 가능하고, 검증된 모델에서 바로 코드를 생성할 수 있는 IBM의 Rhapsody가 81.7% 라는 높은 수치로 1위를 차지하였다. 문서 위주의 설계를 진행한 그룹 (Non‐Modeler라 칭함)이 66.6% 인 것과 비료하면 거의 20% 수준의 Design accuracy 향상이 Rhapsody 라는 툴에 의해 이루어진 것이다. (다시 한 번, 이 보고서는 IBM 의 주도나 IBM 관련된 조사 기관에서 수행된 것이 아님을 강조한다.)
이는 Rhapsody로 설계된 시스템 모델이 최종 목표 제품을 위해 거의 80% 이상 그대로 사용될 수 있음을 의미하기 때문에, Time‐to‐market 과 고객의 만족도 향상에 크게 기여할 수 있음을 의미하는 것이기도 하다. (주의 : IBM은 2008년 Telelogic을 인수하였기에, 현재는 RoseRT와 Rhapsody가 모두 IBM의 제품임)
이즈음에서 독자 중 일부는 몇 가지 반론을 제기할 것으로 생각되는데, 그 중 하나가 MDD의 적용 가능성이 팀의 크기나 개발 환경에 따라 달라진다는 것이리라. 외국의 경우야 객체 지향 개발이 많이 보편화 되어 있고, 개발자들이 이미 이러한 개념들에 익숙하겠지만, 국내 임베디드 소프트웨어 분야는 아직 C 개발자들이 대세이기 때문에 객체 지향을 기반으로 한 UML 모델링 적용이 쉽지 않다는 주장이다.
팀의 크기에 대해서는, 3명 이하의 개발자로 이루어진 팀에서 MDD를 새로 도입하는 것은 미래를 위한 투자가 아니라면 오버헤드라는 데에 필자도 공감한다. 바꿔 말하면, 4~5명 이상의 팀으로 이루어진 개발 프로젝트라면 MDD 도입이 미래를 위해서라도 반드시 필요하다는 얘기가 된다.
개발 환경 부분에서는, 사실 이 부분이 국내 소프트웨어 사업에 아직 MDD가 많이 퍼지지 못한 가장 큰 이유라는 데 또한 전적으로 공감한다. 아직까지도 국내 개발자들 사이에서는 C++나 Java가 C에 비해 무척 무겁고 성능이 떨어지기 때문에 임베디드 적용이 어렵다는 의견이 많은 데, 제대로 이해하고 사용한다면 해결될 수 있는 오해가 대부분이다.
이 부분에 대해서는 따로 할 말은 많지만, 개발 언어의 적합성은 논외로 하더라도, IBM의 Rhapsody는 다른 UML 기반 MDD 툴에 비해 C코드에 대한 처리(자동 코드 생성 및 역공학)가 아주 강력하다. 더구나 최근 발표한 Rhapsody7.5의 Code Centric profile은 C 언어 중심 코드 개발자들이 UML 기반 MDD로 쉽게 진보할 수 있는 유용한 기능들을 제공한다. 즉, 어떠한 툴을 사용하느냐에 따라 C언어 중심의 임베디드 개발자들이 성공적으로 객체 지향의 UML 향 MDD 로 진보할 수 있느냐의 여부가 달려 있다 해도 과언이 아닌 것이다.
◆MDD는 개발자들을 위한 유용한 툴일 뿐, 결코 개발자들의 대체 수단이 아니다
MDD는 시스템 개발 도중 잘못된 분석에 의한 오류와 수동 코딩으로 인한 실수를 최소화 하고, 정형화된 코드와 framework을 통해 모듈의 안정성과 재사용성을 증대시켜서, 현재의 기업들이 요구하는 좋은 품질의 Time‐to‐market에 큰 공헌을 할 수 있음이 다양한 조사 기관과 학계를 통해 증명되고 있다.
문제는 처음부터 제대로 된 MDD 툴 체인을 선택하여, 개발자들이 프로젝트마다 새로운 툴 체인에 익숙해지기 위해 고생하는 것을 막아야 한다는 것이다. 제대로 된 툴 체인이 없이 MDD를 강요한다면, 이는 개발자들에게 또 하나의 무거운 짐만 안겨 주는 것임을 명심하여야 하며, 툴 체인이 개발자들의 창의성과 효율을 높이기 위한 것이지, 결코 개발자들의 창의적 개발 활동을 대체할 수 있는 만능 인공 지능이 아님을 명심하여야 할 것이다.
IBM은 2000년 초 ROSE를 통해서 UML의 창을 열었고, 이제 Rhapsody를 통해 실시간 임베디드 소프트웨어 개발 영역으로 UML을 확장시키고 있다. 나아가서는 Jazz 기반의 다양한 SE(Software Engineering) 툴간 연동을 통해, 기업들에게 최적의 개발 프로세스를 제공하려 노력하고 있다.
이미 외국의 선진 소프트웨어 기업들은 2000년 중반부터 Rhapsody를 사용한 성공 사례들을 속속 발표하고 있으며, 이는 더 이상 국내 기업들이 임베디드 시스템이 갖을 수 밖에 없는 용량과 성능의 제약을 빌미로 소프트웨어 개발 영역의 거대한 trend를 외면할 수 없다는 신호를 주고 있다.
개발의 자동화라는 trend를 내가 더 적극적으로 받아들이고 발전시키면 이를 내가 조정해가며 생존할 수 있으나, 손바닥으로 하늘을 가리고 안주하면 trend에 의해 내가 교체되버릴 수 있다는 것을 명심해야 할 것이다. 예전, 메모리와 성능의 제약을 이유로 DOS에 안주하려던 소위 전문가들이 Windows라는 거대한 trend를 놓쳤던 기억을 되살려 볼 필요가 있지 않을까?
한국이 소프트웨어 강국으로 대대로 번영할 수 있기를 기원하며…
-한국 IBM 오세종 과장
Table, Figure 인용 :
[1] Jerry Crasner, Ph.D., “What Do You Do When The Horse Youre Riding Drops Dead”, EMF, American Technology International Inc., March 2007