1.
저와 무관한 일이라서 생각해서 무관심했습니다. 교보생명과 SK C&C가 불꽃 튀는 공방전입니다. 어느 날 아는 후배가 전화를 주었습니다.
“교보생명과 SK C&C가 왜 공방을 벌이는지 궁금해요”
생명보험사에서 중요한 직책을 맡고 있으니 관심사항일 듯 합니다. 이곳저곳에 전화를 넣어보니까 쟁점을 이해할 수 있었습니다. 사실 신문에 나온 이상은 아닙니다. 읽어본 기사중 가장 사실에 가깝게 정리한 글입니다.
교보생명 제안요청서(RFP)가 논란 판단의 열쇠…내용 살펴보니 = 양측 공방의 진위를 알아보기 위해 <본지>는 지난해 11월 초, 교보생명이 금융IT업계를 대상으로 배포했던 제안요청서(RFP)를 다시 한번 살펴봤다.
당시 제안요청서 ‘6.2 개발방법’ 항목 부문에서, 교보생명측은 입찰에 참여한 IT서비스업체들에게 상세한 개발방법론을 제출할 것을 요구했다. 다만 제안요청서상에서는 MDD 등 특정 개발방법론 모델이 별도로 언급되지는 않았다.
교보생명은 ‘프로젝트 개발방법론 설계 및 상세 정의’ 항목과 관련, ▲국내외 보험사및 금융권 구축사례에 기반한 최적의 개발방법론 제시할 것 ▲영역별 별도 방법론을 사용할 경우 각 방법론에 대한 설명 포함 필요 ▲본 사업의 착수부터 종료까지의 전반적 수행절차를 각 단계별 목표, 세부절차, 주요 영역, 기법및 산출물을 포함하여 제시할 것 ▲영역간및 영역 내 세부 영영 간 연관성을 논리적으로 기술하여 제시 할 것 등을 요구했다.
비교적 상세하게 제안서을 통해 IT서비스업체들이 최적의 개발방법론을 제시하도록 요구했음을 알 수 있는데, 이는 보기에 따라서 여러가지 해석을 낳을 수 있다.
‘왜 사전에 필터링되지 않았나’…의문 = 정말로 특정 개발방법론의 유무가 우선 협상이 결렬될 정도로 ‘중대한 하자’라고 한다면, 한가지 의문이 제기될 수 있다.
개발방법론에 대한 교보생명 내부 기술평가에서 SK와 LG CNS간의 점수 격차가 있었는지, 또는 만약 이 부분에서 점수 격차가 없었다면 추후 우선협상 과정에서 불거진 문제는 어떻게 성격을 규정해야하는지 등의 문제가 제기될 수 있다.
또한 개발방법론이 ‘사후 검증’과정에서 뒤늦게 불거진 문제라면 사후 검증과정 프로세스는 당사자들이 모두 납득할 수준의 정치한 내용이었는지도 따져봐야 할 문제다.
이와함께 MDD 개발방법론의 적용이 차세대시스템 개발의 핵심 사안이었다면 교보생명측은 왜 사전에 제안요청서 단계에서 이를 구체적으로 명시하지 않았는지에 대한 문제도 제기될 수 있다.
한편 이번 논란과는 별개로 ‘개발방법론이 과연 차세대시스템 프로젝트를 좌우할만큼의 중대 사안인가’에 대해서는 금융IT업계 전문가들의 견해가 엇갈린다.
교보생명 차세대 협상결렬, 누구 책임?… RFP 내용 살펴보니중에서
같은 내용을 제안사를 중심으로 재작성한 기사입니다. SK C&C는 MDA(Model Driven Architecture)를, LG CNS는 MDD(Model Driven Development)를 제안하였고 어떤 배경과 계기가 있었는지 모르지만 MDA가 요건을 충족시키지 못하는 방법론이라는 내용입니다.
협상 결렬의 책임을 두고 SK㈜C&C 측은 교보생명 측이 차순위 사업자인 LG CNS와 계약하기 위해 제안요청서(RFP) 상에 없었던 ‘개발소스 자동생성’을 요구했다고 주장했다. SK㈜C&C 관계자는 “RFP 상에는 기본소드 자동생성은 언급하고 있었으나 개발소스 자동생성은 요구하지 않았다”며 “개발소스 자동생성은 국내에서 LG CNS의 개발방법론인 MDD(Model Driven Development·모델 주도 개발)로만 가능해 사실상 LG CNS와의 계약을 염두에 둔 것이 아니냐고 생각된다”고 밝혔다.
개발방법론은 개발과정부터 품질관리, 문제조치 등의 일련의 과정을 뜻하는 것으로 SK㈜C&C가 사용하는 방법론은 MDA(Model Driven Architecture·모델 주도 설계)다.
이 관계자는 “각사마다 자사만의 특화된 개발방법론을 갖고 있어 다른 회사의 방법론을 사올수도 없고 설사 사온다고 해도 기존의 방법론을 수정해 적용하기는 어렵다”며 “협상 과정에서 특정 회사만 갖고 있는 방법론을 제시하는 것은 무리한 요구다”고 밝혔다.
이 관계자는 “만약 개발코드 자동생성까지 요구할 것이었다면 그 때 ‘스펙 아웃’을 시켰어야 했다”며 “협상 과정에서 타사의 개발방법론을 요구한 것은 맥도날드를 뽑아놓고 버거킹 햄버거를 가져오라는 식이다”고 말했다.
SK㈜C&C 측은 아울러 LG CNS 측과 친분이 있는 황주현 부사장이 교보생명의 차세대 사업 자문단을 이끌게 된 것에도 의혹을 제기했다. SK㈜C&C 측은 교보생명이 예초 예정된 우선협상자 발표를 미루고 자문단을 꾸린 뒤 실시한 재평가에서도 SK㈜C&C가 1위를 하자 LG CNS와 계약하기 위해 의도적으로 협상 과정에서 무리한 요구를 했다고 주장했다.
이에 대해 교보생명 측은 SK㈜C&C가 제시한 소스코드의 자동 생성률이 실제 시연을 해본 결과 기대에 미치지 못한 것이 원인이었다는 입장이다. 교보생명 관계자는 “지난 3월 14일 SK㈜C&C를 우선협상대상자로 선정한 후 세부적으로 검증하는 과정에서 우리가 원하는 기술 수준에 미치지 못하는 부분이 있었다”며 “이를 보완하기 위한 적정 인력 투입이나 핵심 인재 확보를 요청했으나 받아들여지지 않았다”고 말했다.
교보생명 측은 총 사업 기간을 30개월로 예상하고 있으며 그 기간 동안 월 326명의 인력을 투입하는 것을 적정선으로 잡고 있다. 이 인력은 SK㈜C&C가 제안한 인력 투입 규모보다 월 기준으로 76명이 많은 수준이고 LG CNS가 제안한 것과는 거의 같은 수준으로 알려졌다.
이 관계자는 또한 “SK㈜C&C가 MDA방식을 제안하면서 MDD 개발방법론을 지원하겠다고 밝혔다”며 “두 방법론은 모델 기반의 방법론이라는 점에서는 똑같다. 구현 수준이 떨어지니까 우리가 다른 걸 구현해달라고 하는 것처럼 말하고 있다”고 말했다.
SK C&C, 교보생명 시스템 구축 협상 결렬··· ‘밀어주기 공방’ 확산중에서
2.
솔직히 처음 MDD를 들었을 때 이상했습니다. 제 기억에 있는 MDD는 Java로 여러가지 프로젝트를 하고 있었던 2005년을 전후한 때 자주 찾던 Theserverside.com에서 보았던 개념이었습니다. 마이크로소프트가 인수한 이후 영향력이 줄었지만 지금도 남아 있는 2004년 글에서 MDD의 흔적을 볼 수 있습니다. SOA(Service Oriented Architecture)의 영향력이 커지는 상태에서 생산성을 높이기 위한 방법론으로 이해했습니다.
The holy grail of model-driven development
그리고 10년이 지난 후 한국에서 MDD와 MDA가 부활하는 듯한 느낌입니다. 계정계 금융시스템의 방법론으로 기억속에 낭아 있는 단어는 프레임워크와 이를 기반으로 방법론인 CBD방법론입니다. 그런데 2011년에 나온 한국은행 컨퍼런스 자료를 보니까 MDD에 대한 모색이 있었더군요. 더불어 MDD의 미성숙을 덧붙이고 있습니다. 제가 신한은행시스템을 개발하였던 때가 2009년이니까 MDA 혹은 MDD가 보편화하기 이전입니다.
개발 언어 및 방법론: X10 및 Python 등 더 business 지향적인, java 이후 세대language가 시험적으로 사용되겠지만 코아뱅킹시스템이 요구하는 performance를 보장할 만큼 성숙하지 않아서 아직 보편화되기에는 이르고 , MDD(model driven development) 도 대규모 application 시스템을 개발하는 방법과 툴로서는 완전 하지 못함
그런데 2013년을 전후하여 MDA와 MDD가 차세대시스템을 개발하는 방법론으로 등장하고 사례가 나오면서 화두로 등장한 듯 합니다.
MDA가 적용되면 프로그램 설계자가 만든 업무 흐름 위주의 표준화된 모델이 MDA 엔진에 의해 자동적으로 자바 소스 코드와 문서로 생성된다. MDA 채택으로 표준화가 이루어지기 때문에 초급 개발자의 프로그래밍의 품질이 확보되고, 설계 모델과 프로그램소스의 일원화로 시스템 구축 이후 유지보수가 획기적으로 개선된다.
이러한 구현 방식은 코볼이나 C에 익숙한 대다수의 금융 IT 전문가들이 개발언어인 자바를 몰라도 자바 기반의 차세대시스템 구축을 가능하게 했다. 과거 개발자의 능력에 의해 프로그램의 품질이 결정되었다면 MDA는 업무흐름에 따른 표준적인 자바 코드가 생성되기 때문에 개발자의 역량을 초월한 향상된 프로그램 품질을 확보할 수 있다.
LG CNS, 전북은행 차세대 시스템 성공적 구축중에서
LG CNS가 전북은행의 성공이후 MDD를 적극적으로 홍보하는 글입니다. 이번 교보생명도 같은 방법론으로 제안했을 듯 합니다.
프로그래밍 언어 없이도 프로그래밍이 가능한가요? (1편) – MDD(Model Driven Development), 모델 기반 개발 방식
프로그래밍 언어 없이도 프로그래밍이 가능한가요?(2편) – MDD(Model Driven Development), 모델 기반 개발 방식
‘기술’에서 ‘비즈니스’ 중심으로 – MDD(Model Driven Development), 모델 기반 개발 방식의 변화
3.
그런데 교보생명에서 다툼을 벌이고 있는 MDA와 MDD. 어떻게 같고 어떻게 다를까요? MDA는 OMG가 표준으로 정한 방법론입니다.
MDA – The Architecture of Choice for a Changing World
위를 보면 처음 MDD가 나왔던 때는 2000년입니다. CORBA를 기반으로 한 방법론이었습니다. 그리고 계속 진화하여 현재 2.0까지 표준으로 나온 상태입니다. OMG가 MDA를 어떻게 정의하는지를 살펴보기 위해 Object Management Group Model Driven Architecture (MDA) MDA Guide rev. 2.0 을 보면 이런 표현이 등장합니다.
MDA is a family of standards, not a single standard
방대한 문서를 읽어보고 정리할 능력은 없습니다. 다만 MDA는 어떤 절차를 통하여 구현으로 이어질까요? 이를 설명한 Model Driven Engineering의 일부분입니다. MDA는 ‘Transforming the system specification into one for a particular platform’을 지원(support)합니다.
The MDA approach defines three model layers meant to be used as abutments:
Computation Independent Models (CIMs) describe business objects and activities independently of supporting systems.
Platform Independent Models (PIMs) describe how business processes are supported by systems seen as functional black boxes, i.e disregarding the constraints associated to candidate technologies.
Platform Specific Models (PSMs) describe system components as implemented by specific technologies.Those models are meant to support the design and development of software components along a sequence of normalized tasks:
Specifying a system independently of the platform that supports it.
Specifying platforms.
Choosing a particular platform for the system.
Transforming the system specification into one for a particular platform.
또다른 토론, what are the differences between Model-driven Architecture, Model-driven development and Model-driven engineering and what are the similarities?을 보면 MDA와 MDD 및 MDE의 정의를 둘러싼 의견이 있습니다. 그렇지만 개인적으로는 아래가 와닿습니다.
Model Driven Architecture is like a guide stablished by the OMG as a standart to implement Model-Driven Development (MDD), which is a software development paradigm that uses models as the first class elements in the develoment process . Model-Driven Engineering are those activities covering an engineering process to develop software (taskt, documentation, etc.)
IEEE에 실린 The State of Practice in Model-Driven Engineering의 정의도 유사합니다. InfoQ에 실린 The State of Practice in Model-Driven Engineering에는 없는 부분입니다.
이런 정의에 따르면 RFP상의 개발방법론은 MDD나 MDA도 아닌 MDE로 이해할 수 있습니다. MDD라고 주장을 하든, MDA라고 주장을 하든 일정정도 코드 생성을 포함할 듯 합니다. 다만 어느 수준인지는 솔류션에 따라 다를 듯 합니다. 역시나 기준은 RFP입니다. RFP상에 발주자의 요구사항을 명확히 하지 못하면 전적으로 발주사가 책임을 져야 합니다. 그런데 한국의 RFP는 두리뭉실 그 자체죠. 해석을 해야 이해를 할 수 있고 확정을 할 수 있는 제안요청서입니다. 그래서 해석의 권한은 갑에게 있죠. 개인적으로 SK C&C가 끝까지 항의를 했으면 합니다.(^^)
또한 솔류션이 아닌 표준으로서의 MDA를 이해할 필요가 있습니다.
