도구 결과가 충돌하면 누구 말을 들어야 하나
핵심은 권위 소스(Source of Truth)와 일관성 거버넌스다.
권위 소스, 데이터 시간, 업무 기준, 상태 버전, 조작 장면 다섯 차원으로 규칙 기반 재정을 해야 한다. 재정할 수 있으면 재정하고, 재정할 수 없으면 일시정지하고 충돌을 노출한다.
도구 반환은 증거로 다루어야지 전부 진리로 다루면 안 된다.
OpenAI의 도구 호출(function calling)은 「모델이 외부 시스템에 접근할 수 있다」만 해결할 뿐, 도구가 반환한 뒤 어떻게 판단할지는 여전히 업무 규칙 설계가 필요하다.
다섯 가지 판단 근거 + 한 가지 금령
순서대로 다음 다섯 가지를 먼저 볼 것:
- 권위 소스
- 데이터 시간(타임스탬프)
- 업무 기준(口徑)
- 상태 버전
- 조작 장면
Agent의 핵심 금기: 자연어적 선호로 「합리적으로 보이는」 결과를 고르는 것을 금지한다. 반드시 명확한 규칙과 사실에 근거해야 한다.
같은 상품, 두 종류의 질문, 두 개의 권위 소스
| 사용자 질문 | 검색 인덱스 | 재고 서비스 | 누구를 믿을 것인가 |
|---|
| 「이 상품 지금 살 수 있나요?」 | 재고 있음 (5분마다 갱신) | 없음 (실시간 차감 소스) | 재고 서비스 |
| 「상품 설명이 무엇인가요?」 | — | — | 상품 마스터 데이터 (재고 서비스보다 권위 있음) |
결론: 권위 소스는 질문 유형별로 정의해야 하며, 전역적으로 가장 권위 있는 도구 하나는 존재하지 않는다.
3대 고빈도 함정
| 함정 | 증상 | 올바른 대응 |
|---|
| 1. 타임스탬프 무시 | 도구가 낡은 데이터를 반환했는데 포맷이 예쁘다고 새 데이터를 덮어쓰면 안 됨 | 결과에 타임스탬프를 강제하고 신선도로 비교 |
| 2. 기준 무시 | 주문 금액 / 결제 금액 / 환불 후 금액 / 청구서 금액이 모두 맞을 수 있지만, 서로 다른 질문에 써야 할 필드가 다름 | 「도구를 더 호출해 교차 검증하자」만 답하지 말고 Source of Truth를 보충할 것 |
| 3. 충돌 전략 부재 | 도구 A와 도구 B가 충돌할 때 처치 로직이 없음 | 충돌을 기록하고, 불확실을 표기하고, 고위험 동작의 계속 실행을 회피 |
환불 전 주문 상태와 결제 상태가 불일치하면 Agent가 스스로 하나를 골라 환불을 계속하게 두면 안 되고, 사람 또는 백엔드 보상 큐로 진입해야 한다.
한 문장 정리
각 질문 유형마다 권위 도구와 필드 기준을 정의하고, 도구 결과에는 모두 타임스탬프, 버전, 출처를 붙인다. 충돌 시에는 먼저 권위 등급과 신선도로 재정하고, 재정할 수 없으면 실행을 거부하고 충돌 증거를 제시한다. 고위험 작업에서는 충돌 자체가 차단 조건이다. 동시에 Trace로 호출 링크를 남긴다.
핵심 통찰
- 「종합적으로 판단한다」는 스스로 아마추어임을 증명하는 말이다 — 그것은 확정적인 거버넌스 문제(누가 진리의 소스인가)를 확률적인 언어 문제로 바꿔치기한다. 이 바꿔치기를 식별할 수 있는지가 바로 시험대다.
- 신뢰도는 도구의 속성이지 결과의 속성이 아니다 — 누구를 믿을지 판단할 때 어느 결과가 「읽기에 더 합리적인가」를 보면 안 되고, 그것을 산출한 도구의 갱신 빈도, 기준 귀속, 권한 범위를 봐야 한다. 신뢰도는 반드시 시스템 설정에 사전 선언되어야지 런타임에 모델이 임시로 평가하면 안 된다.
- 권위 소스는 질문 유형별로 정의해야지 도구별 전역 순위를 매기면 안 된다 — 같은 상품에 대해 「살 수 있는가」를 물으면 재고 서비스가 권위 있고, 「설명이 무엇인가」를 물으면 상품 마스터 데이터가 권위 있다. 즉 권위 테이블의 입도는 「질문 유형 × 필드」이지 「도구」가 아니다.
- 재정할 수 없을 때의 올바른 출력은 「멈춤」이지 「추측」이 아니다 — 대부분의 Agent 사고는 모르기 때문이 아니라, 모르는데도 계속 실행했기 때문에 발생한다. 「일시정지 + 충돌 노출」을 일급 반환값으로 설계하면 신뢰성이 즉시 한 단계 올라간다.
- 고위험 동작에서는 충돌 자체가 차단 조건이다 — 누가 맞는지 먼저 판단할 필요가 없다. 환불 전에 주문 상태와 결제 상태가 불일치하기만 하면 사람/보상 큐로 전환해야 한다. 이는 「일관성 검사」를 사후 대사가 아니라 전치 관문으로 삼는 것이다.
- 다중 도구가 늘리는 것은 증거이지 진리가 아니다 — 교차 검증의 이득은 「기준 관리가 있다」는 전제에 의존한다. 기준 관리가 없으면 도구를 더하는 것은 모순을 확대할 뿐이다. 다중 소환, 다중 모델 투표 등 모든 「다중 소스」 장면에 그대로 이식할 수 있다.
- 기준 충돌은 흔히 「넷 다 맞는」 경우다 — 주문 금액, 결제 금액, 환불 후 금액, 청구서 금액은 모두 틀린 숫자가 아니다. 틀린 것은 어느 것을 쓸지 명확히 하지 않은 것이다. 데이터류 시스템에서 가장 찾기 어려운 버그는 흔히 틀린 값이 아니라 맞는 값에 틀린 기준을 적용한 것이다.
- 단발 충돌은 공학 문제고 반복 충돌은 거버넌스 문제다 — 충돌 샘플을 적립하고 귀인(동기화 지연 / 캐시 만료 / 기준 불일치 / 권한 필터링)해 데이터 거버넌스 프로세스로 환류시켜야 한다. 그렇지 않으면 매번 Agent에게 같은 기준 문제를 현장에서 처리시키는 것이며, 영원히 기술 부채를 갚고 있는 셈이다.
엔지니어링 실전 Tips
- 타임스탬프는 가장 저렴한 재정 무기다: 모든 도구 결과에 타임스탬프만 붙어 있으면 충돌의 절반 이상을 신선도로 무난히 해결할 수 있다. 타임스탬프가 없으면 어떤 재정도 도박이다.
- 「기준」을 필드명이나 메타데이터에 써넣을 것: 특히 금액류 필드는 order_amount / paid_amount / refunded_amount / invoice_amount로 구분해 하류가 글자 뜻으로 함부로 쓰는 것을 막을 것.
- 권한 필터링은 데이터 충돌로 위장한다: 같은 인터페이스가 권한 주체에 따라 다른 결과를 반환하면 데이터 불일치처럼 보이지만 실은 scope 차이다. 귀인 시 반드시 이 유형을 별도로 분류할 것.
- Agent에게 마스터 데이터를 고치게 하지 말 것: 문제를 발견하는 것과 문제를 수정하는 것은 서로 다른 권한 등급이며, Agent는 전자만 담당한다.
- 사용자에게 「명확히 설명된 충돌」을 주지 「거짓 확신의 답」을 주지 말 것: UX상 「재고 서비스는 없다고 표시하는데 검색 결과가 아직 갱신되지 않았습니다」가 자신만만한 「있습니다」 한 마디보다 훨씬 낫다.
- 답변의 가점 구조: 판단 근거(권위 소스/신선도/기준) → 처치(재정/차단) → 증거(Trace, 충돌 증거) → 거버넌스(샘플 적립). 이 네 층을 다 말하면 상용 시스템을 다뤄봤다는 판단을 받을 수 있다.