AI 에이전트 평가(evals)와 관측성: 운영 중 품질 측정·모니터링법

AI 에이전트 평가(evals)는 에이전트에 정해진 입력을 주고 채점 로직으로 결과를 재는 테스트이고, 관측성(observability)은 운영 중 에이전트가 실제로 무엇을 했는지 실행 기록으로 남겨 들여다보는 능력이에요. 두 가지는 역할이 달라요. 평가는 배포 전에 '좋아졌는지, 망가지지 않았는지'를 반복 가능하게 확인하고, 관측성은 배포 후 실제 사용자 트래픽에서 비용·지연·실패와 품질 저하를 찾아내요. 이 글은 2026년 10월 기준 Anthropic 엔지니어링 글, LangSmith·OpenAI의 평가 문서, OpenTelemetry GenAI 시맨틱 컨벤션을 바탕으로 에이전트를 서비스에 넣을 때 필요한 평가 설계와 운영 모니터링을 한 흐름으로 정리해요. 특정 플랫폼을 추천하는 글이 아니며, 도구별 기능과 이름은 바뀔 수 있으니 쓰려는 도구의 최신 문서를 함께 확인하세요.

AI 에이전트 평가와 관측성은 무엇이 다를까요

Anthropic의 설명에 따르면 평가는 AI 시스템에 입력을 주고 출력에 채점 로직을 적용해 성공 여부를 재는 테스트예요. 단순한 챗봇은 프롬프트 하나와 응답 하나를 보면 되지만, 에이전트는 여러 턴에 걸쳐 도구를 호출하고 환경의 상태를 바꾸며 중간 결과에 따라 행동을 바꿔요. 그래서 한 단계의 실수가 뒤로 전파되고 쌓이기 쉬워요. 에이전트 평가가 일반 LLM 평가보다 어려운 이유가 여기에 있어요.

관측성은 그 실행 과정을 기록하는 쪽이에요. OpenAI 문서는 트레이스를 한 번의 실행에서 일어난 모델 호출, 도구 호출, 가드레일, 핸드오프의 처음부터 끝까지의 기록이라고 설명해요. 트레이스가 있어야 '왜 이 답이 나왔는지'를 사후에 추적할 수 있고, 채점기를 트레이스에 붙여 운영 데이터 위에서 평가를 돌릴 수도 있어요. 즉 관측성은 평가의 재료를 공급하고, 평가는 관측 데이터에서 무엇이 문제인지 판단하는 기준을 제공해요.

평가에서 자주 쓰는 용어

여기서 트랜스크립트와 결과를 구분하는 점이 중요해요. 항공권 예약 에이전트가 '예약했어요'라고 말했더라도, 실제 성공 여부는 데이터베이스에 예약이 생겼는지로 판단해야 해요. 말로 끝난 보고만 채점하면 실제로는 아무 일도 하지 않은 실행을 성공으로 셀 수 있어요.

오프라인 평가와 온라인 평가는 이렇게 나눠 써요

LangSmith 평가 개념 문서는 평가를 배포 전 오프라인 평가와 배포 후 온라인 평가로 나눠요. 가장 큰 차이는 정답이 있느냐예요. 오프라인 평가는 입력과 참조 출력이 짝지어진 테스트셋에서 돌기 때문에 정확성을 직접 비교할 수 있어요. 온라인 평가는 실제 운영 트레이스를 대상으로 하므로 참조 출력이 없고, 안전·형식·이상 징후처럼 정답 없이 판단할 수 있는 항목에 집중해요.

두 평가는 하나의 순환으로 연결할 때 가장 쓸모가 있어요. 온라인 평가가 운영에서 이상한 실행을 찾아내면, 그 사례를 정답과 함께 오프라인 테스트셋에 넣어요. 그다음 수정한 버전을 오프라인 평가로 검증하고, 배포 후 온라인 평가로 실제 개선을 확인해요. 이 순환이 없으면 테스트셋은 처음 만든 시점의 사용 패턴에 머물고, 실제 사용과 점점 멀어져요.

정답이 필요한 채점기와 필요 없는 채점기

정답 없이 쓸 수 있는 채점기로는 유해 표현·개인정보 탐지, JSON 구조나 필수 필드 같은 형식 검사, 응답 길이·지연 시간 같은 휴리스틱, 명확성·어조를 보는 정답 없는 LLM 심사가 있어요. 이런 채점기는 오프라인과 온라인 양쪽에서 같은 기준으로 쓸 수 있어 일관성이 좋아요. 반대로 참조 답과의 의미 유사도, 사실 정확성, 분류의 정확 일치는 정답이 있어야 하므로 오프라인에서만 쓸 수 있어요.

에이전트 evals 설계: 태스크·채점기·지표 고르기

Anthropic 글은 에이전트 평가에 코드 기반, 모델 기반, 사람 채점기 세 종류를 섞어 쓴다고 설명해요. 코드 채점기는 문자열 일치, 단위 테스트, 정적 분석, 도구 호출 인자 확인처럼 빠르고 싸며 재현 가능하지만, 형식이 조금만 달라도 맞는 답을 틀렸다고 보기 쉬워요. 모델 채점기는 루브릭 점수, 쌍대 비교처럼 유연하고 열린 답을 다룰 수 있지만 비결정적이고 사람 판정과의 보정이 필요해요. 사람 채점은 가장 신뢰도가 높지만 느리고 비싸서, 주로 모델 채점기를 보정하는 데 써요.

• 가능하면 결정적인 코드 채점을 먼저 쓰고, 필요한 곳에만 LLM 심사를 더해요.
• 도구 호출 순서를 하나하나 강제하기보다 최종 결과를 채점해요. 에이전트가 설계자가 예상하지 못한 정당한 경로를 찾을 수 있어서예요.
• 여러 단계가 있는 태스크는 부분 점수를 둬요. 문제를 파악하고 본인 확인까지 한 실행은 처음부터 실패한 실행보다 나아요.
• LLM 심사는 차원별로 나눠 각각 따로 판정하고, 정보가 부족하면 '알 수 없음'을 고를 수 있게 해요.
• 해야 할 때와 하지 말아야 할 때를 모두 테스트해요. 검색해야 하는 질문만 넣으면 모든 질문에 검색하는 에이전트가 만들어질 수 있어요.

능력 평가와 회귀 평가

능력(capability) 평가는 '이 에이전트가 무엇을 잘할 수 있나'를 묻고, 처음에는 통과율이 낮은 어려운 태스크로 구성해 올라갈 언덕을 만들어요. 회귀(regression) 평가는 '예전에 되던 것이 여전히 되나'를 묻고 거의 100%에 가까운 통과율을 유지해야 해요. 점수가 떨어지면 무언가 망가졌다는 신호예요. 능력 평가에서 높은 통과율에 도달한 태스크는 회귀 세트로 옮겨 계속 돌릴 수 있어요.

pass@k와 pass^k는 다른 질문에 답해요

에이전트는 같은 태스크도 실행마다 결과가 달라서 한 번의 통과·실패만 보면 판단이 흔들려요. pass@k는 k번 시도 중 적어도 한 번 성공할 확률이고, pass^k는 k번 모두 성공할 확률이에요. Anthropic 글의 예처럼 한 번 실행의 성공률이 75%인 에이전트를 3번 돌리면 세 번 모두 성공할 확률은 0.75의 세제곱, 약 42%예요. 같은 조건에서 적어도 한 번 성공할 확률은 1에서 0.25의 세제곱을 뺀 약 98%가 돼요. 여러 후보 중 하나만 맞으면 되는 코드 생성 도구라면 pass@k가 의미 있고, 고객이 매번 같은 품질을 기대하는 상담 에이전트라면 pass^k가 더 중요해요.

운영 환경 에이전트 모니터링: 트레이스·비용·실패율

운영 모니터링은 '실제로 무슨 일이 일어나고 있나'를 보는 단계예요. Anthropic 글은 운영 모니터링이 실제 사용자 행동을 대규모로 보여 주고 합성 평가가 놓친 문제를 잡지만, 문제가 사용자에게 먼저 닿는 사후 대응 방식이고 신호에 잡음이 많으며 계측에 투자가 필요하다고 정리해요. 그래서 운영 모니터링은 오프라인 평가를 대체하지 않고 보완하는 수단으로 봐야 해요.

이 지표를 모으려면 에이전트 실행을 일관된 형식의 트레이스로 남겨야 해요. OpenTelemetry GenAI 시맨틱 컨벤션은 생성형 AI 클라이언트 추론, 에이전트, 도구 실행, 평가, MCP 작업에 대한 스팬·메트릭·이벤트 정의를 다루며 2026년 10월 확인 시점에는 OpenTelemetry 본 저장소에서 별도 저장소로 옮겨져 관리되고 있어요. 표준 형식으로 계측해 두면 관측 도구를 바꾸더라도 수집 코드를 덜 고칠 수 있어요. 다만 컨벤션 자체가 계속 바뀌는 중이므로 속성 이름을 고정하기 전에 해당 버전의 문서를 확인하세요.

온라인 LLM 심사는 호출마다 비용이 들어요. LangSmith 문서처럼 평가기를 프로젝트에 붙일 때 샘플링 비율, 필터, 지출 한도를 따로 정하는 방식이 쓰여요. 모든 트래픽을 심사하기보다 오류가 난 실행, 지연이 긴 실행, 부정 피드백을 받은 실행을 우선 고르면 비용 대비 신호가 커져요. 모델 출시나 가격 변경 소식은 재평가가 필요한 시점을 알려 주기도 해서, 더따리 AI 텔레그램 동향에서 업계 공지를 함께 살펴보면 테스트셋을 다시 돌릴 계기를 놓치지 않을 수 있어요.

페이지 참고

트렌드theddari.com›트렌드텔레그램 · AIAI 채널 실시간 포스팅 피드

AI 에이전트 운영에 평가를 도입하는 순서

1. 1

   성공 기준을 문장으로 적어요

   에이전트가 해야 할 일과 하지 말아야 할 일을 적고, 두 전문가가 같은 태스크를 보고 같은 통과·실패 판정을 내릴 수 있는지 확인해요. 판정이 갈리면 태스크 설명이 모호한 것이므로 먼저 고쳐요.

2. 2

   작은 테스트셋을 만들어요

   출시 전 손으로 확인하던 항목, 버그 트래커와 고객 문의에 들어온 실제 실패부터 태스크로 옮겨요. 각 태스크에는 모든 채점기를 통과하는 참조 답을 만들어 태스크가 풀 수 있는 문제인지 확인해요.

3. 3

   격리된 환경에서 여러 번 돌려요

   트라이얼마다 깨끗한 환경에서 시작해 이전 실행의 파일·캐시가 결과에 섞이지 않게 해요. 같은 태스크를 여러 번 실행해 pass@k와 pass^k를 함께 기록해요.

4. 4

   트레이스를 계측하고 운영 지표를 정해요

   모델 호출·도구 호출·오류·토큰·지연을 트레이스로 남기고, 민감 정보 마스킹과 보관 기간을 정해요. 비용·지연·오류율·품질 점수의 기준선을 오프라인 결과로 먼저 잡아요.

5. 5

   운영 실패를 테스트셋으로 되돌려요

   온라인 평가와 사용자 피드백으로 걸러진 실행을 사람이 검토하고, 정답을 붙여 오프라인 세트에 추가해요. 모델이나 프롬프트를 바꿀 때마다 회귀 세트를 먼저 돌린 뒤 배포해요.

처음부터 모든 것을 자동화할 필요는 없어요. OpenAI 문서도 동작을 아직 디버깅하는 단계라면 개별 트레이스를 보고 채점하는 것부터 시작하고, '좋은 결과'의 모습이 분명해지면 반복 가능한 데이터셋과 평가 실행으로 옮기라고 안내해요. 순서를 지키면 처음 만든 채점기가 엉뚱한 것을 재는 문제를 일찍 발견할 수 있어요.

평가 점수를 그대로 믿기 전에 확인할 위험

평가 점수는 채점기가 맞을 때만 의미가 있어요. Anthropic 글은 채점이 지나치게 엄격해 '96.12'를 기대값 '96.124991…'과 다르다고 틀리게 처리하거나, 태스크 설명이 모호해 에이전트가 잘못 없이 실패하는 사례를 들어요. 수정 후 같은 모델의 점수가 크게 달라졌다는 점은 낮은 점수가 반드시 에이전트의 한계를 뜻하지 않는다는 것을 보여 줘요. 많은 트라이얼에서 통과율이 0%라면 에이전트보다 태스크나 채점기가 고장 났을 가능성을 먼저 의심하세요.

• 트랜스크립트를 직접 읽어요. 실패가 진짜 실수인지, 채점기가 정당한 해답을 거부한 것인지는 기록을 봐야 알 수 있어요.
• 평가가 포화되면 개선이 보이지 않아요. 통과율이 100%에 가까운 세트는 회귀 감시용으로 남기고, 능력 측정용으로는 더 어려운 태스크를 추가해요.
• 에이전트가 채점을 우회할 수 없게 설계해요. 이전 실행의 흔적이나 채점 규칙의 빈틈을 이용해 통과하면 실제 능력과 무관한 점수가 나와요.
• 오프라인 세트가 실제 사용 패턴과 다르면 거짓 안심을 줄 수 있어요. 운영 트레이스에서 주기적으로 새 사례를 들여와요.
• 공개 벤치마크 점수는 내 서비스의 평가를 대신하지 않아요. 순위표의 점수 차이를 읽는 법은 별도로 확인하는 것이 좋아요.

정리하면 AI 에이전트 운영의 품질 관리는 배포 전 오프라인 평가로 회귀를 막고, 배포 후 트레이스와 온라인 평가로 실제 행동을 지켜보며, 운영에서 찾은 실패를 다시 테스트셋으로 되돌리는 순환이에요. 어떤 도구를 쓰든 성공 기준을 명확히 적고, 결정적인 채점부터 시작하며, 점수보다 트랜스크립트를 먼저 읽는 습관이 핵심이에요. 에이전트 평가와 관측 도구를 다룬 개발 블로그 글의 흐름은 더따리 블로그 동향에서 함께 살펴볼 수 있어요.

페이지 참고

트렌드theddari.com›트렌드블로그 포스팅요약된 네이버 블로그 글 피드