신뢰할 수 있는 에이전트 행동 구현을 위한 Agentforce 가이드: 6가지 수준의 결정론을 위한 프레임워크

올파 카라트, 제품 관리 부문 이사 - Agentforce
리니어 반 루켄, 제품 관리 선임 이사 - Agentforce

신뢰는 1999년 설립 이래 새로운 클라우드 컴퓨팅과 SaaS 기술 모델을 개척하는 과정에서 Salesforce의 가장 중요한 가치로 자리 잡았습니다. 비즈니스는 귀중한 기업 데이터를 클라우드에 저장하여 Salesforce를 향한 신뢰를 보여줍니다. 이 데이터는 적절한 액세스 제어를 통해 안전하게 관리됩니다. 이는 여전히 중요한 개념이지만, 에이전트 AI 시대에는 신뢰의 정의가 훨씬 더 넓어졌습니다. 기업이 중요한 비즈니스 기능을 수행하는 데 자율 에이전트에 점점 더 의존하는 지금, 에이전트는 정확하고 관련성 있으며 무엇보다도 신뢰할 수 있는 비즈니스 파트너가 되어야 합니다.

그렇다면 어떻게 신뢰할 수 있는 에이전트를 구축할 수 있을까요? 일반적으로 동일한 입력을 제공할 때 같은 결과를 산출해야 안정성이 있다고 할 수 있습니다. 하지만 에이전트는 본질적으로 결정론적이지 않은 대규모 언어 모델(LLM)을 바탕으로 구동되기 때문에, 같은 입력에 다른 결과가 출력되기도 합니다. 이를 통해 에이전트는 접하게 되는 모든 조건이나 상황을 명시적으로 프로그래밍할 필요 없이 특정 상황에 따라 창의적인 맞춤형 솔루션을 개발할 수 있는 유동성을 갖게 됩니다. 하지만 에이전트는 비즈니스 요구 사항과 운영 가이드라인을 준수하기 위해 거버넌스도 필요로 합니다. 비즈니스 프로세스를 실행할 때는 안정성을 입증하고 결정론적인 제약 조건에 부합하는 비즈니스 성과를 창출해야 합니다. 결정론은 에이전트가 제공하는 자율성 및 유동성과 충돌하는 경직성과 규율을 부과합니다. 따라서 성공적인 에이전트를 생성하려면 창의적인 유동성과 엔터프라이즈 제어 간의 적절한 균형을 유지하는 것이 핵심입니다.

이 문서는 신뢰할 수 있는 에이전트를 개발할 때 고려해야 할 주요 사항을 다룹니다. 에이전트 제어의 6개 수준을 정의하고, 각 수준에서 에이전트 행동에 대한 제어를 획득하고 유지하기 위한 모범 사례를 살펴봅니다. 가이드를 통해 Agentforce 추론 엔진이 작동하는 방식을 설명합니다. Agentforce가 성장함에 따라 이 문서는 최신 모범 사례를 반영하여 업데이트될 예정입니다.

이 문서에서는 Agentforce 에이전트 설계 및 구축의 기본 사항에 익숙하다고 가정합니다. Agentforce 소개의 경우 다음을 권장합니다.

• agentforce.com에서 리소스를 검토하세요.
• 트레일 Agentblazer 챔피언되기 를 따라보세요. 이 트레일은 핵심 AI 개념을 살펴보고 주요 업무를 위한 기본 에이전트를 구축하는 데 도움을 줍니다.
• Agentforce에 대한 자세한 정보는 help.salesforce.com , 특히 에이전트 설게 및 구현 에서 확인하세요. 이 학습 맵은 솔루션 구상, 에이전트 설정 및 구성, 테스트, 배포 및 모니터링부터 모든 주요 수명 주기 단계를 안내합니다.

에이전트 동작을 더 효과적으로 이해하고자 먼저 에이전트와 보다 경직된 모델인 챗봇을 비교해 보겠습니다.

챗봇: 엄격한 규칙 추종

챗봇은 사전에 정해진 결정 트리를 따라 대화에 참여합니다. 이러한 결정 트리의 통과는 사용자가 제공한 답변을 기반으로 합니다. 답변은 사전 결정된 옵션 세트로부터 선택될 수도 있고, 자유 텍스트 답변일 수도 있습니다. 자유 텍스트 답변의 경우 의도 분류에 예측 모델이 사용됩니다. 이러한 트리는 모든 잠재적인 대화 경로를 매핑하고 각 단계에서 챗봇의 응답을 지시합니다. 챗봇의 동작은 사전 설정된 규칙에 따라 엄격하게 결정됩니다. 사용자의 입력이 인식된 경로와 일치하지 않거나 예측 모델이 특정 의도를 인식하도록 훈련되지 않은 경우, 챗봇이 적절하게 응답하지 않습니다.

에이전트: 직관적인 적응형 모델

반면 에이전트는 자연어 처리(NLP)에서 LLM의 강력한 힘과 고급 기능을 활용합니다. LLM을 통해 에이전트는 사용자 입력이 예상치 못한 방식으로 표현된 경우에도 이면의 의도를 알아차릴 수 있습니다. 의도에 대한 이해를 바탕으로 에이전트는 다양한 가능성 중에서 가장 적합한 작업을 선택할 수 있습니다. 에이전트는 완전히 새로운 응답을 공식으로 만들어 내기까지 합니다. 이러한 유연성과 적응성은 에이전트를 챗봇과 차별화합니다.

요리를 활용한 비유

챗봇과 에이전트의 다른 점은 초보 요리사와 숙련된 요리사의 차이에 비유할 수 있습니다.

• 초보 요리사(챗봇)는 정확한 측정, 단계별 명령, 특정 조리 시간이 나와 있는 상세한 레시피에 크게 의존합니다. 레시피를 지키지 못하면 요리를 망칠 수도 있습니다. 마찬가지로 챗봇은 사전 프로그래밍된 결정 트리의 범위 내에서 작동해야 합니다.
• 숙련된 요리사(에이전트)는 수년간의 요리 경험과 직감을 가지고 있습니다. 고객 선호도에 대한 전반적인 이해와 사용 가능한 재료에 대한 간략한 정보를 바탕으로, 고객의 요구를 만족하는 맛있는 식사를 준비할 수 있습니다. 정확한 단계는 매번 다를 수 있으며, 요리를 할 때마다 미묘한 차이가 있을 수 있지만, 전반적인 결과물은 일관되게 만족스럽습니다. 마찬가지로 에이전트는 사용자 입력의 컨텍스트와 의도에 따라 접근 방식을 조정하여 성공적인 상호 작용을 이루어낼 수 있습니다.

요약하자면, 에이전트와 챗봇의 근본적인 차이점은 적응성과 예상치 못한 입력을 처리할 수 있는 능력에 있습니다.

에이전트 인텔리전스의 뚜렷한 특징은 적시에 가장 적합한 작업을 조율하고 트리거하는 능력에 있습니다. 이러한 유연성 덕분에 가능한 사용자 상호 작용을 하나하나 광범위하게 프로그래밍할 필요가 없습니다.

Agentforce에서 에이전트 구축에는 주제, 작업, 자연어 명령 및 설명이 포함됩니다.

주제

주제는 에이전트가 '해야 할 일'입니다. 주제에는 분류 설명, 범위, 명령과 같은 특성이 있어 각 작업과 수행 방법을 정의합니다. 주제에는 에이전트가 실행할 수 있는 작업과 이러한 작업의 실행 방법을 규율하는 명령이 포함되어 있습니다.

조치

작업은 에이전트가 업무를 완수하기 위해 수행할 수 있는 사전 정의된 작업입니다. 작업에는 5가지 유형이 있습니다.

• Apex 코드 실행
• API 호출
• 플로 실행
• 프롬프트 템플릿에 대한 LLM 응답 수신
• 예측 모델 호출

자연어 명령 및 설명

에이전트의 정의에는 에이전트의 자산을 설명하고 에이전트가 작동해야 하는 가이드라인을 정의하는 자연어 명령이 포함되어 있습니다. 명령은 작업 및 주제에 대해 작성됩니다.

• 작업. 작업에는 다음이 포함됩니다.
  • 작업의 기능을 설명하여 추론 엔진에 이 작업을 언제 실행할지 알려주는 명령
  • 에이전트가 준비할 수 있도록 자연어 설명이 포함된 입력
  • 서식을 지정하고 사용하는 방법에 대한 자연어 설명이 포함된 출력
• 주제. 주제에는 상위 수준에서 작업을 실행하는 방법을 규율하는 명령이 포함되어 있습니다. 예를 들어, 명령으로 목소리 톤, 원하는 작업 순서, 가능한 전제 조건, 대화를 사람에게 에스컬레이션해야 하는 시기 등에 대한 가드레일을 지정할 수 있습니다. 주제에는 분류 설명과 범위 설명도 포함되어 있습니다. 에이전트는 이를 통해 정의된 역할의 범위 내에서 업무를 수행할 수 있습니다.
• 데이터. 에이전트가 업무를 성공적으로 수행하려면 데이터가 필요합니다. 데이터는 CRM 데이터와 같이 정형적일 수도, 기업의 기술 문서처럼 비정형적일 수도 있습니다. 에이전트는 작업 입력을 사용하여 데이터에 액세스합니다. 예를 들어, 작업은 CRM 데이터에 기반하거나 검색 증강 생성(RAG) 기술을 사용하여 비정형 데이터 청크로 증강된 프롬프트 템플릿을 호출할 수 있습니다.

이렇듯 다양한 구성 요소를 올바르게 구축하면 에이전트가 적절한 경계 내에서 작동하면서 의도한 목적을 수행하는 데 도움이 됩니다.

Agentforce 추론 엔진은 이러한 구성 요소를 올바른 에이전트 동작으로 조율하며, 주제와 작업에 대해 정의된 자연어 명령과 설명을 활용합니다. 추론 엔진은 2022년에 Yao et al이 도입한 LLM의 새로운 추론 패러다임인 ReAct를 기반으로 구축되었습니다. 이 패러다임은 문제에 대해 추론하고, 조치를 취하고, 작업의 결과를 관찰하고, 작업 완료까지의 주기를 반복하여 사람이 수행하는 작업 관리를 모방합니다.

Salesforce 에이전트는 다음 패러다임을 준수합니다.

1. 추론: 사용자 의도를 파악하고 올바른 주제 및 작업과 일치시킵니다.
2. 행동: 올바른 작업 체인을 시작합니다.
3. 관찰: 사용자 의도에 따라 작업 결과를 평가합니다. 의도가 충족되지 않으면 지금까지 얻은 결과와 주제/작업 명령 및 설명을 바탕으로 판단을 내립니다. 의도가 충족되면 서식 지정 명령을 최대한 준수하면서 최종 응답을 제공합니다.
4. 반복: 최종 지시 단계에 도달할 때까지 단계를 반복합니다.

추론 엔진은 모든 추론 시 LLM을 사용하고 단계를 관찰합니다. 작업 유형에 따라 행동 단계에서 LLM을 사용할 수도 있습니다.

이 섹션에서는 에이전트의 결정론을 개선하기 위한 계층화된 접근 방식을 간략하게 설명합니다. 각 수준은 이전 수준을 기반으로 구축되며, 복잡성과 기능이 갈수록 늘어나 에이전트 동작을 보다 효과적으로 제어할 수 있습니다.

첫 번째 수준에서는 에이전트가 관련 주제를 자율적으로 식별한 다음, 명시적인 명령이 아닌 목표를 사용하여 적절한 작업을 선택할 수 있도록 하는 데 중점을 둡니다. 핵심 메커니즘에는 맥락에 따른 이해를 바탕으로 사용자 입력에 응답하는 것이 포함됩니다. 기술적으로 모든 작업 유형을 추가할 수 있지만, 이 수준에서는 작업이 프롬프트 작업이라고 가정합니다. 프롬프트 작업이 포함된 명령이 필요 없는 주제는 일반적인 쿼리를 빠르고 효율적으로 처리할 수 있는 방법을 제공합니다.

이 수준에서는 동적 이해를 바탕으로 에이전트 응답성과 자율성의 기준 수준을 설정하는 데 중점을 둡니다.

명령이 필요 없는 작업 선택의 토대를 기반으로 구축된 이 수준에는 에이전트 동작을 안내하는 명시적인 명령이 도입됩니다. 정확한 명령을 추가하면 에이전트가 다양한 상황에 대응하는 방식을 더 효과적으로 제어할 수 있습니다. 에이전트에 대한 명령은 규칙, 가이드라인, 가드레일, 예시로 표현 가능합니다. 이를 통해 에이전트는 다양한 주제를 처리하고, 작업을 실행하고, 출력을 처리하는 방법에 대한 구체적인 지침을 얻을 수 있습니다. 이 수준의 목표는 에이전트에 명확한 지침을 제공하여 일관성을 높이고, 기업 가이드라인 및 프로세스 준수를 개선하는 데 있습니다.

그라운딩에는 에이전트의 이해와 응답을 외부 지식 소스에 연결하는 것이 포함됩니다. 그라운딩은 에이전트가 제공하는 정보가 더 정확하고 최신 상태이며 관련성이 높도록 하는 데 도움이 됩니다. 이 수준은 데이터베이스, 기술 자료 및 기타 정보 저장소에 대한 액세스를 통합합니다. 검증된 데이터에 에이전트의 응답을 그라운딩하면 안정성과 신뢰성이 향상됩니다.

이 수준에서는 에이전트가 변수를 사용하여 작업할 수 있는 기능을 추가합니다. 변수를 통해 에이전트는 상호 작용을 개인화하고, 여러 상호 작용에 걸쳐 컨텍스트를 유지하며, 에이전트 세션 중에 유지되는 특정 데이터 포인트에 따라 동작을 동적으로 조정할 수 있습니다. 가령 에이전트는 사용자 선호도, 주문 세부 정보 및 기타 관련 정보를 수집한 후 해당 데이터를 사용하여 상호 작용을 맞춤화할 수 있습니다. 변수를 통해 에이전트는 더 복잡하고, 보다 계획적이고, 한층 개인화된 상호 작용을 효과적으로 처리할 수 있습니다.

이 단계에서는 에이전트를 Salesforce의 핵심 기능인 Apex, API 및 플로와 통합합니다. 통합을 통해 에이전트는 데이터 액세스 및 조작, 워크플로 실행, 다른 시스템과의 상호작용 등 Salesforce 생태계 내에서 복잡한 작업을 수행할 수 있습니다.

• Apex는 프로그래밍 방식 제어를 제공합니다.
• API는 다른 애플리케이션과의 원활한 통합을 지원합니다.
• 플로를 사용하면 복잡한 비즈니스 프로세스를 자동화할 수 있습니다.

이 수준을 통해 에이전트는 정교한 업무를 실행하고 비즈니스 결과에 직접 기여할 수 있는 강력한 도구로 전환됩니다.

수준 5의 기술적 통합을 기반으로, 이 마지막 수준에서는 확률적 AI와 엄격한 비즈니스 로직 간의 간극을 메우기 위해 결정론적 추론을 도입합니다. 이전 수준에서는 어떤 도구를 사용할지 LLM이 결정하도록 했지만, 에이전트 스크립트를 사용하면 추론 과정 자체를 '하드코딩'할 수 있습니다. 문서 형태의 캔버스나 직접 작성한 코드를 활용해 필수 인증 단계, if/else 조건 분기, 강제 주제 전환과 같이 사용자 입력과 관계없이 에이전트가 반드시 따라야 하는 변경 불가능한 경로를 정의할 수 있습니다. 이러한 하이브리드 추론 방식은 LLM의 대화 유연성을 보장된 실행 단계 사이에 배치할 수 있게 합니다. 수준 6은 에이전트를 제로 트러스트 엔터프라이즈급 파트너로 발전시켜, 높은 수준의 규정 준수, 규제 공시, 그리고 복잡한 다단계 의존성을 절대적인 정확성으로 처리할 수 있도록 합니다.

에이전트 응답성과 자율성의 기준부터 시작하여 해당하는 설명과 함께 주제와 작업으로만 구성된 에이전트를 고려합니다. 이 예제 에이전트를 사용하여 추론 엔진의 다양한 단계를 도입하고 이러한 설명을 활용하여 올바른 주제를 선택한 후 실행할 작업을 선택하는 방법을 보여줄 수 있습니다. 이 예제에서 주제 명령을 생략하면 첫 번째 수준의 에이전트는 상위 수준의 에이전트와 비교할 때 가장 자유도가 높다는 점을 확인할 수 있습니다. 수준 1에서 에이전트는 진행 중인 대화만을 바탕으로 적절하다고 판단되는 작업을 자유롭게 선택할 수 있습니다.

추론 엔진에 대한 다음 고려 사항을 검토합니다.

• 추론 엔진의 LLM에 대한 구성 설정이 수정되었습니다. 에이전트 빌더는 이를 변경할 수 없습니다. 현재 에이전트 빌더는 추론을 위해 Salesforce 인프라에서 호스팅되는 OpenAI의 LLM 또는 Anthropic의 LLM 중 하나를 선택할 수 있습니다. 이는 향후 더 많은 모델이 추가됨에 따라 변경될 수 있습니다.
• 추론 엔진 기본 기록: 추론 엔진에 요청이 이루어질 때마다(2~5단계), 가장 최근 요청과 응답 기록을 자동으로 검색합니다. 이 기능은 추론 엔진이 대화 컨텍스트를 유지할 수 있게 합니다. 고객과의 상호작용 외에도, 이 플래너 LLM에 대한 호출에는 주제 선택과 같은 다른 요청을 처리하기 위해 추론 엔진 LLM에 대한 호출이 포함됩니다.

추론 프로세스에는 4가지 주요 단계가 포함됩니다.

1. 주제 선택
2. 작업 선택
3. 에이전트 루프
4. 그라운딩 확인

주제는 에이전트가 올바른 작업 또는 작업 순서를 분류하는 정확성을 개선하도록 설계됩니다. 각 주제는 간결한 주제 설명에 포함될 수 있는 의미론적으로 구별되는 작업들로 이루어져야 하며, 결국 유사한 에이전트 기능에 속해야 합니다.

올바른 주제는 추론 엔진 LLM(다이어그램의 2~3단계)에서 선택합니다. 주제 프롬프트를 사용하여 분류 설명이 마지막 발화와 가장 가까운 주제를 선택합니다. 이 주제 프롬프트에는 모든 주제에 대한 분류 설명과 대화 기록이 포함되어 있습니다. 대화 기록에는 발화 및 에이전트 답변 외에도 실행된 작업과 그 결과가 포함됩니다. 나아가 프롬프트에는 대화 기록의 맥락 내에서 분석을 의무화하는 중요한 명령이 통합되어 있으며, LLM이 사고 프로세스를 공유하도록 요구합니다.

추가 고려 사항:

• '주제 외' 발화를 위한 추가적인 숨겨진 주제가 가시적인 주제와 함께 자동으로 존재합니다. 이 주제는 기존 주제가 발화와 일치하지 않을 때 선택됩니다. 이렇게 하면 에이전트가 오분류를 방지하는 데 도움이 됩니다. 이 주제에는 작업이 없습니다. 추론 엔진이 나중에 적절한 응답을 공식화하는 데 도움을 주기 위해서만 존재합니다.
• 주제 프롬프트에는 주제의 이름과 분류 설명만 사용됩니다.
• 추론 엔진 LLM은 한 번에 하나의 주제만 선택할 수 있습니다.
• 대화의 방향이 예기치 않게 틀어질 수 있습니다. 발화가 수신될 때마다 추론 엔진은 새로운 발화가 있을 때 최신 주제를 선택할 수 있는 주제 선택 단계로 넘어갑니다.

주제의 목적은 2가지입니다.

1. 작업을 그룹화하여 추론 엔진에 혼동을 줄 위험을 줄여 잘못된 작업이 선택되지 않도록 합니다.
2. 명령으로 작업 선택 및 실행을 안내합니다(자세한 내용은 수준 2: 에이전트 제어: 명령 추가에서 확인).

에이전트는 에이전트 기능을 관련 작업으로 이루어진 명확하게 정의된 주제로 신중히 구성하여 더 효과적이고 예측 가능하게 작동하며, 더 쉽게 업데이트하고 확장할 수 있습니다. 주제 설계에는 하향식과 상향식이라는 두 접근 방식이 있습니다.

• 하향식 접근 방식에서는 먼저 에이전트가 수행해야 할 고수준 작업으로 주제를 설계한 후, 해당 주제에 속하는 개별 행동을 정의합니다.
• 상향식 접근 방식에서는 먼저 모든 개별 작업을 정의한 다음 주제로 그룹화합니다.

두 접근 방식 모두 적절하게 따르면 좋은 결과를 가져옵니다.

상향식 접근 방식

이 섹션에서는 상향식 접근 방법을 설명합니다. 상향식 접근 방법이 추론 엔진에서 처음부터 주제를 필요로 하는 이유와 밀접하게 연관되어 있기 때문입니다.

1단계: 모든 에이전트 작업 나열

먼저 에이전트가 수행할 수 있어야 하는 구체적인 작업을 모두 나열합니다. 이 단계에서는 너무 포괄적이기보다는 매우 구체적으로 정하는 편이 더 좋습니다. 작업을 조기에 그룹화하거나 간소화하려 하지 마세요. 에이전트가 할 수 있는 일에 대한 종합적이고 세분화된 보기를 만드는 것이 목표입니다.

예를 들어, 고객 서비스 에이전트의 경우 초기 목록에는 다음이 포함될 수 있습니다.

• 주문 반품: 주문에 대한 반품 프로세스를 시작하는 데 사용합니다.
• 재고 가용성 확인: 제품의 재고가 있는지 확인하는 데 사용합니다.
• 제품 교환 정책 확인: 교환 규칙에 대한 정보를 검색하는 데 사용합니다.
• 지식으로 질문에 답변: 일반적인 질문이나 FAQ 스타일의 질문에 답변하는 데 사용합니다.
• 프로모션 확인: 사용 가능한 프로모션이나 할인을 확인하는 데 사용합니다.
• 배송 날짜 예측: 예상 배송 날짜/시간을 추정하는 데 사용합니다.
• 주문 상태 확인: 고객 주문의 현재 상태를 찾는 데 사용합니다.
• 고객 주문 찾기: 특정 고객의 과거 또는 활성 주문을 모두 검색하는 데 사용합니다.
• 기술 문제 해결: 제품 또는 서비스의 기술적 문제를 해결하는 데 사용합니다.
• 고객 주문 조건 찾기: 주문과 관련된 모든 조건을 검색합니다.
• 고객 자산 찾기: 고객과 관련된 자산을 식별하거나 검색하는 데 사용합니다.
• 배송 주소를 변경합니다.

이 시점에서 '고객 불만 해결'과 같은 작업은 너무 광범위합니다. 작업은 에이전트 동작에서 가장 작은 세분화 수준을 나타내야 합니다. 불만 유형은 다양할 수 있으며, 이미 여러 작업에서 다루고 있습니다.

• 배송 후 문제(예: 손상되거나 오작동하는 제품 문제 해결)는 이미 '기술 문제 해결'에서 다루고 있습니다.
• 배송 전 문제(예: 배송 누락, 배송 날짜 변경 필요, 주문 수정)는 이미 '주문 상태 확인', '배송 날짜 예측' 또는 '주문 반품'과 같은 작업에서 다루고 있습니다.
• 정책 문의와 같은 일반적인 고객 우려 사항은 이미 '지식으로 질문에 답변' 또는 '제품 교환 정책 확인'에서 다루고 있습니다.

2단계: 추론 혼동을 일으킬 수 있는 작업 쌍 하나 이상 표시

추론 엔진에 혼동을 일으킬 수 있으므로, 본질적으로 유사한 작업을 표시합니다. 설명이 의미론적으로 충분히 다르지 않으면 추론 엔진이 5단계에서 어떤 작업을 선택해야 할지 알지 못합니다.

예를 들어, '기술 문제 해결'과 '지식으로 질문에 답변'은 비슷한 설명을 가지고 있지만, 기능은 크게 다를 수 있습니다. 이러한 의미론적 중복을 표시하면 여러 주제에 걸쳐 구분할 작업을 식별하는 데 도움이 됩니다.

3단계: 작업의 초기 그룹화를 주제로 생성

작업이 명확하게 정의되고 의미론적 중복이 식별되면 작업을 예비 주제로 그룹화할 수 있습니다. 주제는 기능의 논리적 범주, 즉 에이전트의 일관된 기능이나 기술을 나타내는 작업을 그룹화한 것입니다.

그룹화할 경우 다음에 유의하세요.

• 필요한 최소 주제 수를 사용하여 의미론적 중복을 방지합니다.
• 각 주제에 의미 있는 관련 작업이 포함되어 있는지 확인합니다.
• 체인에서 실행해야 하는 지원 작업이 동일한 주제에 있는지 확인합니다.

고객 서비스 에이전트를 위한 초기 그룹화의 예는 다음과 같습니다.

주제 1:

• 주문 반품
• 재고 가용성 확인
• 제품 교환 정책 확인
• 프로모션 확인
• 배송 날짜 예측
• 고객 주문 조건 찾기
• 주문 상태 확인
• 고객 주문 찾기
• 고객 자산 찾기
• 지식으로 질문에 답변
• 배송 주소 변경

주제 2:

• 기술 문제 해결
• 고객 자산 찾기

4단계: 주제에 대한 분류 설명을 작성하고 필요한 경우 주제를 세분화합니다.

초기 그룹화가 완료되면 각 주제에 대한 분류 설명을 작성합니다.

• 이 예제의 주제 2는 제품의 기술적 문제에 관한 것입니다.
• 하지만 주제 1은 더 넓은 범위를 다룹니다. 주로 주문 관리와 관련이 있지만, 프로모션 확인이나 지식으로 질문에 답변 등 주문 관리와 관련이 없는 일부 작업도 포함되어 있습니다. 주제 1은 한 문장으로 명확하고 간결하게 설명할 수 없으므로, 주제를 여러 주제로 나누어야 합니다.

나누고 나면 다음과 같은 결과를 얻을 수 있습니다.

• 주제 1: 주문 관리: 교환 및 반품과 관련된 작업을 제외한 고객 주문과 관련 물류의 관리 및 수정과 연관이 있는 작업을 설명합니다.
  • 재고 가용성 확인: 제품의 재고가 있는지 확인합니다.
  • 배송 날짜 예측: 주문이 언제 도착할지 예측합니다.
  • 주문 상태 확인: 고객 주문 상태를 찾습니다.
  • 고객 주문 찾기: 고객이 발주한 모든 주문을 검색합니다.
  • 배송 주소를 변경합니다.
• 주제 2: 문제 해결
  • 고객 자산 찾기: 고객의 등록된 디바이스 또는 제품을 검색합니다.
  • 기술 문제 해결: 기술 지원 또는 진단을 제공합니다.
• 주제 3: 교환: 주문 교환 및 반품과 관련된 작업을 설명합니다.
  • 주문 반품: 주문 반품 프로세스를 시작합니다.
  • 제품 교환 정책 확인: 제품의 교환 규칙을 제공합니다.
  • 고객 주문 찾기: 고객이 발주한 모든 주문을 검색합니다.
  • 고객 주문 조건 찾기: 주문과 관련된 모든 조건을 검색합니다.
• 주제 4: 제품 지원: 정보 검색 및 라우팅에 사용되는 교차 작업을 설명합니다.
  • 지식으로 질문에 답변: 기술 자료 정보를 사용하여 일반적인 고객 문의에 응답합니다.
  • 프로모션 확인: 현재 진행 중인 프로모션 또는 할인을 확인합니다.

요약하자면, 먼저 가능한 모든 작업의 종합적인 목록을 만든 후 작업 간의 의미론적 중복을 표시합니다. 그다음, 최소한 모든 의미론적 중복을 해소하는 일련의 주제를 생성하여 추론 엔진이 한 주제의 범위 내에서 혼동하지 않도록 합니다. 그런 다음 모든 주제의 분류 설명을 작성합니다. 주제의 범위가 너무 넓은 경우 더 세분화된 주제로 나눕니다. 이 지침을 구현하면 성능이 좋을 뿐만 아니라 유지 관리 및 확장이 용이한 에이전트를 구축할 수 있습니다.

이 구조는 에이전트의 동작 내에서 더 나은 추론, 더 정확한 실행, 더 명확한 결정 경계를 지원합니다. 나아가 설계자, 엔지니어, 분야별 전문가 간의 협업에 의존하여 에이전트의 기능을 더 투명하게 만들고 모듈화합니다.

효과적인 주제 생성을 위한 추가 고려 사항

• 최적의 주제 수: 올바른 주제를 분류할 때 LLM의 성능을 개선하려면 일반적으로 10개의 주제를 초과하지 않는 것이 좋습니다. 하지만 이는 어림짐작일 뿐입니다. 또한, 각 주제에 명확하고 뚜렷한 설명이 있어야 합니다. 궁극적으로 최적의 주제 수는 주제 분류 설명 간의 의미론적 간격에 따라 달라집니다. 주제 간에 분류 설명이 크게 다른 경우, 주제 중복의 위험을 최소화할 수 있습니다. 주제 간 중복을 방지할 수 있는 더 많은 모범 사례는 여기 에서 확인하세요.
• 주제 크기와 명확성의 균형: 일반적으로 주제가 사소할수록 작업과 명령 측면에서 분류가 더 쉬워지지만, 비슷한 설명으로 주제를 너무 많이 생성하면 작업 간에 의미론적 중첩이 오분류를 초래하는 등 혼란이 발생할 수 있습니다. 따라서 의미론적으로 명확하게 차별화된 주제 설명을 지정하는 것이 중요합니다. LLM을 사용하여 효과적으로 차별화된 분류를 생성할 수 있습니다.
• 표준 언어 및 컨텍스트 명확성: LLM은 특정 기업 또는 비즈니스적 의미와 약어를 인식하지 못할 수 있습니다. 표준어를 사용하거나 특정 문맥에서 단어의 의미를 명확하게 설명해야 합니다.
• 주제 프롬프트에는 주제 이름과 설명만 전송됩니다. 따라서 주제의 범위나 명령을 변경해도 주제 선택에 영향을 주지 않습니다.

사례 연습

서비스 에이전트가 시계에 대한 보증 정책 요청을 받았다고 상상해 보세요. 보증 문제가 제품 교환 또는 지원과는 관련이 없는 것 같고, 이 요청을 처리하기에는 주문 관리가 가장 적합한 주제인 듯합니다. 따라서 추론 엔진에서 요청을 이행할 가능성이 가장 높은 주제로 후자를 선택합니다.

주제를 선택한 후 추론 엔진이 선택한 주제에서 실행할 올바른 작업을 고릅니다. 다시 말하지만, 추론 엔진 LLM이 관찰 프롬프트라는 또 다른 프롬프트를 사용하여 이를 처리합니다. 관찰 프롬프트의 목적은 추론 프로세스의 다음 단계를 확보하는 것입니다. 다음 단계는 아래 중 하나일 수 있습니다.

• 작업 시작
• 사용자로부터 작업 입력 요청
• 사용자의 요청에 대한 명확한 설명 요청
• 작업 루프가 완료된 후 사용자에게 최종 답변 전송(사용자 요청 이행)(3단계 추론에서 자세한 내용 참조)

관찰 프롬프트에 대한 입력은 대화 기록과 주제의 작업 전체에 대한 모든 설명으로 구성됩니다.

행동 설계를 위한 모범 사례

작업은 에이전트가 업무를 완수하기 위해 수행할 수 있는 사전 정의된 작업입니다. 작업은 업무에 대한 가장 세밀한 정의입니다. 에이전트 작업에는 (1) Apex 코드 실행, (2) API 호출, (3) 플로 실행, (4) 프롬프트 템플릿에 대한 LLM 응답 수신, (5) 예측 모델 호출이라는 5가지 유형이 있습니다. 이러한 작업의 대부분은 결정론적일 수 있습니다. 예외는 프롬프트 템플릿에 대한 응답을 받는 것입니다(외부 시스템인 플로 또는 Apex 작업에 프롬프트 호출 등의 확률적 요소가 포함되어 있지 않은 경우에만 해당). 이러한 문제는 에이전트 제어의 다섯 번째 수준에서 다룰 예정입니다.

1. 프롬프트 행동에서 에이전트 기반 행동 제어: 프롬프트 작업에서 에이전트의 동작을 제어하는 방법에는 2가지가 있습니다. (1) 프롬프트 엔지니어링을 통해 프롬프트 템플릿에 명령을 더 추가하는 방법과 (2) 프롬프트 응답, 특히 온도를 생성하는 LLM의 하이퍼 매개 변수를 구성하는 방법입니다(문서 참조). 온도를 낮추면 생성된 응답의 변동성이 감소하여 응답의 재현성과 에이전트 신뢰성이 향상됩니다.
2. 단일 주제 내에서 최적의 작업 수: 최대 주제 수와 마찬가지로 주제 내 작업 수는 10개를 초과하지 않아야 합니다. 다시 말하지만, 이는 경험에 비추어 본 수치일뿐 실제 동인은 작업 간의 의미론적 간격입니다. 작업이 설명으로 명확하게 구별될 수 있다면 수치는 더 커질 수 있습니다. 하지만 의미론적 간격은 숫자로 측정할 수 없으며, 이는 에이전트 빌더의 해석에 달려 있습니다. 작업 설명 간의 의미적 차이가 클수록 의미론적 간격이 넓어집니다. 중복은 절대로 피해야 합니다.
3. 작업 설명: 이름과는 달리, '작업 명령'은 실제로 추론 엔진 LLM이 주제에서 올바른 작업을 선택하기 위해 사용하는 명령 역할을 합니다. 의미론적으로 고유한 작업 설명을 사용하면 분류의 품질을 크게 개선할 수 있습니다. 이 설명을 주의 깊게 검토하고, 특히 동일한 주제에 속하는 모든 행동 설명을 비교하세요.

사례 연습

서비스 에이전트가 시계에 대한 보증 정책 관련 질문을 받은 이전 예제로 계속 진행해 보겠습니다. 주문 관리 주제를 고르면 가장 가능성이 높은 작업이 선택됩니다. 주문 관리에 관한 주제이므로, 첫 번째 논리적 단계는 주문 조회 작업을 실행하여 주문을 조회하는 것입니다(그렇지 않은 경우 보증 정보를 확인하려는 이유가 무엇인지 확인).

사용자 발화는 답변이 사용자에게 다시 전송되기 전에 여러 작업의 실행을 트리거할 수 있습니다. 이는 에이전트 루프 때문인데, 에이전트 루프는 아래의 조건 중 하나가 충족될 때까지 다음으로 가장 적합한 작업을 선택하고 실행합니다.

• 추론 엔진 LLM이 요청이 완료되었음을 확인합니다. 이 경우 사용자 요청이 응답으로 처리되었음이 확인됩니다. 여기에는 응답이 작업 출력에서 그라운딩되었는지 살펴보는 그라운딩 확인이 포함됩니다. 응답에는 추론 엔진 LLM에서 창조된 정보가 없어야 합니다. 이런 정보가 포함되면 환각이나 잘못된 응답을 초래할 수 있습니다.
• 더 이상 적합한 작업을 찾을 수 없습니다.
• 현재 단계에 허용되는 최대 LLM 호출 수에 도달했습니다. 이 수치는 추론 엔진 자체에서 설정됩니다.

작업에는 특정 시간 초과가 적용되지 않습니다. 이는 복잡성에 따라 작업 실행 시간이 달라질 때 중단을 방지하기 위함입니다. 어떤 작업은 다른 작업보다 실행하기가 더 복잡합니다.

사례 연습

주문 조회를 시작한 후 추론 엔진은 지금까지 생성된 응답을 평가한 다음, 사용자에게 응답을 다시 전송하기 전에 추가 작업을 수행해야 한다고 판단합니다. 이제 대화 기록에 주문이 표시되므로, 보증 정책을 확인하려고 합니다.

그러나 이 과정에서 에이전트는 '주문 조회' 작업을 통해 고객이 실제로 시계 2개를 구매했음을 알게 됩니다. 따라서 에이전트 루프에서 추론 엔진은 고객에게 보증 정보가 필요한 시계가 무엇인지 지정해 달라고 요청하기로 합니다.

과도한 스크립트화 지양

에이전트가 사용자와 대화하는 방식을 과도하게 스크립팅하지 않도록 합니다. 초과 스크립팅은 에이전트가 관계를 구축하고, 고유한 사용자 요구 사항을 이해하고, 역동적인 상황에 효과적으로 실시간 대응하는 능력을 저해할 수 있습니다. 또한, 명령이 길어지면 에이전트의 응답 속도가 느려지고 추론 엔진에 혼동이 발생할 수 있습니다. 명령을 통해 결정론을 강제하는 것은 권장되는 접근 방식이 아닙니다.

하지 말아야 할 일

예를 들어, 에이전트를 대상으로 서비스 답변에서 경쟁사를 언급하지 말라고 지시할 필요는 없습니다. 이는 원치 않는 동작으로 이어질 수 있는데, 에이전트가 경쟁사인 제공업체와의 통합과 관련된 질문에 답변하지 않을 수도 있습니다. 이 대신, '경쟁사 관련 논의에서는 회사의 최대 이익을 고려하여 응답할 것'이라는 명령을 사용할 수 있습니다. 이렇게 하면 '...인 경우에만 경쟁사 xyz 언급'과 같은 제한적인 조건부 명령을 방지하고, 대신 LLM의 추론 기능을 활용하게 됩니다. 이 예제는 사람인 서비스 직원이 회사에 입사한 후 교육을 받는 방식과 유사하게 더 높은 추상적인 수준에서 명령을 제시하는 방법을 보여줍니다.

하지 말아야 할 일의 몇 가지 예를 더 살펴보겠습니다. 다음은 채용 웹사이트에서 지원자 프로필을 처리하는 서비스 에이전트를 대상으로 제공되는 몇 가지 잘못된 명령입니다. 이러한 명령은 가능한 모든 고객의 발화를 예측하려고 시도하므로, 피하는 것이 좋습니다.

명령 1: 에이전트가 다음과 같은 발화를 수신합니다. "제 프로필에 사진을 추가할 수 있나요?" 그런 다음 즉시 고객에게 "프로필 유형이 무엇인가요?"라고 묻습니다.

명령 2: 지원자가 프리미엄 프로필이라고 언급한 경우 "계약 세부 정보를 확인해 보겠습니다"라고 답한 후 계약 세부 정보를 검색하고 프로필 사진을 업데이트하는 데 동의했는지 확인합니다.

지원자가 이에 동의했다면 "예, 제가 대신 업데이트해 드릴 수 있습니다. 새로운 사진을 제공하시겠어요?”라고 대답합니다. 사진을 받으면 그에 따라 지원자의 프로필을 업데이트합니다. 계약 내용에 프로필 사진 변경이 포함되지 않은 경우 "죄송합니다. 작업을 처리할 수 없습니다. 사람 에이전트에게 연결해 드리겠습니다"라고 답합니다.

명령 3: 프리미엄이 아닌 프로필: 고객의 프로필이 프리미엄 프로필이 아닌 경우 "사진을 업데이트할 수 없습니다. 원하신다면 사람 에이전트에게 연결해 드리겠습니다"라고 응답합니다.

명령 4: 프로필 유형이 명확하지 않은 경우 "프로필 유형을 알 수 없습니다"라고 응답합니다.

대신 해야 할 일

세세한 것까지 전부 관리하는 대신, 에이전트의 동작과 행동을 지시하는 보다 유연한 접근 방식을 사용합니다. 다음 모범 사례를 고려하세요.

1. 기술 문서에 포함된 정책 및 규칙에 대해서는 명령으로 작성하지 말고 검색 증강 생성(RAG)/지식 작업을 사용하세요. 관련 정보가 적시에 검색됩니다. 위 예제에서, '사진 업데이트'라는 제목의 기술 문서에 다음과 같이 명시합니다. "계약 내용에서 사진 변경을 허용하는 프리미엄 프로필을 보유한 지원자만 사진을 업데이트할 수 있습니다."
2. 대화와 별개로 주요 지침과 가드레일을 개별적으로 요약합니다. 에이전트를 대상으로 문제의 예상 동작이나 절차에 대한 설명을 명확하고 간결하게 제공합니다.

이러한 모범 사례를 따른 더 나은 명령은 다음과 같을 수 있습니다.

명령 1 : “계정 변경 요청이 있을 경우 지식 작업을 사용하여 정책을 확인합니다.”

명령 2 : “관련 정책을 찾을 수 없는 질문에는 답변하지 않습니다.”

위의 지침을 적용하면 에이전트 결과를 개선할 수 있습니다. 이제 고객이 에이전트에 프로필 변경을 요청하면 에이전트는 기술 자료에서 필요한 정책을 검색하고, 검색된 규칙을 해석하고, 해당 규칙을 컨텍스트에 적용하고, 마지막으로 고객에게 응답해야 한다는 것을 이해하게 됩니다. 초과 스크립팅과 달리, 이러한 동작 접근 방식은 훨씬 더 일반적이고 광범위하게 적용 가능합니다. 에이전트는 가능한 모든 대화를 작성하지 않고도 더 광범위한 대화 주제에 원하는 동작으로 유연하게 대응할 수 있게 됩니다.

작업 시퀀스 적용(에이전트 스크립트에는 해당되지 않음)

관찰 지침에는 지침과 행동 설명이 포함되어 있지만, 순서가 정해져 있지는 않습니다. 작업의 순서가 중요할 때는 해당 지침 내에 명시적으로 기재해야 합니다. 에이전트 스크립트를 사용하는 경우에는 전환을 통해 실행 순서를 적용할 수 있습니다. 이에 대해서는 여섯 번째 장에서 자세히 설명합니다.

채용 웹사이트 에이전트의 예를 계속 살펴보겠습니다. 에이전트는 적절한 면접관을 배정하여 면접 계획을 처리할 수 있어야 합니다. 그러려면 먼저 채용 담당자의 참여 가능 여부를 확인한 다음 지원자에게 가능한 3가지 옵션을 제안해야 합니다.

이 경우 실행 순서를 유지하려면 명령이 개별 상자에 있어서는 안 됩니다.

1. 명령 1: 면접관의 참여 가능 여부를 확인합니다.
2. 명령 2: 그런 다음 지원자에게 적절한 옵션을 제안합니다.

이 지침은 작동하지 않습니다. 추론 엔진이 지침 2의 '그에 따라'가 무엇을 가리키는지 모르기 때문입니다. 이는 지침이 추론 엔진에 특정한 순서 없이 그룹으로 전송되기 때문입니다.

이 대신 순서 정의 명령을 하나의 문으로 결합하고 다음과 같이 작성해야 합니다.

1. 명령 1: 면접관의 참여 가능 여부를 확인합니다. 그런 다음 지원자에게 적절한 옵션을 제안합니다.

재작성 없이 행동 출력을 강제 적용

추론 엔진은 그 자체로 LLM입니다. 에이전트 루프에 따라 최종 답변을 생성하는 역할을 합니다. 이 접근 방식은 응답 생성에 가드레일을 제공하는 에이전트 명령을 시행하거나 에이전트 루프의 일부였던 여러 작업의 출력을 결합하여 사용자 요청을 이행하는 데 필요합니다.

하지만 하나의 프롬프트 작업만 실행되었을 것으로 예상되는 경우, 에이전트에 작업 출력을 절대 변경하지 않도록 지시하는 명령을 내릴 수 있습니다. 이렇게 하면 에이전트 동작이 더 예측 가능하고 안정적으로 이루어집니다.

승인된 프롬프트 템플릿에 이러한 엄격한 준수를 적용하는 것은 특정 상황, 특히 일관성, 규정 준수 및 사전 정의된 메시지가 중요한 경우에 필수적입니다. 2가지 예는 다음과 같습니다.

• 규제 대상 산업: 규제가 엄격한 분야(예: 금융, 의료, 법률)에서 운영되는 조직은 모든 고객 응대 커뮤니케이션을 엄격하게 제어해야 하는 경우가 많습니다. 승인된 프롬프트 템플릿은 응답이 법률 및 규제 요건을 준수하도록 보장하여 잘못된 해석, 책임 또는 부정확한 정보의 유포 위험을 최소화합니다.
• 사전 테스트 및 검증된 응답: 프롬프트 템플릿이 정확성, 효율성 및 원하는 결과를 보장하기 위해 엄격한 테스트와 검증을 거친 경우로, 이러한 템플릿에서 벗어나면 그 효율성과 가치가 떨어질 수 있습니다. 엄격한 준수는 입증된 메시지가 일관되게 전달되도록 보장합니다.

이 명령은 에이전트가 작업의 출력을 변경할 수 있는 자유를 제한합니다. 이 플랜 트레이서에 나와 있는 대로 명령이 프롬프트 템플릿의 출력(예: 'promptResponse')을 참조하는지 확인하세요.

따라서 이 경우의 명령은 다음과 같을 수 있습니다.

“ 에이전트의 채널에 관계없이 promptResponse 출력을 변경하지 않습니다. ”

엄격한 준수의 강제 적용에 대한 제한 사항:

상호 작용에 여러 개의 개별 에이전트 작업이 필요한 경우 단일 템플릿에 대해 엄격한 준수를 적용하기란 불가능합니다. 실제로 이러한 상황에서는 추론 엔진이 관련 작업을 단일 응답으로 통합하여 모든 단일 작업 출력을 변경해야 합니다.

최적의 지침 수

일반적인 LLM 특성을 바탕으로 대상 명령 수는 명령 복잡성과 명령 상호 작용에 따라 5개에서 10개 사이입니다. 이러한 명령 특성은 추론 엔진이 따를 수 있는 명령 수에 영향을 미칩니다.

• 명확성 및 구체성: 잘 정의된 규칙은 따르기가 더 쉽습니다.
• 규칙 간 충돌: 규칙이 서로 모순되는 경우 이를 해결하기 위해 추가 논리가 필요합니다.
• 길이 및 복잡성: 각 규칙에 심층적인 추론이 필요한 경우, 더 세분화된 명령으로 나누는 것을 고려하세요.

명령을 명시적으로 따르는 것이 매우 중요한 경우, 그 중요성을 반영하는 용어를 추가합니다.

• 긴급성 및 중요성(즉시, 긴급, 중요, 필수, 의무)
• 권한 및 실행(필수, 의무, 엄격하게 실행)
• 결과 및 경고(위반은 다음을 초래할 수 있음, 준수하지 않을 경우 다음을 초래할 수 있음, 미준수는 다음을 초래할 수 있음, 엄격한 처벌 적용, 무관용)
• 명확성 및 직접성(금지 필수, 금지, 허용 불가, 항상/절대)

데이터에 그라운딩된 답변은 에이전트의 신뢰성과 신뢰도를 크게 향상시킵니다. 그라운딩된 답변은 추측이나 너무 오래된 지식이 아니라 사실에 기반을 둡니다. 검색 증강 생성(Retrieval Augmented Generation, RAG)은 에이전트가 기술 자료에 접근하고 이를 활용하여 더 정확하고 컨텍스트에 맞는 답변을 생성할 수 있도록 하기 위해 널리 사용되는 기술입니다. 사용자의 쿼리를 기반으로 에이전트는 RAG를 사용하여 적용 가능한 데이터 출처에서 관련 정보를 검색한 다음 이 정보를 프롬프트에 추가하여 대규모 언어 모델(LLM)에 제출합니다. RAG를 사용하는 에이전트는 에이전트 상호작용의 품질, 정확성 및 전반적인 유용성이 향상되어 사용자의 신뢰도와 만족도가 증가합니다. RAG 모범 사례는 공개적으로 이용할 수 있는 백서 Agentforce와 검색 증강 생성(RAG): 더 나은 에이전트를 위한 모범 사례에 자세히 설명되어 있습니다.

지식과 지침 비교

지식과 명령의 구분은 지침과 유연성 사이의 적절한 균형을 맞추는 데 중요합니다. 이는 지식과 명령이 서로 다른 목적을 이행하기 때문입니다.

• 지식: 지식은 에이전트가 답변을 생성하면서 액세스할 수 있는 도서관이라고 생각하면 됩니다. 문서, 기술 자료, 백서 등이 그 예입니다. 여기에는 정책 및 일반 회사 규칙이 포함될 수 있습니다. 지식은 이메일, 통화 스크립트, (에이전트) 대화 기록과 같은 거래 파일도 참조할 수 있습니다. 마지막으로 지식에는 정형 데이터 형식의 긴 텍스트 필드가 포함됩니다. 지식은 일반적으로 검색 증강 생성(RAG)을 통해 에이전트에 전달됩니다.
• 명령: 명령은 에이전트에 각 작업을 언제 사용해야 하는지 명확히 알려주는 최소 규칙 집합이라고 생각하면 됩니다. 명령은 또한 필요한 어조와 같은 가드레일을 전체 대화에 할당할 수 있습니다. 명확성이나 의도를 그대로 살리면서 명령을 더 간결하고 유연하게 만들 수 있는 경우가 많습니다. 가능한 모든 고객 시나리오에 대해 구체적인 응답이 포함된 엄격한 스크립트를 제공하는 대신, 에이전트가 다양한 상황에서 적합한 작업을 선택하는 데 도움이 되는 일반적인 지침과 원칙을 구현하는 것을 고려하세요.

검색 증강 생성

검색 증강 생성(RAG)은 지식을 위한 지능형 데이터 계층 역할을 합니다. 다양한 형식의 정보에 액세스할 권한을 에이전트에 부여하며 질문에 답변하기 위한 관련 텍스트 조각을 제공합니다. 검색 증강 생성(RAG)을 사용하면 에이전트가 불필요한 콘텐츠로 LLM 프롬프트에 과부하를 주거나 컨텍스트 창에 너무 많은 정보를 제공하지 않고도 더 정확한 LLM 응답을 얻을 수 있습니다.

런타임 시 검색 증강 생성(RAG)은 다음 세 단계를 실행합니다.

1. 검색: AI 시스템은 대규모 데이터베이스 또는 지식 소스를 검색하여 LLM 프롬프트에 대한 관련 정보를 수집합니다. 이는 기존 키워드 기반 검색에 비해 더 정교한 기술인 시맨틱 검색을 사용하여 수행됩니다. 정확한 용어와 일치시키는 키워드 검색과 달리 시맨틱 검색은 단어 이면에 숨겨진 의미나 맥락을 이해합니다. 정확하게 일치하는 단어를 찾기보다는 용어 간의 개념이나 관계를 기반으로 관련 정보를 식별합니다. 키워드 검색은 이 검색 프로세스에서도 중요한 역할을 하여 특정 용어나 이름과 일치하는 키워드로 시맨틱 검색을 강화합니다. 이 검색 유형을 하이브리드 검색이라고 합니다.
2. 증강: 검색된 정보가 프롬프트에 추가됩니다.
3. 생성: LLM은 검색된 지식으로 증강된 프롬프트 덕분에 상황에 맞는 적절하고 보다 정확한 응답을 생성합니다.

Agentforce에서 검색 증강 생성(RAG)은 프롬프트 템플릿과 함께 또는 독자적으로 사용할 수 있습니다.

1. 프롬프트 기반 검색 증강 생성(RAG): 이 접근 방식에서 응답을 생성하는 방법을 지정하는 명령은 프롬프트 템플릿의 프롬프트 명령에 있습니다. 이 경우 응답은 전적으로 LLM이 생성하는 내용에 좌우됩니다. 프롬프트 명령 외에도 Einstein Studio의 LLM 구성 설정처럼 응답에 영향을 미치는 방법이 있지만, 이로 인한 결과는 여전히 결정적이지 않습니다.
2. 추론 엔진 기반 검색 증강 생성(RAG): 에이전트는 프롬프트 템플릿을 사용하지 않고 플로 또는 Apex 클래스를 통해 청크를 검색하여 변수에 저장하는 작업을 사용합니다(다음 섹션 참조). 이 접근 방식에서는 추론 엔진이 LLM 대신 검색된 데이터를 기반으로 직접 답변을 생성합니다. 응답 생성을 제어하는 명령은 프롬프트 템플릿 명령이 아니라 에이전트 명령입니다. 검색된 콘텐츠를 보유하는 변수는 계속해서 작업에 대한 입력으로 명시적으로 전달될 수 있습니다. 변수의 콘텐츠에 대한 기본 액세스 권한을 부여하여 추론 엔진에 제공할 수도 있습니다. 이 접근 방식에는 단점이 있습니다. 콘텐츠와 책임으로 추론 엔진에 과부하를 줄 수 있는 잠재적인 위험이 있습니다. 게다가 프롬프트와 달리 추론 엔진의 LLM 매개 변수는 구성할 수 없습니다. 반면, 추론 엔진은 검색된 청크와 대화 기록을 모두 사용하여 답변을 생성할 수 있습니다.

권장 방법은 옵션 1입니다. 이 방법은 추론 엔진이 수행해야 하는 작업 수를 줄여 답변 품질을 개선합니다. 다음 섹션에서는 이 규칙의 예외를 살펴봅니다. 이 규칙에서는 콘텐츠가 대화 내내 보존되므로, 작업에 명시적으로 제공됩니다.

검색 증강 생성(RAG) 모범 사례

• 스크립팅된 검색 증강 생성(RAG) 지침 방지: 구체적인 질문에 대해 특정 문서에 직접 명령을 연결하는 대신, 검색 증강 생성(RAG)의 인텔리전스를 활용하여 가장 관련성 높은 데이터 소스와 정확한 텍스트 조각을 동적으로 찾을 수 있습니다. RAG의 일치 프로세스는 질문과 출처 간의 정확한 매핑이 아닌 질문에 대한 더 넓은 이해를 기반으로 합니다.
• 주제 통합: 관련 질문 범주를 단일 주제로 그룹화합니다. 검색 증강 생성(RAG)은 더 넓은 주제 내에서도 질문 유형에 따라 관련 답변을 효과적으로 식별할 수 있습니다. 예를 들어, 유지보수나 배터리 문제와 같은 제품 문제는 더 포괄적인 주제로 통합될 수 있습니다.
• 변수에 검색 증강 생성(RAG) 출력 저장: 상호 작용 제한 수에 도달하면 검색 증강 생성(RAG) 출력을 변수에 저장합니다. 이렇게 하면 표준 임계값을 넘어 에이전트 상호 작용을 안내할 수 있는 정보에 액세스할 수 있습니다. 다음 섹션에서 예시를 살펴보겠습니다.

특정 비즈니스 프로세스에는 구체적인 작업 순서나 조건을 적용하여 작업이나 주제를 트리거하는 등 훨씬 더 예측 가능한 실행이 필요합니다.

이러한 결정론적 동작을 달성하는 데 변수를 사용할 수 있습니다. 변수는 작업 입력 또는 출력 역할을 할 수 있는 단기 에이전트 메모리의 구조화된 형태로 작동합니다. 또한, 변수의 상태는 특정 주제와 작업의 트리거를 제어할 수 있습니다.

변수가 결정을 지원하는 방법

변수는 다음과 같은 방식으로 에이전트의 안내형 결정론을 달성하는 데 도움이 될 수 있습니다.

1. 지속적인 동적 그라운딩: 변수를 통해 에이전트는 후속 상호 작용의 영향을 받지 않는 중요한 정보를 유지하면서 세계에 대한 이해를 지속적으로 업데이트할 수 있습니다. 이 방법을 사용하면 검색 증강 생성(RAG)을 통해 검색되는 비정형 데이터 또는 사용자 프로필 정보 등의 정형 데이터일 수 있는 중요한 정보가 대화 길이에 관계없이 대화 전반에 걸쳐 유지됩니다.
2. 작업 입력/출력: 변수는 작업의 입력과 출력으로 모두 사용할 수 있습니다. 작업은 명시적으로 변수를 참조하며, 작업의 실행은 이러한 입력과 출력을 설정하는 추론 엔진에 의존하지 않으므로 에이전트의 결정성을 높입니다.
3. 필터링: 변수는 작업 또는 주제의 조건부 실행을 결정하는 데 사용할 수 있습니다. 변수는 작업 실행에서 작업과 결정성 간의 특정 정보 플로를 허용합니다. 이 기능은 이메일처럼 특정 입력 변수가 검증되지 않은 경우 작업을 시작할 수 없는 보안 규칙에 특히 중요합니다.

Agentforce의 변수 유형

Agentforce에는 2가지 유형의 변수가 있습니다.

• 컨텍스트 변수는 사용자 및 대화 세션에 대한 정보를 저장하는 시스템 생성 변수입니다.
• 사용자 지정 변수는 사용자가 인스턴스화할 수 있습니다. 변수가 결정론을 지원하는 3가지 방법 중 하나에 사용되는 모든 종류의 정보를 보유합니다.

변수 유형은 다음 기능을 지원합니다.

고객 응대 문제 해결 에이전트라는 사용 사례를 통해 변수를 더 자세히 살펴보겠습니다. 이 예제에서는 변수가 지속적인 동적 그라운딩, 작업 입력/출력, 필터링의 3가지 목적 모두에 사용됩니다.

이 예제에서는 에이전트가 고객이 기술 디바이스 문제를 해결하는 데 도움을 줍니다. 문제를 해결하려면 일반적으로 여러 단계를 거쳐야 합니다. 에이전트는 사람 서비스 에이전트의 업무를 모방한 서비스 경험을 제공해야 합니다. 이렇게 하려면 에이전트가 고객에게 모든 문제 해결 단계를 한꺼번에 제공해서는 안 됩니다. 대신 단계별 지침과 함께 고객이 응답하는 방식에 따라 앞서 다룬 단계로 돌아가기도 하며 단계를 넘나들 수 있어야 합니다.

이를 달성하기 위한 한 가지 과제는 대화 내내 모든 문제 해결 단계를 유지할 수 있는 에이전트의 능력입니다. 저장할 수 있는 상호 작용 수가 제한되어 에이전트의 메모리에 제약이 있으므로, 대화가 길어지면 추론 엔진의 컨텍스트에서 이러한 단계가 제외될 수 있습니다.

이 과제를 해결하려면 변수를 사용하여 문제 해결 단계 전반에 걸쳐 추론 엔진을 동적으로 그라운딩하면 됩니다. 정보를 검색하고 변수에 저장하면 대화 내내 사용 가능한 상태로 유지되며 업데이트할 수 있습니다. 추론 엔진은 이 변수에 저장된 정보를 사용하여 동적 그라운딩을 수행합니다.

이 예제에서는 주제에 2가지 작업이 포함되어 있는데, 일관된 데이터 플로를 유지하려면 두 작업이 모두 필요합니다. 첫 번째 작업은 모든 문제 해결 단계를 포함하는 변수를 채우는 데 사용됩니다. 두 번째 작업은 문제 해결 과정 중에 해당 변수를 활용합니다.

1. 작업 1: '문제 해결 입력 단계'. 에이전트가 문제를 처음 접했을 때 트리거되는 초기 작업입니다. 에이전트는 검색 증강 생성(RAG)을 사용하여 색인화된 기술 자료에서 필요한 모든 해결 단계를 추출합니다. 작업은 결과 출력을 '해결 단계'라는 변수에 저장합니다.
2. 작업 2: '문제 해결 도중에 사용'. 이는 문제 해결 프로세스 중에 사용할 가능성이 가장 높은 다음 문제 해결 단계를 출력하는 프롬프트에 기반한 작업입니다. 에이전트는 문제를 해결하는 동안 이 작업을 사용하라는 지시를 받습니다.

원래 고객 질문은 두 작업에 모두 입력됩니다. 두 번째 작업에는 '해결 단계' 변수의 내용이라는 또 다른 입력이 있는데, 이 변수는 첫 번째 작업에 의해 설정됩니다. 두 번째 작업은 문제 해결 단계 자체를 검색하지는 않지만, 변수를 통해 첫 번째 작업에서 입력으로 가져옵니다. 다음 다이어그램은 이러한 두 작업 간의 데이터 플로를 보여줍니다.

'문제 해결 도중에 사용' 작업은 항상 문제 해결 단계 작업에서 검색한 원래 문제 해결 단계를 참조합니다. 이 데이터 플로는 대화 길이에 관계없이 문제 해결 단계가 일정하게 유지되고 항상 제공되도록 보장합니다.

이 예제에 정의된 작업을 실행하려면 '항상 '해결 입력 단계' 먼저 실행'과 같은 특정 명령이 필요합니다. 하지만 에이전트가 사용하는 LLM의 비결정적 특성을 고려하면 경우에 따라 다른 순서로 이어질 수 있습니다. 결정적인 실행 순서를 보장하려면 변수에 조건부 필터를 적용하여 적절한 작업 순서를 실행합니다. 에이전트는 변수 '해결 단계'의 값을 읽고 이 변수에 값이 있는지에 따라 2개의 필터를 정의합니다.

• 문제 해결 단계 작업은 '해결 단계' 변수가 비어 있는 경우에만 실행할 수 있습니다.
• '해결 단계' 변수가 채워진 경우에만 '문제 해결 도중에 사용 작업'을 실행할 수 있습니다.

이러한 조건부 필터는 이제 작업 실행 순서를 결정적으로 적용합니다. '문제 해결 도중에 사용'은 '문제 해결 단계'가 작업을 완료할 때까지 기다려야 하므로 '해결 단계' 변수에 항상 값이 있어야 합니다.

올바른 작업 실행을 보장하려면 문제가 완전히 해결된 경우 '해결 단계' 변수를 재설정하는 세 번째 작업을 거쳐야 합니다. 결과적으로 에이전트는 새로 발생 가능한 다른 문제를 지원할 수 있도록 필요한 상태로 재설정됩니다. 이 세 번째 작업을 '해결 변수 비우기'라고 합니다. 전체 작업 다이어그램은 아래에 나와 있습니다.

변수는 문제 해결 에이전트가 다음을 허용하여 고객 문제를 해결하는 데 매우 중요합니다.

• 지속적인 동적 그라운딩: 변수는 문제 해결 단계를 저장하여 상호 작용의 길이나 횟수에 관계없이 대화 전반에 걸쳐 사용할 수 있도록 합니다. 이렇게 하면 에이전트가 맥락에서 벗어나지 않도록 방지할 수 있습니다.
• 데이터 플로: 변수는 작업 간의 데이터 플로를 촉진합니다. 예를 들어, '해결 단계' 변수는 문제 해결 단계 작업에서 검색된 문제 해결 단계를 저장하고 '문제 해결 도중에 사용' 작업에 대한 입력으로 제공합니다.
• 결정론: 변수를 필터로 사용하여 특정 작업 실행 순서를 적용할 수 있습니다. 가령 '문제 해결 도중에 사용' 작업은 해결 단계 변수가 채워진 경우에만 실행되므로, 문제 해결 단계 작업이 먼저 실행됩니다.

생성형 AI 시대에도 예측 AI는 여전히 매우 중요합니다. 예측 AI는 생성형 기능을 안내하고 강화하며 컨텍스트를 제공하는 기초적인 지능을 형성하기 때문입니다. 생성형 AI는 텍스트, 이미지 또는 비디오와 같은 새로운 콘텐츠를 생성하는 데 초점을 맞추는 반면, 예측 모델은 실시간 비즈니스 데이터로부터 입력된 데이터를 기반으로 미래를 예측합니다. 비즈니스 결과의 예로는 고객 이탈 가능성, 전환 가능성, 사례 에스컬레이션 확률, 고객 평생 가치, 사례 분류 등이 있습니다. 예측은 트렌드와 수치를 분석하여 사용자 요구 사항을 예측하고, 출력을 개인화하고, 결정을 내리고, 콘텐츠 관련성을 실시간으로 최적화하는 데 도움이 될 수 있습니다. 예를 들어, 개인화된 학습이나 의료, 재무 계획과 같은 응용 분야에서 예측형 AI는 개별 컨텍스트와 향후 시나리오에 맞춰 생성형 출력을 보장합니다. 예측형 및 생성형 AI가 함께 강력한 시너지 효과를 발휘하여 미래를 예측하는 능력과 창의성이 어우러진 더 지능적이고, 적응력이 뛰어나며, 영향력 있는 기술 솔루션을 만들어 냅니다.

예측 모델 출력을 에이전트 워크플로에 통합하는 방법

예측 모델 출력을 에이전트 워크플로에 통합하려면 Agentforce 자산에 예측 모델 작업을 추가하기만 하면 됩니다. 모델 빌더는 예측 모델을 구축 또는 등록(BYO)할 수 있는 수단을 제공하며, 에이전트는 이러한 모델을 사용하여 예측합니다. 결과 예측 및 예측 변수는 사용자 지정 변수에 저장할 수 있습니다. 에이전트는 이러한 변수 값을 특정 작업과 주제에 대한 입력으로 사용하고, 이를 조건부로 실행할 수 있습니다.

예측 모델과 통합된 사용 사례 예시

• 세분화: 고객 세분화를 위해 다중 클래스 분류를 수행하고 결과 세그먼트를 사용하여 특정 작업을 필터링합니다. 프리미엄 계층 고객을 위해 프리미엄 작업을 예약하는 것을 예로 들 수 있습니다.
• 에스컬레이션 가능성: 서비스 사례에 대한 에스컬레이션 가능성을 예측합니다. 이 가능성이 특정 임계값을 초과하면 사례를 더 빠르게 해결하거나 사람 에이전트에게 신속하게 에스컬레이션하는 작업을 실행할 수 있습니다.
• CPG: 판매 증가(예측 모델로 계산된 점수)가 특정 임계값을 초과하는 경우에만 프로모션을 계획하세요.
• 커머스: 구매 성향이 특정 임계값을 초과하는 경우에만 제품을 제안합니다.

특정 비즈니스 프로세스는 정확한 순서로 실행되어야 하며, 실행 중에 사용자 입력이 필요하지 않습니다. 이 경우 플로, API 또는 Apex를 통해 사전 결정된 단계 플로를 시행할 수 있습니다. 프로덕션 시 적극 활용하는 기존 플로가 있다면, 에이전트에서 이를 유지하고 사용하여 해당 비즈니스 프로세스를 실행할 수 있습니다. 다음 모든 예제에는 에이전트가 사용자 입력 없이도 실행할 수 있는 미리 정해진 일련의 단계가 포함됩니다. 이 경우 에이전트 동작은 실행할 결정론적 프로세스, 필요한 입력을 수집하는 방법, 출력을 해석하고 처리하는 방법을 식별하는 것으로 구성됩니다.

순차적 단계(경험상 3단계 이상)가 대부분이고 변수에 대한 종속성이 많은 비즈니스 프로세스는 명령으로 실행하기에는 너무 복잡하고 번거롭습니다. 이 경우에는 이 섹션에 나와 있는 결정론적 작업 유형을 사용하여 하드코딩하면 됩니다. 마지막으로, 이러한 구현에는 해결된 프롬프트 템플릿을 사용하는 LLM 호출과 같은 비결정적 요소가 포함될 수 있습니다. 따라서 완전히 결정적이고 종합적일 필요는 없으며, 여전히 에이전트가 알고 있는 유동성을 원하는 수준으로 보여줄 수 있습니다.

마케팅 여정의 단계 순서는 고정된 규칙에 따라 달라지며, 대화형 사용자 입력에 의존하지 않습니다. 따라서 플로를 Agentforce 작업으로 사용할 수 있습니다. 플로 또는 Apex 클래스를 호출할 수 있는 솔루션 구성 요소에서 백그라운드 또는 이벤트 트리거 작업을 완료하기 위해 호출 가능한 작업을 생성할 수 있습니다. 플로 또는 Apex 클래스에 호출 가능한 작업을 추가하고 에이전트가 완료하는 작업과 에이전트를 트리거하는 조건을 지정합니다. 호출 가능한 작업은 에이전트의 컨텍스트 변수를 전달하고 중요한 정보를 제공할 수도 있습니다.

Salesforce 플로를 사용하여 후속 작업 생성, 리마인더 이메일 전송, 레코드 업데이트와 같은 일상적인 작업을 자동화할 수 있습니다. 플로는 업무의 효율성과 생산성을 높입니다. 에이전트는 플로 작업을 사용하여 플로를 실행할 수도 있습니다. 결정론으로 인해 플로는 비즈니스 프로세스를 특정 순서로 실행해야 할 때 에이전트 동작을 지시할 수 있는 좋은 방법입니다. 플로 동작이 선호되는 경우는 주제에 '세 작업을 순서대로 수행할 것'과 같은 다른 명령이 포함되어 있을 때입니다. 3단계 이상의 순서를 적용하면 명령과 변수를 통해 관리하기가 번거로워집니다.

플로는 프롬프트를 호출하여 비결정적 요소를 포함할 수도 있습니다. 플로의 프롬프트 노드는 프롬프트 템플릿을 호출하고 플로의 다른 요소에 전달될 수 있는 응답을 수집합니다. 이러한 추가 요소는 다시 프롬프트 노드가 되어 가령 이전 응답을 요약하여 프롬프트 체인을 생성할 수 있습니다. 이는 프롬프트 체이닝 규칙이 정해진 요소에 따라 정의되고 사용자 입력에 의존하지 않는 경우에 특히 유용합니다. 한 예로, 에이전트 검색 증강 생성(RAG)은 플로에서 미리 정의된 리트리버나 프롬프트 순서를 통해 구체적인 데이터 소스에 특정 순서로 액세스할 수 있는데, 예를 들어, 사용자의 국가 문서에서 먼저 데이터를 검색한 뒤 필요에 따라 다른 소스를 참조하는 식입니다. 이 체인 메커니즘은 관련 정보를 신뢰할 수 있게 순서대로 추출합니다.

플로, Apex 및 API 작업과 마찬가지로 사전 정의된 작업 순서를 코딩할 수 있다는 점에서 결정론적 성격을 띱니다. 이러한 작업에는 프롬프트 템플릿 또는 LLM 호출과 같은 비결정적 요소가 포함될 수 있습니다. 하지만 정의에 따라 이러한 단계를 결정적으로 실행하므로, 적절한 시점에 작업을 호출하고 필요한 입력을 수집하고 출력을 처리하여 에이전트 가변성을 줄입니다. 이러한 책임은 여전히 에이전트 명령에 의해 관리되어야 하므로, 결정론적이지 않습니다. Apex 및 API 작업은 플로 작업과 동일한 사전 코딩 작업입니다.

확률적 추론에서 결정론적 추론으로

결정론 수준 1부터 5까지는 에이전트 환경에 점진적으로 구조를 추가해 왔습니다. 먼저 무엇을 할 수 있는지 정의하고(수준 1, 주제), 어떻게 행동해야 하는지 안내했으며(수준 2, 지침), 신뢰에 기반하도록 했고(수준 3, 데이터), 상태를 관리했으며(수준 4, 변수), 명확하게 정의된 도구를 제공했습니다(수준 5, 결정론적 작업). 그러나 핵심 의사 결정 엔진은 여전히 근본적으로 확률적 방식에 기반하고 있었습니다. 추론 엔진은 어떤 도구를 선택할지, 다음에 어떤 질문을 할지를 스스로 결정했으며, 이러한 결정은 전적으로 대규모 언어 모델(LLM)에 의존했습니다.

수준 6인 에이전트 스크립트는 이러한 아키텍처를 근본적으로 변화시킵니다. 이 수준에서는 추론 과정 자체를 하드코딩할 수 있는 기능이 도입됩니다.

에이전트 스크립트를 통해 우리는 모델에 단순히 프롬프트를 제공하는 방식에서, 에이전트를 스크립트로 설계하는 방식으로 전환하게 됩니다. 기존의 경직된 방식의 챗봇으로 돌아가는 것이 아닙니다. 오히려 하이브리드 추론이라고 부를 수 있습니다. LLM의 창의적이고 대화 중심적인 역량을 변경할 수 없는 결정적 로직 사이에 배치하는 방식입니다. 즉, 실행의 핵심 경로('필수 단계')는 명시적으로 정의하면서도, 자연어 이해와 응답 생성은 LLM이 처리할 수 있도록 일정한 자율성을 남겨둘 수 있습니다.

워크플로를 설계할 때는 LLM 기반 에이전트를 스크립트와 함께 사용하여 다음 단계가 이미 명확하고 고정되어 있는 결정적 로직을 단순히 대체하는 일이 없도록 하는 것이 중요합니다. 프로세스가 예측 가능한 경로를 따르고 있으며 이후 작업을 해석하기 위한 복잡한 추론이 필요하지 않다면, 생성형 모델을 도입하는 것은 불필요한 지연, 비용 증가, 그리고 오류 가능성을 초래합니다. 완전히 결정적인 프로세스에는 추론이 필요하지 않기 때문에, 이러한 경우에는 기존의 프로그래밍 기반 흐름이 여전히 더 적합합니다. 단순한 라우팅이나 선형 전환을 처리하기 위해 LLM을 사용하는 것은 과도한 설계로, 표준 절차 기반 흐름으로 충분히 처리할 수 있는 시스템의 신뢰성을 오히려 저하시킬 수 있습니다.

일반적으로 에이전트 기반 솔루션은 시스템이 의사 결정을 내리기 전에 서로 다른 다양한 출처(대화형 입력을 포함할 수 있음)에서 들어오는 비정형 입력을 종합적으로 해석해야 하는 상황에서 고려하는 것이 바람직합니다.

그렇다면 이러한 수준의 제어를 어떻게 구현할 수 있을까요? 비즈니스 아키텍트와 프로 코드 개발자 모두를 위해 두 가지 서로 다른 접근 방식이 마련되어 있습니다.

에이전트에 수준 6의 결정론을 적용하기 위해 반드시 코드를 작성해야 하는 것은 아닙니다. Salesforce는 기본이 되는 에이전트 스크립트를 생성할 수 있도록 두 가지 방식을 제공하여, 결정적 추론을 보다 쉽게 활용할 수 있도록 합니다.

비즈니스 분석가, 관리자, 로우코드 사용자에게는 에이전트 빌더 내에서 직접 수준 6 기능을 사용할 수 있습니다.

이를 위해 텍스트를 스크립트로 변환하는 인터페이스 역할을 하는 문서 형태의 캔버스를 도입했습니다. 코드를 작성하는 대신, 구조화된 자연어로 주제의 로직을 작성하면 됩니다. 빌더는 사용자의 의도를 해석하고 이를 백그라운드에서 에이전트 스크립트로 컴파일합니다.

• 예를 들어 다음과 같이 작성할 수 있습니다. '먼저, 주문이 30일 이전에 생성된 것인지 확인해 줘. 그렇다면 반품을 받을 수 없다는 점을 사용자에게 알리고 정중하게 대화를 종료해 줘. 그렇지 않다면 상품의 상태를 질문해 줘.'
• 시스템은 이러한 자연어 설명을 자동으로 필요한 if/else 구조, 변수 확인, end_conversation 명령으로 컴파일합니다.

이를 통해 자연어로 로직을 작성하면 플랫폼이 이를 코드로 변환하며, 프로그래밍 경험이 없는 사용자도 엄격한 가드레일과 결정론을 적용할 수 있습니다.

최대한의 정밀도를 원하는 개발자는 에이전트 빌더 내에서 에이전트 스크립트를 직접 작성할 수도 있습니다. 자연어로 작성된 설명이 표시되는 캔버스를 전환하면, 그에 해당하는 기본 스크립트를 확인할 수 있으며 개발자는 이를 기반으로 스크립트를 직접 코딩할 수 있습니다. 이 방식은 하이브리드 작성 방식도 지원합니다. 일부 지침은 캔버스에서 자연어로 작성하고, 다른 지침은 코드로 직접 작성하거나 기존 스크립트를 수정할 수 있습니다. 이 두 가지 작업 환경을 오가며 사용할 수 있으며, 두 방식은 항상 완벽하게 동기화된 상태로 유지됩니다.

두 방식 모두 수준 6의 모든 기능을 활용할 수 있도록 합니다.

• 상세 추적: 스크립트 실행 과정을 단계별로 확인하여 변수가 언제 변경되었는지, 어떤 분기가 실행되었는지 정확히 파악할 수 있습니다.
• 복잡한 루프 처리: 자연어로 설명하기 어려운 정교한 재시도 로직이나 여러 변수의 상태 변화를 관리할 수 있습니다.
• 버전 관리: 에이전트의 동작을 코드처럼 관리하여 git 및 CI/CD 파이프라인과 호환되는 방식으로 에이전트 버전을 관리할 수 있습니다.

에이전트 스크립트를 빌더를 통해 생성하든 직접 작성하든, 결과는 동일합니다. 에이전트 스크립트는 에이전트 그래프로 변환되며, 이는 아틀라스 추론 엔진에 의해 실행됩니다.

수준 6을 제대로 이해하려면 내부적으로 어떤 일이 일어나는지 파악하는 것이 중요합니다. 에이전트 스크립트는 추론 블록 내의 특정 프로그래밍 구조를 통해 동작을 제어합니다. LLM이 따르도록 제안하는 일반적인 프롬프트와 달리, 이러한 구조는 어떤 상황에서도 반드시 실행되는 명령입니다. 이 명령은 추론 과정 이전, 도중, 또는 이후에 실행될 수 있으며, 여러 가지 서로 다른 형태의 결정론 유형으로 구성됩니다. 먼저 이러한 패턴 중 일부를 전반적으로 살펴보고 간단한 예시를 소개한 다음, 스크립트 기반 에이전트의 아키텍처 블루프린트 예시를 통해 이를 더 자세히 설명하겠습니다.

수준 1~5에서는 에이전트가 프로세스의 특정 단계 이전이나 이후에 어떤 작업을 수행하기를 기대하는 방식이었습니다. 하지만 수준 6에서는 이를 반드시 수행하도록 강제합니다. before_reasoning 및 after_reasoning 블록에 작성된 내용은 각각 LLM이 지침을 기반으로 추론을 수행하기 전과 후에 항상 실행됩니다. 이 과정에서는 다른 작업을 실행하거나, 다른 주제로 전환하거나, 변수를 설정하는 등의 작업을 수행할 수 있습니다.

예를 들어 주제의 before_reasoning 지침에서 run 지침을 사용하면, LLM이 응답 생성을 위해 호출되기 전에도 작업을 실행할 수 있습니다. 이를 통해 필요한 데이터를 즉시 확보할 수 있으며, 추론 지연을 줄이고 에이전트가 도구 호출을 놓치는 위험도 방지할 수 있습니다.

스크립트 구조:

조건부 결정론을 사용하면 표준 프로그래밍 로직을 활용해 흐름을 제어할 수 있습니다. 이는 단계를 건너뛰거나 임의로 변경할 수 없는 규정 준수 워크플로에서 특히 중요합니다.

스크립트 구조:

이 예시에서는 LLM이 VIP가 아닌 사용자에게 승인을 제공하는 내용을 생성할 옵션이 전혀 없습니다. 분기 처리는 엔진에 의해 결정적으로 수행됩니다.

또 다른 강력한 제어는 에이전트를 현재 주제에서 다른 주제로 강제로 전환할 수 있는 기능입니다. 이를 통해 에이전트가 특정 단계에 머무르거나 관련 없는 대화로 벗어나는 것을 방지할 수 있습니다.

스크립트 구조:

이 전환은 단순한 제안이 아닙니다. 변수 값에 따라 실행 흐름을 강제로 다른 방향으로 전환하는 하드 리디렉션입니다. 다만 리디렉션 자체는 강제적이고 협상의 여지가 없지만, 에이전트가 전환된 주제 내부에서는 다시 일반적인 추론 과정이 수행됩니다.

또한 에이전트 스크립트를 사용하면 하나의 작업이 완료된 직후 다음 작업으로 전환되도록 명시적으로 강제할 수 있습니다. 이 기능을 통해 에이전트는 매 단계마다 확률적이거나 자율적인 의사 결정에 의존하는 대신, 엄격하고 결정적인 흐름을 따르게 됩니다. 이러한 작업을 미리 정의된 순서로 연결하면 특정 작업이 정확한 순서로 실행되도록 보장할 수 있으며, 이를 통해 에이전트의 로직과 동작을 완전히 제어할 수 있습니다.

에이전트 스크립트는 에이전트의 단기 메모리(변수)에 대해 직접 읽기/쓰기 접근 권한을 제공합니다. 작업 출력을 기반으로 변수를 명시적으로 설정할 수 있어, LLM이 도구의 JSON 출력을 잘못 해석하는 전화 게임(telephone game)과 같은 상황을 방지할 수 있습니다.

스크립트 구조:

에이전트 스크립트의 강력함을 제대로 이해하려면 개별 명령만 보는 것을 넘어, 이들이 함께 어떻게 작동하는지 살펴볼 필요가 있습니다. 다음 아키텍처 패턴(에이전트 스크립트 레시피 컬렉션 에서 도출)은 수준 6 결정론이 복잡한 엔터프라이즈 과제를 어떻게 해결하는지 보여줍니다.

문제: 일반적인 에이전트는 종종 추론 지연을 겪습니다. 사용자가 질문을 할 때까지 기다린 뒤 어떤 도구를 사용할지 판단하고, 이미 조회할 수 있는 정보임에도 사용자에게 다시 물어본 다음에야 작업을 호출하기도 합니다. 이로 인해 지연과 단절된 사용자 경험이 발생됩니다. 에이전트 스크립트: 추론 이전 결정론.

LLM이 추론을 시작하기도 전에 데이터를 주입하기 위해 run 명령을 사용합니다.

예시: 긴급 분류 에이전트. 정전 신고를 처리하는 에이전트를 예로 들어 보겠습니다. 사용자에게 주소를 물어보고 기다리는 대신, 세션이 시작되는 순간 스크립트가 자동으로 get_current_location_by_IP와 check_grid_status 명령을 실행합니다.

결과: 에이전트는 "무엇을 도와드릴까요?"로 대화를 시작하지 않습니다. 대신 다음과 같이 시작합니다. "현재 변압기 화재가 확인된 북부 구역에서 전화하신 것으로 확인됩니다. 이미 고객님의 가정을 우선 복구 목록에 추가했습니다. 현재 비상 발전기를 사용 중이신가요?"

로직:

긴 프롬프트(에이전트에게 모든 규칙을 한 번에 제공하는 방식)는 추론 과정에서 환각이 발생할 확률을 높입니다. 에이전트가 규칙 Z를 보느라 규칙 A를 잊어버리는 상황이 발생할 수 있습니다.

에이전트 스크립트 솔루션: 검색 증강 생성(RAG)과 조건부 로직을 결합한 조건부 그라운딩을 통해 필요한 시점에 필요한 지침만 주입하는 것입니다. 이 방식은 대화의 정확한 시점에 적용되는 규칙만 에이전트에게 보여줍니다.

예시: 비적격 오퍼에 대한 규칙 제공. 고객의 신용 점수가 애초에 신용 한도 증액 요청이 가능한 수준이 아닌데, 왜 에이전트에게 그에 대한 규칙을 제공해야 할까요?

로직:

조건부 그라운딩은 필요하지 않은 경우 방해가 되는 정보를 완전히 제거함으로써 오류가 발생할 가능성을 없애는 방식입니다.

문제: 모기지 신청, 채용 인터뷰, 기술 문제 해결 세션과 같이 복잡한 에이전트 대화에서는 사용자로부터 필요한 모든 정보를 수집하기 위해 반드시 답변해야 하는 질문 목록을 유지합니다. 하지만 사용자는 종종 대화의 흐름에서 벗어나 다른 이야기를 하기도 합니다. 일반적인 에이전트는 이러한 대화 흐름을 따라가다가 필수 질문으로 돌아오는 것을 잊어버려, 신청 절차나 대화가 불완전한 상태로 끝날 수 있습니다.

이 시스템의 핵심은 상태 기반 탐색으로, 대화를 모든 항목이 체크되어야 하는 엄격한 체크리스트처럼 관리하는 방식입니다.

상태 기반 탐색을 통해 에이전트는 현재 변수 상태에 따라 주제 간 이동을 수행하거나, 특정 조건이 충족될 때까지 하나의 주제 안에 머무르게 됩니다. 이를 통해 사용자가 대화를 다른 방향으로 유도하려고 하더라도, 허용되지 않은 경로로 에이전트가 이동하는 것을 방지할 수 있습니다. 예를 들어 중요한 모기지 신청 과정에서 사용자가 지점 영업시간을 묻는다면, 에이전트는 단순히 대화를 원래 흐름으로 돌리려 하지 않습니다. 대신 스크립트가 이러한 이탈을 감지하고 규정 준수 재설정 주제로 강제 전환을 실행할 수 있습니다. 이처럼 에이전트를 특정 '로직 공간'에 고정함으로써, 모든 필수 변수가 수집되기 전까지 승인되지 않은 주제를 논의하거나 세션을 종료하는 일이 수학적으로 불가능하도록 만들 수 있습니다.

예: 정비 점검 담당자. 에이전트가 항공기 엔진에 대한 10단계 안전 점검을 수행하도록 기술자를 안내하고 있다고 가정해 보겠습니다. 기술자가 "잠깐만요, 동체에도 긁힌 자국이 있는 것 같아요."라고 말합니다.

동작:

1. 에이전트는 해당 긁힘을 자연어로 확인합니다.
2. 그 정보를 변수에 기록합니다(상태 관리).
3. 그리고 다음 사항이 확인될 때까지 세션을 종료하거나 다른 주제로 전환하지 않습니다. "동체의 긁힘은 기록해 두었습니다. 하지만 흡기 밸브의 토크 설정이 확인되기 전까지는 '외부' 점검 단계로 이동할 수 없습니다. 측정값이 얼마였나요?"

로직:

하지만 가이드형 대화는 단순히 순차적인 질문 목록에 그쳐서는 안 됩니다. 그렇지 않으면 에이전트는 단지 '대화 형태로 위장한 양식'에 불과해집니다. 가이드형 대화의 핵심 가치는 지능형 분류에 있습니다. 초기 탐색 질문을 통해 사용자를 적절한 양식이나 워크플로로 안내하는 것입니다.

복잡성이 증가하면, 단순한 스크립트에서 보다 견고한 에이전트 스크립트로 전환하는 것이 자연스러운 선택이 됩니다. 이 단계에서는 에이전트가 단순히 질문하는 것을 넘어 실제 작업을 수행하기 시작합니다. 예를 들어 에이전트는 문서에서 문제 해결 절차를 추출하거나, 내부 정책을 탐색하거나, 외부 시스템의 API를 호출해 문제를 실시간으로 해결할 수 있습니다.

결정론 프레임워크에서 수준 6으로 에이전트 스크립트가 도입되면서, 이제 수준 1 주제의 개방적이고 창의적인 방식부터 수준 6 에이전트 스크립트의 엄격한 코드 기반 로직까지 전체적인 제어 범위를 활용할 수 있게 되었습니다.

하지만 망치를 가지고 있다고 해서 모든 문제가 못인 것은 아닙니다.

가장 흔한 실수는 '높을수록 더 좋다'라고 생각하며, 이제 모든 작업을 스크립트로 완전히 통제해야 한다고 여기는 것입니다. 하지만 이는 사실이 아닙니다. 에이전트 아키텍처와 설계의 진정한 핵심은 필요한 만큼의 제어만 적용해 안전성을 확보하면서도, AI의 가치를 만들어내는 대화의 유연성을 잃지 않도록 결정성의 수준을 적절히 조정하는 데 있습니다. 에이전트를 과도하게 스크립트화하여 결국 '고급 챗봇' 수준으로 전락하지 않도록 주의해야 합니다.

이 장에서는 수준 1~5의 가이드형 자율성을 활용해야 할 때와 수준 6의 스크립트 기반 정밀성을 적용해야 할 때를 판단하는 데 도움이 되는 의사 결정 프레임워크를 제공합니다. 이는 엄격한 규칙이 아니라 경험적 기준에 가깝고, 결정성의 다양한 옵션과 수준을 어떻게 이해하고 적용할지에 대한 맥락적 기준을 제시하기 위한 것입니다.

의사 결정을 단순화하기 위해 여섯 가지 수준을 두 개의 전략적 영역으로 나눌 수 있습니다.

• 철학: '신뢰하되 검증하라.' 에이전트에게 목표, 데이터, 그리고 도구(수준 5에서처럼 결정적인 도구일 수도 있음)를 제공하되, 그 목표에 도달하기 위한 최적의 경로는 추론 엔진이 스스로 결정하도록 합니다.
• 메커니즘: 확률론적 추론. 에이전트는 사용자의 의도를 분석하고 작업에 가장 적합한 도구를 동적으로 선택합니다.
• 적합한 상황: 검색, 일반 Q&A, 위험도가 낮은 작업, 넓은 범위의 서비스 처리.

다음과 같은 경우에는 수준 1~5의 표준 확률적 동작에 의존하는 것이 좋습니다.

1. 항상 같은 경로가 정답은 아니다

많은 대화형 시나리오에서는 올바른 대화 경로가 상황에 따라 달라지기 때문에, 경직된 하드코딩 방식의 경로가 오히려 단점이 될 수 있습니다. 예를 들어 개인 쇼핑 추천이나 휴가 계획과 같은 동적인 상호작용에서는 하나의 정답 경로가 존재하지 않습니다. 사용자는 가격, 위치, 편의시설 중 무엇을 우선할지 어떤 순서로든 선택할 수 있습니다. 이러한 경우 상태 기반 스크립트를 강제로 적용하면 지나치게 기계적인 경험을 만들 수 있으므로, 지침을 통해 에이전트의 역할과 목표만 정의하고 대화 흐름은 사용자가 이끌도록 하는 것이 더 효과적입니다. 이 접근 방식은 시장 출시 속도도 크게 높여 줍니다. 중첩 변수와 분기가 포함된 복잡한 수준 6 스크립트를 구축하는 것은 내부 HR FAQ 에이전트와 같은 작업에는 과도한 설계가 될 수 있기 때문입니다. 에이전트를 데이터와 검색 증강 생성(RAG)에 기반하도록 설정하면, 모든 상황을 수동으로 스크립트화할 필요 없이 검색 엔진이 기존 지식 기반을 활용해 대화를 동적으로 처리하도록 할 수 있습니다.

2. 모듈형 결정론을 통한 확장: 유지보수 악몽 피하기

에이전트의 범위가 매우 커져 예를 들어 서로 다른 프로세스를 가진 500가지 IT 지원 문의를 처리해야 하는 경우, 핵심 문제는 하나의 결정적 에이전트 스크립트를 만들 수 있느냐가 아니라 그렇게 해야 하느냐는 것입니다. 500가지 작업의 모든 가능한 경우를 하나의 거대한 에이전트 스크립트로 설계하려고 하면 유지보수의 악몽이 발생합니다. 정책이 변경되거나 새로운 문제 해결 단계가 추가될 때마다, 서로 복잡하게 연결된 거대한 로직 구조가 깨질 위험이 있기 때문입니다.

해결 방법은 단일한 거대 스크립트에서 벗어나 수준 5의 결정론적 작업을 활용하는 것입니다. 대화 전체를 스크립트로 작성하는 대신, 비밀번호 재설정이나 계정 잠금 해제와 같은 핵심 고가치 작업에 대해 견고하고 독립적인 흐름을 구축합니다. 그리고 추론 엔진이 트래픽 컨트롤러처럼 작동하도록 하여, 사용자의 다양한 표현에서 의도를 파악하고 적절한 결정적 작업으로 라우팅하도록 합니다. 이 접근 방식은 중요한 작업에는 스크립트 수준의 신뢰성을 제공하면서도, 작업 종류가 증가해도 시스템이 복잡성 때문에 무너지지 않는 유연하고 확장 가능한 아키텍처를 제공합니다.

• 철학: '무엇을 하든, 어떤 추론을 하든, 반드시 이것을 정확히 수행하라.' 경로는 설계자가 정의합니다. 에이전트는 그 로직을 실행하기 위한 인터페이스 역할을 합니다. 즉, 에이전트의 창의적 능력을 반드시 수행해야 하는 로직 계층 사이에 배치하는 구조입니다.
• 메커니즘: 결정론적 추론. '두뇌'는 사전에 컴파일된 그래프를 따라 동작하며, LLM은 스크립트가 허용하는 범위 내에서만 추론, 자연어 이해, 응답 생성에 사용됩니다.
• 적합한 상황: 규정 준수, 금융 거래, 진단 트리, 고위험 워크플로, 규제가 엄격한 산업 환경.

또한 수준 6이 제공하는 결정적 흐름 안에서도 수준 1~5의 모든 기능을 여전히 활용할 수 있습니다.

'대체로 맞는 수준'으로는 충분하지 않을 때 에이전트 스크립트를 사용하는 것이 적절합니다.

1. 반드시 통과해야 하는 단계(보안 및 인증)

사용자가 송금을 요청했을 때, LLM이 인증을 아마도 요청할 것이라고 기대할 수는 없습니다. 거래 절차가 시작되기 전에 인증 절차가 반드시 실행된다는 수학적으로 확실한 보장이 필요합니다.

• 에이전트 스크립트 솔루션: before_reasoning 블록 내부나 스크립트의 가장 상단에 run @actions.verify_identity를 사용하여, LLM이 단 하나의 토큰도 생성하기 전에 인증 절차가 반드시 실행되도록 강제합니다.

2. 규제 준수

의료나 금융과 같은 산업에서는 에이전트가 고지 문구를 원문 그대로 읽어야 하거나, 법적으로 정해진 순서대로 질문을 해야 하는 경우가 많습니다.

• 에이전트 스크립트 솔루션: 해당 고지 문구를 하드코딩합니다.

3. 복잡한 다단계 의존성과 필수 작업 실행 순서

단계 B가 단계 A의 출력값을 반드시 필요로 하고, 단계 C가 단계 B의 계산 결과에 의존하는 경우, 프롬프트 컨텍스트를 통해 변수를 전달하는 방식에 LLM을 의존하는 것은 위험할 수 있습니다. 또한 특정 작업이 다른 작업 이후에 반드시 실행되어야 한다면, 그 순서는 명확하게 고정되어야 합니다.

• 에이전트 스크립트 솔루션: set @variables.x = @outputs.y를 사용해 단계 간 데이터를 명시적으로 연결하여, 데이터 전달의 정확성을 보장합니다. run과 @utils.transition 문을 사용해 실행 순서를 코드로 정의할 수 있습니다.

4. 주제 이탈 방지

위험도가 높은 문제 해결 상황(예: "제 심박조율기에서 경고음이 울립니다")에서는 사용자가 갑자기 "오늘 날씨가 어떤가요?"라고 묻더라도 에이전트가 그 질문에 주의를 빼앗기지 않도록 해야 합니다.

• 에이전트 스크립트 솔루션: @utils.transition을 사용해 문제가 해결될 때까지 사용자를 긴급 프로토콜 주제에 고정하고, 다른 주제로 이탈하는 기능을 명시적으로 차단합니다.

가장 성숙한 에이전트 아키텍처는 둘 중 하나만 선택하지 않습니다. 수준 6을 뼈대로 사용하고, 수준 1~5를 근육처럼 활용합니다. 이때 나타나는 패턴은 이른바 '결정적 샌드위치' 구조입니다. 에이전트 스크립트를 사용해 대화의 중요한 시작과 종료 단계를 처리하고, 그 사이의 과정은 유연한 추론이 가능하도록 열어 두는 방식입니다.

• 1단계(수준 6): 에이전트 스크립트가 분류와 인증을 강제합니다.
  • 결과: 사용자가 안전하게 식별되고 의도가 분류됩니다.
• 2단계(수준 1~5): 에이전트 스크립트가 표준 주제로 핸드오프합니다.
  • 결과: 에이전트는 표준 검색 증강 생성(RAG)와 작업, 지침, 그리고 경우에 따라 변수까지 활용해 사용자의 문제를 유연하게 해결합니다.
• 3단계(수준 6): 에이전트가 문제가 해결되었음을 감지하고 마무리 작업을 위해 다시 에이전트 스크립트로 전환합니다.
  • 결과: 에이전트 스크립트가 CSAT 점수 수집과 규정에 맞는 종료 인사를 강제합니다.

최종 권장 사항: 속도와 검색을 위해 먼저 수준 1~5로 시작하고 로그를 모니터링합니다. 에이전트가 일관성을 유지하는 데 어려움을 겪거나, 정해진 순서를 따르지 못하거나, 파라미터를 환각하는 경우가 보이면 해당 워크플로에 한해 선택적으로 수준 6을 적용해 강화합니다.

에이전트 스크립트는 에이전트에 결정성을 부여하기 위한 퍼즐의 마지막 조각입니다. 이는 AI는 확률적이지만 비즈니스는 결정적이라는 사실을 인정합니다. 에이전트 스크립트를 도입함으로써(자연어 기반 에이전트 빌딩을 지원하는 캔버스를 사용하든, 직접 코드를 작성하든) 에이전트의 지능을 제한하는 것이 아니라, 그 지능을 집중시키는 것입니다. 즉, 대화의 예술과 프로세스 실행의 과학이 만나는 시스템을 구축하는 것으로, 가장 중요한 워크플로가 매번 설계된 그대로 정확하게 실행되도록 보장합니다.

수준 6은 또한 자율적이라는 것이 통제되지 않는 것을 의미하지 않는다는 사실을 보여줍니다.

수년 동안 업계에서는 의사 결정과 프로세스 최적화에 있어 규칙 기반 접근과 AI 기반 접근 중 어느 쪽이 더 적절한지 논의해 왔습니다. 엄격한 규칙을 지지하는 측은 예측 가능성을 강조했고, AI를 지지하는 측은 유연성을 강조했습니다. 에이전트 스크립트는 올바른 아키텍처가 둘 중 하나가 아니라 둘을 함께 사용하는 것임을 보여주며 이 논쟁을 마무리합니다.

에이전트 스크립트를 도입한다는 것은 하이브리드 에이전트를 구축하는 것을 의미합니다. 즉, 코드의 견고한 골격과 LLM의 유연한 사고를 동시에 갖춘 시스템입니다. 엔터프라이즈 AI의 미래는 더 큰 모델에 있지 않습니다. 더 나은 제어에 있습니다. 에이전트 스크립트를 통해 그 제어는 마침내 여러분의 손에 들어왔습니다.