[DT 시론] 애자일 방법론과 SW개발
이바 야콥슨 이바야콥슨컨설팅인터내셔널 회장

입력: 2007-02-16 15:08


소프트웨어(SW) 개발방법론 분야에서 SW엔지니어링 진영과 애자일(Agile) 진영의 논쟁은 끊이지 않고 있다. SW엔지니어링의 대표적인 방법론은 RUP(Rational Unified Process)이며, 애자일 진영은 SCURUM, XP를 들 수 있다.

이 두 접근방식이 상이한 방법으로 이뤄져 있다보니 이런 논쟁을 부추기는 측면이 있다. 하지만 두 방법론을 뒷받침하는 핵심적인 아이디어상호보완적이다. 따라서 중요한 것은 어떻게 두 방법론의 장점을 잘 조화시켜 나가는가 하는 점이다.

SW 업계 종사자들은 변화를 좋아한다. 이런 방법론을 썼다가 다른 방법론에 심취하는 등 극과 극을 달리기도 한다. 어떤 이들은 항상 새로운 시도를 하지만 끊임없이 쏟아지는 새로운 방법론에 회의를 갖기도 한다. 우리 주변에서는 통합모델링언어(UML)로 모델링했다가 애자일 방법론이라는 또다른 극단으로 몰려가는 것을 쉽게 볼 수 있다. 요즘 신세대 개발자들은 애자일 방법론에 심취해 있고, 고참 개발자들은 RUP에서 애자일 방법론으로 선회하기도 한다.

과연 이런 극단적인 변화는 옳은 것인가. 애자일 방법론만이 민첩성을 보장해주는가. 필자는 애자일 방법론에 대한 잘못된 이해가 이같은 불필요한 논쟁을 불러일으킨다고 생각한다. 오늘날 민첩하지 않은 방법론을 좋아할 사람은 없다. 필자 역시 애자일 방법론의 열렬한 팬이다.

지난해 3월 영국에서 애자일 분야의 전문가들과 함께 패널 토론에 참여한 적이 있었다. 이 패널을 기획했던 사람은 내가 애자일 방법론에 대해 반대 의견을 내기를 바랬던 모양이다. 하지만 그들의 예상은 빗나갔다. 청중들은 패널 참석자들에게 애자일 방법론이 무엇인지에 대해 정의해달라고 했다. 자칭 애자일리스트(agilest)들은 가장 중요한 특징으로 반복 개발을 제시했다. 하지만 이는 잘못이다. 반복개발은 RUP의 핵심 프랙티스 중 하나이자 기본사상이다. 그런데 RUP를 비판하는 애자일 진영에서 반복개발을 자신만의 중요 특징이라고 주장하는 것은 문제가 있다.

애자일 방법론은 세 가지 특징을 지니고 있다. 우선 애자일 방법론은 어떻게 하나의 팀으로 일할 것인가, 어떻게 사람들을 고무시킬 것인가, 어떻게 협동할 것인가에 대한 사회공학이라는 점이다. 이는 가장 중요한 특징이자 다른 방법론과 차별화하는 요소이기도 하다.

또 애자일 방법론은 가벼운 프로세스이다. 명시적 지식에 기반한 RUP와 달리 암묵적 지식에 기초하고 있다. RUP가 좋은 프랙티스를 서술하고 있는 데 비해 애자일 방법론은 사람들이 좋은 SW를 개발하는 데 필요한 지식을 머릿속에 가지고 있다고 가정한다.

세 번째 애자일 방법론은 새로운 기술 프랙티스를 거의 제시하지 못하고 있다는 점이다. 이 점이 애자일 방법론의 가장 약한 부분이다. 반복적 및 점진적 개발(iterative and incremental devELOpment)은 새로운 아이디어가 아니다. 사용자 스토리는 단순화된 유즈케이스의 일종이다. 굳이 예를 들자면, `테스트 주도 개발' 정도가 흥미로운 새 아이디어라고 할 수 있다. 애자일 방법론의 기술 프렉티스가 시시하다는 것을 말하려는 것이 아니다. 만약 애자일 방법론이 단지 이런 아이디어로만 구성돼 있다면 우리가 이 방법론에 관심을 가질 이유가 없었을 것이라는 점이다.

SW엔지니어링과 애자일 방법론은 SW개발의 다른 측면들을 다루고 있다. 전자가 기술 프랙티스에 관한 것이라는 것이면, 후자의 장점은 사회공학이라는 점이다. 따라서 상호보완적이다. 문제는 이 둘의 장점만을 취할 수 있느냐는 점이다. 물론 가능하다. 두 방법론의 기술 프랙티스도 공존할 수 있다.

이를 위해서는 프랙티스에 대한 새로운 개념을 정립할 필요가 있다. 프로세스는 프랙티스의 조합일 뿐이다. 따라서 기존의 수동적이고 획일화된 거대한 2세대 프로세스를 논하기보다 능동적이면서도 프랙티스 중심적인 3세대 프로세스에 주목해야 한다.

출처 : http://www.dt.co.kr/contents.html?article_no=2007021602012369631001
by 수시아 | 2009/07/10 18:00 |  ▷ Agile | 트랙백(2) | 덧글(2)
RUP & XP

문) RUP 의 특징 및 RUP의 한계점과 이를 극복하기위한 방안으로 XP를 부분적으로
    도입하는 방안을 제시하시오.


답)

1. 기존 SW개발방법론의 한계점
  가. SW개발방법론의 발전과정
       <전통적>           <개선적>     <혁신적>
       구조적/정보공학 -> OOP/CBD   ->  ASD방법론
       메소드1            RUP           XP
  나. 전통적 SW개발방법론의 한계점 
    1) 초기 요구사항 도출의 어려움
    2) 변화사항에 대한 수용 및 관리 어려움


2. 전통적 SW개발방법론의 한계점을 극복하기 위한 RUP
  가. RUP의 특징
       아키텍쳐중심
       4+1 뷰
       점진적 반복적 모델
       위험관리중심
       도구기반 방법론
  나. 한계점
       계획시점 : 계획에 대한 장시간 소요(작성, 승인등)
       분석/설계시점 : 구현 제약사항 미고려, 설계중심
       구현시점 : 코드에 대한 보증 어려움, 개발자 중심
       테스트시점 : 테스트 기법 및 중요성 미인식
       릴리즈시점 : 릴리즈 시점에 오류 사항 보완 어려움
       프로젝트통제 시점 : 산출물과다, 관리통제 위주 인력상주

3. RUP의 한계점을 극복하기 위한 XP도입방안
  가. XP의 특징
      - 사람중심
      - 코드중심
      - 테스트중심
      - 혁신적 변화수용
  나. XP 부분적 도입을 통한 RUP 한계점 극복방안
       계획시점 : 계획시간 최소화 및 릴리즈계획 우선 고려
       분석/설계시점 : 테스트/코드중심설계 -> 최소화,
                       변화사항에 대한 적극 대처 -> 위험관리
       구현시점 : 코드구현을 위한 패어프로그래밍, 리팩토링
       테스트시점 : 현업참여를 통한 테스트 수행
       릴리즈시점 : Small Release 및 통합
       프로젝트통제 : 산출물 최소화(자체 표준 결정), 관리인력 최소화

4. XP를 통해본 SW개발방법론의 향후 발전방향
  가. 개발방법론별 장단점에 대한 이해와 Tailoring
    - 개선전, 혁신적 방법론이 무조건 좋은 것은 아니며, 장단점 분석이 필요
    - 프로젝트상황에 맞게 적절한 Tailoring 중요 : 프로젝트 규모, 상황, 고객성향등
  나. 실무중심적 개발방법론의 연구
    - 실무에 기반하지 않은 이론적인 개발방법론은 현장통용이 힘든 것이 사실임
    - 실무현장의 문제점을 개선할 수 있는 Light한 개발방법론도 필요함.
  다. 관리자입장이 아닌 사람, 개발자 중심의 개발방법론에 대한 연구
    - 현재 개발방법론이 상위 관리자 중심의 개발방법론으로 적용되는 사례가 많음.
    - 사람중심(고객/개발자)의 개발방법론을 위한 연구 필요.

* 이런 문제는 너무 어렵게 풀려고 생각하지 말고, RUP 의 문제점을 부각시키고
  XP 를 통한 해결책을 제시하는 방법으로 서술함.
  RUP 의 문제점을 각 절차별로 설명하며, XP 를 통한 해결 사항도 절차별로 기술함.
  2단락에서 RUP 의 특징및 한계점을 설명하고, 3단락에서 XP의 특징 및 해결점을 설명함.
  4단락은 XP 를 통해서 SW 개발 방법론의 발전 방향에 대해 기술함.


출처 : http://youngok.egloos.com/1084427

by 수시아 | 2009/07/10 17:53 |  ▷ Agile | 트랙백 | 덧글(0)
사례로 보는「MDA 도입의 장단점」
사례로 보는「MDA 도입의 장단점」
박경민 (화이트정보통신) kmpark@win.co.kr
2004.10.14 / AM 09:23

새로운 IT 패러다임이 등장할 때마다 현기증을 느낀다. 특히 소프트웨어 개발 업계에 막 입문한 사람보다는 나름대로 경험과 노하우를 가지고 있고 실질적으로 새로운 작업을 추진할 만한 위치에 있는 엔지니어일수록 그런 현상이 더욱 심한 것 같다. 국내의 가장 전형적인 SI 업체의 R&D 팀에 소속된 필자의 경우도 꼭 그런 상황이다. 이 글에서는 최근 이슈가 되고 있는 MDA를 필자가 속한 회사가 전문 개발 영역인 ‘인사관리 업무’ 도메인에 도입해, 그것을 조직의 소프트웨어 개발 생산성 향상으로 접목시키려고 노력하고 있는 과정에서 겪었던 그리고 앞으로 겪을 것으로 예상되는 문제점들과 그 해결 방안을 담담히 정리해 본 것이다.

현재 필자가 근무하는 회사에서는 지난 2003년을 전후해서 제대로 만들어진 컴포넌트든 혹은 컴포넌트가 아니더라도 무엇인가 실질적인 소프트웨어 생산성을 끌어 올릴만한 묘안이 절실히 필요했다. 2~3년 전만 해도 그 묘안은 CBD 혹은 컴포넌트였고 현재도 그러한 사실에는 변함이 없다. 필자의 조직은 그러한 컴포넌트 패러다임이 이슈로 등장하던 시절 초기에 나름대로 사활을 걸었고 CBD 사상에 전력투구했던 덕에 지금까지 업계에서 CBD에 관한 기술 선도 업체로서 인정받으면서 영업적으로나 마케팅적으로 그 효과를 보고 있는 것이 사실이었다. 하지만 컴포넌트가 가져다 줄 것이라고 믿었던 본질적인 소프트웨어 생산성 효과보다는 오히려 그 이면에 깔린 마케팅적인 대외 홍보 효과가 더 주효했던 것이 부정할 수 없는 사실이기도 하다. 이 글에서는 CBD 이후에 새롭게 주목받고 있는 MDA 패러다임을 필자가 속한 R&D 팀을 중심으로 조직에 접목하게 된 배경을 비롯해 도입하는 과정에서 겪었던 문제들과 이를 해결하기 위해 고심했던 방안들을 이야기하고자 한다.

<그림 1> MDA 도입 메커니즘

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) 시스템과 같은 인터넷 기반의 복잡한 업무 처리 시스템을 개발하겠다고 한다면 여러분은 과연 그 엔지니어에게 뭐라고 할 것인가? 데이비드는 주저 없이 그 답변에 대해 ‘제 정신 아니네”라고 단정하고 있다. @


출처 : http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039130836
by 수시아 | 2009/07/08 17:26 |  ▷ MDA | 트랙백 | 덧글(0)
CBD(Component Based Development)
Is Component?
독립적으로 실행가능하며 표준 인터페이스를 갖추고 소프트웨어의 대처가능성, 재사용성, 기능적 독립성을 갖춘 소프트웨어 집합
Component의 특징
- 컴포넌트는 독립적인 단위의 소프트웨어 모듈이며 인터페이스를 통해 접근 가능
- 컴포넌트는 구현(Implementation), 명세화(Specification), 표준(Standard), 패키지(Package), 독립적인 배포(Deployment)가 가능하다.
- 하나 이상의 클래스로 구성될 수 있으면 다음 4가지로 구분할 수 있다.
분산 컴포넌트
EJB, CORBA, COM+ 등 분산 객체 환경 지원 컴포넌트
비즈니스
컴포넌트
물리적으로 배포할 수 있는 독립된 하나의 비즈니스 개념을 구현한 컴포넌트
확장 비즈니스
컴포넌트
확장을 고려하여 설계된 Business Component의 집합으로 그룹형태로 재사용이 가능한 항목의 집합체
시스템 컴포넌트
비즈니스 가치를 제공하기 위해 같은 일을 하는 시스템 수준의 컴포넌트들의 집합
컴포넌트 재사용의 장점
- 소프트웨어 개발기간 단축, 개발비용 감소, 생산성 증대 효과
- 테스트된 컴포넌트 사용으로 리스크 감소, 비즈니스 규칙을 적용한 일관성 확대
CBD의 정의
테스트가 완료된 소프트웨어 컴포넌트를 조립하여 사용자의 요구에 맞는 응용 소프트웨어를 만드는 방법으로 전통적 개발방법론 개념을 수용하면서 새로운 웹 기반 개방형 아키텍쳐를 수용하려는 소프트웨어 공학적인 접근 개발 방법. 기존 객체지향 분석/설계에서 상속을 제외하고 인터페이스 중심의 접근을 강화한 재사용 프레임웍을 수용하는 방법론
“CBD = CD+CBSD(컴포넌트 개발+컴포넌트 적용 응용개발)”
CBD의 특징
- 비즈니스 라이프사이클 타임에 적절히 대응할 필요가 있을 때 적당
- 빠르게 변화하는 비즈니스 환경에 능동적으로 대처할 수 있다.
- 네트워크 및 통합을 위한 개방형 표준에 따른 정보 시스템간 상호 운용
- Use Case Driven : 이해당사자간 원활한 의사소통을 위해 UML을 적용하며, 비즈니스 영역별로 현실에 맞게 쓰임새 중심의 분석 및 설계단계 지원.
- 아키텍쳐 중심 : 소프트웨어 재사용 및 개발의 생산성을 위해 프로젝트 시작과 함께 목적에 맞게 체계적인 아키텍처 계획을 수립하고 표준화 및 지속적인 개선노력을 병행함.
- 반복과 점진 : 프로젝트 위험을 감소하기 위해 반복계획 수립시 목적을 명확히 하여 위험을 도출하며 계획대로 실행되었는지를 이용자 참여 하에 평가가 이루어짐
CBD방법론의 종류
마르미-III
- 국내 방법론
- 사용자 화면 및 아키텍처 프로토타입을 이요한 위험관리
- 점진적 개발
- UML기반
Catalysis
- UML기반
- 모델링 개념”, “모델링 레벨”, “원칙이 핵심개념
Select Perspective
- 개발 초기에 비즈니스 프로세스 모델링의 중요성을 강조
RUP
- 표준 컴포넌트 개발 방법론
- UML 기반
- 초기 버전은 객체지향 방법론이었으며 버전업이 되면서 CDB방법론 지원
- 아키텍쳐 중심의 개발 프로세스 지원
그외
CBE/e, CBD96, Advisor, MSF/CD, SDS CBD…
CBD 도입전략
- 가능하면 많은 기능성의 서비스를 외부로부터 공급받는다.
- 시험 완료된 검증된 컴포넌트로부터 시스템을 구성한다.
- 비즈니스 측면에서 재사용 전략 수립
CBD 성공요인
- 프로세스 : CBD를 위한 프로세스를 구성하는 활동들과 역할을 명확하게 정의
- 자동화 : 프로세스를 적극적으로 지원하는 컴포넌트 재사용과정의 자동화 도구
- 컴포넌트 : 활용 가능한 시험을 거친 검증된 컴포넌트 카탈로그 확보
- 접근방법 : CBD을 적용하기 위해 기반구조 및 조직문화의 충분한 이해를 전제로 추진
CBD 공정 및 활동
작업단계
공정의 흐름
요구사항 분석
현황평가 및 도메인 분석 à 요구사항정의 à 시스템 구조정의 à 개발계획 수립
분석
반복계획수립 à 유즈케이스 모델링 à UI 프로토타이핑, 유즈케이스 분석(정적/동적 모델)
설계
UI설계, 컴포넌트 정의 à 컴포넌트 설계 à 구현모델설계 à 컨버젼설계
개발
코딩 및 디버깅
구현
배치계획 à 테스트계획/실시 à 시스템 릴리즈 à 사용자교육
분석단계활동
- 해당 반복에 대한 상세 계획 수립
- 구현할 시스템에서 제공해야 할 기능을 고개관점에서 정의
- 핵심 기능 UI 프로토타이핑을 통해 고객에게서 검증
- 비즈니스 엔티티와 사용자와 시스템간의 상호작용 체계를 정의하고 일들의 일관성 검증
설계단계활동
- 시스템에 구현될 화면 레이아웃 정의
- 화면간의 Navigation 및 파라미터 전달 Signature를 정의,
- 컴포넌트 축출기법을 사용한 컴포넌트 식별, 컴포넌트간 연관관계를 정의, 컴포넌트의 재사용가능성 분석
- 상세 클래스 및 시퀀스 다이어그램 작성을 통해 객체의 속성 및 오퍼레이션과 객체간 메시지 전달흐름을 상세 설계
- 기존 컴포넌트를 재사용하기 위한 명세와 재사용에 필요한 Adaptor, Wrapper 명세
개발 및 구현단계활동
- 프로그래밍
- 컴포넌트 명세, 인터페이스 명세, DB설계 내용을 플랫폼에 매칭 시키고 배포단위를 정의하고 물리적으로 구현함.
객체지향 방법론과 비교
구분
CBD
객체지향 방법론
개발프로세스
소규모 단위의 프로젝트로 나누어 반복과 점진 수행
전통적 SDLC를 따르며 개발 품질 향상을 위해 프로토타입 수행 가능
아키텍쳐 측면
프로젝트 시작과 함께 계획 및 표준화 수립 후 지속적 개선
명확한 아키텍쳐 제시 및 표준화가 미흡함
응용개발 기술
컴포넌트 단위의 블랙박스 상태에서 표준 인터페이스 적용(객체지향의 상속개념 없음)
객체지향 언어 적용 중심 프로그래밍(클래스 수준의 상속, 다형성 접근)
SW공학 측면
비즈니스 중점의 소프트웨어 재사용을 통한 생산성 향상
데이터 및 프로세스 융합을 통한 개발 패러다임 변화


출처 : http://mndpjt.egloos.com/1257682
by 수시아 | 2009/07/05 18:47 |  ▷ CBD | 트랙백 | 덧글(0)
SOA 시작하기

SOA 시작하기

 

developerWorks 웹 서비스 존에는 수 백 개의 기술자료, 튜토리얼, 팁이 포함되어 있으며, 개발자들이 웹 서비스 관련 애플리케이션을 만드는데 일조하고 있습니다. 하지만 이 새로운 주제를 시작하는 사용자들에게는 오히려 이 많은 정보들이 부담스러울 수 있습니다. 이 페이지는 웹 서비스를 시작할 방법을 모색하는 개발자들을 위한 장소입니다. 기본적인 웹 서비스 기술이 포함되어 있으며, developerWorks의 관련 기술자료, 튜토리얼과 팁, IBM 교육 서비스, 웹 캐스트, 워크샵, IBM 제품들로 연결됩니다.

 

서비스 지향 아키텍쳐(SOA)

 

SOA(서비스 지향 아키텍쳐)는 정의가 잘된 인터페이스와 서비스들 간 콘트랙트(contracts)를 통해, 서비스라고 하는 애플리케이션의 다양한 기능 단위를 상호 연관시키는 컴포넌트 모델입니다. 인터페이스는 하드웨어 플랫폼, 운영 체계, 프로그래밍 언어에 독립적인 방식으로 정의됩니다. 따라서 다양한 시스템들에 구현된 어떤 서비스라도 일반적이고 통합된 방식으로 인터랙팅 할 수 있습니다.

 

특정 구현에 얽매이지 않은 중립적인 인터페이스를 가졌기 때문에 서비스들간 약결합(loose coupling)으로 알려져 있다. 약결합 시스템의 장점은 기민성과 각 서비스의 내부 구조 및 구현의 변화에 대응할 수 있는 능력을 꼽을 수 있습니다. 반면 강결합(tight-coupling)은 애플리케이션의 다양한 컴포넌트들이 기능과 형식면에서 밀접하게 연관되어 있어 애플리케이션 일부나 전체를 변경할 때 까다롭습니다.

 

약결합 시스템의 필요성은 비즈니스 애플리케이션이 변화하는 환경에 빠르게 적응해야 하는 데서 기인했습니다. 정책, 주력 비즈니스, 비즈니스 포커스, 파트너쉽, 산업 표준, 비즈니스의 본질에 영향을 미치는 관련 요소들은 늘 변화하기 마련입니다. 우리는 이러한 환경에 유연하게 대처할 수 있는 비즈니스를 온 디맨드 비즈니스(On demand business)로 명명하고 있습니다.

 

서비스 지향 아키텍쳐는 새로운 것은 아니고, 다만 지난 십년 동안 출현했던 강결합 객체 지향 모델에 대한 대안 모델이라 할 수 있습니다. SOA 기반 시스템이 개별 서비스가 객체 지향 디자인으로 구현될 수도 있다는 것을 배제하지 않는 반면, 전체 디자인은 서비스 지향입니다. 시스템 내에 객체를 허용하기 때문에 SOA는 객체 기반 이지만 전체가 객체 지향은 아닙니다. 그 차이는 인터페이스에 있습니다. 초기 SOA 시스템의 고전적인 예는 Common Object Request Broker Architecture (CORBA)인데 이는 SOA와 비슷한 개념을 정의하고 있습니다.

 

하지만, 오늘날 SOA는 eXtensible Markup Language (XML)에 기반하여 진보했다는 점에서 차별됩니다. Web Services Definition Language (WSDL)라고 하는 XML 기반 언어로 된 인터페이스를 설명하게 되면서, 서비스는 CORBA의 Interface Definition Language (IDL)보다 동적이고 유연한 인터페이스 시스템으로 옮겨가게 되었습니다.

 

웹 서비스가 SOA를 구현할 수 있는 유일한 방법은 아닙니다. 앞서 설명했던 CORBA도 하나의 방법이고, 따라서 IBM의 MQseries 같은 메시지 지향 미들웨어도 마찬가지 입니다. 하지만 아키텍쳐 모델이 되기 위해서는 서비스 디스크립션 그 이상이 필요합니다. 전체 애플리케이션이 서비스들 간 워크플로우를 어떻게 수행하는지에 대한 정의를 내려야 합니다. 뿐만 아니라 비즈니스 연산 대 비즈니스에서 사용되는 소프트웨어 연산 사이의 변형 포인트를 찾아야 합니다. 따라서 SOA는 비즈니스의 상용 프로세스를 기술 프로세스와 연관시킬 수 있어야 하고, 둘 사이에서 워크플로우 관계를 매핑해야 합니다. 예를 들어, 공급자 역할을 하는 것은 비즈니스 프로세스이고 새롭게 공급된 것을 추가하여 부품 데이터베이스를 업데이트 하는 것은 기술 프로세스이다. 따라서 워크플로우는 SOA 디자인에서 중요한 역할을 합니다.

 

더욱이, 동적 비즈니스의 워크플로우에는 부서들 간 작동 뿐만 아니라, 다른 외부 파트너들의 작동이 포함되어 있어 여러분에게는 제어권이 없습니다. 서비스 레벨 계약과 운영 정책의 형태로, 서비스들 간 관계가 발생하는 방법에 대한 정책을 정의해야 합니다.

 

마지막으로, 계약 조건에 따라 프로세스를 수행한다는 신뢰 속에서 이 모든 것이 작동되어야 합니다. 따라서, 보안, 신용, 신뢰성 있는 메시징은 어떤 SOA에서든 중요한 역할을 합니다.

 

참고자료:

how SOA expands on the Web services vision참조.
IBM vision of Service Oriented Architectures.
New to Web services.
Introduction to Web services and the WSDK V5.1 튜토리얼.
An Executive''s Guide to Web services.

 

서비스 지향 아키텍쳐의 활용

 

SOA의 필요성은 비즈니스 IT 시스템들이 비즈니스 변화에 대해 보다 민첩하게 대처해야 한다는 필요성에서 생겨났습니다. 확정적인 관계를 받아들이지만 융통성 있는 스팩 구현으로 IT 시스템들은 기존 시스템들의 기능을 활용할 수 있고, 앞으로의 변화에 대응할 수 있습니다.

 

예를 들어, 500개의 국제적인 점포망을 소유하고 있는 의류 소매 조직은 패션에 발맞추기 위해서 디자인을 자주 바꾸어야 합니다. 스타일과 컬러 뿐만 아니라 재질, 제조, 운송 부분 까지도 변경해야 합니다. 소매업체와 제조자 간 시스템이 호환되지 않는다면, 한 공급자에서 또 다른 공급자로의 변경은 매우 복잡한 소프트웨어 프로세스가 될 수 있습니다. WSDL 인터페이스는 융통성이 있기 때문에 각 기업들이 그들의 기존 시스템을 유지하도록 하고, 대신 WSDL 인터페이스에 맞추어 새로운 서비스 레벨 계약을 체결하도록 합니다. 소프트웨어 애플리케이션을 모두 재구현 할 필요가 없습니다. 이것은 비즈니스의 수평적 변화로서 파트너와 모든 비즈니스 작동을 변경하는 것입니다. 비즈니스 인터페이스는 약간 변경되고 내부 작동까지는 변경될 필요가 없기 때문에 외부적으로 협업할 수 있는 것입니다.

 

또 다른 형태는 내부 변화(internal change)입니다. 소매업체가 체인 소매점 내에 장소를 빌려 부띠크 판매자에게 제공하기로 결정할 수 도 있습니다. 이것은 점포 내 점포(store-in-store) 비즈니스 모델입니다. 이 기업의 대부분의 비즈니스 기능은 같지만 이제는 새로운 내부 소프트웨어로 임대 계약을 맺어야 합니다. 내부적으로 소프트웨어 시스템은 정비중이더라도 기존 공급자의 시스템과의 인터랙팅에 심각한 영향을 주지 않고 이를 수행해야 합니다. 이 경우 SOA 모델은 그대로 보존되는 반면 내부 구현이 변합니다. SOA 모델에 새로운 상(aspect)이 추가되어 임대 계약에 대한 새로운 책임이 추가되지만, 일반적인 소매 관리 시스템은 변화가 없습니다.

 

내부 변화에 대한 개념을 확대시키기 위해 IT 관리자들은 다른 방식으로 사용될 수 있는 새로운 소프트웨어 구성 방법을 찾을 수 있습니다. 이를 테면, 광고용 임대 포스터 공간이 이에 해당됩니다. 유연한 SOA 모델에서 생성된 새로운 비즈니스 제안은 이 새로운 디자인에 재적용 됩니다. 이것은 SOA 모델의 새로운 결과물이고, 전에는 불가능했던 새로운 기능이라 할 수 있습니다.

 

수직적 변화 역시 가능합니다. 소매업자가 자신의 옷을 판매하던 방식에서 매장내매장 모델을 통해 독점적인 임대 공간으로 옮길 수 있다. 수직적 변화의 경우 SOA 모델의 중대한 재구성이 수반되어야 합니다. 아마도 새로운 시스템, 소프트웨어, 프로세스, 관계들이 필요합니다. 이 경우 SOA 모델의 장점은 애플리케이션과 프로그램의 관점이 아닌 비즈니스 기능과 프로세스의 관점에서 작용하여 비즈니스 기능에 기반하여 추가되고, 변경되고 제거되어야 할 것이 무엇인지를 명확하게 구분할 수 있게 됩니다. 소프트웨어 시스템은 비즈니스 프로세스에 맞춰 구성될 수 있습니다.

 

주지하듯이, 변화와, 이 변화를 받아들이는 SOA 시스템의 능력은 가장 중요한 요소입니다. 개발자에게 그와 같은 변화는 그들의 작업 내부 또는 외부에서 발생할 수 있습니다. 인터페이스가 정의되는 방법과 서로 인터랙팅 하는 방법에 관한한 그렇습니다. 오히려 개발자 보다는 SOA 모델에 대부분의 변화를 일으키는 것은 아키텍트의 역할 입니다. 개발자들이 서비스로 정의된 기능 단위를 만드는데 초점을 맞춘다면 아키텍트와 모델러는 그 단위를 조합하는 것과 Universal Modeling Language (UML)를 통해 일반적으로 표현하는 것과 Model-Driven Architecture (MDA)로 기술하는 것에 초점을 맞추고 있습니다.

 

참고자료:

Service-Oriented Architecture.
benefits of having SOA.
introduction to SOA for managers.

 

SOA의 컴포넌트 기술

 

SOA는 그 자체로 소프트웨어가 함께 놓이는 방식에 대한 추상적 개념입니다. 소프트웨어 형태로 존재하기 위해서는 XML과 웹 서비스로 구현된 보다 구체적인 개념과 기술에 의존합니다. 또한, 보안, 정책 관리, 신뢰성 있는 메시징, 계정 시스템 등이 효과적으로 작동해야 합니다. 분산 트랜잭션 프로세싱과 분산 소프트웨어 상태 관리를 통해 이 부분을 향상시킬 수 있습니다.

 

SOA 서비스와 웹 서비스의 차이는 디자인에 있습니다. SOA 개념은 서비스가 특별하게 인터랙팅 하는 방식을 정확하게 정의하지 않습니다. 단지 서비스들이 서로를 인식하고 인터랙팅 하는 방법만 정의합니다. 프로세스가 수행되는 방법 전략을 정의하는 것과 실제로 수행되는 방법 전략에는 차이가 있습니다. 반면 웹 서비스는 서비스들간 메시징이 인터랙팅 되는 방식에 대한 특정 가이드라인을 제시하고 있습니다. SOA 모델의 전략적 구현은 HTTP를 통해 전달되는 SOAP 메시지에서 일반적으로 볼 수 있습니다. 따라서 웹 서비스는 SOA가 구현되는 방식의 일부라고 할 수 있습니다.

 

SOA는 웹 서비스로 제한되어 있습니다. WSDL로 서비스 인터페이스를 직접 구현하고 XML 메시지와 통신하는 다른 프로토콜은 SOA에 포함될 수 있습니다. CORBA와 IBM의 MQ 시스템들은 SOA에 참여하여 WSDL로 작동하는 새로운 기능을 사용하고 있습니다. 두 서비스가 데이터를 교환하려 한다면 같은 메시징 프로토콜을 사용해야 하지만 데이터 인터페이스는 같은 정보 교환을 허용합니다.

 

모든 메시징을 적절하게 제어하고 보안, 정책, 계정 등을 적용하려면 SOA 아키텍쳐의 그림에 들어갈 새로운 비즈니스 객체가 필요합니다. 이것은 Enterprise Service Bus f(ESB)이고, 제어 서비스들 간 모든 메시지의 흐름과 통역을 맡고 있으며 모든 가능한 메시징 프로토콜을 사용합니다. ESB가 절대적으로 필요한 것은 아니지만 SOA에서 비즈니스 프로세스를 적절하게 관리하는 중요한 컴포넌트입니다.. ESB는 그 자체로 하나의 엔진이거나 많은 피어와 하위 피어들로 구성된 분산 시스템일 수도 있습니다. 개념상으로 Message Queue와 분산 트랜잭션 컴퓨팅 같은 이전 컴퓨터 과학 개념에서 나온 store-and-forward 메커니즘에서 진화한 것입니다.

 

개발자 측면에서 그들이 사용하는 툴은 SOA의 기능에 대해 인지하고 있어야 하고 개발자가 SOA 객체를 사용하여 효과적으로 작업할 수 있도록 해야 합니다. SOA 모델의 디자인 프로세스, 서비스와 서비스 객체의 개발, SOA 애플리케이션의 테스팅이 이에 해당합니다. 따라서 개발자 툴은 Service-Oriented Application Design/Development (SOAD)를 위한 준비를 해야 합니다.

 

참고자료:

New to Web services
The Web Services Conceptual Architecture
Web services Standards database.

 

SOA와 다른 기술의 연관 방법

 

SOA는 다양한 많은 기술들과 인터랙팅 할 수 있지만 여기에서는 중요한 역할을 하는 컴포넌트의 캡슐화와 집합에 대해서 이야기 하겠습니다. 앞서 언급했지만, SOA 서비스는 단순한 객체, 복잡한 객체, 객체들의 집합, 많은 객체들을 포함하고 있는 프로세스, 다른 프로세스들을 포함하는 프로세스, 하나의 결과를 내는 애플리케이션의 전체 집합 등 이 모든 것이 될 수 있습니다. 서비스 밖에서는 하나의 엔터티로 보이지만 내부에서는 필요한 만큼의 복합적 레벨을 포함할 수 있습니다. 퍼포먼스의 관점에서 보면 대부분의 SOA 서비스들은 단순한 객체의 세분성으로까지는 내려가지 않고 큰 컴포넌트의 중간 정도에 더 잘 맞습니다.

 

SOA는 XML과 WSDL을 제외하고는 언어 스팩이 아닙니다. WSDL을 생성하고 인터랙팅 할 수 있는 한 어떤 프로그래밍 언어로도 구현될 수 있습니다. SOAP 그 자체는 절대적 필요조건은 아니지만 일반적인 메시징 시스템입니다. 따라서 SOA의 멤버 서비스들은 WSDL을 지원하는 다양한 프로그래밍 언어와 플랫폼에서 구현될 수 있습니다.

 

Common Object Broker Request Architecture (CORBA) 기반 애플리케이션은 SOA에 인터페이싱을 하기위한 많은 필수 컴포넌트들이 있습니다. CORBA의 Interface Description Language (IDL)은 개념적으로는 WSDL과 비슷하지만 정확하지 않기 때문에 WSDL로 우선 매핑되어야 합니다. 게다가 프로세스와 정책 관리 같은 SOA의 고급 프로토콜이 사용되어야 합니다. 서비스로 표현되는 CORBA 컴포넌트가 SOA 서비스와 인터랙팅 해야 할 경우입니다. CORBA 모델 내에서는 모든 개별적인 하위 컴포넌트들은 전과 같이 작동할 수 있습니다.

 

Object Management Group이 제안하고 다양한 IBM Rational 제품들을 사용하여 구현된 Model-Driven Architecture (MDA)는 보다 추상적인 레벨에서는 SOA의 개념과 강력한 상관관계를 갖고 있습니다. MDA는 어떤 소프트웨어 프로세스든 모델과 메타모델로 정의될 수 있다는 개념에 기반합니다. 따라서 MDA는 플랫폼 상에서 실행될 수 있는 실행파일로 컴파일 될 수 있는 소프트웨어 애플리케이션으로 컴파일 된 모델을 만듭니다. MDA는 서비스 개념과 객체 개념을 구별하지 않지만 모델이 다른 모델의 하위세트로 구성되는 것을 허용합니다. SOA의 핵심 컴포넌트인 BPEL 내의 프로세스 집합과 비슷한 개념입니다.

 

SOA와 웹 서비스는 프로그래밍 언어에 독립적이지만 그 중에서도 자바가 많이 쓰이고 있습니다. 정의가 잘 된 자바 인터페이스와 풍부한 자바로 구현된 다양한 프로토콜은 자바 개발자들이 모델을 구현할 때 도움이 됩니다. 여기에서 자바는 각 서비스의 기능 개발에 중요한 역할을 하고 데이터 객체들과, 서비스 내에서 논리적으로 캡슐화 된 다른 객체들의 인터랙션을 조작합니다.

 

SOA와 웹 서비스의 또 다른 핵심 관계는 자율 컴퓨팅과 그리드 컴퓨팅의 개념입니다. 자율 컴퓨팅 개념은 분산 서비스 아키텍쳐의 관리에 적용되고, 특히 정책과 서비스 레벨 계약을 관리하는데 도움이 됩니다. 게다가 SOA 시스템의 전체적 안정성에도 기여합니다.

 

그리드 컴퓨팅은 두 가지 레벨의 SOA 시스템에 작용합니다. 분산 컴퓨팅 형태로 되어있는 그리드는 분산 특징과 서비스들과의 인터랙션을 활용하여 SOA 애플리케이션을 전산적으로 지원합니다. 이러한 방식으로, 그리드 서비스는 개별 서비스들이 구현될 수 있는 프레임웍이 되는 것입니다. 따라서 SOA 애플리케이션은 그리드 서비스의 소비자가 될 수 있습니다.

 

그리드 자체는 SOA에서 구현 될 수도 있습니다. 이 경우 각 운영 체계 서비스들은 전체 SOA 애플리케이션을 구성하는 멤버가 되는 것입니다. 따라서 그리드의 개별 컴포넌트들은 웹 서비스를 사용하여 통신하고 SOA의 형태로 인터랙팅 합니다. 요약하면, 그리드 시스템은 SOA 그 자체가 될 수도 있고, 그 상단에 구현된 애플리케이션 레벨의 SOA 모델을 제공합니다.

 

 

참고자료:

Key components of a Service-Oriented Architecture.
• developerWorks Rational
• developerWorks XML
developerWorks Java technology content area.
developerWorks Autonomic Computing content area.
A visual tour of OGSA.

 

SOA 시스템 구현하기

 

SOA를 활용할 부분은 소프트웨어 개발 프로세스 뿐만 아니라 비즈니스 개발 프로세스도 포함됩니다. 특정 소프트웨어 서비스를 구현할 수 있는 네 가지 SOA 채택 레벨이 있습니다. 이 모두가 비즈니스 모델을 온 디맨드 시스템으로 변형하는 것입니다. 자세한 정보는 The Four levels of SOA Adoption 기술자료를 참조하십시오.

 

첫 번째 레벨은 가장 간단합니다. 개별 서비스를 구현하는 것이 이 레벨에 포함되어 있습니다. New to Web services에 자세한 자료가 소개되어 있습니다.

 

두 번째 레벨에서, 서비스를 만들 수 있고 비즈니스 기능들을 SOA에 통합할 수 있습니다. 애플리케이션 통합, 정보 통합, 프로세스 통합, 전체 시스템 통합 등의 여러 통합 단계가 있습니다. Migrating to a Service-Oriented Architecture를 참조하시기 바랍니다.

 

세 번째 레벨은 자신의 엔터프라이즈 IT 인프라를 SOA 모델로 변형하는 것입니다. 네 번째 채택 레벨은 비즈니스 모델을 온 디맨드로 변형하는데 초점을 맞추고 있습니다.

 

IT 실무자 관점에서, SOA 애플리케이션을 구현하기 위해서는 일반적으로 네 가지 단계를 거쳐야 합니다: 구현, 전개, 사용, 관리. 구현 단계에서는 비즈니스 모델 또는 프로세스, 소프트웨어 모델과 SOA 모델을 정의합니다. 그런 다음, 일반적인 인터페이스로 재사용 할 수 있는 서비스를 만듭니다.

 

전개 단계에서는 구현된 서비스들을 실행 및 관리 환경으로 배치하는 것입니다. 사용 단계에서는 앞서 정의된 SOA와 소프트웨어 모델에 따라 애플리케이션을 조립하고 소프트웨어 품질과 퍼포먼스, 확장성 같은 비 기능적 사항들을 테스트합니다. 이 정도 진행되면 전개되어 사용자들이 사용할 수 있습니다. 마지막 관리 단계에서는 보안과 사용을 감시 및 관리하고 서비스 레벨 계약과 정책과 비교하여 퍼포먼스를 비교합니다.

 

이상은 SOA의 개념적인 단계입니다. 이 단계와 실제 환경의 단계를 비교하면 SOA 애플리케이션 생성에 개입된 다양한 역할들이 있습니다. 같은 일 또는 여러 팀 멤버, 심지어는 여러 팀들 내에서 역할이 주어집니다. 역할 개념은 Rational Unified Process (RUP)으로 구별되는 역할로 표현됩니다.

 

RUP 역할에는 프로젝트 매니저, 분석가, 아키텍트, 모델러, 개발자, 테스터, 개발 및 운영자 등이 있습니다. SOA는 개념상의 SOA 모델을, SOA 모델과 IT 인프라의 리소스와 비교하여 테스트하는 SOA Modeler 역할을 추가하여 거의 동일하게 매핑하고 있습니다. 개발자는(사용 단계의) 어셈블러로서의 부차적인 역할을 합니다. 개별 서비스들을 이용하여 정의된 모델에 따라 실제 SOA 애플리케이션을 구현하는 것입니다. 이러한 역할들은 SOA를 사용하는 엔터프라이즈 내에 존재하고 있습니다.

 

참고자료:

our Levels of SOA Adoption.
Migrating to a Service-Oriented Architecture, Part 1, Part 2.
Rational Unified Process: Best Practices for software development teams
Speed-start Web Services
Business processes and workflow in the Web services world
BPEL4WS column
From UML to BPEL: Model Driven Architecture in a Web services world explains how Web services can fit into the world of Model-Driven Architectures.

 

SOA 기술력 개발하기

 

정보 분석가, 소프트웨어 아키텍트, 소프트웨어 개발자, 소프트웨어 품질 분석가, 시스템 관리자 등 역할에 따라 기술이 다릅니다. SOA의 개념은 이 모든 역할까지 확장됩니다. 따라서 각 역할이 어떻게 작동하는지에 대해서는 이해해야 합니다. 그 다음에는 각 역할이 갖춰야 하는 기술 개념에 익숙해져야 합니다.

 

정보 분석가와 소프트웨어 아키텍트는 모델 중심 아키텍쳐와 UMM 2.0을 이해해야 합니다. 소프트웨어 개발자와 프로그래머는 웹 서비스와 MQ 그리고 기타 프로토콜의 프로그램 방식의 인터페이스, 보안 인터랙션 방식, 워크플로우 프로세싱 개념을 자세히 알아야 합니다. 품질 분석가와 시스템 관리자는 SOA 프로세스 모델 대 실제 SOA 기능 아키텍쳐 구현에 대한 이해도를 높여야 합니다. 개별 서비스들이 분산 애플리케이션의 전체 퍼포먼스에 미치는 영향에 대해서도 알고 있어야 합니다. 시스템 관리자는 애플리케이션 보안과 신용 모델이 어떻게 작동하는지, 그리고 애플리케이션이 운영 체계와 네트워크 시스템에 영향을 미치는 정책에 어떤 영향을 미치는 지도 알아야 합니다.

 

 

참고자료:

Web Services project roles
Speed-start Web services .
Level 1 SOA Adoption: Implementing Individual Web services.
Level 2 SOA Adoption: Service Oriented Integration.
An introduction to Model-Driven Architecture.
new tutorials.
Rational UML Resource.
discussion forum, IBM WebSphere SDK for Web services, IBM alphaWorks Emerging Technologies Toolkit.

그림 1. 개별 웹 서비스 구현하기 - 핵심 컴포넌트

 

두 번째 레벨인 서비스 지향 통합에서 툴은 다중의 서비스들을 발견하고 이들과 인터랙팅하고, SOA 모델의 기초를 만드는 수단을 제공하는 것으로 옮겨가고 있습니다. 그림 2a는 레벨 2 채택의 핵심 컴포넌트이지만, 그림 2b는 레벨 2에 도움이 되는 추가 컴포넌트 입니다.

 

그림 2a. 서비스 지향 통합 - 핵심 컴포넌트

 

그림 2b. 서비스 지향 통합 - 추가 컴포넌트

 

레벨 2인 엔터프라이즈 중심의 IT 변형에서 IBM은 광범위한 SOA와 웹 서비스 제품을 제공하여 모든 IT 시스템 기능들을 사용할 수 있도록 하고, SOA 시스템의 엔터프라이즈 중심의 관리용 프레임웍을 제공합니다. 그림 3a는 레벨 2 채택의 핵심 컴포넌트와 그림 3b의 추가 컴포넌트입니다.

 

그림 3a. 엔터프라이즈 중심의 IT 변형 - 핵심 컴포넌트

 

그림 3b. 엔터프라이즈 중심의 IT 변형 - 추가 컴포넌트

 

참고자료:

benefits of having an SOA.
IBM Web services site: Implementing Web services.
IBM Web services site: Service Oriented Integration.
IBM Web services site: Enterprise Wide IT Transformation.



출처 : http://tmznfem.egloos.com/11602

by 수시아 | 2009/07/05 18:32 | ▶ 소프트웨어 공학 | 트랙백(1) | 덧글(1)
소프트웨어 개발 방법론 충격진화「MDA」
정지훈 (필자) jhjeong@hanafos.com
2004.10.06 / PM 02:10


[지디넷코리아]
우리가 현재 살고 있는 산업사회에 있어서 가장 중요한 것은 무엇인가? 혹자는 믿음이라고 답할 것이고, 혹자는 밥이라고 답할 것이며, 어떤 사람은 그저 애니메이션이나 실컷 보면서 살 수 있으면 그만이라고 말할 것이다. 무엇이 되었든 개인에게 있어서 틀린 답은 아니겠으나 산업사회의 발전을 위해서 가장 중요한 사회학적인 요인을 하나만 선택하라고 하면 그것은 곧 ‘생산성(productivity)’이 될 것이다. 소위 우리가 말하는 ‘산업혁명’이라는 것도 기실은 생산성의 폭발적인 증대로 귀결될 수 있다.

소프트웨어를 개발하는 입장에서도 이 생산성의 문제는 무척이나 중요하다. 같은 수준의 완성품을 만드는 데 있어서 가능하면 적은 시간과 적은 노동력과 원자재만을 이용하는 방법을 연구하는 것은 그런 측면에서 커다란 의미를 가지는 것이다. 이번 호 특집에서 언급하는 MDA(Model Driven Architecture) 역시 소프트웨어의 생산성과 관련해서 중요한 의미를 가진다.

소프트웨어의 생산성은 어떻게 높아지는가
그렇다면 과연 어떻게 하면 소프트웨어의 생산성을 높일 수 있는가? 이 문제는 비단 최근에 제기되는 문제가 아니다. 물론 과거에 비해 복잡한 시스템 요구사항과 수많은 기술들이 등장하고 있는 근래에 그 중요성이 높아지고는 있으나 이미 소프트웨어 초창기부터 이 문제는 많은 사람들의 고민거리였다고 말할 수 있다. 이 문제를 해결하기 위해서 등장한 대표적인 학문이 바로 소프트웨어 공학이다.

소프트웨어 공학의 영역은 상당히 포괄적이다. 소프트웨어 개발에 투여되는 수많은 자원들의 효과적인 관리 방법과 평가, 그리고 조직과 의사결정 구조, 심지어는 개발자들의 심리상태에 대한 것도 대상이 될 수 있다. 소프트웨어 공학에 대해서 자세한 이야기를 하자면 소프트웨어의 위기에서부터 많은 방법론에 대한 것까지 커다란 연구 분야라고 할 수 있으며, 그 중요성은 최근의 복잡해진 환경에 의해 점점 더 높아가고 있다. 거창하게 소프트웨어 공학을 이야기했지만 소프트웨어 생산성을 높이기 위해 그 동안 시도됐던 몇 가지 방법에 대해서 간단히 이해하는 것이 MDA에 대한 이야기를 풀어나가는 데 도움이 될 것이다.

전통적인 방법론 vs. 창조적 프로그래밍
소프트웨어의 생산성을 높이기 위한 방법으로 그 동안 다양한 방법론과 이론이 등장했다. 이들에 대한 자세한 논의는 한 권의 책으로도 부족할 것이므로 여기서는 대표적인 몇 가지의 특징에 대해서 간단히 알아보기로 하자. 소프트웨어 공학의 정의로 본다면 모든 방법론들이 소프트웨어 공학으로 설명할 수 있겠으나 최근에 각광받는 몇 가지 방법론이 기존의 방법론과는 상당한 철학적인 차이를 보여주고 있기 때문에 여기서는 이들을 포괄적으로 ‘창조적 프로그래밍’으로 표현하고자 한다.

필자의 경우 소프트웨어 공학을 전문적으로 전공한 것은 아니므로 다소의 용어 선택과 학문적인 설명에 있어서는 오류가 있을 수 있으나 MDA를 설명하기 이전에 그 동안의 경험했던 것들을 바탕으로 접근하는 것이 도움이 될 것이라 생각하기 때문에 이 부분을 언급하도록 하겠다. 혹시라도 필자의 글에 대해 다른 의견이 있는 독자는 언제든지 필자에게 메일을 보낸다면 검토 후 다음 기회에 정정하도록 할 것이다.

전통적인 소프트웨어 공학 방법론은 소프트웨어의 개발 단계를 요구, 분석, 설계, 구현, 테스트와 유지보수로 분류하고 각 단계별로 소프트웨어의 생산성에 영향을 주는 여러 요소들을 관리하고 조정해 생산성을 높이는 방법과 절차, 그리고 이를 지원하는 여러 가지 도구 등으로 구성된다. 소프트웨어 개발에 관한 접근 방식에 따라 기능 중심의 개발방법론, 구조적 개발방법론, 객체지향 개발방법론 등이 있으며 최근에 가장 각광받는 것은 객체지향 개발방법론이라고 할 수 있다.

이러한 전통적인 소프트웨어 공학 방법론은 기본적으로 소프트웨어의 개발을 제조업에서의 생산 공정의 연장선상에서 소프트웨어라는 생산 대상의 특성을 고려하여 만들어지기 때문에 공정의 관리와 제어에 초점을 맞추게 되는 경우가 많다. 예를 들면 프로젝트의 관리를 위해 제안서 및 프로젝트 비용 산정, 프로젝트 계획과 스케줄링, 감독과 검토 과정을 거친 뒤 적합한 인력 배치 등을 하고 프로젝트 팀으로 구성된 조직은 조직 관리의 측면에서 최대한의 생산성을 갖출 수 있는 방향을 선택하도록 하는 것이다.

이런 소프트웨어 공학 방법론은 커다란 프로젝트의 위험성을 최대한 관리하면서 기존에 제조업과 사회과학 분야에서 개발된 여러 가지 형태의 도구를 응용할 수 있기 때문에 중간 규모 이상의 프로젝트에서 상당한 효과를 발휘한다. 이에 비해 창조적인 프로그래밍에 중점을 둔 방법론은 기본적으로 소프트웨어의 개발을 제조업에서의 생산 공정으로 보기보다는 개개인의 숨겨진 잠재력을 최대한 발휘해서 조합하는 것을 더욱 중요하게 생각한다. 그러므로 창조적인 프로그래밍에서는 소프트웨어 개발이란 일종의 공동 예술 작품을 완성하는 것과 비슷하다고 간주한다.

모든 방법론을 이러한 잣대로 분류하는 것은 무리이지만 최근에 각광을 받는 XP(eXtreme Programming), 애자일 소프트웨어 개발(Agile Software Development) 등의 방법론은 기존의 방법론에 비해 이러한 특성의 중요성을 많이 인정하고 있다. 필자는 개인적으로 이러한 두 가지 방법론을 모두 시험해 보았는데 어느 한 쪽의 방법론이 더 우월하다고 말하기는 어렵지만 전반적으로 프로젝트의 규모가 커지고 개발 인원의 수준의 차이가 많이 나는 구성원을 가질수록 전통적인 소프트웨어 개발 방법론이 효과적이며, 반대로 소규모 프로젝트이면서 개발 인원의 수준의 차가 적고 쌍방의 대화가 잘 이뤄질 수 있는 그룹이라면 창조적인 프로그래밍 방법론이 훨씬 효과적이었다.

소프트웨어 개발방법론에 관심이 있는 독자라면 시중에 좋은 책들이 많이 나와 있으므로 이들을 참고하면 큰 도움이 될 것이다. 전통적인 소프트웨어 공학적인 방법론은 교과서도 많이 나와 있고 방법론 자체에 대한 소개도 인터넷에서 쉽게 찾아볼 수 있다. 창조적인 프로그래밍과 관련해서는 켄트 벡(Kent Beck)이 쓴 ‘Extreme Programming Explained’와 애자일얼라이언스(AgileAlliance) 웹 사이트(http://www.aanpo.org/home)를 참고하기 바란다.

CASE vs. MDA
CASE(Computer Aided Software Engineering)는 소프트웨어 개발이나 각 과정별 작업을 컴퓨터의 도움을 받아 공학적 기술을 자동화하는 것으로 각각의 작업의 자동화에 이용되는 도구를 흔히 CASE 툴이라고 한다. 역사적으로 볼 때는 1980년대 초의 구조적 개발방법론이 80년대 후반의 CASE로 발전하게 되는데 초기의 CASE 제품들은 다양한 목적을 가지고 있었다. 대표적인 것으로는 모델링 작업을 도와주거나 데이터베이스를 생성하는 것에서부터 코드의 자동생성 및 역공학 툴, 그리고 프로그래머가 아닌 사람이 프로그래밍할 수 있도록 도와주는 GUI 툴 등이 있다.

초창기 CASE 제품들이 등장하던 시기에는 메인프레임에 대한 COBOL 프로그래밍과 관계형 데이터베이스에 대한 SQL CASE 툴이 주를 이뤘는데, 운영체제나 데이터베이스 아키텍처를 지원하기 위한 정보를 모아두는 공통적인 저장소(repository)가 존재하지 않아서 그 활용에 제한점이 있었다. 이를 극복하기 위해서 IBM에서는 AD 사이클/저장소(Cycle/Repository)를 만드는 프로젝트를 시도했지만 실패로 끝났다.

1990년대에 들어서면서 컴퓨팅 환경이 급속도로 메인프레임에서 유닉스, PC 기반의 운영체제로 그리고 컴퓨터 언어의 측면에서는 C와 베이직 같은 언어가 주류 언어로 자리를 잡게 되면서 기존의 CASE 툴의 활용도가 급속히 떨어지는 현상을 보여주게 된다. 1990년대 후반에 들어가면서 객체지향 프로그래밍 언어의 사용이 일반화되고 1997년에 OMG(Object Management Group)에서 UML(Unified Modeling Language)을 표준화한 것을 계기로 객체지향 모델링을 이용한 사례가 늘어나면서 기존의 CASE보다는 객체지향 개발방법론을 따르는 새로운 형태의 비주얼 툴들이 각광을 받게 되는데 대표적인 제품이 현재는 IBM에 합병된 래쇼날(Rational)의 로즈(Rose)나 볼랜드에 합병된 투게더(Together) 등이다.

CASE 툴의 경우 아직까지 성공과 실패를 논하기에는 이르지만 초기에 가졌던 거창한 목표 달성에는 이르지 못했다고 판단된다. 가장 큰 이유는 CASE가 지향하는 목표가 너무나 방대하고 이를 지원하는 툴들이 실제로 등장해서 소프트웨어 개발에 이용되기에는 실무 소프트웨어 개발 프로세스가 개발 방법론이라는 것을 모두 소화할 만큼 충분히 성숙하지 않았다는 것을 들 수 있을 것이다. 다시 말해, 이론은 좋았지만 현실세계에 받아들여지기에는 아직 먼 이상향이라고나 할까?

이러한 현상은 비단 CASE 툴에 국한된 것만은 아니다. OMG에서 최초로 표준화 작업을 했던 분산객체 표준인 CORBA(Common Object Request Broker Architecture) 역시 초기의 기대와는 다르게 그렇게 많은 영역에서 넓게 채택되지 못했다. 그 이유는 여러 가지가 있겠으나 가장 커다란 요인으로 생각되는 것 중의 하나가 지나치게 무겁고 복잡한 표준 규격으로 인해 실제 소프트웨어 개발에 있어서 쉽게 받아들여지기 어려웠다는 점이다. 그에 비해 최근의 웹 서비스가 그 자체가 가지고 있는 많은 약점에도 불구하고 비교적 쉽게 채택되고 있는 것은 가벼운 표준 규격으로 인해 자유로운 선택의 영역을 넓혔으며 여러 가지 지원 도구들을 통해 쉽게 구현이 가능했기 때문이라고 생각된다.

MDA는 이러한 CASE와 CORBA에서의 교훈을 바탕으로 CASE처럼 지나치게 야심차지 않으면서 보다 느슨하게 연관되어 있는 표준안들의 연결고리를 제공하는 방식으로 접근하고 있다. 또한 이러한 연결고리를 쉽게 구성할 수 있는 도구들을 적시에 제공함으로써 그 성공 가능성을 높이고 있다.

MDA 탄생 설화 - CORBA, UML, MOF 그리고 MDA
OMG는 1989년에 설립이 된 객체 기술에 대한 사용을 증진시키고 이에 대한 표준안을 만들기 위해 소프트웨어 산업계에서 구성한 컨소시엄이다. 이들이 모여서 최초로 만든 것이 바로 OMA(Object Management Architecture)인데, OMA에서 가장 중요한 역할을 하는 것이 바로 CORBA이다. CORBA는 다양한 프로그래밍 언어 간의 상호운용성을 위해 IDL(Interface Definition Language)이라는 것을 도입했다. 플랫폼에 독립적인 프로토콜을 위해 IIOP(Internet Inter-Operable Protocol)와 같은 프로토콜 표준안을 제시하였다. <그림 1>은 OMA를 도식화해서 나타낸 것이다.

<그림 1> Object Management Architecture

그리고 OMG에서는 객체지향 소프트웨어 디자인을 위해서 그동안 다양하게 제시되었던 모델링 시스템을 표준화해 UML을 1997년에 발표하게 된다. 그 밖에도 OMG에서 발표된 대표적인 표준안으로는 플랫폼에 독립적으로 메타 데이터와 데이터를 정의, 조작, 통합할 수 있는 모델 기반의 프레임워크인 MOF(Meta-Object Facility), MOF를 모델 기반의 XML 통합 프레임워크로 재구성하며 MOF 기반의 메타모델의 XML 맵핑을 지원하는 XMI(XML Metadata Interchange), 데이터 웨어하우스 도구, 웨어하우스 플랫폼 그리고 서로 다른 환경에 분산된 웨어하우스 메타 데이터 저장소들 사이의 비즈니스 메타 데이터의 상호교환을 가능하게 하는 표준 인터페이스인 CWM(Common Warehouse Metamodel) 등이 있다. 이들은 MDA를 구성한 하부 요소로서 그 역할을 하게 된다.

CORBA에서 UML로의 중심 이동
필자는 2000년부터 수년 간 OMG 총회를 참석하면서 매번 총회에 참석할 때마다 조금씩 변화해가는 분위기를 느낄 수 있었다. 2000년 초기의 OMG 총회만 하더라도 대부분의 업체들은 총회의 세부 모임에 있어서 CORBA를 중심으로 CORBA 표준 규격안을 발전시키는 데 주력하였다. 또한 CORBA를 분산객체 기술의 산업 표준안으로 발표했음에도 불구하고 이와 유사한 다양한 플랫폼들이 등장하였기 때문에 이들과의 상호운용성을 위한 작업들도 지속적으로 진행되었다. 대표적인 것이 CORBA/COM, CORBA/J2EE의 상호운용성을 확보하는 것이었다.

그리고 비교적 CORBA 표준안이 많이 채택되었던 통신업체와 국방 관련 업체들을 중심으로 해당 도메인 영역에서의 서비스(Service)와 퍼실리티(Facility)를 정의하는 작업들이 한창이었다. 그런데 해가 바뀌면서 OMG 총회에 참석하는 사람들의 움직임이 지속적으로 UML쪽으로 움직이기 시작했다. 그에 비해 CORBA 표준안과 관련한 것들은 특정 도메인 영역으로 축소가 되는 양상을 보이면서 OMG의 중심이 CORBA에서 UML로 넘어가기 시작했다.

이러한 변화는 기술 표준안의 우월성에서 기인한 것이 아니라 여타 다른 경쟁 기술들의 존재로 인해 더 이상 산업계 표준으로서의 추진동력을 점차 상실하고 있었던 CORBA에 비해 객체지향 프로그래밍의 폭발적인 증가와 경쟁이 되는 표준안이 없는 상태에서 사실상의 유일한 표준안으로서 그 위세를 떨쳐나가던 UML의 시장에서의 반응에 의한 것이다. UML은 기존의 플랫폼의 우월성이나 벤더들 사이의 제품 팔아먹기 경쟁에서 옆으로 비켜난 상태로 많은 개발자들에게 받아들여지면서 자연스럽게 OMG를 이끌어가는 핵심 표준안으로 각광받게 된 것이다.

MDA의 탄생과 그 이후
이때부터 OMG 내부에서는 MDA에 대한 구상을 의논하는 그룹들이 생겨나기 시작했다. UML의 시장주도적인 힘을 바탕으로 CORBA가 이뤄내지 못했던 이기종 플랫폼 및 언어독립성을 비교적 받아들이기 쉬운 방법으로 제시하려는 노력들이 모여서 MDA가 탄생하게 되었다. MDA는 2001년 3월 OMG의 CEO인 리차드 솔리(Richard M. Soley)가 ‘OMG Model Driven Architecture’라는 제목의 프리젠테이션을 통해 공식적으로는 처음 세상에 알려지게 되었다. 이 발표는 OMG 웹 사이트에서 현재도 10분 정도의 오디오 파일로 들을 수 있으므로 관심 있는 독자는 한 번쯤 들어보기 바란다. 이 발표를 시작으로 MDA에 대한 구체적인 규격을 논의하기 시작해서 2003년 6월에 공식적인 ‘MDA Guide v 1.0’이 공개되었다.

2001년 3월 MDA에 대한 발표가 있은 뒤부터 MDA 표준안을 실체화하고 MDA에서 내세운 개념들을 구체화하기 위한 움직임들은 점점 활성화되었는데, 그 이후의 OMG 총회에서는 이러한 논의들이 하나씩 소기의 성과를 거두게 된다. 필자는 처음 MDA를 발표하는 자리에 있었는데, 그 발표를 보는 순간 이것이 앞으로 갈 길은 멀어 보이지만 언젠가 세상에서 커다란 반향을 끌어낼 수 있을 것이라는 느낌을 받았다. 그러나 그 때만 하더라도 적어도 5년 안에는 저기서 이야기하는 것이 실체화하기는 어려울 것이라고 생각했었다.

이런 필자의 생각을 깨뜨린 것이 2001년 여름 OMG 총회에서 최초의 MDA를 지원하는 개발 툴로 소개된 아크스타일러(ArcStyler )였다. 당시의 제품은 UML 모델을 바탕으로 플랫폼에 독립적인 모델(PIM, Platform Independent Model)과 플랫폼 의존적인 모델(PSM, Platform Specific Model)을 따로 관리하는 기본적인 MDA의 형태를 갖추기는 했으나 실제로 지원하는 플랫폼은 J2EE 밖에 없는 것이었다. 그렇지만 MDA에 대한 기본적인 개념이나 구현 가능성을 실제로 보여줬기 때문에 당시에 커다란 반향을 불러일으켰다. 아크스타일러는 현재 볼랜드의 엔터프라이즈 스튜디오에 통합되어 있으며 이를 시발점으로 여러 MDA 지원 개발 툴들이 등장하기 시작했다.

MDA의 목표는 소프트웨어 분석가와 개발자가 소프트웨어와 비즈니스 자산을 기술하는데 이용할 수 있는 엔터프라이즈 아키텍처 모델링이 가능하도록 하는 것이다. 이러한 아키텍처를 소프트웨어 도구를 이용해서 만들어냄으로써 실제 소프트웨어 개발에 있어서 아키텍처를 구현하는 특정 애플리케이션을 쉽게 작성할 수 있게 되며 애플리케이션을 다양한 변경 요구에 맞게 쉽게 변경할 수 있을 것이다.

MDA 구성 요소
MDA는 여러 가지 모델과 표준들에 의해서 구성된다. 모든 MDA 모델 들은 MOF라는 추상적인 메타모델에 기초를 두고 있기 때문에 모두 연관되어 있다. 다시 말해 모든 MDA 모델은 MOF와 호환성이 있다. 이런 특징은 MDA에서 이용된 모든 모델들이 다른 MOF 호환 모델들과 호환성을 가진다는 것을 보장한다.

MDA에서 또 한 가지 중요한 부분이 UML 프로파일(profile)이다. UML 프로파일은 UML을 확장한 것이기 때문에 MOF와 호환성이 있으며, UML 2.0에서는 UML의 다양한 기능적인 사용 방법을 기술할 수 있다. UML 프로파일은 UML의 확장인 동시에 그 자체로 MOF 메타모델이다. 일부의 MDA 메타모델은 이미 OMG에서 과거에 정의된 것들이며 일부는 OMG 외부의 그룹 또는 벤더들에 의해 MOF 호환이 되는 형태로 만들어진 것이다. 이러한 OMG 외부의 메타모델들은 비록 공식적인 OMG 표준은 아니지만 MOF 호환성이 있기 때문에 MDA 개발 과정에는 사용되는 데 문제가 없다. 대표적인 MDA 모델들과 프로파일들로는 다음과 같은 것들이 있다.

CWM
CWM(Common Warehouse Metamodel)은 OMG에서 표준화한 데이터 웨어하우스를 관리하는 데 이용되는 메타 데이터 모델이다. CWM을 이용하면 개발자들이 관계형 데이터베이스 테이블, 레코드, 구조체, OLAP, XML 그리고 다차원 데이터베이스 디자인 등과 같은 수많은 데이터 모델 또는 포맷을 생성할 수 있다. 또한 CWM에는 데이터 웨어하우스 이외에도 사용될 수 있는 유용한 부분들도 있는데 예를 들면 데이터 모델이나 데이터 변환, 소프트웨어 배포 등에 관련된 내용도 포함되어 있다.

UML 메타모델
UML의 초기 버전은 MOF와의 완전한 호환성이 보장되지 않지만 UML 2.0은 MOF 호환성을 가진다. 이런 이유로 진정한 MDA 개발을 위해서는 UML 2.0이 사용돼야 한다. UML은 핵심 모델링 개념들과 이들을 위한 다이어그램들로 정의된다. 또한 개발자들이 UML 구성 요소에 다양한 제한(constraint)을 할 수 있도록 허용하고 있다. UML 2.0에서는 UML이 모델들의 행위를 지정할 수 있으며 이러한 행위의 표현들이 직접 코드로 변경된다.

XMI
XMI 표준은 MOF와 호환성이 있는 모델들을 XML 문서 형태로 표현하고 이를 MOF 호환 데이터베이스에 저장할 수 있도록 하는 표준이다. 그러므로 사실상 XMI 문서는 곧 MOF XML 문서라고 할 수 있다.

UML 프로파일
UML 프로파일은 특정 도메인에 대한 UML 모델을 작성하기 위한 일반 확장(generic extension) 메커니즘을 정의하는 것이다. 그러므로 UML 프로파일은 추가적인 스테레오타입(stereotype)과 태그 값(tagged value)이 적용된 엘리먼트(element), 애트리뷰트(attribute), 메쏘드(method), 링크(link) 등으로 이뤄진다. UML 프로파일은 이러한 확장 컬렉션을 이용해서 특정 도메인에 대한 모델링 문제를 기술하고 해당 도메인의 내용들을 모델링할 수 있도록 해준다.

현재 다양한 UML 프로파일이 나와 있으나 MDA와 관련해서는 플랫폼에 따라 각각의 프로파일이 정의될 수 있다. 현재 CORBA 프로파일, EAI 프로파일, EDOC 프로파일, 리얼타임 컴퓨팅을 위한 스케줄링 프로파일 등이 OMG에서 정의되었으며 EJB 프로파일은 JCP(Java Community Process)를 통해, 닷넷 프로파일은 마이크로소프트에 의해 정의되고 있다.

MDA 개발 프로세스와 특징
MDA는 이와 같이 그동안 발표된 여러 OMG의 표준 기술들이 하나로 접목되고 유기적으로 연결된 형태를 가지고 있다. 그 중에서도 MOF와 UML 프로파일의 역할이 가장 중요하다는 것을 아마도 독자도 느낄 수 있을 것이다. 이러한 구성상의 역할과는 별도로 MDA는 소프트웨어 리소스의 관리와 개발 자체에도 초점을 맞추고 있기 때문에 소프트웨어 개발 프로세스에서 모델들이 어떻게 이용돼야 하는지에 대해서도 기술하고 있다.

<그림 2>는 비즈니스 프로세스나 소프트웨어에 대한 기술서를 바탕으로 추상적인 모델을 추출하고, 추상적인 모델을 실행 가능한 구현 모델로 변환시키는 과정을 보여준다. 이런 프로세스에서 사용된 모델들은 UML과 같은 메타모델로 표현되는데 일부의 모델은 플랫폼과 무관하고 일부는 플랫폼과 밀접한 관계를 가진다.

<그림 2> MDA 개발 프로세스

<그림 2>에서 3가지 유형의 MDA 모델을 볼 수 있을 것이다. 일반적으로 비즈니스를 분석하고 요구사항을 추출하는 역할을 맡은 분석가가 CIM(Computation Independent Model)을 모델링하며, 비즈니스 아키텍트나 디자이너가 PIM(Platform Independent Model)을 만든다. PIM 모델은 특정한 구현 모델과는 독립적으로 어떤 형태의 아키텍처를 가질 것인지 기술한다. 그리고 나서 개발자와 테스터가 소프트웨어 툴을 이용해서 PSM을 PIM에서 뽑아낸 뒤에 이를 플랫폼 특성에 맞게 최적화를 하고 코드를 뽑아내게 된다.

MDA 개발 프로세스를 단계별 스텝으로 간단히 정리해 보면 다음과 같다.

[1] 애플리케이션에 대한 비즈니스 요구사항을 수집한다.
[2] 도메인 모델에 대한 UML 다이어그램을 작성한다. 먼저 J2EE, 닷넷, CORBA와 같은 특정 기술에 종속적이지 않은 모델을 먼저 만든다. 이렇게 작성된 UML 모델은 핵심 비즈니스 서비스와 컴포넌트를 나타내게 되는데, 예를 들자면 가격 결정 엔진이라든지 쇼핑 카트 모델이라든지 주문 모델 같은 것들이 될 것이다. 이러한 UML 모델을 PIM이라고 한다.
[3] 애플리케이션에 대한 특정 기술과 관련한 UML 모델을 작성한다. 이와 같이 특정 기술에 종속적인 UML 모델을 PSM이라고 한다. PSM은 직접 작성할 수도 있고 MDA 지원 툴을 이용해서 PIM에서 자동으로 만들어내거나 또는 만들어진 모델을 수정하는 방식으로 작업할 수 있을 것이다.
[4] 마지막으로 MDA 툴을 이용해서 애플리케이션 코드를 만들어낸다. 현재 이미 J2EE의 경우에는 MDA 툴들이 대부분의 서블릿, JSP, EJB와 관련한 코드를 자동을 생성해준다. 그 다음에 만들어진 코드를 바탕으로 수정과 최적화 과정을 거쳐서 프로젝트를 완성한다.

이와 같이 MDA에서는 결국 UML 모델에서 코드를 만들어낸다. 그런데 어찌보면 이것이 새삼스러운 것은 아니다. 아마도 많은 개발자들이 래쇼날 로즈를 이용해서 자바 클래스를 UML 모델에서 만들어낸 경험이 있을 것이다. 이러한 작업과 MDA와의 가장 큰 차이점이라면 MDA는 플랫폼 독립적인 모델에서 시작해서 다양한 플랫폼을 지원하는 프로세스와 툴을 거의 완벽하게 지원한다는 점일 것이다. 이런 측면에서 간단히 MDA에서 만들어지는 모델들과 코드에 대해서 정리를 하면 다음과 같다.

◆ MDA는 다른 디자인 프로세스보다 고수준의 추상화를 먼저 시작한다. 예를 들어 PIM은 매우 추상적이다. 여기에는 엔티티와 서비스만 정의되어 있을 뿐이다.
◆ PSM은 메타 데이터의 형태로 애플리케이션을 완전하게 기술한다. PSM 수준에서 개발자들은 해당 기술과 관련된 디자인을 직접 코드를 건드리지 않고 향상시킬 수 있다.
◆ PSM에서 만들어진 코드는 완성된 애플리케이션에 근접하게 된다. 기존에 많은 도구들이 자동으로 만들어낸 코드들이 애플리케이션의 일부에 해당하는 것에 비해서 그 범위와 정도에 큰 차이가 있다.
◆ PIM에서 PSM을 만들어내고 PSM에서 코드를 만들어내는 알고리즘은 기본적인 것은 제공되지만 아키텍트가 변경하거나 재정의할 수 있다.

MDA의 중요한 특징 중의 하나가 이와 같이 모델링 언어를 프로그래밍 언어처럼 이용하는 것이다. 모델링 언어는 일반적으로 자바나 C++와 같은 프로그래밍 언어에서 하는 것보다 더 높은 수준에서 ‘추상화(abstraction)’를 가능하게 하며, 이러한 추상화 프로세스를 통해 개발자들은 시스템 코드에 꼭 필요한 데이터 이외의 것들은 모두 숨길 수가 있다. 이런 과정은 개발 과정에서의 복잡도를 감소시키는 효과를 가져오기 때문에 개발의 생산성을 높일 수가 있다.

아마도 여기까지 읽은 독자는 일반적인 객체지향 프로그래밍 언어의 가장 큰 특징 중의 하나인 ‘캡슐화(encapsulation)’라는 단어를 떠올린 경우가 많을 것이다. 보통 객체지향 프로그래밍 언어의 3대 특징을 이야기하면 캡슐화, 상속성(inheritance) 그리고 다형성(polymorphism)을 언급한다. 그 중에서도 객체지향이라는 개념을 위해서 가장 중요한 것은 바로 캡슐화이다. 다른 두 가지 특징은 완전히 지원하지 않더라도 객체지향 언어라는 말을 할 수 있지만 캡슐화가 지원되지 않으면 객체지향이라고 말할 수가 없다. MDA는 이러한 객체지향 개념의 캡슐화를 극대화한 것으로 이해할 수 있다. 단순히 프로그래밍 언어 수준에서의 캡슐화가 아닌 모델링을 포함해서 구현에 이르는 과정을 단계별로 캡슐화한 것이 바로 MDA의 정체이다.

MDA 개발 프로세스에서의 이러한 추상화는 시스템의 규격을 하부의 컴퓨팅 환경에 덜 좌우되게 하기 때문에 시스템의 생산성을 높일 뿐 아니라 지속성도 높여준다. 이와 같은 추상화의 수준을 높임으로서 소프트웨어 개발 생산성을 높이려는 시도는 새삼스러운 것은 아니다. 가장 직접적인 예로 현재 우리가 사용하고 있는 대부분의 프로그래밍 언어는 3세대 언어(3GL, 3rd Generation Language)라고 할 수 있는데, 3GL 언어는 기본적으로 어셈블리 언어를 추상화한 것이라고 할 수 있다.

이를 통해 어셈블리 언어로 프로그래밍할 때 알아야 했던 많은 어려운 문제들을 간단하게 컴파일러에게 맡겨버린 뒤 소프트웨어의 생산성이 급속도로 높아졌다는 것은 모두가 인정할 것이다. 그러나 3GL이 처음 등장했을 때만 해도 여러 개발자들은 3GL이 개발자들이 코드를 작성하기 쉽게 해주고 높은 수준의 생산성을 보장하지만 만들어진 실행 프로그램의 수행 속도 문제 때문에 한동안 수많은 논쟁을 했었다. 이러한 문제는 하드웨어의 비약적인 성능 발전으로 인해 자연스럽게 작은 문제로 치부되기 시작했고 이를 통한 소프트웨어 생산성의 증가는 많은 것을 가능하게 하였다.

왜 MDA인가
지금까지 설명한 내용을 충분히 이해한 독자라면 아마도 MDA가 어떤 녀석인지 정도에 대해서는 감을 잡았을 것이다. 그렇다면 왜 MDA가 최근에 각광받게 되었는지에 대해서 조금 더 생각해 보도록 하자. MDA는 MDA 표준을 적용해서 모델의 자동화와 변환(transformation)을 통해 여러 플랫폼을 쉽게 지원하고 개발자의 입장에서는 시간을 많이 잡아먹는 코드 작성 부분을 줄일 수 있으며 개발 프로세스의 측면에서도 품질 관리(QA, Quality Assurance)를 수월하게 할 수 있다. 그리고 과거의 CASE나 4GL과는 다르게 구현시에 유연한 컨트롤이나 커스텀화가 가능하도록 하였다. 잘 알다시피 손으로 코딩하는 부분이 줄고 동시에 빨리 버그를 잡을 수 있다면 소프트웨어의 생산성은 월등히 증가하게 된다. MDA를 이용하는 것이 좋은 이유를 몇 가지 나열해서 설명하면 다음과 같다.

기술 플랫폼 및 기능 변화에 대한 신속한 대응
MDA에서는 PIM과 PSM을 분리했기 때문에 PIM을 변경하지 않고도 기술 플랫폼의 변화나 요구사항 변화에 발빠르게 대처할 수 있다. 예를 들어, 새로운 플랫폼에 대한 애플리케이션을 배포해야 하는 경우 PIM에는 수정이 필요 없으므로 단지 PIM을 이용해서 새로운 플랫폼에 대한 PSM을 자동으로 만들어내고, 이를 수정해서 코드를 다시 생성하는 과정을 통해 쉽게 새로운 기술 플랫폼에 대한 대응이 가능하다. 또한 기능의 변화를 요구하는 경우에도 PSM 수준에서의 변경을 고려하지 않고 PIM에 새로운 기능 변화와 관련된 수정을 가함으로써 쉽게 대응할 수 있다.

시스템의 지속성
플랫폼 의존적인 시스템은 기존의 아키텍처가 새로운 요구사항을 만족시키지 못하는 경우가 많이 발생한다. 이 경우에 완전히 새로운 아키텍처를 다시 잡기보다는 많은 사용자들은 작은 패치와 수정으로 이런 문제를 해결하기를 원하며 현실적으로도 그렇게 할 수밖에 없는 시간?경제적 여유만을 가지는 경우가 많다. MDA를 이용하면 기능과 아키텍처를 분리해서 정의하기 때문에 아키텍처의 변화가 있더라도 변환 과정을 거쳐 구현 과정으로 쉽게 진행할 수 있기 때문에 기능과 요구사항 변화에 의한 아키텍처 변경에 비교적 자유롭다. 이런 장점은 시스템의 생명주기를 연장시키며 더 안정된 시스템 유지를 가능하게 한다.

개발 생산성 증진
MDA는 모델의 자동화와 변환을 통해 여러 플랫폼을 쉽게 지원하고 시간을 많이 잡아먹는 코드 작성 부분을 줄일 수 있으며 쉽게 유지보수가 되도록 한다. 이와 같이 손으로 코딩하는 부분이 줄고 동시에 빨리 버그를 잡을 수 있다. 또한 한 번 작성된 PIM의 경우 비즈니스 핵심 부분에 대한 모델이기 때문에 향후 다른 시스템에서도 쉽게 이용될 수 있으며 재사용성이 높아지게 된다.

용이한 문서 작성
디자인 문서를 업데이트하고 관련 코드를 수작업으로 관리하는 것은 매우 시간이 많이 걸리고 귀찮은 작업이다. MDA에서는 모델과 코드, 문서가 항상 동기화되기 때문에 이러한 문서 작업에 필요한 일의 양을 줄여준다.

품질 관리 비용의 감소
개발 과정에서 소프트웨어의 문제가 늦게 발견될수록 이를 고치는 데 들어가는 비용은 증가한다. MDA 모델 자동화와 테스트 툴을 이용하면 개발자들이 애플리케이션을 모델 수준에서 테스트할 수 있기 때문에 디자인의 문제점이나 애플리케이션 로직의 에러를 빨리 잡을 수 있다. 이를 통해 품질 관리에 들어가는 비용도 감소한다.

양질의 시스템 구축
PIM의 단순함은 양질의 시스템 구축을 가능하게 한다. 모델링은 팀 멤버들 사이의 의사소통을 원활하게 만들고 동시에 결점이 있을 때 이를 빨리 제거할 수 있도록 도와준다. 또한 MDA의 자동화 도구들은 잘 정리된 코딩 패턴을 모델에 적용하기 때문에 손으로 직접 작성한 코드에 비해 결점이 적을 가능성이 많다.

기술 플랫폼 통합의 기로에 서서
OMG는 소프트웨어 개발에 있어서 운영체제와 프로그래밍 언어의 통합이라는 어려운 과제를 수행하기 위해 과거 CORBA를 통해 불철주야 노력했으나 현 시점에서 판단해 보면 그다지 성공적이라고 하기는 어렵다. 그렇지만 CORBA를 논의하면서 모였던 많은 지식과 경험들이 바탕이 되어 MDA라는 새로운 접근 방법을 합의하는 데 성공했으므로 그런 노력들이 헛되기만 한 것은 아니었다는 것을 보여준다. 마지막으로 MDA가 기술 플랫폼 통합의 기로에서 앞으로 어떤 길을 걷게 될 것인지 여러 가지 측면에서 살펴보자.

환경의 변화
최근의 소프트웨어 개발 환경은 과거 CORBA를 만들어낼 때보다도 더 많은 프로그래밍 언어와 기술 플랫폼들이 등장하고 있다. 그리고 소프트웨어의 복잡도도 나날이 증가하고 있으며 이런 복잡한 소프트웨어를 더 효과적으로 개발하는 것이 가장 커다란 도전이 되고 있다.

그렇지만 과거의 환경에 비해 좋은 점들도 있다. 그것은 실질적인 표준으로 받아들여지는 기술이 많이 등장하고 있다는 것이다. 네트워크 프로토콜에 있어서는 TCP/IP, 데이터베이스 질의와 관련한 SQL, 객체지향 모델링에 대한 UML 등은 이제 진정한 표준으로서의 입지를 굳혀가고 있다. 또한 리눅스에서 출발하고 아파치를 통해 더욱 널리 퍼져가고 있는 오픈소스 프로젝트와 이들의 개방 정신은 소프트웨어 개발 정신과 철학에도 지대한 영향을 미치고 있다. 모든 것을 처음부터 만들어내는 접근 방식을 채택하는 것보다 컴포넌트의 재사용과 ERP 애플리케이션을 개발하는 것과 같이 효율적인 소프트웨어 개발을 중요시하는 시각의 변화도 이러한 긍정적인 환경 요소이다.

그에 비해 날이 갈수로 레거시 애플리케이션과 데이터베이스가 늘어가고 ERP 애플리케이션과 같이 수정이 어려운 것들이 많아진다. 또한 다양한 미들웨어가 이용되는 최근의 환경은 다양한 요구사항을 수용하는 엔터프라이즈 아키텍처를 구성하는데 많은 장애가 되고 있다. 그렇지만 이런 장애는 바꾸어 보면 MDA의 성공을 촉진하는 계기가 될 수도 있다. 중요한 것은 MDA가 활약해야 할 환경의 조성은 확실히 되고 있다는 점이다. 그런 측면에서 현재의 환경 변화는 MDA의 성공에 긍정적이라고 할 수 있겠다.

시장의 반응
CORBA가 절반의 실패를 하게 된 가장 큰 이유는 무엇이었을까? 물론 기술적으로 여러 가지 문제를 지적하는 사람들도 많겠지만 필자는 시장의 반응에서 그 답을 찾고 싶다. OMG에서 CORBA를 처음 발표한 이후 실제 이 표준안 시장에 적용하여 내놓은 제품은 전무에 가까웠다. 기껏해야 아일랜드의 작은 벤처기업인 아이오나(IONA)가 오빅스(Orbix)를 통해 CORBA 시장에 뛰어들었고, 뒤를 이어 인도의 비지제닉(후에 볼랜드에 합병된다)이 비지브로커(Visibroker)로 승부를 해온 정도이다.

이들 회사는 마이크로소프트와 같은 거대 회사가 추진하는 COM이라는 강력한 적수를 상대로 나름대로 선전했지만 CORBA가 가지고 있었던 거대한 목표를 달성하는 데에는 실패했다. CORBA의 실패는 표준안이 만들어지는 것이 성공의 요소가 아니라 시장 주도 세력과의 타협을 이루는 것이 더 중요하다는 것을 보여주는 매우 중요한 사례이다.

그렇다면 MDA는 어떠한가? 기본적으로 MDA에 대한 시장은 객체지향 모델링과 개발 툴 벤더를 통해 활성화가 될 것이다. 이들은 MDA를 자신들이 제공하는 톨에 통합할 것이며 기존에 OMG에서 만든 표준안인 UML, MOF, CWM, XMI 등을 지원하는 툴들이 늘어나면서 자연스럽게 그 영역을 확장하고 있다.

이런 움직임은 이미 가장 커다란 벤더들을 통해 주도되고 있으며 여기에 반기를 들고 상대하는 벤더가 없는 상태이다. 쉽게 말하면 초기 장수들의 기세에 무혈 입성하는 분위기이다. 특집 3부에서 다뤄질 각 벤더들의 MDA 지원에 대한 기사를 읽어보면 이러한 움직임을 확실하게 느낄 수 있을 것이다. MDA의 성공 여부에 대해 의문을 가지고 있는 많은 독자들에게 필자는 과감하게 이야기하고 싶다. MDA는 기술의 우위성을 떠나 확실히 성공할 수밖에 없는 단계에 도달하고 있다는 것을… @


출처 : http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039130721
by 수시아 | 2009/07/05 18:28 |  ▷ MDA | 트랙백 | 덧글(0)
MDA와 MDD
SW생산에 있어서 MDAMDD
(전자상거래연구조합 2004. 3.)
SW생산 방법의 진화
전통적으로는 객체지향 방법, 컴포넌트 기반 생산(CBD: Component Based Dvelopment)
최근에는 CBD를 기반으로 MDD, SOD, PLD등으로 발전
MDD: Model Driven Development(MDA기반 개발 방식)
SOD: Service Oriented Development(웹서비스 기반 개발 방식)
PLD: Product-Line Based Development(제품계열 기반 개발 방식)
MDA(Model Driven Architecture)
MDA의미
OMG(Object Management Group)가 그동안 만들어낸 플랫폼 기술과 표준 모델링 언어(UML등)를 이용하여 구현된 여러산업의 표준안을 결합한 모델 방식의 새로운 SW 아키텍쳐
OMG의 세계적 SW개발 표준을 이용한 통합 문제를 해결할 수 있는 모델 주도형 아키텍쳐
특히 최근들어 닷넷, 자바, J2EE등 신기술이 등장하면서 이들을 모두 지원하는 거대한 표준 팍거饅캅?요구되면서 이를 충족하기 위해 탄생
MDA의 핵심은 메타모델을 기반으로 구현 환경에 독립적인 시스템을 개발하고 이를 자동으로 구현 환경에 배치함으로써 구현 단계에서 생산성 향상, 표준 메타모델에 기반을 둔 시스템들의 일반적 호환성 확보 가능
MDA 출현 배경
사용자들이 ─IT업계에 SW분석, 설계를 맡기기 보다는 "우리 일은 우리가 가장 잘 안다"라는 개념으로─ 직접 표준 분석ㆍ설계도를 만들고 이를 IT업계에 주어 호환성을 갖춘 IT시스템을 개발하도록 요구하는 경향이 확산
이와 같은 사용자 주장을 바탕으로 UML(Unified Modeling Language)을 가장 기본으로 해서 모든 플랫폼을 지원할 수 있는 새로운 아키텍쳐가 필요하게 되었으며 이를 수용한 것이 MDA
MDA 중요성
기존의 IT모델이 부분개발이나 디자인을 통해 전체를 완성해 오던 상향식 접근에서 벗어나,
특정업종에 적합한 아키텍쳐를 미리 정의해 놓고 이후 개발로 들어가는 하향식 접근으로 전환되면서 궁극적으로 코딩이나 디자인보다는 아키텍쳐 설계가 IT핵심을 이루게 됨
이는 곧 IT산업의 주도 세력이 솔루션 벤더 업체에서 사용자 기업으로 옮겨가는 것을 의미 (사용자 주도 시대)
MDAMDD SW개발 방법의 표준으로 인정되고 있으며 향후 전세계 산업계 전반에서 사용될 전망
MDA 구조
MOF(Meta Object Facility) : 객체 및 컴포넌트 기술의 핵심을 정형화한 모델
UML: 객체 및 컴포넌트 시스템을 표현하기 위한 언어
XMI(XML Metadata Interchange): XML을 기반으로 정의한 데이터의 표준관리 언어
CWM(Common Warehouse Metamodel): 데이터웨어하우징을 위한 표준 메타 모델
MDA장점
메타모델을 이용하여 대부분의 구현 공정을 자동화 할 수 있는 구조 제공
시스템의 구현 결과, 분석 설계 관리등 프로젝트 진행 전체의 결과를 재사용 가능
시스템이 구현 환경과 독립적으로 정의됨으로 이식성이 증가
시스템 구조가 구현환경으로부터 독립됨으로써 개발된 시스템의 라이프싸이클이 구현 종속적인 시스템에 비해 증가
Cross-Platform 상호 운영성 솔루션에 대한 빠른 개발
모든 도메인의 플랫폼에서 사용할 수 있는 융통성
어플리케이션 개발의 비용 절감, 시간 단축, 품질 향상
MDD

MDD
의 정의: MDA기반의 SW개발 방식
MDD
SW개발 방법: 플랫폼 독립적인 SW모델로부터 플랫폼 종속적인 SW모델로 자동 변환하고, 소스코드를 자동 생성하는 방법으로서 원하는 플랫폼에 맞는 SW를 쉽고 빠르게 개발할 수 있음
MDD
SW개발 기술의 핵심 요소 기술
플랫폼 독립 모델(PIM: Platform Independent Model) 생성기술
플랫폼 종속 모델(PSM: Platform Specific Model) 변환 기술
기술매핑 자동화 기술
MOF(Meta Object Facility) 기반 정보 저장소 기술
MDD중요성과 전망
다양한 컴포넌트 플랫폼에 맞는 SW를 자동으로 생산할 수 있도록 SW모델 자동 매핑과 변환기술을 중심으로 MDD방법의 중요성 부상
MDD는 기존의 CBD방법보다 생산성이 30%이상 향상되어 2005년부터 본격 활용 예상
OMG에서 작업중인 영역별(전자상거래, 재무, 의료, 생산, 통신, 교통, 우주항공등 7개분야) 아키텍쳐 표준화 작업도 MDD를 채택하여 진행중
외국의 관련 정책 동향
미국: 국가 IT개발 프로젝트에서 모벨 주도형 SW생산 기술을 주요분야로 채택(2002년)
유럽: SW공학 연구 분야에서 MDE(Model Driven Engineering) 프로젝트 추진
아시아: 일본과 중국이 Asian-MDA공동 프로젝트 추진 예정


출처 : http://blog.empas.com/yhhwjh/read.html?a=7129462&rfr=http%3A%2F%2Fbrightland.egloos.com%2F7136998
by 수시아 | 2009/07/05 18:24 |  ▷ MDA | 트랙백 | 덧글(0)
MDA(Model Driven Architecture)란 무엇인가?
 
개요
MDA(Model Driven Architecture)는 2001년 3월 OMG(Object Management Group)에서 공식 발표된 이후로 소프트업계에서는 매우 유망한 패러다임으로 받아들여지고 있다. 3년간의 짧은 시간에, 40 개가 넘는 회사에서 MDA를 구현하는 소프트웨어를 출시하였다. 아직 많다고는 할 수 없지만 규모가 있는 사례들을 통해 새로운 개념을 적용하고 또 성공하였다는 것은 의미하는 바가 크다. 이러한 결과를 바탕으로 MDA가 소프트웨어의 개발과 유지보수 업무 방식에 대변혁을 가져오는 잠재성을 가졌다고 말할 수 있다. MDA가 빠른 속도로 대중화되어 가고 있는 이 시점에 MDA의 정확한 본질은 무엇인지를 명확하게 파악해보고자 한다.
MDA에 대한 이해
MDA는 무엇이며 왜 MDA가 필요한가?
결론부터 말하자면 새로운 소프트웨어를 개발하는데 있어 더 큰 생산성을 얻기 위해서이다. 그림 1에서 볼 수 있듯이, 여러가지 측면에서 소프트웨어를 개발하는 속도가 하드웨어의 파워보다 뒤떨어진다.
여기에는 여러 가지 이유가 있다. 첫째로, 소프트웨어 애플리케이션은 금융에서 국방에 이르기까지 광범위한 영역의 문제들을 대상으로 만들어진다. 게다가 이들 애플리케이션의 복잡성 또한 더욱 커지고 있다. 둘째로, 소프트웨어 기술 자체의 복잡성이 폭발적으로 증가하고 있으며, 개발자들은 HTML, XML, WML, 다계층 아키텍처, J2SE, J2EE, J2ME, .NET, 컴포넌트와 오브젝트 모델, 컨넥터, 메시지 브로커 등과 같은 여러 가지 기술을 익혀야만 한다.
그림 1. 생산성 문제
OMG에 따르면, MDA의 특성과 장점은 다음과 같다.
1. 이식성
2. 크로스-플랫폼 상호-운영성
3. 플랫폼 독립성
4. 도메인 특화성
5. 생산성
개발자들은 1번부터 3번까지의 특성으로 인해 CORBA, J2EE, .NET과 같은 특정 컴퓨팅 플랫폼에 구속받지 않게 된다. MDA에서, 개발 프로세스는 순수한 비즈니스 로직과 데이터 정의로 구성되는 플랫폼 독립적 모델(PIM, Platform Independent Model)의 구축으로 시작된다. 이들은 점차적으로 정제되며 CORBA, J2EE나 .NET과 같은 미들웨어 플랫폼에 맞추어진 플랫폼 의존적 모델(PSM, Platform Specific Model)로 변환된다. 최종적으로 PSM을 이용하여 하나 혹은 그 이상의 애플리케이션들에 대한 소스 코드가 생성된다. 이론적으로 수 많은 PSM이 동일한 PIM으로부터 생성될 수 있다.
이식성, 상호-운영성과 플랫폼 독립적인 특성은 특정한 비즈니스 문제를 해결하는데 초점을 두는 기능인 도메인 특화성이라는 4번째 특성을 유도한다. 즉, 은행이나 보험 회사의 업무를 실행하거나, 군사 명령 통제 시스템을 위한 최적의 구조를 만들기 위해서 필요한 최상의 프로세스와 데이터 구조를 설계할 수 있다는 것을 의미한다. 이러한 두 가지 경우에서 (수 만 가지의 경우라 하더라도) 이 솔루션을 어떻게 코딩할 것인가, 그리고 어떻게 특정 플랫폼에서 실행할 것인가에 관한 걱정을 할 필요가 없다. 이런 걱정들은 이후의 단계로 미루어지고, 앞으로 언급하겠지만 그 걱정 또한 크게 감소될 수 있다.
5번째 특성인 생산성은 어떠한가? 사실 MDA의 거의 모든 속성들은 생산성을 증대하는 것으로 밝혀졌다.
그림 2. OMG MDA
비용 관점에서 보자. 비즈니스 측면에서 명확한 이점이 증명되지 않는다면 새로운 소프트웨어 기술은 채택되지 않는다. 이에 대해 OMG는 아래와 같이 MDA 이점을 이야기한다:
1. 비용 절감
2. 개발 시간 단축
3. 향상된 애플리케이션 품질
4. 투자대비효과 증가
5. 최신 기술의 빠른 적용
개발 시간 단축은 비용 절감을 의미하고 투자대비효과의 증가를 유도한다. 비즈니스 로직과데이터 구조는 한 번 정의되며 이로써 일관성과 오류를 방지하기 때문에 MDA는 더 나은 고품질의 애플리케이션을 보장하게 된다. 중요한 점은 플랫폼 독립적이라는 것으로 이는 특정 플랫폼에 발목이 잡힐 가능성이 해소됨을 의미한다. MDA는 유용한 새로운 기술이 나타날 때마다, 업무의 중단과 지연을 최소화하면서 기존 애플리케이션이 새로운 기술의 장점을 수용할 수 있도록 보장하고 있다.
MDA의 특성과 이점이 대단히 유용한 것은 지금까지의 간단한 소개로 명확해졌다. 그러므로 MDA를 구현하는 제품들을 평가할 때에는 이런 특성과 이점을 제공하기 위해서 MDA 구현을 어느 정도 하는지를 가늠자로 삼을 수 있다.
전통적인 소프트웨어 개발 방법과 비교하여 MDA가 어느 정도의 개선점을 제공하는지 살펴보자. 이 질문에 대한 대답은 MDA가 가진 두 가지 특징의 독특한 조합에서 발견할 수 있다. 그 두 가지는 자동화와 관심 영역(비즈니스 영역과 플랫폼 기술)의 분리라는 것이다. 자동화 접근법에서, MDA는 일반 소프트웨어 모델링 툴과 크게 다르지는 않지만 중요한 차이점이 있다.
그림 3. 전통적 모델링과 개발
그림 3의 전통적 접근법에서, 각 프로젝트는 개발자 팀에 의해 수행된다. 개발자는 필요한 코드를 작성하기 위해 선택된 플랫폼의 기능뿐만 아니라 대상 업무도 숙지하여야 한다. 개발자가 완전하게 이해하지 못하면 애플리케이션에 아무것도 추가할 수 없다. 만일 팀이 해체되거나 구성원이 회사를 떠나는 경우 힘겹게 얻은 모든 지식을 잃어버리게 된다.
MDA의 경우 대상 업무 지식과 플랫폼 지식을 분리한다. 논리적으로 독립된 지식 부문들 간에 관심 영역을 더 완벽하게 분리하는 경우 더 완전한 MDA 제품이 된다.
그림 4. MDA 접근법
그림 4에서 보는 바와 같이, MDA는 도메인 전문가, 플랫폼 전문가와 애플리케이션 개발자가 독립적으로 각각 자신들의 지식을 제공하도록 한다. 만일 비즈니스 오퍼레이션이 변경되면, 다른 사람의 도움 없이 도메인 전문가가 대응되는 모델을 수정할 수 있다. 플랫폼 전문가는 플랫폼의 기술 상세를 제공하며, 조합에 반자동적으로 추가된다. 최종적으로, 개발자는 그들이 최선을 다 할 수 있는 고유 업무에 집중할 수 있다. 결국, 가장 적합한 기술 선택과 최상의 결과를 만들도록 조정하는 것이다.
MDA의 핵심 특성은 다음과 같이 정리할 수 있다.
1. 도메인과 플랫폼 전문 지식 간의 분리
2. 기존 IT 기술의 재사용과 개선
3. 도메인과 기술 변화에 빠른 적용
4. 높은 품질의 애플리케이션과 통합 생성
생산성과 관리의 증대
Grady Booch는 The Limits of Software(2002)라는 주제의 강연에서, 소프트웨어 공학의 전체 역사는 추상화 수준을 올리는 것이다 라고 말했다. Booch는 소프트웨어 공학 선구자이며 UML 아키텍트의 한 사람이다.
처음에 컴퓨터는 땜질 인두로 프로그램 된 것이었다. 다시 말하면 새로운 업무마다 다시 ㅐ선작업을 해야했다. 다음으로 각 개별 비트가 스위치를 사용하여 적재되는 기계 코드가 등장했다. 비록 각 문장이 단일 기계 명령으로 대응되었지만 어셈블리 코드는 큰 발전이었다. 그 다음으로 한 프로그램 문장을 수행하기 위해 여러 가지 명령을 생성할 수 있는 3 세대 언어 컴파일러가 등장하였다. 4 세대 언어는 추상화 프로세스를 더 한층 높였다. 만일 개발자가 몇 가지 파라미터를 명세하면, 전체 애플리케이션을 생성할 수 있었다.
추상화 수준이 올라갈수록, 프로그래머는 주어진 시간과 노력을 투자하여 더욱 더 강력한 애플리케이션을 생성할 수 있었다. 단점이 있다면 생산성 향상을 위하여, 유연성과 표준화와 같은 다른 필요 요소를 희생했다는 것이다. 그러다 보니 그 당시 4 세대 언어가 3 세대 언어를 대체할 것이라는 예측과는 달리 대부분 오늘날의 프로그래밍은 C, C++와 Java 같은 3 세대 언어로 이루어진다.
MDA는 성능 및 유연성과 표준화 간의 충돌을 해결한다. 그림 4에서 보는 것처럼 많은 작업을 자동화 하면서 개발이 추상화 수준 간을 부드럽게 이동할 수 있다.
그림 5. 관리 가능한 점진적 정제
MDA가 실제적으로 어떻게 동작하는지에 대한 개념은 그림 5에 나타난다. 핵심 프로세스는, 추상화 명세에서 시작하여 더 상세한 명세를 만들어 내는, 관리 가능한 점진적 정제(정확한 비즈니스 모델을 표현)라는 것이다. 변환 프로세스는, 자체적으로 유지-관리되고 변경될 수 있는 정제 명세에 의해 제어된다. 이 프로세스는 몇 번이고 반복 가능하다. 다시 말하면, 한 단계의 결과인 상세 명세가 다음 단계의 입력이 되는 추상 명세가 되는 반복적 프로세스를 의미한다.
그림 6. 개별 추상 수준과 다중 PSM
어떻게 MDA가 소프트웨어 개발에 사용되는 모델과 언어와 관련되는지, 그림 6에 더 상세하게 표현되었다. 도메인 모델은 몇 가지 확장성을 가진 비즈니스 모델링 언어(일반적으로 UML)로 표현된다. 도메인 모델은 적당한 기술 패턴을 통하여 애플리케이션 모델로 변환된다. 마찬가지로 도메인 모델은 확장을 가진 UML로도 표현되는데 일반적으로 주어진 플랫폼에 대한 UML 프로파일이다. 최종적으로 애플리케이션 모델은 구현 패턴 집합을 사용하여 C++, C#, Java나 CORBA IDL 같은 프로그래밍 언어의 소스 코드로 변환된다.
MDA라 볼 수 없는 것들
여러 벤더가 MDA 툴을 공급한다고 말하지만, 아직은 매우 소수의 업체만 모든 요구 사항을 만족한다. 가장 대체적인 결함은 도메인 모델, 애플리케이션 모델과 소스 코드 생성을 지원하지 못한다는 점이 될 것이다. 많은 제품이 추상화 정도가 낮은 애플리케이션 모델 수준에서 시작한다. 실제적으로는, 단순하고 평범한 모델링 툴이다.
몇 가지 MDA 툴이라 불리는 제품은 대응되는 애플리케이션의 소스 코드와 거의 유사한 상세를 가진 모델을 지원한다. 실제 이런 모델들은 여기서 생성되는 코드보다 더 높은 추상화 수준일 필요가 없다. 그림 4에서 설명한대로, MDA의 핵심은 도메인과 플랫폼 전문적 지식이 분리되어야 하는데 이 접근법은 이 사상을 허용하지 않는다.
특정 제품은 실시간 시스템(임베디드)의 생성을 위해 특화된 실행-가능 UML에 의존한다. 이것은 모델 내에 동적인 오퍼레이션을 정의하는 ASL(Action Semantics Language)를 가진 기본적인 UML이다. OMG는 UML의 선택 사항으로 ASL 표준 작업을 하고 있지만, 궁극적으로 PIM이 코드를 생성하는데 필요한 모든 정보를 가질 것을 의미하지는 않는다. ASL은 분명 유용한 역할을 가지지만, (예를 들어, 비즈니스 모델에 필요한 알고리즘을 명세할 수 있다) UML을 다른 프로그래밍 언어처럼 사용하도록 유도하면 안 된다. 그렇게 되면 대부분의 MDA 이점을 처리 과정에서 잃어버리게 되기 때문이다.
실제로 MDA를 가장 완벽하게 구현하고 있는 Tool은 아직까지는 OptimalJ 밖에는 없는 것 같다.
MDA의 명세 사항
OMG에서 MDA에 대한 스팩 작업 기간이 몇 년 되지 않았고 현재도 진행 중이기는 하지만 MDA의 명세인 UML(Unified Modeling Language), MOF(Meta Object Facility), OCL(Object Constraint Language), CWM(Common warehouse Metamodel)과 XMI(XML Metadata Interchange)는 수 년 전에 정의되었고, 계속 발전하고 있다. 게다가, 이 발전은 MDA의 기반구조를 제공하기 위하여 빠르게 가속화 될 것이다.
MDA는 UML 같은 공식 언어를 사용하여 명확하게 데이터와 프로세스를 표현하는 것이다. 그러나 이미 보았듯이, 한 언어에서 다른 언어로, 심지어는 이종 UML 언어 사이에서 모델을 변환할 필요가 있다. 이 작업은 모든 공식 언어가 논리적으로 일관성과 호환성을 가질 때만이 신뢰성 있게 이루어질 수 있다. 다시 말하면 공통 메타-메타모델을 모두 공유함을 의미한다. 이것이 MOF의 역할이다. UML, CWM, XMI 등이 가지가 되고 MOF가 뿌리로 구성되어야 한다. 이 관계는 그림 7에서 잘 표현된다.
그림 7. MOF는 모든 언어 가지의 뿌리
적절한 MOF로 새로운 언어를 필요할 때마다 정의할 수 있고 기존 언어는 확장할 수 있다. 기존 것의 더 나은 방식이나 새로운 방식을 설계할 때 또한 편리할 수 있다.
예를 들어, 가장 최근의 MDA 툴은 UML 프로파일을 사용하여 한 모델에서 다른 것으로 변환한다. OMG는 MOF 2.0 QVT(Query/View/Transformation)을 제안하여 이런 작업의 더 나은 방법론적 방식을 연구하고 있다. MOF를 사용하여 정의된 언어로 작업함으로써, 모델 간의 매핑 방식을 표준화할 것이다.
UML 2.0과 MOF 2.0을 사용할 시점이 되면 OMG에 의해 최종 채택이 될 것이다. 복잡하게 되는 반면에, 서로들 간에는 완전하게 정렬할 것이므로 MDA의 견고한 기반을 제공할 것이다.
[주: 컴퓨웨어는 MDA 표준 프로세스에 참여하고 있으며, UML 2.0, OCL 2.0과 MOF 2.0 FTF(Final task Forces)의 위원이고, 새로운 MDA 기반 OMA(Object Model Architecture)의 OMG 이사회 운영 위원으로 활동하고 있다. 또한 컴퓨웨어는 MOF 2.0 QVT RFP를 제출하였다]
결론
소프트웨어 개발의 주요 과제는 생산성을 증대하면서 동시에 유연성과 표준화를 조화시키는 것이다. MDA가 소개되기 전까지, 기존 언어는 이런 요구사항 중 한 두 가지는 맞추었지만 모두를 만족시키지는 못하였다. MDA의 출현으로, 완벽한 유연성을 유지하면서, 표준 환경 내에서 높은 생산성이 가시적으로 현실화되었다. 또한, 수동적으로 작성되는 코드가 적어지고 최상의 사례를 적용할 수 있는 패턴을 사용함으로써 애플리케이션 품질도 개선된다.
MDA가 높은 수준으로 자동화를 유지하지만, 100% 자동화는 아마 불가능할 것이다. 실행-가능 UML을 기반으로 하는 소스 코드와 동일한 추상화 수준의 모델을 생성하는 툴은 유용하지만 MDA 제품을 따라가지는 못할 것이다. 이런 모델은 플랫폼 독립적이지 못하다. 따라서 MDA의 품질과 생산성에서의 이점을 얻기가 힘들며 도메인 모델과 애플리케이션 모델 간의 필요한 구분을 불명확하게 만든다.
MDA는 사상이지 표준은 아니다. 하지만 표준을 따르고 있으며 많은 것이 이미 사용 가능하다. OMG에 UML 2.0과 MOF 2.0 표준화 작업이 계속되고 있고, UML Profile, CWM과 XMI는 이미 사용 가능하다. MOF 2.0 QVT 같은 새로운 명세는 MDA 기반 구조를 한층 더 향상할 것이다. 로마는 하루 아침에 세워지지 않았다. 그러나 OMG는 빠른 시간 안에 생산성, 유연성과 표준성의 조합을 통하여 소프트웨어 개발에서 MDA의 비약적인 발전을 약속하고 있다.

[출처] MDA(Model Driven Architecture)란 무엇인가?
by 수시아 | 2009/07/05 18:23 |  ▷ MDA | 트랙백 | 덧글(0)
MDA(Model Driven Architecture)
PLT 11 MDA(Model Driven Architecture)
MDA의 탄생
OMG의 중심이 CORBA에서 UML로 넘어가는 시점에 OMG 내부에서는 MDA에 대한 구상을 의논하는 그룹들이 생겨나기 시작했다. UML의 시장주도적인 힘을 바탕으로 CORBA가 이뤄내지 못했던 이기종 플랫폼 및 언어독립성을 비교적 받아들이기 쉬운 방법으로 제시하려는 노력들이 모여서 MDA가 탄생하게 되었다. MDA 2001 3 OMG CEO인 리차드 솔리(Richard M. Soley) ‘OMG Model Driven Architecture’라는 제목의 프리젠테이션을 통해 공식적으로는 처음 세상에 알려지게 되었다. 이 발표를 시작으로 MDA에 대한 구체적인 규격을 논의하기 시작해서 2003 6월에 공식적인 ‘MDA Guide v 1.0’이 공개되었다.
MDA의 시작은 OMA로부터
OMG 1989 OMA(Object Management Architecture)을 발표한다. OMA에서 가장 중요한 역할을 하는 것이 CORBA이다. CORBA는 다양한 프로그래밍 언어 간의 상호운용성을 위해 IDL(Interface Definition Language)이라는 것을 도입했으며, 플랫폼 독립적인 프로토콜을 위해 IIOP(Internet Inter-Operable Protocol)와 같은 프로토콜 표준안을 제시한다.


Object Management Architecture(OMA)
OMA는 크게 분산 객체 명세와 객체간 원격 호출의 신뢰성, 상호운용성, 이식성 등을 보장하는 ORB가 그 핵심에 있다. ORB를 통해 객체(컴포넌트, 서비스 등으로 대치시켜도 무방하다)를 배포할 수 있었고 배포된 객체는 실행 환경에서 ()사용된다.
OMA에서는 비즈니스 처리에 도움을 주는 편의 기능인 퍼실리티(CORBA Facility)를 준비하고 있다. 퍼실리티는 특정 도메인(금융권, 국방, 행정, 모바일)에서 자주 쓰이는 수직적(vertical) 퍼실리티와 소프트웨어 개발시에 일반적으로 사용할 수 있는(데이터 압축, 룰 처리, 워크플로우 처리, 컬렉션 등) 수평적(horizontal) 퍼실리티가 있다. 이로써 개발자들은 일반적으로 사용하는 수평적 편의 기능들과 현재 산업 도메인의 표준으로 정의된 모델인 수직적 편의 기능을 조합해 자신의 애플리케이션에 맞게 최적화, 특화해 개발하게 된다.
MDA의 목표
- 개발을 위한 최대한의 플랫폼을 준비해 놓고 각 도메인 전문가들이 완성한 표준 모델들을 제공하여 개발에 필요한 최대한의 생산성을 극대화시킨다.
- MDA는 이제 CORBA만을 고집하지 않고 J2EE, 닷넷, 웹 서비스 등 다른 플랫폼을 아키텍처에 포함시켰다.
- OMA에서의 개발 프로세스와 매우 유사한 방법으로 개발 가능하다.
- MDA 산업 도메인 모델을 기반으로 현 시스템이 필요한 모델들을 추출한 후, 최적화시킬 부분을 커스터마이징한다.
- 도메인 모델에 표현되지 않은 특화시켜 추가 개발해야 할 모델들을 모델링하므로 PIM(플랫폼 독립적인 모델 : Platform Independent Model)을 완성한다.
- MDA 프로세스에 따라 PSM(플랫폼 의존적인 모델 : Platform Specific Model)으로 모델 전이(Model Transform)를 하고 해당 플랫폼에 대한 소스코드를 생성한다.
전형적인 방법론 접근법이 이입된 MDA
RUP 모델
MDA 모델
플랫폼 독립
호환 범위
Business Model
PIM
O
비즈니스 도메인
Analysis Model
PIM
O
플랫폼
Design Model
PSM
X
시스템
Code
Code
X
X


MDA 개발 프로세스를 단계별 스텝
1. 애플리케이션에 대한 비즈니스 요구사항을 수집한다.
2. 도메인 모델에 대한 UML 다이어그램을 작성한다. 먼저 J2EE, 닷넷, CORBA와 같은 특정 기술에 종속적이지 않은 모델을 먼저 만든다. 이렇게 작성된 UML 모델은 핵심 비즈니스 서비스와 컴포넌트를 나타내게 되는데, 예를 들자면 가격 결정 엔진이라든지 쇼핑 카트 모델이라든지 주문 모델 같은 것들이 될 것이다. 이러한 UML 모델을 PIM이라고 한다.
3. 애플리케이션에 대한 특정 기술과 관련한 UML 모델을 작성한다. 이와 같이 특정 기술에 종속적인 UML 모델을 PSM이라고 한다. PSM은 직접 작성할 수도 있고 MDA 지원 툴을 이용해서 PIM에서 자동으로 만들어내거나 또는 만들어진 모델을 수정하는 방식으로 작업한다.
4. 마지막으로 MDA 툴을 이용해서 애플리케이션 코드를 만들어낸다. 현재 이미 J2EE의 경우에는 MDA 툴들이 대부분의 서블릿, JSP, EJB와 관련한 코드를 자동을 생성해준다. 그 다음에 만들어진 코드를 바탕으로 수정과 최적화 과정을 거쳐서 프로젝트를 완성한다.
MDA 적용의 장점
기술 플랫폼 및 기능 변화에 대한 신속한 대응
MDA에서는 PIM PSM을 분리했기 때문에 PIM을 변경하지 않고도 기술 플랫폼의 변화나 요구사항 변화에 발 빠르게 대처할 수 있다. 새로운 플랫폼에 대한 애플리케이션을 배포해야 하는 경우 PIM에는 수정이 필요 없으므로 단지 PIM을 이용해서 새로운 플랫폼에 대한 PSM을 자동으로 만들어내고, 이를 수정해서 코드를 다시 생성하는 과정을 통해 쉽게 새로운 기술 플랫폼에 대한 대응이 가능하다.
시스템의 지속성
플랫폼 의존적인 시스템은 기존의 아키텍처가 새로운 요구사항을 만족시키지 못하는 경우가 많이 발생한다. MDA를 이용하면 기능과 아키텍처를 분리해서 정의하기 때문에 아키텍처의 변화가 있더라도 변환 과정을 거쳐 구현 과정으로 쉽게 진행할 수 있기 때문에 기능과 요구사항 변화에 의한 아키텍처 변경에 비교적 자유롭다. 이런 장점은 시스템의 생명주기를 연장시키며 더 안정된 시스템 유지를 가능하게 한다.
개발 생산성 증진
MDA는 모델의 자동화와 변환을 통해 여러 플랫폼을 쉽게 지원하고 시간을 많이 잡아먹는 코드 작성 부분을 줄일 수 있으며 쉽게 유지보수가 되도록 함과 동시에 빨리 버그를 잡을 수 있다. 한 번 작성된 PIM의 경우 비즈니스 핵심 부분에 대한 모델이기 때문에 향후 다른 시스템에서도 쉽게 이용될 수 있으며 재사용성이 높아지게 된다.
용이한 문서 작성
MDA에서는 모델과 코드, 문서가 항상 동기화되기 때문에 이러한 문서 작업에 필요한 일의 양을 줄여준다.
품질 관리 비용의 감소
MDA 모델 자동화와 테스트 툴을 이용하면 개발자들이 애플리케이션을 모델 수준에서 테스트할 수 있기 때문에 디자인의 문제점이나 애플리케이션 로직의 에러를 빨리 잡을 수 있다. 이를 통해 품질 관리에 들어가는 비용도 감소한다.
양질의 시스템 구축
PIM의 단순함은 양질의 시스템 구축을 가능하게 한다. 모델링은 팀 멤버들 사이의 의사소통을 원활하게 만들고 동시에 결점이 있을 때 이를 빨리 제거할 수 있도록 도와준다. 또한 MDA의 자동화 도구들은 잘 정리된 코딩 패턴을 모델에 적용하기 때문에 손으로 직접 작성한 코드에 비해 결점이 적을 가능성이 많다.


출처 : http://mndpjt.egloos.com/1258512
by 수시아 | 2009/07/05 18:22 |  ▷ MDA | 트랙백 | 덧글(0)
[SW 강국-3/3] 개발자들 대접받는 날 '곧' 온다
http://sisa-issue.inews24.com/php/news_view.php?g_menu=085817&g_serial=425056
Date : 2009년 06월 29일 오후 18:56 

무늬만 컨설팅은 가라... 현업 잔뼈 굵은 한국형 아키텍트들이 컨설팅 나서야
강은성기자 esther@inews24.com 서소정기자 ssj6@inews24.com  
 
 
"우리나라 소프트웨어 개발 프로세스는 후진국 수준이다. 발주자의 전문성은 떨어지고 개발 환경은 낙후됐다."

국내 소프트웨어 산업에 대한 비판 중 종종 등장하는 단골메뉴다. 시장은 형성되지 않고 산업은 낙후됐으며 기술 수준도 떨어진다는 것이다.

그러나 이같은 비판은 관점에 따라 달라질 수 있다. 오히려 국내에는 소프트웨어 개발 전문 인력이 풍부하며, 산업 토대는 이미 갖춰졌다는 시각이 제기되고 있다.

◆국내에는 '아키텍트'가 있다?없다?

전 세계에서 가장 유명한 IT인 중 하나인 빌 게이츠의 직함은 마이크로소프트의 '회장님'이나 '사장님'이 아니다. 퇴임 전 그의 공식 직함은 '수석 소프트웨어 아키텍트(Chief Software Architect : CSA)였다. 마이크로소프트의 최고 기술자라는 의미다.

'자바의 아버지'라 불리는 썬마이크로시스템즈의 제임스 고슬링도 수석부사장 등의 화려한 직함 대신 '아키텍트'라는 명함을 내민다.

국내 대형 오픈마켓 최고기술책임자(CTO)는 "한국에는 이같은 '아키텍트'가 없다"고 꼬집었다.

그는 "외국에도 젊고 천재적인 개발자들이 많지만 한국 IT 회사 직원들은 정말 젊다. 하지만 한가지 큰 차이가 있다. 외국 IT 업체들은 젊은 직원들 사이에도 일명 'GOD'이라 불리는 존재가 있기 마련인데, 한국에는 그같은 최고 기술자가 기업내에 전혀 없다"고 설명한다.

단순히 기술만 아는 것이 아니라 산업 및 현업에 대한 깊은 이해에 기반해 문제를 해결하고 컨설팅한다. 그들의 연륜과 경험은 누구도 따라올 수 없는 재산이다. 그래서 이들은 신적인 존재로 통한다.

국내 기업에는 이런 존재가 없어 지식의 '축적'이 이뤄지지 않고 따라서 제대로된 컨설팅도 이뤄지지 않는다는 지적이다.

아키텍트에 대한 중요성은 정부와 업계도 인지하고 있다. 최고의 아키텍트를 양성하기 위해 한국소프트웨어기술진흥협회와 한국소프트웨어아키텍트연합회, 한국소프트웨어진흥원 등은 오는 7월 9일 대규모 '아키텍트 대회'를 여는 등 양성을 위한 노력을 하고 있다.

맞춤형 인력 양성이라는 프로그램을 마련, 지난 해 50억원이 넘는 예산을 투입해 최고 기술자를 양성하기 위한 박사 학위나 국가기술사자격증 취득 등도 지원했다.

그렇다면 국내 소프트웨어 개발자들은 빌게이츠나 제임스 고슬링 같은 뛰어난 기술력이나 컨설팅 능력이 부족해서 아키텍트가 되지 못한 것일까.

대답은 'NO'다. 아키텍트가 될 만한 뛰어난 기술과 경험, 컨설팅 능력을 갖춘 인재가 이미 국내에는 적지 않다는 뜻이다.


◇국내 SW개발자 평균근속연수

 

◆한국형 아키텍트, 가까이에 있다

눈에 보이는 '아키텍트'라는 직군이 형성되지 않았을 뿐, 이미 국내 요소요소에 우리나라는 뛰어난 아키텍트들을 보유하고 있다는 주장이 나오고 있다.

한국소프트웨어진흥원 정책개발팀 신익호 팀장은 "한국형 아키텍트는 거창한 것이 아니다. 국내 주요 IT 서비스 업체에서 십 수년간 현장 개발로 잔뼈가 굵은 노련한 개발자들, 이들이 바로 한국형 아키텍트"라고 강조한다.

그동안 풍부한 기술을 기반으로 정보화 현장에서 직접 뛰며 십수년간 개발에 종사한 이들 엔지니어들은 40대 안팎의 나이가 되면 관리직이나 영업으로 돌아서거나 아예 퇴직을 진지하게 고려해 왔다.

천신만고 끝에 개발해 놓은 완성품도 고객에 불려다니며 이것 저것 시키는대로 바꿔줘야 하는 '험한 일'이기에 젊고 어린 개발자가 차라리 선호되는 것이 현실이기 때문이다.

경험있는 개발자들을 구태여 필요로 하지 않고 '소모품' 정도로 여기는 현 상황은 소프트웨어 개발자들을 3D가 아닌 4D 직종 종사자로 만들었다.

더럽고(Dirty, 연이은 야근 철야에 씻지 못해서), 어렵고(Difficult, 고도의 지적 능력을 요해서), 위험(Dangerous, 정신적-육체적 스트레스로 인해 질병을 얻기 쉬워서)하다는 3D 직종의 특성에 D 하나가 더 추가돼서 4D다. 드림리스, 즉 꿈이 없다는 얘기다.

고생 끝에 낙이 온다는 속담도 무색하게, 고생만 하다가 40줄에 명예롭게(?) 퇴직해야 하기 때문에 꿈이라곤 찾을 수 없다는 의미기도 하다.

◇SW 사업의 주요 초과근무 요인



◇SW 품질 문제 발생의 근원

 

그러나 어느 소프트웨어 업체나 IT 서비스 업체에 있기 마련인 이들 노련한 개발자들이 바로 한국형 아키텍트이며, 이들이 제 몸값을 받고 능력을 펼칠 수 있는 기회가 와야 한다는 주장이다.

신익호 팀장은 "현업 발주자들이 정보화 프로젝트를 할 때 어떤 요구사항이 있는지는 정보기술과 현업 양쪽에 모두 능통한 아키텍트가 아니면 알 기 힘들다"면서 "이를 알기 위해서는 외국 대학의 MBA 학위가 아니라 실제 개발 환경에서 산전수전을 겪은 소프트웨어 엔지니어의 경험이 절대적"이라고 설명했다.

한국IT서비스산업협회 이지운 전무 역시 "발주자들은 정보화 전문가가 아니다. 그들은 전공자도 아니며, 심지어 이 일이 본업도 아니다. 그들이 전문화 돼야 할 이유가 없다"고 강한 목소리를 냈다.

이 전무는 "발주자가 정보화 사업에 대해 전문적으로 알아야 한다는 의미는 그들이 직접 아는 것이 아니라 전문가의 도움을 받아 완성도 높은 정보화 사업을 수행해야 한다는 의미"라면서 "그러기 위해선 현재 산업과 기술에 정통한 국내 엔지니어들의 도움이 필수"라고 강조했다.

◆무늬만 컨설팅, 패션쇼의 모델옷 같아

국내에 아키텍트가 없다는 현실은 소프트웨어 개발자들이 최고 기술자가 되기 위해 국가공인자격증을 취득하거나 비싼 비용을 내고 박사 학위를 따야 해결되는 문제가 아니다.

업체마다 이름없이 빛도 없이 '나이먹은 개발자' 취급을 받고 있는 진정한 전문가들에게 빛을 보여줘야 비로소 한국형 아키텍트가 양성된다.

현재 이같은 경력 십수년 이상의 '현업-기술 양방향 통달자'는 국내 소프트웨어 업체 및 IT 서비스 업체에도 적지 않은 수가 포진하고 있다.

국내 주요 IT서비스업체 3사만 하더라도 이 조건에 해당하는 소위 '비즈니스 어시스턴트(BA)'가 800여명에 달하는 것으로 나타났다.

삼성SDS 관계자는 "BA들이야 말로 고객사의 모든 업무와 개발 과정에 정통한 분들이면서 가장 고객 입맛에 맞는 컨설팅을 해주는 직무"라고 소개한다.

◇SW 기술자 노임단가 및 기술자 분포


그러나 삼성SDS를 비롯한 IT 서비스업체에서 BA들의 위상은 그리 높지 않다. 이 BA같은 양방향 전문가들이 제대로된 정보화 컨설팅을 할 수 있는 인력이라는 사실을 인정받아야 함에도 불구, 그렇지 못했던 것이다.

실제 전문가들은 입을 모아 "외국에서 경영학 석사(MBA)를 취득하고 근사한 프리젠테이션을 만드는 '컨설턴트'들이 정보화 컨설팅을 하곤 하지만, 실제 이들의 컨설팅은 변변한 제안요청서 하나 도출하지 못한다"고 꼬집는다.

한 IT 서비스 업체 임원은 "현 정보화 컨설팅은 패션쇼에 등장하는 모델의 옷"이라고 거침없이 지적했다.

패션쇼에서 모델이 입고 나오는 옷은 너무나 화려하고 아름답지만 일상 생활에서 소화하기에는 다소 거리가 먼, '관람용' 옷이 대부분이다.

현업에 대해 제대로된 요구분석 없이 현재 수행되고 있는 정보화 컨설팅도 이같은 맥락이라는 것이 이 임원의 지적이다.

따라서 현업에 대한 이해가 높은 개발자들이 완성도 높은 컨설팅을 해줄 수 있는 '아키텍트'로 대접받아야 한다고 임원은 강조한다. 그러면 개발자들의 4D 현상도 궁극적으로는 해결될 수 있다는 것.

한국IT서비스산업협회 채효근 실장은 "미국의 경우 전문적인 정보화컨설팅 에이전시가 따로 있다.발주자들은 이들의 도움을 받아 정보화 사업을 진행한다"며 "이 컨설팅 에이전시들은 대부분 십수년의 경력을 가진 소프트웨어 아키텍트들로 이뤄져 있으며, 미국의 젊은 개발자들은 이 아키텍트나 컨설턴트가 되기를 꿈꾼다"고 설명했다.
 

by 수시아 | 2009/07/01 15:40 |  ▷ Gossip | 트랙백 | 덧글(0)


<< 이전 페이지 다음 페이지 >>