목록으로

Evaluation and Guardrails

평가와 가드레일

신뢰와 검증OCLS SHARPEN

허용되는 판단과 위험한 판단을 평가 기준과 안전 규칙으로 구분한다.


Context

에이전트가 스스로 판단하고 실행하면 결과 품질을 나중에 확인하는 것만으로는 부족하다. 시스템이 커질수록 '좋은 실행'과 '위험한 실행'의 기준이 흐릿하면 품질 편차가 벌어지고, 사고가 나도 원인을 분석하기 어렵다.

Problem

평가 기준이 없으면 에이전트의 출력 품질을 정량으로 비교할 수 없고 모듈 교체나 프롬프트 변경의 효과도 잴 수 없다. 가드레일이 없으면 에이전트가 비용 한도를 넘기거나 허용되지 않은 외부 API를 부르거나 민감한 데이터를 드러내는 위험을 미리 막을 길이 없다.

Forces

  • 평가 기준이 빡빡하면 안전한 대신 에이전트의 자율성이 줄고, 느슨하면 위험이 커진다.
  • 사전 가드레일은 위험을 미리 막지만 정상 실행까지 막을 수 있고, 사후 평가는 이미 벌어진 문제를 되돌리기 어렵다.
  • 자동 평가는 빠른 대신 미묘한 품질 차이를 놓치고, 인간 평가는 정확하지만 느리다.

Solution

각 에이전트와 모듈에 정량 평가 기준(성공률, 응답 품질 점수, 비용 효율)과 안전 가드레일(비용 한도, 권한 범위, 금지 동작 목록)을 함께 부여한다. 가드레일은 실행 전에 검증하고 평가는 실행 후에 한다. 평가 결과가 기준에 못 미치면 자동 알림이나 실행 중단 정책을 건다. 비결정적 에이전트를 평가할 때는 pass@k(k번 중 1회 이상 성공 확률)와 pass^k(k번 모두 성공 확률)를 갈라야 한다. 도구로 쓸 때는 pass@k가 맞지만, 고객 대면 서비스는 일관성이 관건이라 pass^k가 핵심 지표다. 또 평가는 capability eval(낮은 통과율, 어려운 과제)과 regression eval(100% 유지, 퇴행 감지)로 나눈다. capability eval이 꾸준히 높은 통과율에 이르면 regression eval로 '졸업'시키는데, 이 졸업 시점이 OCLS 루프에서 경계가 안정됐다는 신호가 된다.

판단 질문

품질과 리스크를 어떤 기준으로 측정할 것인가?

적용 시나리오

예시 시나리오 — 본 페이지의 수치와 기업명은 패턴 설명을 위한 가상 사례이며, 실측 데이터가 아닙니다.

QA Agent가 Response Agent의 출력을 평가한다. 평가 기준: 응답 관련성 점수 ≥ 0.8, 어조 일관성 ≥ 0.7, 할루시네이션 탐지 = false. 사전 가드레일: 개인정보(주민번호, 카드번호) 포함 시 즉시 차단, 응답 길이 500자 초과 시 요약 요청, 외부 URL 포함 시 허용 도메인 목록 대조. 사후 평가: 일일 응답 품질 분포를 따라가다 평균이 0.75 아래로 떨어지면 운영팀에 알린다. 이 구조 덕분에 프롬프트를 바꿨을 때 품질 변화를 정량으로 비교하고, 변경 전후로 A/B 테스트를 돌릴 수 있다.

이렇게 하면 무너진다

평가 기준 없이 운영하면 '요즘 고객 불만이 늘었는데 원인을 모르겠다'는 상황이 되풀이된다. 가드레일 없이 운영하면 에이전트가 고객의 카드 번호를 응답에 끼워 넣거나 있지도 않은 환불 정책을 안내하는 사고가 뒤늦게야 드러난다. 두 경우 모두 시스템을 향한 신뢰가 빠르게 무너진다.

구현 패턴 연결

  • Generator-Critic
  • Evaluator-Optimizer

생성 에이전트의 출력을 검증 에이전트가 평가하는 구조. 사전 가드레일은 실행 전 차단, 사후 평가는 Generator-Critic 루프로 구현한다.

Academic References

  • Beyond Task Completion: An Assessment Framework for Evaluating Agentic AI Systems — arXiv 2512.12791
  • AI Governance by Design for Agentic Systems — Preprints.org

이 패턴을 적용하기

저장소에서 리뷰 스킬을 사용하고, 관련 아티클의 구현 결정과 비교한다. 각 예제를 자신의 권한, 데이터, 실패 조건에 맞춰 검토한다.

관련 구현 기록

  • 프로젝트끼리 비교하며 설계를 배우는 법개발 원칙이 다른 프로젝트를 함께 운영하고, 문제를 먼저 해결한 프로젝트를 기준으로 현재 설계를 리뷰한다. 차이에서 개선 가설을 찾아 검증하고 기록하는 교차 설계 리뷰 절차를 정리한다.
  • 토큰 전략 — 효율·밸런스·공격적, 그리고 인력 배분토큰을 아끼는 것과 태우는 것은 둘 다 전략이다. 같은 루프를 효율·밸런스·공격적 세 모드로 다르게 운영하고, 비즈니스 상황과 진화 단계에 맞춰 모드와 인력을 배분한다. 토큰 사용을 기술적 선택으로 정리한다.
  • 데이터 플라이휠 — 루프를 지속이 아니라 발전시키는 것돈은 루프를 돌리고 토큰은 연산하지만, 다음 바퀴를 이전보다 낫게 만드는 것은 운영이 쌓은 데이터다. trace·평가·학습 신호 세 자산으로 플라이휠을 돌리고, 데이터를 모델 밖 자산으로 두어 주권을 지킨다.

함께 적용하는 패턴

  • 모듈 계약실행 단위의 조건, 권한, 실패 경로를 계약으로 선언한다.
  • 인간 승인고비용·고위험·고영향 의사결정은 인간 승인 흐름 안에 둔다.
  • 의사결정 추적판단 근거, 선택 사유, 협업 경로를 구조화된 로그로 남긴다.