Doximity는 Rails의 ‘검증된 경로’와 뛰어난 유연성 덕분에 비즈니스 로직에 맞게 쉽게 커스터마이징하고 ‘제로에서 백까지’ 신속하게 개발할 수 있었다고 강조합니다. 이는 다른 프레임워크에서는 찾아보기 힘든 Rails만의 강점입니다. 2016년 약 20명 미만이던 Rails 개발팀은 현재 100~150명 규모로 성장했습니다.
GraphQL의 도입은 Vue.js로의 프론트엔드 전환과 모바일 클라이언트 지원의 필요성에서 비롯되었습니다. 기존 REST API의 경우 모바일 클라이언트의 호환성을 깨뜨리기 쉬웠으나, GraphQL은 타입 안정성을 제공하여 이러한 문제를 해결하고 크로스 팀 협업을 용이하게 했습니다. 초기에는 Rails 모놀리스 내에서 GraphQL-Ruby 젬을 활용했으며, 클라이언트가 요청하는 데이터 형태를 예측하기 어렵다는 GraphQL의 특성으로 인해 N+1 문제를 방지하기 위해 Shopify의 Batch Loader 젬을 사용하여 쿼리 로딩을 지연시키는 방식을 채택했습니다.
이후 GraphQL Federation으로의 전환은 시스템 복원력과 개발자 경험 향상을 위한 필수적인 결정이었습니다. 모놀리스 내에서 외부 마이크로서비스의 데이터를 GraphQL 스키마에 매핑하는 과정이 복잡하고, 특정 서비스의 장애가 전체 시스템에 영향을 미치는 ‘전이적 의존성(transitive dependencies)’ 문제가 발생했기 때문입니다. Federation 도입으로 각 팀은 독립적으로 도메인을 구현하고 배포할 수 있게 되어, 모놀리스와 독립적인 서비스의 복원력을 확보했습니다.
Doximity는 새로운 서비스 구축 시 ‘실용주의’를 최우선으로 합니다. 신속한 출시가 필요한 경우 기본적으로 모놀리스 내에 기능을 개발하고, Packwerk 젬을 활용하여 코드 베이스 내에서 도메인을 분리합니다. 반면, Residency Navigator와 같이 장기적으로 독립적인 운영과 높은 가용성이 필요한 서비스는 별도의 Rails 애플리케이션으로 분리합니다. 이러한 결정은 유지보수 비용, 설정 및 배포의 복잡성 등을 고려하여 신중하게 이루어집니다.
실시간 기능의 경우, Doximity는 ActionCable과 AnyCable을 활용합니다. 특히 전화 및 영상 플랫폼과 같이 실시간성이 중요한 서비스에는 AnyCable(Go 서비스 기반)을 사용하여 대규모 연결 부하와 배포 시 연결 끊김 문제를 해결합니다. 메시징 서비스 등 일부 영역에서는 사용자 요구에 따라 실시간 업데이트를 우선순위에서 낮추기도 합니다.
대규모 조직에서 디버깅 및 데이터 관리는 중요한 도전 과제입니다. Doximity는 개발 환경을 위한 ‘seed data’와 ‘sample data’를 체계적으로 관리하며, SRE 팀이 인프라를 지원합니다. 데이터 마이그레이션 시에는 Departure 젬과 PT online schema migrator와 같은 도구를 사용하여 테이블 잠금을 방지하고, 대규모 데이터 변경은 비동기 작업으로 처리합니다. 또한, rake task나 Thor를 활용한 일회성 스크립트를 작성하고, 이들 스크립트에도 테스트 코드를 작성하여 신뢰성을 확보합니다.
조직 전체의 일관된 패턴을 확립하기 위해 Doximity는 ‘적응적’ 접근 방식을 취합니다. 특정 문제가 반복되거나 팀 간 구현 방식에 큰 차이가 발생할 때 플랫폼 팀이 개입하여 표준화된 솔루션을 제공합니다. ‘니즈 평가(needs assessments)’ 및 ‘기술 제안(technical proposals)’과 같은 내부 문서를 통해 아이디어를 공유하고 피드백을 수렴하며, 분기별 계획을 통해 목표를 명확히 하고 자원을 배분합니다. 높은 신뢰도를 바탕으로 한 개방적인 소통 문화와 오프사이트 미팅은 팀 간의 협업과 문제 해결에 크게 기여합니다.