https://www.youtube.com/watch?v=zF84IMiSP7I
안녕 얘들아, 팟캐스트에 온 걸 환영해. 다들 잘 지냈어?
좋았어.
좋아, Kevin, 다시 와줘서 고마워. 너를 모르는 사람들을 위해서, 지금 뭐 하고 있어?
나는 Y Combinator의 파트너고, 2006년에 Wufu라는 회사를 창업했어. 나는 YC 두 번째 배치에 있었고, 그 회사는 사무실 없는 회사였지. 우리 전부 리모트였어. 완전 예전부터.
오, 지금 상황이랑 관련 있네. 초창기부터 그랬다니, 진짜 대단하다. 우연치고는 꽤 운명적인데?
맞아, 진짜 그렇지.
좋아, Mike, 너는 뭐 하는 사람이지?
나는 Zapier의 공동 창업자이자 CPO(Chief Product Officer)야. 원래는 프론트엔드 엔지니어 겸 제품 디자이너로 시작했거든. 그래서 그런 분야에 대한 이해도가 깊어. 지금도 디자인 팀 운영에 관여하고 있고, 지난 7~8년 동안 디자인 팀 확장에 대해 정말 많이 고민했어.
Zapier는 뭐하는 회사야?
Zapier는 업무 자동화를 도와주는 소프트웨어야. 네가 여러 도구를 업무에 쓰고 있는데, 계속 복사 붙여넣기 하거나 반복 작업을 하고 있다면, Zapier를 써서 그런 걸 자동화할 수 있어. 백그라운드에서 알아서 돌아가지.
예를 들면, 프로젝트 매니저인데 팀이 Github에서 일한다고 해보자. 이슈가 완료되면 Slack이나 JIRA에 알림을 보내고 싶잖아. 그런 걸 Zapier로 설정해서 할 수 있어.
오 멋지다. 근데 너희 둘은 어떻게 만났어? 꽤 오래된 사이잖아.
Kevin이랑 나는, 내가 너희가 YC 할 때 일했던 곳에 놀러 갔었거든. 그냥 몇 시간 동안 얘기했는데, 진짜 흥미로운 대화였어. 내가 너한테 Wufu에서 우리가 했던 일 얘기했지. “이거 우리 이렇게 했는데, 너희도 이렇게 해보면 좋을 것 같아” 그런 식으로.
맞아 맞아. 리모트워크에 대해서도 그때 얘기했던 것 같아. “이거 진짜 오래 해야 될 거야” 이런 얘기하면서. 그리고 통합 기능 같은 거 있잖아, 여러 개 이어 붙이는 거, 그런 건 우리한테는 단순히 폼 빌더의 기능 중 하나였는데, Kevin은 그걸 사업으로 확장한 거고.
맞아. 그때 Kevin이랑 얘기하면서 “와, 이거 진짜 쓸모 있겠다” 그런 생각 들었지. 폼 소프트웨어라는 게 진짜 좋은 유즈케이스야. 왜냐면 데이터를 폼에 입력만 하고 끝나는 게 아니거든. 누가 폼 작성하면 그걸 CRM에 넣거나, 리드 평가하거나, 이메일 리스트에 추가하거나 그런 걸 하잖아.
그리고 진짜 흥미로운 게, 사람들이 온라인 비즈니스 시작할 때 단계를 보면 처음엔 존재감을 드러내야 하니까 웹사이트 빌더부터 시작해. 그래서 Wix나 Webflow 같은 게 커졌고. 우리도 그때는 몰랐는데, 나중에 깨달은 게 사람들이 데이터를 어떻게 수집할지 고민하게 돼. 그러면 폼 빌더, 연락처 폼, 설문조사 이런 게 중요해지고. 그다음엔 “이 데이터 다 모았는데 이제 뭘 하지?” 이러거든. 그게 바로 Zapier가 등장하는 시점이야.
완전 자연스러운 흐름이네. 모든 회사가 거치는 3단계: 존재감 → 데이터 수집 → 자동화.
그리고 이 시장들이 엄청 커. 예전에 Wufu 있을 때 사람들한테 "너희 TAM(총 주소 가능 시장)이 뭐야?" 이런 질문 받았는데, 진짜 말도 안 되게 커서 대답을 안 했어. “웹사이트 가진 모든 사람, 데이터 수집해야 하는 모든 사람들” 이런 식이니까 계산이 불가능해.
그런 시장 크기 예측이 도움이 되기도 하지만, 오히려 헷갈릴 수도 있어.
맞아, 특히 시장이 너무 클 땐 그냥 의미 없지. 예를 들어 페이스북한테 "TAM이 뭐야?"라고 안 묻잖아.
우리가 이 시장을 봤을 때 처음엔 “우리 멋진 소프트웨어 하나 만들어서 자립할 수 있을까?” 이런 생각이었는데, 시간이 지나면서 진짜 많은 사람들이 Zapier 같은 게 필요하다는 걸 깨달았지. 소프트웨어 도구들이 엄청나게 많아졌고, 쉽게 만들고 쉽게 배포할 수 있게 되니까, 전부 작은 툴들인데 다들 회사에 들고 오니까 서로 연결할 방법이 필요해. 그게 Zapier가 존재해야 하는 이유야.
게다가 이런 툴들은 너무 많아서, 어떤 한 회사가 수천 개 통합을 다 만드는 데엔 동기가 없어. 그래서 우리 같은 플랫폼이 필요하게 되는 거지.
\근데 지금쯤 되면 너희도 사용자도 엄청 많고 하니까, 더 구체적으로 사용자 유형별로 접근하거나 개별 시장을 키우는 전략을 생각해야 할 것 같은데, 지금은 어떻게 접근하고 있어?
솔직히 말하면, 지금까지도 꽤 수평적인 전략을 유지하고 있어. 지난 7년 동안 우리가 제일 집중했던 건 Zapier에 더 많은 앱을 추가하는 거였고, 사람들이 원하는 툴을 Zapier에서 쓸 수 있게 만드는 데 집중했지.
사실 나도 놀랐던 게, 우리가 2012년에 내린 결정 중에 하나가 오픈 플랫폼을 만들자는 거였거든. 그게 진짜 좋은 결정이었어. 처음엔 우리 셋이서 Zapier에 앱 50~60개를 직접 만들었어. 완전 맨땅에서 시작한 거지.
우리가 2012년에 런칭했을 때 라이브 챗도 달아놨는데, TechCrunch에 기사 나오고 나서 3일 동안 챗 메시지가 계속 들어왔거든. 근데 전부 우리가 지원 안 하는 앱에 대한 요청이었어. 나도 이름도 처음 들어본 앱들이었지. 그때 우리 모두가 깨달았지. "이거 제대로 확장하려면, 우리가 직접 만드는 방식으론 안 되겠다." 앱을 우리만 만들 수 없으니까, 파트너들이 직접 Zapier에 앱을 만들 수 있게 해야겠다, 그 생각이 들었어.
그때는 돈도 없고, 사람도 못 뽑고, 우리가 만들 여유도 없었으니까 거의 생존을 위한 선택이었지. 마침 초기 사용자들이 제품에 정말 흥미를 보여주고 있었고, 런칭에서 얻은 모멘텀도 있었고.
이건 진짜 플랫폼이 되어야 한다는 얘기였네. Salesforce처럼. 근데 그걸 시작하는 게 진짜 어려워. API 열어놨다고 사람들이 알아서 와서 해주는 게 아니잖아. 어떻게 그렇게 작은 시절에 사람들 보고 “우리랑 통합 만들어 주세요” 하게 만들었어?
이게 진짜 재밌는 건데, 거의 모든 SaaS 회사는 일정 규모가 되면 플랫폼이 되고 싶어 해. 나도 예전에 들었던 기준 중에 이런 게 있었거든 — 회사 수익의 1%만 떼어내도 독립 사업이 될 수 있을 정도가 되면, 플랫폼이 될 만한 임계점에 도달한 거라고.
초기엔 우리도 물론 그런 여유는 없었고, 대신에 우리가 제공할 수 있는 가치를 파트너들한테 집중해서 어필했어.
대부분의 플랫폼 전략은 유통 때문이잖아. Salesforce 앱 익스체인지에 입점하면 Salesforce 고객들이 우리 제품을 발견할 수 있으니까. 근데 우리는 그런 유통 채널이 없었어. 사용자 기반도 작았고. 대신 우리가 제공한 가치는 ‘고객 유지율’ 쪽이었지.
Zapier랑 통합을 하면 50~60개의 다른 앱이랑도 자동으로 연결되는 거야. 우리는 계속 새 앱도 추가하고 있었고, 그걸 무료로 쓸 수 있었으니까. 그러면 파트너들이 고객한테 “그거요? 죄송하지만 나중에 고려할게요”라고 말하지 않아도 되고, “네, 그건 Zapier로 가능합니다. 여기 링크요” 이렇게 바로 대응할 수 있었지. 고객 요청에 대해 ‘예스’를 줄 수 있는 방식이었던 거야.
그러니까, Zapier는 그 회사들이 고객 지원하면서 바로 추천할 수 있는 도구가 된 거구나?
맞아. 특히 고객 지원팀이 많이 그랬지. 고객들이 계속 기능 요청하니까 Zapier 링크 주는 거야. “이렇게 하시면 돼요” 하고. 그런 가이드 문서나 도움말에 Zapier가 엄청 많이 링크되어 있고, 세일즈에서도 계약 성사 도구로 쓰였어. 유료 요금제로 전환 유도할 때 Zapier로 통합 가능하다고 하면 바로 넘어오는 경우도 있었고.
그게 바로 SEO에서도 효과를 봤던 시작이었나?
그건 그보다 좀 더 전이야. 우리 앱 디렉토리는 제품보다 먼저 만들었거든. TechCrunch에 나오기 전부터 우리가 만든 게 앱 랜딩 페이지들이었어.
그게 초기 이야기야. 우리가 Zapier 작업한 지 5개월쯤 됐을 때였고. 처음 만든 게 앱 디렉토리였어. 랜딩 페이지를 일일이 만들었고, 사람들이 뭘 원하는지 보려고 이메일 수집도 했어. 이거야말로 Lean Startup이었지. 직접 다 만들기 전에 수요부터 확인하는 거야.
근데 제품 런칭할 땐 50개 앱 정도만 있었던 거지?
응, 맞아. TechCrunch에 나온 시점엔 한 50개쯤 있었고. 원래는 스타트업 위켄드 프로젝트였잖아. 그때 Wade를 처음 만났고, Brian이랑은 1년쯤 전부터 알고 있었고. 원래는 다른 아이디어로 나가려고 했는데, Brian이 API Mixer라는 걸 피치하는 걸 듣고 나서, “이거다!” 싶었지. 그래서 그 주말 동안 그걸로 프로토타입을 만들었어.
그래서 그 주말 동안 우리 핵심 기능인, 앱 간 데이터를 매핑하는 기능을 프로토타입으로 만들었지. PayPal, Highrise, 그리고 Twitter가 우리가 처음으로 연동한 세 개 앱이었어.
그건 어떻게 고른 거야?
그냥 "우리가 이걸로 어떤 멋진 유즈케이스를 보여줄 수 있을까?"를 고민하면서 고른 거야. 스타트업 위켄드 마지막 날이 되면 팀들이 자기 작업 결과를 발표하잖아. 그래서 우리는 무대에 올라가서 사람들한테 트윗을 실제로 하게 하고, 누군가 우리한테 PayPal로 돈을 보내면, 그걸 Highrise에 실시간으로 연동하는 시연을 보여줬어.
그러니까 아이디어는 이런 거였지. 누군가 트윗도 하고 PayPal로 돈도 보내면, 그 데이터를 CRM에 모아서 "아 이 사람은 우리가 좀 더 신경 써야겠다"라고 할 수 있게 해주는 거야. 그냥 그 유즈케이스 하나로부터 시작해서 거꾸로 기능을 확장해나간 거지.
그리고 나서 언제 YC에 지원한 거야?
우린 사실 두 번 지원했어.
두 번이나?
응, 첫 번째는 스타트업 위켄드에서 만든 프로토타입만 가지고 지원했어. 고객도 없었고, 트랙션도 없었고, 그냥 미주리에서 온 개발자 셋이서 만든 해커톤 프로젝트였지. 솔직히 말하면 엄청 좋은 연습이었어. 지원서 작성하는 게 우리한테 부족한 게 뭔지 깨닫는 데 도움이 많이 됐거든.
작성하면서 뭐가 달라졌어?
작성하는 과정 자체가 "아 우리 아직 이런 게 없네?"라는 걸 자각하게 해줬어. 첫 번째 지원 때는 아직 다들 낙관적이었지만, 그걸 통해서 "우린 아직 멀었구나" 하고 인정하게 됐지.
그런데 이메일로 불합격 통보를 받고 나서도, 이미 뭔가 될 수도 있겠다는 조짐이 조금씩 있었기 때문에, 우린 포기하지 않았어. 그때부터 진짜 밤낮으로 40시간씩 일하면서 몇 달을 더 달렸지.
그리고 두 번째로 지원했을 땐?
그때는 진짜 상황이 달라졌지. 수백 명의 사람들이 우리랑 채팅하고, 피드백을 주고 있었고, 그중엔 YC 네트워크 안에 있는 사람들도 있었어. 그 당시에는 초대제로만 쓸 수 있었고, 실제로 유료 결제도 받고 있었어. 첫 10명한테는 100달러씩 받았고, 그다음엔 5달러로 가격을 낮췄지. 몇백 명 정도가 우리한테 실제로 돈을 냈고, “이거 진짜 사람들이 필요로 하는구나” 하는 확신이 생겼어.
그 시점에는 이미 전면 리모트 회사로 운영하고 있었어? YC 지원할 당시엔 직원이 있었나?
아니, 그때는 우리 셋뿐이었어. 그리고 Zapier는 거의 밤낮으로 일하면서 개발하고 있었고, 초창기 4~5개월 동안은 아직 다들 본업이 있었지. Brian이랑 Wade는 직장인이었고, 나는 대학원생이었어. 유일하게 드롭아웃한 스타 창업자지 뭐. Zapier에 전념하기 전에는 다들 퇴근하면 각자 집이나, 아니면 어떤 상사가 자기 사무실을 야간에 쓰게 해줬는데, 거기 모여서 새벽까지 일했지.
사실상 두 개의 풀타임 잡을 병행한 셈이네, 몇 달 동안은.
완전 그랬지. 그리고 나서 Demo Day가 오잖아. 그다음엔 뭘 했어?
YC의 중요한 포인트 중 하나는 캘리포니아로 이사하는 거였어. 그게 우리한테 진짜 큰 계기가 됐어. “이제 더 이상 사이드 프로젝트 아니고, 이게 우리의 본업이야” 하고 올인할 수 있게 된 거지.
그때도 아직 “이게 진짜 될까?” 하는 생각이 있었어?
그 시절을 떠올려 보면, 우리 목표는 그냥 이걸로 자립하고, 우리 스케줄 우리가 컨트롤하고, 우리 스스로 보스가 되는 거였어. 그래서 아직 정규 수입을 대체할 정도는 아니었고, 현실적으로 사이드 프로젝트처럼 운영할 수밖에 없었지. YC에 들어가고 나서 약간의 초기 자금도 받고, Sunnyvale에 아파트도 구하고, 그러면서 완전히 풀타임으로 전환할 수 있었던 거야.
Demo Day 끝나고 나서 한동안 우리가 직면했던 문제 중 하나는, 우리 셋이 아침에 일어나면 다 같이 고객 지원을 해야 했다는 거야.
그때는 Gmail 공유 인박스도 없고, 그냥 이메일이 우리 셋한테 다 복사돼서 들어왔거든. 그래서 세 명이 나란히 앉아서 같은 이메일에 동시에 답장 안 하게 하려고 계속 조율해야 했고, 거의 오전 내내 고객들 세팅 도와주느라 시간을 다 썼어.
개발 시간이 다 녹아버리는 거지.
그래서 우리가 처음 뽑은 사람이 고객 지원 도와줄 사람이었어. 근데 그때 우리는 Bay Area에 네트워크가 아예 없었거든. YC 끝나고 겨우 세 달 됐을 때라 아는 사람도 없고, 인맥도 다 옛날 학교나 직장 인맥밖에 없었지.
그러다가 우리가 "이 역할에 딱 맞는 사람이 누굴까?" 생각했을 때, 딱 떠오른 사람이 Wade의 대학 룸메이트였어. 근데 그 친구는 시카고에 살고 있었고, 우리가 그를 Bay Area로 데려오기도 어렵고, 데려올 생각도 없었어.
그래서 그때 든 생각이 “우리 원래 스타트업 위켄드 이전에도 원격으로 일 잘 했잖아. 그럼 이 사람도 원격으로 해보면 되지 않을까?” 였던 거지.
마침 그 시점이 내가 당시 여자친구였던 아내가 미주리에서 로스쿨을 마치던 시기였거든. 그래서 나도 2주에 한 번씩 캘리포니아랑 미주리를 오가고 있었어. 완전 딱 맞아떨어졌던 거지. 우리가 이미 원격으로 일한 경험이 있고, 우리가 뽑고 싶은 사람도 원격이었고, 나도 반은 원격일 수밖에 없는 상황이니까, 그냥 “해보자”고 했던 거야.
그러니까 이건 원래부터 전략적으로 준비한 게 아니라 실험적으로 “우리 이거 해볼까?”였던 거네?
정확히 말하면, 전략이라기보다 영감에 가까웠지. 그때 Basecamp 같은 회사나, Wufu 같은 리모트 기반 스타트업들이 있었거든. 우리가 봤을 때 그런 작은 규모로도 잘 돌아가는 리모트 조직들이 있다는 걸 알고 있었고, 그냥 우리도 할 수 있지 않을까 했던 거야.
많은 사람들이 회사라는 게 사무실이 있어야 진짜 회사처럼 느껴진다고 생각하잖아. 뭔가 허세도 있고, 보여줄 수 있는 ‘공간’ 같은 게 있어야 한다고 생각하는?
맞아. 그래서 리모트로 규모가 커지는 회사가 대단한 거야. 왜냐면 보통은 "우리 사무실 여기 있어", "이 공간 멋지지?" 같은 걸 보여주는 게 일반적인 흐름이거든.
근데 너희는 “우리 집에서 일해요, 보여줄 공간 없어요”라는 게 자연스러웠던 거야? 그런 거에 대한 고민은 안 했어?
전혀 문제 안 됐어. 확장이나 조직 구성에 아무 장애도 없었어. 근데 지금 생각해보면, 그 고정관념은 꽤 깊게 퍼져 있었던 것 같긴 해. 최근 몇 년까지도, 우리 회사에 새로 입사한 사람이 "부모님이 여기 진짜 회사 맞냐고 물어봐요" 이러는 경우가 있었어. 우린 이미 연 매출 5천만 달러 넘고, 직원도 100명 넘는데 말이야.
그런 면에서 PR 자료 같은 게 오히려 유용하긴 했어. “이거 진짜 사이드 프로젝트 아니고, 진짜 회사야”라고 친구나 가족한테 보여줄 수 있으니까.
근데 너희는 그 유혹에 안 말린 거잖아. 대부분은 “스타트업은 이래야 한다”는 허상 때문에 사무실도 얻고 돈도 쓰고 그러거든. 근데 너희는 그걸 안 했단 말이지.
그게 창업자들한테서 나오는 게 중요해. 우리가 그걸 진심으로 믿었으니까. 사람들은 보통 스타트업이란 게 이렇게 보여야 한다는 걸 따라가는데, 우리에겐 그게 중요하지 않았어. 왜냐면 우리가 회사를 만든 이유 중 하나가, 우리 스케줄을 우리가 통제하고, 누구 눈치도 안 보고 일하고 싶어서였거든.
우린 거대한 조직에서 누가 시키는 대로 일하고 싶지 않았어. 그래서 자율성이라는 게 우리 조직의 핵심 가치야. 그리고 그건 창업 초기부터 있었지. “우리가 다니고 싶은 회사는 어떤 곳일까?” 그걸 기준으로 Zapier를 만들었던 거야.
만약 내가 큰 회사에 간다면 자율성 있는 조직에서 일하고 싶을 거야. 아침 8시 30분에 무조건 출근해야 하는 그런 회사 말고, 내가 어떤 걸 할지 내가 판단해서 행동할 수 있는 곳. 그게 우리가 Zapier를 만든 이유 중 하나지.
지금은 네가 사람들을 뽑는 입장이잖아. 자율성 있는 환경을 원한다고 ‘생각하는’ 사람과 실제로 그런 환경에서 ‘잘 일할 수 있는’ 사람을 구분해야 하잖아? 그걸 어떻게 판단해?
좋은 질문이야. 사실 Zapier는 리모트 회사고, 혼자 일하는 시간이 많기 때문에, 아무래도 혼자 일하는 걸 즐기는 사람들을 더 끌어들이는 경향은 있어. 하지만 꼭 그런 사람들만 있는 건 아니야. 외향적인 사람들도 꽤 있고, 그들도 여기서 잘 적응하고 성과 내고 있어.
내가 채용 인터뷰에서 항상 강조하는 게 하나 있어. “일은 가족이 될 수 없다.” 리모트 회사에서는 특히 이게 더 중요해. 예전엔 직장에서의 관계가 거의 사회적 연결의 전부였던 사람들도 있었는데, Zapier처럼 분산된 리모트 회사에선 그게 안 되거든.
그러니까 여기서 잘 적응하려면, 반드시 회사 바깥에도 자기만의 커뮤니티가 있어야 돼. 사이드 프로젝트도 좋고, 취미, 친한 친구들, 종교 활동, 가족 뭐든지. 일 외에도 사회적 관계망이 있는 사람이 더 건강하게 일할 수 있어.
오, 그 얘기 재밌다. 그럼 리모트 환경에서 일할 사람을 고를 때, 그 외에 또 중요한 성향이나 특성이 있어?
과거에 리모트 근무를 해본 경험이 있다면 그건 꽤 좋은 신호야. 그 사람이 실제로 어떤 건지 알고 있다는 뜻이니까. 물론, 그런 경험이 없어도 여기서 잘 적응한 사람들도 많아. 근데 확실히 적응 곡선은 좀 있어.
내가 면접에서 가장 눈여겨보는 건, 우리 핵심 가치 중 하나인 ‘default to action’, 즉, 행동을 기본값으로 두는 태도를 가진 사람이냐는 거야.
이전 회사에서, 혹은 프로젝트에서 “이건 옳은 일이라고 생각해서 내가 주도해서 밀고 나갔다”는 경험이 있는지. 꼭 모두의 합의를 기다리기보다, 스스로 “이게 맞는 방향이야”라고 판단하고 직접 나서서 행동한 적이 있는지를 봐.
근데 그건 꼭 리모트랑 상관없이, 그냥 어떤 회사에서든 다 좋은 인재상 아닌가?
맞아, 진짜 그게 내가 200명 규모의 리모트 회사를 운영하면서 가장 놀란 점이기도 해.
결국 리모트 회사를 잘 운영하기 위해서 필요한 조건들이, 그냥 좋은 회사를 만들기 위해서도 똑같이 중요하다는 거야.
리모트만의 특수한 문제가 아니라는 거지. 단지 리모트에서는 그걸 더 일찍, 더 명확하게 고민하고 구조화해야 할 뿐이야. 그게 진짜 핵심인 것 같아. 그래서 사람들이 “리모트 회사는 어떻게 운영해요?”라고 물어보면, 나도 이 얘기를 제일 먼저 꺼내.
우리는 의사결정 구조, 커뮤니케이션 방식, 프로세스를 진짜 빠르게 명확하게 만들어야 했어. 왜냐면 그게 없으면 사람들이 어떤 행동을 취해야 할지 몰라서, 기본적으로 멈추게 되거든.
그러니까, 기본적으로 사람들이 스스로 판단하고, 알아서 움직일 수 있는 정보를 줘야 해. 그래야 그들이 액션을 취할 수 있고, 전체 조직이 제대로 작동하는 거야.
아까도 얘기했는데, 내가 다른 팟캐스트에서 들은 게 있어. 시간대가 겹치는 걸 신경 쓰고, 사람들끼리 서로를 막거나 막히지 않게 하는 방법을 고민한다고 했잖아. 그와 관련해서 Neha Mehta가 트위터에서 질문한 게 있어.
“디자이너들이 제품의 서로 다른 부분에서 작업할 때, 집중력을 해치지 않으면서 서로의 작업이나 지식을 공유하는 가장 좋은 방법은 뭔가요?”
이 질문에서 기본적으로 깔린 전제가 흥미로워. 또는 뭔가 중요한 인사이트가 하나 숨어 있는 것 같아.
리모트 근무의 가장 큰 장점 중 하나는 당연히 채용이야. 전 세계 어디에서든 최고의 인재를 고용할 수 있잖아.
근데 그 다음으로 중요한 장점이자, 사람들이 잘 모르는 게 하나 있어. 진짜 좋은 결과물은 누군가 옆에 딱 붙어서 계속 같이 일할 때 나오는 게 아니라, 혼자 깊게 몰입해서 일할 때 나온다는 거야.
그건 제품 디자인 같이 협업적인 분야도 마찬가지야. 결국엔 몇 시간 동안 아무런 방해 없이 몰입해서 다양한 아이디어를 실험하고, 반복하는 시간이 필요해.
그래서 결국 이건 조직의 ‘프로세스’가 얼마나 잘 설계되어 있느냐로 귀결돼.
오피스에서 일하는 회사라면, 깊이 일하는 시간과 동료와 협업하는 시간이 딱히 명확히 나뉘지 않지. 그냥 옆 사람한테 톡 치면서 "이거 어때?" 하면 되잖아. 거긴 프로세스가 없어도 돼.
근데 리모트는 완전히 달라. 누군가랑 커뮤니케이션 하려면 훨씬 더 명확한 절차가 필요해.
그래서 우리 팀에서는 누군가 어떤 걸 공유하고 싶거나, 피드백 받고 싶을 때 어떤 방식으로 접근하는지, 그걸 프로세스로 만들어서 명확히 정리해두는 것부터 시작했어.
근데 이런 시스템 만들기 전에 너희가 했던 실수는 뭐였어? 아까 "우린 이걸 빨리 정리해야 했다"고 했잖아.
음, 우리 초기에 배운 것 중 하나는… 어떻게 말하면 좋을까…
“언제 어떤 커뮤니케이션 방식을 써야 하는가에 대해 의도적으로 결정해야 한다”는 거였어.
직접 같은 공간에서 일하면, 기본값은 뭐야? 그냥 말 걸고, 주목 끌고, 대화하는 거잖아. 그때는 몸짓, 목소리, 표정 다 동원할 수 있으니까, 대역폭이 엄청 큰 커뮤니케이션이지. 완전 실시간이고, 상대방은 100% 방해받아.
근데 리모트에서는 반대야. 대부분의 커뮤니케이션은 **"아예 안 일어남"**이 기본값이야. 같은 팀이 아니면, 서로 말 안 하는 날도 많거든. 그냥 커서만 깜빡이고 있는 슬랙 채널이 끝이야.
그래서 우리는 "어떤 순간에 커뮤니케이션의 대역폭을 올려야 하는지"를 의식적으로 파악하고, 그걸 회사 전체에 교육해야 했어.
예를 들어, 슬랙에 사람들이 동시에 막 타이핑하고 있다는 메시지가 뜨면 — “여러 명이 입력 중입니다” 이런 거 — 그건 이제 전화나 줌콜로 바로 넘어가야 할 시점이야.
그런 논쟁을 슬랙에서 10명이서 한 시간 동안 할 바에야, 그냥 줌으로 10~15분만 통화하고 끝내고, 그 결정을 슬랙에 다시 요약해서 공유하는 게 훨씬 효율적이거든.
우리가 리모트 근무할 때 만들었던 규칙 중 하나가 있었어. 장시간 토론이 이어지는 게 정말 고통스러웠거든. 그러니까 ‘딥워크’—몰입하는 시간, 그리고 ‘메이커스 스케줄’을 방해받는 거—그게 제일 싫었어.
그래서 우리 규칙을 이렇게 바꿨어. 어떤 논의가 15분 이상 계속되면, 그 시점에서 무조건 멈춰야 해. 그리고 다음 일정을 그냥 진행하는 거야.
우리는 그걸 “디폴트 액션”이라고 부르지. 그리고 멈춘 토론은 우리가 금요일에 모이는 시간에 다시 다뤘어. 일종의 회의 시간이었지.
근데 신기한 게 뭔지 알아? 실제로 그렇게 하니까, 90%는 금요일까지 아무도 다시 안 꺼내.
하룻밤 자고 나면, 다들 그냥 마음이 바뀌거나, 스스로 해결하거나, 아 이거 그냥 별일 아니었구나 싶더라고. 진짜 중요한 것만 다시 올라오는 거야.
그러니까 그게 뭔가... 나는 이 아이디어가 진짜 좋았던 게, 기본값을 **“다른 사람의 시간을 존중하는 것”**으로 두는 거야.
누군가의 시간을 정말로 써야 할 땐, 그게 진짜로 가치 있는 시간이어야 하고, 효율적으로 써야 해.
근데 반대로, 만약 네가 어떤 디자인 문제나 프로그래밍 문제에 막혀 있어. 근데 그걸 해결하려면 다른 두 사람의 집중을 깨야 하는 상황이야. 그럴 땐 어떻게 해?
그건 진짜 좋은 질문이야. 현실적으로 말하면, 리모트 환경에서는 설령 내가 다른 사람의 집중을 깨고 싶어도, 그게 안 될 수도 있어.
오피스에선 그냥 다가가서 툭툭 치면 되지만, 리모트에선 그게 안 되지. 슬랙으로 DM을 보내거나, 캘린더에 미팅 요청을 넣어봐야 해. 그 사람이 바로 볼 수 있을지도 모르고.
그리고 나는 이게 좋은 거라고 생각해. 그 사람이 방해받지 않고 집중할 수 있게 지켜주는 구조거든.
그래서 이걸 조직 내에서 어떻게 해결하냐면, 몇 가지 사회적 규칙을 정했어.
예를 들어 슬랙에서 누군가를 @멘션하면, 그 사람은 24시간 안에 반응해야 하는 게 기본 예의야.
우린 전 세계에 팀원이 있어서, 시간대가 다 다르거든. ‘해는 절대 Zapier 위에서 지지 않는다’는 말이 있을 정도야. 😂 그래서 기본적으로 어떤 메시지도 비동기로 돌아가는 게 전제야.
그래서 우리가 “디폴트 액션”을 중요하게 생각하는 이유도 그거야. 막혔을 때 기다리기만 하지 말고, 다른 의미 있는 일을 스스로 찾아서 하라.
네가 만약 "막혔으니까 그냥 기다릴래요. 누가 다음 지시 줄 때까지" 이런 타입이라면, Zapier랑 안 맞아. 아니, 사실 대부분의 리모트 회사랑도 안 맞을 거야.
지금 Zapier는 얼마나 커졌어? 직원 수가 얼마나 돼?
200명 정도야.
200명이나 돼? 그리고 네 주요 역할은 제품 쪽이야?
응, 나는 제품 팀들이 다음에 뭘 만들어야 할지 고민할 때 많이 도와줘. 그리고 디자인, 엔지니어링 팀들이랑 시간을 많이 보내는 걸 좋아해.
그럼 제품팀이랑 디자인팀 규모는 어느 정도 돼?
좋은 질문이네. 프로덕트 매니저(PM)는 7~8명 정도 있고, 디자이너도 비슷한 숫자야. 그리고 그 팀들과 함께 일하는 엔지니어들은 대략 50명 정도 돼.
내 경험상 보면, 새로운 제품을 만들거나 기획할 때 정말 많은 협업이 필요하잖아.
초기 단계에서 아이디어를 정리하고, 실제 디자인하고, 그다음 디자인 문화에서 중요한 **크리틱(피드백 세션)**도 있고. 그러니까 협업은 진짜 핵심이지.
근데 나는 Wufu에 있었을 땐 내가 유일한 디자이너였고, 팀도 10명을 넘지 않았기 때문에 그 문제를 거의 안 겪었거든. 나 자신이랑만 소통하면 됐으니까. 😂
그래서 너희는 디자인팀과 제품팀이 그렇게 떨어져 있는데도, 어떻게 그 협업이 잘 돌아가게 만들었는지 너무 궁금해.
좋은 질문이야. 내가 생각하기에 가장 중요한 관계는 바로 PM과 디자이너 간의 관계야.
이건 뭐 새로운 말은 아닌데, 진짜로 우리한텐 핵심이야.
팀을 꾸릴 때, 그 둘이 의도적으로 관계를 쌓고, 시간을 같이 보내고, 서로가 목표에 대한 강한 공동 책임감을 갖도록 만들고 있어.
근데 그걸 리모트 환경에서 어떻게 유지해? 사람들 시간도 소중하니까 함부로 막 부를 수도 없잖아.
응 맞아. 초기에 우리가 팀을 확장하기 시작한 건 한 1~2년 전인데, 그땐 좀 즉흥적이었어. 프로세스를 만들어가는 중이었고.
하지만 지금은 200명 규모니까 훨씬 더 명확한 프로세스가 필요했지. 그래서 OKR을 사용하기 시작했어.
아 OKR, 목표와 핵심 결과 지표.
응. 정렬(alignment)을 위한 도구로 쓰고 있어. 그리고 지금은 디자이너, PM, 엔지니어 매니저가 함께 하나의 OKR을 공유해.
즉, 그 목표에 공동으로 책임지는 구조야.
그거 좋은데. 근데 OKR이라는 말이 회사마다 정의가 좀 다르잖아. 너희는 어떻게 정의해?
그냥 간단하게, “이번 분기에 이 팀이 달성하고자 하는 목표”야.
예를 들면, “이번 분기 안에 Zap 설정 완료율을 10% 올리자.” 이런 식의 목표지.
이걸 디자이너, PM, 엔지니어 매니저 셋이 같이 책임져. 그러면 팀이 자연스럽게 같은 목표를 향해 움직이게 되고, **각자의 역할을 넘어서서 ‘고객 중심적 사고’**를 하게 돼.
~31:04