AI 프로젝트를 진행할 때 중요한 공정이 개념 실증이라 불리는 'PoC(Proof of Concept)'다. 개발하려는 시스템의 컨셉이 정말 실현 가능한지 검증하는 작업이다. AI 프로젝트는 검증된 기술이 아니라 새로운 기술을 사용한다. 이 때문에 '생각한 대로 결과가 나오지 않는다'거나 '데이터가 예상한 대로 모이지 않는다' 같은 리스크가 따른다. 이 리스크를 고려하지 않고 프로젝트 스케줄을 짜면 기술 문제를 해소할 수 없어 프로젝트 전체가 지연될 우려가 있다.
■ PoC는 언제?
PoC는 언제하면 좋을까? 요건정의 전에 실시할 지, 혹은 요건정의 후에 실시할지는 개발하는 서비스 규모에 따라 다르다. AI가 서비스 핵심 기능이고,그 이외 기능이 적은 경우, 즉 AI 이외의 시스템 개발규모가 적으면 요건정의를 한 후 PoC를 해도 문제가 없다. AI 기술 리스크가 그 밖의 시스템 개발에 미치는 영향이 적기 때문이다. 또 요건정의를 한 후에는 요구가 구체화되므로 PoC로 검증해야 할 내용이 보다 명확해지기 때문이다.
A사의 예처럼 화면이나 결제 구조, 관리 화면 등 많은 주변 기능이 있으면 서비스 요건정의 전에 PoC를 해야 한다. 만약 PoC를 요건정의 후에 했는데 기술 리스크가 해소되지 않는 일이 발생하면 기획부터 다시 짜야 한다. 요건정의 작업이 허사가 될 우려가 있기 때문이다. 단, 기술 리스크가 해소되지 않는다 해도 대체 안이 있는 경우에는 요건정의 후에 PoC를 실시해도 괜찮을 수 있다. 프로젝트 내용에 따라 다르기 때문에 기술 리스크가 요건정의에 미치는 영향도를 고려하면서 전체 개발 프로세스 중 PoC를 어느 시점에서 실시할지 결정하면 된다.
■ PoC 단계서 무엇을 실시할지 결정해야
A사를 예를 들어 PoC단계에서 구체적으로 무엇을 할 지 알아본다. 이 프로젝트에서 PM 등 PoC에 관여하는 3인이 등장한다.
PM:이번 프로젝트 PM으로 경영 기획실 부장으로 마케팅부에서 실적을 쌓아왔다. 고객을 잘 알고 있어 PM으로 발탁됐지만 IT에는 그다지 정통하지 않다.
IT담당:AI 시스템 개발을 담당하고 있으며, 정보시스템부 소속이다. 기간계 시스템 개발에는 익숙하지만 AI 시스템 개발은 처음이다.
컨설턴트:AI 전문 컨설팅 회사의 디지털 컨설팅 사원이며 A사에 상주하며 'AI 프로젝트 PM 보좌'로 이번 프로젝트를 지원하고 있다. AI 관련 프로젝트 경험이 풍부하다.
실제로 시스템을 개발해 예상대로 동작하는지를 검증하는 것이 PoC이다. 하지만 어디까지 만들 것인가하는 고민이 생긴다.
PM: 그동안 세미나에서 'AI를 도입했는데 예상한대로 결과가 나오지 않았다'는 실패담을 들었다. 우리 프로젝트에서도 AI를 도입하려고 하는데 이용자가 충분히 만족할 수 있을까?
IT담당: 그건 해보지 않으면 뭐라고 말할 수 없겠지요.
PM:그래도 상당한 돈을 들여 시스템을 구축한 후에 '제대로 잘 안 되었습니다'라고 사장님께 설명할 순 없어요.
컨설턴트:그렇지요. 도입한 AI시스템의 정확도가 낮으면 시스템의 근간이 흔들려요. 과거의 POS 데이터로 현실적으로 사용 가능한 AI를 개발할 수 있을지 여부'를 PoC로 검증해보는 편이 좋다고 생각합니다.
이처럼 PoC에서 실시할 내용을 결정하려면 먼저 어디에 리스크가 있는지를 특정할 필요가 있다. 리스크 특정은 그 분야의 노하우나 경험이 필요하다. 자사 지식에만 의존하지 말고 이용하고자 하는 기술 분야에 능통한 사람의 협력을 얻으면 좋다. 아침식사용 빵 추천 시스템에서는 기술적 난이도가 가장 높은 것은 역시 AI 부분이라고 생각할 수 있다. POS 데이터 등을 바탕으로 두 종류의 빵 중 고객이 좋아하는 빵이 무엇인지를 알아 맞히는 AI를 구축했더니 정확도가 50% 였다고 하자. 이것은 반 밖에 맞추지 못한다는 것을 의미하므로 동전 던지기와 크게 다르지 않다. 일부러 AI를 만들 필요가 없다.
■ PoC 계획서
결과가 어떻게 나오면 좋다라고 할까? 하는 목적과 목표치를 정하는게 좋다. PoC를 실시할 때 발생하는 작업이나 역할 분담, 스케줄 등을 정리한 실시 계획을 작성하는데, PoC 계획에서는 어떤 결과가 나오면 '좋다'고 할 목표치를 정의하는 것이 중요하다. 앞에서는 PoC 목적이나 검증 범위를 결정했다. 이어 해야 할 일이 무엇인가를 알아본다.
PM:적어도 POC 데이터를 관리하고 있는 마케팅부에 데이터 제공을 요청해야 하겠네. 마케팅부에 아는 사람도 많으니까 바로 부탁해 보지요.
컨설턴트:아, 조금 기다려 주세요. 요청하기 전에 PoC 실시 계획서를 만들어 작업이나 스케줄을 구체화하는 것이 좋다고 생각합니다.
IT담당:PoC 실시 계획서? 어떤 것을 적나요?
컨설턴트:PoC로 무엇을 하고 싶은가, POS 데이터를 언제까지 원하는가, 필요한 것은 어느 범위의 데이터인가 등을 정하는 겁니다.
PoC 목적이나 대략적인 범위를 정리한 후에는 컨설턴트 말처럼 PoC 실시계획을 세운다. PoC에도 데이터 제공 부서나 개발회사 등 적지 않은 사람들이 관여한다. PoC 실시 준비작업에도 여러가지 항목이 있기 때문에 발생하는 작업, 역할분담, 스케줄 등을 정한다. 무엇을 검토할까, 검토해 어떤 결과가 나오면 좋다고 판단할 것인가 등의 목표를 정한다. PoC 계획서 구성과 기재해야 할 내용의 예를 들어 보면 [그림2]와 같다.
■ PoC 목적
처음에 PoC 목적을 기재한다. 예를 들면 다음과 같이 검토 내용이나 목표치 등을 명확히 한다.
-과거 1년치 POS 데이터를 사용해 빵 추천 AI가 80% 정확도로 추천 데이터가 나오는지 검증한다
-과거 1년치 POS 데이터 연계와 빵 추천 AI기반으로 데이터 추출 처리를 1시간 이내에 할 수 있는지를 검증한다
-이러한 목표를 정의해 두지 않으면 PoC 결과를 어떻게 판단하면 좋을지 알 수 없다. 예를 들면 80%의 정확도가 나오면 되는지, 90%가 아니면 안 되는지를 정한다.
-추천은 일반적으로 교사 없는 학습의 부류가 된다고 생각할 수 있다. 이 경우, 교사 있는 학습과 달리 정답 데이터가 없기 때문에 정확도를 어떻게 측정할지가 문제가 된다. 빵 추천을 예로 들면 구입자 중 샘플로 100명을 선정해 그들의 구입 이력과 AI 추천 결과를 사람이 비교, 추천이 그럴듯한 지 여부를 판단한다는 검증 방법이 된다고 예상할 수 있다.
-정확도 수치는 80명 추천이 그럴듯하면 80%, 50명 정도가 그럴듯하면 50%가 된다. 이 '그럴듯함'의 정의를 어느 정도 기계적, 수치적으로 할 수 있으면 사람이 아니어도 시스템으로 정확도를 산출할 수 있다.
제공하는 서비스에 따라 이 정확도에 대한 요구 눈 높이는 다르다. 높은 정확도가 요구되는 대표적인 분야가 병원이다. 병의 진단에 AI를 사용하는 경우 상당히 높은 정확도가 아니면 오진으로 이어질 우려가 있다. 목표를 정할 때는 기계 학습 엔지니어나 데이터사이언티스트 등 전문가로부터 기대 가능한 정확도에 대한 의견을 듣는 것이 좋다. 또, 목표 달성 여부에 따른 그 후 작업을 정해두는 것이 좋다. 예를 들면 다음과 같은 기준과 그 후의 작업을 생각할 수 있다.
-80%를 달성하면 다음 스텝으로 간다(본격 개발을 위한 예산 조정 등)
-70~80%의 경우, 튜닝 여지 유무에 따라 다음 스텝으로 갈지를 판단한다
-70% 미만인 경우에는 2회까지 PoC를 반복한다. 그래도 달성하지 못하는 경우에는 개발을 단념한다.
이런 내용을 경영진에게 설명해 양해를 얻어 두면 PoC 후 작업을 바로 개시할 수 있다. 그렇지 않으면 유저가 불명확해 PoC 성패를 판단할 수 없다. 설령 좋은 결과였다고 해도 PoC 후 작업에 들어가기 위한 여러가지 설명이나 결재에 시간이 걸린다.
■PoC 범위(Scope)
서비스 전체에서 어느 부분을 PoC로 검증할지를 나타낸다. 누구든 범위를 정확히 이해할 수 있도록 그림 등으로 표시하면 좋다
■실시 내용 과 시스템 및 환경
PoC에서 구체적으로 어떤 검증을 할지를 정한다. 예를 들면, n년치 POS 데이터를 바탕으로 추천 AI의 학습 모델을 구축, 그 정확도를 검증하는 것이다. 여기를 제대로 해 두지 않으면 필요한 환경이나 작업이 명확해지지 않기 때문에 제대로 구체화해야 한다.
시스템 및 환경에서는 PoC를 실행하는 시스템 구성도를 작성한다. 예를 들면 클라우드 상에서 가동시킬 지, 로컬 PC 상에서 동작 시킬지 등을 결정한다. 데이터 수신 성능도 검증하고 싶은 경우, 데이터 연계를 하기 위한 기반을 준비해야 한다. 학습 모델 검증은 성능이 아니라 정확도 검증을 위해 로컬 PC라도 상관없다.
■준비 및 실시 작업
준비나 실시에 협력하는 관계자가 할 작업을 정한다. A사 예에서는 다음과 같은 준비 작업이 발생할 것이다.
-POS 데이터의 구체적인 추출 조건 지정
-POS 데이터 제공 요청
-파일 서버나 데이터 연계 환경의 구축(이에 따르는 라이선스 계약, 셋업도 포함)
-학습모델 개발환경의 구축
-실시수단 작성(데이터 연계 검증)
이들 작업은 2~3회 사이클로 해야 한다. PoC가 1회로 끝나는 경우는 드물기 때문이다. 1회째는 데이터나 수순 미비, 학습모델 정확도가 나오지 않는 등의 문제가 발생할 가능성이 있다. 2회째 이후 비로소 올바른 상태로 검증할 수 있으며 학습모델의 정확도를 높일 수 있다.
■스케줄
스케줄을 정할 때는 준비에 필요한 시간을 예상하고, 실시 사이클 간 회고와 대책의 재검토 기간을 충분히 마련하는 것이 중요하다
■PoC 결과를 토대로 다시 계획
A사에서는 이상과 같은 계획하에 PoC를 실시했다. 그 결과는 어땠을까?
PM:전체적으로 78% 정확도로 80%에는 도달하지 않았지만 이정도면 괜찮지 않나고 생각합니다
컨설턴트:그렇지요. 목표는 어느 정도 달성했습니다. 다만, 60대 이상 고령자 세그먼트의 추천 정확도가 58%로 낮은 것이 신경이 쓰입니다.
PM:뭔가 대책이 있을까요?
컨설턴트:60대 이상 세그먼트의 POS 데이터가 분명히 부족합니다. 그러므로 과거 3년치까지 범위를 넓혀 보고 AI에 입력하는 데이터를 늘려보면 어떨까요?
이렇게 AI는 데이터가 부족해서 정확도가 나오지 않는 경우가 있다. 전체적으로는 충분한 양의 데이터가 있지만, 어느 부문(세그먼트)로 좁히면 데이터가 적은 경우가 많이 있다. 이런 경우에는 '그 세그먼트를 AI의 대상으로 한다' '데이터를 더 모은다' '다른 세그먼트와 머지(merge) 한다' 등의 대책이 있다. 또, A사의 예에서는 POS 데이터만 이용하기 때문에 파라미터 종류가 적지만, 다양한 데이터를 이용하는 경우, 어느 파라미터를 사용할 것인가 라는 점도 AI 정확도를 향상시키는 요인이다. 여기에서 말하는 파라미터란 AI에 입력하는 데이터 항목이다. '특정 량(Specific amount)' 이라고도 한다.
예를 들면 성별,연령, 지역과 구입 상품을 인풋으로 해 AI에 학습시키는 것과 성별, 연령과 구입 상품 만을 인풋으로 학습시켜 얻어지는 결과는 달라진다. 수중에 있는 데이터를 바탕으로 어떤 방법(데이터를 늘리거나 파라미터를 늘리는 등)을 강구할 수 있는지 검토해 어느 시점(다음 PoC 사이클이나 본 개발 등)에 대책을 실시할지를 정해야 한다.
■실패하지 않는 PoC 추진방법
기술 검증 부분을 PoC라고 하고, 사업적인 유효성 검증은 PoB(Proof of Business)라고 한다. 그러나 특별히 정의하지 않는 한, PoC는 기술 검증과 사업성 검증 두 가지를 모두 아우르는 개념으로 쓰인다. 최근 PoC 실시 건수를 디지털화 조직의 목표 수치로 잡는 기업도 적지 않다. PoC는 사업의 디지털화라는 목적을 달성하기 위한 수단일 뿐이다. 목적과 수단을 혼동하면 안 된다.
■3개 관점에서 프로젝트 추진
PoC에서 멈춰버리는 이유는 크게 3가지가 있다
첫번째는 '실현하고 싶은 서비스가 불명확' 하다는 것이다. 'MaaS(MobilIT담당y as a Service)'를 검증한다는 추상적인 테마가 경영에서 주어지지만 구체적으로 어떤 서비스를 만들고 싶은지 명확하지 않은 경우가 많다. 이런 상황에서 사업 부문에서 수용할 수 있는 서비스를 만들 수 없는 건 당연하다.
두번째는 '검증 항목이 불충분' 하다는 것이다. 흔히 기술 검증에만 몰두해 버리는 경우다. 세번째는 '실행 체제 미비'다. PoC를 추진하기 위한 적절한 멤버를 모으지 못하고 있는 거다. PoC를 능숙히 진행하려면 '비즈니스' '유저' '시스템' 등 이 3개 관점에서 추진할 필요가 있다
'비즈니스 관점'은 그 서비스에 의해 수익을 창출할 수 있을지의 여부다. '유저 관점'은 그 서비스가 고객에게 바람직한 지 여부고, '테크놀로지 관점'은 그 서비스가 기술적으로 실현 가능한지 여부다. 3개 관점 중 어느 것이 빠져도 서비스화 하기는 어렵다. 이 3개 관점에서 '실현하고 싶은 서비스' '검증 항목' '실행 체제'를 정의하는 방법을 알아보자
PoC 성공에 가장 필요한 것은 '실현하고 싶은 서비스'를 제대로 정의하는 것이다. 하지만 목적이 불명확한 채로 기술적인 검증을 언제까지나 계속하는 기업이 있다. 예를 들면, RFID 태그를 사용해 상품의 재고관리를 하려고 프로토타입 시스템을 구축한 기업이 있다고 하자. 판독 정확도를 높이는 노력을 계속 했지만 판독 오류는 완전히 없어지지 않았다. 그럼에도 불구하고 PoC를 계속하는 경우가 있다.
기술 검증을 끝없이 계속하고 있는 기업은 업무 현장의 과제가 보이지 않는 경우가 많다. 실제 업무에서 어떤 과제가 있고, 그 해결을 위해 어느 정도의 RFID 판독 정확도가 요구되고 있는지 모르고 있기 때문이다. 이 경우, '현장 조사' 라는 태스크를 실시해 필요한 해결책을 도출할 수 있다. 즉 '실현하고 싶은 서비스'를 제대로 정의하려면 PoC에서 어떤 태스크를 실시할지 리스트업 할 필요가 있다.
어떤 태스크를 실행할지는 프로젝트에 따라 다르지만, 비즈니스와 유저, 테크놀로지 3개 관점은 어떤 PoC에도 적용할 수 있다. IT담당 부문이 PoC를 진행하면 아무래도 테크놀로지 관점으로 태스크를 정하기 쉽다. 그러면 비즈니스나 유저 관점이 빠져, 앞의 사례와 같이 실현하고 싶은 서비스가 불명확해진다. 또 이 3개 관점에 더해 프로덕트 릴리스(Release) 후까지 예측한 행동 계획을 만들어야 한다.
'문제와 해결책의 적합성 검증' 에서는 유저 과제를 추출해 그 과제를 해결할 방법을 검증한다. '프로덕트와 니즈의 적합성 검증'에서는 해결책을 구체화한 프로덕트의 프로토타입을 작성해 그것이 유저의 니즈에 합치하는지를 검증한다. '시장 확대'에서는 프로덕트의 릴리스 후 해야 할 일을 결정한다.
■사업 부문을 설득할 수 있는 숫자 취득
PoC의 '검증 항목'에 대해서도 비즈니스, 유저, 테크놀로지 이 3개 관점을 도입하는 것이 성공의 지름길이다. 일반적으로 AI 예측 정확도가 90% 이상이다 같은 테크놀로지 관점 평가만으로 그치는 경우가 적지 않다. 그러나 예상되는 매출이나 업무 개선 효과, 액티브 유저(User)의 수 등 비즈니스나 유저 관점에서도 평가해야 한다
PoC 단계에서 실 서비스화 했을 때의 수익 예상이나 삭감 가능한 인력(Man-Hour)등을 산출해 ROI(투자대 효과)를 계산해둬야 한다. 그렇게 하면 경영층이나 사업 부문의 이해를 얻기 쉬워 PoC 추진이 용이해진다.
테크놀로지 관점과 유저 관점에서 검증해야 할 평가 항목이 크게 다른 예를 보자. 어느 금융 기관에서 기존 고객의 행동 이력 등에서 부정 혐의가 큰 거래를 발견해내는 AI 시스템을 도입하려고 했다고 하자.
이를 위한 AI는 전문 IT담당벤더의 서비스를 이용했다. PoC에서 검증한 결과, 사전에 예상하고 있던 검지율을 상회하는 결과였다. 테크놀로지 관점에서는 만족스러운 결과였다. 그러나, 실제로 그 시스템은 도입할 수 없었다. 혐의가 큰 거래를 발견한 경우, 기존 고객에게 그 취지를 통지해야 한다. 왜 부정 혐의가 있는지, 그 근거를 제대로 설명할 수 없으면 거래 중지 등의 조치를 취할 수 없다. 이렇게 사업 부문은 판단했다. IT담당 벤더의 AI 서비스를 이용했기 때문에 왜 부정으로 판단하는 지의 로직은 금융 기관에게는 블랙박스였던 것이다.
결과적으로 '고객에게 근거를 설명할 수 없었기' 때문에 이 부정 검지 시스템의 도입은 보류됐다. 이를 막으려면 PoC 관점에서 유저(이 경우는 사업 부문)의 관점을 도입해 '부정이 의심되는 고객에 대해 일정 근거를 설명할 수 있는가' 라는 검증 항목을 넣었어야 했다.
*참고문헌>
-기획입〮안에서 시스템 개발까지 실제로 사용하는 DX프로젝트의 교과서 (일경BP사, 2020년3월)
-Nikkei systems (2020.1월호 연재기사)
■필자 심기보는...
1976년부터 한전에서 SW개발자로 전산업무를 시작했다. 30여년간 정보화 사업 기획, 개발, 운영업무를 수행하면서 SI사업 등 발주관리 전문가로 일했다.
우리나라 최초로 FP(기능점수)법에 의한 SW사업대가 기준연구 및 보급으로 SW사업 선진화에 기여했다. SEC 정책자문위원과 SW사업분쟁조정위원회위원, 정보통신기술사협회장, KAIST 전산학부 겸직교수, SW정책연구소 초빙연구원 등을 지냈다. 숭실대 대학원에서 'FP법을 이용한 다중회귀 분석적 SW사업대가 산정모델 연구'로 박사 학위를 받았다. 현재는 심기보기술사설계사무소를 설립해 SW설계‧견적‧감정 일을 하고 있다. 특히 SW사업 분쟁방지를 위한 SW사업 요건정의 및 기본설계 전문가로 활동하고 있다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
