420이라는 숫자는 서로 양립할 수 없는 두 가지 이유로 맞을 수 있습니다. 이 예시에서 두 에이전트는 같은 연락처 세그먼트를 반환하고 모두 고객 420명이라고 보고합니다. 하나는 승인된 매장 오디언스를 사용하고 동의를 확인했습니다. 다른 하나는 다른 워크스페이스의 오래된 내보내기 파일을 복사했는데 우연히 같은 숫자가 나왔습니다.
결과만 평가하면 둘 다 만점입니다. 잘못된 평가입니다.
에이전트 환경의 검증을 다룬 논의는 최종 출력과 거기에 이른 경로를 구분합니다. 스프레드시트 예시에서 올바른 숫자는 일의 일부일 뿐입니다. 수식, 출처 참조, 필수 서식도 중요합니다. 연동에서는 결과의 출처가 애초에 허용되는지 결정할 수 있어 차이가 더 중요합니다.
최종 값만으로는 출처를 증명할 수 없습니다
에이전트가 매장 고객 객체의 필드를 마케팅 시스템에 매핑한다고 가정합니다. email을 이메일에, firstName을 이름에, 동의 필드를 대상의 마케팅 상태에 연결합니다. 미리보기는 그럴듯합니다.
무엇을 읽고 선택했습니까? 현재 스키마입니까, 오래된 예제입니까, 다른 계정의 문서입니까? 동의 필드의 의미를 확인했습니까, 이름으로 추정했습니까? null을 “구독 안 함”으로 처리했습니까, “알 수 없음”으로 처리했습니까?
각 답은 같은 최종 매핑의 신뢰성을 바꿉니다. 매핑은 출력이고 증거 경로는 그것을 사용할 근거입니다.
그 경로에는 판단 당시 사용할 수 있었던 각 출처의 버전이 있어야 합니다. 나중에 수정된 스키마의 화면은 어제 제안된 매핑을 설명하지 못합니다. 관련 스키마나 문서 버전을 결정과 함께 기록하고 승인된 규칙에 연결해 둡니다. 목적은 에이전트가 본 모든 페이지를 저장하는 것이 아니라 결정을 다시 구성하는 것입니다.
그래서 도구 실행 기록은 자신감 있는 설명보다 중요할 수 있습니다. 기록에는 실제로 사용한 호출과 식별자가 남습니다. 글로 쓴 요약도 유용하지만 출처를 확인했다는 증거는 아닙니다. 연동의 증거는 원본 객체, 대상 계약, 데이터를 이동할 구체적인 규칙을 가리켜야 합니다.
업무 도구 연동 가이드가 필드 소유권에서 시작하는 이유는 양쪽의 이름만으로 권한이 정해지지 않기 때문입니다. 과정 검사는 에이전트가 쓰기를 제안하기 전에 그 소유권 결정을 실제로 확인했는지 묻습니다.
허용된 경로를 과제에 적습니다
좋은 테스트 사례에는 두 부분이 있습니다. 첫째, 대상에 있어야 할 내용을 정합니다. 둘째, 거기까지 가는 동안 허용되는 증거와 행동을 정합니다.
예시 세그먼트의 기대 결과는 연락처 420명일 수 있습니다. 하지만 승인된 경로에는 매장 범위로 한정된 조회, 현재 동의 매핑, 제외 레코드를 명시하는 미리보기도 필요할 수 있습니다. 워크스페이스를 넘나드는 읽기와 캠페인의 직접 전송은 금지할 수 있습니다.
이렇게 하면 검증기가 구체적으로 동작합니다. 다른 워크스페이스의 식별자를 기계적으로 거부하고 활성화 전 미리보기 호출 여부를 검사하며 출력에 적힌 데이터 출처와 실행 기록을 비교할 수 있습니다. 모델의 의견이 아닌 규칙입니다.
남은 질문에는 판단이 필요할 수 있습니다. 선택한 동의 필드가 정말 이 캠페인에 대한 허락을 뜻합니까? 이때 사람이나 좁은 결정 모델이 필드 정의와 사용 목적을 살펴야 합니다. 규칙과 판단은 서로 다른 일을 합니다.
그 결과 테스트는 유용한 실패 메시지를 줄 수 있습니다. “답이 틀림”만으로는 팀이 추측해야 합니다. “숫자는 맞지만 다른 워크스페이스의 읽기로 오디언스를 얻음”은 데이터 경계 실패입니다. “매핑은 맞지만 동의 정의가 없음”은 증거 누락입니다. 검증기는 실패 조건과 원인이 된 기록 항목을 알려 최종 문구가 아닌 경로를 고칠 수 있어야 합니다.
실행 기록은 무엇을 증명합니까?
-
승인된 출처와 필수 검사
경로 수용
결과에 과제가 요구한 증거가 있습니다.
-
다른 워크스페이스의 출처
경로 거부
같은 숫자라도 그 읽기를 허가하지는 않습니다.
-
필수 증거 없음
검토를 위해 보류
출력만으로 생성 경로를 증명할 수 없습니다.
실행 기록을 의식으로 만들지 않습니다
“에이전트가 필수 호출을 하고도 결과를 무시할 수 있다”는 반론은 옳습니다. 호출 목록은 호출이 있었다는 것만 증명하며 돌아온 증거가 결정에 쓰였다는 것은 증명하지 못합니다.
이를 시험하는 한 방법은 증거를 바꾸는 것입니다. 다른 조건은 비슷하고 동의 상태만 다른 두 레코드를 보여 줍니다. 에이전트가 같은 매핑과 설명을 준다면 출처 확인은 형식적일 수 있습니다. 또 필수 출처를 제거하고 멈추도록 요구할 수 있습니다. 기억으로 빈틈을 채우면 경로를 따른 것이 아닙니다.
테스트 자료를 만드는 데 일이 더 듭니다. 누군가는 허용된 출처, 구분해야 할 결과, 금지된 지름길을 정의해야 합니다. “답이 좋아 보이는가?”라는 일반 점수는 만들기 쉽지만 가르쳐 주는 바는 적습니다.
리버스 ETL은 매핑을 반복적인 데이터 이동으로 바꿉니다. 매핑이 승인되면 일반 코드가 매 행에 적용할 수 있으므로 에이전트가 매번 증거를 다시 살필 필요는 없습니다. 경로 감사는 규칙을 만들거나 바꾸는 결정과 계약 변화로 재검토가 필요한 시점에 수행합니다.
잘못된 계정에서 얻은 정답은 아까운 실패가 아니라 다른 일을 한 것입니다.
자주 묻는 질문
최종 답이 맞는데 경로를 왜 조사합니까?
에이전트가 허용되지 않은 데이터를 쓰거나 필수 검사를 건너뛰거나 우연히 맞을 수 있기 때문입니다. 출력만으로 안전하고 반복 가능한 경로였다고 증명할 수 없습니다.
모든 중간 행동을 사람이 검토해야 합니까?
아닙니다. 도구 호출을 기록하고 금지 행동에는 결정적 규칙을 적용합니다. 영향이 크거나 모호한 단계와 대표적인 실행 기록을 검토합니다.
팀은 어떻게 시험할 수 있습니까?
기대하는 최종 상태에 허용된 증거 출처와 필수 검사를 연결합니다. 지름길로도 같은 답을 낼 수 있는 사례를 다시 실행해 검증기가 거부하는지 확인합니다.