설정 기반 멀티테넌트 아키텍처란 무엇인가
Instacart는 수백 개의 리테일 브랜드를 운영하면서 브랜드마다 개별 구현 코드를 유지하는 방식의 한계에 봉착했다. 테넌트(리테일러)가 늘어날수록 코드베이스는 복잡해지고, 변경 사항 하나를 전파하기 위해 수십 개의 구현체를 수정해야 하는 유지보수 비용이 기하급수적으로 증가했다. 이를 해결하기 위해 도입한 것이 설정 기반(Configuration-Driven) 멀티테넌트 아키텍처다.
핵심 아이디어는 단순하다. 브랜드별 차이점을 코드가 아닌 설정(Configuration) 으로 표현하고, 실행 엔진은 모든 테넌트가 공유하는 단일 코드베이스로 유지하는 것이다. 새로운 리테일러를 온보딩하거나 캠페인 규칙을 변경할 때 코드 배포 없이 설정 변경만으로 처리할 수 있다. 이는 SaaS 플랫폼 설계에서 자주 언급되는 원칙이지만, 마케팅 캠페인처럼 테넌트별 개인화 요구가 복잡한 도메인에 실제로 적용했다는 점에서 주목할 만하다.
공유 실행 엔진의 설계 포인트
Instacart의 Storefront Pro 플랫폼은 Shared Execution Engine을 중심으로 설계됐다. 이 엔진은 캠페인 발송, 세그먼트 평가, 개인화 로직 등 공통 실행 흐름을 담당하고, 테넌트별 설정을 런타임에 로드하여 동작을 결정한다. 이렇게 하면 수백 개의 리테일 브랜드를 단일 플랫폼 위에서 운영하면서도 각 브랜드의 정체성과 마케팅 규칙을 독립적으로 유지할 수 있다.
설정 변경이 1분 이내로 전파된다는 점은 실무적으로 매우 중요한 지표다. 일반적인 코드 배포 파이프라인은 수십 분에서 수 시간이 소요되므로, 캠페인 운영 중 실시간 조정이 필요한 상황에서 설정 기반 접근이 명확한 우위를 가진다. Java 환경에서 유사한 구조를 구현할 때는 설정 스토어(예: 분산 캐시, 외부 설정 서버)와 실행 엔진 사이의 결합을 느슨하게 유지하는 것이 핵심이다.
// 테넌트 설정을 런타임에 로드하는 간단한 예시
public class CampaignEngine {
private final TenantConfigRepository configRepository;
public void execute(String tenantId, CampaignContext context) {
TenantConfig config = configRepository.findByTenantId(tenantId);
PersonalizationStrategy strategy = StrategyFactory.create(config);
strategy.apply(context);
}
}
이처럼 전략 패턴과 설정 기반 팩토리를 조합하면, 새로운 테넌트 규칙을 추가할 때 기존 엔진 코드를 건드리지 않고 확장할 수 있다.
99.9% 전달 성공률이 말해주는 것
멀티테넌트 구조에서 가장 위험한 지점은 한 테넌트의 장애가 다른 테넌트에 전파되는 것이다. Instacart가 99.9%의 메시지 전달 성공률을 달성했다는 것은 테넌트 간 격리(Isolation)가 잘 설계됐음을 의미한다. 공유 실행 엔진을 사용하더라도 테넌트별 설정 오류나 데이터 이상이 다른 테넌트의 캠페인에 영향을 주지 않도록 격리 경계를 명확히 해야 한다.
백엔드 설계 관점에서 이를 보장하려면 테넌트별 요청 컨텍스트를 스레드 로컬 또는 리액티브 컨텍스트로 엄격히 분리하고, 예외 처리 역시 테넌트 단위로 격리해야 한다. 또한 설정 캐시를 테넌트 단위로 관리함으로써 특정 테넌트의 설정 갱신이 전체 캐시를 무효화하지 않도록 설계하는 것도 중요하다.
정리
- 테넌트별 커스텀 코드 대신 설정 기반 공유 실행 엔진을 도입하면 온보딩 비용을 줄이고 유지보수 복잡도를 낮출 수 있다.
- 설정 변경의 빠른 전파(1분 이내) 는 코드 배포 없이 캠페인을 실시간 제어하는 핵심 경쟁력이다.
- 멀티테넌트 플랫폼에서 높은 가용성을 달성하려면 테넌트 간 격리를 실행 엔진, 예외 처리, 캐시 전략 각각에서 명확히 구현해야 한다.