간단한 마이크로 프로세서
필자는 요즘 AVR이라는 8비트 마이크로 컨트롤러에 빠져있다. 개인적인 호기심을 발동시키는 장난감을 그때 그때 만들어 보기 위해서다. 과거부터 8비트 컨트롤러는 많이 다루어 보았지만 32비트 컨트롤러들을 만지다가 다시 8비트를, 그것도 극도로 단순화된 8비트 RISC컨트롤러를 만지는 느낌은 각별하다. 이 칩의 코어는 90년대 중반에 설계된 최신의 것이다.

8비트 컨트롤러의 세계는 단순하다. 복잡하지 않다. 운영체제를 적용할 필요성조차 없는 애플리케이션이 대부분이니 별로 복잡한 일을 시킬 것도 없다. 개발장비라고 해야 프린터포트만 있어도 되니 준비할 것은 거의 없는 셈이다. 개발 도구도 gcc 기반의 8비트 컴파일러와 인터페이스하는 AVR studio를 회사에서 미리 제공한다. 이 환경은 전혀 어렵지 않다. 개발의 시작부터 고민거리가 크게 줄어들은 셈이다. 문턱이 낮아지면 사람들이 쉽게 접근할 수 있다. 게다가 3-4만원 정도면 기본적인 개발도구와 간단한 개발보드까지 살 수 있다.

이 칩에 관심이 증가한 것은 거센펠드의 FAB라는 책에서 실제로 쓰고 있기 때문이었다. 미니멀리스트인 거센펠드(Neil Gershenfeld)의 프로젝트에서 프로젝트의 중심에 있는 칩이었다. <생각하는 사물>의 저자인 거센펠드는 이 칩으로 많은 것들을 만들었고 실제로 전자과의 입문용으로 많이 사용되고 있기도 하다. FAB 프로젝트에서 AVR은 간단한 전자제어기를 만드는 용도로 사용된다. FAB는 Personal Fabrrication을 다룬다. 개인이 자신이 만들고 싶은 것을 거의 다 만들 수 있는 시대가 왔으며 그럴 필요성이 충분히 있다고 설득하는 책이다.

칩에 전원만 연결하면 마이크로 컨트롤러로 동작할 수 있다. 더 이상 간단한 제어기를 상상할 수 없을 정도다. 이런 칩들은 이미 많은 기계들에 들어가 있다.

AVR의 전력소모는 클럭이 1MHz 일 경우 1mA 정도밖에 되지 않으니 AA 사이즈의 작은 니켈수소 배터리를 사용한다고 해도 몇 달을 버틸 수 있을 정도다. 이 정도면 다른 기계에서 흘러나오는 전력으로도 충분히 사용할 수 있어 사용의 방법이 바뀐다. 높은 클럭으로 동작을 시키면 전력소모가 늘어나는 단점이 있지만 대신 16MIPS 정도의 처리속도를 얻을 수 있다. 이 정도면 웬만한 일은 다 할 수 있는 성능이다. 플래시 메모리를 내장하고 주변장치는 타이머나 통신포트 AD 컨버터까지 다 갖추고 있기 때문에 때로는 주변회로가 필요 없이 전원을 연결하는 것만으로 많은 일을 해 치울 수가 있다.

칩의 가격은 천 원 대부터 시작한다. 아마 실제로 많이 구입하면 더 쌀 것이다. 그래서 기존의 8051 시리즈의 제어기들을 빠른 속도로 대체하고 있다. 중간에 PIC 마이크로프로세서가 같은 이유로 엄청나게 인기가 좋았던 시절이 있다. 이미 인기를 얻고 있으며 점차 중요성이 증가할 칩이지만 간결하게 일들을 해 치울 수 있다는 점은 작업의 문턱을 줄인다. 종이에 무엇인가를 그리고 납땜인두만 들면 간단한 작업은 반나절에 끝낼 수도 있다(물론 몇 달을 끌 수도 있다.). 그러나 분명 프로토타입은 금방 나올 것이다.

예전에 마이크로마우스 같은 것을 만들던 시절에 이 컨트롤러가 있었으면 얼마나 좋았을까 하는 생각이 들 정도다. 그 전에도 컨트롤러들이 없던 것은 아니지만 이 칩은 정말 간단하게 필요한 용도에 적용할 수 있다는 놀라운 이점이 있었다. 너무 간단해지다보니 마이크로컨트롤러가 아니라 부속처럼 사용하면 되는 것이다. 간단한 것은 이토록 좋다. 마이크로컨트롤러가 반드시 시스템의 중심에 있을 필요도 없다. 주변의 부속처럼 조용히 동작해도 좋은 것이다. 32비트 컨트롤러의 시대에 이 칩에 대해 매력을 느끼게 된 것은 성능 때문이 아니었다. 간단하다는 매력 때문이었다. 간단하다는 이유만으로 칩을 사용하는 방법은 기존의 방법들과는 완전히 달라 지게 되었다. 만약에 리드가 수 십 개가 넘는 복잡한 칩이라면 기판의 설계부터 마음이 무거울 것이 틀림없다. 그러나 다리의 수가 10개 미만이고 이들을 다 연결할 필요도 없다면 개발버전을 만드는 일부터 마음이 가벼울 것이고 좀 더 자유로울 수 있을 것이다. 일반적인 하드웨어 개발자들도 사용을 늘리기 시작하는 ARM 마이크로프로세서만 해도 프로세서의 단자 수는 몇 십 개를 훌쩍 넘는다. 개발된 지 20년이 되어가는 196계열의 컨트롤러보다도 마음이 가볍다. 사용하기는 쉽지만 성능이 떨어지던 몇몇 회사의 컨트롤러와도 다르다.

AVR로 쉽게 임베디드 시스템에 접근하는 책도 출판되었다.

싸고 간단하다는 것, 표준적인 부품처럼 쓸 수 있다는 것은 복잡성의 관리에 대해 어느 정도 성공적이라는 것처럼 들린다. 용도를 한정하면 어려울 필요가 전혀 없는데 너무 범용으로 개발된 컨트롤러들처럼 모든 것을 다 커버하기 위해 애쓸 필요는 없었다. 필요한 기종을 조금 다양화하는 것으로 많은 범위의 일을 커버할 수 있는 것이다. 명령어 세트는 같고 사용방법이 조금 다르지만 필요에 따라 수십 종류의 칩중에서 하나를 골라서 쓴다는 것은 대단한 것이다. 코어는 거의 같다. AVR 같은 컨트롤러는 오랫동안 작은 기계들에서 번성할 것이고 개발자들도 좋아할 것이 틀림없다.

기계들은 약간만 복잡해져도 사람들은 가벼운 마음으로 개발하기 힘들다. 교육에도 많은 시간이 필요하며 설계의 변경 역시 쉬운 일이 아니다. 간단하기 때문에 몇 시간에서 며칠만 배우면 되는 임베디드 시스템의 반대편에는 모든 일을 처리하기 위한 운영체제를 탑재하는 본격적인 임베디드 시스템들이 있다. 운영체제는 스케줄러나 메모리관리와 같은 기본적인 일들 이외에도 수많은 디바이스 드라이버들과 프로토콜들의 라이브러리들을 끌어 앉고 있어야 하는 것이 주 업무라고 할 수 있다. 가격이 많이 내려가기는 했지만 전형적인 중형컴퓨터의 운영제제의 유전자를 많이 갖고 있는 윈도우 CE나 리눅스 같은 것들이 있다. 어떻게 보면 이들이 화려한 스포트라이트를 받고 있고 더 돈이 되는 것도 사실이다. 그러나 이들을 제대로 사용하기 위한 교육 기간은 상당히 길며 배워야 하는 내용도 많다. 제어기를 제대로 사용하기 위한 프로토콜들까지 공부하려면 더 상당한 기간을 공부해야 하고 양도 적지 않다.

만약 임베디드 시스템이 중요한 것이 아니라면 공부를 더하건 간단하건 복잡하건 별로 중요한 일이 아닐 것이다. 그러나 사실은 그렇지 않다. PC를 제외한 대부분의 전자제품은 모두가 임베디드 시스템이라고 해도 틀리지 않을 정도다. 컴퓨터를 사용하는 기계와 이들의 상호작용은 필수적인 것이다. 퍼베이시브 또는 유비퀴터스 컴퓨팅이라는 용어는 사실상 컴퓨터끼리 어떻게든 상호작용하지 않으면 안되는 것을 의미한다. 상호작용하지 않는다면 용도는 제한적이 될 수 밖에 없다. 그래서 컴퓨터가 박스 밖으로 1센티라도 벗어나면 상호작용을 생각하지 않을 수 없다. 그래서 임베디드 장비들의 개발에는 많은 것들이 숨어있다. 그 중의 하나는 복잡성의 비용에 관한 문제가 있으며 오래된 주제이다. 복잡성의 측면도 다양하다. 어쩌면 복잡성을 해결하는 것으로 엔지니어링이 발전했다고 볼 수도 있다.

필자가 답을 제시할 수 없는 문제이지만 생각해볼 필요는 많다.

복잡하지 않다는 것
이 간단한 AVR 칩들이 몇 개만 모여도 시스템은 이른바 복잡(Complex)의 세계로 들어간다. 복잡이라는 단어는 유목민들이나 수렵민족이 숫자를 셀 때 하나, 둘, 셋 그 다음은 많다고 생각하는 것과 비슷하다. 상호관계의 경우의 수는 고려해야 할 대상이 늘어날 때마다 폭발적으로 늘어난다. 복잡한 것을 다루는 일반적인 방법은 없으나 추상화나 위계조직으로 경우의 수를 줄여나가면서 시작한다. 물론 이 작업 자체가 복잡함에 복잡함을 더한다.

통신의 문제부터 복잡해진다. 같은 시스템에서 메모리를 추상화하는 IPC(Inter Process Communication)가 골치 아픈 문제인 것처럼 운영체제 내부에서 통신하는 것조차 상당히 어려운 문제다. 프로세스와 프로세스가 통신을 하는 일에도 많은 노력과 복잡하게 보이는 메카니즘들이 산재해있다. 디바이스 사이의 통신은 조금 더 어렵다. USB나 간단한 주변기지조차 모두 디바이스 사이의 통신이다. 하나의 칩을 디바이스로 간주하거나 보드나 시스템을 디바이스로 보건 통신은 어려운 문제에 속한다.

만약에 운영체제가 프로세스(때로는 쓰레드)라는 추상화를 만들지 않았거나 프로세스 사이의 통신이라는 역시 복잡한 추상화를 만들지 않았다면 일반화가 불가능해서 오늘날의 컴퓨터 시스템은 존재하지 않았을 것이다. 아직도 기계어를 가지고 이상한 개별적인 접근을 하고 있을 것이다. 복잡한 추상은 분명히 나름대로의 이점이 있다. 복잡함을 관리할 수 있는 것이다. 다만 , 복잡함을 관리할 수 있는 시점까지만 유효하다. 때가 되면 복잡함을 도저히 관리 할 수 없게 되고 폐기된다.

디바이스 사이의 통신도 바보같이 보이는 기존의 이상한 인터페이스들이 없으면 아직도 표준이 없이 방황을 하고 있을 것이다. 시리얼 통신이나 패러렐 통신 방법이 바보같이 보이기는 하지만 개발 당시의 규격이 그대로 굳어져서 표준이 된 것뿐이다. 128기가를 넘어서면 보드를 바꾸어야 하는 IDE의 규격도 마찬가지다. 규격이 굳어지면 사람들이 더 이상 사용하지 않을 때까지 그대로 표준이 된다.

칩의 이야기만도 아니다. 시스템이 커져 버리면 층층시하라는 말처럼 시스템안의 개체의 존재감은 위축된다. 거대한 위계조직 시스템에서는 많은 노력이 레이어와 레이어 사이의 정보교환에 소요되며 실제로 하는 일은 얼마 되지 않는다. 사회의 관료 시스템이 그렇듯 효율을 희생하고 체제의 유지를 택한다. 컴퓨터의 계층구조는 이것과 많이 닮았다. 통신이 많은 에너지를 소모하며 이것은 시스템도 마찬가지다. 운영체제에서 하나의 추상화 레이어를 통과할 때마다 많은 일들이 일어나지만 이것은 시스템의 유지를 위해 필요하다. 복잡함을 다른 복잡함으로 제어하는 식이다. 원시적인 시스템에서 약간의 유기적인 성격을 갖는 시스템을 만들기 위해서 치루어야 하는 대가는 복잡함이다. 언어들도 복잡해졌고 운영체제도 복잡해졌으며 인터페이스도 복잡해진다.

유지의 복잡성을 극복하지 못하면 진보할 수가 없다. 비효율 적이고 복잡한 시스템은 단순하고 간단한 시스템이 도입되면 무너지고 만다. 혁신적 또는 혁명적인 설계가 나타나면 과거의 것들은 고생한 기억으로만 남는다. 과거 마이크로 프로세서의 설계가 PDP 미니 컴퓨터의 설계를 간단히 흉내낸 칩으로 구현되자 엔지니어링의 역사는 새로운 변화에 접어들었다. 마이크로 프로세서는 기존의 미니컴퓨터나 메인 프레임의 복잡함을 칩 하나로 줄이는 것으로 극복하면서 성장했다. 인터넷의 IP(Internet Protocol) 역시 패킷을 다루는 방법을 개선하면서 성장했다. IP 덕분에 패킷의 스위칭이 가능했고 멀티 펑션 라우터가 나오면서 어떤 패킷이던 보낼 수 있었다. 더 복잡해지기는 했지만 근본적인 복잡함을 해결했다. 때로는 복잡함보다는 번거로움을 해결했다고 보아도 될지 모른다. 컴퓨터의 언어환경도 복잡함에 대응하지 못하면 살아남지 못한다. 운영체제는 더 하다. 적응하는 복잡성의 비용이 실제의 환경에 적응하지 못하면 복잡성의 관리 비용은 급격하게 상승하고 생산성은 떨어진다.

앞에서 간결함의 아름다움을 갖춘 AVR을 이야기 했지만 여러개의 AVR이 시스템을 이루고 다른 기계와 서로 통신해야 한다면 이야기는 조금 달라진다. 앞서와 마찬가지로 시스템이 복잡해지고 복잡성을 관리하기 위한 새로운 복잡성이 증가한다. 임베디드 시스템은 증가하지만 이들을 효과적으로 묶을 수 있는 프로토콜이 없다. 정말 머리 아픈 문제이기도 하고 가장 중요한 복잡성의 원천이다. 디바이스는 서로 다른 방법으로 통신한다.


거센펠드의 책 FAB에는 신랄한 비판이 나온다:

CAN, LIN, BACnet, CEBus, LonWorks, X10, USB, Bluetooth, SPI, I2C. 이들이 공통적으로 공유하는 것이 있다. 바로 비호환성이다. 이들 중 하나에서 다른 것으로 통신하려면 전용 컨버터가 필요하다. 기술적인 바벨탑은 역사적으로 다른 곳에서 개발되었거나, 독자개발 되거나 특별한 용도에 맞추서 개발된 것들도 있다, 어떤 것들은 다른 것보다 특정한 일을 더 잘 할 수 있다. 그러나 엔지니어링에서는 많은 것이 적은 것일 수 있다. 왜냐하면 최적화와 특화에 드는 비용 때문이다.

성경에 나오는 바벨탑이 중간에 무너진 이유는 서로 다른 언어를 사용하게 되면서 사람들이 혼란에 빠졌기 때문이라고 한다. 어쩌면 지나친 세분화 때문에 작업자 간에 의사소통이 이루어지지 않아서일 수도 있지만 근본적으로는 의사소통을 통한 공통의 언어나 프로토콜이 없었다고 볼 수 있다. 통신은 공통적이어야 하지만 실제로는 공통적인 언어나 프로토콜이 쓸만한 게 없다. 인터넷의 IP와 같은 프로토콜이 디바이스 사이의 통신에는 아직 없는 것이다. 여러 가지 규격이 있으나 막상 쓸만한 프로토콜이 없다. 아무리 좋은 시스템이라도 복잡성을 관리할 수 없다면 헛일이다.

상당히 유망한 아이디어이지만 아직 완전한 구현이 안된 거센펠드의 아이디어는 Internet 0 라고 불린다(http://cba.mit.edu/projects/I0/). 참으로 개발이 지연되는 것이 안타까운 프로젝트이기도 하다. 상징적으로 느린 AVR 마이크로 컨트롤러를 이용하여 구현을 시도했다. 아이디어 자체는 특별한 것이 아니다. 기존의 IP의 서브셋으로 기존의 설비를 이용할 수도 있으며 이것으로 디바이스 사이의 네트워킹을 처리하겠다는 것이다.

이 아이디어는 미디어 하우스라는 새로운 건축물 때문에 시작되었다고 한다. 이 건축물은 구조적인 요소들이 물리적인 힘만을 전하는 것이 아니라 에너지와 정보도 전달할 수 있어야 했다. 건축하는 사람이 아니라 거주자가 이들을 하나로 만든다. 그래서 요구에 따라 성장하고 변할 수 있다. 건물 전체가 임베디드 시스템이었다.

Internet 0의 데모보드 (AVR로 만들었다.)

미디어 하우스를 여는 날, 고속의 “Internet 2" 프로젝트의 컴퓨터 아키텍트 중의 한명이 구조물끼리 얼마나 빠르게 데이터를 전송할 수 있냐고 물었다고 한다. 책의 저자는 전구는 고속인터넷으로 영화를 볼 필요가 없다는 것과 데이터를 빠르게 전송하려면 네트워크는 훨씬 복잡해야만 한다는 사실을 상기시켰다. 복잡해진다는 것은 네트워크의 구축을 더 비싸게 만들고 변경하기 어렵게 만든다. 설치와 운용의 비용이 네트워크화된 전구에 대한 중요한 질문이며 통신의 속도가 아니라는 것을 설명했으나 네트워크의 아키텍트는 분통을 터뜨릴 때까지 계속 통신 속도를 물었다고 한다. 저자는 미디어하우스가 인터넷2의 일부가 아니라고 농담을 했다. 현재의 네트워크를 인터넷 1이라고 한다면 그것은 인터넷 0 의 일부라는 것이다.

이 조크는 저자 자신에게 크게 와 닿았고 인터넷을 일상의 장치들로 가져올 한 세트의 원칙을 떠올렸다. 컴퓨터 과학자가 네트워크를 느리게 해서 간단하게 만드는 일의 가치를 이해하기 어렵다면 빌딩 건축 업계는 그렇지 않다. 미국에서는 년간 일조 달러의 사업이라고 한다. 업계에서는 빌딩에 프로그램 가능성을 도입할 수요가 엄청나다.

전등으로 가는 데이터 전송률 질문은 언제나 빠른 컴퓨터와 네트워크가 느린 것보다 좋다는 오래된 편견을 반영한다. 더 빠를 때 네트워크가 더 유용하다는 것을 알아내는 일에는 큰 통찰력이 필요하지 않다. 성능을 증가시키며 발전한다는 것은 쉬운 선택이 되어버렸다. 그리고 속도에 의해 제한을 받는 애플리케이션은 점차 드물어지고 있다. 그러나 업계의 어려운 기술적 문제는 절대적 성능이 아니라 복잡함에 대한 관리비용이다.

전구를 켜는데 필요한 통신 속도는 이들이 인터넷으로 영화를 볼 필요가 없다는 사실이다. 안정이 될 때까지 기다려도 충분한 시간이다. 속도를 더 낮추면 될 것이고 이 스택은 복잡할 필요가 없다. 간단한 세계에서 복잡성을 증가시키는 것은 오히려 속도를 높이기 위한 오버헤드일 수도 있다.

그렇다면 일종의 바벨탑을 쌓고 있는 것이다. 일이 잘 되지 않는 경우의 복잡성은 급격히 상승하고 여기에 들어가는 비용 역시 상당하다. 복잡성의 비용은 눈에 잘 보이지 않지만 많은 문제를 안고 있는 것은 분명하다.

거센펠드의 아이디어는 신랄한 표현만큼 구현의 속도가 빠르게 개발되지는 않고 있지만 전구 값 하나 정도의 임베디드 시스템을 목표로 구현한다고 보아도 좋을 것 같다. 그 정도의 비용이라면 이미 복잡성을 극복한 비용이다. 그때는 이미 전구나 스위치 정도의 비용으로 일들을 처리할 수 있다는 것을 의미한다. 복잡성이 극복되면 일을 편하게 할 수 있다.

재미있다고 생각되는 아이디어라서 다음 회에는 Internet 0 (I0)에 대해 좀 더 이야기 해보려고 한다. I0는 Internet of Things (사물들의 인터넷)라고도 불린다. I0는 간단하지만 거대한 디바이스 네트워크에 적용된다. 거대한 네트워크가 실제로 존재하려면 그 실제 구현은 실용적이고 간단해야 한다.@