- 제1부 엔터프라이즈 CRM의 진화와 4계층 참조 모델
1. 서론
엔터프라이즈 고객 관계 관리(CRM) 플랫폼은 단순한 연락처 데이터베이스에서 포춘 500 기업의 운영 백본으로 진화했다. 그러나 다중 테넌트 CRM 환경에 특화된 아키텍처 및 디자인 패턴에 대한 통합 참조 프레임워크가 부족하다. 본 논문은 17년 간의 금융, 통신, 헬스케어, 에너지, 소비재 분야 엔터프라이즈 CRM 구현 분석을 기반으로 14개 아키텍처 및 디자인 패턴을 제시한다. 이 패턴들은 데이터 아키텍처, 비즈니스 로직, 통합, 프레젠테이션의 4개 레이어로 구성되며, 거버너 인식 패턴, 다중 테넌트 격리 패턴, 플랫폼 진화 패턴의 3개 카테고리로 분류된다. 또한 AI의 3세대(예측, 생성, 에이전틱)가 CRM 아키텍처를 어떻게 변화시키는지 분석하며, AI 코딩 에이전트가 CRM 플랫폼을 대체할 가능성을 논의한다.
본 원고는 엔터프라이즈 CRM 아키텍처의 현재와 미래를 총 3부로 기술한다. 제1부에서는 멀티테넌트 CRM 환경의 기초와 4계층 참조 모델을 다루고, 제2부에서는 AI 변환이 CRM 아키텍처에 미치는 영향을 분석하며, 제3부에서는 AI 코딩 에이전트 시대의 빌드 vs 구매 전략과 미래 전망을 제시한다.
2. CRM의 진화: 지능형 플랫폼으로 진화
지난 20년간 고객관계관리(CRM) 시스템은 극적인 변화를 겪었다. 2000년대 초반, CRM은 단순한 온프레미스 연락처 데이터베이스에 불과했다. 영업 담당자가 고객 정보를 기록하고, 영업 기회를 추적하며, 기본적인 보고서를 생성하는 도구였다. 오늘날 CRM은 영업, 서비스, 마케팅, 커머스, 그리고 최근에는 자율 AI 에이전트까지 운영하는 클라우드 네이티브, 멀티테넌트 플랫폼으로 진화했다.
Salesforce는 18년 연속 Gartner의 Magic Quadrant for Sales Force Automation에서 리더 위치를 유지하며 플랫폼의 아키텍처 성숙도와 시장 지배력을 입증했다. 2024년 글로벌 CRM 시장 규모는 1,280억 달러에 달하며, 연간 13.4%의 성장률을 보이고 있다. Forrester의 2025 CRM Wave는 시장을 변화의 정점에 있다고 평가하며, 이러한 변화의 중심에는 예측형, 생성형, 그리고 에이전틱 AI의 융합이 있다고 지적한다.
하지만 CRM 플랫폼이 이처럼 급속도로 발전하는 동안, 소프트웨어 엔지니어링 학계와 실무 문헌은 이 독특한 아키텍처 환경이 제시하는 도전과제를 제대로 다루지 못했다. Gang of Four의 고전적인 디자인 패턴 카탈로그부터 Martin Fowler의 엔터프라이즈 애플리케이션 패턴, Hohpe와 Woolf의 통합 패턴에 이르기까지, 기존 문헌은 모두 단일 테넌트, 자체 호스팅 환경을 전제로 작성되었다. 이러한 환경에서 개발자는 인프라, 데이터베이스 스키마, 실행 런타임을 완전히 제어할 수 있었다.
멀티테넌트 SaaS CRM 플랫폼은 이러한 기본 가정을 근본적으로 바꾼다. 공유 인프라에서 수천 개의 조직이 동일한 애플리케이션 인스턴스를 사용하며, 플랫폼은 공정한 리소스 분배를 위해 엄격한 실행 제한을 강제한다. 데이터베이스 스키마는 메타데이터 기반 모델로 추상화되며, 실행 순서는 플랫폼이 제어한다. 이러한 제약 속에서 고전적인 디자인 패턴을 순진하게 적용하면 안티패턴이 발생하고, 프로덕션 환경에서 치명적인 실패로 이어질 수 있다.
3. 엔터프라이즈 CRM 아키텍처 4계층 참조 모델
지난 개별 패턴을 제시하기 전에, CRM 플랫폼 기능을 일관된 아키텍처 관심사로 조직화하는 4계층 참조 모델을 확립할 필요가 있다. 이 모델은 Salesforce Well-Architected Framework, Martin Fowler의 엔터프라이즈 애플리케이션 아키텍처 계층 등의 참조한 것으로 플랫폼 관리형 거버너 계층을 포함하는 4계층 엔터프라이즈 CRM 아키텍처는 그림 1과 같다.
그림 1. 플랫폼 관리형 거버너 계층을 포함하는 4계층 엔터프라이즈 CRM 아키텍처 참조 모델 (출처: Salesforce Well-Architected Framework & Fowler's enterprise application architecture layers)
3.1 데이터 아키텍처 계층
데이터 아키텍처 계층은 메타데이터 기반 객체 모델, 관계, 데이터 저장 메커니즘을 포괄한다. 멀티테넌트 CRM 플랫폼에서 이 계층은 Universal Data Dictionary(UDD) 아키텍처에서 작동한다. UDD는 모든 테넌트 데이터가 물리적 데이터베이스 인프라를 공유하지만 해시 파티션된 조직 식별자(OrgID)를 통해 논리적으로 격리되는 다형성 데이터베이스 스키마다.
2009년 ACM SIGMOD에서 Weissman과 Bobrowski가 발표한 Force.com 플랫폼 아키텍처는 이러한 접근 방식의 선구적 사례다. 플랫폼은 flex columns를 사용하여 각 테넌트의 커스텀 필드를 저장하고, OrgID 기반 해시 파티셔닝으로 물리적 데이터베이스 분리 없이도 데이터 분리를 달성한다.
이 계층의 핵심 관심사는 다음과 같다.
• 데이터 모델 설계: 엔터티, 관계, 필드를 어떻게 구조화할 것인가?
• 인덱싱 전략: 쿼리 성능을 최적화하기 위한 인덱스를 어떻게 설계할 것인가?
• 스토리지 메커니즘 선택: 표준 객체, 커스텀 객체, 외부 객체, 빅 객체, 또는 Data Cloud 데이터셋 중 무엇을 사용할 것인가? 이 선택은 데이터 볼륨, 액세스 패턴, 지연 시간 요구사항에 따라 결정된다.
3.2 비즈니스 로직 계층
비즈니스 로직 계층은 실행 가능한 비즈니스 규칙, 자동화, 오케스트레이션 로직을 포함한다. 멀티테넌트 CRM 플랫폼에서 이 계층은 거버너 제한에 의해 경계가 정해진다. 거버너 제한은 트랜잭션당 SOQL 쿼리, DML 작업, CPU 시간, 힙 메모리를 제약한다.
Salesforce 플랫폼을 예로 들면, 동기 컨텍스트에서는 트랜잭션당 100개의 SOQL 쿼리, 150개의 DML 문, 10,000밀리초의 CPU 시간, 6MB의 힙 메모리가 제한된다. 비동기 컨텍스트는 더 높은 제한을 갖지만(200 SOQL, 60,000ms CPU, 12MB 힙), 여전히 제한은 존재한다.
이 계층의 중요한 아키텍처 결정은 선언적 자동화와 프로그래밍 방식 자동화 간의 로직 할당이다. Salesforce Well-Architected Framework는 “클릭 우선, 코드 차선”철학을 규정한다. 표준 비즈니스 로직에는 선언적 도구(Flow, Process Builder, Validation Rules)를 권장하고, 복잡한 데이터 조작, 외부 호출, 선언적 기능을 넘어서는 트랜잭션 제어가 필요한 시나리오에만 Apex를 예약한다.
3.3 통합 계층
통합 계층은 CRM 플랫폼과 외부 시스템 간의 데이터 교환을 관리한다. Gregor Hohpe와 Bobby Woolf의 고전적인 ‘Enterprise Integration Patterns’는 이 계층의 표준 어휘를 제공한다. 그러나 CRM 특화 적응이 필요하다.
현대 CRM 플랫폼의 주요 통합 메커니즘은 다음과 같다.
• Platform Events: Publish-Subscribe 패턴을 구현한다. 게시자는 구독자를 알 필요 없이 이벤트를 발행하고, 구독자는 비동기적으로 이벤트를 소비한다.
• Change Data Capture: Event-Carried State Transfer 패턴을 구현한다. CRM 객체의 변경사항이 자동으로 이벤트로 발행되어, 외부 시스템이 CRM 데이터의 복제본을 유지할 수 있다.
• REST/SOAP API: Request-Reply 패턴을 구현한다. 외부 시스템이 CRM 데이터를 동기적으로 읽고 쓸 수 있다.
• 미들웨어 오케스트레이션: MuleSoft, Boomi, Informatica 같은 플랫폼이 복잡한 통합 흐름을 관리한다.
3.4 프레젠테이션 계층
프레젠테이션 계층은 사용자 인터페이스, 포털, 외부 소비자에게 노출되는 API 표면을 포괄한다. 현대 CRM 플랫폼은 다양한 프레젠테이션 패러다임을 지원한다.
• 컴포넌트 기반 UI 프레임워크: Lightning Web Components는 재사용 가능한 UI 컴포넌트를 구축하는 현대적 웹 표준 기반 프레임워크다.
• 포털 경험: Experience Cloud는 고객, 파트너, 직원을 위한 브랜드 포털을 제공한다.
• 모바일 애플리케이션: 네이티브 모바일 앱과 모바일 웹 경험을 모두 지원한다.
• 헤드리스 API 소비: 외부 프론트엔드가 CRM을 백엔드 API로만 사용하는 패턴이다.
3.5 거버너 및 런타임 계층
멀티테넌트 CRM 플랫폼에 고유한 것으로, 거버너 및 런타임 계층은 개발자가 제어하는 것이 아니라 플랫폼이 관리한다. 이 계층은 트랜잭션당 및 조직당 리소스 제한을 강제한다.
Salesforce 플랫폼의 주요 거버너 제한은 다음과 같다.
• SOQL 쿼리 제한: 동기 100개, 비동기 200개
• DML 문 제한: 트랜잭션당 150개
• CPU 시간 제한: 동기 10,000ms, 비동기 60,000ms
• 힙 크기 제한: 동기 6MB, 비동기 12MB
이 계층을 이해하는 것은 위의 모든 계층에서 패턴 결정을 내리기 위한 전제 조건이다. 거버너 제한은 우회할 수 있는 버그가 아니라, 멀티테넌트 환경에서 공정한 리소스 분배를 보장하는 의도적인 아키텍처 가드레일이다.
4. 거버너 인식 패턴: 멀티테넌트 환경의 핵심
거버너 인식 패턴은 플랫폼이 강제하는 실행 제한 내에서 리소스 소비를 최적화한다. 이 패턴들은 고전적인 디자인 패턴 문헌에 직접적인 동등물이 없다. 왜냐하면 단일 테넌트 환경에는 존재하지 않는 제약에 대응하기 때문이다. 중요한 것은, 고전적 패턴과 달리 거버너 인식 패턴의 채택은 선택이 아니라 필수라는 점이다. 이 패턴들을 적용하지 않으면 품질 저하가 아니라 런타임 실패가 발생한다.
4.1 패턴 1: 벌크화(Bulkification)
비즈니스 로직은 가변 배치 크기로 도착하는 레코드를 처리해야 한다. UI 상호작용을 통한 단일 레코드부터 API 벌크 작업이나 데이터 로드를 통한 200개 레코드까지 다양하다.
문제: 한 번에 단일 레코드를 처리하도록 작성된 코드는 배치를 처리할 때 거버너 제한을 초과하여 프로덕션에서 런타임 오류를 일으킨다.
작용하는 힘:
• 플랫폼 거버너 제한은 레코드당이 아니라 트랜잭션당이다.
• API와 벌크 작업은 트리거 호출당 최대 200개의 레코드를 전달한다.
• 개발자는 자연스럽게 단일 레코드 로직으로 사고한다.
솔루션: 모든 데이터 액세스 및 조작 로직을 개별 레코드가 아닌 컬렉션(리스트, 세트, 맵)에서 작동하도록 설계한다. 모든 SOQL 쿼리와 DML 작업을 루프 밖으로 이동한다. 반복적인 쿼리를 대체하기 위해 맵 기반 조회를 사용한다.
결과:
• (+) 벌크 데이터 작업 시 거버너 제한 예외를 제거한다.
• (+) 배치 크기(1~200 레코드)에 관계없이 일관된 성능을 제공한다.
• (-) 코드 복잡도가 증가한다; 개발자는 컬렉션 관점에서 사고해야 한다.
• (-) 반복적인 단일 레코드 로직에 비해 더 많은 사전 설계가 필요하다.
4.2 패턴 2: 큐어블 체인(Queueable Chain)
비즈니스 프로세스가 단일 동기 트랜잭션이 허용하는 것보다 더 많은 계산을 필요로 하지만(10,000ms CPU 시간, 100 SOQL 쿼리) 조정된 시퀀스로 완료되어야 한다.
문제: 단일 트랜잭션 거버너 제한을 초과하는 장기 실행 프로세스는 실행 중간에 실패하여 데이터를 일관성 없는 상태로 남긴다.
작용하는 힘:
• 동기 트랜잭션은 엄격한 CPU 및 쿼리 제한이 있다.
• 비동기 컨텍스트(Queueable, Batch)는 더 높은 제한을 갖지만 무제한 깊이로 직접 체인할 수 없다.
• 비즈니스 프로세스는 단계의 순차적 순서를 요구한다.
• 오류 처리는 실패 지점에서 재개를 허용해야 한다.
솔루션: 프로세스를 별개의 작업 단위로 분해하고, 각각을 Queueable Apex 클래스로 구현한다. 각 단위는 성공적으로 완료되면 체인의 다음 단위를 큐에 넣는다. 상태는 직렬화된 매개변수나 커스텀 오케스트레이션 객체를 통해 단위 간에 전달된다.
결과:
• (+) 단일 트랜잭션 제한을 초과하는 프로세스를 가능하게 한다.
• (+) 오류 복구를 위한 자연스러운 체크포인트를 제공한다.
• (+) 각 단계는 새로운 제한으로 자체 거버너 컨텍스트에서 실행된다.
• (-) 비동기 복잡성을 도입한다; 동기 코드보다 디버그하기 어렵다.
• (-) 체인 깊이에 대한 플랫폼 제한이 있다.
• (-) 모니터링 및 재시도를 위한 오케스트레이션 인프라가 필요하다.
5. 결론
1부에서는 멀티테넌트 CRM 환경의 기초와 4계층 참조 모델, 그리고 거버너 인식 패턴의 핵심인 벌크화와 큐어블 체인을 다루었다. 다음 제2부에서는 나머지 거버너 인식 패턴과 멀티테넌트 격리 패턴, 플랫폼 진화 패턴을 살펴보고, AI가 이러한 아키텍처에 어떤 변화를 가져오는지 분석한다.
—
참고문헌
1. Salesforce. Architecture Basics. Salesforce Architects, 2025. Available online: https://architect.salesforce.com/fundamentals/architecture-basics
2. Salesforce. Salesforce Well-Architected Framework. Salesforce Architects, 2025. Available online: https://architect.salesforce.com/well-architected/overview.
3. Hohpe, G.; Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions; Addison-Wesley: Boston, MA, USA, 2004.
4. Fowler, M. Patterns of Enterprise Application Architecture; Addison-Wesley Professional: Boston, MA, USA, 2002.
—
저작권 정책
SaaS 전환지원센터의 저작물인 『AI 시대의 엔터프라이즈 CRM 아키텍처와 멀티테넌트 SaaS의 미래』은 SaaS 전환지원센터에서 『상명대학교 서광규 교수』에게 집필 자문을 받아 발행한 전문정보 브리프로, SaaS 전환지원센터의 저작권정책에 따라 이용할 수 있습니다. 다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.