Zendesk의 아키텍처는 초기 ‘공유 로직을 가진 Rails 앱 세트’에서 시작하여, 인수 합병에 따른 ‘서비스 데이터’ 공유, 그리고 현재의 ‘이벤트 기반 아키텍처(Kafka)’로 점진적으로 진화했습니다. 이는 마이크로서비스의 유행 속에서도 모놀리스의 장점을 유지하면서 필요한 경우에만 서비스를 분리하는 실용적인 접근 방식을 따랐음을 보여줍니다. 특히, 제이슨 워너(Jason Warner)의 스펙트럼 비유처럼, 스타트업 초기에는 빠른 반복을 위해 모놀리스가 유리하며, 시장 적합성을 찾은 후 점진적으로 분리하는 것이 바람직하다는 관점을 Zendesk의 경험을 통해 뒷받침합니다.
데이터베이스는 Zendesk의 시스템에서 Ruby 자체보다 훨씬 큰 병목 현상으로 작용했습니다. 방대한 데이터 세트를 관리하기 위해 Zendesk는 샤딩(sharding)과 활성/비활성 데이터(active/non-active data)의 명확한 구분을 도입했습니다. 아나톨리는 데이터베이스의 세 가지 핵심 속성(성능, 쿼리 처리 능력, 데이터 저장 용량) 중 두 가지만을 동시에 만족시킬 수 있다는 물리적 한계를 강조하며, Zendesk가 이 한계 속에서 어떻게 데이터 관리 전략을 진화시켰는지 설명합니다. 즉, Ruby는 느리지 않으며, 데이터베이스가 시스템 성능의 핵심 요소임을 역설합니다.
안정성과 품질 유지를 위해 Zendesk는 광범위한 테스팅을 핵심 가치로 삼고 있습니다. 160만 라인 이상의 코드와 5만 5천 개 이상의 테스트를 보유하고 있으며, MiniTest의 개발자이자 유지보수자인 라이언 데이비스(Ryan Davis)의 주도하에 MiniTest를 적극적으로 활용합니다. MiniTest는 빠르고, 작으며, ‘마법’이 적다는 장점으로 Zendesk의 방대한 테스트 환경에 최적화되어 있습니다. 배포 파이프라인은 스테이징(staging)에서의 통합 테스트, 카나리(canary) 배포, 그리고 모든 프로덕션 포트(pot)에 걸친 표준 테스트 스위트 실행 등 다단계 검증 과정을 거칩니다. 총 3시간이 소요되는 이 과정은 안정적인 서비스 제공을 위한 Zendesk의 노력을 보여줍니다. 또한, GitHub의 코드 오너(code owners) 기능을 통해 코드 책임자를 명확히 하여, 570명 이상의 커미터가 참여하는 대규모 코드베이스의 혼란을 방지하고 협업을 효율화합니다.
오랜 기간 Rails를 사용해온 만큼, Rails 버전 업그레이드는 Zendesk의 중요한 도전 과제였습니다. Rails 1.0부터 현재 7.1/7.2 버전까지 업그레이드를 이어온 비결은 ‘솔직한 테스팅’입니다. 현재 버전과 다음 버전에 대해 동시에 테스트를 실행하여 회귀(regression)를 방지하는 전략을 사용합니다. 초기에는 메타 프로그래밍(meta-programming)과 몽키 패칭(monkey patching)이 업그레이드의 주요 걸림돌이 되었으며, 특히 Rails 4에서 5로의 업그레이드는 2년 반이라는 긴 시간이 소요될 정도로 어려웠습니다. 이는 코드의 ‘마법’을 줄이고 단순화하는 방향으로 전환하는 계기가 되었습니다. 또한, Zendesk가 자체적으로 개발했던 기능들(예: strong parameters, sharding)이 Rails에 공식적으로 통합되면서 기존 구현을 대체해야 하는 ‘선점자 불리(first-move disadvantage)’를 겪기도 했습니다. 이러한 경험을 바탕으로, 새로운 기능을 개발할 때는 커뮤니티와 소통하고 협력하는 것이 중요하다는 교훈을 강조합니다.