옛날 옛적, 여기서 멀지 않은 왕국에서 왕은 두 명의 보좌관을 시험하기로 했다. 왕은 두 개의 기다란 구멍이 위에 나 있고, 조절 노브와 레버가 달린 반짝이는 금속 상자를 보여주며 “이것이 무엇이라고 생각하는가?” 라고 물었다.
전기 기술자인 보좌관이 먼저 대답했다. “토스터입니다”.
왕은 되물었다. “이 장치에 들어갈 임베디드 컴퓨터를 어떻게 디자인할 텐가?”
“4비트 마이크로컨트롤러를 사용하면 굽기 조절 노브에서 흰색에서 석탄처럼 검은색까지 16가지의 값을 읽어오는 간단한 프로그램을 작성할 수 있을 겁니다. 이 값을 타이머 테이블의 인덱스로 사용해 언제 가열을 중단하고 빵이 튀어나오게 할 지 결정할 수 있을 테지요. 다음 주에 다시 오시면 작동하는 프로토타입을 보여 드리겠습니다.”
소프트웨어 개발자인 두 번째 보좌관은 이 말을 듣고 전기 기술자의 좁은 식견에 탄식하며 말했다. “토스터는 빵을 토스트로 만들기만 하는 장치가 아닙니다. 냉동 와플을 데우는 데 쓸 수도 있죠. 전하께서 원하시는 것은 바로 아침 식사 조리기입니다. 이 장치는 더 많은 기능을 가질 필요가 있어요. 소시지와 베이컨을 굽고, 에그 스크램블을 만드는 그런 것들 말입니다. 토스트만을 만들 수 있는 토스터는 몇 년 안에 쓸모없는 물건이 될 거예요. 미래를 보셔야 합니다.”
“물론 저에겐 더 지적인 해결책이 있습니다. 먼저, 아침 식사 클래스를 만듭니다. 이 클래스는 곡류, 육류, 난류 서브 클래스로 특수화될 수 있지요. 곡류 클래스는 토스트, 머핀, 팬케이크, 와플 클래스로, 육류 클래스는 소시지, 비엔나소시지, 베이컨 클래스로, 난류 클래스는 에그 스크램블, 삶은 계란, 수란, 계란 프라이와 여러 개의 오믈렛 클래스들로 한 번 더 특수화될 수 있습니다.”
“햄 치즈 오믈렛 클래스는 특별한 주의가 필요합니다. 육류, 유제품, 난류 클래스의 특성들을 모두 상속받아야 하니까요. 다중 상속을 사용하지 않으면 이 문제를 해결할 수 없습니다. 프로그램은 실행 시간에 적절한 객체를 생성한 후 ‘조리되어라’ 라는 메시지를 전송해야 합니다. 물론 이 메시지의 의미는 객체에 따라 다르게 해석되어야겠지요. 그렇지 않으면 토스트가 에그 스크램블처럼 조리될지도 모르니까요.”
“복기해 보자면, 분석 단계에서는 이 장치가 모든 종류의 아침 식사를 조리해야 한다는 요구사항을 도출했고, 디자인 단계에서는 몇 가지 파생 요구 사항들을 찾아냈습니다. 예를 들면 다중 상속을 위해 객체 지향 언어를 사용해야 합니다. 사용자는 베이컨이 구워지는 동안 계란이 차가워지는 것을 원치 않을 테니 병행 프로세싱도 물론 요구되겠네요.”
“사용자 인터페이스도 빼놓을 수 없지요. 음식을 기계 안으로 집어넣는 레버는 범용성이 떨어지고, 굽기 조절 노브는 명확성이 부족합니다. 사용자 친화적인 GUI를 구비하지 않은 상품은 팔리지 않을 거예요. 아침 식사 조리기가 켜지면, 화면에 카우보이 부츠가 표시되어야 합니다. 사용자가 부츠를 클릭하면 ‘UNIX v.8.3 부팅 중’이 표시되고요. (출시 시점쯤 되면 UNIX 8.3도 릴리즈되어 있겠죠?) 메뉴를 열고 원하는 음식을 클릭하면 조리가 시작됩니다.”
“디자인 단계에서 현명한 결정을 내렸으니 남은 것은 구현 단계에서 적절한 하드웨어 플랫폼을 결정하는 것뿐입니다. 인텔 펜티엄 프로세서와 48MB 메모리, 1.2GB 하드디스크, SVGA 모니터 정도면 충분하겠네요. 다중 상속과 멀티태스킹, GUI 지원이 내장된 객체 지향 언어를 선택한다면 프로그래밍은 식은 죽 먹기입니다.”
지혜로운 왕은 소프트웨어 개발자의 목을 쳤고, 모두가 행복하게 오래오래 살았다고 한다.