# architect 결정 가이드 (decision-guides) - Full Documentation

<!-- document id=8869c765f691d9db0057c20cbcf593cda6bc125b0d6c8dac302f8e11e78282b8 url=/architect/current/ko-kr/decision-guides/guides/get-started-data-360-decision-guides.md -->

# Data 360 Decision Guides 시작하기

이 섹션에서는 프로비저닝 전략, 다중 조직 연결, 통합 패턴 등 Salesforce Data 360에 대한 중요한 아키텍처 결정을 내릴 수 있는 실용적인 지침을 제공합니다. 해당 가이드를 사용하여 고객 데이터를 통합하고 AI 지원 기능을 활성화하는 효과적인 데이터 아키텍처를 설계 및 구현합니다.

---

## Data 360 Provisioning

[Data 360 Provisioning](/docs/architect/ko-kr/decision-guides/guide/data-360-provisioning)은 Salesforce Data 360 프로비저닝 시 기본적인 결정을 다룹니다:

- **Home Org 선택**: 거버넌스, 규정 준수, 가치 실현 기간을 고려하여 기존 프로덕션 조직에 Data 360을 프로비저닝할지, 전용 조직을 생성할지 결정하세요.
- **다중 조직 전략**: 여러 개의 독립적인 Data 360 인스턴스를 사용할지, 또는 Data Cloud One을 사용하여 여러 Salesforce 조직을 통합할지 선택하면서 자율성, 규정 준수, 비용의 균형을 맞추세요.
- **Data Cloud One 아키텍처**: 여러 Companion Org가 중앙 집중식 거버넌스, 메타데이터 공유, 기능 동등성을 통해 단일 Data 360 인스턴스를 공유할 수 있도록 합니다.
- **Data 360 조직 간 데이터 공유**: 지역 규정 준수, 사업부 간 협업 또는 연합 임원용 대시보드를 위해 독립 인스턴스 간 제로-카피 데이터 공유를 사용하세요.
- **Provisioning Considerations**: 엔터프라이즈 전체 배포를 위해 데이터 소재지, 거버넌스 모델, 대기 시간, 통합 복잡성, 비용, AI 준비 상태를 고려하세요.

아키텍트가 Customer 360, AI 및 크로스-플랫폼 혁신에 있어 단순성, 엔터프라이즈 일관성, 규정 준수, 확장성을 보장하는 프로비저닝 전략을 설계할 수 있도록 돕습니다.

---

## Data 360 상호 운용성

[Data 360 Interoperability](/docs/architect/ko-kr/decision-guides/guide/data-360-interoperability)는 Data 360을 외부 플랫폼 및 데이터 레이크와 통합하는 프레임워크를 제공합니다:

- **데이터 수집 패턴**: 실시간, 스트리밍, 배치 수집을 통해 Customer 360, 규정 준수, 중앙 집중식 거버넌스에 적합한 관리되는 표준 데이터셋을 생성할 수 있습니다.
- **Zero-Copy Data Federation**: 라이브 쿼리, 가속 쿼리(캐싱), 파일 페더레이션 방법을 통해 중복 없이 외부 시스템에 실시간으로 접근할 수 있으며, 이를 통해 개인화, 대시보드, AI 및 ML 워크로드를 지원합니다.
- **하이브리드 접근 방식**: 핵심 데이터셋에 대한 관리형 수집과 최신성 및 확장성을 위한 제로-카피 페더레이션을 결합하여 옴니채널 참여, Agentforce 기반 작업, 엔터프라이즈 분석을 지원합니다.
- **결정 프레임워크**: 대기 시간, 비용, 확장성, 거버넌스, 복잡성 측면에서 제약을 평가하여 데이터 소스당 올바른 통합 패턴을 선택합니다.
- **아키텍트 플레이북**: 금융, 헬스케어, 소매, 통신 시나리오에 대한 산업별 지침, 설계 관행, 비용 고려 사항

아키텍트가 데이터 최신성, 거버넌스, 그리고 파이프라인 효율성 간의 균형을 맞추어 운영 및 분석 워크로드를 지원하는 확장 가능하고 상호 운용 가능한 AI 준비 데이터 아키텍처를 구축하도록 안내합니다.

<!-- document id=5fb9d0bffaf6fbfb9b059020d59845e3d2c209524a3d9a69819a782b069684b4 url=/architect/current/ko-kr/decision-guides/guides/data-360-interoperability.md -->

# Data 360 상호 운용성

기업은 종종 Salesforce 및 기타 외부 데이터 레이크(예: _Snowflake_, _Google BigQuery_, _Databricks_, _Redshift_ 또는 _Amazon S3_과 같은 개체 저장소)에 데이터를 저장합니다. 여러 시스템에 분산된 데이터는 기업이 데이터의 전체 가치를 활용하여 AI 기반 경험을 구현하는 데 어려움을 겪게 만듭니다. Salesforce _Data 360_은 모든 Agentforce AI 에이전트가 적시에 올바른 컨텍스트에 액세스하기 위해 사용하는 기본 인텔리전스 계층입니다.

여러 데이터 레이크에서 데이터를 함께 가져오는 작업을 수행하는 아키텍트들은 해당 데이터를 가장 효과적으로 통합하는 방법에 대한 주요 아키텍처 결정에 직면하게 됩니다. _Data 360은_ 데이터 통합을 위한 여러 옵션을 제공하며, 각각은 다양한 장단점을 제공합니다.

## 가이드 개요

이 가이드는 데이터 통합 시 대기 시간, 비용, 확장성, 거버넌스, 복잡성에 대한 요구 사항에 가장 적합한 패턴을 평가하는 프레임워크를 제공하므로 데이터 수집, Zero Copy 데이터 연합 또는 하이브리드 접근 방식을 사용할 시기를 선택할 수 있습니다. 가이드는 각각 다른 요구를 충족하는 다양한 데이터 수집 및 데이터 연합 방법 중에서 선택하는 데도 도움이 됩니다.

외부 데이터 레이크 하우스를 _Data 360_과 통합하려면 데이터 신선도, 거버넌스 및 파이프라인 효율성 간의 상호 작용을 주의 깊게 고려해야 합니다. 예를 들어, Zero Copy 데이터 연합 실시간 쿼리를 사용하면 데이터의 신선도가 극대화되지만, 더 많은 데이터가 네트워크를 통해 이동하면 파이프라인 효율성이 저하될 수 있습니다. 대부분의 실제 구현에서 다중 클라우드 레이크 하우스 생태계에서 수집 및 연합을 결합하는 것이 최적의 경로입니다. 이 하이브리드 접근 방식은 저 대기 시간 운영 워크로드(예: 실시간 개인 설정 및 사기 감지) 및 분석 워크로드(예: 규제 보고 및 내역 추세 분석)를 지원하는 확장 가능, 관리 가능, 상호 운용 가능한 아키텍처를 보장합니다. 이 가이드는 적절한 전략을 사용하여 이러한 절충점을 조율하는 방법을 결정하는 데 도움을 줍니다.

## 주요 인테이크

- **데이터 수집**은 데이터를 Salesforce _Data 360_에 복사하고, 관리되고 표준화된 데이터 모델을 생성합니다. 다음과 같은 경우에 적합합니다.
  - **포괄적인 Customer 360 구축** 이렇게 하면 서로 다른 소스를 통합하고 신뢰할 수 있는 단일 프로필로 변환할 수 있습니다.
  - **엄격한 규정 준수를 준수하십시오.** 이를 통해 감사 가능한 중앙 집중식 복사본을 만들어 데이터 액세스 및 계보를 면밀하게 제어할 수 있습니다.
- **Zero Copy Federation은** 중복 없이 실시간으로 외부 소스를 쿼리하여 실시간 개인화, 실시간 대시보드 및 신속한 소스 온보딩을 지원합니다. 이 접근 방식은 두 가지 기본 옵션을 제공하지만 균형을 맞추어야 하는 제약 사항이 있습니다.
  - **Live Query:** 외부 데이터 플랫폼(예: _Snowflake_, _BigQuery_, _Redshift_ 또는 _Databricks_)에 존재하는 대화형 분석 및 실시간 데이터 대시보드에 이를 사용합니다. 이렇게 하면 소스 시스템에 쿼리 처리를 푸시하고 필요한 결과만 반환하여 비용이 많이 드는 느린 데이터 중복을 방지할 수 있습니다. 이 접근 방식은 최신성이 중요한 드물거나 임시 쿼리에 최적화되어 있습니다. 낮은 _초당 쿼리(QPS)_ 워크로드에 적합합니다(쿼리 비용은 QPS가 높을 때 크게 증가할 수 있습니다).
  - **캐싱(고속 쿼리):** 자주 변경되지 않는 데이터를 대상으로 하는 빈번한 쿼리에 사용합니다. 가속 쿼리는 구성 가능한 간격(15분~7일)으로 업데이트되는 로컬 캐시를 유지하므로 반복적인 소스 접근이 줄어듭니다. 이 접근 방식을 통해 대시보드 성능과 비용, 세분화, BI 워크로드의 균형을 맞추고 약간 오래된 결과를 사용할 수 있습니다. 이는 1초 미만의 의사결정에는 적합하지 않습니다.
  - **파일 통합:** 이를 사용하여 클라우드의 데이터 레이크(예: _S3_ 또는 _ADLS_)의 데이터에 대한 대규모 배치 처리 및 AI 모델 교육을 수행할 수 있습니다. 이 접근 방식은 오픈 테이블 형식의 파일을 직접 쿼리하여 비용이 많이 드는 느린 데이터 수집을 방지하고, 대규모 ETL 데이터셋과 데이터 과학 워크로드를 활용할 수 있게 합니다.
- **하이브리드 모델**은 _통합 프로필_을 위한 데이터 수집과 신선도를 위한 연합을 결합하여 옴니채널 참여, Agentforce 기반 작업, 그리고 AI/ML 교육을 지원합니다.

### 중요 고려 사항

- **하이브리드 아키텍처를 사용하십시오.** 데이터 수집 및 연합을 혼합해야 하는 경우가 많습니다.
  - 정규 데이터 모델 및 핵심 거버넌스를 위해 중요한 데이터에 대한 _데이터 수집_을 사용합니다.
  - 기타 모든 데이터 연합에는 _Zero Copy_를 사용하여 신선도를 유지하고 데이터 수집 파이프라인 구축 및 유지 관리에 필요한 운영 오버헤드를 최소화하십시오.
- **데이터 수집 주기는 중요합니다.** 비즈니스 가치, 대기 시간 요구, 운영 복잡성을 기반으로 주기를 선택합니다.
  - 시간에 민감한 워크플로에 _실시간_을 사용합니다(예: 개인 설정, 실시간 대시보드 및 Agentforce 작업).
  - 약간 긴급한 프로세스(예: 캠페인 및 운영 보고서)에서 _직접 실시간_ 사용
  - 역사적 또는 저속 데이터셋에 배치 처리를 사용합니다.
- **연합 패턴을 지연 시간 및 성능에 맞춥니다.** 액세스 패턴과 최신성, 성능, 비용에 대한 요구 사항에 가장 적합한 옵션을 선택하십시오.
  - _Live Query_를 사용하여 운영 대시보드 및 실시간 개인화를 구현하십시오.
  - 쿼리가 자주 발생하고 약간 오래된 결과가 허용되는 경우 _캐싱(고속 쿼리)_을 사용하여 성능과 비용의 균형을 맞추십시오.
  - 대규모 처리량을 요구하는 분석 또는 배치 워크로드, 즉 역사적 또는 시간에 덜 민감한 데이터셋에는 _파일 연합_을 사용하십시오.
- **거버넌스와 데이터 거주 요구 사항을 조율합니다.**
  - 중앙 집중식 거버넌스가 중요할 때 _데이터 수집_을 사용하십시오.
  - 분산된 거버넌스가 허용되는 경우, _federation_을 사용하고 외부 소스에서는 엄격한 거버넌스를 적용합니다.
  - 소스 수준 정책(예: _행 수준 보안(RLS)_ 및 데이터 마스킹)에 대해 _제로 복사_를 사용합니다.
- **고가치 워크플로를 위한 데이터 수집 우선순위 지정.** 중요한 프로세스(예: ID 확인, 규제 보고, 운영 활성화)에 선택적으로 수집을 적용합니다.
- **비용 및 복잡성이 의사 결정을 좌우합니다.** 실시간 수집은 비싸고 복잡할 수 있습니다. 따라서 아키텍트들은 데이터 온보딩, 저장 및 변환 비용과 _Zero Copy_를 통한 직접 쿼리 비용을 비교해야 합니다.

올바른 통합 패턴(_데이터 수집_, _제로 복제_ 또는 _하이브리드_ 접근 방식)을 선택하면 멀티 클라우드 플랫폼의 지연 시간, 거버넌스, 운영 효율성, 비용에 직접적인 영향을 미칩니다. 이 결정은 실시간 인사이트, AI 기반 활성화, 그리고 개인화된 참여가 신뢰할 수 있고 대규모로 전달되는 방식을 결정합니다.

## 제품 비교

이 표에서는 Salesforce _Data 360_의 _데이터 수집_ 및 _제로 복제_ 패턴을 비교하여 기능, 보상 및 이점, 엔터프라이즈 사용 사례 및 결과에 초점을 맞춥니다. 성능, 비용, 규정 준수에 균형을 맞추는 하이브리드 멀티 클라우드 데이터 플랫폼을 설계할 때 이를 참조할 수 있습니다.

<table>
  <thead>
    <tr>
      <th align="left" valign="top"><strong>패턴 유형</strong></th>
      <th align="left" valign="top"><strong>모드/도구</strong></th>
      <th align="left" valign="top"><strong>혜택</strong></th>
      <th align="left" valign="top"><strong>고려 사항</strong></th>
      <th align="left" valign="top"><strong>결과</strong></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="left" valign="top"><strong>데이터 수집</strong></td>
      <td align="left" valign="top">
        <strong>실시간:</strong>
        <ul>
          <li>CDC가 지원되는 수집 API를 통해 1초 미만의 지연 시간으로 데이터를 수집합니다.</li>
          <li>연속 스트리밍 파이프라인.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>즉각적인 인사이트 제공</li>
          <li>대기 시간이 낮은 운영 및 개인화 사용 사례를 포함합니다.</li>
          <li>이벤트 중심 워크플로 지원</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>높은 비용</li>
          <li>복잡한 아키텍처</li>
          <li>저 대기 시간 소스 시스템 요구 사항</li>
          <li>대용량 소스는 과도한 스트리밍을 유발하여 파이프라인이 포화될 수 있습니다.</li>
          <li>I/O 집약</li>
          <li>선택적 필드 및 필터링은 오버헤드 줄이기에 도움이 될 수 있습니다.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>실시간 사기 경고, 리테일 개인화, 운영 경고</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>1초 미만의 대시보드 및 KPI 모니터링</li>
        </ul>
        <strong>규정 준수:</strong>
        <ul>
          <li>규제된 워크플로에 대한 지속적인 고객 레코드 업데이트</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>스트리밍:</strong>
        <ul>
          <li>네이티브 커넥터를 통해 1~3분마다 마이크로 배치 수집</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>비용과 데이터 신선도 간의 균형을 맞춥니다.</li>
          <li>실시간보다 더 간단한 아키텍처를 제공합니다.</li>
          <li>증분 업데이트를 지원합니다.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>약간의 대기 시간</li>
          <li>중요한 하위 초 결정에 적합하지 않을 수 있음</li>
          <li>배치 크기가 메모리/계산에 미치는 영향</li>
          <li>I/O 중재</li>
          <li>예측 가능한 반복 업데이트 패턴에 적합</li>
          <li>윈도우 집계는 처리 부하를 줄이는 데 도움이 될 수 있습니다.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>적시에 캠페인 트리거 및 거의 실시간 참여를 제공합니다.</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>추천 엔진 및 거의 실시간 대시보드를 제공합니다.</li>
        </ul>
        <strong>규정 준수:</strong>
        <ul>
          <li>감사 추적이 가능한 빈번한 업데이트를 제공합니다.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>배치:</strong>
        <ul>
          <li>커넥터 또는 API를 통해 예약된 대용량 로드를 제공합니다.</li>
          <li>개체 저장소 및 ETL/ELT 파이프라인을 지원합니다.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>대량 데이터 집합의 비용 효율성 지원</li>
          <li>간편한 구현 기능</li>
          <li>내역 분석에 대한 신뢰성 제공</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>데이터 대기 시간</li>
          <li>시간이 많은 작업에 적합하지 않음</li>
          <li>로드 윈도우 동안 I/O 집약적입니다.</li>
          <li>네트워크 처리량이 대용량 파일의 지체 지점이 될 수 있음</li>
          <li>내역 집계 또는 규제된 보고 워크플로에 적합</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>IT 지원 티켓(Jira/ServiceNow) 및 집계된 워크플로</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>내역 분석 및 추세 평가</li>
        </ul>
        <strong>규정 준수:</strong>
        <ul>
          <li>규제 보고 및 환자/ 청구 데이터 집계</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"><strong>Zero Copy</strong></td>
      <td align="left" valign="top">
        <strong>Live Query:</strong>
        <ul>
          <li>데이터 중복 없이 외부 시스템 및 스키마 온 리드에서 직접 쿼리를 제공합니다.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>최대한의 최신성을 제공합니다.</li>
          <li>최소의 저장소 오버헤드를 제공합니다.</li>
          <li>실시간 운영 인사이트를 지원합니다.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>소스 성능에 따라 달라집니다.</li>
          <li>쿼리 용량이 많은 경우 대기 시간에 영향을 미칠 수 있음</li>
          <li>조건자 푸시다운 및 집계를 통해 I/O를 최소화하는 쿼리에 적합합니다.</li>
          <li>대량 데이터 집합에 필터링되지 않은 쿼리를 사용하지 않음</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>실시간 활동에 적응하는 동적 워크플로</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>운영 대시보드 및 실시간 보고</li>
        </ul>
        <strong>규정 준수:</strong>
        <ul>
          <li>소스에서 행 수준 보안 및 마스킹을 준수합니다.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>고속 쿼리(캐싱):</strong>
        <ul>
          <li>15분에서 7일 사이에 구성할 수 있는 연합 쿼리에 대해 캐시된 로컬 사본을 제공합니다.</li>
          <li>최적화된 쿼리 실행 제공</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>대기 시간 줄이기</li>
          <li>반복 실시간 쿼리보다 비용이 낮습니다.</li>
          <li>자주 사용하는 액세스 패턴의 성능을 향상시킵니다.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>캐시 관리 필수</li>
          <li>캐시 간격에 따라 신선도가 달라짐</li>
          <li>빈도가 높은 쿼리에 적합합니다.</li>
          <li>1초 미만의 의사결정에는 적합하지 않습니다.</li>
          <li>증분 새로 고침은 업서트만 지원하며, 삭제된 레코드는 캐시에서 제거되지 않습니다.</li>
          <li>캐시를 소스와 동기화된 상태로 유지하려면 정기적으로 수동 전체 새로 고침이 필요합니다.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>빠른 결정을 위한 사전 집계된 참여 메트릭</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>BI 대시보드, 세분화, 분석 보고</li>
        </ul>
        <strong>규정 준수:</strong>
        <ul>
          <li>감사 로그가 있는 일관되게 규제되는 대시보드</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>파일 통합:</strong>
        <ul>
          <li>객체 저장소 또는 호수(예: <em>S3</em>, <em>Iceberg</em>, <em>Google BigQuery</em>, <em>Redshift</em>)의 대규모 역사 데이터 집합에 직접 액세스할 수 있습니다.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>대규모 데이터 집합 처리</li>
          <li><em>Data 360</em>에서 최소한의 저장소 필요</li>
          <li>AI/ML 워크로드 지원</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>읽기 전용</li>
          <li>외부 시스템 처리량에 따른 쿼리 성능</li>
          <li>배치 작업이 많고 처리량이 중요한 작업에 적합합니다.</li>
          <li>실시간 대시보드에는 적합하지 않음</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>일반적이지 않음(배치 중심적임)</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>ML/AI 교육, 과거 분석, 페타바이트 규모 보고서 작성</li>
        </ul>
        <strong>규정 준수:</strong>
        <ul>
          <li>중복 없이 외부 데이터 집합에 대한 액세스를 관리합니다.</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

## Data 360 통합 패턴

Data 360에는 데이터 수집, 데이터 통합 제로 복사, 하이브리드 접근 방식의 세 가지 기본 통합 패턴이 있습니다.

### 데이터 수집

_데이터 수집_을 사용하면 데이터가 물리적으로 _Data 360_에 복사되어 완전히 관리되며, 데이터가 소스에 남아 있는 _Zero Copy_와는 다릅니다. 즉, 변환을 위한 계산은 중앙 집중식 관리 및 감사를 제공하는 _Data 360_ 내에서 수행됩니다.

#### 데이터 수집 사용 사례

규정 준수 및 운영 제어를 위해 _데이터 수집_을 사용하여 Salesforce _Data 360_에 정규 관리 데이터 집합을 저장합니다. 전체 제어, 감사, 추적 가능성이 필요한 경우 수집을 사용합니다. 데이터 수집은 중앙 집중식 계산 및 거버넌스가 중요한 규제 또는 가치가 높은 워크플로에 적합합니다.

수집은 ID 확인, 규제 보고, 미션 크리티컬한 AI 기반 워크플로 및 고객 참여를 위한 신뢰할 수 있는 기반을 구축하는 데 적합합니다.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360  Ingestion.png" alt="데이터 수집 개요" />

#### 데이터 수집 방법

_데이터 수집_ 방법은 데이터 수집에 사용하는 커넥터에 따라 다를 수 있습니다. 일부 커넥터는 다양한 수집 방법을 제공하며, 다른 커넥터는 배치 또는 스트리밍 모드에서만 작동합니다. _Data 360_ 커넥터 및 사용 가능한 방법의 전체 목록을 보려면 [Data 360: 통합 및 커넥터](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5).

- **실시간:**
  - _Change Data Capture(CDC)_를 사용하여 초 단위 미만의 데이터 수집을 제공합니다.
  - 시간이 중요한 워크플로에 적합합니다(예: 사기 감지, 개인 설정, 운영 대시보드).
  - 다운스트림 I/O를 줄이고 컴퓨팅 사용을 최적화하는 데 도움이 되는 _Data 360_ 내 푸시 변환 및 집계 기능
  - 증분 CDC를 사용하여 데이터 섞기 최소화 지원
- **스트리밍:**
  - 1~3분마다 소규모 증분으로 데이터를 수집합니다.
  - 신선함과 비용의 균형 유지
  - 캠페인 오케스트레이션, 거의 실시간 참여, 운영 보고에 적합
  - 마이크로 배치를 사용하여 입출력 급증 제어 지원
  - 가능한 경우 소스에서 데이터를 집계하여 전송량을 줄이고 저장소를 최적화합니다.
- **배치(예약 로드):**
  - 대규모 데이터 집합의 정기 수집을 제공합니다(예: 시간별, 매일, 매주).
  - 내역 데이터 집합, 규제 보고, 규정 준수 사용 사례에 대한 비용 효율성 및 신뢰성을 제공합니다.
  - 성능을 향상하고 비용을 최적화하기 위해 계산 지역이 소스 저장소와 동일한 지역에 있는지 확인합니다.

#### 설계자 플레이북

- **데이터 수집 사용 사례:**
  - **Customer 360 통합 프로필 생성.** 고객 ID 및 특성에 대한 신뢰할 수 있는 단일 소스를 구축합니다.
  - **규제 준수 데이터 집합을 유지합니다.** 민감한 데이터에 대해 거버넌스, 계보 및 감사 가능성을 적용합니다.
  - **캠페인 오케스트레이션을 중앙 집중화합니다.** 마케팅, 세일즈, 서비스가 모두 일관되고 신뢰할 수 있는 데이터 집합에서 작동하는지 확인합니다.
- **설계 방법:**
  - 역사적 또는 저지연을 허용하는 요구 사항(예: 보관 보고서 또는 정기 스냅샷)에 대해 배치 수집을 수용합니다.
  - CDC 또는 스트리밍 API를 사용하여 운영 및 개인화 워크플로를 최신 상태로 유지하여 실시간에 가까운 업데이트를 보장합니다.
  - 전체 데이터 집합을 다시 로드하는 대신 비용 및 효율성을 최적화하기 위해 증분 로드를 적용하여 저장소 및 계산 성장을 제어합니다.
  - 수집 파이프라인을 컴퓨팅 로컬리티 및 증분 처리에 맞춰 네트워크 I/O를 줄입니다.
  - 불필요하게 원시 데이터를 이동하지 않도록 _Data 360_ 내에서 변환을 적용합니다.
- **비용 고려 사항:**
  - **실시간 수집**은 가장 높은 컴퓨팅 및 파이프라인 비용이 발생하며, 이는 개인화, 운영 대시보드 또는 Agentforce 기반 작업과 같이 가치가 높고 시간에 민감한 워크플로에 대해 정당화될 수 있습니다.
  - **스트리밍 수집**은 적당한 컴퓨팅 및 스토리지 비용이 소요되며, 약간의 지연을 감수할 수 있는 빈번한 업데이트(예: 캠페인 오케스트레이션 또는 운영 보고)에 적합할 수 있습니다.
  - **배치 수집**은 낮은 컴퓨팅 비용과 예측 가능한 스토리지를 제공하며, 이 스토리지는 기록 데이터 집합이나 저주량 업데이트에 적합합니다. 특정 커넥터를 사용하여 Salesforce 조직에서 배치 데이터를 수집하는 것은 무료입니다.
  - **새로 고침 모드**에서는 _증분 새로 고침_ 모드를 선택할 수 있으며, 이를 통해 총 수집 및 계산 비용을 줄일 수 있습니다. Salesforce에서는 모든 수집 유형의 효율성을 최적화하기 위해 가능한 한 _증분 새로 고침_을 사용하는 것이 좋습니다.
  - **비용**도 소스에서 _Data 360_으로의 I/O 볼륨에 영향을 받습니다. 배치 크기, 파티션, 지역 정렬을 최적화하면 전송 비용이 절감되고 성능이 향상됩니다.
- **산업 시나리오:**
  - **금융:** 수집 데이터 집합은 _고객 파악(KYC)_, _돈 세탁 방지(AML)_ 및 감사 가능성 및 규정 준수가 협상되지 않는 사기 감지에 필요합니다.
  - **헬스케어:** 환자 신원 확인 및 HIPAA 준수를 충족하는 레코드를 위해 수집을 사용하면 안전하고 통합된 뷰를 제공할 수 있습니다.
  - **소매:** 세분화 및 개인 설정을 위해 _Sales Point (POS)_, eCommerce 및 충성도 프로그램 데이터를 통합 프로파일로 통합합니다.
  - **Telecom:** 표준화되고 관리되는 구독자 데이터로 이탈 방지 및 사용량 분석을 지원합니다.

#### 데이터 수집 방법 결정 기준

| 기능                              | 실시간 수집                                                                                                                                                                         | 스트리밍 수집                                                                                                                                           | 배치 수집                                                                                                                                                                            |
| :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **지연성과 신선함**            | _Change Data Capture (CDC)_ 지원을 통해, 1초 미만의 지연을 제공하는 수집 기능을 Ingestion API로 제공합니다. 연속 스트리밍 파이프라인을 제공합니다. 대기 시간이 낮은 운영 사용 사례에 적합합니다. | 네이티브 커넥터를 통해 1~3분마다 마이크로 배치 수집을 제공합니다. 증분 업데이트를 지원합니다. 약간의 대기 시간이 예상됩니다.                             | 데이터 대기 시간이 예상됩니다. 예약된 대용량 로드를 허용합니다. 정기 수집(시간별, 매일, 매주)을 제공합니다. 시간에 민감한 작업에는 적합하지 않습니다.                        |
| **기본 사용 사례**                | 대기 시간이 낮은 운영 및 개인화 사용 사례에 적합합니다. 시간에 민감한 워크플로에 사용합니다. 이벤트 중심 워크플로를 지원합니다. 실시간 사기 경고 및 운영 경고에 사용합니다.  | 적당히 긴급한 프로세스에 적합합니다. 캠페인 오케스트레이션, 실시간 참여, 운영 보고에 사용합니다. 적시에 캠페인 트리거에 사용합니다.  | 대량 데이터 집합의 경우 비용 효율적입니다. 역사적 분석을 신뢰할 수 있습니다. 이력 집계 또는 규제된 보고 워크플로에 사용합니다. 이력 또는 저속 데이터 집합에 적합합니다. |
| **아키텍처 복잡성 및 I/O** | 비용이 많이 들고 복잡한 아키텍처를 포함합니다. 저지연 소스 시스템이 필요합니다. 입출력 집약적입니다. 대용량 소스는 포화 파이프라인을 야기할 수 있습니다.                                         | 실시간보다 더 간단한 아키텍처를 제공합니다. 입출력은 보통입니다. 예측 가능한 반복 업데이트 패턴에 적합합니다. 배치 크기는 메모리 및 계산에 영향을 미칩니다. | 구현하기 쉽습니다. 로드 기간 동안 I/O 집약적입니다. 네트워크 처리량은 대량 배치에서 병목 현상이 될 수 있습니다.                                                                        |
| **비용 고려 사항**              | 가장 높은 계산 및 파이프라인 비용을 포함합니다. 가치가 높고 시간에 민감한 워크플로에 대해서만 정당화될 수 있습니다.                                                                                 | 보통의 컴퓨팅 및 스토리지 비용을 포함합니다. 비용과 신선도 간 균형 잡힌 접근 방식을 제공합니다. 약간의 지연을 허용할 수 있는 자주 업데이트에 적합합니다.   | 컴퓨팅 비용을 낮추고 예측 가능한 스토리지를 제공합니다. 이력 데이터 집합 또는 저빈도 업데이트에 권장됩니다. Salesforce 내부 파이프라인을 통한 수집은 무료입니다.                   |
| **설계 관행**                 | 증분 CDC를 사용하여 데이터 셔플링을 최소화합니다. 선택적 필드를 필터링하고 사용하여 오버헤드를 줄입니다.                                                                                         | 마이크로 배치를 사용하여 입출력 급증을 제어합니다. 처리 부하를 줄이기 위해 윈도우 집계를 고려합니다.                                                             | 보관 보고 또는 정기 스냅샷에 사용합니다. 비용 최적화를 위해 컴퓨팅 리소스의 위치가 소스 저장소와 동일한 지역에 있는지 확인합니다.                                              |

### 제로 카피 데이터 연합

#### 제로 카피 사용 사례

_Zero Copy_를 사용하면 데이터 중복 없이 외부 시스템을 실시간으로 쿼리하여 대규모 또는 임시 데이터 집합에 대한 민첩성, 신선도 및 확장 가능한 액세스를 실현할 수 있습니다. 라이브 대시보드, 탐색적 분석, AI/ML 모델 학습, 그리고 실시간 고객 참여에 Salesforce _Data 360_을 통해 직접 사용할 수 있습니다.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360 Zero Copy.png" alt="Zero Copy Data Federation 개요" />

#### 제로 카피 메서드

_Zero Copy_를 사용할 때 아키텍트는 세 가지 사용 가능한 데이터 연합 방법 중에서 선택해야 하며, 각 방법은 신선도, 성능 및 비용 간의 고유한 트레이드오프를 제공합니다.

- **Live Query**
  - 데이터 중복 없이 외부 시스템(예: _Snowflake_, _Google BigQuery_, _Redshift_, _Databricks_ 등)에 대한 쿼리를 직접 실행합니다.
  - 네트워크를 통한 데이터 이동을 최소화하고 Salesforce _Data 360_ 계산의 I/O를 줄여, 조건자와 집계를 푸시다운할 수 있을 때 최적입니다.
  - 실시간 인사이트 및 대기 시간이 낮은 운영 대시보드에 적합합니다.
  - 외부 시스템 성능에 따라 다릅니다.
- **캐싱(고속 쿼리)**
  - Salesforce _Data 360_에 연합 데이터의 캐시된 복제본을 일시적으로 저장합니다.
  - 구성 가능한 기간(분~일)으로 자주 액세스하는 데이터 집합에 대한 반복 쿼리 비용 및 대기 시간을 줄입니다.
  - 데이터는 영구적으로 복사되거나 완전히 관리되지 않으므로 소스에서 예약된 새로 고침을 통해 최신 상태를 관리합니다.
  - _증분 새로 고침_은 업서트만 지원합니다. 삭제된 레코드는 캐시에서 제거되지 않습니다.
  - 캐시가 소스와 동기화된 상태로 유지되도록 정기적으로 전체 새로 고침을 수행합니다.
  - **참고:** _Snowflake_ 커넥터는 Snowflake 시작 스테이징 버킷을 사용하여 가속 속도를 향상시키는 _다운로드_ 기능을 지원합니다. 기본적으로 활성화되어 있지만 연결을 편집하여 비활성화할 수 있습니다.
- **파일 통합**
  - 객체 저장소(예: _S3_ 및 _GCS_에서 _Iceberg_가 적용되는 경우)에서 대규모 데이터 집합에 대해 읽기 전용으로 직접 접근할 수 있습니다.
  - 데이터를 이동하지 않고 AI/ML 워크로드, 이력 분석 및 페타바이트 규모의 보고에 적합합니다.
  - 쿼리 성능은 개체 형식, 분할, 네트워크 I/O에 크게 의존합니다. 대규모 스캔은 최적화되지 않은 경우 상당한 I/O를 생성할 수 있습니다.

#### 설계자 플레이북

- **사용 사례**
  - 고객 행동이 변화함에 따라, **실시간 맞춤화 및 적응형 워크플로우**는 동적 제안, 권장 사항 및 차기 최적의 행동을 제공합니다.
  - **실시간 대시보드 및 운영 분석**은 외부 창고에서 직접 비즈니스 크리티컬 대시보드 및 KPI를 제공합니다.
  - 대규모 외부 데이터 세트를 사용하는 **AI/ML 모델 교육**은 파일 통합을 통해 이동하지 않고도 데이터 레이크 및 창고의 페타바이트 규모의 데이터를 활용합니다.
- **산업 시나리오**
  - **소매/미디어:** 클릭스트림 또는 콘텐츠 상호 작용 데이터를 연합하여 맞춤형 권장 사항 및 실시간 고객 참여를 활성화합니다.
  - **금융:** 중요한 데이터를 복제하지 않고 외부 창고를 쿼리하여 사기 감지 및 위험 점수 매기기를 거의 실시간으로 실행합니다.
  - **Tech/Enterprise:** 데이터 집합이 여러 시스템에 있는 경우 클라우드 간 보고, IT 서비스 대시보드, 운영 분석을 지원합니다.
- **설계 관행**
  - **Live Query**
    - 신선도가 중요한 상황에서 높은 QPS(초당 쿼리)와 낮은 대기 시간의 쿼리에 사용합니다.
    - 외부 시스템에 조건자와 집계를 푸시하여 네트워크상에서의 데이터 이동을 줄입니다.
    - 불필요하게 대용량 데이터를 스캔하는 쿼리를 피하십시오.
    - 대신 파티션 프루닝 및 필터를 고려하십시오.
  - **파일 페더레이션**
    - 수집하지 않고 오브젝트 스토리지에서 페타바이트 규모의 데이터 집합에 액세스합니다.
    - Salesforce 계산과 동일한 클라우드 리전에 오브젝트 스토리지를 유지하여 대기 시간 및 이그레스 비용을 최소화합니다.
    - 파티셔닝된 컬럼 형식(Parquet/ORC) 및 푸시다운 필터를 사용하여 I/O 및 네트워크 전송을 줄입니다.
    - 쿼리 및 조건자 푸시다운을 활용하여 소스에서 데이터를 필터링하고 집계하여 데이터 이동을 줄입니다.
    - 절대적으로 필요한 경우를 제외하고 I/O, 대기 시간, 이그레스 비용이 증가하므로 리전 간 데이터 액세스를 피하십시오.
  - **캐싱(고속 쿼리)**
    - 자주 액세스하는 데이터 집합을 캐시하여 비용과 성능의 균형을 맞춥니다.
    - 새로 고침 간격을 구성하여 신선도와 쿼리 비용 간의 균형을 맞춥니다.
  - **규정 준수:** 소스에서 _행 수준 보안(RLS)_ 및 마스킹 정책을 직접 연합 시스템 내에서 활용하여 거버넌스를 강화합니다.
    - 다음은 플랫폼 전반에서 균일한 RLS 및 마스킹에 대한 몇 가지 모범 사례입니다.
      - **중앙 집중식 엔터프라이즈 ID 사용.** Salesforce _Data 360_의 사용자 및 엔티티를 외부 시스템의 ID에 해당하는 고유한 중앙 집중식 엔터프라이즈 식별자에 매핑합니다.
      - **보안 정책 조정.** 연합 시스템의 RLS 및 마스킹 정책이 매핑된 ID를 기반으로 적용되는지 확인합니다. 이렇게 하면 외부 데이터를 쿼리할 때 규정 준수를 유지할 수 있습니다.
      - **ID 스키마 표준화.** 모든 데이터 소스에서 일관된 ID 특성(이메일, 사용자 ID, 고객 ID 등)을 유지하여 불일치 및 액세스 위반을 방지합니다.
- **비용 고려 사항**
  - **Live Query:** pay-per-query 모델에서 외부 레이크 하우스 계산에 비용이 누적되어 QPS가 높은 경우 급증할 수 있습니다. 이는 비용 변동성보다 높은 가치를 제공하는, 신선도가 중요한 사용 사례에 적합합니다.
  - **고속 쿼리(캐싱):** 이 방법은 소스 시스템에 대한 검색을 줄여 쿼리 비용(_실시간 쿼리)_을 낮추지만 캐시 채우기 및 새로 고침에 대한 배치 데이터 수집 비용을 추가합니다. 이는 자주 액세스하는 데이터 집합에 적합합니다.
  - **파일 페더레이션:** 오브젝트 스토리지에서 데이터로 저장하는 옵션은 가장 저렴하지만 쿼리 비용은 파일 크기, 파티셔닝, 프루닝에 따라 다릅니다. 이는 페타바이트 규모의 과거 또는 대량 데이터에 적합합니다.

#### 제로 카피 방법 결정 기준

| 결정 지점           | 라이브 쿼리                                                                                                                                                                                                                    | 캐싱(가속 쿼리)                                                                                                                                | 파일 통합                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **데이터 소스 위치** | 외부 데이터 레이크(예: _Snowflake_, _Google BigQuery_, _Redshift_ 및 _Databricks_)                                                                                                                         | 외부 데이터 레이크(예: _Snowflake_, _Google BigQuery_, _Redshift_ 및 _Databricks_)                                                      | 오브젝트 저장소 또는 클라우드 데이터 레이크(예: _S3_, _ADLS_ 및 _GCS_)는 종종 _Iceberg_와 같은 오픈 테이블 형식을 사용합니다.                                                                                                                                                                                                                                                                                                                                                     |
| **용도/사용 사례**     | 대화형 분석 및 실시간 대시보드에 적합합니다. 실시간 개인화 및 동적 워크플로에 적합합니다.                                                                                                     | 쿼리가 자주 이루어지지만 결과가 약간 오래된 경우에 적합합니다. BI 대시보드 및 세분화에 적합합니다.                            | 대규모 배치 처리 및 AI/ML 모델 훈련에 적합합니다. 과거 분석 및 페타바이트 규모 보고에 적합합니다.                                                                                                                                                                                                                                                                                                                                              |
| **신선도/대기 시간**    | 최대의 신선도를 제공하며, 실시간으로 쿼리를 실행합니다. 소스 시스템이 효과적인 조건자 푸시다운을 통해 대기 시간이 낮은 쿼리에 최적화된 경우, 1초 미만의 빠른 의사결정을 지원합니다.                                 | 약간 오래된 결과가 허용되는 경우 사용합니다. 새로 고침은 15분에서 7일 사이에 구성할 수 있는 캐시 간격에 따라 다릅니다.                  | 처리량이 많은 배치 작업에 적합합니다. 실시간 대시보딩에 적합하지 않습니다.                                                                                                                                                                                                                                                                                                                                                                                    |
| **액세스 패턴**       | 신선도가 중요한, 쿼리 빈도가 낮은 드문 또는 임시 쿼리에 적합합니다. QPS가 높은 경우 비용이 크게 증가하므로 쿼리 빈도가 높은 경우 캐싱(가속 쿼리)을 평가하는 것이 중요합니다. | 높은 빈도 읽기 시나리오에 적합합니다. 빈번한 액세스 패턴에 대한 성능을 개선합니다.                                                             | r*ead-only* 액세스를 제공합니다. 수집하지 않는 페타바이트 규모의 데이터 집합에 적합합니다.                                                                                                                                                                                                                                                                                                                                                                                             |
| **성능 드라이버**  | 외부 소스 시스템 성능에 크게 의존합니다. 조건자 및 집계를 소스로 푸시할 수 있는 경우에 적합합니다.                                                                                     | 반복 실시간 쿼리와 비교하여 대기 시간을 줄입니다. 성능은 캐시 관리 및 간격에 따라 다릅니다.                                             | 성능은 개체 형식, 파티션 분할 및 외부 시스템 처리량에 크게 의존합니다. 분할된 열 형식(Parquet/ORC)을 사용합니다.                                                                                                                                                                                                                                                                                                                                     |
| **비용 영향**    | 이 모델은 쿼리당 결제 모델이므로 외부 레이크 하우스 계산에 비용이 부과됩니다. 드문 쿼리에는 비용 효율적이지만 QPS 용량이 많은 경우 비용이 급증할 수 있습니다.                                                  | 비용은 반복 실시간 쿼리보다 낮습니다. 외부 소스를 반복적으로 쿼리할 필요가 없지만 캐시 저장소와 새로 고침 오버헤드가 추가됩니다. | 가장 저렴한 저장소 옵션입니다. 동일한 지역의 동일한 클라우드 AWS 설정(예: US-East-1의 _S3_ 및 US-East-1에 있는 _Data Cloud_ 테넌트)의 경우 액세스되는 행에 대한 크레딧이 사용되지 않습니다. 지역 간 또는 클라우드 간 구성(예: _Azure_, _GCS_ 또는 다른 _AWS_ 지역)은 액세스되는 행에 대한 크레딧 소비를 야기합니다. 쿼리 비용은 파일 크기, 파티션 분할 및 조건자 푸시다운 최적화에 따라 다릅니다. |
| **핵심 고려 사항**    | 불필요하게 대량의 데이터를 스캔하는 필터링되지 않은 쿼리를 피하십시오.                                                                                                                                                        | 이 접근 방식은 캐시 관리를 필요로 합니다. 1초 미만의 빠른 의사결정에는 적합하지 않습니다.                                                                          | 쿼리 성능은 파티셔닝 및 조건자 푸시다운을 통한 최적화에 크게 의존합니다.                                                                                                                                                                                                                                                                                                                                                                                        |

### 하이브리드 접근 방식

하이브리드 아키텍처를 사용하면 설계자가 중앙 집중식 거버넌스를 위해 중요한 데이터 집합을 _Data 360_에 배치하면서 신선도 유지, 중복 감소 및 대규모 외부 데이터 집합에 대한 확장 가능한 접근을 달성할 수 있습니다. 이 접근 방식은 I/O, 컴퓨트 로컬리티, 비용, 규정 준수 요구 사항의 균형을 맞춥니다.

#### 하이브리드 사용 사례

데이터 수집 및 제로 복사를 결합하여 실시간 실행 가능한 인사이트를 제공하여 균형 잡힌 거버넌스, 신선함, 운영 효율성을 위해 하이브리드 접근 방식을 사용합니다. 추적 가능성, RLS, 마스킹이 필요한 규제된 가치가 높은 데이터 집합에 대한 수집을 사용하고, 신속성 및 성능이 중요한 임시 또는 대용량 데이터 집합에 대한 연합을 사용합니다.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Copy of Hybrid.png" alt="하이브리드 접근 방식 개요" />

#### 설계자 플레이북

- **사용 사례**
  - **옴니채널 고객 참여:** 과거 고객 데이터를 실시간 행동과 결합하여 상황에 맞는 일관된 환경을 제공합니다.
  - **AI/ML 파이프라인:** 선별된 표준 데이터 집합에서 모델을 학습시키고, 외부 소스의 원시 또는 실시간 신호로 보강합니다.
  - **복합적인 규정 준수 및 민첩성 요구 사항:** 민감한 데이터에 엄격한 거버넌스를 적용하고, 운영 민첩성을 위해 연합을 적용합니다.
- **산업 시나리오**
  - **소매:** ID 확인 및 프로필 통합을 위해 _ingestion_을 사용하고, 실시간 제안 및 개인화를 위해 _federation_을 사용합니다.
  - **헬스케어:** _수집_을 통해 환자 기록을 유지하면서, 즉각적인 컨텍스트를 위해 IoT 장치 스트림 및 센서 데이터에 _연합을 적용합니다_.
  - **금융 서비스:** 규제된 데이터를 규정 준수에 의해 관리되는 데이터 레이크에 수집하고, 외부 사기 감지 및 위험 모니터링 쿼리를 위해 _연합을_ 사용합니다.
- **설계 관행**
  - **수집을 통한 앵커 거버넌스:** 높은 가치 또는 규제된 데이터를 표준 모델로 수집하여 신뢰와 규정 준수를 보장합니다.
  - **신선도 유지를 위한 연합 사용:** 외부 레이크 하우스에서 중복 없이 실시간 또는 대규모 데이터 액세스를 제공할 수 있습니다.
  - **비용 대비 성능:** 작업 부하를 프로파일링하여 _수집_ 또는 _연합_을 언제 사용할지 결정하여 불필요한 스토리지 및 쿼리 비용을 최소화합니다.
  - **계층형 거버넌스 적용:** 수집된 데이터에 중앙 집중식 거버넌스를 적용하면서, 연합 시스템의 보안 제어(예: RLS 및 마스킹)를 활용합니다.
  - **참고:** 하이브리드 파이프라인을 설계할 때 역사적 데이터 집합을 증분적으로 수집하고 연합 소스에 집계 또는 필터를 푸시하여 입출력 및 계산 사용을 최적화하는 것이 중요합니다.
- **비용 고려 사항**
  - 규정 준수나 중요한 데이터의 경우에는 _수집_을, 신선도가 요구되는 경우에는 _연합_을 결합하여 총 비용과 성능을 평가합니다.
  - _수집_과 _연합_을 혼합할 때 I/O 및 계산 분포를 고려합니다. 소스 시스템에 대한 반복 쿼리의 계산 비용을 줄이려면 읽기 빈도가 높고 자주 액세스하는 연합 데이터 집합에 캐싱(Accelerated Query)을 사용합니다.
  - 이 규칙을 사용하여 수집과 연합 중 무엇을 선택할지 결정하세요. 데이터가 자주 액세스되지만 자주 변경되지 않는 경우 일반적으로 _Accelerated Query_가 더 비용 효율적입니다. 그러나 데이터가 자주 변경되는 경우(액세스 빈도와 관련하여) _실시간 쿼리_ 또는 _복사_가 더 적합합니다. 다음은 몇 가지 비용 예시입니다.
    - **가속화가 유리한 경우:** 100만 개의 레코드로 구성되고 매일 약 1만 건이 변경되어 업데이트되는 대시보드는 하루에 20회 조회됩니다. _가속화_ 비용은 약 600 크레딧/월이며, _Live Queries_의 경우 약 4,200 크레딧/월입니다.
    - **Live Query가 유리한 경우:** 30분마다 변경되는 데이터를 사용하여 하루에 20번 게시되는 세그먼트입니다. _Live Queries_ 비용은 이 새로 고침 주기에서 약 4,200 크레딧/월이며, _가속화_의 경우 약 28,800 크레딧/월입니다.

## 사례 결정 가이드 사용

이 논리를 적용하는 방법을 설명하는 몇 가지 일반적인 아키타입을 자세히 살펴보겠습니다.

- **"단일 진실의 원천" 아키타입: 중앙 집중화 및 거버넌스**
  - **시나리오:** 전체 글로벌 기업에 대해 규정 준수 및 통합된 _Customer 360_ 프로필을 작성해야 합니다. 데이터는 수십 개의 다른 시스템에서 제공되며, 엄격한 _GDPR_ 및 _CCPA_ 규정을 준수해야 하며 모든 마케팅 및 서비스 상호 작용에 대한 진실의 원천이 될 것입니다.
  - **권장 패턴:** **데이터 수집.** 여기서 우선 순위는 거버넌스, 신뢰 및 통제입니다. 데이터를 _Data 360_에 수집하면 소스 시스템과 분리된 완전히 감사 가능한 정규 프로필을 만들 수 있습니다.
- **"실시간 인사이트" 아키타입: 이동하지 않고 분석**
  - **시나리오:** 데이터 과학 팀은 _Snowflake_의 거대한 트랜잭션 테이블에서 탐색적 쿼리를 실행해야 합니다. 동시에 경영진 팀은 동일한 데이터로 구동되는 실시간 _BI_ 대시보드를 원합니다. 매일 페타바이트의 데이터를 이동하는 작업은 느리고 비싸습니다.
  - **권장 패턴:** **Zero Copy Federation.** 우선 순위는 속도, 민첩성, 대규모 환경에서의 비용 효율성입니다. _Zero Copy를 사용하면_ 데이터 중복의 오버헤드와 지연 없이 기존 데이터 웨어하우스의 잠재력을 실시간 쿼리에 활용할 수 있습니다.
- **"하이브리드 인텔리전스" 아키타입: 핵심에 거버넌스를 적용하고, 엣지를 연합합니다.**
  - **시나리오:** 데이터 레이크에서 실시간 동작 신호(예: 웹 사이트 클릭)를 사용하여 관리 및 수집된 고객 프로필을 보강하려는 경우 핵심 프로필의 안정성과 실시간 데이터의 즉시성이 모두 필요합니다. 즉각적인 개인화를 실현하려면 두 요소가 모두 중요합니다.
  - **권장 패턴:** **하이브리드 접근법.** _데이터 수집_을 사용하여 고객 데이터에 대한 안정적이고 거버넌스가 적용된 핵심을 만듭니다. _Zero Copy_를 사용하여 변동성이 큰 실시간 "엣지" 데이터를 연합한 다음, 쿼리 시점에 결합하여 완전하고 최신의 보기를 제공합니다.

## 앞으로의 경로

엔터프라이즈 데이터 전략은 더 이상 단일 통합 패턴 선택에 중점을 두지 않으며, 상호 운용 가능한 데이터 에코시스템 내에서 제어된 유연성을 설계하는 것입니다. 올바른 접근 방식은 각 소스 시스템을 최신성, 거버넌스, 비용, 액세스 요구 사항에 가장 적합한 패턴으로 매핑합니다.

- 규제된 미션 크리티컬 데이터 집합을 Salesforce _Data Cloud_에 수집하여 규정 준수, ID 확인 및 운영 워크플로를 수행합니다.
- 스토리지 중복 없이 실시간, 탐색적, AI 기반 분석을 위해 _Zero Copy_를 통해 데이터를 연합합니다.
- 쿼리 빈도가 높고 데이터 변경 빈도가 낮을 경우 소스 시스템 로드 및 크레딧 소비를 줄이기 위해 _캐싱(Accelerated Query)_ 적용

Salesforce _Data 360_ on _Hyperforce_는 다중 지역의 복원력과 확장성을 제공합니다. _Iceberg_ 테이블을 갖춘 개방형 호수 하우스는 _Snowflake_, _Databricks_ 및 _S3 Iceberg와 같은 플랫폼과 컴퓨팅 분리 및 상호 운용성을 가능하게 하며, 이는_ 진정으로 상호 운용 가능한 멀티 클라우드 데이터 에코시스템의 기둥입니다.

데이터 생태계가 발전함에 따라 아키텍처의 민첩성을 유지하려면 신선성, 비용, 성능, 규정 준수의 균형을 지속적으로 맞춰야 합니다. 그래서 수집되고 관리된 데이터를 연합 액세스와 통합하여 플랫폼을 미래에도 대비할 수 있도록 하는 것이 중요합니다. 이를 통해 클라우드, 지역, 비즈니스 도메인 전반에서 실시간 인텔리전스, AI 활성화, 엔터프라이즈 규모의 개인화가 가능합니다.

모든 규모를 충족하는 솔루션은 대부분의 비즈니스에 적합하지 않습니다. 최적의 전략은 올바른 패턴을 올바른 비즈니스 동인에 매핑합니다.

## 작성자 정보

**Yugandhar Bora**는 데이터 및 인텔리전스 애플리케이션 플랫폼 내의 데이터 아키텍처를 전문으로 하는 Salesforce의 소프트웨어 엔지니어링 아키텍트입니다. 그는 데이터 거버넌스 및 통합 데이터 모델에 초점을 맞춘 _엔터프라이즈 아키텍처 검토 위원회(EARB)_ 이니셔티브를 이끌고 있으며, 자동화된 플랫폼 프로비저닝 솔루션에도 기여합니다.

**Jan Fernando**는 2012년 Salesforce에 합류한 Salesforce의 _최고 아키텍트 사무실(OCA)_의 수석 아키텍트입니다. 그는 스타트업 생태계에서의 풍부한 경험을 가지고 있습니다. OCA에 합류하기 전에 그는 _플랫폼_ 조직에서 10년 이상 근무했으며, 여기에서 몇 가지 핵심 기술 전환을 이끌었습니다.

<!-- document id=fb39384cb8e51e29543cbe8a68ad49705c893dcd24100e78d143b717e876a2b0 url=/architect/current/ko-kr/decision-guides/guides/data-360-provisioning.md -->

# Data 360 프로비저닝

Salesforce Data 360은 [Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/)에 구축된 데이터 플랫폼으로 모든 고객이나 계정에 대한 명확하고 완전하며 신뢰할 수 있는 360도 보기로 Salesforce 및 외부 데이터를 통합합니다.

기업은 병합 및 인수, 지역 운영, 기능적 분리 또는 과거 이유로 여러 Salesforce 조직을 운영하는 경우가 많습니다. 아키텍트는 Data 360에 대해 여러 가지 결정을 내려야 하며, 이 모든 결정은 거버넌스, 규정 준수, 비용, 대기 시간, 조직의 AI 및 교차 조직 플랫폼 기능 확장 능력에 영향을 미칩니다.

## 가이드 개요

이 가이드는 Data 360을 사용하여 프로비저닝 결정을 내릴 수 있는 프레임워크를 제공합니다. 이러한 결정에는 다음이 포함됩니다.

- 단일 홈 조직과 다중 조직 구성 비교 선택

- 여러 독립 Data 360 인스턴스 프로비저닝

  - Data Cloud One을 사용하여 단일 인스턴스 아래에서 조직 통합

  - Data 360 조직 간 데이터 공유를 사용하는 독립 Data 360 인스턴스 간 공동 작업

Data 360은 Data 360 라이선스를 받은 프로덕션 조직에서 자동으로 프로비저닝됩니다. Data Cloud One은 단일 홈 조직에서 Data 360 인스턴스를 호스팅할 수 있는 Salesforce의 다중 조직 연결 아키텍처이며, 다른 Salesforce 조직은 동료 조직으로 연결됩니다. Data 360 라이선스를 보유하고, 따라서 Data 360 홈 조직이 되는 조직 선택은 장기적인 영향을 미치는 중요한 아키텍처 결정입니다.

Salesforce Data 360을 프로비저닝하는 방법은 기본적인 아키텍처 결정입니다. 이는 엔터프라이즈에서 고객 데이터를 통합하고, 거버넌스를 적용하고, 조직 전체에서 중요한 플랫폼 기능(특히 AI, Agentforce, 분석)을 활성화하는 방법을 결정합니다. 단일 Data 360에 조직 클러스터를 고정하면 통합 데이터 모델, 중앙 집중식 거버넌스, 엔터프라이즈 전체 AI 준비가 가능합니다. 동반 조직은 데이터가 로컬인 것처럼 공유 메타데이터 및 기능에 액세스할 수 있습니다. 반대로 여러 개의 독립 Data 360 인스턴스는 규제, 규정 준수 또는 자율성 요구 사항으로 인해 중앙 집중화를 방지하는 경우 적절합니다. Data 360 조직 간에 데이터를 공유하면 해당 인스턴스 간에 선택적이고 복사 없는 협업이 가능합니다.

이 결정은 데이터 거버넌스를 제어하는 사람, 데이터가 있는 위치, 플랫폼 기능이 활성화되는 방식, 향후 통합 및 AI 이니셔티브의 원활한 확장에 영향을 미칩니다. 현재 Data 360을 사용하지 않는 조직의 경우에도 향후 Data 360 액세스를 추가하기 위한 전략을 개발하여 아키텍처를 향후 지원하는 것이 중요할 수 있습니다. 세일즈, 서비스, 마케팅, 상거래, 산업, Agentforce 전반의 Salesforce 기능이 Data 360에 구축되고 있습니다. 이러한 플랫폼 기능을 사용하려는 조직은 자체 Data 360을 프로비저닝하거나 동반 조직으로 공유 Data 360에 연결해야 합니다.

이 가이드는 아키텍트가 단순성, 엔터프라이즈 전체 일관성, 규정 준수 및 확장성의 균형을 맞추는 프로비저닝 전략을 설계하는 데 도움이 되어, 조직이 Data 360을 Customer 360, AI, 크로스 플랫폼 혁신을 위해 확신을 가지고 활용할 수 있도록 합니다. 이 가이드를 사용하여 Data 360이 필요한 조직과 Data Cloud One 또는 Data 360 조직 간 데이터 공유를 사용할지 여부를 결정합니다. 이 전략은 Data 360 중심의 미래를 위한 확실한 기반을 마련합니다.

## 범위 내 제품

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/data360-logo.png" alt="Salesforce Platform 로고"></td>
      <td>Salesforce Data 360은 모든 소스(CRM, 웹, 모바일 또는 외부 데이터 레이크)의 데이터를 실행 가능한 단일 고객 프로필에 조화롭게 통합하는 Salesforce의 실시간 하이퍼스케일 데이터 플랫폼입니다. <a href="https://www.salesforce.com/products/what-is-customer-360/">Customer 360</a> 플랫폼의 중요한 구성 요소로서 영업, 서비스, 마케팅 전반에서 AI, 분석, 맞춤형 환경을 지원합니다.</td>
    </tr>
  </tbody>
</table>

## 서비스

- **각 조직은 Data 360 인스턴스에 대한 액세스를 계획해야 합니다.** 각 조직은 Data 360 홈 조직을 호스트하거나 Data Cloud One을 통해 연결된 동료 조직이어야 합니다.

- **조직별이 아닌 엔터프라이즈 전체를 생각하십시오.** 일방적이고 개별 비즈니스 부문에서 독단적으로 내리는 결정을 피하십시오. 이상적으로 엔터프라이즈 아키텍처 또는 데이터 거버넌스 위원회는 프로비저닝 전략을 집합적으로 결정해야 합니다. 항상 광범위한 통합 데이터 집합에 의존하는 향후 AI 및 분석 요구를 예측하십시오.

- **지배 및 소유권을 조기에 계획하십시오.** Data 360을 중앙 집중식(Center of Excellence 모델)으로 관리할지 아니면 사업부에 위임할지 결정합니다. 관리자, 보안 팀, 규정 준수 리드에 대한 역할을 정의합니다. 명확하지 않은 소유권은 문제가 될 수 있으므로 모호하지 않아야 합니다.

- **프로비저닝은 라이센스에 연결됩니다.** Data 360 라이센스를 구매한 조직에 따라 Data 360이 프로비저닝되는 위치가 결정되고 해당 조직의 위치에 따라 지역이 결정됩니다.

- **데이터 소스 지원 고려 사항을 이해합니다.** 여러 퍼블릭 클라우드와 제로 카피 데이터 소스별로 지원되는 지역을 반드시 유의하세요. 또한 해당 데이터 소스에 연결하기 위해 보안 조치에 비공개 연결이 필요한지 여부와 지역 내 또는 지역 간 연결이 지원되는지 여부를 결정합니다.

- **단일 조직인지 다중 조직인지에 따라 프로비저닝하세요.** 단일 조직 고객의 경우, 가장 빠르게 가치를 실현하려면 기존 프로덕션 조직에서 Data 360을 프로비저닝하세요. 다중 조직 고객의 경우, 가능한 한 최소한의 Data 360 인스턴스를 생성하여 복잡성을 최소화하세요. 이상적으로는 Data Cloud One 구성을 사용하세요.

- 필요한 경우에만 **다중 Data 360 인스턴스를 **사용**합니다.** 다중 인스턴스는 규정 준수, 보존 또는 조직적 자율성이 요구하는 경우에만 사용해야 합니다. 이러한 경우, Data 360 조직 간 [데이터 공유](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5)를 사용하여 안전하게 협업하세요.

- **Data 360 조직 간 데이터 공유는 협업을 위해 설정하고, 사용자 정의 ETL 파이프라인 용도로는 사용하지 마세요.** 데이터 공유를 통해 특정 개체(DMO, 계산된 인사이트, 세그먼트)를 공유합니다. 태그는 공유되지 않으며, 사용량은 소스 조직에 청구됩니다.

- **단기적인 편법을 피하세요.** 장기 계획 없이 개념 증명(POC)을 위해 여러 Data 360 조직을 생성하지 마세요. 파일럿 및 초기 배포를 엔터프라이즈 전체 프로비저닝 전략에 맞추세요.

## 결정 지점

이러한 전반적인 고려 사항에 따라 모든 프로비저닝 결정(Data Cloud One, Data 360 조직 간 데이터 공유, 또는 홈 조직 지정 중 선택)을 평가하세요.

<table>
  <tr>
    <th>고려 사항</th>
    <th>중요한 이유</th>
    <th>예시 시나리오</th>
  </tr>
  <tr>
    <td>데이터 보존 및 규정 준수</td>
    <td>데이터가 저장되고 처리되는 위치를 결정합니다. 규제 규칙에는 특정 지역 또는 여러 인스턴스가 필요할 수 있습니다.</td>
    <td>글로벌 은행은 GDPR 준수를 위해 프랑크푸르트에 위치한 Salesforce 조직에서 Data 360 테넌트를 프로비저닝합니다. 미국 사업부를 위해 버지니아에 위치한 조직에서 또 다른 테넌트를 프로비저닝합니다.</td>
  </tr>
  <tr>
    <td>거버넌스와 보안</td>
    <td>정책 관리 및 위임 전략 등 Data 360의 관리자 및 소유권을 식별합니다.</td>
    <td>중앙 IT가 강력한 다국적 기업은 센터 오브 엑설런스에서 관리하는 전용 홈 조직을 만듭니다.</td>
  </tr>
  <tr>
    <td>자율성 대 중앙집중화</td>
    <td>각 리더가 데이터의 별도의 소유권을 원할 수 있습니다. 자율성은 여러 Data 360 조직을 선호합니다. 중앙집중화는 Data Cloud One을 선호합니다.</td>
    <td>독립 자회사가 있는 지주회사는 각 BU가 자체적으로 Data 360을 운영할 수 있도록 허용합니다.</td>
  </tr>
  <tr>
    <td>대기 시간 및 성능</td>
    <td>특히 지역 전반에서 Data 360 테넌트에 연결된 동반 조직의 쿼리 속도와 환경에 영향을 미칩니다.</td>
    <td>미국의 Data 360 테넌트에서 데이터를 쿼리하는 런던의 세일즈 팀은 대기 시간이 더 길어질 수 있습니다.</td>
  </tr>
  <tr>
    <td>통합 복잡성</td>
    <td>더 많은 Data 360 테넌트 = 더 많은 파이프라인, API, 미들웨어. 통합이 간소화됩니다.</td>
    <td>소매업체는 Data Cloud One 구성으로 통합하여 10개의 ETL 파이프라인을 구축하지 않도록 합니다.</td>
  </tr>
  <tr>
    <td>제로 카피 데이터 소스 영역</td>
    <td>일부 커넥터에 대한 지역 간 액세스 요구 사항은 Data 360 조직의 지역 또는 위치를 제한할 수 있습니다.</td>
    <td>회사에 AWS eu-west-1 지역에 Snowflake 인스턴스가 있는 경우 Zero Copy를 사용하여 해당 지역의 Data 360에 데이터를 연합할 수 있지만, Zero Copy를 사용하여 미국 지역의 Data 360에 연합할 수는 없습니다.</td>
  </tr>
  <tr>
    <td>비공개 Connect 지역 간 호환성</td>
    <td>경우에 따라 비공개 Connect 지원은 데이터 소스가 Data 360 테넌트와 동일한 지역에 있는지 여부에 따라 달라집니다.</td>
    <td>회사에 aws-east-1 지역에 0-copy를 통해 Data 360에 연결하려는 Snowflake 인스턴스가 있는 경우 Data 360 홈 조직이 동일한 영역에 있는 경우에만 비공개 연결 네트워크 연결을 설정할 수 있습니다.</td>
  </tr>
  <tr>
    <td>비용 및 라이센스</td>
    <td>각 Data 360 테넌트는 비용을 추가합니다. 더 적은 인스턴스로 통합하면 지출이 최적화됩니다.</td>
    <td>헬스케어 제공자는 여러 개의 독립적인 Data 360 인스턴스 대신 Data Cloud One을 채택하여 라이센스 비용을 절감합니다.</td>
  </tr>
  <tr>
    <td>향후 확장성</td>
    <td>오늘의 프로비저닝 선택 항목은 성장의 기반을 설정합니다.</td>
    <td>SaaS 회사는 단일 Data 360 인스턴스로 시작하지만 Salesforce 조직의 자회사를 확보할 때 Data Cloud One으로 확장할 계획입니다.</td>
  </tr>
  <tr>
    <td>엔터프라이즈 전체 AI 준비</td>
    <td>AI 기능 및 Agentforce 모든 조직에 연결된 Data 360 테넌트가 필요합니다. 프로비저닝 결정은 기업 전반에서 AI 모델이 훈련되고 활성화되는 방식에 영향을 미칩니다.</td>
    <td>금융 서비스 회사는 Data Cloud One에서 데이터를 통합하여 Einstein AI 모델이 엔터프라이즈 전체 고객 데이터에 액세스할 수 있도록 합니다.</td>
  </tr>
</table>

## 사용 사례

Data 360 프로비저닝에 대한 결정이 필요한 세 가지 주요 사용 사례가 있습니다.

- 홈 조직 선택
- 다중 조직 전략 적용
- Data 360 조직 간 데이터 공유

### 홈 조직 선택

Data 360 라이센스를 구매하면 해당 라이센스와 연결된 Salesforce 조직에서 Data 360 인스턴스가 프로비저닝됩니다. 이 조직을 Data 360 홈 조직이라고 합니다. 홈 조직은 Data 360 인스턴스의 앵커입니다. 여기에는 다음이 포함됩니다.

- Data 360 저장소 및 컴퓨팅 관리(프로비저닝 시 선택된 영역)

- 관리, 거버넌스 및 보안 정책의 적용

- 데이터 수집, 조합, ID 확인, 세분화 및 활성화 성능

다중 조직 시나리오에서 홈 조직은 다른 Salesforce "공동" 조직의 중앙 Data 360 인스턴스를 관리합니다.

**홈 조직:**

- Data 360 인스턴스의 지리적 위치를 결정합니다.

- Data 360 인스턴스를 소유하고 관리하는 사람을 결정합니다. Data 360 홈 조직의 관리자는 Data 360에 수집된 모든 데이터에 액세스할 수 있습니다.

- Data Cloud One 구성에서 동료 조직 연결을 제어합니다.

- 엔터프라이즈 데이터 전략의 기반을 설정합니다. 나중에 변경하면 어려움과 혼란을 초래할 수 있습니다.

Data 360 홈 조직에 대한 자세한 내용은 [Data 360 통합 패턴 및 관행](/docs/architect/ko-kr/fundamentals/guide/data360_integration_patterns_and_practices)을 참조하십시오.

#### 결정: 홈 조직으로 기존 조직을 사용할지, 새 조직을 사용할지?

첫 번째 주요 결정은 기존 프로덕션 조직에서 Data 360을 프로비저닝할지 아니면 홈 조직 역할을 할 새 전용 조직을 만드는지 여부입니다.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data 360 Existing_Org_vs_New_Dedicated_Org.png" alt="기존 조직과 새 조직을 홈 조직으로 표시하는 결정 다이어그램" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**옵션 A: 기존 조직에서 Data 360 프로비저닝**

**가장 적합한 경우:** 단일 Salesforce 조직이 있는 고객 또는 대부분의 비즈니스 프로세스가 실행되는 중앙 집중식 주요 조직이 이미 있는 다중 조직 고객

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_an_existing.png" alt="기존 조직에서 Data 360 프로비저닝을 보여주는 다이어그램" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **점:**

  - 가장 간단한 경로: CRM 데이터가 있는 위치에서 Data 360이 프로비저닝됩니다.

  - 로컬 세일즈, 서비스, 마케팅 데이터에 즉시 액세스합니다.

  - 추가 통합이 필요하지 않습니다.

  - 관리할 라이센스 및 환경이 더 적습니다.

  - 조기에 채택, 파일럿, 프로덕션 사용 사례를 가속화합니다.

- **점:**

  - 기존 조직의 거버넌스 또는 기술 부채를 상속할 수 있습니다.

  - 단일 "기본 조직"이 없는 경우 하나를 선택하면 소유권 논쟁이 발생할 수 있습니다.

  - 조직의 위치에 따른 성능이므로, 엔터프라이즈 전체의 데이터 거주 요구사항과 일치하지 않을 수 있습니다.

  - 여러 사업부에서 서로 다른 조직을 사용하는 경우 Data Cloud One과 페어링되지 않으면 로컬 프로비저닝이 조각화될 수 있습니다.

**예:**

Salesforce 조직이 하나인 SaaS 회사는 해당 조직에서 Data 360을 프로비저닝하여 고객 구독 및 지원 데이터를 통합합니다.

**옵션 B: 새로운 전용 조직에서 Data 360 프로비저닝**

**가장 적합한 경우:** 단일 주요 조직에 맞출 수 없는 여러 Salesforce 조직이 있는 고객 또는 강력한 CoE(Center of Excellence) 모델이 있는 기업

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_new_dedicated_org.png" alt="새 전용 조직에서 Data 360 프로비저닝을 보여주는 다이어그램" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **점:**

  - 상속된 조직 복잡성 없이 거버넌스를 위한 백지 상태에서 시작할 수 있습니다.

  - 여러 비즈니스 부문에서 중앙 집중식 제어.

  - 규정 준수 요구에 따라 지역을 유연하게 선택할 수 있습니다.

  - 단일 사업부에 연결되지 않은 중립 "공유 서비스" 조직 역할을 합니다.

  - 향후 Data Cloud One 아키텍처(여러 동료 조직이 있는 홈 조직)를 설정합니다.

- **점:**

  - 고객은 Data 360을 프로비저닝할 새 Salesforce 조직에 대한 라이센스를 구매해야 합니다.

  - Data Cloud One 동료 연결을 통해 Data 360에 조직을 연결하는 데 필요한 추가 통합입니다.

  - 관리 오버헤드(사용자 관리, 보안, ID)를 추가할 수 있습니다.

  - 기존 프로덕션 조직의 프로비저닝 대비 가치 실현 시간이 느려집니다.

**예:**

다국적 금융 서비스 회사는 Data 360을 프로비저닝하기 위한 전용 홈 조직을 만듭니다. 모든 사업부 조직(소매, 자산, 상업 은행)은 Data Cloud One을 통해 동료 조직으로 연결됩니다.

**결정 기준**

<table>
  <tr>
    <th>고려 사항</th>
    <th>홈 조직으로 기존 조직(선호하는 기본 옵션)</th>
    <th>홈 조직으로 새 조직(대안)</th>
  </tr>
  <tr>
    <td>단순성</td>
    <td>신속한 설정을 위해 기존 사용자 및 데이터 구조를 기반으로 구축합니다.<br> Data 360은 기본적으로 홈 조직과 통합됩니다.</td>
    <td>새 Salesforce 조직의 라이센스 및 설정과 추가 관리 오버헤드가 있어야만 관리할 수 있습니다.</td>
  </tr>
  <tr>
    <td>시간-가치</td>
    <td>로컬 CRM 데이터 즉각 사용</td>
    <td>느린 도입과 추가 통합이 필요합니다.</td>
  </tr>
  <tr>
    <td>거버넌스</td>
    <td>기존 조직의 기본 관리 모델(기존 사용자 및 권한 집합)을 상속합니다(조직이 이미 중앙에 있는 경우 허용 가능).</td>
    <td>거버넌스를 위한 백지 상태입니다. COE 주도 모델에 적합합니다.</td>
  </tr>
  <tr>
    <td>규정 준수</td>
    <td>기존 조직의 지역에 연결된 주거</td>
    <td>기존 조직과 독립된 지역 선택의 유연성</td>
  </tr>
  <tr>
    <td>성능</td>
    <td>로컬 CRM 쿼리에 대한 최상의 성능</td>
    <td>동료 조직의 연결에 종속되며, 다른 조직과 동일한 지역이든 교차 지역이든</td>
  </tr>
  <tr>
    <td>향후 확장성</td>
    <td>Data Cloud One과 페어링하면 제대로 작동합니다. 잘못된 조직을 선택한 경우 나중에 이동하기 어려움</td>
    <td>Data Cloud One을 사용하여 쉽게 확장할 수 있습니다. 중립성을 위해 설계되었습니다.</td>
  </tr>
  <tr>
    <td>비용</td>
    <td>증분 비용 절감</td>
    <td>추가 환경의 더 높은 오버헤드</td>
  </tr>
</table>

#### 권장 사항

일반적인 원칙으로 기존 주요 조직을 홈 조직으로 사용하여 초기 노력을 최소화하고 채택을 가속화합니다. 장기 거버넌스 또는 규정 준수 전략에 필요한 경우에만 새로운 전용 홈 조직을 만듭니다. 새로운 전용 홈 조직을 만드는 것은 COE(Center of Excellence)를 보유한 대기업의 일반적인 선택입니다.

**단일 조직 환경**

기존 프로덕션 조직에서 Data 360을 프로비저닝합니다. 이렇게 하면 단순성과 즉각적인 가치를 극대화할 수 있습니다. 불필요한 통합 오버헤드를 방지합니다.

**다중 조직 환경**

일반적으로 대부분의 비즈니스가 실행되는 조직 또는 중앙 집중식 CRM 역할을 하는 조직 중 하나를 선택하여 홈 조직 역할을 수행합니다. 이를 통해 복잡성을 줄이고 설정 작업을 최소화하며 Data 360의 가치를 빠르게 실현할 수 있습니다. 기존 주요 조직을 사용하면 새 환경을 관리하는 데 드는 비용과 통합 노력을 피할 수도 있습니다.

**새로운 전용 홈 조직 고려 시기**

홈 조직을 만들면 유연성과 중립성이 제공되지만, 이러한 경우 가치 창출 시간이 느려집니다.

- 조직에 강력한 CoE(Center of Excellence)가 있고 사업부 조직과 별도의 거버넌스를 원하는 경우
- 규정 준수 또는 조직 제약으로 인해 단일 기존 조직이 적합하지 않은 경우

### 다중 조직 전략 적용

#### 다중 조직 챌린지

기업들은 종종 여러 Salesforce 조직을 운영하며, 이는 예외적인 경우가 아니라 보편적인 현상입니다. 2024년 2월 현재 약 19,000명의 Salesforce 고객이 둘 이상의 Salesforce 조직을 운영하고 있습니다.

발생하는 이유는 무엇입니까?

- **인수 및 합병:** 새로 인수한 회사는 자체 Salesforce 인스턴스를 가져옵니다.
- **지역 운영:** 데이터 보존 법을 충족하기 위해 EU, 북미, 아시아 태평양 등에 대한 조직을 구분합니다.
- **기능적 분리:** 다양한 사업부(예: Retail Banking, Wealth Management, Insurance)는 자율성을 위해 자체 조직을 유지합니다.
- **규제 또는 보안 차단:** 특정 산업에서는 규정 준수 이유로 논리적으로 구분된 조직을 요구합니다.
- **기존적 또는 기술적 이유:** 시간이 지남에 따라 고객은 여러 조직을 자연스럽게 누적합니다.

각 이유는 개별적으로 타당하지만, 함께 작용하면 데이터가 파편화됩니다. 통합 레이어가 없으면 각 조직은 고객에 대한 일부 정보만을 보유하게 됩니다.

아키텍처 문제: 규정 준수, 거버넌스, 자율성 요구 사항을 존중하면서 조직 전반의 데이터를 신뢰할 수 있는 단일 소스로 통합하는 방법은 무엇입니까?

---

#### Data Cloud One

Data Cloud One은 여러 Salesforce 조직이 단일 Data 360 인스턴스를 공유할 수 있는 Salesforce의 다중 조직 연결 아키텍처입니다. Salesforce 조직이 여러 개 있는 기업에 권장되는 패턴입니다.

Data Cloud One 클러스터에서 하나의 Salesforce 조직이 Data 360 인스턴스를 호스팅하는 홈 조직으로 지정됩니다. 다른 Salesforce 조직은 동반 조직으로 연결되어 홈 조직의 Data 360에서 통합된 데이터 및 메타데이터를 사용합니다.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies Data 360 DC One.png" alt="Data Cloud One 아키텍처를 보여주는 다이어그램" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**Data Cloud One의 작동 방식**

- **데이터 수집 및 통합(홈 조직)**

  - 모든 데이터 수집 구성(Salesforce CRM, 외부 소스, 스트리밍, 배치)은 홈 조직에서만 수행됩니다.

  - 홈 조직과 연결된 Data 360 테넌트는 신원 확인, 조정, 모델링 및 신뢰할 수 있는 고객 프로필로의 통합을 수행합니다.

  - Data 360 관리, 거버넌스 정책, 태그 지정 및 마스킹은 홈 조직에서 중앙 집중식으로 적용됩니다.

- **데이터 공간 아키텍처**

  - 홈 조직에서 데이터는 데이터, 메타데이터, 프로세스에 대한 논리 컨테이너 역할을 하는 데이터 공간으로 구성됩니다.

  - 기업은 브랜드, 지역 또는 비즈니스 부분에 대한 데이터 공간을 만들 수 있습니다.

  - 데이터 공간 공유: 홈 조직에서 특정 데이터 공간이 동료 조직과 선택적으로 공유됩니다. 이렇게 하면 관련 데이터(및 관련 메타데이터)만 올바른 조직에 유입됩니다.

- **메타데이터 공유**

  동료 조직은 데이터 모델 개체(DMO), 통합 프로필 스키마, 계산된 인사이트, 세그먼트 [및 기타](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5)를 포함하여 홈 조직에서 메타데이터 정의를 받습니다. 이는 로컬 자산인 것처럼 동반 조직 내에 기본적으로 표시되지만 홈 조직에 연결되어 있습니다.

- **Capabilities in Home Org vs. 동반 조직**
  기능 액세스는 홈 조직과 동반 조직 간에 다릅니다. 동반 조직은 데이터를 수집하거나 통합할 수 없으며, 수집, 모델링, 통합을 위해 홈 조직에 의존합니다. 동반 조직은 Data 360 데이터에 액세스하여 Data 360 지원 플랫폼 기능을 강화할 수 있으며, 공유되고 신뢰할 수 있는 데이터 위에 로컬 인사이트, 세그먼트, 플로우를 만들 수 있습니다. 향후, 활성화 기능에도 액세스할 수 있습니다.

<table>
  <tr>
    <th>기능</th>
    <th>홈 조직</th>
    <th>동료 조직</th>
  </tr>
  <tr>
    <td>Connect: 커넥터를 구성하고, 데이터 스트림을 만들고, 데이터를 수집하거나 연합하세요.</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>조화 및 통합: 데이터 변환 및 ID 확인을 구축하고 실행하세요.</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>데이터 공간 및 권한으로 보안 데이터 관리</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>세그먼트 및 예측 세그먼트, 인사이트 구축 및 Einstein Studio 모델 만들기</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Everywhere 활성화, 데이터 작업 활성화</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>플랫폼 기능: 프롬프트 빌더, 플로, 보고서, 보강 [기타](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&amp;type=5)</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Data 360 지원 기능: Prospecting Center, Sales 및 Service Cloud 기능, Agentforce, 기타</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
</table>

- **플랫폼 기능 동등성**
  사용자 및 빌더의 관점에서 메타데이터가 공유되면 Salesforce 플랫폼 기능 사용과 관련하여 홈 조직과 동반 조직 간에 몇 가지 기능 차이가 있습니다. 지원되는 기능 목록은 [Companion 조직의 Data 360 기능](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5)에서 확인할 수 있습니다.

  - 플로우, 보고서, 프롬프트 빌더, 대시보드 및 기타 플랫폼 네이티브 도구와 같은 Salesforce 플랫폼 기능은 메타데이터를 사용할 수 있으면 홈 조직과 동반 조직 모두에서 작동합니다.

  - Agentforce, Prospecting Center, Sales Cloud Einstein 기능 및 Service Cloud AI 기능과 같은 Data 360 지원 기능도 홈 조직과 동반 조직에서 원활하게 작동합니다. 일부 기능은 완전한 호환성에 도달할 수 있지만, 전반적인 목표는 Data 360에 의존하는 모든 클라우드 간 기능에 대해 홈 조직과 동반 조직 간의 기능 동등성을 달성하는 것입니다.

- **소비 모델**
  모든 동반 조직 활동(쿼리, 세그먼트 실행, Data 360 트리거 플로우, AI 사용, Einstein Trust Layer 로깅 등)은 홈 조직에서 Data 360 크레딧을 사용합니다. 소비는 한 방향으로만 흐릅니다. 크레딧은 홈 조직의 크레딧 할당에 대해 중앙에서 관리되고, 청구 및 추적됩니다. 그러나 Digital Wallet에서 각 개별 조직이 사용한 크레딧 수를 자세히 살펴볼 수 있습니다.
- **설계 원리: 수평 구조**
  Data 360의 가로 구조는 주로 Data Cloud One을 통해 구현되는 기본 설계 원칙으로, 단일 Data Cloud 인스턴스가 여러 고유한 Salesforce CRM 조직에 걸쳐 적용되도록 합니다. 새롭게 릴리스된 모든 기능이 추가 설정 없이 홈 조직과 동반 조직 모두에서 작동하는 것이 목표입니다. 이 기능은 Data Cloud One이 단순한 데이터 아키텍처 선택이 아니라 앞으로 Salesforce 플랫폼의 기본 요소가 되도록 보장합니다.

---

#### 결정: 다중 데이터 조직 및 공유 데이터 360(Data Cloud One) 비교

조직이 여러 개인 기업은 생태계 내에서 Data 360을 배치할 방법과 위치를 선택해야 합니다. 각 조직에서 독립 Data 360 조직을 프로비저닝하거나 Data Cloud One을 사용하여 단일 홈 조직 아래에서 조직을 통합하려고 합니까?

**옵션 A: 여러 개의 독립 Data 360 조직**

각 Salesforce 조직은 자체 Data 360 인스턴스를 프로비저닝합니다.

**점:**

- **자율성:** 각 사업부 또는 지역은 자체 Data 360을 제어합니다.

- **각 조직의 단순성:** 거버넌스, 보안, 그리고 사용자 정의는 각 조직에서 관리됩니다.

- **규제 준수:** 엄격한 규제 구분이 필요한 경우 유용합니다(예: 데이터가 국경을 넘지 않아야 함).

**점:**

- **데이터 사일로:** 통합 프로필은 조직 전체에서 사용할 수 없습니다.

- **고비:** 각 인스턴스에는 라이센스, 관리, 통합이 필요합니다. 고객은 결국 여러 조직에서 동일한 소스 데이터를 여러 번 수집합니다.

- **중복 작업:** ID 확인, 세분화, 보강은 각 Data 360 인스턴스에서 반복해야 합니다.

**옵션 B: One Shared Data 360(Data Cloud One Cluster)**

단일 Data 360은 홈 조직에서 프로비저닝되며 다른 Salesforce 조직은 동반 조직으로 연결됩니다.

**점:**

- **단일 진실 소스(SSOT):** 모든 조직은 통합 데이터 모델을 공유합니다.

- **비용 효율:** 하나의 Data 360 라이센스 및 인프라만 관리합니다.

- **통합 관리:** 중앙 집중식으로 적용되는 정책, 보안, 규정 준수 제어.

- **Cross-org 보강:** 동료 조직 전반에서 조화된 프로필, 인사이트, 세그먼트에 액세스합니다.

- **AI 준비도:** 엔터프라이즈 전체 데이터 집합을 사용하면 AI 모델의 교육 및 활성화를 향상할 수 있습니다.

- **미래 대비:** 새 Data 360 조직이 필요하지 않으므로 새 동반 조직을 추가하기가 간단합니다.

**점:**

- **추가 준비:** 하나의 Data 360은 조직과 홈 조직 간 연결을 위한 계획이 필요합니다.

- **지연 시간 고려 사항:** 다른 지역의 동료 조직은 더 느린 쿼리를 볼 수 있습니다.

- **복잡한 거버넌스:** 각 조직마다 서로 다른 사용자 정의 요구 사항이 있을 경우, 세분화된 거버넌스가 복잡해질 수 있습니다.

**옵션 C: 여러 Data Cloud One 클러스터**

**경우에 따라** 거버넌스, 컴플라이언스 또는 기타 비즈니스 요구 사항 때문에 모든 조직을 함께 클러스터링하는 것이 비실용적일 수 있습니다. 이로 인해 각기 다른 동료 조직 클러스터의 홈 조직 역할을 하는 여러 Data 360 조직을 운영하는 하이브리드 솔루션을 구현해야 할 수도 있습니다.

**예:**

다국적 기업은 유럽, 미국, 아시아 등 다양한 지역에 Salesforce 조직을 보유하고 있습니다. 지역 데이터 거주 규정을 준수하기 위해 각 별도의 지역에 대해 하나의 Data 360을 프로비저닝합니다.

**결정 기준**

<table>
  <tr>
    <th>고려 사항</th>
    <th>여러 독립 Data 360 조직</th>
    <th>하나의 공유 데이터 360(Data Cloud One)</th>
  </tr>
  <tr>
    <td>자동</td>
    <td>각 조직 또는 사업부에 대한 높은 자율성</td>
    <td>중앙 집중화된 거버넌스로 인해 조직당 자율성이 줄어듭니다.</td>
  </tr>
  <tr>
    <td>규정 준수</td>
    <td>엄격한 구분이 필요한 경우 유용합니다(예: 지역 법률).</td>
    <td>중앙 집중화를 허용하는 경우 가장 적합합니다.</td>
  </tr>
  <tr>
    <td>비용</td>
    <td>더 높은 라이센스 및 관리 비용</td>
    <td>비용 효율성이 높아지며, 여러 조직에 대해 하나의 라이센스를 사용합니다.</td>
  </tr>
  <tr>
    <td>거버넌스</td>
    <td>조각화됨, 정책은 조직마다 다름</td>
    <td>조직 전체에서 중앙 집중화된 일관된 정책</td>
  </tr>
  <tr>
    <td>데이터 분산</td>
    <td>각 조직은 고유한 뷰를 가지며, 엔터프라이즈 360은 제공되지 않습니다.</td>
    <td>통합 데이터 집합, 중복 없음</td>
  </tr>
  <tr>
    <td>AI/Analytics</td>
    <td>각 조직의 데이터로 제한</td>
    <td>엔터프라이즈 전체 모델로서 더 높은 정확도를 제공합니다.</td>
  </tr>
  <tr>
    <td>복잡성</td>
    <td>관리할 인스턴스가 더 많고, 통합도 더 많습니다.</td>
    <td>더 단순한 아키텍처, 더 적은 이동 부품 수</td>
  </tr>
  <tr>
    <td>성능</td>
    <td>조직 내 사용 사례에 가장 적합합니다.</td>
    <td>동료 조직 액세스를 통한 잠재적인 대기 시간 증가</td>
  </tr>
</table>

---

#### 권장 사항

**권장 패턴: Data Cloud One**

다중 조직 기업에서 거버넌스를 간소화하고 비용을 최적화하려면, 연결된 동료 조직이 있는 단일 홈 조직을 사용하십시오.

**다중 Data 360 조직을 사용하는 경우:** 규정에 따라 유럽의 운영이 미국의 운영과 완전히 분리되어야 하는 경우 등 규정 준수, 보존 또는 조직 자율성이 엄격하게 요구하는 경우에만 여러 Data 360 조직을 사용합니다.

**Data Cloud One에서 홈 조직을 선택하는 방법:** 먼저 대부분의 비즈니스가 운영되는 주요 조직 중 하나를 고려합니다. 해당 조직에서 Data 360을 프로비저닝하면 복잡성을 최소화하고 초기에 가치를 극대화할 수 있습니다.

기존 조직이 적합하지 않은 경우에만 COE 팀이 관리하는 전용 홈 조직을 만드는 것이 좋습니다.

**일반 원칙:**

다중 조직 환경에서는 Data 360 조직의 수를 최소화합니다. Data Cloud One을 기본 패턴으로 추천하여 중복을 줄이고, AI 준비를 활성화하고, 거버넌스를 간소화합니다.

### Data 360 조직 간 데이터 공유

#### 데이터 공유 필요

Data Cloud One은 대부분의 엔터프라이즈에 권장되는 접근 방식이지만 다음을 포함하여 고객이 여러 Data 360 인스턴스를 프로비저닝해야 하는 시나리오가 있습니다.

- **지역 규정 준수.** 다국적 소매업체는 EU 및 미국에서 Data 360을 하나씩 프로비저닝합니다. Data 360 간 데이터 공유를 통해 회사는 현지 데이터로부터 인사이트를 도출한 후, 해당 인사이트를 미국 본사와 공유할 수 있습니다.
- **비즈니스 단위 협업.** 대기업은 리테일과 보험 부문별로 별도의 Data 360 조직을 운영합니다. Data 360 조직 간 데이터 공유를 통해 사용자는 데이터 이동이나 복사 없이 단일의 신뢰할 수 있는 데이터 소스에 접근할 수 있습니다. Data 360 조직 간 데이터 공유를 통해 보험 조직은 표적 교차 판매 캠페인을 위해 리테일의 "고가치 고객" 세그먼트를 받습니다.
- **병합 및 인수.** 모회사가 자체 Data 360을 보유한 자회사를 인수할 경우, 두 개의 인스턴스를 관리해야 하므로 단기간 데이터 사일로를 유지하는 것이 데이터 보안과 SSOT(단일 진실의 원천) 무결성을 보존하는 데 도움이 됩니다. 동시에 두 Data 360 인스턴스 간에 데이터를 공유하면 전환 중에 필요한 공동 작업을 수행할 수 있습니다.
- **연합 경영진 대시보드.** 여러 대륙에 걸쳐 활동하는 다국적 기업은 지역마다 개별 Data 360 조직을 프로비저닝합니다. 경영진은 연합 분기별 성과 보기를 원합니다. 각 지역의 Data 360은 "경영진 조직"과 집계된 인사이트를 공유하여 전사적 보고를 가능하게 합니다.

#### 데이터 공유 작동 방식

Data 360 조직이 여러 개 있는 경우 통합이 자동으로 이루어지지 않습니다. Data 360에서 Data 360 데이터 공유를 사용하면 고객이 중복 또는 사용자 정의 파이프라인 없이 Data 360 인스턴스 간에 특정 개체를 공유할 수 있습니다. Data 360 조직 전반에서 공동 작업을 위해 고안된 제로 카피 메타데이터 공유 메커니즘입니다.

- 각 Data 360은 자체 홈 조직에서 프로비저닝됩니다.

- 관리자는 공유할 특정 개체들을 그룹화한 데이터 공유를 생성할 수 있습니다.

- 선택한 데이터에 대한 액세스는 대상 조직의 Data 360과 공유되며, 여기에서 개체가 로컬로 정의된 것처럼 표시됩니다. 액세스만 공유되며 기본 데이터는 소스 Data 360에 남아 있습니다.

- 태그는 공유되지 않습니다. 원시 개체만 사용할 수 있으며, 대상 조직은 필요에 따라 관리, 운영 또는 AI 태그를 다시 적용해야 합니다.

#### Data Cloud One의 주요 차이점

- Data Cloud One에서는 여러 동료 조직이 단일 Data 360 인스턴스를 공유합니다. 일관성을 위해 Agentforce, Prospecting Center 및 Tableau Next와 같은 플랫폼 기능은 동일한 기본 데이터에서 실행됩니다.

- Data 360 조직 간 데이터 공유를 사용할 경우 각 조직에 자체 Data 360이 있습니다. 조직 A 및 조직 B의 Agentforce 같은 기능은 각각 로컬 인스턴스에서 독립적으로 작동합니다. 공유는 자동으로 발생하지 않으며, 특정 개체에 대해서만 공동 작업하기 위해 의도한 데이터 공유를 만들어야 합니다.

#### Data 360 조직 간 데이터 공유의 장단점

<table>
  <tr>
    <th>요소</th>
    <th>성과</th>
    <th>단점</th>
  </tr>
  <tr>
    <td>데이터 보존</td>
    <td>공동 작업을 활성화하면서 지역 분리를 지원합니다.</td>
    <td>여러 Data 360 조직을 관리해야 할 필요성이 사라지지 않습니다.</td>
  </tr>
  <tr>
    <td>데이터 중복</td>
    <td>제로 카피, 개체 중복 없음</td>
    <td>각 데이터 공유에 포함할 개체를 의도적으로 선택해야 합니다.</td>
  </tr>
  <tr>
    <td>거버넌스</td>
    <td>공유는 명시적이고 의도적입니다(개체 수준).</td>
    <td>태그나 정책이 전달되지 않으며, 대상 조직은 거버넌스를 다시 적용해야 합니다.</td>
  </tr>
  <tr>
    <td>복잡성</td>
    <td>중앙 집중화 없이 선택적 공동 작업을 활성화합니다.</td>
    <td>여러 Data 360 조직 및 데이터 공유를 관리해야 합니다.</td>
  </tr>
  <tr>
    <td>**AI/Analytics**</td>
    <td>지역별 AI/Analytics가 가능하며, 조직 간에 인사이트를 공유할 수 있습니다.</td>
    <td>데이터가 의도적으로 공유되지 않는 한 엔터프라이즈 전체 AI가 없습니다.</td>
  </tr>
  <tr>
    <td>**플랫폼 기능**</td>
    <td>각 조직의 Data 360 지원 기능은 독립적으로 실행됩니다.</td>
    <td>자동 공유가 없습니다. 주의를 기울이지 않으면 중복 위험이 발생합니다.</td>
  </tr>
  <tr>
    <td>비용</td>
    <td>ETL 파이프라인의 필요성을 줄일 수 있습니다.</td>
    <td>여전히 여러 Data 360 조직의 비용이 부과됩니다. 데이터 쿼리 및 데이터 공유에 대한 크레딧을 사용합니다.</td>
  </tr>
</table>

#### 결정 기준

<table>
  <tr>
    <th>고려 사항</th>
    <th>Data Cloud One(다중 조직의 기본 설정)</th>
    <th>Data 360 조직 간 데이터 공유</th>
  </tr>
  <tr>
    <td>단일 진실의 원천</td>
    <td>예 - 모든 조직이 데이터 모델을 공유합니다.</td>
    <td>아니요 - 각 Data 360에는 자체 데이터 모델이 있습니다.</td>
  </tr>
  <tr>
    <td>규정 준수</td>
    <td>중앙 집중화를 허용하는 경우에만 작동합니다.</td>
    <td>주거 법에서 중앙 집중화를 방지하는 경우 필요합니다.</td>
  </tr>
  <tr>
    <td>거버넌스</td>
    <td>중앙 집중식, 일관적입니다.</td>
    <td>연합, 의도적인 개체 수준 공유.</td>
  </tr>
  <tr>
    <td>복잡성</td>
    <td>구성 요소가 적어져 단순해집니다.</td>
    <td>더 복잡하며, 데이터 공유 구성과 여러 데이터 조직의 관리가 필요합니다.</td>
  </tr>
  <tr>
    <td>AI/Analytics</td>
    <td>엔터프라이즈 전체 AI 모델.</td>
    <td>지역 AI. 선택적으로 인사이트를 공유합니다.</td>
  </tr>
  <tr>
    <td>플랫폼 기능</td>
    <td>공유된 Data 360은 모든 기능이 홈 + 동료에서 일관적으로 작동함을 의미합니다.</td>
    <td>기능은 각 Data 360에서 독립적으로 실행되며, 공유는 명시적이어야 합니다.</td>
  </tr>
</table>

#### 권장 사항

**기업에 여러 Data 360 조직이 있는 경우**

- 사용자 정의 파이프라인을 구축하거나 데이터를 복제하는 대신 Data 360 조직 간 데이터 공유를 사용하여 공동 작업을 수행합니다.

- 데이터 공유를 만들고 대상 조직에 부여하여 특정 개체(DMO, 계산된 인사이트, 세그먼트)를 공유합니다.

- 태그는 공유되지 않으며, 관리, 분류 또는 AI 보강을 위해 수신 조직이 태그를 다시 적용해야 합니다.

**Data 360 조직 간 데이터 공유 사용**

- 중앙 집중화를 방지하는 규제 요구 사항을 충족합니다.

- 선택적 공동 작업을 활성화하면서 사업부 독립성을 유지합니다.

- 여러 지역에 걸쳐 연합 경영진 대시보드를 제공합니다.

- 즉시 통합이 이루어지기 어려운 M&A 시나리오 간의 격차를 해소합니다.

**신중하게 설계하십시오.**

Data 360-to-Data 360 데이터 공유를 Data Cloud One의 대체가 아닌 연합 전략으로 취급합니다.

- 객체별 공유를 사용합니다.
- 과도한 공유를 방지합니다.
- 데이터 공유를 비즈니스 및 규정 준수 요구에 맞춥니다.

#### 기억

Data 360 프로비저닝을 위한 데이터 전략 수립은 조직별이 아닌 전사적 차원의 접근이 필요한 중요한 장기 아키텍처 결정입니다. 이 초기 전략적 선택은 고객 데이터 통합 방식, 거버넌스 시행 방식, 그리고 특히 AI와 분석 등 필수 플랫폼 기능이 조직 전반에 걸쳐 어떻게 확장되는지를 결정합니다. 거버넌스 및 소유권 모델을 사전에 계획하고, 향후 파편화와 복잡성 증가로 이어지는 단기적인 지름길을 피하십시오.

## 자원

[Customer 360이란 무엇입니까?](https://www.salesforce.com/products/what-is-customer-360/)

[Data 360 통합 패턴 및 관행](/docs/architect/ko-kr/fundamentals/guide/data360_integration_patterns_and_practices)

[Data 360 아키텍처](/docs/architect/ko-kr/fundamentals/guide/data-360-architecture)

[Data 360 보안 아키텍처](/docs/architect/ko-kr/fundamentals/guide/data360_security_architecture)

**작성자 정보**

Kunal Goyal은 Data 360 내에서 멀티 조직 아키텍처 및 확장성 향상에 중점을 둔 Salesforce의 제품 관리 디렉터입니다. 2017년부터 교차 조직 공동 작업 및 멀티 테넌트 시스템 설계에 중점을 둔 여러 이니셔티브 및 제품을 이끌었습니다. Kunal은 Data 360 모범 사례 아키텍처 리드 중 한 명이자, Data Cloud One(설정, 프로비저닝 및 관리자 경험) 제품의 책임자입니다.

Erin Wagner Tidwell은 Data 360의 담당 기술 작성자이자 콘텐츠 디자이너입니다. 2013년부터 Salesforce에 근무하고 있으며 명확하고 일관되고 정확한 기술 문서와 앱 내 커뮤니케이션을 통해 Data 360을 더 쉽게 이해하고 사용할 수 있도록 합니다.

Yugandhar Bora는 Salesforce의 소프트웨어 엔지니어링 아키텍트로, 데이터 및 인텔리전스 응용 프로그램 플랫폼 내 데이터 아키텍처를 전문으로 합니다. 그는 데이터 거버넌스 및 통합 데이터 모델에 초점을 맞춘 EARB(Enterprise Architecture Review Board) 이니셔티브를 이끌고 자동화된 플랫폼 프로비저닝 솔루션에 기여합니다.

Samarpan Jain은 Commerce Cloud, 플랫폼 통합, 교차 조직 아키텍처를 전문으로 하는 Salesforce의 주 아키텍처입니다. Salesforce에서 가장 오랫동안 근무한 직원은 정부 고객의 데이터 보존 규정 준수 및 Data 360 사용량 귀속 시스템 등 주요 이니셔티브를 이끌고 있습니다.

<!-- document id=83970a367731a1ce0efa5d59aa42b5570a6cc9c7b37017300fb522b1e1395221 url=/architect/current/ko-kr/decision-guides/guides/async-processing.md -->

# 비동기식 처리

이 가이드를 사용하여 각 사용 사례에 적합한 Salesforce 비동기 처리 접근 방식을 선택합니다.

## 가이드 개요

이 가이드는 Salesforce Platform에서 비동기 처리 요구 사항에 대한 올바른 접근 방식을 평가하는 데 도움이 됩니다. 각 접근 방식을 설명하며 그 강점과 한계를 자세히 전달합니다. 대부분의 접근 방식은 하나의 제품 기능에 기반하지만, 일부 접근 방식은 여러 기능을 조합하여 사용합니다. 가이드에는 각 접근 방식을 사용할 시점을 강조하는 사용 사례가 포함되어 있습니다.

비동기 처리는 아키텍처에 두 가지 주요 혜택을 제공합니다. 먼저 비동기 프로세스는 더 높은 거버너 제한을 가지므로 확장성이 향상됩니다. 두 번째로 비동기식 요청은 자체 스레드에서 실행되므로 사용자가 비동기식 과업이 백그라운드에서 실행되는 동안 다른 작업을 수행할 수 있습니다.

이 가이드는 Salesforce Platform 내에서 비동기 처리 기술 선택에만 중점을 두고 있습니다. 결정 프로세스를 돕는 다른 리소스는 [리소스 섹션](#자원)에 나와 있습니다.

## 이 가이드의 범위에 속하는 제품

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td><a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Lightning Platform</a>은 직원, 자율 AI 에이전트, 회사 데이터 및 애플리케이션을 신뢰할 수 있는 단일 시스템으로 통합하여 생산성과 고객 경험을 향상시킬 수 있는 종합적인 AI 기반 플랫폼입니다. 이를 통해 Customer 360 앱, Data Cloud, Slack을 연결하여 종단 간 자동화를 구현할 수 있습니다.</td>
    </tr>
  </tbody>
</table>

이 문서에서는 MuleSoft, Informatica, Commerce Cloud, Tableau, Marketing Cloud와 같은 다른 에코시스템의 기술을 다루지 않습니다.

## 서비스

- **비동기식 처리를 사용하기 전에 사용 사례가 패턴에 맞는지 확인하십시오.** 비동기 패턴에는 SLA가 없으며, 다중 총괄자 메커니즘이 적용되며, 라이센스를 기반으로 정의된 수용력 제한이 있을 수 있으며, Salesforce Platform 내 비동기 인프라에 할당된 리소스의 유한적인 특성으로 인해 처리 지연이 발생할 수 있습니다. 사용자가 작업을 계속하기 전에 시스템에서 응답해야 하는 시나리오에서 비동기 처리를 사용할 때 다음 제한 사항을 고려하십시오.
- **Salesforce를 통한 비동기 처리는 무한한 확장 요구를 충족하는 솔루션이 아닙니다.** Salesforce Platform은 무제한으로 확장되지 않으며 비동기 패턴에는 제한이 적용됩니다. 비동기 처리는 스레드를 사용하며, 이는 CPU가 명령 스트림을 실행하기 위해 필요한 컨텍스트 정보를 포함합니다. 스레드는 병렬로 실행할 수 있습니다. CPU에서 사용 가능한 스레드 수는 제한되어 있으므로, 플랫폼은 이 스레드를 최대한 효율적으로 활용하기 위한 메커니즘을 마련했습니다. 플랫폼의 [흐름 제어 메커니즘](/docs/architect/ko-kr/fundamentals/guide/async-fundamentals#플로-제어)은 조직이 너무 많은 스레드를 소비하고 다른 조직에 부정적인 영향을 미치지 않도록 방지합니다. 플랫폼의 [공정 사용 알고리즘](/docs/architect/ko-kr/fundamentals/guide/async-fundamentals#공정한-사용)은 또한 조직이 각 메시지 유형에 사용할 수 있는 스레드 수를 제어합니다.
- **극심한 부하를 유발할 수 있는 이벤트를 고려하십시오.** 비동기 프로세스를 설계할 때 작업 부하 급증 및 감소를 예측 가능한 방식으로 관리할 수 있는지 확인하십시오. 구현 시 전력 중단과 같은 예기치 않은 이벤트를 어떻게 처리할지 고려하고 데이터 손실이나 기능 상실을 완화할 수 있는 안전 장치를 설계합니다.

## 제품 비교

이 표는 Salesforce와 함께 비동기 처리에 사용할 수 있는 도구의 개요를 제공합니다. 의사 결정 프로세스 동안 각 도구의 주요 특성을 검토하려면 이 표를 참조하십시오. 아키텍처에 적합한 도구를 선택하는 데 도움이 되는 [사용 사례](#사용-사례) 및 [결정 지점](#결정-지점)을 참조하십시오.

<table style="border-color:white;overflow-x:scroll;">
  <thead>
    <tr>
      <th>접근 방식</th>
      <th>설명</th>
      <th>필요한 기술</th>
      <th>라이센스 및 제한</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Queueable Apex</b></td>
      <td>장기 실행 데이터베이스 작업 또는 외부 웹 서비스 콜아웃과 관련된 프로세스에 사용합니다. Queueable Apex는 작업 ID 지원, 비원시 타입 지원, 그리고 작업 체이닝 기능을 제공합니다.</td>
      <td>프로 코드</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">라이센스 수는 제한을 늘릴 수 있습니다.</a></td>
    </tr>
    <tr>
      <td><b>배치 Apex</b></td>
      <td>레코드 집합을 분할하고 관리 가능한 청크로 처리하여 수백만 개의 레코드를 포함하는 복잡한 장기 실행 프로세스를 구축합니다.</td>
      <td>프로 코드</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">라이센스 수는 제한을 늘릴 수 있습니다.</a></td>
    </tr>
    <tr>
      <td><b>예약된 Apex</b></td>
      <td>Cron 식으로 정의된 예약된 시간에 Apex 실행합니다. Cron 식을 통해 Apex 예약하는 작업은 비동기식 프로세스이지만, 작업이 시작되면 기본 코드가 동기식으로 실행됩니다.</td>
      <td>프로 코드</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">라이센스 수는 제한을 늘릴 수 있습니다.</a></td>
    </tr>
    <tr>
      <td><b>Apex 계속 콜아웃</b></td>
      <td>동기 트랜잭션 컨텍스트에서 실행되는 Apex 메서드의 콜아웃을 실행합니다.</td>
      <td>프로 코드</td>
      <td>아니요</td>
    </tr>
    <tr>
      <td><b>비동기 경로(레코드 트리거 플로)</b></td>
      <td>독자적으로 실행하고자 하는 작업을 수행합니다. 플로를 트리거한 레코드의 일부가 아닌 관련 레코드의 값을 업데이트할 때 발생하는 혼합 DML 오류를 방지합니다.</td>
      <td>낮은 코드</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">라이센스 수와 유형에 따라 제한이 증가할 수 있습니다.</a></td>
    </tr>
    <tr>
      <td><b>예약 경로(커밋 후 플로우)</b></td>
      <td>트리거 이벤트 후 동적으로 예약된 시간(예: 레코드가 생성, 업데이트 또는 삭제된 경우)에 실행합니다.</td>
      <td>낮은 코드</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">라이센스 수와 유형에 따라 제한이 증가할 수 있습니다.</a></td>
    </tr>
    <tr>
      <td><b>예약된 플로우</b></td>
      <td>지정된 시간 및 반복 빈도(매일, 매주 또는 한 번)에 백그라운드에서 플로우를 실행하여 레코드 배치에 대한 작업을 수행합니다.</td>
      <td>낮은 코드</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">라이센스 수와 유형에 따라 제한이 증가할 수 있습니다.</a></td>
    </tr>
    <tr>
      <td><b>플랫폼 이벤트 트리거</b></td>
      <td>Salesforce와 외부 시스템을 느슨하게 결합하고, Salesforce Platform 내의 비동기 구성 요소 간 통신을 가능하게 합니다.</td>
      <td>로우 코드 + 프로 코드</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm">대용량 플랫폼 이벤트 사용 사례에는 애드온 라이센스가 필요합니다.</a></td>
    </tr>
    <tr>
      <td><b>변경 데이터 캡처</b></td>
      <td>데이터베이스 트랜잭션이 커밋된 후 비동기식으로 변경 이벤트를 수집하고 처리합니다.</td>
      <td>프로 코드</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm">기본 할당을 넘어 확장하려면 애드온 라이센스가 필요합니다.</a></td>
    </tr>
    <tr>
      <td><b>Bulk API</b></td>
      <td>많은 레코드를 비동기적으로 삽입, 업데이트, 업서트, 쿼리 또는 삭제하고 나중에 결과를 처리합니다.</td>
      <td>프로 코드</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.260.0.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_bulkapi.htm">제한이 있습니다.</a></td>
    </tr>
    <tr>
      <td><b>Lightning 작업</b></td>
      <td>사용자가 페이지를 완전히 새로 고칠 필요 없이 Lightning 페이지가 서버와 상호 작용하도록 허용합니다.</td>
      <td>낮은 코드</td>
      <td>아니요</td>
    </tr>
  </tbody>
</table>

## 결정 지점

이 표에는 사용할 비동기식 도구를 결정할 때 고려해야 할 사항의 개요가 포함되어 있습니다.

<table>
  <tbody>
    <tr>
      <td><b>필수 기술</b></td>
      <td>이 가이드에 설명된 일부 도구에는 코드가 필요하며, 다른 도구는 선언적으로 구성할 수 있습니다. 옵션을 고려할 때 팀 구성원이 보유한 기술 집합을 생각해 보십시오. 초기 구현을 위해 개발자를 사용할 수 있는 경우(예: 구현 파트너를 통해) 나중에 솔루션을 수정해야 할 수도 있다는 점에 유의하십시오. 유지보수 팀에 개발자가 부족할 경우 로우 코드 옵션이 더 적합할 수 있습니다.</td>
    </tr>
    <tr>
      <td><b>적용되는 플랫폼 제한 유형</b></td>
      <td>실행에 적용되는 <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm">제한</a>의 유형을 결정합니다. 솔루션을 설계할 때 매일 선택한 접근 방식의 거버너 제한에 트랜잭션의 양과 빈도가 어떻게 계산되는지 주의 깊게 생각합니다. 매일 발생할 실행 횟수를 계산합니다. 계산된 값이 선택한 도구와 연결된 제한에 속하는지 확인합니다.</td>
    </tr>
    <tr>
      <td><b>대기 시간</b></td>
      <td>플랫폼에서 처리 결과를 얼마나 빠르게 사용할 수 있는지 결정합니다. 일부 접근 방식에서는 변경 사항이 거의 즉시 적용되지만, 다른 접근 방식에서는 분 또는 시간으로 변경될 수 있습니다.</td>
    </tr>
  </tbody>
</table>

## 사용 사례

비동기 처리를 위한 도구를 선택할 때 먼저 조직의 요구 사항 및 사용 가능한 자원을 평가합니다. 목표는 구현 및 유지 보수 비용을 최소화하지만 확장성을 유지하고 제한 위반 가능성을 최소화하는 도구를 선택하는 것입니다. 이 목표는 앞서 요약된 기술적 고려 사항 및 팀 구성에 따라 다릅니다.

Salesforce에서 비동기 주문 프로세스를 고려하십시오. 주문이 저장되면 항목을 패킹하고 배송하는 방법에 대한 특별 지침이 포함된 외부 창고 관리 시스템에 메시지를 트리거합니다. 주문하는 사용자는 창고 관리 시스템의 즉각적인 응답이 필요하지 않으므로 비동기식으로 요청을 보낼 수 있습니다. 비동기 처리를 사용하면 사용자가 응답을 기다리지 않고 작업을 계속할 수 있습니다.

이 사용 사례의 경우 Apex를 사용하여 구현할 수 있습니다. 이 접근 방식은 팀에 프로 코드 솔루션을 유지 관리할 수 있는 Apex 개발자가 있는 경우에만 작동합니다. 그렇지 않으면 선언적 접근 방식이 더 적합합니다. 또한 다른 도구에 다른 집합의 [제한](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)이 적용된다는 점에 유의하십시오.

다음 표에서 왼쪽 끝의 열에 일반적인 사용 사례를 나열하고 설명을 확인할 수 있습니다. _첫 번째 선택_ 열은 해당 사용 사례를 충족하는 데 사용되는 가장 일반적인 접근 방식과 그 선택 이유를 함께 제공합니다. 이를 분석의 시작점으로 사용하십시오. 첫 번째 선택 접근 방식에는 사용 사례에서 작동하지 않는 제한 사항이 있을 수 있습니다.

<table>
  <thead>
    <tr>
      <th>사용 사례</th>
      <th>설명</th>
      <th>첫 번째 선택 접근 방식</th>
      <th>근거</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>고성능 배치 처리</b></td>
      <td>수천 또는 수백만 개의 레코드를 효율적으로 처리해야 하는 자동화</td>
      <td>배치 <b>Apex</b></td>
      <td>배치 Apex는 플랫폼과의 인터페이스 및 높은 처리 속도를 위한 다양한 API를 제공합니다.</td>
    </tr>
    <tr>
      <td><b>데이터 정리 작업</b></td>
      <td>데이터를 정리하는 작업으로, 정기적이거나 필요에 따라 실행됩니다. 중복 제거, 주소 확인 또는 데이터 통합을 예로 들 수 있습니다.</td>
      <td>배치 <b>Apex</b></td>
      <td>배치 Apex는 플랫폼과의 인터페이스 및 높은 처리 속도를 위한 다양한 API를 제공합니다.</td>
    </tr>
    <tr>
      <td><b>야간 롤업 작업</b></td>
      <td>영업일이 끝날 때 롤업 데이터를 계산하는 작업입니다.</td>
      <td>배치 <b>Apex</b></td>
      <td>배치 Apex는 플랫폼과의 인터페이스 및 높은 처리 속도를 위한 다양한 API를 제공합니다.</td>
    </tr>
    <tr>
      <td><b>레코드 트리거 로직</b></td>
      <td>레코드 업데이트에 대한 응답으로 논리를 실행합니다.</td>
      <td><i>다른</i></td>
      <td>동료 결정 가이드, <a href="/docs/architect/ko-kr/decision-guides/guide/record-triggered">레코드 트리거 이벤트 자동화</a>를 참조하십시오. 대기 가능한 Apex, 배치 Apex, 예약된 Apex, 예약된 플로, 비동기 경로 플로, 그리고 Change Data Capture 등 비동기 사용 사례에 대한 결정 트리가 포함되어 있습니다.</td>
    </tr>
    <tr>
      <td><b>개체 그래프를 통한 연쇄 업데이트</b></td>
      <td>사용자의 저장 작업을 빠르게 완료할 수 있도록 하며, 다른 개체에 대한 연쇄 업데이트는 비동기적으로 실행되도록 연기됩니다.</td>
      <td>대기 가능한 <b>Apex</b></td>
      <td>대기 가능한 Apex는 업데이트 체인을 일련의 비동기 트랜잭션으로 분할할 수 있는 강력한 체이닝 기능을 제공합니다.</td>
    </tr>
    <tr>
      <td><b>레코드별 예약된 처리</b></td>
      <td>레코드에 고유한 향후 동적 날짜(예: 마감 날짜 3일 전)의 자동화</td>
      <td>예약 경로가 있는 <b>플로</b></td>
      <td>예약 경로는 플로의 고유한 장점이며, 레코드의 데이터가 변경될 경우 해당 경로의 예약, 취소 및 재예약을 플랫폼이 자동으로 처리합니다.</td>
    </tr>
    <tr>
      <td><b>여러 느린 외부 서비스를 병렬로 호출하기</b></td>
      <td>동기 실행 중에는 전체 실행 시간을 최적화하기 위해 여러 외부 서비스를 병렬로 호출합니다.</td>
      <td><b>Apex</b> Continuation 콜아웃</td>
      <td>느리게 실행되는 여러 콜아웃을 병렬로 실행하도록 허용하면 작업을 완료하는 전체 시간이 최소화됩니다.</td>
    </tr>
    <tr>
      <td><b>외부 시스템에서 레코드의 데이터 마이그레이션</b></td>
      <td>대량의 레코드를 외부 시스템에서 Salesforce Platform으로 이동합니다. 일회성 또는 정기적으로 예약된 프로세스입니다.</td>
      <td><b>대량</b> <b>API</b></td>
      <td>이는 데이터 마이그레이션을 위한 가장 효율적이고 제한적인 접근 방식입니다.</td>
    </tr>
    <tr>
      <td><b>외부 시스템에서 추가 논리 실행</b></td>
      <td>플랫폼에서 외부 시스템에 이벤트를 알린 후 해당 시스템이 비동기식으로 이벤트를 처리할 수 있도록 합니다.</td>
      <td><b>플랫폼 이벤트</b> 또는 <b>변경 데이터 캡처</b></td>
      <td>pub-sub 모델은 여기에서 가장 적합하며, 준비가 되면 외부 시스템에서 이벤트를 처리할 수 있습니다. 이 패턴에 대한 자세한 내용은 <a href="/docs/architect/ko-kr/decision-guides/guide/event-driven">이벤트 구동 아키텍처</a>를 참조하십시오.</td>
    </tr>
  </tbody>
</table>

사용 사례 테이블은 각 사용 사례에 가장 적합한 접근 방식을 안내합니다. 그러나 First Choice 기술이 사용 사례의 특정 요구 사항에 얼마나 적합한지 확인해야 합니다. 특히, 선택한 접근 방식이 귀하의 조직에 적용되는 governor 제한을 준수할 수 있는지 확인합니다.

사용 사례에 대한 후보 접근 방식을 식별하면 [비동기 처리 기본 사항 가이드](/docs/architect/ko-kr/fundamentals/guide/async-fundamentals)가 솔루션을 철저하게 검증하는 데 도움이 됩니다.

## 자원

결정 프로세스에 도움이 되는 추가 자원은 다음과 같습니다.

- 플랫폼 비동기 기술 각각을 자세히 살펴봅니다. [비동기식 처리 기본 사항](/docs/architect/ko-kr/fundamentals/guide/async-fundamentals)
- 레코드 트리거에 대한 Apex와 플로 간의 선택: [레코드 트리거 이벤트 자동화](/docs/architect/ko-kr/decision-guides/guide/record-triggered)
- 비동기 통합 패턴에 대한 정보: [이벤트 중심 아키텍처](/docs/architect/ko-kr/decision-guides/guide/event-driven)

<!-- document id=bf5240c84edcf135c8966c90aa341b18b0528b1c2f86f03af3e7adda2168255f url=/architect/current/ko-kr/decision-guides/guides/data-integration.md -->

# Salesforce와 데이터 통합

Salesforce와 외부 시스템 간에 데이터에 액세스, 동기화, 공유할 수 있는 다양한 방법이 있습니다. 그러나 모든 도구가 귀하의 특정 프로젝트에 적합한 것은 아닙니다. 이 가이드에서는 Salesforce에서 사용할 수 있는 데이터 통합 도구의 환경을 살펴봅니다. 또한 특정 사용 사례에 가장 적합한 도구(또는 도구의 조합)에 대한 권장 사항과 특정 시나리오에서 피할 수 있는 도구에 대한 지침을 제공합니다.

## 가이드 개요

이 결정 가이드는 Salesforce와 관련된 데이터 수준 통합에 중점을 둡니다. 특히 다음 데이터 통합 사용 사례를 다룹니다.

- Salesforce에서 외부 시스템으로
- 외부 시스템에서 Salesforce로
- Salesforce 조직 -> Salesforce 조직

이는 Salesforce 아키텍처가 직면하는 통합 문제의 하위 집합일 뿐이므로 이벤트 중심 통합, 프로세스 통합을 사용하여 효과적인 고객 또는 직원 대면 워크플로 구축에 초점을 맞춘 더 많은 의사 결정 가이드를 추가할 계획입니다. 마지막으로 여기에 설명된 많은 도구와 접근 방식을 사용하여 더 광범위한 엔터프라이즈 전반에서 통합 문제를 해결할 수 있지만 이러한 용도는 이 가이드의 범위를 벗어난다는 점에 유의해야 합니다.

## 서비스

- **필요하지 않은 데이터 복제를 피하십시오.** 데이터가 반드시 Salesforce에 있어야 하는 경우를 제외하고, Salesforce Connect를 사용하여 데이터를 가상화하는 것을 고려해 보십시오. 조직의 데이터가 많을수록 데이터 볼륨이 늘어날 수 있으며, 이는 [성능](/docs/architect/ko-kr/well-architected/guide/reliability.html#scalability-and-capacity-planning)에 부정적인 영향을 미치고 기술 부채를 늘릴 수 있습니다. 데이터가 Salesforce에 이미 있고 외부 시스템에 필요한 경우 절대적으로 필요한 경우를 제외하고 외부 시스템에 복사하지 마십시오. 대신 외부 시스템이 Salesforce API를 통해 데이터에 액세스하도록 합니다.
- **사용 가능한 경우 MuleSoft 또는 기타 엔터프라이즈 서비스 버스(ESB) 또는 ETL(Extract-Transform-Load) 솔루션을 사용하십시오.** 이러한 도구는 데이터 마이그레이션 및 변환을 지원하기 위해 구축되었으므로, 기업 전체에서 통합을 재사용하고, 보다 강력한 거버넌스를 유지하며, 통합 관리를 중앙집중화할 수 있는 강력한 기능을 제공합니다. 이 가이드에서 MuleSoft Anypoint가 권장되는 모든 위치에서 기존 ESB/ETL 솔루션이 충분한지 여부를 고려합니다.
- **Data 360 및 Data Cloud One을 사용하여 다양한 소스의 데이터를 조화시킵니다.** Customer 360 데이터 모델, ID 확인, 데이터 통합 및 기타 기능을 통해 Data 360은 Salesforce 및 기타 외부 시스템의 데이터를 고객에 대한 통합 보기로 통합합니다. 또한 [Data Cloud One](/docs/architect/ko-kr/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one)을 사용하면 다른 Salesforce 조직의 사용자가 데이터 공간을 통해 Data 360에서 가상으로 공유된 데이터에 안전하게 액세스할 수 있습니다.
- **Data 360 작업 및 활성화를 사용하여 조직 간에 데이터를 이동합니다.** 데이터가 다른 조직에서 Data 360으로 수집되면 [Data 360 actions and activations](/docs/architect/ko-kr/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound)를 통해 데이터를 다른 조직과 동기화할 수 있습니다. 이 접근 방식은 Marketing Cloud 조직과의 통합에 매우 유용합니다.
- **MuleSoft Anypoint를 사용하여 데이터를 추출하고 이동합니다.** MuleSoft Anypoint를 사용하여 Connect API 및 데이터 그래프 API를 사용하여 Data 360에서 데이터를 추출하고 다른 Salesforce 조직으로 이동할 수 있습니다. Data 360이 없으면 Data 360에서 복제하지 않고 조직 간에 데이터를 이동해야 하는 경우에도 MuleSoft Anypoint를 사용할 수 있습니다.
- **아웃바운드 메시징을 사용하여 구축하려는 경우 주의하십시오.** Salesforce는 현재 기능 용량 내에서 계속해서 아웃바운드 메시징을 지원하지만 이 기술에 대한 추가 투자를 계획하지는 않습니다.
- **모든 통합에 대해 "API 전용" 프로필이 있는 통합 사용자 라이센스를 항상 권장합니다.** 또한 Salesforce는 모든 통합에 대해 적절하게 허용된 AuthN 및 AuthZ 패턴으로 외부 클라이언트 응용 프로그램(연결된 앱 또는 SOAP 로그인 지원)을 사용하는 것이 좋습니다.

## 데이터 통합 도구를 선택하기 위한 일반적인 고려 사항

사용 가능한 데이터 통합 도구를 자세히 살펴보려면 도구를 선택할 때 몇 가지 일반적인 고려 사항에 유의하십시오. 아키텍처와 마찬가지로 모든 비즈니스 문제에 대한 처방적 답변이 없습니다. 통합을 선택할 때 "대상에 따라 다름"이라는 단어를 사용했을 경우 적절한 위치를 찾았습니다.

<table>
    <thead>
        <tr>
            <th>고려할 영역</th>
            <th>일반적인 질문</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>기존 도구 및 환경</td>
            <td>기존 ESB 또는 ETL 솔루션이 있습니까? 관련 데이터에 규제 또는 규정 준수 요구 사항이 있습니까? 통합하려는 시스템은 클라우드 또는 온 프레미스에서 어디에 있습니까?</td>
        </tr>
        <tr>
            <td>데이터 플로(타이밍, 예상 사용자 환경, 방향)</td>
            <td>데이터를 동기식으로 비동기식으로 이동해야 하는지 아니면 배치/예약할 수 있습니까? 데이터 복제가 필요합니까? 신뢰할 수 있는 소스가 되는 시스템은 무엇입니까? 데이터 소스는 무엇입니까? 대상 목적지는 어디입니까? 사용자 상호 작용이 필요합니까? 사용자가 통합 결과를 확인해야 합니까? 예외 처리에 대한 요구 사항은 무엇입니까(재시도, 알림, 실패)? 시스템이 얼마나 긴밀하게 연결되어야 합니까?</td>
        </tr>
        <tr>
            <td>구현</td>
            <td>비-Salesforce 시스템에 필요한 작업량은 어느 정도입니까? 통합 구현을 담당하는 팀은 누구입니까? 해당 팀이 선호하는 도구는 무엇입니까?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/ko-kr/well-architected/guide/resource-and-cost-optimization.html#code-organization">기존성</a></td>
            <td>통합을 유지할 것으로 예상되는 팀은 누구입니까? 현재 보유한 기술은 무엇입니까? 향후 어떤 기술이 필요합니까? 시간에 따른 총 소유 비용은 얼마입니까? 로우 코드 또는 프로 코드 도구를 사용하여 테스트, 디버그, 문제 해결 기능이 얼마나 중요합니까?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/ko-kr/well-architected/guide/reliability.html#scalability-and-capacity-planning">데이터 볼륨</a></td>
            <td>통합에 포함되는 데이터의 양은 얼마나 됩니까? <a href="https://trailhead.salesforce.com/content/learn/modules/large-data-volumes">대용량 데이터 볼륨(LDV)</a>을 다루게 됩니까? 변경 사항은 얼마나 자주 대량으로 발생합니까? Singleton 업데이트는 어떤 영향을 미칩니까? 얼마나 자주 발생합니까?</td>
        </tr>
        <tr>
            <td>제한</td>
            <td>데이터가 복잡한 변환을 수행해야 합니까? 여러 소스 시스템에서 데이터를 결합해야 합니까? 사용자 단위를 기준으로 통합이 얼마나 자주 이루어집니까? 총 사용자 수는 몇 명입니까? 미리 대량 데이터 로드를 계획했습니까(예: 새 인스턴스의 초기 데이터 로드)?</td>
        </tr>
    </tbody>
</table>

## 제품 비교

다음은 데이터 통합에 사용할 수 있는 도구의 상위 수준 개요와 각 옵션 평가를 시작하기 위한 몇 가지 고려 사항입니다. 다음 섹션에는 자세한 사용 사례와 해당 도구의 기능에 대한 세부 사항이 포함되어 있습니다.

<table>
    <thead>
        <tr>
            <th></th>
            <th>Salesforce에서 외부 시스템으로 이동</th>
            <th>외부 시스템에서 Salesforce로 이동</th>
            <th>실행</th>
            <th>추가 라이센스 필수</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex 작업</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">서버측</td>
            <td>아니요</td>
        </tr>
        <tr>
            <td><strong>Change Data Capture</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-no">사용할 수 없음</td>
            <td class="guide-table-ok">서버측</td>
            <td>아니요*</td>
        </tr>
        <tr>
            <td><strong>사용자 정의 Apex(REST 및 SOAP 웹 서비스)</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">서버측</td>
            <td>아니요</td>
        </tr>
        <tr>
            <td><strong>외부 서비스</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-no">사용할 수 없음</td>
            <td class="guide-table-ok">서버측</td>
            <td>아니요</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">서버측</td>
            <td>예</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">서버측</td>
            <td>예</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">서버측</td>
            <td>예</td>
        </tr>
        <tr>
            <td><strong>Native Salesforce API들</strong></td>
            <td class="guide-table-no">사용할 수 없음</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">서버측</td>
            <td>아니요</td>
        </tr>
        <tr>
            <td><strong>Omniscript</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-no">클라이언트측***</td>
            <td>예</td>
        </tr>
        <tr>
            <td><strong>OmniStudio 통합 절차</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">서버측</td>
            <td>예</td>
        </tr>
        <tr>
            <td><strong>아웃바운드 메시징</strong></td>
            <td>이상적이지 않음</td>
            <td class="guide-table-no">사용할 수 없음</td>
            <td class="guide-table-ok">서버측</td>
            <td>아니요</td>
        </tr>
        <tr>
            <td><strong>플랫폼 이벤트</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">서버측</td>
            <td>아니요**</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/외부 개체</strong></td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">사용 가능</td>
            <td class="guide-table-ok">서버측</td>
            <td>예</td>
        </tr>
    </tbody>
</table>

[\*대용량 변경 데이터 수집 이벤트 사용 사례에 필요한 추가 기능](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm)

[\*\*대용량 플랫폼 이벤트 사용 사례에 필요한 추가 기능](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)

\*\*\*웹 브라우저 내에서 비즈니스 논리를 실행하는 것이 좋을 경우 적합합니다.

열 범례:

- **사용 가능**: 대부분의 사용 사례에서 잘 작동합니다.
- **이상적이지 않음**: 가능하지만 대체 도구를 고려하십시오.
- **사용 불가**: 향후 12개월 동안 지원할 계획 없음

### Salesforce로 데이터를 보내거나 받는 기타 도구

데이터 레이어 통합의 일부 측면을 지원할 수 있는 다른 도구가 있지만 통합 문제를 해결하는 기본 수단으로 간주해서는 안 됩니다. 이제 이러한 도구를 빠르게 살펴보겠습니다.

**Lightning 웹 구성 요소**는 일반적으로 프로세스 통합에 사용되지만, JavaScript 기능을 사용하여 콜아웃을 만들 수 있으므로 해당 트랜잭션에 데이터가 포함될 수 있습니다.

**Salesforce Flow**는 외부 서비스 또는 Apex 작업을 사용하여 외부 콜아웃을 오케스트레이션하는 데 활용될 수 있습니다. Salesforce Flow 자체는 독립 실행형 데이터 통합 도구로 간주되지 않습니다.

**Data Import Wizard 및 Data Loader**를 사용하여 데이터를 동기화하고 가져오거나 마이그레이션할 수 있습니다. Data Loader 명령은 데이터 가져오기와 내보내기를 자동화하기 위해 스크립팅할 수 있지만, [명령줄 인터페이스](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm)는 Windows 전용이며 이들 도구는 데이터 통합 전략의 기반으로 권장되지 않습니다. 대신 이를 사용하여 데이터 관리 및 유지 관리 전략을 보완합니다.

[**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) 데이터 명령을 사용하여 조직의 레코드를 조작할 수 있습니다. 대량 API 및 SObject 트리 저장 API를 사용하여 데이터를 가져오거나 내보내는 데 도움이 되는 명령을 사용할 수 있으며, REST API를 사용하여 개별 레코드에서 간단한 CRUD 작업을 수행할 수 있습니다. Salesforce CLI 자체는 독립형 데이터 통합 도구로 간주되지 않습니다.

**OmniStudio Data Mapper** 은 선언적 ETL 도구로 사용하여 Salesforce 개체와 JSON 데이터 구조 간에 데이터를 이동할 수 있습니다. REST 인터페이스는 각 데이터 매퍼 인터페이스에 대해 자동으로 생성되며, 외부 시스템에서 Salesforce 개체로 데이터를 이동하는 선언적 방법을 제공하지만 데이터 매퍼 독립형은 데이터 통합 전략의 기준이 아닙니다. 데이터 매퍼 작업은 OmniStudio 통합 절차에서 사용할 수 있습니다.

[**Dataloader.io**](http://dataloader.io/)는 MuleSoft의 Anypoint 플랫폼을 통해 제공되는 Salesforce의 또 다른 데이터 로더 도구로서 기업의 데이터 양을 빠르고 안전하게 가져오고 내보내거나 삭제할 수 있습니다. Dataloader.io는 데이터 통합 전략의 기준이 아닙니다.

## Salesforce에서 외부 시스템으로의 아웃바운드 통합

Salesforce의 아웃바운드 통합의 경우 하위 코드, 프로 코드 또는 하이브리드와 같은 다양한 유형의 도구를 고려할 수 있습니다. 다음 섹션에서는 이러한 각 도구 유형에 대한 지침을 제공하고 샘플 솔루션을 제공합니다.

- [아웃바운드 통합을 위한 로우 코드 도구](#salesforce의-아웃바운드-통합을-위한-로우-코드-도구)
- [아웃바운드 통합을 위한 하이브리드 도구](#salesforce의-아웃바운드-통합을-위한-하이브리드-도구)
- [아웃바운드 통합을 위한 프로 코드 도구](#salesforce의-아웃바운드-통합을-위한-pro-code-도구)

### Salesforce의 아웃바운드 통합을 위한 로우 코드 도구

<table>
    <thead>
        <tr>
            <th></th>
            <th>지침</th>
            <th>라이센스</th>
            <th>시기</th>
            <th>볼륨 및 규모</th>
            <th></th>
            <th>배포 및 유지 관리</th>
            <th></th>
            <th></th>
            <th>개인 정보 보호 및 보안</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>사용 시기</strong></th>
            <th><strong>추가 라이센스</strong></th>
            <th><strong>동기(요청/응답) 또는 비동기(발신/무시)</strong></th>
            <th><strong>다중 개체 지원</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>테스트 및 구축**</strong></th>
            <th><strong>디버깅</strong></th>
            <th><strong>내장 오류 처리/재시도 동작</strong></th>
            <th><strong>Can Use with Data Encrypted at Rest</strong> → <strong>저장 시 암호화된 데이터와 함께 사용할 수 있음</strong></th>
            <th><strong>인증 프로토콜</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>변경 데이터 캡처</strong></td>
            <td>Salesforce의 레코드 수준 변경 사항을 외부 시스템에 게시해야 하며 사용자 정의 페이로드가 필요하지 않은 경우</td>
            <td>필수</td>
            <td>비동기</td>
            <td>아니요</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>외부 서비스</strong></td>
            <td>Flow, Apex, Einstein Bots 또는 OmniStudio를 사용하여 프로세스를 오케스트레이션하는 경우 외부 시스템 API가 OpenAPI 사양을 사용하여 설명됩니다.</td>
            <td>필수 아님</td>
            <td>동기화</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td>N/A</td>
            <td>명명된 자격 증명</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>양방향 동기화를 사용하여 데이터를 확장하여 Heroku에서 모바일 및 기타 앱을 활성화하고 데이터를 Salesforce에도 복제하려는 경우</td>
            <td>필수</td>
            <td>비동기</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td>프로 코드 도구 사용</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예, Shield Connect를 통해</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>OmniStudio 통합 절차</strong></td>
            <td>사용자 상호 작용 없이 데이터를 변환하고 브라우저 대신 서버에서 처리하여 성능을 향상해야 하는 경우</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>선언적 지원</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>명명된 자격 증명</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/외부 개체</strong></td>
            <td>Salesforce UI에 데이터를 표시하되 외부 시스템에 데이터를 저장하려는 경우 데이터는 Salesforce에 복제되지 않습니다.</td>
            <td>필수</td>
            <td>동기화</td>
            <td>아니요</td>
            <td class="guide-table-ok">예*</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구와 선언적 추적기를 함께 사용</td>
            <td>아니요</td>
            <td>N/A</td>
            <td>명명된 자격 증명</td>
        </tr>
        <tr>
            <td colspan="11">*버전 4.01보다 오래된 OData 어댑터는 콜아웃 제한이 적용됩니다. 자세한 내용은 <a href="https://help.salesforce.com/s/articleView?id=platform.odata_general_limits.htm&type=5">OData 콜아웃 요금 한도 고려 사항</a>을 참조하십시오. ** 테스트 및 배포는 낮은 환경에서 구축하고 <a href="https://developer.salesforce.com/docs/metadata-coverage/">메타데이터 API</a>, 패키지 또는 변경 집합을 통해 프로덕션에 배포할 수 있는 기능을 말합니다.</td>
        </tr>
    </tbody>
</table>

### 사용 사례: 로우 코드 도구를 사용한 아웃바운드 통합

> 기회가 수주되면 회사의 ERP 시스템 또는 주문 관리 시스템에서 관련 제품에 대한 주문을 만들어야 합니다.

**Change Data Capture** 기회 레코드가 업데이트되면, 변경 데이터 캡처가 개체에 대한 업데이트를 포함한 변경 이벤트를 게시합니다. 변경 이벤트는 CometD 연결(또는 MuleSoft 커넥터를 통해)을 통해 고객이 소비하고 고객의 ERP 또는 주문 관리 시스템을 업데이트하는 데 사용됩니다. 변경 이벤트를 보강하여 항상 통합에 필요한 개체의 외부 레코드 ID 또는 기타 데이터(예: 지역)를 포함할 수 있습니다. 여러 개체에 대한 변경 이벤트 스트림을 단순화된 구독 및 스트림 처리를 위해 _채널_으로 결합할 수 있습니다(다중 스트림 대신 하나의 스트림을 구독하고 처리할 수 있음).

**외부 서비스** OpenAPI 2.0 또는 3.0 사양을 지원하는 웹 서비스가 있는 경우 Salesforce 내에서 운영 및 서비스를 외부 서비스로 표시할 수 있습니다. 기회의 단계가 "수주"로 변경되면 API 작업(예: 주문 만들기)을 Flow Builder로 구축된 플로우에서 호출 가능한 작업으로 실행할 수 있습니다.

**Heroku Connect** Heroku Connect는 일반적으로 Heroku Postgres 데이터베이스와 Salesforce를 동기화하는 데 사용됩니다. 고객이 Heroku Postgres를 신뢰할 수 있는 트랜잭션 매장으로 사용하는 경우 Heroku Connect를 사용하여 Salesforce의 레코드 및 변경 사항을 Heroku Postgres에 동기화할 수 있습니다. 여기에서 Heroku 스트리밍 커넥터를 사용하여 변경 사항을 Apache Kafka에 게시하고 ERP 또는 주문 관리 시스템 등 다운스트림 응용 프로그램에 이벤트로 보낼 수 있습니다.

**OmniStudio 통합 절차** 주문이 제출되면 프로세스를 오케스트레이션하는 Omniscript가 주문 세부 사항을 ERP 또는 MuleSoft 커넥터에 게시할 수 있습니다. 게시물을 Omniscript(클라이언트측)에서 직접 실행하거나 통합 절차(서버측)를 통해 간접적으로 실행할 수 있습니다. ERP 시스템에서 유효성 검사 오류가 발생하는 경우 Omniscript UI가 사용자에게 알리고 필요한 경우 사용자에 대한 오류를 번역하고 맥락화해야 합니다.

**Salesforce Connect/외부 개체** 기회의 단계가 "수주"로 변경되면 관련 외부 개체에 레코드를 삽입하는 Salesforce의 레코드 트리거 플로우를 만들 수 있습니다. 이는 [교체 트랜잭션](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1)이므로 오류를 방지하기 위해 Opportunity 업데이트와 관련 외부 개체 삽입 사이에 0초 동안 일시 중지 요소를 추가하여 새로운 트랜잭션을 시작하기 전에 하나의 트랜잭션 컨텍스트를 닫습니다.

### Salesforce의 아웃바운드 통합을 위한 하이브리드 도구

<table>
    <thead>
        <tr>
            <th></th>
            <th>지침</th>
            <th>라이센스</th>
            <th>시기</th>
            <th>볼륨 및 규모</th>
            <th></th>
            <th>배포 및 유지 관리</th>
            <th></th>
            <th></th>
            <th>개인 정보 보호 및 보안</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>사용 시기</strong></th>
            <th><strong>추가 라이센스</strong></th>
            <th><strong>동기(요청/응답) 또는 비동기(발신/무시)</strong></th>
            <th><strong>다중 개체 지원</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>테스트 및 구축**</strong></th>
            <th><strong>디버깅</strong></th>
            <th><strong>내장 오류 처리/재시도 동작</strong></th>
            <th><strong>Can Use with Data Encrypted at Rest</strong> → <strong>저장 시 암호화된 데이터와 함께 사용할 수 있음</strong></th>
            <th><strong>인증 프로토콜</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex 작업</strong></td>
            <td>Salesforce Flow를 통해 다른 시스템에 대한 콜아웃을 자동화하려는 경우 개발자는 플로에서 호출할 수 있는 Apex 클래스를 작성하거나 AppExchange 사전 빌드된 솔루션을 다운로드할 수 있습니다.</td>
            <td>필수 아님</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>다중</td>
        </tr>
        <tr>
            <td><strong>이벤트 릴레이</strong></td>
            <td>Salesforce에서 플랫폼 이벤트를 보내고 데이터 수집 이벤트를 Amazon EventBridge로 변경해야 하는 경우 이벤트 릴레이는 AWS Eventbridge에만 연결됩니다.</td>
            <td>아니요</td>
            <td>비동기</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>TLS를 사용하는 HTTP/1.1</td>
        </tr>
        <tr>
            <td><strong>아웃바운드 메시징</strong></td>
            <td>워크플로 규칙에 의해 트리거될 때 수신이 보장된 지정된 끝점에 HTTP(S)를 통해 SOAP 메시지를 보내야 하는 경우</td>
            <td>필수 아님</td>
            <td>비동기</td>
            <td>아니요</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>선언적 지원</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>양방향 TLS</td>
        </tr>
        <tr>
            <td><strong>플랫폼 이벤트</strong></td>
            <td>Salesforce 또는 외부 시스템에서 거의 실시간 변경 사항에 대해 사용자 정의된 구조화된 페이로드가 필요한 경우.</td>
            <td>필수 아님*</td>
            <td>비동기</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/외부 개체(사용자 정의 Apex 어댑터 포함)</strong></td>
            <td>데이터가 Salesforce UI에 표시되지만, OData 또는 GraphQL과 같은 표준 프로토콜을 사용할 수 없는 외부 시스템에 저장되도록 하려는 경우</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td>N/A</td>
            <td>다중</td>
        </tr>
         <tr>
            <td><strong>Data 360</strong></td>
            <td>단일 데이터 저장소의 여러 소스에서 조화된 데이터를 원하거나 다른 Salesforce 조직 또는 다른 외부 시스템에 데이터를 복제하려는 경우</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>다중</td>
        </tr>
    </tbody>
</table>

[\*Add-on](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)은 대용량 사용 사례에 필요합니다.

\*\*테스트 및 배포는 낮은 환경에서 구축하고 [메타데이터 API](https://developer.salesforce.com/docs/metadata-coverage/), 패키지 또는 변경 집합을 통해 프로덕션에 배포할 수 있는 기능을 말합니다.

### 사용 사례: 하이브리드 도구를 사용한 아웃바운드 통합

> 기회가 수주되면 회사의 ERP 또는 주문 관리 시스템에서 관련 제품에 대한 주문을 만들어야 합니다.

**Apex 작업** 기회가 수주되면 기회 상태를 기반으로 레코드 트리거 플로우가 자동으로 실행될 수 있습니다. 플로는 외부 콜아웃을 사용하여 주문을 주문 관리 시스템 또는 ERP 솔루션에 제출하는 호출 가능한 작업을 실행합니다. 대용량 제출 및 다중 사이트 주문은 Apex 배치 및 대기열 메커니즘으로 처리됩니다.

**아웃바운드 메시징**[을 설정한 후](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm), 기회 업데이트에 의해 트리거되는 워크플로 규칙을 정의하여 수신기를 호스팅하는 지정된 끝점 URL로 HTTP(S)를 통해 SOAP 메시지를 보낼 수 있습니다. 메시지에 아웃바운드 메시지가 생성될 때 지정된 필드가 포함됩니다. 알림이 대기열에 지정된 후이지만 전송되기 전에 개체의 정보가 변경되는 경우 업데이트된 정보만 전달되고 메시지가 성공적으로 전송될 때까지 또는 24시간이 지난 후까지 대기열에 남아 있게 됩니다. 24시간 후에는 메시지가 대기열에서 삭제됩니다. ERP 시스템에 추가 데이터가 필요한 경우 외부 시스템에서 콜백 요청을 만들 수 있도록 아웃바운드 메시지에서 sessionId를 전달할 수 있습니다.

**Platform Events** 외부 시스템에서 레코드를 생성하는 데 필요한 데이터를 포함하는 사용자 정의 페이로드를 사용하는 플랫폼 이벤트를 정의할 수 있습니다. 플랫폼 이벤트는 레코드 변경 시 자동 게시되지 않으므로 기회의 단계가 "수주"로 변경되면 Apex, Salesforce 플로 또는 프로세스 빌더를 통해 이벤트를 게시해야 합니다. 외부 서비스는 CometD(또는 MuleSoft 커넥터)를 사용하여 플랫폼 이벤트 채널을 수신하고 외부 시스템에서 적절한 레코드를 만듭니다.

**Salesforce Connect/External Objects(사용자 지정 Apex 어댑터 포함)** Salesforce Connect/External Objects를 기반으로 하는 솔루션은 단순히 데이터 동기화를 요구하는 사용 사례에 적합하지 않습니다. 그러나 이 솔루션은 Salesforce 내 사용자가 확인해야 하며 잠재적으로 외부 시스템의 데이터와 상호 작용하고 Salesforce에서 데이터를 복제할 수 없는 사례에 적용할 수 있습니다. ERP 또는 주문 관리 시스템에서 OData 또는 GraphQL 프로토콜을 지원하지 않는 경우 개발 팀은 [Apex Connector Framework를](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm) 사용하여 지원되는 프로토콜을 통해 외부 시스템과 통신을 처리하는 Apex 클래스를 작성할 수 있습니다.

**Data 360** Data 360을 기반으로 한 솔루션은 하나의 데이터 저장소에서 서로 다른 소스의 데이터를 조화롭게 처리해야 하는 사용 사례에 완벽하게 적합합니다. 또한 Data 360을 데이터 허브로 사용하여 하나의 Salesforce 조직에서 여러 Salesforce 조직 또는 다른 외부 시스템으로 데이터를 복제해야 하는 경우에도 사용할 수 있습니다. 기회가 수주되고 소스 조직에서 업데이트되면 기회 데이터가 Data 360에 동기화되어 작업, 활성화, API와 같은 다양한 메커니즘을 사용하여 Salesforce 조직을 비롯한 다른 시스템에서 복제할 수 있습니다. 마찬가지로 Data Cloud One을 사용하여 다른 Salesforce 조직에서 데이터를 복제하지 않고 기회를 참조할 수 있습니다. 그러나 Data Cloud One은 비-Salesforce 플랫폼을 지원하지 않습니다.

### Salesforce의 아웃바운드 통합을 위한 Pro-Code 도구

<table>
    <thead>
        <tr>
            <th></th>
            <th>지침</th>
            <th>라이센스</th>
            <th>시기</th>
            <th>볼륨 및 규모</th>
            <th></th>
            <th>전달 및 유지보수</th>
            <th></th>
            <th></th>
            <th>개인 정보 보호 및 보안</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>사용 시기</strong></th>
            <th><strong>추가 라이센스</strong></th>
            <th><strong>동기화(요청/응답) 또는 비동기(발사/무시)</strong></th>
            <th><strong>다중 개체 지원</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>테스트 및 구축**</strong></th>
            <th><strong>디버깅</strong></th>
            <th><strong>내장 오류 처리/재시도 동작</strong></th>
            <th><strong>Can Use with Data Encrypted at Rest</strong> → <strong>저장 시 암호화된 데이터와 함께 사용할 수 있음</strong></th>
            <th><strong>인증 프로토콜</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>사용자 정의 Apex</strong></td>
            <td>하위 코드 도구에서 사용할 수 있는 것보다 더 많은 기능이 필요한 경우</td>
            <td>필수 아님</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td class="guide-table-ok">예*</td>
            <td>다중</td>
        </tr>
        <tr>
            <td><strong>외부 서비스</strong></td>
            <td>코드에서 외부 시스템 API와의 통합 방법은 OpenAPI 사양을 사용하여 설명됩니다.</td>
            <td>필수 아님</td>
            <td>동기화</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td>N/A</td>
            <td>다중</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>통합을 구축, 오케스트레이션, 관리하기 위해 단일 엔터프라이즈급 통합 솔루션이 필요한 경우, 레거시 지점 간 아키텍처를 교체해야 하는 경우 또는 API 관리 지원이 필요한 경우</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td class="guide-table-ok">예*</td>
            <td>다중</td>
        </tr>
    </tbody>
</table>

\*Shield Platform Encryption을 활성화하면 특정 동작이 변경됩니다. 자세한 내용은 [General Shield Platform Encryption Considerations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)를 참조하십시오.

\*\*테스트 및 배포는 낮은 환경에서 구축하고 [메타데이터 API](https://developer.salesforce.com/docs/metadata-coverage/), 패키지 또는 변경 집합을 통해 프로덕션에 배포할 수 있는 기능을 말합니다.

### 사용 사례: Pro-Code 도구를 사용한 아웃바운드 통합

> 기회가 수주되면 회사의 ERP 또는 주문 관리 시스템에서 관련 제품에 대한 주문을 만들어야 합니다.

**사용자 정의 Apex** 기회의 단계가 "수주"로 변경되면 ERP 또는 주문 관리 시스템에 콜아웃을 수행하는 Opportunity에서 Apex 트리거 및 트리거 처리기를 만들 수 있습니다. 트리거에서 또는 DML 작업 수행 후 콜아웃을 만드는 경우, @future 또는 queueable 어노테이션이 달린 메서드를 사용해야 합니다. 트리거에서의 콜아웃은 콜아웃 실행 동안 데이터베이스 연결을 유지합니다. 모든 Apex 코드는 지속적으로 개정되는 [Apex Governor 및 API 제한](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm)에 따라 적용됩니다.

**외부 서비스** 회사의 외부 ERP 또는 주문 관리 시스템이 OpenAPI 사양을 통해 정의되면 향후 방법 또는 대기 가능한 작업에서 수행되는 서비스에 대한 콜아웃이 단순화될 수 있습니다. 등록된 외부 서비스는 보일러플레이트 코드를 작성할 필요 없이 Apex에서 직접 호출할 수 있습니다. 이 예에서는 주문을 만드는 콜아웃을 외부 서비스에서 처리할 수 있습니다.

**MuleSoft Anypoint** MuleSoft Anypoint는 엔터프라이즈급 API 관리를 제공합니다. MuleSoft Anypoint는 Salesforce 및 기타 여러 엔터프라이즈 시스템의 데이터에 대해 읽기(및/또는 쓰기) 액세스를 제공하는 API를 생성할 수 있습니다. 구축을 단순화하기 위해 [많은 사전 구축된 커넥터가](https://www.mulesoft.com/platform/cloud-connectors) 있으며, 회사는 자체 커넥터를 만들고 게시할 수도 있습니다. 이러한 API는 중앙 집중식 관리 및 거버넌스를 지원하는 유연한 보안 정책을 사용하여 Anypoint에 배포할 수 있습니다. API가 최대 사용량(vCores에서 측정)에 맞게 적절하게 크기가 조정된 경우 트랜잭션 용량에 대한 제한은 없습니다.

## 외부 시스템 데이터를 Salesforce로 가져오기(인바운드 통합)

Salesforce에 대한 인바운드 통합의 경우 하위 코드, 프로 코드 또는 하이브리드와 같은 다양한 유형의 도구를 고려할 수 있습니다. 다음 섹션에서는 이러한 각 도구 유형에 대한 지침을 제공하고 샘플 솔루션을 제공합니다.

- [인바운드 통합을 위한 로우 코드 도구](#salesforce에-대한-인바운드-통합을-위한-로우-코드-도구)
- [인바운드 통합을 위한 하이브리드 도구](#salesforce에-대한-인바운드-통합을-위한-하이브리드-도구)
- [인바운드 통합을 위한 프로 코드 도구](#salesforce에-대한-인바운드-통합을-위한-프로-코드-도구)

### Salesforce에 대한 인바운드 통합을 위한 로우 코드 도구

<table>
    <thead>
        <tr>
            <th></th>
            <th>지침</th>
            <th>라이센스</th>
            <th>시기</th>
            <th>볼륨 및 규모</th>
            <th></th>
            <th>배포 및 유지보수</th>
            <th></th>
            <th></th>
            <th>개인 정보 보호 및 보안</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>사용하는 경우</th>
            <th>추가 라이선스</th>
            <th>동기화(요청/응답) 또는 비동기화(발행/실패)</th>
            <th>다중 개체 지원</th>
            <th>LDV/Bulk</th>
            <th>테스트 및 배포*</th>
            <th>디버깅</th>
            <th>내장 오류 처리/재시도 동작</th>
            <th>저장 시 암호화된 데이터와 함께 사용 가능</th>
            <th>인증 프로토콜</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>양방향 동기화를 사용하여 데이터를 확장하여 Heroku에서 모바일 및 기타 앱을 활성화하고 데이터를 Salesforce에도 복제하려는 경우</td>
            <td>필수</td>
            <td>비동기</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td>프로 코드 도구 사용</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예, Shield Connect를 통해</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>OmniStudio 통합 절차</strong></td>
            <td>사용자 상호 작용 없이 타사 소스에서 데이터를 가져오고 변환해야 하는 경우</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>선언적 지원</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>명명된 자격 증명</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/외부 객체</strong></td>
            <td>데이터가 Salesforce UI에 표시되지만, OData 또는 GraphQL과 같은 표준 프로토콜을 사용할 수 있는 외부 시스템에 저장되도록 하려는 경우</td>
            <td>필수</td>
            <td>동기화</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td>N/A</td>
            <td>다중</td>
        </tr>
    </tbody>
</table>

\*테스트 및 배포는 낮은 환경에서 구축하고 [메타데이터 API](https://developer.salesforce.com/docs/metadata-coverage/), 패키지 또는 변경 집합을 통해 프로덕션에 배포할 수 있는 기능을 말합니다.

### 사용 사례: 로우 코드 도구를 사용한 인바운드 통합

> 조직의 ERP 시스템에서 연락처가 업데이트됩니다. 이 연락처 정보를 Salesforce에서 업데이트해야 합니다.

**Heroku Connect** Heroku Connect는 일반적으로 Heroku Postgres 데이터베이스와 Salesforce를 동기화하는 데 사용됩니다. ERP 시스템에서 Heroku Postgres를 트랜잭션 저장소로 사용하지 않는 한 이 사용 사례는 불가능합니다. Heroku Postgres를 사용하는 경우 Heroku Connect를 사용하여 Postgres 테이블의 변경 사항을 Salesforce의 개체에 동기화할 수 있습니다.

**OmniStudio 통합 절차** ERP 시스템이 연락처 레코드를 업데이트한 후 Data Mapper에서 생성한 REST API를 통해 Data Mapper 로드 작업 및 응답 작업이 포함된 OmniStudio 통합 절차를 호출할 수 있습니다. 먼저 데이터 매퍼 로드 작업은 JSON 또는 XML 페이로드를 보내며, 이는 외부 ID 필드 또는 [업서트 키](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio)를 통해 연락처 레코드를 업서트하는 데 사용됩니다. JSON의 간단한 응답만 예상되는 경우 응답 작업에서 이전 작업의 관련 정보를 다시 보내 성공 또는 실패를 나타낼 수 있습니다. ERP 시스템에서 특정 응답을 예상하는 경우 데이터 매퍼 변환 또는 추출 작업을 사용하여 연락처 레코드 업데이트에서 트리거에 생성된 데이터를 선언적으로 포함하는 추가 기능이 포함된 JSON 또는 XML 응답을 생성할 수 있습니다. 이 시나리오의 주요 과제는 동시성입니다. 동일한 연락처 레코드를 동시에 업데이트하기 위해 여러 번 호출하면 API가 Salesforce에 직접 존재하므로 문제가 발생합니다.

**Salesforce Connect / 외부 개체** Salesforce Connect 및 외부 개체는 Salesforce에서 데이터 복제를 특별히 필요로 하므로 이 사용 사례에 사용하지 않는 것이 좋습니다. ERP에 구축된 기존 Salesforce Connect 통합이 있는 경우, ERP가 변경 데이터 캡처를 지원한다면 OData 4.0 커넥터를 구성하여 외부 변경 데이터 캡처를 지원할 수 있습니다. 또한 Salesforce에서 Pub/Sub API를 사용하여 ERP에서 변경 스트림을 구독하도록 구성해야 합니다.

### Salesforce에 대한 인바운드 통합을 위한 하이브리드 도구

<table>
    <thead>
        <tr>
            <th></th>
            <th>지침</th>
            <th>라이센스</th>
            <th>시기</th>
            <th>볼륨 및 규모</th>
            <th></th>
            <th>배포 및 유지보수</th>
            <th></th>
            <th></th>
            <th>개인 정보 보호 및 보안</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>사용하는 경우</th>
            <th>추가 라이센스</th>
            <th>동기화(요청/응답) 또는 비동기화(발행/실패)</th>
            <th>다중 개체 지원</th>
            <th>LDV/Bulk</th>
            <th>테스트 및 배포**</th>
            <th>디버깅</th>
            <th>내장 오류 처리/재시도 동작</th>
            <th>저장 시 암호화된 데이터와 함께 사용 가능</th>
            <th>인증 프로토콜</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>플랫폼 이벤트</strong></td>
            <td>Salesforce 또는 외부 시스템에서 거의 실시간 변경을 위해 사용자 정의된 구조화된 페이로드가 필요한 경우</td>
            <td>필수 아님*</td>
            <td>비동기</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/외부 개체(사용자 정의 Apex 어댑터 포함)</strong></td>
            <td>데이터가 Salesforce UI에 표시되지만 OData 2.0/4.0 프로토콜을 사용할 수 없는 외부 시스템에 저장되도록 하려는 경우</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구와 함께</td>
            <td>아니요</td>
            <td>N/A</td>
            <td>다중</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>단일 데이터 저장소의 다양한 소스에서 조화된 데이터를 원하거나 다른 Salesforce 조직 또는 다른 외부 시스템으로 데이터를 복제하려는 경우 Data 360은 일부 플랫폼에서도 가상화를 지원합니다.</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>다중</td>
        </tr>
    </tbody>
</table>

\*[추가 기능](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)은 대용량 사용 사례에 필요합니다.

\*\*테스트 및 배포는 낮은 환경에서 구축하고 [메타데이터 API](https://developer.salesforce.com/docs/metadata-coverage/), 패키지 또는 변경 집합을 통해 프로덕션에 배포할 수 있는 기능을 말합니다.

### 사용 사례: 하이브리드 도구를 사용한 인바운드 통합

> 조직의 ERP 시스템에서 연락처가 업데이트됩니다. 이 연락처 정보를 Salesforce에서 업데이트해야 합니다.

**Platform Events** 외부 시스템의 사용자 정의 코드가 ERP에서 연락처 레코드가 업데이트될 때 플랫폼 이벤트를 게시합니다. Salesforce의 트리거, 프로세스 또는 플로에서 플랫폼 이벤트를 구독하고 이벤트가 처리될 때 해당 Salesforce 개체를 업데이트할 수 있습니다. 플랫폼 이벤트는 데이터를 포함하지 않고 고객의 ERP 시스템에서 변경 사항이 발생했다는 신호로만 작동하거나 Salesforce 개체 업데이트에 필요한 실제 데이터를 포함할 수 있습니다.

**Salesforce Connect/External Objects(사용자 정의 Apex 어댑터 포함)** 이 솔루션은 데이터 복제가 필요한 사용 사례에 적용되지 않습니다. 이 솔루션은 Salesforce의 사용자가 Salesforce에서 복제할 수 없거나 복제할 수 없는 외부 시스템의 정보를 볼 필요가 있고 외부 시스템에서 OData 또는 GraphQL과 같은 표준 프로토콜을 지원할 수 없는 경우에 적용됩니다. [사용 사례: Apex 사용자 정의 어댑터의 예제 사용 사례로, 하이브리드 도구](#사용-사례-하이브리드-도구를-사용한-아웃바운드-통합)를 활용한 아웃바운드 통합 예제를 통해 확인할 수 있습니다.

**Data 360** ERP와 같은 외부 시스템에서 연락처를 업데이트하면 상자 외부 커넥터를 사용하거나 MuleSoft와 같은 API 및 프로 코드 도구를 사용하여 연락처 업데이트를 Data 360에 동기화할 수 있습니다. 연락처는 제로 복사 메커니즘을 사용하여 Data 360에서 참조할 수도 있습니다(일부 플랫폼에서 사용 가능). Data 360에서 데이터가 사용 가능해지면, 기본 제공 통합 메커니즘을 사용하여 데이터를 다른 Salesforce 조직과 동기화할 수 있습니다. Data Cloud One을 사용하여 참조하여 데이터에 액세스할 수 있습니다. 활성화 및 기본 커넥터를 사용하는 기타 API를 사용하거나 MuleSoft Anypoint 플랫폼과 같은 프로 코드 도구를 사용하여 데이터를 복제할 수도 있습니다.

### Salesforce에 대한 인바운드 통합을 위한 프로 코드 도구

<table>
    <thead>
        <tr>
            <th></th>
            <th>지침</th>
            <th>라이센스</th>
            <th>시기</th>
            <th>볼륨 및 규모</th>
            <th></th>
            <th>배포 및 유지보수</th>
            <th></th>
            <th></th>
            <th>개인 정보 보호 및 보안</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>사용하는 경우</th>
            <th>추가 라이센스</th>
            <th>동기화(요청/응답) 또는 비동기화(발행/실패)</th>
            <th>다중 개체 지원</th>
            <th>LDV/Bulk</th>
            <th>테스트 및 배포****</th>
            <th>디버깅</th>
            <th>내장 오류 처리/재시도 동작</th>
            <th>저장 시 암호화된 데이터와 함께 사용 가능</th>
            <th>인증 프로토콜</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>사용자 정의 Apex REST 및 SOAP 웹 서비스</strong></td>
            <td>교차 개체 처리 또는 기타 복잡한 논리와 같은 기본 API 끝점에서 제공하는 것보다 더 많은 기능이 필요한 경우</td>
            <td>필수 아님</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td class="guide-table-ok">예***</td>
            <td>다중</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>통합을 구축, 오케스트레이션, 관리하기 위해 단일 엔터프라이즈급 통합 솔루션이 필요한 경우, 레거시 지점 간 아키텍처를 교체해야 하는 경우 또는 API 관리 지원이 필요한 경우</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td class="guide-table-ok">예***</td>
            <td>다중</td>
        </tr>
        <tr>
            <td><strong>Native Salesforce APIs</strong></td>
            <td>추가 제어가 필요하거나 REST API, SOAP API, Bulk API, GraphQL API 또는 gRPC를 통해 통합을 구축할 수 있는 프로 코드 기술 집합이 있는 경우</td>
            <td>필수 아님*</td>
            <td>모두</td>
            <td class="guide-table-ok">예*****</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td class="guide-table-ok">예**</td>
            <td class="guide-table-ok">예***</td>
            <td>다중</td>
        </tr>
    </tbody>
</table>

\*[API 요청 제한 및 할당](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm)이 적용됩니다.

\*\*Bulk API에는 재시도 동작의 측면이 있으며, 여러 API는 allOrNone 설정을 통해 _롤백_ 보호를 제공합니다(예: 복합 및 컬렉션 요청의 [allOrNone 매개 변수](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm) 참조).

\*\*\*Shield Platform Encryption을 활성화하면 특정 동작이 변경됩니다. 자세한 내용은 [General Shield Platform Encryption Considerations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)를 참조하십시오.

\*\*\*\*테스트 및 배포는 낮은 환경에서 구축하고 [메타데이터 API](https://developer.salesforce.com/docs/metadata-coverage/), 패키지 또는 변경 집합을 통해 프로덕션에 배포할 수 있는 기능을 말합니다.

\*\*\*\*\*복합 API는 다중 개체를 지원합니다.

### 사용 사례: 프로 코드 도구를 사용한 인바운드 통합

> 조직의 ERP 시스템에서 연락처가 업데이트됩니다. 이 연락처 정보를 Salesforce에서 업데이트해야 합니다.

**사용자 정의 Apex REST 및 SOAP 웹 서비스** 연락처 개체에서 CRUD(만들기, 읽기, 업데이트, 삭제) 작업을 수행할 수 있는 Apex 코드를 사용하여 웹 서비스를 만들 수 있습니다. 이 서비스는 외부 시스템(ERP)에서 SOAP 또는 REST를 통해 호출됩니다.

**MuleSoft Anypoint** MuleSoft Anypoint의 의도는 엔터프라이즈급 API 관리를 제공하는 것입니다. MuleSoft Anypoint는 SAP, Oracle EBS, Oracle ERP 및 NetSuite를 비롯한 많은 ERP 시스템과 통합하는 데 사용할 수 있는 [대형 사전 구축 커넥터 세트를](https://www.mulesoft.com/platform/cloud-connectors) 제공합니다. 이러한 ERP 시스템에서 이벤트를 들을 수 있는 플로를 만들 수 있습니다(이 경우에는 새 연락처가 생성되는 경우). 플로가 시작되면 Salesforce 커넥터를 사용하여 새 연락처 레코드를 만들거나 연락처가 이미 있는 경우 업데이트합니다. 또한 복제 트랜잭션에 연락처를 다른 시스템으로 전파하는 작업이 포함된 경우, 다른 시스템과 연동할 수도 있습니다. 필요한 경우 매핑 및 변환 언어(DataWeave)를 사용하여 정보가 여러 이기종 시스템 간에 흐르는 동안 복잡한 논리와 계산을 수행할 수 있습니다. 이러한 시스템에 대한 인증은 기본 인증 및 OAuth 등 다양한 인증 메커니즘을 통해 수행할 수 있습니다. 플로우가 최대 사용량(vCore로 측정됨)에 맞게 적절하게 설계되었다면, 트랜잭션 볼륨에 제한은 없습니다.

**기본 Salesforce API** ERP 시스템의 업데이트 트랜잭션이 완료되면 SOAP API를 통해 연락처 개체에 대한 업서트 작업을 수행하거나 Salesforce 조직에서 Contact sObjects REST API에 대한 [PATCH를](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) 수행할 수 있습니다.

## Salesforce에서 Salesforce 통합

Salesforce to Salesforce 제품의 수명이 끝났습니다. Salesforce to Salesforce는 파트너들이 협력하여 공동 고객에게 판매하고 지원하는 것을 쉽게 해주었으나, Salesforce는 앞으로 다른 도구에 더 많은 혁신을 도입하는 데 투자할 예정입니다. 앞으로 Salesforce 조직 간 데이터 공유에 다음 접근 방식을 사용하는 것이 좋습니다.

### Salesforce 조직 간 데이터 통합을 위한 도구

<table>
    <thead>
        <tr>
            <th></th>
            <th>지침</th>
            <th>비용</th>
            <th>시기</th>
            <th>볼륨 및 규모</th>
            <th></th>
            <th></th>
            <th>배포 및 유지 관리</th>
            <th></th>
            <th>개인 정보 보호 및 보안</th>
            <th></th>
            <th>구현할 도구</th>
        </tr>
        <tr>
            <th></th>
            <th><strong>사용 시기</strong></th>
            <th><strong>추가 라이센스</strong></th>
            <th><strong>동기화(요청/응답) 또는 비동기(발신/무시)</strong></th>
            <th><strong>다중 개체 지원</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>테스트 및 구축*</strong></th>
            <th><strong>디버깅</strong></th>
            <th><strong>내장 오류 처리/재시도 동작</strong></th>
            <th><strong>휴지 상태에서 암호화된 데이터와 함께 사용할 수 있음</strong></th>
            <th><strong>인증 프로토콜</strong></th>
            <th><strong>로우 코드 → 프로 코드</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Salesforce 조직 전체에서 양방향 동기화를 통해 데이터를 확장하고 Heroku에서 실행되는 모바일 및 기타 앱의 데이터에 대한 액세스 권한도 활성화하려는 경우</td>
            <td>필수</td>
            <td>비동기</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>아니요</td>
            <td>프로 코드 도구 사용</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예, Shield Connect를 통해</td>
            <td>OAuth</td>
            <td>낮은 코드</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>통합을 구축, 오케스트레이션, 관리하기 위해 단일 엔터프라이즈급 통합 솔루션이 필요한 경우, 레거시 지점 간 아키텍처를 교체해야 하는 경우 또는 API 관리 지원이 필요한 경우</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td class="guide-table-ok">예**</td>
            <td>다중</td>
            <td>Pro 코드</td>
        </tr>
        <tr>
            <td><strong>기본 Salesforce API</strong></td>
            <td>Salesforce 또는 Heroku Connect가 옵션이 아니거나 더 복잡한 처리가 필요한 경우</td>
            <td>필수 아님</td>
            <td>모두</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>아니요</td>
            <td class="guide-table-ok">예**</td>
            <td>다중</td>
            <td>Pro 코드</td>
        </tr>
        <tr>
            <td><strong>Change Data Capture</strong></td>
            <td>Salesforce의 레코드 수준 변경 사항을 외부 시스템에 게시해야 하며 사용자 정의 페이로드가 필요하지 않은 경우</td>
            <td>필수</td>
            <td>비동기</td>
            <td>아니요</td>
            <td>아니요</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>OAuth</td>
            <td></td>
        </tr>
        <tr>
            <td><strong>Cross-Org 어댑터를 사용하는 Salesforce Connect</strong></td>
            <td>한 조직의 사용자가 데이터 복제 없이 다른 조직의 레코드를 보거나 편집하도록 하려는 경우</td>
            <td>필수</td>
            <td>비동기</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td>N/A</td>
            <td>N/A</td>
            <td>다중</td>
            <td>낮은 코드</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>한 조직의 사용자가 Data 360에서 복제된 데이터를 사용하여 다른 조직의 레코드를 보거나 편집하도록 하려는 경우</td>
            <td>필수</td>
            <td>모두</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>프로 코드 도구 사용</td>
            <td class="guide-table-ok">예</td>
            <td class="guide-table-ok">예</td>
            <td>다중</td>
            <td>하이브리드</td>
        </tr>
    </tbody>
</table>

\*테스트 및 배포는 낮은 환경에서 구축하고 [메타데이터 API](https://developer.salesforce.com/docs/metadata-coverage/), 패키지 또는 변경 집합을 통해 프로덕션에 배포할 수 있는 기능을 말합니다.

\*\*Shield Platform Encryption을 활성화하면 특정 동작이 변경됩니다. 자세한 내용은 [General Shield Platform Encryption Considerations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)를 참조하십시오.

_플랫폼 이벤트는 조직 간에 동일한 이벤트를 수신할 수 없으므로, 한 Salesforce 조직에서 다른 조직으로 데이터를 통합하는 데 최적의 방법이 아닙니다. 사용자 지정 Apex도 이 유형의 통합에 적합하지 않습니다._

### 사용 사례: 여러 Salesforce 조직 연결

> 대기업은 여러 사업부(BU)에서 운영됩니다. 각 BU에는 자체 Salesforce 조직이 있습니다. 단일 고객이 여러 사업부를 다루므로 여러 조직에 계정 및 기회 데이터를 보유합니다. 엔터프라이즈는 단일 조직의 모든 BU 전반에서 모든 계정 및 기회 데이터의 집계 보기에 액세스해야 합니다.

_참고: 아래의 모든 솔루션은 [Takeaway #1](#서비스)에 따라 최소한의 데이터 복제를 위해 설계되었습니다._

**Data 360** 계정 및 다양한 Salesforce 조직의 기회 데이터는 Salesforce 커넥터를 사용하여 Data 360에 수집할 수 있습니다. 이 데이터들은 필요한 경우 집계 및 조화될 수도 있습니다. 데이터가 Data 360에 집계되면 데이터 복제 없이 Data Cloud One을 사용하여 다른 Salesforce 조직에서 액세스할 수 있습니다.

**Heroku Connect** 각 BU의 개별 조직의 경우 Heroku Connect를 사용하여 Salesforce의 변경 사항을 단일 Heroku Postgres 데이터베이스에 동기화할 수 있습니다. 이 시나리오에서는 양방향 동기화가 활성화되지 않으며 Salesforce에서 Postgres로만 동기화됩니다. 그런 다음 Heroku Connect에서 OData 공급자를 활성화하고 집계 보기를 원하는 Salesforce 조직에서 외부 개체로 표시할 테이블을 선택할 수 있습니다. Salesforce 내에서 Heroku에서 OData 공급자를 가리키는 외부 데이터 소스를 정의합니다.

**MuleSoft Anypoint** MuleSoft Anypoint는 엔터프라이즈급 API 관리를 제공합니다. MuleSoft Anypoint API는 여러 조직에 대한 여러 연결이 있는 Salesforce 커넥터를 사용하여 여러 관련 Salesforce 조직의 정보를 읽도록 구성할 수 있습니다. MuleSoft 플로는 다양한 Salesforce 조직을 쿼리하고 필요한 경우 다른 타사 정보로 향상되거나 보강된 특정 구조를 반환할 수 있습니다. API가 호출되면 모든 적절한 Salesforce 조직 콜아웃(이 예에서는 계정 및 기회 정보 쿼리)을 수행하여, 주로 UI에서 데이터를 처리할 수 있도록 합니다. 이러한 시스템에 대한 인증은 기본 인증 및 OAuth를 비롯한 다양한 인증 메커니즘을 통해 수행할 수 있습니다. 플로의 최대 사용량(vCores 또는 Cores로 측정)에 맞게 적절하게 크기가 조정된 경우, 트랜잭션 수량에는 제한이 없습니다.

**네이티브 Salesforce API** 쿼리 작업은 각 대상 조직에 대해 발행할 수 있으며, 특히 수천 개의 레코드를 효율적으로 추출하는 데 적합한 Salesforce Bulk API 2.0을 통해 수행할 수 있습니다. 각 조직에서 쿼리 결과를 개별적으로 검색하고, 고객 요구 사항에 따라 사용자 지정 애플리케이션 또는 미들웨어로 집계할 수 있습니다.

**Salesforce Connect with Cross-Org 어댑터** Salesforce Connect Cross-Org 어댑터는 원격 조직의 계정 또는 기회가 모두 중앙 조직에 _다른_ 개체로 표시되므로 이 시나리오에 적합하지 않습니다. 예를 들어 모든 조직 전반에서 모든 기회의 총합계를 합산할 수 있는 방법은 없습니다.

**선택적 업데이트 Cross-Org 시나리오:** Salesforce 조직 A를 사용하는 판매 담당자는 조직 A에서 작업하는 동안 Salesforce 조직 B의 사례 데이터를 보고 업데이트하고 Salesforce 조직 B의 상위 사례에 사례 댓글을 추가해야 합니다. 데이터를 조직 A에 복제해서는 안 됩니다.

**Heroku Connect** 위의 _데이터 집계 시나리오_에서 설명한 것과 동일한 접근 방식을 사용할 수 있습니다. 그러나 OData 커넥터를 통해 외부 객체에서 CRUD를 활성화하고 변경 사항을 Heroku Postgres에 다시 작성해야 합니다.

**MuleSoft Anypoint** MuleSoft Anypoint는 엔터프라이즈급 API 관리를 제공합니다. 위의 _데이터 집계 시나리오_에 설명된 것과 동일한 접근 방식을 사용할 수 있습니다.

**Native Salesforce APIs** 명명된 자격 증명을 사용하고 네이티브 Salesforce API를 호출하여 관련 Salesforce 조직의 데이터를 읽고 업데이트하세요. 구성 요소는 데이터를 표시하도록 설계되어 있어야 합니다.

**Salesforce Connect with Cross-Org Adapter** 외부 개체에서 데이터를 볼 수 있는 기능(외부 개체에서 CRUD가 활성화된 경우 데이터를 편집하는 기능)은 [Salesforce cross-org 어댑터를 통해](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5) 지원됩니다. 외부 개체 간 관계도 지원되므로 외부 개체의 상위 사례에 연결할 수 있습니다. 그러나 관계 만들기는 기존 데이터 유형을 관계 데이터 유형으로 변환하는 수동 프로세스입니다. 또한 사례를 보다 효과적으로 처리하기 위해 Service Cloud 내에서 수행한 최적화는 원격 조직으로 전파되지 않습니다. Salesforce는 Cross-Org 어댑터를 테스트하고 사용 사례에 대해 외부 개체와 표준 개체를 사용할 때의 장단점을 평가할 것을 강력히 권장합니다.

**데이터 동기화 Cross-Org**: 조직의 사업부 Salesforce 조직 중 하나에서 고객 계정이 업데이트되면, 다른 Salesforce 조직의 계정 개체도 업데이트되어 일관된 계정 정보를 유지할 수 있습니다.

**Data 360** Data 360은 한 조직에서 다른 Salesforce 조직으로 데이터 복제에 사용할 수 있습니다. 단일 Salesforce 조직의 계정 데이터는 기본 Salesforce 커넥터를 사용하여 Data 360에 수집할 수 있습니다. 배치 활성화, 거의 실시간 데이터 작업 또는 API 기반 활성화와 같은 데이터 활성화 메커니즘을 사용하여 Data 360에서 Salesforce 조직으로 데이터를 이동할 수도 있습니다.

**Heroku Connect** 위의 _데이터 집계 시나리오_에서 설명한 것과 동일한 접근 방식을 사용할 수 있습니다. 그러나 양방향 동기화를 활성화해야 하며, 양방향 동기화는 Postgres 테이블을 변경할 때 모든 조직을 최신 상태로 유지하므로 더 이상 Salesforce Connect 활성화할 필요가 없습니다.

**MuleSoft Anypoint** MuleSoft Anypoint는 엔터프라이즈급 API 관리를 제공합니다. MuleSoft Anypoint에서 Flow Designer를 사용하여 표준 및 사용자 정의 오브젝트 이벤트를 수신하고, Salesforce에서 자동 실행 플로우를 시작하도록 [Mule 애플리케이션](https://docs.mulesoft.com/design-center/about-designing-a-mule-application)을 구성할 수 있습니다. Mule 앱이 트리거되면 Salesforce용 Anypoint 커넥터를 호출하여 여러 Salesforce 조직과 통신할 수 있습니다. 이 사용 사례에서 하나의 Salesforce 조직에서 계정 레코드가 업데이트되면 Mule 앱이 관련 Salesforce 조직의 계정 레코드를 업데이트할 수 있습니다. 각 관련 Salesforce 조직에는 MuleSoft의 전체 애플리케이션 플로우에 내장된 고유한 업데이트 단계가 있습니다. 이러한 시스템에 대한 인증은 기본 인증 및 OAuth를 비롯한 다양한 인증 메커니즘을 통해 수행할 수 있습니다. 최대 사용량(vCores 또는 Cores로 측정)에 맞게 플로우 크기가 적절하게 조정된 경우, 트랜잭션 용량에 대한 제한은 없습니다.

**Native Salesforce API** [복제 API](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm)(getUpdated, getDeleted 작업)를 사용하여 조직 간 데이터를 동기화할 수 있지만 이 접근 방식은 권장되지 않습니다.

**Salesforce Connect with Cross-Org Adapter** 레코드 트리거 플로 및 외부 개체를 사용하여 Salesforce 조직 간에 일부 데이터를 동기화 상태로 유지할 수 있습니다. 예를 들어, 조직 A의 계정 레코드를 업데이트하면 계정 외부 개체의 일치하는 레코드를 업데이트하는 플로가 트리거되며, 이는 이러한 업데이트를 조직 B의 계정 레코드에 씁니다. 이렇게 하면 [ 혼합 DML 트랜잭션](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1)을 피하기 위해 플로 시맨틱을 적절하게 사용해야 합니다. 또한 조직 B의 확인 규칙 및 플로는 REST/SOAP API에서 변경한 경우와 동일한 방식으로 트리거됩니다.

## 마감 주석

Salesforce와 관련된 새 데이터 통합을 계획할 때 이 가이드에 유의하십시오. 사용 가능한 옵션의 전체 범위와 특정 사용 사례에 맞는 방법을 이해하는 것이 좋습니다.

### 의견을 알려주십시오.

가장 관련성이 높은 내용을 게시하고 있는지 우리가 확인할 수 있도록 도와주세요. 이 콘텐츠에 대한 피드백을 제공하고 다음에 원하는 내용을 알려주려면 [원하는 설문 조사를 수행하십시오](https://sfdc.co/J0cWb).

<!-- document id=18f0f18eb2579ed2b3eaa03e283060f3e41766d198b14626b3eab872580c98fb url=/architect/current/ko-kr/decision-guides/guides/build-forms.md -->

# 건물 양식

Agentforce 360 플랫폼에서는 로우코드부터 프로 코드 접근 방식에 이르기까지 양식을 작성할 수 있는 여러 가지 옵션이 있습니다. 한쪽 끝에서는 Lightning 앱 빌더의 동적 양식과 Flow Builder의 화면 플로우를 로우코드 솔루션으로 사용할 수 있습니다. 반면에 Lightning Web Component(LWC) 프레임워크는 프로 코드 솔루션에 사용됩니다. 연속 범위 내에서, LWC로 확장된 화면 플로우와 Omnistudio로 구축된 고객용 양식을 활용하여 여러 가지 방식으로 도구를 조합할 수 있습니다.

## 가이드 개요

이 가이드는 UI 솔루션 양식 작성에 대한 결정 프레임워크 및 지침을 제공합니다. 특히 12개의 런타임 및 비기능적 결정 지점을 사용하여 주어진 사용 사례에 가장 적합한 기술을 적절하게 선택합니다.

## 서비스

- **Lightning 페이지에 대한 만들기/편집/보기 레이아웃을 작성할 때 동적 양식을 사용하십시오.** 앞으로 _Lightning 앱 빌더_에서 _동적 양식_을 사용하여 레코드 세부 사항 페이지를 구성하는 것이 좋습니다.

- **한 개체에 대한 양식을 작성, 생성 또는 편집해야 하는 경우 _Lightning 페이지_ 및 _동적 양식_을 사용합니다.** Agentforce 360 플랫폼에서 양식을 작성하는 가장 쉬운 방법입니다. 또한 추가 기능(예: 필드 가시성 제어)을 제공합니다.

- **다중 페이지 양식 또는 마법사를 작성하고 있으며 엄격한 UX 또는 브랜딩 요구 사항이 없는 경우 화면 플로를 사용하십시오.** 화면 플로는 여러 양식을 오케스트레이션할 수 있는 선형 탐색 프레임워크를 제공합니다. LWC를 사용해 양식 간 탐색을 위한 자체 프레임워크를 구성할 수도 있지만, 양식 상태에 집착하기보다 양식 자체에 집중할 수 있도록 플로우에 작업을 맡기는 것을 권장합니다.

- **양식을 지원하는 추가 논리 또는 작업이 필요한 경우, 스크린 플로우, Omnistudio 또는 LWCs를 사용하십시오.** 이러한 각 도구는 단일 레코드 만들기 또는 편집 이상으로 솔루션을 확장할 수 있도록 하여 솔루션을 향상할 수 있는 다양한 방법을 제공합니다. 이 경우 _더_ 많은 용어는 고급 논리(예: 분기 또는 반복)를 참조하거나 외부 시스템과 통합, 이메일 보내기 또는 사용자의 모바일 앱에 알림 푸시와 같은 작업을 참조할 수 있습니다.

- **고급 UX 요구 사항이 있거나 UI 가시성 이상을 동적으로 관리해야 하는 경우 LWC 또는 Omniscript를 사용하십시오.** 테마 및 열 기반 레이아웃을 사용하여 충족할 수 있는 요구 사항의 경우 로우코드 빌더에서 직접 양식을 작성할 수 있습니다. 그러나 양식의 스타일을 세부적으로 제어하려면 LWC의 유연성이 필요합니다. 산업 고객인 픽셀 퍼펙트 브랜딩이 필요하거나 복잡한 계층 데이터가 있는 경우 Omnistudio를 사용하여 복잡한 비즈니스 논리 및 데이터 변환을 처리할 수 있는 소비자급 양식을 구축할 수 있습니다.

- **테스트 자동화를 배포해야 하는 경우 LWC를 사용하십시오.** 포함할 위치와 상관없이 LWC에 대한 단위 테스트를 작성할 수 있습니다. 이를 통해 더 강력한 테스트 전략을 만들 수 있습니다. 여기에는 여러 레코드가 있는 대량 테스트와 음수 테스트가 포함될 수 있습니다.

- **“양자택일” 결정에 얽매이지 않습니다.** 여러 옵션을 결합하여 사용 사례에 가장 적합한 솔루션을 찾을 수 있습니다(예: 플로의 내장형 탐색 시스템 및 LWC에서 제공하는 전체 스타일 지정 유연성이 필요한 경우 함께 사용할 수 있음).

## 범위의 도구

다음 도구는 일반적으로 양식 환경을 구현하고 확장하는 데 사용됩니다.

### 도구 설명

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">동적 양식</th>
<th colspan="1" rowspan="1"><a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Salesforce Lightning 앱 빌더</a>의 <a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_migrate.htm&language=en_US&type=5">동적 양식</a>은 단일 레코드 세부 사항 구성 요소를 개별 구성 가능한 필드 및 섹션으로 분할합니다. 이 기능을 사용하면 관리자가 어디서나 필드를 배치하고 가시성 규칙을 사용하여 사용자 프로필, 장치 또는 데이터를 기반으로 구성 요소를 표시하거나 숨길 수 있어 유연한 고성능 페이지를 만들 수 있으므로 페이지 복잡성을 줄일 수 있습니다.</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">Salesforce <a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">스크린 플로</a>는 사용자가 사용자 정의된 단계별 비즈니스 프로세스를 수행하기 위해 입력해야 하는 <a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">Flow Builder</a> 내의 대화형 자동화 도구입니다. 자동화된 백그라운드 플로와 달리 화면 플로는 마법사와 유사한 사용자 인터페이스를 제공하여 코드를 작성하지 않고 데이터를 수집하고 정보를 표시하거나 <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_page_overview.htm&type=5">Lightning 페이지</a>, 버튼 또는 사용자 정의 앱을 통해 작업을 수행할 수 있습니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Salesforce <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omnistudio_standard.htm&type=5">Omnistudio</a>는 산업별로 안내된 디지털 환경 및 복잡한 비즈니스 프로세스를 신속하게 구축할 수 있도록 설계된 로우코드 도구 제품군입니다. 이를 통해 개발자는 픽셀 완벽한 사용자 인터페이스(예: 안내 워크플로 및 동적 대시보드)를 만들 수 있으며, <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_flexcardsbasics_8118.htm&type=5">Flexcards</a> 및 <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">Omniscripts</a>와 같은 끌어서 놓기 구성 요소를 사용할 수 있습니다. Omnistudio를 사용하면 LWC를 선언적으로 만들 수 있습니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Lightning 웹 구성 요소</strong></td>
<td colspan="1" rowspan="1">Salesforce <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">Lightning 웹 구성 요소</a>는 HTML, CSS 및 최신 JavaScript를 사용하여 구축된 가볍고 사용자 정의 HTML 요소로, 브라우저에서 네이티브로 실행되도록 설계되어 뛰어난 Salesforce UI 성능을 제공합니다. 이를 통해 개발자는 <a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Aura</a> 구성 요소와 함께 존재하는 맞춤형 사용자 인터페이스를 만들 수 있으며, 이는 업계 표준 및 세부적인 구성 요소 생태계를 통해 개발을 촉진합니다.</td></tr></table>

### 도구 기술 집합 및 라이센스 요구 사항

이 표는 Salesforce를 통해 양식을 작성하는 데 사용할 수 있는 도구와 필수 기술 및 라이센스 고려 사항을 간략하게 보여줍니다.

**참고:** 각 도구에 대해 지원되는 특정 기능, 클릭 기반 도구와 코드 기반 도구 간에 선택하는 방법, 나중에 섹션에서 결합할 시기를 자세히 살펴보겠습니다.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">구성</th>
<th colspan="1" rowspan="1">추가 라이센스 요구 사항</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">낮은 코드</td>
<td colspan="1" rowspan="1">없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">낮은 코드</td>
<td colspan="1" rowspan="1">없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">로우코드 + 프로 코드</td>
<td colspan="1" rowspan="1">산업 패키지</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우와 Lightning 웹 구성 요소</strong></td>
<td colspan="1" rowspan="1">로우코드 + 프로 코드</td>
<td colspan="1" rowspan="1">없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Lightning 웹 구성 요소</strong></td>
<td colspan="1" rowspan="1">Pro 코드</td>
<td colspan="1" rowspan="1">없음</td></tr></table>

## 결정 지점

제품 및 도구를 선택할 때 유의해야 할 몇 가지 결정 사항이 있습니다. 이 표는 다양한 결정 지점을 간략하게 보여주며 상위 수준 지침을 제공합니다.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">결정 지점</th>
<th colspan="1" rowspan="1">지침</th></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>런타임 사용 사례 범주</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>양식 범위 및 탐색</strong></td>
<td colspan="1" rowspan="1">양식의 모든 필드가 논리적으로 하나의 화면에 배치될 수 있는지, 또는 사용자가 여러 화면을 이동할 수 있어야 하는지 확인합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>위치</strong></td>
<td colspan="1" rowspan="1">Salesforce 앱 내에서 모바일 앱, 외부 웹 사이트에 이르기까지 양식을 포함할 위치를 식별합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>컨트롤러</strong></td>
<td colspan="1" rowspan="1">데이터 변환 및 외부 시스템과의 통합 등 사용자가 양식과 상호 작용하는 동안 백그라운드에서 수행해야 하는 작업 또는 논리를 식별합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>유효성 검사</strong></td>
<td colspan="1" rowspan="1">Salesforce에서 제공하는 표준 시스템 수준 확인을 넘어 추가 입력 확인 요구 사항이 있는지 확인합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>상호 작용 설계</strong></td>
<td colspan="1" rowspan="1">양식 내에서 동적 응답을 트리거해야 하는 상호 작용 또는 조건 유형을 식별합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스타일링</strong></td>
<td colspan="1" rowspan="1">원하는 스타일 및 CSS 요구 사항에 필요한 정교함 수준을 결정합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>레이아웃</strong></td>
<td colspan="1" rowspan="1">양식의 레이아웃 요구 사항(예: 필수 열, 탭 및 아코디언 수) 및 반복 데이터 블록을 표시할 수 있는 기능을 식별합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>번역</strong></td>
<td colspan="1" rowspan="1">양식을 다른 언어로 현지화해야 하는지 여부를 결정합니다.</td></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>비기능적 고려 사항</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>보안</strong></td>
<td colspan="1" rowspan="1">특정 작업을 수행하기 전에 양식에서 사용자의 액세스를 확인해야 하는지, 양식에 액세스할 수 있는 사람을 제어할 것인지, 양식이 포함될 수 있는 위치를 제어할 것인지 여부를 결정합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>개체 영향</strong></td>
<td colspan="1" rowspan="1">양식이 단일 개체 또는 여러 개체에 대해 작동하는지 결정합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>UI 테스트 자동화</strong></td>
<td colspan="1" rowspan="1">DevOps 프로세스에 따라 양식이 자동 단위 테스트 또는 자동 종단간 테스트를 받아야 하는지 결정합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Metrics</strong></td>
<td colspan="1" rowspan="1">페이지 보기, 양식에 소요된 시간, 완료율, 성공률 등 양식 사용을 추적할 방법을 식별합니다.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>포장 및 배포</strong></td>
<td colspan="1" rowspan="1">양식을 작성한 후 어떻게 배포할지 결정합니다.</td></tr></table>

**참고:** 후속 결정 비교 테이블에는 도구-기능 쌍과 연결된 몇 가지 값이 있습니다.

- **사용 가능:** 도구/기능은 기본 고려 사항에 따라 작동합니다.

- **사용 불가:** 향후 12개월 이내에 지원을 추가할 계획이 없습니다.

- **이상적이지 않음:** 이 도구/기능은 작동할 수 있지만 최적의 도구는 아닙니다.

- **해당 안 함:** 이 도구는 특정 사용 사례에 적용되지 않습니다.

## 사용 사례

다음 시나리오를 사용하여 범위, UX, 운영 요구 사항을 기준으로 도구 선택을 비교합니다.

### 양식 범위 및 탐색

단일 화면 양식에서 모든 사용자 입력을 가져올 수 있는 경우 동적 양식부터 시작합니다. 레코드 페이지의 동적 양식은 단계화된 비즈니스 프로세스를 지원하기 위해 경로 기능을 사용할 수 있다는 점에 유의하십시오.

#### 질문할 질문

- 단일 화면이 필요합니까? 과업을 완료하려면 사용자가 여러 화면 사이를 탐색해야 합니까?

- 사용자가 양식을 작성할 때 프로세스 진행 상황을 시각적으로 보여주도록 하시겠습니까? 사용자가 각 화면의 정보를 특정 순서로 작성해야 하거나 필요에 따라 화면 간에 앞뒤로 이동할 수 있어야 합니까?

동적 양식에서 제공하는 것보다 더 많은 기능이 필요한 경우 몇 가지 추가 질문에 따라 플로, Omnistudio, LWC 중에서 선택할 수 있습니다.

- 양식 하단에 내비게이션 바를 표시해도 괜찮습니까? 스크린 플로우와 OmniScript 탐색 환경이 바람직하지 않은 사용자 경험을 제공한다면, LWC를 고려하십시오.

- 양식 뒤에 수행해야 하는 작업은 무엇입니까? 관리자가 동작을 구성할 수 있어야 하는 경우 플로를 사용합니다. 복잡한 다중 개체 관계의 경우 _Omniscript_ 또는 _LWC_를 사용하십시오.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">단일 화면</th>
<th colspan="1" rowspan="1">다중 화면 양식</th>
<th colspan="1" rowspan="1">진행률 지표</th>
<th colspan="1" rowspan="1">단계/화면 간에 이동 탐색</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">이상적이지 않음</td>
<td colspan="1" rowspan="1">이상적이지 않음</td>
<td colspan="1" rowspan="1">이상적이지 않음</td></tr></table>

플로 또는 Omnistudio를 선택하는 경우 올바른 UX를 달성하기 위해 LWC를 구축해야 할 수도 있습니다. 양식의 스타일을 올바르게 지정하기 위해 LWC를 이미 구축하는 경우 플로에 해당 구성 요소를 [포함해야 하는지](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow) 고려하십시오.

**마법사 스타일의 탐색**

반면, 솔루션이 마법사처럼 보여 사용자가 여러 화면 사이를 탐색해야 한다면 플로 또는 Omnistudio를 고려하십시오. 플로 및 Omnistudio는 내장된 탐색 모델을 사용하므로 함께 연결된 LWC를 구축하고 유지할 필요가 없습니다. 탐색은 선형이며 앞으로 이동하는 작업, 뒤로 이동하는 작업 및 나중에 양식을 저장할 수 있는 메커니즘이 있습니다. 목적에 맞는 경우 비선형 탐색을 사용하여 양식을 작성할 수도 있습니다.

Omnistudio는 양식 내에 단계를 표시하는 표준 탐색의 진행률 표시기를 제공하여 주요 탐색 이점을 제공합니다. 단계 보기에 사용자가 다단계 양식에 있는 위치가 자동으로 표시됩니다. 플로와 달리 사용자는 양식 전체에서 다양한 단계를 클릭하여 화면 간에 이동할 수 있습니다.

단일 화면 또는 다중 화면 양식을 작성하는 경우 사용자가 쉽게 탐색할 수 있도록 양식을 간소화해야 합니다.

### 양식 요소

표준 Lightning 레코드 페이지에 양식을 포함하는 경우 비교한 모든 도구가 작동합니다. 그러나 동적 양식은 현재 데스크톱에서만 사용할 수 있습니다. 사용자가 다른 위치에서 양식에 액세스할 수 있는 환경을 제공하려면 대체 옵션을 고려해야 할 수 있습니다.

#### 질문할 질문

- 사용자가 데스크톱, 모바일 또는 둘 모두를 통해 양식에 액세스해야 합니까?

- 사용자가 유틸리티 막대를 통해 앱의 모든 위치에서 양식에 액세스할 수 있어야 합니까?

- 사용자가 현재 있는 페이지를 떠나지 않고도 양식을 작성할 수 있도록 빠른 작업을 활성화하시겠습니까?

- 외부 웹 사이트에서 양식을 사용할 수 있어야 합니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Lightning 레코드 페이지</th>
<th colspan="1" rowspan="1">Lightning 홈페이지 또는 앱 페이지</th>
<th colspan="1" rowspan="1">Aura Experience Cloud 사이트</th>
<th colspan="1" rowspan="1">LWR Experience Cloud 사이트</th>
<th colspan="1" rowspan="1">내장형 Snap-Ins</th>
<th colspan="1" rowspan="1">유틸리티 막대</th>
<th colspan="1" rowspan="1">개체별 작업</th>
<th colspan="1" rowspan="1">글로벌 작업</th>
<th colspan="1" rowspan="1">Salesforce 모바일 앱*</th>
<th colspan="1" rowspan="1">Field Service 모바일</th>
<th colspan="1" rowspan="1">모바일 SDK</th>
<th colspan="1" rowspan="1">외부 사이트 및 앱</th>
<th colspan="1" rowspan="1">사용자 정의 LWC</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능**</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">이상적이지 않음</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="14" rowspan="1" style="border-right: 1px solid #d8dde6;">*플로 및 LWC는 Salesforce 모바일 앱에서 지원되지만 플로 및 LWC를 포함하는 모든 방법은 지원되지 않습니다(예: 모바일에서는 개체별 작업이 지원되지만 유틸리티 막대 항목은 지원되지 않음).<br><br>**Salesforce Field Service 모바일 앱에는 최신 플로 기능을 지원하는 전용 오프라인 런타임이 있는 플로 엔진에 구축된 오프라인 우선 양식 솔루션인 데이터 수집 포함되어 있습니다. 앱에는 오래된 사용자 정의 오프라인 엔진에서 실행되고 많은 최신 플로 기능을 지원하지 않는 레거시 Field Service Mobile 플로도 포함되어 있습니다.</td></tr></table>

레코드 컨텍스트가 필요하므로 동적 양식 기능은 Lightning 레코드 페이지에서만 지원됩니다. 그러나 Experience Cloud 페이지에서는 동적 양식이 지원되지 않습니다.

레코드 컨텍스트가 필요한 플로우 또는 전역적으로 작동하는 플로우를 구축할 수 있습니다. 다시 말해 다양한 위치에 플로우를 포함할 수 있습니다. 레코드 컨텍스트 플로우의 경우 위치에 다음이 포함될 수 있습니다. Lightning 레코드 페이지, Experience Cloud 레코드 페이지, 개체별 작업 또는 작업 및 권장 사항 배포 전역 플로의 경우, 위치에는 유틸리티 바, 다른 Lightning 또는 Experience Builder 페이지, Snap-ins, 또는 외부 애플리케이션이 포함될 수 있습니다. 현재 플로는 전역 작업으로 지원되지 않지만, 해결 방법으로 _Aura_ 구성 요소에 _플로를_ 래핑할 수 있습니다.

Omnistudio를 사용하면 구성 가능한 FlexCard 및 Omniscripts를 구축할 수 있으며, 플로를 배치할 수 있는 _거의_ 모든 위치에 배치할 수 있지만, 구성 가능한 경우에는 패키지화할 수 없습니다.

LWC는 Salesforce, 커뮤니티, 오픈 소스 프로젝트 전반에서 메타데이터를 통해 대상과 연결할 수 있는 구성 요소를 만드는 데 높은 수준의 재사용성을 제공합니다. LWC 구성 요소는 [Lightning Out 2.0](https://developer.salesforce.com/docs/platform/lwc/guide/lightning-out-intro.html)을 사용하여 자체 웹사이트에 포함할 수도 있습니다.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-locationnoheader.png" alt="Lightning Out on External Sites" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

LWC 구성 요소는 [Lightning-Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation) 구성 요소를 사용하여 플로를 시작할 수도 있습니다.

Omnistudio는 OmniOut 기능을 통해 외부 사이트에 콘텐츠를 노출하는 데 우수합니다. Omnistudio 및 OmniOut을 사용하면 Omniscript 양식 및 FlexCard 구성 요소를 표준 구성 요소로 컴파일한 다음, 타사 사이트 또는 앱에서 플랫폼 외부에서 실행할 수 있습니다.

현재 이 가이드에 포함된 양식 기술은 Mobile SDK 템플릿에서 공식적으로 지원되지 않습니다. Mobile SDK가 사용 사례에 필수적인 경우 양식을 기본적으로 모바일 응용 프로그램에 구축하거나 Visualforce 페이지를 구축하는 것이 좋으며 양식 요소를 염두에 두는 것이 좋습니다.

### 논리

동적 양식은 양식에서 값을 사용하여 레코드를 만들거나 업데이트해야 하는 경우에 적합합니다. 결정 또는 반복 레이어 만들기 또는 양식의 입력을 사용하여 Slack 게시물 또는 이메일을 생성하는 등 해당 범위를 벗어나는 기능에 대해 플로, Omnistudio 또는 LWC를 활용해야 합니다.

#### 질문할 질문

- 백그라운드에서 수행해야 하는 작업 또는 논리는 무엇입니까?

- 관련 레코드의 값을 사용해야 합니까?

- 단일 트랜잭션 또는 여러 트랜잭션에서 양식의 작업을 완료해야 합니까?

- 외부 시스템과 통합해야 합니까?

- 재사용 가능성 및 모듈성에 대한 요구 사항은 무엇입니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">로그 및 작업</th>
<th colspan="1" rowspan="1">계층적 데이터 관리</th>
<th colspan="1" rowspan="1">단일 트랜잭션 내 작업</th>
<th colspan="1" rowspan="1">여러 트랜잭션에서 작업 수행</th>
<th colspan="1" rowspan="1">통합</th>
<th colspan="1" rowspan="1">모듈식 설계 및 재사용</th>
<th colspan="1" rowspan="1">패키징</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr></table>

Flow는 Slack에 게시, 이메일 보내기 및 Quip 문서와 상호 작용을 위한 표준 작업을 제공하며, 이러한 작업에 코드를 작성할 필요가 없습니다. LWC는 [사용자 인터페이스 API](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm)와 상호 작용하는 유선 어댑터를 통해 단일 레코드 및 관련 객체와 풍부한 상호 작용을 제공합니다. LWC는 [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html)의 유선을 사용하여 여러 레코드와 상호 작용할 수도 있습니다.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-controllernoheader.png" alt="LWC Interaction via Wire Adapters" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Omnistudio는 통합 절차와 데이터 매퍼를 사용하여 Salesforce 내부와 외부의 데이터를 가져오고 변환합니다. 수많은 코드 없는 기능 덕분에 다양한 수준의 관계를 가진 데이터 집합을 평탄화하고 확장하는 데 뛰어납니다.

플로, Omnistudio, LWC는 모두 Apex 통합되므로 선택한 솔루션 내에서 간편하게 공백을 닫을 수 있습니다(예: LWC에서 레코드를 필터링해야 하는 경우 Apex 유선 어댑터를 사용하여 복잡한 SOQL 쿼리를 만들 수 있습니다). 클릭 기반 스토리로 인한 영향을 받는 경우 서버 측의 요구에 맞게 Apex 컨트롤러를 대체하는 실용적인 대안으로 Flow 또는 Omnistudio를 사용하는 것이 좋습니다.

또한 작업을 즉시 커밋할 것인지 또는 작업을 양식의 특정 부분으로 연기할 것인지 고려해야 합니다. 이는 다중 페이지 양식을 사용하는 경우 특히 유용합니다. Flow를 사용하면 여러 양식(Flow 화면)의 입력을 쉽게 결합하고, 나중에 마법사(Flow)에서 이를 사용하여 특정 작업을 수행할 수 있습니다. 이것이 바로 Flow를 설계할 때 권장하는 방식입니다. 마지막 단계에서 작업을 수행합니다(사용자가 답변을 변경하기 위해 화면 간에 왔다 갔다 할 경우).

#### 작업 제어

트랜잭션 및 [관리자 제한](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)은 Agentforce 360 플랫폼의 일부입니다. 사용 사례가 상당히 간단한 경우 특정 작업이 발생하는 트랜잭션을 제어하는 것이 중요하지 않을 수 있습니다. 그러나 여러 작업을 여러 트랜잭션에서 수행하는 대신 여러 작업을 하나의 [트랜잭션](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#트랜잭션)에 결합하려는 몇 가지 사용 사례가 있습니다.

다음은 몇 가지 예시입니다.

- **롤백:** 양식이 백그라운드에서 여러 레코드를 생성한다고 가정합니다. 세 번째 레코드 생성에 실패할 경우 처음 두 개의 레코드를 롤백해야 합니까? 각 작업이 서로 독립적인 경우 별도의 트랜잭션으로 실행할 수 있습니다. 그러나 서로 종속되어 있으며 하나의 실패로 다른 하나도 롤백되도록 하려는 경우 단일 트랜잭션으로 구현해야 합니다. 양식이 Flow에 있는 경우 오류 경로의 롤백 요소를 사용하여 트랜잭션을 롤백하고 데이터 무결성을 보장할 수 있습니다.

- **거버너 제한에 대한 다운스트림 영향:** 양식에서 레코드를 만들거나 업데이트할 때 해당 작업의 다운스트림 영향을 고려해야 합니다.

  - 제안된 레코드 변경 사항을 기반으로 저장 순서 내의 어떤 프로세스, 워크플로 규칙, Flow 트리거, Apex 트리거 또는 기타 항목이 실행될 수 있습니까?

  - 이러한 집합 변경 사항은 해당 트랜잭션 내에서 소비되는 거버너 제한에 어떤 영향을 미칩니까?

  - 특정 레코드 변경으로 인해 제한에 영향을 미치는 많은 다운스트림 변경 사항이 발생할 수 있는 경우 자체 트랜잭션 내에서 해당 레코드 변경 사항을 분리하는 것이 가장 좋습니다.

- **배치 처리:** 여러 업데이트를 함께 배치해야 할 수도 있습니다 (UI 컨텍스트 내에서도). 다중 화면 양식이 대규모 레코드 그룹을 대상으로 반복 처리되는 경우, 각 화면 이후에 레코드 업데이트를 커밋하는 대신 모든 레코드에 대한 업데이트를 수집할 때까지 기다린 다음, 모든 레코드를 업데이트하기 위한 하나의 요청을 제출합니다.

동적 양식을 사용하여 레코드를 만들거나 편집하는 경우 하나의 작업만 수행하고 해당 작업은 항상 순 새 트랜잭션의 시작입니다.

스크린 플로우를 구축할 때, 지정된 트랜잭션 내에서 발생하는 일을 상당히 제어할 수 있습니다. 화면 및 로컬 작업은 트랜잭션 간 경계 역할을 합니다. 다음은 화면 플로 아키텍처 내에서 트랜잭션이 관리되는 방법에 대한 상위 수준 요약입니다.

1. 최종 사용자가 화면과 상호 작용한 다음, **다음**을 클릭합니다.

2. 클라이언트가 API에 입력 요청을 게시합니다.

3. API가 요청을 수신하고 트랜잭션 및 데이터베이스 연결을 엽니다. 그런 다음, API는 플로 엔진을 호출하여 요청을 처리합니다.

4. Flow 엔진이 제어를 넘겨받아 Flow 정의의 적절한 경로를 따라 진행하다가 화면 또는 로컬 작업 노드에 도달하면 멈춥니다. 그런 다음, 엔진이 해당 노드에 대한 정보를 API에 반환합니다.

5. API가 렌더링할 다음 화면의 세부 사항을 포함하는 응답 개체를 만들고 클라이언트에게 해당 개체를 반환합니다. 이 시점에서 데이터베이스 변경이 커밋되고([저장 주문 실행](/docs/architect/ko-kr/fundamentals/guide/architecture-basics#데이터베이스-조작)) 데이터베이스 연결 및 트랜잭션이 종료됩니다.

6. 클라이언트가 API 응답을 사용하여 사용자가 상호 작용하는 다음 화면을 렌더링합니다.

7. 1단계에서 시작하고 프로세스를 반복합니다.

즉, 화면은 트랜잭션을 _끊습니다_. 이러한 경우 보류 중인 작업 또는 DML이 커밋되고 이전 트랜잭션이 마감되고 새 트랜잭션이 시작됩니다.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow1.png" alt="multi-screen flow" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
특정 설계 요소(지정된 트랜잭션으로 그룹화하는 작업)는 사용자가 결정한다는 점에 유의하십시오.

다음은 몇 가지 예시입니다.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow2.png" alt="screen flow with separate transactions" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

- 시작하면 여러 화면에서 입력을 수집한 다음, 하나의 트랜잭션 내에서 여러 작업을 수행하는 플로가 표시됩니다.
- 다음 Flow는 별도의 트랜잭션에서 각 작업을 수행합니다.
- Flow는 Roll Back Records 요소를 사용하여, 일련의 데이터베이스 작업 중 단일 작업이 실패할 경우 전체 트랜잭션을 롤백할 수 있도록 합니다.
  <image src="https://architect.salesforce.com/ns-assets/guide-forms-flow3.png" alt="Screen Flow with multiple create records" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
  레코드를 생성하고, 레코드를 업데이트한 다음, 추가 레코드를 생성하는 플로가 있다고 가정합니다(다음 플로에 표시).

이 시나리오에서 처음 두 요소가 성공하고 마지막 요소가 실패하면, 처음 두 DML 작업은 계속해서 적절한 레코드를 생성하고 업데이트하지만, 세 번째 작업은 실패합니다.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow4.png" alt="Screen Flow with Rollback" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
레코드 롤백 요소를 사용하면 세 가지 작업을 모두 함께 수행해야 하는 경우(최종 Flow에 표시된 것처럼) 전체 트랜잭션이 롤백되는지 확인할 수 있습니다.

**참고:** 자세한 내용은 [트랜잭션 플로](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm) 및 [트랜잭션 플로 대량 처리](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm)을 참조하십시오.

LWC에서 트랜잭션을 제어하는 기능은 LWC가 작업을 수행하는 데 사용하는 기본 서비스를 기반으로 합니다. Lightning 기본 구성 요소를 사용하는 경우 양식이 제출될 때 기본 작업(레코드 만들기 또는 업데이트)이 독립형 트랜잭션 내에서 수행됩니다.

일반적으로 다음 규칙이 적용됩니다.

- 각 UI API 호출은 자체 트랜잭션 내에서 분리됩니다.

- 단일 트랜잭션 내에서 여러 작업을 수행해야 하는 경우 입력 내용을 서버측 기술(예: Apex 컨트롤러 또는 플로)로 보냅니다. 해당 기술에 대한 정기 트랜잭션 규칙이 계속 적용됩니다.

#### 외부 통합

Flow, Omnistudio 및 LWC는 모두 플랫폼 이벤트([이벤트 기반 아키텍처](/docs/architect/ko-kr/decision-guides/guide/event-driven)) 및 API 통합을 지원합니다. 사용자 지정 Apex 코드 외에도 Flow 및 Omnistudio에는 API와 통합할 수 있는 선언적 지원 메커니즘이 있습니다.

MuleSoft API 또는 RPA Bot에 연결해야 하는 경우 외부 서비스를 생성하므로 MuleSoft 서비스를 사용하십시오.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-mulesoftnoheader.png" alt="External integrations via MuleSoft" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

API에 OpenAPI 스키마가 있는 경우 외부 서비스를 만듭니다.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-openapi-noheader.png" alt="External Integrations via OpenAPI" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

다른 모든 인스턴스의 경우 플로의 **HTTP 콜아웃** 기능(외부 서비스에서 제공) 또는 Omnistudio의 **HTTP 작업**을 사용합니다.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-callouts-noheader.png" alt="External integrations via HTTP" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Omnistudio는 데이터 매퍼를 통해 데이터를 변환하기 위해 통합 절차를 사용하여 외부 시스템에 콜아웃할 수 있는 다양한 통합 기능을 제공합니다.

구현을 위해 사용자 정의 Apex 코드 또는 외부 서비스를 사용하든 상관없이 **콜아웃**은 여전히 콜아웃입니다.

다음은 알아야 할 사항입니다.

- 콜아웃을 처리하는 데 상당한 시간이 걸릴 수 있습니다.

- 콜아웃이 동기식으로 실행되면 데이터베이스 트랜잭션이 열려 있는 동안 수행됩니다.

- 보류 중인 데이터베이스 작업이 있는 경우 Salesforce에서 데이터베이스 트랜잭션을 열어 둘 수 없습니다.

주된 제한 사항은 데이터가 일관되지 않은 상태로 남아 있는 위험입니다. 이는 동일한 트랜잭션 내에서 **생성**, **업데이트** 또는 **삭제** 작업을 수행한 다음, **콜아웃**을 수행할 때 발생합니다. 위에서 언급한 세 번째 고려 사항이 있으므로 이 패턴은 처음 두 가지 고려 사항으로 인해 허용되지 않습니다.

플로에서 트랜잭션을 중단하여 이 제한을 무시할 수 있습니다. 화면 및 로컬 작업이 브라우저 컨텍스트를 다시 도입한다는 점에 유의하십시오. 외부 콜아웃으로 작업할 때 화면 및 로컬 작업을 사용할 수 있지만 호출 가능한 고급 설정에서 **트랜잭션 제어**를 활성화하는 것이 좋습니다. 트랜잭션 관리를 사용하면 콜아웃을 만들기 전에 트랜잭션을 자동으로 종료할 수 있습니다. 트랜잭션 제어를 활성화하려면 호출된 작업의 **고급** 섹션에서 "**항상 새 트랜잭션 시작**"을 선택합니다.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow5.png" alt="External Integrations via Callouts" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
LWC는 트랜잭션에 대한 콜아웃의 영향을 간소화하는 데 도움이 됩니다. 즉, Lightning 데이터 서비스(LDS)를 사용하여 데이터 작업을 수행한 다음, Apex 컨트롤러를 사용하여 외부 콜아웃을 수행합니다. LDS 호출은 자체 트랜잭션 내에서 (Apex 콜아웃과 별도로) 분리되므로 결과적으로 데이터 불일치가 발생하지 않도록 보호합니다.

#### 재사용 가능성 및 모듈화

동적 양식은 재사용을 지원하지 않습니다. 각각은 특정 개체에 대한 특정 Lightning 레코드 페이지에 연결되어 있지만, 여러 앱, 프로필 등에 해당 Lightning 레코드 페이지를 할당할 수 있습니다.

여러 구성 요소에서 사용할 수 있는 라이브러리, 유틸리티 및 구성 요소를 작성하는 방식과 마찬가지로 **하위 플로**의 기능을 활용하여 플로를 만들 때 유사한 디자인 패턴을 적용할 수도 있습니다. 이렇게 하려면 플로를 더 작은 모듈식 버킷에 저장한 다음, **하위 플로** 요소를 사용하여 다른 플로에서 호출합니다. 설계에 따라, 하나의 플로우를 독립적으로도, 서브플로우로도 유용하게 만들 수 있습니다.

Omnistudio는 기본적으로 모듈성을 위해 구축되었습니다. Data Mapper, OmniScript, FlexCard, 그리고 Integration Procedure는 모두 독립적으로 구축되지만, 상호 교환적으로도 작동할 수 있습니다. FlexCard는 다른 LWC, Omniscript, 레코드 페이지, Experience Cloud 사이트 내에 포함할 수 있는 LWC 구성 요소로 구축할 수도 있습니다.

화면 플로, Omniscript 및 LWC는 모두 외부 사이트 및 Lightning Out 애플리케이션을 비롯한 다양한 위치 내에서 재사용하고 내장할 수 있습니다. 구성 가능한 솔루션을 설계하면 적응성과 안정성의 이점도 얻을 수 있습니다.

### 확인

레코드를 만들거나 업데이트하는 데 사용되는 모든 기술은 기존의 검증 규칙이든 Apex 트리거에 내장된 사용자 정의 검증이든 시스템 수준의 검증을 준수해야 합니다. 레코드 변경을 수행하는 데 사용하는 기술과 상관없이 모든 변경 사항은 저장 주문을 거쳐야 합니다. 즉, 유효성 검사 규칙 외에도 레코드 변경 사항은 여러 저장 전 또는 저장 후 플로우, 저장 전 또는 저장 후 트리거, 에스컬레이션 규칙, 할당 규칙 등을 통해 처리됩니다.

**참고:** 아직 수행하지 않은 경우 Apex [실행 순서](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)를 검토하고 북마크합니다.

#### 질문할 질문

- 시스템 수준 유효성 검사 외에도 양식에 추가 요구 사항이 있습니까?

- 양식 내에서 필수 또는 읽기 전용 필드를 동적으로 설정해야 합니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">시스템 수준 유효성 검사 준수</th>
<th colspan="1" rowspan="1">이 양식에만 해당하는 사용자 정의 필드 수준 유효성 검사</th>
<th colspan="1" rowspan="1">사용자 정의 필드 수준 유효성 검사</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr></table>

일반적으로 플로 화면 또는 Omniscript 단계의 입력이 바인딩되지 않으므로 양식 자체가 특정 개체와 연결된 시스템 수준 확인을 기본적으로 준수하지 않습니다. 그러나 레코드를 만들거나 업데이트하는 데 사용하는 값은 저장 순서로 처리되므로 개체의 시스템 수준 유효성 검사를 통과합니다.

**참고:** 일부 화면 플로 구성 요소에서는 입력 유효성 검사를 지원하지 않습니다.

페이지 레이아웃과 마찬가지로 동적 양식을 사용하면 페이지 수준에서 **필수성** 및 **읽기 전용** 상태를 설정할 수 있습니다. 시스템 수준 설정을 재정의할 수 없습니다.

플로는 양식 입력 유효성 검사를 유연하게 사용자 정의할 수 있습니다. 클라이언트 수준에서 여러 확인을 수행합니다(예: 누락된 필수 필드 플래그 지정 및 데이터 유형 확인 및 입력 확인 규칙 내 호환 수식). 추가 보안 수준으로 서버에서도 입력 유효성 검사가 평가됩니다. 사용자가 **다음**을 클릭하면 Flow가 유효성 검사를 위해 다시 서버에 입력을 보냅니다. 잘못된 입력이 반환되면 탐색이 차단되고 적절한 오류가 표시됩니다.

서버는 다음 사항을 확인하여 입력값을 검증합니다.

- 입력의 **필수성** 설정 또는 입력된 값이 기본 데이터 유형과 호환되는지 여부

- 입력의 사용자 정의 유효성 검사입니다. _부울_ 수식 식이 충족되지 않을 경우 표시할 오류 메시지를 입력해야 합니다.

- 기본 구성 요소의 사용자 정의 유효성 검사입니다. 플로에 대한 사용자 정의 LWC를 구축하는 경우 validate() 메서드에 자체 확인 코드를 추가해야 합니다.

화면 플로의 **메시지** 구성 요소를 통해 액세스 가능한 사용자 경고를 제공할 수도 있지만, 이는 사용자가 다른 페이지로 이동하거나 안내 플로의 다음 단계로 진행하는 것을 방지하지 않습니다. **메시지** 구성 요소 내의 _오류_ 상태는 탐색이 비활성화될 때 오류 경로를 통해 트리거되는 전용 오류 화면에 가장 적합합니다.

Omnistudio는 [조건부 보기](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) 및 [메시징](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5) 구성 요소와 함께 [오류 설정](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5) 작업을 통해 강력한 오류 및 검증 처리를 제공합니다.

LWC의 경우, 대부분의 기본 구성 요소는 자체 클라이언트 측 유효성 검사를 수행합니다(예: lightning-record-form은 시스템 수준의 필수성을 준수하지만, 페이지 수준의 필수성은 준수하지 않습니다). 사용자 정의 구성 요소에 대해 직접 유효성 검사 메커니즘을 구축할 수 있습니다.

사용자가 데이터를 입력해야 하는 필드는 양식의 시작 부분에 표시되어야 합니다. 가능한 경우 양식을 제출하기 전에 클라이언트 측에서 사용자 입력을 확인합니다.

### 상호 작용 설계

정적 양식이 오래되었습니다. 오늘날 초점은 _특정_ 사용자, _특정_ 시간, _특정_ 장소에 적절한 속성 및 값으로 양식을 동적으로 업데이트하는 데 전환되었습니다. Salesforce 양식 작성 도구를 통해 가능한 작업을 자세히 살펴보겠습니다.

#### 질문할 질문

- 양식 내에서 동적 응답을 트리거해야 하는 상호 작용 또는 조건 유형은 무엇입니까?

- 양식을 작성하는 동안 화면 외부(백그라운드) 작업을 실행해야 합니까?

- 필드를 **보기**, **필수**, **읽기 전용** 또는 **비활성화됨**으로 설정하거나 양식 입력에 따라 서식을 변경해야 합니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">오프스크린 데이터 작업 실행</th>
<th colspan="1" rowspan="1">조건부 값 및 계산</th>
<th colspan="1" rowspan="1">조건부 표시</th>
<th colspan="1" rowspan="1">조건부 요구 사항</th>
<th colspan="1" rowspan="1">조건부 서식</th>
<th colspan="1" rowspan="1">조건부 읽기 전용 상태</th>
<th colspan="1" rowspan="1">조건부 비활성화 상태</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>화면 플로</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>화면 플로 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="8" rowspan="1" style="border-right: 1px solid #d8dde6;">*정적 확인란이 아닌 리소스 선택기를 사용하는 구성 요소로 제한됩니다.</td></tr></table>

**반응형 화면**은 화면 플로 상호 작용을 활성화합니다. 반응성을 사용하면 화면 플로의 개별 구성 요소가 서로 통신하므로 화면 플로가 더욱 강력해집니다.

**오프스크린 데이터 작업 실행**

화면 플로는 **화면 작업**을 통해 동일한 화면에서 데이터를 가져오는 선언적 접근 방식을 제공합니다. 화면 작업을 사용하면 화면 내의 모든 변경 사항 또는 사용자가 **작업 버튼** 구성 요소를 클릭할 때 자동 실행 플로를 트리거할 수 있습니다. 자동 실행 플로 결과를 동일한 화면에 매핑할 수 있으므로 사용자가 다른 화면으로 이동할 필요가 없습니다.

LWC는 Salesforce 데이터에 액세스하여 양식 구성 요소의 데이터를 동적으로 채울 수 있는 전체 배열의 유선 어댑터를 제공하며, 이를 통해 개발자는 Apex 컨트롤러를 통해 레코드를 **업데이트**, **삭제** 및 **생성할 수 있습니다**.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-offscreendataoperations-noheader.png" alt="Lightning Web Components Off-Screen Data Operations" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

**가시성**

모든 양식 작성 도구에서 가시성을 동적으로 제어할 수 있습니다. 동적 양식, Flow Builder, Omnistudio는 구성 요소 가시성 기능을 사용하여 이를 해결합니다. 양식 내의 다른 값 또는 사용자가 모바일 장치에서 양식을 작성하는지 여부를 기반으로 필드를 선언적으로 **표시하거나** **숨기기기**할 수 있습니다.

- 동적 양식은 레코드 필드 값, 조회 필드, 그리고 폼 팩터를 기준으로 가시성을 제어합니다.

- 플로를 사용하면 다른 화면 입력과 플로에서 이전에 채워지는 다른 리소스(예: 다른 레코드의 수식 또는 값)를 기준으로 가시성 규칙을 지정할 수 있습니다.

  - **장치 기반 규칙:** 처음부터 명확하지 않을 수도 있지만 사용자가 모바일 장치에 있을 때 특정 필드를 **표시하거나** **숨기기 위해 수식을 사용할 수 있습니다**. **$User.UIThemeDisplayed** 전역 변수의 값을 확인하는 플로 수식을 작성합니다. 값이 **Theme4t**인 경우 사용자가 Salesforce 모바일 앱을 사용하여 양식을 작성합니다.

  - **다른 리소스 평가:** 수동 변수 및 수식 참조는 서버에서만 평가됩니다. 즉, 해당 리소스가 화면을 처음 렌더링할 때 가진 값은 다른 화면으로 이동할 때까지 유지됩니다. 탐색하는 동안 플로 런타임이 플로 엔진(서버)에 요청을 제출하고 최신 수동 변수 및 수식 값을 반환합니다. 사용자가 단일 화면을 통과할 때 가시성 규칙이 업데이트될 것으로 예상되는 경우(예: onblur) 화면의 다른 구성 요소의 값만 참조해야 합니다.

- Omnistudio를 사용하면 **조건부 보기** 속성을 설정하여 구성 요소를 조건부로 **표시**하거나** 숨길 수 있습니다**. 그러나 입력에 대해 둘 이상의 조건부 보기 속성을 추가할 수 없습니다.

**조건부 입력 상태**

다른 속성을 동적으로 제어해야 하는 경우(예: 필드가 **필수**인지, **비활성화**인지 또는 **읽기 전용인지**) 몇 가지 옵션이 있습니다. LWC는 입력 상태를 완벽하게 반응형으로 제어합니다. 반응형 화면 플로 구성 요소를 사용하면 이를 지원하는 표준 구성 요소의 구성 요소 특성(예: **읽기 전용**, **비활성화됨** 및 **필수**)을 동적으로 제어할 수 있으며, Omnistudio는 구성 요소별 특성의 전체 스펙트럼을 지원합니다. 요구 사항에 따라 Flow가 필요하고 구성 요소가 특정 특성 상태를 지원하지 않는 경우 내장형 LWC를 만들어 동적 입력 상태를 달성할 수 있습니다.

다른 속성을 동적으로 제어해야 하는 경우(예: 필드가 **필수**인지 또는 **읽기 전용**인지 여부) LWC를 짧은 시간 동안 사용합니다. 이는 특히 onblur 또는 onclick을 처리하는 방법에 대한 사용자 정의 요구 사항이 있는 경우에 적용됩니다.

**화면 플로의 반응형 LWC**

화면 플로의 다른 구성 요소에 반응하거나 변경할 수 있는 LWC를 구축하는 경우 화면 플로를 위한 [LWC Best Practices for Screen Flows](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows) 가이드를 확인하여 구성 요소가 플로 런타임 엔진과 통합되고 의도한 대로 작동하는지 확인합니다.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">표준 이벤트 처리(blur, onfocus)</th>
<th colspan="1" rowspan="1">사용자 정의 이벤트 처리</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>화면 플로</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>화면 플로 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*Omnistudio 표준 런타임은 Pub/Sub를 지원하지 않지만 Windows postMessage를 지원합니다.</td></tr></table>

사용자 정의 이벤트의 경우 일부 입력(또는 전체 양식)이 페이지의 다른 요소와 통신해야 하는 경우 LWC가 유일한 옵션입니다.

- 동일한 DOM 트리 내에서 통신하려면 [CustomEvent 인터페이스를](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events) 사용합니다.

- DOM을 통해 통신하려면 [Lightning Messaging 서비스](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel)를 사용합니다.

- 대상 컨테이너에서 Lightning Messaging 서비스가 [지원되지 않는 경우](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations) pub/sub 모듈을 사용합니다.

#### 상호 작용 설계를 위한 추가 자원

- 자세한 내용은 _Lightning 웹 구성 요소 개발 가이드_에서 [이벤트와 통신](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events) 및 DOM 간 [통신](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub)을 참조하십시오.

- Omnistudio의 경우, [Lightning Web Component에서 Omniscript와 통신하는 방법](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5)을 확인해 보세요.

### 스타일링

최상의 사용자 환경을 제공하려면 양식 스타일이 내장된 나머지 앱 또는 사이트와 일치하는지 확인해야 합니다. 이는 Salesforce에서 제공하는 표준 템플릿을 사용하거나 디자인에서 모든 픽셀을 사용하여 더 선명한 모양과 느낌을 제공하는 사용자 정의 CSS를 생성하는 것을 의미할 수 있습니다.

#### 화면 플로 스타일 재정의

관리자는 화면 컨테이너 또는 개별 구성 요소에 대해 제한된 화면 및 구성 요소 스타일 재정의 집합(예: 색상, 테두리, 버튼 모양)을 구성할 수 있습니다. 이러한 재정의는 테마 및 브랜딩 뒤에 적용되므로 빌더는 나머지 응용 프로그램에 영향을 미치지 않고 표적화된 시각적 조정을 수행할 수 있습니다.

스타일 재정의는 현지화된 시각적 예외(예: 확인 화면 강조 표시 또는 특정 행동 유도(CTA) 강조)에 사용되며, 전체 스타일링 시스템이 아닙니다. CSS 수준을 제어할 수 없으며 화면 또는 플로에서 재사용할 수 있도록 설계되어 있지 않습니다.

아키텍처 관점에서 스타일링은 다음의 우선 순서를 따라야 합니다.

1. **테마 및 브랜딩:** Lightning 테마, 익스피리언스 빌더 브랜딩 집합 또는 LWR 사이트 테마

2. **플로 스타일 재정의:** 대상 화면 또는 구성 요소 조정

3. **사용자 지정 구성 요소(LWC):** 픽셀 완벽한 제어 또는 재사용 가능한 디자인 패턴이 필요한 경우

테마 및 디자인 시스템을 사용하면 스타일링이 일관되고 확장 가능하며 시간이 지남에 따라 쉽게 유지할 수 있습니다.

#### 질문할 질문

- 원하는 스타일 및 CSS는 얼마나 정교합니까?

- 사용자 정의 픽셀 퍼펙트 스타일링 또는 표준 테마가 필요합니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">직접 스타일링</th>
<th colspan="1" rowspan="1">조직 및 익스피리언스 빌더 테마</th>
<th colspan="1" rowspan="1">픽셀 퍼펙트 스타일링</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">*FlexCard만 해당<br><br>**특정 스타일 특성은 CSS 재정의가 아닌 화면 구성 요소에 대해 구성할 수 있습니다.</td></tr></table>

FlexCard는 이 가이드에서 도구 내에서 구축하는 UI의 스타일 및 레이아웃(예: 여백 및 패딩, 오타그래픽, 색상 등)을 선언적으로 제어할 수 있는 유일한 제품입니다.

동적 양식 및 플로우는 선언적 테마 기능을 준수합니다. 추가 제어가 필요한 경우([Salesforce 테마](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1), [익스피리언스 빌더 브랜딩 세트](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm) 또는 [LWR Experience Cloud 사이트](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm) 지원 이상) 프로그래밍 솔루션을 고려하십시오.

CSS에 익숙한 팀은 여러 옵션을 사용할 수 있습니다:

- 플로우 및 LWC는 [표준 설계 토큰](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm)을 상속합니다.

- Omniscripts 및 FlexCards에는 [뉴포트](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5)를 통해 맞춤형 디자인 시스템 지원이 포함되어 있습니다.

- LWC를 사용하면 자체 구성 요소를 작성하고 HTML 및 CSS를 완전히 제어할 수 있습니다.

가능한 경우 테마 및 디자인 시스템을 사용하여 모든 콘텐츠에서 일관된 모양과 느낌을 제공하는 것이 좋습니다.

**참고:** Lightning 구성 요소를 플로우에 포함할 수 있습니다. 양식의 모양과 느낌을 픽셀 완벽하게 제어해야 하지만 플로의 다른 혜택(예: 탐색 모델)도 사용하려는 경우 두 가지 모두를 최대한 활용할 수 있습니다. Omniscripts 및 FlexCards에 동일한 원칙이 적용됩니다.

### 레이아웃

적절한 레이아웃을 선택하는 것은 빠르고 효율적인 데이터 입력을 활성화하고 데이터 무결성을 향상하는 간소화된 양식을 설계하는 데 매우 중요합니다.

#### 질문할 질문

- 사용자 경험을 최적화하기 위해 양식 레이아웃을 구성하는 방법은 무엇입니까?

- 사용자가 쉽게 양식에 새 데이터를 입력할 수 있도록 기존 데이터를 사용자에게 표시할 수 있는 방법은 무엇입니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">열 2개</th>
<th colspan="1" rowspan="1">4열</th>
<th colspan="1" rowspan="1">4열 초과</th>
<th colspan="1" rowspan="1">반복되는 데이터 블록</th>
<th colspan="1" rowspan="1">탭 컨테이너</th>
<th colspan="1" rowspan="1">아코디언 컨테이너</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="7" rowspan="1" style="border-right: 1px solid #d8dde6;">*Omniscript의 FlexCard에 데이터를 포함하는 경우 탭을 사용할 수 있습니다.</td></tr></table>

동적 양식은 필드 내의 개별 섹션으로 나눌 수 있는 2열 레이아웃을 지원합니다. 이러한 섹션은 구성 요소(예: 탭 및 아코디언) 내에 배치하여 쉽게 사용할 수 있는 구성된 레이아웃을 만들 수 있습니다.

**섹션** 구성 요소를 사용하여 플로우를 렌더링할 수도 있습니다. 플로 화면에서 최대 4개의 열과 무제한 섹션을 추가할 수 있습니다. 섹션 구성 요소는 화면 너비에 따라 반응형으로 동작하므로 더 작은 화면에서도 잘 작동합니다. 이를 통해 전체 섹션에 조건부 가시성을 적용할 수 있으므로 섹션 내의 여러 필드에 더 쉽게 가시성을 대량으로 적용할 수 있습니다. 또한 **플로 섹션**은 열 머리글을 지원하며 사용자가 레이블을 클릭하여 전체 섹션을 축소할 수 있는 아코디언 같은 환경을 제공합니다.

Omniscripts는 필드 및 데이터를 표시하기 위한 다양한 레이아웃 옵션을 제공합니다. 조건부로 축소 가능한 아코디언을 포함하여 최대 12개의 열이 있는 데이터 섹션을 만들 수 있습니다.

LWC를 사용하면 lightning-record-\[edit\|view]-form과 지원되는 lightning-\[input\|output]-field를 사용하여 레이아웃을 제어할 수 있습니다. 레이아웃 제한은 HTML 및 CSS에서만 적용됩니다. **Lightning-record-form** 구성 요소는 관련 페이지 레이아웃의 섹션 구성을 준수합니다(예: 섹션이 페이지 레이아웃에서 2열인 경우 구성 요소에서도 2열).

### 번역

다른 지역의 사용자 또는 다른 언어를 사용하는 사용자가 양식에 액세스해야 하는 경우 해당 양식을 작성하는 데 사용하는 도구가 현지화 요구 사항을 충족하는지 확인해야 합니다.

**참고:** 특히 양식의 경우, 현지화 요구 사항은 일반적으로 텍스트 요소를 다른 언어로 번역하는 것을 포함합니다.

#### 질문할 질문

- 양식이 두 개 이상의 국가 또는 지역에서 사용될 예정입니까?

- 양식의 텍스트를 다른 언어로 현지화해야 합니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">빌더에 입력된 레이블</th>
<th colspan="1" rowspan="1">코드의 레이블</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">해당되지 않음</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*필드 섹션 머리글에만 해당</td></tr></table>

사용자 정의 필드를 현지화하는 경우 동적 양식은 번역된 레이블을 준수합니다. 동적 양식은 Lightning 앱 빌더에서 [구성 요소 레이블 및 속성에 할당된 모든 사용자 정의 레이블](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5)을 준수합니다.

플로는 번역 워크벤치를 통해 모든 표준 및 사용자 정의 화면 구성 요소에 대한 사용자 대면 레이블 번역을 지원합니다.

다음 화면 구성 요소에서 레이블, 도움말 텍스트, 오류 메시지를 현지화할 수 있습니다.

- 텍스트
- 긴 텍스트 영역
- 숫자
- 통화
- 확인란
- 라디오 버튼
- 선택 목록
- 다중 선택 선택 목록
- 확인란 그룹 암호
- 날짜
- 날짜/시간

기본 작업에 대한 내장 번역 지원(예: 이메일 보내기 또는 Chatter 게시)은 없지만 해결 방법이 있습니다. 번역된 레이블을 정의하기 위해 [사용자 정의 레이블을](https://help.salesforce.com/articleView?id=cl_about.htm) 사용하는 경우 Flow Builder에서 해당 레이블을 구성할 때 작업 또는 구성 요소에서 해당 사용자 정의 레이블을 참조할 수 있습니다. 이를 수행하려면 사용자 정의 레이블을 참조하는 플로 수식을 만든 다음, 플로 내의 적절한 위치에서 해당 수식을 참조해야 합니다.

Omniscripts는 번역에 사용자 정의 레이블을 사용합니다. 자세한 내용은 Omniscript가 다국어로 준비되었는지 확인하려면 [이 도움말 문서](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm)을 확인하십시오.

LWC의 경우, lightning-record-form과 같은 특정 기본 구성 요소는 번역 워크벤치에서 구성된 경우 관련 객체의 필드, 도움말 텍스트, 검증 메시지의 번역을 자동으로 상속합니다.

코드에 새 번역 가능한 레이블을 도입해야 하는 경우 사용자 정의 레이블을 사용하는 것이 좋습니다. 필요한 사용자 정의 레이블을 선언한 다음, `@salesforce/label` 범위 모듈에서 구성 요소로 가져옵니다.

## 기능이 아닌 고려 사항

이 섹션을 사용하여 구현하기 전에 보안, 품질, 운영 제약을 평가합니다.

### 보안

보안은 복잡한 주제이며 양식 구축 시 명확하지 않은 여러 가지 고려 사항이 있습니다. 기본 수준에서 양식이 올바른 컨텍스트에서 실행되고 사용자에게 기본 데이터에 대해 작업하는 데 필요한 권한이 있는지 확인해야 합니다. 또한 추가 조치를 취하여 잠재적으로 악의적인 코드 또는 URL을 서식 있는 텍스트 필드에서 제거하거나 특정 사용자가 양식에 액세스하지 못하도록 방지하거나 관리자가 향후 양식을 포함할 수 있는 위치 유형에 제한을 적용할 수도 있습니다.

도구를 선택하기 전에 보안 요구 사항을 철저하게 문서화해야 합니다. 이 유형의 문서에 대한 추가 지침은 Salesforce [우수한 보안 정책 템플릿](/docs/architect/ko-kr/resources/guide/security-policy-template)을 참조하십시오.

#### 질문할 질문

- 특정 작업을 수행하기 전에 양식에서 사용자의 액세스를 확인해야 합니까?

- 사용자 입력을 정제해야 합니까?

- 양식에 액세스할 수 있는 사람을 제어해야 합니까?

- 양식을 포함할 수 있는 위치를 제어해야 합니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">사용자 권한 상승</th>
<th colspan="1" rowspan="1">액세스 권한이 있는 사용자 제어</th>
<th colspan="1" rowspan="1">허용 위치 제한</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">*Apex 필요<br><br>** OmniScript는 지정된 대상 위치 집합을 가질 수 없지만 FlexCard는 사용할 수 있습니다.</td></tr></table>

#### 사용자 권한 상승

프로그램이 **사용자 컨텍스트**에서 실행되면 Salesforce는 필드 수준 보안, CRUD 권한, 조직의 공유 규칙을 기반으로 레코드 액세스를 확인하는 등 일련의 액세스 검사를 적용합니다(예: 사용자가 사례를 업데이트할 수 있는 기능, 적절한 필드 수준 보안, 해당 레코드에 대한 액세스 권한이 있는 경우에만 사례 업데이트 양식을 실행할 수 있음).

사용자가 다른 양식이나 상호 작용을 통해서가 아닌 양식을 사용할 때 특정 작업을 수행할 수 있도록 하려면 어떻게 해야 합니까? 바로 여기서 **시스템 컨텍스트**가 사용됩니다!

**시스템 컨텍스트**를 사용하면 세션 기간 동안 사용자의 권한을 상승시킬 수 있습니다(예: 사용자가 사례 업데이트 양식을 성공적으로 완료하기 위해 사례 개체에 대한 액세스를 업데이트할 필요가 없습니다). 이는 특히 인증되지 않은 커뮤니티에 유용합니다. 게스트 사용자에게 잠재적으로 위험한 기능을 부여하는 대신 시스템 컨텍스트에서 실행되도록 양식을 설정합니다.

시스템 컨텍스트는 절대적으로 필요한 경우에만 사용해야 합니다. 시스템 컨텍스트에서 양식이 실행되면 모든 CRUD 작업이 개체 및 필드 수준 보안 및 공유 구성 요소를 우회합니다. 또한 시스템 컨텍스트는 Salesforce에서 해당 _작업자_(**마지막 수정자** 필드에 표시되는 이름)에 영향을 미치지 않습니다. 양식이 수행하는 각 작업(예: 사례 업데이트)에 대해 현재 사용자가 _작업자_입니다(양식이 다른 컨텍스트에서 실행되는 경우에도).

**참고:** 동적 양식, OmniScript 및 LWC는 항상 사용자 컨텍스트에서 실행되며 이 동작을 재정의할 수 있는 방법은 없습니다.

화면 플로는 기본적으로 사용자 컨텍스트에서 실행되지만 시스템 컨텍스트에서 실행되도록 설정할 수 있습니다. 플로에서 모든 데이터에 대한 액세스 권한을 부여해야 하는지 또는 레코드 수준 액세스를 적용해야 하는지 여부를 결정할 수 있습니다.

- 시스템 컨텍스트에서 실행되는 플로우 내에 Lightning 구성 요소를 포함하는 경우, 플로우가 구성 요소의 컨텍스트를 재정의하지 않습니다. 사용자 액세스 검사를 우회해야 하는 경우, 플로우를 사용하여 해당 작업을 수행하고 Lightning 구성 요소에 적절한 데이터를 전달합니다. 일부 기본 구성 요소(예: Lookup)는 시스템 컨텍스트 내에서 작동할 수 없습니다.

- 플로우에서 Apex 작업을 호출하는 경우, 다른 뉘앙스가 포함될 수 있습니다.

  - Apex 클래스가 _상속된 공유_로 설정된 경우, 플로우 설정에 관계없이 공유와 함께 시스템 컨텍스트에서 실행됩니다.

  - 클래스에 명시적 공유 선언이 없는 경우 플로 설정에 관계없이 공유 없이 시스템 컨텍스트에서 실행됩니다.

  - 클래스가 _공유 또는 공유하지 않음_으로 설정된 경우 플로의 컨텍스트를 재정의합니다.

**Experience Cloud 사이트를 사용하여 시스템 컨텍스트에서 레코드 쿼리**

Experience Cloud 사이트에서 시스템 컨텍스트에서 플로를 실행하는 경우(특히 인증되지 않은 경우) **레코드 가져오기** 요소에 특정 필드만 저장합니다. Flow를 사용하여 작업하고 **레코드 가져오기** 요소의 결과를 서브플로우, 호출 가능한 작업 또는 Lightning 구성 요소로 전달하면 해당 개체의 모든 필드가 브라우저의 개발자 도구에 의해 검사될 수 있습니다. 의도에 관계없이 Experience Cloud 사용자가 필드를 사용할 수 있게 할 수 있습니다. 시스템 컨텍스트가 활성화된 경우 올바른 필드만 표시되도록 하려면 **레코드 가져오기** 요소에 해당 특정 필드를 지정합니다.

**참고:** Omniscript 논리는 클라이언트 측에서 실행되므로 공격자가 Omniscript의 예상 실행을 수정하고 브라우저의 개발자 도구를 통해 통합 절차, 데이터 매퍼 및 Apex 메서드 호출에 대한 응답을 볼 수 있습니다. Omniscript를 사용할 때 서버 측에서 (가능한 경우) 비즈니스 논리를 실행하고 [@InvocableMethod 주석](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5)을 통해 노출되는 모든 Apex 메서드에 대한 입력 검증 규칙을 구현하는 것이 중요합니다.

**입력 정제**

악의적인 요소로부터 조직을 보호하려면 입력 정제를 사용하십시오. 조직 내의 **서식 있는 텍스트** 필드에 매핑할 수 있는 공개적으로 액세스할 수 있는 양식에 입력이 있다고 가정합니다. 악의적인 URL을 숨길 수 있는 HTML을 제외하는 자동화를 활성화하는 것이 좋습니다.

이러한 필드를 작성하는 소스 수가 많을 수 있으므로 양식 수준에서 세분화를 구현하는 것이 좋지 않습니다. 이 문제를 해결하려면 **빠른 필드 업데이트 플로(저장 전)**를 만들거나 기존의 **Apex 트리거를** 사용하여 양식에 입력할 수 있는 모든 잠재적인 HTML을 제거하거나 수정합니다.

#### 모범 사례

- 플로가 기본 컨텍스트에서 실행되도록 허용합니다(특정 작업에 대해 현재 사용자의 액세스 권한을 늘려야 하는 경우 제외).

- 시스템 컨텍스트에서 게스트 사용자에 대한 플로우를 실행하지 마십시오. 제한된 필드 액세스 권한이 있는 권한 집합을 만들고 Experience Cloud 게스트 사용자의 프로필에 할당합니다.

- Experience Cloud 사이트의 시스템 컨텍스트 실행 플로에서 레코드를 쿼리할 때 필요한 필드만 **레코드 가져오기** 요소 또는 **출화 가능한 작업**에 저장합니다.

- 플로가 다양한 작업을 수행하는 경우(모든 작업에 상위 액세스 권한이 필요하지 않음) 하위 플로를 사용하여 시스템 컨텍스트 내에서 실행되어야 하는 작업을 격리합니다.

- 외부 웹 페이지에 양식을 포함하는 경우 잠재적인 피싱 공격을 방지하기 위해 **서식 있는 텍스트** 필드에 매핑해야 할 수 있습니다. 이를 위해 **빠른 필드 업데이트 플로우** 또는 **Apex 트리거**를 사용하여 사용자 입력에서 HTML을 제거하세요.

#### 추가 노트

- Omniscripts, FlexCards, 그리고 LWCs는 기본적으로 사용자 컨텍스트에서 실행됩니다.

- LWC는 기본적으로 사용자 컨텍스트에서 실행됩니다.

- 플로는 사용자 컨텍스트에서 실행되지만 Apex 컨트롤러를 사용하여 재정의할 수 있습니다.

- UI API 내에서 수행되는 작업은 사용자 컨텍스트에서 실행됩니다.

- Apex 컨트롤러로 수행되는 작업은 특정 클래스에 따라 다릅니다. 이러한 작업을 시스템 모드에서 수행하려면 **Apex 클래스**를 with sharing 또는 without sharing으로 설정합니다.

#### 액세스 제어

양식에 액세스할 수 있는 사람을 제어해야 하는 경우 양식이 포함된 컨테이너를 검토합니다(예: 특정 앱, 레코드 유형 또는 프로필에 사용할 수 있도록 Lightning 페이지를 할당할 수 있습니다). 특정 입력이 민감한 경우 가시성 규칙을 사용하여 누구에게 표시되는 내용을 세부적으로 제어합니다. 이 기능은 동적 양식 및 스크린 플로우에 적용됩니다.

플로우를 특정 프로필 또는 권한 집합(예: Apex 클래스 또는 Visualforce 페이지와 유사)으로 [제한](https://help.salesforce.com/articleView?id=flow_distribute_security.htm)할 수 있습니다. 기본적으로 플로는 제한되지 않습니다. 즉, **플로 실행** 사용자 권한이 있는 모든 사용자가 해당 플로에 액세스할 수 있습니다.

Omnistudio를 사용하는 경우 사용자에게 Omniscript, Flexcard, Classic Card 또는 REST API에서 원격 작업을 관리하는 Apex 클래스에 대한 명시적 액세스 권한이 있어야 하는 [Apex 클래스 권한 검사기](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5)를 구성할 수 있습니다.

**참고:** Apex 클래스 권한 확인은 Apex 클래스에만 적용됩니다. 또한 [통합 절차 및 데이터 매퍼](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5)에 대한 프로필 수준 권한을 설정하는 것이 좋습니다.

#### 액세스 제어 모범 사례

- 게스트 사용자에게 플로를 노출할 경우 게스트 사용자에게 절대적으로 필요한 플로에 대한 프로필 액세스 권한만 부여해야 합니다. 게스트 사용자 프로필에 **실행 플로**를 추가할 수 있지만, 이 방법은 위험할 수 있습니다.

- 시스템 컨텍스트에서 작동하는 플로우와 작업할 때 주의하십시오. 데이터를 보호하기 위해 사용할 수 있는 검사 및 균형을 줄여 특정 사용자 집합으로 해당 플로를 제한해야 합니다.

- 게스트 사용자 커뮤니티 내에서 Apex를 실행하는 모든 Omniscript에 Apex 클래스 정의에 **with sharing**이 명시되어 있는지 확인합니다.

- 게스트 사용자 프로필의 경우 게스트 사용자가 호출하도록 허용할 Apex 클래스만 할당합니다. 이 방법을 수행하면 게스트 사용자에게 의도치 않게 추가 비즈니스 논리가 노출되는 것을 방지할 수 있습니다.

LWC의 경우 현재 사용자의 권한 할당을 확인하여 특정 표준 또는 사용자 정의 권한이 있는지 확인할 수 있습니다. `@salesforce/userPermission` 및 `@salesforce/customPermission` 범위 모듈에서 직접 **JavaScript**에서 Salesforce 권한을 가져올 수 있습니다. Apex를 사용하여 권한을 확인할 수도 있습니다.

#### 제어 포함

LWC는 유효한 [대상](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags)으로 추가된 후에만 지정된 위치에서 사용할 수 있습니다(예: 레코드 페이지에서 구성 요소를 사용 가능하게 만들고 유틸리티 막대 항목으로 사용할 수 없음).

화면 플로가 활성화되면 화면 플로가 지원되는 모든 위치에서 사용할 수 있습니다. Flow Builder는 화면이 있는 여러 유형의 플로우를 지원합니다. 가장 눈에 띄는 유형은 **스크린 플로**이지만 특정 위치로 제한되는 몇 가지 다른 전문 유형이 있습니다(예: **Field Service 모바일 앱**은 **Field Service 모바일 플로만 지원)**. 이는 Experience Cloud에서만 지원되는 **연락 요청 플로**과 유사합니다.

플로우 유형에 관계없이 플로우를 만드는 사람이 플로우가 포함된 위치를 제어할 수 없습니다. 플로우는 특정 플로우 유형이 지원되는 모든 위치에서 사용할 수 있습니다.

Salesforce Industries를 사용하는 경우 Omniscript에 대한 약간의 주의 사항이 있습니다.Omniscript에 대한 대상을 지정할 수 없지만, 포함할 FlexCard에 대한 대상을 지정할 수 있습니다.

### UI 테스트 자동화

Salesforce에는 사용자가 양식과 상호 작용하는 방식을 시뮬레이션할 수 있는 여러 종단 간 테스트 자동화 도구(예: [Salesforce UTAM](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam))가 있습니다. Lightning 페이지 및 화면 플로를 비롯한 모든 표준 또는 사용자 정의 UI에 대한 테스트를 작성할 수 있습니다.

**참고:** 이러한 유형의 테스트는 수행 중인 메서드의 출력을 확인할 수 없습니다. UI 테스트 자동화 요구 사항을 구성할 때 이 사항에 유의하십시오.

#### 질문할 질문

- 양식에 대한 자동 테스트가 필요합니까?

- 수행할 테스트 유형은 무엇입니까?

- 테스트 자동화에 필요한 세분화 수준은 어느 정도입니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">단위 테스트</th>
<th colspan="1" rowspan="1">종단간 자동화</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용 가능*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용 가능*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용 가능*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*코드 필요</td></tr></table>

**UI 테스트 자동화 요구 사항 고려**

비즈니스 논리, JavaScript 제어, 특정 구성 요소의 출력을 테스트하는 업계 표준 CI/CD 시스템 및 도구와 일치하는 세분화된 자동화 및 검증을 제공하는 **유닛 테스트** 로우코드 접근 방식을 선택하는 경우 테스트를 자체 작성할 수 없지만, Salesforce는 모든 종단 간 제공 기능을 엄격하게 테스트합니다.

구성 요소의 메서드가 복잡한 경우 메서드를 전용 JavaScript 파일에 배치하여 개별적으로 텍스트를 작성할 수 있습니다. 이렇게 하면 이를 LWC에 가져온 후, 예를 들어 import { sort } from 'c/utils';와 같이 **Jest 테스트**로 가져올 수 있습니다.

ISV의 코드 없는 솔루션을 사용하고, 사용자 정의 테스트 자동화 솔루션을 구축하거나, 전체 자동화를 위해 오픈 소스 테스트 프레임워크(예: Selenium WebDriver 또는 WebdriverIO)를 사용할 수 있습니다. 이러한 솔루션은 모든 Salesforce UI 상호 작용에 유효합니다(예: Lightning 페이지의 동적 양식, 유틸리티 막대의 화면 플로 또는 빠른 작업 플로의 LWC).

### 메트릭

프로덕션 환경에 양식을 배포한 후에는 양식이 효과적으로 사용되고 있는지 확인해야 합니다. 사용 사례에 따라 양식 작성 횟수와 평균 사용자가 정보를 제출하기 전에 양식을 작성하는 데 소요되는 시간을 추적할 수 있습니다. 도구를 선택하기 전에 추적 가능한 KPI를 식별해야 합니다.

#### 질문할 질문

- 양식 사용을 추적해야 합니까?

- 양식이 효과적으로 사용되고 있는지 여부를 판별할 수 있는 KPI는 무엇입니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">페이지 보기</th>
<th colspan="1" rowspan="1">양식에 소요된 시간</th>
<th colspan="1" rowspan="1">양식 완성 추적</th>
<th colspan="1" rowspan="1">성공률 추적</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용 가능**</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능**</td>
<td colspan="1" rowspan="1">사용 가능*</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="5" rowspan="1" style="border-right: 1px solid #d8dde6;">*패키지 기반 Omnistudio 런타임이 활성화된 경우 사용 가능** 상위 Lightning 페이지 사용량을 추적하여 사용 가능</td></tr></table>

전체 양식 사용 및 채택을 추적해야 하는 경우 로우코드 도구를 사용하십시오. 동적 양식 및 스크린 플로우는 기본 사용자 정의 보고서를 통해 추적할 수 있습니다. 그러나 스크린 플로우 추적 보고서는 추가 세분화를 제공합니다. LWC 사용을 추적해야 하는 경우 기본 제공 가용성은 LWC를 사용하는 위치에 따라 다릅니다. Lightning 페이지에 있는 경우 사용 가능한 Lightning 페이지 사용 추적 요소가 모두 LWC에 적용됩니다. 플로에 포함된 LWC에도 마찬가지입니다.

동적 양식은 기본으로 추적할 수 없지만, [Lightning 사용 개체를 통해](https://help.salesforce.com/articleView?id=lex_usage_reports.htm) 상위 Lightning 페이지의 사용을 추적할 수 있습니다. 표준 Lightning 페이지를 추적하려면 페이지 메트릭별 **Lightning 사용자** 사용자 정의 보고서를 사용합니다. 사용자 정의 Lightning 페이지의 경우 **FlexiPage 메트릭별 Lightning 사용량 사용자** 정의 보고서를 사용합니다.

플로우는 특정 양식의 채택을 추적하는 데 도움이 됩니다. **샘플 플로우 보고서 사용: 다음 유형의 질문에 답하기 위한 스크린 플로우**:

- 이 양식의 완료율은 얼마입니까? 현재 제대로 채택되어 있습니까?

- 사용자가 이 양식을 작성하는 데 시간이 얼마나 걸립니까?

- 사용자가 가장 많은 시간을 할애하는 화면은 무엇입니까?

- 사용자가 이전 화면으로 얼마나 자주 이동합니까?

- 오류는 얼마나 자주 발생합니까?

표준 보고서가 요구 사항을 충족하지 않는 경우 복제하고 변경하거나 **스크린 플로** 보고서를 사용하여 처음부터 Build Your Own 보고서를 만들 수 있습니다.

패키지 기반 Omniscript 런타임을 사용하는 경우 [Vlocity 추적 서비스용 Omnistudio](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5)도 사용할 수 있습니다. 이 서비스는 모든 유형의 이벤트를 추적합니다(예: Omniscript에서 단계를 완료하는 데 걸리는 시간을 추적할 수 있으므로 프로세스 개선 사항을 식별하는 데 도움이 됩니다).

**참고:** 화면 플로우, Omniscript 또는 Lightning 페이지에 포함되지 않은 LWC를 추적하는 기본 옵션은 없지만, Apex를 사용하여 사용자 정의 솔루션을 구축할 수 있습니다.

### 패키징 및 배포

변경 집합 또는 **DevOps Center**를 사용하여 테스트 환경 또는 프로덕션에 솔루션을 배포하는 방법을 숙지할 수 있습니다. 해당 배포 옵션은 동적 양식, 플로, LWC를 완전히 지원합니다. 그러나 Omnistudio는 별도의 도구인 [IDX 워크벤치](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5)가 필요합니다.

#### 질문할 질문

- 양식을 배포할 계획은 무엇입니까?

- 양식을 둘 이상의 Salesforce 조직에 배포해야 합니까?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">1세대 관리 패키지(1GP)</th>
<th colspan="1" rowspan="1">2세대 관리형 패키지(2GP)</th>
<th colspan="1" rowspan="1">잠금 해제된 패키지</th>
<th colspan="1" rowspan="1">변경 집합</th>
<th colspan="1" rowspan="1">DevOps Center</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음</td>
<td colspan="1" rowspan="1">사용할 수 없음*</td>
<td colspan="1" rowspan="1">사용할 수 없음*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>스크린 플로우 + LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td>
<td colspan="1" rowspan="1">사용 가능</td></tr>
<tr><td colspan="6" rowspan="1" style="border-right: 1px solid #d8dde6;">*IDX 워크벤치를 사용하여 다른 조직에 Omnistudio 솔루션을 배포합니다.</td></tr></table>

ISV 또는 AppExchange 배포를 위해 솔루션을 패키지하려는 파트너인 경우 동적 양식, 플로, LWC를 확인하십시오. Omnistudio는 패키징을 지원하지 않습니다.

### 로우코드에서 프로코드로 이어지는 연속체를 탐색하세요.

이 가이드는 동적 양식, 화면 플로, Omnistudio, LWC를 통해 사용할 수 있는 기능 및 사용자 정의 수준을 보여줍니다.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-lowcode-continuum.png" alt="Low-Code to Pro-Code Continuum" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
다음은 상위 수준의 개요입니다.

- 양식 구축 시 LWC는 가장 강력하고 사용자 정의 가능한 옵션이지만 가드 레일이 가장 적습니다. 따라서 구성 요소를 [보안](/docs/architect/ko-kr/well-architected/guide/trust.html) 및 [확장성](/docs/architect/ko-kr/well-architected/guide/reliability.html#scalability-and-capacity-planning)을 고려하여 구축하는 것이 중요합니다.

- 동적 양식은 가장 유연하지 않은 옵션이지만, 오류가 발생할 가능성이 훨씬 적습니다.

- Flow와 Omnistudio는 중간 정도의 위치에 있습니다. 동적 양식보다 강력하지만 LWC 수준까지는 달라지지 않습니다. 그러나 동적 양식보다 가드 레일이 적으며 사용자 정의 코드보다 깨지기 어려워집니다.

필요에 맞는 여러 도구를 찾을 수 있습니다. 이러한 경우 최종적으로 결정은 팀에 가장 적합한 도구에 따라 다릅니다. 고려해야 할 추가 측면에 대한 자세한 내용은 이러한 [아키텍트 의사 결정 가이드](/docs/architect/ko-kr/decision-guides)를 참조하십시오.

#### 질문할 질문

- 도구를 비교할 때 팀이 각 도구와 관련하여 얼마나 많은 전문 지식을 보유하고 있는지 평가하는 것이 중요합니까?
- LWC 또는 JavaScript에 능숙한 개발자는 몇 명입니까?
- 팀에 Flow Builder에 대한 전문가이거나 추가 학습에 관심을 보인 개발자가 있습니까?

자세한 내용은 살펴보지 않지만, 다음은 이러한 특정 도구가 지금까지 다루고 있는 평가와 어떻게 관련되어 있는지에 대한 더 많은 정보입니다.

**제공 위임**

일부 요구 사항이 LWC를 요구하더라도 LWC를 사용하여 전체 솔루션을 구축하지 않아도 됩니다. 솔루션을 모듈 방식으로 구축할 수 있는 방법을 결정하는 것이 중요합니다. 이를 수행하려면 코딩된 LWC가 필요한 부분과 그렇지 않은 부분을 구분해야 합니다. LWC가 필요하지 않은 부품은 로우코드 솔루션을 사용하여 구축해야 합니다.

Flow와 LWC에서는 동일한 화면에서 상호 동기화가 가능한 다양한 구성 요소들(예: 반응형 화면 구성 요소 및 화면 Flow)이 존재해 아키텍트, 관리자, 그리고 개발자에게 새로운 도구를 제공합니다. 개발자는 이제 조직 전체에서 재사용할 수 있는 목적에 부합하는 모듈식 구성 요소를 만들어, 팀 생산성을 향상시킬 수 있습니다. 이로 인해 개발자는 표준 및 사용자 정의 Flow 구성 요소를 혼합하여 양식에 동적 효과를 부여함으로써 시간을 절약하고, 새로운 문제 해결에 더 많은 시간을 할애할 수 있습니다. 플로에 반응형 구성 요소가 도입됨에 따라, 양식 구축 시 Flow와 LWC를 혼용하기에 이보다 적절한 때는 없었습니다.

**장기 소유 및 유지 보수**

다단계 양식을 만드는 경우 Flow 또는 Flow와 LWC를 함께 사용하여 시작합니다. 양식을 유지 관리하는 팀이 로우코드 팀인 경우 솔루션이 의도한 대상에 대해 최대한 구성 가능하고 확장 가능한지 확인하십시오. 안정성과 유지 보수성 향상을 위해 선택한 도구와 상관없이 솔루션을 [복합 가능한](/docs/architect/ko-kr/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity) 유닛으로 구성하는 것이 중요합니다.

### 성능

동적 양식, 화면 플로, Omnistudio 또는 LWC와 관련된 성능 고려 사항은 기술이 포함된 프레임워크를 기반으로 합니다. LWC를 기반으로 하는 기술은 Aura를 기반으로 하는 기술보다 성능이 뛰어난 경향이 있습니다. 프레임워크 추상을 통해 JavaScript가 아닌 웹 엔진에서 기본적으로 구현되는 몇 가지 핵심 기능으로 인해 LWC는 향상된 성능 혜택을 제공합니다.

Salesforce의 양식 기술에 대한 이러한 성능 혜택을 어떻게 활용합니까? 자세히 살펴보겠습니다.

- Dynamic Forms(Lightning 페이지 메타데이터 내에서 통합)는 LWC 스택 기반으로 구축되며, 오랫동안 기다려온 여러 기능을 구현할 수 있습니다. Dynamic Forms는 추가적인 성능 향상으로 프로그레시브 렌더링을 사용하여 필드가 많은 페이지의 로드 시간을 개선합니다.

- 화면 플로는 LWC를 기반으로 구축됩니다. 대부분의 개별 기본 제공 구성 요소는 이제 **파일 업로드** 및 **이미지** 구성 요소를 제외하고 LWC로 전환되었습니다. Flow 팀이 플로 런타임 클라이언트(및 대부분의 구성 요소)를 LWC로 전환했지만, 고객은 여전히 자신의 Aura 화면 구성 요소를 LWC로 변환해야 합니다. Salesforce는 화면 플로의 **반응형 구성 요소** 프레임워크 내에서만 LWC 구성 요소를 지원합니다. 자세한 내용은 [Lightning Web Components for Aura Developer](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers) Trailhead 모듈을 참조하십시오. Screen Flow(또는 기타 컨테이너)에 사용할 사용자 정의 구성 요소를 제작할 계획이라면, LWC를 선택하세요!

- 사용할 수 있는 여러 버전의 Omnistudio가 있습니다. 장기 고객이라면 **Angular**를 사용하고 있을 수 있습니다. 모든 신규 고객에게는 LWC 기반 Omniscript 및 FlexCard 사용을 권장합니다. 기존 고객에게도 Angular에서 벗어나도록 권장합니다.

- LWC는 LWC를 기반으로 구축됩니다.

## 자원

<table><tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>동적 양식</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_overview.htm&language=en_US&type=5">동적 양식으로 레코드 세부 정보를 분할하세요</a><br>- <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Lightning 앱 빌더 도움말을 확인하세요</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>화면 플로</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">스크린 플로를 사용하여 사용자와 상호 작용</a><br>- <a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">플로를 사용하여 작업을 자동화하세요</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_omnistudio.htm&release=236&type=5">Omnistudio</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">Omniscripts</a><br>- <a href="https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5">IDX 워크벤치 데스크탑 애플리케이션</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">뉴포트 디자인 시스템</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">뉴포트 디자인 시스템으로 Omniscripts 및 FlexCards를 맞춤 설정하세요</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">- <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">Lightning 웹 구성 요소</a><br>- <a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Lightning Aura 구성 요소 개발자 가이드</a><br>- <a href="https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers">Aura 개발자를 위한 Lightning 웹 구성 요소</a></td></tr></table>

<!-- document id=78e04911018b22f8cfc2362471e70ca47710e1fae588bfd671603511fd67e8dc url=/architect/current/ko-kr/decision-guides/guides/record-triggered.md -->

# 레코드 트리거형 자동화

Salesforce Platform은 복잡한 비즈니스 프로세스의 요구를 충족하기 위해 자동화 아키텍처를 지속적으로 향상했습니다. 이전 세대(워크플로 규칙 및 프로세스 빌더)는 이벤트 중심 논리의 초기 단계를 제공하여 이벤트 중심 논리의 자동화 기능을 확장하고 더 광범위한 빌더에게 도달 범위를 확대했습니다.

이러한 발전은 다음의 두 가지 보완적인 기둥에 중점을 둔 고성능 통합 아키텍처로 끝났습니다. 레코드 트리거 플로우 및 Apex 트리거.

## 가이드 개요

이 문서에서는 트리거 자동화를 설계할 때 정보에 근거한 결정을 내릴 수 있는 프레임워크 및 지침을 제공합니다. Salesforce 레코드 변경 사항으로 인해 트리거되는 올바른 자동화 접근 방식을 선택하도록 안내하는 세 가지 주요 결정 지점에 대한 사용 사례 요구 사항의 균형을 맞춥니다.

## 대상 제품

<table style="border:none">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">플로</td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Salesforce Flow는</a> 강력한 포인트 앤 클릭 자동화 도구로 사용자가 코드를 작성하지 않고 Flow Builder를 사용하여 복잡한 비즈니스 프로세스, 화면 및 논리를 시각적으로 구축할 수 있습니다. 데이터 업데이트, 이메일 보내기, 사용자 안내와 같은 과업을 자동화하여 화면 플로(사용자 상호 작용) 및 트리거 플로(레코드/예약 이벤트)와 같은 유연성을 제공합니다.</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Apex</td> 
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a>는 Java와 유사한 Salesforce 플랫폼의 독점적이고 개체 지향 프로그래밍 언어로, 사용자 지정 비즈니스 논리를 구축하고 프로세스를 자동화하며 선언적 도구를 넘어 핵심 CRM 기능을 확장합니다.</td>
    </tr>
  </tbody>
</table>

## 서비스

Salesforce Platform에서 확장 가능하고 유지보수가 용이하며 고성능의 레코드 트리거형 자동화를 구축하려면 체계적이고 아키텍처 중심의 접근 방식이 필요합니다. Flow와 Apex 사이의 선택과 각각의 구현은 명확한 원칙 집합에 따라 결정됩니다. 이러한 사항은 이러한 원칙을 요약하고 현대 자동화 설계의 기본 규칙 역할을 합니다.

- **Salesforce 개체 자동화 밀도에 따라 작업에 적합한 도구를 선택합니다.**

  - Salesforce 개체에 대한 레코드 트리거형 플로를 사용하여 **저밀도** 자동화를 수행합니다.

  - **중간 밀도** 자동화의 경우, 호출 가능한 Apex로 레코드 트리거형 플로 논리를 보완합니다.

  - Salesforce 개체에 대한 Apex 트리거를 사용하여 **고밀도** 자동화를 수행합니다.

- **비동기 프로세스를 트리거할 때 주의하십시오.**  
  이 규칙은 레코드 트리거 플로에서 비동기 프로세스를 호출하거나 Apex에서 큐어블 작업을 큐에 추가하는 경우에 적용됩니다. 이 패턴은 작업을 오프로드하는 데 유혹적일 수 있지만, 복잡한 오류 처리 시나리오를 초래하고 거버너 제한에 도달할 위험을 높일 수 있습니다.

- **Salesforce 개체당 하나의 입력 지점을 사용합니다.**  
  지정된 Salesforce 개체의 경우 한 메커니즘을 자동화의 진입점으로 사용합니다. 동일한 개체에 대한 입력 지점으로 Flow 및 Apex 트리거를 혼합하지 마십시오.

## 결정 지점

고려해야 할 세 가지 주요 결정 사항이 있습니다.

- 선언적 및 프로그래밍 방식 구현 비교
- 자동화 밀도
- 밀도 선택 매트릭스

### 선언적 및 프로그래밍 방식 구현 비교

플로와 Apex는 공통의 기본 기능 집합을 공유합니다. 각 도구는 레코드를 쿼리하고, 조건부 논리를 실행하고, 변수를 할당하며, 레코드 생성, 업데이트, 삭제와 같은 DML 작업을 지정된 순서대로 수행할 수 있습니다.

그러나 이 기능적 겹침은 도구를 상호 교환할 수 있다는 의미는 아닙니다. 아키텍처 선택은 과업을 수행할 수 _있는지_ 여부가 아니라 과업을 수행하는 _방법_ 및 성능, 확장성, 유지 관리에 미치는 장기적인 영향에 관한 것입니다. 플로는 선언적 명확성과 간단한 프로세스 구현 속도에서 뛰어나며, Apex는 복잡한 솔루션에 필요한 세밀한 제어와 강력한 기능을 제공합니다.

### 자동화 밀도

**자동화 밀도**은 특정 Salesforce 개체에 배치되는 로드입니다. 이는 개체의 최적 구현을 결정하기 위한 휴리스틱 역할을 합니다. 자동화 밀도가 증가함에 따라 트랜잭션 제한을 위반할 가능성이 증가합니다.

볼륨 및 복잡성의 세 가지 특정 치수를 검사하여 자동화 밀도를 계산합니다.

- **자동화 수량:** 단일 DML(데이터 조작 언어) 이벤트 동안 실행되는 고유한 자동화 메타데이터 항목(플로, 트리거 작업 등)의 원시 수입니다.

- **레코드 볼륨:** API 로드 또는 대량 배치 처리를 통해 처리되는 트랜잭션당 레코드이며, 이는 성능이 매우 중요합니다.

- **의존성 확산:** 초기 CRUD 작업으로 트리거된 다운스트림 DML 작업의 측정값입니다. 이는 하나의 업데이트가 관련 개체에 대한 업데이트로 연쇄적으로 이어질 때, 그 그래프의 깊이를 정량화합니다(예: 사례 → 계정 → 연락처 → 사용자 정의 롤업).

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/automation-density.png" alt="자동화 밀도 치수">

Salesforce 애플리케이션의 범위와 복잡성이 증가함에 따라 단일 기본 진입점(레코드 트리거형 플로 또는 Apex 트리거 중 하나)으로 정하십시오. 단일 Salesforce 개체에서 자동화를 여러 메커니즘으로 분할하면 유지보수가 어려워지고 관리가 분산됩니다. 따라서 이를 피해야 합니다.

### 밀도 선택 매트릭스

이 매트릭스를 사용하여 Salesforce 개체에 대한 필수 아키텍처 표준을 결정합니다.

- **레코드 트리거형 플로**는 낮은 자동화 밀도에 권장되는 솔루션입니다. 이는 강력한 기능과 접근성의 균형을 제공하여, 간단하고 서로 독립적인 자동화에 이상적입니다.

- **하이브리드 패턴(레코드 트리거형 플로우와 호출 가능한 Apex)**은 복잡성이 증가하는 중간 밀도의 자동화에 강력하고 유지보수가 용이한 선택입니다. 이 패턴을 사용하면 팀이 계산 집약적인 작업을 Apex에 위임하면서, 선언적 플로우에서 질서 있는 조율을 유지할 수 있어 접근성과 성능의 균형을 맞출 수 있습니다.

- **Apex 트리거**는 고밀도 자동화를 지원하는 견고한 아키텍처 기반을 구축하는 데 필요한 필수 구성 요소입니다. Apex 성능, 세분화된 제어, 개체 지향적 추상화 및 다형성은 이러한 시나리오의 복잡성과 규모를 관리하는 데 더 적합합니다.

<table>
  <thead>
    <tr>
      <th scope="col" style="width:8%">밀도 수준</th>
      <th scope="col" style="width:18%">자동화 수량</th>
      <th scope="col">데이터 용량(배치 크기)</th>
      <th scope="col">종속성 확산</th>
      <th scope="col">아키텍처 표준</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>낮음</b></td>
      <td><b>&lt; 15</b><br>
        자동화</td>
      <td><b>표준</b><br>
        사용자 중심 UI 상호 작용 또는 소규모 API 로드(1~200개 레코드)</td>
      <td><b>분리형</b><br>
        자체 로직. 동일한 개체 또는 관련 개체에 대한 다운스트림 DML 작업 0~1개입니다.</td>
      <td><b>레코드 트리거 플로우</b></td>
    </tr>
    <tr>
      <td><b>중간</b></td>
      <td><b>15–30</b><br>
        자동화</td>
      <td><b>중간</b><br>
        표준 배치 처리(주의 깊게 대량 처리해야 하는 논리 사용)</td>
      <td><b>커플링됨</b><br>
        상위/하위 업데이트: 다운스트림 DML 작업 2~4개. 반복 위험</td>
      <td><b>하이브리드 패턴</b><br>
        레코드 트리거형 플로우 + 호출 가능한 Apex</td>
    </tr>
    <tr>
      <td><b>높음</b></td>
      <td><b>> 30</b><br>
        자동화</td>
      <td><b>높음</b><br>
        대량 API 로드가 있는 대용량 데이터(2,000 – 10,000개 이상의 레코드)</td>
      <td><b>복잡하고 반복적임</b><br>
        복잡한 종속성 그래프 (다운스트림 DML 작업 5개 이상). 삼각형 반복 루프의 위험</td>
      <td><b>Apex 트리거 메타데이터 프레임워크</b></td>
    </tr>
  </tbody>
</table>
실제 아키텍처를 결정하려면 자동화 밀도의 모든 차원을 종합적으로 고려해야 합니다. 주어진 Salesforce 개체에 대한 자동화 메커니즘을 선택할 때 잠재적인 미래 범위를 고려하십시오.

또한 Salesforce는 멀티테넌트 환경에서 공유 자원 관리와 [거버너 제한](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm)을 적용하여 런웨이 자동화가 공유 자원을 독점하지 않도록 하기 때문에 일일 총 DML 작업 수를 고려하십시오. 일일 DML 용량이 많은 Salesforce 개체는 주의를 기울여 자동화를 선택해야 합니다. 예를 들어, CPU 시간(60,000ms) 및 힙 크기(12MB)에 대한 비동기 제한은 동기 제한보다 높습니다. 또한 비동기 실행에 대한 조직 전체 24시간 제한(250,000 또는 사용자 라이선스의 200배)은 런타임 예외를 피하기 위해 아키텍처 설계에 일일 총 DML 작업 수를 고려해야 합니다.

## 제품 비교

레코드 트리거형 플로는 레코드 트리거형 자동화를 위한 플랫폼의 주요 선언적 도구입니다. 플로의 사용 편의성과 내장된 플랫폼 보안을 통해 팀은 확장 가능하고 신뢰할 수 있는 솔루션을 쉽게 구축할 수 있습니다. Salesforce Platform에 솔루션을 구축하는 대부분의 팀에게 이상적인 선택입니다.

Apex는 이 플랫폼의 독점적이며 강력한 타입의 객체 지향 프로그래밍 언어입니다. 자동화 밀도가 높은 Salesforce 개체와 고성능, 정교한 논리 또는 트랜잭션을 세밀하게 제어해야 하는 사용 사례에는 Apex를 사용하세요.

의사결정 과정을 지원하기 위해, 이 매트릭스는 주요 아키텍처 기능 전반에 걸쳐 Flow와 Apex를 직접 비교합니다.

<table>
  <thead>
    <tr>
      <th scope="col">기능</th>
      <th scope="col">레코드 트리거형 플로</th>
      <th scope="col">Apex 트리거</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>제공 및 유지 보수 속도</b></td>
      <td><b>권장</b><br>
        Flow Builder의 시각적 사용자 인터페이스를 사용하면 관리자 및 기타 선언적 빌더가 Apex 코드를 작성, 테스트 및 배포하는 것보다 빠르게 자동화를 만들고 수정할 수 있습니다. 이 인터페이스를 사용하면 광범위한 팀 구성원이 비즈니스 가치를 전달하고 간단한 과업을 위한 전문 개발자 자원에 대한 의존성을 줄일 수 있습니다.</td>
      <td><b> 전문 지식 필요</b><br>
        Apex 코드를 구현, 테스트, 유지 관리하려면 적절한 기술을 갖춘 소프트웨어 개발자가 필요합니다.</td>
    </tr>
    <tr>
      <td><b>모듈성</b></td>
      <td><b>가용</b><br>
        레코드 트리거 플로는 기본적으로 모듈식입니다. 팀은 모놀리식 논리가 아닌 특정 요구 사항에 대한 개별 플로우를 구축하고 플로 트리거 탐색기를 사용하여 함께 통합합니다. 이 모듈성은 독립적인 수정과 간단한 확장을 가능하게 하여 장기적인 소유 비용을 크게 줄여줍니다.</td>
      <td><b>가용</b><br>
        Apex는 설계상 기능 모듈로 분할되어 있습니다. 각 Apex 클래스는 단일 기능 모듈을 구현하도록 고안되었습니다.</td>
    </tr>
    <tr>
      <td><b>가시성 및 거버넌스</b></td>
      <td><b>권장</b><br>
        Flow의 시각적 특징은 비즈니스 논리를 직관적으로 표현합니다. Flow 트리거 탐색기는 개체에 대한 모든 Flow의 통합 보기를 제공하므로 설계자 및 관리자가 코드를 읽지 않고도 쉽게 이해하고 관리하며 문제를 해결할 수 있습니다.</td>
      <td><b> 전문 지식 필요</b><br>
        메타데이터 프레임워크를 사용하여 트리거를 구성하는 것은 유용하지만, 코드를 체계적으로 유지하고 관리하려면 Apex는 체계적인 개발 팀이 필요합니다.</td>
    </tr>
    <tr>
      <td><b>고성능 대량 데이터 처리</b></td>
      <td><b>권장 안 함</b><br>
        복잡한 논리 또는 대용량 데이터를 처리할 때 거버너 제한에 도달할 위험이 증가합니다.</td>
      <td><b>권장</b><br>
        Apex 코드는 플랫폼의 핵심 서비스와 더 가까이 실행되며 개발자에게 쿼리 최적화, 데이터 처리, 알고리즘 효율성에 대한 향상된 제어 기능을 제공합니다. 따라서 특히 대용량 데이터와 관련된 복잡한 시나리오에서 성능과 확장성이 향상됩니다.</td>
    </tr>
    <tr>
      <td><b>강력한 논리 및 데이터 구조</b></td>
      <td><b>가용</b><br>
        <a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">플로 변환 요소</a>는 몇 가지 복잡한 처리 작업에 도움이 될 수 있습니다. 그러나 Flow에는 기본 Map과 Set 데이터 구조가 없으므로 복잡한 데이터 처리가 번거롭고 계산상 효율적이지 않습니다.</td>
      <td><b>권장</b><br>
        Apex는 Map, Set, 그리고 프로그래밍 루프에 대한 완전한 접근을 제공하여 매우 효율적이고 대량 처리가 안전한 데이터 조작을 지원합니다. 전체 기능을 갖춘 프로그래밍 언어로서 Apex 유지 관리 가능한 효율적인 방식으로 복잡한 비즈니스 문제를 해결하는 데 도움이 되는 복잡한 논리 구조, 데이터 구조, 설계 패턴에 대한 액세스 권한도 제공합니다. Apex에는 선언적 도구에서 현재 사용할 수 없는 고급 함수(예: BusinessHours, Crypto)가 포함된 풍부한 표준 라이브러리가 있습니다.</td>
    </tr>
    <tr>
      <td><b>트랜잭션 관리</b></td>
      <td><b>사용 불가</b><br>
        플로는 부분 트랜잭션 커밋 또는 롤백에 대해 `Database.savepoint`, `Database.rollback` 또는 부분적으로 성공한 DML 작업에 대한 액세스 권한을 제공하지 않습니다.</td>
      <td><b>사용 가능</b><br>
        Apex는 트랜잭션 무결성과 복잡한 오류 복구 시나리오를 완벽하고 세부적으로 제어할 수 있습니다.</td>
    </tr>
    <tr>
      <td><b>이메일 배포</b></td>
      <td><b>권장</b><br>
        레코드 트리거 플로에서 미리 구성된 이메일 경고를 보내는 것은 쉽고 확장 가능합니다. 런타임 시 사용자 정의 이메일 경고를 작성하고 배포할 수 있습니다. 사용자 지정 이메일에는 <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">일일 이메일 보내기 제한이 적용됩니다</a>.</td>
      <td><b>사용 가능</b><br>
        Apex는 사용자 정의 이메일 메시지를 생성하고 보낼 수 있습니다. Apex에서 보낸 모든 이메일은 <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">일일 이메일 보내기 제한</a>이 적용됩니다.</td>
    </tr>
    <tr>
      <td><b>플랫폼 보호 적용</b></td>
      <td><b>권장</b><br>
        플로에는 자동 대량 처리 및 자동 재시도와 같은 기본 보호 기능이 포함되어 있습니다. 이러한 보호 기능은 가치를 빠르게 실현할 수 있도록 하며, 복잡한 수동 코딩이 필요한 성능 문제를 방지합니다.</td>
      <td><b>수동 구현 필요</b><br>
        대량 처리와 같은 보호 조치는 명시적으로 코딩되어야 합니다(예: 컬렉션 관리 및 루프 내 SOQL 방지). 자동 재시도는 트리거에 기본적으로 적용되지 않으며 구현하려면 복잡한 사용자 정의 논리가 필요합니다.</td>
    </tr>
    <tr>
      <td><b>비동기식 처리</b></td>
      <td><b>사용 가능</b><br>
        플로는 비동기 경로에서 별도의 트랜잭션이 필요한 자동화를 위한 간편한 메커니즘을 제공합니다. 이러한 자동화에는 일일 제한이 적용됩니다.</td>
      <td><b>사용 가능</b><br>
        Apex는 Change Data Capture와 분리된 트리거 구독자가 처리하는 Queueable 이벤트를 통해 완전한 제어가 가능합니다.</td>
    </tr>
    <tr>
      <td><b>예약된 처리</b></td>
      <td><b>권장</b><br>
        플로의 예약 경로는 고유하고 강력한 예약 기능을 제공합니다(예: "마감 날짜 3일 전 실행"). 이 기능에는 레코드의 데이터가 변경될 경우 자동 취소 및 재예약이 포함됩니다. 이러한 자동화에는 일일 제한이 적용됩니다.</td>
      <td><b>사용 불가</b><br>
        Apex 트리거는 자동 취소를 통해 시간별 레코드별 이벤트를 기본적으로 예약할 수 없습니다. 예약된 Apex가 존재하지만, 이는 특정 시간에 실행되며 트리거의 일부로 개별 레코드를 처리하는 동안에는 예약되지 않는 근본적으로 다른 메커니즘입니다.</td>
    </tr>
    <tr>
      <td><b>실행 순서 및 조율</b></td>
      <td><b>사용 가능</b><br>
        플로 트리거 탐색기를 사용하면 관리자가 동일한 개체의 여러 플로에 대한 상대 실행 순서를 정의할 수 있습니다.</td>
      <td><b>사용 가능</b><br>
        트리거 프레임워크는 자동화의 정확한 순서를 세부적으로 제어합니다.</td>
    </tr>
    <tr>
      <td><b>같은 레코드 필드 업데이트</b></td>
      <td><b>사용 가능 (저장 전)</b><br>
        레코드 트리거 플로는 초기 DML 커밋 전에 트리거 레코드를 업데이트하는 데 가장 효과적인 선언적 옵션입니다.</td>
      <td><b>사용 가능 (저장 전)</b><br>
        Apex는 최소한의 오버헤드로 최고 수준의 성능을 제공합니다.</td>
    </tr>
    <tr>
      <td><b>교차 개체 CRUD</b></td>
      <td><b>사용 가능 (저장 후)</b><br>
        플로는 복잡성이 낮고 간단한 교차 개체 DML 작업에 적합합니다.</td>
      <td><b>사용 가능 (저장 후)</b><br>
        Apex는 교차 개체 DML 작업에 대한 중복 제거, 오류 처리, 성능을 탁월하게 제어합니다.</td>
    </tr>
    <tr>
      <td><b>비용이 많이 드는 연산의 중복 제거</b></td>
      <td><b>사용 가능</b><br>
        플로는 자동 대량 처리를 통해 중복 쿼리 및 DML 문을 제거하는 데 뛰어납니다. 그러나 각기 다른 플로 트리거 또는 단일 트랜잭션 내에서 동일한 플로의 여러 호출에서 상태를 캐시하거나 공유할 수 없습니다. 이 제한 사항은 극한의 성능 시나리오에서 중요해질 수 있습니다.</td>
      <td><b>권장</b><br>
        Apex는 비용이 많이 드는 작업의 중복 제거를 위한 메커니즘을 제공합니다. 개발자는 정적 속성 및 변수를 사용하는 트랜잭션 캐싱과 플랫폼 캐시를 사용하는 플랫폼 수준 캐싱을 활용하여 데이터를 저장하고 재사용할 수 있습니다. 이러한 기술은 SOQL 쿼리와 같은 트랜잭션 거버너 제한의 소비를 줄이고 고성능 및 확장성을 보장하는 데 중요합니다.</td>
    </tr>
    <tr>
      <td><b>사용자 정의 오류 처리</b></td>
      <td><b>사용 가능</b><br>
        CustomError 요소는 저장 작업을 차단하고 사용자에게 메시지를 표시할 수 있습니다.</td>
      <td><b>권장</b><br>
        <code>addError()</code> 메서드는 유연한 필드 수준 및 조건부 오류 메시지를 제공합니다.</td>
    </tr>
  </tbody>
</table>

## 사용 사례

결정 지점을 사용하여 결정을 안내하는 방식을 효과적으로 보여주기 위해, 다음의 사용 사례와 관련 분석 포인트를 고려해 보십시오.

### 가장 적합한 권장 사항

이 표는 제시된 기능을 바탕으로 일반 사용 사례에 대한 최적의 권장 사항을 제공합니다. 궁극적으로 이 문서의 _관련 모범 사례_ 섹션에 포함된 경우와 같이 특정 시나리오에 가장 적합한 시나리오를 찾으려면 추가 고려 사항을 고려해야 합니다. 여기에서 플로와 Apex의 특정 조합이 가장 적합한 접근 방식을 제공하는 경우에 대해 자세히 알아볼 수 있습니다.

<table>
  <thead>
    <tr>
      <th scope="col">사용 사례</th>
      <th scope="col">설명</th>
      <th scope="col" style="width:16%">베스트 맞춤</th>
      <th scope="col" style="width:38%">근거</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>고성능 배치 처리</b></td>
      <td>수천 개의 레코드를 효율적으로 처리해야 하는 모든 자동화</td>
      <td>Apex</td>
      <td>Apex는 플랫폼과의 인터페이스를 위한 다양한 API와 뛰어난 처리 속도를 제공합니다.</td>
    </tr>
    <tr>
      <td><b>복잡한 데이터 처리</b></td>
      <td>고급 데이터 조작이 필요한 시나리오</td>
      <td>Apex</td>
      <td>Apex 플로에서 기본적으로 사용할 수 없는 지도 및 설정과 같은 데이터 구조를 제공하며, 성능이 뛰어난 대량 안전한 코드를 작성하는 데 중요할 수 있습니다.</td>
    </tr>
    <tr>
      <td><b>트랜잭션 제어</b></td>
      <td>세이브포인트, 롤백, 부분 커밋과 같은 제어 메커니즘</td>
      <td>Apex</td>
      <td>Apex Database.savepoint 및 Database.rollback과 같은 메커니즘에 대한 액세스 권한을 제공하며 부분적으로 성공적인 DML 작업을 처리할 수 있습니다.</td>
    </tr>
    <tr>
      <td><b>고급 맞춤형 검증</b></td>
      <td>레코드의 여러 필드에서 데이터 유효성 검사</td>
      <td>Apex</td>
      <td>플로는 `CustomError` 요소로 저장을 방지할 수 있지만, 하위 플로를 포함한 모든 플로 유형에서는 사용할 수 없습니다. Apex <code>addError()</code> 메서드는 트리거 처리를 수행하는 동안 언제든지 레코드에 추가할 수 있는 여러 필드별 오류 메시지를 제공합니다.</td>
    </tr>
    <tr>
      <td><b>간단한 프로세스 내에서 다소 복잡한 논리</b></td>
      <td>단순한 프로세스의 일부로서, 고급 함수의 표준 라이브러리로 간소화된 중간 정도의 복잡성을 가진 논리 및 데이터 조작</td>
      <td>플로 + Apex</td>
      <td>레코드 트리거형 플로는 오케스트레이션 계층으로 작동하며, 복잡도가 높은 작업은 Invocable Apex에 캡슐화됩니다.</td>
    </tr>
    <tr>
      <td><b>단순에서 다소 복잡한 논리까지</b></td>
      <td>복잡성이 낮거나 보통인 데이터 조작, 기본 및 관련 데이터 개체 모두에 대한 트리거 업데이트</td>
      <td>플로</td>
      <td>플로는 관리자와 개발자가 모두 액세스할 수 있는 선언적 모델을 기반으로 하므로 일반적으로 사용 가능 옵션입니다.</td>
    </tr>
    <tr>
      <td><b>고지 및 아웃바운드 메시지</b></td>
      <td>아웃바운드 이메일 및 메시지 보내기</td>
      <td>플로</td>
      <td>플로를 사용하면 레코드 변경 시 이메일 경고와 아웃바운드 메시지를 손쉽게 보낼 수 있으며, 높은 확장성을 제공합니다.</td>
    </tr>
    <tr>
      <td><b>예약된 처리</b></td>
      <td>향후 동적 날짜의 자동화(예: 마감 날짜 3일 전)</td>
      <td>플로</td>
      <td>예약 경로는 플로에 고유한 강점이므로 플랫폼이 레코드의 데이터가 변경될 경우 해당 경로의 예약, 취소, 재예약을 자동으로 처리합니다.</td>
    </tr>
  </tbody>
</table>

### 확장 가능한 처리: 자세한 비동기식 사용 사례

확장성은 구현을 설계할 때 중요한 고려 사항입니다. 레코드 트리거형 자동화의 비즈니스 논리가 복잡하거나 장기적으로 실행되거나 데이터 용량이 많은 경우, Salesforce 플랫폼의 핵심 거버너 제한이 아키텍처 상의 제약 요인이 됩니다. 대량 데이터 업데이트, 복잡한 API 콜아웃 또는 대량 계산과 같은 작업은 단일 데이터베이스 트랜잭션 내의 총 CPU 시간 또는 DML 문 수와 같은 제한을 위반할 위험을 높입니다. 제한 예외로 인해 동기 트리거에 실패하면 사용자의 전체 저장 트랜잭션이 롤백되므로 사용자 환경이 좋지 않고 잠재적인 데이터 손실이 발생합니다. 이 기본적인 위험은 복잡한 작업을 오프로드하기 위한 아키텍처 패턴을 요구합니다.

이 경우 비동기 자동화가 필수적입니다. 설계자는 비동기 메커니즘을 활용하여 장기 실행 또는 대용량 작업을 주 동기식 레코드 저장 트랜잭션과 효과적으로 분리할 수 있습니다. 저장 작업은 빠르고 신뢰성 있게 완료되며, 무거운 처리는 이후에 실행되는 별도의 플랫폼 관리 트랜잭션으로 위임됩니다. 분리하면 안정성이 향상되고 트랜잭션 실패를 방지하며 확장 가능한 엔터프라이즈 응용 프로그램을 구축하는 데 매우 중요합니다. 플랫폼은 신뢰성, 볼륨, 복잡성과 관련하여 각각 고유한 혜택과 제약을 제공하는 몇 가지 특수한 도구를 제공합니다.

### Flow의 비동기 경로

레코드 트리거형 플로 내의 'Run Asynchronously' 경로는 'fire and forget' 방식의 비동기 로직을 구현하는 가장 간단한 메커니즘을 제공합니다. 이 경로는 원래 레코드 저장 트랜잭션이 데이터베이스에 성공적으로 커밋된 후 별도의 트랜잭션으로 실행됩니다.

- **이상적인 사용 사례**: 즉시 실행하거나 사용자 정의 오류 처리가 필요하지 않은 과업에 적합합니다. 예를 들어 이메일 알림 보내기, 팔로우업 과업 만들기 또는 외부 시스템에 대한 간단한 콜아웃을 수행할 수 있습니다.

- **제한 사항**: 이 메커니즘은 다른 비동기 플로 실행과 동일한 일일 거버너 제한을 공유합니다. 매우 대용량 처리에 고안되지 않았습니다.

### 변경 데이터 캡처 (CDC)

변경 데이터 캡처(CDC)는 대용량 시나리오에서 레코드 변경에 의해 트리거되는 비동기 로직을 처리하기 위한, 고처리량과 확장성, 그리고 복원력이 뛰어난 패턴입니다. 이 모델에서 트리거의 유일한 책임은 레코드를 동기식으로 저장하는 것입니다. 그러면 플랫폼이 대용량 이벤트 버스에 레코드의 변경 사항을 포함하는 자세한 이벤트 메시지를 게시합니다. 별도의 전용 Apex 트리거가 이 변경 이벤트를 구독합니다. 복잡한 장기 실행 또는 비동기 작업을 수행합니다.

- **혜택**: 이 패턴은 초기 사용자 트랜잭션에서 비동기 프로세스를 분리합니다. 비동기식 처리에 실패하면 사용자의 레코드 저장이 롤백되지 않습니다. 또한 패턴은 여러 내부 구독자 또는 외부 시스템에서 사용할 수 있는 지속적인 이벤트 스트림을 제공하며 최대 72시간 동안 이벤트를 재생할 수 있어 강력한 복원 능력을 제공합니다.

- **제한 사항**: 변경 데이터 캡처 (CDC) 이벤트 메시지에는 Apex `Trigger.oldMap`에 상응하는 레코드의 이전 상태가 포함되어 있지 않습니다. 이벤트 페이로드에는 새 필드 값만 포함되며, 변경 전의 값은 포함되지 않습니다. 따라서 특정 상태 전환을 기반으로 논리를 구현하는 것이 어려워집니다(예: `Status__c`가 "보류 중"에서 "승인됨"으로 변경된 경우에만 실행). 이벤트 구독자에서 개체의 필드 내역을 쿼리하여 이를 완화할 수 있지만, 이를 통해 프로세스에 복잡성이 추가되고 특정 관심 필드에 필드 내역 추적을 사용할 수 없습니다. 따라서 CDC에 오프로드할 수 있는 자동화 유형을 제한할 수 있습니다.

기본적으로 최대 5개의 Salesforce 개체에 대해 CDC를 활성화할 수 있습니다. 더 많은 개체에 대해 필요로 하는 조직은 이 제한을 제거하고 이벤트 배달 할당량을 늘리는 추가 기능 라이선스를 구매할 수 있습니다.

### 트리거에서 대기 가능한 Apex

트리거에서 직접 대기 가능한 Apex 작업을 대기열에 추가하는 것은 위험한 패턴으로 간주되어야 하며, Apex에서 제공하는 제어가 필요한 경우(예: 복잡한 논리 또는 사용자 정의 재시도 메커니즘)이고 변경 데이터 캡처 (CDC)가 실행 가능한 옵션이 아닐 때만 사용해야 합니다.

대기 가능한 Apex가 필요한 경우, 구현에는 적절한 보안 조치가 포함되어야 합니다.

- **제한 점검**: 코드는 다른 작업을 추가하기 전에 트랜잭션에 이미 대기열에 있는 작업 수를 확인해야 합니다.

  ```
  if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... }
  ```

- **컨텍스트 인식**: 코드는 일괄 처리 작업(`System.isBatch()`)과 같은 비동기 컨텍스트 내에서 실행 중인지 감지하고, 해당 컨텍스트에서 더 엄격한 '트랜잭션당 하나의 작업' 제한을 준수하도록 동작을 수정해야 합니다.

### 트리거된 비동기 Apex에 대한 제한 고려 사항

동기식 트리거에서 비동기식 Apex 호출하면 안정성 위험이 발생합니다. 조직 수준 영향(예: 제한 초과)을 방지하려면 이 패턴을 엄격하게 설계하고 테스트해야 합니다.

- 비동기식 Apex 실행(`Batch`, `Queueable`, `@Future`)의 일일 제한은 조직 전체에서 공유됩니다(일반적으로 250,000개 또는 사용자 라이선스를 기반으로 계산됨). 20,000개의 레코드를 대량으로 로드하면 트리거가 200개씩 청크로 실행되어 100번의 별도 트리거 호출이 발생합니다. 대량 배치 크기가 200개 미만이면 호출 횟수는 더 많아집니다. 각 호출이 비동기 작업을 대기열에 추가하는 경우, 단일 데이터 로드에서 일일 제한의 상당 부분이 소모될 수 있습니다. 이러한 소비로 인해 다른 중요한 비즈니스 프로세스가 비동기 자원을 충분히 활용하지 못할 수 있습니다.

- 작업을 대기열에 추가하는 거버너 한도는 컨텍스트에 따라 크게 다릅니다. UI에서 사용자 작업에 의해 실행되는 트리거(_동기식_ 트랜잭션)에서 최대 50개의 대기 가능한 작업을 대기열에 지정할 수 있습니다. 그러나 배치 Apex 클래스의 `execute` 메서드(_비동기_ 트랜잭션) 내에서 실행되는 트리거의 경우 하나의 대기 가능한 작업만 대기열에 추가할 수 있습니다. 이 차이를 고려하지 못하는 것은 일반적이면서도 치명적인 실패 지점이며, 대용량 데이터 작업 중에 `LimitException` 오류가 발생할 수 있습니다.

- 트리거 컨텍스트에서 직접 Schedulable Apex(`System.schedule`) 또는 Batch Apex(`Database.executeBatch`)를 호출하는 것은 안티 패턴입니다. 이러한 메서드는 트리거 컨텍스트에서 호출되도록 설계되지 않았습니다. 이렇게 하면 비동기 Apex 할당량이 빠르게 소진되어 한도 예외가 발생할 수 있습니다.

### 올바른 비동기 패턴 선택

각 비동기 메커니즘에는 성능, 거버너 제한, 신뢰성과 관련된 특정 트레이드오프가 있습니다. 이 결정 트리를 가이드로 삼아 이러한 옵션을 탐색하고 사용 사례에 적합한 메커니즘을 선택할 수 있습니다.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/async-pattern.png" alt="비동기 패턴 결정 트리">

### 예약 작업의 대안

플로우차트에서 알 수 있듯이, 대용량 DML 작업이 있지만 변경 데이터 캡처를 사용할 수 없는 경우(예: 오브젝트 한도 등), 트리거 기반 프로세스를 완전히 피하는 것이 가장 좋은 아키텍처 선택입니다.

대신 예약된 프로세스를 사용하는 것이 좋습니다. 이는 예약된 플로우 또는 예약된 Apex를 사용할 수 있습니다. 필수 단계는 다음과 같습니다.

1. 동기식 트리거에서 간단하고 비용이 적은 업데이트를 수행합니다. 예를 들어, `Status__c` 필드를 "처리 대기 중"으로 설정하거나 Chatter 게시 등 비용이 적은 관련 레코드를 삽입하여 해당 레코드가 처리되어야 함을 나타냅니다.

2. 15분마다 또는 매시간 등 정기적으로 실행되는 예약 작업(예: 예약된 플로우 또는 예약된 Apex)을 만듭니다.

3. 보류 중 상태인 모든 레코드에 대해 예약된 작업 쿼리를 만들어 제어되는 대용량 컨텍스트에서 복잡한 논리를 실행한 다음, 처리된 레코드를 업데이트합니다.

이 패턴은 사용자의 동기 저장에서 대량 처리를 완전히 분리하고, 트리거로 실행되는 배치의 트랜잭션당 하나의 작업 제한이 적용되지 않으며, 비실시간 요구 사항에 대해 확장 가능하고 관리 가능한 솔루션을 제공합니다.

예약 작업의 지연 시간이 비즈니스 요구 사항에 부합하지 않고, 여전히 CDC나 트리거로 실행되는 큐어블을 사용할 수 없는 경우, 이는 중대한 아키텍처 불일치가 있음을 나타냅니다. 이때 다른 메커니즘을 고려해야 합니다. 핵심 응용 프로그램 설계를 다시 평가하면 다음과 같은 특정 결론을 내릴 수 있습니다.

- 추가 기능을 구매하여 CDC 개체 제한을 제거합니다.

- 비즈니스 요구 사항 자체를 근본적으로 재검토하여, 실시간에 가까운 처리가 정말로 "필수"인지, 아니면 예약된 작업의 대기 시간이 플랫폼 안정성을 위한 허용 가능한 절충안인지를 판단합니다.

## 비기능적 고려 사항

결정 지점 외에도 복잡성 및 표준과 같은 기능적이지 않은 고려 사항을 고려해야 합니다.

### 복잡성

구현의 복잡성 수준은 솔루션의 총 소유 비용과 변화하는 비즈니스 요구 사항에 적응할 수 있는 능력의 일부입니다. 모범 사례를 따르지 않으면 복잡성이 구현에 영향을 미칠 수 있습니다. 이 문서의 _관련 모범 사례_ 섹션에는 다음 패턴을 포함하여 솔루션의 복잡성을 줄이기 위한 권장 사항이 있습니다.

- 하이브리드 패턴: 플로우의 복잡한 논리를 위한 호출 가능한 Apex

- Apex 트리거에 대한 메타데이터 프레임워크 사용

- 메가 플로와 다중 플로 비교

### 프로세스 및 표준

문서는 자동화 자체만큼이나 중요합니다. 문서는 유지 관리성을 보장할 뿐만 아니라, AI 및 에이전트 기반 도구에도 매우 중요합니다. 문서는 비즈니스 프로세스를 이해하고 관리하는 데 도움이 됩니다.

**In Flow**

- 모든 요소 및 변수에 일관된 명명 규칙을 설정합니다.

- 플로에 대한 설명 필드를 사용하여 전체적인 목적, 트리거 기준, 의도한 결과를 설명합니다.

- 각 개별 요소에 대한 설명 필드를 사용합니다(예: `Get Records`, `Action`, `Transform`). 이 방법은 의도를 전달하는 가장 좋은 방법입니다. 특히 호출 가능한 작업 및 하위 플로우에서는 설명이 복잡한 논리를 전달하는 주된 수단이기 때문에 매우 중요합니다.

**In Apex**

- 코드에 논리의 _왜_뿐만 아니라 _무엇_을 명확하게 주석을 달아 설명하세요.

- 메타데이터 구동 프레임워크를 사용하는 경우, 메타데이터 레코드에 사람이 읽을 수 있는 설명 필드가 반드시 포함되어 있고, 각 처리기 클래스가 수행하는 작업과 실행 시점을 설명하도록 해당 필드를 채워야 합니다.

DevOps 및 소스 제어는 성숙한 개발 수명 주기의 일부입니다. 항상 Salesforce 프로젝트에는 Git과 같은 소스 제어 도구를 사용하십시오. Apex 클래스와 Salesforce 플로는 모두 비즈니스 논리를 정의하는 메타데이터이며 버전을 지정하고 관리해야 합니다.

레코드 트리거형 자동화 관리의 컨텍스트 내에서 최신 DevOps 파이프라인은 필수적인 이점을 제공합니다.

- **자동 품질 점검:** [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview)과 같은 도구를 파이프라인에서 자동으로 실행하도록 구성할 수 있습니다. 정적 분석은 두 자동화 도구에서 문제가 발생하기 전에 문제 패턴을 감지할 수 있으며, 이는 성능 저하의 일반적인 원인인 Flow 루프 내의 비효율적인 `Get Records` 요소 또는 Apex for 루프 내의 `SOQL` 쿼리와 같은 문제를 표시합니다.

- **회귀 방지:** 자동화 밀도가 증가함에 따라 하나의 Flow 또는 Apex 클래스로 변경하면 동일한 객체의 다른 자동화에 의도하지 않은 결과가 발생할 수 있습니다. 제안된 변경 사항에 대해 자동화된 Apex 테스트를 실행하는 강력한 DevOps 테스트 전략은 새로운 플로우 버전이 기존 Apex 논리를 중단하지 않도록 보장하는 가장 신뢰할 수 있는 방법입니다(그 반대로).

- **공동 작업 및 가시성:** 소스 제어는 "단일 신뢰할 수 있는 소스"입니다. 관리자와 개발자가 동일한 개체에 대한 자동화 작업을 병렬로 수행할 수 있습니다. 또한 프로덕션 프로세스가 중단되면 자동화를 변경한 _사람_, 변경한 _시기_, 커밋 메시지를 통해 변경한 _이유를_ 즉시 확인할 수 있습니다.

[DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5)는 통합 인터페이스를 제공하여 이러한 모든 단계를 구성할 수 있도록 도와주므로 팀의 모든 구성원이 확장 가능한 소스 제어 기반 개발 프로세스를 이용할 수 있습니다.

문서화 및 DevOps 이행의 결합은 조직의 장기적인 건강과 유지 관리를 보장하여, 당신을 따르는 모든 아키텍트와 관리자에게 큰 혜택을 제공합니다.

## 관련 모범 사례

위의 결정 가이드는 구현을 계획하기 전에 가장 적합합니다. 사용 사례에 가장 적합한 제품을 선택할 수 있도록 지원합니다. 제품을 선택한 후 구현을 위한 기존 모범 사례를 이해하는 것이 중요합니다.

### 하이브리드 패턴 활용: 플로우의 복잡한 논리를 위한 호출 가능한 Apex

_객체당 하나의 도구_ 원칙은 고밀도 자동화 관리에 매우 중요하지만, 이를 순수 선언형 스택과 순수 프로그래밍형 스택 중 하나를 선택해야 하는 이분법적 선택으로 해석해서는 안 됩니다. 보다 효과적이고 유지 보수 가능한 아키텍처 패턴은 하이브리드 모델을 활용합니다. 레코드 트리거드 플로우를 오케스트레이션 계층으로 배치하고, 고복잡성 작업을 Invocable Apex 내에 캡슐화합니다.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/hybrid-pattern.png" alt="하이브리드 패턴 다이어그램">

#### 오케스트레이션 레이어: 플로

레코드 트리거 플로는 비즈니스 프로세스의 오케스트레이션 계층 역할을 합니다. 그것은 입장 기준과 실행 컨텍스트 (_무슨_과 _언제_)를 소유합니다. 결정 논리와 라우팅을 이 계층 내에 유지함으로써 플로 트리거 탐색기를 통해 아키텍처의 프로세스 토폴로지를 투명하고 관리할 수 있어 중요 비즈니스 논리가 코드 내에서 숨겨지지 않도록 방지합니다.

#### 복합 구성 요소: 호출 가능한 Apex

복잡한 구성 요소의 일반적인 예는 사례 레코드에 대한 서비스 수준 계약(SLA) 계산 구현입니다. 비업무 시간 및 휴일을 제외한 정확한 계산에 중요한 BusinessHours 개체와 관련 논리가 Flow에서 기본적으로 액세스할 수 없으므로 전용 Apex 클래스가 사용됩니다. 이 클래스는 종종 `ServiceLevelAgreementCalculator`과 같은 이름으로 불리며, `@InvocableMethod` 어노테이션이 붙은 단일 정적 메서드를 사용하여 경과된 업무 시간을 계산하고 SLA가 '목표 범위 내'인지 '실패'인지를 판별하며, 구조화된 결과를 반환합니다. 이 접근 방식은 복잡하고 고성능의 논리를 Apex에 캡슐화하여, 이를 레코드 트리거 플로의 선언적 오케스트레이션 계층 내에서 원활하게 실행 및 통합할 수 있도록 합니다.

Apex `ServiceLevelAgreementCalculator` 클래스가 정의되면 레코드 트리거 플로 내에서 사용할 수 있습니다.

이 패턴은 우려 사항을 엄격하게 구분하는 것을 보여줍니다. 선언적 레이어는 트랜잭션 수명 주기 및 오케스트레이션을 관리하는 데 사용되며 코드는 복잡한 실행에 사용됩니다. 코드를 기초가 아닌 기능 유틸리티로 취급하여 성능과 서비스 점검의 균형을 맞춥니다.

#### 하이브리드 패턴의 주요 이점

**모듈성**: 이 결정은 전체 프로세스에 대해 Apex 또는 플로우만 사용하는 일원론적 접근에서 벗어납니다. 대신, 아키텍처는 복잡한 논리를 개별적이고, 대량 처리에 안전하며, 독립적으로 테스트할 수 있는 단위로 캡슐화합니다. 이러한 단위는 선언적 레이어에서 사용되는 재사용 가능한 구성 요소로 작동하므로 아키텍처 설계가 복잡하지 않고 자동화의 규모를 확장할 수 있습니다.

**재사용성**: 논리가 트리거 이벤트에서 분리됩니다. 잘 설계된 코드 유닛(예: `InvocableMethod`)은 한 번 작성되지만 여러 입력 지점에서 활용됩니다. 레코드 트리거 플로, 화면 플로 또는 외부 통합 이 코드를 재사용하면 중복 개발이 제거됩니다.

**유지 관리성**: 프로세스 플로 논리는 선언적 플로 내에서 계속 표시되고 관리할 수 있습니다. 이 중앙 집중화를 통해 디버깅 오버헤드가 크게 줄어들고 시스템의 실행 순서가 결정적이고 투명해집니다.

#### 하이브리드 패턴의 제한 사항 및 제약 사항

플로에서 호출 가능한 Apex를 사용하는 하이브리드 모델은 강력하지만, 만능 접근 방식은 아닙니다. 설계자는 하이브리드 솔루션을 적용하기 전에 특정 제한 사항 및 제약 사항을 알고 있어야 합니다.

- **저장 전 지원 없음**: 이는 가장 중요한 제한입니다. 호출 가능한 작업은 저장 후 컨텍스트(작업 및 관련 레코드용 플로)에서만 사용할 수 있습니다. 고성능 저장 전 컨텍스트(빠른 필드 업데이트용 플로)에서는 사용할 수 없습니다. 따라서 이 패턴을 사용하여 동일한 레코드 필드 업데이트를 위임할 수 없습니다. 저장 전 플로우 또는 저장 전 컨텍스트의 Apex 트리거 내에서 기본 플로우 요소를 사용하여 고성능 작업을 수행하세요.

- **삭제 취소 후 지원 없음:** 레코드 트리거 플로는 현재 삭제 취소 후 컨텍스트를 지원하지 않습니다. Salesforce 오브젝트에 휴지통에서 레코드를 복원할 때 자동화를 실행해야 하는 비즈니스 요구 사항이 있는 경우, Apex 트리거만이 해결책입니다.

- **고용량 시나리오의 성능 오버헤드:** 플로 런타임에서 Apex 런타임으로 전환하는 것은 비용이 들지 않는 작업이 아닙니다. 일반적으로 빠르지만, Flow 런타임에서 Invocable Action으로 진입하는 작업은 Apex 트리거 내에서의 기본 실행만큼 빠르지 않습니다. 대부분의 중간 밀도 자동화의 경우 이 마이크로 오버헤드는 접근성 향상을 위한 무시할 수 있을 정도로 작고, 가치 있는 대가입니다. 그러나 극한의 고성능 및 대용량 시나리오의 경우, 순수 Apex 전용 프레임워크가 순수 연산 속도에서 이점을 가집니다.

### 레거시 자동화 전략

자동화 밀도 휴리스틱은 최신 그린필드 아키텍처에 대해 명확한 지침을 제공하지만, 엔터프라이즈 Salesforce 환경의 현실은 보다 미묘합니다. 성숙한 조직 환경에서는 동일한 Salesforce 오브젝트에서 작동하는 레코드 트리거 플로와 Apex 트리거를 찾는 것이 일반적입니다. 이 시나리오는 앞서 설명한 하이브리드 패턴과는 다릅니다. 여기서, 플로와 Apex 트리거는 결합되거나 함께 작동하도록 설계되지 않습니다.

이러한 공존은 플랫폼 기능이 발전하거나 기존 기술 부채로 인해 발생하는 경우가 많습니다. 이 상태는 허용되는 운영 상태이지만, 설계자는 최종 상태가 아닌 계산된 제약으로 취급해야 합니다.

조각화된 오케스트레이션은 상당한 거버넌스 및 유지 보수 오버헤드를 야기하므로 개발, 테스트, 사고 처리 활동이 분리되고 번거롭습니다. 이로 인해 해결 시간(TTR)과 운영 복잡성이 증가합니다.

- 새 Salesforce 오브젝트의 경우 자동화 밀도 원칙을 기본 지침으로 삼으십시오.

- 하이브리드 특성을 가진, 이중 Apex 트리거와 레코드 트리거 플로 진입점이 있는 기존 Salesforce 오브젝트의 경우, 밀도를 평가한 후 유지 관리 가능한 하이브리드 상태로 리팩터링하도록 설계합니다.

  - 밀도가 낮은 경우, Apex 트리거를 레코드 트리거 플로로 리팩터링하고 실행 순서를 지정하여 단일 자동화 진입점으로 만듭니다.

  - 중간 밀도의 경우, 복잡한 메가 플로를 올바른 실행 순서로 플로의 하위 집합으로 리팩터링합니다. 절대적으로 필요한 경우에만 Apex 트리거를 도입하세요(예: 삭제 취소 후 컨텍스트 지원 등).

  - 높은 밀도의 경우 Apex 트리거를 구현하는 것이 좋습니다.

### Apex 트리거에 대한 메타데이터 프레임워크 사용

Salesforce Platform에서 조직의 비즈니스 프로세스가 성숙해지면 레코드 트리거형 자동화의 용량과 복잡성이 불가피하게 증가합니다. 기본적인 모범 사례는 Salesforce 개체당 _한 개의 Apex 트리거_를 유지하는 것입니다. 플랫폼이 동일한 이벤트에 대해 동일한 개체에서 여러 트리거의 실행 순서를 보장하지 않으므로 이 규칙이 중요합니다. 이 제한은 결정적이지 않은 동작, 경쟁 조건 및 디버그하기 어려운 문제로 이어질 수 있습니다.

그러나 _단일 트리거_ 원칙을 준수하면 관리 가능하고 확장 가능한 방식으로 단일 엔트리포인트에서 호출되는 모든 비즈니스 논리를 관리하고 오케스트레이션하는 아키텍처적인 도전이 발생합니다.

#### Classic 트리거 처리기의 제한 사항

이 아키텍처의 첫 번째 진화는 Classic 트리거 처리기 패턴이었습니다. 이 접근 방식에서는 단일 Apex 트리거가 모든 논리를 해당 처리기 클래스(예: `OpportunityTriggerHandler`)에 위임합니다. 이 방법은 트리거 파일에서 논리를 분리하고 개발자가 처리기 클래스의 방법(예: `afterInsert()`) 내에서 실행 순서를 결정적으로 제어할 수 있도록 합니다.

이 패턴은 개선되었지만 종종 모노리틱 처리기 클래스로 이어집니다. 시간이 지남에 따라 더 많은 비즈니스 요구 사항이 추가되면 클래스가 크고 관리하기 어렵고 격리적으로 테스트하기 어렵게 됩니다. 모든 개별 프로세스의 실행 순서가 단일 메서드에 하드코딩되어 있어, 클래스가 병합 충돌에 취약해지고 대규모 엔터프라이즈 환경에서 거버넌스 및 유지 보수 오버헤드가 크게 증가합니다.

#### 솔루션: 메타데이터 중심 트리거 프레임워크

모듈화 및 오케스트레이션의 핵심 문제를 해결하기 위해 아키텍처는 **메타데이터 중심 트리거 프레임워크**로 전환합니다. 이는 실행 _방법_ 및 _시기에_ 대한 구성에서 자동화 논리 자체를 분리하는 중요한 아키텍처 단계입니다.

이 프레임워크는 다음 세 가지 주요 이점을 기반으로 구축됩니다.

- **파티셔닝:** 단일 처리기 클래스 대신, 핵심 비즈니스 논리는 작은, 원자적인 Apex 클래스(예: `RecalculateAccountValues` 클래스 또는 `NotifySalesLeads` 클래스)로 분할되며, 각 클래스는 _단일 책임 원칙_을 준수합니다. 이 모듈성을 통해 논리를 쉽게 테스트, 디버그, 이해할 수 있습니다.

- **순서 및 오케스트레이션:** 실행 순서는 더 이상 Apex 하드 코딩되지 않습니다. 대신 구성 레코드에 의해 선언적으로 정의되며, 일반적으로 사용자 정의 메타데이터 유형(예: `TriggerAction__mdt`)에 저장됩니다. 이렇게 하면 관리자가 배포 또는 코드 변경이 필요하지 않은 메타데이터 레코드를 수정하여 자동화 작업을 다시 정렬, 추가 또는 제거할 수 있습니다.

- **Bypass 기능:** 프레임워크는 표준화된 세분화된 우회 기능을 제공합니다. 각 자동화 작업은 메타데이터 레코드를 통해 전역적으로 비활성화되거나, 특정 관리 사용자에 대해서는 사용자 정의 권한을 참조하여 우회 설정할 수 있습니다.

그런 다음, 개체에 대한 단일 Apex 트리거는 동적 발송자로만 작동합니다. 여기에는 비즈니스 논리가 포함되어 있지 않고, 대신 중앙 `MetadataTriggerHandler` 클래스를 인스턴스화합니다. 이 처리기는 사용자 지정 메타데이터 레코드를 쿼리하여 실행 순서를 동적으로 결정하고 지정된 순서대로 올바른 원자 Apex 클래스를 호출합니다. 자동화는 투명하고 관리 가능한 단일 계층 아래 통합됩니다.

### 트랜잭션에서 비용이 많이 드는 작업 중복 제거

강력한 프레임워크에서 Apex 사용하면 중복 작업을 제거하여 트랜잭션 상태를 관리하고 성능을 최적화할 수 있는 기능을 활용할 수 있습니다. 논리가 누적되면 저장 순서 내의 다양한 자동화가 동일한 비용이 많이 드는 작업을 독립적으로 실행하여 소중한 거버너 제한을 소모하고 DML 작업 시간을 늘리는 것이 일반적입니다.

프레임워크는 두 가지 기본 전략을 통해 이를 해결하도록 설계되었습니다.

- **공유 상태 관리:** 단일 Apex 트랜잭션 범위 내에서 정적 속성 및 변수가 캐시 데이터에 활용됩니다. 이렇게 하면 트리거의 다른 레코드 또는 단계에서 자동화 논리를 여러 번 호출하는 경우에도 구성 설정에 대한 `SOQL` 쿼리와 같은 비용이 많이 드는 작업이 한 번만 실행됩니다. 트랜잭션 제한 소비량이 현저하게 감소합니다.

- **플랫폼 캐시 활용도:** 단순한 트랜잭션 내 캐싱을 넘어서려면, 플랫폼 캐시를 사용하여 특정 데이터에 대해 전체 데이터베이스를 쿼리하는 것을 피할 수 있습니다. 이 관리형 인메모리 캐시는 기본형이 아니고, 코드베이스 전반에서 자주 읽히며, 트랜잭션 동안 변경되지 않는 데이터를(예: 프로필, 역할, 업무 시간) 조회하는 데 이상적입니다. `Cache.CacheBuilder` 인터페이스를 사용하면 시스템이 캐시를 먼저 확인하고 데이터가 없는 경우에만 데이터베이스 쿼리를 수행하여 성능과 확장성을 극대화합니다.

### 동일 레코드 업데이트에는 저장 전 업데이트를 사용하십시오.

자동화가 트랜잭션을 시작하는 레코드의 필드 값만 변경해야 할 때는 항상 저장 전 업데이트를 사용하십시오. 이 내용은 플로우의 빠른 필드 업데이트(저장 전 실행)와 Apex 트리거의 저장 전 컨텍스트 로직(삽입 전, 업데이트 전) 모두에 적용됩니다.

이 패턴은 두 번째 DML 작업과 반복 저장 주기를 방지하므로, 어떤 도구를 사용하더라도 높은 성능을 보장합니다. 변경 사항은 레코드가 데이터베이스에 커밋되기 _전에_ 메모리에 적용되며 원래 트랜잭션의 일부로 저장됩니다. 그렇지 않으면 전체 저장 순서를 다시 실행하고 모든 자동화를 다시 실행하는 두 번째 저장에 대한 오버헤드가 제거됩니다.

### 제어되지 않는 재귀 방지

제어되지 않는 반복은 트리거의 논리가 DML 업데이트를 수행하여 동일한 트리거가 다시 실행되게 만드는, 후-업데이트 트리거에서 흔히 발생하는 문제입니다. 이로 인해 무한 루프가 생성되고, 결국 governor 제한 예외로 종료됩니다. 정적 불린 플래그나 처리된 레코드 ID 컬렉션이 과거에는 이러한 반복을 방지하는 데 사용되었지만, 더 정밀하고 견고한 패턴은 레코드 자체의 새 버전과 이전 버전의 필드 값을 비교하여 논리 실행을 제어하는 것입니다.

특정 관심 필드가 실제로 변경된 경우에만 논리를 실행합니다. 이렇게 하면 중요한 데이터가 변경되지 않은 동일한 트랜잭션 내의 이후 DML 작업에서 트리거의 로직 실행을 방지합니다.

#### 레코드 트리거형 플로우에서 재귀 제어

레코드 트리거형 플로에서 레코드가 조건 요구 사항을 충족하도록 업데이트되는 경우에만 플로가 실행되도록 설정하여 제어되지 않는 반복을 방지합니다.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/recursion-flow.png" alt="레코드 트리거형 플로우에서 재귀 제어">

플로우의 진입 기준 수식을 사용하기로 선택하면, `$Record` 전역 변수(새 값을 나타냄)와 `$RecordPrior` 전역 변수(저장 이전의 원래 값을 나타냄)를 비교하여 무한 재귀를 방지할 수 있습니다. 예를 들어 기회의 금액 필드가 변경된 경우에만 플로가 실행되도록 하려면 항목 기준에서 다음을 사용합니다.

```
$Record.Amount != $Record__Prior.Amount
```

#### Apex에서 재귀 제어

레코드의 새 버전인 `Trigger.new`의 필드 값을 레코드의 이전 버전인 `Trigger.oldMap`의 필드 값과 비교하여 특정 변경 사항이 발생했는지 확인합니다. 이 접근 방식을 통해 자동화가 동일하게 작동하고 필요한 경우에만 실행되므로 시스템의 효율성을 높이고 재해가 발생하는 반복 루프를 방지할 수 있습니다.

### 자동화 무시

잘 설계된 Salesforce 조직은 자동화를 우회할 수 있도록 일관되고 신뢰할 수 있는 메커니즘이 필요합니다. 이는 선택적 기능이 아니라 데이터 무결성을 유지하고 관리 작업을 활성화하기 위한 핵심 운영 요구 사항입니다.

일부 시나리오에서는 다음과 같이 우회 프레임워크가 필수적입니다.

- 대용량 데이터를 로드할 때 각 레코드마다 트리거가 실행되면 프로세스가 급격하게 느려지고, 제한 예외가 발생하며, 잘못된 관련 레코드 및 알림이 생성될 수 있습니다. 우회를 사용하면 데이터를 원활하고 효율적으로 삽입할 수 있습니다.

- 통합 사용자는 레코드의 외부 시스템에서 데이터를 동기화해야 할 수 있습니다. 일반적으로 사용자 시작 변경(예: 이메일 보내기, 작업 생성)에 대해 실행되는 자동화는 변경이 다른 시스템에서 시작된 경우 바람직하지 않거나 중복될 수 있습니다.

- 관리자 또는 지원 담당자가 레코드에 대한 수정 업데이트를 수행해야 할 수 있습니다. 우회 메커니즘을 사용하면 표준 비즈니스 자동화가 실행되지 않아 변경을 수행할 때 예기치 않은 결과를 초래할 위험을 줄일 수 있습니다.

**사용자 정의 권한**: 우회 논리를 구현하기 위한 최신 확장 가능한 표준은 사용자 정의 권한입니다. 이들은 여러 가지 이유로 이전 방식보다 우수합니다.

- **유연성:** 권한 집합을 통해 사용자에게 사용자 정의 권한을 할당할 수 있습니다. 이 방법은 최신 Salesforce 보안 및 액세스 모델과 일치하므로 세분화되고 유연한 할당을 수행할 수 있습니다. 특정 사용자에게 우회 권한을 부여하거나, 특정 만료 일자/시간이 있는 경우에 한해 일시적으로 허용할 수 있습니다.

- **유지 관리성:** 사용자 정의 권한을 사용하면 프로필 또는 사용자가 자동화 논리에 하드 코딩되지 않습니다. 사용자의 역할이 변경되거나 새 프로필에 우회 액세스가 필요할 경우, 변경 사항은 배포가 필요한 코드나 플로 수정 대신 간단한 권한 집합 할당으로 처리됩니다.

- **확장성:** 사용자 정의 권한은 복잡한 사용자 기반에서 예외를 관리할 수 있는 확장 가능한 프레임워크를 제공합니다. 권한 집합, 권한 집합 그룹 또는 프로필을 통해 사용자에게 할당할 수 있습니다. 권한 집합 또는 프로필에 대한 연결은 소스 메타데이터에서도 표시됩니다.

**구현 패턴**: 조직의 모든 레코드 트리거형 자동화에 일관된 우회 패턴을 적용합니다.

**레코드 트리거 플로 우회**: 플로가 실행되지 않도록 차단하는 것이 가장 효과적인 방법입니다. 플로의 항목 기준에 조건을 추가하면 이 작업을 수행할 수 있습니다.

- 레코드 트리거 플로의 시작 요소에서 조건 요구 사항을 수식이 True로 평가됨으로 설정합니다.

  - 수식 빌더에서 `$Permission` 전역 변수를 사용하여 사용자 정의 권한에 대한 확인을 통합합니다. 기존 항목 기준과 확인을 결합합니다.

    - 수식 패턴:

    ```
    ( ) && NOT($Permission.Bypass_This_Flow)
    ```

  - 이 패턴을 사용하면 사용자에게 지정된 사용자 정의 권한이 할당되지 _않은_ 경우에만 플로가 실행됩니다. 이 확인은 플로 인터뷰가 생성되기 전에 수행되므로 가장 성능이 뛰어난 접근 방식입니다.

**Apex 트리거 프레임워크 우회**: Apex 메타데이터 구동 트리거 프레임워크에 바로 우회 논리를 통합하여 세부적으로 제어할 수 있습니다.

- `TriggerAction__mdt` 사용자 정의 메타데이터 유형에는 텍스트 필드(예: `BypassPermission__c`)가 포함되어야 합니다.

  - `MetadataTriggerHandler` 클래스에서 동적으로 작업을 실행하기 전에 코드는 이 필드의 값을 읽어야 합니다.

  - 필드가 채워지면 처리기가 `FeatureManagement.checkPermission()` 메서드를 사용하여 현재 실행 중인 사용자에게 지정된 사용자 정의 권한이 있는지 확인합니다.

  - `checkPermission()`이 true를 반환하면 처리기가 해당 특정 작업을 건너뛰고 순서대로 다음 작업으로 진행합니다.

  - 이 패턴은 전역 우회(모든 `TriggerAction__mdt` 레코드가 동일한 권한을 참조하는 경우)와 세분화된 작업별 우회(다른 레코드가 다른 권한을 참조하거나 일부 레코드에 우회 권한이 전혀 없는 경우)를 모두 허용하기 때문에 강력합니다.

### 메가 플로와 다중 플로 비교

이는 모든 개체 자동화를 하나의 대규모 메가 플로로 통합하는 것은 안티 패턴입니다. 하나의 플로에 통합하고 여러 조건이 적절한 플로로 논리를 분할해도 성능에 큰 영향을 미치지 않습니다. 가장 중요한 성능 향상 효과는 다음과 같습니다.

- 동일한 레코드의 필드 업데이트에 대해서는 저장 전 플로를 사용합니다.

- 정확한 입력 조건을 작성하여 특정 사용 사례에 영향을 미치지 않는 변경 사항에 대해 플로가 실행되지 않도록 합니다.

[플로 트리거 탐색기](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer)를 사용하면 개체의 각 플로에 순서 값을 할당하여 순차 실행 순서를 보장할 수 있습니다.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/trigger-explorer.png" alt="플로 트리거 탐색기">

## 자원

<table>
  <thead>
    <tr>
      <th scope="col">Apex</th>
      <th scope="col">플로</th>
      <th scope="col">작업</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Apex란 무엇입니까?</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_integration_intro.htm">Apex 유틸리티</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Salesforce 플로를 통한 자동화 정보</a></li>
          <li><a href="https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer">플로 트리거 탐색기 소개</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">플로 변환 요소</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/code-analyzer.html">Salesforce 코드 분석기</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5">DevOps Center</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

<!-- document id=69a8ef91dc68bcc1732bba66a50638eb336bd9f4dfb492eba9310b36140d13a9 url=/architect/current/ko-kr/decision-guides/guides/determining-agentic-vs-traditional-workflow-automation.md -->

# 에이전틱 및 기존 워크플로 자동화 선정

이제 Agentforce를 사용하면 규칙으로 단순화할 수 없는 자동화된 작업을 위한 새로운 패러다임을 열 수 있습니다. 이러한 새로운 기능에는 구조화되지 않은 대화에서 고객 의도를 파악하고, 시스템 전반에 걸친 다자간 프로세스를 조정하며, 실시간으로 운영 상황에 대응하는 기능이 포함됩니다. 에이전틱 워크플로는 사전 정의된 단계를 실행하는 대신 결과를 향해 추론하도록 설계된 자동화를 사용합니다. 이러한 요구를 충족하려면 자동화 복잡성의 전체 스펙트럼에서 작동하는 플랫폼과 각 기능이 적합한 위치를 보여주는 프레임워크가 필요합니다.

Agentforce는 Einstein Trust 계층, Reasoning Engine, Agent Script, Flow, Apex, Data 360을 하나의 통합 플랫폼으로 결합합니다. 이 조합은 간단한 레코드 트리거 자동화부터 음성, 비전, 문서, 실시간 Telemetry 전반에 걸쳐 복잡한 다중 에이전트 오케스트레이션에 이르기까지 모든 작업을 처리합니다. MuleSoft는 엔터프라이즈 전반에서 에이전트 워크플로를 연결하는 데 필요한 MuleSoft 패브릭, 거버넌스, 교차 시스템 오케스트레이션을 사용하여 이 플랫폼을 확장합니다. Agentforce Operations(이전의 Agentforce Supply Chain)는 이러한 기능을 운영 및 제조 프로세스의 특정 요구에 적용합니다.

## 가이드 개요

이 가이드는 이 제품 환경 전반에서 정보에 근거한 결정을 내릴 수 있는 오케스트레이션 밀도 프레임워크 및 지침을 소개합니다. 프레임워크는 아키텍트에게 Salesforce Platform의 지능형 자동화 사용 사례에 대한 오케스트레이션 밀도 수준을 사용하여 올바른 도구 및 패턴을 선택하는 반복 가능한 접근 방식을 제공합니다.

## 대상 제품

| 제품               | 설명                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Agentforce            | [Agentforce](https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5)는 Salesforce의 AI 에이전트 구축 및 배포 플랫폼입니다. Atlas 엔진을 사용하여 Apex 및 Data 360을 통해 실시간으로 동적으로 근거가 마련된 작업을 트리거합니다.                                                                                                                                                                                                                                                                                                                           |
| 에이전트 스크립트          | [에이전트 스크립트](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html)는 Agentforce 빌더에서 에이전트의 워크플로, 비즈니스 규칙 및 대화 논리를 정의하는 데 사용되는 선언적 도메인별 언어(DSL)입니다.                                                                                                                                                                                                                                                                                                                                         |
| Agentforce 그리드       | [Agentforce Grid는](https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5) AI 네이티브, 노코드 스프레드시트와 유사한 인터페이스로서 대규모 AI 워크플로를 신속하게 설계하고 운영할 수 있습니다.                                                                                                                                                                                                                                                                                                                                                                     |
| Agentforce Operations | [Agentforce Operations](https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5)(이전의 Agentforce Supply Chain)는 백오피스 비즈니스 프로세스를 간소화하고 자동화하도록 설계된 AI 기반의 공동 작업 흐름 관리 오케스트레이션 플랫폼입니다.                                                                                                                                                                                                                                                                           |
| MuleSoft              | [MuleSoft는](/docs/architect/ko-kr/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html) 기업 통합 및 에이전트 거버넌스를 위한 포괄적이고 통합된 개방형 플랫폼입니다. API 기반 연결 및 MuleSoft 에이전트 패브릭 및 에이전트 브로커를 통해 엔터프라이즈 전반의 에이전트 워크플로를 연결하기 위한 통합 패브릭, 거버넌스 레이어, 교차 시스템 오케스트레이션 파운데이션 역할을 합니다.                                                                                                                                                         |
| 플로 및 Apex        | [Salesforce Flow는](https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5) 코드 없이 복잡한 비즈니스 프로세스를 시각적으로 구축할 수 있는 강력한 포인트 앤 클릭 자동화 도구입니다. [Salesforce Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm)는 Java와 유사하게 Salesforce 플랫폼을 위한 독점적인 개체 지향 프로그래밍 언어입니다. 사용자 정의 비즈니스 논리를 구축하고 프로세스를 자동화하며 선언적 도구 이상의 핵심 CRM 기능을 확장하는 데 사용됩니다. |

## 서비스

Agentforce 규칙 기반 자동화에서 추론 기반 워크플로로의 Salesforce Platform에서 작업이 수행되는 방식의 근본적인 변화를 나타냅니다. 에이전트의 잠재력을 확보하려면 설계자가 에이전트가 적합한 위치, 구성 방법 및 오케스트레이션하는 항목에 대해 의도하고 정보에 근거한 결정을 내려야 합니다. 다음 원칙은 에이전트의 결정에 대한 반복 가능한 지침을 제공합니다.

- **올바른 작업에 적합한 도구를 사용하십시오.** 실행 경로, 모달 혼합 및 목표 복잡성을 기반으로 오케스트레이션 밀도를 사용하여 가장 적합한 솔루션을 결정합니다.

  - **Flows 및 Apex를 활용한 기존 자동화**를 규칙 기반의 결정적 작업에 사용합니다. 이때 결과는 규칙 집합으로 완전히 범위가 지정되고 정의될 수 있습니다. 기존 자동화는 예측 가능하고 반복 가능한 결과를 보장하고 감사 가능성에 매우 중요한 정적 실행 경로를 제공합니다. 엄격한 규정 준수 및 법적 준수를 요구하는 과업에 일반적인 자동화를 선택합니다.

  - 오케스트레이션 복잡성이 낮거나 중간인 대량 추론 사용 사례에 **Agentforce 그리드**를 사용합니다. 이 패턴은 단일 턴 생성적 추론을 사용하여 대량의 CRM 레코드에서 데이터를 분류, 점수화 또는 요약함으로써 즉각적인 감사 가능성과 함께 고처리량 실행을 보장합니다.

  - 원하는 결과는 알지만 설계 시점에 정확한 실행 경로를 지정할 수 없는 개방형 목표가 있는 작업에는 **Agentforce with Agent Script**를 사용합니다. 예측 가능하고 추적 가능한 결과를 보장하기 위해 안내된 결정주의를 통해 추론이 필요한 요구 사항에 이 패턴을 적용합니다.

  - 공급 체인 워크플로를 위한 AI 지원 관리로 협업형 비즈니스 프로세스를 간소화 및 자동화하려면 **Agentforce Operations**를 사용합니다.

- **오케스트레이션 밀도가 낮은 사용 사례에 에이전트 워크플로를 적용하지 마십시오**. 기능 및 비 기능 요구 사항에 대한 기존 자동화와 에이전트 자동화 간의 제약을 평가합니다. 기존 자동화는 사용 사례에 필요한 규모, 신뢰도, 성능을 제공할 수 있습니다.

- **Agent Automation Hybrid 접근 방식**을 채택하십시오. 이는 Agentforce와 기존 자동화를 Flows 및 Apex와 결합할 때, 단독으로 에이전트 자동화 또는 기존 자동화를 사용하는 것보다 더 큰 가치를 제공하는 경우에 해당합니다.

## 결정 지점

Salesforce sObject는 일반적으로 레코드 자동화를 위한 기본 입력 지점입니다. 시스템은 삽입, 업데이트 또는 삭제와 같은 데이터 조작 언어(DML) 이벤트 직후에 규칙을 기반으로 논리를 실행합니다. 효율적인 [레코드 트리거형 자동화](/docs/architect/ko-kr/decision-guides/guide/record-triggered.html)를 위한 도구를 선택하기 위해 자동화 수량, 레코드 볼륨 및 종속성 확산을 고려하여 시스템의 복잡성을 측정하는 수단으로 [자동화 밀도](/docs/architect/ko-kr/decision-guides/guide/record-triggered#automation-density.html)을 도입했습니다. 기존 자동화는 구조화된 스키마 준수 및 규칙 기반 구조로 데이터를 가져오기 위해 필요한 광범위한 사전 작업으로 제한됩니다.

에이전트 자동화는 원하는 결과를 달성하기 위해 사유를 적용할 수 있는 입력으로 사용자 의도 또는 구조화되지 않은 데이터를 사용하여 기존 자동화를 업그레이드합니다. 설계자는 다중 모달 비정형 데이터에 대한 확률적 추론을 활용할 시기와 예측할 수 없는 결과의 위험을 완화하기 위해 결정적 안내 워크플로를 적용할 시기를 결정해야 합니다.

요구 사항이 규칙 기반 단계 실행에서 결과에 대한 추론으로 바뀌면 설계자가 제안된 솔루션의 추론 깊이와 목표 복잡성을 평가할 수 있는 표준화된 프레임워크가 필요합니다.

### 오케스트레이션 밀도

오케스트레이션 밀도는 에이전트 워크플로 내의 복잡성 측정값입니다. 오케스트레이션 밀도는 실행 경로, 목표 복잡성, 모달 혼합과 같은 세 가지 요소로 결정됩니다. 자동화 밀도는 시스템 규칙 및 볼륨의 물리적 복잡성을 측정하지만 오케스트레이션 밀도는 목표를 향한 에이전트 경로의 추론 복잡성을 측정합니다. 복합 오케스트레이션 밀도를 사용하여 설계 요구 사항을 평가하고 아키텍처 표준에 맞춥니다.

- **실행 경로**: 설계 시 워크플로의 범위를 완전히 지정할 수 있는 정도입니다. 완전히 지정된 워크플로는 워크플로가 사전 결정된 실행 경로로 이어지는 모든 분기와 결과를 정의함을 의미합니다. 지정할 수 없는 워크플로는 컨텍스트 데이터 및 지침에 대한 추론을 통해 런타임 중에 나타날 수 있는 경로가 있습니다.
- **목표 복잡성**: 워크플로가 런타임 시 해결해야 하는 고유한 결과, 결정 지점 및 경로 변형의 수입니다. 복잡도가 낮은 워크플로는 사전 결정된 결과가 있는 단일 포함된 과업을 처리하고, 복잡도가 높은 목표는 설계 시 예상할 수 없는 가장자리 사례와 경쟁하거나 충돌하는 목표가 있는 여러 스테이지에 걸쳐 있습니다.
- **모달 믹스**: 워크플로에서 처리해야 하는 입력 유형의 범위 및 워크플로에서 생성해야 하는 출력 양식입니다. 낮은 모달 혼합은 표준 CRM 필드를 읽고 레코드 업데이트를 생성합니다. 중간 모달은 구조화된 CRM 필드와 이메일 본문 또는 사례 기록과 같은 정적 비정형 데이터를 혼합하여 레코드 업데이트를 생성합니다. 높은 모달 혼합은 라이브 오디오나 텔레메트리와 같은 동적 실시간 스트림을 사용하고, 여러 외부 시스템에서 다중 모달 출력을 생성합니다.

![실행 경로, 목표 복잡성 및 모달 혼합 축을 보여주는 오케스트레이션 밀도 프레임워크 다이어그램](https://architect.salesforce.com/ns-assets/determining-agentic-automation-orchestration-density-framework.png)

### 계수 순서

적절한 오케스트레이션 밀도 수준을 결정하려면 실행 경로, 목표 복잡성, 모달 조합을 순차적으로 평가해야 합니다. 먼저 실행 경로를 검사합니다. 경로를 완전히 지정할 수 있는 경우 기존 자동화부터 시작합니다. 추론이 필요 없는 결정적 경로를 단순히 오케스트레이션하고 실행하기 위해 에이전트 솔루션을 사용하는 것은 안티 패턴입니다. 이는 에이전트 확산(비관리 AI 에이전트의 과도한 확산) 및 에이전트 슬롭(품질이 낮고 불필요한 AI 생성 출력)으로 이어져 가치가 낮은 결과를 초래합니다.

일부 또는 지정할 수 없는 경로의 경우 계속해서 목표 복잡성을 평가하십시오. 목표 복잡성이 잘 정의되어 있으나 경로 상의 특정 노드에서 확률적 평가가 필요한 경우, 해당 지역적 요구를 충족하기 위해 Flow 또는 Apex의 에이전트를 호출하는 것을 고려하십시오. 대신, 실행 경로의 단계에서 대규모 레코드 집합에 대해 하나 이상의 AI 기반 요구 사항이 필요한 경우에는 Agentforce 그리드를 고려하십시오. 그리드는 여러 AI 또는 에이전트 열을 통해 다단계 시트 기반 워크플로를 지원합니다. 대량 행 지향 실행에 가장 적합합니다. 이 접근 방식을 사용하면 워크플로의 성능이 높고 감사 가능성이 높아 경로를 미리 정의할 수 없는 경우에만 확률적 추론을 호출합니다.

경쟁 차원(예: 사기 감지, 증권 준수, 고객 만족도와 함께 보험 청구 지급 결정) 및 지정 불가능 실행 경로에 따라 목표 복잡성이 증가함에 따라 Agentforce 에이전트 스크립트를 사용하여 자동화에 대한 안내 결정성을 고려하십시오. Salesforce 및 타사 시스템과 관련된 교차 엔터프라이즈 사용 사례의 경우 MuleSoft Fabric 및 Agent Broker를 사용하십시오.

마지막으로 모달 혼합을 평가하여 다중 모달 연결 또는 전문 통합과 같은 필수 기술 기능을 식별합니다. 모달 혼합은 밀도 계산기가 아닌 기능 선택기로 작동합니다. 기본 오케스트레이션 논리를 변경하지 않고 솔루션의 입력 및 출력 형태를 처리하는 데 필요한 인프라를 결정하는 데 도움이 됩니다.

### 밀도 선택 매트릭스

이 매트릭스를 사용하여 에이전트 자동화의 아키텍처 표준을 결정합니다. 자동화 문제를 해결하는 접근 방식을 선택하여 기존 자동화와 에이전트 자동화의 균형을 맞춥니다.

- **기존 자동화(낮은 오케스트레이션 밀도):** 레코드 변경으로 프로세스가 트리거되고 데이터가 구조화되고 논리가 규칙 기반이며 미리 결정되어 있고 결과가 예측 가능해야 하는 경우 일반 자동화를 사용합니다(예: 표준 가격 계산 또는 자동 과업 생성).
- **Agentforce 그리드(저~중간 오케스트레이션 밀도):** 기존 레코드에서 대량의 AI 작업을 처리해야 하는 경우에는 Agentforce 그리드를 사용하십시오(예: 이 목록의 모든 계정에 대해 마지막 50건의 사례를 요약하고, 감정 점수를 계산하여 사례 필드에 저장).
- **하이브리드 오케스트레이션(고급 증강 자동화):** Flow와 Apex의 트랜잭션 무결성이 필요한 복잡한 종단간 비즈니스 프로세스(예: 청구 처리 또는 온보딩)를 자동화할 때 하이브리드 오케스트레이션을 사용합니다.
- **Agentforce Agent Script(높은 의도 복잡성):** 입력 지점이 비정형(예: 채팅, 이메일, 음성)이고, 해결을 위해 대화 또는 모호한 사용자 요청을 처리할 수 있는 능력이 필요할 경우 Agent Script를 사용합니다.

| 밀도 수준     | 실행 경로                                                                                                     | 목표 복잡성                                                                               | 모달 혼합                                                                                                                | 아키텍처 표준                                                                                                                                          |
| :---------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **낮음**           | 완전히 지정 가능                                                                                                  | **낮음:** 미리 정의된 결과가 있는 단일 작업입니다.                                     | **단일 모달리티:** 구조화된 Salesforce 개체 레코드를 읽고 작성합니다.                                                 | 레코드 트리거형 자동화. 사용 사례에 하나 이상의 추론 과업이 있는 경우 워크플로에서 에이전트 액션을 사용합니다.                                              |
| **낮음 - 중간** | 전체 또는 부분적으로 지정 가능                                                                                     | **낮음:** 미리 정의된 결과가 포함된 일련의 단계입니다.                                           | **혼합 모달리티:** 입력 또는 출력에는 구조화된 데이터와 구조화되지 않은 데이터가 혼합되어 있을 수 있습니다.                                   | Agentforce 그리드 배치 추론을 사용하여 에이전트 액션을 통해 기존 레코드 전체에서 대량 작업을 처리합니다.                                                                |
| **중간**        | 전체 또는 부분적으로 지정 가능. 실행 경로는 미리 정의되지만 중간 단계에는 추론이 필요합니다.           | **중간:** 결과가 가변적인 Apex 또는 Flow 기반의 일련의 단계로 구성됩니다.                        | **혼합 모달리티:** 입력 또는 출력에는 소량의 구조화된 데이터와 비구조화된 데이터가 혼합될 수 있습니다.                        | 하이브리드(Agentforce + Apex/Flow): Agentforce를 고밀도 추론 및 계획에, Agent Script를 안내 결정성에, Apex/Flow를 오케스트레이션에 사용합니다. |
| **높음**          | 부분적으로 또는 지정 불가. 목표는 미리 정의되었지만 중간 단계에는 런타임 컨텍스트와 사용자 의도가 필요합니다. | **높음:** 여러 경쟁 목표와 방대한 추론 요구가 수반되는 경우에는 결정적인 결과가 필요합니다. | **혼합 모달리티:** 입력 또는 출력에는 실시간으로 도착하는 대용량 구조화된 데이터와 구조화되지 않은 데이터가 혼합되어 있을 수 있습니다. | 에이전트 스크립트를 사용하여 결정적 제어와 추론의 균형을 맞춥니다. 복잡한 다중 에이전트 공동 작업을 위해 타사 MCP 또는 A2A에 MuleSoft 에이전트 패브릭을 사용합니다.  |

## 제품 비교

| 기능                     | 기존 자동화(플로/Apex)                                                                                        | Agentforce 그리드                                                                                                                               | Agentforce                                                                                                                             | Agentforce 및 Agent 스크립트                                                                                                                           |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **논리 유형 및 결정론**   | **결정적:** 고정된 if-then-else 논리를 사용합니다. 실행 경로는 레코드 상태를 기반으로 100% 예측할 수 있습니다.           | ** 혼합:** 구조화된 단계를 통해 결정적이고, 개별 AI 단계는 확률적일 수 있습니다.                                                 | **확률적:** 목표를 향한 최적의 경로를 결정하기 위해 다중 턴 추론을 사용합니다.                                                 | **지향적 결정론:** 추론을 사용하여 경로를 계획하고 결정적 노드 경로에서 실행을 허용합니다.                                              |
| **배송 속도**          | **권장(플로):** 시각적 도구를 사용하면 코드 없이 레코드 트리거형 논리를 빠르게 구축할 수 있습니다.                         | **반복적인 AI 자동화에 권장:** 새 플로를 구축하지 않고 기존 레코드 집합에서 AI 논리를 적용하는 가장 빠른 방법입니다.           | **권장:** 특정 도메인 또는 문제에 대한 하위 에이전트(이전의 주제), 지침 및 스킬 매핑 구성을 위한 것입니다. | **권장:** 상태 기반 그래프 및 가장자리 논리의 고급 매핑                                                                            |
| **입력 방식**             | **정형 데이터에 권장:** CRM 필드 및 관련 레코드 컬렉션으로 제한됩니다.                                | **반정형 데이터에 권장:** 레코드 필드에서 대량의 텍스트(설명, 전사)를 처리합니다.                                      | **다중 모달에 권장:** 자연어, 음성, 시각(구형화되지 않은 데이터)을 처리합니다.                                    | **고밀도 데이터에 권장:** 실시간 시스템 상태 데이터로 다중 모달 입력을 합성합니다.                                                     |
| **추론 깊이(계획)** | **사용 불가:** 논리는 명령형이며 단계를 동적으로 "생각"하거나 계획할 수 없습니다. 그러나 에이전트에게 데이터를 보낼 수 있습니다. | **낮음:** 레코드 집합에 적용되는 단일 단계 추론(배치 AI).                                                                        | **중/높음:** 논리 루프(Reason-Act-Observe)를 사용하여 복잡한 의도를 해결합니다.                                                  | **관리:** 근거는 사전 정의된 비즈니스 상태 그래프를 탐색하는 것으로 제한됩니다.                                                            |
| **모듈화 및 재사용 가능성**   | **권장:** 기본적으로 하위 플로 및 Apex 클래스를 통해 모듈식입니다.                                                        | **제한:** 논리는 일반적으로 특정 그리드 행에 연결됩니다. 전체 행 집합에서 열 설정 및 템플릿 기반 워크플로를 재사용할 수 있습니다. | **사용 가능:** 기술(플로/Apex)은 서로 다른 하위 에이전트(이전의 주제) 및 연결된 에이전트 간에 재사용됩니다.                     | **권장:** 에이전트 그래프의 노드는 재사용 가능한 개별 기능 단위입니다.                                                                     |
| **트랜잭션 및 DML 제어**  | **권장(Apex):** 세이브포인트, 롤백, 대량 처리를 완벽하게 제어합니다.                                       | **사용 가능:** 각 행이 독립적으로 처리되므로 실행 범위는 레코드당입니다.                                                         | **제한:** 작업은 세션에서 개별 분리된 단계로 실행됩니다.                                                         | **권장:** Flow/Apex 노드를 사용하여 모든 DML에 대한 결정적 앵커 역할을 합니다. 에이전트 간의 배포된 트랜잭션 제어 지원은 제한됩니다. |
| **모호성 처리**         | **사용 불가:** 미리 정의된 경로가 필요합니다. 예기치 않은 입력은 실패 또는 정적 오류로 이어집니다.                        | **제한:** 출력 품질은 프롬프트의 기반에 따라 달라집니다. 워크플로는 대화식으로 설명을 요청할 수 없습니다.                             | **권장:** 질문을 하거나 대체 기술을 선택하여 "알 수 없는" 상태를 처리합니다.                                           | **사용 가능:** "폴백 노드"를 사용하여 추론 실패 또는 프로세스 시간 초과를 관리합니다.                                                                 |
| **가시성 및 거버넌스**    | **권장:** 플로 트리거 탐색기는 모든 레코드 트리거형 논리의 시각적 맵을 제공합니다.                               | **사용 가능:** 그리드 기반 UI는 행 수준 결과를 명확하게 파악하고 출력 감사 기능을 지원합니다.                           | **사용 가능:** 모니터링 로그는 에이전트가 결정을 내린 방식에 대한 투명성을 제공합니다.                                                 | **전문가 필요:** 그래프 이동 및 LLM 추론 로그를 모두 모니터링해야 합니다.                                                           |
| **성능 및 규모**        | **권장** 대용량 동기식 레코드 처리에 최적화됨.                                                  | **권장** 대용량 데이터에서 대량 AI 과업을 효율적으로 처리합니다.                                                                | **지연에 민감함** 추론 시간에 따라 달라지며, 고밀도 대량 업데이트에는 적합하지 않습니다.                                           | **중간** 복잡한 장기 작업에 적합하지만 오버헤드가 더 높습니다.                                                                         |

## 사용 사례

다음 표는 다양한 사용 사례에 대한 일반적인 모범 권장 사항을 제공합니다.

| 사용 사례                                                    | 설명                                                                                                                                                                                                                                | 베스트 맞춤                                                                                                                                                                                                                           | 근거                                                                                                                                                                                                                                                                                                                                                                                           |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **레코드 처리**                                       | 설계 시 모든 지점 및 결과를 완전히 정의할 수 있는 구조화된 Salesforce 개체의 DML 이벤트로 트리거된 자동화입니다.                                                                                                  | 레코드 트리거형 플로를 사용합니다. 이는 낮은 밀도 일반 자동화입니다.                                                                                                                                                           | 오케스트레이션 밀도가 낮습니다. 단일 모달리티(정형 CRM 필드)와 예측 가능하고 감사 가능한 실행 경로를 가진 단일 목표입니다.                                                                                                                                                                                                                                                        |
| **복잡한 논리로 트랜잭션 제어**                | 세이브포인트, 롤백, 부분 커밋 또는 대량의 레코드에 대한 안전한 데이터 조작이 필요한 자동화입니다.                                                                                                                    | 일반적이고 밀도가 낮은 결정적 자동화에는 Apex를 사용합니다.                                                                                                                                                                    | 오케스트레이션 밀도가 낮습니다. Apex는 트랜잭션 무결성, 비용이 많이 드는 계산의 중복 제거, 플랫폼 수준의 캐싱을 완벽하게 제어할 수 있습니다. 이러한 기능은 플로에서는 사용할 수 없습니다.                                                                                                                                                                                                         |
| **정형 프로세스 내에서 약간 복잡한 논리**    | 전체 프로세스가 규칙 기반이지만 개별 단계에서는 선언적 기능 외에 계산 또는 데이터 조작이 필요합니다.                                                                                            | 밀도가 낮은 결정적 논리에는 호출 가능한 Apex와 함께 플로를 사용합니다.                                                                                                                                                                  | 오케스트레이션 밀도가 낮습니다. 플로는 오케스트레이션 계층 역할을 하며, 호출 가능한 Apex는 복잡성이 높은 작업을 재사용 가능한 대량 안전한 구성 요소로 캡슐화합니다.                                                                                                                                                                                                                                          |
| **예약 및 시간 기반 처리**                       | 레코드 이벤트와 관련하여 동적으로 계산된 향후 날짜에 실행되어야 하는 자동화입니다.                                                                                                                                           | 낮은 밀도의 결정적 처리에는 기존 자동화(레코드 트리거 플로)를 사용합니다.                                                                                                                                      | 오케스트레이션 밀도가 낮습니다. [플로의 예약 경로](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5)는 레코드 데이터가 변경될 경우 자동으로 예약, 취소 및 재예약을 제공합니다. 이러한 기능은 Apex 트리거에서는 기본적으로 제공되지 않습니다.                                                                                                            |
| **대량 기록 추론**                                   | 대규모 기존 레코드 집합에서 단일 AI 추론 단계를 일관되게 적용하여 분류, 요약 또는 점수를 생성합니다.                                                                                                      | Agentforce Grid를 사용하여 배치 추론을 수행하고 대규모로 반복적인 에이전트 역량을 사용합니다.                                                                                                                                       | 중간 오케스트레이션 밀도. 단일 모달리티로 대규모 배치 추론: 에이전트가 구조화된 레코드 필드를 읽고 각 레코드에 일관된 출력을 기록합니다. 반복적 추론 패턴이 하나 있는 낮은 목표 복잡성.                                                                                                                                                                   |
| **비정형 입력 해상도**                           | 진입점이 자연어 요청, 이메일 또는 대화인 자동화로, 이를 해석하고 분류하며 해결해야 합니다.                                                                               | 중간 밀도의 의도 중심 비정형 입력 처리에는 Agentforce를 사용합니다.                                                                                                                                                   | 중간 오케스트레이션 밀도. 혼합 모달리티: 에이전트가 비정형 대화 입력을 받아 텍스트 응답 또는 구조화된 레코드 업데이트를 생성합니다. 목표는 한정된 결과 집합 내에서 사용자 의도를 해결하는 것입니다.                                                                                                                                                            |
| **확률적 프로세스 내에서 약간 복잡한 논리** | 전체 프로세스가 규칙 기반이지만 개별 단계에는 요약 또는 RAG 검색과 같은 AI 기능이 필요합니다.                                                                                                            | AI 기능이 필요한 낮은 밀도의 결정적 프로세스에는 호출 가능한 Apex와 프롬프트 템플릿을 함께 사용한 Flow를 사용합니다.                                                                                                               | 중간 오케스트레이션 밀도. 플로는 오케스트레이션 계층 역할을 하며, [Prompt 템플릿](https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api), [Agentforce 서비스 에이전트, Agentforce 직원 에이전트](https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5)은 호출 가능 작업으로 노출됩니다. |
| **가이드된 프로세스 오케스트레이션**                            | 하나의 작업이 완료되면 추가 작업이 트리거되는 다단계 워크플로 전반에 걸친 자동화                                                                                                                                  | 안내 프로세스 오케스트레이션이 필요한 고밀도 비정의 실행 경로에는 [작업이 포함된 에이전트 스크립트](https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining)를 사용합니다. | 오케스트레이션 밀도가 높은, 입력과 출력 전반의 혼합 모달리티입니다. 설계 시 완전히 예상할 수 없는 경쟁 결과 및 극단 사례 에이전트 스크립트는 안내된 결정성을 제공합니다.                                                                                                                                                                                                  |
| **교차 시스템 프로세스 오케스트레이션**                      | 단일 시스템이 전체 플로를 소유하지 않는 여러 백엔드 시스템에서 다단계 비즈니스 프로세스를 조율하는 자동화입니다.                                                                                                      | 중간 집적도에서 고집적도의 시스템 간 프로세스 오케스트레이션에 에이전트 브로커와 함께 MuleSoft 프로세스 API를 사용합니다.                                                                                                                          | 오케스트레이션 밀도 높음 - 프로세스 API는 복잡한 다단계 비즈니스 논리를 캡슐화하므로 에이전트가 주문 처리 또는 재고 점검과 같은 작업 뒤에 있는 오케스트레이션을 이해할 필요가 없습니다. [에이전트 브로커](https://www.mulesoft.com/ai/agent-broker)는 단일 자연어 목표에서 필요한 에이전트와 도구를 동적으로 순차적으로 호출합니다.                               |
| **백엔드 시스템 추상화**                              | 에이전트가 기존 시스템, 데이터베이스 또는 네이티브 Agentforce 연결이 없는 타사 SaaS 플랫폼과 인터페이스해야 하는 오케스트레이션입니다.                                                                                            | MCP 커넥터와 함께 MuleSoft를 사용하여 레거시 시스템을 래핑하고 모델 컨텍스트를 제공합니다.                                                                                                                                              | 중간 오케스트레이션 밀도. 시스템 API는 레코드 시스템에 대한 안전하고 추상화된 인터페이스를 제공하므로 에이전트 워크플로가 백엔드 복잡성에서 분리됩니다. MCP 커넥터는 MuleSoft 응용 프로그램을 MCP 호환 서버로 변환하여 즉시 검색 및 호출할 수 있습니다.                                                                                                  |
| **대용량 문서 처리 및 예외 처리**  | 대규모로 인바운드 구조화된 문서와 세미 구조화된 문서를 기존 레코드와 조정하는 자동화 - 적절한 수동 중재를 통해 편차, 부분 일치 및 예외를 처리합니다.          | 중간 밀도의 의도 기반 대용량 문서 처리를 위해 Agentforce 오퍼레이션을 사용합니다.                                                                                                                                       | 세미정형 입력 모달을 사용하는 중간 오케스트레이션 밀도. 일치 규칙, 예외 경로, 문서당 승인 임계값에 따라 달라지는 목표 복잡성 균일한 단일 턴 추론이 아닌, 레코드별로 추론이 필요합니다.                                                                                                                                                                |
| **공급업체 간 멀티에이전트 오케스트레이션**                | 자동화를 수행하려면 다양한 플랫폼 또는 공급업체에 구축된 전문 에이전트 간의 공동 작업이 필요합니다.                                                                                                                                      | MuleSoft와 A2A 커넥터, 에이전트 패브릭을 사용하여 다양한 시스템에서 다중 에이전트 오케스트레이션을 수행하세요.                                                                                                                           | 중간에서 높은 오케스트레이션 밀도. A2A 커넥터는 각 에이전트가 구축되거나 호스팅되는 위치와 상관없이 엔터프라이즈급 거버넌스 및 신뢰성을 갖춘 P2P 다중 에이전트 워크플로를 지원합니다.                                                                                                                                                                                             |
| **비정형 문서를 워크플로로 변환**            | 구조화되지 않은 소스(SOP, 공급업체 규칙 문서 또는 프로세스 다이어그램)에 정의된 운영 프로세스를 수동으로 코딩하지 않고 실행 가능한 에이전트 워크플로로 변환해야 하는 자동화입니다.                                     | 고밀도 및 새롭게 등장하는 비정형 문서를 워크플로로 변환하기 위해 Agentforce Operations를 사용하세요.                                                                                                                                | 입력에 대한 높은 모달 혼합이 있는 고밀도. PDF, Word 문서, 이미지 기반 다이어그램을 수집합니다. 수집된 프로세스의 범위 및 분기에 따라 결정되는 목표 복잡성입니다. 설계 시 실행 경로를 지정할 수 없습니다.                                                                                                                                                           |
| **다자간 오케스트레이션**                               | 외부 당사자의 조정된 온보딩을 포괄하는 자동화 - 필수 데이터 수집, 규정 준수 확인, 승인 관리, 여러 동시 온보딩 트랙 전반의 레코드 시스템 업데이트                         | 중간에서 높은 밀도의, 의도 기반에서 새롭게 등장하는 다자간 오케스트레이션을 위해 Agentforce Operations를 사용하세요.                                                                                                                         | 여러 상호 종속 확인 및 승인 단계를 순차적으로 해결해야만 온보딩이 완료됩니다. 모달 조합에는 구조화된 레코드, 구조화되지 않은 문서, 외부 당사자 커뮤니케이션이 포함됩니다.                                                                                                                                                                                 |
| **예측적 자산 개입**                           | 예측 엔진이 실시간 텔레메트리를 수집하여 임박한 장애 조건을 식별하고, 조정된 다단계 백오피스 응답을 트리거하는 자동화입니다.                                                                      | 고밀도 예측적 자산 개입을 위해 Agentforce Operations와 Agentforce for Manufacturing을 사용하세요.                                                                                                                         | Data Cloud는 다양한 형태의 IoT 텔레메트리와 이상 감지를 처리합니다. 그런 다음 Agentforce Operations는 현장 서비스 레코드, 재고 데이터, 고객 커뮤니케이션을 관리하는 중간 모달 백오피스 워크플로를 오케스트레이션하여 프로세스를 종단 간으로 해결합니다.                                                                                                                                |
| **대규모 공급업체 통신 관리**           | 주문 확인, 배달 날짜 변경, 예외 알림 등 대규모 공급업체 기반 전반에서 진행 중인 구조화된 및 반구형 커뮤니케이션을 관리하는 자동화                                            | 중간 밀도의 공급업체 커뮤니케이션 관리를 위해 Batch Inferences용 Agentforce Operations를 사용하세요.                                                                                                                              | 공급업체 간 통신이 일치하는 경우 배치 처리에 Agentforce 그리드를 사용합니다. 응답에 공급업체 관계별 문맥적 추론이 필요한 경우, Agentforce Operations를 사용하여 중간 밀도로 전환합니다.                                                                                                                                                                         |
| **리드 관리(고속 지능형 라우팅)**       | 실시간 마케팅 응답을 수집하고, AI 점수 매기기 및 Data Cloud 보강을 사용하여 자격을 부여하며, 적절한 세일즈 팀에 고품질 리드를 지능적으로 할당하고 라우팅하기 위해 플로우를 사용하는 자동화입니다. | 일반 자동화(플로우) + Data Cloud 및 AI를 사용하여 중간 밀도 고속 지능형 리드 라우팅을 수행합니다.                                                                                                                     | AI 리드 점수, 작업 수준, 활동 내역을 기반으로 높은 속도(리드까지 속도 < 1분) 및 복잡한 데이터 중심 라우팅이 필요합니다. 빠르고 결정적인 할당 논리에 플로우를 사용하며, 리드 자격 및 보강을 위해 확률적 AI 및 Data Cloud로 보완됩니다.                                                                                                                   |
| **리드 육성**                                          | 판매 대화를 준비할 때까지 점수가 낮은 리드를 육성합니다.                                                                                                                                                                    | 리드 육성 에이전트를 사용하여 중간~고 밀도 자동화를 위해 품질이 낮은 리드를 대상으로 지정하고 개선합니다.                                                                                                                      | 리드 데이터 및 고객 성공 스토리를 바탕으로 한 맞춤형 멀티 터치 이메일을 보냅니다. 이메일 응답을 처리하고 핸드오프에 플로우를 사용합니다.                                                                                                                                                                                                                                                  |
| **인바운드 리드 검증**                              | 점수가 더 높은 인바운드 리드를 자동으로 자격을 부여하고 육성합니다.                                                                                                                                                                            | 리드 육성 에이전트를 사용하여 리드의 자격을 부여하고 참여합니다.                                                                                                                                                                              | 멀티 터치 이메일 아웃바운드, 회의 예약, 제품 Q&A, 이의 처리를 실행합니다. "판매자로 보내기" 모드로 작동하여 할당된 리드 담당자를 통해 이메일을 보낼 수 있습니다.                                                                                                                                                                                                              |

## 사례 매핑 사용

![여러 오케스트레이션 밀도 수준에 따른 다양한 자동화 시나리오를 보여주는 사용 사례 매핑 다이어그램](https://architect.salesforce.com/ns-assets/determining-agentic-automation-use-case-mapping.png)

## 기능이 아닌 고려 사항

**대기 시간**

동기식 레코드 트리거 플로우는 플랫폼 트랜잭션 내에서 실행되며, 밀리초 내에 완료됩니다. Agentforce 추론 시간은 Atlas Reasoning Engine에 따라 다르며, 추론 깊이와 모달 복잡성에 따라 확장됩니다. Agentforce 대기 시간이 기본 제약인 대용량 동기식 레코드 처리에 적합하지 않습니다.

**비용**

에이전트 워크플로의 추론 비용은 결과의 비즈니스 가치와 비교하여 정당화되어야 합니다. 결정적 경로가 있는 대용량 및 낮은 오케스트레이션 밀도 작업의 경우 기존 자동화 또는 Agentforce 그리드가 엔드-투-엔드 에이전트 워크플로보다 저렴할 수 있습니다. 명시적인 최대 재시도 제한 및 브레이커를 사용하여 디자인이 올바른 재시도 패턴을 수용하는지 확인합니다. 이 가드레일은 대량 처리와 관련된 비용 초과 위험을 제한합니다.

**거버너 제한**

비동기 실행을 위해 일일 플랫폼 제한 대비 대용량 에이전트 워크플로를 평가합니다. Agentforce 그리드 배치 작업은 표준 플랫폼 트랜잭션 제한을 따릅니다. Salesforce 개체를 포함하는 자동화의 경우 Salesforce는 멀티테넌트 환경에서 공유 자원 관리와 런어웨이 자동화가 공유 자원을 독점하지 않도록 [거버너 제한](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm?_ga=2.244979463.387753096.1774889755-1655953164.1772207150)을 적용하므로 일일 DML 작업의 총 수를 고려하십시오.

**감사 및 규정 준수**

기존 자동화는 플로우 트리거 탐색기 및 Apex 로그를 통해 완전히 감사 가능한 실행 내역을 생성합니다. Agentforce 기반 엔드 투 엔드 또는 하이브리드 패턴은 에이전트 의사 결정 과정에 대한 투명성을 제공하는 추론 로그를 생성하지만, 이를 해석하기 위해서는 전문 지식이 필요합니다. 에이전트 스크립트를 통한 안내 결정성은 완전한 실행 감사 가능성이 준수 요구 사항인 규제 산업에 권장되는 패턴입니다.

**에스컬레이션**

밀도가 높은 에이전트 워크플로에서 금융 거래, 규제 제출 또는 공급업체 서약과 같은 되돌릴 수 없는 결과가 있는 작업에 대해 명시적 인 승인 또는 에스컬레이션 게이트를 통합해야 합니다. 에이전트 스크립트 조건부 제어는 에이전트가 아닌 워크플로 내에서 이러한 게이트를 결정적으로 적용하는 메커니즘을 제공합니다.

## 관련 모범 사례

**오케스트레이션 설계에서 단순함을 우선시하십시오** 목표를 달성할 수 있는 최소한의 오케스트레이션 수준에서 시작하고, 실제 부하에서 검증한 후 반복하십시오. 체인의 추가되는 각 에이전트, 핸드오프 또는 종속성은 일관성 없는 동작을 초래할 수 있는 새로운 위험 요소를 도입합니다.

지정 가능한 실행 경로에서 추론이 필요한 노드에서 에이전트 포함을 시작합니다. Agentforce 에이전트를 구축하기 위한 모범 사례를 따르십시오. 많은 하위 에이전트(이전의 "topics")를 사용하지 말고, 명령을 불필요하게 늘리지 마십시오. 자동화 사용 사례에 배포된 에이전트는 유일한 인터페이스가 아니므로 간결할 수 있습니다. 연결에 적합한 기본 항목을 선택합니다. 오케스트레이션(위임) 패턴은 실행 순서를 더욱 엄격하게 제어하고 전문가에게 하위 과업을 위임할 수 있습니다. 코레오그래프(핸드오프) 패턴을 피하십시오. 핸드오프 설계를 구현해야 하는 경우 로컬 목표가 아닌 전역적으로 최적화할 수 있도록 수신 에이전트에 목표, 컨텍스트, 상태를 제공합니다.

**작업 또는 도구의 난립을 피하십시오**. 작업은 에이전트의 추론이 실현되는 곳이며, 그 설계에 따라 신뢰할 수 있는 결과를 내는지, 실패를 초래하는지가 결정됩니다. 모든 작업은 AI 에이전트가 다음 대화 순서를 계획하는 데 사용할 수 있는 구조화되고 관찰 가능한 응답을 반환해야 합니다.

동일한 과업을 수행하기 위해 두 개 이상의 작업(및 다른 출력 구조)을 사용하면 에이전트가 작업에 적합한 도구를 판단하거나 선택할 수 있는 능력이 저하됩니다. 에이전트가 뉘앙스를 놓칠 수 있습니다. 작업 정의가 중복되면 잘못 분류될 위험이 있습니다. 작업 라이브러리가 감사되고 버전이 지정되어 하위 에이전트(이전 주제) 범위를 준수하는지 확인합니다.

**관찰 가능한 목표를 정의합니다.** 목표를 절차뿐만 아니라 관찰 가능한 결과로 정의합니다. 모호한 목표는 에이전트 드리프트를 초대합니다. 지정 가능한 실행 경로를 사용하여 증가합니다. 하이브리드 추론과 함께 에이전트 그래프를 사용하여 명시적 상태의 그래프 노드로 목표를 모델링합니다. 런타임은 워크플로 내에서 에이전트의 현재 위치를 추적하며, 부차적 입력 후 이를 복원합니다. 또한, 컨텍스트 창에서 추가 정보를 받을 때에도 목표가 손실되지 않습니다.

**테스트 및 평가**. 강력한 테스트 및 평가 프레임워크를 구현하여 확률적 노드의 추론과 에이전트 자동화의 출력을 검증합니다. 예상 결과 경로에 대한 실행 경로를 확인하여 모델이 올바른 결과에 도달하는지 확인합니다. 실행 단계에서 결과를 검증함으로써, 에이전트가 성공을 잘못 보고하거나 무한 루프 혹은 복구 불가능한 루프에 진입하는 것을 방지합니다. [세션 추적](https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_about.htm&type=5)을 사용하여 전환 상호 작용, 추론 엔진 실행, 작업, 프롬프트 및 게이트웨이 입력/출력, 오류 메시지, 최종 응답을 검사합니다.

## 자원

<table>
  <thead>
    <tr>
      <th scope="col">Agentforce</th>
      <th scope="col">기존 자동화</th>
      <th scope="col">통합</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5">Agentforce</a></li>
          <li><a href="https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html">에이전트 스크립트</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5">Agentforce 그리드</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5">Agentforce 운영</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5">Agentforce 서비스 에이전트 및 직원 에이전트</a></li>
          <li><a href="https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining">작업이 있는 에이전트 스크립트</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5">Salesforce 플로우</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5">플로우 예약 경로</a></li>
          <li><a href="https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api">프롬프트 템플릿</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="/docs/architect/ko-kr/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html">MuleSoft</a></li>
          <li><a href="https://www.mulesoft.com/ai/agent-broker">에이전트 브로커</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

**작성자 정보**

Arvind Palaniswamy는 Chief Architect 사무실의 Well-Architected 팀에서 소프트웨어 엔지니어링 아키텍트입니다. 그는 최초 원리를 사용하여 복잡한 시스템을 가장 단순한 형태로 구조화하는 것을 좋아합니다. 수십 년간의 경험과 MS/MBA(Kellogg) 교육을 통해 엔지니어링, 운영, 비즈니스를 이해합니다.

<!-- document id=a2476ea5c24c98c4e27a6e15f5a0c68e69d7ac5df95bc186c477b0fed9f72abb url=/architect/current/ko-kr/decision-guides/guides/event-driven.md -->

# 이벤트 중심 아키텍처에 적합한 도구 및 패턴 사용

이벤트 기반 아키텍처는 시스템 또는 응용 프로그램 상태 변경을 전달하는 이벤트의 효율적인 생산 및 소비를 지원합니다. 이벤트 기반 아키텍처는 시스템 간의 유연한 연결을 가능하게 하고, 여러 시스템에 걸쳐 프로세스 및 거의 실시간 업데이트를 지원합니다. 이벤트 기반 아키텍처의 장점은 쉽게 확인할 수 있지만 구현 세부 사항은 항상 명확하지 않습니다. 이벤트 중심 아키텍처 패턴에서 고려해야 할 기능은 무엇입니까? 이러한 패턴이 해결하는 특정 문제는 무엇입니까? 솔루션에 적용되는 특별 고려 사항은 무엇입니까? 솔루션을 해결하기 위한 최적의 패턴은 무엇입니까?

## 가이드 개요

이 가이드는 Salesforce 기술을 사용하여 작업할 때 최적의 이벤트 중심 아키텍처를 구축하는 데 사용되는 패턴을 제공합니다. 또한 Salesforce에서 사용할 수 있는 이벤트 도구를 설명하고, 여러 사용 사례에 대한 도구 권장 사항을 제공합니다. Salesforce와 관련된 데이터 수준 통합에 대한 자세한 내용은 [데이터 통합 결정 가이드](/docs/architect/ko-kr/decision-guides/guide/data-integration)를 참조하십시오.

## 서비스

- **요청에 대한 동기식 응답이 필요하지 않은 프로세스에 이벤트 기반 아키텍처를 사용합니다.** 이 가이드에 설명된 패턴은 데이터 일관성, 확장성, 재사용을 위해 고안되어, 조직의 애플리케이션 환경이 발전함에 따라 기술 부채를 최소화할 수 있습니다. (자세한 내용은 [Well-Architected - Reliability](/docs/architect/ko-kr/well-architected/guide/reliability.html)를 참조하십시오.)

- **MuleSoft 또는 다른 Enterprise Service Bus(ESB) 솔루션이 기존 환경의 일부인 경우 가능한 경우 이를 사용하십시오.** 해당 솔루션은 이벤트 중심 아키텍처 패턴을 지원하도록 고안되었으며, 엔터프라이즈 전체에서 통합을 재사용할 수 있는 강력한 기능을 갖추고 있습니다.

- **스트리밍 API를 비롯한 다른 API를 사용하여 자체 이벤트 처리기를 구축하는 대신 향후 게시/구독 패턴에 Pub/Sub API를 사용하십시오.** 이제 Pub/Sub API가 정식 출시되었으므로 새 게시/구독 패턴에 사용하십시오. 가능한 경우 스트리밍 API 또는 사용자 정의 Apex 서비스와 같은 다른 플랫폼 API를 사용하여 기존 이벤트 통신을 Pub/Sub API로 마이그레이션할 계획입니다.

- **플랫폼 이벤트 및 변경 데이터 수집(CDC)은 다른 시스템에서 사용해야 하는 레코드 및 필드 변경 사항을 게시하는 데 가장 적합한 메커니즘입니다.** 새 구현에 PushTopic 및 일반 이벤트를 사용하지 않는 것이 좋습니다. Salesforce는 현재 기능 내에서 PushTopic 및 일반 이벤트를 계속 지원하지만, 이 기술에 추가 투자할 계획은 없습니다.

## 적용 범위 내 제품

<table style="border:none;width:100%">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Platform</a>은 직원, 자율 AI 에이전트, 회사 데이터 및 애플리케이션을 신뢰할 수 있는 단일 시스템으로 통합하여 생산성과 고객 경험을 향상시키는 종합적인 AI 기반 플랫폼입니다. 이를 통해 Customer 360 앱, Data Cloud, Slack을 연결하여 엔드 투 엔드 자동화를 실현하고, '에이전틱 엔터프라이즈'를 구축할 수 있습니다.</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: MuleSoft logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/mulesoft-new.png" alt="MuleSoft"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/mulesoft/">MuleSoft</a>은 조직이 온프레미스 및 클라우드 환경 전반에서 애플리케이션, 데이터, 장치를 연결할 수 있는 Salesforce의 선도적인 통합 플랫폼입니다. MuleSoft는 시스템 전반에서 데이터를 잠금 해제하고, 확장 가능한 통합 및 자동화 프레임워크를 개발하고, 차별화되고 연결된 환경을 빠르게 만들 수 있는 플랫폼을 제공하는 플랫폼입니다.</td>
    </tr>
  </tbody>
</table>

## 결정 지점

이벤트 중심 아키텍처(EDA)는 거의 실시간 알림이 필요하며, 대용량 또는 복잡한 메시지에 대한 처리 부하를 배포하고, 대기열을 통해 연결 복원을 필요로 하는 IoT 및 모바일 장치와 같은 시스템을 통합하는 시나리오에 권장됩니다. 그러나 비동기 실행을 위해 설계되었으므로 즉각적이고 동기식 인적 응답이 필요한 프로세스에는 EDA를 구현해서는 안 됩니다. 또한 소스 데이터가 너무 드물게 변경되어 배치 처리와 같은 더 간단한 패턴으로도 충분한 경우에는 적합하지 않습니다.

### 이벤트 중심 아키텍처를 사용하는 경우

다음은 이벤트 중심 아키텍처에 적합한 몇 가지 일반적인 시나리오입니다.

<table style="width:100%">
<thead>
<tr><th scope="col">결정 지점</th><th scope="col">지침</th></tr>
</thead>
<tbody>
<tr><td><strong>거의 실시간 알림</strong></td><td>게시/구독, 폴아웃, 스트리밍과 같은 이벤트 기반 아키텍처 패턴은 여러 응용 프로그램이 상태 변경이나 레코드 업데이트를 거의 실시간으로 통지받아야 하는 경우에 잘 작동하는 경향이 있습니다.</td></tr>
<tr><td><strong>동시 처리</strong></td><td>게시/구독과 같은 패턴은 대용량 데이터 또는 매우 복잡한 메시지가 여러 시스템 간에 처리 부하를 배포해야 하는 시나리오에서 잘 작동하는 경향이 있습니다.</td></tr>
<tr><td><strong>대량 읽기</strong></td><td>전달된 메시지 및 대기열 패턴은 메시지 발생량이 급증하여 생성되는 메시지의 양이 구독자가 즉시 처리할 수 있는 능력을 초과할 경우에 일반적으로 사용됩니다.</td></tr>
<tr><td><strong>고용량 쓰기</strong></td><td>스트리밍 및 대기열 패턴은 조직이 메시지 생성량이 급증하는 여러 시나리오에서 잘 작동합니다.</td></tr>
<tr><td><strong>다른 시스템에 동일한 데이터 보내기</strong></td><td>게시/구독은 여러 시스템에 동일한 데이터를 보내야 하는 조직에서 꽤 일반적인 솔루션이지만 여기에서 다루는 대부분의 패턴으로 해결할 수 있습니다. 가장 적합한 항목을 찾으려면 자세히 검토하십시오.</td></tr>
<tr><td><strong>새 시스템 또는 장치의 자주 도입</strong></td><td>게시/구독, 스트리밍, 대기열 패턴은 전체 환경이 변화하고 새 시스템 및 장치가 정기적으로 추가되는 시나리오에서 잘 작동합니다. 이 시나리오에서는 새 시스템이나 장치가 단순히 이벤트 버스의 구독자가 되거나 대기열에 연결되기만 하면, 별도의 맞춤형 점대점 통합 없이 메시지 수신을 시작할 수 있습니다.</td></tr>
<tr><td><strong>IoT 장치</strong></td><td>IoT 장치는 일반적으로 자주 업데이트를 제공하고, 일부 시나리오에서는 메시지 급증이 발생할 수 있으므로, 스트리밍 및 대기열 패턴은 IT 환경에 통합할 때 잘 작동합니다.</td></tr>
<tr><td><strong>오프라인 모바일 장치 및 시스템</strong></td><td>품질이 낮거나 인터넷 액세스가 없거나 메시지가 전달될 때 오프라인 상태일 수 있는 시스템에서 작업해야 하는 모바일 장치는 대기열에 연결하고 다시 온라인 상태가 되면 관련 메시지를 검색할 수 있는 대기열 패턴을 활용할 수 있습니다.</td></tr>
</tbody>
</table>

대부분의 대규모 조직에는 다양한 기능을 갖춘 여러 시스템이 혼재하는 복잡한 IT 환경이 있습니다. 조직에 이벤트 기반 통합을 지원하지 않는 레거시 시스템이 있을 가능성이 있습니다. 또한, 시스템에서 지원하더라도 이벤트 기반 통합이 적합하지 않은 사용 사례가 있을 수 있습니다(예: 타사에서의 SFTP 파일 전송). 한 걸음 물러서서 조직의 전체 IT 환경을 살펴보면, 다른 아키텍처 솔루션과 마찬가지로 다양한 시나리오를 지원하기 위해 여러 패턴을 혼합해서 사용하게 될 것입니다. 이벤트 기반 방식을 통합의 기본 접근법으로 삼기로 결정했다면, 이를 도구 상자에 추가하는 또 하나의 도구로 생각하십시오. 올바른 시나리오에서 사용할 수 있고 사용해야 하지만 모든 시스템에 적용되는 접근 방식은 아닙니다. 포괄적인 통합 전략을 개발하면 이 가이드에 설명된 패턴이 적절하거나 적절하지 않을 때를 판단하는 데 도움이 됩니다.

### 이벤트 중심 아키텍처를 사용하지 않는 경우

많은 시나리오에서 이벤트 기반 아키텍처가 요구되며, 일부 시나리오에서는 가장 적합하지 않은 경우에도 이벤트 기반 아키텍처가 작동할 수 있습니다. 그러나 일부 시나리오에서는 이벤트 중심 아키텍처를 사용해서는 안 됩니다. 다음은 다음 시나리오를 식별하는 데 도움이 되는 몇 가지 결정 지점 질문입니다.

<table style="width:100%">
<thead>
<tr><th scope="col">결정 지점</th><th scope="col">질문할 지침/질문</th></tr>
</thead>
<tbody>
<tr><td><strong>비즈니스 요구 사항</strong></td><td>[이벤트 중심 아키텍처 사용 시기](#이벤트-중심-아키텍처를-사용하는-경우) 섹션에 설명된 기능에 대한 실제 비즈니스 요구 사항이 있습니까?</td></tr>
<tr><td><strong>기술 요구 사항</strong></td><td>데이터 가상화, 배치 또는 요청/응답과 같은 다른 패턴에 맞는 통합을 설계하고 있습니까? 다시 말해, 맞지 않는 것을 억지로 끼워 맞추려고 하고 있지는 않습니까?</td></tr>
<tr><td><strong>사람들이 응답을 기다리는 과정</strong></td><td>대상 시스템에서 응답을 대기하는 사람이 포함된 통합은 비동기 실행을 위해 설계되었으므로 응답 시간을 보장할 수 없으므로 이벤트 중심 아키텍처에 적합하지 않습니다. 기술 솔루션을 구현하기 전에 이와 같은 프로세스가 조직에 최적인지 고려하십시오. 자세한 내용은 [Well-Architected - Operational Excellence](/docs/architect/ko-kr/well-architected/guide/operational-excellence.html)를 참조하십시오.</td></tr>
<tr><td><strong>변경이 드문 소스 데이터</strong></td><td>소스 시스템의 데이터가 자주 변경되지 않아 정기적인 업데이트가 충분할 경우 이벤트 기반 패턴 대신 [배치 패턴](https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm)를 사용하여 아키텍처를 간소화할 수 있습니다.</td></tr>
<tr><td><strong>구현 요구 사항</strong></td><td>귀하의 솔루션에 포함된 대부분의 시스템이 이벤트 기반 아키텍처를 지원합니까? 업그레이드, 사용자 정의 또는 미들웨어 등 지원되지 않는 시스템에서 이벤트 기반 아키텍처를 사용하려면 어떻게 해야 합니까? 이러한 요구 사항을 충족하기 위해 얼마나 많은 노력이 필요합니까?</td></tr>
<tr><td><strong>메시지 구조 안정성</strong></td><td>메시지 구조는 얼마나 자주 변경되어야 합니까? 이러한 변경 사항이 영향을 받는 시스템 및 수정 프로세스는 무엇입니까?</td></tr>
<tr><td><strong>조직 거버넌스</strong></td><td>모든 이해당사자가 메시지 구조, 트리거, 기타 아키텍처 및 프로세스 관련 결정에 대한 변경 사항을 파악하고 고려할 수 있도록 관리 구조가 마련되어 있습니까?</td></tr>
<tr><td><strong>필요한 역량</strong></td><td>귀하의 직원이 이벤트 기반 아키텍처에 대한 경험이 있고 이를 지원할 수 있습니까?</td></tr>
</tbody>
</table>

## 사용 사례

다양한 이벤트 중심 아키텍처 패턴이 있습니다. 일부는 이벤트 기반 이외의 특별한 요구 사항이 없는 사용 사례에 적용할 수 있는 일반 용도 패턴입니다. 예를 들어, [좋게 설계 - 신뢰성](/docs/architect/ko-kr/well-architected/guide/reliability.html)을 참조하십시오. 여기에서 논의된 특정 사용 사례, 예를 들어 대용량 데이터가 연관된 통합이나 메시지의 장기 보관이 요구되는 시나리오 등에는 다른 패턴도 적용할 수 있습니다.

### 패턴 한눈에 보기

아래 표는 이 문서에 정리된 패턴의 속성을 비교합니다. 지정된 사용 사례에 대한 잠재적인 패턴을 식별해야 하는 경우 빠른 참조로 사용합니다.

<table style="width:100%">
<thead>
<tr><th scope="col">패턴</th><th scope="col">거의 실시간</th><th scope="col">고유 메시지 복사본</th><th scope="col">전달 보장</th><th scope="col">메시지 크기 줄이기</th><th scope="col">데이터 변환</th></tr>
</thead>
<tbody>
<tr><td>게시/구독</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Fanout</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>전달된 메시지</td><td>✓</td><td></td><td>✓</td><td>✓</td><td>✓</td></tr>
<tr><td>스트리밍</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>대기열</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
</tbody>
</table>

### 이벤트 중심 아키텍처용 도구

Salesforce는 이벤트 기반 사용 사례를 해결하는 데 도움이 되는 여러 가지 도구를 제공합니다. 이 표에는 사용 가능한 도구의 개요가 포함되어 있습니다.

<table style="width:100%">
<thead>
<tr><th scope="col"></th><th scope="col">도구</th><th scope="col">설명</th><th scope="col">필요한 기술</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>API 계층을 사용하여 데이터 통합을 활성화하는 플랫폼입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub 커넥터</a></td><td>Pub/Sub API용 커넥터 - 플랫폼 이벤트 게시 및 구독, 실시간 이벤트 모니터링, 변경 데이터 수집 이벤트를 위한 단일 인터페이스를 제공합니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>JMS(Java Message Service) 사양을 구현하는 메시지 서비스의 대기열 및 주제에 메시지를 보내고 받을 수 있는 커넥터입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka 커넥터</a></td><td>Apache Kafka와 엔터프라이즈 애플리케이션 및 서비스 간에 데이터를 이동하는 커넥터입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">MuleSoft Anypoint Solace 커넥터</a></td><td>JCSMP Java SDK를 사용하는 네이티브 API 통합을 사용하는 Solace PubSub+ 이벤트 브로커용 커넥터</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>고객이 응용 프로그램 간에 고급 비동기식 메시지를 수행할 수 있는 멀티테넌트 클라우드 메시지 서비스입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT 커넥터</a></td><td>MQTT(Message Queuing Telemetry Transport) v3.x 프로토콜을 준수하는 MuleSoft 확장 기능입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP 커넥터</a></td><td>응용 프로그램이 AMQP 0.9.1 준수 브로커를 사용하여 메시지를 게시하고 소비할 수 있도록 하는 커넥터입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">MuleSoft Anypoint 이벤트 구동(Async) API</a></td><td>이벤트, 채널, 전송 계층으로 분리하여 이벤트 기반 API의 게시를 지원하는 산업 중립적인 언어입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>고객이 응용 프로그램 간에 고급 비동기식 메시지를 수행할 수 있는 멀티테넌트 클라우드 메시지 서비스입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">MuleSoft Anypoint Data Streams</a></td><td>스트리밍 데이터를 게시하고 구독하는 MuleSoft Anypoint 내에서 사용할 수 있는 프레임워크입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Heroku 플랫폼과 완전히 통합되어 Apache Kafka를 서비스로 제공하는 Heroku 애드온입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">변경 데이터 캡처</a></td><td>Salesforce 레코드의 변경 사항을 게시하는 변경 이벤트 로그입니다. 변경 사항에는 새 레코드 만들기, 기존 레코드 업데이트, 레코드 삭제, 레코드 삭제 취소가 포함됩니다.</td><td>로우코드에서 프로 코드까지</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">아웃바운드 메시지</a></td><td>Salesforce 내에서 필드 값이 업데이트될 때 외부 끝점에 XML 메시지를 보내는 작업입니다.</td><td>낮은 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">플랫폼 이벤트</a></td><td>사용자 정의 이벤트 데이터가 포함된 안전하고 확장 가능한 메시지입니다.</td><td>로우코드에서 프로코드까지</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>플랫폼 이벤트, 변경 데이터 수집 이벤트 및/또는 실시간 이벤트 모니터링 이벤트에 대한 구독을 지원하는 API입니다.</td><td>프로 코드</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">이벤트 릴레이</a></td><td>Salesforce에서 Amazon EventBridge로 전송할 플랫폼 이벤트 및 변경 데이터 수집 이벤트를 활성화합니다. 이벤트 릴레이는 AWS Eventbridge에만 연결됩니다.</td><td>낮은 코드</td></tr>
<tr><th scope="row"></th><td></td><td></td><td></td></tr>
</tbody>
</table>

### 게시/구독

핵심 응용 프로그램 내에서 중요한 레코드가 상태를 변경하는 경우(예: 주문 상태가 "처리 중"에서 "배송됨"으로 변경됨) 여러 다른 시스템에서 각 과업을 수행하기 위해 거의 실시간으로 알림을 요구할 수 있습니다. 이러한 변경 사항의 용량이 많고 메시지가 복잡한 경우 특정 비즈니스 요구 사항이 발생하므로 기존 지점 간 통합이 부담스럽고 유지 관리하기 어려울 수 있습니다. 모든 종속 응용 프로그램에 대해 취약한 사용자 정의 연결을 설정하면 기술 부채가 발생하고 조직의 신속한 확장 능력이 저하됩니다. 소스 시스템을 모든 소비 시스템에 직접 연결하지 않고 이러한 자주 발생하는 데이터 동기화를 관리하려면 강력한 통합 접근 방식이 필요합니다.

#### 게시/구독 패턴

아래 다이어그램은 이벤트 버스를 통해 데이터를 공유하는 여러 게시자 및 구독자가 있는 일반적인 게시/구독 패턴을 보여줍니다. 이 기본 패턴은 이 가이드의 나머지 부분에서 찾을 수 있는 더 구체적인 패턴의 기반이 됩니다. 이 패턴의 일부 주요 특성은 다음과 같습니다.

- 게시자와 구독자 간에 직접적인 연결이 없습니다. 게시자는 단순히 이벤트 버스에 메시지를 보내기만 하면, 이벤트 버스가 해당 메시지를 수신하려는 모든 시스템에 이를 브로드캐스트합니다.

- 동일한 시스템이 게시자이자 구독자일 수도 있습니다.

- 시스템에서 여러 유형의 이벤트를 게시하거나 구독할 수 있습니다.

- 이 가이드의 모든 패턴과 마찬가지로, 게시/구독 패턴은 원격 프로시저 호출(RPI) 또는 단순히 ["발사 후 잊기"](/docs/architect/ko-kr/fundamentals/guide/integration-patterns#원격-프로세스-호출---fire-and-forget)로 알려진 일반적인 통합 패턴 범주에 속합니다.

<!-- Image: Publish/subscribe pattern diagram (Level 2) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Publish - Subscribe L2.png" alt="이 레벨 2 다이어그램은 여러 게시자, 여러 구독자, 이벤트 버스의 채널을 통해 전달되는 여러 이벤트를 포함하는 게시/구독 패턴의 예를 보여줍니다. 이 패턴에서는 동일한 시스템이 모두 게시자와 구독자이고 시스템이 여러 이벤트를 구독할 수 있습니다.">

#### 게시/구독 패턴과 관련된 도구

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">이벤트 흐름 및 동작</th><th colspan="2" scope="colgroup">페이로드 고려 사항</th></tr>
<tr><th scope="col">사용 가능한 도구</th><th scope="col"></th><th scope="col">필요한 기술</th><th scope="col">게시 via</th><th scope="col">구독을 통해</th><th scope="col">재생 기간</th><th scope="col">페이로드 구조</th><th scope="col">페이로드 제한</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성됨</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성됨</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성됨</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성됨</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">MuleSoft Anypoint Solace 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성됨</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">MuleSoft Anypoint 이벤트 구동(Async) API</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Heroku의 Apache Kafka</a></td><td>프로 코드</td><td>API, Heroku Postgres의 레코드 변경 사항</td><td>N/A</td><td>1~6주</td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의됨</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의됨</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">변경 데이터 수집</a></td><td>로우코드~프로코드</td><td>레코드 변경 사항</td><td>Apex, API, Lightning 웹 구성 요소(LWC)</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">사전 정의됨</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">아웃바운드 메시지*</a></td><td>낮은 코드</td><td>플로 및 워크플로 규칙</td><td>N/A</td><td>24시간</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_wsdl.htm">사용자 정의됨</a></td><td>메시지당 100개의 알림</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">플랫폼 이벤트</a></td><td>로우코드에서 프로코드로</td><td>API(들), Apex, 플로</td><td>Apex, API, 플로, LWC</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">사용자 정의됨</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>프로 코드</td><td>Pub/Sub API 또는 API, Apex, 플로</td><td>Pub/Sub API</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">사용자 정의됨</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">이벤트 릴레이**</a></td><td>낮은 코드</td><td>플랫폼 이벤트, 변경 데이터 수집</td><td>API</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">사용자 정의됨</a></td><td>1MB</td></tr>
<tr><td colspan="8">*Salesforce는 현재 기능 내에서 아웃바운드 메시지를 계속 지원하지만 이 기술에 대한 추가 투자를 계획하지 않습니다. **이벤트 릴레이는 AWS Eventbridge에만 연결됩니다.</td></tr>
</tbody>
</table>

### Fanout

조직이 모바일 장치에 푸시 알림 또는 SMS 메시지와 같은 대규모 클라이언트 응용 프로그램에 즉각적인 업데이트를 보내야 하는 경우, 모든 단일 수신자에 대해 고유한 전송을 만드는 기존 프로세스가 빠르게 확장성 병목 현상이 됩니다. 이 경우 핵심 비즈니스 요구 사항은 계정 경고 또는 중요한 서비스 변경 알림과 같은 단일 정보의 빠르고 고성능한 배포를 여러 엔드포인트 응용 프로그램에 동시에 수행하는 것입니다. 이 요구 사항을 충족하기 위한 간소화된 접근 방식은 모든 메시지를 단일 대기열을 통해 라우팅하는 것을 포함하며, 이는 모든 소비 시스템에 대한 이벤트 정보의 중앙 지점 역할을 합니다. 이 접근 방식은 여러 개의 별도의 메시지 사본을 관리할 필요가 없어 성능을 향상합니다.

#### Fanout 패턴

Fanout 패턴을 사용하면 단일 메시지 대기열을 통해 하나 이상의 대상(즉, 클라이언트 또는 구독자 수신)에 메시지가 전달됩니다. 구독자는 고유한 사본이 아닌 대기열에서 동일한 메시지를 검색합니다. (참고: 이는 성능을 향상시키지만, 특정 구독자가 메시지를 수신했는지 여부를 확인하기가 더 어려워질 수 있습니다.)

<!-- Image: Fanout pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Fanout L3.png" alt="이 레벨 3 문서 및 구현 다이어그램은 fanout 패턴의 예시를 보여줍니다. 레코드가 사용자 상호 작용, 플로우 또는 배치 작업을 통해 수정될 때 이벤트가 게시되어 하나의 대기열에 기록됩니다. 구독자 시스템에는 메시지 대기열에서 동일한 이벤트를 수신하는 여러 서비스가 있습니다.">

#### Fanout 패턴 관련 도구

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">이벤트 흐름 및 동작</th><th colspan="2" scope="colgroup">페이로드 고려 사항</th></tr>
<tr><th scope="col">사용 가능한 도구</th><th scope="col"></th><th scope="col">필요한 기술</th><th scope="col">게시 via</th><th scope="col">구독을 통해</th><th scope="col">재생 기간</th><th scope="col">페이로드 구조</th><th scope="col">페이로드 제한</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">MuleSoft Anypoint Solace 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의됨</a></td><td>없음</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Heroku에서 Apache Kafka</a></td><td>프로 코드</td><td>API, Heroku Postgres의 레코드 변경 사항</td><td>N/A</td><td>1~6주</td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의됨</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의됨</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">변경 데이터 수집</a></td><td>로우코드에서 프로코드로</td><td>레코드 변경 사항</td><td>Apex, API, Lightning 웹 구성 요소(LWC)</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">사전 정의됨</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">플랫폼 이벤트</a></td><td>로우코드에서 프로코드로</td><td>API(들), Apex, 플로</td><td>Apex, API, Flow, LWC</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">사용자 정의됨</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>프로 코드</td><td>Pub/Sub API 또는 Apex, API, 플로</td><td>Pub/Sub API</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">사용자 정의됨</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">이벤트 릴레이*</a></td><td>낮은 코드</td><td>플랫폼 이벤트, 변경 데이터 수집</td><td>API</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">사용자 정의됨</a></td><td>1MB</td></tr>
<tr><td colspan="8">*이벤트 릴레이는 AWS Eventbridge로만 데이터를 전송합니다.</td></tr>
</tbody>
</table>

### 전달된 메시지

일부 이벤트 시나리오는 동기화 및 변환 프로세스의 용량을 압도할 위험이 있는 메시지 볼륨의 상당한 유입 또는 이벤트 데이터를 처리하고 변환하는 데 필요한 복잡한 다단계 논리로 특징화됩니다.

일부 예는 다음과 같습니다.

- **계절 볼륨 급증:** 선택 제품이 "계절에 있음"일 때 온라인 소매업체가 경험하는 볼륨이 급증할 수 있습니다. 많은 고객이 동시에 구매하는 경우 생성된 이벤트 수가 일시적으로 동기화 및 변환 프로세스의 용량을 초과할 수 있습니다. 자세한 내용은 [Well-Architected - Reliability](/docs/architect/ko-kr/well-architected/guide/reliability.html#scalability-and-capacity-planning)를 참조하십시오.

- **사례 또는 청구 관리:** 서비스 기반 회사는 중단 시 사례 또는 청구 수가 급증할 수 있습니다.

- **복잡한 데이터 변환:** 메시지를 변환하기 위해 복잡한 논리가 필요한 조직은 변환할 수 없는 속도로 생성되는 이벤트가 걱정되는 경우가 많습니다.

#### 전달된 메시지 패턴

이 패턴은 변환할 수 없는 속도로 메시지가 생성되는 문제를 해결합니다. 스트리밍 메시지 플랫폼을 통합하고 메시지 처리 논리를 전용 구성 요소에 세분화하여 대용량 메시지 및 필수 데이터 조작을 신뢰할 수 있도록 합니다.

전달된 메시지 패턴은 메시지 처리 논리를 여러 구성 요소로 세분화하여 작동합니다.

- 한 구성 요소가 메시지 라우팅을 처리하여 필수 변환 및 최종 대상을 결정합니다.

- 별도의 구성 요소 집합은 다양한 메시지 변환 계층(예: 필드 매핑, 개체 관계 등)을 처리합니다.

- 마지막 구성 요소는 최종 수정된 메시지를 작성합니다.

<!-- Image: Passed messages pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Passed Messages L3.png" alt="이 레벨 3 문서 및 구현 다이어그램은 게시자, 구독자 및 메시지를 포함하는 전달된 메시지 패턴에 대한 프로세스 흐름의 예를 보여줍니다. 메시지는 여러 부분으로 분할되어 개별적으로 변환되고 구독자에게 전송되기 전에 다시 조립됩니다.">

#### 전달된 메시지 패턴과 관련된 도구

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">이벤트 흐름 및 동작</th><th colspan="2" scope="colgroup">페이로드 고려 사항</th></tr>
<tr><th scope="col">사용 가능한 도구</th><th scope="col"></th><th scope="col">필요한 기술</th><th scope="col">게시 via</th><th scope="col">구독을 통해</th><th scope="col">재생 기간</th><th scope="col">페이로드 구조</th><th scope="col">페이로드 제한</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Heroku에서 Apache Kafka</a></td><td>프로 코드</td><td>API, Heroku Postgres의 레코드 변경 사항</td><td>N/A</td><td>1~6주</td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">변경 데이터 캡처</a></td><td>로우코드에서 프로 코드까지</td><td>레코드 변경 사항</td><td>Apex, API, Lightning 웹 구성 요소(LWC)</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">사전 정의됨</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">플랫폼 이벤트</a></td><td>로우코드에서 프로 코드까지</td><td>API(들), Apex, 플로</td><td>Apex, API, 플로우, LWC</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">사용자 정의</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>프로 코드</td><td>Pub/Sub API 또는 API, Apex 플로</td><td>Pub/Sub API</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">사용자 정의</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">이벤트 릴레이*</a></td><td>낮은 코드</td><td>플랫폼 이벤트, 변경 데이터 수집</td><td>API</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">사용자 정의</a></td><td>1MB</td></tr>
<tr><td colspan="8">*이벤트 릴레이는 AWS Eventbridge로만 데이터를 전송합니다.</td></tr>
</tbody>
</table>

### 스트리밍

일부 프로듀서는 이벤트의 연속 스트림을 생성합니다. 일반적인 예로는 미디어 스트리밍으로서 자연스럽게 개별 이벤트로 발생하는 사용자 상호 작용이 수반됩니다. 핵심 스트리밍 환경을 차단하지 않고 여러 시스템이 동일한 사용자 동작에 동시에 반응해야 합니다.

음악 스트리밍 플랫폼에 대한 이벤트를 고려하십시오. 다음이 포함될 수 있습니다.

- 시작/일시 중지됨/ 건너뛰기 이벤트 추적

- 타임스탬프가 포함된 청취 세션 이벤트

- 재생 목록 만들기/수정 이벤트

- 소셜 공유 이벤트

- 오프라인 청취용 다운로드

#### 스트리밍 패턴

스트리밍 패턴에서 구독자는 각 이벤트 스트림에 액세스하고 수신된 정확한 순서대로 이벤트를 처리합니다. 각 구독자에게 각 메시지 스트림의 고유 사본이 전송되므로 구독자별 콘텐츠를 전달하고 어떤 구독자가 어떤 스트림을 수신하는지 식별할 수 있습니다.

<!-- Image: Streaming pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Streaming - L3.png" alt="이 레벨 3 문서와 구현 다이어그램은 게시되는 이벤트 스트림의 예를 보여줍니다. 스트림을 수신하는 구독자는 이를 적절하게 처리합니다.">

#### 스트리밍 패턴과 관련된 도구

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">이벤트 흐름 및 동작</th><th colspan="2" scope="colgroup">페이로드 고려 사항</th></tr>
<tr><th scope="col">사용 가능한 도구</th><th scope="col"></th><th scope="col">필요한 기술</th><th scope="col">게시 via</th><th scope="col">구독을 통해</th><th scope="col">재생 기간</th><th scope="col">페이로드 구조</th><th scope="col">페이로드 제한</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">MuleSoft Anypoint Data Streams</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Heroku에서 Apache Kafka</a></td><td>프로 코드</td><td>API(들), Heroku Postgres의 레코드 변경 사항</td><td>N/A</td><td>1~6주</td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>프로 코드</td><td>Pub/Sub API 또는 API, Apex 플로</td><td>Pub/Sub API</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">사용자 정의</a></td><td>1MB</td></tr>
</tbody>
</table>

#### 스트리밍된 이벤트 주문 관리

스트림이 제대로 작동하려면 모든 이벤트와 관련 메시지가 올바른 순서에 있어야 합니다. 다른 시스템에서 스트림의 데이터를 소싱하는 경우 추가 주문 논리를 설계 프로세스의 일부로 통합해야 합니다.

### 대기열

대기열 사용 사례는 매우 흔합니다. 예를 들면 다음과 같습니다:

- **저품질 인터넷 연결:** 현장 서비스 조직이나 모바일 기기를 사용하는 팀이 품질이 낮거나 간헐적인 인터넷 환경에서 작업해야 하는 경우, 해당 기기의 애플리케이션이 대기열에 연결하여 연결이 복구되면 관련 메시지를 받아올 수 있으므로 대기열의 이점을 누릴 수 있습니다.

- **메시지 버퍼링:** 메시지 양이 가끔 구독자의 처리 용량을 초과하고, 대기 시간 증가가 추가 문제를 일으키지 않는 경우, 대기열은 초과 메시지를 저장하여 데이터 손실을 방지하는 버퍼 역할을 할 수 있습니다.

- **운송 관리:** 차량대를 모니터링해야 하는 물류 조직은 이 패턴을 사용하여 각 차량이 이동 중인 경로를 거의 실시간으로 보고 운전자가 가능한 한 효율적으로 운전하는지 확인할 수 있습니다.

- **IoT 장치:** 제조업체는 빠른 데이터 스트림을 생성하는 시스템을 자주 사용하며, 해당 스트림은 추가 시스템에 다운스트림 영향을 미칠 수 있습니다. 이 패턴은 여러 시스템에 걸친 재해적 오류가 발생하기 전에 사람이 개입해야 하는 이벤트의 시퀀스를 식별하는 데 사용할 수 있습니다.

#### 대기열 패턴

대기열 패턴에서 프로듀서는 대기열에 메시지를 보내고, 구독자가 메시지를 검색할 때까지 메시지를 보관합니다. 대부분의 메시지 대기열은 FIFO(First In, First Out, 선입선출) 순서를 따르며, 각각의 메시지는 검색된 후 삭제됩니다. 각 구독자에게는 고유한 대기열이 있으므로 추가 설정 단계가 필요하지만, 배달을 보장하고 어떤 구독자가 어떤 메시지를 수신했는지 식별할 수 있습니다.

<!-- Image: Queuing pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Queuing L3.png" alt="이 레코드가 수정될 때 이벤트가 게시되고 대기열에 기록되는 대기열 패턴의 예를 보여주는 레벨 3 문서 및 구현 다이어그램입니다. 가입자는 연결된 대기열에서 이벤트 사본을 수신하고 자신의 레코드에 적절한 업데이트를 수행합니다.">

#### 대기열 패턴과 관련된 도구

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">이벤트 흐름 및 동작</th><th colspan="2" scope="colgroup">페이로드 고려 사항</th></tr>
<tr><th scope="col">사용 가능한 도구</th><th scope="col"></th><th scope="col">필요한 기술</th><th scope="col">게시 via</th><th scope="col">구독을 통해</th><th scope="col">재생 기간</th><th scope="col">페이로드 구조</th><th scope="col">페이로드 제한</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/4.3/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP 커넥터</a></td><td>프로 코드</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">구성된 대로</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">사용자 정의</a></td><td>없음</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Heroku에서 Apache Kafka</a></td><td>프로 코드</td><td>API(들), Heroku Postgres의 레코드 변경 사항</td><td>N/A</td><td>1~6주</td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의됨</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">사용자 정의</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">변경 데이터 캡처</a></td><td>로우코드에서 프로 코드로</td><td>레코드 변경 사항</td><td>Apex, API, Lightning 웹 구성 요소(LWC)</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">사전 정의됨</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">플랫폼 이벤트</a></td><td>로우코드에서 프로 코드로</td><td>API, Apex, 플로우</td><td>Apex, API, 플로우, LWC</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">사용자 정의</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>프로 코드</td><td>Pub/Sub API 또는 API, Apex, 플로</td><td>Pub/Sub API</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">사용자 정의</a></td><td>1MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">이벤트 릴레이*</a></td><td>낮은 코드</td><td>플랫폼 이벤트, 변경 데이터 수집</td><td>API</td><td>3일</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">사용자 정의</a></td><td>1MB</td></tr>
<tr><td colspan="8">*이벤트 릴레이는 AWS Eventbridge로만 데이터를 전송합니다.</td></tr>
</tbody>
</table>

#### 메모리 및 저장소 관리

대기열 패턴의 비동기적 특성으로 인해 대기열에 추가되는 메시지와 검색되는 메시지 사이에 긴 지연이 있을 수 있습니다. 대기열에는 메시지를 보관하는 메모리 또는 저장소 공간이 필요하므로 무기한으로 증가할 수 없습니다. 즉, 대기열에 메시지가 충분히 누적되면 무기한으로 오프라인 상태인 구독자가 실패할 수 있습니다. 구독자의 처리 시간이 너무 길어지면 메시지 버퍼링이 동일한 영향을 미칠 수 있으며, 이로 인해 대기열에 많은 양의 메시지가 누적될 수 있습니다. 이러한 위험을 완화하려면 모든 메시지 대기열에 대한 철저한 저장소 요구 사항 분석을 수행하고 필요한 경우 메시지가 설정된 시간 내에 검색되지 않거나 사전 결정된 볼륨에 도달하면 대기열을 제거하고 비활성화하는 프로세스를 설계합니다.

## 비기능적 고려 사항

이전 섹션에 나열된 기능적 고려 사항 외에도 결정에 고려해야 할 비기능적 고려 사항도 있습니다.

### 점대점 통합에서의 마이그레이션

이벤트 기반 아키텍처가 조직에 적합하다고 확신하는 경우에도 이미 많은 점대점 통합이 있는 환경에서 시작할 수 있습니다. 모든 통합을 한 번에 대체하기 위해 프로젝트에 대한 자금을 확보하는 것은 어려울 수 있으며 일부 레거시 시스템에서는 이벤트 기반 아키텍처를 직접 사용할 수 없는 경우도 있습니다. 이러한 시나리오에서 가장 비즈니스에 중요한 애플리케이션을 먼저 변환한 다음, 향후 프로젝트에서 업데이트되거나 교체될 때 다른 시스템을 변환하여 더 느슨하게 연결된 아키텍처로 마이그레이션하는 증분 접근 방식을 취할 수 있습니다. 이 접근 방식을 통해 이벤트 버스에 새 애플리케이션을 쉽게 추가할 수 있으며, 시간이 지남에 따라 시스템이 계속해서 추가되면서 전반적인 IT 환경이 확장성과 탄력성을 유지할 수 있습니다.

### 느슨하게 연결된 시스템 내 트레이드오프

아키텍트로서 우리는 모든 아키텍처에 트레이드오프가 있다는 사실을 알고 있습니다. 이벤트 중심 아키텍처는 예외가 아닙니다. 매끄럽게 연결된 시스템으로 가득한 환경은 확장성이 높고 복원성이 뛰어나지만 고려해야 할 몇 가지 제약 사항도 있습니다.

- **전체적 통합 전략:** 사용하기로 결정한 도구 및 패턴과 상관없이 조직의 다양한 시스템에서 데이터를 공유하는 방법에 대한 전략을 수립하는 것부터 시작하는 것이 중요합니다. 이 전략에는 조직의 데이터 목표, 데이터를 공유할 수 있는 방법, 사용되는 패턴, 데이터 소스, 목표, 구조, 소유권 및 액세스 요구 사항이 포함되어야 합니다.

- **레거시 시스템 지원:** 조직에 단순히 이벤트 중심 아키텍처 패턴을 지원하지 않는 기존 시스템이 있을 수 있습니다. 해결 방법을 구축할 수 있지만(예: 이벤트를 구독한 후 다른 데이터 전송 수단을 통해 대상 시스템에 출력을 보내는 방식으로 진행 방법으로 작동하는 프로세스) 이 경우 다른 통합 방법을 고려할 수 있습니다.

- **메시지의 구조적 변경:** 게시자와 구독자 간에 초기 메시지 구조가 정의되고 동의되면 특히 구독자가 외부인 경우 변경하기 어려울 수 있습니다. 이 문제를 해결할 수 있는 몇 가지 방법이 있습니다. 버전이 지정된 엔드포인트를 사용할 수 있지만, 개발자가 너무 많은 버전을 동시에 유지하지 않도록 각 버전에 대해 명확한 라이프사이클을 정의하고 전달해야 합니다. Heroku 환경에 Apache Kafka가 포함되어 있다면, 스키마 레지스트리나 유사한 도구도 고려할 수 있지만, 환경 내의 다른 시스템에서도 이를 지원하고 실제로 사용해야 합니다.

- **게시자와 구독자 간 가시성 부족:** 대부분의 이벤트 중심 아키텍처 패턴에서 게시자는 구독자의 상태를 인식하지 못합니다. 따라서 모든 구독자가 오프라인 상태일 때 게시자가 중요한 메시지를 보내면, 그 메시지는 전달되지 않을 수 있습니다. 재생 기능을 사용하거나 모든 중요 메시지에 대해 별도의 서버에서 실행되는 중복 구독자를 추가하여 이 문제를 해결할 수 있습니다.

- **성능 병목:** 이벤트 중심 아키텍처가 확장되면, 너무 많은 게시자가 동시에 너무 많은 구독자에게 메시지를 보내려고 할 경우, 이벤트 버스가 메시지 전달의 병목 현상이 될 수 있습니다. 이벤트 버스에 할당된 메모리 및 처리 자원을 늘리거나 여러 이벤트 버스를 사용하여 다양한 유형의 메시지를 병렬로 처리하여 문제를 해결할 수 있습니다.

## 관련 모범 사례

이미 제공된 지침 외에도 다음 모범 사례도 고려하십시오.

### 이벤트 중심 아키텍처 구현

이벤트 중심 아키텍처를 구현하기 전에 정말로 이러한 아키텍처가 필요한지 먼저 고려하십시오. 이전 섹션에서는 각 이벤트 중심 아키텍처 패턴에 적합한 일반적인 비즈니스 시나리오를 설명합니다. [Well-Architected - Reliability](/docs/architect/ko-kr/well-architected/guide/reliability.html) 에서 자세히 읽을 수 있습니다. 이벤트 기반 아키텍처를 구현할 때 고려해야 할 챌린지를 검토하여 고려하는 패턴이 특정 사용 사례에 가장 적합한지 판단합니다.

이 가이드에 포함된 대부분의 시나리오에는 통합이 포함되어 있지만 이벤트 중심 아키텍처를 사용하여 예를 들어 플랫폼 이벤트를 사용하여 단일 Salesforce 조직 내에서 메시지를 보낼 수도 있습니다. 플랫폼 이벤트를 내부 메시징 시스템으로 사용하는 프로세스를 설계할 때 해당하는 [이벤트 할당 제한](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)을 고려하십시오.

### 안티 패턴 피하기

이벤트 중심 아키텍처에 대한 안티 패턴은 Salesforce 조직 내에서 내부 커뮤니케이션에 대한 해결 방법으로 이벤트를 사용하여 발생하는 경우가 많습니다. 일반적인 안티 패턴은 다음과 같습니다.

- **동일한 이벤트 개체와 연결된 Apex 트리거에서 이벤트 게시:** 이렇게 하면 무한 트리거 루프가 생깁니다.

- **DML 트랜잭션이 완료되기 전에 Apex에서 이벤트 게시:** 트랜잭션이 실패하고 롤백되는 경우 즉시 게시 동작이 있는 게시된 이벤트는 롤백 동작에 포함되지 않습니다.

- **다음 자동화를 오케스트레이션하기 위해 Flow에서 이벤트 게시하기:** 여러 자동화 간의 논리를 조정하는 가장 좋은 방법은 [서브플로](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm) 또는 [플로 오케스트레이터](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm)를 사용하는 것입니다.

- **런타임 종속성 만들기:** 패키지 간 통신을 용이하게 하기 위해 적절한 [단계](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8)를 거치지 않고 이벤트를 게시하지 마십시오.

- **불필요하게 큰 페이로드:** 요청할 때 페이로드에서 가능한 한 적은 양의 데이터를 보내서 받는 것이 가장 좋습니다. 사용자의 모든 작업이 잠재적으로 여러 요청을 생성할 수 있으며, 이러한 요청을 효율적으로 처리하는 것이 중요합니다. 필요보다 많은 데이터를 보내도 전송 속도가 느려지고 처리 시간이 늘어날 수 있습니다.

- **응용 이벤트의 비선별적 처리:** 응용 이벤트를 수신하는 구성 요소가 여러 개인 경우, 개발자는 이벤트 처리기가 실제로 필요하고 유용한 경우에만 실행되는지 확인해야 합니다. 예를 들어 Lightning 콘솔에서 포커스가 없는 탭에 포함된 구성 요소는, 보이지 않더라도 여전히 수신할 수 있습니다. 개발자는 백그라운드 유틸리티 항목을 유일한 수신자로 사용하거나 getEnclosingTabId()와 같은 다양한 기법을 활용하여, 이 구성 요소의 인스턴스가 포커스가 맞춰진 탭 내에 포함되어 있는지 판단함으로써 각 이벤트가 의도한 경우에만 처리되도록 할 수 있습니다.

- **플랫폼 이벤트의 게시 동작을 잘못 사용하는 경우:** 플랫폼 이벤트에는 즉시 게시(Publish Immediately) 및 커밋 후 게시(Publish After Commit)의 두 가지 게시 동작이 있습니다. 예를 들어, 트랜잭션 성공 및 커밋 여부와 상관없이 로깅(Logging) 이벤트를 게시하려는 사용 사례에 실시간 플랫폼 이벤트를 사용할 수 있습니다. 그러나 실시간 플랫폼 이벤트에서는 Publish Immediately를 매우 신중하게 사용해야 합니다. 이벤트는 같은 트랜잭션 내에서 구독자가 소비할 수 있으며 행 잠금 또는 기타 경쟁 조건이 발생할 수 있습니다.

### 효과적인 이벤트 설계

이벤트 중심 아키텍처를 구현할 때 성공의 핵심 중 하나는 이벤트 자체가 설계되는 방법에 대한 표준을 설정하는 것입니다. 세부 사항은 조직의 사용 사례에 따라 다를 수 있지만, 다음은 몇 가지 일반적인 지침입니다.

- **이벤트 페이로드에 최적의 구조를 결정합니다.** 메시지 크기가 작을수록 처리 시간이 단축되지만, 구독자에게 대량의 메시지를 보내면 성능 병목 현상이 발생할 수 있습니다. 적절한 균형을 찾기 위해 페이로드 크기와 구조를 반복적으로 조정해야 할 수 있습니다. MuleSoft 및 유사한 ESB 도구는 이벤트와 관련된 메시지에서 사용자 정의 페이로드를 설계할 수 있는 기능을 제공하며, 이를 통해 데이터 구조를 시각화하여 구독자 측의 성능을 개선할 수 있습니다. (자세한 내용은 [Well-Architected - Reliability](/docs/architect/ko-kr/well-architected/guide/reliability.html)를 참조하십시오.)

- **프로세스를 처음부터 끝까지 고려해 보십시오.** 통합이 롤아웃된 후에는 추적하기 어려울 수 있는 "무한 루프" 시나리오를 만들지 않도록 하십시오. 예를 들어, 두 시스템이 각각 레코드가 업데이트될 때 이벤트를 게시하고, 동시에 서로의 이벤트를 수신하여 처리 시 추가로 이벤트를 게시하는 경우가 있습니다.

  소비되는 이벤트로 인해 변경된 논리를 통해 새 이벤트가 게시되지 않도록 두 시스템 모두에 추가하여 이 유형의 안티 패턴을 수정할 수 있습니다. 모든 이벤트, 관련 트리거, 영향을 받을 수 있는 다운스트림 시스템도 문서화해야 합니다. 설계 세션 중에 이 문서를 참고 자료로 활용하여 무한 루프나 유사한 시나리오를 가능한 한 빨리 파악할 수 있습니다. (자세한 내용은 [Well-Architected - Operational Excellence](/docs/architect/ko-kr/well-architected/guide/operational-excellence.html)를 참조하십시오.)

- **시스템 간 공통 명명 규칙을 사용하십시오.** 일관된 명명 규칙은 이벤트 중심 아키텍처를 포함하여 모든 소프트웨어 개발에 대한 모범 사례입니다. 이벤트 이름, 구조, 관련 객체, 오류 처리 프로세스에 대한 표준을 문서화하여 시스템 간 일관성을 보장해야 합니다. (자세한 내용은 [Well-Architected - Operational Excellence](/docs/architect/ko-kr/well-architected/guide/operational-excellence.html)를 참조하십시오.)

## 자원

<table style="width:100%">
<thead>
<tr><th scope="col">패턴</th><th scope="col">자원</th></tr>
</thead>
<tbody>
<tr><td>게시/구독</td><td><a href="/docs/architect/ko-kr/well-architected/guide/reliability.html">Salesforce 솔루션 - 신뢰성</a><br><a href="/docs/architect/ko-kr/well-architected/guide/operational-excellence.html">Salesforce의 고급 설계 - 운영 우수성</a><br><a href="https://medium.com/salesforce-architects/achieve-architectural-efficiency-with-event-relays-c8d4ec7f07af">블로그 게시물: 이벤트 릴레이로 아키텍처 효율성 달성</a><br><a href="https://medium.com/salesforce-architects/announcing-pub-sub-api-generally-available-3980c9eaf0b7">블로그 게시물: Pub/Sub API 정식 출시 발표</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/moving-from-restful-to-eventful/">블로그 게시물: RESTful에서 Eventful으로 이동</a><br><a href="https://blogs.mulesoft.com/dev-guides/event-driven-architectures-asyncapi/">블로그 게시물: 이벤트 기반 아키텍처 및 AsyncAPI 사양</a><br><a href="https://youtu.be/0WJjmmw1ryM">비디오: 게시 / 구독 패턴 연습</a></td></tr>
<tr><td>Fanout</td><td><a href="https://developer.salesforce.com/blogs/2021/08/how-to-work-within-platform-events-delivery-limits">블로그 게시물: 플랫폼 이벤트 배달 제한 내에서 작업하는 방법</a><br><a href="https://youtu.be/zSncRUcucEU">비디오: Fanout 패턴 연습</a></td></tr>
<tr><td>전달된 메시지</td><td><a href="https://youtu.be/U87nErhMuqw">비디오: 전달된 메시지 패턴 설명</a></td></tr>
<tr><td>스트리밍</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">블로그 게시물: Salesforce에서 대용량 쓰기를 위한 설계</a><br><a href="https://youtu.be/-_1CDUI40fY">비디오: 스트리밍 패턴 연습</a><br><a href="https://docs.mulesoft.com/mule-runtime/4.3/streaming-about">문서: Mule 앱에서 스트리밍</a></td></tr>
<tr><td>대기열</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">블로그 게시물: Salesforce에서 대용량 쓰기를 위한 설계</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/event-payment-apis/">블로그 게시물: Evented API를 사용하여 결제 아키텍처를 설계하는 방법</a><br><a href="https://youtu.be/jQvSKbMRbh0">비디오: 대기열 패턴 설명</a></td></tr>
</tbody>
</table>

<!-- document id=3ffca2634eca4d4689a380f030834552dea7bcc901f7f57811aa59a349b0eff5 url=/architect/current/ko-kr/decision-guides/guides/get-started-integration-decision-guides.md -->

# 통합 결정 가이드 시작하기

이 섹션에서는 Salesforce에 적합한 데이터 통합 도구 및 접근 방식을 선택하기 위한 실용적인 지침을 제공합니다. 아웃바운드 통합, 인바운드 통합, 교차 조직 시나리오에 대해 다루며, 설계자가 성능, 유지 관리성, 비용의 균형을 맞추는 데이터 계층 통합을 설계 및 구현할 수 있도록 지원합니다.

---

## Salesforce와 데이터 통합

[Salesforce 데이터 통합](/docs/architect/ko-kr/decision-guides/guide/data-integration)은 Salesforce 데이터 통합 도구 및 모범 사례에 대한 포괄적인 개요를 제공합니다.

- **통합 도구 환경**: 특정 사용 사례에 적합한 도구를 선택하는 방법에 대한 지침과 함께 하위 코드, 하이브리드, 프로 코드 옵션 등 Salesforce 데이터 통합 도구의 개요입니다.
- **아웃바운드 통합**: 변경 데이터 수집, 외부 서비스, Heroku Connect, OmniStudio 통합 절차, Salesforce Connect, MuleSoft Anypoint 및 사용자 정의 Apex 솔루션을 비롯한 Salesforce에서 외부 시스템으로 데이터를 보내는 방법입니다.
- **인바운드 통합**: 데이터 복제 및 가상화와 각 도구를 사용하는 시기에 대한 지침과 함께 외부 데이터를 Salesforce로 가져오는 방법입니다.
- **교차 조직 통합**: MuleSoft Anypoint, Heroku Connect, 네이티브 Salesforce API, 변경 데이터 수집, Salesforce Salesforce Connect 및 Cross-Org 어댑터를 사용하여 레거시 Salesforce-to-Salesforce 구현을 교체하는 지침을 포함하여 Salesforce 조직 간 데이터 공유를 위한 권장 방법입니다.
- **결정 프레임워크**: 기존 도구 및 환경, 데이터 플로 요구 사항(타이밍, 방향, 예상 사용자 환경), 구현 복잡성, 유지 관리 가능성, 데이터 용량, 플랫폼 제한 등 통합 도구를 선택하기 위한 주요 고려 사항

설계자가 각 시나리오에 적합한 통합 도구 및 패턴을 선택하여 불필요한 데이터 복제를 최소화하고 기존 ESB/ETL 솔루션을 활용하며 엔터프라이즈 아키텍처 원칙에 부합하는 확장 가능한 유지 관리 가능한 통합을 보장할 수 있습니다.

<!-- document id=576f167db02b8f0d525137a45f0b0478609cd39dd637b2ea597cf705d3fa4603 url=/architect/current/ko-kr/decision-guides/guides/get-started-platform-decision-guides.md -->

# 플랫폼 결정 가이드로 시작하기

이 섹션은 Salesforce Platform 기능과 관련된 중대한 아키텍처 결정을 내리는 데 필요한 실용적인 지침을 제공합니다. 이 섹션은 비동기 처리, 레코드 트리거 이벤트, 양식 구축, agentic 및 기존 워크플로 자동화, 이벤트 중심 아키텍처, 단계 기반 비동기 프레임워크를 다루어 아키텍트들이 확장 가능하고 유지 보수가 용이하며 고성능의 플랫폼 솔루션을 설계할 수 있도록 돕습니다.

---

## 비동기 처리

[비동기 처리](/docs/architect/ko-kr/decision-guides/guide/async-processing)은 Salesforce에서 비동기 작업을 위한 도구 및 접근 방식에 대한 지침을 제공합니다.

- **비동기 처리 도구**: 대기 가능한 Apex, 예약된 Apex, 플랫폼 이벤트 트리거, 변경 데이터 수집, 예약 경로(커밋 플로 후) 및 비동기 경로(레코드 트리거 플로)의 비교 및 적절한 사용 사례에 대한 지침.
- **서버측 비동기 처리**: 장기 실행 데이터베이스 작업, 외부 콜아웃, 대용량 레코드 처리를 위한 패턴입니다.
- **클라이언트측 비동기 처리**: 브라우저 또는 모바일 앱에서 실행될 수 있는 Apex 연속 콜아웃 및 클라이언트측 비동기 처리와 같은 기술
- **결정 프레임워크**: 사용 사례 유효성 검사, 확장성, 트랜잭션이 진정으로 비동기임을 이해하는 것, 모니터링 및 극한 부하 이벤트 처리를 고려합니다.
- **모범 사례 및 안티패턴**: 아웃바운드 통합, 모니터링, 일반적인 함정을 피하는 등 적절한 사용 지침

설계자가 확장 가능하고 신뢰할 수 있으며 유지 관리 가능한 비동기 패턴을 구현하여 성능을 저하하는 함정을 피할 수 있습니다.

---

## 건물 양식

[양식 만들기](/docs/architect/ko-kr/decision-guides/guide/build-forms)은 Salesforce 양식 작성 옵션에 대해 아키텍트에게 안내합니다.

- **양식 작성 도구**: 동적 양식, 화면 플로, OmniStudio, Lightning 웹 구성 요소(LWC) 및 LWC의 화면 플로와 기술 및 라이센스 고려 사항을 비교합니다.
- **결정 프레임워크**: 개체 영향, 양식 범위, 탐색, 위치(앱, 모바일, 웹), UX, 테스트 자동화를 고려합니다.
- **도구 선택 지침**: 간단한 레코드 레이아웃에서 다중 페이지 마법사 및 브랜드화된 고객 대면 양식에 이르는 권장 사항입니다.
- **조합 패턴**: 도구를 결합하는 지침입니다(예: 스크린 플로우 탐색과 LWC 스타일링).
- **고급 기능**: 기능과 제한 사항을 심층적으로 분석하여 도구 선택에 참고할 수 있도록 합니다.

설계자가 특정 UX, 기능, 통합 요구 사항에 맞는 양식 작성 방식을 선택할 수 있도록 돕습니다.

---

## Agentic 및 기존 워크플로 자동화 결정

[Agentic 및 기존 워크플로 자동화 결정](/docs/architect/ko-kr/decision-guides/guide/determining-agentic-vs-traditional-workflow-automation.html)은 오케스트레이션 밀도 프레임워크를 사용하여 기존 자동화와 Agentforce 간에 선택할 수 있는 프레임워크를 제공합니다.

- **오케스트레이션 밀도 프레임워크**: 실행 경로(완전히 지정 가능한 대 지정할 수 없는), 목표 복잡성(단일 과업 대 경쟁 목표), 모달 혼합(정형 대 다중 모달 입력)을 기반으로 자동화 복잡성을 평가합니다.
- **제품 환경**: 다양한 자동화 시나리오에 대한 플로, Apex, Agentforce, AgentScript, Agentforce 그리드, Agentforce 운영 및 MuleSoft 비교
- **밀도 선택 매트릭스**: 오케스트레이션 밀도 수준(낮음, 보통, 높음)을 레코드 트리거 자동화, 하이브리드 오케스트레이션, 그리고 Agent Script를 활용한 가이드 결정론 등 아키텍처 표준에 매핑합니다.
- **결정 프레임워크**: 순차적 평가 프로세스: 먼저 실행 경로를 평가하고, 다음으로 목표 복잡성과 모달 혼합을 확인하여 올바른 도구를 결정합니다.
- **사용 사례 가이드**: 기존 자동화(규칙 기반, 결정적), Agentforce Grid(대량 AI 작업), 하이브리드 오케스트레이션(복잡한 엔드 투 엔드 프로세스) 및 Agent Script(비정형 진입점과 논리적 요구 사항)에 대한 구체적인 권장 사항을 제공합니다.

설계자가 자동화 스펙트럼 전반에서 정보에 입각한 결정을 내릴 수 있도록 하여, 확장 가능하고 감사 및 유지 관리가 용이한 솔루션을 위해 결정적 제어와 추론 기능의 균형을 이룰 수 있게 합니다.

---

## 이벤트 중심 아키텍처

[이벤트 기반 아키텍처](/docs/architect/ko-kr/decision-guides/guide/event-driven)는 Salesforce 이벤트 도구 및 패턴에 대한 포괄적인 가이드를 제공합니다.

- **이벤트 도구**: 플랫폼 이벤트, 변경 데이터 수집, Pub/Sub API, MuleSoft Anypoint, 스트리밍 API 및 통합 고려 사항의 개요.
- **이벤트 중심 패턴**: 다양한 이벤트 중심 사용 사례에 대한 게시/구독, 팬아웃, 패스스루 메시지, 스트리밍, 그리고 큐잉 패턴을 포함합니다.
- **MuleSoft와의 통합**: 엔터프라이즈 아키텍처에 Anypoint 커넥터(Pub/Sub, JMS, Kafka, Solace, MQ, MQTT, AMQP) 사용
- **플랫폼 이벤트 및 변경 데이터 수집**: PushTopic/Generic 이벤트에서 마이그레이션을 사용하여 레코드 및 필드 변경 사항을 게시하기 위한 기본 메커니즘에 대한 지침입니다.
- **구현 패턴**: 확장성, 일관성, 오류 처리, 모니터링에 대한 모범 사례입니다.

설계자가 여러 시스템을 효율적으로 연결하는 확장 가능한 거의 실시간 이벤트 중심 시스템을 설계할 수 있습니다.

---

## 단계 기반 비동기 프레임워크

[Step-Based Async Framework](/docs/architect/ko-kr/decision-guides/guide/step-based-async-framework)는 모듈식으로 확장 가능한 비동기 작업 처리를 위한 프레임워크를 제공합니다.

- **프레임워크 아키텍처**: 구성 요소에는 Queueable Apex, Finalizers, Scheduled Flow, Apex 커서, 호출 가능한 작업 및 Slack 통합이 포함됩니다.
- **단계별 처리**: 작업을 공유된 거버넌스 및 운영 가시성과 함께 실행, 재시도, 그리고 재시작할 수 있는 여러 독립적인 단계로 분할합니다.
- **구현 지침**: 단계 인터페이스, 단계 처리기, Apex 호출 가능 레이어, 지연 처리 및 알림에 대한 패턴입니다.
- **모범 사례**: CRM에 대부분의 정보가 존재하고 대용량 작업 로드 및 계층적 또는 트리 기반 레코드 처리가 요구되는 경우에 권장되며, 사용하지 말아야 할 상황에 대한 지침도 제공합니다.
- **엔터프라이즈급 기능**: 거버넌스, 규정 준수, 분산된 상태, 진행률 추적, SLA 모니터링, 오류 진단, 감사 수준 로깅

설계자에게 모노리틱 배치 작업 및 연쇄 비동기 호출에 대한 확장 가능한 대안을 제공하여 대용량 Salesforce 워크로드를 완벽한 운영 투명도로 지원합니다.

---

## 레코드 트리거형 자동화

[레코드 트리거형 자동화](/docs/architect/ko-kr/decision-guides/guide/record-triggered)는 Salesforce Platform에서 레코드 트리거형 자동화를 설계하는 프레임워크를 제공합니다.

- **도구 선택**: 자동화 밀도(낮음, 중간, 높음)와 밀도 선택 매트릭스에 따라, 레코드 트리거 플로우와 Apex 트리거 사용 시기를 안내합니다.
- **자동화 밀도**: 자동화의 양, 레코드 용량, 종속성 확산을 평가하여 플로우, 하이브리드(Invocable Apex를 포함한 플로우) 또는 Apex 트리거 중에서 선택하는 방법을 안내합니다.
- **진입점 및 거버넌스**: Salesforce 개체당 하나의 진입점을 사용하며, 진입 조건, 재귀 제어 및 순차 실행에 대한 지침을 제공합니다.
- **비동기식 호출**: 오류 처리와 거버너 제한에 주의하면서, 레코드 트리거 플로우 또는 Apex에서 비동기 프로세스를 언제, 어떻게 호출해야 하는지 설명합니다.
- **모범 사례**: 대량 처리, 하이브리드 Flow–Apex 설계 및 트리거 자동화의 일반적인 함정을 피하는 패턴

아키텍트가 플랫폼 표준에 맞춰 확장 가능하고 유지 관리가 용이하며 성능이 뛰어난 레코드 트리거형 자동화를 설계할 수 있도록 지원합니다.