이 책은 임베디드 소프트웨어 개발자가 알아야 할 종합 상식을 다룬다. 즉,임베디드 소프트웨어 개발 시에 고려해야 할 다양한 측면인, 설계와 개발 도구, 프로그래밍 언어, 특히 C/C++에서 고려할 점, 실시간 시스템, 네트워킹, 리눅스나 안드로이드 같은 오픈소스 플랫폼, 최신의 멀티코어까지 매우 광범위한 내용을 다룬다. 또한 임베디드 시스템 개발에서 소프트웨어 개발 방법이 어떻게 발전되어 왔는지에 관한 역사도 엿볼 수 있다.

임베디드 분야가 커짐에 따라, 개발자가 더 정교한 디바이스에 대한 요구사항을 만족하려면 더 빠르고 더 효율적이며 더 강력한 소프트웨어를 만들기 위해 다양하고 복잡한 주제를 제대로 이해하고 있어야 한다.

이 책에서는 임베디드 엔지니어가 성공하기 위해 알아둬야 할 모든 핵심 주제들, 즉 설계와 개발, 프로그래밍, C/C++와 UML 언어, 실시간 운영체제 고려사항, 네트워킹 등을 다룬다. 특히 개정판에서는 리눅스와 안드로이드, 멀티코어와 관련한 새 내용을 추가해 엔지니어가 성공하는 데 필요한 최신의 실전 노하우를 제공한다.

저자 콜린 월즈가 실무에서 얻은 경험과 통찰력을 이용해 임베디드 소프트웨어 개발의 전체 주기, 즉 설계와 개발, 관리, 디버깅 절차, 라이선싱, 재사용을 설명한다. 임베디드 분야에 처음인 초보 엔지니어들은 물론, 기술을 확장하고 싶어 하는 숙련된 엔지니어들을 위해 상세한 팁과 기술, 테크놀로지에 대한 세부적인 설명을 제공한다.

• 리눅스와 안드로이드, 멀티코어 등 최신 임베디드 소프트웨어 개발 내용 추가
• 각 장을 소개하고 연결 관계를 보여주는 로드맵 제공
• 소스코드와 파워포인트 슬라이드를 통해 유용한 학습 자료와 실전 경험을 제공

임베디드 소프트웨어에 관심이 있다면 유용한 내용이 많다. 폭넓은 범위의 내용을 다루므로 숙련가뿐 아니라 초보자에게도 유용할 것이다. 일반 소프트웨어 개발에 종사하는 사람이라면, 일부 글에서는 하드웨어에 관한 글이라는 느낌도 받을 것이다. 하드웨어 설계 분야에 종사하는 사람이라면 소프트웨어 세계에 대해 이해하게 될 것이다. 교육 현장에서 교재로 사용한다면, 실무든 이론 교육이든 학생들에게 유용한 배경 지식을 줄 수 있을 것이다.

책에 넣을 자료를 선택하면서 모든 글이 현재 임베디드 소프트웨어 개발 관행과 기술에 연관 있는지를 확인하는 것을 목표로 했다. 물론 많은 글이 역사적인 관점을 다루지만 단독으로는 책에 포함될 만큼 충분하진 않았다. 상당수 글은 현재 기술 유행에 맞지 않거나 다른 새 기술에 의해 대체돼버린 것이어서 제외했다. 내가 만일 『임베디드 소프트웨어 역사』라는 책을 쓰게 된다면 이런 내용들을 포함할 것이다. ‘이 모든 것의 시작으로부터 50주년이 되는 해(인텔4004가 출시된 지 50년이 되는 2020년)를 기념해 임베디드 소프트웨어 역사 관련 책을 출판할 계획이다.’

이 책을 올바로 읽기 위한 특정한 방법이 있는 것은 아니다. 앞부터 뒤까지 책을 읽을 때 독자가 이해하기 쉽도록 글의 순서를 정하기 위해 노력했다. 그리고 장 전반에 걸쳐 글을 잘 분류하여 독자가 관심 있어 하는 내용을 찾기 쉽게 하고, 책을 읽을 때 책 여기저기를 넘겨 보는 불편함이 없도록 공을 들였다. 책을 참고할 때 부적절한 색인 때문에 불만스러운 경우가 있다. 그래서 관심 있는 내용을 찾을 때 색인이 효과적인 방법이 될 수 있도록 찾아보기 항목을 고르는 데 신경을 썼다.

무엇을 기대하는가? 완벽함인가?
왜 수많은 펌웨어 프로젝트는 기한을 넘기게 되고 버그 때문에 고생하게 될까? 소프트웨어 복잡도와 버그 원인을 다루는 이론은 차고 넘친다. 하지만 가장 직접적인 원인은 코딩이라는 것이 호모 사피엔스(Homo Sapiens)에게 맞는 일이 아니라는 데 있다. 코딩을 할 때는 정말이지 슈퍼맨 수준의 정확도가 필요하다. 그러나 당연한 말이지만 슈퍼맨은 없다. 동굴에 살던 원시인들은 사냥한 가젤을 모두 소유할 이유가 없었다. 배고픔을 견딜 정도면 충분했다. 농부는 뿌린 씨앗에서 모두 싹이 날 거라고 기대하지 않는다. 어느 정도의 손실을 감안하고 받아들인다. 상인은 대다수 고객이 만족하기를 바라는 것이지 모든 고객이 만족할 서비스를 할 수 있을 거라고 기대하지는 않는다. 자녀가 모든 과목 점수로 ‘수’를 받아온다면 부모는 정말 신날 것이다. 하지만 90점 이상이면 수에 해당한다. 즉 100점이 아니어도 받을 수 있다는 말이다. 인생에서 목표 점수를 10% 이상 벗어나지 않는다면 수를 받을 것이고 노력한 결과로 성공을 얻을 수 있다.

하지만 소프트웨어는 다르다. 90% 수준에 머무르면 완전한 재앙이라고 봐야 한다. 결국 소프트웨어가 쓸모없는 제품이 되고 만다. 99.9%가 완료된 제품도 쓸모 없게 된다. 정확도가 99.9%인 10만 라인짜리 코드라도 드러나지 않은 에러는 100개나 있게 된다. 이걸로는 불충분하다. 소프트웨어는 완벽에 가까워야 한다. 하지만 이는 실수하기 쉬운 인간의 본성에 반한다. 또한 소프트웨어에는 높은 엔트로피 특성이 있다. 완벽한 100라인짜리 코드로 된 시스템을 작성할 수는 있다. 하지만 코드의 크기가 커지면 완벽 또는 완벽에 가까운 시스템 제작에 더욱 더 많은 노력이 들어간다. 비트가 울타리를 벗어나려는 소라고 한다면, 코딩 목동은 소 무리가 커질수록 길 잃은 소가 생기지 않게 더욱더 열심히 일해야 하는 이치와 같다.

그러면 해결책은 무엇일까? 답이 있기는 할까? 펌웨어는 얼마나 좋아야 하고 얼마나 좋아질 수 있을까? 완벽이나 완벽에 가까움을 추구하는 게 헛된 일일까? 복합 시스템(complex system)은 새로운 개념이다. 많아야 대여섯 개 정도의 능동 부품(active device)으로 동작하는 초기 트랜지스터 라디오를 기억할 것이다. 1970년대에 흔했던 진공관 텔레비전은 15개에서 20개의 진공관으로 동작했는데, 이 진공관은 정도의 차이는 있어도 대략 같은 수의 트랜지스터와 비슷한 성능을 낸다. 1940년경 에니악(ENIAC) 컴퓨터는 1만 8,000개의 진공관을 사용했다. 이 컴퓨터를 작동하려고 많은 기술자들이 여분 진공관을 담은 쇼핑 카트를 끌고 다니면서 타버린 진공관을 계속 교체해야 했다. 엄청나게 많은 능동 부품이 있는 것 같지만, 25년이 된 Z80 칩조차도 애니악 의 진공관 한 개보다 수십만 배 작은 다이(die) 공간에 애니악이 지닌 진공관의 1/4 만큼이나 들어간다.

컴퓨터의 구성 요소 중 하나인 펜티엄IV에는 4,500만 개나 되는 트랜지스터가 있다. 좀 큰 메모리 칩에는 약 3억 개 정도 되는 트랜지스터가 있다. 인텔에서는 10년 내로 프로세서에 10억 개의 트랜지스터가 들어갈 것으로 예상한다. 인사말을 담는 전자 카드와 같은 단순한 임베디드 시스템조차도 능동 부품이 수천 개나 들어간다.

소프트웨어의 길이가 기하급수적으로 늘고 있다. 특히 임베디드 애플리케이션에서는 더욱 그렇다. 1975년에 길이가 1만 라인 정도 되는 어셈블리 코드는 매우 큰 편에 속했다. 그 당시 개발 툴이 종이테이프, 대용량 저장장치용 카세트, 조잡한 콘솔용 텔레타이프였다는 점을 고려해보면 이정도 크기의 프로젝트를 진행하기는 매우 어려웠다. 요즘에는 1만 라인이나 되는 C코드(어셈블리 코드로 만들려면 아마 3만 라인에서 5만 라인 정도를 코딩해야 한다)라도 작은 프로그램으로 여겨진다. 휴대전화에는 500만 라인이나 되는 C 코드 또는 C++ 코드가 있다. 제품 크기, 아주 작은 전력 소모, 놀랄 만큼 짧은 개발 기간을 고려해보면 대단한 일인 셈이다.

메모리 사용량으로 소프트웨어 크기를 재기도 한다. 1975년에는 256바이트(오타가 아님) EPROM에 4,000바이트 크기 프로그램을 저장하려면 EPROM 16개가 필요했다. 작은 임베디드 시스템이라도 매우 비쌀 수밖에 없었다. 요즘은 어떤가? 아주 작은 앱에도 128,000 크기 플래시 메모리가 필요할 정도다. 그리고 실제 메모리 크기 때문이라기보다는 주소 공간 지정에 필요한 이유로 프로세서가 8비트에서 16비트로, 16비트에서 32비트 이상으로 변화해 왔다. 1970년대 후반에 시게이트(Seagate)에서 최초의 소형 윈체스터(Winchester) 하드디스크를 출시했다. 이 하드디스크는 약 4.5kg 무게에 5MB 용량을 지녔으며 가격은 무려 1,500달러였다. 그때는 5MB라는 크기가 대부분의 사용자에게 충분한 크기였다. 지금은 20GB용량 디스크도 셔츠 주머니에 들어갈 정도이고, 매우 저렴할 뿐만 아니라 데이터를 순식간에 채울 수도 있다.

이처럼 시스템은 크기나 복잡도 면에서 급속도로 커지고 있다. 개발자들이 이런 거대한 애플리케이션을 올바르게 만들 만큼 뛰어날까? 간단한 애플리케이션조차도 완벽하게 만드는 게 쉽지 않다. 하물며 큰 애플리케이션에 결함이 없을 수는 없다. 소프트웨어가 커지면 점점 더 꼬이게 되므로, 한 부분을 변경하면 다른 부분에 영향을 주고, 때로 그 영향이 엄청난 경우도 있다. 설계를 잘못해서인 경우도 있고, 시스템이 커지면서 생긴 문제인 경우도 있다.

분명한 점은 하드웨어를 완벽하게 만드는 일도 매우 어렵다는 점이다. 오래된 프로세서조차도 정오표(errata sheet)가 딸려 나온다. 정오표가 얼마나 큰지, 데이터시트와 경쟁할 정도다. 악명 높은 펜티엄 나눗셈 버그는 수많은 버그 중 하나일 뿐이다. 요즘에도 펜티엄III의 정오표(스펙 업데이트, Specification Update라는 말로 바꿈)에는 83개의 이슈가 있다. 모토롤라의 MPC555에는 거의 100개나 되는 문제가 있다.

임베디드 시스템 분야에서 현재 기술을 어느 정도 신뢰할 수 있을까? 아무도 모른다. 연구가 거의 없는 분야기도 하다. 하지만 이런 연구에 사용할 원 데이터는 많으며, 일부 데이터에 따르면 개발자들은 제대로 연구하지 않는 듯이 보인다.

화성 탐사선 패스파인더가 착륙선이 하강 중 소프트웨어 중단이라는 심각한 오류에 도 불구하고 성공적으로 임무를 마쳤다. 지상에서 이미 알고 있었던, 작은 문제로 치부하고 무시했던 우선순위 역전 문제(priority inversion problem)가 원인이었다. 하지만 잘 설계한 와치독(watchdog) 타이머 복구 정책 덕에 임무를 마칠 수 있었다. 이는 외부 하드웨어나 소프트웨어를 추가해 예상치 못한 소프트웨어 오류를 다루는 기술의 중요성을 보여주는 좋은 사례이다.

하드웨어와 소프트웨어가 복잡도뿐 아니라 크기도 계속 커진다는 것은 분명한 사실이다. 패스파인더의 우선순위 역전 문제는 RTOS가 필요 없던 마이크로프로세서 초기에는 알려지지 않은 문제였다. 현재에는 대부분의 임베디드 시스템에는 운영체제가 들어있고 위와 같은 위험에 노출돼 있다.

복잡도가 폭발적으로 증가하면 개발자는 무엇을 해야 할까? 새로운 기술을 배우는 일에 계속 시간을 투자해야 한다는 점은 분명하다. 물론 기존 기술도 학습해야 한다. 이미 배웠지만 잊어버린 것들도 공부해야 한다. 결국 예전 개요서와 새로운 개요서, C 프로그래밍의 필수 내용부터 UML과 그 이상의 것들을 다룬 책에 파묻혀 매일 저녁 내내 쭈그리고 책이나 봐야 할 것이다. 이 책의 저자인 콜린은 숙련된 기술자로서, 이러한 일을 어떻게 했는지 실질적인 많은 조언과 경험을 책을 통해 이야기한다.

우리는 경험에서 배운다. 하지만 지식을 습득하는 데는 큰 대가가 따르는 방법이다. 그러므로 거장의 지혜를 듣는 것이고 최소한 이 책을 읽는 동안이라도 거장의 견습생이 되는 편이 더 낫다. 독자는 새로운 통찰력을 갖게 되고 더욱 다양한 도구들로 복잡한 문제를 해결하는 능력을 갖추게 될 것이다. 완벽에 이르기가 어려울지라도 현명한 개발자는 부단히 완벽함에 이르고자 노력할 것이다.

- 잭 갠슬(Jack Ganssle) / 『임베디드 시스템 대사전』(에이콘출판) 저자

- 개정판을 펴내면서 -
책의 초판이 출간된 후로 세상은 많이 달라졌다. 많은 것이 바뀌었지만 그대로 남아있는 것도 있다. 임베디드 소프트웨어 분야에는 새로운 프로세서와 기술이 등장하고 결과적으로 임베디드 소프트웨어 엔지니어의 세상을 변화시켰다. 이런 것을 염두에 두고 엘스비어(Elsevier)에서 개정판의 필요성을 느끼고 내게 연락했다. 나는 개정판 작업을 기쁘게 수락했다.

기존 내용에 덧붙여 새 글을 추가했고 오픈 소스 소프트웨어와 멀티코어를 다루는 단원을 두 개 추가했다. 물론 별로 관련 없어 보이는 내용들을 삭제하기도 했다.

그 외에 내 개인적 상황도 바뀌었다. 내 아내가 최고의 치료를 받았지만 2006년 6월에 저 세상으로 가고 말았다. 그 치료가 없었다면 단지 몇 주밖에 살지 못했을 것이다. 그 치료로 인해 2년을 더 살 수 있었고 어느 정도 기간 동안은 양질의 삶을 누릴 수 있었다. 내 딸들과 나는 잘 지내고 있고 나는 여전히 멘토 그래픽스(Mentor Graphics)에서 일하고 있으며 여전히 임베디드 소프트웨어와 관련된 일을 하고 있다.

다시 한 번 나를 고용해준 분들이 이번 개정판의 수익금도 LINC에 기부할 수 있도록 해준 것에 기쁘게 감사한다. 기부된 돈이 현명하게 사용될 거란 데에 여전히 확신한다.

콜린 월즈(Colin Walls)

25년 이상 전자 산업, 특히 임베디드 소프트웨어에 경험을 쌓아 왔다. 학회와 세미나에서 발표도 하고, 수많은 기술 문서를 작성했고, 임베디드 소프트웨어에 관한 책도 두 권 썼다. 현재 멘토 그래픽스 임베디드 소프트웨어 부서의 마케팅 팀에서 근무한다. 멘토 웹사이트(blogs.mentor.com/colinwalls)에 자주 글을 올린다.

대학 졸업 후 임베디드 시스템 분야에서 오랫동안 일해왔고, 지금은 대학생들을 가르치는 입장에서, 임베디드 소프트웨어를 다루는 좋은 책을 갈망해 왔다. 물론 웹을 검색해 보면 다양한 자료가 있지만, 특히나 수업에서 쓰거나 누군가에게 개론서로 추천해 줄만한 책이 마땅하지 않았다. 대부분의 책이 ARM 계열 하드웨어와 디바이스 드라이버나 BSP 정도를 다루는 내용으로 협소한 내용만 다루고 있었다. 그리고 소프트웨어 개발자의 관점에서 다루는 내용이 많이 부족한 것이 아쉬운 점이었다. 물론 임베디드 시스템은 데스크톱이나 서버 시스템과 달리 하드웨어의 종류가 너무 다양하기 때문에 이 모든 것을 다루는 것이 불가능할 것이다. 그런데 이 책은 소프트웨어 개발자에게 임베디드 소프트웨어 개발에 대한 최소한의 필요한 내용을 거의 다 설명해주고 있다. 각각에 대한 깊이 있는 내용이 부족할 수 있으나, 최소한 독자가 헤매지 않도록 길을 보여주고 있다.

이 책이 임베디드 소프트웨어 개발을 막 시작하려는 개발자나 학생들에게 아주 좋은 지침서가 될 것이라 확신이 들었고, 학생들에게 조금이라도 쉽게 전달해줄 생각으로 번역을 시작했다. 하지만 강의와 연구 중에 틈틈이 번역을 하다 보니 거의 2년 만에 책이 나오게 되었다. 이 책의 내용들은 대부분 저자나 관련 전문가가 과거에 기고했던 단편들을 모아서 최신 경향에 맞도록 수정하고 편집한 것이다. 90년대에 썼던 글도 포함되어 있는데, 오래되었지만 최신 글이라고 해도 믿을 만큼 최근 임베디드 소프트웨어 경향을 잘 반영하고 있다. 원서가 출판된 지 2년이 지나 번역서가 나오게 되었으나, 여전히 임베디드 소프트웨어의 핵심들을 잘 짚고, 초급 임베디드 개발자나 학생들에게 많은 도움이 될 것이라 생각한다.

허준영

서울대학교 컴퓨터공학과를 졸업하고 원격 감시 시스템 개발 회사에서 소프트웨어 개발을 시작했다. 여기에서 처음으로 임베디드 시스템을 접하게 되었다. 그 후 잠시 보안 회사에 몸담았다가 서울대학교 컴퓨터공학과 대학원으로 진학해 시스템 소프트웨어와 임베디드 시스템에 대한 연구를 했다. 특히, 초소형 임베디드 시스템인 센서 노드의 시스템 소프트웨어에 대한 연구를 주로 했다. 그리고 2009년에 박사 학위를 받았고 서울대 차세대 융합 기술 연구원에서 웨어러블 컴퓨팅에 대한 연구를 잠시 했다. 그 후 2009년 2학기부터 한성대학교 컴퓨터공학과 교수로 임용되어 현재까지 학생들을 가르치고 있다. 또한 임베디드 소프트웨어 기술 포럼에서 정보기기 소프트웨어 분과장을 맡고 있고, 한국정보통신기술협회(TTA)의 임베디드 소프트웨어 PG에서 위원으로 활동하고 있다. 그리고 임베디드 소프트웨어 경진대회 심사위원으로도 활동하고 있다.