에이전트가 사용 가능한 플로 만들기

학습 목표

이 유닛을 완료하면 다음을 수행할 수 있습니다.

• 에이전트 작업에 할당할 수 있는 플로를 만듭니다.
  
• 에이전트 작업 플로의 리소스에 유용한 이름과 설명을 작성합니다.
  
• 에이전트 작업 플로에서 적절한 변수를 생성합니다.
  
• 에이전트와 관련 플로가 액세스할 수 있는 데이터를 제한합니다.
  

이 뱃지는 학습자가 플로에 대해 알고 있으며 Flow Builder를 사용해 본 경험이 있다고 가정합니다. Flow Builder로 플로 작성하기 트레일을 따라 강력한 프로세스 자동화 기술을 만들고 Flow Builder 전문가가 되어 보세요.

에이전트에 플로를 사용해야 하는 이유

Agentforce는 사용자와 고객을 위한 아주 강력한 도구이며 그 기능은 대부분 플로에서 나옵니다. 에이전트는 Salesforce 데이터에 액세스할 수 있지만 에이전트 작업 없이 데이터를 변경할 수 없습니다. 에이전트가 레코드를 생성하고, 업데이트하고, 삭제할 수 있도록 하려면, 데이터를 변경하는 에이전트 작업을 정의해야 합니다. 에이전트 작업은 Apex 클래스나 API를 호출하거나, 플로를 실행하거나, 프롬프트 템플릿을 참조할 수 있는 한편, 플로는 로우코드 방식으로 Salesforce org의 데이터를 변경할 수 있는 유일한 방법입니다.

플로는 에이전트가 특정 데이터로 작업하도록 할 때 정확도를 한층 높여 주기도 합니다. 에이전트는 읽기 권한을 부여받은 모든 Salesforce 데이터를 읽을 수 있으며 관련이 있다고 판단되는 모든 데이터를 사용할 수 있습니다. 에이전트가 사용하는 데이터를 제한하고 에이전트의 정확도를 크게 높이기 위해 에이전트에 제공할 구체적이고 정확한 데이터를 검색하는 플로를 생성합니다. 그런 다음 플로가 제공한 데이터만 사용하도록 에이전트에게 지침을 전달합니다.

그렇다면 어떻게 플로 기반 에이전트 작업을 만들어야 할까요?

자동 실행 플로 만들기(트리거 없음)

에이전트 작업은 자동 실행 플로(트리거 없음) 유형의 플로만 지원합니다. 레코드 트리거형 플로와 같은 다른 플로 유형도 기술적으로 자동 실행 플로에 해당되지만, 할당된 플로는 반드시 '트리거 없음' 유형이어야 합니다. 에이전트 작업에서 사용할 기존 플로가 해당 유형이 아니라면 자동 실행 플로(트리거 없음) 유형을 사용하여 플로를 다시 만들어야 합니다.

구체적으로 설명하기

AI 기술은 텍스트에 상당히 의존합니다. AI에 텍스트를 생성하라고 요청할 때 좋은 결과를 얻으려면 자세한 지침을 제공해야 하며, 상세하고 정확한 소스 텍스트가 있어야 합니다. 이는 에이전트 작업으로 실행하려고 하는 어떤 플로도 마찬가지입니다.

에이전트는 플로가 작업 중인 데이터뿐만 아니라 플로의 변수 이름을 통해 플로가 수행하는 작업을 이해합니다. 따라서 플로의 입력과 출력 변수에 정확하고 구체적인 이름을 지정해야 합니다. 'foo'와 같은 관련 없는 변수 이름을 입력하지 마세요. 대신 'Account_ID'와 같은 서술적인 변수 이름을 사용하세요.

플로에서 모든 과정에 설명을 포함하는 것이 이미 가장 좋은 모범 사례이지만, 플로가 에이전트 작업으로 실행되는 경우 그 중요성이 훨씬 커집니다. 에이전트는 플로의 설명과 변수의 설명을 사용합니다. 이 모든 텍스트는 에이전트가 플로의 기능과 플로가 작업하는 데이터를 이해하는 데 도움을 줍니다. 구체적인 이름과 설명이 없으면 에이전트는 변수 및 데이터로 어떤 작업을 수행할지 확실하게 판단할 수 없습니다.

효과적인 설명과 그렇지 않은 설명의 몇 가지 모범 사례를 확인해 보세요.

플로 설명은 다른 설명보다 더 지시적인 설명이라는 점을 주목하세요. 플로를 에이전트에 추가할 때 플로의 설명이 자동으로 에이전트를 위한 지침이 되기 때문입니다. 에이전트 지침의 형태로 초기 플로 설명을 작성하여 시간을 절약하세요.

항상 입력 및 출력 변수 사용하기

플로 기반 에이전트 작업은 언제나 플로에서 최소 하나의 입력 변수와 최소 하나의 출력 변수가 필요합니다. 이 변수들이 필요하지 않더라도 여전히 입력과 출력 변수를 사용하는 것이 모범 사례입니다. 플로에 더 많은 컨텍스트를 제공하면 플로가 더 정확해지며, 이에 따라 플로가 올바른 데이터를 보내면 에이전트의 수행 능력이 향상됩니다.

에이전트에 전달할 데이터가 딱히 생각나지 않더라도 출력 변수에 항상 전달하는 것을 고려해야 할 항목이 있습니다. 바로 오류 메시지입니다. 에이전트는 플로에서 어떠한 결과를 기대합니다. 그 결과가 단순히 플로의 “YOUR FLOW FINISHED(플로가 완료됨)” 메시지라 하더라도 그렇습니다. 하지만 플로의 실행이 실패할 수 있으며, 예기치 않은 오류가 발생할 수 있습니다. 플로에서 데이터를 받지 못하면 에이전트는 사과와 함께 일반적인 “Something went wrong(오류가 발생했습니다)” 메시지를 제공할 것입니다. 또는 어떠한 상황 전달 없이 고객에게 다른 데이터를 제시할 수도 있습니다. 단지 무엇이라도 제시하고 싶기 때문입니다.

이를 방지하기 위해(또는 출력 변수 요건을 충족하기 위해), 더 자세하고 유용한 오류 메시지를 제공하도록 설계된 출력 변수를 생성하세요. 플로에서 오류 경로와 할당 요소를 사용하여 출력 변수에서 오류 메시지를 설정하세요. 그런 다음 에이전트에게 해당 출력 변수를 언제 어떻게 사용할지 지시하세요. 다음 유닛에서 구성 방법을 살펴보겠습니다.

레코드 변수 겁내지 않기

레코드 변수는 단지 플로 내에서만 작업하기 위한 것은 아닙니다. 에이전트도 레코드 변수를 받을 수 있습니다! 에이전트에 하나의 레코드 또는 여러 레코드에서 여러 필드를 전송해야 하는 경우 여러 변수를 생성하지 마세요. 대신 해당 데이터에 대해 하나의 레코드 변수 또는 하나의 레코드 모음 변수를 생성하고 이를 출력에 사용하세요. 에이전트가 진행 중인 고객 사례에서 네 개의 필드를 요청한다고 가정해 봅시다. 4개의 개별 변수를 사용하는 대신 하나의 레코드 변수에서 4개의 사례 필드를 반환합니다. 여러 사례를 반환하고 싶은 경우 이를 단일 레코드 모음 변수로 반환할 수 있습니다.

그러면 에이전트가 모든 데이터를 받아 이를 활용할 수 있습니다. 에이전트의 지침에서 레코드 데이터를 고객에게 제시하라고 되어 있는 경우 에이전트는 먼저 해당 데이터를 유용하고 읽을 수 있는 형식으로 구성합니다.

에이전트에 과다한 데이터 제공 방지하기

에이전트가 플로에서 데이터를 받으면 그 데이터를 무엇인가에 사용해야 한다고 생각하는 경향이 있습니다. 결정을 내리기 위해 데이터를 사용할 수도 있고 불필요한 데이터를 고객에게 표시할 수도 있습니다. 고객에게 노출해서는 안 되는 고객 데이터를 제공할 수도 있습니다. 그러므로 에이전트가 사용하지 않기를 바라는 데이터라면 에이전트에게 절대 제공하지 마세요.

안타깝게도 이 규칙은 플로의 기본 'Get Records(레코드 가져오기)' 설정과 모순됩니다. How to Store Record Data(레코드 데이터 저장 방법) 설정의 기본값은 '모든 필드 자동 저장(Automatically store all fields)'이지만, 에이전트는 아마 모든 필드가 필요하지 않을 것입니다. 대신 'Choose fields and assign variables(필드 선택 및 변수 할당)' 설정을 선택하여 별도의 레코드 변수를 사용하고 에이전트에게 필요한 필드만 선택하세요.

에이전트에 적절한 권한 부여하기

직원용 에이전트는 에이전트와 상호 작용하는 사용자의 권한을 사용하지만, 외부용 에이전트는 단일 전용 사용자의 권한을 사용합니다. 적절한 권한을 보유한 에이전트는 모든 Salesforce 데이터에 액세스할 수 있기 때문에 에이전트에게 여러 많은 데이터에 액세스 권한을 부여하면 위험할 수 있습니다. 각 에이전트의 전용 사용자가 필요한 권한만 소유하도록 하는 것이 특히 중요합니다. 반드시 필요하지 않은 영역에 대해서는 액세스 권한을 부여하지 마세요.

에이전트의 권한을 제어하려면 먼저 해당 에이전트에 할당된 Agent User(에이전트 사용자)를 찾아보세요. Agentforce 빌더의 Agent Details(에이전트 세부 사항) 페이지에서 이 사용자를 조회하고 변경할 수 있습니다.

에이전트 사용자를 파악한 후에는 이 사용자에게 플로를 실행하고 고객 요청을 처리하는 데 필요한 권한 집합, 프로필, 역할을 부여합니다.

하나의 큰 플로보다 여러 작은 플로 구성하기

에이전트에게는 각 개별 작업을 완료하는 소규모의 여러 작업들로 구성된 모듈형 설계가 도움이 됩니다. 이러한 작업들은 여러 방식으로 결합할 수 있으며, 여러 에이전트 간에 재사용될 수 있습니다.

그러면 플로를 분리하는 경계를 설정할 지점을 어떻게 알 수 있을까요? 플로를 에이전트와 연결하는 방법을 생각해 보세요. 각 플로에 하나의 에이전트 작업을 생성합니다. 에이전트가 작업을 수행하라는 요청을 받으면 일반적으로 작업 자체가 플로의 경계를 정의합니다. 예를 들어, 기회 단계를 변경하라는 요청을 받으면 그것이 하나의 플로로 수행되는 하나의 작업이 됩니다. 에이전트가 단계를 변경하지 않고 마감 일자를 변경하라는 요청을 받을 수도 있습니다. 그러면 이 요청은 다른 플로로 수행되는 별도의 작업이 됩니다. 그러나 Stage(단계) 필드의 잠재적인 값마다 별도의 작업과 플로가 필요하지는 않습니다. 플로가 Update Records(레코드 업데이트) 요소를 사용하여 요청된 값으로 필드를 설정할 수 있기 때문입니다.

요청 작업이 Stage(단계) 및 Close Date(마감 일자)를 동시에 업데이트하는 것이었다면, 이 요청을 하나의 에이전트 작업 플로로 수행할 수 있습니다. 하나의 요청이기 때문입니다.

상호 작용 지점 또한 플로의 경계를 설정하는 좋은 방법입니다. 플로 중간에 고객에게 정보를 요청할 수는 없습니다. 따라서 에이전트가 정보를 제시해야 하거나 다음에 수행할 작업을 요청해야 하는 경우 일반적으로 상호 작용 지점이 적합한 경계가 될 수 있습니다. 여러 작업을 수행해야 할 수도 있는 기회 관리용 서브에이전트를 상상해 보세요.

1. 고객에게 어떤 기회를 사용할지 물어봅니다.
   
2. 해당 기회에 대한 데이터를 가져옵니다.
   
3. 적절한 데이터를 바탕으로 에이전트가 고객이 어떤 도움이 필요한지 물어봅니다.
   
4. 고객이 요청한 작업을 수행합니다.
   

이 시나리오에서 하나의 플로로 1단계와 2단계 모두를 처리할 수 있습니다. 에이전트가 3단계를 처리합니다. 4단계는 에이전트가 고객의 기회 레코드로 수행할 수 있는 것이 무엇인지에 따라 하나 이상의 개별 플로로 처리해야 합니다.

기타 고려 사항

에이전트에서 플로로 작업할 때 추가로 주의해야 할 몇 가지 사항이 있습니다.

변수에 긴 텍스트 문자열 보내지 않기

텍스트 변수는 최대 255자까지 포함할 수 있으며 제한을 초과한 글자는 잘립니다. 텍스트 데이터 형식의 입력 변수에 길이를 알 수 없는 텍스트를 할당할 때 주의하세요. 플로에 255자를 초과하는 텍스트를 보내려면 개발자와 협력하여 대신 Apex 정의 변수를 생성하세요.

명확한 텍스트 작성하기

에이전트가 컨텍스트와 지침을 잘 이해할 수 있도록 가능한 정확한 정보를 제공하세요. 문법, 철자, 구두점이 올바른 완전한 문장을 사용합니다. 변수의 API 이름처럼 공백을 사용할 수 없는 위치에 텍스트를 입력하는 경우 단어 사이에 밑줄을 추가하여 명확하게 전달하세요. 예를 들어 AccountINGNumber 대신 Account_ING_Number를 사용합니다.

호환되지 않는 출력 데이터 형식 피하기

다음과 같은 복잡한 데이터 형식은 출력 변수를 통해 에이전트로 반환할 수 없습니다.

• 통화
  
• 선택 목록
  
• 다중 선택 선택 목록
  
• Apex 정의
  

플로가 에이전트에 위 데이터 형식 중 하나를 전달하도록 구성하면 에이전트는 더 이상 어떠한 출력 변수도 처리할 수 없습니다.

플로 변수 변경 후 에이전트 작업 다시 만들기

플로에서 에이전트 작업을 생성하면 그 작업은 플로의 입력과 출력 변수의 스냅샷을 한 번 가져옵니다. 이 스냅샷은 정적이며 플로 변수를 변경해도 스냅샷이 업데이트되지 않습니다. 에이전트가 오래된 변수로 플로를 실행할 때 발생할 수 있는 문제를 방지하려면 해당 에이전트 작업을 삭제하고, 새 에이전트 작업을 만들어 플로를 에이전트 작업에 다시 할당해야 합니다.

리소스

• Salesforce 도움말: 에이전트 작업 지침에 대한 모범 사례
• Salesforce 도움말: Agentforce 고려 사항