멀티 태스킹 지원시 주의점

XCode 3.2.3에서 컴파일된 앱은 iOS 4.0에서 별다른 조치를 하지 않아도, 기본적인 멀티 태스킹 능력을 갖게되는 데 몇 가지 주의 할 점이 있다. 개인적으로 멀티 태스킹이란 용어를 사용하는 것이 조금 망설여진다. 기술적으로 그것은 전혀 멀티 태스킹이 아니기 때문이다. 

일반적으로 멀티 태스킹이란 시분할 시스템을 지칭하는 용어로, CPU를 짧은 시간 단위로 나누어 여러 프로그램에게 차례대로 반복 할당함으로써, 마치 여러 프로그램이 동시에 수행되는 듯한 착각을 일으키는 기술이다. CPU는 충분히 빠르고, 대부분의 프로그램은 연속적으로 CPU를 필요로하지 않기 때문에 매우 효율적이기도 하다.

아이폰4의 멀티 태스킹은 이와는 좀 다르다. iOS 4.0은 홈 버튼을 눌러 앱을 빠져나와도, 해당 프로그램의 메모리를 소거하지 않고, 일종의 집행 유예상태로 남겨둔다. 메모리는 소거하지 않지만, 그렇다고 CPU를 스케쥴해주는 것도 아니므로, 실질적으로 앱은 전혀 실행되지 않는 상태이다. 즉 앱의 종료상태와 백그라운드 상태가 딱히 구분되지 않는다. 일단 종료버튼이 눌리면 유예상태가 되고, 언제 소거될지는 알 수 없다. 다른 앱등에 의해 메모리가 부족한 경우, 가장 과거의 앱 부터 메모리에서 소거되는 것 같다.(이 소거 규칙은 확실하지 않다, 애플은 이러한 내용을 전혀 공개하지 않았다) 기본 메모리가 부족한 3G는 멀티태스킹을 아예 지원하지 않으며, 3GS의 경우엔 게임 한 번정도 실행하면, 이전 태스크는 모두 잃어버린다.

이러한 동작원리는 앱은 자신이 종료되는 시점에, 어떤 형태로 나중에 다시 실행될지 예측할 수 없게 만든다. 다시 실행될 때 메모리에 앱이 남아있다면, 깨우기가 진행되고, 아니면 다시 실행된다. 이런 이유로 만약  앱이 시간복잡도, 외부 자원과 연관을 갖는 경우, 앱은 매우 불안정하게 동작하게 될 수 밖에 없다.

개발자는 이러한 상황을 잘 고려해야 하며, 앱의 특징별로 몇 가지 유형을 정리해 보았다.

첫째. 가장 단순한 유형으로, 응용프로그램이 갖는 컨텐츠가 시간 및 외부 네트워크와 연관되지 않은 경우로, 이 경우엔 대체로 문제가 발생하지 않는다. 대게의 유틸리티성 앱, 악기등과 같이 모든 기능이 앱 내부에 있는 앱들이 이 유형에 속한다. 단 이경우에도 내부 상태를 적절한 시점에 보존해 두지 않으면, 앱이 메모리에서 소거된 뒤 다시 실행될 때, 이전 작업을 모두 잃어버리게 된다.

두번 째로 시간과 연관된 콘텐츠가 있다고 하더라도, 앱 내에서 고유의 시간진행 모델을 갖는 경우 역시, 앱이 백그라운드로 들어가는 순간 시간이 멈췄다가 다시 가게 되므로 그다지 문제 될 것이 없다. 타이밍 기반의 게임(거의 대부분 아케이드, 퍼즐 게임)등이 이에 속한다. 이들 역시 종료되는 시점에는 깨어날 수 있을지 알 방법이 없으므로, 중요한 정보는 즉시 보존해둬야 한다.

세번째로 실제 시간과 연관을 가지는 앱의 경우, 앱이 다시 깨어났을 때, 그동안 흐른 시간에 대해 델타 처리를 해야 한다. 만약 이를 처리하는 시간이 충분히 짧거나 간단하지 않다면, 다시 시작하는 것만 못한 결과가 나타날 수도 있다. 예를 들어 Coin Dozer는 iOS4.0을 지원하면서 백그라운드 태스킹에 들어갔다가 다시 깨어난 경우, 자신이 종료(완전 소거)되었다가 다시 실행된 것인지, 백그라운드에서 돌아온 것인지를 제대로 인지하지 못해, 시간 경과 보상을 주지 않는 경우가 종종있으며, 메모리에서 소거된 경우 진행상태를 완전히 잃어버린다. 이는 근본적으로 아이폰 앱이 엄밀히 말해 *종료*상태와 *백그라운드* 상태가 딱히 구분되지 않기 때문이다.

넷째. 네트워크 자원을 사용하는 경우, 해당 자원은 시간이 흐른 뒤 이미 무효상태를 갖게 되었을 수 있으며, 이것은 매우 골치아픈 문제가 될 수도 있다. 따라서 깨어날 때마다, 정보 유효성 검사를 해야 하는데, 외부 자원을 억세스하고 검증하는데는 많은 시간이 걸린다. 예를 들어 로그인이 필요한 서비스의 경우, 앱이 백그라운드에서 깨어났을 때, 이미 서버쪽에서 그 세션은 만료되어 파기 되었을 수 있다. 사용자는 작성중이던 블로그나 코멘트를 덧 없이 잃어버릴 수 있으며, 개발자는 자기자신이 가진 서버에 대한 클라이언트가 아닌 경우 이런 상황을 디버깅하기가 매우 힘들다. 트위터, 메신저등과 같이 정보가 *추가*되기만 하는 경우는 별로 문제가 되지 않지만, 동적으로 정보가 편집되거나, 삭제될 수 있는 자원인 경우에, 멀티태스킹은 지원하지 않는 편이 나을 수도 있다. 이 경우 컴파일만해도 기본적인 멀티태스킹이 자동으로 되게 되어버리므로, 주의해야 한다.

다섯. 외부 자원 및 실제 시간이 컨텐츠와 연관을 갖는 경우에는 매우 심각한 다양한 문제가 발생할 수 있다. 위룰, 갓 핑거등과 같은 실시간 SNS게임이 이에 속한다. 만약 서비스 클라이언트가 한대가 아닌경우 문제는 더욱 심각해질 수 있다. 기본적으로 SNS, MMORPG, 이 메일, 캘린더 등과 같은 애플케이션은 그 서비스에 영향을 미칠 수 있는 경로가 매우 방대하다. 웹, 또는 다른 유저등이 그 원인이 된다. 예를 들어, 아이폰에서 이메일을 읽는 도중, 백그라운드로 전환하고 PC나 맥에서 그 메일을 지워 버리면, 간단하게 데이터 해저드가 성립된다. 별로 복잡하지 않은 간단한 시나리오 테스트만으로도 아이폰 빌트인 앱 조차 제대로 대응하지 못하고 죽어나갔다.

결론.

iOS 4.0은 누군가의 말 마따나, 애플의 비스타가 될 가능성도 농후하다. 배터리, 성능, 경험 세마리 토끼를 다 잡는다는 전략은 매우 우아하고 칭찬 해 줄 만한 일이지만, 일반 사용자에게 이것의 동작방식은 매우 이상해 보일게 분명하다. 백그라운드에서 실제 동작하지 않는데, 동작한다고 착각함으로써 생기는 부분이라던지, 왜 어떤 경우에는 같은 방법으로 종료했는데도, 다시 안 깨워지는지등에 대한 부분은 전문 개발자가 아니고서는 쉽사리 이해하기 힘든 부분이다. 개인적으로 이 모든 나쁜 경험은 단지 개발자의 탓으로 매도될 것이 거의 분명하다고 생각하기 때문에, 조금 분통이 나기도 한다. 애플이 성공한 것은 아이폰이 훌륭해서가 아니라 SDK 공개(사실은 그 이전부터)로 수많은 개발자가 *참여*한 덕분이라는 사실을 잊어서는 안 될 것이다.