플래시에는 e4x가 있습니다. 그래서 웬만한 데이터는 전부 XML로 만들어서 처리해 버립니다. 플래시에서 XML을 주로 사용하는 이유는 e4x라는 강력한 도구 때문이며, XML 자체의 특징이나 매력과는 큰 상관이 없습니다.

그러면, 코코아 터치에서는 무엇으로 데이터를 다루나요?

결론부터 말씀드리자면 Property List입니다. 이것은 일종의 규격화된 XML로, 작은 데이터를 다루기에 알맞습니다. 데이터셋 크기가 커지면 다소 비효율적이라 예상합니다. 이 프로퍼티 리스트는 기본 컬렉션 개체인 NSArray와 NSDictionary에서 직접 지원하며, 정수, 문자열 등의 기본적인 프리미티브 형식 몇 가지를 지원합니다. 또한 계층적 개체로 구조화된 데이터도 저장할 수 있습니다. 설정 파일이나 그 외 간단한 용도로 제격이죠. XML로 저장되지만, 기능이나 사용 형태는 JSON에 가깝습니다. 예를 들어 전체 데이터셋을 로드하기 위해서 다음 중 하나의 메서드를 사용하면 됩니다.

[NSArray arrayWithContentsOfFile:]
[NSDictionary dictionaryWithContentsOfFile:]

사실 정수, 실수, 문자열과 단순 목록, 연관 목록을 지원하면 모든 종류의 데이터를 다 담을 수 있습니다. 데이터베이스란 것도 사실 별 거 없죠. 하지만 프로퍼티 리스트의 존재를 알기까지는 생각보다 힘든 과정이 필요했습니다.

혼란

처음에 필요했던 것은 간단한 로컬 데이터를 목록으로 만들어 읽는 것이었습니다. 하지만 이런 일이 자주 발생될 것이 너무 뻔하게 예상되므로 기왕이면 플래시의 e4x처럼 프레임워크가 자연스럽게 지원하는 가장 간편한 방식을 알아내고 싶었습니다. 또한, 웹상에 존재하는 많은 종류의 공개 API는 대부분 XML을 기본 데이터 형식으로 사용합니다. 그리고, 이러한 데이터는 프로그래머만 다루는 것이 아니며 때때로 기획자나 디자이너도 다룰 수 있게 해야 합니다. 이런 것을 종합하면, XML외에는 대안이 없습니다. XML도 어려워하는 사람이 많지만, 그나마 가장 널리 퍼져 있는 것이 XML이기 때문입니다. 타 직업군의 사람과의 호환성 확보에 가장 좋다고 할 수 있죠. 결국 제가 원한 프레임워크는 언어 내에서 간단히 다를 수 있으면서도 XML로 읽고 쓸 수 있는 프레임워크였죠. 일단 XML 지원은 필수였습니다.

코어 데이터

처음에 접한 것은 코어 데이터였습니다. 코어 데이터는 대량의 데이터셋을 위해 최적화된 데이터 엑세스 프레임워크입니다. SQLite DB나 바이너리 또는 XML을 백엔드 저장소로 사용할 수 있습니다. 개별 개체의 데이터 변화를 모두 추적하고, 컨트롤에 자동 바인딩도 지원합니다. 네트워크와는 크게 상관없어 보이지만, 어딘가 그런 기능이 있을지도 모릅니다. 애플에서 권장하는 데이터 엑세스 방식이죠. 일견 기능은 매우 강력해 보이지만, 헛점이 있습니다. 너무 어렵다는 것입니다.

코어 데이터를 다루기 위해서는 기본적으로 코코아 바인딩을 마스터해야 합니다. 그런데 이 코코아 바인딩이란 놈이 만만치 않죠. 그 외에도 몇 가지의 복잡한 개념을 이해해야 합니다. 사실 이 기술들의 컨셉은 별 거 없지만, 애플 엔지니어들에게 딱 맞춰진 개념 구현을 익혀야 한다는게 정말 어렵습니다. 그리고 이런 종류의 데이터 바인딩 프레임워크가 다 그렇듯, 유연성이 떨어져 실제 사용에는 제약이 많습니다. 바인딩은 정말 폼 기반 어플리케이션같은 특정 목적의 응용이 아니면 적합하지 않습니다.

그러면 코어 데이터에서 남는 것은 대량의 데이터셋을 효과적으로 다룰 수 있는 아키텍쳐 뿐입니다. 하지만 이것은 데이터가 로컬에 있을 때에나 해당하는 것이며, 데이터가 원격 서버에 있다면 데이터셋 스쿠핑은 서버에서 해결하므로 사실 큰 의미가 없습니다.

XML지원도 사실 어떤 식으로 되는지 모릅니다. 샘플을 슬쩍 봤는데, 개별 개체를 인코딩하고 계층 구조는 개체 아이디로 레퍼런싱하는 방식을 사용하는 듯 했습니다. 이런건 프로그래머도 못봅니다. 오로지 기계만 읽을 수 있습니다.

결국 뭔가 강력한 기능을 제공한다는 것은 알겠지만, 아직 저는 정말로 필요한 때가 아닌 것 같습니다.

아카이브

아카이브는 개체를 바이너리로 저장하는 기능입니다. 코어 데이터의 주 구성 요소 기술 중 하나이죠. 이건 말 그대로 바이너리입니다. 이걸로 커스텀 데이터셋을 간편히 만든다는 것 자체가 불가능하고, XML과도 관련이 없습니다. 그래서 패스했습니다.

JSON

애플 푸시 서비스의 샘플이 JSON으로 되어 있어서 JSON에 관심을 가져 보았으나, 제조사인 애플에서 제공하는 기반 프레임워크가 없는데다, 사용되는 분야가 너무 한정적이라 그만두었습니다. 그리고 웹에서 필수적으로 발생하는 인코딩과 이스케이프 문제에 대한 정의가 너무 허술한 듯 했습니다. 특히 언어에 종속된 문법으로 인해 슬래시를 모두 이스케이프해야 한다는 것은 치명적입니다.

간략한 데이터셋은 프로그래머만 사용하는 것이 아닙니다. 때로는 디자이너나 기획자에게 전달하고, 그들에게 내용을 받아와야 하는 때도 있습니다. 자기 스스로 데이터를 편집하기를 윈하지만, 어려운 것은 다루지 못하는 사람들이 많죠. 여기에 http://로 시작하는 링크조차 모두 이스케이프해야 하는 JSON은 적용하기 힘듭니다.

NSXMLParser

코코아 터치에서 정말깜짝 놀란 것이 XML DOM 파서가 없다는 것이었습니다. 대신 이벤트 드리븐 파서를 제공하는데, 말이 파서지 사실 쓸게 못됩니다. 스트림 프로세서를 만드는 것 외에는 쓸 수 있는 곳이 거의 없고, 결국엔 이 파서를 이용해 작은 전용 DOM 을 만드는 식으로 일이 진행됩니다. 처음에는 forwardInvocation 기능을 이용해 e4x처럼 동적으로 개별 노드에 엑세스하는 DOM 개체를 만들려 했습니다. 그런데 Objective-C 컴파일러는 선언되지 않은 셀렉터에 대해 경고를 내보냅니다. 경고를 무시하는 것은 잠재적인 위험을 무시하는 것이므로, 결국 이 방식을 쓰지 못하게 되었습니다.

이 작은 DOM은 매우 작은 커스텀 XML 메시지를 만들기에 적합하므로 XML API를 사용할 때 유용하리라 생각해서 없애지는 않았습니다만, 기본 데이터 엑세스 용도로는 사용하지 않습니다. 프로퍼티 리스트를 발견했기 때문이죠.

NSArray/NSDictionary 그리고 프로퍼티 리스트

모든 것을 다 포기하고, 기본적인 배열과 사전 개체로 해결을 보려 했습니다. NSArray의 오토릴리즈된 생성자 목록을 보던 중arrayWithContentsOfFile이라는 메서드가 보이더군요. 순간 감이 왔습니다. 애플 엔지니어가 이런것을 생각하지 않았을리 없죠. 미리 다 준비해뒀을 건데 왜 안보이는 걸까. 그건 그게 너무 가까이 있어서 보지 못했기 때문이 아닐까? 하는 생각이 들었죠. 바로 레퍼런스를 뒤적였고, 이 메서드의 설명 근처에서 Property List라는 키워드를 찾을 수 있었습니다. 사실 프로퍼티 리스트는 전부터 알고 있었는데 잊어버리고 있었습니다. e4x의 기능을 가진 프레임워크를 찾는 데 너무 집착했기 때문이죠. 프로퍼티 리스트를 구성 설정에 주로 쓰이며, 간략한 데이터셋을 다루는데 최적입니다. 이제 모든 문제를 해결했습니다.