"AI는 만능 아냐···범위와 업무요건 명확히 해야"

[심기보의 AI프로젝트 성공 비결⑦] AI시스템 요건정의 1

전문가 칼럼입력 :2021/08/22 10:57    수정: 2021/08/22 17:54

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

인공지능(AI) 개요는 이해하고 있지만, 시스템 구축 현장에서는 이를 어떻게 사용해야 할까? 이러한 의문에 답하기 위해 AI시스템 구축시 알아야 할 요점을 소개한다.

 요건은 책상 위에서 모두 작성할 수 없어

요건정의는 AI프로젝트 뿐만 아니라 정보시스템 구축 프로젝트의 성패를 좌우하는 가장 중요한 프로세스다. 특히 AI시스템 구축에서는 AI가 수행해야 할 역할이나 AI시스템 구축 목적이 명확하지 않은 경우가 많기 때문에 통상의 기간계(Backbone) 시스템 구축 때 보다 요건정의 난이도가 더 높다. 또 AI시스템 구축 특징으로 요건정의 단계에서 PoC(개념실증, Proof of Concept)가 있다는 걸 들 수 있다. 일반적인 업무 프로세스를 구축하는 프로젝트와 달리 대부분의 AI시스템 구축 프로젝트는 요건정의 단계때 탁상에서 판단할 수 없는 사항이 수없이 많이 존재하기 때문이다.

프로젝트 범위(Scope) 정량화 및 구체화

프로젝트를 개시할 때 AI시스템 구축 목적을 명확히 해야 한다. '당연한 것' 이라고 생각할 지도 모르지만, AI시스템 구축 프로젝트에 있어 최초로 부딪히는 어려운 문제가 바로 이거다. 즉, 자주 있는 실패 중하나가 'AI의 도입' 자체를 목적으로 하는 거다. AI는 업무상 목적을 달성하기 위한 하나의 수단일 뿐이다. 'AI 도입' 목적을 브레이크다운(Breakdown)해 상세화해야 한다. 또 발주자(User)가 'AI는 만능' 이라고 생각해 목적을 정하지 않는 경우도 자주 볼 수 있다. 이래서도 안된다. 소매업에서 점포 별 수요를 예측해 상품 발주 작업을 지원하는 시스템을 도입한다고 생각해 보자. AI시스템으로 어떠한 효과를 얻을 수 있다고 생각할까? 실제 프로젝트에서는 다음과 같은 AI시스템 구축 목적이 있을 수 있다.

-매매상품의 발주 누락 방지로 매상 향상

-재고 폐기 율 저하로 코스트 저감

-상품 발주업무 시간의 단축으로 잔업 시간 단축

-상품 요건 증가 향상을 종업원에게 교육해 고객의 상품 제안력 강화

-고객의 잠재적 구매 욕구를 끌어내는 감동적인 품질 실현

이중 몇 가지는 상품 발주업무 지원시스템 목적으로 '무리가 있다'고 느끼는 독자도 있을 것 같다. 하지만 실제 AI시스템 구축 프로젝트를 시작하면 그렇지 않다.

AI는 만능 아냐

일정한 코스트와 스케줄로 프로젝트를 진행하려면 실현성 있는 목적과 범위(스콥)를 설정해야 한다. 프로젝트의 스콥을 명확히 하기 위한 유효한 수단 중 하나는 AI시스템 구축의 목적과 효과를 정량화하거나 구체화하는 거다. 복수 관점에서 구축 목적이 알려진 경우, 목표로 해야 할 지표를 보다 구체화하면 목적 간 우선순위를 결정하기 쉬워진다.

앞의 예처럼 프로젝트 목적으로 '재고 폐기율 저하에 따른 코스트 저감'으로 설정하면 AI가 높은 예측 정확도를 구할 수 있다. 반면 '상품 수요 증가 경향을 종업원에게 교육해 고객의 상품 제안력 강화'를 목적으로 할 경우에는 정확도 보다도 해석성(AI가 왜 이러한 예측 결과를 나타내는가, AI를 사용하는 인간이 이해할 수 있는 것)이 높은 알고리즘을 선택하는 것이 더 좋다. AI에 해석성이 필요한가는 업무 요건을 작성하는데 가장 중요한 포인트 중 하나고 알고리즘 제안에 큰 영향을 미친다.

요건정의 단계의 전체 모습(Overall Picture)

AI 프로젝트에서 신(新) 서비스를 개발하는 경우 기존 업무를 정리한 후 시스템 요건을 정의하는 기간계 시스템시 개발 정석이 통용되지 않는다. 이제 시스템화 대상이 되는 기존 업무가 없다는 전제하에 요건정의를 어떻게 해야 할 지를 설명한다.

A사는 서비스 기획 및 전략 단계가 끝나고 드디어 개발해야 할 시스템의 내용을 구체화하는 요건정의 작업을 하려 하고 있다. 먼저 AI리더인 PM, IT담당, 컨설턴트간 대화를 들어보자.

PM :자, 드디어 요건정의를 하는 군요. 어떻게 진행할까요?

IT담당 : 그러네요! 우선은 업무 요건정의를 먼저 한 다음, 시스템 기능 요건정의를 하는 것이 정석이지요.

PM  :역시…. 단, '업무요건'이라고 해도 새로운 서비스니까 기존 업무가 아니겠네요?

IT담당 :  음…. 확실히….

컨설턴트 : 신 시스템 개발 요건정의는 기간계 시스템 개발과는 프로세스가 다릅니다.

이 대화처럼 AI 프로젝트에서 신 시스템을 개발하는 경우에는 기존 업무에 없는 새로운 업무를 대상으로 한다. 기간계시스템처럼 시스템화 대상이 되는 업무를 정리한 후 시스템 요건을 정의하는 개발 방법은 통용되지 않는다. 그럼 어떻게 하면 좋을까? AI 프로젝트도 그 내용에 따라 요건정의 작업의 진행 방식이 다르다. 구체적으로 보면 그 차이는 아래의 [그림2]와 같다.

먼저 기간계 시스템 개발 프로젝트의 요건정의 흐름을 보자. 생명보험회사의 보험계약 체결 관련 시스템 예를 보면, 보험 계약 체결과 관련된 업무는 보험 신청 내용에 부족한 점이 있는 지의 체크나 피보험자의 총액 보험 금액 확인 등이 있다. 이것을 정리한 것이 업무요건이다.

새로운 보험 상품을 개발할 때에는 기존의 업무 어디를 어떻게 바꿀지를 업무요건으로 정리한다. 이 업무요건 중 어떤 업무요건을 시스템화 할까? 또는 어느 시스템 기능을 변경할 지를 정리하는 것이 시스템 요건정의다.

업무개혁을 위한 요건정의는 기간계와 동일

AI프로젝트는 현재 하고 있지 않은 업무를 AI기술을 활용해 시행하는 프로젝트와 현재 하고 있는 업무를 자동화하는 프로젝트 등 두 종류가 있다. RPA(Robotic Process Automation)는 후자에 속한다. RPA는 기존의 업무(작업)가 있고 그것을 어떻게 자동화할지를 생각한다. 즉, 기본적으로 기간계 시스템과 동일한 요건정의 흐름이 된다. 예를 들면, 영수증을 AI를 활용한 OCR(광학문자인식) 시스템으로 판독, 인식한 정보를 회계 시스템에 입력하는 시스템을 구축하는 경우, 영수증 처리 절차 자체는 기존 업무로 존재하기 때문에 이것이 업무요건이 된다. 그 절차 중 어느 부분을 AI나 RPA를 이용해 자동화하는 지가 시스템 요건에 해당한다.

신 서비스 개발은 '기능'을 먼저 정의해야

AI기술을 이용한 신 서비스 개발 프로젝트는 기존의 업무가 있는 게 아니기 때문에 업무요건이 존재하지 않는다. 그럼 어떻게 하면 좋을까? 먼저 시스템 이용자에게 어떠한 기능과 시스템을 제공할지를 정의해야 한다. 웹(Web) 애플리케이션이나 스마트폰 애플리케이션이라면 화면(Front End)과 시스템 이용자용 UI(User Interface) 안을 작성한다. 이용자에게 어떤 서비스를 제공하고 싶은 지에 대한 시스템 기능을 정리하면서 정의해 나간다. 어떠한 시스템을 제공할 지가 정해진 후에는 그것을 운영하기 위한 업무로 무엇이 필요한지를 정의한다. 업무요건을 업무 프로세스 요건으로 파악하면 신 시스템 개발 프로젝트에서 요건정의 프로세스는 시스템 요건정의→업무 요건정의 순서로 이뤄진다. 기간계 프로젝트와는 그 순서가 반대다.

신 서비스를 개발하기 위한 AI 프로젝트 요건정의

신 서비스 개발을 위한 AI 프로젝트의 요건정의 작업을 더 상세화하면 [표1]과 같이 5개로 정리할 수 있다. A사의 프로젝트의 경우 어느 부분의 요건정의를 실시할지를 정의한다.

회원관리나 주문관리 같은 각 점포의 지점장 등이 운영하는 업무가 대상이 된다. (표1)에서 정의한 5종류의 작업은 [그림4]와 같이 진행한다. 먼저 시스템 유저(User)용 화면 기능(Front End)을 정리해 제공하고 싶은 서비스나 표현하고 싶은 것을 확정한다. 다음에는 그 시스템을 제공하기 위해 필요한 운영 업무나 그 업무를 지원하는 관리 기능을 정의한다. 그 다음 화면(Front-End) 기능이나 관리 기능을 실현하기 위해 필요한 AI 기능이나 백엔드(Back-End) 기능이나 데이터 및 관련 시스템과의 인터페이스를 정의한다. 마지막으로 모든 요건을 수용해 가용성이나 안전성이라는 비 기능 요건을 정의한다.

이제 개개 작업의 관련성을 상세히 알아본다. 먼저 프런트엔드(Frontend)기능 요건과 업무 요건 및 관리 기능 요건의 작업 관계성에 대해 설명한다.

신 서비스 개발 프로젝트의 경우, 먼저 서비스 이용자용 기능을 정하지 않으면 업무 요건이 확정되지 않는다.

예를 들면, 빵 추천 서비스 이용자용 기능 요건의 검토 중 '서비스 이용자 화면에 본사나 점포가 기획 및 운영하는 캠페인을 표시해 이용자가 거기에 응모할 수 있다'는 요건이 나왔다고 하자. 캠페인을 표시하려면 캠페인 등록 업무가 필요하고, 시스템 이용자가 캠페인에 응모할 수 있도록 하려면 응모자를 확인해 추첨 작업을 하는 업무도 발생한다. 업무를 하기 위해서는 관리 화면도 필요하다. 캠페인 등록 화면이나 응모자를 목록으로 참조하는 화면 등이다.

이와 같이 신 시스템계 개발 프로젝트의 요건정의는 먼저 시스템 요건 중 프런트엔드 기능 요건을 정해야 한다. 그 결과, 필요한 운영 업무가 정리돼 간다. 이어 프런트엔드 기능 요건이나 업무 요건 및 관리 기능 요건과 AI 기능 요건 및 백엔드 기능 요건의 작업 관계성을 살펴보자. [그림7]이 이를 말해준다.

AI 기능 요건은 [그림8]처럼 프런트엔드 기능 요건의 결정을 수용해 결정한다.예를 들면 프런트엔드 기능 요건에서 '추천하는 빵의 수는 3개와 5개의 패턴이 있다'는 요건으로 했다고 하자. 이 경우, AI의 요건에도 3개의 조합을 추출하기 위한 학습과 5개의 조합을 추출하기 위한 학습 등 두 종류가 필요하다. 백엔드 기능 요건도 프런트엔드 기능 요건의 결정을 수용해 결정한다.

예를 들면 프런트엔드 기능 요건에서 '지불 방법으로 계좌 이체도 가능하게 한다'로 한 경우다. 계좌 이체를 대행하는 수납(Payment) 대행업자에게 청구 데이터를 보낼 필요가 있기 때문에 서버(Back End)측에 계좌 이체 청구 데이터를 작성하는 배치(Batch) 기능이나 청구 결과를 가져올 배치 기능을 준비하는 것이 필요하다. 백엔드기능 요건은 업무 요건의 영향도 받는다.

빵 발송용 상자에 수신인 씰(Seal)을 붙이는 업무를 점포에서 실시하는 경우 일일이 인쇄하는 것은 번거롭다. 발송 대상 회원의 수신인 씰을 일괄적으로 인쇄하는 백엔드 기능이 필요하다는 것을 예상할 수 있다. 이와 같이 백엔드 기능 요건은 프런트엔드 기능이나 업무 요건 및 관리 기능 요건 등을 수용해 정리한다.

비 기능 요건은 다양한 요건의 영향을 받아

마지막으로 비 기능 요건이다. 이것은 프런트엔드 기능, 업무요건 및 관리기능 요건, 백엔드 요건 각각의 영향을 받는다.

예를 들면, 이 시스템에서 요구되는 성능 요건은 캠페인 표시 및 신청 기능을 첨부(Attach)하는 것과 첨부하지 않는 것에 따라 크게 달라진다. 캠페인 표시 및 신청 기능을 첨부하지 않으면 월 1회 추천(Recommend)하는 빵을 스마트폰 상에서 확인할 정도의 접속(액세스) 밖에 없다. 캠페인 표시 및 신청이 가능하게 되면 캠페인 기간에 따라 다르지만 많은 시스템 이용자가 같은 시기에 액세스하게 된다.

보안(시큐리티) 요건도 영향을 받는다. 업무 요건이나 관리 기능 요건으로 캠페인의 당첨 업무를 점포에서 시행하면 개인 정보를 점포에서 다루므로 높은 시큐리티가 요구된다. 백엔드기능 요건으로 계좌 이체 청구 데이터를 외부의 수납 대행업자에게 보낼 필요가 있다고 하면 역시 시큐리티 요건이 발생한다.

가용성 요건은 어떨까? 가용성 요건이란 어느 정도 시스템을 정지시키고 싶지 않은가(높은 가동율을 확보하고 싶은가)의 요건이다. 빵의 확인이나 캠페인 신청이 가능한 시스템 정도라면 '절대로 시스템이 다운되면 안 된다'와 같은 높은 가용성이 요구되지 않는다. 이처럼 비 기능 요건은 각종 요건을 바탕으로 확정(Freezing)할 필요가 있다.

이번 회는 AI프로젝트 요건정의의 전체 모습(Overall picture)을 알아봤다. 다음회는 프런트엔드 기능 요건 작성방법을 다룬다.

* 참고문헌

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

2.Nikkei systems (2018.10월호 연재기사


필자 심기보는...

관련기사

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

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

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

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.