DATOR


BPM을 이용한 개발 프로세스 고도화...(주)엔코아 홍희도 수석 연구원 커버 스토리


coverstory.jpg

지난 9월 프로젝트를 마무리하고 오픈한 모 생보사의 개발체계 고도화 프로젝트는 특이한 프로젝트라고 할 수 있다. 현업의 요청이 아닌 그룹사 ITO조직의 제안을 현업이 수용하여 시작된 프로젝트이기 때문이다. 목적은 프로젝트 이름처럼 시스템 개발 프로세스를 고도화하기 위한 것이었는데, Business Process Management(BPM)라는 개념을 도입하여 현재 사용중인 솔루션과 새로 도입되는 엔코아의 솔루션들을 엮어 체계적인 개발업무를 구현하는 것이었다. 이를 위해 프로젝트에 사용할 BPM엔진을 새로 개발하는 방안을 검토하였으나, 짧은 프로젝트 기간(최초 시작시점 기준)으로 인하여 기존 BPM솔루션을 이용하기로 하고 여러 제품들을 검토한 결과, 오픈소스 BPM엔진인 Activiti를 사용하기로 하였다.


커버스토리


[그림1 전형적인 BPM 프로세스]


기존 고객사의 개발 프로세스는 그룹웨어로부터 현업의 개발요건이 개발자에게 전달되고 개발자는 CA사의 변경관리 솔루션인 Harvest에 요건을 구현하기 위한 패키지(작업할 대상소스를 묶어놓은 덩어리)를 생성하여 개발할 소스를 등록하고, 하베스트가 제공하는 상태관리 기능을 이용하여 일종의 workflow를 따라 PL, ITO팀장, IT운영팀장의 승인을 거쳐 검증계, 운영계에 각각 개발내용을 반영하는 구조로 되어 있었다. 대부분의 요건은 개발자 한 사람이 모두 처리할 수 없기에 그룹웨어에서 발생한 하나의 CSR(Customer Service Request)은 여러개의 패키지로 나뉘어 처리되어야 하나 하베스트는 이러한 기능을 제공하지 않기 때문에, 최초 생성한 하나의 패키지를 split하되 그룹웨어의 "문서번호+개발자명"을 패키지명으로 지정하여 같은 CSR에서 발생한 것임을 간접적으로 나타내는 방법을 사용하고 있었다. 여기서 문제는 하베스트는 개별 패키지별 관리 중심이므로, 이렇게 하나의 CSR을 처리하기 위해 생성된 여러개의 패키지들을 통합하여 관리할 수 있는 방법이 없어 PL들은 그룹웨어의 문서명으로 패키지들을 검색하여 각 패키지의 진행상황을 확인할 수 밖에 없는 불편한 구조였다는 점이다. 이 외에도 원장정보 변경 또는 데이터 추출이 필요한 경우에는 DCMS(Data Change Management System)와 연동이 필요했으나, 업무처리 진행상태를 관리할 수 있는 방법이 하베스트 외에는 없었기 때문에 대상 소스가 없는 빈 패키지를 하베스트에 생성하여 처리하고 있었다.


커버스토리

[그림2 하베스트 워크벤치]


모델은 채널계의 일부 시스템을 제외하고는 관리가 되지 않고 있었고, 이번 프로젝트 진행시 DA팀이 DA#을 이용해 리버스 및 현행화를 통해 모델 구축작업을 동시에 진행하였다. C 언어를 사용하는 기간계 시스템은 요건에 따라 DB변경이 필요한 경우 10여년전에 도입하여 사용중이던 스펙트럼(Spectrum)을 이용하여 개발자가 변경내역을 신청하고 이에 따라 변경/생성되어야 하는 DB IO 파일을 생성해주는 방식을 사용하고 있었다. 스펙트럼은 표준관리나 DDL생성 등 기본적인 메타시스템의 역할도 하고 있었으나, 도입된지 오래되어 테이블명(8자)/컬럼명(30자)의 길이 제한 등 여러가지 제약사항을 안고 있었다.

이러한 개발 프로세스를 기존 시스템 사용을 거의 변경없이 유지하면서도 좀 더 체계적으로 관리하기 위하여, 기존 프로세스를 비지니스 프로세스의 표준이라 할 수 있는 BPMN(Business Process Model and Notation) 2.0 기반의 프로세스로 명시적으로 정의하고, 정의된 프로세스를 Activiti BPM엔진으로 진행시키면서, 필요한 여러 데이터들을 관리하기 위해 별도로 개발한 CSR시스템과 연계하였다. 본래 BPM시스템을 도입하는 경우, BPM솔루션에서 제공하는 메타 UI와 메타 모델을 이용하여 프로세스가 필요로 하는 모든 데이터를 입/출력하고 저장하는 것이 기본이지만, 실제 업무에서 필요로 하는 복잡한 UI와 데이터모델을 BPM이 제공하는 것으로만 구현하는 것은 너무나 어려운 일이었다. 이러한 문제를 해결하기 위해 BPM 프로세스 위에 얹혀진 별도의 CSR시스템을 개발하고 데이터의 상태를 BPM으로 관리하는 절충안을 도출한 것이다. 다만, 이렇게 할 경우 BPM 본연의 장점인 프로세스의 자유로운 변경과 여러 프로세스 버전이 동시에 실행가능하다는 점은 어느 정도 한계를 가지게 되는 단점이 발생한다. 그러나 개발 프로세스라는 것이 기본적으로 가지는 큰 줄기는 크게 바뀌지 않으면서, 주로 변경되는 것은 잔가지들이나 부가기능쪽이 대부분이라는 점에서 장단점을 절충한 방안이라고 할 수 있다.

이렇게 해서 개발된 최종 CSR 시스템은 그룹웨어에서 현업의 개발요건이 기안되고 최종 승인되면 CSR 시스템에 SR이 생성되고, 담당 파트의 PL이 해당 요건을 처리할 개발자를 지정하면 하베스트에 패키지가 자동으로 생성되어 작업대상 소스를 등록할 수 있게 준비해준다. 개발자는 현업이 입력한 요건을 보고 필요한 소스를 등록하는데, 이 때 연계된 AP#의 영향도 분석 기능을 이용하여 각 소스의 영향도를 파악하여 함께 수정되어야 할 소스를 미리 파악할 수 있도록 도와준다. 또한 기존 하베스트는 소스 변경관리를 위한 솔루션이었기에 모델에 대한 작업을 관리할 방법이 없었는데, CSR 시스템은 소스와 함께 수정되어야 하는 모델도 작업대상으로 등록할 수 있는 것은 물론 모델에 대한 영향도 분석 기능도 제공하고 있다. 여기서 작업대상으로 등록된 모델은 DA#에서 변경작업후 META#을 이용하여 신청시 CSR에서 해당 모델을 작업대상으로 등록한 패키지를 지정하여 연결해주고, 모델이 승인되었을 경우 스펙트럼을 이용하는 기간계 시스템의 모델이라면 스펙트럼에 DB IO생성을 위한 인터페이스 데이터까지 연계하여 입력해 주도록 구현되었다. 이로써 모델 변경내역을 관리하면서도 개발자가 스펙트럼 시스템에 별도로 변경내역을 신청할 필요가 없어져 업무는 단순화된다. 개발자가 작업한 소스는 형상관리 기능을 제공하는 하베스트에서 연동되는 체크아웃/체크인 기록은 물론, 단위테스트 및 JAVA를 사용하는 채널계인 경우 AQ#/SQ#을 이용한 소스 품질 검증 결과까지 입력되어 품질을 향상시킬 수 있도록 도움을 주고 있다.

이렇게 다양한 기존 고객사 솔루션 및 엔코아의 솔루션들과의 연계가 프로젝트의 핵심 과제 중 하나였는데, 외부 시스템과의 연계는 기본이 되는 Activiti에서 제공하는 RESTful API를 확장하여 CSR 및 엔코아의 기존 솔루션들에 대해서도 REST 서비스를 구현하여 해결하였다.

또 다른 CSR시스템의 핵심적인 기능은 하나의 고객요구사항이 관련된 여러 파트/업무의 패키지로 생성되는데 있어 제한이 없을 뿐더러, 개발일정에 따라 순차적으로 운영시스템에 반영되는 일종의 배포그룹인 Sub-CSR을 생성하여 여러개의 패키지들을 묶어서 반영할 수 있는데, 이렇게 생성된 많은 패키지들이 하나의 트리구조로 일목요연하게 제공되며 각각의 진행상태를 클릭 한 번으로 쉽게 확인할 수 있어, PL에게 납기준수를 위한 일정관리를 용이하게 해준다는 점이다. 또 단순히 선형적으로 진행되는 workflow가 아닌 데이터의 상태와 조건에 따라 여러개의 분기점을 가질 수 있는 프로세스 기반으로 정의되었기 때문에 하베스트보다 유연한 프로세스 구현이 가능하다. BPM 프로세스의 진행에 따라 CSR 시스템이 하베스트와 연계되어 패키지를 운영시스템에 최종 배포되도록 진행시켜 주므로 하베스트는 기존의 패키지 상태관리 기능을 뺀, 소스 형상관리와 배포 기능만을 남겨두었으며, 굳이 비싼 유지보수 비용을 들일 필요없이 오픈소스 기반의 형상관리/배포관리 솔루션들로 대체될 수 있어 비용절감의 가능성이 열리게 되었다.


커버스토리

[그림3-1 트리구조로 제공되는 패키지]


커버스토리

[그림3-2 트리구조로 제공되는 패키지]


이번 프로젝트는 기존 엔코아의 솔루션들과는 달리 개발 프로세스 공정관리라는 다소 생소한 분야를, 그것도 프로젝트 기간내에 개발해야 하는 점 때문에 일정상 많은 어려움을 겪을 수 밖에 없었다. BPM 시스템에서 중요한 각 시스템간의 연계도 대상 시스템이 많아 어려웠지만 가장 어렵고도 시간이 많이 소요됐던 것은 기존 ITO의 개발 프로세스를 규격화하여 정의하는 일이었다고 할 수 있겠다. 본인들이 일상적으로 수행하던 것을 정의하는데도 프로젝트 조직과 현업 개발자들간의 의사소통 문제라던가 정의된 프로세스를 시스템으로 구현해서 운영해보니 특정 구간에 병목현상이 발생하여 다시 수정한다던가 하는 점은 오픈후에도 또 다시 많은 시간이 소요되는 부분이었다.


그러나 CSR을 중심으로 DA#, META#, AP#, AQ#/SQ# 등 엔코아의 거의 모든 솔루션이 거미줄처럼 연계되어 결과적으로 고객사 개발 프로세스의 품질 향상 및 효율적인 운영을 가능케 했다는 점에서 의의가 있으며, 기존 여러 사이트에서 솔루션 도입후 적극적인 의지가 없는 경우 모델관리나 표준화 측면에서 흐지부지되어 제품을 사용하지 않음으로써 고객 스스로 엔코아 솔루션의 필요성에 대해 재고하는 케이스가 발생하곤 하던 것을, 개발 프로세스의 과정중에 엔코아 솔루션을 반드시 사용하도록 강제함으로써 원천적으로 차단하고 품질을 보장할 수 있게 된 점은 큰 의미가 있을 것이다.

오픈일 그리고 그 후로 몇 주 동안 갖가지 문제점으로 인해 마음 졸였던 시기가 지나고 이제는 어느정도 안정화된 시점에서, 운영사 대표이사에게까지 보고되어 좋은 평가를 받는 등, 현재는 전체적으로 긍정적인 반응을 보이고 있다. 모델변경사항에 대한 시스템 반영 프로세스에 있어서 일부 개선점이 남아있기는 하지만 이전과는 비할 바 없이 편리한 공정관리가 가능해졌다는 점에서 프로젝트에 참여한 인력의 한 명으로서 보람을 느끼고 있으며, 함께 프로젝트에서 고생했던 여러 동료 여러분들에게도 위로와 감사의 마음을 전하고 싶다.


한가지 더, 현재 CSR 시스템은 고객사에 의해 ADAMS(Advanced Development And Management System)라는 다소 작위적(?)이면서도 backronym스러운 이름을 가지게 되었다. 과연 CSR 시스템이 엔코아의 솔루션들을 견인하여 새로운 시장을 창출하는 아담이 될 수 있을까? (그런데 이브가 없잖아....)




Tag :

Leave Comments