디자인 소프트웨어의 대명사 어도비(Adobe)가 클라우드를 기반으로 협업에 특화된 제품을 만드는 피그마(Figma)를 200억 달러, 우리 돈으로 약 28조 원을 주고 인수하겠다고 발표해서 큰 관심을 모았다. 많은 사람들이 지나치게 큰 액수라고 생각하고, 실제로 발표 직후 어도비의 주식이 곤두박질치면서 정말로 무리한 인수가 아니냐는 말이 나왔다.

이에 대해 업계를 잘 아는 전문가인 아말 도라이(Amal Dorai)가 긴 트윗 스레드를 통해 이런 우려에 반대하며 이번 인수는 "테크업계의 역사에 길이 남을 현명한 결정"이라고 주장했다. 아주 쉽고 명확한 설명이어서 전문을 번역해서 소개한다. 참고로 아말 도라이는 대학원생 시절인 2005년에 한국 신문의 기사에 잠깐 등장한 적도 있다.

나는 어도비가 피그마를 200억 달러에 인수하겠다고 한 것이 놀랍지 않다. 그리고 월스트리트의 투자자들이 이를 이해하지 못하는 것이나 어도비의 시가 총액이 오늘 하루 동안 200억이 떨어진 것도 놀랍지 않다. 어도비가 피그마를 인수하려는 건 영리한 결정이다. 레거시(legacy) 소프트웨어 애플리케이션을 멀티유저(mutiuser, 복수의 사용자)가 협업을 할 수 있도록 바꾸는 작업은 불가능에 가깝기 때문이다.

그게 불가능에 가깝다는 걸 아는 건 내가 MS 오피스를 실시간 협업이 가능하도록 만드는 라이브루프(LiveLoop)라는 스타트업을 설립했기 때문이다. 마이크로소프트는 라이브루프를 2015년에 인수해서 MS 오피스를 실시간 협업이 가능한 소프트웨어로 만드는 데 막대한 투자를 했다. 그 결과 MS 오피스를 통한 협업은 2016년 보다 훨씬 좋아졌지만, 그럼에도 불구하고 구글앱(Google Apps) 수준에는 미치지 못한다.  

두 개의 장벽

레거시 애플리케이션을 멀티유저 애플리케이션으로 바꾸는 데는 두 개의 커다란 장벽이 있다. 하나는 파일 포맷과 그 포맷을 중심으로한 생태계, 레거시 클라이언트(오래된 버전이 설치된 컴퓨터–옮긴이), 그리고 하위 호환성 (backward compatibility, 새 버전의 소프트웨어가 이전 버전에서 별도의 수정 없이 그대로 쓰일 수 있도록 하는 것)이고, 다른 하나는 멀티 플레이어라는 환경이 가진 순전히 기술적인 난관이다.

먼저 파일 포맷부터 이야기해 보자. 레거시 애플리케이션은 "파일"로 소통한다. 가령 포토샵의 사용자들은 자신의 아카이브에 수천 개의 .psd 파일을 가지고 있고, 드롭박스 등을 통해 .psd 파일을 공유하고, 이메일로도 .psd 파일을 보낸다. 그들이 만든 파일은 대개 이런식 이름을 갖고 있다:

최종광고시안_v26_진짜최종시안_v6.psd

파일을 기반으로한 시맨틱스(semantics)는 사용자들이 인터넷과 연결되지 않은(offline) 환경에서도 작업할 수 있게 해주고, 자신의 데이터를 직접 소유하게 해준다. (데스크톱에 들어있는 파워포인트 파일에 접근이 불가능한 일은 일어나지 않지만 구글 계정으로의 접근은 막힐 수 있다.)

하지만 파일은 두 개의 큰 단점을 갖고 있다. 첫째, (포토샵에서 사용하는) PSD같은 레거시 파일 포맷은 소프트웨어 스펙(specification, 소프트웨어의 요구사항)만 수천 페이지에 달하는데, 그중 어떤 것도 멀티유저 애플리케이션을 염두에 두고 만들어지지 않았다. 그렇다고 파일 포맷을 무작정 바꿀 수도 없다. 그렇게 할 경우 옛날 버전의 포토샵을 가진 사용자들은 새로운 파일 포맷을 열지 못하게 되기 때문이다.

따라서 파일 포맷을 바꾸려할 때는 실시간 협업에 필요한 기능을–오래된 클라이언트 컴퓨터가 무시하는 방식으로–기존의 형식에 쑤셔 넣을 수 밖에 없다. 그래도 이건 해결할 수 있는 문제다. 해결할 수 없는 문제는 뭐냐면, 파일이라는 개념 자체가 멀티유저 애플리케이션과 호환 불가능하다는 사실이다.

컴퓨터 하드에 있는 파일은 하드 주인이 열어서 바꾸지 않는 한 최신판이지만, 여러 사용자가 같이 작업하는 파일은 언제 누가 수정할지 모르기 때문에 컴퓨터 하드 드라이브가 아닌 서버에 저장해서 네트웍으로 연결해서 수정한다. 이 공유 파일의 사본을 하드 드라이브에 다운받아두면 언제 이 파일이 최신판이 아니게 될지 알 수 없다.

구글앱이나 피그마같은 멀티유저 애플리케이션이 이런 문제를 피할 수 있는 것은 그들이 파일이라는 개념 자체를 거부하기 때문이다. 구글문서(Google Doc)는 다운로드할 수 없다. 다운로드했다면 그건 가령 그 문서의 특정 버전을 PDF 파일로 옮긴 것 불과하다. 네트워크와 연결하지 않고 구글 문서를 편집하는("edit locally") 것은 불가능하다.

그렇다. 이 말은 멀티유저 애플리케이션은 오프라인에서 사용할 수 없음을 의미한다. (오프라인에서 편집된 파일과 온라인 파일의 "통합"은 대부분의 사용자들에게는 너무나 복잡한 작업이다.) 기존의 애플리케이션(소프트웨어)들은 이를 용납할 수 없다. 사용자들에게서 익숙한 기능을 사용하지 못하게 만드는 일이기 때문이다.

하지만 구글앱과 피그마와 같은 애플리케이션은 사용자들이 어도비가 오프라인 편집 기능을 없애는 것을 허용하지 않지만 처음부터 그런 기능을 제공하지 않는 경쟁 애플리케이션은 불만없이 사용한다는 사실을 보여줬다. 인터넷 연결이 보편화되고 협업이 더욱 중요해지면서 오프라인 지원은 구시대의 유물이 되어 버렸다.

파일 기반의 애플리케이션을 사용하는 사람들은 전적으로 파일을 중심으로 한 워크플로(workflows, 작업흐름)를 갖고 있는 경우가 흔하다. 가령 판매 쪽에서 일하는 사람들은 파워포인트로 프리젠테이션을 준비하고 이를 .pptx 파일 포맷을 인식하는 클리어슬라이드(ClearSlide)나 사이즈믹(Seismic) 같은 외부(third-party) 툴을 사용해서 공유하고, 발표한다.

반면 피그마와 같은 멀티유저 애플리케이션의 경우 파일 포맷을 사용하는 대신 개발자 API를 통해 외부 워크플로의 사용을 가능하게 하고, 사용자들은 외부에 권한을 부여해서 피그마 서버에 저장된 문서에 직접 접근해서 읽거나 편집할 수 있게 한다. 개발자 API를 만드는 것은 기술적으로 어렵지만 (여기를 보라) 개발자 신뢰 프로그램(developer trust program)을 구축하는 건 더 어려운 일이다. 하지만 레거시 애플리케이션의 경우 신뢰도가 낮을 경우 파일 기반의 비즈니스 모델을 파괴한 후에 개발자들에게 API로 옮겨 탈(migrate) 것을 권한다.

하위호환성

이제 하위호환성(backwards compatibility)을 얘기해보자. 데스크톱용 레거시 애플리케이션(소프트웨어)은 지난 수십 년 동안 "한 번만 사면 평생 사용할 수 있는" 형태로 판매되었다. 가령 포토샵의 한 버전을 구입하면 업그레이드를 할 필요가 없었다. 이는 전 세계에서 다섯 개 이상의 서로 다른 버전의 포토샵이 돌아가고 있었다는 얘기다.

하위호환성은 패키지 단위로 소프트웨어를 판매하던 기업들에게 아주 중요한 문제가 되었다. 만약 포토샵 CS5가 만든 파일들을 CS4 버전의 사용자들이 사용할 수 없다면? 사용자들은 CS5로 업그레이드하는 것을 아주 망설이게 될 것이다. 그렇다면 업그레이드 버전을 팔아 돈을 버는 비즈니스 모델이 작동하기 어렵게 된다.  

단순히 어도비가 (새로운 버전에서) 색 깊이가 큰(high-depth) 컬러를 포토샵에 추가했다면 이전 버전에 호환될 수 있게 만드는 건 어렵지 않다. 연식이 오래된 클라이언트 컴퓨터에 있는 표준색에서 그 파일을 보여주면 된다. 하지만 멀티유저의 협업은 하위호환이라는 방법을 통하기에는 너무나 큰 변화다.

버전이 크게 다른 두 개의 소프트웨어 사이에서 멀티유저의 협업을 지원해야 하는 상황을 피하기 위해서는 멀티유저 애플리케이션이 웹을 통하거나 모든 참여자가 동일한 코드를 사용하는 테스크톱 컨테이너(desktop container)를 사용하는 수 밖에 없다.

포토샵이나 MS 오피스 같은 프로그램들은 웹을 통해서 사용하도록 설계되지 않았다. 이런 프로그램들은 크기가 일단 몇 기가 바이트에 달하는 애플리케이션이고, 프론트엔드(frontend)와 백엔드(backend)의 구분이 명확하지 않다. 반면 피그마와 같은 애플리케이션은 모든 것을 최대한 백엔드에 두고 웹 애플리케이션의 사이즈는 최소화하도록 설계되었다.

마지막으로 기술적 부채(technical debt)를 얘기해보자. 멀티유저를 염두에 두지 않고 설계된 애플리케이션에 멀티유저 기능을 넣는 일은 엄청나게 어려운 작업이다. 배에 바퀴를 달아서 땅에서 달리게 만드느니, 아예 배를 녹여서 자동차를 만드는 게 낫다.

이렇게 생각해보자. 100가지의 문서 기능(텍스트 추가, 색 변환, 앞으로 가져오기, 코멘트 추가, 투명도 바꾸기 등등)이 있는 애플리케이션을 두 명의 유저가 동시에 사용한다고 하면 이런 기능들이 작동할 수 있는 경우의 수는 100x100=10,000이다. 이 경우 레거시 애플리케이션이라면 유저가 기대에 어긋나지 않게 작동하도록 하기 위해 10,000개의 케이스를 정의하고, 수행해야 한다. 예를 들어 만약 한 유저가 제목 하나를 잘라서 2페이지에 붙이는 동안 다른 유저가 그 제목을 대문자로 바꾸는 작업을 수행한다면 그 두 사람은 제목이 2페이지에 붙을 뿐 아니라 대문자 전환도 이뤄질 것을 기대한다.

지난 수십 년 동안 판매된 레거시 애플리케이션들은 가능한한 많은 기능을 쑤셔 넣는 바람에 애플리케이션이 정의하고 수행해야 할 가능한 기능의 수가 엄청나다. (만약 한 유저가 페이지의 번호를 바꾸는 동안에 다른 유저가 문단 간격을 바꾼다면?)

반면 멀티유저 애플리케이션은 적은 수의 기능으로 출발한 후, 가능할 경우 기존의 기능들을 묶은 형태로 기능을 추가한다. 새로운 기능을 추가할 경우 그 회사에서 배정한 예산에는 새로운 기능들이 협업에서도 기존의 기능묶음과 문제없이 작동할 수 있게 하는 추가 작업이 포함된다.

결론

요약하면, 어도비는 피그마를 절대로 따라잡을 수 없었다. 어도비로서는 피그마의 아키텍처를 사용해서 자신들이 가지고 있는 기존의 애플리케이션을 새롭게 구축하는 것이, 기존의 어도비 애플리케이션을 피그마 수준으로 편리한 멀티유저 애플리케이션으로 바꾸려고 시도하는 것보다 쉽고, 비용도 적게 든다.

멀티유저 협업은 모든 애플리케이션의 미래이고, 피그마는 멀티유저 협업 애플리케이션 중에서도 타의 추종을 불허할 만큼 풍부한 애플리케이션이다. 어도비의 피그마 인수는 테크기업의 역사에서 가장 현명한 인수 결정으로 기억될 것이다. 이번 결정을 후회할 기업이 있다면 그건 어도비가 아니라 마이크로소프트일 거다. 마이크로소프트는 더 큰 액수를 제시했어야 한다.  

이 트위 스레드에 이어서 여러 사람들이 아말 도라이에게 질문을 했다. 그 중 두 개만 뽑아보면 아래와 같다:

"좋은 내용이지만 월스트리트가 (이번 딜의 가치를) 이해하지 못한다는 것에는 동의하지 않습니다. 월가의 투자자들은 두 기업의 통합 작업이 가진 리스크와 단기적인 불이익(현금부족)을 걱정해서 어도비 주식을 팔았다고 봅니다. 그들은 "당장 돈을 보여달라(Show me the money)"는 태도를 가진 사람들이니까요."

아말 도라이의 대답: 저는 피그마를 가지지 않은 어도비가 더 위험한 자산이라고 생각합니다. 시간이 지나면 피그마가 어도비의 매출을 상당부분 잠식할 테니까요. 인수 딜을 듣고 어도비 주식을 판 사람이라면 인수 발표가 나기 전에 팔았어야 한다고 봅니다.

"반독점법 위반이라는 장애물에 부딪힐까요?

아말 도라이의 대답: 그럴 가능성은 분명히 있습니다만, 얼마나 큰지는 모르겠습니다.