오늘날 IT 시스템은 과거와는 비교할 수 없을 만큼 복잡한 비즈니스를 처리하고 있습니다. 과거에는 우수한 하드웨어 및 소프트웨어 개발 기술이 필수적이었다면, 이제는 복잡한 고객의 비즈니스 요구를 반영하는 역할이 점차 심화되고 있는데요. 이번 시간에는 ‘기술’에서 ‘비즈니스’ 중심으로 변화하고 있는 MDD(Model Driven Development)의 이모저모를 함께 살펴보겠습니다.
● 프로그래밍 언어 없이도 프로그래밍이 가능한가요? (1편): http://blog.lgcns.com/573
● 프로그래밍 언어 없이도 프로그래밍이 가능한가요? (2편): http://blog.lgcns.com/605
비즈니스 모델의 전통적 개발 방식의 한계
과거, 카드사 시스템 구축 시에는 일정한 시간 내에 데이터를 안정적으로 처리하는 것이 관건이었습니다. 그러나 현재는 그뿐만 아니라, 포인트/할인/이벤트/보험 등의 각종 상품과 웹/모바일/SNS 등과 연계된 다양하고 복잡한 비즈니스 모델을 개발해야 하는데요. 이러한 비즈니스 모델을 전통적인 개발 방식으로 구현하고자 한다면, 많은 어려움이 있습니다. 기존과는 비교할 수 없을 만큼 개발해야 하는 기능의 수가 많고 새로운 기능이 추가될 때마다 기능 간의 연결 관계 또한 복합해지기 때문이죠. 이로 인해, 전체적인 개발 생산성과 품질의 저하를 불러일으키게 됩니다. 그렇다면, 전통적 개발 방식에 대해 조금 더 자세히 살펴볼까요?
전통적인 개발 방식은 분석, 설계, 개발 및 테스트 단계를 거치면서 최종 시스템을 만들어 냅니다. 설계자는 고객의 요구 사항을 설계 문서로 만들고, 개발자는 설계 문서를 보고 프로그래밍 언어로 시스템을 구현하는데요. 금융 차세대와 같은 대형 프로젝트에서는 개발자들이 수십 명에서 수백 명까지 존재하지만 그들의 실력은 천차만별이죠. 따라서 만일 그 중 누군가가 프로그래밍을 잘못하면, 시스템 오작동이 발생합니다. IT 시스템에서는 이것을 ‘버그(bug)’라고 부르는데요. 고객의 요구 사항이 복잡할수록 버그의 원인을 찾아내고 수정하는데 많은 시간이 걸립니다. 건축에 비유하여, 이러한 상황을 다시 한번 살펴본다면 그 내용은 다음과 같습니다.
● 상황의 예
고객이 다양한 기능을 가진 ‘방문’을 요구하였습니다. 이미 완성된 집에서 방문이 닫히지 않는데, 그 원인이 무엇 때문인지 판별하기가 쉽지 않습니다. 목수가 못을 잘못 박아서 비뚤어진 문턱 때문인지, 아니면 설계자가 문턱의 크기를 설계도에 잘못 표시했기 때문인지 판단이 어려운 상황입니다. 문짝을 다시 재단하여 문제를 해결해 보려고 하지만, 수많은 문의 기능들을 처음부터 다시 테스트해야 합니다. 설상가상으로 고객은 휠체어가 문턱을 넘을 수 없다면서, 또 다른 요구 사항까지 내놓았습니다
위의 상황을 IT 관점에서 한번 해석해 보겠습니다.
● IT 관점으로의 해석
상황의 예
IT 관점으로의 해석
고객이 다양한 기능을 가진 ‘방문’을 요구함
고객의 요구 사항은 복잡하고 다양함
이미 완성된 집에서 방문이 닫히지 않음
개발이 완료된 이후에야 테스트를 수행할 수 있음
예상 원인 1: 목수가 못을 잘못 박아서 비뚤어진 문턱 때문일까?
예상 원인 1: 오류의 원인은 잘못된 ‘개발’일까?
예상 원인 2: 설계자가 문턱의 크기를 설계도에 잘못 표시했기 때문일까?
예상 원인 2: 잘못된 ‘설계’ 때문일까?
문짝을 다시 재단하여 문제를 해결해 보려고 함
오류를 수정하기 위해 설계부터 다시 해야 함
수많은 문의 기능들을 처음부터 다시 테스트해야 함
수정된 부분과 관련된 수많은 단위 기능들을 다시 테스트해야 함
설사가상으로 고객은 휠체어가 문턱을 넘을 수 없다면서, 또 다른 요구 사항을 내놓음
그럼에도 불구하고, 완성된 결과물이 고객이 원하는 욕구를 충족시키지 못함
위에 제시한 비유 상황의 해석처럼, 전통적인 개발 방식에서는 설계 공정이 끝난 이후에 개발을 할 수 있습니다. 그리고 개발을 완료해야 테스트가 가능합니다. 다시 말해, 개발이 끝나기 전까지는 테스트를 시작조차 할 수 없는 것이죠. 또한 개발 이후에 설계가 변경되면, 관련된 기능의 일부분 또는 모든 부분을 여러 번 반복적으로 다시 테스트해야 합니다. 왜냐하면 하나의 기능에 대한 수정 작업이 다른 기능에 영향을 미쳐, 또 다른 오류를 불러일으킬 수 있기 때문입니다. 비즈니스 요구 사항이 복잡하면 복잡할수록, 테스트해야 하는 기능의 수가 많고, 아주 복잡한 업무라면 모든 기능을 테스트할 시간이 부족할 수도 있습니다.
결과적으로는 문제점을 초기에 발견하지 못하고, 뒤늦게 수정 작업을 통해 전체 테스트를 되풀이해야 하는 위험에 처하게 됩니다. 이러한 경우, 개발 기간이 늘어나는 것도 문제지만 더 심각한 것은 설계 초기에 오류 가능성을 발견하여 수정하는 것보다 엄청난 시간과 비용이 소요된다는 것인데요. 더 나아가서는 고객의 신뢰를 잃어버릴 수도 있습니다.
비즈니스 설계 중심의 MDD(모델 기반 개발 방식)
모델은 고객/설계자/개발자 어느 누구라도 쉽게 이해할 수 있도록 그림과 한글로 작성한 표준화된 설계 문서입니다. 그리고 그 모델을 생성하는 과정을 ‘모델링’이라고 부르는데요. 우선, 다음에 제시한 자료를 한번 살펴보도록 하겠습니다.
위의 자료 왼쪽에 제시된 소스 코드는 해당 프로그래밍 언어에 대한 지식이 없다면 정확한 내용 파악이 어렵습니다. 반면, 오른쪽의 모델은 몇 가지 모델링 표기법만 안다면 이해하기 쉬운데요. 왼쪽의 소스 코드는 LG CNS의 MDD 도구를 이용하여, 오른쪽의 모델로부터 자동으로 생성한 것입니다.
LG CNS MDD에서는 고객의 요구 사항을 모델링 도구를 이용하여 표준화된 설계 모델로 작성합니다. 모델은 각각의 기능을 역할별로 구분하여 컴포넌트로 설계하는데요. 하나의 비즈니스 프로세스 컴포넌트는 다른 여러 컴포넌트들을 조립하여 완성합니다.
완성된 모델로부터 100% 실행 가능한 소스 코드와 전통적인 방식의 설계 문서를 자동으로 생성할 수도 있습니다. 또한 프로그래밍 자동화로 개발 단계가 생략되기도 하는데요. 개별 컴포넌트는 설계 초기 단계부터 화면이나 별도의 테스트 프로그램 없이도 단위 테스트가 가능합니다. 그리고 프로젝트가 진행되면서 관련 컴포넌트를 추가하여, 설계 모델을 보다 상세화하고 반복적, 점진적으로 완성해 나가게 됩니다. 그렇다면 지금부터 모델 기반 개발 방식으로 앞서 제시했던 건축 설계의 예를 다시 한번 설명해 보도록 하겠습니다.
● 모델 기반 개발 방식으로 예시 상황 설명
고객이 다양한 기능을 가진 ‘방문’을 요구하였습니다. 문짝과 문턱이 시공된 상태에서 방문이 닫히지 않는데, 자동화 공법으로 문턱의 시공은 완벽합니다. 따라서 그 원인이 잘못된 문턱 설계에 있거나, 고객이 사이즈를 잘못 요구한 것 같습니다. 고객과 설계자가 문턱의 설계 모델을 함께 살펴보았더니, 휠체어가 다닐 수 있게 하려면 문턱을 제거하는 것이 낫겠군요. 설계 모델을 수정한 후, 방문 테스트를 다시 수행합니다. 수많은 문의 기능들은 추가 테스트가 필요 없습니다.
● MDD(모델 기반 개발 방식) 관점으로의 해석
상황의 예
MDD 관점으로의 해석
문짝과 문턱이 시공된 상태에서 ‘방문’이 닫히지 않음
전체 집이 완성되기 전에 방문 컴포넌트만 테스트를 수행함
자동화 공법으로 문턱의 시공은 완벽하므로, 그 원인은 잘못된 문턱 설계 또는 고객의 잘못된 사이즈 요구에 있는 것 같음
자동 생성된 소스 코드에는 이상이 없으므로, 그 원인은 문턱의 잘못된 ‘설계 모델’이나 고객의 ‘요구 사항’에 있는 것 같음
고객과 설계자가 문턱의 설계 모델을 함께 살펴봄
누구나 이해하기 쉬운 모델로 고객과 의사 소통하며, 문제점을 파악함
휠체어가 다닐 수 있게 하려면, 문턱을 제거하는 것이 낫겠다는 결론이 나옴
문제점을 파악하는 과정에서 문턱이 필요 없다는 새로운 요구 사항을 알게 됨
설계 모델을 수정한 후, 방문 테스트를 다시 수행함
모델에서 문턱을 없애고 문짝을 수정한 후, 소스 코드를 자동으로 생성하여 다시 테스트를 수행함
수많은 문의 기능들의 추가 테스트가 필요 없음
방문의 기능들은 별도의 개별 컴포넌트로 설계되었기 때문에 문짝의 크기가 변경되어도 영향을 받지 않음
MDD(모델 기반 개발 방식)의 가치
1) 비즈니스 설계의 최적화 실현
MDD는 기존의 방식에 비해 비즈니스 설계를 최적화시킬 수 있다는 장점이 있습니다. 고객의 복잡한 요구 사항도 컴포넌트를 분리 설계하여 기능 확장에 유리한 구조이기 때문이죠. 반복적으로 사용되는 기능은 공통 컴포넌트로 구현하여 재사용성을 높일 수 있습니다. 또한 전체 시스템이 완성되기 전에 컴포넌트별 조기 테스트를 통해, 설계 초기 단계에서 문제점을 발견 및 수정하여 비용을 절감할 수 있게 해 줍니다.
MDD에서의 개발, 즉 프로그래밍은 인간의 수작업이 반드시 필요하다는 한계를 뛰어넘어 100% 자동화되었습니다. 그로 인해, 개발 생산성이 향상되고, 절약된 시간을 활용해 고객의 비즈니스 요구 사항에 대해 더 많이 고민하고, 정확하게 설계할 수 있게 되었습니다. 또한 설계 모델과 구현 기술이 분리되었는데요. 소스 코드와 개발 프레임워크가 밀착되어 있던 기존의 개발 방식과는 달리, 설계 모델의 변경 없이 프레임워크의 업그레이드나 변경이 가능합니다.
유지 보수 측면은 어떨까요? 기존 개발 방식에서는 고객이 정보 시스템에 대한 소스 코드 내부 파악이 거의 불가능했습니다. 문서로 작성된 산출물을 통해서는 부분적으로 관리가 가능했죠. 반면, MDD로 만들어진 모델은 고객 입장에서 가장 구체적이고, 100% 현행화되어 있어 고객이 직접 해석할 수 있을 뿐만 아니라 관리가 가능한 자산이 될 수 있습니다. 업무 인수인계 시에도 별도의 문서 작업이 필요 없는데요. 가시적인 설계 모델로 쉽고 빠르게 업무 파악이 가능하기 때문입니다. 또한 유지 보수 인력을 탄력적으로 운영할 수 있습니다.
2) 일하는 방식의 변화
개발자들이 수작업으로 진행하던 프로그래밍을 기계(MDD 자동화 도구)가 대신하게 되면, 실업을 유발할 것이라고 생각하기 쉽습니다. 그러나 실업은 실제로 그 사람들의 직무를 전환하지 않고, 정책적으로 ‘해고’하고자 할 때 일어나는 것이죠.
MDD를 하게 되면 설계자와 개발자 모두 비즈니스 설계 중심으로 업무 방식이 바뀝니다. 우선, 설계자는 개발자와 의사소통하기 위해 프로그래밍 언어를 습득할 필요가 없죠. 또한 자동화 기능을 통해 자신이 설계한 결과물을 테스트까지 수행함으로써 설계를 보다 정밀하게 할 수 있습니다. 개발자는 단순 반복인 프로그래밍 대신 더 가치 있는 모델 설계자로 역할이 전환되어, 비즈니스 전문성을 키울 수 있습니다. 그리고 비즈니스가 아닌 전문 분야에서 일을 하고 싶다면, MDD 자동화 도구 등의 MDD 기반 기술을 개발하는 새로운 역할 수행이 가능합니다.
LG CNS는 MDD로 인한 업무 방식 변화에 대비하여, 여러 가지 교육 프로그램을 만들고 프로젝트 참여 인력들이 쉽게 적응할 수 있도록 체계적인 전환 교육을 실시하고 있습니다.
지금까지 ‘기술’에서 ‘비즈니스’ 중심으로 변화하고 있는 MDD(Model Driven Development)에 대해 함께 살펴보았습니다. MDD를 활용하면, 기존의 프로그래밍을 주 업무로 하는 많은 사람들이 보다 쉽고 여유롭게 일을 할 수 있고, 효율적인 시간 활용이 가능하게 될 텐데요. 이것이 바로, 진정한 ‘비즈니스 중심의 모델링’이 아닐까 생각합니다.
글ㅣLG CNS MDD기술팀
