Easier said than done

요새 연말 모임이 잦다 보니 평소에 보지 못했던 사람들과 이런 저런 이야기를 나누는 시간이 많아졌다. 그러다가 가끔 대화가 서로 하는 일, 혹은 최근 이슈가 되는 일들이 회자되곤 하는데 이럴 때 마다 꼭 크게 훈수를 두시는 분들이 있다. ‘그건 이렇게 하면 되지’, ‘내가 해봐서 아는데, 그건 이러이러 한거야’, ‘에이~ 그건 바로 저렇게 풀면 되는거 가지고… [회사]는 그것도 못하나?’

제 3자가 보기엔 문제가 단순해 보이고 왜 그걸 풀지 못하는지 의아해 하는 경우가 있다. 물론 정말 간단한 해결책이 있는데 완전 깜빡하고 있는 경우도 있지만, 대부분의 경우는 말은 쉽지만 실제로 문제를 해결함에 있어 밖에서 보는 사람은 절대 알 수 없는 매우 애매한 뉘앙스 및 복잡한 문제들이 도사리고 있어서 술자리에서 가볍게 얘기하는 수준으로 문제를 해결할 수 있지 아닌 경우가 대부분이다.

예를 들어 ‘가짜 뉴스’가 2017년의 큰 이슈 였는데 많은 사람들은 ‘딱 보면 가짜인지 아는데 그걸 왜 페이스북이랑 트위터에서 못 잡아내는거야?’라고 불평을 한다.

페이스북이랑 트위터에 다니는 똑똑한 수재들이 가짜 뉴스가 정말 ‘딱 보면 알 수 있는’ 것이었으면 왜 여태껏 해결을 못했겠는가. 근본적으로 가짜 뉴스는 ‘딱 보면 알 수 있지’ 못하거니와, 많은 인터넷 플랫폼 사업자들은 컨텐츠의 내용의 진위를 (가짜 뉴스, 댓글 조작 등) 평가 및 판별하는데 있어 크게 사용자 제보, 머신러닝, 그리고 실제 인력을 투입하는데, 이런 다양한 기법 및 최첨단 기술을 활용해도 다음과 같은 뉘앙스와 복잡함으로 문제 해결이 용이하지 못하다:

사용자 제보

혹자는 사용자들이 ‘신고하기’로 제보된 뉴스를 골라서 거르면 가짜 뉴스 문제가 해결될 것이라고 생각한다. 문제는 가짜 뉴스에 현혹된 사람들은 그 뉴스를 믿기에 ‘신고하기’를 누르지 않는다. 되레, 그들은 ‘좋아요’ 혹은 ‘추천’을 마구 누를 가능성이 더 높다. 또한 이런 플랫폼들은 보통 추천 알고리즘으로 컨텐츠를 사용자에게 개인화 해서 보여주기 때문에 설령 ‘딱 보면 가짜인지 아는’ 사람들이 있더라도 그들에겐 이런 가짜 뉴스가 보여지지 않을 가능성이 높다.

머신러닝 적용

머신러닝이 실리콘밸리에서 큰 유행처럼 번지고, 또 그 그대치에 걸맞는 결과들이 나오면서 (예: 알파고) 가짜 뉴스 파악에도 머신러닝이 많이 적용되고 있다 (페이스북 예). 많은 사람들은 머신러닝이 가짜 뉴스를 포함 많은 문제점들을 해결해 줄 것이라고 생각하지만 머신 러닝은 항상 precision 과 recall 이라는 제한이 존재한다 (참고: precision = 예측한 결과가 실제 맞는 경우, recall = 검출율; 모든 ‘true’ 중 맞게 예측한 정도). 99% precision이 있는 가짜뉴스 판별 시스템을 만든다고 해도 1%의 가짜 뉴스는 미꾸라지 처럼 빠져 나가고, 또 이런 높은 precision의 경우엔 recall이 상대적으로 낮아 가짜 뉴스를 막는데 큰 도움이 되지 못한다. 최대한 많은 가짜 뉴스를 걸러내기 위해 recall을 높이면 precision이 낮아지므로 가짜 뉴스가 아닌 무고한 뉴스들도 가짜 뉴스를 걸러내는데 희생(?) 당할 수 있는 위험이 있다.

실제 인력 투입

어떻게 보면 가장 확실한 방법은 ‘전수 조사’를 하는 것이다. 하지만 페이스북 같은 거대 플랫폼에서 올라오는 모든 뉴스들을 사람이 일일히 팩트체크를 하는 것은 현실적으로 불가능하다. 설령 전수조사가 가능하다고 해도 실제로 ‘딱 보면 아는’ 가짜 뉴스가 얼마나 될까? 또한 개개인의 조사자들이 가진 가치관과 지식의 차이 때문에 매우 일관적이고 공편하게 가짜뉴스에 대한 판단을 내리는 것이 정말 어려울 것이다.

.

영어 표현 중에 ‘easier said than done’ 이라는 말이 있다. 간단히 말해 ‘말이 쉽지’ 라는 뜻. 실제로 안에서 일어나는 일을 알지 못하면 모든게 쉽게 느껴질 수 있다. 나 역시 한 때 어느 제품이나 서비스를 사용하며 안좋은 경험이 있을 때 마다 ‘아 이런 회사가 이런것 기본적인 것도 못하네’ 라고 매섭게 비평을 할 때가 있었는데, 막상 ‘내부자’가 되어보니 정말 ‘easier said than done’임을 실감하며 나의 과거 모습이 부끄러워 진다.

위에 연말 모임의 분위기를 살짝 망치는 ‘훈수쟁이’가 되지 않기 위해서라도 많은 문제들이 ‘easier said than done’임을 인정하고, ‘정답’을 제시하는 것 보다 문제를 해결하는데 도움이 되는 새로운 접근 방식, 그리고 관련된 경험을 공유하는 것을 의식적으로 노력해야겠다.

제품 관리의 예술 (The Art of Product Management)

https://pixabay.com/en/ethics-right-wrong-ethical-moral-2991600/

테크 회사의 제품 담당자 인터뷰를 준비하는 분들이 가끔 조언을 얻고자 지인을 통해 내게 연락이 오는 경우가 종종 있다. 거의 모든 분들이 가장 두렵고 알고 싶어하는 것은 바로 ‘코딩 할 줄 알아야 되나요?’의 질문에 대한 답변. 이 질문을 조금 일반화 시키면 제품 담당자가 되기 위해 기술적인 역량이 필요한가에 대한 물음일 것이다. 코딩 까지는 아니더라도 (나의 생각은 여기에) 일단 제품 담당자라고 하는 직군은 논리적 사고와 계량적인 방법론들을 이용하여 사용자들이 원하는 제품을 정의하고 성공을 위해 팀을 이끌어 나가는 집단이라고 일반적으로 정의하곤 한다.

이에 제품 담당자가 갖추어야 할 계량적이고 기술적인 소양에 대해서 최근 십여년 간 많은 블로그와 서적을 통해 기술되었고, 이렇게 생성된 정보들이 제품 담당자들 사이에, 그리고 제품 담당자가 되고 싶어하는 자들에게 널리 알려지게 되었다. 예를 들어 그로스해킹과 A/B 실험의계량적인방법론들, 기존의 소프트웨어 개발 주기의 폭포(waterfall) 모델에서 상황의 변화에 민첩하게 대응할 수 있는 애자일(agile) 기법의 정수로 알려진 스프린트(sprint) 모델 등, 간단한 구글 검색 혹은 아마존 서적 검색을 하면 자세한 정보를 누구나 알 수 있게 되었다. 심지어 이런 기법들을 집대성하여 제품 담당자 취업대비서까지 나온 상황이다.

이런 책들과 블로그를 읽다 보면 A/B 실험에 대한 직관력을 키워서 좋은 성과를 달성하고 스프린트 기법을 통해 제품을 빨리 출시하고 개선하는 법을 통달하면 훌륭한 제품 담당자가 될 것 같은 느낌이 든다. 하지만 실제로 제품 담당자의 커리어를 걷다보니 훌륭한 제품 담당자가 되기 위해서는 제품 관리의 예술적인 (= the art of product management) 부분이 위의 계량적인 방법론을 숙달하는 것 못지 않게, 혹은 더 중요한 역할을 한다고 느낄 때가 많이 있다.

제품 관리의 예술적인 부분? 제품 관리의 예술적인 부분이란 계량화나 객관적인 비교가 어려운, 제품의 심미적인 그리고 가치관에 관한 영역이라고 할 수 있다. 어느 것이 더 아름다운가? 어느 것이 더 가치있는 것인가? 어느 것이 더 옳은 것인가? 이런 것을 판단하기엔 계량적인 접근 방법이 어렵거나 맞지 않을 때가 대부분이다 — 특히 가치와 윤리에 관련된 제품 결정을 해야할 때는 더더욱.

예를 들어 어느 화상채팅 앱을 특정 사용자들이 섹스팅 앱으로 사용하고, 그들의 인앱 매출이 상당한 부분을 차지한다면 그 해당 제품 관리자는 어떠한 결정을 내려야 할까? 플랫폼 자체는 중립성을 가지고 있고 그 플랫폼을 이용하여 나쁜 행위를 한 사람들의 잘못이라고 생각할 수 도 있다. 더 나아가, 성인 사이의 동의하에(consent) 이루어진 일이라면 전혀 문제가 될 일이 아니라고 까지 할 수 있다. 상황을 조금 더 엮어보자. 만약 해당 집단에서의 인앱 매출을 포기했을 때 회사를 운영할 수 없을 정도의 타격이 온다면? 그럼에도 불구하고 제품 담당자로써 내 제품을 통해 그러한 행위가 이루어지는 것이 내 양심에 ok 인가? 또 내 제품의 비전과 일치하는가? 비전과 일치하는 것이 의미가 있기라도 한 것인가?

또 다른 예로, 어느 커뮤니티 사이트 플랫폼에서 혐오 단체가 온라인 커뮤니티를 형성하고 이 커뮤니티를 이용해 어느 특정 집단을 비하, 모욕, 공격을 한다면, 그 커뮤니티 사이트 제품 담당자는 어떠한 판단을 해야할까? 마찬가지로 플랫폼의 중립성이라는 논리는 이용하여 용인할 것인가 아니면 제제를 가할 것인가? 제제를 가하면 또 다른 형태의 억압이 아닌가? 어느 것이 옳은 결정인가?

위 두 예 모두 대중들이 일반적으로 생각하는 가치관/윤리관과 제품 담당자의 성공 지표(매출, 사이트 접속/사용량 등)가 대립하고 있는 경우이다. 제품의 성공 지표들을 기준으로 A/B 실험을 진행한다면 섹스팅 앱과 혐오 단체 커뮤니티를 유지시켜야 하는 결론이 나올 것이다. 극단적인 예를 들어 너무 당연한 결정을 어렵게 포장 했다고 할 지 모르겠지만, 실제 상황들은 더 복잡하게 얽히고 뉘앙스가 가득하여 이런 상황에서의 의사 결정이 여의치가 않을 때가 너무나 많다.

나 역시 제품 담당자로서 가장 어려웠던 시기들은 이런 가치관과 윤리가 엮인 제품 결정을 내려야 하는 경우였는데, 이런 고난(?)을 극복하는데 개인적으로 도움이 되었던 것은 마이클 샌달 교수의 ‘정의란무엇인가’ 강의를 다시 듣는 것이었다. 강의에서 공리주의에 대한 이야기나 나오는데 ‘greatest good for the greatest number’의 사고 방식이 현재 테크회사의 데이터를 기반으로 하는 의사결정 저변에 깔려있는 가치라고 생각된다. A가 B 집단 보다 10% 결과가 좋으면 A 방식을 택하였을 때 피해가 보는 사람이 있더라도 전체로 봤을 때 A집단의 효용이 높기 때문에 A를 선택하는 것이 옳다는 그로스 해킹의 기본 접근 방식이 바로 이런 것이 아닌가. 진부하지만 너무 명쾌한 공리주의에 대한 반론 ‘그렇다면 콜로세움에서 사자의 먹이감이 된 몇 명의 그리스도 인의 죽음은 몇 만 명의 로마인들의 즐거움을 위해 정당화 할 수 있는가?’ 역시 위 두 예의 딜레마와 일맥상통한다.

‘정의란 무엇인가’ 수업을 듣거나 책을 읽은 사람은 알겠지만 사실 이런 윤리적/가치관적인 문제들에 대한 정답은 없다. 위 예에서 나온 고민들도 어떻게 결정을 내리던 옳은 결정이라고 하기엔 무리가 있다. 단, 어느 확고한 가치관과 논리를 기반으로 어느 제품에 대한 의사 결정을 하고, 동시에 그런 결정을 내림에 있어서 올 수 있는 한계점들에 대해 고민과 해결책들을 제시하는 것이 바로 제품 관리의 예술적인 부분이라고 생각한다. 이런 깊은 생각을 하고 데이터가 답해 줄 수 없는 문제들에 대해 ‘신의 한 수’의 결정을 내릴 수 있는 제품 담당자들이 정말 고수인 것이다.

결론: Product management is as much of an art as it is a science.

공리주의의 아버지 제레미 벤담 형님과 함께 (실제유골임)

.

베끼기, 가짜, 그리고 소비자 태도에 대한 생각

올해 테크 및 스타트업 업계에서는 유난히 베끼기와 가짜에 관련한 뉴스들이 많은 한 해 였다. 가짜 뉴스, 스타트업끼리, 또 정부의 스타트업 아이디어 베끼기 논란 등. 개인적으로도 직/간접적으로 이와 관련된 문제를 겪었는데 이를 통해 베끼기와 가짜 논란의 이유에 대해 깊게 생각하고, 또한 조금 흥미로운(?) 소비자들의 반응을 관찰할 수 있는 기회가 되었다. 이와 관련하여 나의 생각을 정리.

*본론에 들어가기에 앞서 ‘IANAL’ (I am not a lawyer – 나는 변호사가 아닙니다)라는 단서와 함께 개인적인 생각을 적어둔 것라는 점을 명시해 둠.*

베끼기와 가짜의 문제는 크게 다음의 세 가지의 MECE 하지 않는 이유에서 나온다고 생각한다. 지적재산권 침해, 가장(impersonation)으로 속는 소비자, 그리고 상도/상생의 가치관 부재.

지적재산권 침해 => 베끼기

지적재산권 침해는 남이 가지고 있는 상표권이나 지적재산을 무단으로 도용하는 것이다. 예를 들어 유치원 홍보물에 뽀로로 캐릭터를 사용하는 경우. 많은 경우는 지적재산권에 대한 깊은 생각 없이 순진(?)하게 법을 범하게 되는 것이지만 악의적인 의도를 가진 사람들을 남의 지적재산의 도용을 통하여 자신의 상품과 서비스가 유명한 브랜드와 연관되어 있거나 그들이 보증하는 것 처럼 보이게 한다. 더 심한 경우엔 원천 기술을 그대로 베껴 지적재산의 원 보유자가 가진 경쟁 우위를 무마시키는 사태를 야기하기도 한다. 다행인 것은 지적재산권 침해는 법적으로 보장을 받을 수 있지만, 동시에 절차가 매우 길고 복잡할 수 있기 때문에 (예: 삼성 vs 애플 특허 분쟁) 본질에만 집중하고 빨리 움직여야 하는 스타트업 같은 경우는 지적재산권 침해 문제에 엮이는 것 자체가 골치 덩어리이다.

가장(impersonation)으로 속는 소비자 => 가짜

가짜를 진짜처럼 가장하여 판매하는 것에 대해서는 순진한 실수가 있을 수 없다. 가짜를 진짜처럼 가장하여 판매하는 자들의 의도는 분명하다. 소비자를 속이는 것, 혹은 소비자를 통해 더 많은 대중을 속이는 것. 이 때문에 가장(impersonation)이 가짜/베끼기의 문제 중 가장 비열하고 악질적이다.

그런데 이런 가짜에 대한 소비자의 태도가 참 재미있다. 명품 브랜드의 경우 소위 ‘A급 짝퉁’이라고 암암리에 알려주고 판매할 경우엔 소비자들은 생각보다 호의적인 반응을 보인다 (최소한 한국에서는). 오히려 진짜에 더 가까운 가짜일수록 그 실력을 인정해 주면서 구입하려고 한다. 명품 브랜드를 소유한 척 함으로써 남에게 보여지는 (허위) 경제력 및 품위는 가지고 싶으나 실제로 그런 것을 이룰 수 없는 괴리감을 탈출하려는 시도인지, 쓸데 없이 ‘비싸기만 한’ 제품에 대한 반감인지 모르겠다. 동시에 가짜 휘발유, 가짜 자동차 부속 등 사치와 심미적인 것이 아닌 것들에 대해서는 같은 소비자들이 정 반대의 태도를 보인다.

소비자의 태도가 어찌하던 진짜로 가장한 가짜는 창조자(original creator)에게 너무나 치명적이다. 알고도 가짜를 사는 소비자층이 형성되면 기술과 디자인을 선도하기 위해 모험을 감행한 수고의 보상이 사라져 창조자들은 큰 경제적인 피해를 입는다. 감쪽같이 소비자들을 속여 가짜를 판매하는 경우에는 소비자들은 사기를 당한 셈이 되고, 창조자에겐 매출 피해는 물론, 가짜 제품의 낮은 사용자 경험이 창조자의 브랜드에 악영향을 끼치는 lose-lose 상황이 형성된다.

스타트업에 그나마 다행인 것은 이런 가짜가 흔하게 나오지는 않는다는 점. 단, 피싱 (phishing) 및 악성 소프트웨어들이 진짜로 가장하여 소비자를 위험할 위험이 있으니 항상 주의해야 한다.

상도/상생의 가치관 부재 => 베끼기 & 가짜

어느 선을 넘어야 가짜이고 베끼기인가. ‘아 다르고 어 다르다’고 해서 나훈아와 너훈아가 전혀 관련이 없는 두 인물이라고 할 수 있을까? 장르의 유사성, 포맷의 벤치마킹 등으로 용인될 수 있는 부분은 어디까지일까?

몇 초 후 사라지는 비디오 메시지라는 재미있는 포맷을 통해 미국 청소년들을 사로잡은 스냅챗. 올 해 초 페이스북의 대항마로 주목받아 화려하게 주식시장에 데뷔하였다. 그것을 본 페이스북은 보란듯이 인스타그램에 스냅챗의 핵심 기능들을 그대로 베껴서 구현, 10억명이 넘는 인스타그램 사용자들에게 추가로 스냅챗을 사용할 이유를 없애버렸다. 케빈 시스트롬은 뻔뻔하게(?) 이런 새로운 메시징 포맷을 선구한 스냅챗이 멋지다는 멘트까지 날리기도 하였다. 아니나 다를까, 수 달 만에 인스타그램 내에서 스냅챗 유사 기능을 사용하는 사람들의 숫자가 (DAU/MAU) 스냅챗을 월등히 능가하게 되었다. 언론들은 Snapchat copycat (“가짜 스냅챗”) 이라는 수식어를 쓰면서 대기업이 작은 회사를 고사시킨다고 비난했지만, 위의 지표에서 보듯이 사용자들은 굳이 마다하지 않는 듯 한 사용 패턴을 보였고 주가는 이를 반영하였다.

한국에서는 구닥 – 스냅킥, 라마마 – 타로냥 등의 업체들이 위와 비슷한 논란들이 있었는데, 이 논란들은 모두 포맷을 참고한 (혹은 서비스를 홀딱 베낀) 측의 사과와 서비스 중단으로 마무리 되었다. 포맷을 참고 했다고 굳게 믿는다면 인스타그램 처럼 욕을 먹더라도 묵묵히 뚫고 나가지 못해서 억울한 면이 있을 것이고, 정말 악의적으로 잘 나가는 (나갈 것 같은) 서비스를 표절 하였다면 한국의 스타트업 커뮤니티의 자정 능력이 빛을 발한 것이다.

그 진실이 어떠하던 결론적으로 이런 베끼기와 가짜의 경계선에 있는 상황들에 대한 가치 판단은 정말 어렵다. 하지만 이 모든 상황에서 알 수 있는 것은 ‘포맷 인용자’들의 상도 및 상생의 가치관이 없어 보인다는 점. 물론 가치관 자체를 어떻게 정의하냐에 따라 일정 부분은 비판의 대상에서 제외할 수 있겠지만 전반적으로 ‘시장 기회가 보이고 경쟁자가 하던 것을 베끼던 포맷을 참고하던 법적인 문제가 없기 때문에 우리도 해야겠다’라는 사고 방식이 컸던 것 같다. 개발사들은 자신들이 악의적인 의도가 없고 상도와 상생의 의지가 있다고 한다면 포맷을 참고하는 데 있어서 한 번 더 생각해 보도록 해야할 것이다.

.

그로스 해킹 – 웹사이트 A/B 실험에 대한 7가지 법칙

몇 달 전 ‘그로스해킹 – 이보다 더 과학적일 수 없다’ 라는 포스팅을 통해 계량적으로 접근하는 그로스 해킹이 ‘논문’ 형식으로 발표 된다는 사실을 소개한 적이 있는데, 며칠 전 내가 예전에 다녔던 링크드인과 그 회사를 인수한 마이크로소프트에서 일하는 데이터 과학자들이 ‘웹사이트 A/B 실험에 대한 7가지 법칙’이라는 논문을 2014년 KDD 학회에서 발표한 자료를 접하게 되었다. 비록 몇 년 지난 자료지만 지금도 충분히 적용될 수 있는 것 같아 내 경험을 덧붙여 짧게 정리해서 공유.

(참고: 여기서 ‘법칙’은 rule of thumb, 즉 ‘어림잡은, 혹은 대략 적용되는’ 법칙이라고 해석하면 됨)

1. 작은 변화가 주요 지표에 큰 변화를 줄 수 있다

나의 그로스 해킹 시리즈에서 반복적으로 언급했지만 그로스 해킹의 핵심은 속도감 있게 많은 양의 실험을 수행하여 (홈런이 아닌) 단타로 점수를 내는 것이다. 많은 실험을 빨리 실행하기 위해서는 코딩을 적게 해야하고, 코딩을 적게 하려면 제품과 사용자 경험을 가급적이면 최소한으로 바꾸어야 한다. 이렇게 자주 ‘값 싼’ 실험을을 계속적으로 하다보면 ‘어쩌다가 걸려서’ 홈런이 나오는 땡큐한 상황이 간간히 나올 때가 있다. 논문은 MSN 웹사이트의 링크를 ‘새 탭에 보이기’, 그리고 Bing 검색 엔진의 검색 결과 색깔 실험이 그런 좋은 예라고 언급한다. 나 역시 링크드인에 있을 때 Upgrade 버튼을 파란색에서 노란색으로 바꾸어서 좋은 결과를 내었었고, 업그레이드 페이지 (chooser page라고 부름)에 배열을 다르게 함으로 수십 억 단위의 연간 추가 수익을 냈던 경험이 있다. (아래 자료 참고)

.

2. 대부분의 경우 실험의 결과가 지표에 큰 변화를 주지 않는다.

#1 법칙으로 흥분 했다면 제발 워~ 워~. 지난 번 포스팅에서도 중요하게 언급된 부분인데 대부분의 실험은 지표에 미미하거나 아예 영향을 주지 않는 경우가 대부분이다. 너무 큰 변화를 목격한다면 홈런을 외치기 보다는 어디 코드에 버그가 있는지 의심부터 해 봐야 하는 것이다. 잊지 말자… 단타싸움!

3. 케바케 (Your Mileage Will Vary)

어느 다른 회사의 어떠한 온라인 실험이 대박을 쳤다고 나도 그것을 따라하면 대박을 낼 수 있을 것이라는 기대를 하고 많은 투자를 하면 낭패를 보기 십상이다. 고객 구성, 제품의 특성, 주변 상황 등 모든 것 들이 다른 상황에서 동일한 실험 결과를 기대하는 것은 당연히 무리일 수 밖에 없다. 내가 파란색 버튼에서 노란색 버튼으로 재미 봤다고 해서 내가 아는 스타트업들에게 ‘모두 버튼을 노란색으로 바꾸세요~’ 라고 할 수 없는 이유가 바로 여기에 있다.대신 이렇게 남들이 성공했을 때 사용했던 접근했던 방식을 best practice로 일반화할 수 있다면 (예: 몇 가지 색깔의 변화로 실험을 해 보세요) 자신의 상황에 더 유연하게 적용할 수 있을 것이다.

참고로 이 반대 상황도 마찬가지이다. 사람들을 만나다 보면 꼭 ‘내가 해봐서 아는데, 이것은 절대 될 수가 없어’ 라고 주장하는 사람들이 있다. 그렇게 ‘답정너’인 태도보다 어떤 상황에서 이런 식으로 실험을 했는데 잘 안되었던 이유는 이런것 저런것 같다 라고 분석적인 태도를 취하고 그 교훈을 바탕으로 더 개선된 아이디어로 다시 도전할 수 있는 자세를 가지는게 더 바람직하다.

4. 웹사이트의 속도는 정말 정말 정말 중요하다

어떤 새로운 사용자 경험을 실험할 때 그것이 실제 웹사이트 속도에 얼마나 미치는지 점검하는 것이 좋다. 큰 회사들을 latency를 측정할 수 있는 도구들이 다 있겠지만 이런 화려한 도구가 없더라도 웹 브라우저의 디버그 툴 (크롬의 경우 오른쪽 클릭 > Inspect > Network) 을 사용, 페이지 각 콤포넌트들의 로딩 시간 등을 잴 수 있다. 인터넷 기반 서비스는 모든 것이 다 같은 경우 (all else equal) 웹사이트의 속도가 느려지면 핵심 지표의 성과도 낮아지기 마련이기에 반드시 신경쓰고 모니터링 하는 버릇을 들이자.

웹사이트 로딩 시간과 주요 지표는 보통 반비례 관계를 가진다. (이미지 논문에서 발췌)

5. 클릭 이탈을 막는 것은 어렵다. 클릭을 다른 곳으로 유도하는 것은 (그나마) 쉽다

Bing 검색엔진의 주요 지표중 하나는 클릭 이탈이다 (검색 결과를 클릭하지 않고 사용자가 이탈해 버리면 검색 결과가 형편 없다는 뜻). 마이크로소프트 개발자들이 이 지표 움직이려고 별 노력 다 해봤는데 의미있게 움직이는데 실패했다고 한다. 그나마 다행인 것은 사용자가 어디 클릭하는지는 충분히 영향을 줄 수 있다고. 이 법칙에서 나온 사용자 행동을 일반화 시켜 받아드리면 장바구니 담아두고 결제를 포기하는 사람들을 잡는 것 보다 장바구니에 아이템을 담을 때 조금 더 비싸거나 사용자에게 적합한 상품을 선택하도록 유도하는 것에 투자를 하는 등, 전자상거래 분야에 적절하게 적용할 수 있을 것 같다.

6. 복잡한 실험 설계를 피해라

‘실험 하는 김에 이런 것도 한번 알아보면 좋지 않을까?’의 똑똑해 보이려는 생각과 행동이 의도치 않은 문제점을 유발할 수 있다. A/B 테스트가 아닌 A/B/C/D 등의 다변수 실험을 할 경우 더 많은 트래픽이 필요로 할 뿐만 아니라 코드도 더 복잡해지고 (버그 위험!) orthogonality를 제대로 확인하지 않으면 왜곡된 실험 결과를 초래, 심지어는 웹사이트의 ‘폭망’으로 이어질 수 있는 위험이 있기 때문이다. 이것의 좋은(?) 예로 Knight Capital이라는 금융회사가 버그가 있는 코드를 실험 환경을 거치지 않고 바로 배포를 하여 $460M (4척6백만 달러!)라는 손실을 낸 일화가 논문에 소개된다. 간단하고 깔끔한 코드로 아주 적은 트래픽을 대상으로 실험을 수행 후 결과에 따라 트래픽을 점진적으로 늘린 다음 실험으로 넘어가는 것을 습관화 하길 추천한다.

7. 충분한 사용자를 확보한 후 실험에 임하라

통계의 매력은 작지만 의미있는 표본을 통해 전체 집단의 결과를 추정하는 것이다. 그로스 해킹 및 계량적인 마케팅 기법은 이런 의미있는 표본이 있을 때 제대로 힘을 발휘할 수 있다. 만약 사용자 수가 많지 않다면 실험을 더 오래 돌리거나, 제품에 더 큰 변화를 주는 이상적이지 못한 선택을 해야 할 것이다 (= 늦은 의사결정 또는/혹은 더 많은 위험 수반). 아니면 차라리 마케팅과 제품 개발의 본질로 돌아가서 ‘고객이 무엇을 원하는지’를 발품 팔아 그들에게 직접 피드백을 듣고 그것을 바탕으로 의사결정을 하는것이 낫다 (= do things that don’t scale). 다음 도표는 논문에서 제시한 적절한 표본 집단의 크기. 역시 유동성이 큰 매출 지표는 꽤 많은 사용자들을 표본집단으로 필요함을 알 수 있다.

각종 지표와 권고되는 표본 집단의 크기 (이미지 논문 발췌)
.

프로덕트 매니저 개론

작년 이 맘 때 쯤 ‘프로덕트 마케터 개론’이라는 글을 통해 프로덕트 마케팅 직군에 대한 글을 쓴 적이 있는데, 어느새 그 화려한 마케터의 삶을 접고 제품 담당자로 커리어를 전환한지 거의 일 년이 되어간다. 사업을 전반적으로 총괄하는 업무를 수 년 동안 해 오면서 제품에 관여를 많이 해 왔지만 회사 연구개발 부서에서 엔지니어들과 머리를 맞대고 제품을 hands-on으로 담당해서 만드는 일은 지난 일 년이 처음. ‘직접 경험해 보지 않으면 아는 척 하지 마라’는 말에 너무나 공감이 가는 것이, ‘위에서’ 업무를 조율하고 지시하는 것과 실제로 내가 ‘현장’에서 무엇을 만들어 낸다는 것은 하늘과 땅 차이라는 것을 뼈저리게 경험하였다. 이런 경험을 통해 제품 담당자가 무엇을 하는 사람이고, 또 훌륭한 제품 담당자에서 돋보이는 성향들을 관찰하고, 습득하고, 정리할 수 있는 기회가 되었다

주의: 이것은 나의 제한된 경험을 바탕으로 정의 된 것이고, 실제로 회사마다 제품 담당자의 정의 및 역할이 다르기 때문에 아래의 내용을 ‘canonical definition’으로 받아드리면 곤란 하다는 것을 미리 공지함.

제품 담당자란? (Who is a product manager?)

“Product Manager is the ultimate person responsible for the success of the product — he/she makes the ‘magic’ happen.”

간단히 말해 제품 담당자는 해당 제품의 전반적인 성공을 책임지는 사람이다. 어느 ‘무엇 (what)’으로 ‘누구 (who)’에게 가치를 제공하는 일을 하고, 그 결과에 따라 성과를 평가받는 직군이다. 제품의 성공 여부를 최종적으로 책임지는 역할이기에 ‘CEO of the product’이라고도 하지만 CEO와 다르게 제품 담당자들을 제품에 관여하는 사람들에 대해 인사권이 전혀 없는 ‘이빨 없는 호랑이’이다. 엔지니어들은 제품 담당자가 원하는 기능을 복잡하고 기술적으로 멋지지 않다고 무시하면 그만, 프로덕트 마케터들이 제품 담당자가 정의한 고객 페르소나 밖의 타겟층에게 마케팅을 해도 제품 담당자가 딱히 할 수 있는 것을 별로 없다. (특히, 그 마케팅을 통해 매출이 확 늘어난다면 더더욱!)

오히려, 제품 담당자는 미식 축구의 ‘쿼터백’과 더 유사하다고 할 수 있을 것 같다*. 미식 축구에서 쿼터백은 공을 남에게 건내 주거나 패스를 통해 팀이 전진하도록 하는 업무를 가진, 팀에서 가장 주목받고 중요한 포지션이다. 쿼터백은 스냅이 이루어지면 재빨리 어디가 막혔고 어느 선수가 공을 받을 수 있는 위치에 있는지를 파악하여 의사결정을 해야만 한다. 제품 담당자도 제품의 개발 및 출시에 있어 여러가지 난관을 재빨리 파악하여 팀이 성과를 낼 수 있도록 신속한 의사 결정을 해야한다. 게다가 감독처럼 ‘지시’를 내리는 것이 아니고 동료 엔지니어와 함께 데이터를 보면서 직접 (hands-on) 이런 결정을 내려야 한다. 그리고 결정적으로, 쿼터백은 경기를 이기면 팀을 대표해서 주목을 받고 지면 팀을 대표해서 욕을 먹는데, 이 역시 제품 담당자의 역할과 일맥상통한다. 비록 제품 담당자가 코딩 한 줄 하지 않았지만 그것에 대한 책임을 지는 것이다. (심지어 칭찬을 받으면 팀에게 공을 돌리고, 욕을 먹으면 혼자 짊어지는 미덕도 역시 비슷.)

제품 담당자의 주 업무는?

위 제품 담당자의 정의의 마지막에 “he/she makes the ‘magic’ happen”이라는 문구가 있다. 일부로 멋지게 쓰려고 한 것이 아니라, 저 단어 외로는 광범위하고 때마다 너무 다른 제품 담당자의 주 업무를 표현하기 어려워서 쓴 것이다. 물론, 제품 담당자의 기본 업무는 엔지니어와 같이 협업하여 멋진 제품을 정의하고 개발하여 시장에 출시하는 것이다 (define, build, and release the product to market). 하지만 그것은 성공적인 제품의 필요조건이지 절대로 충분조건이 될 수 없다. (아니, 그 보다 더 본질적으로 ‘제품’이라는 것이 세상에 존재하기 위해 필요한 너무나 당연한 기본 업무 밖에 되지 않는다). 이런 기본적인 업무 외에 제품의 성공에 기여하기 위해 수행해야 하는 제품 담당자들의 주 업무는 다음과 같다고 생각한다:

고객의 숨은 니즈 파악

헨리 포드의 유명한 일화가 있다: “내가 고객들에게 무엇을 원하는지 물어봤다면 그들은 ‘더 빠른 말’을 원한다고 대답을 했을 것이다”. 고객들에게 직접 그들의 니즈를 물어 어떠한 제품을 만들어야 할 지 파악하는 것은 혁신적인 제품일수록 어렵다. 그것을 경험하기 전 까지는 그러한 제품이 필요한지 알지도 못하기 때문이다. 자동차라는 제품을 눈으로 보기 전에는 더 빠른 말이 고객들이 상상할 수 있는 최고의 제품이었다. 아이폰을 보기 전에는 컴퓨터의 키보드를 전화기에 옮겨 놓는 것이 대중이 상상할 수 있는 최고의 제품이었다. 하지만 고객들의 진정한 니즈는 A 지점에서 B 지점까지 더 편리하고 빨리 갈 수 있는 수단이었고, 컴퓨터 앞에 앉아서만 할 수 있는 일들을 이동 중에서도 계속해서 경험하는 것이었다. 마케팅 부서에서 제공하는 인사이트는 이러한 고객의 니즈에 대한 힌트를 줄 수 있어도 정말 고객들이 원하는 것이 무엇인지, 그리고 또 어떠한 경험과 제품이 그런 궁극적인 니즈의 ‘심금’을 울릴 수 있는지 깊게 생각하고 파악하는 것은 제품 담당자의 몫이다. 말로는 쉽지만 실제로는 너무나 어려운 업무이다.

살을 깎는 트레이드오프 (trade-off)

100이면 100, 내가 아는 모든 제품 담당자들은 할 것은 너무 많고, 주어진 로드맵을 온전히 실행하기 위해 필요한 엔지니어 팀원들은 너무 적다고 불평을 한다. 단 한 명도 팀에 엔지니어가 넉넉하여 여유롭다고 하는 경우를 보지 못하였다. 항상 제품 담당자들이 꿈꾸는 ‘이상적인’ 제품과 그 제품을 만들 때 현실적으로 닥치는 기술적인 난관, 버그, 제품 방향의 긴급 수정 등의 일들이 생기기 때문이다. 이럴 때 제품 담당자의 핵심 업무는 제품의 성능, 기능, 출시 기한을 어떻게 타협할 것인가에 대한 어려운 결정을 해야만 한다. 꼭 필요한 기능 (must-have) 중에서 또 다시 추리고, 엔지니어들과 묘수를 찾기 위해 고민을 하고, 고객들이 이탈한다고 ‘협박’하는 영업팀과 마케팅팀들의 원성을 원활하게 조율하되, 제품의 궁극적인 비전에서 벗어나지 않는 트레이드오프 결정 과정은 과학이 아닌 예술에 가깝다고 할 수 있다.

팔방미인 코스프레 (jack of all trades)

이 외에 제품 개발 및 출시에 있어 막히거나 더딘 부분이 있으면 제품 담당자가 책임지고 해결해야 한다. 아무리 그것이 자잘하거나 제품 담당자의 ‘job description’ 밖에 있는 것일지라도 제품의 성공을 막는 그 어느 요인이 있다면 그것은 자동적으로 제품 담당자의 업무가 되는 것이다. 고객 인터뷰를 하거나, 고객의 항의성 C/S 전화를 받고, 영업팀에서 급하게 필요한 자료를 만들어 주고, 현장에서 일어난 일을 수습하기 위해 당장 뛰어 나가는… ‘제품 담당자 직군 매뉴얼’에 쓰여있진 않지만 제품 담당자들이 때와 상황에 맞추어 해야하는 업무이다. 이런 것들을 다 해결할 때 비로소 ‘magic’이 일어날 수 있는 기회가 생기는 것이다.

훌륭한 제품 담당자가 되기 위하여…

동료 제품 담당자들과 ‘우리 업’에 대해서 종종 이야기를 하는데, 이야기를 하면 할수록 훌륭한 제품 담당자가 되기 위해선 계량화 하기 어려운 ‘소프트’한 것들이 매우 중요한 것 같다는 결론을 자주 내리게 된다. 실제로 내가 존경하고 훌륭하다고 생각되는 제품 담당자들을 관찰하고, ‘전설적인’ 제품 담당자들의 글을 읽고 제품을 경험하며, 또 그들에게서 종종 조언을 들으면 다음과 같은 ‘soft skill’들의 훈련과 발전이 훌륭한 제품 담당자의 길로 가는데 도움이 될 것이라 생각된다:

기술적인 호기심 가득 (Technically Curious)

최근에 제품 담당자가 되고 싶어하는 친구들에게 가장 많이 들은 질문이 “코딩 할 줄 알아야 되나요?”, “기술적인 지식이 깊어야 하나요?”이다. 특히 컨설팅 및 MBA 출신 친구들이 다른 ‘스펙’은 다 되는데 기술적인 부분이 약하다고 제품 담당자에 지원하는 것을 고민하는 것을 많이 본다. 몇 달 전 Hunter Walk와 이 부분에 있어서 Q&A를 할 수 있는 시간이 있어 물어봤는데 그의 대답이 이 질문에 매우 적절한 것 같다.

“You don’t have to be technical per se, but you need to be technically curious. (기술적일 필요는 꼭 없지만, 기술적인 것에 대한 호기심이 있어야해요)”

테크 회사에서 제품 담당자는 기술을 이용하여 고객에게 가치를 줄 수 있는 제품을 만들고, 그 제품의 성공을 책임지는 사람이다. 이에 기술을 어떻게 이용해서 어떤 멋진 경험을 선사할 수 있을지 항상 고민해야 한다. 이런 호기심 없이는 세상을 바꾸는 훌륭한 제품을 상상해 내고, 또 그것을 현실적인 제약에 맞추어 성공적으로 구현해 내는 훌륭한 제품 담당자가 될 수 없을 것이다.

왜? What & WHY

무엇을 만들 것인가, 즉 제품에 대한 정의를 하는 것은 제품 담당자의 기본 역량이자 업무이다. 하지만 뛰어난 제품 담당자들은 제품 정의에 대한 명확한 논리와 강력한 설득력이 있다. 왜 주어진 상황이 문제인지, 그리고 그 문제를 풀기 위해서 왜 이러한 제품을 만들어야 하는지에 대해 정확한 논리와 뜨거운 열정이 느껴지는 제품 담당자들과 일하는 팀은 대체적으로 능률이 더 높으며 제품의 성과도 훨씬 좋은 편이다. 문제에 대한 인식과 제품에 대한 정의가 명확하기에, 애매하고 대충 정의된 제품을 만들 때 늘 따라오는 trial & error 및 기타 ‘삽질’과 짜증남을 피할 수 있기 때문에 그런 것 같다.

추상화 (Abstraction)

제품을 개발할 때 고객들이 가지는 문제, 그리고 그것을 풀 수 있는 방법을 잘 추상할 수 있으면 문제의 어느 특정한 부분에 발목 잡히지 않고 문제의 전반적인 본질을 이해할 수 있으며, 또 이에 필요한 해법의 방향과 전략을 가늠할 수 있다. 예를 들어 위에서 언급한 ‘더 빠른 말을 원하는 고객’들의 진정한 니즈는 이러한 추상화 과정을 통해 파악할 수 있는 것이다. (추상화를 못했다면 아마 더 단단한 말굽, 더 공기역학적인 안장, 말의 근육량을 늘릴 수 있는 사료들에 집중했을 것이다.) 단, 여기서 중요한 것은 추상화의 과정은 자세한 것에서 부터 시작한다는 점. 자세한 것을 제대로 이해하지 못한 상태에서 그냥 큰 그림만 겉핥기 식으로 파악하는 것은 위험하다. 또한 너무 과하게 추상을 하여 현실과 너무 동 떨어지는 상상을 하는 것은 큰 꿈을 꾸는 제품 담당자가 아닌 허황된 생각만 하는 바보라는 것을 경계해야한다. (‘빠른 말’에서 얻은 ‘아 고객들은 한 곳에서 다른 곳으로 빨리 이동하고 싶어하는구나’ 라는 인사이트를 ‘순간 이동 텔레포터’ 제품으로 풀려는 꼴)

유연함 (Flexibility)

팔방미인 코스프레를 하기 위해선 유연한 성격 및 뛰어난 ‘현장 적응 능력’이 있어야만 한다. 유연하지 못하고 ‘대쪽’같은 성격을 가지고 있다면 답답한 상황에 스트레스만 쌓이고 자신이 정한 제품 담당자의 역할에 대한 제한적인 ‘행동 반경’ 때문에 제품의 성공에 크게 기여하지 못할 가능성이 높다. 물론, 제품의 비전과 제품의 핵심적인 가치에 대해선 확고함이 필요하겠지만 비전과 전략만큼 중시되는 제품 담당자의 실행 능력에 있어서 만큼은 유연함이 필수이다.

.

제품 담당자라는 직군… 실리콘밸리에서는 흔하다고 하지만 기존 직군들과 비교해서는 상대적으로 새롭고, 이에 직군에 대한 정의와 역할이 아직 명확하지 않은 상태이다. 앞으로 더 많은 훌륭한 제품 담당자들의 활약을 통해 이 직군이 조금 더 명확해지고 회사에서 ‘없어서는 안될’ 너무나 당연하고 필요한 직업으로 거듭나길 바라며, 나 역시 이 개인적인 바램에 일조할 수 있도록 더욱 더 열심히 살아야겠다.
.

* 참고: 이 정의는 내 친구이자 훌륭한 제품 담당자로 십 수 년 동안 실리콘밸리에서 활약하고 있는 Sachin Rekhi에게서 차용한 것임.

.