인사이드 빅테크: 우버, 어도비, SAP
샌프란시스코에 있는 빅테크(BigTech) 회사들을 방문했다!
(1) 우버는 본인을 "플랫폼 회사"로 정의하고 있었다. 기존에는 승객(user)와 운전자를 연결하는 양면 시장 (2-sided market) 이었다면, 이제는 고객(user), 운전자, 그리고 레스토랑을 연결하는 다면 시장 (3-sided market)으로 변화하고 있다. 우버 입장에서 풀어야하는 문제가 3개가 되는 것이다. 그리고 때로 고객의 편리함이 운전자의 경험을 해치기도 하는데, 이 경우에는 무엇을 우선해야 할까? 아쉽게도 답은 때에 따라 다르다..ㅎㅎ
우버는 '사람'과 '운전자'를 연결하는 플랫폼이었는데, 이제는 '물건'과 '운전자'를 연결하기도 한다. (Courier) '사람'과 '자전거'를 연결하기도 한다. 이처럼 '무엇'을 연결할지, 어떻게 해야 우버의 강점을 잘 활용할 수 있을지를 치열하게 고민하고 있다고 한다.
(2) 우버는 자율주행 자동차를 생산할까? 답은 아니다. 왜냐면 우버는 플랫폼 회사이지 자동차 제조 회사가 아니기 때문이다. 우버의 경쟁사는 웨이모일까? 이것 또한 아니다. 일례로 일부 미국 도시에서는 우버 앱으로만 웨이모를 호출할 수 있다. 우버를 '모빌리티 사업' 이라고 생각했던 나는 이 포지셔닝이 흥미로웠다.
(3) 우버는 업무와 핏이 잘 맞는 사람을 특히 선호하는 것 같았다. 다만 외부자의 입장에서는 그 ‘핏’이 정확히 무엇인지 파악하기가 쉽지 않다. 나도 처음에는 내가 해온 일이 우버와는 크게 관련 없다고 생각했는데, 우버 안에는 유저 메시징만 전담하는 팀도 있다고 했다. 이런 팀이라면 오히려 내가 더 잘 맞을 수도 있는 것이다. 결국에는 여러 곳에 지원해보고, 그중에서 내가 기여할 수 있는 팀을 만나는 수밖에 없는 것 같다...ㅎㅎ 다행히 내부 팀 이동은 상대적으로 자유로운 편이라고 한다.
(1) AI를 어떻게 활용할 수 있을까? 어도비는 업무 전반에 걸쳐 AI를 적극적으로 사용하고 있었다. 고객 여정(Customer Journey)을 그릴 때, PRD를 작성할 때, 프로토타입을 만들 때, 심지어 데이터 분석을 위한 SQL 쿼리를 짤 때나 고객용 카피를 작성할 때까지 다양하다. 그래서 가장 중요한 역량은 결국 AI가 내놓은 결과를 평가(evaluate)하는 능력이라고 했다.
흥미로웠던 점은, 이렇게 내부에서는 AI를 폭넓게 활용하면서도 실제 고객이 사용하는 프로덕트에서는 AI 사용을 최소화하고 있다는 것이다. 어도비의 주 사용자층은 크리에이터들인데, 이들은 AI가 자신의 작업물을 허락 없이 활용하는 데 대해 민감하다. 그래서 어도비는 AI가 ‘대체자’가 아니라 크리에이터의 도구로 느껴지도록 매우 조심스럽게 접근한다고 했다. 실제로 어도비 직원들은 각자 어떤 형태로든, 뜨개질이라던가 목걸이 만들기 같은, 창작 활동을 해본 경험이 있다고도 했다(!)
(2) 어도비 프로덕트 라인은 크게 세 가지다: 디지털 미디어(Photoshop, Lightroom, Illustrator), 문서(Acrobat), 그리고 디지털 경험(기업 대상 솔루션). 전체 제품군이 공통으로 쓰는 기능(firefly, 결제 등)이 아닌 이상, 서로 협업할 일이 많아 보이지는 않았다.
(3) 또 하나 인상 깊었던 건 어도비가 얼마나 다양한 산업 분야에 쓰이고 있는지였다. 은행, 리테일, 미디어, 테크, 정부, 헬스케어 등 거의 모든 산업에서 어도비 제품을 사용한다고 강조했다. 유저도 학생, 중소기업(SME), 크리에이터, 개발자, 기업 등으로 분류해 접근한다는 점이 흥미로웠다. 그중에서도 특히 ‘학생’에 집중하고 있다는 느낌을 받았는데, 학교와 라이선스 계약을 많이 맺고 있고, 이들이 나중에 어도비의 충성 고객이 되기 때문이 아닐까 싶었다. 실제로 교사 출신 PM들이 꽤 있었고, 교육용 제품만 담당하는 팀도 따로 있는 듯했다.
SAP이 System Application Programming 의 약자라는 걸 알았나? 난 몰랐다ㅎㅋ
(1) 세계적인 기업 중에서 SAP을 사용하지 않는 곳을 찾기 어려울 정도다. 특히 규모가 큰 회사일수록 커스터마이징 요구가 많아지는데, 그 과정에서 기능과 로직이 복잡하게 얽히는 스파게티 문제(어디를 고쳐도 다른 곳에 영향이 가는 구조적 얽힘)가 자주 발생한다.
SAP은 이러한 레거시 시스템을 종료하고 새로운 시스템으로 전환하고 싶어 하지만, 실제 고객사들은 강하게 반발한다고 한다. 생각해보면 내가 예전에 다니던 회사도 2025년에 종료 예정이었는데, SAP과 협의해 2년 정도 연장했던 기억이 난다. 이유는 간단하다. 시스템 이관 자체가 엄청난 작업일 뿐더러 회사 직원들이 기존 방식을 그대로 쓰고 싶어 하기 때문이다.
(2) 발표를 진행한 PM 리드 분은 무려 SAP에 세 번째 입사했다고 소개했다. 그런데 재입사가 자발적인 건 아니었다고 한다. 다녔던 스타트업이 SAP에 인수되면서 자연스럽게 합류한 경우가 반복된 것이다. 이렇게 SAP은 작은 회사들을 발굴해 M&A를 통해 새로운 기술을 끊임없이 흡수하며, 통합 ERP 시스템으로 발전하기 위해 노력하고 있었다. 기술을 내재화하고 경쟁 우위를 확보하는 데 효과적인 전략이라는 생각이 들었다.
(3) SAP 시스템을 실제로 접목하는 것은 엔지니어지만, 그 시스템을 일상적으로 사용하는 사람들은 엔지니어가 아니다. SAP이 상대하는 유저(엔지니어)와 실제로 프로그램을 쓰는 유저(업무 사용자)가 서로 다른 구조다. 이런 상황에서는 진짜 유저(업무 사용자)의 문제를 파악하기가 어려울 수밖에 없다. 이를 해결하기 위해 SAP은 고객사 직원들을 초대해 인간 중심 디자인(Human-Centered Design) 혹은 디자인 사고(Design Thinking) 워크숍을 진행한다고 했다. 현장에서 문제를 발견하고 해결하는 과정을 함께 경험하며, 그 회사가 실제로 필요로 하는 기능을 구체적으로 찾아내는 방식이다.
⬇︎ 아마존, 메타, 월마트, 틱톡이 궁금하다면? ⬇︎