엔터프라이즈 고객을 위한 아키텍처 재설계

주간SaaS 오늘의 소개 글

아키텍처는 변화할 수 밖에 없습니다. 당연하고 멈춰 있는 아키텍처는 있을 수 없습니다. 비즈니스를 막 시작했을 때 목표를 반영한 아키텍처와 지금의 비즈니스 환경이 요구하는 아키텍처는 다를 수 밖에 없기 때문이죠. 오늘 소개하는 Slack은 사례는 이런 변화를 어떻게 만들어갔는지 그 아키텍처 재설계의 여정을 보여 줍니다. 

모든 소프트웨어는 처음에 세운 몇 가지 중요한 가정을 토대로 만들어집니다. 하지만 시간이 흘러 코드가 덧쌓이고 사용 방식이 달라지면서 처음의 가정과는 전혀 다른 모습이 되기도 합니다. 이럴 때 개발자들은 고민에 빠지게 되죠. 지금까지 쌓아온 것을 엎고 처음부터 다시 시작해야 할까? 아니면 지금의 구조를 유지한 채 새로운 기능을 억지로 끼워 넣어야 할까? 물론 대부분의 경우 시간과 위험 부담을 줄이기 위해 기존 구조를 유지하는 쪽을 택합니다.

하지만 가끔은, 아주 가끔은 전체 시스템을 갈아엎는 모험이 필요한 순간이 찾아옵니다. 슬랙이 최근 경험한 '통합 그리드(Unified Grid)' 프로젝트가 바로 그랬습니다. 저희는 과감하게 백엔드 시스템과 데스크톱, 모바일 앱 등 클라이언트가 데이터를 주고받는 방식 자체를 완전히 바꾸는 대대적인 작업을 감행했습니다.

슬랙은 2013년, 비교적 단순한 구조로 서비스를 시작했습니다. 사용자는 각자 '워크스페이스' 라는 공간에 소속되어 채널에 참여하고 메시지를 주고받았죠. 로그인한 다른 워크스페이스의 메시지를 보려면 해당 워크스페이스를 클릭해야 했습니다.

이러한 구조는 2017년 'Enterprise Grid' 출시와 함께 변화를 맞이하게 됩니다. Enterprise Grid는 대기업 고객이 조직 특성에 맞게 여러 개의 워크스페이스를 만들고 관리할 수 있도록 지원하는 기능입니다. 처음에는 대부분의 사용자가 하나의 워크스페이스에만 속해 있었지만, 시간이 지나면서 여러 워크스페이스를 동시에 사용하는 경우가 늘어났습니다. 슬랙은 이러한 사용 패턴 변화에 발맞춰 '스레드', '읽지 않은 항목'과 같이 여러 워크스페이스의 데이터를 하나의 화면에서 보여주는 기능과 워크스페이스 간 채널 기능을 새롭게 선보였습니다.

하지만 새로운 기능들을 추가할수록 기존 시스템과의 '충돌'은 점점 더 심해졌습니다. "만약 사용자가 여러 워크스페이스를 넘나들며 일하는 게 당연해졌다면, 모든 데이터를 한 곳에서 볼 수 있도록 하는 게 맞지 않을까?" "여러 워크스페이스에 흩어진 데이터를 한 화면에 모아 보여준다면 사용자 경험도 좋아지고, 데이터 동기화 문제로 인한 버그도 줄일 수 있지 않을까?" "API 요청을 한 번만 보내도 여러 워크스페이스의 데이터를 불러올 수 있다면 속도도 훨씬 빨라질 텐데?"

이러한 의문에서 시작된 프로젝트가 바로 '통합 그리드'입니다. 하지만 슬랙이 '한 사용자는 하나의 워크스페이스에 속한다'는 전제 하에 설계되었다는 점을 생각하면 이는 불가능에 가까운 시도였습니다. 그럼에도 불구하고 저희는 '통합 그리드' 프로젝트를 시작하기로 결정했습니다. 기존 시스템의 한계에 계속 부딪히는 상황에서, 이 문제를 해결하지 않고는 앞으로 나아갈 수 없다는 걸 잘 알고 있었기 때문입니다.

Enterprise Grid, 슬랙 아키텍처 변화의 시작

'통합 그리드' 프로젝트가 왜 그렇게 어려운 과제였는지 이해하려면 슬랙의 시스템 구조와 수년간의 변화 과정을 살펴봐야 합니다.

2013년 처음 서비스를 시작했을 때만 해도 슬랙의 시스템은 아주 단순했습니다. 사용자는 특정 워크스페이스에 속해서 활동했고, 관련 데이터는 모두 해당 워크스페이스 전용 데이터베이스 샤드에 저장됐습니다. 각 워크스페이스는 하나의 고객을 나타냈고, 관련된 모든 데이터는 '샤드(Shard)'라는 별도의 데이터베이스 서버에 저장되었습니다. 슬랙 앱은 사용자 ID와 워크스페이스 ID가 담긴 '워크스페이스 토큰'이라는 세션 토큰을 이용해 API 요청을 인증했습니다. 서버는 이 토큰 정보를 바탕으로 요청을 적절한 워크스페이스로 연결하고, 해당 워크스페이스의 데이터베이스 샤드에 접근하여 데이터를 가져오거나 권한을 확인했습니다.

슬랙은 성장하면서 자연스럽게 대기업 고객을 유치하게 되었고, 이 과정에서 기존 시스템의 한계에 부딪히게 됩니다. 거대 조직이 슬랙을 효율적으로 사용하기 위해서는 부서별로 여러 개의 워크스페이스를 생성해야 했는데, 기존 시스템으로는 이를 효율적으로 관리하기가 어려웠기 때문입니다. 예를 들어, 회사 전체에 적용되는 보안 정책이나 결제 관리 등을 각 워크스페이스 별로 따로따로 해야 한다면 얼마나 불편할까요?

이러한 불편을 해결하기 위해 탄생한 것이 바로 'Enterprise Grid'입니다. Enterprise Grid는 여러 워크스페이스를 하나로 묶어 관리할 수 있는 기능으로, 슬랙을 사용하는 대기업 고객에게 필수적인 기능이 되었습니다.

'Enterprise Grid'를 구현하기 위해 슬랙은 '조직'이라는 새로운 개념을 도입했습니다. '조직'은 여러 개의 워크스페이스를 아래에 두고 관리하는 일종의 상위 그룹과 같은 역할을 합니다. 사용자는 여전히 특정 워크스페이스에 소속되어 활동하지만, 데이터는 워크스페이스 레벨이 아닌 조직 레벨에 저장될 수도 있게 되었습니다.

예를 들어 '워크스페이스 간 채널(corss-workspace, XWS)' 기능을 사용하면 서로 다른 워크스페이스에 속한 사용자들이 하나의 채널에서 함께 대화할 수 있습니다. 이 경우 대화 내용은 특정 워크스페이스가 아닌 '조직' 레벨에 저장되기 때문에 모든 워크스페이스의 사용자가 동일한 내용을 볼 수 있습니다.

환경의 변화

처음 Enterprise Grid를 출시했을 때만 해도 사용자들은 대부분 하나의 워크스페이스만 사용했기 때문에 큰 문제가 발생하지 않았습니다. 하지만 시간이 지남에 따라 여러 워크스페이스를 동시에 사용하는 사용자들이 늘어나면서 불편을 호소하는 사례가 증가하기 시작했습니다. 워크스페이스 간 전환이 번거롭고, 중요한 알림을 놓치는 경우도 발생했습니다.

저희는 이러한 문제들을 해결하고 싶었고, 다행히 그동안 진행해 온 인프라 개선 작업들이 해결의 실마리를 제공했습니다. 먼저 'Vitess'라는 시스템을 도입하여 워크스페이스나 조직 ID 외에 다른 기준으로 데이터를 분산 저장할 수 있게 되었습니다. 즉, 더 이상 특정 워크스페이스나 조직 정보가 없어도 중요 데이터에 접근할 수 있게 된 것입니다. 또한 실시간 메시지(RTM) 시스템을 개선하여 조직 레벨 데이터를 모든 워크스페이스에 실시간으로 동기화할 필요성을 없앴습니다. 수천 개가 넘는 워크스페이스를 운영하는 대기업 고객도 문제없이 슬랙을 사용할 수 있도록 말이죠. 마지막으로 앱 자체도 업데이트하여 여러 워크스페이스에 흩어진 조직 데이터를 하나로 모아 관리할 수 있도록 했습니다. 이러한 인프라 개선을 통해 '스레드', '읽지 않은 항목' 보기와 같이 여러 워크스페이스의 콘텐츠를 한 화면에 모아 보여주는 기능도 구현할 수 있었습니다. 하지만 이러한 노력에도 불구하고 워크스페이스 중심적인 설계라는 근본적인 문제는 여전히 남아있었습니다. 결국 수천 개가 넘는 API, 데이터베이스 쿼리, 권한 설정들을 수정해야 하는 엄청난 작업이 필요했지만, 저희는 '조직' 중심적인 시스템으로의 전환을 결심했습니다.

프로토타입 과정

담당 개발팀은 물론 경영진까지, 모두가 '통합 그리드' 프로젝트의 성공 가능성에 의문을 제기했습니다. 엄청난 시간과 비용을 투입할 만한 가치가 있는 프로젝트인지 확신하기 어려웠기 때문입니다.

저희는 수천 개의 API를 한 번에 고치는 대신, 작은 부분부터 단계적으로 문제를 해결해 나가기로 했습니다. 슬랙 구성원들이 직접 '통합 그리드' 프로토타입을 사용하면서 문제점을 찾고 개선해 나가는 방식을 택한 것입니다. 누구보다 슬랙을 잘 아는 사람들이 직접 사용해 보면서 개선해 나간다면 자연스럽게 좋은 결과물이 나올 거라고 생각했습니다.

가장 먼저 해결해야 할 과제는 앱 실행 시 특정 워크스페이스가 아닌 '조직' 전체 채널 목록을 보여주는 것이었습니다. 저희는 사용자가 속한 모든 워크스페이스와 채널 정보를 한 번에 불러오는 새로운 API를 만들고, 앱이 이 정보를 '조직' 레벨에서 관리하도록 코드를 수정했습니다.

앱 실행 문제를 해결한 뒤에는 슬랙 API 프레임워크를 '통합 그리드'에 맞게 수정하는 작업을 시작했습니다. 그리고 내부 테스트를 진행하면서 하나씩 문제를 해결해 나갔습니다. 특히 개발자들이 실제 업무에 지장을 받는 중요한 문제들을 우선적으로 해결했습니다.

API 수정 과정에서 저희는 크게 세 가지 전략을 사용했습니다.

프로토타입 개발 초기에는 여기저기 문제가 튀어나왔지만, 시간이 지날수록 '통합 그리드'의 편리함이 뚜렷하게 느껴지기 시작했습니다. 이후 더 많은 동료들을 테스트에 참여시켰고, 심지어 당시 CEO였던 스튜어트 버터필드도 테스트에 참여했고, "확실히 이게 더 낫네요"라는 긍정적인 반응을 보였습니다.

프로토타입에서 정식 출시까지

'통합 그리드' 프로젝트는 슬랙 앱이 사용하는 모든 API와 권한 설정에 영향을 주는 대규모 프로젝트였습니다. 수십 명의 개발자가 투입되어 수개월 동안 작업해야 했고, 새로운 디자인과 기능을 담은 IA4 업데이트와 동시에 진행해야 하는 어려움도 있었습니다. 결국 '통합 그리드'는 IA4 업데이트의 핵심 기능으로 포함되었고, 회사의 최우선 과제로 진행되었습니다.

저희는 먼저 먼저 슬랙 앱에서 사용하는 모든 API와 권한 설정 목록을 스프레드시트에 꼼꼼하게 정리한 후, 각 개발팀에 작업을 분배했습니다. 그리고 앞서 말한 '단계적 개선' 전략에 따라 모든 API를 두 단계에 걸쳐 검토했습니다. 첫 번째 단계에서는 내부 테스트를 통과할 수 있을 정도로 기본적인 기능을 구현하는 데 집중했습니다. 그리고 몇 주 후, 두 번째 단계에서는 실제 서비스 환경에서 발생할 수 있는 다양한 예외 상황과 권한 문제를 해결하는 데 집중했습니다. 이러한 2단계 검토 방식을 통해 아직 완벽하지 않은 기능이라도 미리 테스트하고 개선할 수 있었습니다.

핵심 개발팀은 이제 프로토타입 제작에서 벗어나, 다른 개발팀들이 '통합 그리드' 개발에 참여할 수 있도록 다음과 같은 다양한 도구와 프레임워크를 제공하는 데 집중했습니다:

마치며

2023년 여름, 드디어 슬랙 구성원 대부분이 일상 업무에서 '통합 그리드'를 사용할 수 있을 만큼 안정적인 버전이 완성되었습니다. 그리고 몇 달간의 베타 테스트를 거쳐 2023년 가을부터 순차적으로 정식 출시를 시작했고, 2024년 3월 모든 사용자를 대상으로 서비스를 시작했습니다. 2년 가까이 진행된 대장정 끝에, 처음에는 제대로 작동할까 싶었던 프로토타입이 새로운 슬랙의 핵심 기능으로 완전히 자리 잡게 된 것입니다.

물론 기존 시스템을 뒤엎는 대규모 업데이트는 가급적 피하는 것이 좋습니다. 하지만 슬랙의 '통합 그리드' 프로젝트는, 때로는 과감한 도전이 최고의 결과를 가져올 수 있다는 것을 보여주는 좋은 사례입니다.

'통합 그리드' 프로젝트는 성공적으로 마무리 되었지만, 저희는 여전히 배가 고픕니다. 더 유연하고 강력해진 '통합 그리드'를 기반으로 어떤 새로운 기능과 서비스를 만들 수 있을지 끊임없이 고민하고 있습니다. 앞으로 슬랙이 어떤 모습으로 진화할지 지켜봐 주세요!

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요