화이트정보통신㈜

새로운 IT 패러다임이 등장할 때마다 현기증을 느끼는 사람들이 있다. 특히, 소프트웨어 개발 업계에 막 입문한 사람보다는 나름대로 경험과 노하우를 가지고 있고, 무엇보다도 자신이 속한 조직 내에서 실질적으로 새로운 작업을 추진할 만한 위치에 있는 엔지니어들일수록 그런 현상이 더욱 심한 것 같다. 최근 이슈가 되고 있는 MDA라고 하는 새로운 패러다임을 도입하여 그것을 조직의 소프트웨어 개발 생산성 향상으로 접목시키는 와중에 현장(field)에서 느끼고 있는 문제들과 그 해결 방안에 대해 고심하고 있는 사안들에 대해서 솔직 담백하게 털어 놓고자 한다.

MDA 도입 배경

필자의 회사에서는 2003년도를 전후해서 제대로 만들어진 컴포넌트이든, 혹은 컴포넌트가 아니더라도 무엇인가 실질적인 소프트웨어 생산성을 끌어 올릴만한 묘안이 절실히 필요했다. 2-3 년 전만 해도 그 묘안은 CBD 혹은 컴포넌트였고 현재도 그러한 사실에는 변함이 없다. 필자의 조직은 그러한 컴포넌트 패러다임 초기에 나름대로 사활을 걸고 CBD 사상에 달려 들었던 탓에, 업계에서 지금까지 CBD에 관한 기술 선도 업체로서 인정받으면서, 영업적으로나 마케팅적으로 그 효과를 보고 있는 것이 사실이었다. 하지만, 컴포넌트가 가져다 줄 것이라고 믿었던 본질적인 소프트웨어 생산성(productivity) 효과라기 보다는 오히려 그 이면에 깔린 마케팅적인 대외 홍보 효과가 더 주효했던 것이 부정할 수 없는 현실이기도 하다.

여하튼 필자의 회사는 2003년을 전후해서 꾸준히 수주하는 프로젝트가 많아졌고, 더불어 그 규모(scale)나 기간(duration)도 상대적으로 커지고 길어졌다. 어느 회사에서나 그러하듯이 전통적인(?) 방식 즉, 새로운 개발자를 내부 직원으로 충원하거나 임시방편으로 외부인력을 조달하면서(outsourcing) 프로젝트를 진행했다. 하지만, 시스템의 납기(delivery)가 자의 반 타의 반 연장되면서 그로 인한 기회비용 손실은 말할 것도 없고, 회사가 울며 겨자 먹기 식으로 어쩔 수 없이 떠안아야 하는 재정적(financial) 부담은 이루 말할 수 없었다. 회사의 재정을 관리하는 관리부서를 중심으로 볼멘 소리가 터져 나오기 시작했다. “대형 SI 업체들의 프로젝트 저가 수주 전략(?)이라는 육탄 세례 속에서 , 이미 탁상공론을 넘어 저 먼 외국 사례로 인용되고 있는 정통부나 과기처의 소프트웨어 개발 단가표(table)는 고사하고…… 우리가 무슨 떼돈 벌겠다고 하는 것도 아닌데……” 한마디로, 근본적인 해결책이 없는 가운데 프로젝트를 계속해서 수주하는 것이 관리부서 입장에서는 기쁜 일만은 아니었다.

“실제 현장(site)에서 프로젝트를 수행해 보면 그런 소리 못한다”고 현장에서 겪는 고초를 하소연하던 개발팀에서도 점차 자성의 목소리가 흘러 나왔다. 당장 촉박하게 프로젝트를 종료하기 위해 몸부림치던 당시에는 못 느꼈지만, 막상 프로젝트를 마무리하고 본사로 철수하거나 다른 현장으로 투입된 초기에 가만히 앉아서 살펴 보면서 다들 ‘저쪽 고객 사에서 요구했던 것이나 이쪽 고객 사에서 요구하는 것이나 크게 차이가 나지 않는데 왜 그렇게 프로젝트를 마무리하기 어려운 것인지……’라며 머리를 갸우뚱거리게 된다. 고객의 요구사항이 수시로 바뀌는 것이야 어제 오늘의 이야기가 아니겠지만, 인터넷 기반의 시스템 개발이 보편화 되면서 특히 그런 요구사항 변경이 더욱 시스템 개발을 어렵게 한다는 너무나도 단편적인 원인으로 그 탓을 돌리는 것도 한편으로는 이해가 가지만, 어쨌든 SI 업계에서 수행하는 시스템 개발 프로젝트에서의 소프트웨어 생산성 문제는 필자의 회사 같은 중소 업체 입장에서는 사활이 걸린 중대한 사안일 수밖에 없다. 프로젝트를 계획대로 종료하지 못하고 납기일이 연장 되면 수금이 지연되고, 이는 곧 인건비 부담으로 직결되고 자금 사정이 여유롭지 못한 중소 업체 입장에서는 여간 부담스러운 것이 아닐 수 없다.

MDA 도입 과정

“Evaluating Software Architecture-Methods and Case Studies”라는 책을 보면 소속 조직에 새로운 기술이나 패러다임을 도입-위 책에서는 ATAM 기법(method)-하기 위한 아주 세부적인 전술(tactics)을 제시하고 있다. ROI 분석에서부터 조직 내에서 동조자를 끌어드리고, 의사결정권자를 설득하기 위한 세세한 조언까지 아끼지 않고 있다. 그러한 아이디어를 접목하여 필자의 조직에 MDA를 도입했던 과정을 차근차근 살펴 보기로 한다.

경영진의 설득

앞선 “MDA 도입 배경”에서 살펴 본 상황으로부터 쉽게 유추할 수 있겠지만, 필자의 조직에서는 일단 어떠한 형태로든 돌파구가 필요한 상황이었다. 경영진들 입장에서의 압박감은 그 상황이 더욱 심각하게 고려되었다. MDA 이전에 가장 활발하게 이슈가 되었던 컴포넌트에 관해서는 조직 내부에서조차 그 효용성에 대해 다소 회의적인 시각들이 팽배해 있었고 이는 곧 IT 업계에서 시기마다 발표되는 패러다임 혹은 기술이라는 것에 대한 부정적인 시각으로 확대 해석되고 있는 상황이었다. 그렇다고 컴포넌트 패러다임을 부정하면서 그것을 대체할 수 있는 패러다임이라고 MDA를 부각시키는 것은 타당성이 없어 보였다. 사실, MDA는 CBD를 대체하는(replacing) 패러다임이라기 보다는 오히려 CBD 사상에 근거한 소프트웨어 개발의 단위인 “컴포넌트를 보다 컴포넌트답게” 시스템 개발 초기에 모델이라는 형태로 만들고, 향후에도 그 수준에서 재사용해 보자는 것이 근본 취지였기 때문에, 실행 개체 수준 컴포넌트 개념에서 모델 수준 컴포넌트 단위로의 형태론적(syntax) 변화일 뿐 컴포넌트의 전면적인 부정은 아니다.

필자는 그러한 사실을 지속적으로 조직 구성원 특히, 조직의 방향성에 대한 결정권을 가지고 있는 경영진들에게 전달하고 그러한 MDA 접근법이 보편화되었을 때 예상할 수 있는 시스템 개발 방식의 변화 등을 설명하려고 노력했다. 그리고 보다 현실적인 측면에서, 필자의 조직에서 활발하게 활용하고 있는 모 업체의 CASE 도구 속에서 그러한 MDA 사상을 접목시키고자 노력하고 있는 모습 즉, 추가하고 확장하는 기능(function)들이나 기술들을 예로 들면서 앞으로 MDA가 향후 소프트웨어 산업계의 핵심 메커니즘으로 자리잡아 갈 것임을 확신시키려 노력했다. 그리고 MDA를 통해 획득할 수 있는 소프트웨어 생산성에 대한 참고 자료를 소개하는 시간을 많이 갖도록 노력하였다. 그러한 자료 중에 2003년 6월에 발표된 “더 미들웨어 컴패니(The Middleware Company)” 연구 팀에서 발표한 “MDA 접근법을 활용한 J2EE 플랫폼 기반의 모델 중심 개발에 대한 생산성 분석(Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) Approach-Productivity Analysis)”이나 2004년 1월에 추가로 발표한 “MDA 접근법을 활용한 J2EE 플랫폼 기반의 모델 중심 개발에 대한 유지보수성 분석(Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) Approach-Maintainability Analysis” 보고서는 매우 설득력 있는 자료로 활용할 수 있었다.

개발팀들과의 마찰 해소 방안

코드 중심의 개발 방식(code-centric development)에 익숙한 개발자들에게 당장 눈앞에 직면한 프로젝트에 대해 반드시MDA를 적용해서 시스템을 개발하라고 강제한다면 그것은 현장에서 고객들과 씨름해야 하는 개발팀에게는 “기름통을 들고 불 속으로 뛰어들어라”는 말과 다르지 않게 느낄 것이다. 그래서 일단 R&D의 작업 방향에 대해 관심을 내비치는 엔지니어들에게는 그저 앞으로의 소프트웨어 개발 방식은 UML을 보다 적극적으로 활용하는 방식으로 진화할 것이며 그에 대한 나름대로의 대비가 있어야 한다는 정도로만 이슈로 제시하면서, R&D 팀을 중심으로 그러한 준비를 조직적으로 수행하고 있으며 점차 그러한 작업이 실체화 되는 시점에 내부 인력을 대상으로 내부 교육이 진행될 것임을 주지시켰다. 그러한 내용을 굳이 개발팀원들에게까지 전파하는 목적은 무엇보다도 향후 조직에서 필요로 하는 엔지니어가 되기 위한 실천 방안을 사전에 비전(vision)으로 제시함으로써, 최소한 UML을 활용해 구축된 모델을 접하게 될 시점에 거부감 없이 쉽게 수용하고 수월하게 전환 교육이 이루어질 수 있도록 채비시키기 위함이었다. 그것은 R&D 팀에서 본격적으로 MDA 기반의 시스템 개발 작업을 수행하면서 조직 내부에서 제기될 수 있는 불협화음을 사전에 차단하기 위한 기반 작업이기도 했다.

수행 조직 결정

국내의 영세한 SI 업계 상황을 고려할 때, 굳이 MDA가 아니더라도 고객의 명시적인(explicit) 요구사항으로 제시되거나 모험을 감수해야 하는(?) 신생 업체가 아닌 이상 일반 중소 SI 업체 입장에서, 특정 패러다임이나 기술에 대한 전문가가 부재한 상황에서 지금까지 쌓아온 개발 노하우나 방식을 전면적으로 뒤엎으면서까지 새로운 패러다임이나 기술을 전면적으로 도입하려고 한다면 그것은 도박일지도 모른다. 그것도 당장 법적으로 납기일이 명시된 현장(site)에서 도입한다는 것은 더더욱 불가능하다.

R&D 팀의 성격상 당장 고객들에게 무엇인가 보여줘야 하는 개발팀들과는 달리 필자 조직의 R&D 팀은 2-3년 전에는 CBD, 그리고 이번에는 MDA와 같은 새로운 기술 혹은 패러다임을 접하고 그것을 조직의 새로운 패러다임으로 접목할 임무를 수행하기로 결정하였다. 그것은 R&D 팀의 특정상 어쩌면 당연한 임무이자 역할이기도 하다. 하지만, 관행적으로 SI 업체 R&D 조직의 보편적인 역할은, 해당 업체에서 수행하는 여러 프로젝트에서 공통으로(common) 사용하거나 상대적으로 난이도가 있는 모듈(module) 혹은 컴포넌트(component) 개발 및 유지보수를 전담하거나, 프로젝트 초기 전반적인 시스템 아키텍처(architecture)의 설계 정도에 한정되는 것이 보통이다. 필자의 R&D 팀의 조직 내에서의 역할도 그러한 보편적인 역할에서 크게 벗어나지 못하고 있었다. 그러한 문제를 해결하기 위해 내부적으로 R&D 팀 구성원을 추가로 확보하고, 조직 내의 개발팀들을 지원하는 팀과 MDA 기반의 내부 프로젝트를 진행할 팀으로 이원화하는 방식을 채택하는 식으로 역할을 분담하였다.

내/외부 공모자 확보

인사 관리 도메인 지식을 갖춘 사람과 새로운 기술을 개척할 수 있는 엔지니어를 중심으로 MDA 관련 자료를 회람하면서 정보를 공유하였다. 또한, 내부적으로 기술적인 측면에서든 인사 업무 측면에서든 어느 한 편에 대한 상대적 경쟁력을 갖춘 역량 있는 인력을 R&D 팀으로 합류시킴과 동시에 외부적으로는 필자의 R&D 팀에서 MDA라는 새로운 패러다임에 기꺼이 도전하려는 새로운 인력 충원을 적극 고려하였다. 설령 그것이 MDA가 아닌 다른 사상이나 기술이라 할지라도, 개인적 신념만으로 일을 추진하기에는 너무나도 험난한 것이 사실이고, 최근의 시스템 개발 문제는 조직 내에서 단순히 능력이 뛰어난 몇몇 컨설턴트나 엔지니어에 의해 주도적으로 수행되기에는 이미 그 규모(scale)나 비중(relative importance)이 커졌다는 사실을 반증하는 것이기도 하다.

MDA 실현의 난제 및 그 해결방안 모색

지금까지 필자 조직의 R&D 팀 관점(perspective)에서 MDA라는 전략(strategy)이 결정된 배경과 그 도입 과정을 간단히 살펴 보았다. 이제부터는 보다 구체적으로 MDA를 수용하고 필자의 조직에서 목적하는 시스템-인사 관리 시스템-에 접목하는 과정에서 발생했고, 앞으로 발생할 것으로 예상되는 난제(issue)들과 그것들을 해결하고자 채택하고 있는 전술(tactics)들에 대해 살펴 보기로 한다.

전문 도메인 지식 습득(Domain Knowledge Acquisition)

MDA 기반의 인사 관리 시스템 개발을 추진하는 수행 조직으로 결정된 R&D 팀 이전 구성원들의 역량은 상대적으로 기술적(technology)인 측면에 비해 인사 관리(human resource management)라는 비즈니스(business) 측면에 대한 지식이 부족한 상황이었다. 어떠한 도메인이든 MDA 기반으로 제대로 된 시스템 개발을 위해서는 해당 도메인에 대한 전반적이고 체계적인 지식이 필수적인 상황에서, 단지 CASE 도구를 활용한 UML 기반의 모델링이 가능하다는 사실은 그저 “무엇(business)”인가를 담을 수 있는 “틀(technology)”은 갖추었지만, 막상 담아야 할 내용(contents)이 무엇인지는 모르는 형국에 지나지 않았다. 그렇다고 조직내의 다른 개발팀들처럼 특정 고객에게 필요한 인사 관리 시스템만을 구축하면 그 역할이 끝나는 상황도 아니었다. 일단 R&D 팀과 현장에서 시스템을 구축 중인 개발팀들과의 유기적 관계를 구축하였다. 일단 R&D 팀에서는 지금까지 필자의 조직에서 수행한 인사 관리 시스템 구축 시 활용되거나 작성한 자료를 수집하고, 전사적인 차원에서 공통적으로 참고할만한 관련 자료를 정리 및 통합한 후 다시 그러한 내용을 각 개발팀원들이 모두 공유할 수 있도록 시스템을 구축하였다. 필요한 시점에 R&D 팀에서 각 사이트에서 진행 중인 프로젝트의 상황을 모니터링 하여 필요 시에 해당 사이트에 방문하여 자료를 수집할 수 있도록 협조를 요청하였다.

또한, R&D 팀에서 진행하는 인사 관리 시스템은 특정 고객사를 대상으로 하는 시스템이 아니기 때문에, 모든 개발 현장에서 보편 타당하게 수용할 수 있는 제품이어야 하는 특성을 고려하여, 인사 관리에 관한 국내외 표준 자료를 수집하였다. 그것은 현재 OMG를 중심으로 특정 도메인에 대한 데이터 교환 표준 규약을 XML 기반으로 구축중인 것과 일맥상통한다. 그러나, 아쉽게도 아직 OMG에서 명시적으로 인사 관리 도메인에 대한 표준화 작업은 미비한 상태였다. 그런 와중에 외국의 인사 관리 관련 업체들을 주축으로 결성된 HR-Consortium에서 제시하는 공개된 자료를 발견하였고, 그곳에서 제안하는 XML 기반의 인사 관련 표준 데이터 스키마와 프로세스를 중심으로 보편 타당한 인사 시스템의 비즈니스 아키텍처 작성 작업을 진행하였다.

제대로 된 UML 지식(Advanced UML Knowledge)

간혹 필자는 주변에서 현재 OMG에서 준비 중인 UML 2.0 명세(specification) 최종 버전이 확정되고, 각 CASE 도구 벤더들이 본격적으로 UML 2.0을 지원하는 시점부터 MDA 기반의 시스템 개발이 가능하지 않겠느냐는 질문을 받을 때가 있다. 그러나, 그것은 MDA 관련 참고할 만한 서적을 한번이라도 읽어 본 사람이라면 사실과 다르다는 것을 금방 알 수 있다. 기왕이면 “새로운 포도주(MDA)를 새로운 그릇(UML 2.0)에 담는 것”이 좋기는 하겠지만, 현재 CASE 도구 벤더들이 표준으로 지원하고 있는 UML 1.4 에서도 충분히 MDA적인 시스템 개발 접근법이 가능하고, 무엇보다도 필자가 이 글을 쓰는 시점에 대표적인 많은 CASE 도구들이 이미 다양한 형태로 OMG의 MDA 구현에 관한 표준에 근거한 확장 메커니즘을 적용하여 CASE 도구의 기능을 추가 및 갱신하고 있는 상황이다.

UML 2.0이 전제되어야만 MDA식 개발이 가능하다는 오해의 이면을 살펴 보면, 필자의 조직을 비롯하여 많은 업체들이 지금까지 표면적으로는 UML이라는 OMG의 모델링 표준에 근거하여 분석과 설계 작업을 한다고 했지만, 실질적으로는 완벽한 UML 중심의 작업이었다기 보다는 UML의 일부 간단한 표기법(notation)을 중심으로 개념적이고 피상적인 수준에서 UML을 활용했다는 반증이기도 하다. 그러한 결과 소프트웨어 산업계에 만연되어 있는 “시스템 개발 초반의 CBD 컨설팅 따로, 후반의 실질적인 개발 따로”라는 이분법적 고정관념을 엔지니어 머리 속에 만들어 냈고, 이는 곧 프로젝트의 전반적인 생산성 저하라는 고질적인 소프트웨어 산업계의 악순환 구조를 양산하고 말았다. 무엇보다도 MDA 기반의 시스템 개발 방식과 지금까지의 코드 중심 개발 방식은 표면적으로는 큰 차이가 없어 보이겠지만, 그 내면을 들여다 보면 혁혁한 패러다임의 전환을 필요로 한다는 사실을 직감할 수 있다. 소프트웨어 산업계에 MDA 개발 방식이 보편화되기 시작하면, 이것은 예전처럼 소위 UML을 통해 어설프게 모델링 작업을 수행하던 사람들에게는 새로운 도전이며, 그 동안 UML을 먼 나라 이야기처럼 한쪽 귀로 듣고 한쪽 귀로 흘려 왔던 엔지니어들에게는 가히 극복하기 어려운 도전으로 다가올 것이라 생각한다.

이러한 상황에서 필자의 R&D팀은 일단 이전에 대충 훑어 보았던 기존의 UML 1.4 명세의 상급 수준 특징들(advanced feature)을 보다 면밀히 검토하고, 보다 정밀한 모델링이 가능하도록 설계 문서들간의 연관관계에 대해서 고민하기 시작하였다. 특히, 앞서 살펴 본 인사 관리 도메인을 보다 체계적으로 모델링 하는 작업에 전념하였다. 한편으로는 현재 시중에 나와 있는 MDA 관련 서적을 집중적으로 살펴 보고, UML 2.0 초안을 검토하여 기존에 활용하던 UML 1.4와의 차이점과 보강된 내용을 체계적으로 정리하는 작업을 수행하였다.

CASE 도구 선정(CASE Tool Selection)

필자의 조직에서 특정 벤더의 CASE 도구를 향후 조직의 기본 도구로 선정하는 과정에서는 사실 거의 이견이 없었다. 무엇보다도 오랫동안 필자의 조직에서 프로젝트를 수행하면서 어설프게라도 해당 CASE도구를 기본으로 활용하여 작업했던 탓에 상대적으로 다른 CASE 도구들에 비해 사용자 저변이 많이 확산되어 있는 상황이었다. 또한, 향후 MDA 기반의 시스템 개발이 확산되면 기존의 개발 도구나 각종 CASE 도구들에 상대적으로 모델링 작업을 수행해야 하는 CASE 도구에 대한 종속성(dependency)이 커지겠지만 , 그렇다고 기존의 여타 코딩이나 형상관리(configuration management) 등의 작업에 필요한 도구 그리고 운영 플랫폼들과의 연동이나 통합을 고려하지 않을 수 없었다. 그런 관점에서 보더라도 필자의 조직에서 선정한 모델링 CASE 도구는 최소한 필자 조직에서 가장 자연스러운 최적의 선택이었다.

엔지니어들의 도구 친밀도와 기술적인 측면에 덧붙여 해당 CASE 도구 제작 벤더에 대한 시장에서의 고객 선호도를 고려하였다. 고객들의 CASE 도구 선정 경향은 일반적인 엔지니어적인 관점에서의 기술 구현 완성도(completeness)나 기능(functionality) 등에 국한되지는 않는다. 오히려 수치화가 어려운 고객들간의 입 소문이라든지 고객사의 과거 경험이나 주변인들의 권유가 많이 작용하는 것이 현실이다. 고객사의 특별한 제약사항으로 제시되는 경우가 아니라면, 프로젝트 초기에 개발업체에서 “이러 이러한 도구들을 중심으로 개발하겠습니다”라는 식의 도구 제안이 들어가게 된다. 고객들은 앞서 언급한 바와 같이 특별한 상황이 아닌 이상 그러한 제안을 수용하는 것이 일반적이다. 무엇보다도 지금까지의 개발 방식에서는 CASE 도구 특히, 모델링 도구가 큰 비중을 차지하지 않았고, 더욱이 국내에서 소프트웨어 개발 환경에서는 모델링 도구란 그저 요식적인 “그림 도구(drawing tool)”에 지나지 않게 치부되는 상황을 생각하면 훨씬 쉽게 이해될 수 있다. 그런 맥락에서, 필자의 조직에서 선정한 모델링 도구는 그나마 전반적으로 고객들의 거부감을 자극하지 않을 수 있는 도구였고, 나름대로 평가하기에도 CASE 도구 중 최소한 MIS 분야 시스템 설계에서는 가장 보편적으로 활용되고 있는 도구였다.

모델 버전 관리(Model Version Control)

MDA 기반의 시스템 개발을 추진하게 될 고객 입장에서는 해당 결과물인 각종 모델들과 모델간 전환(transformation)을 위한 메커니즘 구현물들(profiles)만을 대상으로 유지 보수하는 것으로써, 특정 상위 비즈니스 업무가 변경되더라도 상위 모델(PIM) 중심의 수정작업을 통해 손쉽게 시스템을 재구성하거나 변형할 수 있고, 또한 기존의 형상관리 기법을 그대로 적용하면 손쉽게 조직 내에서 달성해야 할 소프트웨어 생산성 혹은 재사용성이라는 소기의 목적을 달성할 수 있겠지만, 필자의 조직과 같은 SI 업체 입장에서는 인사 관리라고 하는 특정한 비즈니스 모델 결과물(PIM)을 재사용하면서 여러 고객 사이트에서 다양하게 변형하거나 커스터마이징 작업을 통해 수익을 창출해야 하는, 어쩌면 보다 복잡한 메커니즘 구현이 필요한 상황으로 판단되었다. 필자의 조직에서 이제 막 MDA를 도입하여 시스템 개발을 추진하는 시점에서 명쾌한 그 방안을 제시할 수는 없는 노릇이지만, 필자의 조직처럼 특정 도메인 모델을 중심으로 여러 사이트에 적용시켜야 하는 조직이라면 반드시 MDA 기반 시스템 개발 초기에서부터 염두에 두어야 할 주요 이슈일 것이다.

지금 현재 필자의 조직에서 그러한 모델의 버전 관리 문제와 관련해서 시스템 설계 시에 고려하는 사안은 일단 인사 도메인에서 단위 비즈니스 프로세스 및 데이터 구조 자체의 비즈니스적인 유연성(flexibility) 확보를 위해 단위 업무별 공통성(commonality)과 가변성(variability)을 시스템 설계 초기부터 모델에 반영하고, 특정 플랫폼으로의 전환 시 해당 전환 규칙(transformation rules)에서 불필요한 요소를 아예 전환이 되지 않도록 제어하는 방식으로 고려하고 있다. 바로 소프트웨어 프러덕트 라인(SPL: Software Product Lines) 접근법이다. 또한 단위 업무들-엄밀히 말하면 단위 업무별 비즈니스 모델-뿐만 아니라 전환 규칙(transformation rules) 자체를 형상 아이템(CI: Configuration Item)으로 전환할 것을 염두에 두고 필자의 조직에서 결정한 CASE 도구에서 제시하는 다양한 형태의 모델 단위(unit) 구조를 연구하고, 인사 관리 단위 시스템의 구조(structure) 결정 작업을 진행하였다.

특히, 필자가 주목하는 사항은 OMG의 MDA 접근법에서 제안하는 프로파일(profiles)이라는 형태의 전환 규칙(transformation rules)의 조직 자산(organization’s asset)화 문제이다. 즉, 기존의 전통적인 개발 방식과는 다르게 메타 데이터(meta-data)를 통해 소스(PIM)를 목적 플랫폼(target platform, PSM)으로 전환하는 기술이 궁극적으로는 향후 MDA 기반 개발이 보편화되는 시점에는, 필자의 조직과 같은 소프트웨어 개발 및 통합 업체 입장에서는 타사와 차별화 될 수 있는 기술력에 대한 실질적인 자산이 될 것이라는 점에 주목하고 있다.

모델 보안(Model Security)

마지막으로, 앞선 단락에서 언급한 MDA 기반 기술 개발로 축적되는 모델이라는 새로운 형태의 조직 자산에 대한 보안 문제이다. 가장 중요한 문제이면서도 아직까지 명확한 방안을 생각해 내지 못한 이슈이기도 하다. 가령, 다른 업계에 비해 상대적으로 IT 업계에서 보편화되어 있는, 엔지니어들의 잦은 조직 이동 문제를 고려해 보자.

핵심 인력의 이동 문제는 과거에도 그랬고 향후에도 이전 조직에 결정적인 타격을 줄 것임은 변하지 않겠지만, MDA 기반의 개발 방식이 보편화 되는 시점에서의 핵심 인력 유출은 상대적으로 지금의 코드 중심의 개발 방식에 비해 상당한 수준의 기술 유출로 이어질 수 있으리라 생각된다. 특히, 개발 소스나 자료의 보안 관리가 허술하게 이루어지고 있는 국내 프로젝트 실정을 고려한다면 심히 염려가 되지 않을 수 없다. 코드 중심의 개발 방식에서는 아무리 좋은 소스 코드를 많이 보유하고 있더라도 특정 고객의 시스템 개발에서는 일일이 소스를 뜯어 고치지 않고서는 고객이 원하는 시스템을 구현할 수 없었지만, MDA 기반의 개발 방식에서는 소스 레벨보다 상위 추상화 수준(level of abstraction)에서 약간의 수정만으로도 지금까지 상상할 수 없었던 수준의 소프트웨어 재사용이 가능해질 것이기 때문이다.

태양이 밝게 빛날수록 이면에 드리우는 그림자는 더욱 짙어지는 것과 같이, MDA가 가지는 수많은 장점 이면에는 어쩌면 우리가 예상치 못한 어떤 부작용들이나 난관이 반드시 존재하리라 예상된다. MDA 모델 혹은 프로파일 자산의 보안 문제는 바로 그러한 맥락에서 이해할 수 있고, MDA를 고려하고 있는 조직에서는 반드시 염두에 두어야 할 이슈사항일 것이다.

결론

필자는 종종 국내 IT 업계 원로 중의 한 분이신 필자의 연구소장님으로부터 예전의 구조적 프로그래밍이 팽배했던 시절 이야기나 그 원리(principle) 그리고 당시의 사회적 분위기에 대해 들으면서 놀라움을 금치 못하곤 한다. 필자의 미천한 경험 탓이기도 하겠지만, 이전의 패러다임들에 대해 미처 제대로 경험하지 못하고, 이해하지 못했던 사실들을 간접적으로나마 접하면서 점점 확신을 갖게 되는 생각이지만, 구조적 분석 설계 기법(SADT: Structured Analysis & Design Technique)으로부터 시작된 정보 기술 패러다임(IT Paradigm)의 변천사는 이전의 패러다임을 뒤엎는 혁명(revolution)이 아니고 진화(evolution)였다는 사실이다.

문제는 이전의 패러다임에 익숙한 엔지니어들이 새로운 패러다임에 대해 피상적인 용어(glossary)나 개념(concept) 정도 살펴 본 것을 전부인 양 착각하고, 새로운 패러다임에 편승하거나(hitch a riding) 가장하다가(disguise), 또 다른 새로운 패러다임이 등장하면 그 새로운 패러다임을 구식 패러다임으로 간주하고 또다시 새로운 패러다임에 편승하는 국내 IT 업계에 팽배해 있는 뿌리 없는 기회주의(opportunism)가 가장 커다란 문제일 것이다. 혹자들은 MDA가 CBD를 대체하는 또 다른 유행(fashion) 혹은 패러다임이라고 주장하기도 하지만, MDA는 분명히 CBD를 전제로 하면서 제품계열 기술(SPL: Software Product Line)이나 서비스 지향 아키텍처(SOA: Service-Oriented Architecture) 등과 같은 동시대의 다른 패러다임들과 더불어 CBD를, 엄밀히 말하자면, “컴포넌트를 보다 컴포넌트답게” 혹은 제대로 된 컴포넌트를 만들려고 노력하는 이 시대의 선도 엔지니어들이 합의하여 제시하는 미래 소프트웨어 산업계의 비전이다. MDA 개발 패러다임으로의 전환이 IT 업계 특히, 소프트웨어 산업계에 가져올 가장 큰 후 폭풍은 단순한 개발 방식의 변화가 아니라 전반적인 프로젝트 수행 조직의 역할 변화와 시스템 자산에 대한 기업의 인식 변화일 것이다.

마지막으로 어느 MDA 전문가의 이야기를 소개하면서 글을 마무리하고자 한다. MDA 전문가 중의 한 사람인 David S. Frankel은 그의 저서 “Model Driven Architecture-Applying MDA to Enterprise Computing”에서 MDA에 대한 일반인들의 회의적인 시각에 대해서, 예전에 0과 1의 조합으로 프로그램을 작성하던 시절(Machine-centric computing)에 어셈블러(Assembly Language)가 등장하면서 당시에 많은 엔지니어들이 보냈던 회의적 시각에 비유하고 있다. 만약, 지금 당신 주변의 누군가가, 그 당시 많은 엔지니어들이 회의적인 입장을 취했던 바로 그 어셈블러를 가지고 인터넷 기반의 복잡한 업무 처리를 수행해야 하는 고객관리 시스템(CRM)을 개발하겠다고 한다면 여러분은 뭐라고 할 것인가? 저자는 주저 없이 그 답변은 아마도 “제정신이 아니네……”라고 단정하고 있다.

<참고자료>

Evaluating Software Architecture-Methods and Case Studies,” Paul Clements, Rick Kazman, Mark Klein, Addison-Wesley, 2002
Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) Approach-Productivity Analysis,” Research Team, The Middleware Company, June 2003
"Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) Approach-Maintainability Analysis,” Research Team, The Middleware Company, January 2004
"http://hr-xml.org/channels/home.htm
"Model Driven Architecture-Applying MDA to Enterprise Computing,” David S. Frankel, OMG Press, Wiley Publishing Inc, 2003

* 이 글은 마이크로소프트웨어 2004. 8월호 "특집 소프트웨어 개발 패러다임의 진화 3-1부"에 게재된 내용입니다.