“주간보고 생성이 완료됐습니다.” AI의 메시지가 돌아왔습니다. 파일도 열립니다. 그러나 이번 주 수치는 원자료와 맞는지, 확인하지 못한 원인을 사실처럼 쓴 항목은 없는지, 팀장이 금요일 회의에서 일정 조정을 결정할 수 있는지는 아직 확인하지 않았습니다.
가상의 보고서 업무입니다. 이 장면에서 파일 생성은 관찰한 사실이지만 업무에 사용할 수 있다는 결론은 추가 확인이 필요합니다. AI가 한 일을 설명하는 문장과 공유 폴더의 파일과 그 내용처럼 실제로 남은 결과를 구분해야 합니다.
AI 엔지니어링 시리즈의 마지막 편입니다. Anthropic의 공개 에이전트 평가 글을 업무에 적용해 읽으면 평가의 범위도 답변의 인상에서 실제 결과와 운영 비용으로 넓어집니다. 이 글에서는 무엇을 확인했고 무엇이 아직 남아 있는지 나누고, 더 복잡한 설계가 실제로 도움이 되는지 판단하는 방법을 살펴봅니다.
01실행한 기록과 최종 결과는 확인할 대상이 다릅니다
Anthropic의 2026년 에이전트 평가 글은 실행 기록과 최종 환경 상태를 구분합니다. AI가 어떤 행동을 했는지와 그 행동으로 무엇이 실제로 달라졌는지를 함께 보아야 한다는 관점입니다. 에이전트 평가 글
보고서 생성 도구가 성공 응답을 반환했다면 생성 동작에 관한 근거가 됩니다. 파일을 열어 확인했다면 읽을 수 있는 산출물이 있다는 근거가 추가됩니다. 수치를 원자료와 대조했다면 사실의 일부를 확인한 것입니다. 그러나 이 각각을 중요한 누락이 없고 실제 판단에 쓸 수 있다는 결론까지 확대할 수는 없습니다.
요리로 비유하면 완성 벨이 울린 것과 주문에 맞는 음식이 나온 것은 다릅니다. 도시락을 주문했는데 접시 요리가 나오면 맛이 좋아도 사용 목적과 맞지 않습니다. 주문과 실제 음식, 필요한 맛과 분량을 확인해야 합니다. AI 평가도 생성의 성공과 결과의 쓰임을 함께 살펴야 합니다.
실행 기록은 실패를 분석할 때 도움이 됩니다. 틀린 보고서가 나왔다면 잘못된 자료를 찾았는지, 올바른 자료를 읽고도 수치를 잘못 썼는지, 검사가 실패했는데도 완료 처리했는지 구분할 수 있습니다. 결과만 보면 오류의 영향은 알 수 있지만 고칠 원인을 분리하기 어려울 수 있습니다.
반대로 기록만 자세하고 실제 결과를 확인하지 않으면 설득력 있는 설명을 성과로 받아들일 수 있습니다. 따라서 평가에는 결과의 확인과 원인의 분석이 함께 필요합니다. 사용자에게 보여줄 완료 상태에도 확인한 범위가 드러나야 합니다.
02형식과 사실과 업무 판단은 서로 다른 방식으로 확인합니다
가상의 보고서에서 필요한 항목이 있고 문서가 열리는지는 기계적으로 확인할 수 있습니다. 수치가 맞는지는 원자료와 대조할 수 있습니다. 일정 조정에 필요한 쟁점과 선택지가 적절한지는 업무를 이해하는 사람이 살펴야 합니다. 모두를 하나의 “좋은 답” 점수로 묶으면 어떤 품질이 부족한지 보이지 않을 수 있습니다.
코드 기반 검사는 명확하게 표현할 수 있는 조건에 적합합니다. 필수 항목, 파일 형식, 계산 결과 같은 조건이 예입니다. 다만 제목이 있다고 내용도 충분한 것은 아닙니다. “지연 원인” 항목에 근거 없는 설명이 들어가도 제목 검사만으로는 발견할 수 없습니다.
다른 AI 모델이 결과를 읽고 채점하는 방식은 문장과 내용의 질을 검토하는 보조 수단이 될 수 있습니다. 하지만 평가 모델이 그럴듯한 설명을 높게 평가할 수도 있으므로 평가 방식 자체를 확인해야 합니다. 실제로 사람이 틀렸다고 판단한 결과를 잘 구분하는지, 설명의 길이나 표현에 지나치게 영향을 받는지 살펴볼 수 있습니다.
가상 사례에서는 근거가 없는 원인을 매끄럽게 쓴 답과, 원인을 미확인으로 남기고 확인할 질문을 제시한 답을 비교해 볼 수 있습니다. 업무상 후자가 더 적절하다면 평가 기준도 불확실성을 올바르게 드러내는 답을 인정해야 합니다. 완결된 문장만 좋아하는 평가가 실제 업무의 오류를 키우지 않도록 하는 것입니다.
사람 평가에는 책임과 판단의 기준이 필요합니다. 누구나 막연히 “좋다”고 평가하는 대신 팀장이 결정할 쟁점이 있는지, 원자료로 돌아갈 수 있는지, 중요한 누락이 없는지 같은 질문을 함께 볼 수 있습니다. 자동 검사가 통과했다고 사람의 판단이 필요한 부분까지 확인된 것은 아닙니다.
03평균 안에 숨은 중요한 실패와 실행의 변동을 봅니다
평가 사례는 정상적인 업무만 모아서는 부족할 수 있습니다. 자료가 충돌한 경우, 원인이 확인되지 않은 경우, 조회에 실패한 경우, 중간에 멈춘 경우처럼 실제로 고치려는 실패를 포함해야 합니다. 각 사례에서 성공이 무엇인지 먼저 정하면 평가가 더 구체적입니다.
원인이 없는 사례에서는 그럴듯한 원인을 써 주는 것이 성공이 아닙니다. 미확인으로 남기고 필요한 확인을 연결하는 것이 기대하는 행동일 수 있습니다. 도구 조회가 실패한 사례에서도 “자료 없음”과 “아직 확인하지 못함”을 구분해야 합니다. 같은 유형의 업무라도 성공 조건은 상황에 따라 다릅니다.
평균 점수만 보면 드물지만 중요한 실패가 가려질 수 있습니다. 평소 요약을 잘하더라도 기준이 충돌할 때 승인되지 않은 초안을 사용한다면 해당 업무에서 별도로 관리할 오류입니다. 모든 오류를 같은 무게로 합치기보다 어떤 실패가 업무 판단을 바꾸는지 드러내야 합니다.
같은 입력으로 실행해도 거친 조회 단계와 순서, 최종 결과가 달라질 수 있다는 점도 살펴야 합니다. 한 번의 성공을 반복 업무의 안정성으로 받아들이기 어렵습니다. 반복 횟수는 오류의 영향과 확인 비용에 맞춰 정하되, 실행마다 달라진 결과와 실패 조건을 기록하면 변동을 판단할 근거가 됩니다.
개선에 사용한 사례와 확인용 사례를 나누는 것도 필요합니다. 실패 사례를 보며 지시와 도구를 계속 바꾸다 보면 그 사례에만 잘 맞는 구조가 될 수 있습니다. 수정에 쓰지 않은 사례에서 같은 성공 기준을 확인하면 다른 업무 조건에서도 도움이 되는지 볼 수 있습니다. 좋은 평가 사례는 고정된 영구 자산이 아니라 실제 새로운 실패에 따라 갱신할 대상입니다.
04더 복잡한 설계가 유리한지는 품질과 운영 비용을 함께 비교합니다
에이전트와, 도구·진행 기록·검사를 연결하는 실행 환경인 하네스에 기능을 더하면 해결할 수 있는 문제가 늘 수 있지만 관리할 요소도 늘어납니다. 조회가 많아지면 기다리는 시간과 호출 비용이 늘고, 검사와 상태 기록을 추가하면 갱신할 기준이 생깁니다. 성능이 좋아졌다는 말을 실제 업무의 이익으로 연결하려면 이 비용도 보아야 합니다.
보고서에 원자료와 수치를 대조하는 검사 단계를 더했다고 해 봅니다. 그 단계가 없는 구조와 있는 구조에 같은 기록을 주고 비교하는 것이 출발점입니다. 틀린 수치가 줄었는지와 함께 검사 실패 뒤 보고서를 다시 만드는 시간과 사람의 확인 부담도 봅니다. 모델과 자료, 성공 기준을 가능한 범위에서 맞추고 결과 품질, 실행 시간, 호출 비용, 복구에 필요한 행동, 사람의 재작업을 기록합니다. 오류가 줄어도 사람이 더 많은 부분을 확인해야 한다면 해당 업무의 부담이 어떻게 달라졌는지 살펴야 합니다.
AI 실행 시간만 줄고 사람의 수정 시간이 늘 수도 있습니다. 반대로 실행은 느려져도 사람이 다시 조사할 부분이 줄어 전체 업무에 도움이 될 수도 있습니다. 어느 시간을 세었는지와 어떤 수정까지 포함했는지가 드러나야 수치를 해석할 수 있습니다. 처리한 결과 수를 실제로 사용 가능한 결과 수와 구분하는 이유도 같습니다.
하네스 요소가 도움이 되는지 확인하려면 같은 조건에서 요소 하나를 빼는 비교도 가능합니다. 그때 어떤 실패가 다시 나타나는지 보면 해당 요소의 역할을 분리할 수 있습니다. 모델이 바뀌었을 때 이런 재평가를 하자는 관점은 Anthropic의 2026년 하네스 설계 글에서도 다룹니다. 하네스 재평가 관점
여기서 목적은 점수 하나를 최대화하는 것이 아닙니다. 해당 업무에서 필요한 품질을 얻는 데 어떤 비용과 책임이 남는지 판단하는 것입니다. 모든 업무에 같은 평가표나 자동화 수준을 적용하기보다, 사용자의 성공 기준과 실제 실패를 먼저 연결해야 합니다.
05마치며: 확인한 결과와 남은 확인을 함께 적습니다
최근 AI 결과 하나에서 세 줄을 적어 보시길 권합니다. AI가 했다고 말한 일, 실제로 확인한 결과, 아직 확인하지 못한 것입니다. 마지막 줄이 다음 평가 대상이고, 실패한 줄은 다음 설계 개선의 출발점입니다.
이 시리즈에서 프롬프트는 목적을 전달하고, 컨텍스트는 현재 볼 정보를 고르며, 에이전트는 다음 행동이 달라지는 지점의 판단을 다룹니다. 하네스는 그 일을 이어갈 환경을 연결하고, 평가는 실제 결과를 확인해 다음 개선으로 돌려줍니다. 한 업무 안에서 서로 겹치며 작동하는 설계 대상입니다.
AI 엔지니어링의 흐름을 읽는 데 필요한 질문은 최신 이름을 얼마나 알고 있는가와 함께, 우리 업무에서 무엇이 실패했고 어디를 바꿔야 하는가입니다. 바꾼 뒤 어떤 결과를 확인했는지까지 연결될 때 지식이 실제 설계 판단으로 이어집니다.
이 글은 AI의 도움을 받아 작성했습니다.