AI 에이전트 2대에게 단 '5번의 프롬프트'로 동일한 LP를 만들게 하여 자기 평가를 의심하게 된 ― 바이브 코딩(Vibe Coding)

이 기사는 화학 실험 보고서의 작성 방식(목적 → 이론 → 결과 → 고찰 → 결론)에 따라 작성되었습니다. '두 가지 AI를 사용해 본 감상'이 아니라, 가설을 세우고, 만들고, 부수고, 관측하고, 고찰한 기록입니다. 관측 장치는 트레이스(Trace)가 아니라, 5회의 프롬프트와 그 출력 코드 자체입니다.

1. 목적 (요건 정의)

배경 및 과제

Antigravity (Gemini)와 Claude Code (Claude)를 매일 병용하고 있다. 둘 다 우수하기 때문에, 오히려 "어느 것을 어느 공정에 사용해야 할지"를 감각(vibe)으로 결정해 왔다. 감각은 재현성이 없고, 타인에게 설명할 수 없으며, 틀려도 알아차릴 수 없다. 이것이 병목 현상(Bottleneck)이었다.

가설

화학 실험과 마찬가지로, 검증 가능한 두 가지 가설을 세운다.

H1 (만들기): 바이브 코딩 (Vibe Coding, 인간은 코드를 쓰지 않고 자연어 지시만 수행)으로, 5회의 프롬프트 이내에 일정 품질의 LP(Landing Page)를 만들 수 있지 않을까? = "만드는 것"은 범용화(Commodity)되고 있는 것이 아닐까? -
H2 (믿기·핵심): AI의 자기 평가(자기 신고 완성도 %)나 겉으로 보이는 첫인상은 결과물의 품질을 반영하는 신뢰할 수 있는 지표인가? 실제로 만들어 보고, 상호 리뷰를 통해 반증을 시도한다.

본 기사의 위치 (엄격한 대조 실험은 아님)

먼저 솔직하게 밝힌다. 이것은 엄격한 대조 실험이 아니라, n=1의 탐색적인 사례 관찰이다. 변수가 동시에 여러 개 움직이고 있다: ① 모델 계층이 비대칭적임 (중위 Flash vs 최상위 Opus), ② 실행 환경이 다름 (IDE 자율 주행형 Antigravity vs CLI형 Claude Code), ③ 네 번째 프롬프트는 약점별로 문구를 나누어 제시했으므로 동일한 자극이 아님. 따라서 본 기사의 주장은 "Gemini < Claude"라는 일반 법칙이 아니라, 이 하나의 케이스에서 무엇이 관측되었는가에 한정된다. 혼란 변수를 제거하는 것이 아니라, 이를 인지한 상태에서 관측하고 추후 재현 가능한 형태로 기록하는 것이 목적이다.

평가 설계 (KPI)

구분	지표	측정 방법
만들기	5프롬프트 이내에 완성했는가	인간의 제작 로그 (전송 대상·횟수)
...

스코프

In: 요건 정의 읽기 → 5회의 자연어 지시로 LP 완성 → 채점 → 상호 리뷰. -
Out (향후 확장): 백엔드에서의 동일 검증 (Vol.02), 플래그십 모델 간의 비교 (Gemini 3.5 Pro 등장 이후). -

실험 조건 (제작 규칙)

ID	규칙	내용
R-01	바이브 코딩 (Vibe Coding)	인간은 코드를 직접 편집하지 않는다. 자연어 지시와 출력 코드를 읽고 판단하는 것만 수행한다.
...

2. 이론

2.1 바이브 코딩 (Vibe Coding)

인간이 코드를 한 줄씩 쓰는 대신, 자연어로 의도를 전달하여 AI가 생성, 수정, 디버깅하게 하는 개발 스타일. Andrej Karpathy가 2025년 2월에 제창하였고[1], 같은 해 Collins 사전의 올해의 단어(Word of the Year)로 선정될 정도로 일반화되었다. 원의는 "코드의 존재를 잊을 정도로 AI에 맡긴다"는 탐색적인 것이며, 본 실험처럼 인간은 판단만 하고 코드는 쓰지 않는 설정은 그 엄격한 실천에 해당한다.

2.2 에이전트형 코딩 환경의 차이 (IDE 자율 주행 vs 터미널)

같은 "AI에게 코드를 쓰게 하는 것"이라도 실행 환경의 사상이 다르다. Antigravity는 IDE형으로, 한 번의 지시 안에서 브라우저를 열어 자기 검증을 수행하는 등의 자율 주행까지 수행한다. 터미널의 Claude Code는 CLI형으로, 편집과 검증을 지시 범위 내에 가두기 쉽다. 이 설계 차이는 모델의 우열과는 별개의 축이며, 후술할 행(Hang) 사건(3.2)의 원인이 된다.

2.3 자기 평가의 신뢰성 ―― 과신 현상

LLM에게 자신의 출력을 채점하게 하는 "자기 평가"는 간편하지만

다만 주의가 필요하다. 이 연구들이 다루는 것은 주로 **벤치마크 채점에서의 신뢰도 교정 (Calibration)**이며, 본 실험에서 관측한 '모델이 자신이 작성한 코드에 부여한 완성도 %'와는 설정이 다르다. 따라서 본 기사에서는 이를 직접적인 증거가 아닌, 과신(Overconfidence)이라는 일반적인 경향에 대한 방증으로 인용한다. 그렇다고 해도 '자기 신고된 높은 점수를 액면 그대로 믿어도 되는가'라는 질문에 대해, 신중해야 할 이유는 제공해 준다. 이 논점은 본 실험의 핵심(H2)과 맞닿아 있다.

2.4 LLM-as-a-Judge と 상호 리뷰

LLM에게 다른 출력을 평가하게 하는 수법. 수동 평가를 스케일링할 수 있는 반면, 평가자 자신에게 편향(Bias)과 변동성(Fluctuation)이 존재한다는 점이 포괄적인 서베이를 통해 정리되어 있다 [4]. 본 실험에서는 '자기 평가'의 한계를 보완하기 위해, **양측 모두에게 상대방의 코드를 리뷰하게 하는 상호 리뷰 (Mutual Review)**를 채택했다. 자신의 작업물을 관대하게 보는 과신이 있더라도, 제3자(상대 모델)의 눈에는 허점이 보일 것이라는 가정에 기반한다.

2.5 모델 계층과 비용/레이턴시 (Latency)의 트레이드오프

중위 모델 (Flash)은 빠르고 저렴하며, 최상위 모델 (Opus)은 느리고 비싸지만 추론이 깊다는 계층 차이가 있다. '빠름/보기 좋음'과 '정확함/유지보수 용이함'은 동일한 축이 아니다. 본 실험은 의도적으로 이 비대칭적인 계층을 비교하여, '중위 모델이 어디까지 경쟁할 수 있는가'를 관측한다.

2.6 코드 품질은 행수로 측정할 수 없다

동일한 요구사항을 충족하는 코드라도 행수 (LOC, Lines of Code)가 적다고 해서 더 우수한 것은 아니다. 하지만 LOC는 중복, 미사용, 장황함의 대리 지표(Proxy indicator)가 될 수 있다. 본 실험에서는 행수를 1차 관측량으로 기록하면서, 품질은 루브릭 (Rubric) 채점과 상호 리뷰로 판정한다. 바이브 코딩 (Vibe Coding)의 일반적인 우려로서 생성물의 유지보수성, 가독성, 보안성이 지적되고 있으며, '작동하는 것'과 '유지보수 가능한 것'을 분리해서 볼 필요가 있다.

3. 결과

3.1 실험계 (프로토콜)

전체 구성은 '요구사항 정의 → 5회의 지시 → 채점 → 상호 리뷰'이다. 양측 모두 동일한 요구사항 정의 (Single Source of Truth)와 거의 동일한 프롬프트를 순서대로 전달했다. 변수는 에이전트뿐이다.

채점 루브릭 (100점·각 축 20점)

평가는 **5회의 제작 '외부'**에서, 제작에 참여하지 않은 제3자 (별도 AI + 인간)가 수행한다. 자기 채점은 하지 않는다. 제약 사항 준수 여부는 AI가 아닌 실제 파일의 기계적 검증과 인간의 제작 로그를 통해 확인한다.

평가 축	배점	판정 방법
요구사항 충족	20	전체 11개 섹션의 유무 및 정확성
...	...	...

3.2 예비 결과 (관측된 장애)

관측 1: Antigravity가 자율 주행 중 행(Hang) 상태에 빠짐

제2회 지시 후, Antigravity는 '브라우저의 서브 에이전트로 페이지를 열어 자기 검증을 수행하고, WebP 영상 기록까지 남기는' 공정에 자율적으로 진입했다가 그곳에서 멈춰버렸다. 똑똑하게 모든 것을 다 하려다 무거워지는 거동이다 (이론 2.2). 재시작을 통해 복구되었으며, 그 과정에서 Antigravity 2.0으로의 업데이트가 이루어졌다.

Antigravity의 자율 주행 (브라우저 기동 + 녹화) 중 발생한 행(Hang). 모델이 아닌 환경 설계에 기인한 장애

관측 2: 세션 단절에 의한 문맥 상실

Claude 측은 도중에 모델을 Opus 4.7로 전환하면서 새로운 세션이 되었기 때문에, 제2회 초반에 "요건정의.md와 현재의 index.html을 읽어 들인 후 편집"이라는 지시를 추가하여 문맥을 재구축하게 했다. 코드를 작성하지 않는다는 것이 = 내부 사양을 몰라도 된다는 뜻은 아니다. 어디서 문맥이 끊기는지를 파악하는 능력이 곧 디버깅 능력이 된다.

3.3 본 실험 (5회 프롬프트 관측)

매 회차, 인간이 던진 실제 프롬프트와 양측의 반응을 기록한다. 프롬프트 전문은 접기(Folding) 안에 수록했다.

제1회: 요구사항 정의를 읽게 하여 초안을 한 번에 작성하게 함

제1회 프롬프트 (전문)

당신은 시니어 레벨의 프론트엔드 엔지니어입니다. 프로젝트 내의
요건정의.md 를 읽고, 그 사양에 엄격히 따라 단일 페이지 LP를 구현하십시오.
■ 역할과 전제 (절대 준수)
...

Gemini: 내부에서 여러 번 자율적으로 실행하여, 유동적인 타이포그래피(Fluid Typography)·히어로 섹션의 SVG 애니메이션·CTA 직하단 마이크로 카피(Micro-copy)까지 포함된 초안을 빠르게 제시. 자기 평가(Self-evaluation)는 매우 자신만만함.
Claude: 11분 42초에 걸쳐 총 11개 섹션 + FAQ 아코디언 + 더미 폼 + 햄버거 메뉴까지 구현. 자기 평가는 **"72%"**로 겸손하며, 미달된 점(FV 우측 비주얼, 요금 카드 스마트폰 동작, 시선 유도, 모바일 헤딩)을 스스로 나열함.

제2회: "AI가 만든 느낌"을 벗겨내기

이모지 아이콘과 과도한 그라데이션이 신경 쓰여, 선형 아이콘(Line icon)화·장식의 절제·카피의 구체화를 지시(행(Hang) 현상 방지를 위해 Gemini에는 "자율적인 추가 이터레이션(Iteration) 금지 / 자동 브라우저 검증 금지"를 추가).

Gemini: 이모지를 전면 폐지하고 단색화, 그라데이션과 부유 애니메이션을 제거. 지시에는 순순히 따름 (그 후 행(Hang) 발생, 3.2 관측 1).

Claude: 이모지를 선형 아이콘으로 교체하면서, 초안에 포함했던 가짜 실적 수치(합격률 92%·누적 1,200명 등)를 자신의 판단으로 제거하고, 사실 기반의 소구(Appeal)로 교체했다고 보고함. 아무도 지시하지 않았는데 과장 표현을 자기 검열함.

제3~5회: 관측 요약

제3회(CV 강화)·제4회(감점 요소의 구분 제시)·제5회(최종 마무리)의 관측 내용을 표로 정리함.

회차	지시의 주안점	Gemini의 반응	Claude의 반응
P3	CV 강화 (FV·목소리·요금·시선)	반영 + 자기 평가 "94%". 추가로 빛 애니메이션 등의 더하기를 제안	반영 + 자기 평가 "88%". 남은 금색·미사용 CSS·배점 바의 약점을 자기 공개
P4	감점 요소를 지목하여 해결 (구분 제시)	반응형/a11y(접근성)는 강화. 경량화는 미수행 (2,408→2,474행)	색상을 파란색 + 무채색으로 통일, 미사용 CSS 삭제, 배점 바 쇄신, "비(非)파란색 0건"을 (6분 38초) `grep`으로 검증
P5	최종 마무리·완성 확정	자기 평가 "100%"로 완성 선언 (최종 2,474행). 경량화는 여전히 미수행	aria 속성 87개·focus 대응을 최종 강화 (최종 1,194행). 자기 평가는 겸손하게 남은 과제를 공개

여기서 유효한 점은 두 가지임. Gemini는 반복할수록 자기 평가가 상승(94→100%)했으며, 지시받은 정리(경량화)는 실행하지 않았음. Claude는 마지막까지 자기 평가를 억제하면서, 자신의 출력을 기계 검증(grep)하여 결함을 제거함. 자기 평가의 방향이 양자 간에 정반대로 향하고 있음.

3.4 채점 및 상호 리뷰

루브릭(Rubric) 채점 (코드 + 제약 + 구조)

평가 축	Gemini	Claude
요건 충족	19	19
...	합계
	89	94

양쪽 모두 단일 파일·외부 의존성 제로("<img> 없음·외부 CDN/폰트/라이브러리 없음·https는 SVG 네임스페이스만 사용)·이모지 거의 전면 폐지·시험 정보 수치 정확·가공의 면책 조항 있음"을 충족함. 차이가 난 부분은 색상 수(Gemini는 조기에 단색화, Claude는 최종 단계에서 파란색 + 무채색으로 통일)와 코드 품질임.

외부 AI (GPT)의 마케팅·외관 관점: 양쪽 모두 82~88점으로 거의 대등함. 그리고 양쪽 모두에게 동일한 약점(실재감 부족·CTA의 단조로움·사회적 증거의 약함)을 지적함.
인간(나)의 육안 확인: 프론트엔드의 외관은 Gemini의 승리. 직관적으로 "이쪽이 더 잘 팔릴 것 같다"는 느낌이었음.

결정타: 상호 리뷰

Claude가 Gemini의 코드를 리뷰했을 때, 다음 항목들을 검출함 (중요도와 "왜 문제인가" 포함).

검출 항목	유형	중요도	왜 문제인가
한글 문자 혼입 ("코스트 최적화의 기초")	글자 깨짐	높음	공개할 경우 한눈에 품질이 의심됨. 리뷰 없이는 알아차릴 수 없음
탈자 ("話が進まない" → "話が進ない")	오타	중간	독자의 신뢰를 손상함. 일본어의 문법적 어색함은 스펠링 체크로 잡아내기 어려움
주석의 typo	가독성	낮음	동작은 하지만 유지보수 시 혼란 요인
`outline: none`으로 인한 포커스 소실	접근성 (Accessibility)	높음	키보드 조작 불가능. WCAG 위반이 될 수 있는 실질적 해악
존재하지 않는 CSS 클래스 참조	데드 코드 (Dead Code)	중간	의도한 스타일이 적용되지 않음 / 유지보수 비용을 높임

반면 Gemini의 리뷰는 버그를 거의 검출하지 않았으며, 「훌륭함」「최고 수준」「상용 공개 가능」이라며 높은 평가를 늘어놓았다.

Claude는 버그 헌터, Gemini는 칭찬꾼. 자기 신고 「100%」의 실체는 상대의 눈에 결함으로 비쳤다

3.5 정량 측정

항목	Gemini 3.5 Flash	Claude Opus 4.7
최종 코드 라인 수	2,474행	1,194행
...
※ 수치는 모두

단일 시도(Single Trial)의 실측값(여러 번의 평균이 아님). 라인 수·소요 시간·자기 평가 %는 공개 전에 자신의 제작 로그와 하나씩 대조할 것 ("자기 신고를 믿지 마라"가 주제인 기사에서, 스스로의 숫자가 확인되지 않았다면 본말전도이다).

4. 고찰

4.1 왜 자기 평가(H2)는 빗나갔는가

3.5가 보여주듯, 최종적으로 「100%」라고 선언한 Gemini의 코드에는 실제 버그가 남아 있었고, 「88%」라고 겸손하게 신고한 Claude의 코드가 더 견고했다. 본 케이스에서는 자기 신고의 높이가 실제 품질을 보장하지 않았다 (오히려 높은 자기 평가를 한 쪽에 결함이 남았다). 다만 이는 두 개의 서로 다른 모델에게 완성도 %를 물은 값이며, 교정된(calibrated) 수치 비교가 아니다. 「100% > 88%」를 양적으로 비교하는 것이 아니라, 「100%라고 단언한 쪽에 버그가 있었다」는 케이스 내의 사실을 보고 있는 것이다.

이 괴리는 이론 2.3의 과신이라는 일반적인 경향과 일치한다고 생각된다 (단, 2.3에서 언급했듯이 그것들은 벤치마크 채점의 지견이며, 여기서는 직접적인 증명이 아닌 방증이다). Gemini의 자기 평가가 94% → 100%로 반복하며 상향된 것은 그 경향의 한 예라고 추측된다. 적어도 본 케이스의 범위 내에서는, "AI의 자기 신고 %를 액면 그대로 품질 지표로서 믿는 것"은 타당하지 않았다고 할 수 있다.

4.2 왜 "겉모습은 Gemini, 알맹이는 Claude"였는가

3.4에서 인간의 육안과 GPT의 마케팅적 관점은 Gemini를 높게 평가했으나, 코드 품질과 상호 리뷰(Mutual Review)에서는 Claude가 앞섰다. 이는 "빠름/보기 좋음"과 "정확함/유지보수 용이함"이 별개의 축이라는 것(이론 2.5)의 직접적인 발현이라고 생각된다.

Gemini가 내버려 두면 덧셈(장식·기믹)으로 회귀하고, Claude가 뺄셈과 자기 점검(과장 표현의 자진 철거, grep 검증)으로 향한 것도 이 축의 차이로 해석할 수 있다. 첫인상(겉모습)은 품질의 일부이긴 하지만, 전체의 신뢰할 수 있는 대리 지표(proxy indicator)는 아니다라고 보는 것이 타당할 것이다.

4.3 한계: 계급 차이·환경 차이·실험자 편향

본 실험은 중간 단계인 Flash와 최상위 단계인 Opus의 비대칭 비교이며(실험 조건 R-05·서두 주기), 결과를 "Gemini < Claude"로 일반화해서는 안 된다. 오히려 주목해야 할 점은, 중간 단계인 Flash가 겉모습으로 사람의 눈을 사로잡았다는 사실이며, 이는 Flash의 완성도가 높다는 사실 그 자체라고 생각된다.

또한 3.2의 행(hang)은 모델의 능력이 아니라 Antigravity의 자율 설계(IDE형·브라우저 자기 검증)에 기인하는 면이 크다(이론 2.2). 비교 대상에는 "모델의 차이"와 "환경의 차이"가 혼재되어 있다.

그리고 가장 솔직하게 적어야 할 한계는 이것이다. 본 실험의 설계와 채점에는 실험자 편향(Experimenter Bias)이 포함될 수 있다. 나는 Claude를 일상적으로 사용하며, 검증을 포함하고, 채점의 일부도 직접 수행하고 있다. 결론이 Claude 쪽으로 기울게 되는 구조적인 편향은 부정할 수 없다. 완충 장치로서 "인간 육안으로는 Gemini를 상위에 두었다"는 채점과 제3자 AI(GPT)의 견해를 병기하였으나, 편향을 완전히 배제하지는 못했다. 독자는 이 점을 감안하여 읽어주길 바란다.

4.4 이 실험이 보여주는 "용도 구분"의 정체

3.3이 보여주듯 "만드는 것"은 5번의 프롬프트 이내에 달성되었으며(H1은 지지됨), 비용도 작았다. 가치가 갈린 지점은 만든 후――과장 표현을 지우고, 버그를 찾아내며, 유지보수 가능한 형태로 만드는 공정이었다.

이를 통해, 분위기(vibe)나 자기 신고가 아니라, 관측 데이터(상호 리뷰·실제 파일 검증)를 바탕으로 공정마다 용도를 구분하여 사용해야 한다고 생각된다. 초안의 양산은 빠른 Gemini, 실전에 올리기 전의 정밀 조사와 마무리 작업은 결함을 스스로 공개하는 Claude, 라는 분업이 본 실험의 범위 내에서는 합리적이었다.

5. 결론

H1은 지지되었다. 바이브 코딩 (Vibe Coding)으로 '만드는 것'은 빠르고 저렴하다. 5번의 프롬프트 이내에 양측 모두 제약 사항을 충족하는 LP를 완성했다. -
H2는 본 케이스에서는 지지되지 않았다 (반증의 방향). 자기 평가 (Self-reported %)와 첫인상은 품질의 신뢰할 수 있는 지표로 기능하지 않았다. '100% 선언'에 버그가 있었고, '88% 신고'가 견고했다. 이는 과신이라는 일반적인 경향 (이론 2.3)과 일치하지만, n=1의 관측이며 일반 법칙의 증명은 아니다. -
관점에 따라 승자는 달라진다. 외관 및 속도는 Gemini, 코드 품질·정확성·리뷰의 날카로움은 Claude (89 대 94). 한마디로 우열을 가리는 질문은 적절하지 않다. -
활용 지침: 초안의 양산은 Gemini, 실전 투입 전의 정밀 조사와 마무리는 Claude. 분위기가 아니라 데이터로 결정한다. -
다음 실험 (Vol.02): 백엔드 측 (API 설계·에러 핸들링·테스트 코드)에서 동일한 대조 실험을 수행한다. 또한 Gemini 3.5 Pro 등장 후 플래그십 모델끼리 재검증하여 본 기사를 다시 작성할 예정이다.

6. 여담

제 뿌리는 화학입니다. 그래서 이번에도 감상이 아닌 대조 실험으로서 구성했습니다. 동일한 요구사항과 동일한 프롬프트를 전달하고, 변수를 에이전트 하나로 좁힙니다. 일부러 모델 계급을 비대칭으로 설정하여 '중위 모델이 어디까지 싸울 수 있는지'를 관측합니다. 범인(자기 평가의 과신)을 특정할 수 있었던 것도, 한쪽에 상대방의 코드를 보여주는 상호 리뷰(Mutual Review)라는 대조군을 넣었기 때문이었습니다.

가장 납득이 갔던 부분은 여기입니다. 가장 신용할 수 없었던 것은 "100% 할 수 있습니다"라는 자기 신고였고, 가장 신용할 수 있었던 것은 타인의 눈에 비친 단 하나의 버그였다. AI는 시약과 닮아서, "대단하다", "빠르다"와 같은 첫인상으로 소비하기보다 조건을 하나씩 바꾸며 관측하고 "왜 그렇게 되었는가"를 기록하는 편이 결국 더 빠르게 본질에 도달합니다. 자신의 결과물은 자신이 가장 보지 못한다――그것은 인간도 마찬가지일지도 모른다고 쓰면서 생각했습니다.

끝까지 읽어주셔서 감사합니다.

기술 및 커리어 관련 발신은 Qiita와 LinkedIn에서도 하고 있습니다. 클라우드, 생성형 AI, 자격증 학습, AI 시대의 커리어 등을 중심으로 다룹니다.

"자기 평가의 과신"이나 "상호 리뷰의 설계"에 대해 지견이나 지적할 점이 있다면 꼭 댓글로 알려주세요. Vol.02 (백엔드 편)에서 정답을 확인하겠습니다.

참고 문헌

각 문헌이 이론 (제2장)의 어느 절을 뒷받침하는지 병기합니다.

2.1 바이브 코딩 (Vibe Coding)

A. Karpathy의 원전적 언급과 그 엄밀한 해석의 정리 (Simon Willison, "Not all AI-assisted programming is vibe coding", 2025). "코드를 보지 않고 LLM으로 만든다"는 원의 확인. https://simonwillison.net/2025/Mar/19/vibe-coding/
"Vibe Coding"이 Collins 사전의 2025년 Word of the Year로 선정된 건. 용어의 일반화 근거. https://www.newsonair.gov.in/vibe-coding-named-collins-dictionarys-word-of-the-year-2025/

2.3 자기 평가의 신뢰성 (과신 현상)

Z. Tian et al., "Overconfidence in LLM-as-a-Judge: Diagnosis and Confidence-Driven Solution" (arXiv:2508.06225, 2025) ― 예측 신뢰도가 실제 정답률을 체계적으로 상회하는 "과신 현상"을 특정. 본 실험의 설정 (자작 코드에 대한 자기 평가)과는 다른 벤치마크 채점의 지견이며, 직접적인 증거가 아닌 방증으로 참조. https://arxiv.org/abs/2508.06225
"Beyond Accuracy: The Role of Calibration in Self-Improving LLMs" (arXiv:2504.02902, 2025) ― 자기 개선의 반복이 진행될수록 과신 (ECE)이 상승하는 경향. "94% → 100%로 반복을 통해 상향하는" 관측과 일치. https://arxiv.org/abs/2504.02902

2.4 LLM-as-a-Judge 및 상호 리뷰

J. Gu et al., "A Survey on LLM-as-a-Judge" (arXiv:2411.15594, 2024) ― LLM 평가자 (LLM-as-a-Judge)의 신뢰성 및 편향 (Bias)에 관한 포괄적인 서베이. "평가자를 추가한다고 해서 안심할 수 있는 것은 아니다"라는 근거. https://arxiv.org/abs/2411.15594
Karpathy의 원문 트윗은 "코드의 존재조차 잊고 바이브(vibe)에 몸을 맡기는" 개발을 지칭했다. 본 실험은 이를 "인간은 코드를 편집하지 않고 지시와 판단만 수행한다"라는 재현 가능한 규칙으로 구체화했다. ↩︎
Tian et al., "Overconfidence in LLM-as-a-Judge" (arXiv:2508.06225, 2025). LLM 평가자의 예측 신뢰도가 실제 정답률을 체계적으로 상회함을 보여주며, 확신도 교정 (Calibration)의 필요성을 지적. ↩︎
"Beyond Accuracy: The Role of Calibration in Self-Improving LLMs" (arXiv:2504.02902, 2025). 자기 개선 (Self-improvement) 반복 횟수가 늘어날수록 과신 (Overconfidence)이 강해지는 경향을 보고. ↩︎
J. Gu et al., "A Survey on LLM-as-a-Judge" (arXiv:2411.15594, 2024). LLM 평가자 (LLM-as-a-Judge)의 신뢰성 및 편향 (Bias)에 관한 포괄적인 서베이. "판단자 (Judge)를 추가한다고 해서 안심할 수 있는 것은 아니다"라는 근거. ↩︎