본문으로 건너뛰기
Tech

최근 아티클

최근 아티클을 표시합니다.
    Research12 MIN

    AI Agent의 실패를 어떻게 재현하고 평가할까

    부동산 상담 실패를 회귀 테스트로 바꾼 Evaluation Harness 사례

    상담 품질 감시관 Agent가 상담 실행 기록을 따라가며 정책대출 답변의 결함을 발견하고, 이를 다시 실행할 수 있는 회귀 평가 자산으로 남기는 장면

    복덕방 가재(이하 상담 Agent)는 부동산 질문에 필요한 근거를 확인해 답하는 부동산 AI Agent(real estate AI agent)입니다. 이 글은 상담 실패를 같은 조건에서 다시 실행하고 판정하는 평가 하네스(evaluation harness)를 다룹니다. 매일 아침 상담 품질을 감사하는 Agent(이하 감시관 Agent)가 전날 상담 실행 기록을 훑어 문제로 보이는 답변을 골라냅니다.

    어느 날 감시관 Agent가 정책대출 상담 하나를 문제 후보로 표시했어요. 5억 원짜리 집을 보유 현금 1.5억 원으로 살 수 있느냐고 묻는 고객에게, 상담 Agent가 정책대출로 “가능하다”에 가까운 답을 내놓은 기록이었습니다.

    문제는 근거였어요. 디딤돌 같은 정책대출은 대상 여부와 방공제, 금리, 한도가 조건마다 갈려요. 전용 계산 기준으로 보면 이 고객이 닿을 수 있는 최대 매수가는 방공제를 적용해 3억 원대 초반, 조건이 좋아도 4억 원대 후반이었고요. 5억 원짜리 집은 이 경로만으로 닿지 않습니다. 그런데 답변은 금리를 3.5%로 잘못 읽고 대상 판정과 방공제 계산을 건너뛴 채, 5억 원까지 가능한 것처럼 말하고 있었어요.

    처음에는 계산식만 고치면 될 것 같았어요. 상담 Agent는 관련 정책 문서를 이미 읽은 뒤였거든요. 하지만 실행 기록을 따라가 보니 문서가 안내하는 기준과 계산 도구가 처리하는 범위가 어긋나 있었고, 도구를 호출한 순서도 그 둘과 맞지 않았으며, 감시관 Agent가 판정에 쓰는 기준마저 또 다른 규칙을 보고 있었습니다.

    모든 상담을 똑같이 깊게 볼 수는 없습니다

    이 상담이 감시관 Agent의 눈에 들어온 것부터가 우연은 아니었어요. 상담 Agent는 하루에도 수많은 고객과 대화를 나눕니다. 이 대화를 전부 같은 깊이로 파고들면 어떻게 될까요? 시간과 비용을 감당하기 어렵고, 정작 중요한 문제가 사소한 이슈에 묻힙니다.

    응급실을 떠올리면 쉬워요. 환자가 한꺼번에 몰릴 때 응급실은 접수한 순서대로 진료하지 않잖아요. 먼저 상태를 훑어 위급한 정도를 나누고, 가장 위급한 환자부터 봐요. 감시관 Agent도 같은 순서를 밟아요.

    먼저 가볍게 훑습니다. 이 대화가 내부 테스트인지 실제 고객 상담인지, 어떤 유형인지를 미리 정해둔 규칙으로 빠르게 걸러 내요. 깊이 들여다보지 않으니 속도가 빠르고 자원도 아껴요. 그다음 남은 상담마다 점수를 매겨 심각도를 '낮음·보통·심각'으로 나눠요.

    깊은 분석은 여기서 시작됩니다. '심각'으로 분류된 상담만 골라, 왜 그런 답변이 나왔는지 실행 기록을 따라가며 파고들어요. 그 정책대출 상담이 걸린 것도 이 단계였고요. 나머지 대다수는 여기까지 오지 않습니다.

    이 방식에는 전제가 깔려 있어요. 고객이 남긴 모든 아쉬움을 한 번에 해결할 수는 없다는 것. 그래서 목표를 “전부 잘하기”가 아니라 “심각한 문제부터 확실히 고치기”로 잡았습니다. 감시관 Agent가 심각도순으로 줄을 세워 주면, 저희는 그 순서대로 하나씩 처리해요.

    골라내는 것까지는 됐습니다. 문제는 골라낸 상담을 무엇으로 평가하느냐였어요.

    최종 답변만 봐서는 알 수 없습니다

    처음에는 저희도 질문표를 썼어요. 고객이 물을 법한 질문마다 실제 답변과 기대 조건, 피해야 할 표현을 적어 두는 방식이었죠. 어떤 질문에 답할 수 있어야 하는지 기준선을 맞추는 데는 쓸모가 있었어요.

    문제는 재현이었어요. 질문 한 줄과 최종 답변만으로는 같은 정책대출 실패를 다시 만들 수 없었어요. 상담 앞부분에서 어떤 조건을 확인했는지, 어떤 문서를 읽었는지, 계산 전에 어느 도구를 불렀는지가 남지 않았거든요. 답이 틀렸다는 사실은 적을 수 있어도 왜 틀렸는지는 적을 수 없었습니다.

    정답 문구를 고정하는 방식도 맞지 않았습니다. 정책 상담에서는 조건이 부족하면 더 물어야 하고, 근거가 얇으면 답변의 강도를 낮춰야 하잖아요. 표현이 달라도 안전한 답변일 수 있고, 문장이 그럴듯해도 잘못된 계산 경로를 숨길 수 있습니다.

    재현하려면 덜어내고 다시 세워야 합니다

    그래서 평가 단위를 바꿨습니다. 질문과 답변의 쌍이 아니라, 새 세션에서 통째로 다시 실행하는 상담 시나리오로요. 이렇게 실패를 다시 세워 판정하는 장치를 평가 하네스라고 부릅니다.

    감시관 Agent는 재현에 필요한 조건부터 정리했어요. 고객과 지역을 식별할 수 있는 정보, 실제 금융 조건은 뺐고요. 대신 재현 입력과 확인해야 할 계산 근거(방공제를 반영한 대출 가능액), 허용하지 않을 답변 범위(5억 원까지 가능하다는 단정), 기대하는 실행 경로를 남겼습니다.

    원인은 상담 Agent의 성격이 아니라 도구와 SKILL의 규칙에 있다고 봤어요. 정책 기준 문서에는 전용 계산 도구를 써야 하는 조건을 명시하고, 상담 경로를 결정하는 SKILL에는 정책대출과 일반 대출의 경계를 연결했습니다.

    평가는 매번 새 세션에서 시작해요. 이전 상담의 대화 상태가 섞이면 무엇 덕분에 통과했는지 알 수 없으니까요. 한 실행 안에서 평가 결과를 상담 Agent에게 되돌려 통과할 때까지 고치는 방식도 쓰지 않았습니다.

    권한은 여기서 갈립니다. 감시관 Agent는 도구와 SKILL의 수정안을 만들고 검증할 수 있지만, 운영자가 거부하거나 보류하면 그 수정안은 격리된 평가 환경에 그대로 남고, 승인 지시가 내려온 다음에야 검증을 마친 변경만 운영에 반영합니다. 덕분에 Agent가 운영을 돌리면서도 복덕방 가재의 역할과 상담 원칙을 바꾸는 결정은 사람 손에 남았어요.

    감시관 Agent가 정책대출 실패를 재현하고 도구와 SKILL 수정안을 격리된 환경에서 평가한 뒤, 운영 메신저의 승인 지시에 따라 운영에 반영하는 구조

    이 글의 그림과 표는 실제 내부 스키마나 호출 단위 trace가 아니라, 업무 기록에서 확인한 구성 요소를 공개 가능한 수준으로 일반화했습니다.

    하네스는 문서 읽기와 도구 호출, 계산 근거와 최종 답변을 실행 증거로 모아요. 근거가 모자란 실행은 통과도 실패도 아닌 별도 확인 대상으로 뺐고요. 질문표보다 실행 시간과 관리 비용은 늘었지만, 최종 문장 뒤에 가려져 있던 실패 경로를 비교할 수 있게 됐습니다.

    증거는 그렇게 모였습니다. 그 증거로 무엇을 통과라 부를지는 아직 정하지 않은 상태였고요.

    무엇을 통과로 볼지부터 정해야 합니다

    정책대출 시나리오의 기대 행동과 금지 행동, 필요한 근거를 세 가지 평가 기준으로 묶었어요.

    1. 계산 결과를 결정형 기준값과 비교합니다

    필요한 데이터는 이미 있었어요. 없던 것은 정책의 분기와 산식을 안정적으로 처리할 계산 경로였어요. 문서를 읽은 상담 Agent가 산식을 직접 해석하면 대상 여부나 방공제, 금리와 한도 가운데 하나쯤은 놓치거든요.

    그래서 분기와 산식은 전용 계산 도구에 맡겼습니다. 주택가격에 상품 LTV를 적용하고 지역별 방공제를 뺀 뒤 상품 한도와 소득 기준을 비교해, 같은 입력이면 언제나 같은 대출 가능액을 내는 대출계산기예요. 상담 Agent는 고객이 밝힌 조건을 정리하고 빠진 조건을 되묻고 결과를 설명하는 쪽에 집중해요.

    앞의 5억 원 상담을 이 도구에 그대로 넣으면 최대 매수가가 3억 원대 초반으로 나와요. 감시관 Agent는 답변이 내놓은 값이 아니라 이 계산값을 놓고, 둘이 어긋나는지 직접 비교했습니다.

    문서와 도구만 바꿔서는 기준이 또 어긋납니다. 감시관 Agent가 평가 하네스에서 보는 계산 기준값도 같은 곳을 가리키게 맞췄어요. 데이터와 문서, 계산 도구와 상담 경로, 그리고 감시관 Agent의 평가 기준까지 같은 정책 기준 하나를 보게 한 겁니다.

    2. 답변이 근거 범위를 넘지 않는지 판정합니다

    계산이 맞아도 상담은 위험할 수 있어요. 특정 조건에서만 가능한 범위를 모든 경우로 넓혀 말하거나, 확인하지도 않은 조건을 충족했다고 단정하면 그렇습니다.

    그래서 하네스에는 원칙을 하나 따로 걸어 뒀어요.

    답변의 주장 범위는 문서와 도구가 뒷받침하는 근거 범위를 넘지 않아야 합니다.

    계산값이 맞더라도 소득이나 지역 같은 대상 조건을 확인하지 않은 채 “가능하다”고 하면 근거보다 넓은 주장이에요. 감시관 Agent는 답변이 확인된 조건 안에서만 말했는지, 근거가 부족한 자리에서 판단을 미뤘는지를 봤습니다.

    판정은 두 갈래로 나눴어요. 대출 가능액이나 대상 여부처럼 구조화된 결과는 기준값과 곧바로 비교해요. 반면 “가능하다”와 “확인이 필요하다”처럼 의미로 갈리는 표현은, 틀린 문구를 금지 목록에 하나씩 더하는 대신 검토 대상으로 남겼어요. 금지 목록은 새 표현이 나올 때마다 무력해지지만, 근거 범위를 넘지 않는다는 기준은 표현이 달라져도 그대로 서 있거든요.

    이 상담에는 예약이나 저장처럼 외부 상태를 바꾸는 동작이 없었어요. 그래서 계산값과 답변의 주장 범위만 확인하면 됐고요. 상태를 바꾸는 상담이라면 답변 문장이 아니라 실제로 바뀐 최종 상태를 봐야 합니다.

    3. 실행 경로와 불필요한 조회를 확인합니다

    처음 만든 평가에는 구멍이 있었어요. 필요한 도구가 실행 중 한 번이라도 등장하면 통과였거든요. 그런데 정책대출 전용 계산보다 일반 대출 계산이나 모델의 직접 해석이 먼저 시작되면 거기서 만들어진 값과 설명이 뒤따르는 답변에 그대로 남고, 마지막에 전용 도구를 부르더라도 이미 어긋난 근거는 지워지지 않으며, 관련 없는 도구를 거치는 동안 호출과 응답을 기다리는 시간까지 더해집니다. 앞의 상담에서 잘못 읽힌 3.5% 금리도 전용 계산 이전 경로에서 넘어온 값이었어요.

    정책대출 전용 계산 경로보다 일반 대출 계산이나 정책 산식 직접 해석이 먼저 실행된 뒤 전용 계산 도구를 호출한 흐름

    그래서 결과만 보지 않고 매 실행의 경로를 함께 봤어요. 정책대출처럼 시작을 잘못 끊으면 타격이 큰 경로에는 첫 도구와 필수 호출 순서, 앞서면 안 되는 조회를 못 박아 뒀어요. 당시 이 기준을 시작 동작 계약(Start Contract)이라고 불렀어요.

    모든 상담의 호출 순서를 하나로 고정하지는 않았습니다. 같은 근거로 같은 결과에 닿으면서 군더더기 조회를 만들지 않는 대체 경로는 그대로 뒀어요. 대신 필요한 도구로 바로 들어갔는지, 정책상 중요한 시작 순서를 지켰는지는 매번 확인했습니다.

    한 경로를 고치면 옆 경로가 흔들립니다

    세 기준을 걸고 수정안을 돌렸어요. 달라진 것은 검증 표면별로 갈라 놓아야 눈에 들어옵니다.

    검증 표면운영 실패 기록도구·SKILL 수정안 적용 실행
    정책 계산상담 Agent가 문서의 분기와 산식을 해석결정형 전용 계산 도구가 처리
    도구 경계정책대출과 일반 대출 계산의 역할이 불명확정책 문서·도구·호출 조건을 같은 기준으로 정렬
    실행 경로일반 계산이나 직접 해석을 먼저 거쳐 호출과 응답 시간이 늘어날 수 있음전용 계산 경로로 바로 진입하고 불필요한 조회·반복 호출이 없는지 확인
    답변 범위계산 근거보다 강한 결론을 만들 수 있음기준값과 답변의 주장 범위를 함께 판정
    회귀 확인대상 실패의 초기 실행 결과를 보존대상 반복 실행과 인접 일반 대출 경로를 별도 확인

    첫 실행은 그래도 기준을 넘지 못했어요. 어긋난 기준을 하나씩 맞추고 나서야 대상 시나리오가 통과했습니다.

    그런데 고치고 나니 반대쪽이 걱정됐어요. 정책대출 경로를 좁히면 일반 대출 질문까지 전용 계산으로 끌려갈 수 있거든요. 그래서 실패했던 시나리오와 인접한 일반 대출 시나리오를 나란히 돌렸습니다. 실행 뒤에는 시나리오와 평가 기준, 실제 경로와 근거 상태, 판정 사유를 하나의 비교 결과물로 남기고, 감시관 Agent가 이것을 수정안과 함께 감시 이슈로 묶어 운영 메신저에 올렸어요.

    정책대출 실패 기록과 도구·SKILL 수정안이 적용된 실행을 독립된 새 상담 Agent 세션에서 평가하고 회귀 자산으로 남기는 과정

    다만 이 결과는 당시 정의한 대상과 인접 시나리오에 한정됩니다. 전체 상담의 통과율이나 정확도가 올랐다는 뜻도, 검증하지 않은 HTTP·webchat 경로까지 같으리라는 보장도 아닙니다.

    판정 기준도 틀릴 수 있습니다

    상담 Agent는 고쳤어요. 대상 요건을 확인하지 않고 “대출을 받을 수 있다”고 단정하던 문제는 조건부터 묻도록 바꿨어요. 그랬더니 이번에는 감시관 Agent가 걸렸어요. 하네스가 쓰던 문자열 판정 규칙이 “대출을 받을 수 있다”와 “대출 대상인지는 확인이 필요하다”를 구분하지 못해, 안전해진 확인 문장까지 실패로 처리한 겁니다.

    잘못된 단정을 실패로 잡는 판정은 그대로 두고, 안전한 확인 문장까지 막던 부분만 걷어냈어요. 그리고 같은 상담을 다시 돌렸습니다. 상담 Agent의 회귀뿐 아니라 판정 기준이 만들어 낸 거짓 양성(false positive)까지 함께 본 셈이에요.

    증거를 연결하는 과정에서도 오류가 납니다. 상담 세션과 trace 식별자가 어긋나 멀쩡한 실행을 “기록 없음”으로 판정한 적이 있어요. 이건 상담 Agent의 실패가 아니라 평가 근거 누락으로 따로 뺐습니다.

    실패로 떴다고 모두 상담 Agent의 잘못은 아니었어요. 그래서 최종 판정을 네 갈래로 갈랐습니다.

    • 상담 Agent의 기준 위반
    • 감시관 Agent의 오판
    • 평가 근거 누락
    • 수동 검토 필요

    앞의 둘은 정반대예요. 하나는 상담 Agent가 실제로 틀린 경우고, 다른 하나는 맞게 답했는데 판정하는 쪽이 실패로 잡은 경우입니다.

    그래서 하네스는 확실히 가릴 수 있는 것만 자동으로 판정합니다. 읽어야 아는 것은 실패로 몰지 않고 마지막 갈래로 넘겼어요. 판정하는 쪽도 틀릴 수 있다는 것을 겪고 나서 그은 선입니다.

    다시 실행할 수 있어야 자산이 됩니다

    정책대출 상담을 고친 뒤 남은 것은 “이번에는 잘 답했다”는 인상이 아니었습니다. 어떤 조건에서 실패를 찾았고, 도구와 SKILL을 어떻게 고쳤으며, 그 앞뒤로 경로와 근거가 어떻게 달라졌는지 다시 확인할 수 있는 시나리오와 비교 결과물이었어요.

    5억 원짜리 집을 현금 1.5억으로 살 수 있느냐던 그 상담은, 이제 한 번의 수정으로 끝나지 않습니다. 같은 조건을 새 세션에 다시 넣으면 그때의 실패와 지금의 실행이 나란히 놓여요.

    한 번 고친 답변은 그 상담에서 끝납니다. 저희가 남기는 것은 다음 변경에서도 다시 돌릴 수 있는 시나리오입니다.

    에이전트파트

    다양한 데이터와 AI Agent 기술을 연결해 사용자의 의사결정을 돕습니다.

    다른 글