주저하는 기획자들을 위해(Feat.AI) - 1편
이번 포스팅은 스터디 후기이며 기억나는 내용들을 조금 두서없이 써보려고 합니다.
지난 3월부터 6월까지 모두의연구소에서 ‘주저하는 기획자들을 위해(Feat.AI)’라는 풀잎스쿨 스터디를 진행했습니다.
제목에서 스을쩍 나타난 것처럼, AI 프로젝트or 서비스를 기획하고자 하는 분들과 함께 진행한 스터디입니다.
스터디장으로 활동하면서 1주일에 1번, 12주의 스터디를 어떻게 보낼지를 처음에 생각할 때에는 기획자들이 어떤 지식과 내용을 익혀야 할 것인지에 대해서 고민을 많이 했습니다.
하지만 실제 현업에서 AI 서비스를 기획하고 있는 스터디원들은 AI 지식보다 AI를 둘러싼 다양한 업무적인 요소들에서 고민하고 있는 부분이 많았기 때문에, 이 점을 해소할 수 있는 정보를 찾고자 노력했습니다.
기획자를 위한 AI 스터디의 포스팅을 두세 번 정도 나눠서 해보려고 하는데요, 먼저 ‘AI 기획자는 누구이며 이론을 어디까지 알아야 할까?’ 입니다.
AI 기획자는 누굴까?
우선 AI 서비스를 기획하고 계신 분들은 기존에 사업기획의 영역에서 기획을 하시는 분들의 케이스가 있었고, 연구 및 개발을 기획하고 계시는 분들의 케이스로 생각해볼 수 있었습니다.
전자의 경우는 해당 도메인에서 종사해오신 분들의 경우가 많고, 후자는 AI와 개발을 메인으로 전공 및 종사하시다가 속한 기업이나 조직의 도메인에 따라 적용을 하시는 경우가 있습니다.
위 이미지는 앤드류 응 교수님의 ‘AI for Everyone’ 강의입니다.
전술했던 표현을 이 벤 다이어그램에 비추어보면 우측 벤 다이어그램의 포지션이 도메인 전문가, 즉 해당 분야 및 기업에서 사업기획을 하시던 기획자의 경우이겠지요?
마찬가지로 왼쪽의 벤 다이어그램이 AI를 연구 및 개발해오시던 기획자의 경우일 것입니다.
어찌되었건 두 기획자의 케이스 모두 가운데의 ‘비즈니스&AI’의 교집합을 찾아내는 것이 목표일 것이고, 스터디 역시나 저 교집합을 찾아가는 여정이었습니다.
(여기서 잠깐! 역시나 저희 스터디에서도 기획자와 PM(Project Manager)의 차이에 대한 토론이 있었습니다. 각자 조직이나 업무 환경에 따라 다르기 때문에 쉽게 정의하지 못했는데요, 이번 포스팅에서도 굳이 PM이라는 표현을 달리 사용하지는 않겠습니다. 이 포스팅을 보시는 분들의 배경과 의견에 따라 해석해주시면 감사하겠습니다!)
한 편으로는 AI에 대해서는 기획자의 롤이 아예 규정되지 않은 조직도 있었습니다. 베테랑 AI 연구자 및 개발자가 자연스레 리딩하는 것이지요. 여하튼간에 AI를 통해서 비즈니스 가치를 이끌어내고자 하는 기업에는 저 벤 다이어그램의 가운데 부분을 발굴할 누군가가 필요하며, 그 롤을 수행하는 사람을 AI 기획자로 부르기로 했습니다.
다만 AI 지식을 알아야 하는 것도 사실이기에 도대체 어디까지 AI에 대한 지식을 알아야 할 지가 고민이었습니다. 이 스터디에 다양한 도메인의 AI 기획자가 참여했기 때문에 ‘도메인을 어디까지 알아야 하는가?’는 고민 요소에서 뺐습니다. ^^;
AI 기획자는 어디까지 알아야 할까?
벤 다이어그램을 다시 볼까요?
왼쪽 그룹의 AI 전문가는 이미 AI를 잘 아는 사람이기 때문에 Max로 두었습니다.
하지만 저 포함 스터디원들은 아무래도 오른쪽 그룹에 해당되었기 때문에 최소한의 지식을 어디까지 알아야 할 지를 규정해야 했습니다.
스터디이기 때문에 따라갈 수 있는 베이스라인이 있으면 좋겠다는 생각에 앤드류 응 교수님의 ‘AI For Everyone’을 채택했습니다.
거기에 각자의 상황과 배경에 맞게 추가적인 지식을 습득하는 방향으로 진행했습니다.
(강의 유튜브 링크 : https://youtube.com/playlist?list=PLuyk1nLMhRm5aV6_eeUIuj_MKEekvwGDR)
찾아본 바로는 한글 자막이 따로 없고, 숙명여대 김형률 교수님께서 강의 스크립트를 한글로 작성해주신 것이 있어서 참고했습니다.
(김형률 교수님 스크립트 : https://wakelet.com/wake/7c45a78c-e628-4311-ad46-2115968f188c)
강의 내용의 중요 토픽을 간단히 나열해보자면,
1. AI, ML, DL의 정의
2. AI 프로젝트의 개발 흐름과 데이터 프로젝트와의 차이
3. 조직 내에서 AI 프로젝트를 구축하는 방법
4. AI와 사회적 이슈
등이 있습니다.
강의 내용을 다 서술드릴 수는 없어서 링크로 첨부했으니 나중에 참고하시면 좋을 것 같은데요, 기억나는 포인트 위주로 말씀드려보겠습니다.
우리가 처음 딥러닝을 입문할 때의 기억을 돌이켜보면 Neural Network가 뭐고, Back-Propagation, Gradient Descent, Loss Function, Optimizer, Hyper-Parameter, Regression, Classification, CNN, RNN 등등… 다양한 개념적인 요소를 배웠습니다.
이 강의에서는 이런 설명이 없이 A to B mapping, A ->B 스타일로 안내합니다.
어떤 데이터라는 Input이 있고, 데이터를 통해 원하는 Output을 도출하는 것을 사람이 직접 정해서 코딩하지 않고(not rule-based) 네트워크의 학습을 통해서 행하는 것으로 표현을 달리 했습니다.
이 때 겪었던 고민은 ‘그럼 딥러닝 이론적인 개념들은 몰라도 될까?’ 였습니다.
스읍…
일단 저와 스터디원들은 알아야 하는 영역이라고 생각이 들어서 각자 필요한만큼 추가적으로 공부하는 것으로 일단락 했습니다.
그럼에도 불구하고 스터디에서 반드시 다뤄야 할 것은 ‘AI로 할 수 있는 것이 뭐가 있을까? 였습니다.
이를 설명하기 위해서 저는 papers with code 사이트를 참고했습니다.
(https://paperswithcode.com/sota)
사실 AI 연구자 및 개발자들께서는 이미 익숙한 사이트겠지만, 기획자에게는 논문과 코드를 당장 접할 일이 없기 때문에 자주 사용하지는 않습니다.
제가 sota 사이트를 참고한 이유는 다양한 딥러닝 task를 소개해주기 때문입니다.
익숙하시지요? 하지만 이 사이트만큼 task를 잘 정리한 사이트를 저는 잘 모르겠습니다. (아시면 추천 부탁드립니다!)
이것만 보면 정확하게 해당 task를 살펴보기 어렵다보니 유튜브와 구글링을 곁들여 각 task에 대한 설명을 얻었습니다.
여기서 알아야 할 부분은, task라는 것이 연구자분들에게는 중요한 연구 분야이며 개발자에게는 구현해야 할 대상이겠지요.
기획자에게는 이런 다양한 task가 비즈니스 가치를 이끌어 내는 기능과 수단입니다.
단적인 예로 NLP에서 Question Answering은 어떤 질문에 대해서 모델이 적절한 답변을 하는지를 연구하는 분야이고 개발 관점에서는 유저가 질문을 했을 때 답변을 하는 챗봇이나 머신에 필요한 기능을 구현하는 코드가 sota 사이트에 있겠지요.
기획자가 QA라는 task를 알았을 때에는 고객의 질문에 답변하는 CS(Customer Service)에 활용한다던지, 아니면 음성 task를 더해 ARS나 전화 응대에 활용한다던지 등의 ideation을 할 수 있을 겁니다.
아무튼 기획자는 특정 알고리즘에 에너지를 쏟기 난감한 포지션일 가능성이 높은데, method나 모델 보다는 task를 중심으로 비즈니스에 도움이 될 아이디어를 떠올릴 수 있습니다.
-------------------------------------------------------------
이와 같은 방식의 스터디를 통해 기획자가 AI의 어떤 부분을 얼만큼 알아가야 할지를 고민하는 즐거운 시간이었습니다.
다음 포스팅에서는 기획자가 어디까지 알아야 하는지를 고민한 부분을 더 작성해 보겠습니다.
task에 이어 task에 필요한 데이터와 annotation, evaluation metric 같이 여전히 고민할 요소가 남아 있습니다.
적다보니 길어졌네요…
아무쪼록 비슷한 고민을 하고 계신 분들에게 조금이나마 도움이 됐으면 좋겠습니다!