초록색 시험 결과가 빠진 규칙을 숨길 수 있습니다. 이 예시에서 에이전트는 매장을 이메일 플랫폼에 연결해야 합니다. 시험 서버가 연락처 업데이트를 받고 깔끔한 200 응답을 반환합니다. 에이전트는 일을 끝내고 시험에 합격합니다.
하지만 실제 대상 시스템에는 한 가지 규칙이 더 있습니다. 연락처 업데이트로 사용자 정의 속성을 설정하려면 그 속성을 먼저 선언해야 합니다. 시험 서버는 이 규칙을 모의하지 않았습니다. 초록색 결과는 시험 세계의 에이전트에 관해 무언가 증명하지만 실제 세계에서 빠진 규칙은 증명하지 못합니다.
이것이 시뮬레이션의 핵심 맞교환입니다. 위험하거나 비싼 행동을 반복할 수 있게 하는 대신 실제 시스템과 행동이 달라질 수 있는 두 번째 시스템을 만듭니다.
대체 환경이 행동 시험을 가능하게 합니다
행동하는 에이전트를 시험하려면 목표, 환경, 관찰 가능한 최종 상태를 줍니다. 에이전트의 모의 환경에 관한 출처는 브라우저와 지식 작업에서 이 구조를 설명합니다. 검증기는 환경을 통해 에이전트가 남긴 상태를 알려진 올바른 결과와 비교할 수 있습니다.
연동의 대체 환경은 대상 작업 몇 가지를 제공할 수 있습니다. 필드 목록, 연락처 생성과 업데이트, 읽어 오기입니다. 선언된 FNAME 필드와 존재하지 않는 CUSTOM_TIER 필드로 시험 자료를 만들 수 있습니다. 에이전트에게 매핑을 제안하게 한 뒤 정의 전에 CUSTOM_TIER를 쓰는 요청을 거부하도록 시험할 수 있습니다.
대체 환경은 매번 같은 상태에서 시작하므로 유용합니다. 누락된 필드, 거부된 허가, 오래된 스키마 버전, 모호한 식별자처럼 한 번에 한 조건만 바꿀 수 있습니다. 모델이나 프롬프트를 바꾸며 호출 순서와 결과 상태를 비교할 수 있습니다.
이는 에이전트가 무엇을 할지 글로 묻는 것보다 강합니다. 통제된 세계에서 실제로 무엇을 호출했는지 시험합니다.
시험 자료에는 정해진 응답뿐 아니라 호출 전후 상태를 넣습니다. 연락처를 두 번 만들면 두 번째 호출에서 시험하려는 중복 행동을 보여 줘야 합니다. 쓰기 후 필드를 읽으면 저장된 상태가 돌아와야 합니다. 그렇지 않으면 그럴듯한 요청만 보내도 합격하고 의도한 레코드가 만들어졌는지는 알 수 없습니다.
충실도도 시험의 일부입니다
“공급업체에 샌드박스가 있는데 왜 하나를 더 만드는가?”라는 반론은 타당합니다. 필요한 사례를 지원하고 데이터를 안전하게 보관한다면 공급업체 샌드박스를 사용합니다. 결정적으로 초기화하거나 의도적으로 오류를 만들거나 공식 샌드박스에서 마련할 수 없는 호출을 시험할 때 로컬 대체 환경이 가치가 있습니다. 유지 비용도 있습니다. 모의한 규칙마다 틀리거나 낡을 수 있습니다.
공식 Brevo 연락처 API는 속성이 계정에 존재해야 하고 선언된 형식에 맞지 않는 값은 무시된다고 말합니다. 모든 잘못된 값을 거부하는 대체 환경은 이 문서화된 경우와 다르게 행동합니다. 실제로 오지 않을 오류를 에이전트가 기대하게 만들 수 있습니다.
대체 환경이 다루는 공급업체 행동을 적어 둡니다. 실제 API나 공식 시험 환경을 상대로 작은 계약 확인 집합을 유지합니다. 차이가 발견되면 대체 환경을 업데이트하고 발견하게 한 사례를 추가합니다. 시뮬레이션은 공급업체의 모델이지 공급업체의 대체물이 아닙니다.
시간에도 같은 규율이 필요합니다. 모든 쓰기를 즉시 보이게 하는 대체 환경은 너무 빨리 읽는 워크플로를 놓칠 수 있습니다. 모든 쓰기를 늦추는 환경은 공급업체에 없는 실패를 만들어 낼 수 있습니다. 시험할 판단에 시간이 영향을 줄 때만 모의하고 나머지는 모의 범위 밖이라고 표시합니다. 합격의 뜻은 정확해집니다. 이 에이전트가 모의된 이 규칙에서 이 행동을 완료했다는 것입니다.
Tajo의 Brevo 커넥터 가이드는 매장 쪽에서 같은 실제 문제를 설명합니다. 요청은 성공해도 필드는 없을 수 있습니다. 시험은 HTTP 응답만 보지 않고 필드를 확인해야 유용합니다.
모의 대상 시스템은 모델링한 규칙 아래에서 에이전트를 시험합니다. 작은 계약 확인으로 그 규칙을 실제 대상과 비교한 뒤 범위가 좁은 미리보기를 실행합니다.
안전한 연습에서 제한된 현실 증거로 옮깁니다
시뮬레이션을 통과하면 작은 실제 미리보기를 진행합니다. 기대하는 대상 상태가 명확한 레코드 몇 건을 고릅니다. 일반 레코드, 선택 필드가 없는 레코드, 동의 상태상 마케팅에 쓸 수 없는 레코드를 포함합니다. 요청 내용만으로 추정하지 말고 대상이 실제로 저장한 것을 확인합니다.
합성 데이터 미리보기와 대상 확인은 서로 다른 질문에 답합니다. Tajo 매핑 미리보기는 대상에 쓰지 않고 변환을 시험합니다. 아래 제안 화면은 다음 경계를 보여 줍니다. 업데이트가 적용돼도 대상 상태를 확인해야 합니다. 대기 중 상태를 남겨 두면 예행연습을 증거로 오해하지 않습니다.
쓰기가 끝나도 증거는 필요합니다
고객 동기화가 끝났나요?
쓰기가 적용됐습니다. 검증은 대기 중입니다.
대상 시스템의 상태는 아직 확인하지 않았습니다.
동기화 활동
- 요청 수락됨
- 업데이트 적용됨
- 대상 확인 대기 중
실행 예시 · 14:32 UTC
확인된 내용
- 제공업체 응답
- 수락됨
- 쓰기 결과
- 적용됨
- 대상에서 다시 읽기
- 대기 중
호출 성공만으로 최종 상태를 증명할 수 없습니다.
Tajo 활동 피드를 참고한 제안 화면입니다. 이 그림의 검증 상태는 예시이며 대상에서 다시 읽는 기능이 이미 구현됐다는 뜻은 아닙니다.
미리보기의 범위는 좁고 멈춤 조건은 명확해야 합니다. 실패하면 광범위한 활성화를 막고 필드 정의, 식별자, 형식, 허가, 시간 중 어느 부분이 다른지 짚어야 합니다. 합격해도 미래의 모든 레코드가 같다는 증거는 아니지만 오늘 선택한 사례에서 계약이 동작한다는 증거는 됩니다.
이 순서는 두 질문을 분리합니다. 시뮬레이션은 “세계를 통제할 때 에이전트가 설계한 규칙을 따르는가?”를 묻습니다. 실제 미리보기는 “설계한 규칙이 이 공급업체 계정에 맞는가?”를 묻습니다. 하나가 다른 하나를 대신하지 못합니다.
리버스 ETL 가이드는 최종 작업이 많은 레코드에서 반복되는 이유를 설명합니다. 반복은 모의 계약과 실제 계약 사이에 남은 불일치를 키웁니다.
초기화할 수 있는 세계에서 연습하고, 초기화할 수 없는 세계를 확인합니다.
자주 묻는 질문
모의 대상 시스템에서는 무엇을 시험할 수 있습니까?
에이전트가 기대하는 호출을 고르고 허가를 지키며 알려진 오류를 처리하고 모의 환경에 기대 상태를 남기는지 시험할 수 있습니다.
무엇은 증명할 수 없습니까?
공급업체 모델이 완전하다는 사실은 증명할 수 없습니다. 문서화되지 않은 행동, 처리 시간, 계정별 설정이 시뮬레이션과 다를 수 있습니다.
시뮬레이션에 합격한 다음에는 무엇을 해야 합니까?
실제 대상에 범위를 제한한 미리보기나 소규모 시험을 수행하고 넓게 활성화하기 전에 결과 상태를 조사합니다.