Intercom은 2011년부터 Rails 기반으로 구축된 서비스로, 12년간의 개발을 통해 약 800개의 Active Record 모델과 200만 라인에 달하는 코드를 가진 복잡한 다중 테넌트 시스템으로 성장했습니다. 이러한 거대한 환경에서 고객 데이터의 격리 및 보안은 핵심적인 과제였으나, 기존에는 주로 엔지니어의 모범 사례와 구전 지식, 수동 QA, 그리고 버그 바운티 프로그램에 의존하고 있었습니다. 이는 데이터 유출과 같은 보안 사고의 위험을 내포하고 있었으며, 개발 속도 저하를 야기했습니다. 본 발표는 Intercom이 이러한 문제점을 해결하고 다중 테넌트 시스템에서 데이터 격리를 강화하기 위해 진행한 'Guard Rails' 프로젝트의 배경, 해결 과정, 그리고 그 결과를 상세히 다룹니다.
Intercom은 12년간 개발된 대규모 다중 테넌트 Rails 시스템에서 고객 데이터 격리 문제를 겪었습니다. 약 800개의 Active Record 모델과 200만 라인 코드 규모에서, 데이터는 여러 MySQL 클러스터에 분산되어 있었고 모델이 앱 연관성 없이 직접 조회되는 경우가 많아 데이터 유출 위험이 있었습니다. 사용자가 여러 앱을 오갈 수 있어 요청 시 정확한 앱 컨텍스트 식별이 중요했고, 이에 ‘Guard Rails’ 프로젝트는 ‘앱 X가 앱 Y의 프라이빗 데이터에 접근하는 것을 절대 허용하지 않는 것’을 목표로, 잘못된 접근 시 예외를 발생시켜 보안 사고를 ‘단순한 가용성 사고’로 전환하는 방식을 채택했습니다.
해결책은 ‘올바른 앱’ 컨텍스트를 정의하고 이를 데이터 접근 검증에 활용하는 것입니다. 각 웹 요청에 단일 ‘올바른 앱’이 있다는 가정을 세우고, 해당 앱 객체를 스레드 로컬 변수에 저장하여 with_safe_app 블록 내에서 안전하게 접근하도록 구현했습니다. 이 컨텍스트는 비동기 작업에도 미들웨어를 통해 전파되었습니다. 이 컨텍스트를 활용하여 데이터 접근을 검증하기 위해 ApplicationRecord의 after_initialize 콜백을 통해 모델 인스턴스화 시 safe_app의 ID와 모델의 app_id가 일치하는지 확인했습니다. 초기에는 메트릭을 기록하여 문제 지점을 식별하고, 수백 건의 PR을 통해 엣지 케이스를 수정 및 제외 목록을 문서화했습니다. 컨텍스트가 안정화되자, 콜백은 직접 예외를 발생시켜 잘못된 데이터 접근을 원천 차단했습니다. Rails 캐시 보호도 유사하게 구현되어, 캐시 항목에 safe_app_id를 포함시켜 언마샬링 시 검증하고 불일치 시 예외를 발생시켰습니다.
'Guard Rails' 프로젝트는 Intercom의 다중 테넌트 Rails 애플리케이션에서 오랜 기간 축적된 데이터 격리 문제를 성공적으로 해결했습니다. 이 프로젝트는 단순히 데이터 보안을 강화하는 것을 넘어, 기존에 모호했던 데이터 모델링 가정을 명확히 하고 문서화하는 부수적인 효과를 가져왔습니다. 또한, 각 요청을 특정 앱에 귀속시킬 수 있는 견고한 컨텍스트 계층을 구축함으로써, 예상치 못한 다양한 운영상의 이점을 창출했습니다. 예를 들어, 특정 고객의 경험을 추적하고 컴퓨팅 자원 사용량을 분석하며, 데이터베이스 샤딩 라우팅을 자동화하고, 비상시 특정 고객의 요청을 차단하는 '킬 스위치'를 구현하는 등의 활용이 가능해졌습니다. 이처럼 'Guard Rails' 프로젝트는 복잡하고 오래된 시스템에서 데이터 격리 문제를 해결하는 모범적인 사례를 제시하며, 견고한 시스템 아키텍처 구축의 중요성을 강조합니다.