"기능을 먼저 결정하고 프런트 엔드 구성 상세화해야"

[지디넷코리아]

이번 회는 신 서비스 개발 AI 프로젝트의 요건정의를 상세히 설명한다. 우선 요건정의 중 가장 중요하다고 하는 프런트 엔드 기능 요건정의에 대해 알아보자.

프런트 엔드 기능 요건정의는 실 사용자에게 어떠한 서비스(기능이나 컨텐츠)를 제공할 지를 결정한다. 전회에서 설명한대로 업무 요건 및 관리 기능 요건, 백 엔드 요건 및 AI 기능 요건 등에 영향을 주는 중요한 작업이다. 구체적인 프런트 엔드의 와이어 프레임(Wire FRAME)을 그리면서 통지(Notification) 등 시스템 사용자와의 커뮤니케이션 등을 포함한 서비스 내용을 다시 결정해 간다. 주요 작업을 보면 [표1]과 같다.

웹(Web) 내플리케이션과 스마트폰 애플리케이션 용 서비스 개발을 예상한 것이다. A사는 개발해야 할 서비스 내용을 구체화하는 첫번째 요건정의 작업인 프런트 엔드 요건정의 작업을 하려 하고 있다. AI리더인 PM, IT담당, 컨설턴트의 대화를 들어 보자.

PM:프런트 엔드 기능 요건정의에서 무엇을 해야 할지는 알겠는데 이것을 우리가 할 수 있을까요?

IT담당 : 음…. 저는 업무 프로세스를 만든 경험 밖에 없어서요...

PM : 업무 요건은 발주자가 내는 것이 보통인데요, 프런트 엔드 기능 요건도 우리가 하는 것일까요?

IT담당 : 음….

컨설턴트 : 프런트 엔드 기능 요건은 발주자 혼자 결정하는 것은 어렵다고 생각합니다. 서비스 개발 전문업체의 지원을 받는 것이 좋다고 생각합니다.

프런트 엔드 기능 요건정의 작업은 업무가 아니라 서비스에 관한 요건정의 작업에 해당한다. 따라서 프런트 엔드 개발에 강한 전문 회사나 디자인 회사, 시스템 개발 회사에 의뢰하는 것이 일반적이다. 스마트폰의 애플리케이션이나 웹(Web) 시스템의 UX(User Experience)나 UI(User Interface)는 나날이 진화해 가고 있다. 예를 들면, 스마트폰 애플리케이션으로 성별이나 연령, 주소 등을 입력시키는 요건인 경우, 경우에 따라서는 공개 불가라고 판단할 우려가 있다. 또, 위치정보 취득 룰(Rule) 등도 OS에 따라 여러 제약이 있다. 이러한 최신 정보는 스마트폰 애플리케이션 개발 실적이 많은 회사가 잘 알고 있다. 또, 많은 타사 사례를 알고 있는 사람이 최적의 UX를 생각할 수 있을 것이다. 프런트 엔드 개발에 능통한 회사를 요건정의 단계부터 참가시키면 무난하다.

그렇다고는 해도 그런 회사에 전부 맡길 수 있는 건 아니다. 발주자인 사용자로서 '무엇을 실현하고 싶은가?' '무엇을 제공하고 싶은가?'를 확실히 전달할 필요가 있다. What(무엇을 만들까?) 보다도 How(어떻게 만들까?)에 대해 외부의 지원을 받는 것이 좋다.

■ 리얼(Real)한 화면 이미지를 만들면서 구체화

그러면 주된 요건정의 작업에 대해 하나씩 말해보자. 우선은 화면 요건정의다. 구상 단계에서도 간단한 프런트 엔드 이미지는 정리하였지만 요건정의 단계에서는 좀더 상세히 검토한다.

프런트 엔드의 구성이나 표시 항목을 나열한 '와이어 프레임' 레벨까지 구체화한다. 기간계 시스템 개발 프로젝트 요건정의는 '여기에 회원 정보를 입력한다' 등 엔티티(Entity, A chunk of Information, 데이터그룹) 단위로 화면을 정의하는 방법이나 주요 항목 만을 정의하는 방법이 일반적이다. 그러나 AI 프로젝트는 기간계와 달리 인풋이 되는 명확한 기존의 업무 요건이 없다. 그래서 어느 정도 리얼한 화면 이미지를 만들면서 요건을 정의해 가는 애자일(Agile)적인 진행 방식이 필요하다. 리얼한 화면 이미지란 하나 하나의 표시 항목의 레벨까지 구체화한 것이다.

또 신 서비스 개발에는 프런트 엔드 기능을 지탱하기 위한 관리 기능이나 백 엔드 기능이 있다. 프런트 엔드 기능 만이라도 빨리 구체화해 두지 않으면 스케줄이 대폭 연장될 우려가 있다. 원래 AI 프로젝트는 기간계 시스템 프로젝트에 비해 개발 기간이 짧은 것이 대부분이다. 기간계 시스템 프로젝트와 동일한 진행 방식으로는 할 수 없다는 것을 알 수 있다.

■유스케이스(Usecase) 별로 요건 정의

화면 요건정의 작업은 구상 단계에서 정리한 유스케이스 별, 또는 관련 있는 복수 유스케이스 별로 진행한다.

유스케이스 단위로 요건정의를 하는 목적은 UX 향상에 있다. 서비스 이용자의 화면 조작(Operation)을 유스케이스 단위로 생각, 가장 쾌적한 UX를 제공할 수 있는 화면 구성이나 조작 플로우(Operation Flow)를 검토한다. 그 중에서도 우선적으로 검토해야 할 것은 서비스의 근간이 되는 유스케이스다. A사 서비스에서는 빵의 추천(Recommend)이 서비스 근간이므로 추천에 관한 유스케이스의 우선도가 높다.

실제로 빵의 추천에 관한 유스케이스로 어떻게 화면 요건정의를 진행해 갈지에 대해 알아본다. 먼저 이용자의 조작 플로우(Operation Flow)를 그리고 전체 UX를 생각하면서 각 화면의 구성을 검토하고, 그 구성을 바탕으로 플로우를 고쳐 나가는 방식으로 플로우와 구성의 정의를 반복하면서 완성도를 높여간다.

예를 들면, 배송하는 빵을 AI가 선택하는 '위임 플랜'과 이용자가 '스스로 선택'하는 플랜 등 2개를 준비하기로 한다. 화면 흐름(Flow)이 다르기 때문에 각각에 대해 정리한다. '위임 플랜'은 AI가 추천을 할 때 필요한 정보를 이용자에게 입력시키게 하는 것을 의식한 플로우로 하고 있다. 조건(칼로리)을 선택하게 한다, 회원 정보를 입력시킨다 등이다.

도시와 교외에서는 기호성이 다를 것이며 춥거나 따뜻한 기온의 차이도 기호성에 영향을 줄 가능성이 있다. 성별, 연령에 의한 경향도 있을 것이며 칼로리를 신경 쓰는 사람과 그렇지 않은 사람으로 취향이 갈릴지도 모른다. 이런 것을 생각하며 어떤 화면이 필요한지를 검토한다. 그다음, 개개의 화면 레이아웃을 검토한다. 예를 들면 회원 정보를 입력하는 화면 레이아웃에서는 추천에 필요한 입력 정보를 항목 레벨로 정리해 간다.

]

전 항목을 1개 화면에 입력할 것인지, 혹은 여러 개로 나누는 것이 좋을 지를 생각해 UX를 고려, 화면 플로우와 화면 구성을 결정해 간다.

■애플리케이션 동작(behavior)이나 백 사이드(Back side)에서 처리 정리

화면 흐름(Flow)과 구성이 대략 확정되면 각 화면의 처리 요건을 정의한다. 이용자가 문자 입력이나 화면 선택 등을 할 때 애플리케이션이 어떤 동작을 하는 지, 그 백 사이드(Back side)에서 어떠한 처리가 필요한지를 정리한다.

정리할 내용은 정보를 출력하는 화면인지, 입력시키는 화면인지에 따라 다르다. 출력의 경우, 스스로 빵을 선택하는 코스를 선택한 이용자에게 빵의 선택 화면을 표시한다. 이때, 빵의 정보를 시스템 어디부터 취득, 어떻게 가공해 표시할지를 정의할 필요가 있다

A사는 상품 정보를 정리한 '상품 마스터'를 기존 시스템으로 관리하고 있다. 빵 선택 화면에서는 이 빵의 상품 마스터에 있는 정보를 표시한다. 상품 마스터 정보 API가 제공되어 있는 경우에는 이 API를 통해 정보를 검색하는 처리를 기재한다. 그 다음, 검색한 정보를 어떻게 표시할지를 생각한다. 상품명을 문자 만으로 표시할 것인지, 그림을 넣을 것인지, 상품명이 긴 경우에는 어떻게 표시할 것인지 등이다.

표시 순서나 개수도 검토한다. 순서는 상품의 등록일자 순서나 가격이 싼 순서, 인기 순서 등을 생각할 수 있다. 또, 식사 빵으로 최대 몇개까지 표시할지, 그 임계 값을 넘는 상품은 어떻게 할지 등을 정해 간다.

중요한 것은 필요한 정보는 무엇인지, 그것을 어디에서 가져올 지를 명확히 하는 것이다. 이것이 백 엔드 기능 요건에 영향을 준다. 예를 들면, API가 없으면 배치(Batch)로 데이터를 취득하는 기능이 필요하게 된다. 순서는 상품 마스터에 없는 '인기 순'을 이용한다고 하면 관리 화면을 새로 만들어야 한다.

이용자에게 주소 등을 입력하게 하는 화면에서는 입력 데이터의 검증(Validation)을 위해 무엇을 체크할 것인 지, 데이터 등록이나 경신 시에 어떠한 처리를 행할 것인지, 어느 시스템의 어떤 정보를 변경할 필요가 있는지를 정의한다.

예를 들면, 메일 주소를 ID로 하는 경우, 메일 어드레스에 2중 등록 체크로 검증(Validation)할 필요가 있다. 크레디트 카드 번호를 입력하는 경우, 카드 회사의 시스템과 연계해 카드 번호 존재 확인이나 이용 금액 범위 확인 등의 처리가 발생한다.

이 서비스에서 새로 회원으로 등록한 이용자를 기존 CRM(고객 관계 관리) 시스템에서도 관리하는 경우는 CRM 시스템의 등록 API를 실행하는 처리도 필요하다. DMP(Data Management Platform) 등 데이터 분석용의 데이터베이스가 있는 경우, 그에 대한 정보 등록도 검토한다.

또, 이용자가 입력한 데이터 자릿수의 검증 등의 세세한 요건은 요건정의 단계에서 정하지 않아도 된다. 이러한 요건은 이 후 실시하는 백 엔드 요건정의 등의 작업에 영향을 주지 않는 경우가 많기 때문이다. 여기서는 '후속 작업에 영향을 줄 것 같은 항목'을 명확히 한다는 의식을 가지도록 한다.

■커뮤니케이션 수단 정의

소비자용 서비스는 메일이나 SMS, 푸시(Push) 통지 등이 이용자와의 커뮤니케이션 수단으로 중요하다. 이 통지 등의 요건정의는 프런트 엔드 기능 요건정의와 업무 및 관리 기능 요건정의 각각에서 실시한다.

프런트 엔드 기능 요건정의에서는 이용자의 행동에 따라 발생하는 통지 요건을 정의한다. 업무 및 관리 기능 요건정의에서는 서비스 운영자의 의향에 따라 발생하는 통지 요건을 정의한다.

여기에서는 프런트 엔드 기능 요건에 대한 통지 등의 요건정의 진행 방식을 진단한다. 진행 방식은 화면 레이아웃 정의와 기본적으로 동일하다. 각 유스케이스 중에서 어느 타이밍에 어떠한 통지를 낼 것인가를 정의한다. 그 때 전달해야 할 정보를 레이아웃으로 정리한다. A사의 빵 추천 서비스에서는 매월 청구가 발생하는 서비스 때문에 본인 확인이 중요하다. 어카운트(Account) 등록 시에 휴대전화 번호를 입력하게 해 SMS를 보내 본인 확인을 할 필요가 있을지도 모른다.

월정액 서비스 신청이 완료됐을 때는 확인 메일을 송부하는 것도 필요하다. 매회 빵의 추천 내용이 확정되면 그 뜻을 푸시 통지로 알려주는 애플리케이션 사용을 유도하는 요건도 생각할 수 있다. 이용자에게 송부하는 SMS나 메일, 푸시 통지가 어떤 내용이 될지도 여기서 정의한다. 세세한 문구는 통합 테스트 등 테스트 공정 전까지 결정하면 문제없다.

이 단계에서 정해야 할 것은 데이터베이스 등에서 취득해 동적으로 출력하는 항목을 정의하는 것이다. 어떤 정보를 어디까지 받아 어떻게 가공해 어떤 순서로 몇 개를 표시해야 하는 지 등 이는 모두 백 엔드 요건에 영향을 줄 가능성이 있기 때문에 요건정의 단계에서 명확히해야 한다.

통지 대상자나 타이밍 등도 정의할 필요가 있다. 프런트 엔드 기능의 통지 요건의 경우 발송 대상자는 액션을 일으킨 사람, 발송 타이밍은 리얼타임(Real time)인 경우가 많다. 뿐만 아니라 '본인 확인용 SMS'를 보냈으나 발송되지 않았을 경우, 몇 회까지 재 발송할 것인가? 같은 세세한 발송 방법도 정의해야 한다.

또한, 이 후 업무 요건이나 관리 기능 요건에서는 '1개월간 로그인하고 있지 않은 사람에 대해 재 방문을 촉구하는 통지를 월초에 보낸다' '특정 지역만 캠페인 고지 통지를 설정한 타이밍에 발송한다' 등 전송 대상자나 타이밍을 제대로 정의할 필요가 생긴다.

■B2B 서비스는 양식도 필요

양식(Form) 및 파일 요건 진행 방식은 메일, SMS, 통지 요건정의와 기본적으로 동일하다. 서비스를 제공할 때 양식이나 다운로드 파일 등이 발생하는 경우 어떤 양식과 파일이 필요한지, 어떤 양식을 어떻게 생성할지 등을 정의해 간다. 양식이나 파일은 B2C 서비스의 이용자용 요건으로는 별로 눈에 띄지 않는다. 반면 B2B 서비스에서는 많은 경우 필요하다.

■어떤 OS나 브라우저를 동작 대상으로 할까?

이 서비스가 동작 대상으로 하는 OS나 웹(Web) 브라우저를 결정한다. 여기에서 결정한 OS나 웹 브라우저의 동작을 보증해준다. 스마트폰 애플리케이션의 경우 OS는 iOS나 안드로이드(Android)가 된다. '

버전 N.N이상'과 같이 구체적인 버전도 정의한다. 웹 브라우저를 통해 제공하는 애플리케이션의 경우, 윈도와 맥 iOS와 안드로이드 등 PC와 모바일 단말 각각의 OS를 버전과 함께 정한다. 웹 브라우저도 마찬가지로 인터넷 익스플로러N.N 이상, 크롬 최신판 등과 같이 정의한다.

이때 고려해야 할 것은 개발하려고 하고 있는 서비스 대상 이용자가 어떤 단말을 사용하고 있는 지다. 비교적 연배 있는 이용자도 대상으로 하면 윈도나 인터넷 익스플로러의 오래된 버전을 이용하고 있을 가능성도 있다. 젊은 층을 대상으로 한 서비스라면 대상 범위는 조금 더 좁혀도 좋을 것이다. 넓은 범위를 보증하면 테스트도 그 만큼 많이 실시할 필요가 있고 환경에 맞춘 사용자 인터페이스 수정 작업도 발생한다. 오래된 버전의 단말을 준비하는 데도 상당한 수고가 든다. 또 앞으로의 작업 인력(Man hour)에 적지 않은 영향을 미치는 요건이기도하다. OS나 브라우저의 세어(share) 조사 등도 참고로 하며 신중히 결정해야 한다.

■요건정의에서 펼친 '보자기'를 닫는다

프런트 엔드 기능 요건정의를 거쳐 A사의 서비스의 내용은 구상 단계와 달라졌다.

PM : 구상 단계에서 정의한 내용과 달라졌네요..

IT담당 : 그렇지요. 당초 예상했던 요구 중 몇 개를 삭감했습니다

PM : 이렇게 깎아도 괜찮나요?

컨설턴트 : 괜찮아요. 오히려 삭감해서 좋았다고 생각합니다.

구상 단계에서는 '보자기'를 펼치지만, 요건정의는 펼친 보자기를 접는 단계다. 특히 프런트 엔드의 기능 요건정의는 업무 및 관리 기능, 백 엔드 기능에 영향을 준다. 이 타이밍에서 인적 자원이나 스케줄을 생각한 현실적인 내용으로 해 갈 필요가 있다.

A사의 경우 구상 단계에서는 택배 할 빵을 선택할 때 '식사 빵' 등 메인이 되는 빵 만을 선택하도록 하고 있었다. 실제로는 추천 로직이 복잡해 진다는 이유와 결국, 전부 스스로 선택하고 싶은 사람이 있다는 가정 하에 '스스로 선택' 이라는 플랜으로 변경됐다. 이와 같이 구상 단계에서 정한 것이 요건정의에서 뒤집히는 경우가 드물지 않다. 이 부분이 워터폴 형으로, 확실히(Firmly) 요건을 확정(Freezing)해 가고 기본적으로 재작업을 할 수 없도록 하는 기간계 시스템 프로젝트와 다르다.

또, B2C 서비스의 경우 기능을 많이 넣는 것 보다 심플하게 하는 것이 이용자가 사용하기 쉬운 측면이 있다. 서비스 개발자는 '이것도 저것도 하고 싶다, 만들고 싶다'고 하기 쉽지만, 그것이 잘 된다고는 할 수 없다. 이용자의 시선도 비교적 가지고 있는 프런트 엔드의 개발 회사나 제작 회사의 의견을 잘 들으면서 요건을 좁혀가면 좋다.

이번 회는 프런트 엔드 기능요건 작업 프로세스에 대해 알아보았다. 다음 회는 업무 및 관리 기능 요건의 작업 프로세스에 대해 알아본다.

*참고문헌

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

■필자 심기보는...

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

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