"AI프로젝트 성패는 기획 내용이 결정"

AI 프로젝트 구상은 기간계(Backbone) 시스템 개발 프로젝트와 그 내용이 다르다. 어떻게 만들 것인지를 생각하기 전에 무엇을 만들 것인지를 결정해야 하기 때문이다. 이번 회에서는 구상 단계에서 결정해야 할 4가지 항목과 이 단계의 근간이 되는 서비스 기획의 추진방법을 살펴본다.

먼저 AI 프로젝트의 최초 공정인 구상단계에 대해 알아본다. AI 프로젝트의 구상 단계는 기간계 시스템 개발 프로젝트와 작업 내용이 다르다.

기간계 시스템 개발 프로젝트는 프로젝트 종류에 따라 해결해야 할 과제와 해결 방침이 어느 정도 결정된다. 예를 들면, 프로젝트 종류로 패키지 도입이나 시스템 이행, 시스템 통폐합 등이 있다. 이러한 경우 해결해야 할 과제는 코스트 삭감이나 EOS(End of Support)에 대한 대응 등이다. 해결책도 SAP, 오라클EBS 등의 패키지를 도입하거나 개발 언어를 코볼(COBOL)에서 자바(Java)로 바꾸는 등 대체적으로 예상이 가능하다. 어느 정도 무엇을 만들지가 명확하기 때문에 구상단계에서는 제품 선정이나 효과, 코스트 견적 등 '어떻게 할까(How)'에 무게를 둔다.

그러나 AI 프로젝트는 다르다. 무엇을 만들 것인가(What)를 정의하는 것부터 시작한다. 예를 들면, B2C(소비자용) 서비스 작업의 경우 누구(어떠한 소비자)에게 왜 어떠한 서비스를 제공할지를 먼저 정의한다.

기간계 시스템처럼 기존 시스템이나 기존 업무가 있는 게 아니라 필요한 시스템을 제로베이스에서 결정해야 하는 것이다.

구상 단계는 본래 누구를 위한 서비스인지 애매한 경우도 있다. 특히 블록체인이나 얼굴인식 등의 기술을 이미 가지고 있는 회사의 경우 그 기술로 무엇을 하려고 하는 프로덕트-아웃(Product-out)적인 발상이 되기 쉽다. 이렇게 되면 AI 프로젝트는 잘 진행되지 않는다. 누구에게 제공할지가 확실하지 못한 서비스는 시장(고객) 니즈에 부합하지 못한 서비스가 되기 쉽다. 적지 않은 투자를 했지만 사용하고 싶지 않는 서비스가 되고 만다. 따라서 시스템을 개발하기 전, 구상 단계의 기획 내용이 서비스 성패에 크게 영향을 미친다.

시스템 개발이 진행돼 버리면 비용이나 스케줄 제약으로 기획단계로 다시 돌아가기 어려운 것이 현실이다. 따라서 AI 프로젝트에서 구상 단계는 매우 중요한 공정이다. 그럼 구상 단계에서 구체적으로 어떠한 일을 해야 할지 알아보자. 구상 단계는 요건 정의 직전까지, 즉 요구 정의를 포함한다.

■ 구상 단계에서 결정해야 할 4개 항목

AI 프로젝트 구상 단계에서 정해야 할 주요 항목은 ①서비스 기획 ②서비스 요구 정의 ③사업 전략 및계획 작성 ④ 프로젝트 계획서 작성 등이다.

여기에서 거론한 4 종류의 작업은 순서에 따라 진행하는 것이 좋다. 왜냐하면 각 작업 간에는 [그림2]와 같은 관계가 있기 때문이다. 이들 4종류 작업을 하나씩 알아보자.

▲서비스 기획: 먼저, 누구의 어떤 과제를 어떻게 해결할지를 결정한다. ‘누구의 어떤 과제’란 프로젝트 대상이 일반 소비자(toC)일 경우에는 소비자가 어떤 속성으로 어떤 고민이나 생각을 가지고 있는 사람인가를 예측한다는 뜻이다. 프로젝트 대상이 기업(toB)인 경우라면 어떤 업종에서 어떤 업무 과제를 안고 있는 기업을 대상으로 할지 결정해야 한다.

‘누구의 어떤 과제’가 결정되면 그 정해진 과제를 해결할 아이디어나 해결방법을 결정한다. 그 아이디어와 해결방법 정리가 서비스가 된다. 이를 실현하기 위해 어떤 기술이 필요한지도 검토한다. 이상의 작업을 마치면 서비스 요구정의에 들어간다. 서비스 기획이 정해져 있지 않으면 서비스 요구정의를 진행할 수 없다. 예를 들면 기업용 서비스를 개발하는 경우, 대상 업종이나 해결해야 할 업무 과제가 정해져 있지 않으면 어떤 기능을 준비해야 할 지를 결정할 수 없다. 애초부터 니즈에 부합하지 않은 서비스가 될 가능성이 있다.

아울러 서비스 기획 성과는 사업 전략 및 계획 작성에도 필요하다. 누구에게 무엇을 제공할지 정해져 있지 않으면 경쟁사가 누구인지도 알 수 없고 경쟁에 대처할 전략도 짤 수 없다. 예컨대 경쟁사를 이길수 있는 가격은 어떻게 설정할 것인가? 상품의 우위성을 어떻게 확보해야 할 것인가? 등을 결정할 수 없다.

▲서비스 요구 정의(시스템 요구 및 업무요구 정의): 서비스기획에서 정한 과제의 해결안(서비스안이나 시책안)을 받아 이를 구체화하는 단계다. 누가 어느 상황(Scene)에서 어떤 시스템 기능을 사용하는가? 어떤 데이터가 발생하는가? 어떤 업무에서 필요한지 등을 검토한다.

여기까지 끝나면 사업 전략 및 계획 작성에 들어간다. 기능의 이미지를 정리함으로써 경쟁사의 서비스와 비교하기 쉬워 메뉴나 가격도 정할 수 있다. 필요한 시스템 기능이나 구성, 업무 기능이 명확해지기 때문에 코스트 견적도 할 수 있다. 또, 판매 가격과 코스트를 바탕으로 사업 계획을 짤 수 있다.

▲사업 전략 및 계획 작성: 서비스 요구정의 내용을 받아 사업 전략을 짠다. 어필해야 할 우위성, 가격, 판매 방법 등을 결정한다. 또 몇 년 만에 손익분기점에 도달할 수 있을지 결정한다. 이 작업이 끝나면 프로젝트 계획서(요건정의 등) 작성에 들어간다. 사업 계획상 언제까지 무엇을 만들지를 정하지 않으면 요건 정의 작업 범위가 정해지지 않는다. 요원 계획도 세우지 않고 요건정의 작업에 들어갈 수 없다.

▲프로젝트 계획서 작성: 서비스 개발 프로젝트 요건 정의와 작업계획을 합친 '프로젝트 계획서'를 작성한다. 요건 정의 작업 대상이 되는 기능이나 요건 정의 작업의 성과물, 추진체제, 스케줄 등의 계획서를 작성한다. 그리고 예산화나 사내 인력 준비, 개발 회사 준비 등 프로젝트를 셋업 한다.

이렇게 보면 이들 4개 항목 검토가 마치 워터폴처럼 진행되는 인상을 받을지 모른다. 그러나 실제는 그렇지 않다. 예를 들면, 일단 메뉴나 가격을 결정했지만 코스트 회수에 시간이 너무 많이 걸린다는 것을 알게 돼 재검토에 들어가는 경우가 많댜. 구상 단계에서 이러한 재검토가 생기는 것이 당연하다고 생각해야 한다. 기존 상품 및 서비스 개량이나 개선이 아니므로 검토가 진행됨에 따라 구체화 돼 보이는 부분이 많아 지기 때문이다. 어느 정도 왔다 갔다 반복할 수 있는 여유 있는 스케줄을 짜 두어야 한다

■ 서비스 기획에서 유저 과제를 예상

앞에서 설명한 구상 단계의 4개 항목 중 구상의 근본을 이루는 서비스 기획의 구체적인 작업 프로세스는 다음과 같다. 먼저 기본적으로 대상 유저와 과제를 정의한다.

[그림3]

누구의 어떠한 과제를 해결하기 위한 서비스인지를 결정하는 것이다. 또, 그 과제의 해결책을 생각한다. 이 해결책이 서비스안이 된다. 하지만, 프로젝트에 따라 그 전에 보유한 기술이나 제품을 정리할 필요가 있다. 예를 들면 기업이 이미 보유하고 있는 기술이나 제품을 사용하는 것을 전제로 할 수 있다. 이 때, 서비스로 해결해야 할 과제의 종류는 이들 기술이나 제품에 관계되는 과제로 좁힐 수 있다.

예를 들어 '얼굴인식 AI를 가진 회사가 그 기술을 사용해 서비스를 만드는' 경우에는 얼굴인식에 관련된 유저 행동이나 그 과제에 한정해 검토할 수 있다. 구체적으로는 점포 내의 카메라에 비친 고객을 인식함으로써 해결할 수 있는 과제를 생각할 수 있다. 자사의 보유 기술이 없는 경우에는 이 작업 프로세스는 생략하고 대상 유저나 과제 정의부터 시작한다.

■ 양질의 입력자료를 모아야

대상이 될 서비스 이용자나 과제는 어떻게 정할 것인가? 가장 먼저 해야 할 일은 입력(인풋)이 될 정보를 수집하는 것이다. AI 프로젝트 담당자가 평소부터 느끼고 있는 생활이나 비즈니스 과제가 힌트가 된다. 사내 전문가에게 얻은 정보를 입력하는 경우도 있다.

B2C(소비자용) 서비스를 개발하는 경우 사내에서 입력자료를 모을 수 없을 때도 있다. 이 때는 가설 발견을 위한 조사를 실시해도 좋다. 관찰로 사람들 행동 스타일을 파악하는 '에스노그라피(Ethnography)' 조사가 대표적이다. B2B(기업용)의 경우 사내의 고객 창구 부서나 고객 기업에서 듣는(Hearing) 방법도 있다. 인풋을 모으는 작업은 매우 중요하다.

■ 대상의 서비스 이용자와 과제를 정의해야

입력자료(인풋)를 얻은 다음에는 대상 서비스 이용자와 과제를 정의한다. B2C의 서비스에서는 이용자의 성별이나 연령, 이용하고 있는 상품, 어떤 상황에서 어떤 부족한 점이나 니즈를 가지고 있는지를 정리한다. 여기에서 가상의 기업 프로젝트를 설정, 대상이 되는 서비스 이용자와 과제를 생각해 보자. 베이커리 체인을 전국적으로 전개하는 A사는 B2C의 신규 사업을 시작하려 한다.

A사의 프로젝트 멤버는 우선 [그림4]의 A안과 같이 대상 유저와 과제를 정의했다. 대상 유저는 빵을 좋아해서 아침 식사로 맛있게 먹고 싶지만 평소 베이커리에 들르지 못하는 도시의 비즈니스 맨을 타깃으로 하고 있다. A안 내용을 사내에서 논의한 결과 신규로 B안도 채택됐다. A안은 점포에 오지 않은 이용자가 타깃이므로 배송을 전제로 한 서비스가 된다고 예상할 수 있다. 한편, B안은 점포에 오는 이용자가 타겟이므로 점포 내에서 제공하는 서비스로 하는 것이 자연스럽다.

이 두 과제 모두를 해결하려면 서로 다른 서비스 두 개를 준비할 필요가 있다. 구상 단계에서의 작업도 두 배가 된다. 인력이나 예산이 충분이 있는 경우에는 두 개 서비스를 개발할 수 있다. 하지만 AI 프로젝트는 기간계 시스템 개발 프로젝트 보다 검토해야 할 요소가 많기 때문에 여기저기 손을 대면 어정쩡한 검토로 실패할 가능성이 높다.

■ 대상 이용자의 과제 평가

서비스 이용자와 과제를 정의해도 그 과제를 담당자가 예상할 수 있는 경우는 드물다. 이용자와 과제를 정의할 때 가설 발견 리서치나 고객 히어링 등을 인풋하면 사실에 근거한 과제 설정이 가능하지만, 담당자나 전문가의 히어링만을 인풋하면 '분명 이런 일은 곤란할 것' 이라고 생각, 실제로는 존재할 수 없는 과제를 설정할 가능성이 있다.

이를 방지하기 위해 양적, 질적 평가를 실시한다. 우선 양적 평가를 보자. 이용자 수를 파악하기 어려운 경우는 인터넷 설문조사나 자사 고객 앙케이트 등을 실시해 어느 정도 이용자가 이 과제의 필요성을 느끼고 있는지를 조사한다. 인터넷을 사용해 광범위하게 조사해도 좋고, 자사의 고객에 대해서만 조사해도 좋을 것이다. 앙케이트 결과를 보면 어느 정도 이용자 수가 예측되는 지를 검증할 수 있다.

A사의 경우 '빵이 좋지만 평소 빵집에 가깝지 않은 도시의 비즈니스맨'이 몇 명 정도 인지를 조사한다. 이용자 수는 서비스 아이디어가 복수인 경우 어디를 우선해야 할지의 판단 기준이기도 한다. 다음은 질적 평가다. 설정한 과제가 적절한지 여부를 조사하거나 과제 내용을 보다 구체화한다. 조사전문기관에 의뢰하는 등 예상한 타켓에 적합한 사람을 실제 모아 인터뷰한다.

A사 예는 출근 시간이나 퇴근 시간, 식사 방법이라고 하는 이용자의 실제 생활에 대한 고민과 빵에 대한 생각이나 기대 등의 살아 있는 목소리를 들으면 된다. 이렇게해 가설을 구체화하면 해결안을 결정하기 쉽다.

■ 서비스안 정의

'서비스안'이란 어떠한 것인지를 정리하기 위해 (표1)에서 보여주고 있는 2개의 사례를 다시 보자. (표1)의 부분이 과제 해결(안)인 동시에 서비스(안)이 된다. 과제를 어떻게 해결할지 아이디어를 내 보자. 프로젝트 멤버끼리 서로 의견을 내면서 다양한 방법을 생각한다. A사는 대상 유저 과제를 3개로 분류, 각각에 대해 다음과 같은 아이디어를 도출했다.

과제① : 빵집이 영업 중인 시간대에 귀가할 수 없다(아이디어1 : 한번 신청하면 정기적으로 도착할 수 있다, 아이디어2: 웹 사이트에서 매번 주문할 수 있다).

과제② : 미리 사서 냉동할 시간도 없다(아이디어3 : 냉동한 상태로 자택에 배송 시킨다).

과제③ : 건강이나 칼로리도 배려하고 싶다(아이디어4 : 빵 종류 선택을 개인화(personalize)해 제안하는 구조를 제공한다).

이렇게 열거해 보면 아이디어1과 아이디어2에서는 필요한 구조가 다르다. 아이디어1은 서브스크립션(Subscription) 구조이고, 아이디어2는 EC(전자상거래) 구조다. 양쪽 모두를 실현하는 방법도 있지만, 인적 자원이나 예산 면에서 곤란하다. 그러므로 몇 개 아이디어를 정리해 서비스(안)의 패턴을 만든다.

A사는 크게 2개의 서비스(안)를 준비했다. 하나는, A사에서 추천한 빵을 조합해 정기적으로 배송하는 서비스 안이다. 유저 수고는 적은 반면 선택의 자유도도 없다. 또 다른 하나는 유저가 좋아하는 타이밍에서 빵을 주문할 수 있는 서비스 안이다. 이 때 빵의 조합 방법을 A사가 추천하되 최종적으로는 유저가 구입하는 빵을 선택한다. 이러한 서비스안은 문자 정보만으로는 이미지가 부각되기 어려워 공통 인식이나 이해를 얻지 못할 우려가 있다. 그림이나 이미지를 작성하면 사내에서의 논의가 쉬워진다

■ 서비스안 검토 및 선정

서비스안이 정해지면 서비스를 구체화해 간다. 서비스 상품 내용이나 정의, 실제 유저 이용 흐름(Flow)을 구체화해 나가면서 시스템 기능이나 필요한 데이터, 발생하는 업무 등을 정리한다. 서비스 안을 좁혀 두지 않으면 각각의 서비스 안에 대해 시스템 요구 및 업무 정리 작업이 발생, 상당한 인력(Man-Month)이 필요하기 때문이다.

서비스 안을 좁힐 때의 평가 기준은 '예상효과(과제의 해결 정도)' '코스트(초기 코스트, 운영 코스트)'

'실현 난이도' 등이 있다. 이 평가 기준에 근거해 상기 사례의 각 서비스안을 평가해 보려한다

이용자기 바쁘다는 점을 고려하면 2개의 서비스(안) 가운데 ①의 방법이 효과가 있을 것이다. 그러나 이용자의 수고를 없애기 위해서는 빵을 선택할 수 없는 구조이기 때문에, 이용자에게서 불만이 나올 가능성이 있다. ②는 빵을 선택할 수 있지만 주문하는 수고를 불만으로 느낄 가능성이 있다.

코스트는 업무가 복잡해지는 ②쪽이 높을 것이다. 한편, 실현 난이도는 ①편이 힘들다. 냉동 빵의 정기적인 배달이라는 구조 자체가 없기 때문에 그 구조를 구축하는 데 품이 많이 들고, 이용자가 받아들이기 어려울 수도 있다.

이런 점에서 볼 때 A사의 경우 ①안과 ②안 모두 우열을 가리기 어렵다. 또, 이렇게 서비스 안을 생각하고 있는 시점에서는 확실한 예측을 할 수 없다. 이용자의 과제 해결 효과가 높다고 생각해 비용을 들였지만 실제 그 효과는 얻을 수 없을 지도 모른다.

결국, 경영상 판단으로 ①, ②중 어느 한 쪽을 선택하게 되는데, AI 프로젝트에는 임원이나 대표 등 경영층이 적극적으로 관여해야 한다. A사는 난이도는 높되 가장 과제를 해결할 수 있을 것 같은 서비스(안)①을 선택했다.

<참고문헌>

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

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

■필자 심기보는...