"AI서비스가 그림의 떡 안되려면 계획이 충실해야"

AI프로젝트 구상 단계의 4가지 항목 중 이번회에서는 '서비스 요구정의' '사업 전략 및 계획 작성' '프로젝트 계획서 작성'에 대해 살펴본다. 먼저 필요한 시스템 기능이나 업무 흐름(Flow)을 명확히해 프로젝트 계획을 수립해야 한다.

계획을 제대로 세우면 관계자의 협력을 얻기 쉬워 성공적인 프로젝트를 기대할 수 있다. 서비스 요구정의 작업 목적은 서비스 내용을 구체화하는 것이다. 이전 회에서 A사는 '고객에게 최적의 빵을 조합해 정기적으로 자택에 배달한다'는 서비스안을 정한 바 있다. 그러나 아직 '어떤 상품을 제공할 것인가?' '어떤 기능을 제공할 것인가?' '어떤 업무가 필요한가?'까지는 구체화하지 않았다. 실제 서비스를 이용하는 상황(Scene)을 머리속에 그려가며 이들을 구체화해 다음 단계인 '프로젝트 계획서 작성'에서 실시하는 요건정의 범위를 명확히 하는 것이 서비스 요구정의 단계의 목표다. 여기 아웃풋이 다음 단계의 인풋이 된다.

·■서비스 요구정의

서비스 요구정의 전체 흐름을 정리해 보자. 여기서 '요구'란 서비스로 무엇을 제공 및 실현하고 싶은 지를 의미한다. 즉, 서비스에 요구되는 기능이나 업무다. 서비스 요구정의에서는 서비스 등장 인물과 이용 상황 및 관련 방법에 대한 흐름도를 작성, 구체화해 필요한 기능을 정리한 다음 서비스의 제공 메뉴와 상품을 결정한다. 이들은 ‘시스템 기능 요구정의’ 와 ‘업무 기능 요구정의’ 라고 한다.

먼저, 서비스에서 등장하는 인물과 각각의 서비스 이용 상황과 이용 방법을 찾아낸다. 등장 인물을 이용자(Actor), 이용하는 상황이나 방법을 유스케이스(Usecase)라고 한다. 서비스의 전체 구성도를 보면서 어떤 이용자가 등장할 지를 생각한 다음, 이용자에게 제공하는 서비스(유스케이스)를 작성한다.

이 단계서는 유스케이스를 완벽히 찾아내지 않아도 된다. 우선은 서비스를 이용하는 고객이나 서비스 제공자의 주된 행동(behavior)을 알아낸다.

■ 이용자(Actor)별로 흐름도 정리해야

유스케이스 분석에서는 각각의 이용자가 언제 무엇을 하는지를 흐름도로 정리한다. 스마트폰 등 화면 서비스의 경우 화면 이미지도 준비해 이용 상황과 이용 방법을 구체화한다. 이 작업을 통해 서비스의 내용을 세부적으로 정리한다. 예를 들어 고객의 '정기 도착 서비스에 신청한다'고 하는 상황을 흐름도로 작성해 보자. 심플한 흐름도를 그리기만 해도 검토가 필요한 포인트가 여러 개 보인다. 구체적으로는 '서비스 대응 지역' '플랜이나 가격' '신청 시 선택 가능한 항목' 등을 어떻게 할까 라는 것이다.

대응 지역이나 플랜, 가격, 신청 시의 선택 사항 등을 검토하는 작업은 상품 및 메뉴 검토 정도다. A사의 경우 빵이라는 상품을 월별 정액제(Subscription)로 제공하는 서비스를 만들려 하고 있다. 제공하는 상품이나 제공 방법을 먼저 정리하지 않으면 어떤 화면으로 해야 할 지 검토할 수 없다. 또, 빵을 추천하는 AI의 구조도 생각할 수 없다. 그러므로 먼저 상품이나 메뉴를 검토할 필요가 있다. 상품 및 메뉴는 이용자 개개의 과제와 그 해결 방법을 정리함으로써 구체화할 수 있다.

각 과제에서 검토 요소를 찾아 내 상품 및 메뉴로 검토한다. 최종적으로는 '메인의 빵을 선택한다' '크림 빵이나 반찬 빵은 추천' '몇 끼 분을 매월 배송할지를 결정할 수 있다'와 같이 상품이나 메뉴 요구의 골자가 정해진다

■ 이용자의 행동 흐름도 작성

정해진 상품 및 메뉴를 어떤 화면에서 제공할지, 또 이용자나 제공자가 무엇을 할지를 다음에 정리한다. 동시에 필요한 시스템 기능이나 데이터도 도출한다. 여기에서는 화면을 세밀하게 그릴 필요는 없다. 이용자의 주요 행동 이미지가 부각할 정도 화면만으로 충분하다. 다양한 브랜치(Branch)를 고려한 구체적인 화면 흐름도는 이후의 요건 정의 공정에서 작성한다.

화면을 그리는 것은 문자 보다 검토를 진행하기 쉽기 때문이다. 개발 항목 수를 파악할 때에도 유용하다.여기에서 작성한 화면 이미지는 시스템 개발 코스트를 산출할 때의 재료가 된다.

이용자의 행동(behavior) 흐름도만이 아니라 서비스 제공자의 업무 흐름도를 그려간다. [그림6]은 고객이 주문한 빵을 구워 발송 준비하는 업무 흐름도를 정리한 것이다. 제공자의 흐름도를 그림으로써 상품의 내용을 더욱 세부적으로 구체화할 수 있다. 필요한 관리 화면이나 업무, 서비스 제공에 필요한 설비나 비품 등도 보인다. 이러한 정보가 사업 계획을 세울 때 원가(코스트) 계산의 인풋이 된다. 다음으로 시스템에 요구되는 기능 및 데이터, 그 시스템을 사용할 때의 업무(작업)를 정리한다.

■ 시스템에 요구되는 기능이나 데이터 정리

[그림7]의 왼쪽은 A사 가 정리한 시스템 기능 목록이다. 이 작업의 토대가 되는 것은 유스케이스 분석에서 정리한 업무 흐름도다. 이것을 기본으로 시스템 기능이나 데이터 목록을 작성한다. 사업 계획의 코스트 계산이나 요건 정의의 작업 견적 인풋이 된다. 반대로 이 목록을 정리하지 않으면 사업 계획도 분명하지 못하게 돼 요건정의 작업계획도 실행성이 없어진다. 이는 대단히 중요한 프로세스다. 시스템 기능 만이 아니라 이 서비스를 운영할 때 필요한 업무도 목록화 한다[그림7 오른쪽]. 사업 계획을 세울 때 서비스 운영에 어느 정도의 작업 시간과 인력이 필요하게 될지를 견적 할 수 있는 재료가 된다.

기능이나 데이터 등의 목록을 정리한 다음 시스템 구성도를 그린다. 시스템 구성도는 요건 정의 이후의 계획을 세우거나 추진체제를 고려할 때, 또는 IT 부문이나 개발 회사에 서비스를 설명할 때 편리하다. AI 프로젝트를 관리하는 사람은 이 시스템 구성도를 항상 최신화해 지금 만들고자 하는 것을 조감(Bird’s-eye view)할 수 있도록 해 둬야 한다.

■ 사업 전략 및 계획 작성

상품이나 서비스의 시스템 기능, 운영 업무 내용 등을 바탕으로 어느 정도 고객을 확보할 수 있을지, 또 어느 정도 수익을 예상할 수 있을 지를 작성하는 것이 '사업 전략 및 계획 작성' 작업이다. 사업 전략 및 계획 작성 목적은 서비스 수익성을 검증하는 것이다.

AI서비스가 그림의 떡이 되지 않도록 경쟁사나 대체 서비스와 비교해 우수한 것이 무엇인지, 중기적인 경쟁력은 무엇인지 등의 전략이나 수익계획을 검토한다. 물론, 해보지 않으면 알 수 없을 것이다. 그러나 차근차근 조사를 해 나가면 동일한 서비스가 이미 있는지 알아 낼 수 있게 된다. 대체 수단이 있어 이대로 서비스를 개시하면 아무도 사용하지 않을 것이다 라는 상황을 피해야 한다. 고객을 확보했다고 해도 적자가 될 것이 확실한 서비스를 시작해서는 안될 것이다.

이 작업에서 수익성을 예측할 수 없는 경우, 서비스 내용 자체도 재검토하게 될 가능성이 있다. 필요하면 재검토를 해 어느 정도 수익을 예상할 수 있는 계획을 세우는 것이 이 작업의 목표다.

■ '3C' '4P' 기본 파악해야

사업 전략 및 계획 작성의 흐름을 정리한다.

서비스 우위성 검토나 경쟁사 비교 등으로 추정한 가격 및 판매 방법 등을 검토해 이를 바탕으로 코스트를 계산한다. 그리고 수익모델을 작성한다. 마지막으로 사업 전개 스토리를 정리해 판매 계획 및 코스트 계획을 세운다.

새로운 서비스나 상품을 생산하는 AI 프로젝트에서는 경영학에서 말하는 '3C'나 '4P'등의 마케팅 프레임워크를 이용해 판매 전략을 정리해 두면 좋다. 이 외에도 다양한 프레임워크가 있으므로 사용하기 쉬운 것을 선택하면 된다.

3C는 '고객(Customer)' '자사(Company)' '경쟁사(Competitor)'의 관계를 분석하는 것이다. 고객이라면 '아침, 자택에서 맛있는 빵을 먹고 싶지만, 베이커리에 갈 시간이 없다' 혹은 '우리회사는 전국에서 가장 점포수가 많고 커버 범위가 넓다'와 같이 규정한다.

경쟁이 있는 경우는 경쟁사가 제공하는 상품 내용이나 기능 등을 구체적으로 도출해 예상 고객에게 자사 서비스의 어디가 어필 포인트(강점)인지 정리할 필요가 있다. 기존의 상품이나 서비스가 있어 동일한 것을 만들거나 또는 동일한 판매 방법을 사용해도 고객은 선택해 주지 않는다.

또한, 경쟁과 대체는 구별해 생각한다. 경쟁은 동일한 니즈를 똑같은 방법으로 만족시키는 것, 대체는 동일한 니즈를 다른 방법으로 충족시키는 것이다. '아침, 자택에서 맛있는 빵을 먹는다'는 니즈(Needs)에 대한 경쟁은 농협의 냉동 빵이다. 이에 대해 '아침, 맛있는 빵을 먹는다'는 니즈를 자택 이외에서 충족시켜 주는 카페 안의 베이커리의 조식 세트는 대체 수단이다.

경영학에서 말하는 4P는 사업 계획을 세울 때 유용한 프레임워크이다. 상품(Product), 가격(Price), 판매 채널(Place), 프로모션(Promotion)을 검토한다. 이 중 가격은 특히 중요한 요소다. 코스트(상품의 원가)나 제공 가치, 경쟁 및 대체 제품 등을 토대로 고객이 납득할 수 있는 가격을 정할 필요가 있다. A사의 사례에서는 경쟁하는 농협의 냉동 빵은 1개 2000~3000원 카페 안 베이커리의 경우 세트로 4000원 정도다. 이 정도의 가격선이 1개의 기준이다.

판매 채널과 프로모션 수단은 이후 이익률 계산이나 판매 및 코스트 계획에서 필요한 정보가 된다. 예를 들면 판매 채널로서 네트워크만이 아니라 점포 판매를 하는 경우, 점포 운영 코스트를 고려하지 않으면 안 된다. 프로모션 수단으로 SNS 광고도 실시한다면 그 광고 비용을 코스트로 감안할 필요가 있다.

■적자 서비스 내지 않게 해야

새로운 서비스를 준비해 운영할 때 어느 정도 코스트가 들지를 계산한다. 코스트 산출과 계산이 불충분하면 정작 서비스를 개시했을 때 구조적인 적자가 될 지도 모른다.

[그림9]와 같이 코스트의 종류를 정리해 각각의 항목을 견적 한다. 이 중 시스템 개발 코스트 견적은 코스트 전문가에게 의뢰한다. 이때, 서비스 요구정의 프로세스에서 작성한 시스템 기능 목록이나 시스템 구성도가 중요하다. 시스템 기능 목록만이 아니라 시스템 구성도가 있으면 견적의 정확도는 훨씬 높아진다.

코스트 전문가에게 자사에서 서비스하고자 하는 구체적인 기능(EI, EO, EQ, ILF, EIF) 목록을 파악할 수 있는 시스템 구성도를 제공함으로써 코스트의 정확도를 높일 수 있다. EI는 등록, 수정, 삭제 등 3가지로 이뤄 진다. 업무 운용비용은 이 서비스를 운영할 때 발생하는 각각의 업무에 대해 어느 정도 시간이 걸릴지, 또 그 시간을 인건비로 환산하면 얼마가 될 지의 관점에서 계산한다.

어떤 코스트가 고정비인지, 주문하는 수량이나 회원(고객) 수에 따라 변하는 변동비인지를 명확히 해 둬야 한다. 이는 수익 모델 계산에 필요하다.

■ 마일스톤이나 목표를 정해 사업 계획을 정리해야

시간대별 이용자 수나 매출, 초기 비용 회수기간 등을 구체적인 수치로 정리한다. 하지만, 아무것도 없이 갑자기 사업 계획은 세워지지 않는다. 우선은 최초의 디딤돌로서 상품이나 서비스를 세상에 전개할 스토리나 마일스톤, 목표치를 정한다. 만약 '3년내 초기 비용을 회수한다'는 마일스톤이나 목표를 세웠다고 한다면 가격이나 코스트는 이미 구체화되어 있으므로 3년안에 회수하려면 매출을 얼마나 해야 할지를 계산할 수 있다.

이를 위해서는 1~3년 안에 어느 정도 이용자 수가 필요한지, 그 결과 코스트는 어느 정도로 해야 할 지와 같은 계획을 세워간다. 이 시점에서 기대하는 수익성이 예상되는 경우는 문제없지만, 명확히 수익성이 낮을 가능성도 있다. 이런 경우, 코스트에서 삭감해야 할 곳은 없는지 매출을 줄여야 할지를 재검토한다. 더 높은 가격을 책정할 수 없을지 등 서비스의 내용 그 자체를 재검토할 필요가 생길 경우도 있다. 사업 계획이 정리되면 개발 단계별 예산 배분도 정한다. A사의 빵 정기 도착 서비스의 경우 3개년의 계획으로 수립됐다.

단계1에서는 기본적인 기능이나 AI의 기본형, 기본적인 관리 화면을 개발한다. 단계2에서는 포인트 프로그램이나 마케팅 목적의 푸시형 안내 기능 개발이 들어 있다. 여기까지 정하면 다음 공정인 요건 정의 대상도 결정한다. 즉, 요건 정의 작업 계획을 세울 수 있다. 반대로 여기에서 정하지 않으면 모든 기능을 대상으로 하거나, 요건 정의가 시작될 때부터 단계 배분을 검토하게 되므로 매우 비효율적이다.

■ 프로젝트 계획서 작성

구상 단계의 마지막 작업은 요건정의다. 요건 정의는 구상 단계와 달리 많은 관계자를 끌어들여서는 안된다. '무엇을 누가 언제까지 할까?'에 대한 설명 자료가 없으면 협력을 타진하기 어려워진다. 타진되는 측도 어느 정도의 인력이 필요한지 알 수 없으면 가부를 판단할 수 없다. 그래서 요건 정의 작업 계획도 프로젝트 계획서를 확실히 만들어야 한다.

[표1]과 같은 내용을 프로젝트 계획서로서 정리한다. 규모가 작은 서비스나 시스템의 경우는 몇 사람 정도가 요건정의를 진행하므로 그다지 신경 쓰지 않아도 되지만, 규모가 커지면 팀을 짜 작업을 분담할 필요가 있다. 어느 팀이 담당할지 애매한 항목이 있거나 항목이 누락되기도 하는 것을 방지하는 데 유효한 것이 시스템 구성도다.

[그림11]와 같이 어느 팀이 어디를 담당(분담)할지를 정한다. 작업 누락을 방지하면서 각 팀에게 자신들의 담당을 알기 쉽게 인식시킬 수 있다. 체제도 안의 멤버명은 이 단계에서는 공란이라도 관계없다. 인력 준비나 관계 회사 준비가 끝나지 않으면 채울 수 없기 때문이다.

■ 관계자 협력을 얻는게 중요

요건 정의를 원활히 시작하려면 인력 확보가 중요하다. 요건 정의에서는 UX(User Experience)나 와이어프레임(화면 레이아웃)을 작성하는 디자이너, 기계 학습 엔지니어, 데이터 사이언티스트, 업무 담당자, 관련 시스템 담당자 등 해당 관계자가 프로젝트에 참여하는 것이 중요하다. 이 사람들의 협력을 얻으면 성공적인 요건 정의를 할 수 있다.

프로젝트 계획서를 그대로 작성할 수 있는 시점에서 관계자의 협력을 타진한다. 제대로 된 프로젝트 계획서가 있으면 자신의 역할(역량)이 왜 필요한지, 어느 정도 부하가 걸릴지 알기 쉬우므로 협력을 얻기 쉬워진다. 반대로 계획서가 없으면 '무엇을 할지'가 애매하게 된다.

디자인 회사, AI 개발회사, 스마트폰 애플리케이션 개발 회사 등에 요건 정의를 위탁하는 경우는 이들 회사에 RFP(제안요청서)를 보내 견적을 받고 요건에 맞는 개발회사를 선정한다. RFP는 서비스 기획서와 프로젝트 계획서만 있으면 제안요청 사항을 정리해 작성할 수 있으므로 계획서를 만들어 두는 것이 중요하다. 물론, 사내 관계 부서나 관련 시스템과 협력도 타진한다.

이때, 프로젝트 오너가 사장이나 임원급이면 부서간 조정이 비교적 무난하지만, 임원 아래 직급에서 프로젝트 오너를 맡게 되면 상급자인 임원 결재 과정을 거쳐야 하고 타 부서와의 협력에도 많은 노력을 필요로 한다. 다양한 사람에게 몇 번씩 설명하는 등 작업 코스트가 들 뿐 아니라 시간도 늦어질 가능성이 있다. 이러한 작업 코스트를 줄일 수 있으려면 사장이나 임원이 프로젝트 오너가 되는 것이 매우 중요하다.

*참고문헌

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

2. DX프로젝트 성공의 급소 (일경시스템즈, 20120.1월호 연재기사)

■ 필자 심기보는...