디오이즈
따라서 현재 점점 VoIP 기반의 전화기가 집안, 직장, 혹은 모바일환경인 핸드폰 등에 보급되고 있는 것을 본다면 미디어폰이 그 다음 단계로 진화하게 되리란 것은 쉽게 짐작할 수 있다.
지난 호에 이어…
인터넷 프로토콜(Internet Protocols)
Web을 통해 정보를 보기 위해서는 데이터를 요청하고 읽어내는 HTTP 클라이언트가 필요하다. 데이터 즉, 컨텐츠 자체는 다른 프로토콜(Protocol)을 따를 수 있다. 일반적인 Web 컨텐츠 포맷으로는 HTML, CSS, JavaScript 등은 물론이고 다양한 이미지 타입이 있다. 이 프로토콜들의 역할은 유저와 상호작용을 하거나, 컨텐츠를 브라우저에 보여주는 방식을 정의하는 것이다.
또 다른 종류의 프로토콜로는 원본 데이터를 네트워크로 전송하거나, 단말기에서 컨텐츠를 보여줄 때, 어떤 방법으로 보여줄 것인지를 정의하는 프로토콜이 있다. XML은 이러한 기능을 하는 대표적인 프로토콜이다.
XML은 크게 다음과 같은 타입으로 구분된다. 컨텐츠를 독자적인 방법으로 보여주는 내용을 정의하는 타입의 XML (스키마:Schema). 업계 표준으로 흔히 사용되는 스키마인 RSS(Really Simple Syndication) 혹은, Atom으로 불리는 XML등이 있다. (이 두 가지는 대표적인 뉴스피드(Newsfeed) 스타일의 스키마로서, 주로 빠르게 업데이트되는 뉴스헤드라인이나, 블로그의 글을 보여주는데 사용된다.)
또 다른 포맷으로는 최근 유행하고 있는 JSON(JavaScript Object Notation)이 있는데, JSON은 JavaScript엔진과 직접 인터페이스 하도록 구성되어 있다(하지만, 대부분의 개발 언어에는 JSON을 해석(Parsing)할 수 있는 라이브러리들이 포함되어 있으므로 JSON은 JavaScript에만 한정되는 것은 아니다.)
하나의 예시로 Twitter API를 살펴보면 대부분 인터넷 기본 프로토콜을 지원하면서, XML, JSON, RSS, Atom 등 컨텐츠를 읽을 수 있도록 지원하고 있다.
웹(Web) 서비스는 다양한 형태로 사용되며 스타일 또한 다양하다. SOAP(Simple Object Access Protocol)는 소위 인터넷 스타일의 표준으로 사용되고 있지만, 최근엔 SOAP가 너무 무겁거나 웹서비스를 하는데 적절하지 않은 것으로 인식되어, 다른 서비스들이 소개되고 있다.
또 하나의 예시로, Google Maps에 사용되고 있는 웹 서비스는 JavaScript와 Flash 효과나 느낌이 난다. 하지만 여기서 사용된 웹 서비스 중 플래시 효과 이외에도 정적인 서비스의 하나인 이미지 데이터를 받는 HTTP 서비스 요청 등과 관련된 웹 서비스까지도 Google Maps에 사용되는 실제 서비스는 유저에게는 명확히 알려지지 않고 있다.
또한, Facebook도 JavaScript를 이용한 서비스와 .Net 느낌이 나는 서비스 프로토콜들을 사용하고 있지만, 이 또한 유저 입장에서 명확히 알 수 있는 웹 서비스가 아니다. 웹 컨텐츠를 보기 위한 프로토콜들 이외에도 이메일 정보를 확인할 수 있는 POP3(Post Office Protocol 3)나 IMAP (Internet Message Access Protocol) 같은 프로토콜이 있다.
위젯을 지원하는 GUI
최근 플래쉬를 이용한 듯한 느낌이나 복잡한 기능을 갖춘 유저 인터페이스가 유행하면서 유저 인터페이스는 제품을 개발하는데 있어 가장 복잡한 요소 중 하나가 되었다. GUI를 구현하는 기술은 상당히 다양한데, 전통적인 라이브러리를 사용하는 것부터 업계 표준의 상위레벨 추상화를 기반으로 한 방법 등이 있다.
보통 전통적인 라이브러리를 이용하면, 기본적인 좌표 계산을 통해서 비록 원시적이지만 자유롭게 유저 인터페이스의 구성요소들을 그릴 수 있다.
물론, 이런 전통적인 라이브러리를 통한 방식이 가장 유연한 유저인터페이스를 개발을 가능하게 해 주면서 빠른 응답속도를 유지해 주지만, 이 방법을 이용해서 복잡한 GUI를 개발하려면 매우 숙련된 개발 능력이 요구된다. 따라서 위젯을 이용하면 복잡한 내용은 전문 개발진에 의해서 미리 개발되고, 이 위젯과 UI 레벨을 연결하는 추상영역(Abstraction layer)은 비교적 쉽게 개발도 가능하다.
예를 들면, 아래 설명하고 있는 상위 레벨의 추상영역(abstractions)방법을 통하면, 기존 전통방식의 장점과 위젯을 이용한 방식 두 가지의 장점을 모두 취할 수 있다.
상위 레벨 GUI 추상화는 빠른 시간 내 UI를 개발할 때 매우 유리하다. 물론 만족할 만한 UI 반응 속도를 얻기 위해서는 고성능 하드웨어가 필요하다. 부가적으로 플랫폼의 주된 기능(즉, VoIP 이나 미디어 엔진 등의 기능들)과 위젯을 효율적으로 연결하려면, 글루 레이어(Glue Layer)가 반드시 필요하다.
글루 레이어는 UI 요소와 주된 기능(엔진 등)을 연결하는 기능을 담당한다. 글루 레이어는 전체적인 제품 개발 공정으로 보면 작은 영역이지만, 이를 개발하는 일도 전문적인 개발 경험을 필요로 한다.
또 다른 UI개발 방법으로는 전문적인 RAD(Rapid Application Development) 툴을 사용하는 것이다. 이런 RAD툴을 사용하면, 빠르게 UI를 개발할 수 있다. 하지만 단점으로는 RAD툴 제품이 갖고 있는 제약조건 내에서만 UI를 개발할 수 있다는 점에서 융통성은 줄어들 수 있다. RAD 툴이 특정 하드웨어의 가속기능을 이용할 수 있다면, 매우 빠른 UI 응답속도를 기대할 수도 있다.
마지막으로 고려할 만한 것은 HTML/CSS/JavaScript를 렌더링하고 해석할 수 있는 웹브라우저, 어도비 플래시, 자바 애플릿 같은 업계 표준의 런 타임 엔진을 사용하는 것이다. 이 방법의 장점은 이 영역의 경험을 풍부하게 가진 개발자를 쉽게 찾을 수 있으며, 비교적 복잡한 UI구현이 가능하다는 점이다.
하지만, 단점으로는 상기 예시했던 각각의 엔진들이 상당한 CPU의 리소스를 사용하기 때문에 빠른 응답속도를 내기 위해서는 고성능 하드웨어를 사용하거나, 시스템을 최적화하기 위해서 상당히 많은 시간이 필요할 수 있다는 점이다.
보안 프로토콜(Security Protocols)
특정환경에서 보안은 전체 솔루션에서 가장 주된 기능이 될 수 있다. 때로는 데이터 자체를 보호해야 하기 때문에, 보안이 중요할 수 도 있지만, 특정한 경우에는 방화벽(Firewall) 뒤에 숨어서 보안을 유지하는 것이 더 안전할 수도 있다.
웹 컨텐츠를 안전하게 접근하기 위해서는 HTTPS(HTTP over SSL) 방법이 웹의 표준으로 사용되고 있다. VoIP 통화 시에는 SIPS(SIP over SSL)이 보안 채널을 제어하는데 필요한 내용을, 그리고 SRTP(Secure RTP)가 음성 데이터를 안전하게 보호한다. SRTP는 표준 AES 암호화 기법을 사용하며 컨텐츠를 보호하기 위해서 데이터 접근 시 암호화 키를 요구한다.
암호화 키를 주고 받는 가장 단순한 방법은 통화를 처음 시도할 때, SIP메시지에 키를 포함해서 통화 연결을 하는 것이다. 그리고 이 키는 SIPS 프로토콜을 통해서 보호된다. SIP 이외의 방법으로 암호화된 키를 주고받는 방법으로는 ZRTP와 MIKEY 등의 방법이 있지만 이러한 방법은 아직 업계의 주목을 받지 못하고 있다.
HTTPS와 달리 SIPS과 SRTP(SIP/SDP를 이용해서 키를 주고 받을 때)방식은 시작점에서 끝점까지(End-to-End)의 보안을 보장해 주지 않는다. 좀 더 정확히 표현하면 보안의 시점은, 각각 개별 송화자와 수신자 사이의 보안을 의미한다. 따라서 기술적으로는 서버까지 통화가 연결될 때, 누군가 메시지를 훔쳐볼 수 있다는 것을 의미한다.
하지만 각각의 송화자와 수신자를 연결하는 데 서버가 개입해야 하는 현재의 방법에서는 이 부분이 필요악일 수 밖에 없다(각각의 송화자와 수화자를 연결하기 위해서는 서버는 암호화되지 않은 메시지가 필요할 수밖에 없다). 또한, 대부분의 경우 서버는 통화 연결 이외에도, 전화 연결기록이나 전화 내용을 녹취하는 등 비즈니스 목적에 따라 다른 기능을 수행할 수도 있다.
따라서 시작점에서 끝점까지의 확실한 보안이 요구될 경우는 ZRTP 등의 방법으로 이러한 보안의 취약점을 해결할 수 있다. ZRTP는 서버가 개입하지 않고 양쪽 통화자 끼리 만 암호화 키를 주고받는 방식으로 동작 있기 때문이다.
또 한가지 재미있는 SIPS의 부작용은, SIPS를 이용하면 방화벽을 뚫기 매우 쉽다는 점이다. 방화벽은 SIPS 프로토콜을 의심하지 않거나 그 목적을 수행할 수 있도록 의도적으로 검열(Inspect)을 하지 않기 때문이다. 또한 SIPS 작업은 443번 포트를 이용해서 수행되며, 443 포트는 HTTPS의 표준 포트이기 때문에 방화벽이 검열을 하지 않는다.
응용프로그램(Application)
마지막으로, 미디어 전화기는 상기의 모든 구성요소를 갖추어야 완전한 전화기의 기능을 수행할 수 있다. 즉, 유저인터페이스를 구현하는 것은 물론이고, 미디어폰의 다양한 기능을 수행하거나 제어하는 등 주된 기능 이외에도 기기 자체를 부팅하거나, 펌웨어를 관리, 환경 설정기능을 제공하는 기능 등 여러 가지 작은 노력들을 마무리 해야 한다. 이런 작업이 일차적으로 마무리된 후에도 시스템 최적화 및 제품 품질 테스트를 위해서 많은 시간과 노력이 뒤따르게 마련이다.
레퍼런스 디자인(Reference Designs)
이번 글을 통해서 미디어폰을 개발하는 데 필요한 방대한 노력과 그 복잡도에 대해서 이제까지 설명했다. 심지어 폰에 부가되는 응응프로그램들을 제외하고 핵심 기능에 해당하는 요소들만 하더라도, 각 콤포넌트들을 개발하는데 수많은 엔지니어들의 시간과 땀을 요구한다. 물론 이 구성요소들을 합쳐서 하나의 동작하는 솔루션으로 만드는 데는 그 배수에 해당하는 노력이 소요된다.
또한 전체 시스템을 구성하는 각각의 콤포넌트들 즉 예를 들면 RTOS(OS), 네트워킹, VoIP과, 미디어 프로토콜들, 음성과 영상 엔진들, 보안, 그리고, GUI 등을 라이브러리로 구매한 후에 이들을 하나의 미디어 폰 제품으로 완성하더라도 여전히 많은 노력이 요구된다.
VoIP 기술이 빠르게 변하고 있기 때문에 대부분의 회사들이 최선의 노력을 들여 제품개발에 투자한다고 하더라도 빠른 시간에 제품화에 대응하는(Time-to-Market)것 뿐만 아니라 제품을 혁신하고 최적화하고 기본적인 기능들에 대해서 충분히 품질 테스트를 하는 등의 목적을 모두 달성하란 쉽지 않다.
따라서 시장에 따르게 양질의 제품을 소개하기 위해서는 레퍼런스 디자인(Reference Design)을 기반으로 제품 개발에 착수하는 것이 이미 핵심 기능에 대해서는 모두 검증이 되어 있는 반면, 자사의 핵심역량인 제품 차별화에 집중화 해서 빠르게 시장의 요구에 대응할 수 있는 안전한 방법이다.
이런 레퍼런스 디자인을 선택하는 핵심 기준은 기능면보다는 기본 기능의 품질에 차별성을 보이는 요소들을 바탕으로 선택해야 한다.
실시간 운영체제(OS)
레퍼런스 디자인은 최소한 실시간의 성능을 보장할 수 있는 운영체제를 포함하고 있어야 한다. 예를 들어, VoIP 통화는 GUI 요소가 변경될 경우, 통화품질에 영향을 받을 수 있다. 또한, 네트워크 스택의 동작으로 인해 비디오 재생을 방해하면 안 된다.
네트워킹 스택(Networking Stack)
레퍼런스 디자인은 CPU점유율을 크게 사용하지 않으면서도, 응답 속도를 보장할 수 있는 효율적인 스택을 선택해야 한다.
프로토콜(Protocols)
레퍼런스 디자인은 VoIP과, 미디어 및 인터넷 접근에 필요한 유행하는 모든 프로토콜을 지원해야 한다. 또한, 각각의 프로토콜은 커스텀 기능을 구현할 수 있도록 확장성을 고려해서 설계되어야 한다. 예를 들어, 표준 RFC 등을 벗어난 특별한 기능을 수행해야 한다면, 이에 맞추어 코어 프로토콜을 수정할 수 있어야 한다 (물론 반드시 필요한 경우에).
미디어 엔진(Media Engine)
미디어 엔진은 반드시 적응형 지터 버퍼(Jitter Buffer)및 자주 사용되는 코덱들을 지원해야 한다(물론, 코덱들은 하드웨어의 가속기능이 가능하다면, 충분히 활용할 수 있도록 효율적으로 구현되어 있어야 한다). 또한, 경우에 따라 오디오 비디오에 대한 노이즈 제거나, 음향 에코 제거(Acoustic Echo Canceller) 기능이 포함되어야 한다.
그래픽 유저 인터페이스(GUI)
최근 기대 수준이 맞는 복잡다기한 UI 표준을 만족하면서, 유동적으로 대응 가능한 GUI로 디자인되어야 하며, 유저 응답속도가 빨라야 한다. 가장 이상적으로는 하드웨어의 가속기능을 최대한 활용한 GUI를 선택해야 한다.
보안 프로토콜(Security Protocols)
레퍼런스 디자인은 표준 보안규정을 만족해야 한다. 물론, 보안 프로토콜들이 하드웨어의 가속기능의 이득을 볼 수 있으면 좋지만, 그렇지 않은 경우라도 합리적인 범위의 시스템 리소스를 사용하면서 동작해야 한다.
개발 환경(Development Environment)
개발 환경은 매우 중요한 소요이다. 개발 환경에 따라 전체 개발 시나리오와 시간 등이 좌우되기 때문이다. 수준 낮은 개발환경을 사용하면 실제 개발 속도가 느려져서, 빠른 시장대응(Time-To-Market)의 목적을 달성하지 못한다. 어떤 경우에는 개발환경을 구축하는데 경제적으로 큰 비용이 소요될 수도 있다. 반면 어떤 경우는 거의 경제적인 부담이 없는 경우도 있다.
당연히 경제적으로 부담이 될 경우, 한정된 개발 툴로 인해서 여러 명의 개발자가 작업하더라도 시간을 효율적으로 활용하지 못할 수 있다. 또 어떤 경우는 실제 하드웨어 상에서 개발과 디버깅(Debugging) 할 수 있을 때까지 많은 시간을 기다려야 할 수도 있다. 이 경우 실제 하드웨어가 없더라도 디버깅이 가능하도록 하는 방법도 있다.
Win32나 Linux의 경우는 개발자가 실제 하드웨어가 아닌 데스크탑 개발 환경에서 개발함으로써 많은 시간을 절약할 수 있다.
결론
미디어 폰은 전화기 세계와, 미디어, 인터넷 정보의 세계를 잇는 컨버전스에 대한 새로운 시도이며 매우 흥미로운 제품이다. 그러나 빠른 시장(Time-To-Market)의 요구를 만족하기에는 매우 복잡하고 오랜 개발 노력을 기울여야 하는 제품이다. 따라서 이미 핵심 기능에 대해서 사전 개발되어 최적화 및 오랜 테스트를 마친 레퍼런스 디자인을 선택하는 것은 매우 현명한 출발점이 될 수 있다.
이런 기본 기능을 바탕으로 자사가 갖고 있는 핵심 역량을 통해 차별화된 제품을 개발한다면 시장에서 돋보이는 제품개발이 가능할 것이다.
[About Unicoi Systems]
Unicoi Systems(유니코이 시스템즈)는 임베디드 기기에 필요한 실시간 오디오 비디오, 그리고 데이터 처리와 관련된 소프트웨어를 선도하고 있는 Global 기업이다. 2000년도 Georgia주 Atlanta 를 기반으로 시작해서 현재 전세계 300개 이상의 주요 기업들이 제품 개발시 Unicoi의 Fusion Software에 의존을 하고 있다.
Unicoi 사의 소프트폰(SoftPhone) 솔루션
Unicoi사의 Fusion SoftPhone Reference Design은 VoIP 응응프로그램을 제작할 경우 필요한 모든 솔루션을 제공한다. 강력한 Fusion Call Manager(FCM)는 SIP,SDP 등 내부의 복잡한 프로토콜을 관리하면서 외부로는 단순한 개발자 API를 제공하고 있다. 때문에 개발시 FCM을 이용해서 GUI 와, VoIP 내부의 기능들을 쉽게 연결할 수 있다. 또한 Unicoi SoftPhone RD는 플랫폼(Platform) 독립적이기 때문에 어떤 OS에서도 쉽게 구동할 수 있도록 되어 있다. Win32기반의 Winows CE/Windows Mobile/Linux/Android/ MacOS등 각종 OS기반의 포팅 예제가 있기 때문에 Fusion SoftPhone RD를 활용한다면, 사용자 인터페이스 부분에 역량을 집중해서 제품을 쉽게 완성할 수 있다.
>>> 저자 및 본 Article에 대한 소개
Jason Robertson
Unicoi Systems의 기술을 총괄하는 부사장이며, Web Browser, VoIP, Networking protocols, XML등과 같은 제품의 설계 및 개발을 총괄하고 있다. Unicoi이전에는 Veriprise Wireless, Inc사의 수석 시스템 설계 총괄을 역임하고, Motorola에서 수석 소프트웨어 개발 담당을 역임했다. "IP 미디어폰과 레퍼런스 디자인-Reference Designs and IP Media Phones" 란 제목의 본 기고는 , 2010년 Silicon Valley에서 열리는 Embedded System Conference 에서 발표하는 주제로, Jason 부사장은 이곳에 연설하는 연사로 초대되었다.
>>> 번역자 소개
Allan Kim
Allan은 Unicoi Systems 에서 한국 시장 개발을 담당하고 있으며, 현재는 한국 지사 설립 작업을 진행하고 있다.
성원호/ 디오이즈 대표
디오이즈(www.dioiz.com)는 Unicoi의 한국 총판이며, 국내에서의 1차 기술지원을 담당하고 있다.
회원가입 후 이용바랍니다.
개의 댓글
댓글 정렬
BEST댓글
BEST 댓글
답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
내 댓글 모음