2장. ClaimOps의 업무 경계부터 고정하라

모델보다 먼저 상태를 정의한다

에이전트 프로젝트가 흔들리는 가장 큰 이유는 프롬프트가 짧아서가 아니라 “성공”의 의미가 사람마다 다르기 때문이다. 운영자는 추가 증거 요청을 성공적인 처리로 보지만, 대시보드를 만든 개발자는 승인만 성공으로 셀 수 있다. 상태를 먼저 고정하면 이 오해를 줄일 수 있다.

fixtures/policies.json에는 자동 승인 한도 5만 원, 수동 검토 한도 20만 원, 신청 가능 기간 14일과 사유별 필수 증거가 들어 있다. 숫자는 가상 정책이다. 실제 서비스에서는 법무·재무·CS 책임자가 승인한 정책 저장소에서 가져와야 한다.

이 장의 단순 판정기는 autoApproveLimit, requiredEvidence, maxRequestAgeDays만 실행에 사용한다. fixture의 manualReviewLimit과 receiptRequiredAbove는 뒤 장에서 정책 확장 지점을 토론하기 위해 남긴 예약 필드이며 현재 코드가 강제하지 않는다. 따라서 20만 원 초과 요청이나 영수증 의무를 이 예제가 막아 준다고 가정하면 안 된다. 운영 전에는 두 필드를 실제 판정과 테스트에 연결하거나 스키마에서 제거한다.

{
  "autoApproveLimit": 50000,
  "requiredEvidence": {
    "duplicate_charge": ["payment_ids"],
    "delivery_damage": ["photo_id", "receipt_id"],
    "service_outage": ["incident_id"]
  },
  "maxRequestAgeDays": 14
}

자연어 정책의 함정

“소액은 자동 승인할 수 있다”는 문장은 프로그램이 실행할 수 없다. 소액의 기준, 증거가 없을 때의 처리, 신청 기간, 예외 승인자를 모른다. 프롬프트에 긴 정책 문서를 붙이는 것만으로는 해결되지 않는다. 모델이 읽은 정책과 실행 코드의 한도가 달라질 수 있기 때문이다.

이 책은 역할을 나눈다. 모델은 고객 문장을 reason과 증거 후보로 구조화한다. 애플리케이션은 허용 사유, 기한, 증거, 금액을 순서대로 판정한다. 환불 실행기는 승인 결과와 별도의 권한 경계를 가진다. 이렇게 하면 모델이 “고객이 매우 불편해 보인다”고 판단해도 금액 한도를 우회할 수 없다.

결정 표를 직접 읽기

표의 순서도 계약이다. 14일을 넘긴 요청은 증거가 충분해도 거절된다. 애플리케이션과 평가 데이터가 같은 순서를 사용해야 한다.

실습: 경계값을 말로 설명하기

npm run lab:run -- CLM-1002

CLM-1002는 배송 파손, 8만 8천 원, 사진과 영수증을 모두 갖췄다. 결과는 manual_review다. 증거가 충분하다는 사실과 자동 승인 한도를 넘었다는 사실은 동시에 참이다. “증거 충분”을 곧바로 “승인”으로 연결하면 위험한 단축 규칙이 된다.

운영 판단

정책 버전은 날짜나 배포 태그로 식별해야 한다. 과거 요청을 재생할 때 현재 정책을 적용하면 당시 결정이 재현되지 않는다. 규정이 바뀌었을 때 과거 건을 재심사할지 여부도 별도의 비즈니스 결정이다.

완료 기준

• 네 개 상태의 의미와 후속 행동을 설명할 수 있다.
• 모델이 맡을 일과 결정적 코드가 맡을 일을 나눴다.
• 경계 금액과 정책 적용 순서를 테스트 사례로 적을 수 있다.