"AI시스템 구현 단계서는 불확실성 제거가 중요"

[심기보의 AI프로젝트 성공 비결⑭] 구현

(지디넷코리아=심기보 전 정보통신기술사협회장)이번호는 AI 시스템 개발의 설계 단계 다음단계서 행하는 구현(Implementation)에 대해 알아본다. 구현단계는 개념증명(PoC)에서 개발한 모델을 정리해 주변기능도 구현한다.

AI시스템은 기계학습 모델을 조합한 시스템이다. 통상의 시스템 개발 프로세스와 다른 점은 극히 일부다. 다만 모델 개발은 유의해야 한다. 워터폴(Waterfall)형의 개발 프로세스를 채택하고 있는 경우, 프로그램 설계부터 단위 테스트 단계에서 변화가 발생한다. 워터폴 형은 설계를 시작으로 진행하고, 이후 요건정의 및 설계 단계에서 구현해야 할 기능을 자세히 조사해 구현하고, 테스트 단계에서 설계대로 구현되고 있는 지를 검증하는 작업이 한꺼번에 이뤄지는 프로세스다.

이에 비해 AI시스템의 경우 설계단계에서는 완전히 파악할 수 없는 불확실성이 내재되어 있다. 기계학습 모델의 내부가 블랙박스이기 때문이다. 그래서 구현단계에서는 이러한 불확실성을 제거하기 위해 유의해야 한다.  불확실성을 제거하기 위해 프로그램 설계부터 단위 테스트까지의 프로세스에서는 워터폴형이 아니라 보다 반복적인 개발 프로세스를 채용할 필요가 있다. 반복적인 프로세스를 포함한 프로젝트의 진행방식을 바탕으로 구현 단계를 진행해 간다.

■모델과 부수(Attaching) 기능 분리

AI 시스템을 구현할 때 시스템 핵심인 모델을 개발하는 것을 생각하는 사람이 많을지 모른다. 그러나 AI 시스템에 있어 구현 대상은 모델만이 아니다. 모델을 적용하기 위한 시스템 전체가 대상이다. 따라서 우선 중요한 작업은 모델과 그 모델을 성립(Establish)시키기 위해 부수(Attaching)되는 기능을 분리하는 것이다.

AI 시스템은 모델이 중요하다. PoC에서 구축한 모델을 실제 구현할 필요가 있다. 구현 단계서는 PoC에서 예측하지 못한 경우 대응할 수 있는 모델 확충이나, 신규 데이터에 대한 정확도(Accuracy)를 향상시키는 작업이 필요하다.

모델에 부수되는 처리도 많이 있다. 데이터 전(Pre)처리, 업무 시스템의 모델 호출, 모델 추론(Inference) 결과 연계, 학습용 파라미터, 후속 검토에 활용하기 위한 모델 보존 등이다. 그러나, 이러한 처리를 실행하기 위한 구성 요소 역할이 PoC 시점에서 반드시 명확한 것은 아니다. PoC에서 작성한 알고리즘 코드는 시행착오를 거쳐 작성한 것이다. AI 시스템의 역할에 대한 기술(Description)이 명확하지 않고 또 전(Pre)처리, 테스트 코드까지 혼합해 적혀 있는 경우가 있다. 특히 추론은 모델 파일만이 아니라 입출력에서 데이터를 변환하기 위한 사전 등의 정적(Static) 파일도 배치해야 한다. 즉, 구현 단계는 PoC 시점 코드부터 모델에 부수적 처리의 역할을 정리 및 구별해 구현할 필요가 있다. 이 정리는 후속 단계인 테스트 단계서도 유용하다. 이제 각각의 구현에 있어 중요한 점을 알아보자.

■모델 구현

알고리즘이 기재된 모델 코드를 학습 기반에 구현해 모델을 전개(deploy)한다. 앞에서 설명한 것과 같이 PoC를 거쳐 생성한 코드는 시행착오를 거듭해 생성한 것으로 코드의 최적화가 불가결하다. AI 시스템은 모델 내 모듈별로 분할해 각각의 책임 범위를 명확히 하면서 구현해야 한다. 안정적으로 가동시키기 위해 모델 내부 구조를 파악하면서 코드를 정리해야 한다. 예를 들면 모델 내의 전(Pre) 처리용 처리 모듈과 학습 모듈을 가능한 한 분리해 독립된 모듈로 두는 것이 핵심이다. 전(Pre) 처리용의 처리 모듈은 학습만이 아니라 추론을 실행할 때에도 필요하기 때문이다. 또 문제가 발생한 경우 모델과 데이터 어느 쪽에 원인이 있는지를 파악하기 쉬워진다.

코드 최적화만이 아니라 장래를 예측한 아키텍처(Architecture)도 구축한다. 장래 대응이 필요한 경우로서는 용도에 맞는 모델의 교체나 부분적인 프레임워크의 버전업 등을 생각할 수 있다. 계속적인 AI 시스템 도입으로 1개 모델을 복수의 애플리케이션에서 공유하는 케이스도 생각할 수 있다. 이러한 경우에는 AI시스템을 이용하는 프레임워크의 환경 의존성이나 비 기능 요건의 설정 등 대응해야 할 과제가 많이 존재한다. 특히, 과제가 되는 것은 조건이 다른 환경에서의 모델 병행 이용이다. 병행 이용은 새로운 AI시스템을 도입할 때마다 기반을 구축할 수 있게 되지만 코스트 면에서 곤란하다. 그래서 모델 구현에서는 컨테이너 가상화(Virtualization) 기술인 도커(Docker) 등을 이용하는 것을 추천한다. 컨테이너를 이용함으로써 각 모델이 독립적인 소프트웨어 스택(software stack)이 되어 각각에 대해 실행 환경, 비 기능 요건을 설정할 수 있다. 또한 애플리케이션 측에 변경이 있는 경우 그림3처럼 컨테이너를 바꾸어 만드는 방법으로 대응할 수 있다.

컨테이너에 의한 가상화(Virtualization)는 장점이 많은 반면 복수의 컨테이너를 관리해야 하는 과제도 있다. 클라우드(Cloud) 환경에서 이용하는 경우에는 컨테이너관리 및 오케스트레이션 툴(orchestration tool)인 '도커 컴포즈(Docker Compose)나 쿠버네티스(Kubernetes) 등을 사용함으로써 해결할 수 있다.

■데이터 플로우 구현

PoC에서 작성한 데이터 플로우를 본 가동 데이터로도 재현할 수 있게 구현한다. 이 때 중요한 것은 본 가동 데이터 취득이나 데이터 가공을 자동화할 수 있다는 것이다. 데이터 플로우는 학습, 추론(Inference)에서 모두 필요하며 사람이 수작업으로 하는 대응은 현실적이지 않다. 다른 부서에서 데이터를 받아(Receipt) PoC를 실시하는 경우 등에는 그림4처럼 데이터 접수(Receipt) 플로우까지 포함해자동화한다

또한, 데이터 플로우를 실시할 때에는 트랜잭션(transaction) 양에 따른 처리 성능을 확보할 필요가 있다. 이미지, 비디오와 같이 유지보수에 대량의 리소스를 필요로 하는 데이터는 충분한 처리 성능을 확보하도록 주의한다.

■모델에 부수되는 시스템 구현

모델과 데이터 플로우 이외의 시스템 구현은 AI 시스템 개발에 적합한 서포트 툴이나 서비스가 제공되어 있다. 특히 데이터 셋의 버전 관리나 모델 관리 등에 관한 툴은 수없이 많이 있다. 모델을 관리하기 위한 서비스의 경우에는 아마존 웹 서비스(AWS)의 '아마존 세이지메이커(Amazon SageMaker)'나 오픈소스 소프트웨어의 'CometML'이라고 하는 툴이 있다, 최근에는 작성한 모델의 추론 결과까지 계속적으로 모니터링할 수 있는 툴도 제공되고 있다. 이들 툴을 이용해 표1처럼 운용의 사이클을 확인해 가는 것이 중요하다.

■모델 정확도 검증 및 수정

구현 단계에서는 시스템 구현만이 아니라 모델 검증, 정확도(Accuracy) 향상을 목적으로 한 모델의 수정에 대응한다. 우선은 PoC 시점에서의 알고리즘에 대해 새로운 데이터로 모델 정확도를 확인한다. 이때, 최신의 본 가동 데이터는 어떤 경향이 있는지 불명확하므로 정확도 검증에는 적합하지 않다. 이 때문에 베이스라인이 되는 데이터 셋(Data set)을 별도 작성해 검증하는 것이 좋다. 정확도 검증을 위한 지표도 주의가 필요하다. 먼저 PoC 시점에서 설정한 알고리즘 고유의 정확도 지표를 확인한다. 그 다음 업무 시스템과의 접속을 예상해 고유의 중요평가지표(KPI)를 사용해 검증한다. KPI는 모델 정확도만이 아니라 지연(latency) 등의 비 기능 요건까지 포함해 설정한다. 구현 후의 상황을 예측해 KPI를 설계하고 그것을 이용해여 검증하면 재작업을 피할 수 있다. 예측한 정확도가 나오지 않은 경우에는 모델을 수정한다. 모델을 수정할 때에는 입력 데이터, 알고리즘, 학습 시에 설정한 모델의 하이퍼 파라미터의 어디를 변경할지는 그림5처럼 인력(Man-Hour)을 고려해 결정한다.

우선 대응 인력(Man-Hour)이나 코스트를 억제할 수 있는 하이퍼(Hyper) 파라미터의 변경부터 착수한다. 하이퍼 파라미터 변경으로 정확도가 개선되지 않으면 알고리즘 변경으로 대응한다. 그래도 개선되지 않는 경우에는 입력 데이터 변경도 검토한다. 입력 데이터를 변경하는 경우에는 데이터 플로우의 구현을 재검토할 필요가 있다는 점을 고려해야 한다.

*출전 : NIKKEI systemS 2019.2

■필자 심기보는...

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

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

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

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