1장. 에이전트를 만들었는데 왜 운영할 수 없는가

데모의 성공과 서비스의 성공은 다르다

한 번 좋은 답을 내놓은 것은 기능 시연이다. 같은 종류의 요청 1만 건에서 위험한 승인을 한 건도 만들지 않고, 실패를 분류하고, 비용을 예산 안에 유지하며, 사고를 재현해야 서비스가 된다. 이 차이를 메우는 활동을 이 책에서는 AgentOps라고 부른다.

AgentOps는 특정 제품명이 아니다. 모델과 프롬프트의 버전 관리, 입력·출력·도구 호출의 관찰, 평가 세트, 배포 게이트, 카나리, 사고 대응을 하나의 운영 루프로 묶는 방법이다. MLOps와 겹치지만 모델 학습 파이프라인에만 머물지 않는다. DevOps와 겹치지만 HTTP 200만으로 성공을 선언하지 않는다. 에이전트의 업무 결과와 권한 사용을 함께 검사한다.

고객 보상 심사를 예로 들어 보자. 서버는 정상 응답했지만 24만 원 요청을 자동 승인했다면 기술적으로 성공하고 업무적으로 실패했다. 반대로 모든 요청을 사람에게 넘기면 안전해 보이지만 자동화의 가치가 사라진다. 따라서 한 개의 숫자로 품질을 표현할 수 없다.

네 개의 운영 계약

첫째는 업무 계약이다. 어떤 요청이 승인·거절·추가 증거·수동 검토인지 정의한다. 둘째는 증거 계약이다. 그 결과를 재현하려면 어떤 버전과 사건을 남겨야 하는지 정한다. 셋째는 위험 계약이다. 평균 정확도가 높아도 절대 허용하지 않을 실패를 따로 정의한다. 넷째는 비용 계약이다. 한 건 성공에 드는 토큰, 시간과 재시도 횟수의 상한을 정한다.

이 책의 첫 번째 불변 조건은 다음과 같다.

예상 결과가 approve가 아닌 요청을 자동 승인한 횟수는 반드시 0이어야 한다.

정확도 95%보다 이 조건이 먼저다. 100건 중 95건을 맞혀도 나머지 5건이 모두 잘못된 환불이라면 배포할 수 없기 때문이다.

첫 실행

npm run lab:eval

예상 결과의 핵심은 다음과 같다.

{
  "total": 6,
  "exact": 6,
  "accuracy": 1,
  "unsafeApprovals": 0,
  "piiLeaks": 0,
  "pass": true
}

fixture가 여섯 건이라 정확도 1은 제품 성능을 자랑하는 수치가 아니다. 평가 배관이 올바르게 연결되었음을 확인하는 스모크 테스트다. 실제 팀은 고객 문의 분포를 반영한 수백·수천 건으로 확장해야 한다.

완료 기준

• 기능 성공과 업무 성공의 차이를 자신의 서비스 예로 설명할 수 있다.
• 평균 정확도와 위험 승인 수를 별도 지표로 두는 이유를 안다.
• build/eval-report.json에서 기준 평가 결과를 확인했다.