“기존 시스템의 소스 코드를 분석하여 모델을 만들어내는 방법”

이것은 LG CNS에서 설명하는 MDD-R의 정의입니다. 의미를 살펴보면 MDD-R은 소스를 분석하는 도구로 추측이 됩니다. 그런데 일반적으로 프로젝트 현장에서 소스를 분석할 때 체인지마이너(ChangeMiner) 등과 같은 영향분석 도구를 사용하는데요. MDD-R은 이런 도구와 비슷한 것일까요?

위에 적힌 MDD-R의 정의를 다시 찬찬히 살펴보겠습니다. “모델을 만들어내는 방법”이라는 문구가 있는데요. 산출물이 모델이 된다는 것이 다른 점 같습니다. 그런데 또 의문이 생깁니다. ‘모델은 왜 만드는가? 만들어서 어떻게 활용할 수 있는가?’

저는 2015년, MDD-R을 이용한 여러 프로젝트를 경험하게 되었는데요. 그 경험을 바탕으로 처음에 제가 가졌던 의문에 답을 해보려고 합니다.

소스 코드를 분석?

MDD-R은 소스 코드를 분석해 여러 산출물을 제공해준다는 점에서 기존의 영향분석 도구와 많이 닮아있습니다. 제가 참여했던 프로젝트에서는 MDD-R을 통해 프로그램•인터페이스 목록, 호출 관계도, CRUD 매트릭스 등을 엑셀 문서로 받아볼 수 있었는데요.

프로그램 목록에서는 LOC 정보까지 알려주어 현행 시스템 규모를 파악하는데 활용할 수 있었고, 호출 관계도를 통해 여러 프로그램에서 호출하는 기능을 확인하고 공통기능 대상을 추출하는데 활용하기도 했습니다. 이러한 것들은 사실 기존의 영향분석 도구를 이용했을 때에도 충분히 제공 가능한 기능입니다.

제가 느꼈던 MDD-R의 기존 영향분석 도구와 가장 큰 차이점은 MDD-R은 단순히 현재의 시스템을 분석하는 것을 목적으로 하는 것이 아니라, To-Be의 관점을 반영한 모델을 생성해준다는 점입니다.

MDD-R이 만들어주는 모델은 기본적으로 객체지향의 모델입니다. 모델이 UML로 표현되고, UML이 객체 지향적 분석•설계 방법론의 표준 지정을 목표로 하는 모델링 언어인 만큼 당연한 이야기죠. 이 말은 곧, 현행 시스템이 COBOL이거나 C이거나 관계없이 MDD-R은 모듈은 Class로 변환해 구조를 생성하고, 모듈 내 기능은 Operation으로 변환해 호출 관계를 시퀀스 다이어그램으로 표현해줍니다.

단순히 객체지향 모델로 만들어준다고 해서 To-Be 관점이 반영되었다고 할 수 있을까요? MDD-R에서는 현행 시스템의 모듈을 특정 레이어로 정의해서 모델로 변환할 수 있습니다.

예를 들어 C언어로 개발된 시스템이 있습니다. A라는 패키지 밑에 있던 .c 모듈은 주로 UI에서 호출되고, C라는 패키지 밑에 있는 .c 모듈은 주로 다른 모듈에서 호출해서 사용한다는 분석 결과가 나오면, A 패키지 밑에 있는 모듈은 프로세스 컴포넌트로, C 패키지 밑에 있는 모듈은 공통 컴포넌트로 변환하는 것이죠.

또는 DB를 호출하는 부분이 모듈이 아닌 단순 코드 라인으로 존재하는 경우, DAO(Data Access Object) 클래스를 생성해 해당 클래스를 호출하는 것으로 시퀀스 다이어그램에 표현해줄 수도 있습니다.

모델의 사용 용도는?

MDD-R의 가장 강력한 특징 중에 하나는 바로 ‘Re-Structuring’입니다. 일례로 EJB 컴포넌트 모델을 기반으로 구축된 시스템에 MDD-R을 적용했던 경험이 있었는데, 해당 시스템은 비즈니스 로직을 처리하는 컴포넌트와 DB 핸들링을 담당하는 컴포넌트 사이에 EJB와 EJB Proxy 레이어를 두고 있었습니다.

To-Be에서는 EJB 관련된 레이어를 제외한 모습으로 모델을 그려야만 했기에 해당 레이어를 제거해야만 했습니다. 기존 시스템의 일부분이니 그냥 제거할 수는 없고 MDD-R의 시퀀스 다이어그램 일괄 병합 기능을 통해 EJB 레이어의 로직을 비즈니스를 처리하는 컴포넌트 로직에 포함시킨 후 제거한 모델로 생성할 수 있었습니다.

기존 시스템의 일부를 다른 곳에 병합하는 것만 가능한 것이 아닙니다. 기존 시스템에 없는 것을 생성하는 것도 가능한데요. 하나의 커다란 시스템으로 구성되어 있는 기존 시스템을 To-Be에서는 최상위 업무기준으로 5개의 시스템으로 분리된 모습으로 모델을 그려야만 했습니다.

이 때 분리된 시스템 간의 직접 호출은 할 수 없도록 해야만 했습니다. 이러한 요건을 반영한 변환 규칙을 MDD-R에 적용하여 5개의 분리된 모델과 분리된 모델간 연동을 책임지는 컴포넌트를 추가로 생성하여 호출하도록 모델을 생성했습니다.

이런 식으로 현행 시스템 그대로 모델로 생성하는 것이 아니라, To-Be의 모습을 먼저 정의하고 그에 가깝게 생성하다 보니 구축 대상 시스템의 모습을 손쉽게 파악할 수 있었는데요. 더군다나 만들어진 것은 문서가 아닌 시각화된 모델이었습니다.

이런 측면에서 MDD-R은 단순히 To-Be 시스템에 가까운 모델을 확인하는 용도로 그치지 않습니다. 생성된 To-Be 모델에 신규 기능을 반영하고 필요 없는 기능은 삭제하면서 모델을 수정한 후, MDD-F를 통해 소스 생성까지 이어진다면, 현행 시스템을 바탕으로 To-Be 시스템을 구축할 수 있게 되는 것입니다.

MDD-R의 만족도는?

현행 시스템을 To-Be 모델에 가까운 모델로 만든 후, 이를 바탕으로 소스를 생성해서 시스템을 구축한다는 게 정말 가능할까요? 현행 시스템의 품질에 따라서, 또는 현행 시스템과 To-Be 시스템의 Gap이 얼마나 차이가 있는가에 따라 MDD-R 적용 만족도가 매우 달라진다는 결론을 얻었습니다.

우선 현행 시스템이 표준 없이 중구난방 개발된 시스템이라고 가정해보겠습니다. 엉망진창으로 되어있는 시스템을 그럴싸한 모델로 만들어줄 수는 없습니다. 모든 프로그래밍언어가 input에 따라 output이 나오는 것처럼 MDD-R도 마찬가지인데요.

더군다나 MDD-F를 적용하기 위한 모델은 한글로 작성되어야 합니다. 현행 시스템이 용어 표준 없이, 메타를 적용하지 않은 시스템이었다면 온전히 한글화된 모델로 만드는 것 역시 불가능합니다.

만약 용어를 포함한 시스템 표준화가 잘 적용되어 있다면, 변환된 모델로 금세 소스 코드를 생성할 수 있을까요? ‘현행 시스템의 화면이 전부 합쳐지고 나눠지는 등 변경되었다면? 화면이 아니라 DB가 모두 변경되었다면?’ 이런 경우는 현행시스템 기준으로 생성된 모델에 To-Be의 변경된 요소(화면이든 DB든)를 반영하는 작업이 상당히 많을 수 있습니다.

그럼 쓸모없다는 것일까요? 물론 아닙니다. 진행했던 프로젝트 가운데 현행 시스템의 기능은 유지한 채 프레임워크 변경이나 최신화를 원하는 요구 사항이 꽤 있었고, 이를 위한 방법으로 MDD-R을 적용했습니다.

몇몇 프로젝트는 현행 시스템의 표준화가 꽤 잘 되어 있어 만족할만한 결과를 내기도 했습니다. 즉, 프레임워크 변경, 현행 시스템 표준화 또는 분석, To-Be 시스템의 컴포넌트 구조 도출 등 적용하려는 목적을 명확히 한다면, MDD-R이 상당한 도움이 될 수 있습니다.

여러 MDD-R 프로젝트에 참여하면서, 많은 개발자가 참여하는 프로젝트일수록 용어나 코딩 등의 표준을 잘 지켜 일정 수준의 품질을 확보하는 것이 얼마나 중요한지 느낄 수 있었는데요. MDD로 프로젝트를 수행한다면 보다 편리하게 품질을 확보하실 수 있으실 것입니다.

MDD를 활용하여 모델 중심으로 프로젝트를 진행하면 품질 및 생산성 향상 효과뿐만 아니라, 기술 변화에 유연하게 대처할 수 있다는 장점이 있는데요. 소프트웨어 산업이 앞으로 MDD와 함께 더욱 발전해 나가기를 기대합니다.

글 ㅣ LG CNS MDD기술팀

[‘최첨단 소프트웨어 개발 방식 MDD’ 연재 현황]

• [1편] 최첨단 소프트웨어 개발 방식으로 미래를 대비하자 http://blog.lgcns.com/1186
• [2편] AS-IS를 통해 TO-BE 바라보기, MDD-R http://blog.lgcns.com/1187