Salesforce DevOps CI/CD 구축 프로젝트의 대다수는 도구를 먼저 정하고 아키텍처를 나중에 맞춥니다. 이 순서가 뒤바뀌어 있다는 것이 문제의 본질입니다. Flosum이든 Gearset이든 Copado든, 도구는 파이프라인 설계가 이미 견고할 때만 효과를 냅니다. 조직이 3개 이상의 Salesforce 오그와 Data Cloud, MuleSoft 통합 계층을 함께 운영하는 시점부터는 CI/CD가 단순한 배포 자동화가 아니라 멀티클라우드 아키텍처의 일부로 다뤄져야 합니다.
Salesforce DevOps CI/CD 구축이 단일 오그 프로젝트와 다른 이유
단일 오그, 단일 팀 환경에서는 CI/CD가 비교적 단순합니다. Sandbox 하나, Git 저장소 하나, 배포 파이프라인 하나로 충분합니다. 하지만 리테일 접점 3,000개 이상 규모의 조직이나 사업부 15개를 아우르는 조직에서는 상황이 완전히 달라집니다. Sales Cloud, Service Cloud, Data Cloud, 그리고 Agentforce 에이전트가 서로 다른 릴리스 주기로 움직이면서, 하나의 메타데이터 변경이 다른 클라우드의 통합 로직을 깨뜨리는 일이 흔하게 발생합니다.
이 규모에서 CI/CD가 실패하는 패턴은 거의 동일합니다. 첫째, 여러 SI 벤더가 각자의 브랜치 전략으로 작업하면서 병합 시점에 충돌이 누적됩니다. 둘째, Flow와 Apex 트리거가 여러 팀에 걸쳐 수정되면서 의존성 그래프가 아무도 파악하지 못하는 상태로 커집니다. 셋째, 파이프라인은 존재하지만 품질 게이트가 형식적이어서 배포 후 장애가 프로덕션에서 처음 발견됩니다. 이런 구조는 결국 org 진단 및 고도화 프로젝트로 이어지는 전형적인 경로이며, 이 흐름은 이전 글 Salesforce 거버넌스와 SI 의존성에서 다룬 문제와 정확히 맞닿아 있습니다.
파이프라인 아키텍처: 트렁크 기반 개발이 정답인 이유
Salesforce DevOps CI/CD 구축에서 가장 먼저 결정해야 할 것은 브랜치 전략입니다. 결론부터 말하면, 멀티오그 환경에서는 장기 존속 피처 브랜치 방식보다 트렁크 기반 개발이 명확히 우위에 있습니다. 이유는 단순합니다. 피처 브랜치가 2주 이상 유지되면 메타데이터 충돌 해결 비용이 지수적으로 증가하기 때문입니다.
실전에서 작동하는 구조는 다음과 같습니다.
main (프로덕션 미러)
├─ integration (통합 테스트)
│ ├─ feature/agentforce-topic-update
│ ├─ feature/data-cloud-stream-config
│ └─ feature/flow-refactor
└─ release/2026-Q3각 피처 브랜치의 수명은 3일을 넘기지 않도록 강제합니다. 이를 위해서는 Scratch Org 기반 개발 환경이 필수입니다. Sandbox만으로 파이프라인을 구성하는 조직은 환경 프로비저닝 자체가 병목이 되어, 결국 피처 브랜치 수명이 늘어나는 악순환에 빠집니다. Scratch Org는 매번 정의 파일(sfdx-project.json)에서 깨끗하게 생성되므로, 개발자마다 격리된 상태에서 작업하고 병합 직전에만 통합 오그에서 충돌을 확인하는 구조가 가능해집니다.
품질 게이트는 최소 세 단계로 구성해야 합니다. 정적 분석(PMD, ESLint), Apex 테스트 커버리지 검증(단순 75% 수치가 아니라 변경된 클래스에 대한 실질 커버리지), 그리고 Agentforce Testing Center를 통한 에이전트 회귀 테스트입니다. Agentforce가 Topics와 Actions를 통해 비즈니스 로직을 담당하는 조직이 늘어나면서, 전통적인 Apex 테스트만으로는 배포 리스크를 잡아낼 수 없습니다. Instructions 변경이 Atlas Reasoning Engine의 응답 패턴을 바꾸는 경우가 실제로 자주 발생하기 때문입니다.
멀티클라우드 환경에서의 배포 순서 설계
Data Cloud와 Sales Cloud, Service Cloud가 얽힌 환경에서 Salesforce DevOps CI/CD 구축의 난이도를 결정하는 요소는 배포 순서입니다. Data Streams 설정, DMO 스키마 변경, Identity Resolution ruleset이 Apex 코드보다 먼저 배포되지 않으면, 애플리케이션 레이어가 존재하지 않는 필드를 참조하면서 배포 자체가 실패합니다.
일반적인 엔터프라이즈 배포 순서는 다음과 같은 계층 구조를 따라야 합니다.
- Data Cloud 메타데이터 (Data Streams, DMO, Data Graphs)
- 공유 Apex 라이브러리 및 Platform Events 정의
- Flow 및 비즈니스 로직
- Agentforce Topics, Actions, Instructions
- UI 레이어 (Lightning 컴포넌트, 페이지 레이아웃)
이 순서를 파이프라인 코드가 아니라 사람이 매번 수동으로 판단하게 두는 조직이 대부분이며, 이것이 배포 실패의 가장 흔한 원인입니다. CI/CD 파이프라인은 이 계층 구조를 YAML 설정 파일에 명시적으로 고정해야 하고, 배포 오케스트레이션 도구가 이를 강제해야 합니다. 이 부분에서 MuleSoft를 통한 외부 시스템 통합이 얽혀 있다면, External Services 정의 배포는 반드시 Data Cloud 계층과 함께 묶여야 합니다. 별도 릴리스 트랙으로 분리하는 순간 통합 계약(contract) 불일치가 프로덕션에서만 드러나는 사고가 반복됩니다.
멀티클라우드 통합의 복잡성에 대해서는 이전 글 Salesforce 멀티클라우드 통합 아키텍처에서 더 깊이 다뤘습니다. CI/CD 파이프라인은 결국 이 통합 아키텍처를 코드로 표현하는 작업이라고 이해하는 것이 정확합니다.
함정: 대부분의 조직이 파이프라인 설계에서 놓치는 지점
가장 흔한 함정은 CI/CD 도구 도입을 곧 “DevOps 성숙도”로 착각하는 것입니다. 도구가 있다고 해서 배포 리스크가 사라지지 않습니다. 실제로 파이프라인이 있는 상태에서 발생하는 장애가, 파이프라인이 아예 없는 상태보다 더 위험할 때가 있습니다. 자동화된 배포가 잘못된 순서나 검증되지 않은 코드를 프로덕션까지 빠르게, 그리고 조용히 실어 나르기 때문입니다.
두 번째 함정은 SI 벤더 교체 시점에 파이프라인 소유권이 불명확해지는 것입니다. 벤더가 바뀔 때마다 브랜치 전략, 네이밍 규칙, 승인 절차가 조금씩 달라지면서, 3~4년이 지나면 파이프라인이 누구도 전체 그림을 이해하지 못하는 블랙박스가 됩니다. 이는 앞서 언급한 거버넌스 문제와 동일한 뿌리를 갖습니다. 파이프라인 설정 자체를 조직의 자산으로 문서화하고, 벤더 교체와 무관하게 유지되는 소유권 체계를 별도로 정의해야 합니다.
세 번째 함정은 테스트 커버리지를 배포 게이트가 아니라 사후 보고 지표로 취급하는 것입니다. 커버리지 75%를 채웠다고 안전한 것이 아니라, 변경된 로직 경로가 실제로 검증되었는지가 중요합니다. 특히 Agentforce 도입 이후에는 Prompt Builder 템플릿 변경, Topic 범위 조정이 전통적인 코드 커버리지 지표에 전혀 잡히지 않는다는 점을 인지해야 합니다. Agentforce Testing Center의 회귀 테스트 시나리오를 CI/CD 게이트에 통합하지 않은 조직은, 에이전트 응답 품질이 배포마다 조금씩 저하되는 것을 몇 달 뒤에야 발견하게 됩니다.
네 번째는 릴리스 주기를 클라우드별로 다르게 가져가면서 발생하는 조율 부담입니다. Data Cloud 팀은 주간 배포, Sales Cloud 팀은 격주 배포, Agentforce 팀은 스프린트마다 배포하는 식으로 각자 움직이면, 결국 통합 테스트 환경에서 세 가지 버전이 동시에 충돌하는 상황이 반복됩니다. 릴리스 주기를 통일하거나, 최소한 통합 테스트 오그의 스냅샷 주기를 모든 클라우드 팀이 공유하도록 강제해야 합니다.
향후 12개월 내에 Agentforce 배포 빈도가 늘어날 조직이라면, 지금 CI/CD 파이프라인에 에이전트 회귀 테스트 게이트를 넣지 않은 결정이 내년 이맘때 가장 후회할 결정이 될 가능성이 높습니다. 파이프라인은 한번 굳어지면 되돌리기 어려운 관성을 갖기 때문에, 지금 설계하는 배포 순서와 품질 게이트가 향후 2~3년의 릴리스 안정성을 사실상 결정합니다.
CI/CD 구축을 org 전체 아키텍처 진단과 분리해서 진행하는 조직도 많은데, 이는 순서가 잘못된 접근입니다. 파이프라인을 새로 짜기 전에 현재 오그의 메타데이터 의존성 그래프와 기술 부채 수준을 먼저 파악해야, 어떤 배포 순서와 게이트가 실제로 필요한지 판단할 수 있습니다. 이 진단 작업 없이 파이프라인부터 구축하면, 몇 달 뒤 근본 구조를 다시 뜯어고쳐야 하는 상황이 발생합니다. 이런 이유로 CI/CD 구축은 org 진단 및 고도화 작업과 함께 설계되어야 실질적인 효과를 냅니다.
핵심 정리
- Salesforce DevOps CI/CD 구축은 도구 선택 문제가 아니라 멀티클라우드 아키텍처 설계 문제이며, 3개 이상 오그 환경에서는 배포 순서 고정이 도구 선정보다 우선한다.
- 피처 브랜치 수명은 3일 이내로 제한하고 Scratch Org 기반 개발 환경으로 전환해야 트렁크 기반 개발이 실제로 작동한다.
- 배포 순서는 Data Cloud 메타데이터, 공유 Apex, Flow, Agentforce 구성 요소, UI 레이어 순으로 고정해야 하며 이 순서를 사람이 아닌 파이프라인 설정이 강제해야 한다.
- Agentforce Testing Center를 CI/CD 품질 게이트에 통합하지 않으면 Topic과 Instructions 변경으로 인한 에이전트 응답 품질 저하를 배포 이후 몇 달이 지나서야 발견하게 된다.
- SI 벤더 교체 시점마다 파이프라인 소유권과 네이밍 규칙이 흔들리는 조직은 3~4년 내 파이프라인 자체가 블랙박스가 되며, 이는 org 진단으로 되돌아가야 해결되는 문제다.
