"신사업 AI프로젝트는 업무와 관리요건 정의 병행해야"

[심기보의 AI프로젝트 성공 비결⑨] 요건정의3-업무 및 관리 기능

(지디넷코리아=심기보 전 정보통신기술사협회장)新사업이나 신서비스를 개발하는 AI 프로젝트는 업무 요건과 관리 기능 요건 정의를 병행해 진행하는 것이 효율적이다. 시스템 운영을 가정하면서 요건을 정리하면 된다. 요건정의 작업은 어느 정도 업무 프로세스 지식이나 경험 외에  관리 화면 등의 시스템 기능 지식도 요구된다. 아래는 화면(Front End) 요건정의를 끝낸 A사의 PM과 IT담당자간 오고간 대화다.

PM:관리 화면은 업무 시스템 화면과 똑같지요?

IT담당:그렇지요. 업무 요건을 먼저 정리하고 그 후 관리 화면 요건정의를 하는 것이 기본입니다.

PM:그러면 상당한 기간이 필요하겠네요!

기간계 시스템 개발 프로젝트는 먼저 업무 요건이 있고 그 업무를 실현하기 위한 시스템 기능인 화면 요건이 있다. 반면 AI 프로젝트의 신사업과 서비스 개발 프로젝트는 업무 요건과 관리 기능(관리 화면) 요건 정의를 병행해 하는 것이 효율적이다. 기존 업무가 있지 않기 때문에 어느 정도 업무를 시스템에서 실행할 것을 예상하면서 업무 내용을 정리해가면 된다. 예를 들면 매주 월요일에 '그 주에 발송 대상 빵을 구워 준비한다'는 업무가 있다고 하자. 이 때 우선은 준비할 빵의 개수를 확인하고, 업무 요건을 임시로 정리하면 아래표와 같다.

이 내용을 보고, 이대로 관리 화면의 기능요건으로 사용할 수 있다. 일부러 동일한 내용을 다른 성과물로 정의하는 것도 소용이 없기 때문에 업무 요건 겸 관리 기능 요건으로 해 두는 것이 좋다. 이렇게 새 시스템계 프로젝트는 업무 요건과 관리 기능 요건을 병행해 진행하면 좋다.

■운영 업무나 이에 필요한 시스템 기능 정리

업무요건 정의 및 관리기능 요건 정의는 시스템 제공에 필요한 운영 업무나 그 업무를 지원하는 시스템 기능의 요건을 정리하는 작업이다. 주로 실시하는 것은 아래의 표1과 같다.

운영 업무에서도 통지나 파일 출력은 발생하기 때문에 메일이나 SMS, 통지 요건 정의나 양식 및 파일 요건정의 등 화면 기능 요건과 동일한 작업이 있다. 업무요건 및 관리기능 요건 정의 작업은 어느 정도의 업무 프로세스 지식이나 경험 외에 관리 화면 등 시스템 기능 지식이 요구된다. 양쪽 모두를 갖춘 사람은 좀처럼 없다. IT 벤더나 컨설팅 회사에 지원을 의뢰하는게 좋다. 업무 지식이 있는 사람은 다음과 같다. 예컨대 A사 예를 들면 빵을 굽는 업무에 정통한 점포 출신 사원을 말한다. 시스템 기능 지식이 있는 사람이라면 일반적인 업무 플로우는 대충 이해하고 있기 때문에 드래프트(Draft)로서의 업무 요건은 정리할 수 있다. 반대로 업무 지식만 있는 사람이라면 시스템 지식이 없으므로 어디까지 시스템으로 할 수 있는지 몰라 업무 요건 정리가 지체되기 쉽다. 이 때문에 IT 벤더나 컨설팅 회사 요원을 메인(Main)으로 두는 것이 좋다.

■머리 속에서 업무를 시뮬레이션 

정의해야 할 업무 요건은 구상 단계와는 다르다. 구상 단계는 대략의 플로우를 정리하였지만, 요건정의 단계는 그림2처럼 플로우 하나하나(상자)의 업무 내용을 결정해 간다.

업무 요건 및 관리 기능 요건은 서비스 근간을 이루는 유스케이스에 우선도를 붙이며 정리해 간다. 이것은 화면(Front End) 요건 정의와 동일하다. 구상 단계에서 정리한 플로우를 보면서 그림3처럼 하나하나 상자의 업무 내용을 정의한다.

요건 정의는 시스템을 제공할 때 운영 시 무엇을 해야 할지를 '구상하면서' 정리하는 것이 포인트다. 현 시점에서 정답은 없기 때문에 머리 속 업무를 시뮬레이션하는 작업이 된다. 예를 들면  '주문 내용 확인 및 당월 분 주문 목록. 인쇄'라는 업무는 그림4와 같은 업무 요건 및 관리 기능 요건을 예상한다.

이것은 구상 단계에서 매월 작업하고 있지만 검토를 진행하는 동안 월별로는 이용자 편의성이 낮고 냉동실도 꽉 차버린다는 것을 알 수 있다. 그래서 매주 작업으로 변경했다. 이렇게 업무 요건도 요건정의 단계에서 필요에 따라 변할 수 있다.

점포에서 빵을 굽는 계획을 세울 때 필요한 것은 빵 종류와 각각의 개수 일 것이라고 예상할 수 있다. 또 점포에서는 그것을 인쇄물로 보는 것이 편리하다. 이러한 것에서 데이터를 CSV 형식으로 출력해 표 계산 소프트웨어(Excel) 등으로 인쇄할 수 있게 됐다. 점포 담당자가 확인을 잊지 않도록 매주 메일로 통지하는 요건도 포함시켰다. 이와 같이 실제로 시스템을 운영하고 있는 상황을 상상하면서 요건을 정리해 간다.

이들은 관리 화면에서 행하는 작업이기 때문에 관리 기능 요건이 된다. 관리 기능 요건을 정리하는 중에 메일이나 양식, 파일 등의 입출력 데이터가 등장하거나 배치 기능 등이 발생한 경우는 표와 같이 목록화해 정리해 두면 기능의 목록을 정리할 때 편리하다.

특히 관련 시스템과 교환이 발생할 때는 관련 시스템과 조정이 필요하다. 사양 조정이나 테스트 환경 준비, 어카운트(Account) 준비 등이다. 이러한 작업을 착실히 진행하기 위해서는 누락되지 않도록 조심할 필요가 있다. 예를 들면 빵을 구워 발송 준비를 하는 플로우 마지막에는 배송업자 용의 송장용 씰(Seal)을 인쇄하는 업무 요건이 있다. 인터넷 판매는 배송업자의 송장 인쇄 시스템을 이용하는 것이 일반적이므로 이 시스템을 이용한다.  이 시스템명을 그림5의 표 가장 오른쪽 열과 같이 기재한다. 이렇게 함으로써 누락을 방지한다.

한편, 관리 기능과 관계가 없는 업무 요건도 있다. 그림6처럼 재료의 재고 확인이나 상품 준비(빵을 굽는 것)는 시스템화 하지 않는다는 전제로 했다.

시스템화를 하지 않은 업무에 대해서는 업무 운용의 테스트인 통합 테스트 전까지 정리하면 좋으므로 요건정의에서는 깊이 생각하지 않는다.

■이용자 종류와 권한 정의

관리 기능 요건을 정리하면서 화면 레이아웃이나 메일 및 양식, 파일 등의 요건도 결정해 간다. 이 작업은 화면 기능 요건 정의 작업과 기본적으로 동일하다. 화면(Front End) 기능 요건과 다른 것은 관리 기능의 경우는 이용자 종류와 권한을 정리할 필요가 있다. 예를 들면, 시스템 이용자의 개인 정보를 열람할 수 있는 사람과 그렇지 못한 사람의 권한을 나눠 메뉴로 전이(Transit)나 화면 표시를 제한하는 요건을 생각할 수 있다. 관리 기능이 정리된 후에 이용자의 종류와 권한을 정리한다.

■잊어서는 안되는 분석 기능

아래 대화를 보자.

PM : 시스템의 이용자수나 이용 상황을 경영진에게 보고할 필요가 있지요?

IT담당: 그렇지요. 보수 업무로서 데이터를 추출하여 집계할까요?

PM : 그래도 꽤 귀찮을 것 같아요.

컨설턴트: BI(Business Intelligence) 툴을 도입하는 것이 좋을지도 모르겠네요 .

신 서비스계 프로젝트의 경우 빠뜨려서는 안되는 것이 분석 기능이다. KGI(경영 목표 달성 지표)나 KPI(중요 업적 평가 지표) 취득이나 이용자 행동 등을 정량적으로 파악하기 위해 준비한다. 분석 기능은 어떻게 이용할 수 있을까? 대표적인 것이 액세스 해석이나 시스템 이용자의 행동 추적이다. 화면(Front End) 기능인 웹페이지나 스마트폰 애플리케이션의 화면 내에 특정 문자열(태그)를 집어넣어 툴을 사용해 이용자의 조작을 파악한다. 그 데이터를 BI 툴 등의 화면에서 참조한다. KGI나 KPI의 목표에 대한 실적을 확인하거나 시스템 이용자의 이탈을 유발하기 쉬운 부분을 발견하는 분석을 한다.

분석 업무/분석 기능 요건정의의 작업 내용은 다음과 같다.

-취득(Acquisition)할 수치의 정의(KGI/KPI)

-취득할 수치 정의(행동 지표)

-수치 취득(Acquisition)처의 정의와 계산

-화면(Front End) 기능 요건이나 서버(Back End) 기능 요건 전달

-필요한 분석 화면 정리

■취득할 수치 정의(KGI/KPI)

A사의 서비스처럼 청구(Billing)가 발생하는 경우 청구 이용자 수나 월 수익액, 이용자 1명 당 수익액 등이 KGI가 된다. KPI는 신청 페이지 액세스 수, 회원 신청율(conversion rate)등을 예상할 수 있다. 이와 같이 비즈니스 면에서 체크할 필요가 있는 지표는 어떤 것인지를 생각해 정리한다.

■취득할 수치 정의(행동 지표)

빵의 정기 배달 시스템 경우, 이용자가 신청 완료까지 원활하게 진행하는 것이 KPI나 KGI를 높이는 포인트가 된다. 신청 완료까지의 플로우 중에서 시스템 이용자의 이탈을 초래하고 있는 것이 어느 화면인가 등 이용자의 행동을 정량적으로 파악하는 요건이 필요하다. 마케팅 용어로 '퍼넬(Funnel)'이라 불리는 틀(FRAME)을 분석하거나 그 이외의 이용자 행동을 포착하기 위해 봐야 할 수치를 정의한다. 또, 어느 점포에서 어떤 빵이 가장 추천되어 출하되고 있는가, 지역별로는 어떤지? 등의 상품면의 수치도 보고 싶을 수 있다. 이렇게 시스템 전체의 성과를 보기 위해 어떤 수치가 필요한 지를 정의하는 것이 행동 지표다.

■수치 취득처 정의와 계산

예를 들면 신청 완료까지의 시스템 이용자 행동을 분석하고 싶은 경우, 어떤 화면의 어느 액션을 계측할지를 정의한다. 이것이 태그가 채워질 장소가 된다. 컨버젼(Conversion)율이나 로그인 율 등의 수치를 보고 싶은 경우는 분모와 분자, 각각의 수치의 출력 방법 등을 정의한다.

■화면(Front End) 기능 요건이나 백 엔드(Back End) 기능 요건으로 전달

어떤 화면의 어느 액션의 수치를 취하고 싶은지를 정리해 화면 기능 요건에 추가한다. 요건이 발생하는 것은 분석 업무이지만 그것을 구현하는 것은 화면 기능이기 때문이다. 마찬가지로 월 수익액을 내고 싶은 경우 그 금액을 계산하거나, 필요한 데이터를 BI 툴에 전달하는 배치 기능도 필요한다. 즉 백엔드 기능 요건에도 하고 싶은 것을 전달, 기능으로서 준비할 필요가 있다.

■필요한 분석 화면(Front End) 정리

경영자가 분석 화면을 본다면 과금 이용자 수, 월수익액, 액세스 수 등의 KGI나 KPI 수치는 1개의 화면으로 비주얼화 해 보고 싶어 질 것이다. 이른바 대시보드(Dash board)다. 한편 프로덕트 오너는 프로덕트(서비스) 개선에 주안점을 두고 있기 때문에 신청에 이르기까지의 사용자 행동, 신청 후의 상품의 매상 행위 등을 각각 개별적으로 보고 싶을지 모른다. 이와 같이 취득한 수치를 누구에게 어떤 화면에서 보여줄지를 정의해 분석 화면 목록으로 정리한다.

■분석 업무 및 기능 요건정의 진행시 주의점

마지막으로 주의점을 정리해 보자. 시스템 성과를 제대로 보기 위해서는 다양한 수치를 다양한 각도에서 분석할 필요가 있다고 생각하기 쉽다. 물론 이론적으로는 BI툴 등을 사용하면 복잡한 조건에서도 비교적 간단히 분석 화면을 만들 수 있다. 그러나 현실에서는 너무 많은 수치를 취득하면 불량을 일으킬 수 있다. 예를 들면, 어느 시스템에서 분석 화면 만으로도 100개 가까운 종류를 준비했다고 하자. 이것만 있으면 모든 화면을 보는 것은 불가능에 가깝다. 즉 모처럼 만들어도 많은 분석 화면이 거의 보이지 않는 상태가 된다. BI로 간단하게 만든다고 해도 분석 기능은 테스트가 힘들기 때문에 그만큼의 노력이 든다. 노력했는데도 별로 사용되지 않는다면 안타까운 일이다. 예산이나 인적 자원에 여유가 있으면 먼저 많은 분석 화면을 만들어 두는 것도 하나의 선택지다. 그러나 여유가 없으면 화면 기능의 태그 삽입이나 BI툴의 입력 파일 준비 등 '교육(Preparation)에만' 한정시켜 두는 것도 좋다. 우선은 날마다 열람하는 필요한 최소한의 분석 화면을 준비하는 것을 권하고 싶다.

*참고문헌

1. 기획입〮안에서 시스템 개발까지 실제로 사용하는 DX프로젝트의 교과서 (일경BP사, 2020년3월)

■ 필자 심기보는...

1976년부터 한전에서 SW개발자로 전산업무를 시작했다. 30여년간 정보화 사업 기획, 개발, 운영업무를 수행하면서 SI사업 등 발주관리 전문가로 일했다.

심기보 전 정보통신기술사협회장

우리나라 최초로 FP(기능점수)법에 의한 SW사업대가 기준연구 및 보급으로 SW사업 선진화에 기여했다. SEC 정책자문위원과 SW사업분쟁조정위원회위원, 정보통신기술사협회장, KAIST 전산학부 겸직교수, SW정책연구소 초빙연구원 등을 지냈다. 숭실대 대학원에서 'FP법을 이용한 다중회귀 분석적 SW사업대가 산정모델 연구'로 박사 학위를 받았다. 현재는 심기보기술사설계사무소를 설립해 SW설계‧견적‧감정 일을 하고 있다. 특히 SW사업 분쟁방지를 위한 SW사업 요건정의 및 기본설계 전문가로 활동하고 있다.

심기보 전 정보통신기술사협회장(pmodosa@naver.com)