데이터 사이언스 현장의 안티패턴들

효과적인 데이터 사이언스 도입을 가로막는 숨은 함정들

데이터 사이언스는 조직이나 도메인의 고유 특성에 따라 다른 방법론이 적용되는 분야지만, 이에 관계없이 데이터 사이언스 현업에 있다보면 자주 발견되는 패턴이 있다. 여기서는 필자가 그동안 검색 및 추천서비스에서 업무를 수행한 경험을 바탕으로 데이터 및 분석 결과가 가치를 창출하는 과정에서 장애가 되는 부정적인 패턴 및 해결 방법을 정리해 보려 한다.

단일 데이터 혹은 지표에 의존

지난 글에서 밝힌대로 온라인 서비스의 성공적인 운영을 위해서는 여러 상충되는 목표를 동시에 만족시켜야 하며, 고려해야 할 품질의 기준도 여러가지가 있다. 이런 상황에서 특정 데이터 혹은 지표에만 의존하는 것은 자칫 편향이나 균형잡힌 목표 추구를 방해할 수 있다. 따라서 서비스 분석에는 최대한 다양한 데이터와 지표를 동원해야 한다. 분석 방법 관점에서도 Causal Inference와 같이 가정에 대한 완전한 검증이 어려운 분석 기법을 적용할 때는 보통 두가지 이상의 방법론을 적용한 후 결과를 교차검증하는것이 좋다. 

온라인 서비스의 가장 보편적인 데이터 형태인 사용자 로그를 생각해보자. 로그 데이터로 서비스 자체에서 어떤 일이 일어나고 있는지에 대한 사실적인 기록을 수집할 수 있지만, 로그 데이터의 바탕은 현재 서비스를 사용하는 사용자들의 행동이다. 따라서 로그 데이터를 바탕으로 아직 우리 서비스가 도달하지 못한 마켓에 대한 결론을 도출하는 것은 편향된 결론을 낳을 수 있다. 이를 극복하기 위해 좀더 폭넑은 관점에서의 시장 분석을 통해 우리 서비스에 접속하는 사용자들의 인구학적인 구성이 경쟁사와 어떤 차이를 갖는지, 사용 목적 및 패턴은 어떻게 다른지를 분석해볼 수 있을 것이다. 

또한 로그 데이터는 행동의 기록이며, 이를 올바로 해석하기 위해서는 별도의 레이블 데이터 컬렉션 등을 통해 로그 데이터의 한계를 다양한 방식으로 보완해야 한다. 예를 들어 검색 및 추천 시스템에서 컨텐츠별 체류 시간을 만족도의 지표로 사용하고 싶다면, 어디까지를 만족으로 볼지에 대해 사용자 혹은 크라우드소싱을 통해  레이블을 모아 분석해보아야 할 것이다. (관련 연구 [1] [2])

조직 리더십이 분석 결과를 무시

전통적으로 데이터 사이언스의 성공적인 도입에 가장 큰 리스크는 조직 리더십과의 충돌이었다. 이는 데이터에 근거한 의사결정이 자신의 권위를 침범한다고 느끼거나, 분석 결과보다 자신의 직관을 믿으려는 일부 리더들의 고집이 낳는 문제다. 최근처럼 데이터의 중요성이 강조되는 분위기에 아직도 이런 경영진이 있겠냐마는, 데이터 분석 팀을 만들어 놓고도 실제 의사결정에서는 위에서 마음대로 한다는 이야기는 아직도 업계 곳곳에서 들린다.

여기서 데이터로 내리는 결론이 매번 완벽하다거나, 조직 리더십의 경함과 직관을 무시하자는 이야기는 아니다. 데이터로 내리는 의사결정에 따를 수 있는 맹점이나 편향은 늘 주의해야 하고, 특히 A/B테스트는 단기적으로 로깅이 가능한 지표의 차이로만 의사결정을 해야 한다는 한계가 있다. 하지만 데이터로 명백한 결론을 내릴 수 있는 문제의 경우에도 리더 개인의 직관이 우선하는 분위기에서 분석을 바탕으로 의사결정하는 문화가 자리잡는 것은 불가능에 가깝다. 

이런 경우 경험상 시간이 걸리더라도 분석 결과를 지속적으로 제공하여 리더들이 스스로 깨달을 수 있도록 유도해야 한다. 필자가 몸담았던 스냅(Snap)의 경우 입사 초기만해도 디자이너 출신 창업자를 포함한 리더십 팀의 직관이 제품의 방향에 지대한 영향을 끼쳤다. 물론 그가 옳은 경우도 많았지만, 때로는 서비스 업데이트에 대한 잘못된 의사결정이 DAU를 5%이상 떨어뜨리며 서비스와 회사의 근간을 흔들었던 경우도 있었다. 

하지만 데이터 조직에서는 참을성을 가지고 (별달리 선택의 여지가 있었던 것은 아니지만:) 매번 서비스 업데이트에 대한 A/B테스트를 수행하여 분석 결과를 제공하여, 리더의 직관으로 내린 결론과 비교해볼 수 있도록 지원하였다. 그리고, 창업자를 포함한 리더십은 시간이 지나면서 자신들이 틀릴 수도 있다는 사실을 인지하고 좀더 분석 결과에 귀를 기울이기 시작했고, 위에서 언급한 디자인 변경은 재검토를 거쳐 더 나은 디자인으로 바뀌었다. (관련 기사)

데이터와 의사결정의 이력이 쌓이지 않음

데이터, 특히 서비스 로그 데이터의 가치는 오랜 기간동안의 축적에서 온다. 분석 과정에서 흔히 마주치는 질문이 '과거에는 어땠을까?'이며, 이런 질문에 대답하기 위해서는 과거 데이터를 가지고 있어야 하기 때문이다. 물론 저장 용량 및 사용자 프라이버시 등의 문제로 보관 기간을 제한해야 하는 경우도 있다. 하지만 그런경우에도 분석에 사용할 수 있는 요약 데이터는 필요하다. 

분석과 함께 남겨야 하는 것이 서비스에 영향을 끼치는 각종 의사결정의 이력이다. 서비스 UX 및 로깅의 변경사항, 검색 및 추천 모델의 업데이트 이력 등이 제대로 관리되지 않으면 KPI지표가 갑자기 떨어졌을 때 이를 추적할 방법이 없고, 문제 해결에 전 직원이 동원되는 촌극이 벌어질 수 있다. 따라서 이런 의사결정 및 변경사항도 별도 DB로 관리해서 다양한 분석에 활용할 수 있어야 한다.

또한 AB테스트를 자주 수행하고, 이를 바탕으로 서비스 변경 의사결정을 내리는 경우, 개별 시험에 대한 의사결정 사항이 실험의 최종 리포트와 함께 관리되어야 한다. AB테스트 지표를 계산할 수 있는 데이터와 함께 이런 의사결정의 기록들이 남아있다면, 신규 지표를 개발한 후 과거의 AB테스트에 대해서 해당 지표의 움직임을 확인해볼 수 있다. (관련 논문 [1])

분석가들의 노하우가 공유되지 않음

바쁘고 빠르게 성장하는 데이터 조직에서 주로 발견되는 문제로, 각 분석가들이 자신의 일에 바쁜 나머지 반복되는 분석에 대한 팀내 공유나 템플릿화를 게을리하는 것이다. 이는 반복되는 분석 요청에 대응하는 노력이 계속 쌓이면서 구성원의 피로가 누적되고 팀의 생산성이 떨어지는 악순환을 낳는다. 물론 파트너 입장에서도 비슷한 에러가 반복되고, 분석 결과의 품질도 나아지지 않을 것이다. 

조직에 따라 다르겠지만, 필자의 경험에 따르면 A/B 테스트, KPI 지표 변화 분석 등 대부분의 분석 유형은 반복되고, 몇 번 대응을 하다 보면 일반화된 방법론을 템플릿으로 만들 수 있다. 혹은 외부에 잘 정리된 템플릿을 구해서 변경/재사용할수도 있을 것이다. (여기서 템플릿은 - 다른 형태도 가능하지만 - 정해진 파라메터만 입력하면 누구나 실행할 수 있는 노트북 형태의 분석 코드를 가리킨다.)

물론 쓸만한 분석 템플릿 만들기가 말처럼 쉬운 것은 아니고, 개별 분석 요청에서 공통되는 요소를 찾아 처리 루틴을 재사용이 가능한 모듈화하고 문서화와 함께 노트북 형태로 정리하는 것은 일정 수준의 경험과 코딩 실력을 필요로 하는 일이다. 하지만 이런 노력을 하는 개인, 그리고 이런 분석 코드의 재사용을 장려하는 조직은 장기적으로 반복되는 업무의 비중을 줄이고, 창의적이고 도전적인 업무에 시간과 노력을 투자할 수 있을 것이다. (넷플릭스의 노트북 플랫폼 관련 자료 [1])

데이터 및 분석 결과의 신뢰성 검증 절차가 없음

데이터 업계의 공공연한 비밀은 분석 과정에서 데이터 처리가 대부분의 시간과 노력을 차지한다는 것이며, 여기서 파생되는 문제는, 이 과정에서 한번의 실수만 있어도 전체 분석 결과에 영향을 끼친다는 점이다. 업계 종사자라면 누구나 분석을 완료한 상황에서 검증을 하다 오류를 발견하고 처음부터 다시 시작하느라 진땀을 뺀 경험이 있을 것이다. (분석에서 처음 내린 결론이 100% 맞을 확률은 처음 작성한 코드에 버그가 없을 확률 만큼이나 희박하다.)

그래서 필자가 데이터 팀의 수준을 판단할 때 보는 것이 데이터 및 분석 결과의 신뢰성 검증 절차다. 만약 신뢰성 검증이 분석가 개인에게 맡겨저 있다면 분석의 품질이 들쭉날쭉하거나, 적어도 분석가 개인이 많은 노력을 들여야 신뢰성 있는 결과를 낼 수 있다는 뜻이다. 제대로 된 분석 조직이라면 데이터 및 분석 코드의 신뢰성 체크를 최대한 자동화하고, 자동화가 힘든 분석 결과에 대해서는 리뷰어를 지정하여 서로 교차 검증을 할 수 있는 시스템을 만들어야 한다. 

신뢰성의 문제는 앞서 언급한 분석의 템플릿화와도 관련이 깊은데, 분석 코드가 모듈 및 템플릿화 될수록 에러 검증 등을 자동화하여 이에 들이는 노력도 줄어들 것이며, 분석 코드를 복붙하여 고치는 시간을 템플릿을 개선하는데 쓸 수 있으니 분석의 품질이 시간에 따라 개선될 것이다. 필자가 속한 네이버 Data&Analytics팀에서도 분석 환경 표준화 및 분석 코드의 버전 관리 및 템플릿화에 많은 노력을 기울이고 있다. (MS Exp 팀의 관련 아티클)

맺음말

지난 글에서 현업 데이터 분석의 어려움에 대해 썼는데, 오늘도 현장에서 부딛히는 다양한 함정을 논의했다. 개인의 경험 및 롤에 따라 다를 수 있는 부분이지만, 오늘도 본인이 수행하는 분석 결과가 가치있게 쓰이기를 바라는 많은 동업자 분들은 공감하시리라 본다. (특정 부분 격하게 공감하시거나, 내가 겪는 어려움에 대해서 추가 의견 있으신 분은 댓글로 알려주세요!)

데이터 사이언스 현장의 안티패턴들 (요약)