요즘 회사 프로젝트 방향이 거의 AI 위주로 된 것 같아서 한번 각잡고 공부해봐야겠다 싶었는데, 마침 온라인 워크숍 기회가 생겨서 신청했다. 4월 6일부터 10일까지 5일짜리 온라인 부트캠프다.
| 날짜 | |
|---|---|
| 1일차 | 4월 6일 (월) |
| 2일차 | 4월 7일 (화) |
| 3일차 | 4월 8일 (수) |
| 4일차 | 4월 9일 (목) |
| 5일차 | 4월 10일 (금) |
오늘은 1일차라 환경 세팅이랑 기본 데이터 구조 살펴보는 걸 했다. 실습 전에 배경 지식 쌓는 느낌? 아직까지는 은근히 재밌었다.
부트캠프에서 뭘 하냐면
전체 커리큘럼을 먼저 훑었는데, 요약하면 이렇다.
- Agentforce Builder (Canvas + Agent Script)로 AI 에이전트 직접 만들기
- Data 360으로 고객/주문 데이터 통합하기
- Prompt Builder로 데이터 기반 프롬프트 템플릿 설계하기
- RAG 붙여서 비정형 데이터까지 응답에 활용하기
- 완성한 Service Agent를 웹사이트에 배포하고 실제 동작 확인하기
한 마디로 AI 에이전트를 처음부터 끝까지 다 만들어보는 거다. 환경 세팅 → 데이터 이해 → 에이전트 설계 → 배포까지. 꽤 빡세 보이긴 하는데 5일이니까 어떻게 되겠지...
환경 세팅 — Salesforce Org 만들고 Agentforce 켜기
실습용 Salesforce Org를 새로 하나 만드는 것부터 시작했다.
그 다음이 Agentforce 활성화인데, 순서가 이렇다.
- 우측 상단 톱니바퀴 아이콘 → 설정 열기
- 좌측 빠른 찾기에서
Agentforce검색 - Agent Studio > Agentforce Agents 클릭
- Agentforce 토글 ON
이걸로 세팅 끝. 쏘 이지~
Pronto라는 가상의 음식 배달 플랫폼을 배경으로 진행된다. 실습 내내 이 데이터를 기반으로 에이전트를 만들게 되니까, 데이터 구조부터 이해하는 게 먼저였다.
Pronto의 Salesforce 데이터 모델은 크게 두 가지로 나뉜다. 가맹 브랜드 쪽이랑 고객 쪽.
가맹 브랜드 데이터 — Accounts & Storefronts
App Launcher에서 Customer Support 앱을 열고, Accounts 탭으로 이동.
계정 레코드 페이지에 관련 레코드들이 쭉 붙어 있는데, 여기서 Storefronts 탭을 보면 이 계정이 운영하는 개별 매장들이 나온다.
- Accounts = 여러 매장을 가진 브랜드/사업자
- Storefronts = 그 브랜드 산하의 개별 매장 하나하나
프랜차이즈로 생각하면 딱 맞는 구조. 본사가 Account고, 각 지점이 Storefront인 느낌.
고객 데이터 — Contacts, Cases, Reviews, Gift Certificates
고객 관련 객체들:
Cases
고객이 접수한 서비스 문의들이다. 누락된 메뉴, 배송 지연, 주문 오류, 환불 요청 같은 것들.
Reviews
고객이 서비스 이용 후 남긴 리뷰나 평점.
Gift Certificates
크레딧이나 상품권 정보. 환불이나 보상 처리할 때 영향을 주는 데이터다. 예를 들어 "환불 대신 쿠폰 드렸던 이력이 있는 고객인지" 이런 걸 체크할 수 있겠지?
Orders는 외부데이터
근데 주문 데이터인 Orders는 Salesforce가 아닌 외부 DB에 저장된다. 이게 포인트인데, 에이전트가 주문 관련 문의를 처리하려면 외부 시스템을 호출하는 액션(Action) 을 통해서 데이터를 가져와야 한다.
현실에서도 ERP나 별도 주문 시스템 쓰는 경우 많으니까, 이 설정이 괜히 현실적으로 느껴졌다. 나중에 이 부분 실습할 때 어떻게 연동하는지 더 자세히 보게 될 것 같다.
실습 1 — 에이전트 만들기
에이전트 생성
App Launcher에서 Agentforce Studio 앱을 열고 New Agent를 클릭. 프롬프트 창에 에이전트가 뭘 해야 하는지 설명을 입력하면 AI가 초기 구조를 제안해준다.
근데 이번 실습에서는 처음부터 직접 만들어보는 게 목표!
빌더 인터페이스 구경
에이전트를 만들고 나면 Agentforce Builder가 뜨는데 구성이 이렇다.
- 왼쪽: 탐색 패널 (Explorer) — 토픽, 액션, 변수 등 관리
- 가운데: 메인 편집 화면 — Canvas 또는 Script 모드로 에이전트 설계
- 오른쪽: 에이전트 생성 도우미 (Authoring Agent)
Canvas ↔ Script 전환이 가능한데, Canvas는 시각적으로 흐름을 보면서 작업하는 모드고 Script는 텍스트 기반으로 직접 수정하는 모드다. 둘 다 같은 에이전트를 다른 방식으로 보는 것.
시스템 메시지 설정
탐색기에서 System을 클릭하면 에이전트에게 전달되는 기본 지침, 환영 메시지, 오류 메시지를 설정할 수 있다.
Topic Selector
탐색기에서 Topic Selector를 클릭하면 이게 모든 대화의 시작 지점이라는 게 보인다. 사용자가 메시지를 입력할 때마다 에이전트는 Topic Selector를 기반으로 "어떤 토픽으로 넘길지"를 판단한다.
그래서 Topic Selector에는 다른 토픽으로 넘기는 전환(Transition) 액션만 들어가야 한다는 게 포인트.
변수(Variables)
탐색기에서 Variables를 클릭하면 현재 에이전트에 설정된 전역 변수 목록이 나온다. linked로 표시된 변수는 시스템이 자동으로 값을 설정하는 것들 (예: @MessagingSession.Id). 에이전트가 직접 바꿀 수 없음.
실습 2 — 토픽이랑 액션 붙이기
토픽 생성
탐색 패널에서 Topics 옆 + 아이콘 → Create new topic으로 새 토픽을 만든다.
토픽을 만들면 자동으로 Topic Selector에 연결은 안 되고, 별도로 라우팅을 구성해줘야 한다.
미리보기로 라우팅 테스트
Preview 버튼을 누르면 에이전트랑 직접 대화해볼 수 있다.
오른쪽 Interaction Details 패널에서 에이전트가 왜 이 토픽을 선택했는지 이유까지 볼 수 있다. 이게 되게 유용한 디버깅 도구였다.
Apex 기반 액션 추가
토픽에서 Actions 옆 + → Create an action
Reference Action Type: Apex/Flow/API/External Service
Reference Action: {Action}
Outputs - {Object}: Show in conversation 체크Salesforce에 미리 만들어진 Apex 클래스 등을 에이전트 액션으로 불러다 쓰는 것.
Agent Script에서 출력 타입 수동 수정
여기서 좀 번거로운 작업이 있었는데, Canvas 모드에서는 출력 타입을 자동으로 못 잡는 경우가 있어서 Script 모드에서 직접 수정해야 했다.
Canvas → Script 전환 후 출력 항목 찾아서 타입을 list[object]로 바꾸고 complex_data_type_name을 Apex 클래스 경로로 지정.
출력값이 단순 텍스트가 아니라 객체 리스트일 때 LLM이 올바르게 파싱할 수 있도록 알려줘야 한다.
실습 3 — Order Issues & Refunds (하이브리드 추론 Part.1)
이번 실습에서 Hybrid Reasoning(하이브리드 추론) 이라는 개념이 처음 나왔다. LLM의 자연어 이해 능력 + 구조화된 제어 요소(토픽, 변수, 조건 로직)를 결합해서 예측 가능하고 안정적인 에이전트 동작을 만드는 방식이다.
Order Issues & Refunds 토픽 생성
같은 방식으로 토픽 생성. 이 토픽이 다루는 범위가 꽤 넓다 — 누락 메뉴, 잘못된 주문, 늦은 배달, 배달 안 온 케이스, 환불 처리까지.
액션 3개 추가
1. Get Customer Profile — 이메일 주소로 고객 정보 조회 (Apex)
2. Get Related Cases — 고객의 관련 문의(Case) 목록 조회 (Apex)
- Script에서 출력 타입
list[object]로 수동 수정 필요
3. Handle Order Refunds — 실제 환불 처리 (Flow)
refundAmount,refundReason,verifiedContactId전부 Require Input to execute action 체크- 검증된 고객 ID가 없으면 환불 못 하도록 강제하는 것
토픽 지침에 액션 사용 흐름 추가
When a user asks about their order or requests a refund, ask for their email address.
Run Get Customer Profile → Get Related Cases or Handle Order Refunds동작 확인
Preview에서 Can you show me all of my cases? 입력 → 이메일 요청 → 이메일 입력하면, Interaction Details에서 Get Customer Profile → Get Related Cases 순서로 액션이 실행되는 게 보인다.
실습 4 — 고객 검증 가드레일 (하이브리드 추론 Part.2)
오늘 실습 중에 제일 핵심이었던 것 같다. 환불 같은 민감한 작업을 하기 전에 고객 신원을 반드시 확인하도록 강제하는 로직을 만드는 것.
Verify Customers 토픽 생성
신원 확인만 전담으로 처리하는 토픽.
인증 관련 액션 2개 추가
1. Send Email with Verification Code (Flow)
- 고객 이메일로 인증 코드 발송
2. Verify Code (Flow)
- 고객이 입력한 코드 검증
전역 변수 2개 추가
| 변수명 | 타입 | 역할 |
|---|---|---|
IsVerifiedCustomer | Boolean | 고객 인증 완료 여부 (기본값: False) |
AuthenticationKey | String | 인증 코드 발송~확인 사이의 키 값 전달 |
변수는 탐색 패널의 Variables에서 Create a Custom Variable로 추가.
Enable API write access도 체크해줘야 액션이 값을 쓸 수 있다.
변수 매핑
액션의 입력/출력값을 변수에 연결하는 작업.
Send Email with Verification Code→authenticationKey출력 →VerificationKey변수에 저장Verify Code→VerificationKey변수를 입력으로 받고 →isVerified출력 →IsVerifiedCustomer변수에 저장
이렇게 하면 인증 코드를 발송하고 확인하는 두 액션이 같은 키를 공유하게 됨.
토픽 지침에 단계별 흐름 + 조건 로직 추가
여기서 Script 모드에서 /를 입력하면 리소스 선택기가 뜨는데, 여기서 조건문(Conditional Statement) 을 선택할 수 있다.
if IsVerifiedCustomer == true
→ Topic Selector로 전환 (원래 요청으로 돌아감)
else
→ 인증 실패 메시지 + Step 1로 돌아가기Order Issues & Refunds에도 조건 로직 적용
이 토픽에서도 같은 방식으로:
if IsVerifiedCustomer == true
→ Get Related Cases / Handle Order Refunds 실행
else
→ Verify Customers 토픽으로 전환이렇게 하면 인증 안 된 고객이 환불 요청을 해도 바로 인증 토픽으로 튕겨나간다.
전체 흐름 테스트
Preview에서 Hi, I'm Alex Morgan. Can you show me all of my cases? 입력.
→ 인증이 안 된 상태라 Verify Customers 토픽으로 전환됨
→ 이메일 입력 → 인증 코드 발송 → Interaction Details에서 코드 확인 → 입력
→ 인증 완료 → Order Issues & Refunds로 돌아와서 Get Related Cases 실행
알아서 착착착 잘 수행한다.
실습 5 — 외부 API 연동 (Order Lookup)
주문 데이터는 Salesforce 밖에 있다고 했는데, 이걸 에이전트가 조회하려면 외부 API를 연결해야 한다. 여기서 External Services라는 기능을 처음 썼다.
나는 이게 있다는 걸 이번에 처음 알았는데, API 스펙(Swagger/OpenAPI)을 등록하면 Salesforce가 알아서 연동 레이어를 생성해주는 기능이다. 직접 HTTP 호출 코드를 짜지 않아도 되니까 꽤 편하다.
External Service 등록
설정 → External Services → Add an External Service → From API Specification 선택.
Name: 입력
Named Credential: 선택
URL: 입력저장하면 API 스펙을 읽어서 사용할 수 있는 Operation 목록을 보여준다.
권한 세팅
External Service를 에이전트가 쓰려면 Permission Set에서 External Credential Principal Access도 활성화해줘야 한다. 이걸 빼먹으면 연동이 안 됨.
Permission Sets → {Permission Set} 선택 → External Credential Principal AccessOrder Lookup 토픽 생성 + Lookup Orders 액션 추가
Reference Action Type: API
Reference Action Category: External Services
Reference Action: List Orders
Inputs - Contact Email: Require Input to execute action
Outputs - 200: Show in conversationOutput이 200인 이유는 HTTP 200 OK 응답, 즉 API 호출 성공 시 반환되는 주문 데이터를 의미.
여기서도 Script에서 출력 타입 수동 수정이 필요했다. complex_data_type_name을 External Service에서 자동 생성된 Apex 타입 경로로 지정하고 Object 이름이 200 숫자로 되어있는 것을 문자열로 변경해주었다.
고객 검증 조건 + Get Customer Profile 추가
Order Lookup 토픽에서도 IsVerifiedCustomer == true면 주문 조회 실행, 아니면 Verify Customers로 전환하는 조건 로직을 동일하게 적용했다.
그리고 Get Customer Profile 액션을 먼저 실행해서 고객 이메일을 가져온 다음에 Lookup Orders에 넘기는 구조.
테스트
Can you show me my last 3 orders? 입력 → 인증 → Get Customer Profile → Lookup Orders 순서로 실행.
Interaction Details에서 API 호출 입력값/출력값까지 확인 가능.
오늘 배운 것 정리
Canvas ↔ Script 둘 다 쓸 줄 알아야 한다. Canvas만으론 안 되는 세부 설정이 있어서 Script로 직접 수정하는 경우가 꽤 중요하다.
에이전트 설계는 결국 흐름 설계다. 어떤 토픽이 있고, 각 토픽에서 어떤 액션을 실행하고, 조건에 따라 어디로 전환할지를 미리 그려놔야 막히지 않는다.
변수랑 조건 로직이 하이브리드 추론의 핵심이다. LLM이 알아서 판단하는 것 같아 보여도, 실제로는 변수와 조건으로 흐름을 명확하게 제어하고 있다. 이게 없으면 에이전트가 엉뚱한 상황에서 환불 처리를 해버릴 수도 있다.
External Services는 이번에 처음 써봤는데 꽤 유용하다. API 스펙만 등록하면 Salesforce가 알아서 연동 레이어를 만들어줘서, 외부 시스템이랑 붙일 때 직접 HTTP 코드 안 써도 된다는 게 편했다.
내일은 Data 360이랑 Prompt Builder를 한다고 한다. 오늘보다 더 많은 게 나올 것 같아서 이미 살짝 걱정됨 🚀
