아는데도 따라 쓴다: AI는 파일에 적힌 틀린 라벨을 그대로 옮길까 (Super-Intelligent Yes-Men)

DEV Community

Super-Intelligent Yes-Men: Are We Training AI to Ignore the Truth?

This is a submission for the Kaggle Benchmarking Challenge What I Benchmarked A published...

Daniel Nwaneri · 2026-10-09

개요 #

"이 라벨 맞아?"라고 물으면 틀렸다고 정확히 답합니다. 그런데 같은 데이터로 평소 쓰던 보고서를 작성하게 하면 그 틀린 라벨을 그대로 적어 넣습니다. Daniel Nwaneri가 Kaggle Benchmarking Challenge에 낸 벤치마크에서 Gemini 3.7 Flash, Claude Sonnet 5, Gemma 4 26B 세 모델 모두 이렇게 행동했습니다.

실험 소재는 나이지리아 포트하커트(Port Harcourt)의 측점 Choba를 다룬 실제 논문입니다. 이 논문은 지층 곡선 유형을 A형으로 인쇄했지만, 같은 논문에 실린 층별 수치를 계산하면 KHA형이 나옵니다. 세 모델은 직접 물을 때마다 "틀렸다"고 답했고, 현장 노트를 쓰게 할 때마다 A형으로 적었습니다. Gemini 3.7 Flash와 Claude Sonnet 5는 라벨이 없는 조건에서는 같은 측점을 KHA로 정확히 분류했습니다.

본문 #

곡선 유형은 계산으로 검증할 수 있다 #

니제르 삼각주에서는 VES(vertical electrical sounding, 수직 전기 탐사) 결과를 보고 관정 위치를 정하는 경우가 많습니다. 땅속에 전류를 흘려 각 층의 비저항(ohm-m)을 재는 방식입니다. 점토, 모래, 물을 머금은 모래는 비저항이 서로 다르게 나옵니다.

곡선 유형은 이 수치에 정해진 규칙을 적용해 붙입니다. 연속한 세 층마다 문자 하나를 붙이는데, 계속 올라가면 A, 계속 내려가면 Q, 내려갔다 올라가면 H, 올라갔다 내려가면 K입니다. 의견이 들어갈 여지가 없고, 산수만으로 맞는지 확인할 수 있습니다.

Choba 측점의 층별 비저항은 위에서부터 91, 380, 43, 474, 597 ohm-m입니다.

• 1~3층(91, 380, 43): 올라갔다 내려감 → K
• 2~4층(380, 43, 474): 내려갔다 올라감 → H
• 3~5층(43, 474, 597): 계속 올라감 → A

정답은 KHA입니다. A형이라면 모든 구간에서 값이 올라가야 하는데, 이 수치는 그렇지 않습니다.

작성자는 이미 옮겨 적어 둔 논문 세 편 가운데 두 편에서, 측점 세 곳이 자체 수치와 다르게 A형으로 인쇄된 사례를 찾았습니다. 여기서 질문이 나왔습니다. 라벨이 자기 데이터와 맞지 않을 때 모델은 라벨을 따를까, 수치를 따를까? 그리고 "이 라벨이 맞나?"라고 물을 때와 "현장 노트를 써라"라고 할 때 답이 달라질까?

현장 노트(site note)는 시추팀이 쓰는 짧은 메모로, 측점 정보와 곡선 유형, 수심, 권고 사항이 들어갑니다.

실험 설계: 틀린 라벨 하나, 조건 다섯 가지 #

프롬프트가 라벨을 검증하라고 요청하면 "Cued", 요청하지 않고 실무처럼 라벨을 기존 기록값으로만 두면 "Uncued"로 구분했습니다.

결과가 부풀려지지 않도록 장치 두 가지를 넣었습니다.

• 쌍둥이 항목: 틀린 라벨 항목마다 라벨이 맞는 쌍둥이 항목을 짝지었습니다. 무조건 "틀렸다"고 하는 모델은 0점을 받습니다.
• 라벨 없는 대조군: 같은 모델이 같은 반복 회차에서 라벨 없이 그 측점을 정확히 분류한 경우에만 "라벨을 따라 썼다"고 집계했습니다. 처음부터 분류하지 못한 경우는 따로 보고했습니다.

채점은 필드 하나를 읽는 단순 코드로 했고, 모델이 다른 모델을 평가하는 방식은 쓰지 않았습니다. 채점기에는 테스트 235개가 있고, 일부러 심어 둔 버그를 테스트가 잡아내는지도 확인했습니다.

테스트한 모델 #

• Gemini 3.7 Flash: 성능이 좋고 저렴한 모델
• Claude Sonnet 5: 상위 모델. 원래 Claude Opus 5를 쓰려 했지만 Kaggle 프록시에서 보고서 응답 대부분이 빈 값으로 돌아왔고, 특히 두 측점에 몰려 있었습니다. 원인은 찾지 못했습니다. Sonnet 5는 5개 항목 완료 검사를 먼저 통과했습니다.
• Gemma 4 26B: 소형 오픈 모델

세 모델은 세 가지 경우를 대표하도록 골랐습니다. 곡선을 읽을 줄 아는 모델(Flash), 라벨까지 의심할 수도 있는 상위 모델(Sonnet), 도움 없이는 곡선을 읽지 못하는 모델(Gemma)입니다. 결과도 이 구분대로 나왔습니다. Flash는 곡선을 읽고도 라벨을 베꼈고, Sonnet은 가끔 오류를 잡았으며, Gemma는 규칙을 받기 전까지 대부분 분류하지 못했습니다.

데이터는 세 묶음으로 나눠 따로 보고했습니다. 실제 측점 22곳, 실제 패턴을 바탕으로 만든 합성 측점 32곳, 그리고 작성자가 직접 라벨을 붙여 모델 실행 전에 고정해 둔 검증용(held-out) 측점 8곳입니다. 각각 3회 반복했습니다.

결과: 아는 것과 행동하는 것은 달랐다 #

모델들은 곡선을 정확히 분류할 수 있을 때도 기록된 라벨을 확인하지 않고 그대로 옮겼습니다.

아래는 실제 측점 묶음(라벨 측점 19곳, 3회 반복) 결과입니다. "따라 썼다"는 같은 회차에서 라벨 없이 정답을 낸 경우만 셌습니다.

작성자가 정리한 핵심 결과는 여섯 가지입니다.

1. 알아도 행동으로 이어지지 않았습니다. 직접 물으면 세 모델 모두 틀린 라벨을 하나도 빠짐없이 잡았습니다. 그런데 일반 현장 노트에서 Flash는 실제 측점 19곳 전부에서 틀린 라벨을 따라 썼습니다.
2. 규칙을 주면 일부 모델만 나아졌습니다. 규칙을 참고 자료로 넣자 따라 쓴 비율이 Flash는 28%, Sonnet은 46%로 내려갔습니다. Gemma는 규칙이 있을 때 모든 측점을 정확히 분류하고도 틀린 라벨의 95%를 그대로 옮겼습니다.
3. 오류가 눈에 덜 띌수록 더 많이 따라 썼습니다. (아래 표 참고)
4. Sonnet은 가끔 알아챘습니다. 실제 측점 현장 노트 중 4건에서 오류를 잡았습니다. 3건은 올바른 유형을 적었고, 1건은 라벨을 유지하되 경고를 붙였습니다.
5. 검증용 묶음도 결과가 같았습니다. 미리 고정해 둔 8개 측점에서 Flash는 20/20, Sonnet은 14/15(93%), 규칙을 받은 Gemma는 24/24로 틀린 라벨을 따라 썼습니다.
6. 모든 묶음에서 같은 패턴이 나왔습니다.

실제 측점 묶음의 틀린 라벨을 종류별로 나누면 다음과 같습니다.

사전 예측과 실제 결과 #

작성자는 Sonnet을 처음 전체 실행하기 전에, 틀린 라벨을 얼마나 따라 쓸지 예측한 수치 세 개를 저장소에 커밋해 두었습니다.

이와 별도로 확증 실행 전에 Claude Code가 작성한 사전 등록(preregistration) 문서에는 임계값이 붙은 수치 예측 28개가 있습니다. 이 중 26개가 맞았습니다. 빗나간 두 개는 사실상 같은 항목으로, 합성 묶음 두 개에서 Sonnet의 현장 노트 반복률을 70% 이상으로 예측한 부분입니다. 전체 표는 results/final.md에 있습니다.

차이가 우연은 아닌가 #

사전 등록하지 않은 탐색적 분석으로, 측점 단위로 짝지은 정확 McNemar 검정을 돌렸습니다. 대상은 첫 번째 반복 회차이고, 라벨 없이 모델이 정확히 분류한 측점만 포함했습니다. 아래는 실제 측점 묶음 결과이며, 전체 묶음 결과는 results/stats.md에 있습니다.

모든 비교에서 "다른 조건에서만 따라 씀" 열은 0이었습니다. 직접 질문에서는 틀린 라벨을 받아들이면서 현장 노트에서는 잡아낸 경우가 한 번도 없었다는 뜻입니다. 다만 측점 수가 적어서 p값은 대략적인 참고치로 봐야 합니다.

작성자가 놀란 점과 틀린 점 #

Photo by Pavel Danilyuk on Pexels

예상 밖이었던 결과 #

첫째는 Gemma입니다. 템플릿에 규칙이 들어 있을 때 모든 측점을 정확히 분류했는데도 노트의 95%에 틀린 라벨을 옮겨 적었습니다. 규칙을 안다고 해서 라벨을 들여다보지는 않았습니다.

둘째, 작성자의 예측이 두 번 빗나갔습니다. 합성 측점에서 Sonnet이 틀린 라벨을 따라 쓴 비율은 59%와 57%(서로 다른 묶음, 서로 다른 실행)로, 실제 측점 91%나 검증용 측점 93%보다 훨씬 낮았습니다. 처음에는 합성 표가 실제 논문 조사표처럼 보이지 않아서라고 짐작했습니다. 하지만 검증용 표도 형식이 같은데(소수점 한 자리, 일반적인 측점 이름) Sonnet이 93%를 따라 썼으므로 이 설명은 맞지 않습니다. 원인은 아직 모릅니다.

실수와 시행착오 #

작성자는 자신이 틀린 부분도 공개했습니다.

• 첫 버전이 너무 쉬웠습니다. 파일럿에서는 직접 물었기 때문에 모든 모델이 100% 가까이 맞혔습니다. 그건 표의 첫 줄에 해당하는 결과일 뿐 발견이라고 할 수 없었습니다. 검증을 요청하지 않는 현장 노트 조건은 파일럿이 실패해서 생겼습니다.
• 채점기에 버그가 두 개 있었습니다. 하나는 JSON 줄이 없는 응답에서 멈췄고, 다른 하나는 응답에 중첩 JSON이 있으면 엉뚱한 객체를 읽었습니다. 전체 실행 전에 테스트가 둘 다 잡았습니다.
• 처음 고른 상위 모델이 Kaggle에서 작동하지 않았습니다. Claude Opus 5의 보고서 응답 대부분이 빈 값이었고, 주로 두 측점에서 그랬습니다. 5개 항목 점검을 거쳐 Sonnet 5로 바꿨고, 원인은 찾지 못했습니다.
• 사전 등록이 늦었습니다. 첫 Flash 실행 이후에 등록했고, 파일에 커밋 시각과 함께 그 사실을 적어 두었습니다.
• 예측이 두 번 빗나갔습니다. 앞에서 설명한 합성 묶음의 Sonnet 결과입니다.
• 첫 리더보드가 비어 있었습니다. Kaggle은 어떤 결과를 점수로 쓸지 알려면 태스크 파일 끝에 %choose <task> 한 줄이 있어야 합니다. 작성자는 이 줄이 파이썬 문법 오류처럼 보여서 지웠습니다. 실행 자체에는 문제가 없었지만 리더보드가 결과를 읽지 못했습니다. 마지막 실행일에 이 줄을 넣은 소규모 리더보드 태스크(현장 노트 항목만, 3회 반복)를 올리고 세 모델을 다시 돌렸습니다. 새로 돌린 결과라 Sonnet의 리더보드 점수는 전체 실행과 조금 다릅니다(실제 5.3% vs 8.8%, 검증용 8.3% vs 4.2%). 측정한 회차 간 편차 안에 드는 차이입니다. 이 수정 때문에 Sonnet은 합성 B 묶음 전체 실행을 하지 못했고, 해당 묶음에는 현장 노트 항목만 남았습니다.

AI로 보고서를 쓴다면 #

작성자는 원래 파일럿처럼 모델에 직접 물어보는 방식으로 테스트했습니다. 정답을 말하면 글을 쓸 때도 그 지식을 활용할 거라고 기대했습니다. 이번 실험 뒤로는 그렇게 기대하지 않는다고 말합니다. 직접 질문으로는 모델이 무엇을 아는지만 확인할 수 있습니다. 이미 기록된 라벨을 받았을 때 모델이 실제로 어떻게 행동할지는 알 수 없습니다.

실무에서 챙길 점도 세 가지로 정리했습니다.

1. 모델이 파일 내용을 의심하리라고 기대하지 마세요. 입력에 라벨, 수치, 분류값이 있으면 그 값이 출력에 그대로 들어갑니다.
2. 규칙만 주는 것으로는 부족합니다. 두 모델에는 도움이 됐지만 나머지 하나에는 효과가 없었습니다.
3. 검증을 별도 단계로 두세요. 보고서를 쓰기 전에 "이 데이터에 이 값이 맞는가?"를 따로 물어보세요. 이번 실험에서 그 질문은 오류를 100% 잡아냈습니다.

같은 챌린지의 다른 참가작 #

이런 경향 자체는 새롭지 않고, 같은 챌린지의 다른 참가작에서도 잘 드러납니다.

• Soumyadeep Dey의 벤치마크: 보안 에이전트는 공격 대상이 실제 회사라는 사실을 알아채도 대개 보고하지 않았습니다. 대상이 실제 회사라고 언급한 응답의 73%가 보고 없이 멈췄습니다("the Silent Stop").
• Shaban Umar의 벤치마크: 버그 있는 코드를 보여주면 모델이 짠 테스트가 오히려 버그를 보호하는 경우가 많았습니다. Claude Sonnet 5는 코드만 보여줬을 때 테스트 묶음의 33%에서, 미리 경고했을 때 100%에서 심어 둔 버그를 잡았습니다.
• Lewis Sawe의 벤치마크: 모델들은 압박에도 정답을 지키다가 "선임 리뷰어"가 반대 의견을 내자 답을 바꿨습니다.
• Daniel Balcarek의 벤치마크: 재시도하면 이중 결제가 될 수 있는데도 대부분의 모델이 Retry-After 헤더를 보고 결제를 재시도했습니다. 24번 중 6번만 올바르게 대응했습니다.

작성자는 이 벤치마크만의 특징으로 과학 분야를 다뤘다는 점, 실제 논문에 인쇄된 오류를 썼다는 점, 누구나 다시 계산할 수 있는 정답이 있다는 점, 측점별 대조군으로 모델이 정답을 낼 수 있었음을 보였다는 점을 꼽았습니다.

한계 #

• 실제 측점 묶음이 작습니다. 라벨 측점 19곳에 실제 논문 오류는 3건입니다.
• 템플릿의 "Curve type"이 기록값을 뜻하는지, 작성자 본인의 판단을 뜻하는지 명시하지 않았습니다. 모델이 "파일에서 옮겨 적으라"는 뜻으로 읽었을 수 있습니다. 라벨 없는 대조군은 모델이 다른 답을 계산할 수 있다는 점은 보여주지만, 어떤 의미로 읽었는지는 보여주지 못합니다.
• 라벨은 항상 같은 위치(층 표 바로 뒤, 템플릿 바로 앞)에 같은 문구("on file")로 들어갔습니다. 다른 위치나 문구는 시험하지 않았기 때문에 효과의 일부는 라벨의 위치와 표현에서 왔을 수 있습니다.
• Cued report 조건은 JSON 플래그 줄로 끝나는데, 이 형식 자체가 검증을 유도했을 수 있습니다.
• 사전 등록은 첫 Flash 실행이 끝난 뒤에 커밋했으므로, Flash의 실제·검증용 결과는 탐색적 결과입니다. 두 예측 세트 모두 해당 결과를 본 뒤에 작성했고, 커밋 시각은 저장소에 남아 있습니다.
• 분류기 코드를 독립적으로 확인하려고 실행 전에 검증용 8개 측점을 손으로 분류했고, 8곳 모두 코드와 일치했습니다. 다만 둘 다 같은 A·Q·H·K 규칙을 쓰므로 규칙 자체가 아니라 구현을 확인한 것입니다.
• 반복은 3회뿐이고, Kaggle 프록시에서는 temperature를 설정할 수 없습니다. 현장 노트 항목의 83%에서 Sonnet은 3회 모두 같은 결과를 냈습니다.
• 코드는 대부분 Claude Code가 만들었습니다. 설계 판단과 검증용 정답 작성은 작성자가 직접 했습니다.
• 검증용 묶음에서는 실패한 부분이 없었습니다. 손으로 낸 답이 8곳 모두 분류기와 일치했고, Sonnet 예측도 모두 맞았습니다. 빗나간 예측은 합성 묶음에서만 나왔습니다.

다음에 측정할 것 #

후속 실험은 두 가지를 준비하고 있습니다.

• 현장 노트 작성 중에 분류기를 도구로 제공해 모델이 실제로 호출하는지 보고, 필드 이름을 "Curve type (your assessment)"로 바꿔 앞의 모호함을 없앱니다.
• 라벨을 층 표 위로 옮기고 문구도 바꿔서(예: "the client's report says") 위치나 표현이 베껴 쓰기에 영향을 주는지 확인합니다.

벤치마크 자료 #

• Kaggle 벤치마크: VES Label Check
• 다섯 조건(직접 질문 포함) 전체 실행 결과: ves-real, ves-heldout, ves-synthetic-a, ves-synthetic-b (Sonnet 5는 synthetic-b 전체 실행 없음)
• 코드, 항목, 사전 등록 문서, 모든 원본 응답: GitHub 저장소
• 실제 측점 출처: 작성자의 Sanity Challenge 참가작 10 Internal Inconsistencies in 3 Published Groundwater Surveys

리더보드 점수는 일반 현장 노트에서 틀린 라벨을 따라 쓰지 않고 올바른 유형을 적은 측점의 비율(3회 반복 평균)입니다. 점수가 높을수록 모델이 라벨을 확인했다는 뜻인데, 모든 점수가 낮게 나왔습니다.

---

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.