배터리 소모가 적은 라이브 타일 업데이트
새로 개발 중인 Windows 8의 모든 ‘화면’에서 공통적으로 신경 쓰고 있는 것은 바로 알림(Notifications)을 효율적으로 간소화하는 것입니다. 원래 이러한 기능을 제공하는 용도로 나온 것이 바로 Windows 가젯입니다. 가젯은 뉴스나 날씨, 경기 결과, 업무 일정 등등 중요한 정보를 한 눈에 볼 수 있도록 간단히 표시하는 화면입니다. 하지만 가젯을 시작하는 데 걸리는 시간과 그 기본 모델은 데스크톱과 랩톱의 중요한 고려 사항인 전체 전력 소비량을 줄이는 데 도움이 되지 않을 뿐 아니라, 개발자에게 '전체 화면(full-screen)' 플랫폼을 제공하는 추세와도 맞지 않습니다. Windows 8의 시작 화면에서는 이러한 알림을 제공하는 화면 영역이 훨씬 넓어진 동시에, 네트워킹 리소스 사용량 등의 업데이트를 관리할 수 있는 사용자 제어 인터페이스도 제공됩니다. 최근에 푸시와 구조화된 정보를 통해 제공되는 정보의 양이 점차 늘어나면서 이러한 변화는 개발자와 최종 사용자에게 또 하나의 독자적인 기회를 제공하고 있습니다. 이번 글에서 Ryan Haveson은 메트로 스타일의 라이브 타일 개발 과정을 살펴보고, 전반적인 전력 소모량과 시스템 작업량을 줄이면서 훨씬 많은 수의 타일로 아키텍처를 확장하는 방법에 대해 설명합니다.
– Steven Sinofsky
새로운 Windows 버전이 성공을 거두기 위해서는 성능과 배터리 수명이 아주 중요하며, 이와 관련된 의견들도 계속 올라오고 있습니다. KISSmakesmeSMILE 님이 보내주신 의견에 이러한 부분이 잘 요약되어 있습니다.
“...작업량을 최대한 줄이고 간소화하여 "경쟁업체의" 배터리 작동 시간과 동일하거나 이를 능가하는 성능을 실현하려고 하며...”
이와 동시에 PC부터 TV, 휴대전화에 이르기까지 최근에는 모든 환경에서 한 눈에 정보를 볼 수 있도록 가젯, 위젯 또는 플러그인 모델의 형태가 이용되고 있습니다. TV 뉴스나 스포츠, 일기예보를 시청할 때는 다각도에서 실시간으로 들어오는 정보가 구조화된 화면에 표시됩니다. 사람들은 주식 시세, 날씨, 전자 메일 계정, 다음 일정, 업무 현황이나 소셜 네트워킹의 새 소식을 단 몇 초만에 신속하게 확인하고 원래 하던 작업으로 돌아가기를 원합니다. 여러 가지 면에서 PC는 다른 장치에 비해 이 부분에서 개선의 여지가 많다고 할 수 있습니다. 알림 인프라를 설계하는 과정에서 Windows 개발 팀에게 주어진 과제는 PC에서 실시간으로 작업 알림을 제공하면서 전력과 대역폭 사용량의 효율성을 극대화하는 방법을 모색하는 것이었습니다. AndyCadley 님의 의견은 이러한 목표를 잘 설명합니다.
"배터리 수명과 성능에는 영향을 미치지 않으면서 모든 '메트로' 앱이 백그라운드에서 항상 실행되는 것처럼 처리되어야 합니다."
시작 화면은 데스크톱 또는 메트로 스타일 앱에 대한 집중도를 떨어뜨리지 않으면서 한 눈에 파악할 수 있는 정보를 전체 화면에 표시함으로써 사용자 모델 관점에서 효율성을 실현하고 있습니다. 또한 효율성을 높이는 동시에 성능이나 배터리 수명에 지장을 주지 않고도 필요한 알림 앱을 얼마든지 설치할 수 있도록 개선하고자 했습니다.
내부에서 Windows 8을 사용하면서 알게 된 점 하나는, 시작 화면은 업무 응용 프로그램에 알맞게 여러 정보를 통합된 화면에서 한 눈에 쉽게 파악할 수 있도록 표시하므로 시작 화면을 사용함으로써 생산성이 크게 향상된다는 점입니다. 저희는 주로 알림 기능을 수행하는 앱을 중점적으로 살펴보고 있습니다. Windows 8은 새로운 푸시 알림 플랫폼의 확장성을 바탕으로 시스템에 미치는 영향을 최소화하면서 이러한 기능을 제공할 수 있습니다. 이러한 알림 기능은 현재 Windows에 활용되고 있는 다양한 메커니즘 중에서도 개선 효과가 매우 큰 부분입니다. 데스크톱만 고집하는 사용자라도 새로운 시작 화면을 사용해 본다면, 한 번의 키 입력만으로 중앙에 효율적으로 표시되면서 간편하게 제어할 수 있는 알림 영역의 가치를 높이 평가하게 될 것입니다.
알림 플랫폼의 목표
수백 개에 이르는 앱 타일의 작업 정보를 실시간으로 제공하는 동시에 성능을 그대로 유지한다는 두 가지 목표는 언뜻 서로 상충하는 것으로 보입니다. 결국 '작업'이란, 말 그대로 리소스가 소모되기 마련인데, 예를 들어 클라우드에서 알림을 받으려면 네트워크를 사용해야 하고 타일에 알림을 렌더링하려면 GPU/CPU 리소스를 사용해야 합니다. 성공적인 디자인을 위해서는 처음에 세웠던 목표를 계속해서 상기할 필요가 있었습니다.
- 수백 개의 라이브 타일을 사용하면서 성능을 그대로 유지합니다.
- 풍선, 배지 및 텍스트뿐 아니라 아름다운 이미지를 사용합니다.
- 개발자의 편의성을 고려하여 자동화된 개발을 지원합니다.
- 실시간으로 제공한다는 목표를 실현하여 '인스턴트 메시지'를 즉시 전달합니다.
이러한 목표를 염두에 두고 기반 기술 아키텍처와 관련하여 처음에 내린 결정은 데이터 중심의 플랫폼을 개발하는 것으로, 시작 화면을 구동하기 위해 백그라운드에서 어떤 앱 코드도 실행하지 않는 것이었습니다.
알림 제공 시스템을 자세히 살펴보면 연결 시기에 관한 논리, 인증, 로컬 캐싱, 렌더링, 오류 처리, 백오프 알고리즘, 성능 제한 등 여러 가지 요소들이 있습니다. 또한 이 시스템은 전달되지 않은 콘텐츠를 캐싱하고 재시도가 필요한 복잡한 시나리오를 처리할 수 있도록 사용자의 연결 여부를 확인하는 등의 서비스 쪽 문제도 해결해야 합니다. 그런데 라이브 타일을 포함한 앱이 각각 모든 클라이언트/서버 코드를 자체적으로 사용한다면 어떻게 될까요? 구현된 앱마다 각기 다른 버그들이 발생할 뿐 아니라, 메모리에 각 앱을 로드할 때마다 기본적으로 동일한 코드가 실행되어 중복되고, 디스크에 계속해서 코드 페이징을 수행했다 취소하는 문제가 생길 것입니다. 시작 화면을 라이브 상태로 유지하기 위해 모든 앱을 항상 실행해야 하므로 이러한 방법은 비효율적입니다. 메모리가 많은 시스템이라도 결국 성능이 저하될 수밖에 없습니다.
Windows 8에서 메모리 사용량을 줄이는 방법에 관해 Bill Karagounis가 작성한 글에서 언급했듯이, 실행되는 프로세스, DLL, 서비스 등의 수가 증가하면 그에 따라 성능은 저하됩니다. 모든 라이브 타일이 각각 자체 코드로 실행된다면 수백 개의 라이브 타일을 사용하면서 성능을 그대로 유지한다는 첫 번째 목표를 달성할 수 없을 것입니다.
그에 따른 우리의 해결책은 데이터 중심의 모델을 개발하는 것이었습니다. 다시 말해서 개발자는 사전 정의된 일련의 속성과 서식 파일, 이 경우에는 XML 스키마를 사용하여 타일을 표현할 수 있습니다. XML 타일 데이터는 단순한 HTTP POST를 통해 Windows 푸시 알림 서비스(WNS)로 보내지고 나머지는 자동으로 처리됩니다. 연결, 재시도, 인증, 캐싱, 렌더링, 오류 처리 등에 필요한 모든 코드가 전력을 효율적으로 사용하면서 일관된 방식으로 이루어집니다.
여기서 개발자가 Windows 8 앱 개발에 사용할 수 있는 많은 타일 서식 파일 중 하나를 살펴보겠습니다. 이 서식 파일은 단순하게 이미지 하나와 텍스트 필드 하나로 이루어져 있지만 다른 여러 가지 서식 파일을 선택할 수 있습니다.
그림 1: 예제 서식 파일(TileWideImageAndText)
위의 타일을 설명하는 XML 코드는 다음과 같습니다.
<?xml version="1.0" encoding="utf-8"?> <tile> <visual lang="en-US"> <binding template="TileWideImageAndText"> <image id="1" src="https://www.fabrikam.com/kickflip.png"/> <text id="1">First ever surfboard kickflip recorded in Santa Cruz</text> </binding> </visual> </tile>
데이터 중심 모델을 채택한 결과, 성능과 빠른 실시간 경험을 구현한다는 처음 두 가지 목표를 이룰 수 있었지만, 여전히 실시간으로 정보를 제공하면서 자동화를 효율적으로 처리하는 방법을 찾아야 했습니다.
클라이언트/서버 콘텐츠 제공에는 고차원적 디자인 패턴이 두 가지 있는데, 바로 폴링과 푸시입니다. 폴링 방식의 경우, 클라이언트는 새로운 콘텐츠가 있는지 확인하기 위해 주기적으로(예: 90분마다) 서비스를 확인합니다. 반면 푸시 방식에서는 새로운 콘텐츠가 있을 때 서비스가 클라이언트로 직접 데이터를 보냅니다.
폴링 모델에서 새로운 메시지가 도착했을 때 즉시 처리할 수 있도록 알림을 즉각적으로 구현하는 유일한 방법은 충분히 자주(예: 5초마다) 폴링을 수행하는 것입니다. 그러나 이런 경우 저희가 추구하는 성능 목표를 달성하기 어렵습니다. 5초 간격으로 폴링된다면 네트워크 라디오 스택이 쉴 새 없이 작동하면서 배터리 수명이 크게 감소하며, 데스크톱 시스템은 절전 모드로 전환되지 않고 항상 켜져 있게 됩니다. 이러한 상황은 휴대전화로 하루 종일 통화하여 결국 배터리가 방전되는 것과도 같습니다. 뿐만 아니라, 평소에는 대부분 새로운 내용이 거의 없기 때문에 5초마다 서버에서 새로운 내용을 확인하면 리소스 낭비가 매우 심합니다. Vista에 도입된 시스템 트레이 알림과 데스크톱 가젯은 폴링 방식으로 구현된 것입니다. 그러나 어떤 폴링 방식을 사용해도 현재의 폴링 주기로는 '즉각적'인 오늘날의 실시간 서비스를 따라가기 어렵습니다.
따라서 Windows 8에서는 푸시 기반의 서비스 아키텍처를 채택했습니다. 이는 궁극적으로 10억 명 이상의 사람이 사용할 수십만 개의 앱 타일을 지원하는 엄청난 규모로 플랫폼을 구축하는 문제이므로 매우 중대한 결정이었습니다. 그러나 그 결과 얻게 되는 가치는 분명했습니다. 즉, 개발자는 클라이언트와 직접 지속적인 연결을 구축하거나 유지할 필요 없이 해당 고객에게 효율성이 아주 높은 실시간 알림 서비스를 무료로 제공하게 됩니다.
푸시 알림 플랫폼
디자인을 보다 세부적으로 설명하기 위해 이 플랫폼의 여러 가지 구성 요소에 관해 자세히 알아보겠습니다. 아래 다이어그램에는 세 가지 핵심 요소가 나와 있습니다.
- Windows 푸시 알림 서비스(WNS): 라이브 타일 알림과 토스트 알림을 처리합니다.
- 앱 서비스: WNS를 통해 토스트 알림과 타일 업데이트를 보내기 위해 메트로 스타일 앱이 기존 웹 사이트 등에서 실행하는 웹 서비스입니다. 예를 들면 개발자 프리뷰 빌드에 제공된 Weather(날씨) 앱에 이용되는 백엔드 서비스 또는 소셜 네트워킹 앱에 이용되는 사진을 호스팅하는 백엔드 서비스가 있습니다.
- Windows 8 클라이언트 플랫폼: 최종 사용자 경험을 위해 연결망을 형성하는 OS의 하위 구성 요소와 실제 PC를 나타냅니다.
그림 2: 푸시 알림 플랫폼
일반적인 사용 시나리오를 통해 이 플랫폼의 작동 방식을 알아보겠습니다. 어떤 사용자가 사진에 댓글을 다는 경우 타일 업데이트를 보내는 소셜 네트워킹 사이트를 앱 서비스로 가정해 보겠습니다. 혹은 처리할 버그가 나에게 할당되거나 지출 보고서의 결제가 필요할 때 업데이트를 보내는 업무 앱이라면 이해하기 쉬울 것 같습니다. 업데이트가 있으면 앱 서비스가 WNS로 알림을 보냅니다(위 다이어그램의 1단계). 여기서 WNS는 클라이언트로 알림을 푸시합니다(2단계). 시작 화면에 타일 업데이트를 표시할 때가 되면 OS가 알림 XML에 포함된 URL을 바탕으로 앱 서비스로부터 이 이미지를 가져옵니다(3단계). 알림과 이미지가 다운로드되면 앱이 XML에 지정된 서식 파일을 사용하여 라이브 타일을 렌더링하고 시작 화면에 표시합니다.
앞서 언급했듯이 여기서 처리를 자동화하는 것이 목표입니다. 따라서 개발자가 복잡한 캐싱을 작성하고, 절전 상태의 랩톱과 같이 PC가 연결되지 않은 경우 작업을 재시도하는 번거로움을 겪지 않도록 PC가 다음 번에 온라인 상태가 될 때까지 WNS 클라우드에서 각 앱에 하나의 알림이 캐싱됩니다.
클라이언트 플랫폼 구성 요소를 디자인하면서 성능을 높이고 전력 소모량을 줄이기 위해 엔지니어링 측면에서 모든 노력을 기울였습니다. 핵심 부분 중 하나는 알림 페이로드를 이미지 페이로드와 분리하는 것이었습니다. 일반적인 알림 XML의 데이터 크기는 1KB 미만이지만 이미지의 크기는 최대 150KB에 이를 수 있습니다. 이 두 부분을 분리함으로써 이미지 중복이 많은 경우에 네트워크 대역폭을 상당히 줄일 수 있었습니다. 예를 들어, 친구의 프로필 사진을 타일 이미지로 사용할 수 있는데, 이 이미지는 PC에서 한 번 다운로드되면 이후에 다시 사용할 수 있도록 로컬에 캐싱됩니다. 알림을 이미지와 분리하면 사용하지 않는 알림을 보다 효율적으로 폐기할 수 있으므로 번거롭게 이미지를 다운로드할 필요가 없습니다. 업무를 처리하는 동안 장치 화면이 꺼진 채로 침대 위에 올려져 있다면 다음 번에 장치를 사용할 때는 타일 이미지가 이후 업데이트로 대체될 것이므로 이미지를 다운로드할 필요가 없습니다.
인증 모델
라이브 타일과 알림은 앱 경험에서 중요한 부분을 차지하기 때문에 앱 서비스에서 시작 화면의 타일에 이르는 전 과정에서 통신 채널을 인증하고 보안을 유지하는 것이 중요합니다. 앱이나 악성 웹 서비스가 시스템에서 아무 타일이나 업데이트하도록 허용한다면 심각한 문제가 발생할 것입니다. 따라서 PC와 WNS 사이의 연결을 고유하게 식별하는 익명의 인증 방식을 사용합니다. 앱과 앱 서비스는 WNS와 정보를 주고받을 때도 인증을 사용합니다. WNS에 대한 두 연결을 모두 인증하므로 스푸핑 공격과 같이 라이브 타일 업데이트를 악용하는 경우도 효과적으로 차단됩니다. WNS가 사용하는 인증 방식은 응용 프로그램과 서비스를 명시적으로 연결하여 다른 응용 프로그램이나 악의적 사용자가 무단으로 타일에 콘텐츠를 보내지 못하도록 합니다. 물론, 모든 통신은 보안 채널을 통해 이루어집니다.
이러한 모든 작동 방식은 Windows Live ID를 사용하여 Windows에 로그인했는지 여부와 관계없이 이루어집니다. 물론, Katie Frigon이 작성한 Windows Live ID를 이용한 로그인에 관한 글에서 언급했듯이, Windows 8에서 연결된 계정을 사용하면 앱 클라우드 저장소, 로밍 Windows 및 앱 설정, 다수의 앱에 대한 단일 로그인 등 새롭게 개선된 다양한 경험을 누릴 수 있다는 이점이 따릅니다. Windows Live ID로 로그인하더라도 푸시 알림 플랫폼은 익명 인증 방식을 사용하기 때문에 앱 개발자는 알림 파이프라인을 통해 사용자의 Windows Live ID, 시스템 정보 또는 위치를 알아낼 수 없습니다.
대규모로 확장 가능한 서비스 구축
이 글의 초반부에 엄청나게 많은 사용자와 앱을 지원하도록 플랫폼을 구축해야 했다고 언급했습니다. 이러한 규모를 쉽게 이해할 수 있도록 아래 그래프에 앱에서 하루에 Windows 8로 보내는 알림의 수를 표시했습니다. 아직 베타 버전도 나오지 않은 상태인데 몇 주 전만해도 하루에 거의 9천만 개의 타일 업데이트가 전송되었습니다!
그림 3: 하루에 Windows 8 개발자 프리뷰 빌드로 보낸 알림의 수
Stocks(주식) 앱은 개발자 프리뷰 빌드에서 가장 인기가 높은 테스트 앱 중 하나입니다. 다음 그래프는 개발자 프리뷰 빌드 출시 후 첫 달에 이 앱에 등록된 총 라이브 타일의 수를 보여줍니다.
그림 4: 개발자 프리뷰 빌드의 Stocks(주식) 앱에 등록된 라이브 타일 수
개발자 프리뷰 빌드가 출시되었을 때 데이터 센터를 통해 들어오는 트래픽을 관찰하면서 어떤 식으로 확장되는지 주의 깊게 모니터링했습니다. 아래 데모에서는 //build 컨퍼런스에서 개발자 프리뷰 빌드를 출시한 후 처음 몇 일간 알림의 실제 지리적 분포를 시각적으로 표현했습니다. 데이터는 평방 마일당 단위를 나타내며 폭넓은 밀도 값을 나타내기 위해 로그 스케일을 사용했습니다.
다른 미디어 플레이어로 보려면 이 비디오를 다운로드하십시오.
고화질 MP4 | 저화질 MP4
WNS의 디자인은 Windows Live Messenger 서비스 아키텍처를 기반으로 하며, 실제로 알림 플랫폼의 서비스 부분은 같은 팀에서 개발했습니다. 단시간에 엄청난 규모로 확장되는 글로벌 규모의 서비스를 구축할 수 있는 전문성과 지식을 갖춘 팀은 전 세계 어디서도 찾기 어려울 것입니다. 아래의 몇 가지 통계로 현재 Windows Live Messenger 서비스의 규모를 파악할 수 있습니다.
- 매월 3억 명의 사용자 활동
- 매일 6억 3천만 번 로그인
- 매일 100억 개의 알림
- 4천만 번 이상의 최고 SOC(동시 온라인 접속)
- 전 세계적으로 3천 대의 컴퓨터에서 메시지 전달
작업 관리자를 통해 쉽게 파악할 수 있는 타일 리소스 사용량
알림 플랫폼의 성능 측면을 개선하려는 열의에 따라 각 응용 프로그램에 대해 타일 플랫폼이 소모하는 대역폭을 추적할 수 있는 측정 기능을 새로운 작업 관리자에 추가했습니다. 일반적으로, 타일의 리소스 사용량은 비교적 적은 편입니다. 개발자 프리뷰 빌드를 사용하는 개발자라면 작업 관리자의 앱 기록 탭으로 이동하여 '타일' 열에서 각 라이브 타일이 지난 30일 동안 소모한 대역폭의 양을 확인해 보십시오.
그림 5: 작업 관리자의 앱 기록에 표시된 라이브 타일의 리소스 사용량
요약
Windows 8에서는 기존의 플러그인 및 가젯 기반 모델에서 유발되는 모든 성능 문제와 배터리 수명 문제를 해소하고, 정보를 한 눈에 파악할 수 있는 알림 플랫폼을 설계하기 위해 노력했습니다. 이를 위해 모든 디자인 요소는 성능과 배터리 수명의 효율성을 고려하여 결정되었습니다. 앱 개발자가 쉽게 참여할 수 있도록 Windows 푸시 알림 서비스를 구축했기 때문에 복잡한 네트워크 연결 코드를 작성하지 않고도 라이브 타일을 만들 수 있으며, WNS는 HTTP POST와 같은 표준 웹 기술을 사용하므로 개발자는 기존의 웹 서비스를 기반으로 알림을 쉽게 통합할 수 있습니다.
결과적으로 성능이나 배터리 수명에 지장을 주지 않으면서 원하는 앱을 얼마든지 설치하는 동시에 다양한 정보를 한 눈에 볼 수 있는 알림 플랫폼을 구현하게 되었습니다.
- Ryan Haveson