iPhone 2.0 SDK: The No Multitasking Myth

casaubon · 2008-03-13, 11:04 PM

iPhone 2.0 SDK: The No Multitasking Myth
March 13th, 2008 | History, Journal, Markets, Mobiles, Software, Tech, the Media

Daniel Eran Dilger

아이폰 2.0 SDK를 두고 악랄한 우려를 개발해낸 전문가들이 있다. 이들이 말하는 첫 번째 문제는 아이폰이 한 번에 여러 개의 애플리케이션을 돌릴 수 없어보인다는 점이다. 이들에 따르면 오리지날 맥이나 Palm Pilot처럼 아이폰은 멀티태스킹 능력이 떨어지지만, 윈도 모바일용의 WinCE는 그렇지 않다고 한다. 이들은 틀렸다. 왜인지 알아보자.

The iPhone is Unix.
일단 아이폰이 어떻게 돌아가는지, 코어 OS가 어떤지를 보면 된다. 아이폰의 커널은 맥오에스텐의 커널과 같다. 즉, 표준형 유닉스 하부시스템을 구성하는 Mach와 BSD의 하이브리드이며, 다중 프로세서와 다중 사용자를 지원한다.

이 시점에서 Palm OS 또한 멀티태스킹 커널상에서 만들어졌다는 점을 지적해야겠다. 그러나 Palm은 Kadak으로부터 싱글-태스킹 환경만 라이센스받았다. 이 때문에 Palm OS는 80년대 중반의 클래식 맥오에스와 대단히 유사해졌다. 첫 번째 애플리케이션을 종료시켜야 두 번째 애플리케이션이 돌아갔기 때문이다.

애플은 아이폰에서 같은 문제를 겪지 않았다. 애플 스스로 아이폰 커널을 소유하고 있기때문에, 멀티태스킹을 막을 만한 외부적인 기술 제한이 없었다. 아이폰은 전화 통화중에도 Maps 프로그램을 돌릴 수 있으며, 전화 통화가 끝나기 전에 웹페이지 링크를 따라들어갈 수도 있다. 모두 첫 번째 광고에 이미 나온 기능이다.

웹브라우징을 할 때 전화가 울리고, 다른 작업을 할 때 백그라운드 상에서 음악이 돌아가며, 메일도 확인한다. 확실히 멀티태스킹을 한다는 얘기다. 그렇다면 SDK 문서는 어째서 "한 번에 하나의 아이폰 애플리케이션을 돌릴 수 있다."라 쓰여 있을까? 아이폰이 클래식 맥이나 Palm Pilot과 똑같은 구조적인 문제는 일단 없다는 점부터 시작해 보자.

iPhone의 BSD 유닉스
어처구니 없는 Palm의 실수연발

Multitasking Macs before Unix.
오리지날 맥은 다중 애플리케이션을 한 번에 돌릴 만한 자원을 갖지 못했다. 첫 번째 맥 사용자들은 한 번에 하나의 애플리케이션만 돌릴 수 있었는데, 이는 심각한 제한이었다. 1985년, 앤디 허츠펠드(Andy Hertzfeld)는 Switcher라는 유틸리티를 만들어서, 활성화중인 애플리케이션을 중지시키고 새 애플리케이션을 돌릴 수 있도록 했었다. 1987년, 애플은 동시에 여러 개의 애플리케이션을 보여주고, 그 사이를 빠르게 이동시켜주는 MultiFinder를 출시한다.

그러나 클래식 맥은 유닉스-스타일의 선점형 멀티태스킹을 하지 않았다. 선점형 멀티태스킹이란, 운영체제가 활성화중인 애플리케이션에게 프로세싱 자원을 엄격하게 관리하여 부여하는 방식이다. 클래식 맥은 그 대신 협력형 멀티태스킹을 사용하여 프로세서 상에서 순번을 바꾸는 식에 의존하였다. 즉, 애플리케이션 하나가 무한루프에 들어가게 되면, 전체 머신이 멈춰지는 문제를 야기할 수 있었다.

유닉스에서는 이런 일이 일어나지 않는다. 프로세스를 신뢰하지 않기 때문이다. 커널이 이 프로세스를 관리하는데, 작동이 멈춰지면, 그 작동을 넘어서서 시스템 차원에까지 영향을 끼치지는 않게 된다. 시스템 자체를 멈추게 될 프로세스는 커널 그 자신이다. 즉, 커널 상의 모든 소프트웨어는 극단적으로 안정적이다. 이 때문에 애플은 개발자들에게, 불필요할 경우, 되도록이면 커널 익스텐션으로 프로그램 작성을 하지 말도록 권장한다.

Folklore.org: Macintosh Stories: Switcher

Just Because You Can, Doesn’t Mean You Should.
아이폰은 유닉스의 ‘kernel in command’ 아키텍쳐를 갖고 있다. 하지만 동시에 여러 가지 애플리케이션을 돌릴 수 있다고 해서, 개발자들에게 이를 무조건 허용하는 것이 좋다는 의미는 아니다. 맥오에스텐에서 여러 가지 애플리케이션을 활성화시키는 일은 그다지 큰 문제를 일으키지 않는다. 시스템이 RAM 한도를 벗어나는 경우, 시스템은 비활성중인 애플리케이션을 하드드라이브 상의 가상메모리에 집어 넣는다. 다시 활성화시킬 때까지 동면시키는 것이다.

아이폰의 가상 메모리 시스템도 같지만, 기가바이트 급의 RAM이나 가상메모리 스왑공간이 충분한 하드 드라이브까지 갖고 있진 않다. 아이폰의 RAM은 128MB이며, VRAM이 11MB 정도이고, 시스템이 점유한 용량이 19MB 정도이다. 즉, 사용자가 사용할 수 있는 메모리는 76MB 정도다.

백그라운드 프로세스 양을 조절해야, 아이폰의 오에스텐은 우선 활성중인 애플리케이션에 더 많은 RAM을 할당시킬 수 있다. 아이폰은 일반적인 목적의 컴퓨터가 아니며, 휴대폰과 브라우저, 아이포드의 합체이다. SDK가 야기한 제한때문에, 아이폰은 상당한 게임용 플랫폼이면서, 바로 사무용 애플리케이션으로 돌아갈 수도 있다. 이 모두가 휴대폰 자체의 기능과 브라우징, 아이포드를 희생시키지 않아도 된다. 다른 기기들은 그렇지 못하다.

furbo.org · What the iPhone specs don’t tell you
Mac OS X 마이크로커널의 미신을 벗긴다 1-3

The Problem With Background Processes.
물론 아이폰은 보통의 스마트폰 RAM의 두 배를 갖고 있지만, 백그라운드 프로세스가 돌아간다고 하면 76MB 정도는 우스워진다.

RAM만이 아니다. 미디어 재생과 WebKit 렌더링, 전화와 라디오신호 처리, VoIP 데이터암호화, 푸시 이메일과 문자 메시지, 정보 관리 모두가 제대로 돌아가지 않으면 안될 필수 기능들이다.

휴대폰의 핵심 기능이 사용할 광대역 외에도, 프로세서가 소비하는 별도의 백그라운드 프로세스가 생기면, 전화기는 뜨거워지고, 전기도 닳아서 배터리 수명이 짧아진다. 결국 기기 자체의 수명도 줄인다는 얘기다.

따라서 아이폰이 생각한대로 움직이도록, 발열이 심해지지 않도록, 새 애플리케이션을 설치해도 배터리 수명에 지장이 없도록 해야 할 가이드라인을 지정해줘야 한다. 그것이 애플의 책임이다. 써드파티가 멋대로 백그라운드 프로세스를 잡아먹게 놓아 둬서는 안된다. 개발자들에게 문을 활짝 연 뒤에, 프로세서 관리를 못한다면서 사용자를 타박해서도 안된다. 무책임한 행동이다.

iPhone의 OS X: Mach 커널과 RAM

The Problem with Foreground Multiprocessing.
백그라운드 문제만 있지는 않다. 전면부(foreground)에서 돌아가는 다중 애플리케이션의 문제도 있다. 물론 아이폰은 분명 어디서든지 다중 애플리케이션을 한 번에 돌릴 능력을 갖추었다. 전화 받으면서, 홈스크린으로 되돌아간 다음 다른 애플리케이션을 돌릴 수 있으니 말이다. 통화중에는 화면 최상단에 녹색 막대가 나타나서, 언제든 전화중 상태의 화면으로 되돌아갈 수 있다.

다른 애플리케이션(물론 이 경우 Safari는 웹페이지를 돌아다니다가 충돌을 일으킬 경우가 잦다)이 돌아갈 때 아이튠스는 오디오를 돌릴 수 있다. 어디에서건, 아이포드 재생 컨트롤러 Home 버튼을 더블클릭해서 아이포드 재생 컨트롤러를 화면상에 불러들일 수 있다.

두 사례 모두 보면, 화면 인터페이스에 다소 제약이 있다. 일부러 그런 것이다. 돌아가고 있는 다른 애플리케이션이 없으면, 활성화중인 애플리케이션과 중요한 백그라운드 프로세스에 더 많은 자원을 할당할 수 있다. 위에 언급한 바와 마찬가지이다. 이뿐만이 아니다. 사용자 입장에서 인터페이스도 크게 단순해진다.

아이포드 기능도 주요 기능이기는 하지만, 아이폰은 휴대폰이기에 독특한 면이 있다. 하지만 프로세서 안에서 모든 애플리케이션이 자기 자리를 점유해버린다면, 남는 자리가 안 생길 것이다. 더군다나 아이폰 디스플레이는 그 많은 애플리케이션이 다 뜰 만큼 크지도 않다. 물론 그럴 수도 있겠지만 휴대용 기기에 적절하지 않은 인터페이스로 만들어 놓고 애플릿을 구겨 넣은 다른 곳보다 애플은 더 휴대용 기기를 더 잘 알고 있다.

Rocket Launching.
시스템 정책을 따르기보다 애플리케이션 스스로가 결정을 내리도록 해야 한다는 의견이 들리기는 좋을지 몰라도, 실제로는 그리 좋지 못하다. 사실 애플의 정책은 사파리에 대한 써드파티 애플리케이션과 동일하다. 사용자가 Home 버튼을 눌렀을 때, 시스템은 현재 애플리케이션 데이터를 저장한 다음, 애플리케이션을 종료시키고, 애플리케이션 메뉴가 있는 Springboard를 내놓는다. 다음에 애플리케이션을 다시 활성화시키면, 종료됐을 때와 같은 상태로 시작한다.

이 활성화 시간이 너무나 빠르기에, 사용자 입장에서는 가상 메모리 상에서 돌아가는 애플리케이션을 다시 불러들이는 것이나, 종료시켰다가 필요해서 다시 활성화시키는 것이나 별 차이 없다고 느끼게 마련이다. 물론 기술적인 차이는 있다. 애플리케이션 종료가 배터리 수명 등, 자원 사용에는 더 효율적이다. 사용자들도 그것을 알아차릴 것이다.

이 때문에 애플은 SDK에서 이렇게 적고 있다. "한 번에 하나의 아이폰 애플리케이션을 돌릴 수 있으며, 써드-파티 애플리케이션은 백그라운드에서 돌리지 않는다. 사용자가 다른 애플리케이션으로 전환시키거나, 통화를 하고 이메일을 확인할 때, 해당 애플리케이션은 종료된다는 의미다."

Invent, Suggest, Panic!
엔지니어링에 대해 잘 모르는 블로그들이 있다. 이름도 기가 막히게, BoyGenius Report라고 되어있는데, 이곳이 최근 써드파티 애플리케이션도 백그라운드에서 돌아가게 해달라며, 동등한 권리를 요구하는 청원에 나섰다. 종료시킬 필요 없이 애플리케이션간에 전환이 가능하게 해 달라는 것이다. 듣기에는 좋게 들린다. 하지만 제대로 알고 하는 얘기일까?

엡슈타인(Zach Epstein)은 아이폰에 "진정한 멀티태스킹이 없다"면서, 개발자인 발루섹(Robert Balousek)을 인용하였다. "AOL 인스턴트 메신저같은 애플리케이션을 돌린다면, 통화가 오거나 브라우징을 할 때마다, 나중에 다시 로그인해야 할 것이다. 못읽은 메시지는 영원히 못읽게 되고, 대화는 끝이다."

그러나 콕스(Christopher Cox)는 이런 지적을 했다. "이 글 저자는 크게 오버하고 있다. [...] 간섭이 있을 때, 애플리케이션이 정지해서, 현재의 데이터를 저장하게 된다. 다시 애플리케이션을 돌리면, 예전 메시지는 여전히 남아 있다. [...] AIM 서버도, 프로그램이 접속 끊기 신호를 보낸다거나, 특정 시간 이상 연결되어있지 않는 이상, 접속을 끊지 않는다. 즉, AIM 애플리케이션으로 되돌아가면, 메시지도 바로 나타난다는 의미다. 재접속 할 필요가 없다. 물론 AIM에 24시간 내내 접속해 있고 싶다면야, 단점이 될 것이다. 그 뿐이다. 그러나 대부분은 그럴 정도의 마음가짐을 갖고있지 않다."

iPhone SDK Honeymoon Over - No Background Processes?! | The Boy Genius Report

What Would Happen If Apple Didn’t Know Any Better.
아이폰 SDK와 관련, 멀티태스킹이 안되리라는 주장이 헛것이라는 점을 알았다. 잘못된 정보다. 그런데 혹시, 애플이 제한을 가하지 않을 경우 아이폰이 어쩌면 더 나아질 가능성은 없을까? 추측할 일도 없다. 듣기 좋은 발린 단어 나열만 좋아하는 위원회 식의 엔지니어링을 통해, 만들어진 확실한 사례가 있기 때문이다. 마이크로소프트의 WinCE이다.

마이크로소프트는 WinCE를 유닉스와 같은 멀티태스킹 아키텍쳐로 간주하지만, 가상메모리 구조를 갖고 있기는 해도, 동시에 돌릴 수 있는 프로세스가 32개에 불과하다. 또한 각각의 프로세스가 갖는 가상 어드레스 공간 또한 32MB 뿐이다. 하지만 이 정도 사양도, 수 년 후에나 널리 쓰일 WinCE 6.0 사양이다. 그 때까지 멀티태스킹 WinCE라는 주장은 근본적으로 오류다. 물론 실상은 그보다 더 열악하다.

멀티태스킹 기능을 효율적으로 사용하지 못하게 막으면서도, WinCE는 써드파티의 백그라운드 프로세스만은 제한이 두지 않았다. 하지만 휴대용 기기에서 다중의 애플리케이션을 돌리는 것은 좋지 않다. 그 이유는 많다. 첫 번째 이유는 필자가 이미 명시한, 자원 사용의 문제다. 필자 대신, WinCE 옹호자인 헤러라(Chris De Herrera)의 말로 해 보겠다.

"한 번에 여러 가지 애플리케이션을 돌려놓으면, 전면부 애플리케이션이 눈에 띄게 느려질 때가 있다. 이런 현상은 운영체제가 백그라운드 애플리케이션에게 자원을 써 주어야 하기 때문이다. 이 때 필자가 권장하는 바는, 소프트웨어의 재시동이다."

Like kill on the road,
Windows has failed to respond.
Control! Alt! Delete!

그런데 또 하나의 이유가 있다. 같은 시간에 그 많은 걸 들여다 볼 화면이 없다는 것이다. 실질적인 화면 크기가 정해져 있기에, 데스크톱처럼 다중의 겹쳐지는 창과 제목막대, 창끼리 전환하는 기능을(Lisa가 최초로 보여준 기능이다) 들여다보는 것이 실질적으로 유용하지 않다. 하지만 마이크로소프트는 아랑곳하지 않고, 90년대 후반 이후, 맥 데스크톱 UI를 베낀 윈도를 그 조그마한 화면에 애써 구겨 넣었다.

그러니 팔릴리가 없다. WinCE 기기는 너무나 복잡해져서 그걸로 뭘 어떻게 할지 이해하기도 힘들어졌다. 게다가 충돌도 잦고, 배터리 수명도 절망적이었다. 아이폰은 너무나 간단해서, 일단 돌려본 다음, 별다른 훈련 없이 잘 쓸 수 있다. 그저 잘 돌아가는 아이폰이다. 애플이 Dock과 Finder 데스크톱을 아이폰에 구겨 넣으려 했다면, 아이폰 역시 절망적으로 안팔렸을 것이다.

WinCE와 Windows Mobile의 처절한 실패사

Less is More; More with Less.
아이폰은 WinCE에 비해 더 나은 멀티태스킹 커널을 갖고 있다. 서류상에 나온 모든 기능을 다 하려들다가, 결국 아무 것도 잘 못해고 팔리지도 않는 기기를 만들어내는 마이크로소프트식 시스템이 아니다. 애플 엔지니어들은 아이폰 2.0 SDK에 제한을 가해서 사용자에게 더 유용한 애플리케이션을 덧붙이도록 할 것이다.

새 소프트웨어가 나오기도 전에, 기존 아이폰 판매량은 이미 미국 내에서 윈도 모바일 휴대폰의 판매량을 크게 넘어섰다. 아이폰의 스마트폰 시장 점유율은 27%이고, 모든 모바일 웹 트래픽의 71%를 차지하는 휴대폰이 아이폰이다.

마이크로소프트는 데스크톱 PC와 마찬가지다. 복잡함을 벗어나 WinCE를 애플 아이폰처럼 만들기는 불가능할 것이다. 이미 나와 있는 윈도 모바일 애플리케이션들이 모두 프로세서 백그라운드에서 돌아갈 권리를 갖고 있어서, 스마트폰을 느리고, 비효율적으로 만들기 때문이다. 제일 열광적인 윈도 옹호자들조차 끌지 못할 정도로 복잡해진 것이 윈도 모바일이다.

아이폰도 당연히 똑같은 문제를 겪어야 한다고 주장하는 꼴을 보니, 실용성과 단순성을 그들이 왜그리 이해못하는지 확실히 알 만하다.

iPhone과 경쟁하기 - 소프트웨어

What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

iPhone 2.0 SDK: The No Multitasking Myth

2008-03-13, 11:04 PM	#3
casaubon Moderator Registered: Sep 2001 My Mac: MacBook Air Posts: 2,234 오프라인	iPhone 2.0 SDK: 멀티태스킹 미신 iPhone 2.0 SDK: The No Multitasking Myth March 13th, 2008 \| History, Journal, Markets, Mobiles, Software, Tech, the Media Daniel Eran Dilger 아이폰 2.0 SDK를 두고 악랄한 우려를 개발해낸 전문가들이 있다. 이들이 말하는 첫 번째 문제는 아이폰이 한 번에 여러 개의 애플리케이션을 돌릴 수 없어보인다는 점이다. 이들에 따르면 오리지날 맥이나 Palm Pilot처럼 아이폰은 멀티태스킹 능력이 떨어지지만, 윈도 모바일용의 WinCE는 그렇지 않다고 한다. 이들은 틀렸다. 왜인지 알아보자. The iPhone is Unix. 일단 아이폰이 어떻게 돌아가는지, 코어 OS가 어떤지를 보면 된다. 아이폰의 커널은 맥오에스텐의 커널과 같다. 즉, 표준형 유닉스 하부시스템을 구성하는 Mach와 BSD의 하이브리드이며, 다중 프로세서와 다중 사용자를 지원한다. 이 시점에서 Palm OS 또한 멀티태스킹 커널상에서 만들어졌다는 점을 지적해야겠다. 그러나 Palm은 Kadak으로부터 싱글-태스킹 환경만 라이센스받았다. 이 때문에 Palm OS는 80년대 중반의 클래식 맥오에스와 대단히 유사해졌다. 첫 번째 애플리케이션을 종료시켜야 두 번째 애플리케이션이 돌아갔기 때문이다. 애플은 아이폰에서 같은 문제를 겪지 않았다. 애플 스스로 아이폰 커널을 소유하고 있기때문에, 멀티태스킹을 막을 만한 외부적인 기술 제한이 없었다. 아이폰은 전화 통화중에도 Maps 프로그램을 돌릴 수 있으며, 전화 통화가 끝나기 전에 웹페이지 링크를 따라들어갈 수도 있다. 모두 첫 번째 광고에 이미 나온 기능이다. 웹브라우징을 할 때 전화가 울리고, 다른 작업을 할 때 백그라운드 상에서 음악이 돌아가며, 메일도 확인한다. 확실히 멀티태스킹을 한다는 얘기다. 그렇다면 SDK 문서는 어째서 "한 번에 하나의 아이폰 애플리케이션을 돌릴 수 있다."라 쓰여 있을까? 아이폰이 클래식 맥이나 Palm Pilot과 똑같은 구조적인 문제는 일단 없다는 점부터 시작해 보자. iPhone의 BSD 유닉스 어처구니 없는 Palm의 실수연발 Multitasking Macs before Unix. 오리지날 맥은 다중 애플리케이션을 한 번에 돌릴 만한 자원을 갖지 못했다. 첫 번째 맥 사용자들은 한 번에 하나의 애플리케이션만 돌릴 수 있었는데, 이는 심각한 제한이었다. 1985년, 앤디 허츠펠드(Andy Hertzfeld)는 Switcher라는 유틸리티를 만들어서, 활성화중인 애플리케이션을 중지시키고 새 애플리케이션을 돌릴 수 있도록 했었다. 1987년, 애플은 동시에 여러 개의 애플리케이션을 보여주고, 그 사이를 빠르게 이동시켜주는 MultiFinder를 출시한다. 그러나 클래식 맥은 유닉스-스타일의 선점형 멀티태스킹을 하지 않았다. 선점형 멀티태스킹이란, 운영체제가 활성화중인 애플리케이션에게 프로세싱 자원을 엄격하게 관리하여 부여하는 방식이다. 클래식 맥은 그 대신 협력형 멀티태스킹을 사용하여 프로세서 상에서 순번을 바꾸는 식에 의존하였다. 즉, 애플리케이션 하나가 무한루프에 들어가게 되면, 전체 머신이 멈춰지는 문제를 야기할 수 있었다. 유닉스에서는 이런 일이 일어나지 않는다. 프로세스를 신뢰하지 않기 때문이다. 커널이 이 프로세스를 관리하는데, 작동이 멈춰지면, 그 작동을 넘어서서 시스템 차원에까지 영향을 끼치지는 않게 된다. 시스템 자체를 멈추게 될 프로세스는 커널 그 자신이다. 즉, 커널 상의 모든 소프트웨어는 극단적으로 안정적이다. 이 때문에 애플은 개발자들에게, 불필요할 경우, 되도록이면 커널 익스텐션으로 프로그램 작성을 하지 말도록 권장한다. Folklore.org: Macintosh Stories: Switcher Just Because You Can, Doesn’t Mean You Should. 아이폰은 유닉스의 ‘kernel in command’ 아키텍쳐를 갖고 있다. 하지만 동시에 여러 가지 애플리케이션을 돌릴 수 있다고 해서, 개발자들에게 이를 무조건 허용하는 것이 좋다는 의미는 아니다. 맥오에스텐에서 여러 가지 애플리케이션을 활성화시키는 일은 그다지 큰 문제를 일으키지 않는다. 시스템이 RAM 한도를 벗어나는 경우, 시스템은 비활성중인 애플리케이션을 하드드라이브 상의 가상메모리에 집어 넣는다. 다시 활성화시킬 때까지 동면시키는 것이다. 아이폰의 가상 메모리 시스템도 같지만, 기가바이트 급의 RAM이나 가상메모리 스왑공간이 충분한 하드 드라이브까지 갖고 있진 않다. 아이폰의 RAM은 128MB이며, VRAM이 11MB 정도이고, 시스템이 점유한 용량이 19MB 정도이다. 즉, 사용자가 사용할 수 있는 메모리는 76MB 정도다. 백그라운드 프로세스 양을 조절해야, 아이폰의 오에스텐은 우선 활성중인 애플리케이션에 더 많은 RAM을 할당시킬 수 있다. 아이폰은 일반적인 목적의 컴퓨터가 아니며, 휴대폰과 브라우저, 아이포드의 합체이다. SDK가 야기한 제한때문에, 아이폰은 상당한 게임용 플랫폼이면서, 바로 사무용 애플리케이션으로 돌아갈 수도 있다. 이 모두가 휴대폰 자체의 기능과 브라우징, 아이포드를 희생시키지 않아도 된다. 다른 기기들은 그렇지 못하다. furbo.org · What the iPhone specs don’t tell you Mac OS X 마이크로커널의 미신을 벗긴다 1-3 The Problem With Background Processes. 물론 아이폰은 보통의 스마트폰 RAM의 두 배를 갖고 있지만, 백그라운드 프로세스가 돌아간다고 하면 76MB 정도는 우스워진다. RAM만이 아니다. 미디어 재생과 WebKit 렌더링, 전화와 라디오신호 처리, VoIP 데이터암호화, 푸시 이메일과 문자 메시지, 정보 관리 모두가 제대로 돌아가지 않으면 안될 필수 기능들이다. 휴대폰의 핵심 기능이 사용할 광대역 외에도, 프로세서가 소비하는 별도의 백그라운드 프로세스가 생기면, 전화기는 뜨거워지고, 전기도 닳아서 배터리 수명이 짧아진다. 결국 기기 자체의 수명도 줄인다는 얘기다. 따라서 아이폰이 생각한대로 움직이도록, 발열이 심해지지 않도록, 새 애플리케이션을 설치해도 배터리 수명에 지장이 없도록 해야 할 가이드라인을 지정해줘야 한다. 그것이 애플의 책임이다. 써드파티가 멋대로 백그라운드 프로세스를 잡아먹게 놓아 둬서는 안된다. 개발자들에게 문을 활짝 연 뒤에, 프로세서 관리를 못한다면서 사용자를 타박해서도 안된다. 무책임한 행동이다. iPhone의 OS X: Mach 커널과 RAM The Problem with Foreground Multiprocessing. 백그라운드 문제만 있지는 않다. 전면부(foreground)에서 돌아가는 다중 애플리케이션의 문제도 있다. 물론 아이폰은 분명 어디서든지 다중 애플리케이션을 한 번에 돌릴 능력을 갖추었다. 전화 받으면서, 홈스크린으로 되돌아간 다음 다른 애플리케이션을 돌릴 수 있으니 말이다. 통화중에는 화면 최상단에 녹색 막대가 나타나서, 언제든 전화중 상태의 화면으로 되돌아갈 수 있다. 다른 애플리케이션(물론 이 경우 Safari는 웹페이지를 돌아다니다가 충돌을 일으킬 경우가 잦다)이 돌아갈 때 아이튠스는 오디오를 돌릴 수 있다. 어디에서건, 아이포드 재생 컨트롤러 Home 버튼을 더블클릭해서 아이포드 재생 컨트롤러를 화면상에 불러들일 수 있다. 두 사례 모두 보면, 화면 인터페이스에 다소 제약이 있다. 일부러 그런 것이다. 돌아가고 있는 다른 애플리케이션이 없으면, 활성화중인 애플리케이션과 중요한 백그라운드 프로세스에 더 많은 자원을 할당할 수 있다. 위에 언급한 바와 마찬가지이다. 이뿐만이 아니다. 사용자 입장에서 인터페이스도 크게 단순해진다. 아이포드 기능도 주요 기능이기는 하지만, 아이폰은 휴대폰이기에 독특한 면이 있다. 하지만 프로세서 안에서 모든 애플리케이션이 자기 자리를 점유해버린다면, 남는 자리가 안 생길 것이다. 더군다나 아이폰 디스플레이는 그 많은 애플리케이션이 다 뜰 만큼 크지도 않다. 물론 그럴 수도 있겠지만 휴대용 기기에 적절하지 않은 인터페이스로 만들어 놓고 애플릿을 구겨 넣은 다른 곳보다 애플은 더 휴대용 기기를 더 잘 알고 있다. Rocket Launching. 시스템 정책을 따르기보다 애플리케이션 스스로가 결정을 내리도록 해야 한다는 의견이 들리기는 좋을지 몰라도, 실제로는 그리 좋지 못하다. 사실 애플의 정책은 사파리에 대한 써드파티 애플리케이션과 동일하다. 사용자가 Home 버튼을 눌렀을 때, 시스템은 현재 애플리케이션 데이터를 저장한 다음, 애플리케이션을 종료시키고, 애플리케이션 메뉴가 있는 Springboard를 내놓는다. 다음에 애플리케이션을 다시 활성화시키면, 종료됐을 때와 같은 상태로 시작한다. 이 활성화 시간이 너무나 빠르기에, 사용자 입장에서는 가상 메모리 상에서 돌아가는 애플리케이션을 다시 불러들이는 것이나, 종료시켰다가 필요해서 다시 활성화시키는 것이나 별 차이 없다고 느끼게 마련이다. 물론 기술적인 차이는 있다. 애플리케이션 종료가 배터리 수명 등, 자원 사용에는 더 효율적이다. 사용자들도 그것을 알아차릴 것이다. 이 때문에 애플은 SDK에서 이렇게 적고 있다. "한 번에 하나의 아이폰 애플리케이션을 돌릴 수 있으며, 써드-파티 애플리케이션은 백그라운드에서 돌리지 않는다. 사용자가 다른 애플리케이션으로 전환시키거나, 통화를 하고 이메일을 확인할 때, 해당 애플리케이션은 종료된다는 의미다." Invent, Suggest, Panic! 엔지니어링에 대해 잘 모르는 블로그들이 있다. 이름도 기가 막히게, BoyGenius Report라고 되어있는데, 이곳이 최근 써드파티 애플리케이션도 백그라운드에서 돌아가게 해달라며, 동등한 권리를 요구하는 청원에 나섰다. 종료시킬 필요 없이 애플리케이션간에 전환이 가능하게 해 달라는 것이다. 듣기에는 좋게 들린다. 하지만 제대로 알고 하는 얘기일까? 엡슈타인(Zach Epstein)은 아이폰에 "진정한 멀티태스킹이 없다"면서, 개발자인 발루섹(Robert Balousek)을 인용하였다. "AOL 인스턴트 메신저같은 애플리케이션을 돌린다면, 통화가 오거나 브라우징을 할 때마다, 나중에 다시 로그인해야 할 것이다. 못읽은 메시지는 영원히 못읽게 되고, 대화는 끝이다." 그러나 콕스(Christopher Cox)는 이런 지적을 했다. "이 글 저자는 크게 오버하고 있다. [...] 간섭이 있을 때, 애플리케이션이 정지해서, 현재의 데이터를 저장하게 된다. 다시 애플리케이션을 돌리면, 예전 메시지는 여전히 남아 있다. [...] AIM 서버도, 프로그램이 접속 끊기 신호를 보낸다거나, 특정 시간 이상 연결되어있지 않는 이상, 접속을 끊지 않는다. 즉, AIM 애플리케이션으로 되돌아가면, 메시지도 바로 나타난다는 의미다. 재접속 할 필요가 없다. 물론 AIM에 24시간 내내 접속해 있고 싶다면야, 단점이 될 것이다. 그 뿐이다. 그러나 대부분은 그럴 정도의 마음가짐을 갖고있지 않다." iPhone SDK Honeymoon Over - No Background Processes?! \| The Boy Genius Report What Would Happen If Apple Didn’t Know Any Better. 아이폰 SDK와 관련, 멀티태스킹이 안되리라는 주장이 헛것이라는 점을 알았다. 잘못된 정보다. 그런데 혹시, 애플이 제한을 가하지 않을 경우 아이폰이 어쩌면 더 나아질 가능성은 없을까? 추측할 일도 없다. 듣기 좋은 발린 단어 나열만 좋아하는 위원회 식의 엔지니어링을 통해, 만들어진 확실한 사례가 있기 때문이다. 마이크로소프트의 WinCE이다. 마이크로소프트는 WinCE를 유닉스와 같은 멀티태스킹 아키텍쳐로 간주하지만, 가상메모리 구조를 갖고 있기는 해도, 동시에 돌릴 수 있는 프로세스가 32개에 불과하다. 또한 각각의 프로세스가 갖는 가상 어드레스 공간 또한 32MB 뿐이다. 하지만 이 정도 사양도, 수 년 후에나 널리 쓰일 WinCE 6.0 사양이다. 그 때까지 멀티태스킹 WinCE라는 주장은 근본적으로 오류다. 물론 실상은 그보다 더 열악하다. 멀티태스킹 기능을 효율적으로 사용하지 못하게 막으면서도, WinCE는 써드파티의 백그라운드 프로세스만은 제한이 두지 않았다. 하지만 휴대용 기기에서 다중의 애플리케이션을 돌리는 것은 좋지 않다. 그 이유는 많다. 첫 번째 이유는 필자가 이미 명시한, 자원 사용의 문제다. 필자 대신, WinCE 옹호자인 헤러라(Chris De Herrera)의 말로 해 보겠다. "한 번에 여러 가지 애플리케이션을 돌려놓으면, 전면부 애플리케이션이 눈에 띄게 느려질 때가 있다. 이런 현상은 운영체제가 백그라운드 애플리케이션에게 자원을 써 주어야 하기 때문이다. 이 때 필자가 권장하는 바는, 소프트웨어의 재시동이다." Like kill on the road, Windows has failed to respond. Control! Alt! Delete! 그런데 또 하나의 이유가 있다. 같은 시간에 그 많은 걸 들여다 볼 화면이 없다는 것이다. 실질적인 화면 크기가 정해져 있기에, 데스크톱처럼 다중의 겹쳐지는 창과 제목막대, 창끼리 전환하는 기능을(Lisa가 최초로 보여준 기능이다) 들여다보는 것이 실질적으로 유용하지 않다. 하지만 마이크로소프트는 아랑곳하지 않고, 90년대 후반 이후, 맥 데스크톱 UI를 베낀 윈도를 그 조그마한 화면에 애써 구겨 넣었다. 그러니 팔릴리가 없다. WinCE 기기는 너무나 복잡해져서 그걸로 뭘 어떻게 할지 이해하기도 힘들어졌다. 게다가 충돌도 잦고, 배터리 수명도 절망적이었다. 아이폰은 너무나 간단해서, 일단 돌려본 다음, 별다른 훈련 없이 잘 쓸 수 있다. 그저 잘 돌아가는 아이폰이다. 애플이 Dock과 Finder 데스크톱을 아이폰에 구겨 넣으려 했다면, 아이폰 역시 절망적으로 안팔렸을 것이다. WinCE와 Windows Mobile의 처절한 실패사 Less is More; More with Less. 아이폰은 WinCE에 비해 더 나은 멀티태스킹 커널을 갖고 있다. 서류상에 나온 모든 기능을 다 하려들다가, 결국 아무 것도 잘 못해고 팔리지도 않는 기기를 만들어내는 마이크로소프트식 시스템이 아니다. 애플 엔지니어들은 아이폰 2.0 SDK에 제한을 가해서 사용자에게 더 유용한 애플리케이션을 덧붙이도록 할 것이다. 새 소프트웨어가 나오기도 전에, 기존 아이폰 판매량은 이미 미국 내에서 윈도 모바일 휴대폰의 판매량을 크게 넘어섰다. 아이폰의 스마트폰 시장 점유율은 27%이고, 모든 모바일 웹 트래픽의 71%를 차지하는 휴대폰이 아이폰이다. 마이크로소프트는 데스크톱 PC와 마찬가지다. 복잡함을 벗어나 WinCE를 애플 아이폰처럼 만들기는 불가능할 것이다. 이미 나와 있는 윈도 모바일 애플리케이션들이 모두 프로세서 백그라운드에서 돌아갈 권리를 갖고 있어서, 스마트폰을 느리고, 비효율적으로 만들기 때문이다. 제일 열광적인 윈도 옹호자들조차 끌지 못할 정도로 복잡해진 것이 윈도 모바일이다. 아이폰도 당연히 똑같은 문제를 겪어야 한다고 주장하는 꼴을 보니, 실용성과 단순성을 그들이 왜그리 이해못하는지 확실히 알 만하다. iPhone과 경쟁하기 - 소프트웨어 What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas. Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks! iPhone 2.0 SDK: The No Multitasking Myth __________________ FAQ