| Model Driven Crisis #1(프로메슘) (2008/11/20) | |
제이랩 허원진
이 기사는 필자가 MD?(?에는 A 붙이든 D를 붙이든 기본은 MD 이다)를 시작하게 될 때 부터 현재 까지의 이야기다. 이클립스 프로젝트 중에는 EMF와 GMF를 언급 한다. EMF는 이미 제이랩 기사로 다루었으므로 GMF만 자세히 다룰 예정 이다.
프로메슘
은하 철도 999 철이와 메텔
필자가 처음 MD를 접했을때 이렇게 말했다. "이건 뭔 프로메슘 이야기야", 현실은 지구에서 엄마랑 먹고 살기도 힘든데 어디 있는지도 모르는 별이야기나 하는것으로 느껴졌다. 프로메슘는 일본 에니메이션 "은하 철도 999"에서 철이와 메텔의 최종 목적지이다. 1998년도에 소프트웨어 제조업으로 세무서에 신고를 하고 SI 하청을 받아 사업을 꾸리던 시기이다. 이때 이야기를 짧게 한다면 하루에 4~5시간 자고 학교와 사업을 같이 하던 시기였다. 결국은 한달간 병원 신세를 지기도 했다. 그때 필자가 이해한 MD는 "모델을 정의 해서 이 모델에 부가 장치를 추가하여 프로젝트를 수행한다" 였다. 모델이라고 해봤자 개발 계획서에 들어가는 입력과 저장 레코드 모델? 정도 였다. 지금도 세미나나 강의로 MD에 대해 이야기하면 청중들도 그떄의 나처럼 프로메슘 이야기로 받아들이지 않을까 생각한다.
이름은 생각 나지 않지만 1998~1999년도 PC잡지에 입력 래코드를 정의 하면 래코드를 기반으로 하는 어플리케이션(비디오 테이프, 병원 등등)을 자동으로 만들어주는 소프트웨어를 판매하는 광고가 있었다. 이 때에는 한국 소프트웨어 산업의 황금 시대였다. 지금의 SI 중심 보다는 자기 브랜드를 걸고 패키지를 만드는 회사가 많았다. 이런 소프트웨어의 일종인가 생각했다. 이렇게 MD와의 만남은 큰 의미는 남기지 않고 2001년도가 된다.
이클립스를 만나다. CBD를 만나다.
2001년은 필자에게 있어 큰 변화의 시기이다. 함수와 구조체가 전부인 필자에게 Class 중심의 객체 지향이 시작된것이다. 이때의 클래스는 필자에게 함수가 들어 있는 구조체였다. 전에 디스크에 저장하기 위해서는 구조체를 정의 하고 이 구조체를 인자로 하는 함수를 만들어야했는데, 이제는 구조체가 스스로 자기를 저장하는 함수를 갖을 수 있게 되었다. 이리 하여 수많은 함수들은 각 목적에 맞는 클래스로 분화 되어서 프로젝트를 전체적으로 볼수 있는 여건이 되었다. 필자가 단일 프로젝트로 가장 많이 프로그램밍을 해본 기록은 31만 라인이였다. 지금의 자동 생성 되고 stub/skeleton 기반의 OOP(Object Oriented Programming) 환경에서는 모르겠지만 과거의 31만 라인은 실로 엄청난 양 이었다. 이때의 프로젝트 분석은 솔직히 불가능했다. 이때문에 코딩 보다는 주석 열심히 다는 개발자가 추앙 받던 시대였다.
OOP에 관한 책자 들을 보면 재사용의 쉽다고 써있는데 실제로 내가 작성한 클래스를 재사용한적이 거이 없다. 2002년도 제이랩 스터디의 설문 조사도 자신의 코드의 8% 정도만 재사용하는것으로 나와있다. 여러 이유가 있겠지만 다음과 같은 이유가 가장 컸다.
1. 내가 작성한 클래스의 용도를 일일히 기억하기 어렵다.
2. 내가 작성한 클래스를 관리하기 어렵다.
과거에 가장 많이 만든 클래스는 문자열 관련 클래스이다. 대표적으로 우리나라 숫자 표기 처럼 1000단위마다 ","를 표시 한다거나 하는 것들이다. 만들때는 와 정말 좋아 나중에도 써야지 하고 jar로 만들어 놓는다. 이게 끝이다. 이게 어디 있는지 이 안에 뭐가 있는지 알수가 없다. 또 위와 같은 기능이 필요하면 또 만든다. 기껐해봤자 copy&paste수준의 재사용인 것이다. 기능의 집합이 아닌 기능 하나 하나로 사용 하려 했기 때문에 재사용이 제대로 되지 않은것이다. 또한 문서도 문제이다. 아무리 주석을 열심히 달아도 이 jar안에 뭐가 있는지 알 수가 없다. 현재의 근본적인 원인은 다음과 같았다.
1. 기능을 원소(클래스) 단위로 기억/관리/ 사용 하려 했다.
2. 사용 중심의 문서가 없다.
JavaDoc
2의 문제는 자연 스럽게 JavaDoc으로 해결이 되었다. 여전히 1의 클래스 단위로 접근하려는 문제는 해결되지 않았다. 기능을 구룹별로 나누고 기능을구룹 단위로 제공할 방법이 필요했다. A기능을 제공 하는 A클래스가 아니고 A기능을 가지고 있는 A구룹이다. JavaDoc의 사용과 JavaDoc을 지원하는 IDE(통합 개발 환경)의 사용으로 코드 재사용은 단번에 30% 이상 증가 했다. 이떄 만난것이 이클립스이다. 이클립스는 참 신기한 물건이었다. 플러그인 이라는것만 설치하면 기능이 무한히 늘어났다. 이전에도 플러그인 기반의 어플리케이션은 있었지만 이처럼 정말 기능이 무한히 늘어나는 플러그인 기반 소프트웨어는 처음 봤다. 이클립스 안에서 테트리스도 하고 MSN도 하고 MP3도 들을 수 있다. 이클립스는 컴포넌트 환경을 적극 활용하여 extension point라는 구체적인 기능 확장 개념까지 만들었다. 하지만 이와 같은 CBD환경은 유지 보수와 재사용에는 도움이 되지만 최초 실제 개발에는 큰 도움을 주지 못한다. A 프로덕트를 만들때 그냥 만들던 CBD를 이용하던 걸리는 시간은 같다라는것이다.
"CBD를 기본으로한 Model Driven 방식은 끝임없이 증가하는 개발 비용 문제의 근본적인 해결 방법이다."
여전히 너무 개발 비용은 많다.
OOP나 CBD 모두 개발 비용에 많은 도움을 주었지만 실개발에 있어서는 여전히 개발 비용은 많다. 소프트웨어 개발은 고도의 노동 집약적 작업이다. 인간이 해야될것이 너무 많다. 여러 솔루션을 이용하여 자동 생성하자니 여전히 손히 가는 부분이 많고 결과도 마음에 들지 않는다. 어차피 손이 가는데 새 솔루션을 익히는데 걸리는 시간이 아깝다. 내가 OOP, Pattern, CBD등으로 생산력을 강화해도 프로젝트도 그에 따라서 같이 복잡도가 증가하니 결국 걸리는 시간은 줄지 않는다. 여러분이 지식 습득으로 생산력이 증가됐다고 느낀다면 여러분은 과거와 같은 일을 하고 있다는것을 뜻 한다. 즉, 복잡도가 증가된 좀더 높은 수준의 프로젝트를 하는것이 아니다. 내가 현재의 상태로 10년전에 했던 프로젝트를 했다면 당연히 엄청난 생산력을 보일수 있지만 현재의 프로젝트에는 10년 전과 생산력이 다를바가 없다. 뿐만 아니라 개발 내용도 너무 복잡해 졌다. 과거의 몇가지 문서와 소스 만으로 인수인계가 가능했던것과 달리 현대의 프로젝트는 고도의 배경 지식을 필요로 한다. 1년 여 전 인수인계를 위해서 책을 쓰고 있는 자신을 발견하고 놀란적이 있다. 필자는 제이랩 기사 스타일의 글들을 개발 문서에 포함시켜 공동 작업자나 후에 이어나갈 개발자, 나 자신에게도 실제 도움이 되도록 한다. 이렇게 추가적인 문서가 있더라도 복잡하다.
프로덕트를 Model, View, Control로 나누어 보자. 자신의 프로젝트가 MVC아키텍처를 사용하지 않았더라도 나누어만 보자. Model은 입력 내용이 되기도 하고 저장 내용이 되기도 한다. 과거의 개발에도 Model 비중은 꽤 컸다. 고전적인 개발 문서 양식에는 입력, 출력, 저장 래코드(포멧) 란이 있다. 자연계 상에 존재하는 모델이 아닌 팩킷 모델이나 데이터베이스 모델에는 차후 확장등을 고려해서 시간이 걸릴 수도 있으나 기본적으로 요구사항이 수렴되면 바로 나오는 것이 모델이다. 그리 시간이 걸리는 부분은 아니다. View를 보자. 유저의 입력을 받고 입력에 대한 feedback 결과를 보이고 이 부분은 꽤 개발 비용이 든다. 코드량도 많지만 사용자의 변덕 때문에 개발 중에도 많이 바뀐다. Control은 이벤트(일반적으로는 유저나 시스템)에 따른 결과를 View에 통보하고 이를 또한 모델에 반영하고 영속성(persistence)을 디스크 저장이나 DB를 통해 기록한다. 이또한 코드량, 테스트량 복잡도가 꽤 높은 부분이고 버그가 발생하면 가장 곤란한 부분이다. 작업량을 비교하자면 Model < View = Control 이다.
View와 Control의 비용을 줄여야 실제 개발 비용이 줄어든다
View의 비용 문제는 나중에 이야기 하기로 하고 Control 비용 문제를 살펴 보자. Control의 역할은 크게 2가지이다.
1. 인풋 피드백(뷰의 이벤트를 실제 모델에 반영한다)
2. 영속성 유지
2의 역할은 현대 소프트웨어에서 점차 작아지고 있다. 뿐만 아니라 현대 소프트웨어에 있어서 중간 생산물로 xml을 이용함으로써 이 xml을 adapt하거나 convert만 해주면 영속성 유지 역할은 끝이 난다. 주 역할은 유저나 시스템에 의한 인풋 피드백인 것이다.
MVC Sequence
이전 나의 EMF나 GEF글에서 밝힌바와 같이 Control은 Model에 종속적이다. Model이 디자인되면 Model 디자인을 넘어서는 Control이 만들어 질 수는 없다는 뜻 이다.
위 클래스 다이아그램을 보자 Natural Model에 GEF를 위해 추가 필드와 메소드가 있는 모델 클래스이다. SimpleDiagram이 SimpleModel을 포함하고 있다. 즉 내가 무슨짓을 하든 SimpleModel이 SimpleDiagram을 포함할 일은 없다는것이다. Model이 Control을 제한한다. 위 모델에 따른 Control을 수동으로 만든다면 고작해야 인풋이 SimpleModel인지 확인하고 SimpleModel이면 SimpleDiagram에 넣는 코드를 작성하게 된다. Control은 Model 종속적이고 제한되기 때문에 Model을 통한 Control engineering이 가능하다. Control을 통한 Model의 reverse engineering은 완벽하지는 못하다. 이유는 스스로 생각해 보기를 바란다. 결국은 이러한 관계 때문에 Model만으로 Control을 공짜로 얻을 수 있다는 말이다.
그러면 그 공짜로 얻을 수 있는 Control을 만드는 개발자들은 바보인가. 다음과 같은 이유로 아니다.
1.Model Driven Software Package가격은 무지 비싸다.
2.Model Driven Software로 만들어진 Control은 코드가 지저분 하다.
3.2와 관련된 이유인데 Model이 수정되어 Control을 다시 생성하면 문제가 발생할때가 많다. (당연한 이야기지만 여러분이 EMF가 생성해준 코드를 손댔을 경우 다시 생성하면 다 날아간다! 고가의 소프트웨어 중에는 이 문제를 해결한것도 있지만 주석에 손을 대거나 수정의 선을 넘었을 경우 마찬가지로 문제가 발생한다.)
아래는 EMF가 자동 생성해준 코드 중 일부 이다.범용 Model Driven Software로써의 고충은 알겠는데 이걸 볼때마다 갑갑하다. (EMF가 생성한 코드는 기계어다! 그 영역에 가지말자.)
public void unsetCategory() {
ContentCategory oldCategory = category;
boolean oldCategoryESet = categoryESet;
category = CATEGORY_EDEFAULT;
categoryESet = false;
if (eNotificationRequired())
eNotify(new ENotificationImpl(this, Notification.UNSET, GethinkPackage.CONTENT__CATEGORY, oldCategory, CATEGORY_EDEFAULT, oldCategoryESet));
}
public boolean isSetCategory() {
return categoryESet;
}
public EList getLinks() {
if (links == null) {
links = new EObjectResolvingEList(Content.class, this, GethinkPackage.CONTENT__LINKS);
}
return links;
}
public String getLink() {
return link;
}
public void setLink(String newLink) {
String oldLink = link;
link = newLink;
if (eNotificationRequired())
eNotify(new ENotificationImpl(this, Notification.SET, GethinkPackage.CONTENT__LINK, oldLink, link));
}
public Object eGet(EStructuralFeature eFeature, boolean resolve) {
switch (eDerivedStructuralFeatureID(eFeature)) {
case GethinkPackage.CONTENT__TITLE:
return getTitle();
case GethinkPackage.CONTENT__DESCRIPTION:
return getDescription();
case GethinkPackage.CONTENT__CATEGORY:
return getCategory();
case GethinkPackage.CONTENT__LINKS:
return getLinks();
case GethinkPackage.CONTENT__LINK:
return getLink();
}
return eDynamicGet(eFeature, resolve);
}
public void eSet(EStructuralFeature eFeature, Object newValue) {
switch (eDerivedStructuralFeatureID(eFeature)) {
case GethinkPackage.CONTENT__TITLE:
setTitle((String)newValue);
return;
case GethinkPackage.CONTENT__DESCRIPTION:
setDescription((String)newValue);
return;
case GethinkPackage.CONTENT__CATEGORY:
setCategory((ContentCategory)newValue);
return;
case GethinkPackage.CONTENT__LINKS:
getLinks().clear();
getLinks().addAll((Collection)newValue);
return;
case GethinkPackage.CONTENT__LINK:
setLink((String)newValue);
return;
}
eDynamicSet(eFeature, newValue);
}
public void eUnset(EStructuralFeature eFeature) {
switch (eDerivedStructuralFeatureID(eFeature)) {
case GethinkPackage.CONTENT__TITLE:
setTitle(TITLE_EDEFAULT);
return;
case GethinkPackage.CONTENT__DESCRIPTION:
setDescription(DESCRIPTION_EDEFAULT);
return;
case GethinkPackage.CONTENT__CATEGORY:
unsetCategory();
return;
case GethinkPackage.CONTENT__LINKS:
getLinks().clear();
return;
case GethinkPackage.CONTENT__LINK:
setLink(LINK_EDEFAULT);
return;
}
eDynamicUnset(eFeature);
}
public boolean eIsSet(EStructuralFeature eFeature) {
switch (eDerivedStructuralFeatureID(eFeature)) {
case GethinkPackage.CONTENT__TITLE:
return TITLE_EDEFAULT == null ? title != null : !TITLE_EDEFAULT.equals(title);
case GethinkPackage.CONTENT__DESCRIPTION:
return DESCRIPTION_EDEFAULT == null ? description != null : !DESCRIPTION_EDEFAULT.equals(description);
case GethinkPackage.CONTENT__CATEGORY:
return isSetCategory();
case GethinkPackage.CONTENT__LINKS:
return links != null && !links.isEmpty();
case GethinkPackage.CONTENT__LINK:
return LINK_EDEFAULT == null ? link != null : !LINK_EDEFAULT.equals(link);
}
return eDynamicIsSet(eFeature);
}
EMF를 Model Driven Software로 사용 할 경우의 권고안
필자가 EMF를 Model Driven Software로 사용 할 경우의 권고안은 다음과 같다. 이미 팔자가 연재한 EMF기사에 있는 내용이다. 말 그대로 권고안이다 이 권고를 뛰어넘어 더 유용하게 쓸 수 있는 방법이 있다면 알려달라 100번 머리를 조아려 감사히 가르침을 받겠다.
Level2단계만 쓰자
EMF가 생성해주는 코드는 3래밸로 나눈다(테스트 코드 제외)
Level1 Model Level2 Item Provider Level3 Viewer/Editor Viewer 불편 하지만 기본적인 Viewer를 EMF만으로도 생성 할 수 있다. 하지만 Level 1과 Level2만을 사용하기를 권고 한다. 이유는 Level3의 코드는 정말 지저분하고 이걸 쓸만하게 고치려면 끝이 없기 때문이다.
EMF가 생성해준 코드 그대로 쓰자
Level1,2만으로도 Model Control의 코드는 완벽하다. 파일 로드/세이브에 어뎁터나 컨버터를 붙히는 수준의 수정만 하기를 권한다. 모델을 이용해서 제너레이션하면 모델 플러그인과 모델 컨트롤 플러그인이 따로 생성된다. 이것을 수정할 생각을 하지 말자. 모델 정의가 완벽하다면 이것을 수정할 일은 없다.
Model이 수정 될 경우 다시 제너레이션 해서 쓰자
예를 들어 필드 하나 추가했다고 기존 코드 수정해서 쓰지 하는 오류를 범하지 말자. 다시 제너레이션 해서 쓰는 것이 훨씬 빠르고 안전하다.
Note EMF에 대한 궁금함은 기사 하단의 관련 제이랩 기사를 참조를 하면 도움이 된다.
다음 기사에서는 Viewer의 비용을 줄이는 방안을 고민해 보고 GMF에 대해 알아보자.
| 관련 제이랩 기사 | |
| 지니가 EMF를 만났을 때1 | http://www.jlab.net/news/20050722/news.htm |
| 지니가 EMF를 만났을 때2 | http://www.jlab.net/news/20050727/news.htm |
| 지니가 EMF를 만났을 때3 | http://www.jlab.net/news/20050729/news.htm |
| 지니가 EMF를 만났을 때4 | http://www.jlab.net/news/20050804/news.htm |
| 지니가 EMF를 만났을 때5 | http://www.jlab.net/news/20050809/news.htm |
| 정보 |
| 은하철도 999 는 마츠모토 레이지의 작품 입니다. |
About Author
허원진
제이랩 대표 운영자, Total Eclipse 대표 저자, Eclipse Consultant, Juliet Scandal Project Leader. 이클립스 프로젝트들을 적극 이용해서 저비용으로 쾌속개발을 하는데 관심이 많다. Contact
www.jlab.net
이 컨텐츠는 JPL에 의해서 보호 받습니다. 오탈 자나 건의는 이곳에 해주십시오
