SQL을 알아야 하는 이유
나도 프로그래밍을 배워야 하나?
실리콘밸리에 있으면 하루에도 몇 번씩 이런 고민을 한다. 업계 특성상 개발자는 존중받고 대우도 좋다. 창업이 목표인데 프로그래밍을 할 줄 모르면 프로토타입도 만들 수 없다는 생각에 위축되기도 한다. 특히 실리콘밸리에서는 창업할 수 있는 역량이 프로그래밍과 직결한다는 느낌을 받는다.
유데미(Udemy)나 코세라(Coursera)와 같은 온라인 교육 플랫폼에서 몇몇 파이썬 강의를 구입했지만 흥미가 없어 이런저런 핑계로 2주를 넘기지 못했다.
파이썬은 배우지 않아도
SQL은 배워야 한다
내가 찾은 절충안은 파이썬 같은 프로그래밍은 배우지 않더라도 데이터를 다루는 SQL은 배우자는 것이다. 소프트웨어 회사는 사용자와 앱에 대한 데이터를 모으기 때문에, 앱의 버튼을 클릭한 사람 수나 사람들이 앱에 머무른 시간 등 필요한 정보를 SQL로 뽑아낼 수 있다. SQL을 알면 다른 팀이나 동료의 도움 없이도 유연하게 정보를 얻을 수 있다.
데이터를 추출할 수 있으면 무궁무진한 분석을 할 수 있다. 위 이미지는 런던의 타워브리지 폐쇄로 인한 트래픽 변화를 데이터로 시각화한 것이다. 2016년 말 타워브리지는 3개월 동안 폐쇄되었는데, 이로 인해 매일 2만 대가 넘는 차가 통행 제한을 받았다. 그리고 이에 대한 데이터 분석으로 템즈 강을 기준으로 남쪽으로 이동할 때 폐쇄 전보다 시간이 약 65% 증가하고, 북쪽으로 이동할 때는 시간이 약 30% 증가했다는 데이터를 얻을 수 있었다.*
* 관련 글: Examining the Impact of the London Tower Bridge Closure (출처: medium.com)
이런 데이터 분석으로 드라이버와 라이더가 어떻게 움직여야 더 많은 고객을 태우고, 어떻게 시간을 절약해 목적지로 이동할 수 있는지 도울 수 있다.
내가 SQL을 배우게 된 계기는 매주 사업지표를 모니터하고 보고해야 하기 때문이었다. 사업지표가 급등하거나 하강했을 때 그 이유를 분석해야 하는데, 데이터를 다루는 팀에게 물어봐야 하니 업무의 속도가 붙지 않았다. 처음에는 어디서부터 시작해야 할지 몰라 SQL을 잘하는 동료가 쓴 쿼리(query)*를 수정해 데이터를 뽑아봤지만 오류가 많았다.
* 프로그래밍 언어를 위한 명령어
프로젝트 매니저로 일하는 요즘은 SQL을 쓰는 일이 드물다. 그래도 잊지 않기 위해 매일 오후 다섯 시부터 한 시간 동안은 SQL을 사용하는 업무를 하려고 일정을 비워둔다. 데이터를 뽑아야 하는 일이 있으면 직접 하려고 한다. SQL을 학습하는 최고의 방법은 꾸준히 사용하는 것이기 때문이다.
운영업무직에 지원할 때 SQL을 할 줄 알면 플러스 점수를 받는다. 게다가 배우기 어렵지 않다. SQL에 관심이 있다면 코세라의 Managing Big Data with MySQL 과정을 추천한다. 옵션으로 청강(Audit)을 선택하면 무료이고, 한국어 자막도 있다. 나는 스터디파이(studypie)라는 온라인 교육 스타트업을 통해서 SQL스터디 그룹을 운영하는데, 이런 스터디 그룹에 참여하는 것도 좋은 방법이다.
개발팀과 일하기: 해결책이 아닌 문제를 말하라
우버에서 처음 1년은 미국 동부를, 두 번째 해는 싱가포르 지사로 옮겨가 아시아 지역을 담당했다. 이렇게 한 지역을 책임지는 운영자로서 자나 깨나 이 지역에서 어떻게 하면 서비스가 더 나아질지 고민하는 건 당연했다.
당시 우버 드라이버(운전기사) 앱은 아시아 지역에서 사용하기에 흔한 말로 '무거웠다'. 실리콘밸리 본사의 개발자가 쓰는 아이폰에는 이 앱이 잘 돌아갈지 모르겠지만, 아시아에서는 아니었다. 인터넷 속도가 빠르지 않은 곳이나 드라이버의 휴대폰 사양이 좋지 않아도 앱을 원활하게 사용할 수 있도록 '가볍게' 만들 필요가 있었다.
매일 본사에 있는 개발팀에 이 문제를 알리기 위해 노력했다. 새벽 3시에도 본사에서 업무에 대해 이야기하자고 하면 현지 시각을 말하지 않고 미팅을 했다. 본사로 출장을 가면 아시아 지역의 특수함을 알리고자 설명회를 열었다. 우버 싱가포르 티셔츠를 준다고 사람들을 꼬셔 모아 이 지역 드라이버가 필요하다고 피력했다. 2년 동안 짝사랑을 제대로 했고, 나는 내가 잘하고 있다고 믿었다.
본사로 돌아와 개발팀과 협력하며 그때의 일을 돌이켜보니 나는 개발팀과 일하며 문제를 해결하는 방식을 잘 몰랐다. 보이지 않던 짝사랑의 결실은 싱가포르를 떠나 우버 본사의 우버 프레이트팀에서 일하기 시작했을 때 맺을 수 있었다. 개발팀 매니저를 찾아가 운영팀으로서 어떻게 하면 도움이 될 수 있냐고 물은 후였다.
개발팀 매니저는 이렇게 전했다.
개발자는 고객이 어떤 점을 불편해하는지 알고 싶어 해.
이전까지 내가 생각하는 해결책을 말했다면 지금부터는 문제점이 무엇인지 설명하게 된 거다.
나는 고객의 피드백을 개발팀에 전달하는 미팅을 매달 열기로 했다. 사용자가 보낸 피드백을 토씨 하나 빼지 않고 캡처해 테마별로 정리했다. 이렇게 해야 더 피부에 와 닿을 거라고 생각했다.
나중에 사용자의 피드백을 바탕으로 추가해야 할 기능에 대한 이야기를 개발팀과 나누었을 때, 개발팀으로서는 이미 미팅을 통해 인지하고 있던 문제였기 때문에 모두가 공감한 상태에서 문제를 해결할 수 있었다.
개발팀은 문제의 해결책보다
문제점을 자세히 알길 원한다
개발팀에게는 문제의 해결책을 설명하는 것보다 고객이 느끼는 불편에 대해 자세히 설명하는 것이 문제를 더 빨리 푸는 방법이라는 걸 배웠다.
다음의 영상을 보자. 일명 '개발자라면 봐서는 절대 안 될 영상'이다.
영상에서처럼 관리자는 대개 문제를 해결하는 과정을 모르고 개발자에게 해결을 요청한다. 그러나 운영업무 등을 하는 관리자는 개발은 모르더라도 고객이 원하는 것과 회사에 어떤 것이 중요한지는 안다. 매일 고객과 대화하고 사업지표와 핵심성과지표를 모니터하기 때문이다.
그래서 이제는 개발팀과 이야기할 때 해결책에 대해 이야기하지 않는다. 고객이 무엇을 원하는지, 이 문제가 해결되면 비즈니스에 어떤 임팩트가 있는지 우선순위를 매겨 이야기한다. 운영팀에서 A/B 테스트를 할 수 있으면 결과도 정리한다.
그리고 하나 더. 개발 스케줄을 이해하고 채근하지 않는다. 내가 생각하기에 참 간단해 보이는 기능(feature)이라도 변수에 따라(코드 베이스가 복잡하다든가) 몇 주, 몇 달이 걸릴 수 있기 때문이다. 또 개발팀은 문제를 파고드는 데 집중할 시간이 있어야 한다고 해서 일의 흐름이 끊기지 않게 미팅을 잡을 때도 책상을 떠난 때인 점심 전후로 한다.
영업운영팀과 일하기: 다른 업무를 이해하는 방법
우버 프레이트에 일하면서 올해 처음으로 영업운영팀과 일하게 되었다. 처음 영업운영팀과의 미팅에서 내 업무에 필요한 CRM에 새로운 기능을 넣어달라고 조심스럽게 요청했는데 반응이 좋지 않았다. 그는 이렇게 말했다.
영업운영팀은 세일즈포스(Salesforce)*를 커스터마이즈(customize)하는 팀이 아니야. 너 지금 영업운영팀과 영업팀의 업무를 모르는 것 같은데, 영업에 대한 책을 읽어보는 건 어때?
* 고객관리시스템 중의 하나. 세일즈포스에서 만든 동명의 소프트웨어
한 대 맞은 것 같았다. 이전까지 B2C 서비스를 담당했기에 B2B 영업에 대해 아는 것이 많지 않다는 것에 찔리면서도, 그래도 함께 일하는 동료가 가르쳐주지 않고 책을 읽어보라고 하자 자존심이 상했다. 뭔가 이유가 있겠지 하고 책을 추천해달라고 했다.
그렇게 오기로 읽은 트리시 벨투치(Trish Bertuzzi)의 <영업개발안내서(The Sales Development Playbook)>란 책은 확실히 도움이 되었다. 이 책은 영업과 영업운영에 대해 설명한다. (우버 프레이트와 같은) B2B 소프트웨어 회사의 성공은 새로운 고객을 얼마나 효율적으로 유치하느냐에 직결하는데, 고객을 유치하는 영업팀의 일과 영업팀의 구성원을 어떤 방식으로 배치해야 할지 설명한다.
회사마다 조금씩 다르겠지만 영업팀의 성과는 몇 건의 계약을 따오느냐에 달려있다. 대개 성과급제이기 때문에 성과에 따라 월급과 보너스가 책정된다. 영업운영팀은 이런 영업팀과 다르다. 영업팀과 다른 팀에 속해 있으면서 영업팀에게 가이드라인을 주는 역할을 한다.
예를 들어 영업팀이 만나야 할 비즈니스 리스트를 정해주고, 팀원에게 매 분기 달성해야 하는 성과 목표를 정해주면서 달성 여부에 따라 월급과 보너스를 책정한다. 세일즈포스에 기능을 추가하고 빼는 '영업지원'의 일을 하지 않는다. 이런 걸 알지 못한 나의 태도로 중요한 이해관계자와의 첫 미팅이 불편해진 것은 당연했다.
알고 보니 책을 추천한 담당자 역시 영업운영 업무를 시작한 지 1년밖에 되지 않았다. 본인 역시 업무를 시작하는 데 독서가 가장 큰 도움이 되었기에, 순수한 마음으로 책을 추천한 것이었다. 책을 읽고 감상을 전하면서 이제 업무를 이해하고 있음을 보여준 다음부터 우리 팀과의 협업은 훨씬 좋아졌다. 그리고 나 역시 그 책을 팀원에게 종종 추천한다.
운영업무를 한다면 여러 부서와의 협업을 원활하게 진행하는 '최고의 이해관계자'가 되어야 한다. 그러기 위해선 상대방의 업무를 정확히 이해해 그 팀 성과와 우리 팀 성과의 교집합을 찾아야 한다. 이렇듯 다른 부서의 일을 이해하려고 노력할 때, 내 업무를 존중받을 수 있는 건 덤으로 얻는 또 다른 성과다. 운영업무의 스페셜리스트가 되고 싶다면 이 점을 기억해야 한다.
조직에 필요한 일과 개인이 하고 싶은 일의 교차점
우버에서 커리어를 키우면서 내가 가장 좋아하고 잘하는 업무는 무엇일까에 대해 고민한다. 데이터 분석에 뛰어난 동료는 프로덕트 운영팀이나 데이터 분석팀으로 이동하고, 더 큰 팀을 이끄는 제너럴 매니저가 되고 싶은 동료는 한 팀에 오래 있으면서 한 계단씩 승진하는 것을 본다.
반면 나는 '고 투 마켓(Go-to-market) 전략'*으로 새로운 서비스를 론칭하는 것과 고객과 매일 소통하면서 서비스를 발전시키는 업무를 하는 게 즐겁다. 아무것도 없는 캔버스 위에 마케팅, 온보딩 프로세스, 가격 정책을 하나씩 그려가는 일에 희열을 느끼고, 내가 꾸린 팀이 자리를 잡고 운영이 안정화되면 다시 출발선에서 새롭게 시작할 서비스에 대한 기회를 엿보게 된다.
* 새로운 서비스로 어떻게 목표 고객에게 다가가 경쟁 우위를 확보할 것인지 고민하는 전략이다.
그런데 하고 싶은 업무가 있더라도 회사에 그 일이 필요하지 않으면 소용이 없다. 이때 상사인 매니저와 1:1 면담이 도움이 된다. 나는 면담에서 내가 하고 싶은 업무가 어떤 것이고 그 일을 하는데 내가 왜 적합한 사람인지 주기적으로 말했다.
2018년 초 우버 프레이트팀에서 화주(shipper)를 대상으로 한 운영팀이 생긴다는 이야기가 있었다. 우버 프레이트는 화물을 배송하기 원하는 화주와 트럭 운전기사를 연결하는 서비스인데, 회사에서 화주의 온보딩을 관리하고 서비스의 성장을 이끄는 운영팀이 없었다. 나는 2년 동안 드라이버 관련 업무만 했었다.
이제는 새로운 도전을 하고 싶어서 몇 달 동안 매니저에게 화주 운영팀을 시험 운영하게 되기로 결정된다면 내가 그 업무를 맡고 싶다고 말했다. 그래서 올해 1월 부터 화주 운영팀을 직접 구성하고 4명의 팀원을 모집해 우버 프레이트의 B2B 소프트웨어를 론칭하는 업무를 맡았다. 우버 입사 후 가장 보람된 프로젝트를 해낼 수 있었던 것은 내가 하겠다고 먼저 손을 들었기 때문이다.
조직이 필요로 하는 일과 개인이 하고 싶은 일의 교차점을 찾는 첫 번째 단계는 본인이 어떤 업무를 가장 잘하고, 어떤 업무를 하고 싶은지 파악하고, 그것을 적극적으로 어필하는 것이다.
나도 팀장으로 2년간 일하면서 7~8명의 팀원을 관리했다. 팀원 스스로 자신이 어떤 업무를 하고 싶고, 어떤 분야로 발전하고 싶은지 명확하게 알고 그것을 말해줄 때, 매니저로서는 기회가 있을 때마다 밀어주게 된다.
에릭 슈미트는 구글 오퍼를 두고 다른 회사와 고민하는 셰릴 샌드버그에게 "로켓에 자리가 나면 묻지 말고 올라타라"라고 했다. 여기에 한 마디를 더한다면 로켓도 좋지만, 로켓에서 비행을 하고 싶은지, 정비를 하고 싶은지 알 수 있다면 우주를 나는 일이 더 즐거워질 것이다.