격리된 데이터 분석가
데이터 분석가를 격리하지마세요.
정말 굉장한 능력을 가진 데이터 과학자가 있다면 어떻게 가능할 수는 있겠지만, 일반적인 데이터 과학자 혼자서 데이터 과학을 비즈니스에 적용하는 것은 불가능합니다. 데이터 과학 적용에 실패하는 패턴으로는 회사 외부에서 데이터 과학자만 모으거나, 사내에서 데이터 과학만을 교육하는 프로그램을 만들거나, 데이터 과학자만으로 구성된 조직을 만드는 패턴이 있습니다.
가장 최악이라고 할 수 있는 것은 “외톨이 데이터 과학자” 패턴입니다. 주변의 동료들이 데이터 과학에 대한 이해가 없는 고독한 외톨이 상태의 데이터 과학자라는 의미입니다.
“그럼 데이터 과학자가 외톨이가 되지 않게, 여러 명 있으면 되겠구나”라고 생각할 수도 있겠지만 그런 의미가 아닙니다. 조직 내부에서 데이터 과학자가 고립되어 있으면, 여러 명이 있더라도 “외톨이 상태”로서 상황이 동일합니다.
타카하시 이치로, <직장인의 교양, 데이터 과학>
이 책을 읽은 지는 꽤 되었는데 다시 읽어도 웃퍼서 흐헣헣헣 웃었더니 반려인이 뭐가 그리 웃기길래 아침부터 웃어대느냐고 묻는다. (난 슬플 때 힙합을 추는 게 아니라 슬프게 웃음) 꽤 여러 회사를 다녀보았지만 위 내용을 인지하고 있고, 데이터 분석가(과학자든 뭐든 좋다.)가 고립되지 않게 노력하는 회사가 많지는 않을 것 같다. 내가 경험하기로는 그랬다. 만약 본인의 회사가 그렇지 않다면 댓글을 남겨서 자랑해주세요. 자연스러운 PR 타임!
외톨이야~ 외톨이야~ 이 노래가 생각난 사람은 나와 동년배.그래도 현재 있는 조직에서는 이런 상황이 다른 조직에 있을 때보다 매우 적은데 이유는 간단하다.
데이터 분석가도 프로덕트팀의 일원이라고 인지하고 있는가?
데이터 분석에 필요한 일련의 일들을 프로덕트를 만드는 작업의 일환이라고 생각하는가?
위의 책 발췌 내용과 다르지 않다. 하나라도 충족되면 나머지도 같이 충족되는 듯하다.
1. 데이터 분석가도 프로덕트팀의 일원이라고 인지하고 있는가?
데이터 분석가는 메이커가 아니고, 어떤 식으로 프로덕트 개발 및 개선에 참여하는지 잘 알려져 있지 않다 보니 프로덕트 팀원이라 생각하지 않고 별도 부서로 다루는 경우가 꽤 많다. 크로스 펑셔널(Cross- functional)로 운영해도 그다지 다르진 않다. 크로스 펑셔널로 운영하는데 분석가는 프로덕트 팀 스크럼에 참여하지 않는(하지만 분석가들끼리의 스크럼은 존재하는) 경우도 목격한 적 있다. 그래서 프로덕트팀에서 어떤 고민을 하고 있는지 알 수가 없었다…. 크로스 펑셔널로 구성한다고 데이터 분석가가 자동으로 프로덕트 팀원이 되는 것이 아니다. 처음부터 프로덕트를 만드는 프로세스 안에 분석가가 포함되어 있고, 이 피쳐를 왜 만드는지 분석가도 이해하고 있고, 각 단계별로 분석가가 어떤 일을 해야 하는지 정의되어 있어 메이커들이 ‘데이터 분석이 중요하다는데 정확히 분석가가 무슨 일을 하는지 모르겠네. 알아서 잘 하고 있겠지?’라고 생각하지 않는 게 필요하다고 생각한다.
분석가를 프로덕트팀의 일원이라고 인지하게 되면 많은 것이 달라진다. 심한 경우 분석가는 자신이 하고 있는 일(분석, 추출 등)이 왜 하게 된 것인지, 어떤 점에서 중요한 것인지, 이것이 어떤 영향을 끼칠 것인지를 모르고 일을 할 수도 있다. 제대로 알고 있었다면 더 적절한 방식으로 작업을 할 텐데 내막을 모르면 그렇게 하기가 어렵다. 물론 분석가 개인도 노력해서 이런 정보를 알아낼 수 있고, 알아내야 하지만 프로덕트 팀원으로 받아들여지냐 아니냐에 따라서 이 정보를 얻는 데 드는 에너지가 달라진다. 팀원이라면 당연히 알려줘야 하는 정보인데, 아니라면 ‘이게 데이터 분석에 왜 필요한 거지..? 나 지금 바쁜데 무엇을 어디까지 알려줘야 하나?’라고 생각할 수도 있다. 분석가가 프로덕트 팀에 속해있지 않다면 나는 이것도 자연스러운 반응이라 생각한다.
2. 데이터 분석에 필요한 일련의 일들을 프로덕트를 만드는 작업의 일환이라고 생각하는가?
데이터 분석에는 분석가 말고도 여러 직군의 도움이 필요하다. 어쩌면 가장 많은 직군과 접점이 있는 직군이다. 분석에 필요한 다양한 단서는 다른 직군을 통해야 얻을 수 있기 때문이다. 게다가 로그 작업은 개발자와 QA의 도움이 필요하다. 로그를 얼마나 잘 남기는지에 따라 알아낼 수 있는 정보량이 달라진다. AB TEST를 하더라도 실험군의 결과가 더 좋지 않을 경우 그 이유를 찾아낼 수 있는 수준의 로그가 없으면 “실험군이 별로네… 왜 별로인지는 정확히 모르겠지만” 하고 끝나게 된다.
나는 “로그 개발은 개발자들이 제일 싫어하는 작업이다. 그러니 로그는 개발자들이 원하는 대로 추가할 것이다”라는 말을 실제로 들어본 적 있다. 그 말을 들었을 때 내 마음은 화조차 나지 않았고 이게 내 개인의 영달을 위해서 하는 작업이 아니라 팀을 위해서, 무엇보다 나도 월급을 받았으니까 받은 값어치를 하기 위해 하는 일인데 나는 같은 팀이 아닌 것 같다는 생각이 들었다. 우리 같은 조직에 속해있지 않은 건가? 데이터 적재를 위해 하는 작업을 프로덕트 업무가 아니라고 생각한다면 그럴 수 있을 것 같다. 당연히 해야 하는 일이 아니라 데이터 분석가가 요청해서 추가로 해주는 일이 되면 업무 외 작업인 거니까.
반대로 내가 감동받았던 상황은 새로운 피쳐가 생길 때마다 “이거 로그 필요할 것 같은데 설계하고 알려줄래?” 하고 개발자가 먼저 알려주거나, 내가 로그를 설계한 후 공유 미팅을 할 때 개발자와 QA가 “네가 그 정보를 원한다면 그건 이렇게 로그를 남기면 어떨까?” 하고 더 좋은 방법을 제안해줄 때였다.
무엇보다 가장 감동받았을 때는 “프로덕트 출시만 하는 게 목표가 아니다. 출시 후 (당연히) 지표를 알아야 하고 어떤 것을 개선해야 할지 알아야 한다”라는 말을 들었을 때였다. 데이터 적재 작업이 부대 작업이 아니라 반드시 필요하다는 것을 인지하고 있어야 나올 수 있는 말이다. 분석가를 프로덕트 스크럼에도 포함시키는 것도 물론이다. 메이커들이 어떤 고민을 하고 있는지 알게 되면 누군가 요청하지 않더라도 분석가가 알아서 분석을 할 수도 있다. 무엇보다 우리는 같은 팀이 아닌 건가…? 하는 회의감이 사라지게 된다. 결과적으로 팀을 위해서 내가 할 수 있는 게 뭘까? 우리 팀은 무엇이 필요할까? 를 훨씬 더 많이 생각하게 되었다. 나는 이런 차이가 어디에서 오는 걸까 굉장히 궁금했는데 사람의 차이가 아니라 문화의 차이 같다는 결론을 내렸다.
마지막으로 이 책에서는 “아무리 심장 뛰는 주제라도, 현장에서 받아들여지지 않고, 활용되지도 않는다면 어떠한 의미도 없습니다”라는 내용이 나온다.
이 부분을 읽고 나는 내가 평소 자주 떠올리던 문장을 생각했다.
나의 벗, 독자여! 네가 없으면 난 대체 무어란 말인가!
생각건대 모든 건 혼잣말로 끝나고 나의 기쁨도 할 말을 잃을지니….
덧. 마지막 문장은 <괴테 시집>이다.
덧. 어떻게 협업하면 좋은지 구체적으로 잘 적어주신 글이 있어 링크를 추가한다.
