컬럼 원문: Data Science and Agile (What Works, and What Doesn’t) by eugeneyan

애자일 프레임워크를 배우고 있지만, 개발 직군에 한정된 이야기 같고, 데이터 관련 직군에서 애자일은 어떤 특징을 가질까 의문이 들어 찾아봤다. 저자는 아마존에서 senior applied scientist로서 추천 시스템 쪽 종사하고 있다고 함. ML systems, engineering 관련 글도 종종 기고하는 것 같음. ML 쪽 스타트업 엔젤 투자자라고도 하는데 엄청난 사람인 듯.. ML 이력을 아래와 같이 한 문단으로 표현한게 인상 깊어서 가져옴

Previously, I led machine learning at Lazada (acquired by Alibaba in 2016). I also built the product ranking system (conversion & revenue up 5-20%), smart push-notifications (CTR & add-to-cart up 10%), and automated product & review classification (cost down 90%). Hypergrowth’s fun!

TL; DR

데이터 사이언스 프로젝트에서 애자일을 도입할 때 좋은 점

매 스프린트 시작할 때 계획, 우선 순위 설정
전달하려는 프로덕트와 수반되는 일정을 명확히 할 수 있음
매 스프린트 끝 시점에서의 회고 및 데모

데이터 사이언스 프로젝트에서 애자일을 도입할 때 단점

데싸에서 들여야 하는 공수를 명확히 정의하기 어려워서 추정하기 어려움
작업 범위, 요구 사항 변동성이 커짐
개발처럼 데싸 스프린트에서도 결과물이 있어야 한다는 기대
스크럼에 너무 능숙하거나 규율적이라는 점

장점1. 매 스프린트 시작할 때 계획, 우선 순위 설정

프로젝트 방향성을 체크하고, 작업의 우선 순위를 설정해서 리소스를 효율적으로 분배하는 것이야 당연히 좋음. 그 중에서 저자는 특히 스프린트 시작 할 때 프로젝트에 관련된 이해관계자를 같이 참석시켜 계획, 우선 순위를 같이 논의하는 것의 필요성을 언급함. 데싸 프로젝트는 데이터 팀으로만 진행할 수 없음. 다른 팀과 협업이 필수적이라 이해관계자와 데이터 팀 간 정기적으로 생각을 맞추는 자리는 반드시 필요함. 이걸 당연시 여기는 프레임워크다 보니 장점이 되는 것 같음.

장점2. 전달하려는 프로덕트와 수반되는 일정을 명확히 할 수 있음

데싸 프로젝트하면서 자주 마주치는 이슈는 초심을 잃는 것. 프로젝트 목적에 대한 집중력이 떨어지고, 연구 리서치 등을 반복하다보면 곁가지로 새는 일이 흔함. 애초에 데이터 사이언스라는 것이 명확히 정의되어 있지 않다는 근본적인 문제에서 기인하기 때문에 어쩔 수 없음. 이런 문제를 줄이는데 먼저 문제와 그에 필요한 업무를 정리하고, 결과물 전달하기까지 필요한 대략적인 일정을 짜보는 것이 좋다고 함.

업무 예시:

지표 분석

Net Promoter Score라는 유저 경험 지표가 악화됨. 이 현상의 원인을 배송, 상품, 고객 응대 방식, 앱 작동 방식 등을 분석해서 파악하는 방식을 문제를 좁힐 수 있음. 다음엔 NPS 감소가 비즈니스에 미치는 영향을 따져야 함. NPS가 낮은 고객이 덜 소비하는지, 리텐션은 더 낮은지 등을 집계하는 등. 이런 방식으로 문제를 정의하고, 검증할 가설을 정리하는 것이 분석가 스스로와 이해관계자 모두에게 필요함.

데이터 프로덕트 개발 (참고)

이렇게 업무를 정의하고 나면, 이해 관계자가 ‘그래서 얼마 걸리는데’라고 물어볼텐데, 이건 도메인마다 너무 다른 문제라 보통 시니어들한테 부탁하는 것이 좋다고 함.

장점3. 매 스프린트 끝 시점에서의 회고 및 데모

회고, 데모는 팀원 들 간 서로 배우고 축하하고 피드백 받는 아주 재밌는 자리라고 함. 30분 ~ 1시간 정도 하는 것에 비해 팀에 기여하는 것은 엄청남. 저자의 팀에선 모든 팀원들이 아래 항목에 대해 답해야 한다고 함.

Enjoyable: 어떤 업무가 가장 재밌었고, 축하해야 할 성과가 있는지?
Frustrating: 가장 좌절했던 것은? 그건 어디에서 기인한건지? (기술적인건지, 비즈니스건지, 아니면 사내 정치 등..?) 이걸 어떻게 개선할 수 있을지?
Puzzling: 무엇이 가장 어려웠는지? 팀원들 중 비슷한 문제를 마주쳤던 경우가 있는지? 다음 작업을 어떻게 가져갈지?

데모 자체는 회고 보다는 더 큰 개념으로, chunk of work이나 milestone이 종료되면 하며 보통 2~8주 사이에 진행한다고 함. 회고와 마찬가지로 내 작업물 공유하고, 다른 사람의 피드백을 받는데 다른 점이 있다면 외부 팀을 초대해서 데싸 팀의 작업 방식을 보여주고 서로 간 이해를 높일 수 있다는 특징이 있음.

단점1. 데싸에서 들여야 하는 공수를 명확히 정의하기 어려워서 추정하기 어려움

엔지니어링에 비해 데싸는 명확히 정의할 수 없는 것들이 많음. 첫번째는 문제가 주어져도 어떤 데이터를 사용해서 해결해야 할지 바로 알기 어렵다는 것. 또한 적합한 데이터를 찾아도 적절한 프로세스를 따지고, 각 프로세스에 들이는 노력을 얼마나 할지도 프로젝트마다 천차만별이라 프로젝트에 들여야 하는 공수를 명확히 하기가 어려움. 예를 들어 쿠팡에서 전환율을 5퍼센트 높이기 위해 랭킹 알고리즘을 개선시키고자 할 때, 아래와 같은 불명확한 부분이 있음

분석에 쓰일 데이터는 정돈되어 있는지?
데이터에 이슈는 없는지? 정합성이나 무결성 등
분석의 목적이나 영향력은?
이 문제를 어떻게 모델링할지? 랭킹 문제인지, 아니면 classification 문제인지?
성과 측정할 지표는 어떻게 잡을지? 클릭 수? 매출? 전환율?

목적(문제) 자체가 명확하더라도, 문제를 해결할 수 있는 여러 방식이 있기 때문에 애자일이 어렵다고 저자는 말함. 이에 반하여 (댓글에서도 언급되어 있긴한데) 오히려 이렇게 시도해볼 방법이 많고, 실험할 수 있는 것이 많기 때문에 기존 waterfall이 아닌 agile이 더 적합하다고 생각함.

단점2. 작업 범위, 요구 사항 변동성이 커짐

만약 분석을 했는데, 이해관계자의 직관에 위배되는 결과가 나왔다면? 비즈니스에선 생각보다 흔한 일인데, 이런 경우 자신의 직관을 바꿀 수 있는 이해관계자는 많지 않으며, 대체로 분석을 다시 해보는 것으로 결정됨. 문제는 이런 pivot이 너무 자주 발생하면 스프린트에 악영향을 미침.

단점3. 개발처럼 데싸 스프린트에서도 결과물이 있어야 한다는 기대

엔지니어링에선 스크럼이 끝날 때 쯤, 인프라를 구축한다거나, 새로운 피처를 도입한다거나, 새로운 프론트-엔드를 구축한다는 등의 결과물이 있음. (그런가..?) 데싸에서는 누군가에게 답을 줄 수 있어야 하는 정성적인 측면이 강함. 또한 연구 성향이 짙기 때문에 명확한 마감일자를 정해야 하는 파워 J인 PM은 데싸 업무를 정의하거나 맡기기 힘들어 함. 데싸 자신들도 이런 관점에선 스스로 계발하고 최선의 해결책을 찾기 힘들어하는 경우가 많음

단점4. 스크럼에 너무 능숙하거나 규율적이라는 점

이해관계자는 어떤 프로젝트가 가장 비즈니스에 큰 도움이 될지 보는 눈이 있음. 다르게 말하면 프로젝트의 단기 성과에만 집중하는 경향이 있음. 더 큰 성과를 위한 장기적인 관점을 보는 눈이 부족할 수 있는데, 스크럼을 적용하는 데싸 조직에도 적용될 수 있음. 당장의 스프린트 성과에 집중하면 더 큰 것을 놓친다는 말 같음. 당장 급한 것을 높은 우선순위로 가장 빠르게 처리하지만, 덜 급하고 더 중요한 것은 뒷전으로 미룬다고 함.

근데 이것도 장점1에서 말한 것처럼 스프린트나 프로젝트 방향을 잘 잡으면 되는 문제 아닐까? 장점1이 제대로 되지 않았을 때 단점4가 발생할 수 있다고 봐도 될 것 같다.

개인적으론, 애자일 프레임워크를 일부 도입하고 있는 조직에 몸 담고 있는 분석가로선, 단점1이 가장 큰 방해 요인이자 장점(?)인 것 같다. 난 명확히 하기 어렵기 때문에 이걸 계속 정의하려는 시도가 반드시 필요하다는 의견. 다만 이게 waterfall이 아닌 애자일 프레임워크에서 더 잘 달성되는가를 고민해보면.. 잘 모르겠음.

프로덕트 개선이 아닌 지표 분석의 경우, PM이 껴있지도 않은 경우가 많아 티켓 조차 없이 요청 -> 공유가 끝이다.