AI 자기 검수의 한계: 클로드 코드에서 검증을 분리하는 방법
AI 자기 검수는 결과물을 만든 모델이 그 결과물을 스스로 평가하는 구조입니다. 2024년 연구에서 자기 출력을 알아보는 능력이 강한 모델일수록 그 출력에 더 높은 점수를 준다는 결과가 나왔습니다. 검증을 만든 쪽에서 떼어 놓는 방법과 그렇게 해도 남는 한계를 정리했습니다.

AI 자기 검수는 결과물을 만든 모델이 그 결과물을 스스로 평가하는 구조입니다. AI에게 일을 시킨 뒤 결과가 맞는지 다시 물어보는 방식은 이제 흔하게 쓰입니다. 잘 된 것이 맞느냐고 물으면 대체로 잘 됐다는 답이 돌아옵니다.
그런데 그 답을 어디까지 믿어도 되는지는 덜 알려져 있습니다. 같은 지시를 두세 번 반복하게 되는 상황이 이어지면, 대부분은 모델이 부족한 탓으로 결론을 내립니다.
원고를 쓴 사람이 자기 원고를 교정하면 오탈자가 눈에 잘 들어오지 않듯, 결과물을 만든 모델에게 그 결과물의 검수를 맡기면 문제가 드러나지 않은 채로 넘어갑니다. 출판사가 교정자를 따로 두는 이유와 같습니다. 이 글에서는 자기 검수가 왜 어긋나는지 연구 결과로 확인하고, 검증을 떼어 놓는 방법과 그렇게 해도 남는 한계를 정리하겠습니다.

AI가 자기 결과물에 더 높은 점수를 주는 현상
이 현상을 정면으로 다룬 연구가 2024년에 나왔습니다. Arjun Panickssery, Samuel R. Bowman, Shi Feng이 쓴 「LLM Evaluators Recognize and Favor Their Own Generations」이고, 같은 해 NeurIPS에 실렸습니다. 제목을 그대로 옮기면 LLM 평가자는 자기 생성물을 알아보고 편애한다는 뜻입니다.
연구진은 요약문 데이터셋을 놓고 두 가지를 따로 쟀습니다. 하나는 자기 인식(self-recognition), 즉 여러 요약문 가운데 자기가 쓴 것을 골라내는 능력입니다. 다른 하나는 자기 선호(self-preference), 즉 자기가 쓴 요약문에 더 높은 점수를 주는 정도입니다.
위 그림이 그 결과입니다. 두 값이 왼쪽 아래에서 오른쪽 위로 이어지는 직선에 가깝게 놓입니다. 자기 글을 잘 알아보는 모델일수록 자기 글을 더 좋게 평가했다는 뜻입니다.
여기서 한 걸음 더 나아간 실험이 있습니다. 연구진은 자기 인식 능력만 올리도록 모델을 미세 조정했습니다. 그러자 자기 선호 점수도 함께 올라갔습니다. 이 결과는 두 값이 우연히 같이 움직인 것이 아니라, 자기 글을 알아보는 능력이 편애를 만드는 쪽에 가깝다는 근거입니다.
정리하면 자기 선호 편향(self-preference bias)은 결과물을 만든 모델이 같은 결과물을 평가할 때 사람이 매긴 것보다 높은 점수를 주는 경향입니다.
AI는 왜 자기 문장에 더 높은 점수를 줄까요?
자기 인식이라는 개념은 자기 선호보다 상대적으로 낯설 수 있습니다. 쉽게 말하면 여러 글을 늘어놓았을 때 어느 것이 자기가 쓴 것인지 가려내는 능력입니다.

위 도표는 모델별 자기 인식 점수입니다. 사람이 쓴 요약과 자기 요약을 놓고 고르게 했을 때 GPT-4는 0.9를 넘겼습니다. 같은 조건에서 Llama 2와 GPT-3.5는 0.6대에 머물렀습니다. 다른 모델이 쓴 요약과 비교한 경우에는 값이 내려갑니다. Llama 2와 GPT-3.5는 0.5 근처로, 동전을 던진 것과 비슷한 수준입니다. GPT-4만 0.6에서 0.7대를 지켰습니다.
원인을 다르게 설명한 연구도 있습니다. 2024년 10월 공개된 「Self-Preference Bias in LLM-as-a-Judge」는 이 편향을 친숙함에서 찾습니다. 모델은 혼란도(perplexity)가 낮은 텍스트에 높은 점수를 주는 경향이 있는데, 자기가 만든 문장은 혼란도가 낮을 수밖에 없습니다. 자기가 쓸 법한 문장이라서 익숙하고, 그 익숙함이 품질 점수로 바뀌는 셈입니다.
교정 이야기로 돌아오면 이해가 빠릅니다. 자기가 쓴 문장 앞에서는 눈이 미끄러지듯 지나갑니다. 다음에 어떤 단어가 올지 이미 알고 있어서 글자를 하나하나 보지 않기 때문입니다. 모델도 자기 문장 앞에서 같은 상태가 됩니다.
검증을 만든 쪽에서 떼어 놓는 세 가지 방법
편향의 원인이 익숙함이라면 대응은 단순해집니다. 검수하는 쪽이 그 결과물을 낯설게 보게 만들면 됩니다. 실무에서 쓸 수 있는 방법은 세 가지입니다.
- 세션을 나눕니다: 만드는 작업과 검수하는 작업을 같은 대화에서 이어 하지 않습니다. 대화 기록에 결과물을 만든 과정이 그대로 남아 있으면, 검수 단계에서도 그 과정을 전제로 판단하게 됩니다. 클로드 코드에서는 서브에이전트를 따로 두거나 검수를 별도 세션으로 돌리는 방식이 여기에 해당합니다.
- 기준을 문서로 고정합니다: 지켜야 할 조건, 배경, 합의된 규칙을 파일 하나에 적어 둡니다. 교정자에게 교정 지침서를 건네듯, 검수하는 쪽에는 결과물이 아니라 기준을 먼저 줍니다. 기준이 대화 안에만 있으면 대화가 길어지는 동안 압축되거나 사라질 수 있습니다.
- 대조 시점을 정합니다: 판단이 필요할 때마다 그 문서와 맞춰 보게 합니다. 작업이 다 끝난 뒤에 한 번 훑는 방식보다, 판단이 나뉘는 지점에서 대조하는 편이 고치는 비용이 적습니다.
세 가지 가운데 두 번째가 가장 자주 빠집니다. 검수 역할만 따로 만들어 놓고 기준 문서를 주지 않으면, 검수하는 쪽도 결국 결과물만 보고 판단합니다.
자기 검수 구성과 분리 구성의 차이
두 구성이 실제로 어떻게 달라지는지는 표로 놓고 보면 분명해집니다.
| 항목 | 자기 검수 구성 | 분리 구성 |
|---|---|---|
| 검수 주체 | 결과물을 만든 세션 | 별도 세션이나 서브에이전트 |
| 판단 근거 | 대화에 남은 작업 과정 | 미리 적어 둔 기준 문서 |
| 대조 시점 | 작업이 끝난 뒤 한 번 | 판단이 나뉠 때마다 |
| 흔한 결과 | 대체로 잘 됐다는 답 | 기준에 어긋난 항목 목록 |
| 준비 비용 | 없음 | 기준 문서를 쓰는 시간 |
준비 비용이 분리 구성의 부담입니다. 기준 문서를 처음 쓰는 데 반나절 정도가 듭니다. 대신 같은 지시를 반복하던 시간이 줄어듭니다.
기준 문서에 무엇을 적을지 막막하다면 이미 두 번 이상 반복한 지시부터 옮기면 됩니다. 같은 말을 두 번 했다는 것은 그 조건이 대화에 남지 않았다는 신호입니다.
이 방법으로도 잡히지 않는 것
분리 구성이 모든 문제를 걸러 주지는 않습니다. 남는 구멍이 세 가지 있습니다.
첫째, 기준 문서에 적히지 않은 종류의 실수는 그대로 통과합니다. 교정자가 지침서에 없는 문제를 그냥 넘기는 것과 같습니다. 새로운 유형의 실수를 만날 때마다 문서에 한 줄씩 늘려 가는 방식으로 메울 수 있습니다.
둘째, 검수를 맡는 쪽도 같은 모델이면 편향의 일부는 남습니다. 세션을 나누면 대화 기록은 끊기지만 모델 자체가 바뀌지는 않습니다. 정확도가 중요한 작업이라면 다른 모델로 한 번 더 대조하는 방법이 있습니다. 토큰은 더 들지만 잘못된 결과를 되돌리는 비용보다는 적은 편입니다.
셋째, 기준 자체가 틀렸을 때는 검수가 오히려 잘못된 방향을 굳힙니다. 기준 문서는 한 번 쓰고 끝내는 문서가 아니라 작업이 진행되는 동안 함께 고쳐야 하는 문서에 가깝습니다.
그래서 마지막 확인은 사람이 맡는 편이 안전합니다. 분리 구성의 목적은 사람이 볼 것을 없애는 쪽이 아니라, 사람이 볼 양을 줄여 주는 쪽에 가깝습니다.
검증도 같은 모델에게 맡겨도 되나요?
세션만 나누어도 효과는 있습니다. 대화 기록에 남은 작업 과정이 판단에 끼어드는 것을 막아 주기 때문입니다. 다만 모델이 같으면 자기 문장을 익숙하게 느끼는 성질은 그대로 남습니다. 결과가 어긋났을 때 되돌리기 어려운 작업이라면 다른 모델로 교차 확인하는 편이 낫습니다.
검증 단계를 넣으면 토큰이 많이 들지 않나요?
늘어납니다. 검수를 위한 호출이 한 번 더 들어가고, 기준 문서를 매번 읽히는 비용도 붙습니다. 판단 기준은 되돌리는 비용과의 비교입니다. 잘못된 결과물을 그대로 넘겨 뒤에서 고치는 상황이 반복된다면, 검증에 쓰는 토큰이 더 싼 쪽에 가깝습니다.
사람이 검수하면 되는데 굳이 나눠야 하나요?
사람이 마지막에 보는 것은 그대로 필요합니다. 분리 구성은 사람이 보는 양을 줄이는 장치입니다. 기준에 어긋난 항목이 목록으로 먼저 올라오면, 사람은 전체를 다시 읽는 대신 그 목록부터 확인하면 됩니다.
3줄 요약
- AI 자기 검수는 결과물을 만든 모델이 그 결과물을 스스로 평가하는 구조이고, 2024년 연구에서 자기 글을 알아보는 능력이 강한 모델일수록 자기 글에 더 높은 점수를 준다는 결과가 나왔습니다.
- 대응은 검수하는 쪽이 결과물을 낯설게 보게 만드는 것입니다. 세션을 나누고, 기준을 문서로 고정하고, 판단이 나뉠 때마다 대조하게 합니다.
- 기준 문서에 없는 실수는 통과하고 같은 모델이면 편향의 일부가 남으므로, 마지막 확인은 사람이 맡습니다.
Sources
이 글이 도움이 되셨다면 공유해 주세요
메신저로 바로 보내거나 링크를 복사할 수 있습니다.

Written by
데이터로 설명하는 마케터
AI에게 작업을 시킨 뒤 같은 세션에서 결과를 검수시켰을 때 가장 먼저 의심할 점은 무엇일까요?
이 글이 도움이 되었나요?
다음 단계
이어서 읽기 좋은 글
OpenWiki 사용법: 코딩 에이전트를 위한 저장소 문서 자동 생성 도구
OpenWiki는 코딩 에이전트가 읽을 저장소 문서를 자동으로 만들고 유지하는 랭체인(LangChain)의 오픈소스 CLI 도구입니다. 사람용 문서와 에이전트용 문서의 차이, 설치와 자동 갱신 설정, 초기 벤치마크 결과까지 정리했습니다.
같이 보면 좋은 글

Qwen3.8 27B는 알리바바 Qwen 팀이 2026년 8월 공개한 Apache 2.0 오픈 웨이트 모델입니다. 메모리 24GB 맥미니 M4 프로에 직접 설치해 돌려 보니 GPU에 올라가지 못하고 CPU로 실행됐고, 그때 측정한 속도를 그대로 정리했습니다.
2026. 8. 16.
코덱스 CLI와 클로드 코드는 터미널에서 파일을 직접 읽고 만드는 코딩 도구입니다. 두 도구에 똑같은 규격서를 주고 같은 도구를 만들게 해서 걸린 시간, 결과물 규모, 안전장치가 어떻게 다른지 측정했습니다.
2026. 8. 16.
코덱스 CLI는 터미널에서 파일을 직접 읽고 만드는 코딩 도구입니다. 빈 폴더에서 시작해 내 글이 AI 답변에 인용되기 쉬운지 확인하는 GEO 점검 도구가 나올 때까지, 시킬 말 전문과 명령을 그대로 정리했습니다.
2026. 8. 16.
Google AI Studio는 Gemini 모델을 시험하고 자연어로 웹 앱과 Android 앱을 만드는 개발 환경입니다. 처음 접하는 분을 위해 Playground와 Build의 차이, 앱 제작 순서, API 키와 배포 시 주의할 점을 정리했습니다.
2026. 8. 16.ADVERTISEMENT