techNInfo

데이터 관리는 세일즈포스 관리자에게 가장 일상적이면서도 동시에 가장 긴장되는 작업입니다. 수천, 수만 건의 레코드를 한 번에 처리하다 보면 단 한 번의 클릭 실수로 데이터가 꼬이거나 중복값이 넘쳐나는 대참사가 발생할 수 있기 때문입니다. 특히 신규 프로젝트를 시작하거나 외부 시스템의 데이터를 이관할 때, “어떤 도구를 써야 가장 안전하고 빠를까?”라는 고민은 필연적입니다. 오늘은 제가 실무에서 데이터를 다루며 체득한 경험을 바탕으로, 상황에 맞는 최적의 도구 선택법과 대용량 업로드 시 반드시 챙겨야 할 체크리스트를 정리해 보겠습니다.

한눈에 비교하는 데이터 도구: 어떤 상황에 무엇을 쓸까?

도구 선택의 첫걸음은 각 도구가 가진 한계와 강점을 명확히 비교하는 것입니다. 아래 표는 제가 실무에서 의사결정을 내릴 때 기준으로 삼는 주요 차이점들입니다.

비교 항목	Data Import Wizard (가져오기 마법사)	Data Loader (데이터 로더)
적재 한도	최대 50,000건	최대 5,000,000건
설치 여부	불필요 (브라우저 기반)	필요 (데스크톱 설치형)
지원 오브젝트	일부 표준 오브젝트 및 커스텀 오브젝트	모든 표준 및 커스텀 오브젝트
중복 방지	내장된 필드 매칭 기능으로 중복 제거 가능	기능 없음 (사전 정제 필수)
데이터 삭제	지원하지 않음	지원함 (Delete, Hard Delete)
자동화 지원	지원하지 않음 (수동 작업)	명령줄(CLI) 인터페이스로 스케줄링 가능
워크플로우 제어	업로드 시 자동화 로직 실행 여부 선택 가능	기본적으로 모든 로직 실행 (Bulk API 시 선택적)

도구 선택의 갈림길: 임포트 위저드와 데이터 로더의 메커니즘 차이

위의 표에서 보듯 두 도구는 언뜻 비슷해 보이지만, 그 내부 메커니즘과 목적은 확연히 다릅니다.

먼저 Data Import Wizard는 별도의 설치 없이 브라우저에서 바로 실행할 수 있는 ‘경량급’ 도구입니다. 이 도구의 가장 큰 매력은 ‘안전장치’에 있습니다. 계정이나 연락처를 올릴 때 이름이나 이메일을 기준으로 중복을 자동으로 걸러주는 기능이 내장되어 있어, 데이터 정제가 완벽하지 않은 상태에서도 비교적 안심하고 사용할 수 있습니다. 다만, 지원하는 오브젝트가 제한적이라는 점이 아쉬운 부분입니다.

반면 Data Loader는 대량의 데이터를 다루는 ‘중량급’ 전문가용 도구입니다. 모든 오브젝트를 지원할 뿐만 아니라, 데이터를 넣는 것(Insert) 외에도 수정(Update), 삭제(Delete), 내보내기(Export) 등 전천후 기능을 제공합니다. 수백만 건의 데이터를 처리할 수 있는 강력한 성능을 자랑하지만, 중복 체크 기능이 없으므로 사용자가 사전에 데이터를 완벽하게 가공해야 한다는 책임이 따릅니다.

실패 없는 데이터 업로드를 위한 실무 최적화 전략

단순히 도구를 선택하는 것보다 중요한 것은 업로드 과정에서 시스템의 안정성을 유지하는 것입니다. 대용량 데이터를 다룰 때 제가 항상 지키는 몇 가지 철칙이 있습니다.

1. 성능 극대화를 위한 Bulk API 활용

데이터 로더를 사용할 때 일반 API 대신 Bulk API를 선택하면 처리에 소요되는 시간을 획기적으로 줄일 수 있습니다. 이는 데이터를 배치(Batch) 단위로 쪼개어 병렬로 처리하기 때문인데, 10만 건 이상의 데이터를 다룰 때는 선택이 아닌 필수입니다.

2. 가상 키(External ID)의 마법

업로드할 데이터에 기존 시스템의 고유 번호(Legacy ID)가 있다면, 이를 세일즈포스 필드 중 ‘External ID’로 설정하세요. 이렇게 하면 세일즈포스 ID를 몰라도 기존 시스템 ID를 기준으로 데이터를 매핑하거나 업데이트(Upsert)할 수 있어 데이터 관리의 유연성이 엄청나게 높아집니다.

3. 일시적인 시스템 ‘멈춤’ 단추 활용

대규모 적재 시에는 해당 오브젝트에 걸려 있는 트리거(Trigger)나 플로우(Flow), 그리고 밸리데이션 규칙을 잠시 비활성화하는 것을 고려해야 합니다. 로직이 작동하면서 발생하는 부하 때문에 업로드 속도가 느려지거나, 예상치 못한 오류로 전체 작업이 중단될 수 있기 때문입니다. 작업 완료 후 다시 켜는 것을 잊지 마세요.

마치며: 도구보다 중요한 것은 데이터에 대한 이해

결국 어떤 도구를 쓰느냐보다 중요한 것은 내가 다루는 데이터의 성격과 양을 정확히 파악하는 것입니다. 5만 건 미만의 간단한 데이터 입력이나 중복 체크가 필수적인 경우에는 ‘Data Import Wizard’가 효율적입니다. 하지만 정기적인 데이터 이관이나 대규모 이력 데이터 적재가 목적이라면 ‘Data Loader’의 강력한 기능을 활용해야 합니다. 오늘 정리한 가이드와 비교표가 여러분의 데이터 관리 업무에 실질적인 도움이 되기를 바라며, 작업 전 ‘백업’은 아무리 강조해도 지나치지 않다는 점을 다시 한번 상기시켜 드립니다.

---

자주 묻는 질문 (FAQ)

Q1. 데이터 로더로 업로드할 때 시간이 너무 오래 걸리는데 해결 방법이 있나요?

가장 먼저 데이터 로더 설정에서 Bulk API 모드가 활성화되어 있는지 확인해 보세요. 또한 배치 사이즈(Batch Size)를 기본값인 200에서 상황에 맞게 조정(최대 10,000)하면 속도를 높일 수 있습니다. 다만, 복잡한 로직이 실행되는 오브젝트라면 배치 사이즈가 너무 클 때 오히려 오류가 날 수 있으니 적절한 값을 찾아가는 과정이 필요합니다.

Q2. 임포트 위저드에서 ‘중복 체크’는 어떤 원리로 작동하나요?

임포트 위저드는 업로드 설정 단계에서 매칭 기준을 선택할 수 있게 해줍니다. 예를 들어 연락처(Contact)의 경우 ‘이메일’을 기준으로 설정하면, CSV 파일 내의 이메일 주소가 이미 세일즈포스에 존재하는 경우 새 레코드를 만들지 않고 기존 레코드를 업데이트하거나 무시하도록 선택할 수 있어 중복 발생을 원천 차단합니다.

Q3. 실수로 잘못된 데이터를 대량으로 올렸을 때 가장 빠르게 삭제하는 방법은?

데이터 로더의 Delete 기능을 활용하는 것이 가장 빠릅니다. 업로드 직후 생성된 성공 로그 파일(Success Log)에는 방금 생성된 레코드들의 세일즈포스 ID가 포함되어 있습니다. 이 로그 파일을 그대로 데이터 로더의 Delete 작업에 소스로 사용하면, 방금 올린 레코드들만 골라 깔끔하게 삭제할 수 있습니다.

복잡해지는 비즈니스 로직과 트리거 관리의 중요성

세일즈포스 개발 환경에서 Apex 트리거는 데이터 변경에 따라 실시간으로 비즈니스 로직을 실행하는 가장 강력한 도구 중 하나입니다. 하지만 프로젝트의 규모가 커지고 요구사항이 복잡해질수록 트리거 내부에 직접 작성한 코드는 유지보수를 어렵게 만드는 주범이 됩니다. 특히 하나의 오브젝트에 여러 개의 트리거가 생성되거나, 수백 줄의 로직이 트리거 문체(Body) 안에 뒤섞여 있는 경우 코드의 실행 순서를 보장할 수 없고 디버깅은 불가능에 가까워집니다.

스파게티 코드와 실행 순서 제어의 불확실성

많은 초보 개발자나 관리자가 실수하는 부분은 트리거 내부에 모든 비즈니스 로직을 기술하는 것입니다. 이러한 방식은 크게 세 가지 치명적인 문제를 야기합니다.

첫째, 실행 순서의 혼란입니다. 세일즈포스는 동일한 오브젝트에 여러 개의 트리거가 존재할 경우 어떤 트리거가 먼저 실행될지 보장하지 않습니다. 이는 데이터 무결성을 해칠 수 있는 위험 요소입니다.

둘째, 테스트 코드 작성의 어려움입니다. 트리거 내부에 로직이 박혀 있으면 특정 비즈니스 로직만 분리하여 단위 테스트(Unit Test)를 수행하기가 매우 까다롭습니다.

셋째, 가독성 저하와 코드 중복입니다. 비슷한 로직을 여러 이벤트(Before Insert, After Update 등)에서 공유해야 할 때, 트리거 내부에 코드를 짜면 중복 코드가 발생하게 됩니다. 이러한 문제는 결국 세일즈포스의 거버너 리밋(Governor Limits) 초과로 이어져 전체 시스템의 성능을 저하시킵니다.

Trigger Handler 패턴을 활용한 로직 분리와 체계화

이러한 문제를 해결하기 위한 업계 표준은 Trigger Handler 패턴을 도입하는 것입니다. 이 패턴의 핵심은 트리거 자체는 오직 ‘이벤트를 감지하고 핸들러를 호출하는 역할’만 수행하게 하고, 실제 모든 비즈니스 로직은 별도의 Apex 클래스(Handler)에서 관리하는 것입니다.

1. 단일 트리거 원칙 (One Trigger Per Object)

가장 먼저 지켜야 할 원칙은 한 오브젝트당 단 하나의 트리거만 생성하는 것입니다. 이를 통해 실행 순서를 명확하게 제어할 수 있습니다.

2. Handler 클래스 구조화

핸들러 클래스는 트리거 이벤트를 메서드로 분리하여 수용합니다. 예를 들어 beforeInsert, afterUpdate와 같은 메서드를 정의하여 로직을 배치합니다.

3. 실제 코드 구현 예시: Account 오브젝트 기준

먼저 트리거는 다음과 같이 단순하게 구성합니다.

Apex

trigger AccountTrigger on Account (before insert, before update, after insert, after update) {
    AccountHandler handler = new AccountHandler();
    
    if (Trigger.isBefore) {
        if (Trigger.isInsert) {
            handler.onBeforeInsert(Trigger.new);
        } else if (Trigger.isUpdate) {
            handler.onBeforeUpdate(Trigger.oldMap, Trigger.newMap);
        }
    } else if (Trigger.isAfter) {
        if (Trigger.isInsert) {
            handler.onAfterInsert(Trigger.newMap);
        }
    }
}

그리고 실제 로직을 담은 핸들러 클래스를 작성합니다.

Apex

public with sharing class AccountHandler {
    
    // Before Insert 로직: 예를 들어 특정 필드 자동 채우기
    public void onBeforeInsert(List<Account> newList) {
        for (Account acc : newList) {
            if (acc.Industry == null) {
                acc.Industry = 'Other'; // 기본값 설정
            }
        }
    }
    
    // Before Update 로직: 변경 사항 검증
    public void onBeforeUpdate(Map<Id, Account> oldMap, Map<Id, Account> newMap) {
        for (Account acc : newMap.values()) {
            Account oldAcc = oldMap.get(acc.Id);
            if (acc.AccountNumber != oldAcc.AccountNumber) {
                // 계좌 번호 변경 시 로직 수행
            }
        }
    }
    
    // After Insert 로직: 관련 레코드 생성 (예: 기회 생성)
    public void onAfterInsert(Map<Id, Account> newMap) {
        List<Opportunity> oppsToInsert = new List<Opportunity>();
        for (Account acc : newMap.values()) {
            oppsToInsert.add(new Opportunity(
                Name = acc.Name + ' New Opp',
                StageName = 'Prospecting',
                CloseDate = System.today().addMonths(1),
                AccountId = acc.Id
            ));
        }
        if (!oppsToInsert.isEmpty()) {
            insert oppsToInsert;
        }
    }
}

이 구조를 사용하면 트리거는 매우 깨끗하게 유지되며, 모든 로직이 핸들러 클래스에 집중되어 있어 코드 재사용성이 극대화됩니다. 특정 기능이 문제를 일으킬 때 해당 메서드만 확인하면 되므로 유지보수 비용이 획기적으로 줄어듭니다.

결론: 지속 가능한 Salesforce 아키텍처를 위한 첫걸음

Trigger Handler 패턴은 단순한 코딩 스타일을 넘어 대규모 엔터프라이즈 환경에서 세일즈포스 인스턴스의 안정성을 보장하는 필수적인 아키텍처 전략입니다. 단일 트리거 원칙을 고수하고 로직을 핸들러로 분리함으로써, 개발자는 거버너 리밋을 더 효율적으로 관리할 수 있고 향후 비즈니스 로직이 확장되더라도 유연하게 대처할 수 있습니다. 지금 작성하고 있는 트리거가 너무 비대하다면, 지금 바로 핸들러 패턴으로 리팩토링하는 것을 권장합니다. 이는 기술 부채를 줄이고 팀 전체의 생산성을 높이는 가장 빠른 길입니다.

---

자주 묻는 질문 (FAQ)

Q1. 왜 한 오브젝트에 트리거를 하나만 만들어야 하나요?

세일즈포스 플랫폼은 동일한 오브젝트에서 여러 트리거가 실행될 때 그 순서를 제어하는 기능을 제공하지 않습니다. 두 개의 트리거가 서로 다른 필드를 업데이트하거나 연쇄 반응을 일으킬 경우 예상치 못한 데이터 오류가 발생할 수 있습니다. 단일 트리거 패턴을 사용하면 코드 내에서 if 문이나 핸들러 호출 순서를 통해 실행 로직의 선후 관계를 완벽하게 제어할 수 있습니다.

Q2. 트리거 핸들러 패턴이 거버너 리밋(Governor Limits) 해결에 도움이 되나요?

직접적인 해결책은 아니지만 리밋 관리를 훨씬 수월하게 해줍니다. 핸들러 패턴을 쓰면 코드가 구조화되므로, 중복되는 SOQL 쿼리나 DML 작업을 하나의 리스트로 모아서 처리(Bulkification)하기가 훨씬 용이해집니다. 로직이 파편화되어 있을 때 발생하는 ‘루프 내 쿼리 실행’ 같은 실수를 방지하는 데 큰 도움이 됩니다.

Q3. 인터페이스(Interface)를 활용한 핸들러 프레임워크를 꼭 써야 할까요?

프로젝트 규모에 따라 다릅니다. 소규모 프로젝트라면 위 예시처럼 단순한 핸들러 클래스만으로도 충분합니다. 하지만 대규모 팀 프로젝트나 복잡한 패키지 개발의 경우, ITriggerHandler 인터페이스를 정의하고 트리거 실행을 자동화하는 프레임워크를 도입하면 핸들러 작성 방식을 통일하고 공통 유틸리티(재귀 실행 방지 등)를 일괄 적용할 수 있어 더욱 강력한 제어가 가능합니다.

Salesforce 권한 모델의 본질과 실무 관점에서 꼭 알아야 할 것들

도입

Salesforce를 운영하다 보면 반드시 마주하게 되는 것이 사용자 권한 관리다. 모든 사용자는 시스템 내에서 어떤 데이터를 보고 어떤 기능을 사용할 수 있는지를 명확히 결정해야 하기 때문이다. 많은 관리자는 처음에 Profile만 가지고 권한을 구현하려 하지만, 실제로는 **Permission Set(퍼미션 세트)**이 훨씬 더 유연하고 효과적인 권한 확장 수단임을 깨닫게 된다. 이 글은 왜 Permission Set이 Profile보다 중요한지 실전 사례 중심으로 설명한다. Salesforce의 공식 자료와 실무 사례를 바탕으로 정리하며, 이해를 돕기 위한 예시도 포함했다. salesforcetrainingindia.com+1

문제

Profile의 한계: 단 하나만 할당 가능하다

Salesforce에서 Profile은 모든 사용자에게 반드시 하나가 할당되는 기본 권한 집합이다. 객체 접근, 필드 수준 보안, 시스템 권한 등 대부분의 권한은 Profile로 설정된다. 하지만 다음과 같은 한계가 있다.

• 하나의 사용자에게 오직 하나의 Profile만 할당 가능하다는 점은 복잡한 권한 시나리오를 처리할 수 없게 만든다. salesforcetrainingindia.com
• 여러 권한 조합이 필요할 때는 Profile을 새로 만들어야 하는데, 이는 Explosion(폭발적 증가)을 초래한다. 즉 비슷한 권한을 가진 Profile이 여러 개 생겨 관리가 어려워진다. SalesforceCodex
• Profile을 수정하면 그 Profile을 가진 모든 사용자가 영향을 받는다. 작은 변경이 대량 사용자 권한 변경으로 이어져 의도치 않은 권한 탈취 또는 과도한 권한 부여로 이어질 수 있다. salesforcetrainingindia.com

Role이나 Sharing과 혼동하면 더 위험하다

Role Hierarchy(역할 계층)는 레코드 가시성을 결정하는 구조다. 하지만 Role은 레코드를 볼 수 있는 범위를 결정할 뿐, 사용자가 어떤 기능을 실행할 수 있는지를 제어하지 않는다. 프로필만으로 권한을 완벽히 제어하려고 활용하면 오해가 생기고 문제가 복합적으로 얽힌다. CRS Info Solutions

해결

Permission Set으로 권한을 확장한다

Permission Set은 Profile의 권한을 확장하는 수단으로 설계됐다. 사용자는 Profile 하나를 갖지만 여러 Permission Set을 동시에 가질 수 있다, 이 때문에 권한 설계가 훨씬 유연해진다. kicksaw.com+1

Permission Set의 장점

• 여러 개 할당 가능: Permission Set은 필요한 만큼 여러 개를 만들고 하나의 사용자에게 복수로 할당할 수 있다. SalesforceCodex
• Profile 변경 없이 권한 확장: 기본 Profile을 변경하지 않고도 개인별 권한을 확장할 수 있어 위험이 줄어든다. Trailhead
• Temporary(임시) 권한 부여 가능: 프로젝트나 특정 기간 동안만 권한을 부여했다가 제거할 수 있다. TechForce Academy

예시로 보는 Permission Set의 유용성

예를 들어 영업팀 사용자 모두에게는 Sales User Profile이 할당되어 있다고 가정하자. 기본적으로 이 프로필은 리드, 거래처, 기회 객체에 대해 읽기, 수정 권한만 가진다. 그런데 몇 명의 영업사원이 특정 오브젝트를 삭제하거나 API 기능을 사용해야 하는 경우가 있다.

이때 두 가지 선택이 있다.

• (나쁜 선택) Sales User Profile을 복제해서 새 권한을 추가한 후 몇 명에게만 할당한다.
  → Profile 수가 늘고 관리가 어려워짐.
• (좋은 선택) API/삭제 권한을 가진 Permission Set을 새로 만들고, 해당 사용자에게만 할당한다.
  → Profile은 그대로 유지되고 권한만 필요 사용자에게 부여된다. kicksaw.com

이 예시는 Permission Set이 왜 Profile보다 강력하고 실무에서 유리한지 보여준다.

Permission Set Group을 활용해 설계 복잡도를 낮춘다

Permission Set을 여러 개 사용하는 경우 관리가 번거로울 수 있다. 이를 위해 ‘Permission Set Group’이라는 개념을 통해 관련된 Permission Set들을 하나의 그룹으로 묶어서 사용자에게 할당할 수 있다. 이 방식은 대규모 조직의 복잡한 권한 모델을 단순화한다. Trailhead

권한 설정 시 실무 팁

• 기본적으로 Profile은 최소 권한만 부여하고
• 추가 권한은 Permission Set으로 부여하라.
• 여러 Permission Set을 자주 쓰는 조합이 있다면 Permission Set Group으로 묶어 재사용하라.

이 원칙은 권한 설계를 유지보수하기 쉽게 만든다.

결론

Salesforce에서 Profile은 중요한 기능이지만, 이 시스템만으로 권한을 관리하는 것은 매우 제한적이고 위험하다. Permission Set은 이러한 한계를 극복할 수 있도록 만들어진 도구로, 아래와 같은 이유로 권한 설계에서 핵심적이다.

• 하나의 Profile만 할당 가능하다는 구조적 한계를 Permission Set이 보완한다. salesforcetrainingindia.com
• Permission Set은 여러 개 할당이 가능해 세밀한 권한 확장과 유지보수성을 높인다. SalesforceCodex
• Permission Set Group을 활용해 관리 복잡성을 줄일 수 있다. Trailhead

따라서 Salesforce 권한 모델 설계 시 Profile은 베이스라인, Permission Set은 확장의 도구로 사용하는 것이 장기적인 안정성, 보안, 유지보수 측면에서 가장 바람직하다.
이 접근법은 특히 조직 규모가 커지고 역할이 다양해질수록 그 진가가 드러난다.

자주 묻는 질문 (FAQ)

Profile로 모든 권한을 처리할 수 없나요?

Profile은 기본적인 권한만 처리할 수 있다. 하지만 하나의 사용자에게 Profile은 하나만 할당 가능하며, 구체적인 역할별 권한까지 다루기 어렵다. Permission Set을 사용하면 프로필 변경 없이 개별적으로 권한을 확장할 수 있다. salesforcetrainingindia.com

Permission Set이 Profile을 대신하나요?

Permission Set은 Profile을 대체하는 것이 아니라 확장하는 도구다. Profile이 베이스라인 역할을 하고 Permission Set으로 필요한 추가 권한을 부여한다. Permission Set은 Profile이 부여한 권한을 되돌리거나 제한할 수 없다. salesforcetrainingindia.com

Permission Set Group이 무엇인가요?

Permission Set Group은 여러 Permission Set을 묶어서 한 번에 사용자에게 할당할 수 있는 구조이다. 이는 반복되는 권한 조합을 효율적으로 관리할 때 매우 유용하다. Trailhead

도입: 왜 지금 Agent AI를 이야기하는가

Salesforce는 최근 Agentforce라는 이름으로 AI 에이전트를 CRM 전반에 본격적으로 통합하고 있다. 단순한 챗봇이나 추천 기능을 넘어, 사용자의 요청을 이해하고 필요한 데이터를 조회한 뒤 실제 업무까지 수행하는 구조다. 고객 응대, 세일즈 지원, 내부 운영 자동화 등 적용 범위도 넓다.

문제는 “AI가 된다”는 말만 듣고 도입을 결정하기에는 현실이 그렇게 단순하지 않다는 점이다. 실제 프로젝트를 경험해보면 Agent AI는 기술보다 데이터 구조, 조직 준비도, 운영 전략에 훨씬 더 크게 영향을 받는다. 이 글에서는 Agent AI 도입을 고민하는 입장에서 반드시 짚고 넘어가야 할 현실적인 포인트를 정리해본다.

문제: Agent AI 도입에서 자주 발생하는 현실적인 어려움

데이터는 있는데, 쓸 수 없는 경우

Agent AI는 Salesforce에 쌓인 데이터를 기반으로 동작한다. 하지만 많은 조직에서 CRM 데이터는 “존재”만 할 뿐, AI가 신뢰할 수 있는 상태는 아닌 경우가 많다.
중복된 계정, 오래된 리드, 표준화되지 않은 커스텀 필드 구조는 AI 에이전트의 판단 정확도를 급격히 떨어뜨린다.

실제로 Agent AI를 테스트해보면, 답변이 엉뚱하게 나오거나 실행 결과가 기대와 다른 경우가 발생하는데, 원인을 따라가 보면 대부분 데이터 품질 문제로 귀결된다.

기대가 너무 큰 상태에서 시작하는 도입

Agent AI는 마치 사람처럼 모든 업무를 대신해 줄 것처럼 보이지만, 초기 단계에서는 명확히 정의된 시나리오에서만 안정적으로 동작한다.
“모든 고객 문의를 자동 처리하자” 같은 목표로 시작하면, 오히려 실망만 커질 수 있다.

특히 경영진과 실무자 사이에 기대 수준이 맞지 않으면, 도입 이후 평가 단계에서 프로젝트 자체가 실패로 인식되는 경우도 적지 않다.

비용과 운영 부담에 대한 간과

Agent AI는 단순 기능 추가가 아니다.
Data Cloud 연계, 추가 라이선스, 프롬프트 설계, 운영 정책 수립 등 지속적인 관리 비용이 발생한다. 초기 구축보다 이후 운영 단계에서 부담이 커지는 경우도 많다.

해결: 실패 확률을 낮추는 현실적인 접근 방법

데이터 정비를 가장 먼저 고려해야 한다

Agent AI 도입 전에 가장 먼저 해야 할 일은 데이터 정리다.
계정, 연락처, 케이스, 활동 이력 등 핵심 오브젝트를 기준으로 중복 제거와 구조 정비가 선행되어야 한다.

이 단계 없이 AI를 먼저 붙이면, 문제를 해결하기 위해 AI를 도입했는데 오히려 문제를 더 복잡하게 만드는 상황이 발생한다.

작은 업무부터 시작하는 것이 정답이다

전사 도입보다는 하나의 명확한 업무를 정해 파일럿으로 시작하는 것이 현실적이다.
예를 들면 다음과 같은 영역이다.

• 자주 반복되는 고객 문의에 대한 1차 응답
• 내부 직원용 CRM 데이터 조회 에이전트
• 세일즈 미팅 후 요약 자동 생성

이렇게 범위를 제한하면 성과 측정이 쉬워지고, 내부 신뢰도도 빠르게 쌓을 수 있다.

AI는 자동화 대상이 아니라 ‘보조자’로 설계해야 한다

Agent AI는 모든 결정을 대신하는 존재가 아니라, 사람의 판단을 빠르게 돕는 도구에 가깝다.
중요한 승인이나 고객 대응에는 반드시 사람이 개입할 수 있는 구조를 남겨두는 것이 운영 안정성 측면에서 유리하다.

한국 기업 사례에서 얻을 수 있는 시사점

국내 금융사와 통신사 사례를 보면, Agent AI를 전면에 내세우기보다 상담원의 업무 부담을 줄이는 방향으로 활용한 경우 성과가 좋았다.
단순 반복 문의는 AI가 처리하고, 상담원은 복잡한 케이스에 집중하는 구조다. 이 방식은 고객 만족도와 내부 생산성을 동시에 개선하는 결과로 이어졌다.

결론: Agent AI는 기술이 아니라 준비도의 문제다

Salesforce Agent AI는 분명 강력한 도구다. 하지만 성공 여부는 기능 자체보다 데이터 상태, 도입 범위 설정, 조직의 이해도에 달려 있다.
AI를 도입한다는 사실보다, 어떤 문제를 해결하려는지가 더 중요하다.

충분한 사전 준비와 단계적인 접근이 이루어진다면 Agent AI는 비용이 아니라 투자로 작동한다. 반대로 준비 없이 도입하면, 유지비만 늘어나는 시스템이 될 가능성도 높다.

사람들이 자주 묻는 질문

Salesforce Agent AI는 기존 챗봇과 무엇이 다른가요?

기존 챗봇은 정해진 시나리오 기반 응답이 중심이라면, Agent AI는 CRM 데이터를 조회하고 업무를 실제로 실행할 수 있는 구조다. 단순 응답이 아니라 업무 흐름에 직접 개입한다는 점이 가장 큰 차이다.

중소 규모 조직도 도입이 가능한가요?

가능하다. 다만 전사 도입보다는 특정 업무에 한정한 소규모 적용이 적합하다. 데이터 구조가 단순한 조직일수록 초기 성과를 내기 쉬운 편이다.

개발자가 꼭 필요한가요?

노코드 설정만으로도 시작은 가능하다. 하지만 실제 운영 단계에서는 프롬프트 설계, 예외 처리, 외부 시스템 연계를 위해 개발자의 역할이 점점 중요해진다.

실무에서 Flow가 더 위험해지는 순간들

세일즈포스 개발자로 일하다 보면 자동화를 구현할 때 가장 많이 고민하게 되는 선택지가 있다. Apex Trigger를 사용할지, 아니면 Flow로 처리할지에 대한 문제다. Salesforce는 최근 몇 년간 Flow를 중심으로 한 로우코드 자동화를 적극적으로 권장하고 있고, 실제로 간단한 요구사항에서는 Flow가 빠르고 효율적인 선택이 된다.

하지만 실무에서는 “Flow로 구현했는데 운영 중에 장애가 났다”거나, “Apex로 다시 구현하고 나서야 문제가 사라졌다”는 상황을 종종 마주하게 된다. 이 글에서는 단순한 기능 비교가 아니라, 실무에서 Flow가 오히려 더 위험해지는 순간은 언제인지, 그리고 어떤 기준으로 Apex Trigger와 Flow를 선택해야 하는지를 정리해본다.

Governor Limit에 더 민감해지는 Flow

Salesforce의 Governor Limit은 Apex뿐 아니라 Flow에도 동일하게 적용된다. 문제는 Flow에서는 이 제한을 개발자가 체감하기 어렵다는 점이다.

Record-Triggered Flow는 내부적으로 SOQL과 DML을 자동으로 생성해 실행한다. Flow 화면에서는 단순히 “Get Records”, “Update Records”처럼 보이지만, 실제 실행 시에는 Apex와 동일하게 limit이 누적된다. 특히 Apex 로직과 Flow가 같은 트랜잭션 안에서 함께 실행되면, CPU Time이나 DML limit 초과로 이어지는 경우가 많다.

이런 문제는 테스트 환경에서는 잘 드러나지 않고, 데이터가 쌓인 이후 운영 환경에서 처음 발생하는 경우가 많아 더 위험하다.

대량 데이터 처리에서 드러나는 한계

Apex Trigger는 기본적으로 bulk 처리를 전제로 설계된다. 개발자가 직접 컬렉션을 다루고, SOQL과 DML을 한 번씩만 실행하도록 제어할 수 있기 때문이다.

반면 Flow는 반복 구조가 시각적으로 명확하지 않다. 특히 다음과 같은 구조는 실무에서 자주 문제를 일으킨다.

• Record-Triggered Flow에서 관련 레코드를 조회
• Loop를 사용해 레코드를 하나씩 처리
• Loop 안에서 Update Records 실행

설계 단계에서는 문제가 없어 보이지만, 관련 레코드 수가 늘어나면 DML limit에 빠르게 도달한다. 데이터가 적을 때는 정상 동작하다가, 어느 순간 갑자기 장애로 이어지는 전형적인 패턴이다.

복잡해질수록 유지보수가 어려워지는 Flow

Flow는 처음에는 직관적이고 이해하기 쉽다. 하지만 요구사항이 추가되면서 Decision 요소가 늘어나고, Subflow가 연결되고, 예외 처리를 위한 Fault Path가 추가되면 전체 흐름을 파악하기가 점점 어려워진다.

코드는 코드 리뷰와 버전 관리로 변경 이력을 추적하기 쉽지만, Flow는 변경이 누적될수록 영향 범위를 파악하기가 쉽지 않다. 여러 명이 동시에 관리하는 조직에서는 이 문제가 더욱 크게 드러난다.

해결

Flow에서 문제가 되는 대표적인 구조 예시

실무에서 자주 보게 되는 Flow 구조를 예로 들어보자.

• Account 업데이트 시 실행되는 Record-Triggered Flow
• 특정 조건을 만족하면 관련 Contact 조회
• Loop를 돌며 Contact를 하나씩 업데이트

Flow 상에서는 자연스러운 구조지만, 내부적으로는 다음과 같은 문제가 발생한다.

• Loop 안에서 DML이 반복 실행됨
• Contact 수가 많아질수록 DML limit 소모 증가
• 다른 Apex 로직과 함께 실행될 경우 limit 초과 가능성 증가

Flow에서는 이런 구조가 즉각적으로 위험해 보이지 않기 때문에, 데이터가 늘어난 뒤에야 문제가 드러나는 경우가 많다.

같은 로직을 Apex Trigger로 구현했을 때

위와 동일한 요구사항을 Apex Trigger로 구현하면 구조가 훨씬 명확해진다.

trigger AccountTrigger on Account (after update) {
    Set<Id> accountIds = new Set<Id>();

    for (Account acc : Trigger.new) {
        if (acc.Status__c == 'Active') {
            accountIds.add(acc.Id);
        }
    }

    if (!accountIds.isEmpty()) {
        List<Contact> contactsToUpdate = [
            SELECT Id, Status__c
            FROM Contact
            WHERE AccountId IN :accountIds
        ];

        for (Contact con : contactsToUpdate) {
            con.Status__c = 'Active';
        }

        update contactsToUpdate;
    }
}

이 코드의 핵심은 다음과 같다.

• SOQL은 한 번만 실행
• DML도 한 번만 실행
• 레코드 수가 늘어나도 구조는 변하지 않음
• Governor Limit에 대한 예측이 쉬움

실무에서는 이런 명시적인 bulk 처리 구조가 안정성 측면에서 큰 차이를 만든다.

Flow와 Apex를 함께 사용하는 현실적인 방식

Flow를 완전히 배제할 필요는 없다. 오히려 실무에서는 Flow와 Apex를 역할에 따라 분리해서 사용하는 방식이 가장 안정적이다.

Flow의 역할은 다음과 같다.

• Record-Triggered Flow에서 조건 판단
• 관리자가 수정해야 하는 비즈니스 조건 관리
• Apex 호출 트리거 역할

Apex의 역할은 다음과 같다.

• 대량 데이터 처리
• 복잡한 로직 실행
• 성능에 민감한 연산

이를 위해 Invocable Apex를 사용하는 경우가 많다.

public class UpdateContactsService {

    @InvocableMethod
    public static void updateContacts(List<Id> accountIds) {
        List<Contact> contacts = [
            SELECT Id, Status__c
            FROM Contact
            WHERE AccountId IN :accountIds
        ];

        for (Contact con : contacts) {
            con.Status__c = 'Active';
        }

        update contacts;
    }
}

Flow에서는 이 메서드를 호출만 하고, 실제 데이터 처리 책임은 Apex에 맡긴다.
이 구조의 장점은 명확하다.

• Flow는 단순하고 읽기 쉬움
• Apex는 성능과 안정성 확보
• 역할 분리가 명확해 유지보수 비용 감소

Flow에서 특히 조심해야 할 패턴

실무 기준으로 Flow에서 문제가 되는 패턴은 거의 정해져 있다.

• Loop 안에서 레코드 업데이트
• 동일 객체에 여러 개의 Record-Triggered Flow 존재
• 조건 분기마다 Get Records 반복 실행
• Apex, Flow, 기존 자동화가 동시에 실행되는 구조

이 패턴들이 겹치기 시작하면, 문제는 코드가 아니라 설계 구조 자체에서 발생한다.

Flow는 분명 강력한 자동화 도구다. 하지만 모든 상황에서 Apex Trigger를 대체할 수 있는 만능 해결책은 아니다. 특히 다음과 같은 경우에는 Flow가 오히려 더 위험해질 수 있다.

• 대량 데이터가 동시에 처리되는 트랜잭션
• 여러 자동화가 한 객체에 중첩된 구조
• 복잡한 조건과 반복 로직이 필요한 시나리오

이런 경우에는 Apex Trigger 또는 Apex 기반 로직을 병행하는 것이 안정성과 유지보수 측면에서 훨씬 낫다. 중요한 것은 “Flow냐 Apex냐”의 문제가 아니라, 현재 요구사항에 가장 적합한 도구를 선택하는 개발자의 판단이다.

자주 묻는 질문 (FAQ)

Flow는 Apex Trigger보다 항상 성능이 나쁜가?

그렇지 않다. Before-Save Record-Triggered Flow는 DML 비용을 거의 발생시키지 않아 단순 필드 업데이트에서는 Apex보다 빠를 수 있다. 다만 복잡한 조건, 반복 처리, 대량 데이터 환경에서는 Apex가 더 안정적인 경우가 많다.

같은 오브젝트에 Flow와 Apex Trigger를 함께 사용해도 괜찮은가?

가능하지만 주의가 필요하다. 실행 순서와 Governor Limit 누적으로 인해 예상치 못한 결과가 발생할 수 있다. 역할을 명확히 분리하고 중복 로직을 피하는 것이 중요하다.

모든 자동화를 Flow로 통일하는 것이 좋은 전략인가?

초기에는 관리가 쉬워 보일 수 있지만, 장기적으로는 권장되지 않는다. Flow는 단순 자동화에 강점이 있고, Apex는 복잡한 로직과 성능 제어에 강점이 있다. 두 도구를 상황에 맞게 병행하는 것이 가장 현실적인 전략이다.