우발적인 장타였는데 이야기가 길어진다.
앞에 작성한 글이 주장하는 바가 불명확해 덧붙이는 글을 쓴다.
모델에서 코드를 생성하는 접근 자체에 대해 찬성과 반대 중에 한 가지 답만 하라면, 대답은 상황에 따라 다르다. 먼저 소프트웨어 공학의 미래를 위해선 이런 시도가 필요하다고 본다. 학교나 연구소에서 해야 할 실험을 프로젝트에서 시도하지만 않으면 말이다. 다음으로 모델링이나 설계를 공부하려는 개발자라면 강력 추천이다. 모델과 코드 사이에서의 추상화 수준의 차이를 이해하고, 모델링 도구와 IDE의 차이, 모델링 도구의 한계와 효용성 등을 알아야만 적절히 활용할 수 있다. 도구는 잘 알아야 잘 쓸 수 있는 법이다. 하지만 역시
공부는 개인적으로 해야지 프로젝트에서 제품을 만들면서 하는 방법은 옳지 않다. 프로젝트에서 코드 생성을 찬성할 경우는 언제일까?
아직은 행위 중심의 객체 설계가 힘든 현실을 인정한다면, ERD와 대응할 수 있는 수준의 도메인 객체의 관계를 뽑을 수 있는 프로젝트라면 모델과 코드의 연계를 권하고 싶다. 둘 중 한 쪽만 변경하고, 동기화를 하는 방법은 운영 단계에서 특히 효과를 발휘한다. 반면 운영 단계에선 모델을 쓸 생각이 없어 별도의 설계 문서를 요구한다면, 모델은 곧 현실과 마치 화석처럼 현실과 멀어질 수 있다.
Anemic model과 같이 객체가 데이터 운반이나 구조체 정도로 쓰이는 형국을 비난하는 말이 있긴 하지만, 대규모 프로젝트에서는 ERD와 대응할 수 있는 수준의 객체 모델을 만들어내는 경우는 극히 드물다. Level 1은 넘어야 다음 단계로 갈 수 있는 법이다.
컴포넌트를 채용해서 개발했고 즉, CBD이고 동시에 운영 단계에서 컴포넌트가 실제로 의미를 지니는 경우라면 컴포넌트 인터페이스는 모델과 코드 동기화를 확보하면 유용하다. 컴포넌트 인터페이스 변경은 상당한 공수를 요하기 때문에
유지보수를 맡은 개발자도 사람답게 살기 위한 절차를 마련해둘 수 있다. 필요한 시간을 보고하고, 모델을 수정해 작업 흔적을 남긴 후에 코드에 반영한다. 이 때,
자동생성하는 부분과 개발자가 작성하는 코드는 물리적으로 분리하기를 권장한다. 최근의 모델링 도구는 개발자가 작성한 코드에 덮어쓰기를 하는 일은 드물지만, 자칫 실수하면 여전히 기존 코드를 날릴 수 있기 때문이다. 또한, 모델 수준에서 의미가 있는 정보는 프로그래밍 코드 수준이 아니다. 그래서 코드에서도 추상화 정도가 높은 인터페이스 영역과 구현체를 분할하는 방법은 권장할만한 방법이기도 하다.
그러나 위와 같은 수준에 도달한 조직은 많지 않다. 아쉽게도 다음과 같은 현상을 자주 접할 수 있다.
- 프로젝트 주관사 혹은 고객사 QA 담당자가 한 가지 방법 허용한다면
표준화 하라고 한다. 내용면에서보면 강제하는 형식이 맞지 않는데도 말이다. 이런 경우는 획일화란 용어를 권장해주고 싶다.
- 프로젝트 초기에 배운 방법이나 가이드나 나온 형식대로 방대한 UML 모델을 작성한다. 유스케이스 모델을 작성하다 보면 너무 간단한 내용을 어렵게 그리는 듯한 느낌을 받는다. 그리고 업무 별로 수 백개의 다이어그램이 거의 유사하다. 업무명이나 데이터를 담는 클래스 이름만 다르고 나머지는 거의 동일해서 모델링이 단순 작업으로 전락한다.
- 객체가 너무 많아 ERD를 역공학으로 읽어와서 객체 모델로 변경한다. 객체가 너무 잘게 쪼개져서 있어 걸핏하면 Join을 해야 하는 형국이다. 속성 이름이 대부분 약어라 도저히 알 수가 없다. 유지보수를 위해서는 엑셀로 테이블과 속성 이름을 설명하는 문서를 작성해야한다. (그렇다면 모델은 용도는 무얼까?)
- 중요한 업무 규칙은 UML 모델에 담기 어려워서 설계를 이중으로 하는 느낌이다. 그러는 가운데 개발 단계가 다가왔다. 일단 코드를 만들어야 하는데, QA 담당자가 설계를 완성하고 코드 생성을 통해서 만든 코드로만 구현을 하라고 한다.
- 공동작업하던 모델이 마구 꼬인다. CVS/SVN/ClearCase 등을 연계해서 써보니 충돌을 해결하는 작업이 너무 힘들다. 그냥 동시에 작업을 하지 못하게 하고 공통으로 쓰는 객체는 공통 담당자를 두어 통합하게 한다. 막판에 일이 몰리면, 통합 담당자가 죽어 나거나, 암묵적 합의에 의해 대강 알아서 해결한다. (동일한 쓰임을 갖는 객체가 다른 이름으로 여러 개 존재한다.)
더 길어지면 자칫 비관적인 글로 오인할 듯 해 그만둔다. 이야기가 너무 길어질 해서 이제 마무리를 해야겠다. 느닷 없긴 하지만 MDA를 소개하고자 한다. 쉽게 말해 MDA는 모델과 코드를 좀 더 유기적으로 연계하여 개발 공정을 개선하려는 시도이다.
앞서 언급했던 2003년 프로젝트에 참여할 당시 모델링 도구에 대한 환상을 가지고 있던 나에게 가장 획기적으로 보였던
도구는 MDA 툴이었다. 당시는 OMG가 MDA 판촉에 열을 올리던 때였고, 아크스타일러, 카비라가 시장 선도 업체였다. 당시
시장 선도 UML 모델링 도구였던 Rose나 2인자 Together는 선언부 정도의 코드는 모델과 코드 사이의 양방향 변환,
일명 RTE(Round-Trip-Engineering)를 지원했다. 그 수준도 조악하다 느낄 정도였는데, 여하튼 내부 구현 코드
생성은 이상에 지나지 않았다. 그러던 차에 만난 카비라 시연은 놀라웠다. UML 모델에 몇 가지 규칙을 일종의 스크립트로 입력한
후에 적용한 플랫폼 유형을 선택하고, 변환을 시도하면 해당 플랫폼에서 구동 가능한 모델(Platform Specific
Model)이 나오는데 이는 바로 실행이 가능했다. 놀라움은 얼마 가지 않아 궁금함으로 바뀌었다. 가변적인 업무 규칙을 어떻게
스크립트 언어만으로 표현할 수 있고, 접속자가 많아지면 과연 그에 맞게 규모 가변성(Scalability)를 제공할까?
쉽게 답을 찾을 수 있었다. 해당 툴을 도입해서 팔려던 시도는 결국 국내에서 한 곳도 레퍼런스를 찾지 못하고 실패로 돌아갔다. 지금 보니 해당 업체도
방향을 약간 전환한 듯 하다. MDA를 위해 등장한 UML2.x는 많이 발전한 듯 보이지만, MDA는 여전히 무척 느린 행보로
진행하고 있고 얼마후 등장한 MDD는 MDA로 가기 위한 과도기 성격처럼 보인다. UML을 전문적으로 연구하는 어떤 분의 말에
따르면 유럽의 자동차 업계에서 MDA는 실적이 있다고 한다.
하지만 정보시스템/엔터프라이즈 영역에서 가변적인 요소를 체계적으로 정리해서 정형화를 단기간에 하겠다고 한다면 이는
풋내기로 볼 수 밖에 없다. 마틴 파울러가 illogic이라고 표현한 기업/조직의 역사가 만들어낸 일반화 하기 힘든 비즈니스
규칙을 수식으로 풀어내기엔 소프트웨어 공학은 아직 많이 어리다. 솔직히 내 생전에 얼마나 비슷하게라도 가능할지 의문이긴 하지만, MDA는 어찌 보면 많은 소프트웨어 공학 관계자에겐 꿈이자 실현 가능하게 보이는 지향점이다.
