Windows Mobile폰 iPhone, BlackBerry 부럽지 않게 사용하기

여기저기 iPhone 소식에, Android폰도 나올 것  같고, LiMo출시 소식도 들립니다. 이미 BlackBerry를 구입해서 오바마 기분을 만끽하는 분도 계십니다. 하지만, 이 땅의 99.9% 스마트 폰 사용자는 고우나 미우나 Windows Mobile 폰을 사용하고 있습니다.

Windows Mobile이 그동안 혁신에 게을렀던 것은 사실이지만, 이미 수 많은 사용자를 확보했고, 그 동안 수 많은 어플이 개발되어 있어 조금만 관심을 가지면, iPhone 부럽지 않게 활용할 수 있습니다.  물론 이런 노하우를 쌓으려면 약간의 노력이 필요합니다.

저보다 많은 분들이 좋은 노하우를 갖고 계시겠지만, 제 나름대로 삼성 미라지(i780)폰을 1년여동안 사용하면서 경험한 노하우를 공유하도록 하겠습니다. 적절한  인터넷 요금제와 몇가지 유료 어플을 설치하면 iPhone, BlackBerry 부럽지 않게 Windows Mobile를 활용할 수 있습니다.

1. 정액제 데이터 요금제에 가입한다

아직도 잘못 접속된 인터넷에 화들짝 놀라거나, 데이터 접속을 금기시 하나요? 적은 비용은 아니지만, 진정한 모바일 웹을 경험하려면 데이터 요금제는 이젠 선택이 아닌 필수가 되어가는 것 같습니다.

저는 KT사용자로서, 한달 500MB에 12,000윈 짜리 정액 요금제에 가입하였습니다. 이 정도 용량이면 출퇴근길과 화장실에 틈틈히 e-mail도 쓰고 SNS를 이용할 수 있는 충분한 용량을 확보할 수 있습니다. 물론 Full Browsing보다는 서비스 전용 Client를 설치하고, PDA용 사이트를 주로 방문해야 합니다.  하지만 Opera Mobile 설치하여 Turbo모드를 켜시면 Full Browsing도 부담없이 사용할 수 있습니다.

iPhone 출시를 계기로 새로운 통합 데이터 요금제도 나오는등, 데이터 요금에 대한 부담이 줄었다고 하지만, 별로 싸진 느낌은 들지 않습니다.

2. 최신 Opera Mobile 를 설치한다.

http://www.opera.com/mobile/
미라지폰에서도 iPhone수준의 Full Browsing을 즐길 수 있습니다. 특히, Turbo모드를 켜두시면, Opera 서버에서 데이터를 80%정도 압축해주므로, 상당히 빠르게 브라우징을 즐길 수 있고, 그 만큼 데이터 전송량도 줄일 수 있습니다.

3. Google Sync로 BlackBerry 흉내내기

Google Sync를 사용하면, Google Calendar, Contract, GMail를 동기화할 수 있습니다.
실시간 Sync는 안되지만, Push Mail 흉내는 낼 수 있습니다.

4. Microsoft SMS 설치

아직도 200개로 제한된 SMS를 쓰십니까? Copy & Paste는 제대로 되나요? 문자 삭제는 참 번거롭지요.
Windows Mobile의 SMS가 원래 이렇게 문제가 많은 것은 아닙니다. MS에서 만든 SMS는 참 가볍고 마치 채팅하듯 사용하기 쉽습니다. MS SMS를 설치한후, 문자를 10배는 많이 보낸 것 같습니다. 덕분에 요금은 좀 더 나왔습니다.

설치방법 소개 (다소 까다롭습니다)

4. Twitter, Facebook는 전용 툴로

• Free Twitter Clients


• Microsoft Facebok Client

많은 Twitter Client가 있지만, Twikini가 제일 좋은 것 같습니다. 물론 무료로는 사용기간에 제한이 있어서, 구매를 해야 하나 가격도 비싸지 않으므로 구입해 볼 만합니다. 아직까지 한글 입력을 지원하지 않지만,  Multiple Account를 지원하는 등 보기만하는데도 상당히 유용합니다.


Microsoft에서 개발한 Facebook전용 Client로 친구들에게 바로 전화거는 기능을 제공합니다.

6. 할 일은 Remember the Milk로 Sync하자

Google Sync로는 Google Calendar에서 제공하는 To Do List를 동기화할 수 없습니다. 비용은 좀 들지만, 대표적인 웹 기반 할일 관리 서비스인 RTM(Remember the milk)는 Windows Mobile Sync프로그램을 제공합니다. 설치만 하면 Outlook의 To Do List를 RTM과 쉽게 동기화할 수 있습니다.

7. Google Map으로 길도 찾자

사용하는 Windows Mobile 폰이 GPS를 지원한다면, Google Maps for Windows Mobile를 설치해보기 바랍니다. 네이게이션 수준은 아니지만, 현재 위치를 지도에 표시해주고, 뚜벅이를 위한 길 안내도 지원합니다.

2회 BarCamp Seoul 참가

1회에 이어 bacamp Seoul 2회에 참가하게 되었습니다. 행사 주관은 다음에서 일하면서 한국 모질라 커뮤니티를 이끌고 있는 윤석찬님이 하고 있으며 IT관련 특히, 웹 분야를 주도하고 있는 분들을 만날수 있고 동향을 살필수 있는 자발적 모임이라고 할수 있습니다.

지난 1회 때는 준비할 시간이 많지 않아 지금까지 그려온 만화를 가지고 "프로그래머 이야기"라는 발표을 했었습니다. 2회때 부터는 1회때 발표를 한 사람은 그냥 참관으로 참석할 기회가 있어서 발표 신청은 하지 않았습니다. 하지만 뭔가를 준비는 해야 할 것 같습니다.

오픈소스나 웹브라우저와 관련해서 저만의 이야기를 풀어볼 생각입니다.

참고

* barcamp Seoul 1회 참가 후기

* barcamp Seoul 1회 소개

소프트웨어 개발 환경의 변화와 향후 전망

SW 개발자의 큰 걱정 중 하나는 계속 공부를 해야 한다는 것입니다. SW분야 만큼 기술의 변화, 발전 속도가 빠른 분야도 없을 것입니다. 저 개인적으로는 이런 변화를 즐긴다고 자부해왔지만, 가끔은 애써 나하고는 무관하다라고 외면하는 경우도 있습니다. 물론, 변하지 않는 핵심을 잘 이해하고 있으면 새로운 기술에 대한 적응은 쉽습니다. 하지만 관심마저 저버린다면 누구와 대화라도 나누기가 힘들어집니다.

90년대 부터 제가 경험한 SW 개발환경의 변화와 향후 발전 방향에 대해 간략하게 알아보도록 하겠습니다. 이런 글을 쓰게 된 이유는 앞으로의 일어날 변화가 지금까지 경험한 변화 가운데 가장 크다고 생각하고 있고 저 자신도 이러한 변화에 발맞추어 나가려고 하기 때문입니다.

객체지향 프로그래밍(OOP)와 GUI 프로그래밍
90 년대 초반, 이 때는 대부분의 SW 개발자가 도스에서 C 프로그래밍을 하던 시절이였습니다. 이 때 두가지 변화의 물결이 다가왔는데, 바로 OOP와 윈도 프로그래밍이였습니다. 볼랜드의 OWL(Object Windows Library)과 비주얼 C++의 MFC(Microsoft Foundation Class Library)와의 전쟁에서 비주얼C++가 승리하면서 마이크로소프트는 개발툴에서도 독점을 이어나갔습니다. 하지만 진짜 비주얼 개발툴은 바로 비주얼 베이직이였습니다. 수 많은 초보 개발자를 윈도 개발자로 다시 태어나게한 일등 공신이라고 생각합니다.

기상기계(Virtual Machine)기반의 자바 언어 등장
97년이였던 것 같습니다. 자바(Java)의 등장은 많은 개발자에게 신선한 충격으로 다가왔습니다. 크로스 플랫폼을 지원하며 개발툴도 무료로 제공되었고 네트워크 어플리케이션 부터 GUI 프로그램까지 쉽게 개발할 수 있었습니다. 지금까지 개발된 어떤 언어보다 명시적이고 풍부한 기능을 제공하였고 쉽게 배울 수 있었습니다. 한 때, 웹 브라우저에서 동작하는 유일한 어플리케이션 실행 환경으로 각광을 받았지만, 플래시(Flash)에 밀렸고 현재는 모바일이니 서버쪽에서 많이 쓰이고 있습니다. 하지만 이클립스(Eclipse)와 같은 네이티브(native) UI기반의 SW 프레임웍(framework)이 등장하면서 현재는 데스크탑 환경에서 풍부한 UI를 제공하고 있습니다.
자바는 현재도 JSR(Java Sepcification Request)을 통해 새로운 기술과 기능에 대한 자바 API 규약이 나오고 있으며 계속 진화, 발전하고 있습니다.

웹과 스크립트 언어
많 은 소프트웨어가 웹을 기반으로 개발되면서 스크립트 기반의 개발환경 또는 언어가 대중화되기 시작합니다. 서버측면에서는 ASP, JSP, PHP가 대중화되었고 웹브라우저에서는 자바스크립트(JavaScript)가 사용되었습니다. 자바스크립트는 자바 보다는 오히려 C언어와 유사한 부분이 많죠. 물론 이전부터 파이썬(python), 펄(perl)도 CGI 개발에 사용되고 있었죠. 하여간 스크립트 언어 하면 웹을 연상할 만큼 웹 어플리케이션 개발에 많이 사용되고 있습니다. 하지만 스크립트 언어는 유닉스의 역사와 함께할 만큼 오랜 세월 동안 사용되어 왔습니다. 근래들어 루비가 많은 관심을 끌고 있더군요. 이러한 사실은 몇 년전 부터 시작된 대안언어축제라는 행사를 통해 알게되었습니다.

Win32API와 MFC의 종말(?)


얼마 전 뉴욕타임즈 리더라 는 프로그램을 다운로드 받았는데, UI가 좀 색다르게 구성되었고 글꼴 출력이 무척 미려했습니다. 닷넷(.Net) 프레임워크에서 제공하는 WPF(Windows Presentation Framework)를 사용해서 개발된 프로그램이였습니다. 비록 닷넷 프레임웍 런타임(runtime) 환경을 다운로드 받아야 했지만, 기존 윈도 프로그램에서 볼 수 없었던 부드러움과 신선함을 느낄 수 있었습니다. 닷넷 프레임워크는 마이크로소프가 자바를 대항에서 만든 윈도 기반의 어플리케이션 실행 환경입니다. 비주얼 베이직과 같은 런타임 실행 환경과 다양한 소프트웨어 컴포넌트로 구성되어 있습니다. C#이라는 언어에 의존적이지 않고 다양한 언어를 지원할 수 있도록 공통 언어 인프라스트럭쳐(Common Language Infrastructure)를 제공하고 있습니다. 단순히 자바를 죽이기 위해 개발된 것 보다 윈도의 차세대 SW 플랫폼을 만들기 위한 전략으로 개발된 것 입니다.

이런 사실 때문에 Win32 API와 MFC가 윈도 개발의 모든 것이라고 생각했던 많은 개발자에게 또 다른 고민거리를 안겨주었습니다. 이것은 비주얼 베이직이 등장할 때와 또 다른 문제였습니다. 마이크로소프트가 닷넷 프레임워크를 향후 윈도 프로그래밍의 주력으로 밀 것이 분명해보였고 이것은 윈도 비스타가 출시되면서 현실이 되었습니다.
윈도 비스타의 새로운 기능인 벡터 방식의 그래픽, 3D기능, 애니메이션 기능은 바로 닷넷 프레임워크 3.0에서 제공하는 WPF의 기능이며 현재 윈도XP에서도 지원하고 있습니다. 이 기능을 제대로 활용하려면 닷넷 프레임웍을 새로 공부해야 하고 비주얼 스튜디오2005에도 익숙해야 하며 무엇보다는 UI를 만들려면 XAML(eXtensible Application Markup Language)을 잘 알아야합니다. UI가 기존의 대화상자나 콘트롤 위주가 아니라 벡터 그래픽, 3D, 애니메이션, 동영상이 결합되기 때문에 이를 통합 할 도구의 사용법도 익혀두어야 합니다. 앞으로 플래시 만큼 상큼하고 역동적인 UI를 윈도 어플리케이션에도 흔히 볼 날도 머지 않았습니다. 물론 많은 개발자들이 이를 지원할 수 있도록 공부를 해야겠지요.

웹에서 데스크탑으로
소프트웨어를 개발할 수 있는 방법이 점점 더 다양해져가고 있습니다. 이전에는 나름대로 고유영역이 있었습니다. C,C++는 높은 성능과 최척화가 필요한 부분에 사용되었고, 자바는 네트웍 환경에서 서비스나 데이터를 처리하는데 많이 사용됩니다. 웹은 브라우저 기반의 정보 서비스와 같은 주로 정적인 정보 제공하는 역할을 제공했었지요. 플래시는 벡터 방식의 단순한 애니메이션을 보여주는 기능을 해왔습니다. 하지만 지금은 그 경계가 무너지고 있습니다. 특히 웹브라우저와 플래시는 자신의 영역을 계속 넓혀가고 있습니다. 웹브라우저는 Ajax기술을 이용하여 웹 페이지 변경 없이, 마치 데스크탑 어플리케이션 처럼 풍부한 UI를 지원합니다. 플래시도 마찬가지로 단순한 애니메이션 저작툴이 아닌 다양한 응용 어플리케이션도 개발할 수 있는 소프트웨어 플랫폼의 역할을 할 수 있을 정도로 기능이 강화되고 있습니다. 이들 인터넷 기반의 새로운 어플리케이션 형태를 RIA(Rich Internet Application)라는 부르고 있습니다. 웹브라우저를 기반으로 마치 전통적인 데스크탑 어플리케이션과 같은 기능을 제공하는 소프트웨어를 부르는 말입니다. 지금 RIA가 데스크탑 어플리케이션을 따라가고 있다면 데스크탑 어플리케이션은 WPF와 같은 기술을 통해 한 발짝 더 나아가려 하고 있습니다. 이런 흐름에서 도도하게 옛 방식만을 고수하기는 힘들 것입니다.

변화가 싫다면 발전 속도가 느린 시스템 프로그래밍 이하를 파고 들던지 아니면 새로운 환경에서 좀 더 유연한 개발 언어, 개발 환경을 통해 지금 보다 나은 풍부한 사용자 경험과 편리함을 제공하면 어떨까요? 물론 SW 개발도 이전보다 더 쉽고 재미있어야 하겠죠?

소스코드 복사의 대표적인 위험 사례 - 아리안 5호 폭발사고

김윤수님께서 소스코드 복사의 위험성에 관해서 좋은 글을 써주셨습니다.

결함이 포함된 코드를 이 프로젝트 저 프로젝트에서 쓰다보면 예상치 못한 문제를 겪을 수 있습니다.

대표적인 사례로 아리안 5호 Flight 501의폭발사건을 살펴볼 수 있습니다.

1996년 6월 4일 Flight 501은 아리안5호 발사체로 처음 발사되었습니다. 그런데, 발사된지 37초만에 제어 소프트웨어의 오동작으로 인해 그만 궤도를 벗어나고 말았고, 결국 컴퓨터에서 초과된 고도 변경 명령을 내려 과도한 공기압력을 받아 폭발하고 말았습니다.

이 문제는 아리안5호가 Ada로 작성된 아리안4호의 일부 모듈을 그대로 재사용하며서 발생하였습니다.

문제가 된 모듈은 16비트 정수값을 처리할 때는 문제가 없으나 64비트 부동소수 값을 처리할 때, 그만 수치 오버플로우(numeric overflow)가 발생하였고, 이를 제대로 처리를 못해 문제가 발생한 것입니다.

아마 아리안4호에서는 16비트 정수값만 들어왔던 모양이고 문제가 없던 코드이니까, 개발자는 그대로 아리안 5호에서 사용했던 모양입니다. 그런데, 아리안 5호에 오면서 일부 스펙이 변경되면서 64비트 부동소수값이 들어왔던 것 같습니다. 스펙의 변경을 고려하지 않고 예전 코드가 잘 동작했으니까, 그대로 사용하가다 그만 허공에 3억7천만불을 날려버리고 만 것입니다.
코드 재사용해야합니다. 그러나 그냥 재사용하지 말고 꼼꼼히 살펴봅시다.

참고

http://en.wikipedia.org/wiki/Ariane_5_Flight_501

또 다른 바캠프 행사 - FutureCamp Seoul

소식을 늦게 접해 참가 신청은 했으나 아마도 신청인원 내에는 들지 못할 것 같습니다.

2007년을 전망을 주제로 IT관련 내용이 많이 발표될 것 같습니다.

바캠프 특성상 당일날 가면 귀동냥은 가능할 듯 보입니다. 그래도 뭔가 발표할 내용은 준비하는 것이 예의라고 할 수 있겠죠.
지난 BarCamp Seoul도 무척 유익하고 즐거웠습니다. IT업계에서 영향력을 가진 분들이 많이 참석하셨고 지인들도 만나서 좋았습니다.

이번 바캠프도 무척 기대가 됩니다.

2006 삼성 소프트웨어 멤버십 전시회

http://www.secmem.org/exhibition/ssm2006ex/index.html

소프트웨어 멤버십 전시회가 열린다고 합니다..

장소는 강남멤버십이며 11/15 ~ 11/17간 열린다고 합니다. 주중이라서 가기는 힘들겠네요.

멤버십 규모가 상당히 늘었습니다. 제가 들락달락할 때(10년전 친구 덕에) 서울에 하나 지방에 하나였던 것으로 기억합니다. 지금은 전국적으로 8개나 있네요. 그 때나 지금이나 운영상에 변화는 없어보입니다. 여전히 자유스럽게 자기 하고 싶은 일을 하면 되고 모든 지원은 삼성전자에서 부담하고 있습니다. 1년에 한번씩 결과물만 보여주면 되지요. 좀 다른 부분은 선발입니다. 예전에는 내부 회원간의 추천만 의존했지만 지금은 공개적으로 뽑고 있습니다.

지금은 좀 다르겠지만, 멤버십 제도 덕분에 학점은 다소 좋지 않지만 컴퓨터 실력이 뛰어난 학생들이 삼성전자에 입사할 수 있었습니다. 지금은 다들 학점관리를 잘하니까(?) 별 문제는 없겠지만, 사실 컴퓨터 실력과 학점이 반드시 비례하지는 않았습니다. 프로그래밍 좋아하는 친구들은 자기가 좋아하는 분야에 매달리다 보니 전날 늦게 자고 수업시간에 졸고 그러는 등 학과 공부에 다소 소홀한 부분이 많았죠.
회사에서 보면 멤버십 출신들은 상당히 돋보입니다. 개발 경험이 많기 때문에 같은 신입사원이라도 멤버십 출신들은 바로 업무에 투입해도 손색없이 일을 합니다.
제가 죽 전시회 내용을 파악하고 있는 것은 아니지만 전시회 규모도 무척 크고, 재미있는 아이디도 많습니다. 물론 다소 영상 처리, 게임에 치중된 부분이 많기 한데, SoC 설계부터 로봇까지 주제는 무척 다양합니다.

홈페이지에 전시 내용이 잘 소개되어 있으니 한번 들러보세요~

8Bit 시절...

피플웨어라는 블로그를 운영하는 류한석님의 "8Bit 키드의 현재"라는 글을 읽고...

8Bit시절...



애플2, MSX 가 양대산맥으로 있던 그런 시절이 있었습니다. 가끔 금성 패미콤 시리즈나 삼성 SPC시리즈를 갖고 있던 아이들도 있었으나 역시 주류는 애플과 MSX였지요.

제가 처음 컴퓨터를 접한 것은 1984년, 당시 초등학교에 처음 도입된 FC-100이라는 컴퓨터였습니다. 학교에 단 한대의 컴퓨터가 들어왔고 이듬해에 컴퓨터반이 생겼습니다.

아이들 60명에 단 한대의 컴퓨터.

그 컴퓨터가 과학실에 있었고 담임선생님이 관리 담당이라서 방과 후에 혼자 쓸 수 있는 기회를 갖게 되었습니다. 그렇게 컴퓨터와의 인연은 시작되었습니다.

중학교 2학년, 생애 최고의 성적결과로 고무된 부모님은 저에게 MSX2를 사주셨고 그 이후로 그 성적은 역사의 한페이지가 기록되고 말았습니다. ^^; 하여간 저는 중학교 내내 컴퓨터에 푹 빠져서 지냈습니다. 온갖 게임도 다 해보고 Basic으로 게임도 만들고 나중에는 Z80 기계어까지 공부하려고 했으나.. 중학생 수준에서는 무리였던 것 같습니다.

국민PC로 IBM PC가 선정되면서 8Bit는 역사의 뒤안길로 사라지기 시작했습니다. 컴퓨터 잡지 기사는 점점 줄고 친구들 중 하나둘씩 PC를 구입하면서 같이 게임하고 이야기 나누던 친구들도 멀어져갔습니다.
지금 생각해보면 정부에서 참 잘한 일이라는 생각이 듭니다. 계속 8Bit 컴퓨터를 끌고 나갔다면 일본에 컴퓨터 시장이 종속될 것이 뻔했고 빨리 PC를 사용한 덕분에 일본이 PC9801기종으로 삽질하는 동안 우리는 정보통신 강국의 기초를 잘 닦을 수 있었습니다.

고등학교와서 가끔 게임 하는 것 외에는 컴퓨터를 잘 쓰지 않다가 대학에 와서 386 PC와 PC통신으로 새로운 세계에 빠져들게 되었습니다.

중학교 때 MSX Basic을 마스터한 덕분에 Visual Basic으로 처음 윈도 프로그래밍을 하게 되었고 그 인연으로 지금까지 개발자의 길을 걷고 있습니다. 아마도 그 당시 MSX Basic을 공부하지 않았다면 현재의 저의 모습은 찾기 힘들 것입니다. 그 당시에는 잘 몰랐으나 MSX의 'M'이 오늘날의 Microsoft를 의미하는 것이였고 MSX-DOS를 비롯하여 8Bit시절에 많은 것을 선행 학습할 수 있었습니다.

다행스럽게도 8Bit 시절의 추억을 갖고 여전히 이쪽에서 일하는 분들이 많네요. 요즘 아이들은 온라인 게임에 푹 빠져있지만 그 때 우리는 나름대로 게임을 하기 위해 코드를 입력했고 지금도 그렇지만 그 때도 버그와 싸웠었지요. ^^; 지금 우리들의 모습에서 그 때 기억을 떠올리니 재미있습니다.

BarCampSeoul

바캠프라는 행사가 열리는군요.

무척 흥미로운 행사 같아서 참가 신청을 했습니다.

일종의 컨퍼런스인데, 누구나 어떤 주제를 가지고 발표를 할 수 있습니다.

발표 주제를 무엇으로 할까 고민 좀 해봐야겠습니다.

아래 내용은 행사 소개에서 가져왔습니다.

BarCamp의 취지 및 진행

BarCamp는 여러 관심사의 사람들이 만나 서로 의견을 교환하는 강력한 교류의 장입니다. 모두가 참여자가 되며 구경꾼이 있을 수 없습니다. FooCamp 보다 더 자유로운 형식을 지향해서 실리콘밸리에서 시작된 이 행사는 전 세계적으로 주로 인터넷 서비스나 기술에 대한 주제를 기반으로 열리고 있으나, 영화 만들기나 취미 생활 같은 주제를 나누어도 무방합니다. BarCamp는 캠핑장에서 숙박을 같이 하면서 열리기도 하고, 하루 행사로 열리기도 합니다. 국내에서 처음 열리는 BarCampSeoul은 아래와 같은 모임을 제안합니다.

---

일시 및 장소

• 
  
  
  
  • 일시: 2006년 10월 21일(토) 오전 11:00 ~ 17:00
  
  
  • 장소: 다음커뮤니케이션 3F (열린방) 찾아 오시는 길
    
    
    
    • 전체 60석 좌석에 4개의 분할 세션이 가능합니다.
    
    
    
    
  
  
  
  

참가 신청은 아래 URL에서 가능합니다..

http://barcamp.org/BarCampSeoul

소프트웨어 테스팅

Ron Patton저, 소프트웨어테스팅 2판, 정보문화사(SAMS)

이 책은 이론적인 부분 보다는 저자의 실제적인 경험, 특히 Microsoft에서 경험한 국제화, 호환성, 사용성 테스팅에 관해서 잘 소개해 놓았습니다.

몇 가지를 기억나는 내용을 추려보면 다음과 같습니다.

우선, 저자가 경험한 소프트웨어 테스팅의 몇가지 특성이 눈에 띄었습니다.

• 살충제 내성 : 같은 테스터가 여러번 테스트를 진행하다 보면 관성에 빠져 일부 결함은 찾지 못한다는 이야기입니다. 여러 사람이 다양한 방법으로 테스트하면 테스트 범위를 넓혀 살충제 내성 문제를 해결할 수 있습니다.

• 버그가 많을 수록 잠재 버그도 많다.

• 소프트웨어 테스터는 아무나 하는 것이 아니다.

소프트웨어 개발 단계 가운데, 테스트가 가장 어렵다고 합니다. 얼마나 어느 정도 해야할지 가늠하기 힘들며 누구도 결함이 없다고 보장할 수 없기 때문입니다. 그래서 결함에 대한 통계적 자료를 축적하는 것이 중요합니다. 동일 프로세스로 여러 소프트웨어를 개발하다 보면 어느 정도 테스트하고 결함이 어느 정도 일때, 제품을 출시할 수 있을 지 지표를 통해 판단할 수 있기 때문입니다.
그리고 책 앞부분에 소프트웨어 테스팅 때문에 발생한 오류 사례를 소개하는데, 생각보다 심각한 오류가 많았습니다. 1999년에 있었던 화상 탐사선의 추락사건 부터 패트리엇미사일(patriot missile)의 발사 실패로 인한 인명손실 등 작고 많은 사건들이 있었습니다. 펜티엄 부동소수 문제도 빠뜨릴 수 없군요.

저도 그 옛날 설치 프로그램이 잘못만들어서 많은 윈도3.1 시스템을 망가뜨린적이 있습니다. 사실 이 문제는 Visual Basic 4.0에 포함된 인스톨러 버그로 인한 문제였지만, 하필 최종 설치본을 테스트 안해보고 넘긴 저의 책임이기도 합니다. 당시 저는 학생이였고 아르바이트한 것이라서 단지 돈을 못받았을 뿐 큰 책임을 지지는 않았지만 의뢰한 회사는 적지 않은 피해를 입었을 것입니다.

소프트웨어 테스팅, 때로는 사람의 목숨도 좌우할 수 있을 만큼 중요한 것이니 소홀히 하지 맙시다.

201가지 소프트웨어 개발 원칙

이 가운데 쓸만한 몇가지 원칙을 뽑아 본다면..

일반원칙

• 품질이 제일이다.


• 사후에 품질을 만들어 넣으려하지 마라.


• 성능보다 신뢰성이 더 중요하다.


• 시제품을 고객에게 빨리 보여준다.


• 처음 시도하는 것은 폐기할 작정으로 개발한다.


• 보면 볼수록 더 많은 것을 원한다. (변경에 대비하자)


• 개발중의 변경은 피할 수 없다.


• 가능하면 개발하기 보다는 구매한다.


• 사용자 메뉴얼이 간단하게 되도록 소프트웨어를 개발한다.


• 아무리 복잡한 문제라도 해결책은 있다.


• 소프트웨어 도구는 우수한 개발자에게 제공한다.


• 대세를 따를 때는 주의해야 한다. (신기술대한 맹목적 수용은 위험)


• 문서표준을 사용한다


• 모든 문서에 용어정의를 한다.

요구사항 원칙

• 요구사항이 불명확할수록 비용예측이 어렵다.


• 시제품으로 사용자 인터페이스 선정의 위험을 줄인다.


• 요구사항의 우선순위를 정한다.

설계원칙

• 설계산출물에서 요구사항을 추척한다.


• 문서가 없는 설계는 설계가 아니다.


• 캡슐화한다.


• 가능하면 재사용한다.


• 단순하게 개발한다.


• 특수한 경우를 많이 만들지 않는다.


• 변경이 쉽게 설계한다.


• 효율적인 알고리즘을 사용한다.


• 뛰어난 설계는 뛰어난 설계자가 한다.


• 무모한 값을 입력하면 적절한 오류 메시지를 출력하도록 한다.

코딩원칙

• 글로벌 변수를 사용하지 않는다.


• 의미있는 명칭을 사용한다.


• 사람을 위한 프로그램을 작성한다.


• 최적의 자료구조를 사용한다.


• 코드를 완성하기 전에 주석을 작성한다.


• 코딩을 시작하기 전에 문서화한다.


• code 검토를 실시한다.


• 너무 깊이 중첩시키지 않는다.

시험원칙

• 시험에서 요구사항을 추척한다.


• 시험하기 훨씬 이전에 시험을 계획한다.


• 자신이 개발한 소프트웨어는 자신이 시험하지 않는다.


• 블랙박스 시험과 화이트박스 시험을 실시한다.


• 항상 스트레스 시험을 한다.


• 단위시험이 끝나기 전에 통합하지 않는다.


• 소프트웨어에 특정한 시험용 코드를 내장시킨다.

관리원칙

• 뛰어난 관리는 뛰어난 기술보다 중요하다.


• 고객의 우선순위를 알아야한다.


• 많은 사람보다는 소수정예요원이 낫다.


• 항상 기대치를 높이 가진다.


• 능숙한 의사소통 기술은 필수적이다.


• 인력과 시간은 대체할 수 없다.


• 소프트웨어 개발자의 능력차이는 크다.


• 불가능한 것은 피한다.


• 적절한 프로세스 모델을 사용한다.


• 직면한 위험을 이해한다.


• 방법론이 당신을 구제해 주지는 못한다.

제품보증 원칙

• 형상관리 절차를 조기에 확립한다.


• 모든 중간산출물에 명칭과 버전 번호를 부여한다.


• 기준선을 통제한다.


• 모든 것을 보존한다.


• 변경관리를 해야 한다.

진화원칙

• 소프트웨어는 계속 변화한다.


• 증상이 아닌 근본적인 문제를 수정한다.


• 최악의 구성요소는 처음부터 다시 개발한다.


• 변경한 후에는 반드시 회귀시험을 실시한다.


• 비구조적인 코드는 구조화해도 개선되지 않는다.

이상입니다~

단순함의 미학

Google의 검색 페이지와 Apple의 iPod의 공통점과 성공요인은 무엇일까요?

그것은 단순함에 있습니다.



처음 구글 검색 페이지를 봤을 때, "도대체 이 회사는 광고도 없이 무엇을 먹고 사나" 이런 생각이 들었습니다. 하지만 그들은 모두가 포털을 추구할 때, 검색 엔진의 성능에만 집중함으로써 많은 사용자를 끌어들일 수 있었습니다. 그리고 검색 입력창만 있는 단순한 구성을 통해 사용자게는 편리함과 기술력에 대한 신뢰를 줄 수 있었습니다.



Apple의 iPod는 HW적 측면을 볼 때, 저장공간이 큰 것 빼고는 다소 부족해보입니다. 국내 MP3 Player에서 기본적으로 제공하는 녹음과 FM라디오 기능이 없습니다. 하지만 꼭 필요한 음악을 듣고 MP3 파일을 관리하는 기능은 아주 뛰어납니다. 특히 컨텐츠 관리 측면에서 보면 iTunes Music Store와 연동 기능과 넓은 화면 그리고 특유의 브라우징 휠의 편리함은 다른 MP3 플레이어가 넘어서기 힘든 부분입니다.

HW적으로 부족한 부분을 SW적으로 해결했다고 볼 수 있고 FM라디오, 녹음 기능은 악세서리를 이용하면 가능하기 때문에 꼭 그 기능이 필요한 사용자에게는 별 문제가 안됩니다. 게다가 Apple은 이와 같은 악세서리 판매로도 많은 수익을 창출하고 있습니다.

꼭 필요한 기능만으로 사용자가 원하는 핵심에 다가서는 단순함과 집중성!
Apple과 Google의 성공 비결인 듯 싶습니다.

[Professional 소프트웨어 개발] 변하지 않는 핵심 잡기

소프트웨어 개발자는 공부를 많이 해야 한다. 새로운 기술이 늘 쏟아지다 보니 지금 유행하는 기술도 어느새 최신 기술에 밀려 찬밥 신세가 되고 만다.

모뎀으로 겨우 통신이 가능하던 시절에는 대부분의 개발자가 단독으로 실행되는 프로그램을 개발했지만 인터넷이 등장하고 웹이 일반화되면서 웹개발이라는 새로운 영역이 생겨나기 했다.

C, C++이 보편적으로 쓰이던 때에 갑자가 Java, C#이 이라는 언어가 나타나서 개발자들에게 배울거리는 던져주기도 했다.

그러고 보면 그 옛날 열심히 공부했던 VB, Win32API, MFC는 최근 2년간 거의 사용하지 않고 C, C++ 기본 라이브러리로만 개발을 해왔었다.

툴과 언어는 계속 진화하고 또 사라진다. 특히 10여년전에 만들어진 언어는 지금도 버전업하면서 더 복잡해지고 있다. 특히 툴이나 특정 프레임웍 또는 API에 의존적으로 개발을 하다 보면 변화에 둔감해 질 수 있다. 당장 MFC는 앞으로 거의 사용되지 않을 전망이고 Win32 API 미래도 그리 밝아보이지 않는다. 새롭게 출시될 롱혼에서는 이 들을 가지고는 롱혼 전용 애플리케이션 개발은 불가능할 것이다.

그래도 우리가 배우고 익힌 소프트웨어 기술 가운데 변하지 않는 핵심은 분명 존재한다. 하지만 바쁘게 개발을 하다보면 이런 것들을 잘 못느끼고 엉뚱한 것들에 가치를 두는 경우가 많다. 대표적인 것이 툴과 언어에 대한 집착이다.

그렇다면 변하지 않는 것은 무엇이 있을까?

"Professional 소프트웨어 개발"이란 책에서는 SWEBOK에서 식별한 전문 소프트웨어 엔지니어가 갖추어야 할 능력을 구성하는 지식 영역을 다음과 같이 소개하였다.

* 소프트웨어 요구사항(Software Requiremenet)
* 소프트웨어 설계(Software Design)
* 소프트웨어 구축(Software Construction)
(상세설계, 코딩, 디버깅, 단위시험, 코드리뷰, 최적화)
* 소프트웨어 시험(Software Testing)
* 소프트웨어 유지보수(Software Maintenance)
* 소프트웨어 형상관리(Software Configuration Management)
* 소프트웨어 품질(Software Quality)
* 소프트웨어공학 관리(Software Engineering Management)
* 소프트웨어공학 툴과 방법론(Software Engineering Tools and Method)
(CASE 도구, 재사용 코드 라이브러리, 정형 방법론 같은 도구와 방법론의 지원, 조직 내에서 도구와 방법론 채택, 전파하는 기법)
* 소프트웨어공학 프로세스(Software Engineering Process)
(소프트웨어 개발 품질, 일정, 생산성 및 프로젝트와 제품의 특성을 향상시키기 위한 활동)

사실 여기서 많은 개발자들이 앞부분의 2-3개 분야가 모든 것인양 알고 공부해왔을 것이다. 오직 코딩이라는 측면만 보면 그 말도 맞긴 하다. 하지만 우리가 생각하는 것외에 더 많은 지식 영역이 존재하고 이는 더 좋은 소프트웨어를 개발하는데 필수적인 지식이다. 그럼에도 불구하고 많은 개발자들이 품질이나 프로세스와 같은 SE측면을 간과하고 있는 것은 안타까운 부분이다.

나만 좋은 소프트웨어를 개발하는데는 많은 지식이 필요하지 않지만 남이 좋아하는 소프트웨어를 개발하기 위해서는 몇배의 지식이 필요하다.

오늘도 나만을 위한 개발을 위해 엷은 지식에 만족하고 있는지 되묻고 싶다.

참고문헌
* Professional 소프트웨어 개발, 스티브 맥코넬, 2003
* SWEBOK (http://www.swebok.org)

읽을거리
* 프로그래머가 알아야할 것

[Professional 소프트웨어 개발] 소프트웨어의 특성

"Professional 소프트웨어 개발"을 읽고

소프트웨어업계에 몸을 담은지도 거의 10년이 다 되가는 것 같다. 대학 졸업하기전부터 업계에 투신(?)했기 때문에 오랜 경력을 쌓고 있으나 그것이 진정한 경력이라고 말하기는 힘든 것 같다. 적어도 이 책을 읽고 나면 그런 생각이 든다.

Software Engineering의 중요성을 알게 된 것은 그리 오래되지 않았다. 2003년 PDA용 웹브라우저를 개발하면서 마감기간을 지키기 위해 몇날을 밤새웠고 잘못된 아키텍쳐 선정으로 몇주를 그냥 날려버리고 개발보다 테스트에 많은 시간을 들이는 등 총체적인 문제에 직면했었다. 물론 프로젝트는 성공적으로 마무리가 되었다. 하지만 부작용은 심각했다. 크리스마스와 새해를 회사에서 보냈고 결국 무리하게 개발을 진행하다가 핵심 개발자 두 명이 회사를 그만두고 말았다.

무엇이 문제였을까?

* 우선은 너무 짧은 개발기간이 문제였다.
사실 이것이 모든 문제의 원인 같다. 이로 인해 프로젝트에 대한 검토 기간이 적어 잘못된 아키텍쳐를 적용했고 몇가지 요구분석이 제대로 이루어지지 않아(이보다는 요구분석이 공유되지 않아)중요한 기능들을 나중에 적용하느라 많은 부분에서 수정이 이루어졌다.

* 자동화된 테스트를 시도하지 않았다.
브라우저 특성상 여러 웹페이지를 테스트해야 하는데, 이를 모두 사람이 하나하나 테스트를 했다. 기능하나 추가할 때 마다 여러 기종으로 모든 웹페이지를 다 테스트했다.

* 개발초기에 Code Review가 없었다.
각자 모듈을 어느정도 개발하고 통합하려고 보니 심각한 문제가 발생했다. 중요한 통신 모듈 코드가 생각보다 복잡하고 확장하기 힘들게 개발된 것이다. 그 분야에 개발경험이 없는 개발자에게 무턱대고 일을 시킨 결과 원하는 품질의 코드가 나오지 않은 것이다. 미리 미리 코드 리뷰를 거쳤다면 초기에 해결될 문제를 결국 거의 다시 개발할 수 밖에 없었다.

이 책을 보면 위와 같은 문제에 관해 이미 잘 나와있었다. 아마 소규모 개발업체의 많은 개발자가 이런 문제에 직면하고 있을 것이다.

아래와 같이 소프트웨어의 특성을 안다면 위와 같은 실수는 되풀이하지 않을 것이다.

소프트웨어의 특성
1. 프로젝트의 성공은 초기에 얼마나 빨리 코딩하는기에 달려있지 않다.
2. 결함수를 비용과 일정과 맞바꿀 수 없다.
품질에 집중하라. 이를 위해 테스트 & review를 통해초기 버그를 줄여라
3. 은빛 총알은 프로젝트에 유해하다
방법론(CMM, RUP)이나 기술을 너무 믿지 마라. 모든 것을 해결해주지는 않는다.
4. 건성으로 프로세스를 개선하는 것은 유해하다
5. 소프트웨어는 소프트하지 않다. 소프트웨어를 소프트하게 만들기 위해서는 비용이 더 든다.

다음에 계속...

참고문헌
* Professional 소프트웨어 개발, 스티브 맥코넬, 2003

일 잘하는 법, 마이크로소프트에서 배운다

일 잘하는 법, 마이크로소프트에서 배운다
줄리 빅 지음, 김동헌 옮김 / 한언출판사
나의 점수 : ★★★

원제: All I really need to know in business I Learned at Microsoft

마이크로소프트는 세계 최고의 소프트웨어 회사입니다. 한창 오피스 전쟁이 일어나고 있을 때, 이곳에서 일한 저자가 쓴 글인데, 재밌고 유익합니다. 요즘 우리나라에는 삼성관련 책이 많이 나와있는데, 사실 그다지 체험적이지 않고 삼성이라는 이름을 빌린 듯한 책이 많은데, 이 책은 MS에서 일어나는 사소한 일들도 많이 소개되어 있습니다. 아쉬운 것은 출판된지 거의 10년이 다되서 이미 마이크로소프트도 많이 변해 있기 때문에 책에 있는 내용대로 지금의 현실을 이해한다는 것은 다소 무리가 있습니다. 하여간 어떤 회사에서 일하던지 도움이 될만한 이야기들을 제목만 뽑아 봤습니다.

=전문가만이 살길이다=
예상 답변을 미리 준비하자
업무에 관한 한 모든 것을 속속들이 알아두자
경쟁사를 치밀하게 분석하자

= 효과적으로 일하자=
현명하게 일하라 오래 앉아 있는 것이 능사는 아니다
잘 모르겠습니만 곧 알아보겠습니다.
우기지 말고 웃겨라! 그리고 웃어라
휴식으로 뇌를 재부팅하라
새로운 아이디어는 예상치 못한 곳에서 나오기도 한다
약속을 지킬 수 없다면 다른 사람의 도움을 요청하라

칭찬의 마력, 한 마디의 칭찬이 인생을 바꾼다
집요하게 파고들면 신뢰를 얻는다
메모를 잘 활용하자

여러 책이나 기사를 보다보면 MS 직원들도 야근을 많이 하는 것을 확인할 수 있습니다. 이 책에서도 "일주일에 이틀은 칼퇴근 하자"라고 지은이가 제안할 정도이니까요. 세상을 앞서 나간다는 것은 때론 피곤한 것이도 합니다. 물론 성취감이 있으니까 야근을 밥먹는듯이 하겠죠. 하여간 이것이 효율적이지 못하다면 개인의 금같은 시간을 낭비하는 것이니 가능한 야근하지 않도록 근무시간에 좀더 집중해야겠습니다.

나의 조엘 테스트

조엘 on 소프트웨어라는 책을 보면 조엘 테스트가 나옵니다. 예전에 한번 보기도 했는데, 괜찮은 테스트이므로 한번 여러분의 소프트웨어 개발 환경에 대해 점검해 보기 바랍니다.

1. 소스코드 관리 시스템을 사용합니까?
cvs, MS visual source safe, rational clear case와 같은 형상관리 툴이 있습니다.

저는 위 3가지 툴을 모두 써봤습니다.
source safe -> cvs -> clear case

source safe는 5년전에 쓰던거라 현재 버전에 대해 뭐라 평가하기는 힘들고 한사람이 소스 파일을 check-out하면 다른 사람은 코들를 수정할 수가 없었습니다. 퇴근하기전 check-in은 필수였습니다. VC++이나 VB에서 기본 제공하므로 가장 쓰기 편했습니다.

cvs는 오픈소스프로젝트에서 사용하고 있는 형상관리툴입니다. 모든 플랫폼에서 안정적으로 동작하면 특히 merge기능은 상용툴인 clear case보다 좋은 것 같습니다. 한번도 실망시킨적이 없습니다.

전반적으로는 상용 제품인 clear case가 좋긴 좋더군요. 물론 서버를 관리해주는 사람이 따로 있다고 가정할 때 말이죠. 특히 소스코드를 서로 다른 프로젝트로 이동하거나 다양한 버전을 유지할 때 그리고 폴더, 파일 이름 변경이 쉬워서 좋았습니다. cvs에서도 서버 접근만 되면 가능하면 쉽게 할 수 있긴하죠.

2. 한방에 빌드를 만들어낼 수 있습니까?
한번 빌드에 다양한 버전에 소프트웨어를 컴파일까지 하고 설치버전까지는 만드는 것입니다. 사실 이 부분은 아직까지 시도해보지 못했습니다. 여러 라이브러리를 쓰면, 라이브러리 따로 컴파일하고 실행파일도 따로 컴파일하고 dll도 따로 빌드하고 이 결과를 가지고 설치 프로그램을 만드는 것은 다소 복잡한 일이기도 하지요. 게다가 버전이 여러가지 유지한다면 분명 실수할 수도 있습니다.

3. 일일 빌드를 하고 있습니까?
일일 빌드라고 말할 수 없지만 수시로 전체 프로젝트를 업데이트해서 각자 빌드는 하고 있습니다. 문제는 실제 타겟용으로 자주 빌드를 해야 하는데, 그렇지 못해서 컴파일이 안되곤 합니다. 임베디드 환경에서는 PC에서 작업을 하고 타겟용으로 다시 컴파일을 하는데, 이때 문제가 자주 발생합니다. PC에서 잘 동작한다고 너무 자신만만해서는 안됩니다. 이것은 꼭 임베디드에 해당하는 것은 아니고 여러 플랫폼을 지원하면 자주 접할 수 있는 문제입니다.

4. 버그 추적 시스템을 운영하고 있습니까?
지금 회사에서도 훌륭하게 운영하고 있었지만 전에는 wiki를 이용하기도 했고 zero board에서 운영한적도 있습니다. 잘만 쓰면 모두 훌륭합니다. 못쓰면 아무리 좋은 툴도 소용이 없습니다.

중요한 것은 다음의 항목이 있어야 한다는 군요.

* 버그를 재현하기 위한 완벽한 단계
* 예상 수행 결과
* 실제 수행 결과
* 수정을 맡을 개발자
* 수정했는지 여부

5. 코드를 새로 작성하기전에 버그를 수정합니다.
이건 정말 중요합니다. 그렇지 못하면 소프트웨어의 위기에 빠지고 맙니다.
하지만 내 마음속에만 숨어있는 버그도 있긴합니다. 거의 발생한 일이 없으므로 아무도 못찾으면 그냥 넘어가기도 하지요.

6. 일정을 업데이트하고 있습니까?
조엘이라는 사람은 MS프로젝트에 대해 좋지 않은 평가를 내리고 있습니다. 저도 MS프로젝트를 이용하고 있지만 처음 작성할 때만 보고 그 후에는 거의 쳐다보지 않게 됩니다.

7. 명세서를 작성하고 있습니까?
정말 중요하다는 사실은 알고 있지만 코딩하는 것 보다 더 어렵습니다. 파워포인트로 아이디어를 정리하고 코딩한 후에 정식으로 문서화를 하고 있습니다.

8. 조용한 작업 환경에서 일하고 있습니까?
한 사무실에 몇십명씩 앉아서 일하는 환경이라면 조용하기가 참 힘들죠. 그 때는 해드폰으로 귀를 막고 모니터에 폭 빠져 일하는 것이 좋습니다. 2-3곡을 무한 반복으로 들으면서 일하면 집중이 잘~ 됩니다.

9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
만약 관리부서 사람들이 제일 먼저 업그레이드 한다면? 그 회사는 머지 않아 망합니다.
다지이너가 제일 먼저 업그레이드를 한다면? 프로그램이 화면발은 죽이지만 버그는 엄청날 수도 있습니다...
개발자에게 LCD 모니터를 사주세요. 정말 일 잘할겁니다.

회사에서 집보다 좋은 환경을 쓰면 그만이겠죠?

10. 테스터를 별도로 두고 있습니까?
출시일이 다가오면 사장님빼고 모두 테스터가 된적도 있습니다. 지금 회사와서 놀란 것은 테스트를 전담해주는 팀이 있다는 사실입니다. 역시 큰회사라 다르군요. 전에 웹브라우저 만들 때, 정말 테스트는 힘든 작업이였습니다. 자동화하기도 힘든 부분이라 일일히 주요 웹페이지를 돌아다니면서 테스트를 했습니다. 개발자가 테스트하면 웬진 비용이 덜 드는 것 같지만 사실 엄청난 비용을 들이는 것입니다.

11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
저도 이런 테스트를 받아본 적도 해본적도 없습니다. 프로그램 결과물과 소스코드를 제출한 적은 있습니다. 사실 이런 테스트를 받으면 잘 할 수 있을지 고민이 되기 합니다.

12. 무작위 사용 편의성 테스트(hallway usabiliy test)를 수행하고 있습니까?
해당 소프트웨어에 대해 문외한인 사람에게 테스트를 맡기는 것이라고 하네요. 영업부나 관리부 직원이면 적당할 것 같습니다.

프로그램 테스트

그동안 소프트웨어 개발에 있어서 자동화된 테스트에 대해 무지했던 것 같다.
지난 프로젝트에 자동화된 테스트를 도입했다면 밤샘근무와 야근도 많이 줄였을텐데..

테스트는 코딩이 끝난 후에 하는 것이 아니라 개발하기전에 시작해야한다고 한다.

지금은 특정 모듈 개발이 끝나면 바로 테스트 프로그램을 작성하여 어느정도 테스트를 진행하면 신뢰성이 생기면 다음 단계로 진행하게 된다. 이렇게 하면 각 모듈간의 독립성이 높아지고 버그도 많이 줄어들게 된다.

특히 이 모듈 저 모듈이 통합되면서 생기는 골치 아픈 버그를 상당히 줄일 수 있다.

사실 테스트 프로그램을 만들고 테스트하는데 많은 시간이 필요하다. 때로는 실제 개발한 모듈보다 테스트 프로그램이 더 긴경우도 있다. 하지만 테스트를 자동화하는데서 얻는 잇점은 많다.

- 새로운 기능이 추가될 때, 테스트를 빨리 완료할 수 있다.
- 일일히 사람이 테스트하지 않고 자동화 하므로 퇴근후에도 테스트가 가능하다.

아직은 테스트툴을 직접 만들어서 사용하지만 좋은 툴도 많이 나와있다.

Java, C++용으로 개발된 것이 있는데, 한번 사용해 보면 좋을 것 같다.

관련 URL
http://occam.n4gate.com/tt/index.php?pl=62

http://reiot.com/blog/index.php?pl=126

http://www.gamesfromwithin.com/articles/0412/000061.html

하버드 아키텍쳐와 폰 노이만 아키텍쳐

폰 노이만 아키텍쳐
컴퓨터 아키텍쳐의 한 종류로서 데이터는 메모리에서 읽거나 메모리에 쓰기도 하는 반면, 명령어는 메모리에서 읽기만 하는 구조를 말한다. 이를 처음 고안한 폰 노이만의 이름을 따서 폰 노이만 아키텍쳐라고 부르며 현대 컴퓨터는 거의 대부분 이 방식을 따른다.

특징
1. 프로세서에게 메모리 특정 지점부터 실행하도록 지시할 수 있다. 이 때 데이터와 명령어 사이에 뚜렷한 구분이 없어서 주어진 내용을 무조건 실행한다.
2. 데이터 자체에 고유 의미가 없다. 즉, 이를 해석하는 프로그램에 의해 의미가 달라진다.
3. 데이터와 명령어는 메모리를 공유한다. 특정 프로그램에서 명령어인 내용은 다른 프로그램에서 데이터일 수 있다.

하바드 아키텍쳐
하바드 아키텍쳐는 명령어와 데이터 통로를 저장공간과 물리적으로 분리한 컴퓨터 아키텍쳐를 말한다. 이 용어는 릴레이를 기반으로한 하바드 마크1이란 초기 컴퓨터에서 나온 것이다. 마크1는 명령어를 펀치 테이프에 데이터를 relay latche에 저장한다.
폰 노이만 아키텍쳐와 다르게 CPU는 메모리로 부터 명령어를 읽거나 데이터를 읽기/쓰기가 동시에 가능하다. 그러나 명령어와 데이터가 같은 신호 통로와 메모리를 동시에 사용하지 않는다.

특징
1. 하바드 아키텍쳐 컴퓨터에서는 CPU는 메모리로부터 명령어와 데이터를 동시에 사용할 수 있다.
2. 현재 명령을 마치는 것과 동시에 다음 명령을 가져올 수 있기 때문에 속도가 더 빠를 수 있다.

참고문헌
John Catsoulis, Designing Embedded Hardware, O’Reilly(한빛 미디어)
http://en.wikipedia.org/wiki/Harvard_architecture
http://en.wikipedia.org/wiki/Von_Neumann_architecture