Prompt Builder(프롬프트 빌더) 템플릿은 프로덕션 설정처럼 움직입니다. 템플릿 하나를 바꾸면 고객 이메일, 생성된 필드 값, 에이전트의 답이 함께 바뀌고, 그 변경이 아무 검토 없이 적용될 수도 있습니다. 스폰서나 관리자 책임자가 프롬프트를 직접 쓸 필요는 없습니다. 각 템플릿의 소유자, 템플릿이 읽을 수 있는 데이터, 시험 방법, 수정 권한자, 사용자에게 알릴 출력의 성격을 알면 됩니다.
템플릿마다 소유자, 그라운딩 소스마다 소유자
각 템플릿에는 출력을 책임지는 업무 소유자와 설정을 책임지는 관리자 소유자가 필요합니다. Sales Email 템플릿이 무엇을 말해도 되는지는 영업 운영 책임자가, 케이스 요약에 무엇이 들어갈지는 서비스 책임자가 정합니다. 관리자 소유자는 버전, 권한, 릴리스를 맡습니다.
그라운딩 데이터에도 소유자가 필요합니다. 템플릿에 들어가는 병합 필드, 관련 목록, Flow, Apex 클래스는 모두 의존 관계이고, 그 소유자는 해당 데이터가 최신인지 아는 사람입니다. 필드 열다섯 개를 끌어오는 템플릿은 의존 관계도 열다섯 개입니다. 목록을 요구하고, 소스마다 근거를 요구합니다. 정해 둔 행동이 나아진다는 시험 결과가 있을 때만 소스를 추가합니다. 맥락을 더하면 오래된 값, 서로 어긋나는 값, 더 넓은 노출도 함께 들어오고, 답이 저절로 좋아지지는 않습니다.
템플릿에는 한 가지 목적만 맡깁니다. “계정 이력을 요약하고, 다음 행동을 제안하고, 위험을 찾는” 템플릿은 이름 하나 아래 템플릿 세 개가 들어 있는 셈입니다. 나누면 부분마다 소유자와 시험 세트가 하나씩 생깁니다. 그다음 출력을 쓰는 곳을 기록합니다. Flow, Action, 생성 필드, 화면, 에이전트입니다. 에이전트가 호출하는 Flex 템플릿은 둘을 묶습니다. 템플릿만 되돌리고 그 템플릿을 부르는 에이전트 설정은 그대로 두면, 또는 그 반대로 하면, 동작이 시험한 내용과 어긋납니다.
템플릿이 읽을 수 있는 데이터
ADX201을 가르칠 때 보안 모듈은 한 가지 원칙에서 출발합니다. 사용자는 프로필, 권한 집합, 공유 설정이 허용하는 만큼만 봅니다. 템플릿은 누군가를 대신해 레코드를 읽으므로, 관리할 질문은 데이터를 가져올 때 누구의 권한을 쓰는가입니다. 그라운딩 소스마다 답을 요구합니다. 병합 필드, Flow, Apex 클래스가 반드시 같은 권한으로 실행되지는 않고, 관리자가 돌리는 데모로는 그 차이가 보이지 않습니다.
그리고 시험합니다. 샌드박스에서 특정 필드를 보면 안 되는 사용자로 템플릿을 실행하고, 출력에 그 필드 내용이 드러나지 않는지 확인합니다. 사용자 권한과 상관없이 어떤 템플릿도 병합하면 안 되는 필드 목록을 짧게 유지합니다.
출력이 저장되는 곳도 봅니다. 제한된 메모를 요약해 더 많은 사람이 보는 필드에 쓰는 Field Generation 템플릿은 그 내용을 해당 필드를 보는 모든 사람에게 다시 공개합니다. 저장된 출력은 원본 소스의 규칙과 상관없이 그 출력을 담은 필드의 접근 규칙을 따릅니다.
릴리스 전에 승인된 시험 세트
템플릿은 시험 세트를 통과한 뒤에 운영에 올립니다. 좋은 예시 세 개로는 부족합니다. 세트에는 정상 케이스, 빈 필드, 서로 어긋나는 소스, 접근 권한이 없는 사용자, 범위 밖 요청, 민감한 내용, Instruction을 무력화하려는 시도가 들어갑니다. 케이스마다 입력, 실제로 채워진 맥락, 합격 기준을 저장합니다. 합격 기준은 구조, 허용된 사실, 필수 필드, 금지 내용입니다. 올바른 표현이 여러 개일 수 있으므로 문장을 글자 그대로 비교하는 기준은 쓰지 않습니다.
업무 소유자는 출력을 읽은 뒤가 아니라 릴리스 전에 케이스와 기대 결과를 승인합니다. 통제된 거절은 합격입니다. 통화 기록에 고객의 고충이 나오지 않을 때 “확인되지 않음”을 쓰는 생성 필드는 올바른 출력이고, 나중에 사람이 다시 볼 레코드를 찾을 때 조회할 수 있는 값이 됩니다. 근거 없이 매끄러운 답은 불합격입니다.
Prompt Performance Metrics는 Data 360 Calculated Insights를 쓰는 베타 기능으로 문서화돼 있고, 크레딧 소비를 늘릴 수 있습니다. 시험 세트 옆에 두는 원격 측정으로 쓰고, 릴리스 관문을 대신하게 하지 않습니다.
버전, 릴리스 주기, 프로덕션 수정 권한
템플릿 변경에는 소유자, 이유, 새 버전, 시험 실행, 되돌림 경로가 있어야 합니다. 되돌림은 이전 문구를 복원하는 데서 끝나지 않습니다. 문제가 있던 버전이 활성화된 동안 저장된 출력과 실행된 Action을 찾아야 합니다.
검토 주기는 조직이 이미 따르는 릴리스 일정에 맞춥니다. Salesforce는 해마다 세 번 릴리스를 내고, 봄에 통과한 템플릿도 아무도 고치지 않은 채 다음 릴리스 뒤에 다르게 동작할 수 있습니다. 저는 같은 이유로 교육 전에 모든 실습을 다시 해 봅니다. 시험 세트도 수정할 때만 돌리지 않고 릴리스마다 다시 돌립니다.
프로덕션 수정은 다른 메타데이터와 같은 경로로 갑니다. 샌드박스에서 바꾸고, 시험하고, 배포합니다. 템플릿을 만들고 수정할 수 있는 사람은 짧은 명단으로 관리합니다. 템플릿을 실행하는 권한과 수정하는 권한은 따로 있고, 대부분의 사용자에게는 실행 권한이면 충분합니다.
Einstein Trust Layer 설정과 사용자 안내
Einstein Trust Layer 설정은 모든 템플릿에 걸쳐 적용됩니다. 그래서 소유자는 플랫폼 책임자이고, 이 설정의 변경도 같은 검토를 거칩니다. 슬라이드 대신 Setup 화면에서 직접 보여 달라고 요청하고, 적어도 다음을 확인합니다.
- 데이터 마스킹: 프롬프트가 Salesforce 밖으로 나가기 전에 어떤 데이터 유형을 가리는지, 그 설정이 어느 기능에 적용되는지
- 감사 기록: 프롬프트와 응답이 저장되는지, 얼마나 보관되는지, 누가 읽을 수 있는지
- 유해성 감지: 점수가 기록되는지, 표시된 출력을 누가 검토하는지
사용자는 출력이 무엇이고 무엇이 아닌지 알아야 합니다. 출력은 정해진 필드로 만든 초안입니다. 검증된 사실, 상업적 약속, 법률 의견은 아닙니다. 저장하거나 보내기 전에 무엇을 확인할지, 잘못된 출력을 어떻게 신고해 템플릿 소유자에게 전달할지 알려 줍니다. 고객에게 나가는 글은 보낸 사람이 끝까지 책임집니다.
확인할 항목
- 활성 템플릿마다 업무 소유자와 관리자 소유자의 이름이 있습니까?
- 관리자 소유자가 템플릿의 그라운딩 소스를 모두 나열하고, 각 소스가 누구의 권한으로 실행되는지 말할 수 있습니까?
- 마지막 릴리스 전에 업무 소유자가 시험 세트를 승인했습니까?
- 프로덕션에서 템플릿을 수정할 수 있는 사람은 몇 명이고, 이름이 정해져 있습니까?
- Trust Layer 설정을 마지막으로 검토한 날짜와 검토자를 댈 수 있습니까?
- 사용자는 출력을 저장하거나 보내기 전에 무엇을 확인해야 하는지 압니까?