한빛출판네트워크

임베디드 시스템 만들기

중학교 때, 미로를 탈출하는 마이크로 마우스가 처음 등장했다. 살아 있는 쥐처럼 움직이는 마이크로 마우스에 매료되어 버렸다. 초등학교 때부터 더 빠르게 반응하는 게임을 만들고 싶어 6502 어셈블러를 공부한 나였지만, 하드웨어와 소프트웨어가 결합한 마이크로 마우스는 오르기 힘든 산이었다. 하드웨어와 그 하드웨어에 딱 맞게 제작된 소프트웨어에 대한 동경은 그 때부터 시작되었다. 소프트웨어 개발, 컨설팅, 아키텍팅을 직업으로 삼으면서 하드웨어에 대한 동경은 점차 소프트웨어 공학으로 옮겨 갔다. GoF의 디자인 패턴을 처음 읽었을 때 어찌나 놀라왔는지 몇 달 동안 놓을 수가 없었다. 살아온 과정이 하드웨어와 디자인 패턴을 결합한 이 책을 만날 수 밖에 없었던 이유였나 보다.
이 책은 변화에 잘 대응할 수 있도록 임베디드 시스템을 설계하고 구현하는 방법을 설명한다. 보통 OO 언어로 구현하는 다양한 디자인 패턴을 임베디드 시스템의 주력 언어인 C로 구현하는 방법을 설명한다. 또, C로 OO 프로그래밍의 기본 철학인 캡슐화, 정보은폐, 위임을 어떻게 구현하는 지 설명한다. 디자인 패턴을 적용하여 임베디드 시스템의 문제들을 해결한다. 또, 데이터시트 읽기, 프로세서, 회로도 읽기, 디버깅, 테스팅을 다루어서 하드웨어에 대한 기초 설명도 빼놓지 않았다. 임베디드 시스템이 갖춰야 하는 OS 수준 작업도 I/O, Timer, IRQ, 태스크 관리, 주변장치 통신으로 나누어 잘 설명한다. 부트로더, 코드 올리기, 메모리 관리, 수치 계산, 전력 관리 같이 응용프로그램 수준 작업도 잘 설명한다.
초보자가 읽기엔 약간 부담스러울 수 있지만 임베디드 시스템 개발 전반을 잘 다룬 책으로 추천한다.

우선 하드웨어 개발 사이클을 경험하지 못했기 때문에 이 책의 내용이 낯설었다. 하지만 오라일리 책의 특징인 정말 쉽게 쓰여져 있는 내용을 통해 웹 사전을 찾아가며 학습을 할 수 있었고, 관심을 갖고 있었던 임베디드의 첫 계단을 밟을 수 있었다.

이 책에서 얻을 수 있었던 가장 중요한 부분은 프로젝트 계획표의 상세한 내용이었다. 하드웨어팀과 어떤 계획을 통해 일을 진행하는가 그에 대한 프로젝트 계획과 함께 그 상세 내용이 내가 하드웨어 프로젝트를 이해하는데 도움을 주었다.


임베디드 시스템의 사전적 정의를 이야기 한다면, 기계 또는 전자 장치의 두뇌 역할을 하는 마이크로 프로세서를 장착해 설계함으로써 효과적인 제어를 할 수 있도록 하는 시스템을 말한다. 이 때 소프트웨어(운영체제)를 컴퓨터처럼 디스크에서 읽어들이는 게 아니라 칩에 담아 기기에 내장시킨 형태의 장치를 말하는 것.






임베디드 시스템에서는 설계과정에서 불필요한 자원을 최소화 하는 것에 대해 언급한다.

그 고려해야 할 항목 5가지.

메모리(RAM)
코드공간(ROM, Flash)
프로세서 사이클 (속도)
전력 소모
프로세서 주변장치
p. 42

코딩 가이드라인이 중요한 이유는 디버깅 시간을 절약하여 생산성을 높일 수 있기 때문이다.

구글 오픈소스 프로젝트 스타일 가이드: https://code.google.com/p/google-styleguide/



p. 55

임베디드 시스템에서는 MVC로 가상박스나 샌드박스를 제공해서 알고리즘 개발과 검증을 가능하게 함



그렇다면 샌드박스의 사전적 정의는 무엇인가?

보호된 영역 내에서 프로그램을 동작시키는 것으로, 외부 요인에 의해 악영향이 미치는 것을 방지하는 보안 모델. (‘아이를 모래밭(샌드 박스)의 밖에서 놀리지 않는다’라고 하는 말이 어원). 이 모델에서는 외부로부터 받은 프로그램을 보호된 영역, 즉 ‘상자’ 안에 가두고 나서 동작.

한 블로그의 정리한 내용을 인용하자면,





디자인 패턴을 알기 전에 객체 지향을 알아야 한다.



물론 현대 개발자 중에 객체 지향을 모르는 경우는 거의 없을 것입니다. 하지만 중요한 것은 디자인 패턴은 객체 지향을 기반으로 한다는 것입니다. 객체 지향에 대한 완벽한 이해가 기본이 되어야 디자인 패턴을 이해할 수 있습니다.객체 지향에 대한 개념이 불명확한 초보 개발자들 혹은 절차 지향에 익숙한 개발자가 있을 경우는 디자인 패턴은 그만큼 불확실해 질 수 있으며 오히려 더 잘못된 설계를 야기할 수 있습니다.



개발자의 예측이 얼마나 적중할 것인가?



디자인 패턴은 설계 단계를 강조하고 있습니다. 즉 변화 혹은 변경이 있을 것으로 예상되는 부분에 디자인 패턴을 적용해서 유용하게 대처하는 것입니다. 하지만 중요한 것은 개발자의 예측이 항상 맞는 것은 아니라는 점입니다. 예를들어 이 부분은 유연한 변경이 필요하므로 디자인 패턴을 적용하고 이 부분은 그렇지 않으니깐 적용하지 말자라고 가정하고 소프트웨어를 설계합니다. 하지만 실제로 고객은 디자인 패턴을 적용한 부분에 대해서는 변경 요청을 하지않지만 적용하지 않은 부분에 대해서는 변경 요청을 할 수 있습니다. 그리고 이러한 일이 매우 자주 발생한 다는 점에 문제가 있습니다. 실제로 개발자의 예측이 맞을 확률은 채 10%가 되지 못한다는 주장도 있습니다.



디자인 패턴은 너무 어렵다.



국내의 대부분의 개발자들이 디자인 패턴을 공부하면서 얘기 하는 것이 너무 어렵다는 점입니다. 그렇다면 정말 디자인 패턴이 어려운 것일까요? 사실은 그렇지가 않습니다. 근데 어렵게 느끼는 이유는 무엇일까요? 그것은 대부분의디자인 패턴 책이 미국 책을 번역한 것이며 인터넷이나 잡지에 나오는 내용들 역시 미국에서 나온 자료를 토대로 하고 있다는 것이 문제 입니다. 미국의 개발자들은 오랜 기간 동엔 객체 지향 -> UML -> 디자인 패턴으로 옮겨오는 과정에 이미 익숙해 있습니다. 즉 디자인 패턴을 설명하면서 객체 지향과 UML에 대한 설명은 전혀 하지 않고 자연스럽게 해당 용어를 사용합니다. 하지만 국내 개발자들은 이러한 체계적인 과정 혹은 기술적인 적립이 매우 짧습니다. 그러므로 객체지향과 UML 등과 같은 체계에 익숙하지 않은 상태에서 디자인 패턴을 접하게 되므로 매우 혼동스러워 하게 되는 것입니다.

만일 디자인 패턴이 어렵다고 느낀 다면 자신이 객체 지향에 대한 이해가 부족하지 않은 지를 의심해 보고 다시 기본부터 공부 해 보는 것이 바람직 합니다.



디자인 패턴의 남용



어떤 분야의 엔지니어든 한번 공부한 것 혹은 터득한 것 그 중에서도 터득하는 데 아주 어려움을 겪었다면 이것을 꼭 적용하고 싶어하는 경향이 있습니다. 그리고 심지어 억지로 디자인 패턴을 적용하는 경우도 발생합니다. 비록 디자인 패턴이 고급 개발자들의 경험의 결과라고는 하지만 잘못 적용된 디자인 패턴은 오히려 소프트웨어를 어렵고 복잡하게만 합니다.



결국 이렇게 적용된 디자인 패턴은 프로젝트에 별 도움이 되지 않으며 재사용과 융통성 역시 이루어지지 않고 그 누구도 재사용하지 않는 결과로 나타나게 됩니다. 개발자들은 그냥 ‘그래 디자인 패턴 한번 적용해 봤어’라고 스스로 위안을 하고 프로젝트를 끝내게 될 것입니다.



결국 디자인 패턴을 성공적으로 적용하기 위해서는 디자인 패턴이 기반으로 하는 객체 지향에 대한 사고를 확실히 이해하고 있어야 하며 뿐만 아니라 디자인 패턴을 맹신해서도 안됩니다. 그러한 이유로 리팩토링과 XP와 같은 다른접근 방법에 대해서도 함께 고려를 하고 병행해서 적용해야 합니다.



--------------------------------------------------------------------------------------------------------------------------



IoT(Internet of Things)의 시대가 다가오고, 아두이노 & 라즈베리파이 등을 작동하고 스스로 자신의 아이디어를 실현하는 개발자들이 증가하고 있다. 이 책을 통해 하드웨어에 익숙해지고자 노력하였고, 다시 한 번 내가 배워야 할 부분이 많다는 것을 실감하게 되었다. 특히 하드웨어와 소프트웨어의 통합 (즉 하드웨어 프로젝트 계획과 그 상세내용) 내용 부분이 가장 필요했던 부분이었다.



간단한 기기를 만들고 작동시키는 것에서 만족하지 않고, 임베디드 시스템을 통해 프로젝트를 진행하고 그를 위한 디자인 패턴에 대한 이해를 하는데 도움이 될 책이다.

일반적인 PC의 시대가 저물고 스마트폰이 대중화되면서 임베디드 시스템에 대한 관심이 높아지고 있다. 하지만, 임베디드 시스템은 PC나 서버에서 구동되는 Application과 달리 Hardware와 밀접한 관계를 가지고 있고, 또한 하드웨어의 제약사항에 많은 영향을 받기 때문에 임베디드 소프트웨어 개발은 일반적인 Application보다 더욱 어렵다.

“디자인 패턴을 적용한 임베디드 시스템”은 이런 어려운 임베디드 시스템을 처음 접하는 개발자가 임베디드 시스템의 개발의 처음 단계부터 마지막 단계까지 설명을 해주는 가이드와 같은 역할을 하는 책이다. 처음에는 임베디드 시스템에 대한 간략한 개요를 설명하고 시스템 아키텍처를 설계하는 방법을 설명한다. 그리고 난 후에 임베디드 시스템이 가지는 성격처럼 하드웨어를 다루는 방법에 대해 설명을 하고, 또한 OS에 대한 설명을 한다. 이후 임베디드 시스템 개발자가 소프트웨어를 개발하는 방법을 설명을 한다. 후반부에는 대다수의 임베디드 시스템의 목표인 소프트웨어 크기를 줄이거나 전력을 줄이는 방법을 설명하며 마무리를 하고 있다.

이 책이 가지는 장단점은 바로 임베디드 시스템을 다룬다는 점일 것이다. 하드웨어와 관계가 많기 때문에 대부분의 임베디드 관련 서적들은 그 내용이 쉽지가 않다. (이 책도 어렵기는 하지만,) 초급 개발자의 관점에 책의 수준을 맞추어 작성을 해서 상대적으로 책의 내용을 이해하기가 쉽다. 또한 (비록 주로 C의 관점에서 코드를 다루지만,) 자바 개발자들에게 친숙한 디자인 패턴의 관점을 차용해서 각 장을 설명해서 (우리나라에 유독 많은 자바 개발자들에게) 내용 이해를 친숙하게 했다는 것도 하나의 장점이다. 반면에, 임베디드 시스템을 다루기 때문에 전자공학의 지식이 없는 사람은 책 초반부터 심한 좌절감을 느끼기가 쉽고, 또한 (다수의 임베디드 시스템들은 자체 OS를 개발해야 하기 때문에) OS에 대한 지식이 없다면 책의 내용이 무척 어렵게 느껴질 것이다.

회사와 병행하여 야간 대학원을 다닐 때 (업무와 큰 관계가 없었지만,) 임베디드 시스템에 관심이 많아서 관련 과목을 꽤 많이 들었었다. (비록 많은 것을 얻었음에도 불구하고,) 임베디드 시스템 수업은 너무나도 어려웠었다. 그래서 한빛리더스에서 미션 도서로 이 책이 나왔을 때 한편으로는 선택을 하고 싶다는 생각이 들었지만, 한편으로는 그 고통을 겪고 싶지 않아서 다른 책을 선택할까 하는 생각이 많이 들다 결국 이 책을 선택했었다. 책을 리뷰하고 나니 대학원에서 관련 수업을 듣기 전에 이 책을 만났었다면 관련 수업에 많은 도움이 되었을텐데 하는 아쉬움이 남는다. 지금 임베디드 세계에 첫발을 내딛고 싶어하는 이가 있다면 이 책을 볼 것을 권한다.