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

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

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

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

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

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