"AI프로젝트시 데이터 요건 항상 경신해야"

[심기보의 AI프로젝트 성공 비결⑪] 요건 정의-백엔드 기능

(지디넷코리아=심기보 전 정보통신기술사협회장)백 엔드(Back End) 기능 요건정의는 서버에 필요한 기능을 결정하는 것이다. 프런트 엔드(Front End) 기능이나 관리 기능 요건정의에서 정한 API는 이 프로세스에서 정리해 통합한다. 시스템으로 보유할 데이터를 정리한 데이터 요건은 항상 업데이트해 기능 간 일관성을 유지해야 한다. 새 서비스를 백업하는 백 엔드 기능 요건정의 작업을 구체적으로 보면 그림1과 같다.

B씨:프런트 엔드와 업무 및 관리 기능, AI와 요건정의는 상상 이상으로 대단하네요…

C씨:수고하셨습니다. 여러가지를 상상하면서 진행해야 하니 머리를 사용하게 되네요.

A씨:백 엔드 기능 요건정의는 무엇을 하는 걸까요?

B씨:프런트 엔드 기능이나 업무 및 관리 기능에서는 처리 요건까지 확실히 정의했어요. 그것과 같지 않을까요?

지금까지 프런트 엔드 기능이나 업무 요건 및 관리 기능 요건, AI 기능 요건과 시스템의 근간에 관한 부분의 요건정의를 해 왔다. 백 엔드 기능 요건은 이들 요건을 받아 백엔드(Back End), 즉 서버에서 필요한 기능을 정의하는 작업이다.

서버 사이드 기능의 구현 기술이나 구현 방법은 여러 종류가 있다. 여기서는 스마트폰 애플리케이션이나 웹(Web) 애플리케이션에서 채용하는 경우가 많은 웹API(application Programming Interface)를 이용하는 것을 전제로 설명한다. 웹API란 인터넷을 통해 소프트웨어 기능을 호출하기 위한 기술이다. 구현 기술이나 구현 방법이 달라도 요건정의에서 해야 할 작업은 같다. 서버(Back End) 기능 요건정의에서 주로 실시하는 것은 표1과 같다.

■API를 정밀 조사해 통폐합

프런트 엔드 기능 요건이나 관리 기능 요건정의 중 각 기능에서 이용하려는 API는 그림3처럼 정리돼 있다.

API 기능 요건정의는 이미 파악한 API를 정밀하게 조사해 통폐합하면서 API 목록을 정리한다. 만약 이 단계에서 아직 API를 정리하지 않았으면 그 정리 작업부터 시작한다. 또, 프런트 엔드 기능이나 관리 기능의 요건정의에서 API를 정리할 때 그림3과 같이 각 기능의 처리 요건도 기재했다. 이들은 프런트 엔드에 한정한 것이 아니라 서버 사이드도 포함한 처리 요건으로 되어 있다. 이 때문에 백 엔드 기능 요건정의에서 다시 각 기능의 처리 요건을 정리하면 프런트 엔드나 관리 기능 요건에서 기재한 요건 내용과 중복된다. 그러므로 API 기능 요건정의에서는 기본적으로 처리 요건까지 기재할 필요가 없다. 검토 과정에서 프런트 엔드 기능이나 관리 기능에서 언급하지 않은 처리 요건이 있는 경우에만 거기에 대한 처리 요건을 기재하면 된다. 예를 들면 백 엔드 처리에 관한 공통 기능을 API로 잘라낸 경우다.

■뿔뿔이 흩어진 API 정리

프런트 엔드 기능이나 관리 기능은 화면 별로 이용하는 API를 정리했기 때문에 내용이 불규칙해지기 쉽다. API 명칭에 표기가 혼돈이 있거나 처리하는 정보 단위로 API를 정의하고 있는지 살펴봐야 한다. 또  취득 및 등록의 처리 단위라고 하는 차이가 발생하기도 한다.

물론 처음부터 룰(Rule)을 정해 정리하면 좋지만, 프런트 엔드 기능이나 관리 기능 요건은 리뷰할 때마다 내용이 변경될 가능성이 있으므로 항상 API 명칭의 일관성을 취하는 것은 매우 어려운 일이다. 이러한 흩어진 API를 정리하는 것이 여기서의 작업이다. 예를 들면 'REST'라 불리는 소프트웨어의 설계 방법을 따르면, API 단위는 엔티티(데이터의 그룹) 단위가 된다. 그러므로 그림5와 같이 정리할 수 있다. 이와 같이 API의 종류를 결정한다.

여기서 API 종류가 어느 정도의 정확도로 밝혀지면, 설계 공정 이후의 견적 정확도가 높아진다. 화면의 수로 대체적인 규모는 알 수 있을 거라 생각할 지도 모르지만, Web 시스템 개발 현장에서는 서버 사이드 엔지니어와 프런트 엔드 엔지니어가 다른 경우가 많기 때문에 각각이 만드는 기능의 수를 명확히 하는 것이 포인트다. 그 방법이 개발 벤더도 준비를 진행하기 쉽고 인력(Man/Hour)이나 코스트의 견적 정확도도 높아질 수 있다. 또한, 여기에서 API를 통폐합했으므로 다시 화면과 API 대응표를 정리해 두면 좋을 것이다. 개발이나 테스트의 관리상 이 표가 있으면 편리한다.

■사내외 시스템과 연계 생각해야

관련 시스템 인터페이스 요건정의에서는 연계되는 관련 시스템과의 인터페이스 내용을 정리한다. 관련 시스템은 사내 시스템과 사외 시스템으로 크게 2개로 나눠 생각할 수 있다. 우선 사내 시스템에 대해 A사의 케이스로 생각해 보자. AI의 인풋이 되는 데이터로 POS 데이터가 있다. POS 데이터는 사내의 다른 시스템에서 관리되고 있으므로 여기에서 데이터를 꺼낼 필요가 있다. 데이터의 취득을 취득하는 타이밍(월 1회, 주 1회 등)이나 취득하는 내용(데이터의 종류나 항목) 등을 인터페이스 요건으로 정의한다. 기존의 고객관계관리(CRM) 시스템 등이 존재하는 경우는 이번에 개발하는 시스템에서 신규 취득한 회원 데이터를 등록할 필요가 있을지도 모른다. 이 경우 시스템으로부터 CRM 시스템으로 데이터를 넘겨주게 된다.

사내의 기간계(Core) 시스템에 데이터를 등록한다는 것은 이 시스템을 운용, 보수하고 있는 부서나 IT 벤더에게 적지 않은 영향을 미친다. 외부 시스템에서 데이터 등록이 있으면 그것을 출력하는 기능이 필요하게 될지 모르고, 그 작업을 보수 담당자가 실시할지도 모른다. 어쨌든 보수 담당자가 하면 부담 없이 대응할 수 있을 종류의 것은 아니다.

그러므로 사내 시스템과의 인터페이스가 있으면 요건정의의 타이밍에서 ▲어떤 시스템에 대해 ▲언제 ▲어떤 데이터를 어느 정도 건수로 ▲취득할까, 등록할까 등을  확실히 정의해 둘 필요가 있다.

■무엇을 하고 싶은 지 설명하고 협력 체제 구축해야

사외 시스템은 A사의 경우, 결제 수단으로 크레디트카드 지불도 취급하는 경우는 크레디트카드의 수납 대행 회사의 시스템과 접속하게 된다. 수납 대행업자가 제공하고 있는 카드 유효성을 확인하는 API나 'Authority'라 불리는 결제 처리 등의 API 등을 이용하게 된다. 그러한 시스템의 프런트 엔드를 호출하는 경우도 있을지도 모른다. 이들에 대해서도 인터페이스 요건으로서 빠짐없이 정의해 놓는다.

사내외를 불문하고 중요한 것은 연계할 가능성이 있는 시스템이나 시스템을 망라적으로 목록화 하는 것이다. 그리고 각각에 필요한 인터페이스 종류를 정리한다. AI 프로젝트는 프로젝트 내부의 커뮤니케이션도 중요하지만 사내의 타부서나 협력업체 등 외부와의 커뮤니케이션도 중요하다. 외부 멤버는 프로젝트 내부와 온도차가 있는 것이 일반적이기 때문에 무엇을 하고 싶은 지 자세히 설명해 협력 체제를 구축한다.

■필요한 배치 기능 파악해야

이어서 배치 기능 요건정의에 대해 설명한다. 프런트 엔드 기능이나 업무 요건 및 관리 기능 요건, 인터페이스 요건, AI기능 요건 등을 실현하기 위해 어떠한 배치(Batch) 기능이 필요한지를 정의한다. 예를 들면, POS 데이터를 사내의 POS 시스템에서 정기적으로 취득한다고 하는 인터페이스 요건이 있는 경우, 데이터를 취득해 시스템의 데이터베이스에 일괄 등록하는 배치 기능이 필요하다. 추천하는 빵의 작성이 월 1회 있다면 각각의 타이밍에서 빵 추천을 작성하는 처리나 작성 후에 메일이나 푸시 통지 등으로 알리는 정기 처리도 실시해야 한다.

이와 같이 시스템 전체를 통해 필요한 배치 기능을 알아낸다. 그리고 배치 기능별로 입력 데이터나 출력 데이터의 파일 및 테이블 등을 정의한다. 처리 내용에 대해서는 개요 레벨에서 기재한다. 배치의 실행 순서나 의존 관계의 정리(Job설계), 배치 처리 설계는 설계 단계에서 한다.

■데이터 요건 항상 업데이트해야

마지막으로 데이터 요건정의 작업에 대해 설명한다. 이번에 개발하는 시스템에서 보유할 데이터를 정리하는 작업이다. 데이터 요건은 프런트 엔드 기능 요건, 업무 요건 및 관리 기능 요건, 서버 기능 요건, AI 기능 요건 등을 거치지 않으면 최종적으로 확정되지 않는다. 그렇다고 해서 마지막에 정리하면 된다는 것이 아니라 각각의 요건정의와 병행해 정리 및 업데이트 해 간다.

데이터는 시스템의 모든 기능의 중심에 있다. 그러므로 항상 데이터 요건을 업데이트해 기능 간 요건의 일관성을 취할 수 있도록 해 둬야 한다. 데이터 요건정의는 프런트 엔드 기능, 관리 기능, 서버 기능 요건에서 취급하는 데이터의 종류를 알아내 데이터 목록(또는 테이블 목록)으로 정리한다. 목록화 후에 데이터를 보유할 장소도 검토한다. 스마트폰 애플리케이션의 경우는 유저의 단말(Front End) 측에서 데이터를 보유할지, 서버 사이드 데이터베이스에 둘 지 혹은 보유할 지 등을 임시라도 좋으니 일단 정리해 둬야 한다.

프런트 엔드와 서버 어느 쪽에 보유할지를 최종적으로 결정하는 것은 설계 공정이 된다. 이 단계에서 이른바 ER(엔티티 관련도)도 그림6처럼 만들어 두는 것이 좋다. 데이터 목록만으로는 데이터 관계성을 알기 어려우므로 ER도로 시각적으로 알기 쉽게 정리한다.

■필자 심기보는...

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

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

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

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