Article Category

분류 전체보기 (202)
사는 이야기 (15)
Programming (174)
Photo (5)
게임 (2)
프로젝트 (0)

Recent Comment

Recent Trackback

Calendar

«   2019/05   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Archive

  • Total96,493
  • Today0
  • Yesterday2
주목받는 SW 개발방법론「비교 분석」
최상훈 (소프트웨어 엔지니어)
2004/11/01
소프트웨어 발전 방향을 미리 예견하기는 무모하거나 용감한 작업이 될 수 있다. 선배의 말을 빌리자면 차세대 채택되는 패러다임을 예측하기란 현재 학계나 커뮤니티에서 논의되고 있는 패러다임을 제비로 접어서 통에 넣어 흔든 후 하나를 뽑는 것과 같다고 한다. 그만큼 장담하기 힘들고 어려운 부분이다. 하지만 그것은 학계에서 발표되는 패러다임 101 버전의 얘기이지(이번 특집의 주제인 MDA만 하더라도 3년 전에 발표된 내용이다).

실제 산업에서 사용할 수 있는 수준의 차세대 패러다임을 점친다는 것은 메이저 벤더들의 제품 비전만 보더라도 쉽게 알 수 있다(대형 밴더들이 그런 고민은 다 해준다). 물론 ‘시장에서 채택될 것인가?' 하는 아주 복잡하고 우연적인 변수를 제거했을 때 말이다. 또 다른 방법이 있다 약간의 추리력과 예지력이 필요한데 과거 소프트웨어가 어떻게 발전되었는지 흐름을 잡고 미래를 예측해보는 것이다. 이 방법은 ’메이저 벤더들의 제품 비전’ 보다 앞서 미래를 점쳐볼 수 있다.

MDA의 목적, 실체를 살펴보기 위해 OMG에서 꾸준히 추진해온 OMA(Object Management Architecture)를 살펴보는 것은 도움이 된다. 결국 MDA는 OMG의 주력 표준인 UML과 OMA를 조합해 탄생한 총아이기 때문이다. 또한 MDA를 통해 얻고자 하는 것이 무엇인지, 그리고 다른 ‘제비’들과는 어떻게 다른지를 살펴보는 것은 흥미롭다. 자, 그럼 OMA를 통해 엔터프라이즈 소프트웨어가 어떤 것들을 어떻게 정복하며 발전했는지 살펴보자. 여기서 관전 포인트는 소프트웨어 재사용 단위, 형태를 기준으로 하는 것이 적당하겠다. 그리고 이 재사용성은 표준 혹은 규약으로 형상화된다.

OMA에서 MDA로
라이트 형제가 만든 플라이어호는 F-16 전투기와 너무도 다르다. 과거의 비행기에 비해 현재의 비행기는 너무 강력하고 많은 기능들이 추가되었다. F-16 전투기는 플라이어호부터 F-16 전투기 이전 버전까지의 결과물이다. 즉 F-16 전투기를 이해하기 위해 이전 버전들의 발전 과정을 추적해 보면 아주 잘 이해할 수 있다. OMA와 MDA의 관계가 그렇다.

<그림 1> OMA 아키텍처 1

OMA는 크게 분산 객체 명세와 객체간 원격 호출의 신뢰성, 상호운용성, 이식성 등을 보장하는 ORB가 그 핵심에 있다. ORB를 통해 객체(컴포넌트, 서비스 등으로 대치시켜도 무방하다)를 배포할 수 있었고 배포된 객체는 실행 환경에서 (재)사용된다(객체 표준/규약). 분산객체에 원격호출이 요청되면 그 객체가 가지는 비즈니스를 실행하게 된다. 엔터프라이즈 시스템에서의 비즈니스는 상당히 복잡한 처리과정을 갖는다. 네이밍 서비스를 통해(J2EE에서 JNDI) 타 서비스를 찾아 비즈니스를 연동하기도 하며 트랜잭션 서비스를 통해(J2EE에서 JTS or MTS, TP Monitor) 트랜잭션 처리를 위임하기도 한다.

또한 이벤트/Notification 서비스를 통해(J2EE에서 JMS or IBM MQ Series) 메시징 처리 및 EAI를 위임하는 것 이외에(데이터베이스) 쿼리, 보안, 라이선싱, 객체 저장 등의 서비스를 사용한다. 이런 각 코바 서비스는 비즈니스 처리를 위해 기술적 난점들을 재사용 가능하게 한다. 과거에 이 서비스들을 미들웨어라 불렀다(미들웨어 표준/규약).

객체 표준과 객체간의 통신의 문제도 각종 기술적인 문제도 점령됐다. 이제 비즈니스 처리에 전념할 수 있다. OMA에서는 비즈니스 처리에 도움을 주는 편의 기능인 퍼실리티(CORBA Facility)를 준비하고 있다. 퍼실리티는 특정 도메인(금융권, 국방, 행정, 모바일)에서 자주 쓰이는 수직적(vertical) 퍼실리티와 소프트웨어 개발시에 일반적으로 사용할 수 있는(데이터 압축, 룰 처리, 워크플로우 처리, 컬렉션 등) 수평적(horizontal) 퍼실리티가 있다. 이로써 개발자들은 일반적으로 사용하는 수평적 편의 기능들과 현재 산업 도메인의 표준으로 정의된 모델인 수직적 편의 기능을 조합해 자신의 애플리케이션에 맞게 최적화, 특화해 개발하게 된다. 물론 도메인 퍼실리티는 코바 퍼실리티 프로바이더에 의해 제공된다.

그리고 이를 바탕으로 <그림 2>의 도메인(객체)이 형상화, 정규화된다(레이어가 연상되지 않는가?). CORBA 도메인은 금융권부터 국방, 통신에 이르기까지 상당히 광범위하게 정의되어 있으며 다루고 있는 영역도 상당히 정밀하다. 사실 이 도메인이나 퍼실리티는 해당 분야의 기술자들이 오랜 경험을 통해 축적된 지식과 노하우를 통해 연구하여 설계한 모델이다(산업 도메인 표준/규약).

OMA 아키텍처는 이렇게 가장 기본이 되는 것부터(밑에서부터) 하나씩 표준화 작업을 수행했으며 이 표준화된 규약에 맞춰 개발된 COTS를 이용해 좀 더 검증되고 안정된 플랫폼을 제공하려는 비전을 갖는다. 표준화 작업으로 점령하는 과정은 가장 근본적이고 재사용성이 강한 대상부터 시작한다(ORB -> Service -> Facility). 그리고 그 종국에는 Domain이 있다. Domain은 해당 도메인에 가장 안정적인 아키텍처, 통신 프로토콜, 자료구조(경우에 따라서 데이터베이스 논리 테이블(Logical Data Model)까지) 등을 제시하고 있다. 따라서 개발자는 먼저 이미 벤더에 의해 제공되는 도메인을 도입하여 자신의 시스템에 맞게 애플리케이션을 최적화 시키고, 도메인이 제공하지 않는 자신의 시스템에 특화된 부분만 개발하는 작업으로 업무를 단순화할 수 있다.

그렇다면 왜 OMA 브레인들을 포함하여 다른 표준화 기관에서는 표준과 계약하고 싶어할까? 계약은 ‘계약에 의한 설계(Design by Contract)'를 통해 각 이해 당사자들이 상대방에 대한 서비스 제공과 같은 책임과 의무를 기술함으로써 대상에 대한 ‘How’가 아닌 ‘What’에 집중하게 한다. 표준은 반복해서 재사용할 수 있는 대상에 대한 ‘계약’으로서 지식과 경험에 대한 결과를 공유하려는 목적을 갖는다. 이를 통해 상호운영성, 통합, 연동의 문제에서 자유로울 수 있다. 그렇다면 OMA와 MDA가 어떤 연관관계가 있을까?

<그림 2>에서 분류된 도메인 오브젝트와 <그림 3>에서 MDA의 화살표로 지시되는 수직적 도메인과 매우 일치하지 않는가? <그림 2>의 도메인 오브젝트는 OMA 도메인 오브젝트 중 그림 구성상 일부만 표현한 것이다. 마치 OMA의 도메인 오브젝트들을 MDA 마지막 레이어에 감싸놓은 것 같다. OMA의 경우 IDL(Interface Definition Language)로 도메인 오브젝트들을 정의한 반면 MDA는 모델로 대체하고 있다. 물론 이 연관 관계에는 OMG의 다른 표준인 MOF나 UML 등의 내용은 차치한다.

<그림 2> OMA 아키텍처 2<그림 3> Model Driven Architecture

MDA의 목표는 OMA의 그것과 다르지 않다. 개발을 위한 최대한의 플랫폼을 준비해 놓고 각 도메인 전문가들이 완성한 표준 모델들을 제공하여 개발에 필요한 최대한의 생산성을 극대화시킨다. MDA는 이제 CORBA만을 고집하지 않고 J2EE, 닷넷, 웹 서비스 등 다른 플랫폼을 아키텍처에 포함시켰다. 그러므로 OMA에서의 개발 프로세스와 매우 유사한 방법으로 개발 가능하다. 즉 MDA 산업 도메인 모델을 기반으로 현 시스템이 필요한 모델들을 추출한 후, 최적화시킬 부분을 커스터마이징한다.

끝으로 도메인 모델에 표현되지 않은 특화시켜 추가 개발해야 할 모델들을 모델링하므로 PIM을 완성한다. 다음 MDA 프로세스에 따라 PSM으로 모델 전이(Model Transform)를 하고 해당 플랫폼에 대한 소스코드를 생성한다. ‘PIM → PSM → Code’로의 전이는 매우 훌륭하지만(이 전이 과정은 일반적 방법론과 매우 잘 일치한다. 박스 기사 참조) 또 하나 상기해야 할 부분은 나와 똑같은 도메인 선배 전문가의 경험과 지식으로 표준화된 도메인 모델들을 잊지 않아야 할 일이다.

[전형적인 방법론 접근법이 이입된 MDA]
전형적인 방법론에서의 모델링 순서는 ‘비즈니스 모델 → 유즈케이스 모델 → 분석 모델 → 설계 모델 → 구현 모델’ 단계로 구체화된다. 유즈케이스 모델은 시스템 요구사항을 도출하기 위한 모델이므로 일반적인 시스템을 추상화, 개념화 작업과 거리가 있기 때문에 현재 논의에서 제외시키자. 비즈니스 모델은 플랫폼에 독립적이며 동일 도메인의 다른 환경에서도 재사용가능하다. 이를테면 A회사의 윈도우 환경, C/S 기반의 인사관리 시스템의 비즈니스 모델은 B회사의 유닉스 환경, 자바 기반의 인사관리 시스템에도 적용할 수 있다. 분석모델도 플랫폼 독립적이다. 하지만 동일 도메인간의 재사용은 불가능하며 닷넷으로 구축된 시스템의 분석 모델을 J2EE 플랫폼으로 적용 가능하다. 디자인 모델은 플랫폼 종속적이다. 하지만 운영체제 같은 시스템에 독립적이다.

<그림 1> RUP 모델링과 MDA 모델링

그렇다면 MDA의 모델들과 비교해 보자. <표1>은 RUP의 모델들과 MDA의 모델들을 비교한 대차대조표이다.

<표 1> RUP의 모델과 MDA의 모델 비교

SOA 시대 도래
엔터프라이즈 시장에서 소프트웨어 기술 추이는 ‘분산객체(CORBA) → CBD 플랫폼(J2EE, 닷넷) → SOA’로 흐르고 있다. 특징을 비교하면 재사용성이 높고 실세계적 체계를 갖는 객체지향 단위의 오브젝트에서 좀 더 굵은 입자(coarse grained)를 갖고 객체간의 상호작용을 더욱 느슨하게(loosely coupled) 하여 변경관리가 용이할 수 있는 컴포넌트가 대세가 된다. 그렇다면 컴포넌트와 서비스와는 어떤 차이가 있을까? 좀 더 구체적으로 J2EE에 배포되어 ‘서비스되는’ 빈과 SOA(Service Oriented Architecture)의 서비스와는 어떤 차이가 있을까? SOA는 CORBA 오브젝트와 EJB를 서비스의 한 형태로 보고 있다. 단지 차이라면 그 자체가 아니라 동작되는 운용방식과 세계관에 있다. 결론만 말하면 비즈니스적이고 느슨한 관계를 가져 환경 통합이 용이하다.

웹 서비스와의 관계는 어떠한가. SOA와 웹 서비스와의 관계는 마치 애자일 방법론과 XP의 관계와 유사하다. SOA의 한 실체가 웹 서비스이고 웹 서비스는 SOA 아키텍처를 따른다. 웹 서비스와 SOA의 차별성과 개연성을 놓고 논란이 있지만 일반적인 관계는 이렇다. 즉 필자에게 객체와 컴포넌트, SOA의 차이를 규정하라고 한다면 그 기준을 크기(granularity)에 따른 책임에 두고 설명하고 싶다(단지 필자의 접근법이다). 객체는 기존에 알고리즘과 자료구조를 분리해서 다뤘던 프로그래밍 패러다임에서 실제 행위와 상태를 갖으므로 그 대상의 책임이보다 분명하게 정의할 수 있었다. 객체가 알고리즘과 자료구조를 추상화(facade) 한다.

하지만 객체간의 복잡한 관계들은 관리적 측면에선 단점이 된다. 컴포넌트는 좀 더 큰 범위에서 인터페이스를 통해 실제 사용하는 기능에 집중할 수 있게 한다. 컴포넌트가 객체들을 추상화(Facade)한다. 서비스는 컴포넌트의 처리를 비즈니스 단위로 묶어 작업 단위를 상위 레벨에서 캡슐화해 접근하게 한다. 서비스가 컴포넌트을 추상화한다.

<그림 4> SOA의 3계층 아키텍처

그러므로 사용자는 소비자로서 더욱 자신의 비즈니스 흐름에 집중할 수 있고 필요에 의해 비즈니스 흐름에 필요한 서비스를 선택하게 한다. <그림 4>는 SOA의 큰 범위에 등장하는 아키텍처적 레이어이다. 애플리케이션 아키텍처는 하나 이상의 서비스 공급자로부터 제공되는 서비스들을 찾아 비즈니스 프로세스 속으로 각 서비스들을 통합한다. 서비스 아키텍처는 실제 서비스를 처리하는 컴포넌트 아키텍처와 소비자 사이에 브릿지 역할을 함으로써 서비스를 위한 연동, 처리 관계, 상태 등을 관리해준다. 컴포넌트 아키텍처는 실제 서비스 구현을 담당하며 레거시 시스템이 좋은 후보가 될 수 있다. 이런 기반 구조에서 다음과 같은 효과를 얻을 수 있다.

◆ 프로세스 중심
◆ 플랫폼 독립적 애플리케이션 통합
◆ 느슨하게 결합된 메시지 지향
◆ 메시지 및 프로세스 상태 관리

SOA의 기본 세계관은 이미 개발된 각 기업의 컴포넌트들을 통합하기 위해 규격화·일반화한 서비스 컴포넌트를 상호운용할 수 있도록 함으로서 개발자가 중복 개발하는 것을 지양하는 것이다. 즉 네이버에서 개발된 블로그를 엠파스에서 똑같은 작업을 반복할 필요없이 네이버 블로그 ‘서비스’를 사용한다면 개발자의 노동력을 1/n배 감소할 수 있을 거라는 가설이다. 하지만 SOA는 이처럼 단순하지만은 않다. SOA는 보다 비즈니스 프로세스 관점에서 접근한다. 비즈니스 프로세스적 접근이란 마치 C 언어에서 main 함수를 시초로 다른 함수들을 호출해 프로그램이 진행되듯이 소비자가 각 서비스를 이용해 하나의 비즈니스 프로세스를 수행하는 방식을 말한다.

물론 하나의 서비스는 독립성을 갖지만 서비스는 상호 이용할 수 있으며 하나의 비즈니스 서비스는 서비스들의 조합으로 완성된다. 이를테면 <그림 5>에 표현된대로 ‘항공권 구매’란 비즈니스 서비스는 컴포넌트의 복잡한 조합에서 작업 흐름(프로세스)에 따라 호출되는 서비스들의 집합으로 관계를 단순화시킬 수 있다(인터페이스 중심의 패러다임에서 프로세스 중심으로의 패러다임 전이). SOA가 행운의 ‘제비’가 된다면 개발자는 서비스 마켓 플레이스에 진열된 양질의 서비스를 선택해 비즈니스 프로세스의 구성요소들을 구매한다. 만약 원하는 서비스가 없다면 개발해 구성 서비스에 추가시킨 후 서비스로 제공하게 될 것이다.

<그림 5> SOA의 프로세스 중심적 서비스 조합의 예

여기서 또 하나의 기대효과를 얻을 수 있다. 이렇게 서비스들이 빌트인 된 상황에서 각 서비스들의 상호작용을 마치 UML 시퀀스 모델링하듯이 비즈니스 프로세스 수행 시나리오를 작성하게 된다는 것이다. 웹 서비스의 WSFL(Web Service Flow Language)과 WSCL(Web Service Composition Language)이 이런 역할을 한다. 유사 기술로는 BPM(Business Process Management)의 BPML(Business Process Modeling Language), 마이크로소프트의 XLANG가 있다.

디자인 완전정복, 패턴언어
필자는 본지에서 지난 2003년 3월부터 3회에 걸쳐 분산 프레임워크에서의 패턴 언어를 소개한 바 있다. 패턴의 대부분의 패러다임은 패턴의 아버지인 건축학자 알렉산더로부터 제안된다. 바꿔 말하면 알렉산더와 그의 연구소는 패턴이란 종교의 메카격이 된다. 알렉산더는 1987년 ‘A Pattern Language’란 책을 통해 ‘유기적 건축양식’이란 패턴이론을 소개했다. 소프트웨어에서도 거의 유사하게 ‘패턴언어’란 패러다임은 적용된다. 패턴언어에서의 패턴은 독립적으로 존재하지 않고("No Pattern is an Island") 패턴간의 조밀한 응집도를 구성할수록 그 마법과 위력은 막강해진다("a dense composition of patterns").

기존의 Pattern Vocabulary, Pattern System의 패러다임과는 달리 패턴언어는 도메인에 종속적인 성격을 갖는다. 즉 MDA에서 수직적/수평적 도메인이 모두 디자인 차원에서 언어화(Pattern Language)될 수 있는 대상이 된다. 하나의 도메인은 하나의 언어가 된다. 왜 도메인을 언어란 개념으로 다루고 있을까? 초기 GoF 패턴 개념은 패턴 용어집(Pattern Vocabulary)의 패러다임이었다. 사람은 정확하고 확실한 의사소통을 위해 잘 정의된 용어집이 필요하고 이 용어집의 어휘가 많을수록 의사전달자로서 유리한 자산을 확보한 셈이 된다.

디자인 패턴에서 하나의 어휘는 하나의 패턴에 해당한다. GoF의 패턴으로 설계 문제를 해결하는 방식은 문제영역(패턴의 목적과 동기)을 기준으로 패턴의 목록을 살핀 후 가장 적합한 패턴을 선택해 적용하는 방식이다. 이때까지 패턴간의 응집도는 상당히 일반적이며 그 밀도는 낮았다. 패턴언어의 개념에서는 좀 더 축적된 용어들을 체계화해 하나의 언어 영역을 구성한다고 본다. 따라서 하나의 도메인을 이해하기 위해서는 그 도메인을 구성하는 언어체계(그 도메인의 패턴과 패턴간의 관계)를 이해하는 것이 필요하며 이 언어체계를 잘 이해할수록 그 도메인의 문제영역 풀이가 쉬워진다.

그렇다면 도메인에서 패턴간의 응집도는 어떻게 구성될까? 일반적으로 그 도메인의 문제영역이나 아키텍처 구성을 기준으로 패턴간의 응집도가 구성된다. <그림 6>의 J2EE 패턴 언어를 보자. J2EE는 크게 presentation, business, integration tier로 구성된다. 처음 클라이언트로부터 HTTP 요청이 들어오면 Decorating Filter 패턴은 HTTP 요청정보를 분해, 수집(필터링) 한다. 그 후 Front Controller 패턴은 사용자 인증이나 로깅 같은 공통적인 처리를 하고 View Helper 패턴에게 다음 처리를 위임한다.

View Helper는 서블릿 처리와 뷰에 관한 처리를 분리시키며 Business Tier의 Business Delegate 패턴으로 처리를 위임한다. Business Delegate 패턴은 서비스 컴포넌트의 복잡한 구조를 은닉하고 실제 비즈니스 처리를 담당하는 Session Fa?ade 패턴으로 처리를 위임한다. Session Fa?ade 패턴은 비즈니스 처리를 하면서 DB 접속을 시도할 경우 Integration Tier의 Data Access Object 패턴을 사용하므로 클라이언트 요청을 처리한다. 이렇게 패턴간의 응집도를 통해 처리의 전이가 발생하며 각 패턴은 해당되는 레이어의 문제들을 하나씩 해결한다.

<그림 6> J2EE 패턴 언어

이때 각 패턴들은 서로를 이용하기도 하고 같은 목적을 갖는 패턴들과 서로 경쟁하기도 한다. 또한 아키텍처 패턴과 디자인 패턴, 구현 패턴간의 계층적 포함 관계도 갖는다. 이렇게 패턴언어는 해당 도메인의 문제를 해결할 수 있는 여러 모델들을 제공하고 있다. 패턴언어에서 문제영역 해결방식은 개발자가 자신의 문제영역에 가장 적합한 패턴들의 집합을 조합하여 패턴의 구현 방식에 따라 시스템을 구성하면 된다. 즉 패턴언어의 프로세스는 이렇다. 첫째 개발자는 해당 도메인의 패턴언어를 살펴본 후 개발에 필요한 패턴 집합을 선택한다. 둘째, 선택된 패턴들을 구현한다. 셋째, 패턴으로 채워지지 않은 문제영역들을 구현한다. 패턴언어에서 재사용 자산은 도메인 개발자의 디자인 경험과 지식이고 그 결과물은 MDA에서의 모델과 다르게 패턴으로 형상화된다.

MDA, SOA, 패턴언어
눈치 빠른 독자라면 MDA, SOA, 패턴언어간의 유사성을 느꼈을 것이다. 이 세 기술은 각 공통적으로 축적 가능한 지적 자산을 최대한 모으고 축적된 자산들을 일정한 틀에 의해 배치시키고 저마다 하나의 문제영역을 해결하기 위한 최대한의 준비를 빌트인 하고 있다. 사용자의 몫은 이들을 잘 선택하고 조합해 이용할 수 있는 가치들을 최대한 획득하는 것이다.

MDA는 도메인 모델을 제공하고 모델을 재사용하게함으로서 모델을 통한 재사용성의 극대화를 추구한다. SOA는 서비스 형태를 갖는 이미 개발되어 컴포넌트들을 통합하여 하나의 비즈니스를 완성한다. 패턴언어에서는 하나의 도메인을 나타내는 패턴들의 조합들 중에 자신이 필요한 패턴의 집합을 선택해 시스템의 디자인을 구성한다. 하지만 이들의 사용 형태가 다른 만큼 이들이 채택한 기술도 차이가 있다.

MDA는 Executable UML, CWM, OCL 등을 통해 모델을 정의하고, 정의된 모델들을 QVT(Query, View, and Transformations)함으로서 구현을 완성한다. SOA는 웹 서비스를 기준으로 XML을 십분 활용해 통신을 위한 프로토콜을 SOAP으로 채택하고 WSDL을 통해 서비스 명세를 하고 UDDI를 통해 서비스의 생성, 기술, 발견, 통합을 가능하게 한다. 또한 이렇게 갖춰진 환경들을 WSFL이나 WSCL을 통해 비즈니스 차원에서 워크플로우 개념으로 조합한다. 패턴언어의 경우는 좀 불행하다. 패턴의 구성 원리와 패러다임만 있을 뿐이지 기술적인 실체가 없다.

해당 도메인의 지적 자산을 모으기 위해서는 튼튼한 아키텍처와 표준이 필요하다. MDA는 도메인과 플랫폼, 이들을 유기적으로 엮을 수 있는 MOF, CWM, UML 같은 기술로 모델에서 실행 가능한 코드로의 전이를 보장하고 있다. 즉 모델링을 기반으로 한 프로세스적인 측면이 강하다. 또한 각 도메인별로 수직적인 도메인 모델들을 포진시킨다. SOA의 경우는 서비스를 독립적이고 서로간의 느슨한 결합도를 유도하는 시스템 배치, 구성, 효과적인 사용 방법에 주안점을 두고 아키텍처를 만들었다. 패턴언어의 경우 패턴언어 자체가 아키텍처를 유도하고 있다. 그러므로 MDA, SOA는 엔터프라이즈 시스템 구축에 보다 적합하며 패턴언어는 프레임워크나 자체 솔루션을 구축하기에 적합하다. 이것이 패턴이 크게 뜨지 못하는 장애요인 중에 하나이다.

끝으로 각 기술들이 꿈꾸는 유토피아는 어떤 것일까? MDA는 소프트웨어의 모든 모델들이 MDA를 통해 만들어져서 모든 마켓 플레이스에 MDA 모델들이 진열되길 바랄 것이다. SOA의 비전은 개발을 원하는 모든 컴포넌트들이 서비스화되어 컴포넌트 조합으로 프로젝트가 끝나버리는 모든 마켓플레이스에 서비스가 진열되는 세상을 목적할 것이다. 패턴언어의 경우는 어떠한가? 패턴으로 표현할 수 있는 모든 디자인의 문제들이 패턴언어로 점령되기를 바랄 것이다. 그리고 이를 통해 좀 더 실체적인 프레임워크나 플랫폼으로 구체화되길 바랄 것이다.

우리의 과제
바스티유는 무너져도 앙시앙 레짐은 무너지지 않았다.
필자가 C 프로그램을 익히고 자바 프로그래밍을 막 배울 때의 일이다. 필자의 코드를 본 선배가 ‘C-tic한 자바프로그래밍’이라고 놀리던 일이 기억난다. 구조적 습관과 접근법을 아직 벗어나지 못한 상태에서 객체지향 프로그래밍을 하니 당연히 자바로 구조적 프로그래밍을 할 수 밖에 없다. ‘C-tic한 프로그래밍?’ 그때 필자의 코드들은 문법은 자바를 사용하지만 구성과 형식은 C 언어였다. 무엇이 문제였을까? 객체지향 언어를 사용하지만 구조적 프로그래밍이란 세계관을 버리지 못했던 탓이 컸다.

‘바스티유는 무너져도 앙시앙 레짐은 무너지지 않았다.’ 프랑스 혁명의 성공으로 봉건제도의 진원지인 바스티유를 함락시켰지만 앙시앙 레짐(old regime:구체제)의 습속은 여전히 남아있는 현상을 보고 한 지식인이 한 말이다. 우리는 새로운 패러다임을 접할 때 그 패러다임이 원하는 세계관은 무시한 채 그 패러다임의 용법에만 관심을 갖는 경우가 많다. 마치 필자의 ‘C-tic한 자바프로그래밍’의 경우처럼… ‘새 술을 새 부대에 담으라’는 말이 있다. 진정으로 체화되어 그 패러다임을 십분 활용하기 위해서는 그 패러다임이 원하는 방식과 접근법을 따라야 한다. 요즘 많이 거론되는 ‘내제적 접근법’으로 MDA란 새 기술을 대하는 태도가 필요하다.

세계관과 더불어 문화를 바꿔야 한다. XP를 도입하는 조직이 힘든 이유는 XP의 기민하게 상호작용해야 하는 개발자간의 문화를 바꾸기 힘들기 때문이다. 특히 MDA처럼 개발 단계가 극도로 축소되는 프로세스를 따르는 경우는 개발 참여자의 역할이 크게 구조조정된다. 즉 MDA는 개발 조직 체계를 바꾼다. MDA를 도입한 프로젝트에서 구성원의 시스템을 문화적인 부분까지 고려하여 바꾸지 않는다면 성공을 담보하기 힘들다.

Learning Curve를 고려해야…
하나의 기술을 프로젝트에 적용하기 까지 우리는 충분히 준비하지 못한 상태에서 프로젝트에 투입되곤 한다. 마치 소총 격발법 한번 읽어보고 전쟁터에 나간다고 비유하면 억지일까? 조금 여유있는 프로젝트의 경우 그 제품에 대한 교육도 받고, 파일럿도 하고 충분히 숙련과정을 거친 상태에서 제품 컨설턴트까지 대동하여 프로젝트에 투입하는 경우도 있다. 하지만 대부분의 경우는 이렇게 행복하지 않다. 짧은 시간 안에 스파이크 솔루션을 해보고 예제 실습 및 약간의 테스트를 거치고 곧바로 프로젝트에 적용한다. 필자의 동료는 더 고약한 경우를 당했다. PHP 프로젝트에 투입됐는데 두꺼운 PHP 책을 한권 주고 하루의 여유를 주더니 다음날부터 바로 코딩을 시켰다고 한다. 당연히 제대로 프로젝트가 끝날 수 없다. 이정도 되면 내제적 접근법은 아예 시도조차 못한다.

MDA는 모델링을 통해 프로세스 전반을 아우르는 상당히 거대한 범위를 다루고 있다. 따라서 학습해야 할 부분도 상당히 많다. 이를테면 PIM을 시스템 독립적으로 설계해야 하는 기술과 PIM에서 PSM으로 전이시키기 위해 고려·설정해줘야 하는 것들 타겟 플랫폼에 대한 이해·실행 가능한 코드를 생성할 때 코드 최적화를 위해 고려해야 하는 사항, 이후 테스트, 산출물 작업에 이르기 까지 알아야 할 것도 많고 배워야 할 것도 많다.

그러므로 현재 프로젝트 성공을 위해, 그리고 성공적일 다음의 MDA 프로젝트를 위해 체계적이고 전략적인 학습과정이 필요하다. 바쁘고 촉박한 프로젝트 환경에서 프로젝트 성공을 위한 충분한 학습을 하자는 것이 아니다. (물론 가장 바람직한 경우겠지만) 프로젝트를 통해 학습할 수 있는 기회를 가능한 만들어 다음 프로젝트에서는 좀 더 숙련된 기술을 보유하려는 노력, 함부로 사용하려 하지 않는 노력이 필요하다. ‘운전은 한다. 차는 모른다’라는 광고 카피가 있었다. ‘MDA를 프로젝트에 적용시켰다. MDA는 잘 모르겠다.’ 엔지니어인 우리에게 적용되기엔 너무 곤란한 경우이다.

적용을 위한 타당성, 적합성 검증 우선
좀 규모가 큰 프로젝트에서는 ‘단지 이 기술이 대세’이기 때문에 사용하려는 경우가 많다. 물론 대부분의 개발자들은 이런 기술, 플랫폼, 운용환경 선택의 의사결정 기회가 없지만 필자가 보아온 몇 가지 J2EE 프로젝트는 ‘Apache + Tomcat’만으로도 충분히 괜찮은 플랫폼인데 J2EE란 트랜드를 따라 무겁고 비싼 J2EE를 이용한다. MDA가 담당할 수 있는 영역은 상당히 광범위하다. 임베디드 시스템에서 국방, 금융권에 이르기까지 MDA로 못하는 것이 없다고 봐도 무방하다. 하지만 잊지 말아야 할 질문이 있는데, MDA가 현재 프로젝트를 위해 필요조건을 만족하는가, 충분조건을 만족하는가이다. 타당성이 확인되지 않은 기술을 사용하는 프로젝트는 개발자의 목적의식을 절감시키는 요인이 된다.

필자가 소개한 기술들은 소프트웨어 진화에 일익을 할 것이다. 그러므로 대세에 발맞추는 것도 개발자로서 좋은 태도이다. 하지만 조금 약아 보이더라도 실용적 입장을 취하는 것은 나쁘지 않다. 끝으로 MDA가 꼭 뽑히는 ‘제비’가 되기를 개인적으로 바란다. @

출처: ZDNET

Trackback 0 and Comment 1
필자는 프로그래밍을 비교적 늦은 나이인 이십대 중반에 시작했다. 따라서 독학을 통해서 익힌 ‘초식’이 많았는데 그래서인지 10년이 지나도록 잘 고쳐지지 않는 습관이 하나 있다. 머리 속에 알고리즘의 윤곽이 떠오르면 일단 키보드를 붙잡고 코드를 두드려야만 직성이 풀리는 것이다. 그렇게 하지 않으면 다음 내용이 잘 떠오르지 않는다. 프로그래밍 방법론이나 소프트웨어 공학의 충고에 의하면 이것은 ‘코딩’이 ‘설계’에 앞서는 대단히 잘못된 방법에 속한다. 교과서에 적힌 기본을 무시하는 철저한 아마추어리즘의 소산인 것이다.

프로그래밍의 맛
여러 명의 개발자가 함께 코딩을 하는 경우에는 물론 얘기가 다르다. 그런 경우에는 레쇼날 로즈(Rational Rose) 같은 소프트웨어나 객체 설계용 언어인 UML을 이용해서 어느 정도 설계를 마친 다음에 코딩을 시작할 수밖에 없다. 하지만 프로그래밍을 혼자서 할 때는 언제나 ‘코딩’이 ‘설계’를 앞선다. “진정한 ‘프로’는 설계를 마친 다음에 비로소 키보드를 잡는 거야”라고 아무리 말해도 소용이 없다. 커피를 마실 때 크림을 넣지 않으면 맛이 느껴지지 않는 것처럼 손끝에 전달되는 키보드의 감촉이 없으면 프로그래밍의 ‘맛’이 느껴지지 않는다.

이런 습관은 회사에서 수행하는 공식적인 프로그래밍에도 종종 연결된다. 외부의 API가 모두 결정된 상태에서 독립적인 컴포넌트의 내부를 구현하는 경우에는 예외 없이 코딩에서 부터 설계가 시작된다. 화면에 뜬 편집기(필자의 경우에는 주로 vi)라는 캔버스 위에 키보드 커서라는 연필을 조금씩 움직여 나가면 머리 속에 감추어져 있던 알고리즘이 서서히 눈앞에 모습을 드러낸다. 때로는 종이 위에 동그라미, 네모, 선 등을 그리면서 설계를 하는 경우도 있지만 그것은 어디까지나 키보드를 통해서 하는 붓질을 돕는 보조적인 조치일 뿐甄?

프로그래밍에 ‘조예’가 있는 개발자라면 이런 습관은 그다지 자랑할 바가 아니라고 생각할 것이다. 당연하다. 필자도 아주 최근까지 그렇게 생각했다. 그렇지만 프로그래머 중에서 이와 같은 습관을 가지고 있는 사람이 적지 않으리라는 점은 분명하다. 손끝에 키보드의 감촉이 전달될 때 비로소 프로그래밍의 맛을 느끼는 사람은 결코 필자에 국한되는 얘기가 아닐 것이다.

하지만 그런 사람들조차 대부분 ‘설계’에 앞서는 ‘코딩’은 자랑할 바가 아니라고 생각한다. 특히 프로그래밍 실력이 뛰어난 고수일수록 설계를 마치기 전에는 키보드를 넘실거리지 않을 것이라고 믿는다. 뒤집어 말하면 설계를 끝내기 전에 키보드를 만지작거리는 사람은 일종의 ‘하수’로 간주되는 셈이다.

프로그래밍 예술론
필자가 이와 같은 ‘설계’와 ‘코딩’의 관계를 포함하여 흔히 알려진 프로그래밍의 방법론이나 소프트웨어 공학의 ‘교리’를 의심하기 시작한 것은 (지난 해에 두 권의 책을 쓰면서) 프로그래밍의 본질이 ‘공학’에 있는가 아니면, ‘예술’에 있는가 하는 문제를 고민하면서부터였다.

프로그래밍이 도대체 예술일 수 있는가에 대한 답을 구하려면 우선 예술이 무엇을 의미하는지 이해해야 하는데 그것은 간단하지 않은 주제이므로 여기서 다루기 어렵다. 하지만 한 가지 분명한 것은 필자의 관점에서 볼 때 프로그래밍은 공학적 요소를 포함하고 있긴 하지만 분명히 예술에 더 가깝다는 점이다.

프로그래밍을 예술로 파악하는 것은 물론 새로운 관점이 아니다. 「프로그래밍의 예술(The Art of Computer Programming」로 유명한 스탠포드 대학의 도날드 카누스 교수는 일찍이 「문학적 프로그래밍(Literate Programming)」이라는 책에서 ‘프로그래밍은 예술’이라고 선언한 바 있다. 그는 이러한 선언을 한 걸음 더 밀고 나아가 프로그램 소스 코드도 다른 예술 작품들과 마찬가지로 미학적 요소와 독창성을 고려해서 ‘값’이 매겨지는 시대가 도래할 것이라고 예언하기까지 했다.

문학적 프로그래밍이란
카누스 교수가 말한 ‘문학적 프로그래밍’이란 사실 단순한 비유에서 그치는 것이 아니라 코드의 예술성을 담보하기 위한 일종의 구체적인 프로그래밍 방법론이었다. 우리나라에서는 「생각하는 프로그래밍」이라는 책으로 번역된 ‘프로그래밍 펄(Programming Pearl)’로 유명한 존 벤틀리는 카누스 교수가 ‘문학적 프로그래밍’을 설명한 글을 읽고 감명을 받은 나머지 자신의 컬럼 몇 개를 카누스 교수의 새로운 방법론을 소개하는데 바치기도 했다.

‘프로그래밍은 예술’이라는 명제는 사실 수학 명제처럼 명쾌하게 증명될 수 있는 것이 아니다. 그러나 프로그래밍을 하는 사람이라면, 그 ‘맛’을 조금이라도 아는 사람이라면, 이 명제를 간단하게 거부하지 못할 것이다. 오픈소스 프로젝트에 참여하여 자신의 여가시간마저 프로그래밍에 바치는 해커든, 아니면 회사에 출퇴근하면서 정해진 틀에 따라 코딩을 하는 ‘월급쟁이’이든 상관이 없다.

프로그래밍이 단순히 기술이나 공학의 수준에 머무르지 않는다는 사실은 누구에게나 분명하다. 프로그래밍이라는 행위 안에는 꼭 집어서 설명할 수 없지만 가슴이 떨리고 흥분이 밀려오는 ‘창조적 긴장’의 순간이 담겨 있기 때문이다.

카누스 교수는 스스로 수학적 논리와 알고리즘에 대해서 실로 심오한 내공을 갖추고 있었다. 그런 맥락에서 그는 프로그래밍이 가지고 있는 ‘과학적 미학’의 측면을 강조했다. 이에 비해서 폴 그래이엄은 프로그래밍에 담겨 있는 ‘창조적 미학’의 측면을 날카롭게 부각시켰다. 그래이엄은 하버드에서 컴퓨터 공학 박사 학위를 받고 인공지능 언어인 LISP에 대한 교과서를 쓸 정도로 내공이 중후한 프로그래머였다. 뿐만 아니라 인터넷 붐이 한창이던 1998년에 ViaWeb이라는 회사를 야후에 팔아서 ‘비즈니스맨’으로서도 이름을 얻었다.

그래이엄은 프로그래밍에 담긴 예술의 측면을 설명하기 위해서 프로그래밍을 그림 그리는 행위에 비유했다. 앞에서 그를 소개하면서 내공이 중후한 ‘프로그래머였다고’ 말한 이유는 그가 지금은 그림(painting)을 공부하여 화가의 길을 걷고 있기 때문이다.

그가 보기에 프로그래밍은 순수한 논리나 학문의 대상이라기보다는 ‘실천적 행위’를 통해서 몸에 익혀 가는 구체적인 ‘행동’에 가까웠다. 그것은 마치 텅빈 백지 위에 붓을 한 번 크게 긋는 행위와 다를 바 없었다. 그래서 그는 컴퓨터 과학이라는 표현이 프로그래밍의 진정한 속성을 정확하게 담지 못한다고 비판했다.

프로그래밍이 ‘컴퓨터 과학’ 혹은 ‘컴퓨터 공학’과 같지 않은 이유는 그림을 그리는 예술적 실천이 물감의 화학적 배합을 연구하는 ‘학문’과 같지 않은 이유와 동일하다. 다시 말해서 그림을 그리는 화가는 물감의 화학적 성분이나 여러 화학 이론에 대해서 굳이 알 필요가 없다.

이와 마찬가지로 프로그래밍이라는 창조적 활동을 하는 사람(즉, 프로그래머)들은 컴퓨터 과학과 공학의 수많은 이론을 굳이 자세하게 알 필요가 없다. 예를 들어서 튜링 기계나 오토마타의 개념 정도는 알 필요가 있을지 몰라도 복잡성 이론(complexity theory)에 등장하는 명제를 모두 읽어야만 좋은 프로그램을 만들 수 있는 것은 아니다.

코딩이 설계에 앞선다?
그래이엄을 알기 전까지 필자는 ‘코딩’이 ‘설계’를 앞서는 습관을 ‘아마추어리즘’의 표현이라고 생각해 왔다. 진정한 프로라면 교과서에서 가르치는 대로 정확하게 설계를 마친 다음 비로소 코딩을 시작해야 하는 것이라고 생각했다. 이런 강박관념은 일종의 열등감마저 수반했는데 그래이엄의 통찰은 필자를 ‘예술’이라는 아름다운 이름과 함께 구원해 주었다.

프로그래밍을 예술로 바라보는 관점에서 생각해 보면 ‘판에 박힌 듯한’ 소프트웨어 개발 방법론은 프로그래머 개개인의 감성을 존중하기보다는 정해진 틀에 맞는 상품을 생산하기 원하는 기업의 욕망을 반영하고 있다. ‘획일적인 틀’은 상품 생산을 위해서 필요할 뿐 진정한 창조와 아무런 상관이 없기 때문이다.

뛰어난 프로그래머였던 그래이엄은 자기 자신도 프로그래밍을 할 때 키보드를 붙잡고 코딩부터 시작한다고 고백했다. 그가 밝힌 방법은 우선 가볍게 키보드를 두드리면서 코드의 전체 윤곽을 잡고, 다시 처음으로 돌아가서 조금씩 각 부분의 디테일을 살려 나가는 방식으로 프로그램을 작성하는 것이었다. 그는 코딩이 설계에 앞서는 이와 같은 방식을 조금도 이상하게 여기지 않았다. 오히려 그는 모든 예술적 창조가 대개 이와 비슷한 과정을 거치면서 이루어지며 그림을 그리는 과정도 이와 다르지 않다고 말했다. 그리고 미술에서는 그것을 ‘스케치’라는 자연스러운 이름으로 부른다고 지적했다.

혹시 필자가 이 글을 통해서 ‘코딩은 설계에 앞서야 한다’는 명제를 주장하고 있다고 잘못 이해하지 않기 바란다. 그것은 손으로 달을 가리켰더니 손가락만 바라보더라는 이야기와 다를 바 없는 오해가 될 것이다. 여러 명이 함께 복잡한 소프트웨어를 만들 때 ‘설계’의 과정이 결정적으로 중요하다는 사실에는 이견이 있을 수 없다. 다만 필자는 소프트웨어의 ‘생산성’을 높이기 위한 방법론이 반드시 프로그래밍의 ‘예술성’을 강화시키는 쪽으로 작용하지 않는다는, 아니 정확하게 말하자면 그 반대의 방향으로 작용한다는 사실을 지적하고 싶었을 뿐이다.

그럼 프로그래밍의 ‘예술성’을 강조하는 프로그래머는 그렇지 않은 프로그래머에 비해서 소프트웨어 ‘생산성’이 떨어지는 것일까? 놀랍게도 전혀 그렇지 않다. 오히려 그 반대의 경우가 더 많다. 창조의 기쁨을 아는 사람과 그렇지 않은 사람이 발휘하는 능력에는 본질적인 차이가 존재하기 때문이다. 필자가 이 글을 통해서 말하고 싶은 것이 바로 그 차이이다. ‘기쁨’이 있는 사람과 없는 사람 사이에 존재하는 차이는 프로그래밍의 예술적 속성을 이해하는데 있어서 핵심적인 열쇠가 된다.


임백준 (루슨트 테크놀로지스)

Trackback 0 and Comment 0