바인더의 탄생
먼저 바인더(Binder)라는 이름의 유래를 알아보는 것으로 시작하자. 예전에 비(Be) 라는 이름의 회사가 만든 비박스(BeBox) 라는 컴퓨터가 있었다. 이 컴퓨터는 BeOS 라는 자신만의 OS를 장착하고 있었고, 꽤 참신한 아이디어들로 무장하고 있었지만, 결국 시장의 반응을 끌어내지는 못한 채, 다른 회사에 흡수되고 말았다. Be를 인수한 팜(Palm)은 팜 파일럿(Palm Pilot) 이라는 PDA로 한 시절을 풍미한 회사다. 팜 역시 나름의 복잡한 역사를 갖고 있지만 여기서는 필요한 만큼만 언급하고 넘어가기로 하자. 팜(Palm), 팜원(PalmOne), 팜소스(PalmSource)를 구별하지 않고 팜이라고 부르겠다. 여기까지가 2001년의 일이다. 어쨌거나 꽤 오래 전임에도 불구하고 시스템 API를 모두 C++로 제공하는 도전적이고 스타일 있는 시스템으로 기억되고 있다. 이 시절을 잊지 못한 사람들이 하이쿠(Haiku) 라는 이름으로 BeOS를 되살려 놓으려고 하고 있다. 그 시절의 추억을 되살리고 싶은 분들은 http://www.haiku-os.org/ 로 찾아가 보기 바란다. 그런데 회사가 인수되기 전에 시작한 내부 프로젝트가 있었다고 한다. 오픈 바인더(OpenBinder)라는 프로젝트인데, 차세대 BeOS의 핵심 기능들을 위해 준비되던 컴포넌트 시스템(Component System)이다. 컴포넌트 시스템이란, 비교적 작고 단순한 여러 개의 소프트웨어들이 상호 협력하여 컴퓨터를 운영할 수 있도록, 구성 요소들간의 신호 전달에 대한 통일적이고 효율적인 방법을 제공한다. 근처에서 비슷한 것을 찾아보면 윈도우즈의 COM이나 유닉스 진영의 코바(Corba)와 같은 것들이 있다. 오픈 바인더가 이들과 어떤 점에서 차별 점을 갖고 있는지는 뒤에서 좀 더 자세히 다룰 것이다. 일단은 다른 시스템들에 비해 굉장히 가벼운 설계를 갖고 있다는 정도만 기억해 두자. 이 프로젝트를 이끌던 Dianne Hackborn 이라는 친구가 팜으로 옮긴 후에도 작업을 계속했고, 결국 2004년 경에 코발트(Cobalt) 라는 이름으로 알려진 PalmOS 6 의 중요한 구성요소로 완성하게 된다. - Cobalt Networks 의 NetBSD/cobalt 와 혼동하지 않기 바란다. - 코발트 역시 이제는 잊혀져 가는 이름이 되고 말았다. 팜은 리눅스로 기반 OS를 변경하게 되고, 오픈 바인더 역시 리눅스로 이식된다. 이 리눅스 버전이 오픈 소스로 공개되었고, 지금도 http://www.angryredplanet.com/~hackbod/openbinder/ 에서 다운로드 할 수 있다. 하지만 개발은 2005년 말에 중단된 상태이고, 더 이상 의미 있는 형태로 사용되지는 않고 있다. 최근에 팜프리(Palm Pre) 라는 스마트폰으로 부활의 신호탄을 쏘아 올린 팜은, 리눅스(Linux)기반의 webOS 라는 시스템을 새로 개발하여 사용하고 있다. 심지어 webOS에서 제공되는 PalmOS 에뮬레이터마저도 PalmOS 5 만을 지원할 뿐, 코발트는 영영 잊혀진 이름이 되고 말았다. 어쨌거나 오픈 바인더는 더 이상 팜에서 사용되지 않을 듯하고, Hackborn 역시 일찌감치 구글(Google)로 옮겨간 상태다. 이 때쯤에 쓴 것으로 보이는 인터뷰 기사는 바인더에 관련된 여러 가지 유용한 실마리를 제공한다. http://www.osnews.com/story/13674/Introduction_to_OpenBinder_and_Interview_with_Dianne_Hackborn 에서 볼 수 있다. 구글로 옮겨간 Hackborn은 안드로이드를 위한 바인더(Binder)를 새로 작성하게 된다. 기본적인 설계는 공유하고 있지만, 커널 모듈을 제외하고는 오픈 바인더의 코드를 사용하지 않고 전면적인 재 구현이 이루어졌다. 커널 모듈의 경우도 전체적인 구조는 그대로 유지하고 있지만, 세부 사항에 있어서 상당 부분 수정이 가해졌다. 같은 리눅스기반임에도 불구하고 안드로이드 바인더는 오픈 바인더와 호환성이 없다. 때문에 안드로이드의 바인더는 오픈 바인더와는 단절되고 부분적인 역사만을 공유한다. 이제야 바인더의 최초 설계가 빛을 발휘할 플랫폼에 비로소 안착할지, 아니면 바인더의 설계를 채용했던 다른 플랫폼들의 전철을 밟게 될지는 두고 볼 일이다. 시작할 때 바인더(Binder)라는 이름의 유래를 알아보겠다고 하고서는 지나간 이야기들만 잔뜩 늘어놓았다. 지금까지 출생의 비밀을 밝혔으니, 이제 이름의 의미도 마저 짚어보자. 바인더(Binder) 는 링커(Linker) 의 비슷한 말로 이해해야 한다. C 언어로 작성된 프로그램을 빌드(Build) 하는 과정을 생각해 보자. 소스코드를 컴파일(Compile)해서 기계어(Machine Code)로 번역한 후에, 링크(Link)하여 각 함수들이나 전역변수들과 같은 기호(Symbol) 들을 연결시키고, 주소 공간을 배치한다는 사실을 떠올리면 된다. 이렇게 링커가 수행하는 연결 작업을, 최종 연결 시점에 따라 정적 바인딩(Static Binding) 이나 동적 바인딩(Dynamic Binding) 이라고 부른다는 것도 함께 떠올린다면 다 끝났다. 링커는 결국 하나의 프로세스 내부에서 함께 존재하는 이름들을 연결했다. 반면에 바인더(Binder)는 서로 다른 프로세스로 나뉘어져 있는 이름들을 연결한다. 그러면 바인더는 도대체 어떤 방법으로 연결하는 것일까? 또 "연결"한다는 것은 구체적으로 무엇을 뜻할까?