핵심 요약
- 임베디드 소프트웨어 전문가 잭 갠슬이 임베디드 프로젝트가 파행을 겪는 핵심 원인들을 회고했습니다.
- 하드웨어 장비에는 수천만 원을 쓰면서 컴파일러 등 소프트웨어 도구 비용은 아까워하고, 설계 없이 코딩부터 서두르는 관행을 꼬집었습니다.
- 안전성이 검증되지 않은 C 언어 코딩 습관과 도구 부재가 결합할 때 프로젝트가 실패하기 쉽다고 경고했습니다.
요약 임베디드 시스템 전문가 잭 갠슬(Jack Ganssle)이 2002년 기고를 통해 지적한 '임베디드 프로젝트가 망가지는 대표적인 이유'들이 개발자 커뮤니티에서 다시금 공감을 사고 있습니다.\n\n글에서 첫 번째로 꼽힌 원인은 '자원 부족'입니다. 전투기 같은 고성능 장비에서 소프트웨어(펌웨어)는 무게를 늘리지 않으면서도 기능을 추가할 수 있는 수단으로 각광받았고, 오늘날 전투기 전체 비용의 절반 가까이를 차지할 만큼 비싼 영역이 되었습니다. 임베디드 소프트웨어의 규모가 급격히 팽창함에도 불구하고, 현실에서 소프트웨어 팀은 기본적인 개발 툴 예산조차 승인받기 어렵습니다. 하드웨어 엔지니어들은 수만 달러짜리 계측 장비를 쉽게 지원받는 반면, 소프트웨어 팀은 컴파일러나 정적 분석기 비용 몇천 달러를 결재받지 못해 "그냥 GNU 오픈소스나 포팅해서 써라"라는 말을 듣기 일쑤라는 것입니다.\n\n두 번째 원인은 '너무 성급한 코딩 시작'입니다. 초기 설계와 아키텍처에 대한 면밀한 분석 없이 무작정 에디터에 'void main()'부터 치고 들어가는 관행이 프로젝트를 수렁으로 끕니다. 특히 임베디드는 성능이 부족한 CPU를 고르거나 메모리가 부족한 보드를 만들어버리면 나중에 되돌릴 수 없는 재앙이 됩니다. 실시간 처리(RTOS) 도입 여부나 상태 머신 구조 같은 핵심 설계 결정을 건너뛰고 첫 주부터 화면에 뭔가 돌아가는 모습만 보여주면, 경영진은 "벌써 다 만들었다"며 엉뚱한 착각에 빠지게 됩니다.\n\n세 번째로는 'C 언어의 무분별한 사용 습관'이 지목되었습니다. C는 강력하고 배우기 쉬운 언어지만, 디버깅 지옥에 빠지기 쉬운 구조를 가지고 있습니다. 안전성이 극도로 중요한 분야에서 쓰이는 Ada나 SPARK 같은 언어들은 문법 자체에서 엄격한 고민을 강제해 C 언어 대비 버그 발생률이 절반에서 6분의 1 수준에 불과합니다. C 언어로 프로젝트를 안정적으로 끌고 가기 위해서는 Lint, 복잡도 분석기, 정적 분석 툴, 정기적인 코드 리뷰 등 철저한 안전장치와 규율이 반드시 동반되어야 한다고 글은 강조합니다.
Sponsored · 광고