아이폰 개발 vs 안드로이드 개발

아이폰 개발은 내가 학습에서 가장 지진했던 분야다. Hello World를 완전히 이해하는데 무려 이틀이 걸렸고, ViewController 및 delegate 구조, nib와 outlet, 각종 UI 컴포넌트 사용법 등의 주요 개념을 파악하는데 2주 가량 걸렸다. 3주 째에 첫번째 아이폰 애플리케이션을 완성. HTML/CSS/JS로 만든다면 하루면 충분한 정도의 애플리케이션이었다. 한 달 가량이 지나서야 내 맘대로 개발할 수 있겠다는 생각이 들었다.

반면, 안드로이드는 Hello World는 할 것도 없었고 View, ViewGroup, Context, resource, Intent, Animation 등의 주요 개념을 학습하는데 1주가 안 걸렸다. 나흘 째에 이미 첫번째 업무로 주어진 애플리케이션의 기능을 대부분 완성하고 UI까지 다 입혔다. 아직 2주도 채 지나지 않았는데 다 파악했다는 느낌이 온다.

물론, 둘다 내 학습 스타일상, 책 펴놓고 공부하거나, 문서 열심히 읽고 시작하거나 하지는 않았고, 일단 개발 환경 실행시켜놓고 달려드는 식이었다. 하지만 아이폰 쪽은 문서를 안 읽고는 이해가 안가는 부분들이 너무 많아서 하면서 내내 문서를 뒤적거리면서 했던 반면, 안드로이드는 대부분 API 문서 찾아보는 것과 구글링으로 충분했다.

이쯤 되면 아이폰 개발을 안드로이드 개발보다 훨씬 후진 걸로 평가해야 정상일 텐데, 별로 그런 생각이 들지 않는다. 아무래도 직접 비교하기는 좀 그렇다. 사실 아이폰 개발은 다른 GUI 애플리케이션 개발과 구조가 완전히 다르다. 지금까지 GUI 애플리케이션 개발 경험을 보면 AWT에서 시작해서 비주얼 베이직, MFC, SWT, HTML/CSS/JavaScript, 플래시까지 많은 플랫폼을 써봤는데, 대부분 비슷비슷한 개념들을 쓰고 있고, 안드로이드도 그런 관례를 충실히 따르고 있다. 하지만 아이폰 UI 클래스들의 구조는 이런 것들과 완전히 다르다. 때문에, 나의 UI 개발 경험들이 안드로이드에는 거의 그대로 적용이 되었지만 아이폰에는 별 도움이 안되었다.

거기에 OS와 IDE에 익숙지 않은 것도 한 몫 한다. 코코아가 다른 GUI 툴킷과 다른 것처럼 맥도 리눅스, 윈도우와는 큰 차이가 있다. 특히 단축키 구조가 다른 것이 가장 고통스러웠다. 현실적으로 맥의 단축키 구조가 그 자체로 주는 장점이 거의 없는 이상, 윈도우의 관례를 따라가는 것이 좋지 않을까. 키보드도 다르게 생겼지만 UX적으로 아무런 장점도 주지 못하고 있다. 맥 애플리케이션의 멀티 윈도우 시스템도 고통스러운 점 중 하나. 파인더도 버그인지 기능을 몰라서 그런지 짜증스러운 점이 좀 있었다. Xcode는 나름의 장점이 있지만 편집 단축키가 한참 부족하고 리팩토링, 소스 스켈레톤 생성 등의 기능이 모자라다. 아뭏든, 이런 점들이 있기 때문에 익숙해지는 과정을 단순 평가하기는 힘들다. 물론, 안드로이드 개발이 기존의 경험을 잘 활용하게 해준다는 것은 그 자체로도 충분히 플러스 점수를 줄 수 있는 것이기는 하다.

그래서, 익숙해진 후의 관점을 비교한다면, 아이폰과 안드로이드는 장단점이 비슷하게 어우러지는 느낌이다. 완성도는 아이폰이 압도적으로 높다. 이미 코코아에서 탄탄하게 다져진 클래스들을 코코아 터치로 가져온 것이기 때문에 API의 완성도가 높고 되는 것 안되는 것이 명확하다. 하지만 안드로이드는 SWT나 스윙의 컴포넌트 상속 구조를 그대로 가져오지 않고 새로 만든 것이기 때문에 아직은 완성도가 낮다. 이벤트에 여러 개의 리스너를 지원하지도 않고 중첩 컴포넌트의 이벤트 전달도 좀 부실하다. View와 ViewGroup 등의 상속 구조, 난립하는 ViewGroup 클래스들 등이 UIView를 중심으로 하는 코코아 터치의 견고한 설계에 비하면 부족한 느낌이다.

인터페이스 디자이너의 완성도 차이는 그야말로 극과 극이다. 코코아 터치의 인터페이스 디자이너는 가히 UI 디자이너 중 최고라고 할 만한데 안드로이드의 레이아웃 에디터는 형편 없다. 스타일조차 에디터에서는 반영이 안되니 실행시켜봐야 한다. 여담이지만, 둘다 코드만으로 UI를 구성하는 것도 가능한데, 이건 정말 어리석은 일이다. 코드도 불필요하게 번잡해질 뿐더러, 직관성이 아주 떨어진다. UI를 구성할 때 눈으로 보면서 구성하는 것과, 실행해보고 고치고 하는 것의 생산성 차이는 엄청나다. 안드로이드에서는 레이아웃 에디터가 불편해서 xml 에디팅을 직접 하기는 하겠지만 그래도 자바 코드로 하는 것보다는 훨씬 낫다. 비유를 하자면, 웹 프로그래밍 하면서 HTML을 직접 쓰는 것과, 자바스크립트의 DOM으로 HTML을 그리는 것의 차이다. 많은 숙련된 자바스크립트 개발자들이 DOM을 쓰느니 차라리 innerHTML을 쓰라고 하는 것도 이게 더 직관적이기 때문이다. 심지어 플래시 개발할 때도 코드로 뷰를 그리는 개발자를 본 적이 있는데, 이래서는 안된다. 이 문제가 더 심각한 것은, 이렇게 코드로 뷰를 그리는 것을 선호하는 개발자들이 대개 뷰와 컨트롤러를 분리하지 않는다는 것이다. 그래서 뷰를 그리는 코드와 로직 코드들이 얽혀 있는 코드를 만들어내곤 한다. 그림은 툴로 그리고, 머리는 로직을 짜는데 쓰는 게 좋다.

다시 돌아와서, 에뮬레이터도 아이폰은 금방 뜨는데 안드로이드는 이미 악명이 높다. 안드로이드 에뮬레이터의 성능에 관한 최고의 조언은, 일단 띄워 놓으면 절대 닫지 말라는 것. 에뮬레이터 뜨고 나서의 실행 시간도 느리다.

하지만 안드로이드의 API들은 익숙하다. 설계는 조금 다르지만 기본 컨셉은 기존의 GUI 툴킷과 같기 때문에 경험을 쉽게 재활용할 수 있다. Objective C와 Java의 차이도 크다. 둘다 문법이 verbose한 편이기는 하나, Java가 그래도 조금 더 간결하다. 무엇보다 Objective C의 verbosity는 Xcode가 썩 잘 커버해주지 못한다. 캐스팅이라든지, protocol implement, property 등을 보면 만드는 과정의 중간 단계들은 자동 완성 지원이 되는데, 전체 과정이 자동화되지는 않는다. 반면 이클립스는 중간 단계들은 물론이고 전체 단계도 스무스하게 잘 완성시켜 준다. 사실 자바는 이클립스든 IDEA든, IDE가 워낙 좋아서 문법의 verbosity로 인한 context 끊김이 적다. 뭔 소리냐면, 예를 들어, 퀵 소트 알고리즘을 직접 구현한다고 할 때, 알고리즘을 생각하다가 리스트 사용법을 생각하느라고 알고리즘 생각이 끊기는 일이 없다는 것이다. 하지만 Objective C는 로직을 생각하다가 빠뜨린 괄호를 붙이러 맨 앞으로 간다든지, 프로퍼티를 바로 연결하고 싶은데 IBOutlet property로 선언하느라 .h와 .m을 왔다갔다 하는 등, 문법의 verbosity로 인한 끊김이 크다. 거기에 가비지 컬렉션이 안되는 건 정말 불편하다.

또 다른 중요한 차이는, 아이폰이 훨씬 이쁘다는 것이다. 계속 쳐다보고 싶은 생각이 든다. 하지만 안드로이드의 에뮬레이터는, 아니 어떻게 그렇게 못 생기게 만들 수가 있는지. 이건 진짜 내가 디자인해도 저거보다 잘하겠다. 기본 위젯들의 생김새도 차이가 크다.

물론, 아이폰이 안드로이드보다 더 견고한 아키텍처와 깔끔한 API를 가질 수 있는데는 아이폰이 더 단순하다는 것도 있다. 다양한 화면 크기와 입력 장치를 생각해야 하는 안드로이드와 달리 아이폰은 그런 고민이 필요 없다. 키 이벤트도 필요 없고 포커스 개념도 first responder 정도로 충분하다. 가변폭도 생각할 필요가 거의 없고, 위젯도 없고 멀티 윈도우도 없고 intent 같은 것도 없다. 물론 단순함이 주는 장점도 크지만 그것이 아이폰을 장난감에 머무르게 하는지도 모른다. 위젯이 안된다는 것은 정말 비즈니스 스마트폰으로는 실격이다.

어느 쪽이 개발이 즐거운지는 좀 애매하다. 일단 아무리 UI 개발이라도 개발의 대부분은 코드와 함께하는데, 코딩하기에는 역시 이클립스가 Xcode를 압도한다. 다양한 편집 기능과 단축키, 리팩토링, 프로젝트 관리, 소스 저장소 등등, 거의 모든 기능에 차이를 보인다. 딱 하나 좋은 것은 타이핑할 때 자동완성이 이클립스보다 좀더 기민하다는 것. 하지만 이것도 IDEA나 RubyMine 앞에서는 무릎을 꿇어야 한다. IDEA나 RubyMine에 90점을 준다면 이클립스는 80점, Xcode는 50점 정도다. 비주얼 스튜디오 2008은 60점 정도? RubyMine을 써보면서 꼭 이놈은 내가 뭘 하고 싶은지를 알고 있는 것 같다는 느낌을 많이 받았는데, Xcode는 그냥 내가 뭘 타이핑하고 싶은지를 아는 정도다. 그러다보니 코딩의 재미는 안드로이드 쪽이 더 크다. 반면, 아이폰은 에뮬레이터가 좋고 UI가 미려하고, UI 그리기가 수월하다보니 만들고 실행해보고 하는 과정은 아이폰이 훨씬 재미있다.

어쨋든 전부 플래시 개발이랑 비교하면 형편 없다. 개발 도구도 이클립스에 FDT를 쓸 수 있기 때문에 좋고, 플래시 툴 자체도 코코아의 인터페이스 디자이너처럼 쉽지는 않지만 편리함에서는 비슷하다. 무엇보다 큰 차이는 아키텍처다. UI 개발에서 가장 중요한 것은 View 상의 컴포넌트를 어떻게 조작하고, 이벤트를 어떻게 연결하는가이다. 코코아 터치에서는 코드로 일단 써놓고 인터페이스 디자이너에서 연결해야 해서 좀 번거로운 편이다. 반대로 인터페이스 디자이너 쪽에서 뭔가 지정하고 자동으로 코드를 생성하게 했다면 훨씬 나았을 텐데. 안드로이드는 리소스 클래스를 이용하는 방식이라 글로벌한 ID를 지정해야 하는데, 이게 캐스팅 문제도 좀 있고, 간혹 뷰를 넘겨야 하는지 ID를 넘겨야 하는지 혼동되는 점도 있는 등, 약간 불편하다. 반면 플래시는 뷰를 디자인하면서 속성 이름만 지정해주면 그대로 코드에서 프로퍼티로 쓸 수 있다.

이벤트 지정 방식도 IBAction을 선언하고 연결해줘야 하는 코코아 터치는 역시 순서가 바뀐 느낌이라 불편하다. 안드로이드는 예의 자바의 익명 클래스를 활용한 이벤트 리스너 등록이라 문법이 번잡하다. 플래시는 클로저가 가능하니 당연히 훨씬 좋다. 하지만 이벤트 전달 방식은 HTML 쪽이 더 좋은 듯.

UI 재활용 측면에서도 재활용하려면 별도의 nib로 분리하고 컨트롤러를 붙이거나, View에서 로드하거나 해야 하는 코코아 터치는 많이 번거롭다. 안드로이드도 layout xml 파일을 분리해야 하므로 불편. 사실 큰 부분을 재활용할 때는 분리하는 게 더 낫지만 테이블의 셀처럼 작은 부분을 컴포넌트화하고 싶을 때도 그 때마다 파일을 분리해야 되면 번거롭다. 반면 플래시는 심볼로 만들어주기만 하면 손쉽게 재활용 가능하다.

애니메이션은 뭐 비교 불허. 비디오, 오디오 등의 미디어를 다루는 것도 월등이 편리하다.

개발 생산성을 비교한다면, 똑같은 애플리케이션을 만들 때, 플래시로 일주일이 걸리는 일이라면, 안드로이드는 1개월, 아이폰은 2개월 가량 걸리지 않을까. 잡스는 고집 그만 부리고 그냥 플래시 탑재하자. 플래시는 이미 아이폰보다 오래 전부터 핸드폰에서 쓰였고, 성능에 아무 문제 없다.

블로그 / 소프트웨어 개발