Why Figma Wins (Figma는 왜 이기는가?)

Figma 초고속 성장의 비결 / SaaS에 네트워크 효과 적용하기

Why Figma Wins (Figma는 왜 이기는가?)

이 글은 Figma 커뮤니티에서 크게 회자 되었던 Greylock의 전 투자자인 Kevin Kwok의 에세이 “Why Figma Wins”를 Kevin의 동의하에 Relate 팀이 번역한 글입니다.

기업은 차례대로 연결되는 “루프”(loop)들을 만나 성장한다 (아래 GIF 이미지 참조). 처음 한두 번 정도는 운 좋게 초기 성장을 만들어 내는 핵심 루프를 만나 성장할 수는 있겠지만, 장기적으로는 반복해서 “다음 루프”를 찾아내는 기업만이 살아남는다.

클라우드 기반 인터랙션 디자인 도구인 Figma는 이러한 연속적인 루프를 계속해서 찾아내고 있는 보기 드문 사례다. Figma는 최근까지도 계속해서 폭발적인 성장을 만들어 내고 있어 스타트업과 테크 업계에서는 좋은 소프트웨어 성장 사례로 인식되고 있지만, 그들이 어떻게 해서 여기까지 오게 되었고, 또 앞으로 어떻게 해야 더 큰 성장을 만들 수 있는지에 대해서는 비교적 이해도가 낮은 편이다.

Image for post
당신은 아마도 내가 GIF도 만들 줄 안다는 사실까지는 몰랐을 것이다.

Figma는 “디자인은 디자이너를 포함한 모두의 일”이라는 생각에서 출발했다. 개발자와 디자이너, 그리고 이해관계자들이 결국 모여 하는 일은 디자인에 대한 논의이다. 이들의 논의는 주로 목업과 프로토타입, 그리고 그것들에 대한 피드백으로 이루어져 있다. 또한 개발 팀에게 넘겨지는 핸드오프 (handoff)와 스펙, 그리고 애셋(asset) 역시 개발자들과의 소통할 때 들어가는 핵심적인 요소다. 이 프로세스를 위해 제작되는 도구는 디자이너들이 대체되는 것이 아니라 오히려 조직에서 더 큰 영향력을 발휘할 수 있도록 돕는다.

디자이너뿐만 아니라 모두를 위한 디자인 프로세스를 만드는 일은 Figma의 첫 번째 핵심 “루프”이기도 하다. 이 루프는 Figma의 성장과 스케일을 만들고 지지기반을 확립하는 초기 동력이 되어주었다. Figma는 초창기부터 이 루프를 만들기 위한 노력을 많이 기울였다. 그들이 초기에 선택했던 결정들을 보면 그 사실을 알 수 있다.

  • 브라우저 기반으로 제품을 만들고 그저 클라우드를 “저장용도”로만 쓰지 않은 것
  • WebGL과 CRDT와 같은 당시 신기술을 적극적으로 활용해 브라우저-퍼스트(browser-first) 접근을 가능하게 한 것
  • 벡터 기반의 디지털 프로덕트 디자인에 집중한 것

Figma의 성장은 역시나 Product-Market-Fit을 제대로 찾았기 때문이지만, Figma는 그뿐 아니라 프로덕트를 유통하고 마케팅하는 과정 역시 제대로 찾았기 때문이다. 이것은 두 번째 핵심루프이다.

또한 프로덕트의 가치를 Figma를 사용하는 고객 회사들만 알고 있다면, 분명 Figma 성장세는 한계가 있었을 것이다. 그렇기에 Figma는 새로운 유저들이 추가될 때마다 모두의 효용 가치가 덩달아 높아지는 “네트워크 효과”를 설계할 필요가 있었다. Figma를 혼자서 쓰는 유저든, 기업내에서만 쓰는 유저든 간에 말이다. Figma는 이 과제를 세 번째 핵심 루프인 플러그인과 커뮤니티 생태계로 풀었다. 밑에서 이 과정을 더욱 자세하게 설명하겠다.

대부분 회사는 세 번째 핵심 루프를 찾는 데서 헤매고 만다. 그들은 핵심 프로덕트를 만들기까지는 성공했지만, 그 뒤 고객군을 넓히고 성장하는 과정에서 프로덕트의 효용 가치를 높이는 과정에서는 큰 어려움을 겪는다. 이른바 ‘플랫폼’을 구축하고 다음 연결되는 루프들을 찾아 잇는 방법을 잘 이해하지 못하기 때문이다.

플랫폼을 만드는 일에는 굉장히 복잡하고 많은 결정사항이 들어간다. 프로덕트의 어떤 부분들을 중앙에서 관리할지, 오픈소스 생태계를 조성할지/말지, 아니면 돈을 벌고자 하는 기업들을 중심으로 생태계를 조성할지, 생태계를 만든다면 얼마나 크거나 작게 할지 등 — 플랫폼 구축을 위해 옳은 결정을 내리기 위하는 과정에 대한 이해는 아직은 과학보다는 예술에 더 가깝다.

디자인의 인접 영역인 엔지니어링은 확실하게 플랫폼 및 네트워크 효과를 활용해 전체 커뮤니티의 생산성과 효용 가치를 크게 끌어올릴 수 있었다. 디자인 영역도 과연 그렇게 발전할 수 있을지, 그리고 Figma가 그 과정에 앞장서서 모두의 디자인 생산성을 향상할 수 있을지는 앞으로 몇 년 동안 주의 깊게 지켜보아야 할 사안이다.

‘협업’이 지나온 길 (The Arc of Collaboration)

Figma가 처음 출시되었을 때, Figma의 핵심 가치 제안은 디자인 협업을 좀 더 원활하고 편리하게 해주는 것에 있었다. 디자인 업무가 만일 웹브라우저 위에서 만으로도 돌아갈 수 있다면, 디자이너들은 같은 프로젝트를 띄워놓고 협업할 수 있게 된다. 그것도 동시에 말이다.

2014년에 나는 Greylock Partners에서 투자자로 일하면서 Figma 투자에 기여했었다 (아쉽게도 나는 개인적인 지분은 없다). 투자 검토를 위해 나는 여러 스타트업 디자이너들이 어떻게 일하고 협업하는지를 자세히 관찰했었다.

그때 발견한 재밌는 사실은, 스타트업 디자이너들 모두의 컴퓨터 화면에는 늘 상단 오른쪽 노티피케이션 센터에서 드랍박스(Dropbox) 아이콘이 열심히 돌아가고 있었다는 점이다. 당시만 해도 디자이너들은 모두 로컬에서 디자인 파일을 저장하고드랍박스와 같은 도구로 파일을 공유했다. 누군가가 디자인 파일을 열어 수정했으면 나머지 디자이너들의 드랍박스에도 알림이 갔고 업데이트를 강제했다. 또한 당시 디자이너들은 서로 엇갈리거나 파일의 버전을 확실하게 관리하기 위해 복잡하고, 귀찮고, 어려운 파일 네이밍으로 고통받고 있었다.

Figma는 이 문제를 효과적으로 잘 해결해주었다. 클라우드에 디자인 파일들을 저장하게 해줄 뿐 아니라 작업 역시 클라우드에서 할 수 있게 했다. 이 말은 즉 Figma의 유저들은 동시에 같은 디자인을 보고 수정할 수 있게 되었다는 뜻이다. 드랍박스 기반으로 디자인 협업하는 것과 Figma로 협업하는 것의 차이는 워드 문서를 각자 드랍박스에 저장하고 협업하는 것과 구글 문서를 열어 동시에 한 화면을 보면서 협업하는 것의 차이 정도랄까.

누군가가 클라우드에 저장된 디자인 파일을 수정한다는 것은, 사실은 복제본을 수정한다는 얘기다. 그래서 두 명 이상이 동시에 수정하는 것이 골치 아픈 문제가 되었다. Figma 위에서는 이런 문제는 찾아볼 수 없었다. 동시 수정 및 협업이 가능했기에 디자이너들은 “profile_design_v23_final_draft2”와 같은 복잡하고 귀찮은 파일 이름 관리에서부터 벗어날 수 있게 되었다. 또한 서로 이메일로 피드백을 주고받는 것 대신, Figma 위에서 디자인 옆에서 댓글을 주고받을 수도 있게 되었다.

Image for post
루프가 짧으면 짧을수록, 간단하면 간단할수록 더 좋다.

Figma 투자를 고려할 당시에 나는 왜 Figma 팀이 그토록 브라우저 기반 툴을 만드는 것에 집착하는지 이해를 하지 못했다. 도대체 브라우저 기반과 클라우드 기반의 차이가 뭐길래? 나는 시간이 지나고 나서야 서서히 왜 이 차이가 그토록 중요했는지 깨달을 수 있었다.

당시 디자인 소프트웨어를 만드는 회사들은 하나같이 “클라우드 기반”을 외치고 있었다. 그러나 대부분은 그저 데스크톱 환경에서 디자인하고 파일을 온라인에 저장하는 정도가 클라우드 기반 소프트웨어인 줄 알았다.

오직 Figma 만이 유일하게 클라우드에서 파일 저장하는 것을 넘어 웹브라우저 기반의 협업을 상상했던 것이다. Figma 팀은 기술적으로도 WebGL, Operational Transforms, 그리고 CRDT와 같은 브라우저 기반의 기술들에 대해서도 높은 이해를 하고 있었다.

Figma가 제공한 새로운 경험은 인터넷 환경에서 가장 자연스러운 경험이었다. 사실 아직도 Figma의 경쟁사들은 “클라우드 기반”을 강조하고 있다. 그러나 몇 년 전의 상황과 크게 다르지 않다.

디자이너들은 그런 Figma에 열광했고, 이 인기로 인해 Figma는 처음부터 제대로 성장할 수 있었다. Figma가 곧이어 붙인 기능들인 team library와 같이 디자이너들끼리 공통으로 공유하고 협업할 수 있는 기능들 역시 디자이너들이 다른 디자이너들을 Figma로 초대할 만한 좋은 인센티브로 작용했다.

그러나 여기서 끝나지 않았다. Figma의 비전은 디자이너들만의 툴이 아니었으니까. 그들의 목표에는 비디자이너들 역시 디자인 프로세스에 충분히 기여할 수 있도록 돕는 것도 포함되어 있었다.

Image for post
DM으로 넘어가야 하면 맥락이 끊기기 마련이다.

디자이너뿐만 아니라 비디자이너들도 함께 디자인에 참여할 수 있는 디자인 도구 (Tools for Design, not just Designers)

분명 Figma의 원래 목적은 디자이너들에게 더 나은 도구를 제공하는 것이었지만, Figma의 브라우저-퍼스트 전략은 비디자이너들에게도 혁신적이고 엄청난 영향을 주게 되었다.

우리는 이러한 생산성 소프트웨어의 목적이 개인의 생산성을 향상하는 것이 아니라 ‘팀’ 전체의 생산성을 향상하는 것에 있음을 자주 잊어버린다. 아쉽게도 소프트웨어를 만드는 회사들조차 이 점을 잊는다.

물론 개인의 생산성 향상을 도우면서도 팀 전체의 생산성 역시 높일 수 있다. 하지만 본질적으로 중요한 것은 후자다. 개인의 생산성 향상 여부를 떠나 정말로 중요한 것은 “팀이 사용하기 좋은” 도구가 되는 것이라는 얘기다.

워드 프로세서를 통한 문서 작업이 좋은 예시다. 예전에는 워드프로세서에 타입 세팅(typesetting)과 같은 기능을 붙여 개인의 생산성을 높이고자 하는 노력이 많았다. 그러나 개인 생산성이 일정 부분 구현되자 오늘날의 생산성 소프트웨어 개발의 중심은 팀의 ‘협업’으로 넘어왔다.

또한 이제는 우리가 협업하는 방식과 우리가 사용하는 도구들이 잘 어울려야한다는 것을 알고 있다. 예전에는 덜 중요했다. 협업하는 것 자체가 물리적으로 제약을 받았고, 비용도 컸기 때문이다. 그러나 오늘은 얘기가 다르다. 이전보다 훨씬 더 협업하기 편해졌다. 비용도 낮아졌다. 이 통찰을 이해하는 것은 너무나도 중요한 역량이 되었다.

예전과는 달리 오늘날 직장에서 사람들의 업무는 칼로 자른 듯 반듯하게 구분되지 않는다. 우리가 사용하는 도구들은 이 점을 충분히 반영해야 할 것이다.

최고의 도구는 이전에는 상상도 할 수 없었던 방식으로 협업을 가능하게 만들어 준다.

Figma가 있기 전에는 비디자이너들이 디자인 프로세스에 참여하고 싶어도 물리적인 제약이 많았다. 비디자이너들, 그러니까 프로덕트 매니저, 개발자, 혹은 CEO들을 디자인 프로세스에 참여시키려면 모두 디자이너들이 시간을 내 직접, 손수 프로세스를 관리해야만 했다.

디자이너는 그들에게 디자인 시안을 공유하기 위해 현재 작업 중인 디자인 파일을 이메일 등으로 보냈을 것이다. 그러면 비디자이너들은 그 파일을 열기 위해 Adobe나 Sketch 같은 전문 디자인 도구 라이센스를 구매해서 컴퓨터에 설치했어야만 했다.

그리고 이 도구들은 느리고 무거웠으며 당연히 디자이너가 아닌 사람들에게는 어떻게 사용하는지조차도 알기 어려울 정도로 부담을 안겨주었다. 비디자이너들은 피드백을 디자인 도구 밖에서 이메일이나 구두로 전달해야 했다. 디자인 파일 버전 관리가 안 되어 있어 잘못된 버전을 공유하는 경우도 빈번했다.

디자이너들에게 이런 경험은 불편함 그 자체였을 것이다. 그들이 아무리 프로덕트 매니저나 개발자들에게 피드백을 받고 싶어도, 이런 불편한 경험 때문에 그러기가 쉽지 않았을 것이다. 그나마 디자이너들이 할 수 있었던 방법은 디자인 파일을 이미지로 변환하거나 스크린샷을 찍어서 공유하고, 나중에 피드백을 받으면 수기로 기록하고 다음 버전을 또 같은 방식으로 공유하는 것이었다. 이렇게 느린 피드백 루프(feedback loop)로 인해 다음 할 일을 하지 못하고 기다리고만 있는 디자이너들이 허다했다.

물론 이 불편한 경험의 내막에는 비디자이너들이 그저 디자인에 큰 관심이 없었던 것도 있었다. 디자인을 검토하고 피드백을 주고받는 일은 그들에게 우선순위가 아니긴 했지만, 그렇다고 이런 불편한 경험이 비디자이너들에게 디자인에 큰 관심을 없게 만드는 데 아무런 도움이 되지 않은 것도 아니다.

Figma는 이 불편한 경험을 해결했다.

Figma에서는 디자인을 공유하는 것이 링크 하나 공유하는 것만큼이나 쉬웠다. 누구나 브라우저로 이 링크를 열 수 있었고, 디자인을 볼 수 있었다.

비디자이너 입장에서는 이 링크만 있으면 언제든 최신의 디자인을 확인할 수 있다는 얘기가 된다. 디자이너들의 업무를 방해하지 않으면서도 자신의 의견을 적극 디자인에 반영할 수 있게 되었다.

비디자이너도 이제는 Figma를 통해 디자인에 직접적으로 기여할 수 있다. 이 변화는 비단 Figma 내에서의 변화나 디자인 팀에서의 변화뿐만 아니라 더 큰 산업적인 변혁을 불러일으키게 되었다. 기업들은 Figma를 쓰면서 여태껏 다른 디자인 툴들은 비디자이너들을 배려한 기능은 하나도 넣지 않았음을, 혹은 비디자이너들에 대해서 아예 생각하지도 않았음을 깨닫게 되었다. Figma를 도입하고 나서야 비디자이너들도 디자인에 참여해야 한다는 사실을 깨달을 수 있었다. 비디자이너들의 참여에 대해 더욱더 깊게 알아보자.

빠르고 효율적인 피드백 루프를 만들다 (Tightening the Feedback loop)

Figma가 디자이너들과 비디자이너들의 협업을 손쉽게 한 것에는 그것 자체보다도 훨씬 더 중요한 면이 있다. 여태껏 대부분의 디자이너가 사용해온 디자인 프로세스는 너무 복잡해서 비디자이너가 손쉽게 참여할 수 없게 되어 있었다. 그래서 비디자이너들은 주로 대부분의 디자인 결정 사항들이 정해지고 나서 참여하는 척(?)하곤 했다. 모든 게 다 정해지고 디자인에 대한 피드백을 받으려다 보니 비디자이너가 디자인에 의미 있는 영향을 주기란 불가능에 가까웠다.

Figma를 통해 디자이너와 비디자이너 간의 피드백 루프를 빠르고 효율적인 프로세스로 만드는 것에는 디자이너들이 생각하는 것보다 훨씬 더 큰 가치가 있다.

Image for post
Figma 하나로 다 된다.

빠르고 효율적인 피드백(협업)을 통해 프로덕트를 만드는 팀들은 디자인과 개발을 동시에 실시간으로 구현할 수 있고, 또한 피드백을 주고받을 때 한쪽으로만 치우쳐진 피드백이 아니라 모두가 참여하는 피드백 프로세스를 도입할 수 있기 때문이다.

이뿐 아니라, 엔지니어링과의 핸드오프 역시 이전보다 훨씬 더 매끄럽게 진행할 수 있게 되었다. PM과 엔지니어들이 디자인 자체에 너무 개입하지 않고, 또한 아무런 불편함 없이 피드백을 줄 수 있다.

비디자이너들을 프로덕트와 디자인 프로세스에 적극 참여시키는 것이야말로 디자이너들의 영향력을 키우는 가장 좋은 방법이다.

우리는 너무 오랫동안 디자인, 영업, 고객 만족(CS) 부서 간의 선을 의도적으로 그어 두었다. 디자인은 디자인하고, 영업은 영업하게끔 말이다. 하지만 이런 사일로(silo) 현상은 최근 많은 회사에서 사라지고 있는 것을 확인할 수 있다.

이들은 디자인 따로, 비즈니스 따로 하지 않고 이터레이션 중심으로 하나의 프로세스를 구축하는 것이 얼마큼 효율적이고 프로덕트와 엔지니어링 결정에도 큰 도움이 되는지를 깨닫게 되었다. 그러나 이 추세는 새로울 것이 전혀 없다. 지난 1~20년간의 엔지니어링 및 소프트웨어 개발 업계에서도 이미 우리는 같은 추세를 지켜봐 왔다.

Figma의 성장 (Means of Ascent)

Figma의 안정적으로 초기에 성장할 수 있었던 것에는 사용자 회사 내부에서 아주 빠른 속도로 퍼지게 된 것이 크다. 회사내 유관 부서, 다른 디자인 팀들에서도 Figma를 사용하는 사람이 많아지면 많을수록, Figma는 더욱더 유용해지기 때문에 사람들은 서로 Figma를 추천하기 바빴다.

또한 경쟁 앱들이 디자인 업무방식의 복잡성 때문에 비디자이너가 어려워하는 거라며 헤매고 있을 때, Figma는 디자인 그 자체가 장벽이 아니라 ‘사람’에게 있음을 꿰뚫어 보았다.

Figma는 팀이 디자인하는 도구다. 디자이너들만의 도구가 아니라.

Image for post

Figma는 디자이너, 비디자이너 모두에게 적합한 도구로써 포지셔닝하게 되면서, 이른바 “크로스 네트워크 효과”(cross-side network effect)를 만들어 냈다.

일반적인 네트워크 효과를 (direct network effect) 만드는 소프트웨어에서는 같은 부류(homogenous)의 사람들이 더 모이면 모일수록 소프트웨어의 가치가 증가한다. 반대로 크로스 네트워크 효과를 만드는 소프트웨어에서는 서로 다른 부류의 사람들이 더 모이면 모일수록, 서로가 느끼는 소프트웨어의 가치가 증가한다.

디자이너들이 Figma를 사용하면 사용할수록, 함께 일하는 유관 비디자이너들을 끌어당긴다. 마찬가지로 비디자이너가 Figma를 사용하게 된다는 것은 다른 디자이너들이 Figma를 사용할 충분한 인센티브를 제공한다는 것이다. 이보다 더 강력한 루프(loop)와 선순환 구조는 없을 것이다.

크로스 네트워크 효과에 대하여 (Cross-side Network Effects)

크로스 네트워크 효과*는 일반적인 네트워크 효과보다는 덜 주목받는다. 이는 우리가 네트워크 효과 자체를 정의하는 폭이 생각보다 좁아서일 수도 있겠지만, 사실은 그냥 우리가 크로스 네트워크 효과는 마켓플레이스에만 (한국에서는 O2O, ‘양면 시장’ — 시장은 원래 양면이다 — 로 이해하기도 함) 적용되는 개념이라고 잘못 생각하고 있어서 일 것이다.

*Cross-side network effect는 일반적으로 한 부류의 사람들이 많아지면 많아질수록 총합의 가치가 더불어 증가하는 네트워크 효과와는 다르게 ‘여러’ 다양한 부류의 사람들이 모일 때의 총합의 가치가 더불어 증가하는 네트워크 효과를 말한다.

물론 크로스 네트워크 효과를 적용하는 대표적인 사례는 마켓플레이스들이 맞지만, 마켓플레이스에서만 볼 수 있을 거라는 생각은 잘못되었다. 크로스 네트워크 효과가 공급자와 수요자 간의 효과로만 존재하는 것은 아니기 때문이다.

디자이너와 디자이너가 모여 이루는 일반적인 네트워크 효과만으로는 Figma가 초기 성장 이후 지속해서 폭발적인 성장을 만들어 내는 데 어느 정도 한계가 있었다. 디자인 업무에 있어 디자이너들끼리, 디자이너들 간의 소통은 분명 적진 않지만, 딱히 엄청 많지도 않기 때문이다. 일반적인 네트워크 효과는 점금선적으로 분포한다 (asymptotic distribution).

Figma가 그 대신 집중한 크로스 네트워크 효과를 살펴보자.

Figma를 사용하는 디자이너들은 Figma를 써서 동료 엔지니어, PM과 디자인 시안을 공유한다. 이렇게 비디자이너들이 Figma의 편리함을 조금씩 알아가면 알아갈수록, 다른 디자이너와 일을 할 때도 Figma를 권할 가능성이 커진다는 것이다. 이처럼 크로스 네트워크 효과는 팀이라는 개체를 넘어 조직 전체에 퍼뜨릴 강력한 무기가 되어준다.

Image for post
오직 이 경우에만 루프가 많으면 많을수록 좋다.

이것은 기업들이 Figma를 도입하는 과정에도 큰 영향을 미친다. 디자이너들이 필요로 하는 툴이라면 그것 자체로는 소프트웨어를 도입하는 일의 우선순위가 낮을 수도 있을 것이다. 하지만 Figma를 디자이너 뿐만 아니라 PM들과 엔지니어들이 전부 원한다면? 혹은 디자인에 (아직은) 개입하지 않는 CEO마저도 회사 전체에 좋은 영향을 주는 제품이라면?

이 질문을 하는 순간 Figma 도입 우선순위는 훨씬 더 높아지고 Figma는 훨씬 더 강력한 가격결정력을 갖추게 된다.

Product-Distribution Fit (프로덕트-마케팅(유통) 핏)

크로스 네트워크 효과는 정말로 Figma가 상상 이상으로 빠르게 성장하게 해준 큰 요인이다. 이를 위해 Figma는 농부가 씨앗을 심듯이 회사마다 한두 명 정도를 섭렵하는 것으로 시작했다. 이 “씨앗”들은 시간이 지나서 결국 회사 전체가 Figma 를 도입하게 했다. 이처럼 단지 몇 명의 디자이너만 처음에 Figma만 도입하더라도, 얼마 안 있어 부서 전체가 Figma를 도입하게 되는 모습을 확인할 수 있었다. 이들은 위에서 설명했듯 결국 회사 전체가 도입할 때까지 추천하고 권한다.

Figma의 ‘성장 복리’ (compounding growth rate)는 여기서 나왔다. 성장궤도에 오르기까지 제법 오랜 시간이 걸렸지만, 오르고 나서부터는 기하급수적인 성장률을 기록했다.

아주 드물게 스타트업에서 찾을 수 있는 강력한 무기는 바로 제품과 마케팅(유통)의 일치다. Figma 제품의 핵심은 곧 Figma 마케팅(유통)의 핵심이다. 제품과 마케팅을 100% 얼라인(align)하는 과정이야말로 성장 복리를 촉진하는 필수 조건이다.

프로덕트 유통과정의 혁신을 위해 여느 B2B 소프트웨어 회사들처럼 Figma 역시 두 단계의 영업 프로세스를 도입했다. 먼저 바텀업 (bottoms-up)으로 유저가 스스로 제품을 도입하고 제품을 써보며 팀 사람들과 공유하기 시작하면, 탑다운 (top-down)으로 들어가 제품을 전사적으로 판매하는 방식이다.

이런 2단계 영업 프로세스를 하기 위해서는 꽤 많은 선행 작업이 들어간다. 사전에 엔터프라이즈 레벨의 기능들을 (eg., SSO, SAML, etc) 갖춰야 하고, 영업팀을 구축해야 한다. 지난 10여 년 동안 Figma는 이를 위해 차근차근 준비해왔다.

Image for post

이렇게 제품과 그로스를 모두 추구하면서 B2C와 B2B 세일즈 형태를 모두 갖춘 새로운 형태와 방식에 대해 우리는 아직 100% 다 이해하지 못하고 있다. 우리는 아직도 어떻게 하면 제품과 그로스를 모두 추구하는 최적의 조직을 만들 수 있을지, 또 GTM은 어떻게 설계하고, 가격정책 등은 어떻게 추구해야 할지에 대해 아는 것이 많지 않다. 하지만 SaaS 시대에 접어들면서 SaaS를 운영하는 방법이 점차 예술의 영역에서 과학의 영역으로 넘어온 것처럼, 제품과 그로스를 모두 추구하는 이러한 형태의 영업 프로세스도 그렇게 될 것이라 생각한다. 물론 Figma도 아직 갈 길이 많이 남았다고 생각하지만, 분명 기존의 영업 방식을 넘은 새로운 형태를 선도할 것이라고 본다.

영업, 마케팅 실무자들 사이에서는 영업 프로세스도 우리가 그로스 해킹을 (growth loops) 경험한 것처럼 속도와 효율을 극대화하고 프로덕트와 오퍼레이션 사이에서 빠르게 스케일할 수 있는 영역이라 믿기 시작한 것 같다. 그리고 Figma야말로 이렇게 새로운 영업 방식을 선도할 가장 최전선에 있는 기업이다.

Figma 생태계 만들기 (Building an Ecosystem)

Figma의 다음 단계는 무엇일까?

코어 프로덕트를 개선하는 일에는 “끝”이 없다. 더 가파른 성장세를 만들기 위해서는 언젠가는 다음 성장 시퀀스를 준비하지 않으면 안 된다.

Image for post
그래프 오른쪽 오렌지 색 박스에 들어갈 루프.

Figma와 경쟁하는 회사들도 가만히 있지는 않는다. 그들 역시 Figma의 핵심 역량을 벤치마크하고 점차 따라 하기 시작했다. 따라서 경쟁사들이 치고 올라오며 주는 압박을 이겨내기 위해서는 Figma도 마찬가지로 멈춰서는 안 된다.

Figma와 가장 치열하게 경쟁하는 회사인 Sketch는 최근 가격 정책을 바꾸고 고객 팀들이 Sketch Cloud를 도입할 수 있게끔 시도하고 있다. 또한 자금 확보를 위해 창업 이래 처음으로 Benchmark로부터 벤처캐피털 투자를 받았다. 투자를 받은 이상 더 이상 macOS 네이티브 애플리케이션으로 멈출 수는 없다. 팀 협업과 브라우저 기반 소프트웨어로의 방향성은 굳혀졌다.

Adobe도 비슷한 행보를 보이고 있다. 주력 상품인 Photoshop과 Illustrator는 많이 쓰이고 보편화한 툴이지만, 디지털 프로덕트를 디자인하는 용도에 특화된 툴은 아니다. 2019년에 Adobe는 Sketch와 Figma의 경쟁 툴인 Adobe XD를 출시했다.

지난 몇 년간 Figma는 다른 형태의 유통과정보다도 ‘고객사 직원들 사이에서 퍼지는 것’에 더욱 집중했다. 이제는 ‘고객사들 사이에서 퍼지는 것’에도 노력을 기울여 가치를 높여야 한다. Figma를 사용하는 회사들의 생태계를 만들기 위함이다.

글로벌 네트워크 효과 만들기 (Global Network Effects)

앞서서 설명했듯이 크로스 네트워크 효과를 통한 product-distribution fit에서 나온다. 기존에 Figma를 사용하고 있는 회사라면, 시간이 지나고 사내 사용자가 많아지면 많이 질수록 효용 가치는 누적된다. Figma를 아직 도입하지 않는 팀이라면? Figma는 어떻게 한 번도 Figma를 사용하지 않은 회사에는 어떻게 팔까?

최근 Figma의 성장을 들여다보면, 조직 내 부서와 팀 간에 퍼지는 것은 물론이고, 회사들 사이에서도 입소문이 나는 경우도 꽤 많이 발생하고 있는 것을 알 수 있다. 물론 이런 부분들은 의도적으로 퍼진다기보다는 자연스럽게 스스로 퍼지는 경향을 보인다. 예를 들어, 에이전시나 컨설팅 회사들 같은 경우 자연스럽게 다른 회사들과 (클라이언트사) 협업이 잦다. 또한 Figma를 사용하는 직원이 이직했을 때, 새로운 직장에 가서도 Figma를 도입하기도 한다.

Figma를 사용하는 회사내에서는 크로스 네트워크 효과 덕분에 새로운 사용자가 느끼는 가치는 회사 밖에서 쓰는 것보다 훨씬 더 크다. 동료들은 이미 Figma 위에서 협업하고 있다. Figma에 모든 디자인 애셋과 디자인 라이브러리가 존재한다. 재활용할 수 있는 컴포넌트들도 Figma에 저장되어 있다.

하지만 동료들이 쓰지 않고 있는 상태, 즉 처음으로 Figma 도입을 고려하는 회사로서는 위의 가치는 하나도 적용되지 않는다. 물론 Figma의 프로덕트 자체로도 충분한 가치를 지녔지만 지난 몇 년 동안 Figma가 차근차근 쌓아온 네트워크 효과의 덕은 보기가 어렵다는 것이다.

Image for post

Figma의 다음 챌린지는 바로 이것이다. 회사내 로컬 네트워크 효과를 포함해 ‘글로벌 네트워크 효과’를 만들어 내는 것. 글로벌 네트워크 효과를 만들기 위해 여러 가지 전략과 방법을 시도해볼 수 있지만, 나는 그들이 이미 채택하여 진행하고 있는 방향에 관해 설명해보고자 한다.

Image for post

Figma는 2019년부터 본격적으로 커뮤니티와 플러그인 생태계를 활성화했다. 8월에는 플러그인을 런칭했고 얼마 안 있어 커뮤니티도 런칭했다. 커뮤니티와 플러그인은 Figma의 3번째 핵심 루프이다.

Image for post

Figma 커뮤니티 (Empowering Creativity through Communities)

Figma는 일찌감치 유저들과 기업들이 서로 디자인 작업물을 공유할 수 있도록 커뮤니티를 만들었다. 예전에는 디자인을 공유하고 피드백을 받으려면 Dribbble과 같은 포트폴리오 사이트에 올려야만 했다. 이런 포트폴리오 사이트 대부분의 경우 ‘결과물’ 만을 공유했기 때문에, 디자인 전체 — 컴포넌트와 레이어까지 — 를 공유하고 전반적인 피드백을 주고받기에는 부족했다.

또한 디자인 전체가 공유되었더라도 Dribbble 유저 각기 모두 다른 디자인 도구를 사용했기에 쉽게 파일을 받아 열어볼 수도 없었다. 그에 반해 Figma 커뮤니티는 결과물뿐만 아니라 컴포넌트들과 디자인 애셋들, 그리고 복잡한 인터랙션에 대한 설정을 한꺼번에 공유할 수 있었다. 이 차이는 이전의 방식과는 구성 차원에서 매우 큰 차별점이다.

좋은 예시는 Figma의 디자인 디렉터인 노아 레빈(Noah Levin)이 예전에 Figma 커뮤니티에 공유했던 애니메이션이다. Dribbble 등에 공유했더라면 유저들은 그저 노아의 애니메이션 결과물만 볼 수 있었을 것이다. 하지만 Figma 커뮤니티에 공유함으로 유저들은 노아의 애니메이션을 직접 수정하고 보완할 수 있었다. 유저들은 노아의 애니메이션 파일 일부분을 가져와서 자기 디자인에 참고할 수도 있었다.

또한 엔지니어들의 커뮤니티인 Github을 이용해 UI키트, 컴포넌트, 디자인 시스템 등을 배포하는 디자이너들도 있었다. 아주 좋은 오픈소스 성격의 아이디어였지만, Github 자체는 애초부터 디자인을 위해 만들어진 툴이 아니였다. 깃(Git) 기술을 통해 리포지토리(repository)에 코드를 푸시하고 관리하는 방식은 엔지니어들에게는 매우 편리한 방식이지만, 디자인에서는 그렇게 간단하지 않다. 깃으로 관리한다고 해도, 디자인은 파일 형식이 다르니 Github을 쓰더라도 그저 드랍박스, 구글 드라이브와 같은 클라우드 저장공간 정도의 용도로밖에 쓸 수 없었다.

Image for post

Figma는 하나의 통합된 웹 기반 인터랙션 디자인 툴로써 이 문제를 해결했다. Figma 커뮤니티에서는 누구나 Figma 디자인 파일을 문제없이 쉽고 간편하게 열어 볼 수 있고 필요에 따라 다른 디자이너의 파일을 복사해와서 자기 디자인으로 승화시킬 수도 있었다. 많은 부분에서 엔지니어들에게 Github이라는 환상적인 커뮤니티가 있다면, 디자이너들에게는 Figma가 있는 것이다.

Figma로 인해 점점 더 많은 사람이 자신의 디자인을 공유했고 모두가 이로 인해 이익을 얻는 네트워크 효과를 만들어 냈다.

플러그인 생태계가 약속하는 가능성 (The Promise of Plugins)

(초보자인) 나는 Figma를 주로 친구들에게 보낼 재밌는 밈(meme)들을 제작하는 데 사용한다. 이 용도로 Figma는 매우 좋은 툴이지만, 귀찮은 일을 해야만 할 때가 종종 있다. 내가 좀 더 제대로 밈들을 만들기 시작하면서 밈에 들어가는 텍스트를 강조하기 위해 배경색을 덧입히기 시작했는데, 덧입히는 수작업은 매우 귀찮고 짜증 나는 일이다. 꾸역꾸역 참으며 밈을 만들다가 최근에 Substrate for Text라는 Figma 플러그인을 발견하게 되었다.

러시아에 사는 디자이너 Andreslav Kozlov가 만든 Substrate for Text 플러그인은 Figma내에서 아무 텍스트를 선택한 다음, 플러그인을 구동시키면 뒷배경이 자동으로 덧입혀진다. 지구 반대편에서 Andreslav는 나와 똑같이 텍스트에 뒷배경색을 덧입히는 일을 귀찮아했고, 플러그인을 만든 뒤 커뮤니티에 배포한 것이다.

Andreslav의 플러그인은 나의 Figma 사용경험을 더욱더 좋게 만들어 주었다.

Image for post
Image for post

Andreslav의 플러그인은 Figma 플러그인이 약속해주는 무한한 가능성의 작은 예시다. 플러그인을 통해 Figma를 사용하는 디자이너들은 훨씬더 자유롭고 편리한 워크플로우를 만들어 서로 공유할 수도 있다. 디자이너들이 디자인을 더 잘할 수 있게 돕는 최적의 생태계인 것이다.

Image for post

지금 커뮤니티에 등록된 대부분의 Figma 플러그인들은 귀찮고, 반복적인 일들을 자동화하거나 편리하게 해주는 플러그인들이다. 기업들도 자신들의 니즈에 맞게 Figma 플러그인들을 새롭게 만들어 쓸 수 있다. (예: Coinbase 디자인팀이 만든 Autoflows). 예를 들어, 다크모드 디자인을 자동으로 만들어 준다든지, 외부 데이터를 가져와서 흔히 발생할 수 있는 디자인 에러들을 점검한다든지, 아니면 디자인 애셋들을 올바른 포맷으로 손쉽게 만들어 준다든지 말이다. 플러그인은 모든 팀들에게 부스터가 되어준다.

하지만 플러그인이 Figma에게 중요한 이유는 이것때문만은 아니다. 더욱 중요하게는 이런 플러그인들이 온라인 커뮤니티에 배포되면 생태계를 더 크고 유용하게 만들어 준다는 점이다. Figma 유저라면 아무 제약 없이 이런 플러그인들을 설치해서 쓸 수 있다. 차트를 만드는 일이든, 커스텀 지도, 디자인에 데이터를 불러오는 작업, 엔지니어들에게 전달하기 위해 레드라인 스펙을 만드는 일이든, 무작위의 blob 벡터를 만드는 일이든, 플러그인은 디자이너의 생산성을 향상한다. 또한 Figma Chat과 같은 플러그인들은 디자이너들의 영향력을 크게 확장할 수 있는 기회를 만들어 주기도 한다.

일반적으로 기업이 성장하면 성장할수록 고객들에게 제공되는 가치가 증가하기란 매우 어려운 일이다. 고객의 수가 많아지면 기업은 각 고객만의 활용 방법 (use case)과 니즈를 일일이 맞춰줄 수 없기 때문이다. 또한 기업이 성장하면 핵심 고객층을 벗어나 인접 고객층으로도 확장해야 하기에, 만족도가 이전보다 떨어질 수밖에 없다. 이런 현상은 팀 전체가 아니라 일부만이 Figma를 도입해서 쓰는 팀들의 경우에 더욱 증폭된다.

Image for post

하지만 Figma는 플러그인 생태계의 확장을 통해 인접 고객층뿐만 아니라 특수한 니즈를 가진 유저들까지 만족시킬 수 있게 된다. 유저가 많아지면, 플러그인도 많아지고, 플러그인이 많아지면, Figma 프로덕트 자체의 경험 또한 좋아지게 된다.

플랫폼 구축하기 (Architecting a Platform)

우리는 Figma의 출현 이전에도 Sketch와 같은 툴이 어떻게 플랫폼을 구축하고 플러그인 생태계를 만들어 성장했는지를 경험한 적이 있다. Adobe 역시도 마찬가지로 오랫동안 플랫폼과 플러그인 생태계를 확장해왔다.

앞서 말했듯, 모든 유저가 원하는 기능과 경험을 제공하기란 그냥 불가능하다. 그렇기 때문에 플랫폼화가 중요한 것이다. 플랫폼이 구축되면, 유저들은 회사가 상상할 수 있는 것 이상으로 플랫폼을 확장하게 한다. 그리고 유저들 스스로 필요한 기능과 경험을 창조해 사용한다.

Sketch의 경우, 이제는 Sketch 개발팀이 기능을 추가하는 것보다 유저들이 스스로 플러그인을 만들어 쓰는 것이 훨씬 더 빨라지게 되었다. Figma 역시 핵심 기능을 보완하고 안정화하는 데 노력을 기울이고, 새로운 기능의 경우에는 플러그인 생태계와 플랫폼 확장을 통해 갖출 가능성이 커 보인다.

Image for post

플랫폼은 여전히 우리에게 애매모호한 개념이다. 지금으로서는 회사들 각자가 알아서 플랫폼을 구축하는 방법을 스스로 터득해나가고 있다. 간단히 말해 바퀴를 여러 번 재개발 중이란 얘기다. 하지만 앞으로 10년 이내, 우리는 플랫폼을 이해하는 데 도움이 될 명확한 프레임워크를 갖게 될 것이고, 이에 따른 공식이나 지표도 나올 것이다. 시장에는 플랫폼 생태계를 만드는 데 도움이 되는 도구들도 몇 개 등장할 것이다. 이러한 변화는 자연적으로 시장이 안정기에 접어들면서 일어날 수순이다. 구독 경제, SaaS 등이 거쳐와 오늘의 위치에 서게 된 것처럼 말이다.

Image for post

우리는 플러그인 생태계, 플랫폼 구축 등을 너무 쉽게 생각하는 경향이 있다. 플러그인은 모두 똑같다고 생각하는 식이다. 하지만 현실은 그렇지 않다. Figma의 경쟁회사인 Sketch의 예시로 들어가 보자.

Sketch 케이스 스터디

Sketch의 플러그인 생태계를 들여다보자. 우선 Sketch API에 대한 설명이 매우 잘 정리되어 있고, 플러그인을 개발하는 방법이나 구축 프레임워크 역시 잘 설명되어 있다. 그러나 Sketch의 플러그인은 Sketch 코어 프로덕트 영역 “밖”의 일이다.

Sketch 플러그인은 주로 사용자들이 따로 만들어 둔 Github이나 제3의 웹사이트에서 수동으로 다운로드받아 설치하게 되어 있다. 여담이지만, 이런 부분 역시 “클라우드와 로컬”의 차이일 것이다. 설령 앞으로 Sketch가 클라우드 위에서 돌아가게 된다고 하더라도 플러그인은 여전히 로컬 파일로 존재하게 된다. 플러그인을 다운로드하고, 관리하는 것은 여전히 수동이고 번거로운 작업이다. 다시 말해, Sketch를 쓰는 회사들은 직원들이 같은 플러그인을 쓰게 하려면 컴퓨터 하나하나씩 플러그인을 설치하고 손으로 하나씩 다 관리해야 한다는 얘기다.

Sketch에게 플러그인은 우선순위가 아니다. 플러그인을 관리하고 배포하는 일은 한마디로 ‘탈중앙화’되어 있다. 물론 Sketch 역시 플러그인을 모아둔 사이트를 운영하고 있고 자동으로 업데이트도 일부 가능하지만, 대체로 Sketch는 플러그인 생태계에 대한 컨트롤을 사용자들에게 일임한다.

Sketch 플러그인은 Sketch 팀의 승인을 받지 않아도 되고, 또한 어떤 플러그인이 Sketch 유저들 사이에서 자주 쓰이는지에 대한 공식적인 자료도 없다. Sketch 유저들은 Github과 같은 다른 사이트에서 가령 요새 어떤 플러그인들이 인기를 얻고 있는지에 대한 정보를 얻는다. 플러그인의 성능이나 보안, 안정성 문제 역시 Sketch에서 책임지거나 관리하지 않는다.

위의 내용을 순전히 Sketch 플러그인 생태계에 대한 비난으로 받아들여서는 안 된다. 위에 언급된 단점들은 오로지 Sketch가 플러그인 생태계를 확장하려고 노력을 기울이면서 발견된 부분들이지, 그냥 생겨난 게 아니기 때문이다. 또한 그들의 중립적인 스탠스 때문에라도 Sketch 커뮤니티가 활성화된 것도 없지 않아 있을 것이다. Sketch는 많은 면에서 디자인 도구의 선구자였기에, 후발주자인 Figma, Adobe XD의 경우는 플러그인 생태계 키우는 것에 관한 공부를 미리 할 수 있기도 했다.

Sketch를 마냥 비난할 수 없지만, 그들의 선택이 가져온 결과에 대해서는 분명하게 얘기할 수 있다. 그들은 플러그인 생태계를 지금보다 훨씬 더 크고 유용한 환경으로 확장할 수 있었을 것이다. 이 점은 Sketch 팀 역시 잘 알고 있는 부분이다. 지금 Sketch 팀은 플러그인 생태계를 포함해 100% 클라우드 환경으로 넘어가는 것을 준비하고 있다.

복잡계 시스템하에 기업들은 아키텍처, 정책, 규율 등에 대한 선택에서 자유롭지 못하다. 오히려 이런 결정사항들이 기업의 성패에 큰 영향을 미친다. 생태계가 만들어지기 전부터 사실 기업들은 이러한 선택들로 인해 만들 수 있는 생태계의 구조, 크기, 영향력 등이 결정된다.

우리는 관념을 만들고 구체화하고, 관념들은 우리를 구체화한다.

Figma: 기초 기반을 만들다 (Figma: Forming Foundations)

Figma 생태계에 들어 있는 플러그인들은 매우 초기 단계라고 볼 수 있지만, 큰 가능성을 짐작할 수 있다. 이 플러그인들은 브라우저 기반이며 Figma 만을 위해 제작됐다. Figma 커뮤니티에서 플러그인을 찾아 바로 설치하면, Figma 파일에서 바로 구동시킬 수 있다. 사실 “설치”하는 것도 아니다. 기술적으로는 스위치를 켜는 것과 같다. ‘마법’ 같다.

Image for post

모든 ‘마술’이 그러하듯, 정말로 마법처럼 보이기 위해서는 매우 많은 연습과 연구가 필요하다. Figma의 플러그인들도 높은 수준의 보안과 안정성을 갖춰야 한다. 더군다나 Figma의 플러그인은 ‘브라우저 기반’이기 때문에 더더욱이 신경 써야만 한다. 당연한 얘기일 수도 있겠지만 — 플러그인을 쓰면서 Figma의 성능저하나 보안 문제를 걱정할 필요는 없어야 한다. 또한 플러그인 개발자, 유저들 모두 Figma API 역시 그만한 안정성을 유지해줄 것을 기대하고 있다.

이러한 선행조건 없이는 플러그인은 그저 부품이 될 뿐이다. 신뢰와 안정성은 강력한 생태계의 기초 기반이다.

Image for post

Figma의 엔지니어링 블로그를 들춰보면, 신뢰와 안정성을 유지하기 위해 Figma 팀이 얼마나 많은 시행착오를 통해 기반을 만들려 하는지 알 수 있다. 예전에 엔지니어링 팀이 플러그인 아키텍처 설계에 관해 을 쓴 적이 있는데, 한 달도 채 지나지 않아 보안취약점을 발견하여 수정하게 되기도 했다.

플랫폼의 안정성과 높은 보안 수준을 유지하는 것은 비단 기술의 문제만은 아니다. Figma는 애플처럼 모든 플러그인을 직접 심사하고, 조사과정을 거쳐 최종 승인 결정을 내리는 중앙화된 프로세스를 갖고 있다. 플러그인들이 Figma의 공식 승인을 받으려면 보안과 안정성, 법률, UX 등의 관점에서 심사를 통과해야 한다.

플랫폼이 되기까지 (The Path to Platforms)

Figma에게 플랫폼 운영 정책이란 보안, 안전, 안정성, 법률 등의 사안만 고려하는 정책이 아니다. 물론 이런 사안들도 매우 중요하지만, Figma는 사업성과 관련된 정책도 고민해야 한다. 이를테면 플러그인 개발사들이 돈을 받고 플러그인을 판매하는 것을 허용할 것인지, 혹은 Figma의 무료, 유료 유저들을 차별해서 플러그인을 제공하는 것을 허용할 것인지 등의 고민이다.

플러그인 개발사들이 얼마나 자유롭게 Figma 플랫폼에서 사업을 전개하게 할지에 따라서 플랫폼의 방향 및 정체성이 완전히 뒤바뀌어 버릴 수도 있으니까 말이다. 물론 정답은 없다. 중간에 방향을 바꾸지 말라는 법도 당연히 없다. 오히려 이렇게도 해보고, 저렇게도 운영해보는 것이 더 바람직하다. 우버의 운전자들, 워드프레스의 플러그인들, 혹은 에어비앤비의 호스트들이 시간이 지나면서 어떻게 변하는지만 봐도 알 수 있다.

Image for post

플랫폼 구축하기 위해서는 이런 어려운 결정들을 많이 내려야만 한다. 지금의 성장과 장기적인 비전 사이에서 어떻게 행동에 옮길 것인가? 플러그인들이 만들어지는 과정에 플랫폼은 얼마나 깊숙이 개입해야만 하는가? 혹은, 초기에는 플랫폼이 직접 플러그인들을 만드는 것은 어떤가? 플러그인 중에 유용한 것은 그대로 둘지, 혹은 플랫폼 자체의 기능으로 내재화할지 등 — 모두 플랫폼이 내려야만 하는 어려운 결정들이다.

Figma가 흥미로운 이유는 어쩌면 사람들이 플러그인을 만들기 쉽도록 설계했다는 것일지도 모른다. Figma의 플러그인 시스템은 오직 디자이너들이 높은 수준의 개발역량 없이도 쉽고 간편하게 자신들의 워크플로우를 플러그인화 할 수 있게끔 설계되었다. 이에 비해 대부분의 플랫폼이나 마켓플레이스에서는 오로지 기술 역량을 갖춘 사람들, 기업들만이 플러그인을 만들 수 있다. 따라서 개인 디자이너들이 워크플로우를 기반으로 플러그인을 만들어 생태계를 이룬다는 생각은 어쩌면 굉장히 볼드한 도전으로 볼 수도 있는 것이다.

Figma의 플러그인 생태계는 아직도 초기 단계에 있다. 그들이 발표한 앞으로 지원하려고 계획한 기능 목록을 보면, 아직 플랫폼 개방 및 플러그인 시스템 고도화까지 갈 길이 아주 멀다는 것을 알 수 있다. 또한 플러그인 생태계를 정의하는 관념들을 바로 세우는 일 또한 굉장히 중요한 일이기에 — 하루아침에 이뤄지지는 않을 것이다.

여태까지 Figma의 정책들은 많은 부분에서 엄격하고 보수적인 접근을 취했으나 플러그인 만큼만은 상당히 개방적으로 풀어두었다. 아직 초기 단계인 만큼, 어떤 나쁜 정책이나 별로인 기능을 공개해 사용자경험을 해칠 수 있는 위험을 떠안는 것보다는, 자유롭게 풀어두어 커뮤니티가 스스로 알아서 방향성을 찾도록 하는 게 더 좋은 결정일 것이다. 또한 자유로운 정책은 이렇게 멋진 플러그인 데모도 만들 수 있도록 돕는다.

그러나 우리는 시간이 지나면서 Figma가 점차 생태계 발전에 직접적으로 개입하는 모습을 볼 수 있을 것이다. 단순하게만 봐도 알 수 있다. 현재 Figma의 플러그인 페이지를 방문해보면 지금은 인기순으로만 플러그인들을 찾을 수 있다. Slack과 Apple의 앱스토어처럼 플러그인 생태계가 커지게 되면 분명 Figma도 어떤 방식으로 플러그인들을 분류하고 관리해야 할지 고민해야 한다.

프로덕트의 관점에서 보아도, 어떤 형태의 플러그인을 내재화하고, 어떤 형태는 플러그인으로 두어야 할지 고민해야 하는 것은 당연한 수순이다. 어떤 방식으로 API 지원을 유지해야 하는지도 프로덕트 관점의 결정사항이다.

성장에 박차 가하기 (Pushing Progress)

디자인은 진화하고 있는가? 디자이너들은 예전보다 디자인을 더 잘하게 되었는가? 그저 예술적인 관점뿐만 아니라, 기능적인 업무로서 말이다.

답은 물론 “Yes”다. 우리는 10년 전만 해도 쓰는 것을 상상하기조차 힘들었던 도구들을 사용하고 있다. 예전보다 훨씬 디자인하기가 쉬워졌다. 디자인에 입문하기도 쉬워졌다. 디자인은 산업으로서의 확장성을 갖추게 되었다.

인접 영역인 엔지니어링과 비교해보면 어떨까. 엔지니어링이 몇 번 진화의 과정을 거치며 오늘날 초대형 산업으로서의 면모를 갖추게 된 것과 비교할 때, 디자인은 어떻게 될 것인가? 엔지니어링은 디자인 영역과는 비교도 할 수 없을 만큼 무섭고 빠르게 성장해왔다. 이것은 지금도 ‘현재진행형’이다. 프레임워크, 언어, 인프라 등 엔지니어링은 늘 진화하고 있다.

예전에는 무언가 작동하는 앱을 만들기 위해 코딩 군단이 필요했다면, 지금은 개발자 몇 명이 뚝딱 만들어 낸다.

Image for post

어느 직무든지 발전 과정에서 일을 더 잘하는데 필요한 사회적인 규칙이나 방법론이 생겨나고 그것을 반영한 도구들이 탄생하기 마련이다. 또한 이것들을 통해 전체적으로 모두가 더 일을 잘할 수 있는 관념 같은 것들을 만들 수 있게 된다. 디자인의 영역은 점차 엔지니어링이 발전했던 방향으로 나아가고 있는 것 같다. 그리고 Figma는 이 과정의 기로에 서 있다. 디자인 도구로서 디자이너 뿐만 아니라 다른 직무들까지도 디자인에 참여할 수 있게 해주기 때문이다.

Image for post

하지만 결국 Figma의 무한한 가능성은 플랫폼이 성공적으로 구축될 때 비로소 열릴 것이다. Figma이 만일 플랫폼화에 성공한다면, 이는 분명 디자인 직무 자체에 대한 무한한 발전을 초래할 것이다.

기업의 성패를 가르는 변수는 셀 수 없이 많고 운도 분명 큰 요인이 된다. 하지만 기업의 주도하에 어떤 특정 직무(discipline)가 큰 변화를 겪을 때, 변화를 주도하는 기업의 영향력은 상당해진다. 기업이 내리는 결정들 — 사회적 관념의 설정부터 시작해서 운영정책, 설계 등은 다음 세대에게까지도 영향을 미친다. 플랫폼 기업의 경우에는 더더욱이 이렇다. 생태계가 성장하면서 아직 굳지 않은 찰흙처럼 유기적으로 변형되고 발전하여 결국 생태계의 최종적인 모습을 형성한다. 기업들에게 이러한 생태계의 특성은 더할 나위 없는 큰 기회와 책임이며, Figma는 그 기회를 잡고 책임을 부여받은 것이다.

도움주신 분들

이 주제를 놓고 나와 열띤 토론을 해주고 글을 써서 배포할 수 있도록 격려해준 KeilaFong에게 감사의 말을 전한다. 또한, Max Bulger, Michael Dempsey, Kane Hsieh, Boris Jabes, Dave Petersen, Ryan Petersen, Kevin Simler, Eugene Wei도 나와 토론, 첨삭 과정에 참여해주었다. John Lilly는 Greylock Partners의 Figma 투자를 리드해주었다. 내가 가진 생산성과 협업에 관한 생각은 모두 John으로부터 시작되었다. 2014년에 그가 Figma에 투자를 하면서 쓴 투자기획서는 여전히 내게 선견지명이 있는 살아있는 글로 다가온다.

Casey WintersBrian Balfour에게도 감사드린다. 나는 그들이 만든 Advanced Growth Strategy 강의를 통해 Figma의 “루프”를 처음 생각하게 되었다. 나는 여전히 이 강의에서 Figma 사례 연구 수업을 가르친다.

모든 그래픽은 ProcreateFigma를 통해 만들었다. Procreate은 iPad로 그림 그리기에 적합한 최고의 도구다. 또한, 여기까지 내 글을 읽었는데 아직도 Figma가 무슨 도구인지 모른다면, 내가 당신에게 무슨 말을 건네야 할지 모르겠다. Procreate와 Figma 사이의 연동을 원하는 사람은 나밖에 없을지도 모르지만, 나는 정말 잘 쓸 자신이 있다.


이 글은 Figma 커뮤니티에서 크게 회자 되었던 Greylock의 전 투자자인 Kevin Kwok의 에세이 “Why Figma Wins”를 Kevin의 동의하에 Relate 팀이 번역한 글입니다.