Applying agile to AI projects
AI 프로젝트는 복잡성과 불확실성 때문에 전통적인 프로젝트 관리방식으로는 효과적으로 관리하기 어려울 수 있다. 이에 따라, Agile철학을 적용하여 빠르게 변화하는 기술에 유연하게 대응하고, 지속적인 학습과 개선을 통해 최적의 결과를 도출하는 방법이 필요하다. 하지만 AI project는 기존 software project의 사촌격이지만 software project를 운영하는 접근 방식을 그대로 Ai 프로젝트에 적용하면 Agile 구현에 실패한다. 다음은 datascience 사이트(https://www.datascience-pm.com/agile-ai/)에서 소개하는 7가지 Agile 모범사례를 통해 Ai 프로젝트의 context에서 어떻게 Agile 개발 방법론을 사용할것인지 알아볼것이다.
필요성
AI를 위한 애자일 방식을 채택하는 이유는 실패를 빠르게 경험하고 이를 통해 배우는 데 있다. 많은 기업과 데이터 과학자들이 예측 기능을 추가하는 것이 단기간 내 성공해야만 가치가 있다고 믿지만, 이는 비현실적이다. 반복적 접근 방식이 가설을 세우고 이론을 검증하는 과학적 방법에 뿌리를 두고 있기 때문이다. 모든 이론이나 예측이 참으로 입증되는 것은 아니다.
첫째, 올바른 비즈니스 문제에 집중해야 한다. AI 솔루션이 비즈니스에 중대한 변화를 가져올 수 있는 비즈니스 케이스를 식별하는 것은 어렵다. 데이터를 수집, 정리 및 저장하는 비용이 모델 해결에 드는 비용보다 더 클 수 있다.
둘째, 일부 사용 사례에서는 기존 데이터가 모델링 노력을 위한 필수적인 신호를 담고 있지 않을 수 있다. 무엇보다 중요한 것은 가능한 많은 행동을 빠르게 모델링해 보려는 노력이다. 기업 리더들은 다양한 가설을 세우고 팀이 각 모델링 실험을 시도할 수 있도록 해야 한다.
예를 들어, 캐나다의 대형 자동차 부품 제조업체인 Spectra Premium 프로젝트에서는 초기 모델링 시도가 실망스러웠지만, 데이터를 더 깊이 파고들어 다른 접근 방식을 시도한 결과 전반적인 정확도를 90% 이상으로 끌어올릴 수 있었다.
데이터 과학 팀은 소프트웨어 엔지니어링 팀과 달리 모델링 결과에 대해 보장할 수 없다. 데이터 과학 연습은 모두 가설로 시작되며 때로는 귀무 가설을 기각할 수 없는 경우도 있다.
팀이 실험을 통해 빠르게 반복하고 가설을 테스트할수록 AI가 기업에 제공할 수 있는 놀라운 결과를 얻을 가능성이 더 높아진다. AI 프로젝트의 성공에 있어 유연성과 변화에 대한 의지가 중요한 역할을 한다.
1. Agile의 foundational principle에 충실하기
Agile은 정해진 프로세스를 고수하는 것이 아니다. 오히려 팀이 스스로 관리하고, 학습하고, 적응하고, 기여할 수 있도록 지원하는 철학이다. 팀원 모두는 먼저 팀이 지향하는 principle을 숙지하고 있어야한다. Agile Manifesto와 같이 4가지 초기 선언문과 12가지 원칙이 있으며, 이는 AI project에 Agile철학을 담을 수 있는 시작점이 된다.
2. Agile로 만들어진 framework들을 layering 하기
많은 팀들이 애자일 프레임워크를 도입하려고 하지만, 그 본질이나 중요성을 충분히 이해하지 못한 채로 시작한다. 이는 주로 소프트웨어 개발 방식을 인공지능 프로젝트에 적용하려는 팀들에서 흔히 볼 수 있는 문제이다.
단순히 "애자일을 실행하기 위해서" 애자일 프레임워크를 적용하는 것이 아니라, 애자일의 기본 원칙들을 이해하고 그에 기반하여 프레임워크를 선택하거나 만들어야 한다. Scrum, kanban, Data Driven Scrum, 또는 팀의 특성에 맞는 맞춤형 프레임워크 등 다양한 옵션이 있다. 하지만 이 중 어느 것을 선택하든, 단순히 프레임워크를 적용한다고 해서 애자일이 되는 것이 아니다. 오히려 이러한 접근법들을 애자일로의 여정을 돕는 수단으로 생각해야 하므로 AI project의 성격, 팀의 성향, 팀원들의 성격들을 파악해서 팀의 가장 최적화된 Agile 프레임워크를 맞춰 나아가야한다.
3. 타부서간의 협업
각 AI 프로젝트는 여러 분야에 걸쳐 있다. 애자일을 효과적으로 구현하려면 기술 및 비즈니스 상황을 종합적으로 이해할 수 있는 다양한 구성원들로 구성된 AI 팀을 구성해야한다. 자세한 내용은 데이터 과학 역할 가이드를 참조하세요.
4. 최소 실행 가능한 AI(MVAI) 구축하기
복잡성을 줄이고, 개발 속도를 높이며, 프로젝트 초기 단계에서 배움을 극대화하기 위해, 팀은 가능한 한 빠르게 축소된 규모이지만 가치가 있는 AI 솔루션을 제공하려 노력해야 한다. 이를 세부적으로 나누면, MVAI(데이터 과학의 최소 실행 가능한 제품, MVP라고도 함)는 다음과 같다:
- Minimal - 팀이 솔루션을 신속하게 제공할 수 있게 한다.
- Valuable - 이해관계자가 핵심 요구 사항을 해결할 수 있게 한다.
- Artificial Intelligence - 인간의 지능을 모방한다.
5. 점진적으로 모델 개선하기
처음 만든 모델이 완벽하지 않을 수도 있다. 대부분의 상황에서 이는 문제가 되지 않는다. "가능한 최고의 모델"을 만들려고 하면, 무언가를 제공하기까지 너무 많은 시간이 소요될 수 있다. 대신, 기본 솔루션부터 시작해 지속적으로 개선하는 Agile 원칙을 따라야한다.
창의적으로 생각해야한다. 일부 팀은 기본적인 ML 모델을 제공한다. 다른 팀은 heuristic (business rules) 솔루션으로 시작한다. 또 다른 팀은 배후에서 답을 제공하는 사람(the Wizard of Oz approach)으로 시작할 수도 있다. 이 초기 솔루션을 배포하고, 실제 데이터를 수집하며, 사용자 상호작용을 기반으로 접근 방식을 개선해야한다. 이러한 접근 방식은 시간이 지나면서 더욱 정확하고 효과적인 AI 구현으로 발전한다.
6. 진행 상황 측정
Agile AI는 과정이면서도 여정이다. Performance를 효과적으로 측정하지 않으면 이 여정의 어느 지점에 있는지 파악하기 어렵다. 여기에는 recall, precision, 또는 RSME와 같은 Data scientist가 건너뛰기 쉬운 많은 모델 성능 metric이 포함되지만, 비즈니스 KPI, 이해관계자 및 팀의 행복도, 주기 시간과 같은 프로세스 metric도 중요하게 살펴봐야 한다. 다양한 데이터 과학 프로젝트 metric을 사용하면 프로젝트의 현재 위치와 진행 상황을 더 깊이 이해할 수 있다.
7. 빠르고 효과적인 학습
학습은 Agile, 인공 지능 및 전문적인 개발을 관통하는 기본적인 요소다. 특히 Agile은 팀이 빠르게 학습하고 대응할 수 있도록 돕는 관행을 중심으로 한다. 마찬가지로 인공 지능은 경험을 통해 학습하는 컴퓨터 시스템(머신 러닝)을 기반으로 구축된다. 이러한 영역에서 효과적인 실무자가 되려면 마찬가지로 학습에 집중해야 한다. 다음은 Agile을 적용할 수 있는 리소스들이다.
- Scrum in AI - Paolo Sammicheli의 이 책은 이 게시물에서 탐구하는 많은 개념을 다루며 특히 AI 이니셔티브에서 스크럼의 사용을 강조한다.(https://www.scrum-ai.com/)
- Agile AI - 이 오라일리의 책은 AI 팀이 민첩성을 향상시키는 데 사용하는 프로세스와 도구를 다룬다.(https://www.oreilly.com/library/view/agile-ai/9781492074984/ch01.html)
sillicon valley의 Agile 사례 - Apple
애플은 소프트웨어 개발 프로젝트에 스크럼이라는 애자일 소프트웨어 개발 방법론을 주로 사용한다. 스크럼은 반복적이고 점진적인 개발에 중점을 두고 협업, 유연성, 고품질 소프트웨어 제공을 강조하는 인기 있는 애자일 프레임워크다. 스크럼에는 다음과 같은 핵심 요소가 포함된다:
1. 교차 기능 팀: 애플은 개발자, 디자이너, 테스터 및 기타 필요한 역할로 구성된 교차 기능 팀을 구성하여 소프트웨어 프로젝트에서 공동으로 작업한다.
2. 스프린트: 개발 작업은 스프린트라고 하는 시간 제한 반복으로 나뉘며, 일반적으로 1~4주 동안 진행된다. 각 스프린트는 잠재적으로 배송 가능한 제품 증분을 제공하는 데 중점을 둔다.
3. 제품 백로그: 제품 백로그에는 우선순위가 지정된 기능, 개선 사항 및 버그 수정 목록이 포함되어 있으며 개발팀의 주요 작업 소스 역할을 한다. 이 목록은 프로젝트 전반에 걸쳐 지속적으로 개선되고 조정된다.
4. 스프린트 계획: 각 스프린트가 시작될 때 팀은 제품 백로그에서 작업할 항목 세트를 선택한다. 각 항목을 완료하는 데 필요한 작업을 정의하고 필요한 노력을 추정한다.
5. 일일 스탠드업 미팅: 팀은 일일 스크럼이라고도 하는 일일 스탠드업 회의를 열어 활동을 동기화하고, 진행 상황을 논의하고, 장애물을 파악한다. 회의는 일반적으로 짧고 집중적으로 진행된다.
6. 스프린트 검토: 각 스프린트가 끝날 때마다 팀은 스프린트 검토를 수행하여 완성된 작업을 이해관계자에게 보여주고 피드백을 수집하며 제품 백로그에 필요한 조정을 한다.
7. 스프린트 회고: 팀은 회고 회의를 열어 스프린트를 되돌아보고 개선 기회를 파악한다. 이 회의에서는 잘된 점, 개선할 수 있는 점, 향후 스프린트를 위한 실행 항목에 대해 논의한다.
스크럼을 포함한 애플의 애자일 구현은 유연성, 협업, 고품질 소프트웨어의 신속한 제공을 가능하게 한다. 이를 통해 애플은 다양한 소프트웨어 제품 및 서비스 전반에 걸쳐 원활한 사용자 경험을 제공하는 데 집중하면서 빠르게 반복하고, 고객 피드백에 대응하고,변화하는 시장의 요구에 적응할 수 있다.
결론
Agile, scrum등 어느 하나만 고집하는것이 아닌 프로젝트의 성격, 팀의 성향등에 대한 다양한 factor들을 고려해서 유연하게 프로젝트를 이끌어가야한다. 직접 경험해보고, 조사해보고, 공부해본바 팀프로젝트를 진행하기 위한 design process는 정답이 없다. 단지 찾아 나아가야할뿐이다.
통제할 수 있는 부분은 self learning, self deriven, self motivated한 사람들을 모으고 호흡 화합을 맞춰나가는것이다.
구글 엔지니어 디렉터 또한 Agile의 short-term planning의 단점을 들면서 유동적으로 적용해야한다고 말했다.
(https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/David-Jeske?share=1)
[번외]
나의 팀프로젝트에 대한 회고(feat.KPMG 아이디어톤)
왜 했는가?
같이 뜻을 함께 할 팀원 모집과 더불어 팀을 이끄는 여러 실험들을 해보고 능력을 배양하는것. 시스템을 설계하고자 진행함. 아이디어를 만드는 능력 또한 진행하고자 이 대회를 참여했다.
What I learned from the project after learning about design process
효율적인 팀운영을 위한 고민은 군대 전역후 KPMG 아이디어톤에서부터 시작되었다. 주제는 생성형 AI를 활용한 업무 효율화로 우리팀은 회의 최적화를 위한 퍼실리테이션 bot을 아이디어로 만들었다. 회의를 진행하다보면 agenda에서 너무나 벗어나거나 감정이 격해질때, 본질에서 벗어난 주제에 대해서 이야기를 할때, 그리고 팀원들이 회의에 대한 준비가 잘 되어있지 않을때, 회의 참여자들을 정할때등 너무나도 비효율적으로 회의가 운영될 수 있는 factor들이 많았고, 이 고민은 효율적인 팀운영과도 연결이 되었다. 팀빌딩을 하기 위해서 소프트웨어 융합대학 포트폴리오 사이트에서 생성형 AI에 관심이 있고, 깃허브와 블로그들을 조사하면서 연락을 취했고, 나보다 실력이 월등히 뛰어난 선배들을 모아서 이끌어가는 입장에서 팀을 운영하는데에 부담감으로 정말 많은 고민을 했었다.
내가 가질 수 있는 무기는 프로젝트를 진행, 관리하고, 팀을 빌딩하는 추진력, 그리고 프로젝트를 혼자 남더라도 끝까지 이끌어갈 집념이라고 생각하고, 이 능력들을 더 optimize하기 위해서 하루하루 팀프로젝트를 진행하고나서는 회고하고, 주위 선배 개발자들, 현업자, 박사님께 여쭤보며 시스템을 구축해나아갔다.
하지만 팀빌딩시 대회에 나가는 인원수를 채우기 위해서 1~2명을 아는 지인으로 모집을 했다보니 열심히 하는 4명과 2명으로 나뉘게 되었다. 문제는 self learning, self deriven, self motivated한 4명이 있어도 나머지 2명이 팀의 분위기를 해쳤다. 프로젝트를 성공적으로 마치기 위해서는 이 2명을 방출시키는것이 맞지만 대회 신청때문에 쉽지 않았고, 지인이기 때문에 쓴소리를 할 자신이 없었던때가 많았다. 쓴소리를 하더라도 팀분위기를 해치는 2명의 빌련이 큰 반발이 일어났기에 크고 작은 다툼이 정말 많았고, 거기에 쓰이는 정신적,시간적 리소스가 많았다. 아직 프로젝트를 리드할때 사람과의 관계에 있어서는 아직 나 자신이 부족하다는점이 느껴졌다.
What I learned from the project after learning about design process
아이디어톤 뿐만 아니라 팀프로젝트에서 Agile Manifesto 12 principles의 5번과 Manifesto에서도 볼 수 있듯이 결국에는 프로젝트에 성공적으로 이끌어가는 핵심적인 요소는 결국에는 사람이라고 느꼈다. 또한 절대적인 프로젝트를 이끌어가기 위한 개발 방법론이 없다는점, 아무리 좋아보이는 Agile 방법론도 shot-term planning으로 인한 한계점, 팀의 특성과 프로젝트의 성격에 따라서 팀의 성과를 최적화하는 방법론은 저마다 다양할 수 있다는점을 통해서 결국에는 효율적인 팀을 운영할 수 있는 안목과 경험, 이를 뒷받침해줄 지식이 필요하다고 생각을 했다.
Agile을 함께할 수 있는 팀원들을 모아 프로젝트를 하고 싶은 욕구가 생겼다. 이를 위해서는 나부터가 self learning, self deriven, self motivated하는 개발자가 되어야겠다. .
참고문헌 및 자료 출처
1. 7 Aigle Ai Best Practices: https://www.datascience-pm.com/agile-ai/
2. 10 Best Generatice AI Tools for DevOps Teams in 2024: https://clickup.com/blog/ai-tools-for-devops/
3. scrumb: https://www.scrum.org/
4. Why Big Data Science and Analytics Projects Fail?: https://www.datascience-pm.com/project-failures/
5. Chapter1. Introduction: Agile AI Processes and Outcomes: https://www.oreilly.com/library/view/agile-ai/9781492074984/ch01.html
6. agile manifesto picture: 경희대학교 오픈소스sw 개발방법 및 도구 강의자료(이성원 교수님)
