"발표 서비스는 품질과 밸런스 유지하면서 계속 개선해야"

[심기보의 AI프로젝트 성공 비결⑬] 설계 부문

(지디넷코리아=심기보 전 정보통신기술사협회장)신(新) 서비스를 개발하는 AI 프로젝트에서는 서비스 발표(Release) 자체가 목표는 아니다. 발표 후 이용자 반응을 보면서 서비스 개선을 거듭해야 한다. 개발 스피드와 서비스 품질 어느 쪽을 얼마나 우선시할지는 프로젝트마다 다르다. 이를 유의해 프로젝트를 진행해야 한다.

지금까지 AI 프로젝트를 진행하는 A사가 서비스 내용을 구체화하는 요건 정의를 설명했다. 이제부터는 시스템 설계에 들어간다. 설계 단계 중심은 시스템 개발을 수탁 받은 IT 벤더다. 그러나 발주자인 A사 입장에서도 파악해 둬야 할 포인트가 몇 가지 있다. 아래는 요건 정의가 끝나고 한숨 돌린 PM과 IT담당자와의 대화다.

PM: 드디어 요건 정의가 끝났네요. 서비스 내용도 정했고 발표가 기다려지네요.

IT담당: 그렇네요. 그런데 여기서부터 길어요. 설계나 개발에는 시간이 걸리고 만들어진 시스템의 리뷰도 힘듭니다.

PM: 상당히 힘들겠지요. 타사에 앞서 한시라도 빨리 발표하고 싶은데 기다리기만 하면 되나요…

IT담당: 글쎄요. 시스템에 정통한 멤버만 있는 것은 아니니 제대로 리뷰할 수 있는 체제를 짤 수 있을지 모르겠습니다.

PM: 우리는 어떻게 대처하면 좋을까요?

신 서비스계 AI 프로젝트의 경우 발표가 시작된다는 것은 목표가 아니라 스타트라인에 선 것에 지나지 않는다. 서비스를 발표하고 이용자 반응을 보면서 개선하는 것이 중요하다. 즉 개발 기간을 길게 잡고 발표를 느긋하게 기다리는 것은 최선의 방법이 아니다. 물론, 일정한 개발 기간은 필요하다. 신 서비스에서 요구되는 품질수준을 충족시키려면 그 만큼의 시간이 걸린다. 다만 프로젝트 멤버가 품질 확보에 기여할 수 있어야 하는데 그렇지 않는 경우도 많다. AI 프로젝트에 항당(Assign)된 멤버 중 시스템 부문 이외의 사람은 시스템 개발 자체에 익숙하지 못할 것이다. 이들 멤버가 벤더의 보고나 성과물을 바탕으로 품질 확보라는 중요한 역할을 담당하는 것은 어려운 일이다.

어떤 시스템 개발도 개발 스피드와 품질 그 어느 것 하나라도 소홀히 할 수 없다. 기간업무 시스템 개발 프로젝트와 AI 프로젝트는 그림1처럼 양자간 밸런스가 크게 다르다.

또 동일한 AI 프로젝트라도 내용에 따라 개념은 달라진다.  각각에 대하여 알아보자. 어디까지 품질을 요구할 것인지는 프로젝트에 따라 다르다. 먼저 기간업무 시스템 개발의 경우, 한 예로 휴대전화의 계약 업무 시스템을 쇄신하는 프로젝트를 생각해 보자. 이 경우, 신규 계약 접수 화면이나 계약 상황 확인 화면이라는 프런트 엔드(Front End) 기능 개발과 함께, 계약 정보 취득과 이 정보의 고객 정보 관리 시스템에의 연계라는 백 엔드(Back End) 기능 개발 등이 필요하다.

이러한 기간업무 시스템 쇄신이나 개선 보수의 경우, 이미 기존 업무가 가동하고 있는 중에 시스템 변경이 일어나면서 저 품질 시스템이 발표 되면 문제없이 진행되고 있던 기존 업무에 장애를 일으키거나 정지시킨다.  즉, 기간업무 시스템 프로젝트의 경우 개발 스피드를 우선 시 하는 것보다 기존 업무에 영향을 주지 않도록 품질을 높인 다음 시스템을 발표하라는 요구가 많다.

RPA를 도입하는 업무용 AI 프로젝트의 경우에도 기간업무 시스템과 마찬가지로 기존의 업무가 있는 상태에서 시스템 개발이 진행된다. 따라서 기존 업무에 영향을 미치지 않는 수준까지의 고품질 시스템 발표에 유의하는 것이 중요하다.

이에 비해 신서비스 개발계의 AI 프로젝트는 시스템 발표가 스타트라인에 선 것에 불과하다. 발표 직후 많은 서비스 이용자를 획득해 궤도에 오르면 좋지만, 그렇게 잘 되지 않는다. 일반적으로 A/B 테스트, 서비스 이용 상황 확인을 반복하는 등 꾸준한 개선을 하면서 서비스를 키워간다. 개발속도도 중요하다. 타사가 간단히 추종할 수 없는 혁명적인 서비스라면 문제 없지만, 그러한 서비스는 드물다. 서비스의 스타트가 늦어지면 그만큼 경쟁 상대가 늘어난다. 따라서, 경쟁사가 적은 블루오션에서 서비스를 궤도에 올리려면 ‘스피드 중시로 개발한다’ ‘가능한 한 빨리 서비스를 발표한다 한다’ ‘서비스를 키우는 기간을 가능한 한 길게 확보한다’ 등 3개 전략이 중요하다.

그럼, 품질 등의 정도까지 담보해두면 좋을까? 이러한 서비스는 앱 스토어의 리뷰나 SNS 등에서 평가가 한순간에 확산되는 특징이 있다. 고평가면 좋지만 사용 편의성이 나쁘거나 오류가 있는 경우도 있다. 이러한 상황이 계속되면 아무리 서비스를 확대해도 돌이킬 수 없는 상태에 빠지게 된다. 서비스 중에 이용자가 직접 체감하는 부분의 품질 만은 결코 소홀히 할 수 없다.

■개발 프로세스 맞춤화(Customize)해야

이제부터는 신서비스 개발 속도를 단축하기 위해 중요한 사항과 최소 확보해야 할 품질을 담보하기 위해 발주자인 A사가 할 수 있는 것을 생각해 보자. 요건 정의 이후의 시스템 개발 프로세스에는 설계, 구현(프로그래밍), 테스트로 크게 3개의 공정이 있다. 스피드를 중시해 발표까지의 기간을 단축하려면 ‘프로세스 자체의 맞춤화(Customize)’와 ‘각 프로세스 기간 단축’이 필요하다.

먼저 프로세스 자체의 추출에 대해 살펴보자. 각 프로세스의 실제 작업은 IT 벤더가 담당하므로 발주자 입장에 있는 사람이 세세히 이해할 필요는 없다. ‘벤더는 이런 작업을 하고 있구나?’ 정도를 이해하고 있으면 충분하다. 신 서비스계의 AI 프로젝트에서 필요한 프로세스를 (그림2)와 (표1)에 서 보여주고 있다.

워터 폴 개발의 V자형 모델을 토대로 한 프로세스를 AI 프로젝트의 특징에 맞춰 조금 변형된 것이다. 이 프로세스의 포인트는 3가지로 ▲애자일이 아니라 어디까지나 워터 폴 개발이 베이스 ▲상세 설계나 프로그램 설계 공정을 생략 ▲디자인 작성 및 개선 공정을 명확히 정의한다 등이다.

■워터폴 개발이 베이스가 되는 이유

이와 관련해  ‘스피드를 중시한다면 애자일 개발이 좋지 않을까?’ 라고 생각하는 사람도 있을 것이다. 그러나 요건 정의 이후의 프로세스를 생각하면 그렇지도 않다. 앞에서도 언급했지만, 애자일 개발을 성공시키기 위한 전제 조건 네가지를 뒤돌아보자. ①개발 규모가 크지 않을 것 ②미션 크리티컬(Mission critical)하지 않을 것 ③프로덕트 오너가 있어 의사 결정을 할 수 있을 것 ④생산성이 높은 엔지니어가 확보되어 있을 것 등이다. 신 서비스 개발의 경우 ②와 ③ 요건을 충족하는 프로젝트가 많을 것이다. 그러나 ①과 ④ 요건에는 문제가 있는 경우가 대부분이다.

실증(PoC)을 마치고 본격적인 서비스 실현을 위한 개발에 들어가면 프런트 엔드(화면), 백 엔드(서버 등) 관리 기능을 개발해 갈 필요가 있다. 개발 규모가 커지면 그 만큼 많은 엔지니어를 필요로 한다. 이렇게 되면 생산성이 높은 엔지니어 만을 모으는 것은 곤란하다. 만약 규모가 그다지 크지 않은 경우에도 사내 업무 시스템이나 회계 시스템, 신용카드 결제 기반으로 한 사외 시스템과의 연계가 필요한 개발이 많아진다. 회사 내외 관계자와의 조정이나 시스템 연계 부분 개발, 쌍방이 접속된 상태에서의 품질 확인 등을 실시할 필요가 있으며 기본 설계나 외부 결합 테스트라는 공정을 신중히 진행해야 한다. 따라서 워터 폴 개발이 친화성이 높게 된다.

반면 그림2와 같이 상세 설계나 프로그램 설계는 생략한다.  워터폴 형 개발에서는 필수라고 생각하는데 왜 생략할 수 있을까? 이들 공정은 IT 벤더가 알아서 하기 때문이다. 상세 설계나 프로그램 설계는 요건이 확정되었고, 사 내외 시스템과의 사양 조정이 완료되어 있다는 것을 전제로 보수성이 높은 효율적인 처리를 어떻게 만들면 좋을지 생각하는 것을 목적으로 한다. 물론 이 공정이 불필요하다고 할 수는 없지만, 스피드를 중시하는 경우, 굳이 다큐먼트는 만들지 않고 구현(프로그래밍)하는 엔지니어에게 맡길 수 있다. 설계를 하면서 구현을 진행하면 그 만큼 스피드가 올라간다. 앞에서도 언급했지만, 사양의 정합성은 취하면서 이러한 부분에 한정해 부분적인 애자일 개발을 도입해도 좋을 것이다.

■디자인 작성 및 개선 공정 명확히 해야

디자인 작성 및 개선은 엔지니어가 아니라 디자이너 업무(태스크)다. 프로젝트 중 디자이너 인력은 엔지니어에 비해 적은 것이 일반적인데,  창조적인 작업이기 때문에 태스크 관리를 디자이너에 맡겨 버리는 경우가 있다. 그러나 이것은 위험하다. 신 서비스계 AI 프로젝트에서 디자인 계획 작성이나 진척 확인을 게을리하면 프로젝트 전체의 스케줄이 크게 지연될 리스크가 높아진다.

요건 정의 시점에서는 기본적으로는 와이어프레임(WireFRAME)을 사용해 프런트 엔드 화면 이미지를 공유하면서 UI/UX를 검토한다. 기본 설계 이후에는 이 와이어프레임을 토대로 구체적인 디자인을 만들지만, 와이어프레임 자체를 변경하고 싶다는 요구가 제기되는 경우도 있다. UI/UX 향상으로 이어진다면 그 요구를 받아들이는 것은 중요하다. 색깔(Color)의 변경 같은 단순한 요구는 간단히 대응할 수 있을지 모르지만, 표시 방법이나 표시 내용에까지 영향을 주는 변경을 하고 싶은 경우에는 소스 코드 수정이 필요한 경우도 발생한다.

이러한 가운데 디자인 태스크 계획(디자인 작성 순번이나 드래프트 작성 예정, 발주자에 의한 리뷰 타이밍 등)이 불명확한 채 진행되면 디자인 작성이나 개발이 예정대로 완료되지 못할 사태가 발생하기 쉽다. 따라서 신 서비스계 AI 프로젝트에서는 개발 계획과 동일하게 디자인 태스크 계획도 작성할 필요가 있다. 이 계획에 따라 발주자와 디자이너 간 의견 교환을 하는 것도 중요하다. 또, 화면 디자인 검토는 그림3처럼 발주자가 해야 할 중요한 역할 중 하나다. 화면이라는 어느 의미에서는 알기 쉬운 성과물을 확인하고, 그 품질을 디자이너와 함께 높여가는 작업은 UI/UX 서비스를 크게 좌우하기 때문이다.

*참고문헌

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

■필자 심기보는...

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

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

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

심기보 전 정보통신기술사협회장(pmodosa@naver.co.kr)