에이전트 검수와 평가: 자기 검수 편향과 별도 검수자

🤔 "잘 됐나요?"라고 물으면 늘 잘 됐다는 답이 올 때

에이전트에게 일을 맡긴 뒤 결과가 맞는지 같은 대화에서 다시 물어보는 일은 흔합니다. 대부분 잘 됐다는 답이 돌아오는데, 막상 확인해 보면 빠진 곳이 있습니다. 같은 지시를 두세 번 되풀이하게 되면 모델이 부족하다고 결론 내리기 쉽지만, 원인은 검수를 맡긴 구조에 있는 경우가 많습니다.

소스를 수십 번 맛본 요리사는 간이 센지 약한지 잘 모르게 됩니다. 같은 맛에 익숙해졌기 때문입니다. 에이전트도 자기가 만든 결과물 앞에서 비슷한 상태가 됩니다. 이 편에서는 자기 검수가 왜 후해지는지, 검수와 평가를 어떻게 떼어 놓는지를 도구와 상관없이 정리합니다. 클로드 코드에서 검증을 나누는 구체적인 방법은 AI 자기 검수의 한계에 있습니다.

🔑 에이전트 검수와 평가의 정의

에이전트 검수는 결과물 하나가 기준에 맞는지 확인하는 일이고, 에이전트 평가는 여러 과제를 반복해 돌려 에이전트를 얼마나 믿을 수 있는지 측정하는 일입니다.

둘은 보는 단위가 다릅니다. 검수는 오늘 받은 결과물 한 건을 봅니다. 평가는 과제 수십 개를 여러 번씩 돌려, 모델이나 지침이나 도구를 바꿨을 때 에이전트가 나아졌는지 나빠졌는지를 숫자로 확인합니다. 검수는 매일 하는 일이고 평가는 에이전트의 구성을 바꿀 때 하는 일입니다.

🪞 자기 검수가 후해지는 이유

결과물을 만든 모델이 자기 결과물을 평가하면 점수가 올라간다는 사실은 연구로 확인됐습니다. 2024년 발표된 「LLM Evaluators Recognize and Favor Their Own Generations」는 이를 자기 선호(self-preference)라 부르며, 사람이 보기에 품질이 같은데도 모델이 자기 출력에 다른 출력보다 높은 점수를 주는 현상으로 정의했습니다. 연구진은 모델이 자기 글을 알아보는 능력이 클수록 자기 글을 편애하는 정도도 커지는 직선에 가까운 관계를 찾았습니다.

같은 해 10월 공개된 다른 연구는 원인을 익숙함으로 설명했습니다. 모델은 자기에게 익숙한 글, 즉 혼란도(perplexity)가 낮은 글에 사람보다 높은 점수를 주는데, 자기가 만든 문장은 당연히 익숙하다는 설명입니다. 혼란도는 모델이 다음 단어를 얼마나 예측하기 어려워하는지를 나타내는 값입니다.

여기에 대화 기록이 겹칩니다. 같은 대화에서 검수를 시키면 결과물을 만든 과정과 이유가 대화에 그대로 남아 있어서, 검수하는 쪽도 그 과정을 전제로 판단합니다. 사용자의 말에 맞춰 주려는 아부 성향까지 더해지면 잘 됐느냐는 질문에는 잘 됐다는 답이 나오기 쉽습니다.

🧑‍⚖️ 검수를 만든 쪽에서 떼어 놓는 방법

편향의 원인이 익숙함과 대화 기록이라면, 검수하는 쪽이 결과물을 낯설게 보게 만들면 됩니다. 클로드 코드 공식 모범 사례 문서가 권하는 방법도 같은 방향입니다.

• 새 컨텍스트에서 검수합니다: 공식 문서는 새 컨텍스트가 코드 리뷰를 개선한다며, 방금 쓴 코드에 치우치지 않기 때문이라고 설명합니다. 한 쪽이 작성하고 다른 쪽이 검수하는 작성자와 검수자 분리 방식을 예로 듭니다
• 변경 내역과 기준만 줍니다: 새 서브에이전트로 도는 검수자는 변경 내역과 사람이 준 기준만 보고, 그 변경을 만든 추론 과정은 보지 않는다는 점이 장점으로 적혀 있습니다
• 짚을 범위를 좁힙니다: 같은 문서는 문제를 찾으라고 지시받은 검수자는 작업이 멀쩡해도 대개 무언가를 보고한다고 경고합니다. 정확성이나 요구사항에 영향을 주는 문제만 짚으라고 지시해 두어야 쓸데없는 지적이 줄어듭니다

기준을 문서로 고정하는 일도 함께 필요합니다. 검수자에게 결과물만 주고 기준을 주지 않으면 검수자도 결과물의 인상만 보고 판단합니다. 무엇을 지켜야 하는지 적은 문서를 먼저 주고, 결과물을 그 기준에 대조하게 합니다.

세션을 나눠도 모델이 같으면 익숙함에서 오는 편향 일부는 남습니다. 되돌리기 어려운 결과물이라면 다른 모델로 한 번 더 대조하고, 마지막 확인은 사람이 맡습니다. 검수를 나누는 목적은 사람이 볼 것을 없애는 것이 아니라 사람이 볼 양을 줄이는 것입니다.

🧪 결과를 판정하는 세 가지 방법

검수와 평가에서 결과를 판정하는 장치를 채점기(grader)라고 부릅니다. 앤트로픽이 2026년 1월 공개한 에이전트 평가 글은 채점기를 세 가지로 나눕니다.

순서는 코드 기반부터입니다. 코드로 확인할 수 있는 것은 코드로 먼저 걸러 내고, 남은 것을 모델 기반으로 보고, 사람은 마지막에 둘이 걸러 낸 목록을 봅니다. 앤트로픽은 에이전트 개발 도구를 소개하면서도 다른 모델이 채점하는 방식이 규칙 기반 확인보다 덜 견고하다고 적었습니다.

📊 평가에서 쓰는 말과 pass@k, pass^k

에이전트 평가 글이 정리한 용어를 알아 두면 평가 도구나 연구 결과를 볼 때 편합니다.

• 과제(task): 입력과 성공 기준이 정해진 시험 하나
• 시행(trial): 과제를 한 번 돌린 것. 같은 과제도 여러 번 돌립니다
• 채점기(grader): 에이전트가 잘했는지 점수를 매기는 장치
• 기록(transcript): 시행 한 번의 전체 기록. 출력, 도구 호출, 중간 결과가 모두 들어갑니다
• 결과(outcome): 시행이 끝났을 때 실제 환경에 남은 상태

에이전트는 같은 과제도 돌릴 때마다 결과가 달라서 성공률을 두 가지로 봅니다. pass@k는 k번 가운데 한 번이라도 성공할 확률이고, pass^k는 k번 모두 성공할 확률입니다. 한 번 성공률이 80%인 에이전트라면 세 번 중 한 번이라도 성공할 확률은 1에서 0.2의 세제곱을 뺀 99.2%이지만, 세 번 모두 성공할 확률은 0.8의 세제곱인 51.2%입니다.

여러 안을 받아 좋은 하나를 고르면 되는 일은 pass@k로 봐도 되고, 매일 같은 작업을 사람 확인 없이 맡기려면 pass^k로 봐야 합니다. 같은 에이전트라도 어느 쪽으로 보느냐에 따라 믿을 만한 정도가 크게 달라집니다.

📝 결과만 보지 말고 기록을 읽는다

평가 글은 기록을 정기적으로 읽으라고 권합니다. 결과가 통과로 나와도 과정이 어땠는지는 기록에만 남기 때문입니다. 보상 해킹처럼 테스트를 고쳐 통과한 경우는 결과만으로 정상 통과와 구분되지 않고, 기록을 읽어야 드러납니다. 반대로 결과는 실패인데 기록을 보면 채점기가 너무 엄격해서 멀쩡한 답을 틀렸다고 본 경우도 있습니다.

작게 시작한다면 실제로 실패했던 작업을 과제로 모으는 편이 쓸모가 큽니다. 성공 기준을 한 줄씩 적고, 과제마다 여러 번 돌려 보고, 모델이나 지침 파일을 바꿀 때마다 같은 과제 묶음을 다시 돌려 비교합니다.

⚠️ 검수와 평가에서 자주 하는 실수

• 만든 대화에서 바로 검수합니다: 과정이 남아 있는 대화에서 검수하면 결과가 후해집니다
• 기준 없이 검수자만 따로 둡니다: 검수 역할을 만들어도 기준 문서를 주지 않으면 결과물의 인상만 봅니다
• 한 번 성공으로 판단합니다: 한 번 잘 됐다는 것은 pass@1 한 번의 표본일 뿐이라 반복해서 맡길 근거가 되기 어렵습니다
• 모델 채점을 사람 기준에 맞춰 보지 않습니다: 다른 모델이 채점한 점수가 사람의 판단과 맞는지 가끔 표본으로 대조해야 채점기를 믿을 수 있습니다

❓ 자주 묻는 질문

검수도 같은 모델에게 맡겨도 되나요?

세션을 나누기만 해도 효과가 있습니다. 결과물을 만든 과정이 판단에 끼어드는 것을 막아 주기 때문입니다. 다만 모델이 같으면 자기 문장을 익숙하게 여기는 성질은 남으므로, 되돌리기 어려운 결과물은 다른 모델로 한 번 더 대조하는 편이 낫습니다.

검수 단계를 넣으면 토큰이 많이 들지 않나요?

늘어납니다. 검수를 위한 호출이 한 번 더 들어가고 기준 문서를 매번 읽히는 비용도 붙습니다. 잘못된 결과물을 넘긴 뒤 되돌리는 비용과 비교해서 정하는데, 같은 실수를 뒤에서 고치는 일이 반복된다면 검수에 쓰는 토큰이 더 싼 쪽에 가깝습니다.

평가 체계는 언제 만들어야 하나요?

에이전트의 구성을 바꾸기 전에 만듭니다. OpenAI는 파인튜닝 안내에서 평가를 먼저 만든 뒤에 투자하라고 강조하는데, 모델이나 지침을 바꿀 때도 같습니다. 바꾸기 전과 후를 같은 과제로 재야 나아졌는지 판단할 수 있습니다.

📋 3줄 요약

1. 결과물을 만든 모델이 자기 결과물을 평가하면 사람이 같은 품질로 본 것보다 높은 점수를 주는 자기 선호 편향이 2024년 연구들에서 확인됐습니다.

2. 클로드 코드 공식 문서는 새 컨텍스트의 검수자에게 변경 내역과 기준만 주는 작성자와 검수자 분리 방식을 권하고 검수자에게는 정확성과 요구사항에 영향을 주는 문제만 짚게 하라고 안내합니다.

3. 한 번 성공률 80%인 에이전트도 세 번 모두 성공할 확률은 약 51%라서 매번 믿고 맡길 일은 k번 중 한 번 성공률인 pass@k가 아니라 k번 모두 성공하는 pass^k로 판단합니다.

📚 참고 자료

• 앤트로픽, Demystifying evals for AI agents (2026-01-09): https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
• 클로드 코드 문서, Best practices: https://code.claude.com/docs/en/best-practices
• Panickssery, Bowman, Feng, LLM Evaluators Recognize and Favor Their Own Generations: https://arxiv.org/abs/2404.13076
• Wataoka, Takahashi, Ri, Self-Preference Bias in LLM-as-a-Judge: https://arxiv.org/abs/2410.21819