Wednesday, August 5, 2009

Chrome O/S와 Home Server

최근 Google의 Chrome O/S가 업계의 화두가 되었습니다. 약간 과장을 해서 마이크로소프트의 악몽이 시작되었다라고 하는 사람들도 있지요. 과거 1-20년 정도의 기간을 되돌아 보면 관련 기술의 발전 방향은 상당한 일관성을 가지고 있는 것으로 생각됩니다. 깊이 생각해보지 않아도 web-based application 과 cloud computing이 앞으로의 추세가 될 것은 분명해 보입니다. 프로그램을 개발하는 입장에서 보자면 특정 O/S, 특정 Language, 그리고 특정 API 등에 종속적이던 개발 환경이 이제는 상당부분 web-based의 통합적 환경으로 진행될 것이라는 것을 의미합니다.

이번 포스팅에서는 관련 기사들을 살펴보면서 현재의 홈서버 애플리케이션 개발과 관련해 떠오르는 생각을 간단히 정리해 보려고 합니다. 작금의 computer O/S 에서의 이런 변화 자체가 직접적으로 홈서버 개발에 어떤 영향을 주는 것은 아니지만 분명한 것은 이런 체계, 그러니까 지금과 같은 server - thin client 의 체계가 발전할 수록 이런 개념을 다른 분야 (홈서버 개발)에 적용하는 것이 용이해지는 환경이 조성되는 것은 틀림이 없습니다.

기본적인 아이디어는 이런 개념을 홈서버에 적용 가능하다면 현재의 체계가 가지고 있는 여러가지 고민들을 해결할 수 있을 것이라는 점입니다. 즉, UI 및 이에 관련된 high-level의 routine들은 개별 machine의 O/S에 무관하게 server application에서 처리하게 하고 device에 관련된 low-level routine 들만 local machine에서 담당하게 하는 것입니다. 각 home server에 탑재될 software는 web browser (O/S, hardware independent) 와 이 web browser와 low-level (hardware) api를 연결하는 간단한 middleware 정도가 올라가는 구성이 되겠습니다. 개발 환경은 아무래도 Java가 유력하겠습니다.

단순한 작업은 아니겠지만 이와 관련해서 얻을 수 있는 장점을 생각하면 충분히 검토해 볼 가치는 있을 것 같습니다. 이런 시나리오에 대해 가능성을 높게 생각하는 이유는 Chrome O/S가 Netbook에 탑재되어 동작하는 환경을 home server에 그대로 적용할 수 있을 것이라는 생각때문입니다. 하여간 이런 방식이 적용된다면 대략 다음과 같은 장점이 예상됩니다.
  • 하드웨어 사양(주로 메모리 관련)을 낮출 수 있습니다. 서비스가 복잡하고 다양해져도 하드웨어 사양이 높아지지 않습니다.
  • O/S에 종속성을 줄일 수 있습니다. 하드웨어 관련 Low-level routine들은 CPU 개발사가 2개 이상의 O/S에 대해 API 형태의 BSP를 제공하므로 O/S의 선택이 문제되지 않습니다.
  • 하드웨어에 대한 종속성도 동시에 줄어듭니다. 하드웨어 선택이 자유로워지면 제조 단가를 줄이는 데도 상당히 유리합니다.
  • 프로그램 업그레이드가 용이하고 관리에 들어가는 비용을 상당히 낮출 수 있습니다. 한정된 소프트웨어 개발팀의 자원을 최대한 활용할 수 있습니다. 현재와 같은 체계라면 프로젝트가 진행될 수록 소프트웨어 유지 관리에 드는 비용이 계속 증가할 것입니다.
  • 새로운 제품의 개발 기간과 노력이 획기적으로 줄어들 것입니다. 신제품 기획시의 제약 사항도 줄어들고 지금보다 훨씬 다양한 제품의 기획이 가능할 것입니다.

Monday, August 3, 2009

Home Automation 과 ZigBee

ZigBee가 Smart Home 분야에서 화두가 된 지는 상당히 오래되었습니다만 가시적인 성과는 쉽게 보이지 않습니다. 이런 상황에서 업계의 선도적 입장이라면 한가지 방침을 정해 밀고 나갈 수 있겠지만 그렇지 않다면 업계의 추이와 득실을 따져보고 움직여야 할 것입니다.

일단 홈오토메이션 시장에서의 네트웍 프로토콜에 대해서는 이 기사가 이제까지의 상황을 요약하는데 도움이 될 것입니다. 이 분야는 시각에 따라서 현재의 분위기와는 상당히 다른 결론을 내릴 수 있는데 그 결론을 미리 요약해 보자면
  • 표준 프로토콜은 홈오토메이션 자체의 분야가 아닌 외적인 조건에 의해 결정될 것이다.
  • 표준 프로토콜이 도입되는 시기는 아직 멀었다.
입니다.

우선 현 시점에서 홈 오토메이션 장비 공급업체의 입장에서만 보자면 프로토콜 통합의 이유를 찾기 어렵습니다. 사실 이 상황은 묘하게도 빌딩오토메이션 분야에서 통합 프로토콜이 등장하게되는 배경과 비슷합니다. 물론 그 이외에 다른 배경도 있습니다만. 하여간 장비 공급업체의 입장에서는 단품 공급이 아닌 솔루션 공급이라면 표준 프로토콜에 대해 자사의 고유 프로토콜을 선호할 것은 당연한 결과입니다. 솔루션 형태로 공급받은 장비의 프로토콜의 문제가 대두되는 것은 사용자가 새로운 장비를 추가하거나 또는 최초 공급된 장비의 교체 시점이 되어야 나타나게 되고 이는 공급업자의 관심사항이 아니라 사용자의 관심사항이 됩니다.

이런 특성이 빌딩오토메이션 분야에서 프로토콜의 통합이 아주 오랜 시간이 걸리게 된 배경입니다. 홈오토메이션은 빌딩 오토메이션 분야에 비해 시장이 훨씬 작고 소비자의 힘도 훨씬 작으므로 이런 역학관계로 본다면 프로토콜이 통합될 이유는 전혀 없습니다.

현재 진행되고 있는 프로토콜 통합의 움직임도 따라서 홈오토메이션 업체의 의지와는 전혀 무관하게 가전 제품업계(우리나라의 경우 - 개인적으로는 전혀 이해되지 않는)나 아니면 반도체 업계(ZigBee, PLC 칩셋생산업체), 전력 공급 업체(외국의 Smart Gride)의 이해 관계로 진행되고 있습니다.

현 시점에서 두가지 시나리오를 생각할 수 있습니다. 첫째는 바로 위에서 언급한 대로 홈오토메이션 업계가 아닌 외적인 요구에 의해 프로토콜이 통합되는 것입니다. 그러기 위해서는 그만한 이유(Killer Apps)가 반드시 따라야 하고 현재 이에 가장 접근해 있는 것이 Smart Grid 사업입니다. 하지만 최근의 예측에 의하면 본격적으로 Smart Grid가 보급되는 것은 최소 5년 - 10년 정도를 예상해야 할 것 같습니다. 즉, 상당 기간은 이런 문제가 홈오토메이션 업계로 넘어올 가능성은 없다는 것입니다.

두번째 시나리오가 주목해야 할 경우가 되는데, 국내 주택 시장의 특성상 소위 '분위기' 라는 것 때문에 무선 네트웍을 제품에 채용해야 할 경우입니다. 특히 관련 기관에 로비를 통해서 자사의 이해를 관철시키려는 업체등에 의해 '정책적으로' 이런 상황이 오는 것을 대비해야 할 것입니다. 단, 이 경우에도 프로토콜 통합은 여전히 쉽지 않을 것입니다. 따라서 결론은 '무선 네트웍은 조만간 준비해야 하지만 프로토콜은 당분간 통합되지 않을 것이다' 입니다.

사실 모든 표준 프로토콜의 공통적인 문제점은 가능한 모든 경우의 가능성을 포함하기 위해서 '무겁다'라는 점이고 이 점은 ZigBee에 아주 극명하게 드러납니다. 개인적인 경험과 의견으로는 동적이고 복잡한 센서 네트웍을 위해 만들어진 ZigBee 프로토콜은 극히 단순한 구조인 홈오토메이션에는 적합하지 않다입니다. 이 점은 관련 업체들이 모두 인정하는 바이고 그래서 거의 모든 ZigBee 솔류션 공급업체들이 따로 자사의 proprietary protocol을 따로 제공하고 있습니다. 그러므로 Home Automation 공급업체의 입장에서 현 시점에서 올바른 대책은 주요 wireless sensor network 솔류션 공급업체들의 proprietary protocol을 검토해서 적절한 한 두가지를 선택한 후 이를 채용하는 연구를 하는 것이라고 생각합니다.

ZigBee와 관련해서 초기에 난립하였던 업체들이 최근에는 약 3개(Freescale, TI, Ember)의 major provider로 압축되는 것 같습니다. 이 중 Ember는 작은 규모의 업체는 상대하지 않으므로 실질적으로는 Freescale과 TI 정도가 고려 대상이 됩니다. 그 외 자사 chipset은 개발하지 않지만 TI나 Freescale의 solution을 사용해서 wireless module을 공급하는 회사들도 고려 대상이 될 수 있을 것입니다. 최근 Microchip 사도 Freescale RF IC를 사용해서 module 형태의 solution을 준비하고 있는 것 같습니다. 정식 ZigBee 프로토콜을 사용할 것이 아니라면 이런 제품들도 좋은 선택이 될 것입니다.