지난 시간에 나는 모바일 환경에 대해 간단하게 이야기하고 자원의 제약으로 인한 트레이드-오프 관계를 설명했다. 애플과 구글은 이 관계에서 서로 다른 전략을 취하고 있으며, 그렇기 때문에 각 플랫폼이 갖는 장점과 단점이 분명하게 갈린다.


오늘은 아이폰과 안드로이드폰의 어플리케이션 모델에 대해 이야기하려고 한다. 어플리케이션은 스마트폰의 기능을 활용하여 사용자에게 유용한 서비스를 제공하는 응용 프로그램이며, 언제든지 새로운 어플리케이션을 내려받아 설치하여 바로 사용할 수 있다는 것이 아이폰과 안드로이드폰의 대표적인 특징이다.


개발 환경의 차이

애플과 구글 모두 개발킷(SDK)을 무료로 공개하여 누구나 다운로드하고 사용할 수 있다.

아이폰은 XCode로, 안드로이드폰은 Eclipse로 개발된다.


아이폰 SDK는 맥 OS에서만 동작한다. 아이폰의 기반 라이브러리가 맥 OS의 기반 라이브러리와 상당히 유사한데 이런 이유로 인해 맥 OS 전용 SDK가 된 것이 아닌가 추측해본다. 한편 안드로이드 SDK는 표준 자바 환경에서 동작하기 때문에 윈도우/리눅스/맥 등 대부분의 운영체제에서 동작한다. 개발자 접근성 관점에서는 안드로이드 SDK가 압승이다.


멀티 태스킹 = 멀티 프로세싱 + 멀티 스레딩

많은 사람들이 아이폰은 멀티 테스킹이 안 된다고들 하는데, 이를 좀 더 구체적으로 살펴볼 필요가 있다. 멀티 태스킹은 멀티 프로세싱과 멀티 스레딩으로 구분해서 생각해야 하기 때문이다.

여기서 프로세스는 각각의 어플리케이션을 의미한다. 그리고 '멀티' 라는 접두사가 붙으면 일반적으로 '동시에-'라고 해석한다. 그러나 아이폰과 안드로이드폰 모두 둘 이상의 어플리케이션을 동시에 실행하지는 않는다.

한편 스레드는 어플리케이션 내부에서 생성한 독립적인 실행 유닛이다. 하나 이상의 스레드를 생성함으로써 어플리케이션은 다수의 작업을 동시에 처리할 수 있다. 아이폰과 안드로이드폰은 모두 멀티 스레드를 지원하지만 그것의 생명 주기는 차이가 있다.


멀티 프로세싱? 아니요, 어플리케이션 조합입니다!

아이폰과 안드로이드폰 모두 둘 이상의 어플리케이션을 동시에 실행하는 것은 불가능하다. 그러나 이는 기기적 결함이나 제약이 아닌 애플과 구글의 전략적 특성이다. 조그마한 화면 내에서 둘 이상의 어플리케이션을 동시에 실행하는 것은 비효율적이며, 제한된 시스템 자원 때문에 성능이 크게 저하될 수 있기 때문이다.

안드로이드는 이 제약을 창의적으로 피하고 있다. 안드로이드 어플리케이션은 그것을 구성하는 각각의 기능이 독립적인 유닛(Activity)로 구성되는데 이 때 각 유닛은 다른 어플리케이션에 의해 호출될 수 있다. 안드로이드의 이러한 특징은 우리가 알고 있는 멀티 프로세싱과는 다소 차이가 있다. 이는 멀티 프로세싱이 아니라 어플리케이션 조합이라고 불러야 더 정확하다.

안드로이드에서 실행 중인 어플리케이션이 다른 어플리케이션의 기능을 호출하면 호출한 어플리케이션은 대기 상태가 된다. 사용자의 어떠한 이벤트에도 반응할 수 없는, 말 그대로 대기 상태가 되어 호출한 기능이 완료될 때까지 실행을 멈춘다. 그리고 호출한 기능이 완료되면 수행을 이어서 계속한다.

이러한 특징은 다양하게 응용될 수 있다. 편집 기능이 없는 사진 보기 어플리케이션이 그럼에도 불구하고 편집 버튼을 제공하는 경우를 생각해보자. 사용자가 편집 버튼을 클릭하면 안드로이드 OS가 자동으로 설치된 어플리케이션 중에서 사진 편집 어플리케이션을 찾아 그것을 실행시킨다. 사용자가 편집을 완료하면 이전 상태로 돌아온다. 또 다른 예로 PDF 보기 어플리케이션을 생각해보자. 사용자가 영문 PDF 문서를 보다가 특정 단어의 뜻을 검색하기 위해 단어 사전 버튼을 클릭하면 안드로이드는 설치된 사전 어플리케이션을 찾아서 실행시켜줄 것이다. 그리고 사전을 종료하면 다시 PDF 보기 상태로 돌아온다.

어플리케이션 조합의 장점은 각각의 어플리케이션이 자신의 주요 기능에 집중할 수 있고, 다양한 조합을 통해 기능을 확장할 수 있으며, 사용자에게 특화된 어플리케이션 구성이 가능하다는 것이다. 이것은 데스크탑 운영체제도 지원하지 않는 정말 획기적인 기능이다. 다양한 공개 서비스를 제공하고 매시업을 권장하는 구글의 탁월한 전략과 기술이라고 볼 수 있다.

그러나 어플리케이션 조합을 위해서는 몇 가지 제약이 따른다. 우선 어플리케이션 설치 시 그것이 제공하는 단위 기능들을 명시적으로 안드로이드에 등록해야 하며, 이것은 전적으로 개발자 책임이다. 만약 아무 것도 등록하지 않으면 이 어플리케이션의 어떠한 기능도 다른 어플리케이션에 의해 호출될 수 없다. 또한 어플리케이션이 다른 어플리케이션의 단위 기능을 호출하기 위해서는 그 기능이 무엇인지 명확하게 알고 있어야 한다. 만약 어떤 어플리케이션이 설치되면서 단위 기능 몇 개를 안드로이드 OS에 등록했는데 무엇을 등록했는지 외부 개발자에게 공개하지 않는다면, 다른 어떠한 어플리케이션도 그 기능을 호출할 수 없다.

안타깝게도 이렇게 훌륭한 어플리케이션 조합이 실제로는 거의 일어나지 않고 있다. 대부분의 개발자는 자신이 구현한 기능이 다른 어플리케이션에 의해 호출되기를 원치 않거나, 아예 조합 자체를 고려하지 않기 때문이다. 또한 이로 인해 보안에 취약해질 수 있다. 악의적인 코드가 실행될 수 있는 여지가 충분하기 때문이다.

한편 아이폰은 하나의 어플리케이션에서 다른 어플리케이션의 기능을 호출하지 못하므로 실행 중인 하나를 종료하고 다른 하나를 찾아 실행시켜야만 한다. 이 때 적절한 어플리케이션을 찾는 과정은 매우 지루하며, 이전 어플리케이션에서의 어떤 선택이나 데이터를 다른 어플리케이션으로 전달할 수 없기 때문에 어플리케이션간 전환이 매끄럽지 못하다. 다시 이전 상태로 돌아오려면 어플리케이션을 종료하고 이전의 것을 찾아 다시 실행시켜야 한다. 이 때 종료 직전의 상태로 복구가 가능하지만 그것이 다시 시작하기 위함인지, 새로 시작하기 위함인지는 알 수가 없다.


멀티 스레드는 OK, 하지만 생명 주기가 다르다.

두 플랫폼 모두 스레드를 생성시킬 수 있다. 스레드는 자신만의 제어를 갖는 실행 코드이며 어플리케이션 내에서 생성한다. 일반적으로 하나의 어플리케이션은 하나 이상의 스레드를 생성하며, 스레드를 통해 무대 뒤편에서 보이지 않는 수 많은 작업들을 동시에 수행한다. (아이폰의 애니메이션 효과도 그 중 하나이다)

아이폰의 경우 실행 중인 어플리케이션을 종료시키면 그것이 생성한 모든 스레드 역시 종료된다. 하지만 안드로이드폰의 경우 어플리케이션이 종료되더라도 그 수행을 지속시킬 수 있는데 이것을 안드로이드에서는 스레드와 구분하여 서비스(Service)라고 부른다.

서비스는 어플리케이션이 종료되더라도 혼자 남아서 묵묵히 자기 일을 수행한다. 메신저 같은 어플리케이션을 생각해보자. 만약 서비스가 없었다면 메신저 어플리케이션을 종료하는 순간 로그아웃 상태가 될 것이다. 그러나 서비스 덕분에 메신저를 종료하더라도 로그인 상태나 자리비움 상태를 유지할 수 있고 다른 사람이 메시지를 보내면 그 즉시 화면에 표시할 수 있다.

그러나 백그라운드 서비스는 우리도 모르는 사이에 CPU와 메모리, 배터리를 소모한다. 많은 백그라운드 서비스가 동작하고 있으면 어플리케이션의 실행 속도가 현저히 떨어지거나 메모리가 부족하여 비정상적으로 종료될 수 있다.

백그라운드 서비스 없이 오직 하나의 어플리케이션만 동작한다면 그 어플리케이션은 항상 최고의 기기 성능을 활용할 수 있다. 게임과 같은 어플리케이션은 기기 성능에 크게 영향을 받는다. 아이폰은 오직 하나의 어플리케이션만 실행 가능하고, 기기 구성이 항상 동일하다는 점에서 콘솔 게임기와 유사하다. 그리고 이러한 유사성으로 인해 많은 게임 개발사가 아이폰 어플리케이션 개발에 참여하고 있다.

초기에 아이폰은 백그라운드 서비스를 지원하지 않다가 3.0 버전부터 푸시 알림(Push Notification)이라는 이름으로 유사 기능을 지원하고 있다. 백그라운드 서비스의 부재는 얻는 것보다 잃는 것이 더 많았기 때문이리라. 그러나 안정적인 성능 유지는 아이폰에서 굉장히 중요한 요소가 되었고, 따라서 다소 제약적인 모습으로 제공하게 된 것이 아닐까 생각한다.


결론

어플리케이션 모델 관점에서 애플의 아이폰은 상당히 보수적인 전략을 취했다. 어플리케이션간의 조합이 불가능하며 백그라운드 서비스에 제약을 가했다. 그러나 이로 인해 각각의 어플리케이션은 최고의 기기 성능을 활용할 수 있으며, 강력한 보안을 유지할 수 있다.

반면 구글의 안드로이드는 상당히 개방적인 전략을 취했다. 어플리케이션간의 조합은 상당히 진보된 기술로써 다양한 어플리케이션의 조합을 통해 새로운 부가 서비스를 창출할 수 있는 환경을 제공한다. 또한 백그라운드 서비스는 어플리케이션이 종료되더라도 그 기능을 지속하여 사용자 편의를 극대화한다. 그러나 실제로는 어플리케이션 조합이 거의 일어나지 않고 있으며, 각각의 어플리케이션은 최고의 기기 성능을 보장받을 수 없고 보안에 취약하다는 단점을 갖는다.

트레이드-오프의 기로에서 애플과 구글의 전략적 선택은 분명하게 갈렸지만, 아이폰의 푸시 알림 기능이 추가된 것을 통해 알 수 있듯이 때때로 그 전략은 변경되기도 한다.

다음 시간에는 앱스토어에 대해 이야기해보려 한다.



  1. highwind 2010.04.06 19:06 ADDRESS | MODIFY/DELETE | REPLY

    애플이 개발자들을 자기네 스토어로 끌어들이는 부분에서
    상당히 어지러운 부분중에 하나이죠....

    모두를 자기네 편으로 끌어들이고 싶어하는걸까요?

    비교적 빠른 시작을 보였으나 의미없는 병목을 만들어버린건
    참 마이너스네요. 애플이 저것마저도 Java를 택했더라면....

    아마 지금 이야기가 많이 다를텐데 말입니다.

    그래도 워낙 Xcode에서 생성된 엔진이 뛰어나다고 많은 사람들이
    그러니까 그것또한 무시 못하겠네요....

    ^-^늘 좋은 포스팅 잘보고 갑니다.

    • semix2 2010.04.07 02:14 ADDRESS | MODIFY/DELETE

      병목으로 인해 더디게 반응하는 것은 어쩔 수 없지만, 그렇기 때문에 일관성을 유지할 수 있다고 생각합니다. 그리고 이러한 일관성으로 인해 개발자가 헤매지 않고 정진할 수 있는 거지요. 이 역시도 트레이드-오프라고 생각합니다. ^^

      다음 주제가 앱스토어인데요, 이 문제를 좀 더 자세히 살펴볼 예정입니다. 기대해주세요~

      아이폰 OS가 맥 OS에 기반을 두고 있기 떄문에 자바라는 선택지 자체가 없었던 것 같습니다. 하지만 말씀대로 워낙 잘 만들어놔서;; ^^ 저도 이제 막 공부하고 있지만 정말 혀를 내두를 정도로 잘 만들어져있더라구요. ㅎㅎ

      늘 관심가져주셔서 감사합니다. highwind 님의 댓글 덕분에 부실한 글이 점점 알차게 변해가네요- 히힛

CATEGORIES