• 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학론

2020/8 컴퓨터/IT 51위 | 현재 컴퓨터/IT 51위 |

• [시리즈] 에이콘 임베디드 시스템 프로그래밍 시리즈 [43]

출판사 리뷰

출판사 서평 ★ 요약 ★ 이 책은 임베디드 소프트웨어 개발자가 알아야 할 종합 상식을 다룬다. 즉,임베디드 소프트웨어 개발 시에 고려해야 할 다양한 측면인, 설계와 개발 도구, 프로그래밍 언어, 특히 C/C++에서? 고려할 점, 실시간 시스템, 네트워킹, 리눅스나 안드로이드 같은 오픈소스 플랫폼, 최신의 멀티코어까지 매우 광범위한 내용을 다룬다. 또한 임베디드 시스템 개발에서 소프트웨어 개발 방법이 어떻게 발전되어 왔는지에 관한 역사도 엿볼 수 있다. ★ 이 책에서 다루는 내용 ★ 임베디드 분야가 커짐에 따라, 개발자가 더 정교한... ★ 요약 ★ 이 책은 임베디드 소프트웨어 개발자가 알아야 할 종합 상식을 다룬다. 즉,임베디드 소프트웨어 개발 시에 고려해야 할 다양한 측면인, 설계와 개발 도구, 프로그래밍 언어, 특히 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++ 코드가 있다. 제품 크기, 아주 작은

★ 저자 서문 ★

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

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

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

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

★ 옮긴이의 말 ★

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

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

목차
1장 임베디드 소프트웨어
__1.1 임베디드 애플리케이션 동작
____1.1.1 개발 시 문제점
____1.1.2 소프트웨어 재사용
____1.1.3 실시간 운영체제
____1.1.4 파일 시스템
____1.1.5 USB
____1.1.6 그래픽
____1.1.7 네트워킹
____1.1.8 결론
__1.2 임베디드 시스템 메모리
____1.2.1 메모리
____1.2.2 구현 시 문제
____1.2.3 모두 잘못되는 경우
____1.2.4 모두 올바른 경우
__1.3 메모리 구조
____1.3.1 옵션
____1.3.2 균일한 단일 공간 메모리
____1.3.3 세그먼트 메모리
____1.3.4 뱅크 교환 메모리
____1.3.5 다중 공간 메모리
____1.3.6 가상 메모리
____1.3.7 캐시 메모리
____1.3.8 메모리 관리 장치
____1.3.9 결론
__1.4 소프트웨어가 하드웨어 설계에 미치는 영향
____1.4.1 누가 하드웨어를 설계하는가?
____1.4.2 하드웨어를 이끄는 소프트웨어
____1.4.3 소프트웨어와 하드웨어 간 균형 조정
____1.4.4 하드웨어 디버깅
____1.4.5 자가 진단 지원
____1.4.6 결론
__1.5 기존 소프트웨어를 새로운 프로세서 아키텍처로 이전
____1.5.1 타겟 특화
____1.5.2 RTOS 이슈
____1.5.3 프로세서 이동과 공개 표준
____1.5.4 결론
__1.6 운송 애플리케이션용 임베디드 소프트웨어
____1.6.1 소개
____1.6.2 운송 시스템 특징
____1.6.3 프로그래밍 이슈
____1.6.4 실시간 운영체제를 사용하는 이유
____1.6.5 결론
__1.7 시스템온칩 설계 시 CPU를 선택하는 방법
____1.7.1 설계 복잡도
____1.7.2 설계 재사용
____1.7.3 메모리 구조와 보호
____1.7.4 CPU 성능
____1.7.5 전력 소모
____1.7.6 비용
____1.7.7 소프트웨어 이슈
____1.7.8 멀티코어 SoC
____1.7.9 결론
__1.8 USB 소프트웨어 소개
____1.8.1 USB란?
____1.8.2 USB 주변장치
____1.8.3 USB 통신
____1.8.4 USB 소프트웨어
____1.8.5 USB와 임베디드 시스템
____1.8.6 결론
__1.9 USB 3.0 소개
____1.9.1 소개
____1.9.2 버스 구조
____1.9.3 케이블과 커넥터
____1.9.4 패킷 라우팅
____1.9.5 양방향 프로토콜 흐름
____1.9.6 벌크 스트리밍
____1.9.7 USB 3.0 전원 관리
____1.9.8 USB 3.0 허브
____1.9.9 xHCI - 새로운 호스트 제어기 인터페이스
____1.9.10 USB의 향후 응용
____1.9.11 결론
____추가 참고 도서 목록
2장 설계와 개발
__2.1 최신 임베디드 시스템 소프트웨어 개발 기술
____2.1.1 마이크로프로세서 장치 기술
____2.1.2 시스템 구조
____2.1.3 설계 구성
____2.1.4 소프트웨어 내용물
____2.1.5 프로그래밍 언어
____2.1.6 소프트웨어 팀 크기와 배치
____2.1.7 UML과 모델링
____2.1.8 주요 기술
____2.1.9 결론
__2.2 개발 툴 선택
____2.2.1 개발 툴 체인
____2.2.2 컴파일러 특징
____2.2.3 임베디드 시스템을 위한 확장
____2.2.4 최적화
____2.2.5 빌드 툴: 주요 이슈 정리
____2.2.6 디버깅
____2.2.7 디버그 툴: 주요 이슈 정리
____2.2.8 표준과 개발 툴 통합
____2.2.9 개발 툴을 고려한 선택
____2.2.10 결론
__2.3 이클립스: 임베디드 툴 통합 환경
____2.3.1 소개
____2.3.2 이클립스 플랫폼 철학
____2.3.3 플랫폼
____2.3.4 임베디드용 이클립스
____2.3.5 결론
__2.4 RTOS 경계를 넘는 개발 시스템
____2.4.1 표준으로 해결이 될까?
____2.4.2 이클립스를 통한 해결
____2.4.3 이클립스 플러그인
____2.4.4 이클립스 라이선스
____2.4.5 이클립스 사용 장점
____2.4.6 퍼스펙티브
____2.4.7 임베디드용이 아닌 플러그인
__2.5 임베디드 소프트웨어와 UML
____2.5.1 왜 UML로 모델링하는가?
____2.5.2 애플리케이션과 구조의 분리
____2.5.3 xtUML 코드 생성
____2.5.4 결론
__2.6 사용자 인터페이스 개발
____2.6.1 다양한 사용자 인터페이스
____2.6.2 사용자 인터페이스 구현
____2.6.3 합리적 UI 솔루션
____2.6.4 결론
__2.7 소프트웨어와 전력 소모
____2.7.1 소개
____2.7.2 소프트웨어 이슈
____2.7.3 소프트웨어에서 전력 제어
____2.7.4 멀티코어
____2.7.5 하드웨어 이슈
____2.7.6 가상 프로그래밍
____2.7.7 결론
3장 프로그래밍
__3.1 이국적 메모리 프로그래밍
____3.1.1 이국적 메모리
____3.1.2 비휘발성 RAM
____3.1.3 공유 메모리
____3.1.4 결론
__3.2 임베디드 시스템 자가 테스팅
____3.2.1 메모리 테스팅
____3.2.2 입/출력 디바이스
____3.2.3 멀티스레딩 이슈
____3.2.4 와치독
____3.2.5 자가 테스트 실패
____3.2.6 마지막 사항
__3.3 명령 행 인터프리터
____3.3.1 임베디드 시스템 진단
____3.3.2 임베디드 시스템 동작 개시
____3.3.3 명령 행 인터프리터: 요구사항
____3.3.4 명령 행 인터프리터 설계
____3.3.5 CLI 구현
____3.3.6 CLI 프로토타입 코드
____3.3.7 결론
__3.4 교통신호등: 임베디드 소프트웨어 애플리케이션
____3.4.1 애플리케이션
____3.4.2 하드웨어 설정
____3.4.3 프로그램 구현
____3.4.4 메인 루프
____3.4.5 인터럽트
____3.4.6 시간 지연
____3.4.7 신호등
____3.4.8 전역 변수 사용
4장 C 언어
__4.1 C 커먼
__4.2 C 함수 프로토타입 사용
____4.2.1 프로토타입 이전
____4.2.2 프로토타입 적용
____4.2.3 프로토타입 사용
____4.3 인터럽트 함수와 ANSI 키워드
____4.3.1 인터럽트 함수
____4.3.2 ANSI C의 const 키워드
____4.3.3 ANSI C Volatile 키워드
__4.4 비트
____4.4.1 비트 연산자
____4.4.2 이진 상수
____4.4.3 구조체의 비트 필드
____4.4.4 마이크로프로세서 비트 필드 명령어
____4.4.5 I/O 장치와 비트 필드
____4.4.6 결론
__4.5 부동 소수점 애플리케이션 프로그래밍
____4.5.1 테스트 케이스
____4.5.2 테스트 케이스 실행
____4.5.3 문제 해결
____4.5.4 결론
__4.6 다른 관점에서 본 C 언어
____4.6.1 정적인 것
____4.6.2 세미콜론의 모든 것
____4.6.3 포인터와 포인터 연산
__4.6.4 영악해서 덜 똑똑해지고 마는 때
____4.6.5 결론
__4.7 함수 호출 오버헤드 줄이기
____4.7.1 컴파일러와 구조화된 코드
____4.7.2 인라인 함수
____4.7.3 함수 호출
____4.7.4 인자 전달
____4.7.5 지역 저장소
____4.7.6 스택 프레임 생성
____4.7.7 리턴 값
____4.7.8 결론
__4.8 구조체 레이아웃으로 전문가 되기
____4.8.1 주요 개념
____