새로운 IT 패러다임이 등장할 때마다 현기증을 느낀다. 특히 소프트웨어 개발 업계에 막 입문한 사람보다는 나름대로 경험과 노하우를 가지고 있고 실질적으로 새로운 작업을 추진할 만한 위치에 있는 엔지니어일수록 그런 현상이 더욱 심한 것 같다. 국내의 가장 전형적인 SI 업체의 R&D 팀에 소속된 필자의 경우도 꼭 그런 상황이다. 이 글에서는 최근 이슈가 되고 있는 MDA를 필자가 속한 회사가 전문 개발 영역인 ‘인사관리 업무’ 도메인에 도입해, 그것을 조직의 소프트웨어 개발 생산성 향상으로 접목시키려고 노력하고 있는 과정에서 겪었던 그리고 앞으로 겪을 것으로 예상되는 문제점들과 그 해결 방안을 담담히 정리해 본 것이다.
현재 필자가 근무하는 회사에서는 지난 2003년을 전후해서 제대로 만들어진 컴포넌트든 혹은 컴포넌트가 아니더라도 무엇인가 실질적인 소프트웨어 생산성을 끌어 올릴만한 묘안이 절실히 필요했다. 2～3년 전만 해도 그 묘안은 CBD 혹은 컴포넌트였고 현재도 그러한 사실에는 변함이 없다. 필자의 조직은 그러한 컴포넌트 패러다임이 이슈로 등장하던 시절 초기에 나름대로 사활을 걸었고 CBD 사상에 전력투구했던 덕에 지금까지 업계에서 CBD에 관한 기술 선도 업체로서 인정받으면서 영업적으로나 마케팅적으로 그 효과를 보고 있는 것이 사실이었다. 하지만 컴포넌트가 가져다 줄 것이라고 믿었던 본질적인 소프트웨어 생산성 효과보다는 오히려 그 이면에 깔린 마케팅적인 대외 홍보 효과가 더 주효했던 것이 부정할 수 없는 사실이기도 하다. 이 글에서는 CBD 이후에 새롭게 주목받고 있는 MDA 패러다임을 필자가 속한 R&D 팀을 중심으로 조직에 접목하게 된 배경을 비롯해 도입하는 과정에서 겪었던 문제들과 이를 해결하기 위해 고심했던 방안들을 이야기하고자 한다.
MDA 도입 배경
2003년을 전후해서 필자의 회사는 꾸준히 프로젝트를 수주해 그 수가 증가했고 더불어 규모나 기간도 상대적으로 커지고 길어졌다. 어느 회사에서나 그러하듯이 전통적인(?) 대처 방식, 즉 새로운 개발자를 내부 직원으로 충원하거나 임시방편으로 외부 인력을 조달하면서 프로젝트를 진행했다. 하지만 시스템의 납기가 자의반 타의반 연장되면서 그로 인한 기회비용 손실은 말할 것도 없고 회사가 ‘울며 겨자 먹기’ 식으로 어쩔 수 없이 떠안아야 하는 재정적 부담은 이루 말할 수 없었다. 회사의 재정을 관리하는 관리 부서를 중심으로 볼멘소리가 터져 나오기 시작했다. ‘대형 SI 업체들의 프로젝트 저가 수주 전략(?)이라는 육탄 세례 속에서, 이미 탁상공론을 넘어 저 먼 외국 사례로 인용되고 있는 정통부나 과기처의 소프트웨어 개발 단가표는 고사하고, 우리가 무슨 떼돈 벌겠다고 하는 것도 아닌데…’ 근본적인 해결책이 없는 가운데 프로젝트를 계속해서 수주하는 것이 관리부서 입장에서는 기쁜 일만은 아니었다. 사실 이에 대해서는 중소 SI 업체에서 할 말이 많을 것이다. 대형 SI 업체의 프로젝트 저가 수주는 곧 중소 하청 SI 업체가 고스란히 떠안아야 할 부담이 된다는 것은 자명한 사실이다.
실제 현장(site)에서 프로젝트를 수행해 보면 그런 소리 못한다고 현장에서 겪는 고초를 하소연하던 개발팀에서도 점차 자성의 목소리가 흘러 나왔다. 당장 촉박하게 프로젝트를 종료하기 위해 몸부림치던 당시에는 못 느꼈지만 막상 프로젝트를 마무리하고 본사로 철수하거나 다른 현장으로 투입된 초기에 가만히 앉아서 살펴보면, ‘저쪽 고객사에서 요구했던 것이나 이쪽 고객사에서 요구하는 것이나 크게 차이가 나지 않는데 왜 그렇게 프로젝트를 마무리하기 어려운 것일까?’ 머리를 갸우뚱거리게 된다.
고객의 요구사항이 수시로 바뀌는 것이야 어제 오늘의 이야기가 아니겠지만 인터넷 기반의 시스템 개발이 보편화되면서 특히 그런 요구사항 변경이 더욱 시스템 개발을 어렵게 한다는 너무나도 단편적인 원인으로 그 탓을 돌리는 것도 한편으로는 이해가 가지만 어쨌든 SI 업계에서 수행하는 시스템 개발 프로젝트에서의 소프트웨어 생산성 문제는 상대적으로 대형 업체에 비해 중소 업체 입장에서는 사활이 걸린 중대 사안일 수밖에 없다. 가령 프로젝트를 계획대로 종료하지 못하고 납기일이 연장되면 수금이 지연되고 이는 곧 인건비 부담으로 직결되며 자금 사정이 여유롭지 못한 중소 업체 입장에서는 여간 부담스러운 것이 아닐 수 없다.
MDA 도입 과정
‘Evaluating Software Architecture-Methods and Case Studies’라는 책을 보면 소속 조직에 새로운 기술이나 패러다임을 도입하기(ATAM 기법) 위한 아주 세부적인 전술을 제시하고 있다. ROI 분석에서부터 조직 내에서 동조자를 끌어들이고 의사결정권자를 설득하기 위한 세세한 조언까지 아끼지 않고 있다. 그러한 아이디어를 접목하여 필자의 조직에 MDA를 도입했던 과정을 차근차근 살펴보기로 한다.
경영진의 설득
앞선 MDA 도입 배경에서 살펴본 상황으로부터 쉽게 유추할 수 있겠지만 필자의 조직에서는 일단 어떠한 형태로든 돌파구가 필요한 상황이었다. 경영진들 입장에서의 압박감은 그 상황이 더욱 심각하게 고려되었다. MDA 이전에 가장 활발하게 이슈가 되었던 컴포넌트에 관해서는 조직 내부에서조차 그 효용성에 대해 다소 회의적인 시각들이 팽배해 있었고 이는 곧 IT 업계에서 시기마다 발표되는 패러다임 혹은 기술이라는 것에 대한 부정적인 시각으로 확대 해석되고 있는 상황이었다. 그렇다고 컴포넌트 패러다임을 부정하면서 그것을 대체할 수 있는 패러다임이라고 MDA를 부각시키는 것은 타당성이 없어 보였다.
사실 MDA는 CBD를 대체하는 패러다임이라기보다 오히려 CBD 사상에 근거한 소프트웨어 개발의 단위인 ‘컴포넌트를 보다 컴포넌트답게’ 시스템 개발 초기에 모델이라는 형태로 만들고 향후에도 그 수준에서 재사용해 보자는 것이 근본 취지였기 때문에, 물리적인 실행 파일 수준 컴포넌트 개념에서 모델 수준 컴포넌트 단위로의 형태론적(syntax) 변화일 뿐 컴포넌트의 전면적인 부정은 아니다.
필자는 그러한 사실을 지속적으로 조직 구성원, 특히 조직의 방향성에 대한 결정권을 가지고 있는 경영진들에게 전달하고 그러한 MDA 접근법이 보편화됐을 때 예상할 수 있는 시스템 개발 방식의 변화 등을 설명하려고 노력했다. 그리고 보다 현실적인 측면에서 필자의 조직에서 활발하게 활용하고 있는 모 업체의 CASE 도구 속에서 그러한 MDA 사상을 접목시키고자 노력하고 있는 모습, 즉 추가하고 확장하는 기능들이나 기술들을 예로 들면서 앞으로 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’ 보고서는 매우 설득력 있는 자료로 활용할 수 있었다.
수행 조직 결정
국내의 영세한 SI 업계 상황을 고려할 때, 굳이 MDA가 아니더라도 고객의 명시적인 요구사항으로 제시되거나 모험을 감수해야 하는(?) 신생업체가 아닌 이상 일반 중소 SI 업체 입장에서는 특정 패러다임이나 기술에 대한 전문가가 부재한 상황에서 지금까지 쌓아온 개발 노하우나 방식을 전면적으로 뒤엎으면서까지 새로운 패러다임이나 기술을 전면적으로 도입하는 일은 일종의 도박일지도 모른다. 그것도 당장 법적으로 납기일이 명시된 현장에서 도입한다는 것은 더욱 불가능하다.
R&D 팀의 성격상 당장 고객들에게 무엇인가 보여줘야 하는 개발팀들과는 달리 필자 조직의 R&D 팀은 2～3년 전에는 CBD, 그리고 이번에는 MDA와 같은 새로운 기술 혹은 패러다임을 접하고 그것을 조직의 새로운 패러다임으로 접목할 임무를 수행하기로 결정했다(참고로 필자의 조직은 일반적인 관리 부서를 제외하고 고객사를 대상으로 전면에서 프로젝트를 수행하는 2개의 개발팀과 1개의 R&D 팀으로 구성되어 있다). 그것은 R&D 팀의 특정상 어쩌면 당연한 임무이자 역할이기도 하다.
하지만 관행적으로 SI 업체 R&D 조직의 보편적인 역할은 해당 업체에서 수행하는 여러 프로젝트에서 공통으로 사용하거나 상대적으로 난이도가 있는 모듈 혹은 컴포넌트 개발 및 유지보수를 전담하거나 프로젝트 초기 전반적인 시스템 아키텍처 설계 정도에 한정되는 것이 보통이다. 필자의 R&D 팀이 조직 내에서 수행하는 역할도 그런 R&D 팀의 보편적인 역할과 크게 다르지 않았다. 그러나 그것은 본격적인 작업(?)을 수행하기에는 적합하지 않기 때문에 그러한 문제를 해결하기 위해 내부적으로 R&D 팀 구성원을 추가로 확보하면서 조직 내의 개발팀들을 지원하는 팀과 MDA 기반의 내부 프로젝트를 진행할 팀으로 이원화하는 방식을 채택하는 식으로 역할을 분담했다.
내/외부 공모자 확보
인사관리 도메인 지식을 갖춘 사람과 새로운 기술을 개척할 수 있는 엔지니어를 중심으로 MDA 관련 자료를 회람하면서 정보를 공유했다. 또한 내부적으로 기술적인 측면에서든 인사업무에서든 어느 한 편에 대한 상대적 경쟁력을 갖춘 역량 있는 인력을 R&D 팀으로 합류시키고, 외부적으로는 필자의 R&D 팀에서 MDA라는 새로운 패러다임에 기꺼이 도전하려는 새로운 인력 충원을 적극 고려했다. 설령 그것이 MDA가 아닌 다른 사상이나 기술이라 할지라도 개인적 신념만으로 일을 추진하기에는 너무나도 험난한 것이 사실이고, 최근의 시스템 개발 문제는 조직 내에서 단순히 능력이 뛰어난 몇 명의 컨설턴트나 엔지니어에 의해 주도적으로 수행되기에는 이미 그 규모나 비중이 커졌다는 사실을 반증하는 것이기도 하다.
개발팀과의 마찰 해소 방안
코드 중심의 개발 방식(code-centric development)에 익숙한 개발자에게 당장 눈앞에 직면한 프로젝트에 대해 반드시 MDA를 적용해서 시스템을 개발하라고 강제한다면 그것은 현장에서 고객들과 씨름해야 하는 개발팀원들은 ‘기름통을 들고 불 속으로 뛰어들어라’는 말과 다르지 않게 느낄 것이다. 그래서 일단 MDA 관련된 R&D의 작업 방향에 대해 관심을 내비치는 엔지니어에게는 그저 앞으로의 소프트웨어 개발 방식은 UML을 보다 적극적으로 활용하는 방식으로 진화할 것이며, 그에 대한 각자 나름대로의 대비가 있어야 한다는 정도로만 이슈로 제시하면서 R&D 팀을 중심으로 그러한 준비를 조직적으로 수행하고 있으며 점차 그러한 작업이 실체화되는 시점에 내부 인력을 대상으로 내부 교육이 진행될 것임을 주지시켰다.
그러한 내용을 굳이 개발팀원에게까지 전파하는 목적은 무엇보다도 향후 조직에서 필요로 하는 엔지니어가 되기 위한 실천방안을 사전에 비전으로 제시함으로써 최소한 UML을 활용해 구축된 모델을 접하게 될 시점에 거부감 없이 쉽게 수용하고 수월하게 전환 교육이 이루어질 수 있도록 채비시키기 위함이었다. 그것은 R&D 팀에서 본격적으로 MDA 기반의 시스템 개발 작업을 수행하면서 조직 내부에서 제기될 수 있는 불협화음을 사전에 차단하기 위한 기반 작업이기도 했다.
MDA 실현의 난제와 해결 방안 모색
지금까지 필자 조직에서 MDA라는 전략이 결정된 배경과 그 도입 과정을 간단히 살펴보았다. 이제부터는 더 구체적으로 MDA를 수용하고 필자의 조직에서 목적하는 시스템(여기서는 인사관리 시스템 중심으로)에 접목하는 과정에서 발생했고 앞으로 발생할 것으로 예상되는 난제(issue)들과 그것들을 해결하고자 채택하고 있는 전술에 대해 살펴보자.
전문 도메인 지식 습득
MDA 기반의 인사관리 시스템 개발을 추진하는 수행 조직으로 결정된 R&D 팀 이전 구성원들의 역량은 상대적으로 기술적인 측면에 비해 인사관리라는 비즈니스 측면에 대한 지식이 부족한 상황이었다. 어떠한 도메인이든 MDA 기반으로 제대로 된 시스템 개발을 위해서는 해당 도메인에 대한 전반적이고 체계적인 지식이 필수적인 상황에서 단지 CASE 도구를 활용한 UML 기반의 모델링이 가능하다는 사실은 그저 ‘무엇(business)’인가를 담을 수 있는 ‘틀(technology)’은 갖췄지만, 막상 담아야 할 ‘내용(business)’이 무엇인지는 모르는 형국에 지나지 않았다. 그렇다고 현재 추진 중인 R&D 팀의 MDA 관련 내부 프로젝트의 성격이 조직 내의 다른 개발팀처럼 특정 고객에게 필요한 인사관리 시스템만을 구축해 주고 나면 그 역할이 마무리되는 상황도 아니었다.
그러한 미비점을 보완하고자 일단 R&D 팀과 현장에서 시스템을 구축 중인 개발팀과의 유기적 정보 교류 네트워크를 구축하였다. 일단 R&D 팀에서는 지금까지 필자의 조직에서 수행한 인사관리 시스템 구축 시 활용되거나 작성한 자료를 수집하고 전사적인 차원에서 공통적으로 참고할만한 관련 자료를 정리 및 통합한 후 다시 그러한 내용을 각 개발팀원이 모두 공유할 수 있도록 시스템을 구축했다. 필요한 시점에 R&D 팀에서 각 사이트에서 진행 중인 프로젝트의 상황을 모니터링 하여 필요시에 해당 사이트에 방문하여 추가적인 보완 자료를 수집할 수 있도록 사전에 협조를 요청하였다.
또한 R&D 팀에서 진행하는 인사관리 시스템은 특정 고객사를 대상으로 하는 시스템이 아니기 때문에 개발 현장에서 보편타당하게 수용할 수 있는 제품이어야 하는 특성을 고려해 인사관리에 관한 국내외 표준 자료를 수집했다. 그것은 현재 OMG를 중심으로 특정 도메인에 대한 데이터 교환 표준 규약을 XML 기반으로 구축중인 것과 일맥상통한다. 그러나 아쉽게도 아직 OMG에서 명시적으로 인사관리 도메인에 대한 표준화 작업은 미비한 상태였다. 그런 와중에 외국의 인사관리 관련 업체들을 주축으로 결성된 HR 컨소시엄에서 제시하는 공개된 자료를 발견했고 그곳에서 제안하는 XML 기반의 인사 관련 표준 데이터 스키마와 프로세스를 중심으로 보편타당한 인사 시스템의 비즈니스 아키텍처 작성 작업을 진행했다. 국제적으로 인정할만한 표준을 검토해 시스템 개발에 접목하게 된 것은 회사의 장기적인 비전으로 준비 중인 국제무대로의 진출을 염두에 둔 것이었다. 명시적인 고객이 존재하지 않는 R&D 팀 관점에서 이것은 일종의 고객 요구사항으로 고려되었다.
제대로 된 UML 지식
간혹 필자는 주변에서 현재 OMG에서 준비 중인 UML 2.0 명세 최종 버전이 확정되고, 각 CASE 도구 벤더들이 본격적으로 UML 2.0을 지원하는 시점부터 MDA 기반의 시스템 개발이 가능하지 않겠느냐는 질문을 받을 때가 있다. 그러나 그것은 MDA 관련 참고할 만한 서적을 한번이라도 읽어 본 사람이라면 사실과 다르다는 것을 금방 알 수 있다. 기왕이면 ‘새로운 포도주(MDA)를 새로운 그릇(UML 2.0)에 담는 것’이 좋기는 하겠지만 현재 CASE 도구 벤더들이 표준으로 지원하고 있는 UML 1.4(필자가 글을 쓰고 있는 시점에 UML 2.0을 완벽하게 지원하고 있는 CASE 도구는 없다.
특정 벤더에서는 대외적으로 세계 최초의 UML 2.0 CASE 도구라고 선전하고 있지만, 실제 모든 UML 2.0에서 제시하는 모든 표기법과 다이어그램을 지원하지는 않는다. 무엇보다도 UML 2.0 명세는 현재 최종 초안이 공표되고 최종 심의를 거치고 있는 과정이다)에서도 충분히 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 도구를 필자 조직의 기본 도구로 선정하는 과정에서는 사실 거의 팀 내에서의 이견은 없었다. 무엇보다도 오랫동안 필자의 회사에서는 여러 프로젝트를 수행하면서 어설프게라도 해당 CASE 도구를 기본으로 활용해 작업했던 까닭에 상대적으로 다른 CASE 도구들에 비해 사용자 저변이 많이 확산되어 있는 상황이었다. 향후 MDA 기반의 시스템 개발이 확산되면 기존의 개발 도구나 각종 CASE 도구들에 상대적으로 모델링 CASE 도구에 대한 종속성(dependency)이 커지겠지만 그렇다고 기존의 여타 코딩이나 형상관리(configuration management) 등의 작업에 필요한 도구 그리고 운영 플랫폼들과의 연동이나 통합을 고려하지 않을 수 없었다. 그런 관점에서 보더라도 필자의 조직에서 선정한 모델링 CASE 도구는 나름대로 적절한 선택이었고 최소한 필자 조직에서는 가장 자연스러운 최적의 선택이었다.
엔지니어의 도구 친밀도와 기술적인 측면에 덧붙여 해당 CASE 도구 제작 벤더에 대한 시장에서의 고객 선호도를 고려했다. 고객들의 CASE 도구 선정 경향은 일반적인 엔지니어적인 관점에서의 기술 구현 완성도(completeness)나 기능(functionality) 등에 국한되지는 않는다. 오히려 수치화가 어려운 고객간의 입 소문이라든지, 고객사의 과거 경험이나 주변인의 권유가 많이 작용하는 것이 현실이다. 고객사의 특별한 제약사항으로 제시되는 경우가 아니라면 프로젝트 초기에 개발업체에서 ‘이러이러한 도구들을 중심으로 개발하겠습니다’라는 식의 도구 제안이 들어가게 된다.
고객들은 앞서 언급한 바와 같이 특별한 상황이 아닌 이상 그러한 제안을 수용하는 것이 일반적이다. 무엇보다도 지금까지의 개발 방식에서는 CASE 도구 특히, 모델링 도구가 큰 비중을 차지하지 않았고 더욱이 국내에서 소프트웨어 개발 환경에서의 모델링 도구 위상이란 그저 요식적인 ‘그림 도구(drawing tool)’에 지나지 않게 치부되었습니다. 그것은 곧 고객들이 모델링 도구 선정에 있어 각종 플랫폼 선정 작업에 비해 상대적으로 면밀히 검토하지 않는 원인이 되었다. 그런 현실적인 여건과 상황을 고려하여 필자가 속한 조직에서 선정한 모델링 도구는 도구 제안 시 전반적으로 고객들이 거부감을 느끼지 않을 정도의 도구로 평가될 도구였다.
모델 버전 관리
MDA 기반의 시스템 개발을 추진하게 될 고객 입장에서는 해당 결과물인 각종 모델들과 모델간 전환(transformation)을 위한 메커니즘 구현물(profiles)만을 대상으로 유지보수하는 것으로써 특정 상위 비즈니스 업무가 변경되더라도 상위 모델(PIM) 중심의 수정 작업을 통해 손쉽게 시스템을 재구성하거나 변형할 수 있다. 또한 기존의 형상관리 기법을 그대로 적용하면 손쉽게 조직 내에서 달성해야 할 소프트웨어 생산성 혹은 재사용성이라는 소기의 목적을 달성할 수 있다. 하지만 필자의 조직처럼 특정 업무영역을 특화해 비즈니스 모델 결과물(PIM)을 제작하고, 그것을 다시 재사용하면서 여러 고객 사이트에서 다양하게 변형하거나 커스터마이징 작업을 통해 수익을 창출해야 하는 경우라면 더 복잡한 메커니즘 구현이 필요하다.
이 글을 쓰고 있는 시점을 기준으로 이제 막 MDA를 도입해 시스템 개발을 추진하는 과정 중에 있는 관계로 그에 대한 명쾌한 방안을 제시할 수는 없지만 필자의 조직과 유사한 처지에 있는 상황에서 MDA를 전략적으로 도입하려고 준비하는 조직이라면 반드시 MDA 기반 시스템 개발 초기에서부터 염두에 둬야 할 주요 이슈일 것이다.
지금 현재 그러한 모델의 버전 관리 문제와 관련해서 시스템 설계 시에 고려하는 사안은 일단 인사 도메인에서 단위 비즈니스 프로세스 및 데이터 구조 자체의 비즈니스적인 유연성을 확보하기 위해 단위 업무별 공통성(commonality)과 가변성(variability)을 시스템 설계 초기부터 모델에 반영하고 특정 플랫폼으로의 전환시 해당 전환 규칙(transformation rules)에서 불필요한 요소를 아예 전환이 되지 않도록 제어하는 방식으로 고려하고 있다. 바로 소프트웨어 프로덕트 라인(SPL: Software Product Lines) 접근법이다. 또한 단위 업무(엄밀히 말하면 단위 업무별 비즈니스 모델)뿐만 아니라 전환 규칙(transformation rules) 자체를 형상 아이템(CI: Configuration Item)으로 전환할 것을 염두에 두고 작업을 진행 중이다. 특정 CASE 도구에 종속적일 수도 있겠지만 보다 현실적인 접근법으로써 내부적으로 결정한 CASE 도구에서 제시하는 다양한 형태의 모델 단위 구조와 실제 구현 대상이 되는 인사관리 단위 업무를 매칭시켰다.
특히 필자가 주목하는 사항은 OMG의 MDA 접근법에서 제안하는 프로파일이라는 형태의 전환 규칙(transformation rules)의 조직 자산화(organization's asset) 문제이다. 즉 기존의 전통적인 개발 방식과는 다르게 메타 데이터를 통해 소스(PIM)를 목적 플랫폼(target platform, PSM)으로 전환하는 기술이 궁극적으로는 향후 MDA 기반 개발이 보편화되는 시점에는 필자의 조직과 같은 소프트웨어 개발 및 통합 업체 입장에서는 타사와 차별화될 수 있는 기술력에 대한 실질적인 자산이 될 것이라는 점에 주목하고 있다.
모델 보안 문제
마지막으로 앞선 단락에서 언급한 MDA 기반 기술 개발로 축적되는 모델이라는 새로운 형태의 조직 자산에 대한 보안 문제이다. 가장 중요한 문제이면서도 아직까지 명확한 방안을 생각해내지 못한 이슈이기도 하다. 가령 다른 업계에 비해 상대적으로 IT 업계에서 보편화되어 있는 엔지니어의 잦은 조직 이동 문제를 고려해 보자.
핵심 인력의 이동 문제는 과거에도 그랬고 향후에도 해당 인력의 이전(previous) 조직에 결정적인 타격을 줄 것임은 어쩔 수 없다. 하지만 MDA 기반의 개발 방식이 보편화 되는 시점에서의 핵심 인력 유출은 지금의 코드 중심의 개발 방식 시절에 비해 상대적으로 상당한 수준의 기술 자산 유출로 이어질 것임은 너무도 자명하다. 개발 소스나 자료의 보안 관리가 허술하게 이뤄지고 있는 국내 프로젝트 관리 실정을 고려하면 심히 염려되지 않을 수 없다.
가령 코드 중심의 개발 방식에서는 어떤 엔지니어가 이전 직장에서의 프로젝트에서 활용했던 아무리 잘 작성된 소스코드를 가지고 있다고 해도 막상 유사한 새로운 프로젝트에 적용하려면 소스 내부를 수정하지 않고서는 거의 재사용이 불가능한 것이 일반적이다. 반면 MDA 기반의 개발 방식에서는 소스 레벨보다 상위 추상화 수준(level of abstraction)에서 약간의 수정만으로도 지금까지 상상할 수 없었던 수준의 소프트웨어 재사용이 가능하고 이는 곧 해당 엔지니어의 역량으로 평가될 수 있을 것이기 때문이다.
모델이 아니더라도 기업의 보안 문제는 단순히 기술적으로 해결할 수 있는 문제가 아니라 사회의 제도적인 장치 마련이나 기업 문화의 성숙 등과 같은 복합적인 해결 방안이 강구돼야 할 사안으로 생각된다. 조직의 MDA 모델 자산의 보안 문제는 바로 그러한 맥락에서 그 해결 방안을 고려해야 하고 MDA 도입을 고려하고 있는 조직에서는 반드시 염두에 둬야 할 이슈가 아닐 수 없다. 태양이 밝게 빛날수록 이면에 드리우는 그림자는 더욱 짙어지는 것처럼 MDA가 갖는 장점들 이면에는 지금 언급한 모델 보안 문제 수준이 아니라 어쩌면 우리가 예상치 못한 결정적인(critical) 부작용들이나 난관이 반드시 파생되리라 생각된다.
패러다임의 진화, 컴포넌트를 더 컴포넌트답게
종종 국내 IT 업계 원로 중의 한 분이신 필자가 근무하는 연구소의 연구소장님으로부터 예전의 구조적 프로그래밍이 팽배했던 시절 이야기나 그 원리 그리고 당시의 사회적 분위기에 대해 들으면서 놀라움을 금치 못하곤 한다. 필자의 미천(?)한 경험 탓이기도 하겠지만 이전의 패러다임에 대해 미처 제대로 경험하지 못했던 사실들을 간접적으로나마 이해하면서 점점 확신을 갖게 되는 것이 있다. 바로 구조적 분석 설계 기법(SADT: Structured Analysis & Design Technique)으로부터 시작된 정보 기술 패러다임의 변천사는 이전의 패러다임을 뒤엎는 ‘혁명(revolution)’이 아니고 ‘진화(evolution)’였다는 사실이다.
국내 IT 업계의 문제는 이전의 패러다임에 익숙한 엔지니어들이 새로운 패러다임에 대해 피상적인 용어나 개념 정도 살펴본 것을 전부인 양 착각하게 된다. 또한 새로운 패러다임에 편승하거나 가장하다가 또 다른 새로운 패러다임이 등장하면 그 패러다임에 너무 쉽게 편승한다면 이는 뿌리 없는 기회주의(?)가 아닐까 싶다. 혹자는 MDA가 CBD를 대체하는 또 다른 유행(fashion) 혹은 패러다임이라고 주장하기도 하지만 MDA는 분명히 CBD를 전제로 하면서 소프트웨어 프로덕트 라인(SPL: Software Product Line)이나 서비스 지향 아키텍처(SOA: Service-Oriented Architecture) 등과 같은 동시대의 다른 패러다임들과 더불어 CBD를 엄밀히 말하면 ‘컴포넌트를 더 컴포넌트답게’ 혹은 제대로 된 컴포넌트를 만들려고 노력하는 이 시대의 선도 엔지니어들이 합의해 제시하는 미래 소프트웨어 산업계의 비전이다. MDA 개발 패러다임으로의 전환이 IT 업계 특히 소프트웨어 산업계에 가져올 가장 큰 후폭풍은 단순한 개발 방식의 변화가 아니라 전반적인 프로젝트 수행 조직의 역할 변화와 시스템 자산에 대한 인식 전환일 것이다.
마지막으로 OMG의 MDA 작업에 깊이 관여했던 전문가 중의 한 사람인 데이비드 프랑켈(David S. Frankel)의 의미심장한 일화를 소개하면서 이 글을 마무리하고자 한다. 그의 저서 ‘Model Driven Architecture-Applying MDA to Enterprise Computing’에서 데이비드는 MDA에 대해 현재 많은 엔지니어들이나 일반인들이 보이는 회의적인 시각을, 예전에 0과 1의 조합으로 작성하는 머신 코드로 프로그램을 작성하던(Machine-centric computing) 것이 일반적이었고 당시에는 혁신적인 어셈블러(Assembly Language)가 제안됐던 시절에 비유하고 있다. 당시에 많은 엔지니어들은 ‘어떻게 어셈블러와 같은 고급 언어(high-level language)로 프로그램을 작성할 수 있느냐’ 혹은 ‘엔지니어들은 절대 어셈블러를 개발 언어로 받아들일 수 없을 것이다. 프로그램을 제대로 작성하려면 머신 코드로 작성해야지…’라며 어셈블러에 크게 주목하지 않았다.
그러나 어셈블러는 엄연히 당대를 주름잡는 개발 언어로서 소프트웨어 공학사에 큰 족적을 남겼다. 세월이 흘러 인터넷 기반 시스템 개발이 보편화되고 있는 요즘 만약 여러분의 주변에 있는 어떤 엔지니어가 지금은 거의 특정 분야에서만 한정적으로 사용하고 있는 어셈블러를 가지고 고객관리(CRM: Customer Relationship Management) 시스템과 같은 인터넷 기반의 복잡한 업무 처리 시스템을 개발하겠다고 한다면 여러분은 과연 그 엔지니어에게 뭐라고 할 것인가? 데이비드는 주저 없이 그 답변에 대해 ‘제 정신 아니네”라고 단정하고 있다. @
