최근 관계형 데이터 베이스 디자인 도구를 만들고 있는 데, DB로 부터 역공학 된 DB의 모델을 우아하게 그려주는 문제를 담당하게 되었다. 이들(테이블과 관계선들)을 보기 좋게 배치하는 데 필요한 여러가지 관심사가 있는 데, 그중에 하나가 교차선 없이 공간 효율적으로 테이블들과 관계를 배치하는 문제이다.

교차된 선이 나타나지 않게끔 버텍스를 이동하는 아이폰용 퍼즐게임을 즐겨본적이 있어서, 이와 관련된 AI나 그래프 이론이 있을거라 생각해서 뒤져봤다.

그러나 이런 문제에 대한 알고리즘 연구가 이정도로 형편없다는 데 매우 놀랄 수 밖에 없었다. 주제를 명기하는 이름조차 제대로 없어서, Drawing Graphs Nicely 정도로 적당히 불리고 있었다. 아무튼 다음과 같은 요구 조건들이 달성되야 한다.
  1. 교차: 가능한한 교차되는 선이 나타나지 않아야 한다.
  2. 영역: 가능한한 적은 면적을 사용하여 배치해야 한다.
  3. 엣지 길이: 가능한한 엣지의 길이는 짧아야 하며, 장해물을 피해가야 한다.
  4. 비율: 주어진 비율에 대해 최적화된 배치를 이뤄야 한다. (어느 용지에 출력할 것이냐 등등의 문제)
불행하게도 이 Goal들은 서로 배타적이지 못하고, 모순을 이루기도 한다. 더더군다나 교차등과 같은 문제는 NP 컴플릿 문제를 발생시키기도 한다.

수학적 연구가 제대로 진행되지 않은 탓에, 이것에 대해 최적해나, 성능 기반의 유사해를 내 놓는 접근 방식은 사용할 수 없을 것 같고 - 개발자로서는 도저히 이 무시무시한 시도를 엄두조차 낼 수 없다 - , 장력 시뮬레이션등과 같은 - 스프링 레이아웃과 같은 - 방법이나 뽕빨 휴리스틱을 써야 할 것 같다. 

30년간 아무런 진전도 보이지 못한 인공지능 분야의 몰락은 참 아쉬운 일이다. 에라이. 하긴 뭐 돈 안되니깐. 인정.
Posted by 지이이이율
,

모든 것을 MAC으로

Toy 2010. 8. 2. 23:35

이 매뉴얼을 처음 손에 잡았을 때, 내가 왜 저 말을 무시했을까.
 - 지율, 모블미를 결재하며
Posted by 지이이이율
,
얻을수 있는 장점들:
  1. SQLite로 고속 동작을 보증하는 추상화 모델 클래스를 제공 받을 수 있다. (모델 파일을 더블 클릭하여 새 윈도우에서 엔티티 디자이너를 연상태에서만 새 파일 마법사에 "Managed Object" 항목으로 나온다 - 버그인지 의도인지 모르겠다, 개발자가 부분적으로 오버라이딩 한 경우 머지는 안된다.)
  2. 코어 데이터로 추상화된 모델은 모델이 버전업 했을 경우 매핑 모델을 정의함으로써 데이터 버전업 기능을 쉽게 구현할 수 있다.
  3. 코어 데이터로 추상화된 모델은 WIFI, Bluetooth등으로 싱크할 때 더 편리한 API지원을 받을 수 있다.
  4. 데이터 정합성을 어느정도 보장 받을 수 있다. (관계형 DB에서 삭제 액션 등등)
  5. 이미 존재하는 클래스로 부터도 모델 엔티티 다이어그램을 얻을 수 있다. (하지만 역반영은 불가능하다)
이제부터는 깐다. :)

효율적인 디자인 - 모델 매핑 부재:
맥에서의 개발과는 달리 아이폰, 아이패드에서는 이 코어 데이터와 UI 가 모델 패스로 바인딩 되지는 않는다. 그러나 XIB파일을 일반 xml에디터로 열어 실험해 본 결과, 모델 바인딩이 된다고는 한다. 키밸류 코딩을 이용하면 코드로는 바인딩이 가능한 것이 확실하다. 그러나 이 부분에 대해 애플이 공식적인 지원이 보증될 지는 알 수 없고, 리젝션 위험도 있다.

학습 비용에 대한 리스크:
코어 데이터는 모델로서의 기능 보다 DB Row로서의 특징이 훨씬 강하기 때문에, SQLite 에 대한 이해를 필요로 하며, 동시에 키밸류 코딩 및 옵저빙을 세션 매니저로 활용하므로 Object-C에 대한 깊은 조예를 필요로한다. 따라서 다분야의 전문지식을 갖춘 MDA경험자가 필요하며, 이는 단순하게 교육되거나 커리큘럼에 의해 학습되기 어렵다. 이미 MDA에 익숙한 고급 엔지니어가 아이폰과 같은 초급 기술을 다시 습득하기위해 시간을 투자하는 것은 비용낭비로 비춰지기 쉽기 때문에, 정치적 요건 마련이 필요하다. 또한 이것은 시니어 엔지니어의 작업부담을 높여, 효율적인 분업을 어렵게 할 것이다.

모델 유연성 리스크:
EMF나 기타 모델 제네레이션 프레임웍과 달리, XCode의 모델 클래스 생성기능은 매우 초보적인 수준이어서, 새 파일 만들기만 가능하다. 따라서, 모델 생성 후 후처리 작업에 대한 프로세스를 수동으로 관리해야 하며, 인건비 상승요인이 된다. 또한 모델의 동작 방식은 키밸류 매커니즘에 의해 관리되기 때문에, 단순히 유도속성 하나를 추가하는데에도 최고 수준의 엔지니어가 필요하며, 모델이 리팩토링 될 때마다 투입되어야 한다.

임시 결론:
엔터프라이즈 B2B 에서 엔티티 디자이너는 절실히 필요하지만, SQLite같은 낮은 스케일과 연결된 엔티티를 사용할 수는 없을 것이다. 물론, ManagedObject는 너무 단순하기 때문에 다른 스토어링 코디네이터나, 컨텍스트를 직접개발하는 것이 어려울 것으로 보이지는 않는다. 코어 도큐먼트는 오랜동안 맥의 앱들에서 신뢰성이 확보되었고, 엑스코드 및 아이폰 SDK의 흐름을 보면, 애플이 점점 더 코어 도큐먼트의 지원을 확장하고 있으므로, 여유자금이 충분하다면, 이에 기반한 작업 프로세스를 갖춰 놓는 것도 좋을 것 같다. 

그러나 아이폰 앱의 수익구조를 살펴볼 때, 이러한 다분야 전문가를 몇명이나 고용할 수 있을지는 의문이다. 이러한 고민은 자바 진영 쪽엔 밤하늘에 육안으로 관찰 가능한 별의 수만큼이나 많은 논의와 발전이 있어왔기 때문에, 안드로이드에서 MDA를 도입하는 것은 너무나 쉬운 일이다. 때문에 B2B프로젝트에서 아이폰 개발이 생산성 측면에서 불리할 것 같다. 또한 B2B환경에 작용하는 삼성과 같은 기업의 압력 및 협력 체계 또한 무시할 수 없다.

그럼에도 B2C프로젝트에서 블루투스, 아이튠즈, 와이파이등을 이용한 사용자 데이터 싱크 기능은 사랑받을 것이 분명하고, 코어 도큐먼트를 사용하면 그러한 기능에 대해 빠르게 대처할 수 있다. 하지만 아직까지는 사용자의 데이터를 매우 중요시하여, 그것을 다루는 것이 중점이 된 비즈니스 앱은 많지 않고, 현재 수익이 높은 앱들은 대부분 그러한 특성을 갖고 있지도 않기 때문에, 코어 도큐먼트의 도입은 비용증가에만 머물 우려도 있다. 이러한 특성은 사용자의 눈에 한 두번만에 들어오는 것이 아니기 때문에 가치를 입증받기도 쉽지 않다. 충분한 능력이 있다면 도입할만한 가치나 근거는 분명히 있다. 여러모로 생산성이 뛰어나 질 것이며, 향후 작성할 앱들의 기본적인 품질을 높혀줄 것이다.


'Objective-C' 카테고리의 다른 글

멀티 태스킹 지원시 주의점  (0) 2010.07.23
X-Code의 인터페이스 빌더  (0) 2010.04.28
메모리 관리  (0) 2010.04.25
Getter Method  (0) 2010.04.25
Posted by 지이이이율
,