보람찬 프로덕트 매니징 (01)
아래 맥킨지 커리어 블로그에서 퀀텀블랙팀 직원들이 찍은 유쾌한 동영상을 보며 실실대다가, 제게도 프로덕트를 통해 크루들을 돕고 신났던 경험이 있어 풀어봅니다. 이름하여 보람찬 프로덕트 매니징! 그 첫 번째는 저도 맥킨지 사례와 유사하게 데이터 엔지니어들을 위해 했던 일들을 먼저 떠올립니다.
너네 팀 잘 하고 있는 것 맞니?
크롤링 데이터를 적재하고 정제하여 검색 인덱싱으로 보내는 빅데이터 팀에 파견 된 본인. 당시 제가 받은 미션은 엔지니어들이 본연의 업무에 집중할 수 있도록 파이프라인 프로세스를 정비하고 비엔지니어 주니어를 관리하는 일이었습니다. 파견 첫 날 들뜬 마음으로 인상 좋은 구성원들과 인사를 하고 여유로운 마음으로 데이터 파이프라인을 파악하기 위해 눈을 빛내고 있는데, 리더님이 제게 말합니다. "링크님... 내일 데일리 스탠딩에 같이가욤..." 무슨 그런 말씀을!? 당연히 가야지요!
그렇지만 다음날 함께 참여한 스탠딩의 분위기는 다소 충격적이었습니다. 근 1시간 동안 빅데이터팀 리더님이 가운데 서서 쪼임 당하는 것을 지켜보아야 했기 때문이지요. "데이터가 잘 수집되는 것이 맞나요?" "데이터가 나오질 않아요." "도대체 알 수가 없네요." 질문들에는 대개 뾰족한 감정이 실려있었고, 한결같이 '당신들이 잘 하는지 도대체 알 수 없다.'를 표현하고 있었습니다. 빅데이터팀 리더님은 데이터 적재와 전달이 나름대로 잘 되고 있음을 어필했지만, 제가 듣기에도 너무 모호했지요. 제가 오기 전에 이런 스탠딩을 몇 번 쯤 한 것일까요?
핵심 문제를 추려보니: 투명성 제로
핵심 문제를 추려야 했습니다. 빅데이터팀은 프로덕트의 데이터 품질을 책임지는 중심에 있었기 때문에 프로젝트의 성패를 좌우할 수 있었지요. 제가 파악한 팀의 문제는 아래와 같았습니다.
1) 데이터 파이프라인별 담당자 간에 사일로(silo)가 있고 서로의 데이터를 검증하지 않는다.
2) 업무 효율을 높이거나 데이터 현황을 파악할 수 있는 도구 또는 대시보드가 전무하다.
3) 다른 프로젝트 구성원들의 신뢰를 받고 있지 못하다.
한마디로 불투명하다는 것이었고, 이 요구는 다른 팀의 요구, 즉, 알 수 있게 해달라와 결을 같이하고 있었습니다. 프로젝트 구성원들의 신뢰를 받고 있지 못하다는 3)번 항목은 1)번, 2)번 항목의 '결과'일 수 있지만 해결해야 할 중요한 문제로 설정했습니다. 프로젝트 내부에 수많은 기획자와 의사결정자들이 있는데도 소중한 데일리 스탠딩 시간이 특정 팀에 대한 원망으로 점철되고 있다면, 이 프로젝트는 문제해결을 함께 해본 적이 없는 것이 분명해 보였습니다. 문제해결 과정을 공유하는 것이 전체 프로젝트의 성과를 높이는데 중요한 점으로 보였습니다.
솔루션 개론: 있는 그대로 드러내고 도움을 청하기
리더님에게 가장 처음 제안한 것은 데이터 현황을 보여주는 아주 간단한 표 만들기였습니다. 다음 솔루션을 위한 의사소통의 시급성 때문이었지요. "리더님, 다소 엄밀함이 떨어지더라도, 적어도 현재까지 파악된 수준을 보면 의사소통하는데 대세에 지장은 없어요. 데이터 수준별로 표를 만들어 봐요." "옹. 좋은 관점이에요." 우리는 아주 별것도 아닌 Good, Middle, Bad, Miss 표를 만들었습니다. 그리고 수집 주기(iteration) 별로 크롤링 대상 사이트의 추정 데이터 수 대비 수집된 데이터 수가 90% 이상이면 Good, 50% 이상이면 Middle, 그 이하이면 Bad, 도저히 수집되지 않는 문제가 있는 대상은 Miss로 분류하였습니다. 각 수준별로 수집 및 적재에 서로 다른 문제가 포진하고 있을게 분명해 보였습니다.
이렇게 표를 분류해놓고 나니 빅데이터팀이 수집과 적재를 썩 잘 하고 있지는 못하다는 것이 직관적으로 드러났습니다. 다소 민망한 상황이긴 했지만, 각론으로 들어가 해결책을 도모할 수 있으니 할 일이 생겼지요. 기대했던 대로 데일리 스탠딩에 이 표를 공유하자 비난이 줄어들고 원인과 해결책 찾기에 대한 갑론을박이 이어졌습니다. 불투명했던 정보를 가시화 하면, 그 중심으로 다음을 도모할 수 있게 됩니다.
이 일이 있고 나서 곧 총괄 PO님을 만나게 되었습니다! "링크님, 데이터 대시보드와 어드민을 만들어 주세요." 당연한 수순이었습니다. 빅데이터팀은 대시보드를 만들 수 있는 엔지니어가 없으니 이전에는 시도할 수조차 없었던 일이었지요. 3)번을 해결하고 나니 바로 2)번을 해결할 수 있는 길이 열렸습니다. "PO님! 개발자를 지정해주세요!" 저는 추가 리소스를 배정받고 데이터 파이프라인 별 누수를 파악할 수 있는 정밀한 대시보드를 설계하여 운영하게 됩니다.
솔루션 각론: 역할 확장하여 다음 솔루션으로 이어주기
2)번과 3)번의 문제를 해결해가는 중이었지만, 1)번 담당자간 사일로(silo) 문제는 조금 다른 해결책이 필요했습니다. 대시보드가 생기면서 각 파이프라인 담당자끼리의 소통이 확실히 늘기는 했지만, 문제 해결은 오롯이 각 담당자 고유의 몫이었기 때문이지요. 대시보드의 통계를 통해 문제 유무를 한 눈에 파악할 수는 있지만, 세세한 원인을 밝히는 것은 또 한 차례 인고의 시간을 견뎌내야 합니다.
데이터 엔지니어들의 역할은 대고객 서비스 엔지니어들과 다릅니다. 서스테이닝 업무 효율을 위해 기획자가 흔히 생각하는 '일반적인 어드민'을 착착 만들기는 어렵습니다. Hadoop Echo, ElasticSearch 등 알려진 프레임워크를 주로 사용해야 하는데다, 관리형 클라우드 플랫폼을 사용하여 효율을 꾀하는 것은 전사적인 IT 전략 의사결정을 거쳐야 하는 문제였지요. 프로젝트는 중반 이후를 달려가고 있고, 근본적인 해결에는 큰 비용이 들었습니다. 모두들 기본 업무 외에는 디테일을 파고 들 환경이 뒷받침 되지 않아보였지만 데이터 결함은 수십가지의 디테일에서 나오는 것이 틀림없었습니다.
"왜 데이터가 이쪽으로 이동할 때 누수가 있어요?" "원인이 여러가지 있을 수 있어요. 메타정보가 있더라도 실제로 데이터를 다운로드 할 때 저작권 문제로 막힐 수도 있구요, 서비스 구조에 따라 우리 스크레이퍼가 기능을 못할 수도 있고..." "그 문제를 분류해놓았을까요?" "아뇨.. 추정은 되지만..ㅠ" 예상한대로 엔지니어들은 끝까지 데이터를 추적할 여력이 없었지만 대략의 원인은 추정하고 있었습니다. 서브 엔지니어가 되어야 되겠다! 이 결정은 프로덕트 매니저로서는 어쩌면 최후의 방법 같은 것이었겠네요.
이후 데이터 분석가 리더님과 엔지니어 동료의 도움을 받아 MySQL, HiveSQL, Python, CronJob 그리고 엑셀과의 씨름이 이어집니다. 주요한 목표는 개발자처럼 행동하는 것이 아닙니다. 1) 통계 데이터를 가공하여 유의미한 문제 패턴을 찾아내는 것, 2) 리소스를 꼭 들여야 할 데이터를 구분해내는 것이었습니다. 엔지니어에서 분석가에게 주요 과제를 위임하며, 양Quantity에서 질Quality을 고민할 수 있도록 임시 가교 역할을 수행하게 된 것이지요. 이후, 수집할 데이터에는 우선순위와 그 기준이 마련되었고, 중요한 데이터에는 총력을 기울이고, 비교적 덜 중요한 데이터는 과감히 리소스를 포기하게 됩니다. 대단한 관리 툴을 만들 수는 없었지만, 일 자체를 최적화 한 것이지요.
첫 프로젝트 투입 후, 여기까지 대략 8개월이 소요되었습니다. 물론! 앱은 중간에 무사히 릴리즈를 했지요. 그리고 성공하여 만인의 사랑을 받았답니다...하고 끝나면 좋았겠지만 ^^; 어디 인생이 그렇게 호락호락 한가요. ㅎㅎ
보람찬 맺음
이 프로젝트는 프로덕트 매니저인 제게 아래의 중요성을 가르쳐주었습니다.
1) 드러냄(Design)
프로젝트 구성원의 체력, 즉, 리소스가 부족하면 사일로와 멱살의 먹구름이 끼기 시작합니다. 리소스 부족은 조직의 한계, 의사결정의 한계, 역량의 한계 등 다양한 문제에서 비롯되지만 이런 문제가 없는 프로젝트는 없습니다. 아니, 오히려 천편일률적으로 이런 문제가 있다고 볼 수 있겠네요. 프로덕트 매니저는 시기별로 적절하게 문제를 골라내어 적절한 방법으로 드러냅니다. 그러나 말로 드러내는 것과 디자인으로 드러내는 것은 다릅니다. 프로덕트 매니저는 디자인 해야 합니다.
2) 관점(focus)의 전환
지금 당장 필요한 것이 무엇일까요? 문제를 골라내기, 새로운 리소스의 배정, 툴의 개발, 빵꾸난 역할 메우기, 양적인 과제에서 가치의 과제로 이동...등, 프로덕트 매니저는 적시에 적절한 사안으로 주의를 환기합니다. 여기서 내가 꼭 이런 것까지 해야해? 라는 질문은 통할 데가 없습니다. 그렇지만 반드시 잊지 말아야 하는 것은 누군가를 대체하려는 목적이 아니라 제품을 중심으로 자신의 역할을 카멜레온처럼 바꿔야 한다는 것입니다. 그걸 위해 코딩을 해야 한다면, 가끔은 해야지요.
오늘은 여기까지 할게요.
또 재미있는 일화를 들고 돌아오겠습니다!
