brunch

라이킷 16 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 호영 May 04. 2023

당신의 AI 프로젝트가 계획대로 끝나지 않는 이유

Task들을 확률적으로 구성하고 이를 수행하기

저는 AI 프로젝트를 수행하면서 "최초에 설정한 종료일"에 "마무리"한 적이 없습니다.

제가 맡은 R&R(Role and Responsibilities)을 전부 수행했지만 다른 부분에서 일이 터져 프로젝트가 조금 연장되는 경우도 있었고, 반대로 저의 R&R을 달성하지 못하여 기간이 연장된 적이 있습니다. 왜 항상 기간 내에 본인을 포함한 팀원, 조직이 AI 프로젝트가 계획 내에 달성하지 못하는 것일까요?

https://m.blog.naver.com/artplay2020/222193677815

아마 독자분 중에 초등학생 방학 숙제로 (지켜지지 않았던) 방학 계획표를 구성했던 경험이 있을 것입니다. 마찬가지로 프로젝트를 수행하기 전에 공수산정을 또는 WBS(Work Breakdown Structure, 작업 분할 구조도)를 구성하게 됩니다. 아래와 같은 6개월짜리 작은 프로젝트와 같은 경우에는 WBS 샘플은 아래와 같습니다.

보안을 위해 모자이크 처리를 하였습니다. WBS 검색하면 다양한 형태로 보실 수 있습니다.

만약 글로벌 컨설팅 업체와 수많은 회사들이 컨소시엄으로 참가하는 프로젝트의 WBS의 내용 분량은 어마무시할 것입니다. WBS는 보통 Project Manager 또는 Project Leader가 작성을 혼자 할 때도 있고 Task를 수행하는 인력들과 함께 작성합니다. 근데 WBS를 작성하면서도 드는 생각은 "이게 정말로 제대로 지켜질까?", "이 기간 내에 못하면 어쩌지?"등 막연한 걱정이 항상 있었습니다.

WBS와 같이 계획이라는 것을 왜 구성할까요? 그것에 대한 본질, 필요성을 나름대로 서술해 보았습니다.

- 계획을 수립하고 이를 통제함으로써 명확한 책임 부여를 하기 위함
- 고객과의 의사소통 기준이 될 수 있음
- Task 내의 수행할 요소들에 대해 MECE(Mutually Exclusive Collectively Exhaustiv) 기법을 적용, Risk 요소를 식별하기 위함

정도 될 것 같습니다.

하지만 제가 글의 제목에 명시했듯이 그냥 '프로젝트'가 아닌 'AI 프로젝트'입니다. 일반 소프트웨어 개발 방식은 1) 코드를 구현하고 → 2) Build → 3) 배포 와 같이 단방향(Uni-directional)으로 진행되었습니다. SW 개발 방식과 AI 프로젝트의 공통점 부분은 1) 버전 관리, 2) 테스트 자동화, 3) 모니터링 정도 있겠습니다.

하지만 이 두 프로젝트 유형에서 가장 큰 차이점은 'Data'라는 놈을 만나야 하고 이때 많은 허들이 생기기 시작합니다. 내가 구현하고 싶어 하는 요리(모델)가 있는데, 원활한 재료(데이터) 수급이 안되거나 정제(요리 손질)가 되질 않는다면 다음 단계로 넘어가지 못한다는 뜻입니다.

피지컬갤러리 - 우마게임 4화에 나오는 괴식. 당신의 프로젝트 결과가 괴식이라면?

뿐만 아니라 줘도 먹지 않을 괴식 요리(모델의 성능이 만족하지 않거나 요구사항에 어긋나는 Output)가 탄생한다면 요리 재료(데이터 이슈)가 상했는지, 손질법(데이터 전처리 방식이나 엔지니어링 방식)이 잘못되었는지, 요리 방법(모델 알고리즘이 또는 튜닝)이 잘못되었는지 아니면 태초 마을로 돌아가서 메뉴 선정(문제정의)부터 잘잘못을 찾아야 하는 문제가 있습니다.

그래서 해결법은 AI 프로젝트에서 만큼은 다음과 같이 수행하도록 제시하고자 합니다.

프로젝트 수행 접근 방식을 확률적(probabilistically)으로 수행하기

본인이 근무하는 부서 또는 조직에 AI를 적용하고자 하는 많은 비 AI 회사 사람들을 기준으로 했을 때, 훌륭한 기술 조직이 있음에도 많은 리더 또는 조직이 이해하기 어려워하는 것이 AI입니다. 그래서 AI 프로젝트를 좋은 방향으로 관리하기 위해 확률적으로 수행하자는 것인데 아래 그림을 한번 보겠습니다.

이 그림은 위에서 WBS 언급한 것과 같이 우리가 일반적으로 생각하는 방식입니다. 주차별로 단방향성으로 Task F가 C, E에 종속되어 있고 Task C는 A, B에 Task E는 D에 종속되어 있습니다. 하지만 AI 프로젝트 입장에서 이런 방식은 하나의 Task에서 실패를 한다면 전체 프로젝트가 리스크에 노출될 수 있습니다. (가뜩이나 일반적인 SW 프로젝트보다 실패할 확률이 매우 높습니다.)

확률 값은 그냥 임의로 준 것임 (合이 1이어야 하는 것을 일단 무시)

그리하여 특정 작업이 일정 시간이 걸린다고 가정을 하는 것보다 위 그림처럼 1) 각각의 작업을 완료할 수 있는 가능성을 허용하고 2) 종속성에서 벗어날 수 있게 3) 잠재적으로 대안 Task를 추구할 수 있는 확률을 부여하자는 것입니다. Task B, C가 모두 Task D를 수행하기 위한 대안을 구성하자는 것입니다.

이를 병렬적으로 수행하다가 만약 Task C 방법이 이슈가 생기거나, 동작하지 않는다면 B를 기준으로 융통성 있게 작업을 수행하자는 뜻입니다. 즉, 예상보다 오래 걸린다는 것을 알게 되면 타임라인을 적절히 조정하면서 접근하자는 것입니다. 그렇다고 모든 작업을 병렬로 해야 하는 것은 절대 아니며, 어려운 Task 한정하여 확률적으로 구성할 부분에 대해서 이런 방식을 도입하자는 뜻입니다.

마무리를 하자면 AI는 Data를 바탕으로 Science를 하는 경향이 상당히 강한 분야라고 저는 생각합니다. 그래서 각 과정 안에서 실험이라는 요소가 필연적이라 실패할 확률이 상당히 높습니다. 따라서 "이 문제를 이렇게 해결할 거야"라는 방식보다는 "이 문제 해결을 위해 다양한 접근 방식을 열어 두고 시도할 거야"가 옳게 된 방법입니다.

아마 이 글을 읽는 AI 개발하시는 분들은 공감이 될 수 있습니다. 또한 AI를 도입하고자 하시는 조직의 관리자 또는 리더급 분들도 외주 또는 AI 개발하는 사람들이 요구 사항을 달성하기 위해 이런 과정이 있다는 것을 이해하면 좋겠습니다. 성공한 프로젝트이냐 아니냐도 중요하지만, 과정 중에 얼마나 잘 실행이 되었는지도 중요하다는 것입니다.

긴 글 읽어주셔서 감사합니다 :)

keyword