B2B 마케팅, RevOps 및 영업 팀에게 있어 이제 질문은 AI가 이메일을 한 통 더 작성할 수 있느냐가 아닙니다. 개발자 측면에서의 문제는 모든 자율적인 액션(autonomous action)이 그 트리거(trigger), 승인된 데이터, 권한 결정, 비즈니스 결과 및 에스컬레이션 경로(escalation path)까지 추적될 수 있느냐 하는 것입니다.

Salesforce는 Agentforce SDR이 24시간 내내 인바운드 잠재 고객과 소통할 수 있다고 말합니다. Marketing Cloud Next는 자율적인 액션을 캠페인 조립, 성능 최적화 및 개인화(personalization) 영역까지 확장합니다. 이렇게 확장된 운영 표면(operating surface)은 관찰 가능성(observability), 기여도 분석(attribution) 및 예외 처리(exception handling)를 출시 후에 추가하는 선택적 보고 사항이 아니라, 제어 시스템(control system)의 일부로 만듭니다.

기능을 액션 계약(Action Contracts)으로 변환하기

보고된 기능과 가정을 분리하는 것부터 시작하십시오.

Marketing Cloud Next의 유료 미디어(paid-media) 기능은 성과가 낮은 광고를 일시 중지하고 타겟팅 및 지출에 대한 개선 사항을 권장할 수 있습니다. 하지만 이것이 자율적인 예산 재할당이나 실시간 입찰 수준의 제어권을 확립하는 것은 아닙니다.

이러한 구분이 중요한 이유는 동사(verbs)가 권한의 경계(permission boundary)를 정의하기 때문입니다. "권장(Recommend)", "일시 중지(pause)", "변경(change)"은 서로 다른 부작용(side effects)을 가진 서로 다른 액션입니다. 이를 단일한 autonomous: true 플래그로 표현하는 것을 피하십시오.

대신, 허용된 모든 작업에 대해 액션 계약(action contract)을 정의하십시오. 다음 사항을 기록하십시오:

• 액션을 실행 가능하게 만드는 트리거(trigger)
• 사용할 수 있는 승인된 데이터 및 지식(knowledge)
• 발생할 수 있는 외부 부작용(side effects)
• 실행이 자동인지, 검토가 필요한지, 또는 금지되었는지 여부
• 액션과 연결된 신뢰할 수 있는 비즈니스 지표(business metric)
• 예외 및 에스컬레이션 경로(escalation path)
• 결정을 재구성하는 데 필요한 텔레메트리(telemetry)

이를 통해 제품 기능은 개발자, RevOps, 마케팅 및 컴플라이언스(compliance) 팀이 함께 테스트할 수 있는 무언가로 변환됩니다.

제어 모델을 YAML로 인코딩하기

다음 아티팩트(artifact)는 Salesforce 설정 구문이라기보다는 개념적인 것입니다. 이는 귀하의 팀이 이미 사용 중인 정책 엔진(policy engine), 워크플로 시스템(workflow system) 및 관찰 가능성 스택(observability stack)에 맞게 조정되도록 설계되었습니다.

control_model:
  agent: "Agentforce SDR"

...

목표(goal), 권한(permission), 텔레메트리(telemetry), 기여도(attribution), 그리고 에스컬레이션(escalation) 규칙을 하나의 아티팩트(artifact)에 유지함으로써, 이들이 서로 다른 운영 경계를 설명하는 별개의 문서로 분산되는 것을 방지할 수 있습니다.

활동이 아닌 의사결정을 중심으로 관측성(Observability) 설계하기

유용한 모니터링 설정은 에이전트가 출력을 생성했는지 여부 그 이상을 보여주어야 합니다. 개발자는 왜 특정 액션이 발생했는지, 그리고 해당 액션이 제어 모델(control model)을 통해 어떻게 이동했는지를 재구성할 수 있어야 합니다.

각 실행(run)에 대해, 트레이싱(tracing) 및 모니터링 시스템은 다음 질문에 답할 수 있어야 합니다.

• 어떤 트리거(trigger)가 실행을 시작했는가?
• 승인된 어떤 지식 및 데이터 참조(data references)가 사용되었는가?
• 어떤 권한 규칙(permission rule)이 액션을 허용하거나 차단했는가?
• 에이전트가 어떤 의사결정을 내리고 어떤 출력을 생성했는가?
• 액션이 외부 부작용(side effect)을 생성했는가?
• 어떤 기여도 참조(attribution reference)가 해당 액션을 신뢰할 수 있는 비즈니스 지표와 연결하는가?
• 예외(exception)가 발생했는가, 발생했다면 어디로 에스컬레이션되었는가?

이러한 필드들은 이미 귀하의 스택(stack)에서 승인된 에이전트 트레이싱(agent-tracing), 애플리케이션 로깅(application-logging) 또는 모니터링 도구로 전송될 수 있습니다. 벤더(vendor)가 무엇인지보다 권장(recommendation), 승인(approval), 실행(execution) 및 에스컬레이션(escalation) 경로 전반에 걸쳐 일관된 트레이스 계약(trace contract)을 유지하는 것이 더 중요합니다.

대시보드는 이러한 상태들을 일반적인 성공 결과로 그룹화하기보다는 각각 구분하여 보여주어야 합니다. 검토자에게 도달한 권장 사항, 실행된 승인된 액션, 그리고 에스컬레이션된 예외는 운영 측면에서 서로 다른 결과입니다.

관측성(Observability)은 자율성(autonomy) 결정도 지원합니다. 만약 팀이 특정 액션을 권한 결과, 다운스트림 결과(downstream outcome), 그리고 예외 경로와 연결할 수 없다면, 해당 액션의 권한을 확대하는 데 필요한 근거가 부족한 것입니다.

브랜드 제어와 승인 제어를 분리하여 유지하기

브랜드 가이드라인과 승인 정책은 서로 다른 질문에 답합니다.

브랜드 가이드라인은 출력이 어떻게 보이고 들려야 하는지를 결정합니다. 승인 정책(Approval policy)은 위험한 외부 작업이 진행되어도 되는지를 결정합니다. 어떤 출력물은 모든 브랜드 규칙을 준수하더라도, 그 주장(claim), 목적지, 또는 부작용(side effect)으로 인해 권한 경계(permission boundary)를 넘을 수 있습니다.

구현 및 텔레메트리(telemetry) 단계에서 이러한 제어 항목들을 별도로 표현하십시오. 추적(trace)은 브랜드 준수를 실행 권한으로 취급하는 대신, 출력 품질 결과와 실행 권한 결과를 모두 보여주어야 합니다.

신뢰할 수 있는 데이터를 런타임 인프라로 취급하기

Agentforce SDR이 인바운드 영업 개발(sales-development) 업무를 처리할 수 있지만, 승인된 지식(knowledge), 라우팅(routing), 주장(claims), 그리고 에스컬레이션(escalation) 규칙은 여전히 인간의 책임 영역으로 남습니다. 에이전트가 이러한 규칙을 바탕으로 행동하기 시작하면, 해당 책임들은 런타임 의존성(runtime dependencies)이 됩니다.

따라서 더 나은 자율성을 확보하기 위해서는 엔지니어링 작업을 다음과 같은 상류(upstream) 단계로 전환해야 합니다:

• 목표 설계 (Goal design)
• 데이터 품질 (Data quality)
• 속성 부여 (Attribution)
• 권한 (Permissions)
• 관측 가능성 (Observability)
• 예외 처리 (Exception handling)

데이터 파이프라인은 신뢰할 수 있는 기록을 올바른 액션 경로로 전달해야 합니다. 보고(Reporting)는 신뢰할 수 있는 비즈니스 지표와 감사 추적(audit trail)을 모두 노출해야 합니다. 예외 처리는 인간 관리자가 인수인계(handoff) 시점부터 업무를 계속할 수 있도록 충분한 컨텍스트(context)를 제공해야 합니다.

자율성은 이러한 주변 시스템의 품질을 증폭시킵니다. 빠른 실행 속도가 신뢰할 수 없는 데이터, 불완전한 라우팅, 또는 누락된 속성 부여를 보완해 주지는 않습니다.

추적 증거를 통한 자율성 촉진

자율성을 실행 시점(launch-time)의 영구적인 결정으로 만들지 마십시오. 에이전트가 신뢰할 수 있는 비즈니스 지표에 따라 안정적으로 동작한 후에만 액션의 권한을 확장하십시오.

이러한 확장을 릴리스 게이트(release gate)로 취급하십시오. 액션 추적(action traces)을 검토하고, 해당 지표가 의도된 결과를 나타내는지 확인하며, 예외 사항을 점검하고, 에스컬레이션이 필요한 컨텍스트와 함께 책임 있는 관리자에게 도달하는지 검증하십시오.

증거가 불충분하다면, 해당 액션을 권장(recommendation) 모드 또는 검토 필요(review-required) 모드로 유지하십시오. 목표는 최대의 자율성이 아닙니다. 가용한 증거가 뒷받침할 수 있는 가장 넓은 권한 경계를 설정하는 것입니다.

저자 소개

Van Data Team은 데이터 파이프라인 (data pipelines), 워크플로 자동화 (workflow automation), 리포팅 (reporting), 그리고 리스크 기반 검토 게이트 (risk-based review gates)를 통해 에이전트 기반 작업 (agentic work)을 운영 가능한 상태로 만듭니다.

무엇을 가장 먼저 자동화하시겠습니까?

만약 Agentforce를 구현한다면, 어떤 단일 액션 (single action)을 가장 먼저 자동으로 허용하시겠습니까? 그리고 해당 권한을 확장하기 전에 어떤 추적 증거 (trace evidence)와 신뢰할 수 있는 비즈니스 지표 (trusted business metric)를 요구하시겠습니까?

📖 가이드 전문 읽기 → Salesforce Autonomous AI Agents: What Agentforce Changes