AI 에이전트의 완료 보고는 증거가 아니다: 자동화 실패를 잡는 검증·평가 설계

 

AI 에이전트가 “작업을 완료했습니다”라고 답했다고 실제 업무가 끝난 것은 아닙니다. 문서를 만들었다는 설명과 문서가 올바른 위치에 저장된 사실은 다릅니다. 예약을 처리했다는 문장과 예약 데이터가 실제로 존재하는 것도 다릅니다. AI 에이전트 자동화에서 신뢰할 수 있는 완료 판정은 모델의 말보다 도구 응답과 최종 상태에 근거해야 합니다.

 

이 글은 AI 에이전트 검증과 평가, 즉 에이전트 이밸루에이션을 처음 설계하는 개발자와 실무자를 위한 가이드입니다. Anthropic의 공식 평가 자료와 도구 설계 문서, 국내 기술 블로그 사례를 참고해 완료 조건, 평가 데이터, 채점기, 반복 실행, 실패 복구, 운영 지표를 정리했습니다.

 

프롬프트 엔지니어링과 컨텍스트 엔지니어링을 이미 활용하고 있더라도 결과를 검증하는 구조가 없으면 개선 효과를 확인하기 어렵습니다. “더 똑똑해 보인다”는 인상과 실제 작업 성공률을 구분하고, 모델과 도구를 바꿨을 때 이전에 잘 되던 업무가 망가지지 않았는지 확인하는 데 평가가 필요합니다.

 

자료 확인 기준은 2026년 10월 14일입니다. 아래의 예약·문서 작성 시나리오, 평가 항목과 도입 계획은 원문을 바탕으로 구성한 설명용 예시입니다. 특정 기업의 실제 장애나 자체 실험 성과를 주장하지 않으며, 출처의 관찰을 모든 제품에 동일하게 적용하지 않습니다.

 

핵심 요약

 

 

• 완료 보고, 도구 호출 성공, 실제 업무 완료는 서로 다른 상태입니다.

• 에이전트 평가는 최종 결과와 실행 기록을 함께 확인해야 합니다.

• 코드 기반 검사, 모델 기반 채점, 사람 검토를 목적에 맞게 조합할 수 있습니다.

• 반복해서 한 번 성공하는 능력과 매번 안정적으로 성공하는 능력은 다릅니다.

• 평가 과제와 검사 기준이 잘못되면 좋은 결과도 실패로 판정될 수 있습니다.

• 정상 사례뿐 아니라 정보 부족, 권한 거부, 부분 실패, 타임아웃을 평가에 포함해야 합니다.

 

목차

 

• AI 에이전트의 완료 보고를 그대로 믿기 어려운 이유

• 평가 과제, 실행 기록, 최종 결과, 채점기의 구분

• 코드·모델·사람 평가의 장점과 한계

• 반복 실행과 성공률, 실제 업무 기반 평가 데이터

• 예약 및 문서 작성 에이전트 검증 예시

• 운영 지표, 국내 기술 블로그 사례, 도입 순서와 FAQ

 

AI 에이전트의 완료 보고와 실제 결과는 왜 다를까?

 

일반적인 대화형 AI는 주로 답변을 생성합니다. 업무용 AI 에이전트는 여기에 검색과 도구 실행, 상태 변경이 추가됩니다. 모델은 사용자 요청을 해석하고 필요한 행동을 선택하며, 도구가 돌려준 결과에 따라 다음 행동을 결정합니다. 여러 단계가 연결되기 때문에 중간의 작은 오류가 뒤의 판단으로 이어질 수 있습니다.

 

문서 작성 에이전트를 예로 들어보겠습니다. 모델이 초안을 완성하고 저장 도구를 호출했지만 도구가 오류를 반환했다면 초안 작성과 저장 성공을 구분해야 합니다. 그런데 최종 답변에서 두 단계를 하나로 묶어 “문서를 작성해 저장했습니다”라고 말하면 사용자는 실제 상태를 오해할 수 있습니다.

 

 

반대 상황도 있습니다. 저장 요청은 실제로 처리됐지만 응답이 늦거나 끊겼을 수 있습니다. 이때 실패로 단정해 같은 문서를 다시 생성하면 중복 문서가 생길 수 있습니다. 응답을 받지 못한 상태와 실행되지 않은 상태는 같지 않습니다. 변경 작업에서 처리 상태를 확인하는 경로가 중요한 이유입니다.

 

Anthropic의 「Demystifying evals for AI agents」는 실행 기록과 최종 결과를 구분합니다. 에이전트가 예약됐다고 말하는 것은 기록의 일부이고, 실제 환경에 예약이 존재하는 것이 결과입니다.[1] 이 구분을 적용하면 “무슨 말을 했는가”와 “무엇이 바뀌었는가”를 각각 검사할 수 있습니다.

 

따라서 완료 조건은 행동 동사보다 확인 가능한 상태로 작성하는 편이 좋습니다. “문서 저장 도구를 호출했다” 대신 “지정한 위치에 요구한 내용을 포함한 문서가 존재한다”가 결과 중심의 기준입니다. 호출 기록도 중요하지만 그것만으로 최종 상태를 대신하지는 못합니다.

 

프롬프트 엔지니어링만으로 해결되지 않는 부분

 

좋은 프롬프트는 목표와 제약, 출력 형식을 명확히 전달합니다. “정확히 해줘”보다 “확인된 근거와 미확인 사항을 나누어 표시해줘”가 검사하기 쉬운 요청입니다. 그러나 잘못된 자료를 받거나 도구의 상태 의미가 모호하거나 결과 조회 기능이 없다면 지시문만으로 문제를 해결하기 어렵습니다.

 

컨텍스트 엔지니어링은 모델이 판단할 때 볼 정보 전체를 구성하고 갱신합니다. 정책 문서와 도구 정의, 실행 이력, 현재 작업 상태를 관리하는 것이 여기에 포함됩니다. 검증 결과도 다음 판단에 필요한 정보가 될 수 있으므로 평가와 컨텍스트 설계는 서로 연결됩니다.

 

 

하네스는 모델 주변에서 도구 실행과 상태, 검증, 재시도, 종료를 관리하는 시스템으로 이해할 수 있습니다. 목표를 문장으로 전달하는 것, 필요한 자료를 제공하는 것, 실제 행동과 결과를 확인하는 것은 서로 다른 역할입니다. 한 역할을 잘 설계했다고 다른 역할이 자동으로 완성되지는 않습니다.

 

예를 들어 “저장이 실패하면 완료라고 말하지 않는다”는 지시는 유용합니다. 하지만 저장 응답에 성공과 실패를 구분할 상태가 없다면 판단이 어렵습니다. 도구 반환값과 실제 상태 조회, 마지막 완료 판정까지 연결해야 그 지시를 안정적으로 적용할 수 있습니다.

 

이 글의 관점은 프롬프트를 버리자는 것이 아닙니다. 프롬프트의 효과를 실제 업무 결과와 비교할 수 있게 만들자는 것입니다. 지시문을 수정한 뒤 같은 평가 과제를 실행하면 오류가 줄었는지, 다른 업무에서 새 문제가 생겼는지 확인할 수 있습니다.

 

평가를 구성하는 여섯 가지 요소

 

첫 번째는 과제입니다. 하나의 입력과 성공 조건을 가진 평가 단위입니다. 예를 들어 “사용자가 지정한 다음 주 시간대에 회의를 예약하고 참석자를 확인한다”는 과제를 만들 수 있습니다. 날짜와 시간대, 대상, 허용 범위를 명시해야 판정의 모호함을 줄일 수 있습니다.

 

두 번째는 실행 시도입니다. 같은 과제를 한 번 수행한 기록입니다. 언어 모델 기반 시스템은 동일한 시작 조건에서도 다른 행동과 출력을 보일 수 있으므로, 하나의 과제를 여러 번 실행해 안정성을 살펴볼 수 있습니다.

 

세 번째는 실행 기록입니다. 모델 응답, 도구 호출, 전달한 인자, 도구 응답, 중간 상태 등을 연결한 기록입니다. 성공과 실패를 설명할 근거가 됩니다. 실제로 제공되지 않은 모델 내부 사고 과정을 임의로 추정하거나 기록했다고 가정하지 않아야 합니다.

 

 

네 번째는 최종 결과입니다. 실행 후 환경에 남은 상태입니다. 예약 데이터, 저장된 문서, 수정된 코드, 처리된 티켓처럼 사용자의 목표와 연결되는 대상입니다. 자연어 설명과 별도로 확인할 수 있는 결과를 정하는 것이 중요합니다.

 

다섯 번째는 채점기입니다. 결과나 기록의 특정 조건을 검사하는 로직 또는 검토 방법입니다. 하나의 과제에 여러 채점기를 사용할 수 있습니다. 저장 위치는 코드로 검사하고, 문서의 설명 품질은 모델과 사람이 검토하는 식입니다.

 

여섯 번째는 평가 실행 환경입니다. 과제를 실행하고 기록을 수집하고 검사 결과를 모으는 기반입니다. 실제 서비스와 너무 다른 환경이면 성능을 잘못 추정할 수 있습니다. 실행 간 데이터와 상태가 섞이지 않도록 관리하는 것도 필요합니다.[1]

 

이 요소들을 구분하면 낮은 점수가 무엇을 의미하는지 따져볼 수 있습니다. 모델의 판단이 잘못된 것인지, 도구가 실패한 것인지, 환경이 불안정한 것인지, 검사 기준이 유효한 결과를 거부한 것인지 나누어 조사할 수 있습니다.

 

코드 기반 검사는 무엇을 잘하고 무엇을 놓칠까?

 

코드 기반 채점기는 형식, 필수 필드, 실제 상태, 테스트 결과처럼 명확한 조건을 빠르게 검사하는 데 적합합니다. 문서 식별자가 존재하는지, 지정한 폴더에 저장됐는지, 시간대가 요청과 맞는지, 필수 항목이 빠지지 않았는지 확인할 수 있습니다.

 

소프트웨어 개발 업무에서는 테스트 통과와 기존 기능의 유지, 타입 검사, 정적 분석을 활용할 수 있습니다. 다만 테스트가 존재한다는 사실만으로 모든 요구사항을 검증한 것은 아닙니다. 실제로 중요한 동작을 검사하는 테스트인지도 확인해야 합니다.

 

 

정확한 문자열 비교는 객관적이지만 지나치게 엄격하면 유효한 표현을 실패로 처리할 수 있습니다. 날짜 표시나 문장 표현이 달라도 의미와 결과가 맞는 경우가 있기 때문입니다. 필요한 곳에는 정확한 비교를 사용하고 다른 곳에는 구조와 의미를 검사해야 합니다.

 

예를 들어 결제 금액이나 주문 식별자는 엄격히 확인해야 할 수 있습니다. 반면 고객 안내 문구의 어미까지 동일해야 한다고 요구하면 자연스러운 다른 표현을 불필요하게 거부할 수 있습니다. 검사 방식은 업무에서 중요한 오류와 허용 가능한 차이를 구분해야 합니다.

 

코드 기반 검사는 기록의 존재와 실제 결과를 확인하기 좋지만 모든 설명의 설득력이나 연구 보고서의 완결성을 판단하기는 어렵습니다. 이러한 부분은 다른 평가 방법과 조합할 수 있습니다. 빠르고 재현하기 쉽다는 장점과 평가 범위의 한계를 함께 이해해야 합니다.[1]

 

모델 기반 채점기를 쓸 때 필요한 기준

 

모델 기반 채점기는 자유로운 문장과 복합적인 품질 기준을 평가할 때 유용할 수 있습니다. 보고서에 근거 없는 주장이 있는지, 답변이 필요한 조건을 설명했는지, 사용자의 요청을 제대로 반영했는지와 같은 항목을 다룰 수 있습니다.

 

하지만 채점에 쓰는 모델도 오류를 낼 수 있습니다. 긴 답변이나 자신 있는 표현을 과대평가하거나 근거를 잘못 읽거나 같은 출력에 다른 점수를 줄 수 있습니다. 따라서 “AI가 좋다고 했으니 좋은 결과”라는 구조로 평가를 끝내면 안 됩니다.

 

평가 기준은 막연한 칭찬보다 관찰 가능한 항목으로 써야 합니다. “친절한 답변인가”만 묻기보다 “정책 근거를 설명했고, 미확인 정보를 확정하지 않았으며, 사용자가 필요한 다음 조치를 이해할 수 있는가”처럼 조건을 나눌 수 있습니다.

 

 

채점기에 필요한 근거를 제공하는 것도 중요합니다. 답변만 보여주고 사실 여부를 판단하게 하면 외부 지식이나 추정에 의존할 수 있습니다. 실제 검색 자료와 도구 결과, 과제의 성공 기준을 함께 주고 근거가 부족하면 판단 불가로 표시할 수 있게 해야 합니다.

 

사람의 판단과 맞는지 주기적으로 확인하는 과정도 필요합니다. 여러 사람이 같은 결과를 평가했을 때도 의견이 크게 다르면 기준 자체가 모호한지 살펴봐야 합니다. Anthropic은 모델 기반 채점기를 사람 전문가와 비교하며 보정하는 접근을 강조합니다.[1]

 

하나의 모델이 모든 차원을 한 번에 평가하기보다 사실 근거, 요구사항 충족, 표현 품질을 구분해 평가할 수 있습니다. 다만 분리한 검사들이 서로 충돌하지 않도록 최종 판정 규칙도 정의해야 합니다. 점수의 정교함보다 무엇을 확인했는지가 중요합니다.

 

사람 검토는 언제 필요할까?

 

사람 검토는 업무 지식과 사용자 기대가 중요한 상황에서 도움이 됩니다. 정책 해석, 연구 보고서의 균형, 설계 선택의 적절성처럼 자동 검사로 다루기 어려운 부분을 확인할 수 있습니다. 모델 채점 기준을 보정할 때도 기준 사례를 제공할 수 있습니다.

 

모든 출력을 같은 수준으로 검토하면 비용과 시간이 커집니다. 영향이 큰 업무, 정보가 상충하는 사례, 새로운 실패 유형, 자동 채점 결과가 불확실한 사례를 우선 검토하는 방식이 후보가 됩니다. 검토 범위는 서비스의 목적과 운영 조건에 맞게 정해야 합니다.

 

사람 검토도 완벽하지 않습니다. 검토자마다 기준이 다를 수 있고 피로와 경험에 따라 판정이 달라질 수 있습니다. 공통 기준과 예시를 마련하고 의견이 갈리는 사례를 함께 검토하면 일관성을 높일 수 있습니다.

 

 

자동 검사와 사람 검토를 경쟁 관계로 볼 필요는 없습니다. 코드 검사는 상태와 형식을 빠르게 확인하고, 모델 검사는 자유로운 설명의 품질을 보조하고, 사람은 중요한 예외와 기준의 적절성을 확인할 수 있습니다. 각 방법이 놓치는 부분을 다른 방법이 보완하는 구조입니다.

 

한 번 성공과 매번 성공은 다른 능력이다

 

에이전트 평가에서 반복 실행을 고려해야 하는 이유는 동일한 과제의 성공 여부가 실행마다 달라질 수 있기 때문입니다. 첫 시도에서 성공했는지, 여러 시도 중 한 번이라도 성공했는지, 모든 시도에서 안정적으로 성공했는지는 서로 다른 질문입니다.

 

Anthropic은 pass@k와 pass^k를 구분해 설명합니다. pass@k는 여러 시도 중 적어도 한 번 성공하는 경우를 보는 관점이고, pass^k는 여러 시도가 모두 성공하는 일관성을 보는 관점입니다.[1] 두 지표를 같은 성능 숫자처럼 비교하면 제품의 실제 요구를 놓칠 수 있습니다.

 

독립적이고 동일한 성공 확률을 가진 시도라는 단순한 가정을 두면 차이를 수식으로 볼 수 있습니다. 한 번의 성공 확률이 p이고 시도 수가 k일 때, 적어도 한 번 성공할 확률은 1-(1-p)^k이고 모두 성공할 확률은 p^k입니다.

 

예를 들어 p가 0.8이고 세 번 시도한다는 설명용 가정에서는 한 번 이상 성공할 확률은 99.2%, 세 번 모두 성공할 확률은 51.2%입니다. 이는 실제 모델의 측정 성능이 아니라 지표의 차이를 보여주는 계산입니다. 현실의 실행들은 같은 환경 문제나 공통 데이터 때문에 서로 독립적이지 않을 수 있습니다.

 

 

초안을 여러 개 만든 뒤 사람이 하나를 고르는 제품은 여러 시도 중 좋은 결과를 찾는 능력이 중요할 수 있습니다. 반면 사용자가 매번 동일한 품질을 기대하는 업무 자동화에서는 일관된 성공이 더 중요할 수 있습니다. 어떤 지표를 쓸지는 제품의 사용 방식에서 결정해야 합니다.

 

재시도를 늘려 점수를 높이는 것과 운영 품질을 개선하는 것도 다릅니다. 추가 호출의 시간과 비용, 중복 변경 위험이 있기 때문입니다. 첫 시도 성공률과 재시도 후 성공률, 총비용을 함께 기록하면 숫자를 더 정확히 해석할 수 있습니다.

 

능력 평가와 회귀 평가를 나누자

 

능력 평가는 현재 시스템이 어려워하는 업무에서 무엇을 할 수 있는지 확인합니다. 개선이 필요한 과제와 새로운 기능을 대상으로 삼을 수 있습니다. 낮은 통과율로 시작하더라도 목표가 명확하면 어떤 능력을 더 키워야 하는지 보여줍니다.

 

회귀 평가는 이전에 잘 처리하던 업무가 변경 이후에도 유지되는지 확인합니다. 프롬프트를 바꾸거나 도구 설명을 고치거나 모델을 교체했을 때 다른 영역의 품질이 떨어지는 문제를 찾는 데 사용합니다.[1]

 

두 평가를 하나의 평균 점수로만 합치면 중요한 변화를 놓칠 수 있습니다. 어려운 새 과제의 성능이 좋아져 전체 평균이 올랐지만, 자주 쓰는 기존 업무의 성공률이 떨어질 수도 있습니다. 사용자가 체감하는 품질은 업무 빈도와 영향에 따라 달라집니다.

 

새 기능에 대한 평가와 기존 핵심 기능의 유지 조건을 각각 보고, 실패 유형별로 결과를 비교하는 편이 좋습니다. 잘 되던 과제가 새 변경에서 실패하면 모델 자체뿐 아니라 검색 자료, 도구 계약, 환경의 변화도 함께 조사해야 합니다.

 

 

성공 기준과 기준 버전을 관리하는 것도 필요합니다. 업무 정책이 바뀌었다면 이전 결과가 더 이상 올바르지 않을 수 있습니다. 평가 과제의 기대값을 바꿨는지, 시스템이 바뀌었는지를 구분해서 기록해야 실제 회귀와 정책 변경을 혼동하지 않습니다.

 

좋은 평가 과제는 실제 업무와 닮아 있어야 한다

 

평가를 시작하려고 거대한 데이터셋을 기다릴 필요는 없습니다. 먼저 사람이 반복해서 확인하던 업무와 실제 실패 사례를 과제로 정리할 수 있습니다. Anthropic은 초기 단계에서 실제 실패에 근거한 작은 과제 집합부터 시작하는 방향을 제안합니다.[1]

 

과제에는 입력, 환경의 시작 상태, 허용된 행동, 성공 조건, 확인할 근거가 들어가야 합니다. 두 명의 업무 전문가가 독립적으로 읽어도 비슷한 성공과 실패 판정을 내릴 수 있는 정도로 구체적이어야 합니다.

 

정답 경로를 지나치게 고정하지 않는 것도 중요합니다. 결과가 맞고 필요한 제약을 지켰다면 다른 도구 순서나 다른 표현도 유효할 수 있습니다. 특정 호출 순서를 외우게 만든 평가가 실제 문제 해결 능력을 측정한다고 보기 어렵습니다.

 

반대로 결과만 맞으면 모든 과정을 허용하는 것도 적절하지 않습니다. 사용자 권한 확인이나 승인 조건처럼 반드시 지켜야 할 제약은 검사해야 합니다. 자유롭게 선택할 전략과 반드시 지켜야 할 경계를 나누어야 합니다.

 

과제 자체가 해결 가능한지 확인할 기준 결과도 필요합니다. 요청하지 않은 저장 경로를 검사기가 요구하거나, 지시한 목표보다 더 높은 수치를 강제로 요구하면 올바르게 행동한 시스템을 실패로 처리할 수 있습니다. 점수가 낮을 때는 에이전트뿐 아니라 과제와 채점기도 점검해야 합니다.

 

정상 사례와 예외 사례의 균형

 

 

성공해야 할 사례만 평가하면 에이전트가 무리하게 행동하는 쪽으로 최적화될 수 있습니다. 정보가 충분한 상황에서는 작업을 수행해야 하지만, 권한이 없거나 대상이 여러 개로 불명확한 상황에서는 멈추거나 확인이 필요할 수 있습니다.

 

예약 업무를 예로 들면 사용자가 시간과 참석자를 명확히 지정한 경우와 같은 이름의 참석자가 여러 명인 경우를 함께 평가해야 합니다. 조회 결과가 하나인 경우에 잘 예약하는 능력과 여러 후보에서 임의로 선택하지 않는 능력이 모두 중요합니다.

 

재시도도 같은 방식으로 평가할 수 있습니다. 일시적인 읽기 오류는 다시 조회해서 해결할 수 있지만 권한 거부를 같은 인자로 반복하는 것은 도움이 되지 않습니다. 변경 요청의 상태가 미확정이면 실제 처리 여부를 먼저 확인해야 합니다.

 

보류 판단을 평가할 때도 균형이 필요합니다. 모든 요청을 사람에게 넘기면 잘못된 실행은 줄일 수 있지만 자동화의 목적을 달성하지 못합니다. 해결 가능한 요청을 적절히 처리하고, 필요한 경우에만 확인을 요청하는지 살펴봐야 합니다.

 

외부 자료에 지시가 섞인 경우도 평가 대상입니다. 검색된 문서가 업무 정보를 제공하는 것과 실행 권한을 부여하는 것은 다릅니다. 외부 문구가 사용자 목표나 시스템의 권한 조건을 바꾸지 못하도록 자료와 지시의 경계를 확인할 수 있습니다.

 

예약 에이전트의 검증을 설계하는 예시

 

설명용 과제를 하나 만들어보겠습니다. 사용자가 다음 주 특정 시간대에 프로젝트 회의를 예약하고 지정한 참석자에게 안내해달라고 요청했습니다. 성공 기준은 일정과 참석자가 정확하고 요청한 시간대가 맞으며 안내 결과가 확인되는 것입니다.

 

 

첫 단계에서는 날짜와 시간대, 참석자 정보가 충분한지 확인합니다. “다음 주 오후”처럼 범위가 넓거나 참석자 후보가 여러 명이면 필요한 확인을 진행합니다. 둘째, 참석자의 가능한 시간과 필요한 자원을 조회합니다. 셋째, 허용된 범위에서 일정을 생성합니다.

 

넷째, 생성된 일정의 상태를 다시 조회합니다. 제목, 시작과 종료 시각, 시간대, 참석자 목록을 요청과 대조합니다. 다섯째, 안내 메시지의 발송 또는 접수 상태를 확인합니다. 일정 생성과 메시지 전달을 하나의 성공 상태로 묶지 않는 것이 좋습니다.

 

회의실 예약이 실패했다면 부분 성공을 표시할 수 있습니다. 일정은 생성됐지만 장소가 확정되지 않았다는 사실을 보고하고 추가 조치가 필요한지 판단해야 합니다. 모든 단계가 끝난 것처럼 말하면 사용자는 준비 상태를 잘못 이해할 수 있습니다.

 

평가에서는 실제 일정 데이터와 발송 상태를 검사하고, 최종 답변이 그 상태를 정확히 설명하는지 확인합니다. 형식과 식별자는 코드로 확인하고, 미확인 사항을 명확히 전달했는지는 모델 또는 사람 검토로 보조할 수 있습니다.

 

이 예시는 실제 일정 서비스의 API 사양이 아닙니다. 어떤 시스템이든 사용자의 목표를 확인 가능한 상태로 바꾸고 단계별 결과를 검증하는 방법을 보여줍니다. 구현할 때는 사용 중인 서비스의 권한과 상태, 시간대 처리 계약을 확인해야 합니다.

 

문서 작성 에이전트는 글자 수만 맞으면 성공일까?

 

문서 작성 업무에서도 분량과 품질, 저장과 공개 상태를 구분해야 합니다. 본문이 지정한 길이를 넘었다고 내용의 사실성이나 요구사항 충족이 자동으로 보장되는 것은 아닙니다. 반대로 글이 잘 작성됐어도 저장 위치와 공개 상태가 틀리면 요청한 업무가 완료되지 않았을 수 있습니다.

 

 

코드 기반 검사로 제목과 본문 존재, 분량, 필수 항목, 문서 식별자, 저장 위치를 확인할 수 있습니다. 카테고리나 공개 상태가 요구사항에 있다면 그것도 실제 문서 상태로 확인해야 합니다. 화면에서 버튼을 눌렀다는 기록만으로 공개됐다고 판단하지 않습니다.

 

내용 평가에서는 핵심 주장에 근거가 있는지, 출처의 실제 내용과 일치하는지, 예시와 실제 관찰을 구분했는지 확인할 수 있습니다. 관련 자료를 여러 개 읽었다는 사실보다 각 주장을 정확한 근거에 연결했는지가 중요합니다.

 

서식도 독자의 이해와 요구사항에 맞게 평가합니다. 제목과 소제목의 계층이 적절한지, 문단이 읽기 쉬운지, 질문에 바로 답하는 FAQ가 있는지, 링크가 올바른 대상으로 연결되는지 확인할 수 있습니다. 소제목을 많이 넣는 것 자체를 품질 지표로 삼으면 중복과 불필요한 분량이 늘 수 있습니다.

 

저장 상태가 계속 처리 중이라면 결과 미확정으로 표시해야 합니다. 문서는 작성됐지만 발행 여부를 확인하지 못한 상태와 실제 발행 완료를 구분하는 것입니다. 사용자가 다음 행동을 판단할 수 있게 현재 확인된 상태를 정확히 보고해야 합니다.

 

실행 환경이 평가 결과를 왜곡하는 방식

 

동일한 과제를 반복할 때 이전 실행의 상태가 남아 있으면 비교가 어려워집니다. 이미 생성된 문서나 예약, 캐시된 자료가 다음 실행에 영향을 줄 수 있습니다. 일부 과제는 이전 기록을 읽어 정답을 쉽게 찾을 수 있고 다른 과제는 중복 데이터 때문에 실패할 수 있습니다.

 

각 실행이 어떤 시작 상태를 갖는지 정의해야 합니다. 테스트 계정과 자료, 도구 버전, 검색 인덱스, 모델 설정을 기록하고, 실행 간 공유 상태를 어떻게 관리할지 정할 수 있습니다. 환경의 변화와 에이전트의 변화가 섞이지 않도록 하는 것이 목적입니다.

 

 

여러 실행이 같은 서버 장애나 자원 부족으로 실패했다면 모델의 판단 문제만으로 해석하면 안 됩니다. 실패가 공통 환경 요인에 영향을 받았는지 확인해야 반복 실행의 결과를 더 정확히 읽을 수 있습니다.[1]

 

실제 서비스와 평가 환경의 차이도 기록해야 합니다. 평가에서는 도구가 즉시 응답하지만 운영에서는 느린 경우, 평가 데이터는 깨끗하지만 실제 데이터는 오래되거나 충돌하는 경우가 있습니다. 자동 평가가 실제 사용을 얼마나 반영하는지 지속적으로 확인해야 합니다.

 

운영 중 새로운 실패가 나오면 개인정보를 제거하고 재현 가능한 과제로 정리할 수 있습니다. 환경과 입력, 도구 응답을 함께 남기면 같은 문제를 다시 검사할 수 있습니다. 실패를 한 번 수정하는 데서 끝내지 않고 회귀 평가에 추가하는 것이 장기적인 개선에 도움이 됩니다.

 

실패를 읽는 방법과 개선의 우선순위

 

낮은 점수를 봤을 때 먼저 실제 결과와 실행 기록을 대조해야 합니다. 에이전트가 어떤 근거로 행동했고 어디서 잘못된 상태를 받아들였는지 확인합니다. 최종 답변만 읽으면 중간의 검색 누락이나 잘못된 인자를 발견하기 어렵습니다.

 

목표가 모호했다면 과제와 프롬프트를 정리하고, 필요한 자료가 누락됐다면 검색과 컨텍스트를 개선하고, 도구를 오용했다면 입력 계약과 설명을 고칠 수 있습니다. 실제 상태를 확인하지 않았다면 검증 경로와 완료 판정을 추가해야 합니다.

 

Anthropic의 도구 설계 자료는 실제 업무 기반 평가와 함께 도구 호출 시간, 횟수, 토큰 사용량, 오류를 살펴보라고 설명합니다.[2] 무의미한 반복 호출과 자주 틀리는 인자는 도구 인터페이스의 개선 후보를 보여줄 수 있습니다.

 

 

모든 오류에 같은 처방을 적용하면 원인이 남습니다. 더 강한 모델을 사용해도 잘못된 정책 자료를 받으면 잘못된 근거로 답할 수 있습니다. 프롬프트를 길게 만들어도 조회 결과의 상태 의미가 모호하면 완료 판정이 흔들릴 수 있습니다.

 

개선 우선순위는 빈도와 사용자 영향, 수정 가능성을 함께 고려할 수 있습니다. 자주 발생하는 작은 불편과 드물지만 영향이 큰 변경 오류를 구분해야 합니다. 모델 교체, 도구 변경, 검색 개선을 비교할 때 다른 조건을 가능한 한 고정하면 무엇이 도움이 됐는지 설명하기 쉽습니다.

 

국내 기술 블로그 사례에서 배우는 검증 방식

 

우아한형제들 기술블로그의 컨텍스트 엔지니어링 글은 디자인 시스템에 맞는 코드 생성에서 지침이 일관되게 적용되지 않는 문제를 다룹니다. 규칙의 적용 범위를 명확히 하고 복합 지시를 나누며 검증 기준을 정리한 경험을 설명합니다.[3]

 

이 사례에서 가져올 수 있는 것은 특정 개선 수치보다 평가 가능한 구조 신호를 정한 방법입니다. 지정한 컴포넌트와 토큰을 사용했는지, 규칙을 위반했는지를 관찰할 수 있는 항목으로 나누었습니다. 반복 실행 결과를 비교하면 한 번 잘 나온 코드만으로 안정성을 판단하는 문제를 줄일 수 있습니다.

 

MadPlay의 하네스 엔지니어링 글은 지시 문서, 도구, 린터, CI, 관찰 도구를 함께 다루며 에이전트 주변 환경을 설계하는 관점을 설명합니다.[4] 문서에 규칙을 적는 것과 실제 검사로 위반을 발견해 피드백을 주는 것은 다른 역할입니다.

 

국내 사례의 결과를 다른 업무의 보장된 성능으로 확대하지 않아야 합니다. 도메인과 모델, 입력, 도구, 검사 기준이 다르면 효과도 달라질 수 있습니다. 우리 환경에서 같은 실패를 재현하고 같은 기준으로 개선 전후를 비교해야 합니다.

 

 

기술 블로그 형식으로 결과를 공유할 때는 문제 상황, 변경 내용, 평가 조건, 실제 관찰, 한계를 함께 제시하면 좋습니다. “성능이 좋아졌다”는 결론만 있는 글보다 어떤 실패가 줄었고 무엇은 아직 확인하지 못했는지 설명하는 글이 실무에 도움이 됩니다.

 

작은 팀을 위한 평가 도입 순서

 

첫 단계에서는 한 가지 업무와 완료 조건을 정합니다. 사람이 현재 어떻게 성공과 실패를 확인하는지 기록하면 평가의 출발점이 됩니다. 저장 상태나 예약 정보처럼 객관적으로 확인할 수 있는 조건부터 찾고 설명 품질처럼 판단이 필요한 항목은 별도로 정리합니다.

 

두 번째 단계에서는 정상 사례와 실제 실패 사례를 모읍니다. 정보가 충분한 요청, 대상이 여러 개인 요청, 권한이 없는 요청, 느린 도구, 부분 실패를 포함할 수 있습니다. 입력과 시작 상태, 허용된 행동, 기대 결과를 한 과제 안에 담습니다.

 

세 번째 단계에서는 가능한 조건을 코드로 검사하고 필요한 부분에 모델과 사람 평가를 추가합니다. 채점기가 올바른 기준 결과를 통과시키는지, 잘못된 결과를 제대로 거부하는지 확인해야 합니다. 검사기 자체의 오류가 점수를 왜곡하지 않도록 관리합니다.

 

네 번째 단계에서는 같은 과제를 반복해 실행하고 실패 유형을 비교합니다. 프롬프트나 모델을 바꾸기 전의 기준 결과를 남기고 변경 이후 비용과 지연, 성공률을 함께 측정합니다. 기존에 잘 되던 업무와 새 기능의 평가를 구분해 회귀를 확인합니다.

 

다섯 번째 단계에서는 운영 관찰과 연결합니다. 자동 평가로 발견하지 못한 실제 사용자 문제를 과제로 추가하고, 사람이 일정 비율의 기록을 검토하며 모델 채점 기준을 보정할 수 있습니다. 평가 집합과 정책, 도구, 모델의 버전을 함께 유지해야 합니다.

 

 

이 계획은 특정 기간 안에 성능을 보장하는 일정표가 아닙니다. 팀이 작은 범위에서 시작해 결과를 설명할 수 있는 구조를 만드는 제안입니다. 평가를 복잡하게 만드는 것보다 중요한 실패를 놓치지 않는 조건과 재현 가능한 기록을 갖추는 것이 먼저입니다.

 

자주 묻는 질문

 

Q1. AI 에이전트가 완료라고 말하면 왜 다시 확인해야 하나요?

 

자연어 보고와 실제 환경 상태가 다를 수 있기 때문입니다. 도구 응답을 잘못 해석하거나 일부 단계만 성공했거나 변경 상태가 미확정일 수 있습니다. 사용자의 목표와 연결되는 최종 상태를 확인해야 합니다.

 

Q2. 모든 평가를 언어 모델에게 맡겨도 되나요?

 

모델 채점은 자유로운 설명을 평가하는 데 도움이 될 수 있지만 오류와 변동성이 있습니다. 상태와 필수 필드처럼 명확한 조건은 코드로 확인하고, 중요한 의미 판단은 모델과 사람 검토를 함께 활용할 수 있습니다.

 

Q3. 같은 과제를 여러 번 실행하면 점수가 반드시 좋아지나요?

 

여러 시도 중 한 번 성공할 가능성은 높아질 수 있지만 매번 안정적으로 성공하는 능력과는 다릅니다. 추가 비용과 지연, 중복 변경 위험도 고려해야 합니다. 제품이 어떤 수준의 일관성을 요구하는지에 맞춰 지표를 선택해야 합니다.

 

Q4. 평가 점수가 낮으면 모델이 나쁜 것인가요?

 

그럴 수도 있지만 과제가 모호하거나 검사기가 유효한 결과를 거부하거나 환경에 문제가 있을 수도 있습니다. 최종 결과와 실행 기록, 평가 조건을 함께 확인해야 원인을 구분할 수 있습니다.

 

Q5. 프롬프트만 고쳐서 실패를 해결할 수 있나요?

 

목표와 지시가 모호한 실패에는 도움이 될 수 있습니다. 하지만 자료 누락, 도구 계약의 모호함, 권한 검사와 결과 검증 누락은 다른 계층의 개선이 필요합니다. 평가로 실패 유형을 구분하는 것이 중요합니다.

 

 

Q6. 로보틱스와 피지컬 AI에도 같은 원칙이 적용되나요?

 

고수준에서는 목표와 실제 결과를 구분하고 실행 후 상태를 확인하는 관점이 연결됩니다. 다만 로봇에는 센서 불확실성, 운동 제어, 지연, 물리적 안전 요구가 추가됩니다. 소프트웨어 에이전트의 평가를 그대로 복사하거나 언어 모델의 보고만으로 로봇 동작의 안전성을 판단하면 안 됩니다.

 

결론: 믿을 수 있는 자동화는 완료의 증거를 남긴다

 

AI 에이전트의 가치는 자신 있게 완료를 선언하는 데 있지 않습니다. 사용자의 목표를 허용된 범위에서 실제로 달성하고, 그 결과를 확인할 수 있게 만드는 데 있습니다. 프롬프트와 컨텍스트, 도구, 실행 환경, 검증이 함께 작동해야 합니다.

 

좋은 평가는 팀이 무엇을 성공으로 보는지 명확하게 만들고, 변화가 실제 개선인지 회귀인지 구분하는 기준을 제공합니다. 코드와 모델, 사람의 평가를 목적에 맞게 조합하고 반복 실행과 실제 운영의 차이를 확인해야 합니다.

 

오늘 바로 시작한다면 자주 수행하는 업무 하나를 골라 완료의 증거를 써보세요. 어떤 상태를 확인해야 끝났다고 말할 수 있는지, 어떤 경우에는 미확정이나 부분 성공을 보고해야 하는지 정리하는 것입니다. 그 기준을 과제와 검사로 바꾸는 과정이 신뢰할 수 있는 AI 에이전트 개발의 출발점입니다.

 

참고 자료

 

[1] Anthropic, Demystifying evals for AI agents. 2026년 1월 9일 공개. 과제·시도·채점기·실행 기록·최종 결과의 구분, 채점 방식, 반복 실행, 능력 및 회귀 평가, 평가 도입 과정을 설명합니다.

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Demystifying evals for AI agents

 

 

[2] Anthropic, Writing effective tools for agents — with agents. 2025년 9월 11일 공개. 도구 설계와 실제 업무 기반 평가, 도구 응답과 오류의 개선을 다룹니다.

https://www.anthropic.com/engineering/writing-tools-for-agents

Writing effective tools for AI agents—using AI agents

 

[3] 우아한형제들 기술블로그, AI가 내 프롬프트를 흘려듣는 이유: 원리부터 다시 본 컨텍스트 엔지니어링. 2026년 7월 7일, 김상국. 디자인 시스템 코드 생성에서 지침과 검증을 개선한 사례입니다.

https://techblog.woowahan.com/26459/

AI가 내 프롬프트를 흘려듣는 이유: 원리부터 다시 본 컨텍스트 엔지니어링 | 우아한형제들 기술

 

[4] MadPlay, 프롬프트와 컨텍스트를 넘어, AI 에이전트를 위한 하네스 엔지니어링. 2026년 2월 15일. 실행 환경, 도구, 지시 문서, 린터와 CI의 역할을 설명합니다.

https://madplay.github.io/post/harness-engineering

프롬프트와 컨텍스트를 넘어, AI 에이전트를 위한 하네스 엔지니어링

 

 

함께 읽기: 프롬프트·컨텍스트·하네스 엔지니어링 비교 가이드