“용두사미가 되고 말았다.” 차세대시스템 프로젝트 현장에서 자주 듣는 표현이다. PI 또는 ISP를 통해 수립한 목표 모델이 시스템 구축 과정에서 흔적도 없이 사라지는 현상을 가리킨다. 목표 모델은 투자의 정당성을 획득하기 위한 것일 뿐 실제 개발된 시스템은 목표 모델이 추구하고 있는 모습을 만들어내지 못하는 경우가 흔히 발생하고 있다.

수립된 목표 모델과 구축된 결과물의 괴리는 상당하다. 목표 모델에 따라서 시스템을 구축하는 것은 현실적으로는 불가능하다고 말하는 사람도 있다. 시스템 구축에 들어가면 개발자들은 목표 모델보다는 현재 시스템을 토대로 설계하는 경향이 있다. 이렇게 해서는 목표 모델을 구현하여 비즈니스 성과를 혁신하고자 하는 당초 목적을 달성할 수가 없다.

목표 모델을 그대로 구축하는 것은 과연 불가능할까?

실제 현장에서는 목표 모델과 구축이 따로 논다

차세대 프로젝트의 소요 예산은 적게는 수백억 원에서 많게는 수천억 원에 이른다. 보통 2년 이상의 기간에 걸쳐서 수백명이 투입된다. 기간이 길어지고 인원이 많아질수록 목표 모델의 사상을 구현하기는 어려워진다. 대규모 프로젝트가 아니더라도 목표 모델에 맞게 구현하는 것은 쉽지 않다.

일반적으로 시스템 구축을 착수하기 전에 컨설팅 프로젝트부터 시작한다. 시스템 구축은 단순히 하드웨어나 소프트웨어 도입만으로 이루어지지 않는다. 먼저 구축하고자 하는 목표 모델을 정의하고 이를 실행하기 위한 방안을 수립해야 한다. 목표 모델 수립은 현재의 문제점을 개선하는 것과 새로운 비즈니스 방식을 도입하는 것도 반영해야 한다.

컨설팅은 대개 정보전략수립 또는 프로세스혁신 등으로 수행된다. 경영 전략을 토대로 비즈니스 프로세스를 정의하고 이를 작동시키기 위한 정보시스템의 미래 모습을 설계한다. 그리고 이를 달성하기 위한 마스터플랜을 수립한다. 구축 과정에서는 프로젝트 관리(PMO) 서비스를 통해 프로젝트의 품질과 진도, 리스크 등을 관리하는 일로 이어진다.

필자는 같은 고객사를 대상으로 PI/ISP와 PMO 컨설팅을 이어서 수행하였다. 수행 과정에서 발견한 것은 앞선 PI/ISP 프로젝트의 산출물은 참고자료일 뿐, 개발을 담당하는 SI회사는 그들의 방법론에 맞춰 분석과 설계 작업을 새로 한다는 것이었다. 컨설팅과 구축 단계를 이어주는  ‘요구사항정의서’라는 산출물은 있다. 하지만, 요구사항은 텍스트로 된 산출물이기 때문에 결국에는 서로가 모여 눈높이를 맞추고 공유하는 과정이 필요하다.

요구사항을 어떻게 ‘빠르게’ 파악하고, 모두가 같은 시각으로 이해할 수 있도록 ‘가시화’할 것인가를 해결하기 위해서 실제 프로젝트에서는 다양한 방법을 활용한다. 통상적으로는 워크숍을 통해서 개발회사가 만든 분석 설계 보고서를 함께 검토한다. 이때 적용하는 기법 및 산출물로는 프로세스정의서, 프로세스맵, 액티비티정의서, User-story map, 고객여정지도, 이벤트반응 분석 등이 있다.
 

[그림 1] 요구사항 삼각형

그러나 이런 산출물은 컨설팅 단계에서 고객의 비즈니스 담당자와 커뮤니케이션 하기에는 유용한 도구이나 SI(개발자)들과 소통하기에는 어려움이 있다. 이는 구축 프로젝트에서 SI(개발자)는 좀 더 구체적인 산출물이 필요하기 때문이다. 예를 들면 “이 화면 그대로 만들어 주세요” 라고 고객이 요구하더라도, 개발자는 “이 데이터를 조회했을 때 default 값은 뭐로 할까요?”, “이 화면에서 버튼 명도 그대로 할까요?” 같은 질문을 해결해야 하기 때문이다. 

개발자에게 목표 모델을 그들의 언어로 설명해주기 위한 방법

일반적으로 목표 모델은 파워포인트 도구를 사용하여 작성한다. 그림과 문장으로 목표 모델을 설명한다. 하지만 이는 개발자에게는 완전한 산출물이 아니다. 개발자는 업무를 액티비티와 데이터 그리고 인터페이스 등으로 이해해야 하기 때문이다. 목표 모델을 기술한 언어와 개발자가 분석 설계하기 위한 언어가 다른 것이다.

이를 해결하기 위한 방법은 프로세스 모델링 도구를 사용하는 것이 바람직하다. 개발자가 빠르고 정확하게 이해할 수 있는 방식으로 목표 모델을 기술하는 효과가 있다. 해외에서는 흔히 사용하는 방식이다. 또한 디지털 탈바꿈을 위해서는 필수적으로 적용되어야 한다. 우리나라에서는 테크놀러지 기업 중심으로 사용되고 있을 뿐, 금융회사들은 아직 익숙하지 않은 방법이다.

‘프로세스 모델링 도구 활용’의 기본적인 사상은 BPMN(비즈니스 프로세스 모델 및 표기법)을 활용하여 프로세스를 그리는 것이다. 이 때 정의한 User(actor)별 activity에 대한 설명을 Use-case로 표현하면, 비즈니스 사용자가 자신의 업무를 쉽게 이해할 수 있다. 뿐만 아니라 사용자 화면과 인터페이스도 정의할 수 있고 데이터 모델도 비즈니스 프로세스에 맞게 생성된다. 이렇게 하면 개발자와 비즈니스 사용자 간에 커뮤니케이션 오류가 발생할 수 있는 여지가 제거된다.

목표 모델을 정의하는 방식은 두 가지가 있다.

1) 프로세스 모델링, 화면설계, 데이터 연계와 코딩을 한 사람이 하는 방법
2) 상세한 프로세스 모델링과 화면 설계를 하면 개발자가 데이터 설계와 코딩을 하는 방법

물론 가장 이상적인 방법은 1)로 모델링과 코딩을 한번에 하는 방법이다. 하지만 현실에서 업무와 모델을 모두 다 아는 사람이 드물어 1)번 방법은 전문 모델러와 업무 분석자가 한 팀이 되어 상세하게 모델링을 하고 이 팀이 정의한 상세 스펙을 보고 개발자가 개발하는 방법이 통상적이다.

2)번 방법은 프로세스 모델링과 화면 설계 업무를 이해한 Business Analyst가 모델링하고, 개발자는 데이터 연계와 코딩을 수행하는 방법이다. 이 방법은 ①프로세스를 시스템 관점으로 한 단계 상세화 하는 것, ②화면 정의와 설계 명세 상세화로 요약할 수 있다.

- 끝 -

* 본 글은 ‘목표 모델 그대로 구축하기 2부: 프로세스 모델링 도구 사용 방법’으로 이어집니다.