"AI 개발 프로세스 안이하게 생각하면 실패"

[심기보의 AI프로젝트 성공 비결③] 애자일인가? 워터폴인가?

전문가 칼럼입력 :2021/07/25 17:11    수정: 2021/08/01 17:03

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

AI 프로젝트는 애자일(Agile) 개발이 일반적으로 적용돼 있다고 생각하기 쉽다. 그러나 실제 꼭 그렇지 않다. 워터폴형이 적합한 경우(케이스)도 많이 있다. 프로젝트 특성에 따라 개발 프로세스를 유연하게 적용해야 한다. AI 프로젝트의 시스템 개발 흐름은 기간계 시스템과는 다르다. 그럼 어떠한 수순에 맞게 진행하면 좋을까?

먼저, AI 프로젝트의 개발 흐름 전체상을 보자. [그림1]은 AI 프로젝트의 대표적 개발 프로세스다. 프로젝트 내용이나 예산 및 체제에 따라 적절한 개발 프로세스가 다르지만 '리스크가 높은 신기술을 이용한다' '신규 유저용 서비스를 개발한다'고 하는 AI 프로젝트는 이러한 개발 프로세스가 하나의 모델이 될 수 있다.

[그림1]을 보면 '워터폴형'이라고 느낄지 모른다. AI 프로젝트의 경우 요건정의에서 설계, 개발 순서대로 진행해 가는 워터폴형이 아니라 짧은 사이클로 개발이나 테스트를 반복하는 애자일형이 적합하다고 생각하고 있는 사람이 많이 있다. 그러나, AI에 항상 애자일형이 적합하다고 할 수 없다. 워터폴형이 적합한 프로젝트도 다수 있다. 이번 회에서는 우선 [그림1]과 같은 워터폴적인 개발 프로세스를 바탕으로 프로젝트 진행 방식을 단계별로 설명하려 한다. 애자일형은 어떤 경우에 채용해야 하는 것인지, 또 어떻게 도입해야 할 지에 대해서도 알아본다.

서비스 기획과 요구정의를 먼저 해야

먼저 단계 ①에서는 요구 정의를 한다. 새로운 서비스를 개발하는 AI 프로젝트는 기존 업무가 존재하지 않는다. 그래서 우선은 서비스 기획과 서비스 요구 정의를 한다. 서비스 기획이란 '고객(서비스 이용자)은 누구인가?' '어떠한 과제를 해결하는가?' '무엇을 사용해 해결하는가?'의 3개 항목을 명확히 하는 것이다. 이들이 애매하면 요건정의에 무엇을 담아야 할 지에 대한 판단 축이 흔들린다.

이 3개 항목을 명확히 할 때의 포인트는 유저 관점을 만족시키는 것이다. 3개 항목이 제대로 정해져 있는 것처럼 보여도 유저 관점에서 검증돼 있지 않은 경우가 많이 있다. AI 프로젝트 기획은 유저 과제나 니즈(Needs)가 존재하는 지 확실히 확인하지 않으면 실패할 확률이 높다. 아무도 사용하지 않는 시스템이 되고 만다.

다음에 서비스 요구정의를 한다. 기획(안)을 실현하기 위해 어떤 디바이스로 어떤 기능을 필요 한 지를 다음과 같이 정리한다. 첫째, 과거의 일별 주문 데이터를 이용해 최적의 스텝(staff) 수를 예측한다 둘째, 예측 결과를 점장에게 메일로 통지한다.

PoC나 테스트 마케팅으로 재검토 필요

서비스 요건 및 요구를 받아 실시하는 것이 PoC(Prove of concept, 개념 실증)와 테스트 마케팅이다. 이들을 통해 기획 검증이나 재검토를 시행한다. 이 프로세스가 가장 AI 프로젝트다운 공정이라고 할 수 있다.

AI 기술을 이용해 미지의 서비스를 개발하는 AI 프로젝트는 워터폴형으로 최초에 요건을 엄밀히 정의해 그대로 개발하면 다양한 리스크가 있다. PoC나 테스트 마케팅이라고 하는 공정을 만들어 기획을 검증, 필요에 따라 재검토하거나 수정해야 한다. PoC는 기획이나 아이디어가 실현 가능한지를 검증하는 작업이다. AI기술을 이용한 서비스의 경우, 가장 일어나기 쉬운 리스크는 '정확도가 높지 않다' 혹은 '실용적이지 못하다'는 것이다. 학습용 데이터가 충분히 있어도 그 데이터의 질이 높지 않으면 기대하는 정확도가 나오지 않는다. 이외에도 엔지니어 스킬이 부족하다 거나 이용하는 알고리즘이 적합하지 않는다 등의 리스크가 항상 존재한다. 이들 리스크를 배제하기 위해 PoC를 2∼3회 정도 반복하는 스케줄을 잡을 필요가 있다. 물론, 한없이 반복할 수는 없으므로 3개월 등 기간을 정해야 한다.

테스트 마케팅은 PMF(Product Market Fit )를 확인하기 위해 실시한다. 개발하려고 하는 제품이나 서비스가 마켓, 즉 유저 니즈에 적합한지 여부를 검증하는 것이다. 수십억∼수백억 원을 들였지만 아무도 사용하지 않는 시스템을 만들었다는 비극을 현실에서 자주 접한다. 이를 피하기 위해서는 목업(mock-up)이나 프로토타입(Prototype) 등의 MVP(Minimum Viable Product, 검증 가능한 필요 최소한의 프로덕트)를 이용해 예상되는 유저에게 서비스 이미지를 확인받고, 가능한한 빨리 피드백을 받아 PMF의 미스매치를 방지하는 것이 중요하다.

PoC나 테스트 마케팅을 실시하면 그 결과를 미리 검증할 수 있다. AI 예측 결과가 실제로 사용할 수 있는 정확도인가, 고객 니즈에 맞는 서비스인가 등을 검증해 개발을 그대로 진행할 지, 또 PoC 기간을 연장 할지, 서비스 내용 자체를 재검토할 지 등을 재계획한다. 임시 개발을 할때도 그대로 진행하는 경우는 드물다. 많은 경우, PoC 결과나 테스트 마케팅 결과를 받아들여 기획 및 요건을 재검토해야 한다.

시스템 요건 정의와 업무요건 정의

단계②에서는 시스템 요건 정의와 업무 요건 정의를 시행한다. 먼저 서비스 요구를 바탕으로 시스템 요건을 결정한다. 구체적으로는 서비스 요구 내용을 바탕으로 '입력 데이터' '처리의 내용' '출력 데이터'를 저리해 기능이나 데이터 목록을 정의한다.

기능 및 데이터를 정리한 후 [그림2]와 같이 시스템을 어떻게 구성할 지 정의한다. 업무 요건정의란 서비스 요구를 충족시키기 위한 업무 개요를 업무 플로우로 정리하는 것이다. 예를 들어 다음과 같이 정리한다. 첫째, 필요한 인력(Staff) 예측을 이용한 시프트 생성 업무 플로우 둘째, 예측에 대한 결과의 입력 업무 플로우 등이다.

AI에서도 시스템 설계는 필수

단계③에서 시행하는 것은 시스템 설계, 구현, 테스트 등이다. 우선은 기본설계와 상세설계다.

AI프로젝트라고 해서 설계가 불필요하다고는 할 수 없다. 예를 들면 [그림3]과 같은 시스템을 개발하는 경우, UI(User Interface) 등의 프론트(Front)나 백엔드(Backend) 기능, 기타 모듈의 일관성을 확보하기 위해 설계는 필수다. 어떤 입력 데이터를 사용할까, 그 데이터를 기초로 어떠한 특정 량(AI로 해결하고 싶은 과제를 특정 짓는 것, 파라메터)의 설계를 하고 있는가를 마무리해 두지 않으면 운용단계에서 시스템 보수를 할 수 없게 된다.

일방적인 서비스는 요건이나 사양이 변하기 쉽다(변해갈 필요가 있다)는 특성이 있다. 그러므로 설계단계에서 만드는 것은 최소한의 설계 다큐먼트로 한정할 필요가 있다. 또, 기본설계 다큐먼트와 상세설계 다큐먼트를 별도로 만들면 관리(메인터넌스) 수고가 증가하므로 가능하면 한 개로 정리한다.

테스트에 요구되는 것은 기간계와 동일

설계가 끝나면 기본 및 상세 설계 다큐먼트를 바탕으로 구현을 한다. 단 앞에서 설명한대로 요건이나 사양이 변하기 쉬우므로 그때마다 테스트 사양서를 만들면 메인터넌스가 뒤따라가지 못한다. 그러므로 CI(Continuous Integration, 계속적 인티그레이션) 일환인 자동 테스트 등의 구조를 도입하면 좋을 것이다.

기존의 CRM(고객관계관리) 시스템과 연계하거나 기간 시스템에서 데이터를 취득하는 등 연계 시스템이 있는 경우는 외부결합 테스트를 제대로 실시할 필요가 있다. 이 때, 유저 기업 내의 관계 부서와 사전 조정을 배려하는 것이 포인트다.  IT부서 등 연계 시스템의 관리 담당자가 유연한 스케줄로 대응해 주는 경우는 거의 없다. 기일에 여유를 가지고 사전에 상담해 스케줄과 테스트 내용을 조정해야 한다.

최종 품질 보증 테스트인 통합 테스트는 AI 서비스 개발에도 필수다. 단위 시스템으로 동작하는 간이적인 툴 레벨의 서비스라면 필요 없겠지만 복수 시스템으로 구성하는 경우, 서브 시스템 전부를 접속한 상태에서 테스트를 한다.

본 가동 수준의 데이터를 처리할 수 있는 지 여부를 체크하는 성능 테스트나 시스템 운용을 예상한 테스트, OS나 브라우저 등 동작 환경 확인이라고 하는 비 기능 요건 테스트도 요구된다. 서비스에 따라서는 취약성 진단도 필요하다. 이 같은 품질 보증 사고 방식은 기간계 시스템 개발과 같다.

유저 테스트도 중요하다. 서비스 공개 전에 AI팀 담당자들에 의한 조작감이나 기능검증을 행한다. 한정된 사람들에게 실제로 이용하게 해 피드백을 받아 개선해 가는 프로세스다. 한정된 사람이란 기획 단계에서 예상한 타깃의 조건에 맞는 사람들을 가리킨다. 그 중에서 얼리어덥터(Early adaptor)라고 불리는 비교적 새로운 것을 좋아하는 사람들을 선정하면 좋다. 보수적인 사람에게 의견을 물으면 부정적인 의견만 나온다.

공개 대상자 인원 수는 10인 정도로 모집하는 것이 좋다. 너무 많은 의견이 나와도 그 의견을 서로 이해하기 힘들다. 유저에게서 피드백을 받으면 서비스 재검토나 수정을 실시한다. 피드백 내용이 서비스의 핵심 기능이나 UX(User Experience)에 관한 경우는 개선 후 그 결과를 한번 더 유저에게 확인을 받는다. 피드백 내용이 경미한 것이면 한번의 유저 테스트로도 괜찮다. 여기까지 마치면 드디어 릴리스다. 덧붙여서 베타B판 릴리스와 같이 폭넓게 유저에게 피드백을 받는 방법도 있다.

애자일이 적합한 네 가지 조건

지금까지 살펴본 바와 같이 AI 프로젝트도 종래의 업무 시스템 개발 프로세스와 크게 다르지 않다. AI 프로젝트도 시스템 개발 프로젝트의 하나인 것이다. 하지만 AI나 IoT 등과 같이 최신 기술을 이용한다 든지, 누구도 본 적 없는 신규 서비스를 처음부터 만든다든지 등 AI 프로젝트에는 특유의 리스크와 성질이 있다. 이들을 고려한 개발 프로세스로 튜닝해 가는 것이 요구된다.

여기까지 워터폴형 개발 프로세스를 기준으로 AI 프로젝트 진행방식을 설명했다. 일반적으로 AI 프로젝트는 애자일 개발 프로세스가 적합하다고 생각하기 쉽다. 물론, 애자일 개발 프로세스가 적합한 경우도 있다. 단, 애자일 개발은 다음과 같은 4개의 전제 조건을 충족시킬 때 적합하다.

첫째, 시스템 개발 규모가 크지 않다 둘째, 고품질이 요구되는 시스템이 아니다 셋째, 프로덕트 오너가 있어 의사결정을 할 수 있다 넷째, 스킬이 높은 엔지니어를 확보하고 있다 등이다. 이들 조건을 충족시키지 못하면 애자일 개발은 대폭적 스케줄 지연이나 프로젝트 중지 등 중대한 트러블을 초래할 수 있다. 이러한 조건에 대해 상세히 알아본다.

시스템 개발 규모가 크지 않은 경우

개발 규모가 크면 관련된 멤버 수가 많아진다. 그만큼 커뮤니케이션 코스트가 증가한다. 멤버 각각의 스킬 과 지식 레벨 차이, 이해력 차이 등으로 다음과 같은 커뮤니케이션이 발생되기 때문이다.

첫째, 가르치고 이해시키기 위한 커뮤니케이션 둘째, 사양의 일관성을 유지하기 위한 커뮤니케이션

셋째, 품질 레벨을 일정하게 하기 위한 리뷰 넷째, 팀으로서 모티베이션을 지키기 위한 커뮤니케이션(감정적인 다툼을 일으키지 않는 등) 등이다.

스킬 레벨이 다른 사람이 많으면 멤버의 작업량을 조정하는 것도 어렵다. 그 결과, 개발 스피드가 올라가지 않아 투입 인력에 비해 생산량이 낮아져 애자일 개발의 강점이 나오지 않는다. 프로젝트 내용에 따라 다르지만 프로덕트 오너를 포함해 4~5명 정도로 팀을 조직해 진행할 수 있는 규모가 중요하다.

이 조건에 맞는 AI 프로젝트는 단계적인 RPA(Robotic Process Automation) 도입 프로젝트, 이미지 인식 등 단기능의 AI 개발 프로젝트, IoT 제품의 프로토타입 개발 프로젝트 등이 해당된다. (그림4). 단, 이들은 어디까지나 전형적인 예로 실제 프로젝트 내용에 따라 다르다.

고품질을 요구하는 시스템이 아닌 경우

하드웨어 제품 등 이용자가 손에 넣을 수 있는 것이나 B2B2C(기업용 서비스를 제공, 고객 기업이 그것을 일반 소비자에게 제공하는 형태)와 같이 다양한 관계자가 등장하는 서비스 시스템, 기존 시스템과 연계하는 시스템의 경우 높은 레벨의 품질을 요구할 수 있다. 그러므로 프로토타입 개발은 애자일형으로 괜찮다고 해도 본 서비스의 개발 시에는 반드시 엄밀한 품질 보증 테스트가 필요하게 된다. 즉, 도중에 워터폴형 개발이 된다.

예를 들면, 호텔 예약 서비스의 경우 서비스 제공자, 숙박 시설 담당자, 예약자라고 하는 3자의 기능이 있다. 각 기능에서 사양 일관성 확보나 전체 업무 흐름을 확인하는 통합 테스트가 필요하게 된다. 기존 시스템과 연계하는 서비스 시스템이라면 사양 조정의 타이밍을 맞출 필요가 있으므로 품질 보증을 위해 연계 테스트를 하지 않으면 안 된다. 기존 시스템과의 연계 테스트는 사전에 스케줄, 테스트 케이스나 테스트 데이터, 테스트 수순 등을 조정한 다음 실시한다. 일반적으로 연계 테스트는 결합 테스트와 통합 테스트를 적어도 2회 실시한다. 필연적으로 워터폴형이 되기 쉽다.

프로덕트 오너가 있어 의사 결정을 할 수 있어

규모나 내용이 애자일에 적합한 프로젝트라고 해도 팀 체제가 애자일에 맞는 지의 여부를 확인할 필요가 있다. 애자일 개발의 요체는 '빨리 물건을 만들어 요건을 충족시키는 것'이라고 할 수 있다. 그럼 '요건을 충족시키고 있는가?'는 누가 판단할까? 프로덕트 오너(프로덕트 매니저)다. 프로덕트 오너가 이름만 어사인 돼 있고 실제는 최종 승인자가 팀 외의 임원이나 부장이라고 하면 애자일형은 원활히 진행되지 않는다. 의사결정에 시간이 걸릴 가능성이 있기 때문이다.

상위직에 있는 사람이 매우 바빠서 승인에 시간이 걸리고 사전 보고(강의)에 시간이 걸리는 등 많은 작업 코스트도 발생한다. 현장 실태나 요건을 세밀히 파악하지 못한 임원이나 부장급의 한 마디로 밥상이 뒤집힐 리스크도 있다.  그러므로 AI 프로젝트 기획 내용의 현장을 잘 파악해 프로젝트 본연의 모습을 이해하고 있는 프로덕트 오너에게 의사 결정 권한이 주어져야 한다. 프로덕트 오너가 엔지니어고 물리적으로 가까운 장소에 있어 즉시 판단할 수 있는 환경도 중요하다.

스킬이 높은 엔지니어 확보하고 있어야

애자일 개발에서는 엔지니어 스킬이 높은 것도 중요하다. 엔지니어 스킬 부족으로 개발에 시간이 오래 걸리거나 품질에 문제가 발생할 수 있다. 이래서는 빨리 물건을 보면서 요건을 생각하는 것 자체가 불가능하기 때문에 개발의 끝이 보이지 않게 된다. 그러면 단번에 애자일 개발에 대한 불신감이 생겨 프로젝트 자체가 중지되어 버릴지 모른다. 여기에서 말하는 스킬은 프로그래밍 스킬 만이 아니다. 프로덕트 오너의 요망을 이해 및 해석하는 스킬도 중요하다.

부분적으로 애자일을 도입해야

전면적으로 애자일 개발을 도입할 수 없다고 해도 부분적으로 애자일적인 진행방식을 도입하는 것은 가능하다. 오히려 부분적인 도입을 적극적으로 검토해야 한다. 애자일적인 진행 방식이란 목업(mock up)을 기본으로 요건을 상세화하는 등 '개발을 수반하지 않는 반복 작업'을 말한다. 애자일이 도입 가능한 곳은 '기획~요건정의' '설계~구현'의 2개다. 구체적으로 [그림5]의 ①과 ③ 부분이다.

먼저 ①의 '기획~요건정의」에 대해 설명한다. AI 프로젝트의 경우 처음부터 명확한 요건은 없다. 이 때문에 기획단계에서 실현하고 싶은 서비스 이미지를 일러스트 등의 형태로 표현, 서비스 아이디어를 반복해 브러시업 한다. 요건정의도 일러스트 만으로는 UX 이미지가 부각되기 어려우므로 목업(Mock up)을 만든다. 그리고 기능 요건을 정해 목업에 반영해 요건을 확정(Freezing)하는 반복적인 검토가 효과적이다. PoC나 테스트 마케팅을 거쳐 기획 내용이나 요건을 재검토하는 공정도 넓은 의미로는 애자일적인 진행방식이 된다고 생각할 수 있다.

단, 부분적인 애자일이라고 해도 프로덕트 오너에 따라 의사 결정 체제나 일정 이상의 스킬을 가지는 멤버가 필요하다. 기획~요건정의에서는 스킬이 있는 플래너(Planner)나 UI 및 UX 디자이너를 멤버에 추가해야 한다.

개발을 시작하기 전 규격(사양) 일관성을 유지해야

또 하나 ③의 '설계~구현' 단계에서 상세한 사양을 애자일적으로 확정(Freezing)하는 것은 가능하다. 예를 들면 화면 전환(Transition) 이나 초기 표시 등의 거동은 요건정의 단계서는 상세히 정하지 말고 실제 화면을 보면서 사양을 구체화해 가는 편이 효율적인 경우가 많다.

그러나, 아무것도 정하지 않고 개발을 시작하면 좋지 않다. 개발을 개시하기 전에 기능간, 데이터 간 사양에 대해 대체로 일관성을 취할 필요가 있다. [그림5]의 ② 단계가 이에 해당한다. 또, 기존 시스템과 접속하는 경우 인터페이스 사양도 ② 단계에서 확실히 조정할 필요가 있다.

테스트 공정 이후에는 애자일형이 기본적으로 적합하지 않다. 워터폴적으로 수순을 따라 진행하게 된다. 이와 같이 AI 프로젝트를 담당하면 'AI 프로젝트이므로 애자일 개발이다' 고 하지 말고 우선은 프로젝트가 애자일에 적합한지, 애자일에 필요한 팀 체제가 정비되어 있는지를 체크한다. 만약 애자일 개발이 어려운 경우, 부분적으로 애자일을 취하는 방법을 생각한다.

AI 프로젝트 개발 프로세스는 애자일 이나 워터폴의 양자 택일이 아니다. 각각의 좋은 부분을 취해 시행하는 것이 프로젝트를 성공적으로 이끄는 포인트다.

*참고문헌

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

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

관련기사


필자 심기보는...

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

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