OracleWorkflow: 같은 0.7인데, 왜 다음 결과는 달라질까

“배송이 늦었는데 일부 환불도 받을 수 있나요?”

온라인 쇼핑몰 고객센터에서 AI Agent 두 개가 이 문의를 받았다. 오늘 처리한 문의는 각각 열 건이고, 둘 다 일곱 건을 제대로 해결했다.

점수는 똑같이 0.7이다.

첫 번째 Agent는 다음 날 같은 문의를 받아도 같은 실수를 반복한다. 두 번째 Agent는 이번 실패를 기록한다. 주문 상태와 결제 수단을 먼저 확인하도록 처리 순서를 바꾸고, 판단하기 어려우면 상담원에게 넘기는 기준도 추가한다.

오늘의 실력은 같아 보인다. 내일의 결과는 다르다.

AI 시스템을 평가할 때 현재 점수만 봐서는 이 차이를 알 수 없다.

1. 점수 0.7이 말해 주지 않는 것

0.7은 오늘 열 번 중 일곱 번 성공했다는 뜻이다. 다음에도 같은 결과가 나올지는 알려 주지 않는다.

학교 시험에 비유하면 쉽다. 두 학생이 모두 70점을 받았다. 한 학생은 틀린 문제의 답만 외웠다. 다른 학생은 왜 틀렸는지 확인하고 풀이 방법을 고쳤다. 오늘 성적표에는 차이가 없다. 비슷한 문제가 다시 나오면 차이가 드러난다.

AI Agent도 마찬가지다. 한 번의 점수에는 두 가지가 섞여 있다.

• 지금 이 일을 얼마나 잘하는가

• 실패한 뒤 다음 실행을 얼마나 빨리 바꾸는가

두 번째를 이 글에서는 개선속도(improvement velocity)라고 부른다. 복잡한 공식부터 만들 필요는 없다. 다음 질문에 답하면 된다.

• 같은 실수를 몇 번 만에 줄이는가

• 실패를 다음 행동 규칙으로 남기는가

• 처음 보는 문제에서도 배운 내용을 가져다 쓰는가

개선속도는 점수가 오르는 속도만 뜻하지 않는다. 실패가 줄어드는 방식까지 포함한다.

2. 기록이 있다고 모두 학습은 아니다

두 번째 Agent가 나아진 이유는 대화 내용을 저장했기 때문이 아니다.

실패가 다음 실행을 바꾸는 규칙으로 변했기 때문이다.

실패한 문의
→ 왜 틀렸는지 기록
→ 확인할 조건과 처리 순서 수정
→ 다음 문의에 적용

고객과 나눈 대화를 보관만 하면 창고가 하나 늘어난다. 다음에 확인할 항목, 도구를 부르는 순서, 사람에게 넘길 조건이 달라져야 시스템이 배웠다고 말할 수 있다.

여기서 memory는 지난 대화를 쌓아 둔 저장소가 아니다. 다음 행동을 바꾸는 근거다.

이 관점에서 평가 대상도 달라진다. Agent가 마지막에 쓴 답변만 볼 수 없다. 어떤 정보를 확인했고, 어떤 도구를 썼으며, 어디에서 사람에게 넘겼는지까지 함께 봐야 한다. 이 전체 흐름을 WorkflowGraph라고 부른다. 쉽게 말하면 일을 처리한 경로다.

3. 한 번 성공한 것과 다시 성공하는 것은 다르다

실제 벤치마크도 이 차이를 다루기 시작했다.

τ-bench는 대화가 끝난 뒤 주문이나 환불 같은 실제 상태가 목표대로 바뀌었는지 확인한다. 같은 과제를 여러 번 시켰을 때 계속 성공하는지도 pass^k라는 지표로 따로 본다. 한 번의 성공률만으로는 다음 실행의 흔들림을 알기 어렵기 때문이다. Yao et al., 2024

최종 답만 맞았다고 처리 과정까지 맞았다고 볼 수도 없다. 수학 추론을 다룬 연구에서는 마지막 답만 채점하는 방식보다 풀이 단계에 피드백을 주는 방식이 더 나은 결과를 냈다. 모든 AI Agent에 그대로 적용되는 결론은 아니지만, 결과와 과정을 나눠 봐야 한다는 근거는 된다. Lightman et al., 2023

코딩 벤치마크에서도 비슷한 문제가 발견됐다. SWE-bench의 후속 감사에서는 테스트를 통과한 패치가 실제 개발자의 의도와 다를 수 있고, 그 때문에 해결률이 부풀려질 수 있음을 보였다. 초록불 하나만 보고 “문제가 해결됐다”고 말하기 어려운 이유다. Wang, Pradel & Liu, 2025

4. 무엇이 달라져야 개선인가

고객센터 Agent의 점수가 0.7에서 0.8로 올랐다고 해보자. 숫자만 보면 좋아졌다.

그런데 새 버전이 답변 하나를 더 맞히는 대신 처리 비용을 두 배로 썼다면 어떨까. 예전에 잘하던 환불 문의를 틀리기 시작했다면 어떨까. 개인정보 규칙을 어겨 점수를 올렸다면 더 큰 문제다.

개선을 판단하려면 다섯 가지를 함께 봐야 한다.

안전 위반과 예전 기능의 고장은 평균 점수로 덮으면 안 된다. 별도의 탈락 조건으로 두는 편이 맞다.

평가에 쓰던 문제가 학습 과정에 섞이지 않았는지도 확인해야 한다. 이미 답을 본 문제에서 점수가 오른 것은 새로운 문제를 잘 푼다는 증거가 아니다. 벤치마크 데이터 오염 연구가 계속 지적하는 부분이다. Xu et al., 2024

이 글에서 말하는 개선은 다음 조건에 가깝다.

같은 실패가 줄었다
+ 예전에 잘하던 일을 망가뜨리지 않았다
+ 안전 규칙을 지켰다
+ 처음 보는 문제에서도 나아졌다

5. 채점표가 바뀌면 가짜 성장이 생긴다

같은 고객 답변을 어제는 70점, 오늘은 85점으로 평가했다고 하자.

Agent가 좋아졌을 수도 있다. 채점표가 바뀌었을 수도 있다. “근거를 제시했는가”의 비중을 낮췄거나, 새 채점 모델이 긴 답변을 더 좋아했을 가능성도 있다.

눈금이 바뀌었는데 키가 컸다고 착각한 셈이다.

이 글에서는 AI의 결과를 평가하는 채점 시스템을 Oracle이라고 부른다. 사람일 수도 있고, 정답을 확인하는 프로그램일 수도 있으며, 다른 AI 모델일 수도 있다.

AI가 AI를 채점하면 빠르고 많은 사례를 처리할 수 있다. 다만 편향이 생긴다. 연구에서는 답변의 순서, 길이, 자기 모델이 만든 답변인지 같은 요소가 판단에 영향을 줄 수 있음을 확인했다. 후속 연구는 이런 편향을 12가지 유형으로 나눠 측정했다. Zheng et al., 2023 Ye et al., 2024

Agent의 점수가 올랐다는 주장과 채점 기준이 그대로였다는 주장은 서로 다른 주장이다.

6. Oracle health는 채점기의 건강검진이다

체중계가 고장 나면 운동 성과도 믿기 어렵다. AI 평가도 같다. Agent를 재기 전에 채점기가 제대로 작동하는지 확인해야 한다.

Oracle health는 네 가지 질문으로 풀 수 있다.

사람의 선호와 비슷하게 판단한다고 사실과 논리까지 잘 평가하는 것은 아니다. JudgeBench는 강한 모델도 어려운 판단에서는 무작위 추측보다 조금 나은 수준에 머문 사례를 보고했다. Tan et al., 2025

채점 모델을 속이는 짧은 문구를 답변에 붙여 점수를 올릴 수 있다는 연구도 있다. 절대 점수를 매기는 방식은 두 답변을 비교하는 방식보다 더 취약했다. Raina, Liusie & Gales, 2024 평가 지시문의 형식만 바꿔도 견고성 차이가 최대 40%까지 나타났다는 점검 결과도 있다. Li et al., 2025

평가 모델이나 채점표를 바꿨다면 이전 점수와 바로 이어 붙이면 안 된다. 정답이 분명한 고정 문제를 다시 풀게 한 뒤, 새 채점기가 이전과 같은 기준을 유지하는지 먼저 확인해야 한다.

7. OracleWorkflow는 두 시스템을 함께 관리한다

Agent는 여러 단계를 거쳐 일을 처리한다. Oracle도 결과를 모으고, 기준과 비교하고, 통과 여부를 판단한다. 둘 다 하나의 작업 흐름이다.

OracleWorkflow는 이 두 흐름을 함께 관리하는 방식이다.

일하는 시스템
실패 → 기록 → 규칙 수정 → 다음 실행

채점하는 시스템
결과 수집 → 기준과 비교 → 판정 → 채점기 점검

두 시스템은 가능한 한 독립적으로 운영해야 한다. 답을 만드는 쪽과 채점하는 쪽이 같은 근거와 같은 편향을 공유하면, 실제 성능보다 채점 방식에 익숙해질 수 있다. 이 글에서 disjoint라고 부르는 것은 이런 독립성을 저장소 구조에 명시하자는 설계 원칙이다. 모든 상황에 적용되는 수학 법칙은 아니다.

Agentic benchmark 연구도 과제 설정과 보상 설계의 결함이 성능을 크게 높이거나 낮춰 보이게 할 수 있다고 지적한다. 좋은 평가를 만들려면 대상 시스템뿐 아니라 평가 과정도 관리해야 한다. Zhu et al., 2025

8. 다음 배포에서 물어야 할 것

새 버전의 점수가 올랐다는 보고를 받으면 네 가지를 더 묻는다.

• 같은 실수를 덜 반복하는가

• 실패가 다음 행동 규칙으로 남았는가

• 예전에 잘하던 일과 안전 기준을 지켰는가

• 점수를 매긴 채점기는 어제와 같은 눈금을 쓰는가

첫 질문부터 세 번째까지가 개선속도를 확인한다. 마지막 질문이 그 개선이 진짜인지 지킨다.

현재 점수 0.7은 출발점이다. 다음 문의에서도 0.7인지, 0.8로 오르는 동안 무엇을 바꿨는지, 그 숫자를 잰 눈금이 그대로인지가 남는다.

---

참고 문헌

1. Lightman et al. (2023), Let's Verify Step by Step

2. Yao et al. (2024), τ-bench

3. Wang, Pradel & Liu (2025), Are “Solved Issues” in SWE-bench Really Solved Correctly?

4. Xu et al. (2024), Benchmark Data Contamination of Large Language Models

5. Zheng et al. (2023), Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

6. Ye et al. (2024), Justice or Prejudice? Quantifying Biases in LLM-as-a-Judge

7. Zhu et al. (2025), Establishing Best Practices for Building Rigorous Agentic Benchmarks

8. Tan et al. (2025), JudgeBench

9. Raina, Liusie & Gales (2024), Is LLM-as-a-Judge Robust?

10. Li et al. (2025), LLMs Cannot Reliably Judge (Yet?)

작성 메모

• WorkflowGraph는 Agent가 과업을 처리한 전체 경로를 뜻한다. 본문에서는 비전문가가 이해할 수 있도록 “일을 처리한 경로”로 먼저 설명했다.

• OracleWorkflow는 대상 시스템의 현재 상태와 개선속도를 평가하면서, 채점 시스템 자체의 정확성·일관성·공격 내성·기준 변화도 함께 관리하는 개념이다.

• disjoint는 대상과 평가 과정의 독립성을 높이기 위한 이 Repository의 설계 원칙이다. 인용 논문이 증명한 보편 법칙으로 주장하지 않는다.