Core 분리 및 Override Layer 설계를 통한 7개 테넌트 통합 관리 체계 구축

I've white-labeled the same CRM codebase 7 times for 7 different clients. I never touch the core. Here's how the override layer works.

Andrew Lee Jenkins2026년 5월 13일10분intermediate

AI 요약

Context

클라이언트별 커스텀 요구사항 대응을 위해 개별 Git Branch 및 Forked Repo를 사용하던 레거시 구조의 한계 직면. 각 리포지토리별로 버그 수정 사항을 반복적으로 Merge 해야 하는 운영 오버헤드와 유지보수 비용의 기하급수적 증가 발생.

Core App Code와 Override Layer를 완전히 분리하여 Core의 불변성(Immutability)을 유지하는 계층형 아키텍처 설계
.env 파일을 통한 Branding 정보 및 Feature Flag를 외부화하여 런타임에 테넌트별 설정을 주입하는 방식 채택
CSS Custom Properties와 Tailwind CSS를 결합하여 하드코딩 없는 동적 테마 시스템 구현
/public/brand/ 경로의 Asset Folder 구조화를 통한 정적 리소스의 테넌트별 매핑으로 코드 변경 없는 브랜드 교체 실현
비즈니스 로직과 브랜드 설정 간의 의존성을 제거하기 위해 brand.config.ts라는 단일 추상화 레이어 도입

실천 포인트

1. 클라이언트 전용 브랜치를 생성하기 전, 해당 요구사항이 Config/Asset/Feature Flag로 해결 가능한지 우선 검토

2. 테마 색상 변경 시 Tailwind 클래스를 직접 사용하지 말고 CSS Variable에 바인딩하여 런타임 주입 구조 설계

3. 하드코딩된 문자열이나 설정값을 brand.config.ts와 같은 중앙 집중형 설정 객체로 추상화

4. 정적 자산(Logo, Favicon)을 테넌트별 경로로 구조화하여 배포 시점에 파일 교체만으로 대응 가능하게 구성

태그