슬랙의 가파른 성장을 뒷받침한 퍼블릭 클라우드, 그리고 당면 과제

다른 그룹 메시징이 추락하는 동안 슬랙이 성공한 이유는 무엇일까? 비결은 간소함이다. 슬랙은 실용적인 대화방 디자인을 통해 모든 기능을 클릭 한 번으로 이용할 수 있도록 했다. 비공개 채널, 손쉬운 통합, 간단한 파일 공유 역시 장점이다.

그러나 멈추지 않는 성공의 비결은 드러나지 않는 뒤에 있다. 아무것도 없이 시작해 3년 만에 일일 활성 사용자 수가 500만 명에 이르는 동안 슬랙은 서비스의 안정성과 응답성을 유지했고, 중단과 사고가 발생하더라도 그에 대해 투명함을 유지해 좋은 인상을 남겼다. 또한, 슬랙에는 10만 명 이상의 외부 개발자가 참여해서 최근 집계를 기준으로 900여 개의 독립 앱을 만들었다.

갑자기 등장한 슬랙은 점점 더 많은 기업 조직에서 필수 애플리케이션으로 자리를 잡아가며 그 입지를 점점 더 넓히는 중이다. 슬랙의 인프라 엔지니어링 책임자인 줄리아 그레이스는 지난 주 인터뷰에서 “IBM, 캐피탈 원과 같은 대기업이 슬랙을 기반으로 비즈니스를 운영한다”면서 “느긋할 틈이 없다. 항상 빠르게 움직여야 한다”고 말했다.

그레이스가 슬랙에 입사한 2015년 10월 이후 슬랙 사용자 수는 두 배로 늘었다. 슬랙 창업자들이 애초에 퍼블릭 클라우드에 슬랙을 구축하기로 결심하지 않았다면, 이처럼 빠른 성장에 맞춰 대응하기는 지금보다 훨씬 더 힘들었을 것이다. 흥미롭게도 이 결정이 내려진 시기는 2009년인데, 당시 슬랙은 타이니 스펙(Tiny Speck)이라는 이름의 게임 회사로 브라우저 기반 대규모 다중 사용자 온라인 게임인 글리치(Glitch)를 운영 중이었다.

슬랙의 초석은 게임
그레이스는 “글리치 개발 시절에는 클라우드 업체들이 많지 않았다. 특히 높은 신뢰성과 업타임이 필요한 비즈니스를 구축하려는 경우에는 선택권이 더욱 없었다”고 말했다. AWS가 사실상 유일한 선택안이었다.

나중에 드러났듯이 클라우드의 확장성뿐만 아니라 글리치의 게임 아키텍처도 슬랙의 성공에 결정적인 역할을 했다. 슬랙 최고 설계자인 케이스 애덤스는 지난해 12월 InfoQ 프레젠테이션에서 글리치의 최초 게임 디자인이 지금도 계속 유지되고 있다며 다음과 같이 밝혔다.

슬랙의 실제 아키텍처는 대규모 다중 사용자 온라인 게임의 아키텍처와 닮았다. 사용자가 활동하는 일종의 세계, 즉 자신이 속한 팀이 있다. 그 세계를 지속적인 세계로 보이게 하고 다른 사물과 상호 작용을 통해 변하는 세계로 만들기 위해서는 현재 그 세계에서 일어나고 있는 일들에 관해 두터운 캐시를 만들어야 한다. 그러면 그 세계의 변화에 대한 지연 업데이트 방법을 갖게 된다. 결국 슬랙의 많은 부분은 “온라인 게임하고 비슷하다”는 말로 설명이 가능하다.

애덤스는 슬랙의 회사 스타일을 “보수적”이라고 설명한다. 애덤스는 간단히 설명하자면 슬랙이 “아주 적절히 실행된 스케일 아웃 LAMP 스택이며 MySQL을 중심으로 포장된 멤캐시(memcache)”라고 설명했다. MySQL을 선택한 이유는 “수많은 서버가 데이터 손실 없이 MySQL을 운영해온 시간, 다 합치면 수천 년에 이르는 그 역사 때문”이다.

또한 슬랙은 유행하는 마이크로서비스 아키텍처를 적어도 지금까지는 피해왔다. 핵심 애플리케이션은 페이스북의 힙합(HipHop) 가상 머신과 JIT(Just-In-Time) 컴파일러를 사용하는 PHP 단일체다(애덤스는 페이스북 엔지니어 출신임).

넓은 관점에서 보면 기본적으로 슬랙은 자바로 직접 작성한 메시징 버스와 결합된 대규모 웹 애플리케이션이다. 애덤스는 버스를 직접 제작한 이유에 대해 고전적인 “만들기 대 구입하기”의 관점에서 설명했다. “상용 소프트웨어를 구입해서 정확히 원하는 동작을 하도록 개조하는 데 들어가는 노력을 감안하면 그냥 원하는 프로그래밍 언어로 원하는 동작을 직접 프로그램하는 게 더 나을 때도 있다.”

신중한 발전
인프라 측면에서 그레이스는 간소함에 대한 애덤스의 신념에 동조한다. 그레이스는 지난 주 AWS 서밋 기조 연설에서 “슬랙은 S3, EC2, 클라우드프론[AWS의 콘텐츠 배포 네트워크]와 같은 기초적인 서비스를 선호한다”고 말했다.

그러나 슬랙은 신중하긴 해도 계속 발전하고 있기도 하다. 그레이스는 “천천히 각 부분을 들어내 서비스를 만들고 있다. 이렇게 해서 좀더 격리된 환경을 만들어 실행, 빌드, 배포, 확장 등을 할 수 있다. 우리 팀에서는 슬랙의 모놀리식 아키텍처에 연결되는 다양한 서비스를 실행하고 있으며 다른 것들도 천천히 떼어내는 중”이라고 말했다.

슬랙은 처음부터 검색에는 아파치 Solr, 로그 데이터 크런칭에는 EMR을 사용해 인프라에 대한 시야를 확보했다. 그레이스는 AWS 서밋에서 AWS의 최신 AI와 머신 러닝 기능을 이용하기 위한 새로운 API와 SDK 모음인 아마존 렉스(Lex) 도입에 대해서도 이야기했다. 그레이스는 “렉스를 통해 대화 봇을 만들기가 훨씬 더 간단해질 것”이라면서 이것이 슬랙의 차별화 기능 중 하나가 될 것임을 암시했다.

또한 슬랙의 독립 개발자 커뮤니티는 회사가 나아가야 할 방향을 알려주는 데 있어 그동안 중요한 역할을 해왔다. 그레이스는 “외부 개발자들의 사용 패턴과 이들의 API 호출을 관찰하고, 장기간에 걸쳐 슬랙 플랫폼을 기반으로 무엇을 쌓아 올리고 어떻게 변경했는지 파악할 수 있다. 이는 미래 기능을 계획할 때 반영하는 중요한 부분”이라고 말했다.

그 외에도 그레이스는 조만간 중대한 결정을 내려야 한다. 바로 장애 복구를 위해 클라우드 공급업체를 다변화해야 하는지 여부다. 당면한 질문은 다음과 같다.

아마존에서 필요한 안정성과 속도를 얻을 수 있는가…아니면 예를 들어 S3의 가동 중단과 같은 사고가 발생하더라도 고객이 계속 작업을 할 수 있도록 하기 위해 클라우드를 다변화해야 하는가? 고객이 미국 서부에서 발생하고 있는 사고에 대해 걱정할 필요가 없도록 하려면 어떻게 해야 하는가?

예를 들어, 구글 클라우드로 슬랙을 복제한다면 방대한 작업이 될 것이다. 특히 슬랙이 트래픽 미러링을 원한다면 더욱 그렇다. 그레이스는 “장애 복구 시나리오를 이해하고, 실제로 원활하게 장애 복구를 할 수 있다고 확신하려면 대규모 운영 경험이 필요하다”면서 “그래야 사고가 발생해도 당황하지 않고 트래픽을 전환 또는 리라우팅하거나 기타 다른 작업을 처리할 수 있다”고 말했다.

모든 신생 기업(엔터프라이즈 이니셔티브도 마찬가지)은 첫 릴리스 전에 내려진 의사 결정을 계속 안고 가야 한다. 중요한 시장에서 기록적으로 빠른 시간 내에 독보적 입지에 올라선 슬랙과 같은 실시간 메시징 시스템에서 이러한 의사 결정의 영향은 더욱 크게 나타난다. 이러한 기초적인 부분에 대한 변경은 한참 고속도로를 달리는 차에서 엔진을 바꾸는 것과 마찬가지이기 때문이다. 슬랙이 미래를 어떻게 헤쳐 나갈지 지켜보는 일은 아주 흥미로울 것이다. editor@itworld.co.kr