브라우저에서 100단계를 거치는 작업을 예로 들어 보겠습니다. 각 단계가 다른 단계와 독립적으로 99%의 확률로 성공한다고 가정합니다. 모든 단계가 성공할 확률은 0.99^100, 약 36.6%입니다.
99%는 매우 좋아 보이지만 36%는 그렇지 않습니다.
브라우저의 거래형 작업을 다룬 논의는 이 계산으로 좁은 요점을 보여 줍니다. 고객은 작업이 완료될 때 가치를 얻지만 비용과 실패 위험은 단계마다 쌓입니다. 이는 가정에 따른 산술이며 특정 브라우저 에이전트나 Tajo 동기화의 발표된 성공률이 아닙니다. 실제 오류는 서로 연관될 수도 있습니다. 한 번의 로그인 만료가 이후 여러 작업을 함께 실패시킬 수 있습니다.
따라서 유용한 질문은 “모델의 마지막 클릭은 얼마나 정확했는가?”가 아닙니다. “사용자가 요청한 상태가 실제로 나타났는가?”입니다.
중요한 단위는 거래 전체입니다
에이전트가 보험 포털을 열어 문서를 찾고 다운로드한 다음 올바른 계정의 문서인지 확인한다고 가정합니다. 99개 화면을 정확히 지나도 100번째에서 잘못된 파일을 받으면 실패입니다. 성공한 클릭으로 가득한 로그도 결과를 고치지 못합니다.
연동에서도 마찬가지입니다. 에이전트는 API를 찾고 필드 매핑을 제안하며 초안을 저장할 수 있습니다. 하지만 어느 것도 대상 시스템의 연락처가 의도한 동의 상태에 도달했다는 뜻은 아닙니다. 승인된 작업이 실행되고 관련 사후 조건이 확인되어야 일이 끝납니다.
이는 활동과 완료의 차이입니다. 활동은 세기 쉽지만 완료에는 정의가 필요합니다.
파일 다운로드라면 요청과 일치하는 계정 번호가 있는 결과물이 증거일 수 있습니다. 연락처 동기화라면 올바른 식별자, 필드, 허용된 메시지 상태를 가진 대상 레코드일 수 있습니다. 검사는 사용자가 중요하게 여긴 대상을 확인해야 합니다. 앞선 호출의 성공 응답은 호출이 돌아왔다는 증거일 뿐, 대상이 의도대로 바뀌었다는 증거는 아닐 수 있습니다.
Tajo의 업무 도구 연동 가이드는 워크플로와 데이터 객체별 기준 시스템에서 시작합니다. 이 선택이 최종 확인의 의미를 결정합니다. 두 시스템이 같은 필드의 소유권을 주장한다면 쓰기를 완벽하게 수행해도 장기 상태는 잘못될 수 있습니다.
판단을 하나 더하는 비용
가상의 단계별 성공률 99%를 그대로 적용하면 독립적인 판단 10번의 전체 성공률은 약 90.4%, 50번은 약 60.5%, 100번은 약 36.6%입니다.
전체 성공 확률(%)
독립적인 단계 수
- 단계별 성공률 99% 가정
계산된 값 확인
| 단계 | 전체 성공률(%) |
|---|---|
| 0 | 100.0 |
| 10 | 90.4 |
| 25 | 77.8 |
| 50 | 60.5 |
| 75 | 47.1 |
| 100 | 36.6 |
평균이 좋아도 곱셈은 봐주지 않기 때문에 곡선은 가파릅니다. 추가되는 판단마다 존재할 이유가 있어야 합니다.
그렇다고 모든 API 호출을 하나의 거대한 작업으로 합치라는 뜻은 아닙니다. 알려진 커서로 페이지를 가져오거나 식별자를 비교하고 승인된 매핑에 따라 필드를 쓰는 호출은 결정적입니다. 레코드마다 모델이 다시 판단할 필요가 없습니다. 반면 새 공급업체 필드, 바뀐 오류 문구, 담당자가 불명확한 요청에는 실제 모호함이 있으므로 판단이 필요할 수 있습니다.
실무에서는 판단으로 규칙을 설계하거나 복구하고 안정된 규칙은 일반 코드가 적용하게 합니다. 리버스 ETL은 반복되는 데이터 이동의 한 예입니다. 일상적인 각 행의 작업은 대화가 아니라 파이프라인이 수행해야 합니다. 에이전트는 파이프라인이 무엇을 해야 할지 정하는 데 여전히 도움을 줄 수 있습니다.
이는 구호가 아닌 경계입니다. 공급업체가 필드의 의미를 바꾸면 결정적 규칙이 잘못된 작업을 완벽하게 반복할 수 있습니다. 전제가 바뀐 사실을 감지하고 해당 사례를 검토로 돌릴 방법이 필요합니다.
거대한 도구 하나가 답이 아닌 이유
“긴 체인이 실패한다면 작업 전체를 한 번의 도구 호출 뒤에 넣자”는 반론은 타당합니다. 확인 가능한 결과를 가진 명확한 거래라면 도움이 됩니다. 하지만 길고 불확실한 과정을 숨기기만 한다면 실패합니다.
syncCustomer()가 업데이트를 보낸 직후 success: true를 반환한다고 가정합니다. 대상 시스템이 업데이트를 나중에 처리한다면 그 호출은 아직 최종 연락처 상태를 증명하지 못합니다. 보이는 단계만 줄었을 뿐 불확실성은 줄지 않았습니다.
더 나은 인터페이스는 중요한 상태를 드러냅니다. 접수, 적용, 확인, 실패가 그것입니다. 각 표현에는 대응하는 증거가 있어야 합니다. 영향이 작은 미리보기에는 쓰기 접수만으로 충분할 수 있습니다. 캠페인 오디언스나 동의 상태의 변경은 완료라고 부르기 전에 대상을 확인해야 합니다.
이 Tajo 제안 화면에서는 요청 수락과 업데이트 적용을 검증된 대상 상태와 구분합니다. 마지막 확인은 아직 대기 중입니다. 다음 행동은 대상에 무엇이 저장됐는지 조사하는 것입니다. 성공한 도구 호출을 하나 더 세어도 원래 질문에는 답하지 못합니다.
쓰기가 끝나도 증거는 필요합니다
고객 동기화가 끝났나요?
쓰기가 적용됐습니다. 검증은 대기 중입니다.
대상 시스템의 상태는 아직 확인하지 않았습니다.
동기화 활동
- 요청 수락됨
- 업데이트 적용됨
- 대상 확인 대기 중
실행 예시 · 14:32 UTC
확인된 내용
- 제공업체 응답
- 수락됨
- 쓰기 결과
- 적용됨
- 대상에서 다시 읽기
- 대기 중
호출 성공만으로 최종 상태를 증명할 수 없습니다.
Tajo 활동 피드를 참고한 제안 화면입니다. 이 그림의 검증 상태는 예시이며 대상에서 다시 읽는 기능이 이미 구현됐다는 뜻은 아닙니다.
측정 방식도 달라집니다. 시도 횟수가 비용 진단에 도움이 되면 기록하고, 중간 오류가 고장 난 단계를 찾는 데 도움이 되면 기록합니다. 그러나 워크플로는 확인 방법을 숫자 곁에 적은, 검증된 완료 거래로 평가해야 합니다. “호출의 99%가 성공했다”는 보고로는 고객의 일이 끝났는지 알 수 없습니다.
MCP 서버 설명은 도구를 통해 어시스턴트가 다른 시스템을 호출하는 방식을 보여 줍니다. 도구 접근은 시작에 불과합니다. 계약에서 중요한 것은 뒤에 남는 상태입니다.
올바른 클릭 100번 뒤에도 아무것도 남지 않을 수 있습니다. 결과를 세어야 합니다.
자주 묻는 질문
대부분의 단계가 정확한데 긴 워크플로는 왜 실패합니까?
각 단계가 독립적으로 확률 p로 성공한다면 n단계 전체의 성공 확률은 p의 n제곱입니다. 단계마다 99%라고 가정하면 100단계의 완료율은 약 36.6%입니다. 실제 실패에는 상관관계가 있을 수 있으므로 에이전트의 실측 성공률이 아닌 예시입니다.
도구 호출을 줄이면 신뢰성이 반드시 좋아집니까?
아닙니다. 합친 작업에서도 적절한 확인과 복구 지점이 드러날 때만 도움이 됩니다. 불투명한 호출 하나도 긴 체인처럼 실패한 쓰기를 숨길 수 있습니다.
팀은 에이전트 워크플로에서 무엇을 측정해야 합니까?
모델 호출의 성공만이 아니라 사용자의 거래가 검증을 거쳐 완료되었는지 측정합니다. 완료를 증명하는 결과물이나 대상 상태를 정의하고 전체 워크플로 뒤에 나타나는 비율을 기록합니다.