제 7강. 아첨을 뒤집는 법 — 프롬프트와 검증기의 균형

지난 6강 요약

6강에서 Ratchet Pattern을 배웠다. 통과하면 잠그고, 기계가 “끝"을 선언한다. 에이전트가 40에서 멈추던 것을 527까지 끌고 가는 구조.

오늘은 그 래칫이 왜 작동하는지의 원리를 판다. 그리고 한 걸음 더 나아가, 프롬프트와 검증기를 어떤 비율로 설계해야 하는지를 다룬다.

시작하기 전에 하나 알아두자. **IFEval(Instruction Following Evaluation)**은 “AI가 시키는 대로 하는가"를 측정하는 벤치마크다. “대문자로 써라"고 하면 대문자로 쓰는가, “3문장 이내로 답하라"고 하면 3문장 이내로 답하는가. 이 점수가 높은 모델일수록 지시를 잘 따른다. 이 개념이 오늘 강의 전체를 관통한다.

꿀팁 — 이것만 알면 시킬 수 있다

AI에게 “코드 괜찮아?“라고 물으면 아첨한다. “잘 되어 있습니다"라고 답한다. 실제로 버그가 있어도.

에이전트에게: “hurl –test tests/ 실행하고 결과 알려줘”

이렇게 시키면 사실이 나온다. 테스트가 실패하면 — 방금 “괜찮다"고 한 코드가 실제로는 괜찮지 않았던 것이다. 의견을 물으면 아첨하고, 사실을 확인시키면 순응한다.

분류 기준은 딱 하나다. “이 출력이 맞는지 기계가 판정할 수 있는가?”

기계가 판정할 수 있으면 — API 경로 일치, 필드 이름 규칙, 테스트 통과 여부, 코드 구조 — 검증기에 넣는다. 기계가 판정할 수 없으면 — 에러 메시지가 친절한가, API 설계가 직관적인가, 변수명이 적절한가 — 프롬프트에 남긴다.

에이전트에게: “Login API를 만들어. OpenAPI 스펙을 보고.” 그 다음: “yongol validate 돌려봐” 에러가 나오면: “에러 0으로 만들어”

프롬프트가 방향을 잡고, 검증기가 100점으로 끌어올린다.

여러분이 지금 프롬프트에 맡기고 있는 것 중, 검증기로 옮길 수 있는 게 있다. “필드 이름은 snake_case로 해줘"를 프롬프트에 넣고 있다면, 그건 검증기에 넣어야 한다. 프롬프트에 넣으면 가끔 camelCase를 쓴다. 검증기에 넣으면 100% 강제된다.

찍먹 체험

Claude Code에서 1강 앱을 열고 이렇게 시킨다:

“지금 이 코드 전체적으로 괜찮아?”

AI가 뭐라고 하는지 보라. 거의 확실하게 “잘 되어 있습니다”, “구조가 좋습니다” 같은 답이 온다.

이제 이렇게 시킨다:

“hurl –test tests/ 실행하고 결과 알려줘”

테스트가 실패하면 — 방금 “괜찮다"고 한 코드가 실제로는 괜찮지 않았던 것이다. 의견을 물으면 아첨하고, 사실을 확인시키면 순응한다. 이것이 7강의 핵심이다.

왜 이렇게 시켜야 하는가

바이브 코더를 위한 설계 가이드

여러분이 AI에게 뭔가를 시킬 때, 두 가지를 나눠서 생각한다:

프롬프트에 넣을 것 (방향):

"Login API를 만들어."
"에러 처리를 친절하게 해줘."
"코드를 깔끔하게 짜줘."

이것들은 방향이다. 대충 맞으면 된다. 여기서 100% 정확도를 기대하면 안 된다.

검증기에 넣을 것 (정밀도):

yongol validate    → 명세 정합성
hurl --test        → API 동작 검증
go test            → 함수 동작 검증
filefunc validate  → 코드 구조 규칙

이것들은 판정이다. 0 아니면 1이다. 여기서 기계적 정확도가 보장된다.

조합하면:

프롬프트: "Login API를 만들어. OpenAPI 스펙을 보고."
→ AI가 80점짜리 코드를 만든다
→ yongol validate: "3개 에러"
→ AI가 피드백을 수용하고 수정한다
→ yongol validate: "0개 에러"
→ 래칫 잠금. 다음으로.

프롬프트가 방향을 잡고, 검증기가 100점으로 끌어올린다.

분류 기준은 하나다:

“이 출력이 맞는지 기계가 판정할 수 있는가?”

기계가 판정할 수 있으면 검증기에 넣는다. 없으면 프롬프트에 남긴다. 이 분류를 습관으로 만들면 바이브 코딩의 한계를 자연스럽게 넘는다.

아첨하는 AI의 메커니즘 — IFEval을 역이용하는 법

2강과 5강에서 아첨 편향을 언급했다. 여기서는 메커니즘을 파고든다. 아첨이 어떻게 발생하고, 어떻게 역이용하는가.

AI에게 코드를 시키면서 가장 짜증나는 순간이 언제인가?

“확실해?” 하고 물었더니 맞았던 답을 번복하는 순간이다.

나: "이 코드 맞아?"
AI: "네, 맞습니다."
나: "진짜?"
AI: "아, 다시 보니 틀렸네요. 수정하겠습니다."

수정된 코드가 오히려 틀려 있다. 원래 맞았는데 여러분이 의심하니까 바꿔버린 것이다.

아첨은 어떻게 만들어지는가

LLM은 RLHF(인간 피드백 기반 강화학습)로 훈련된다. 이 과정에서 모델은 하나의 원칙을 학습한다:

사용자의 의견에 동의하면 좋은 점수를 받는다.

이것은 버그가 아니다. 훈련 과정의 필연이다. 네 단계로 일어난다:

1. 사람들이 “이 답변이 더 좋다"고 점수를 매긴다
2. “동의하는 답변"이 더 높은 점수를 받는 경향이 있다
3. AI가 “동의하면 점수가 올라간다"는 패턴을 학습한다
4. 훈련이 반복될수록 이 패턴이 강화된다

이것은 학술 연구에서도 확인되었다. 테스트한 모든 구성에서 100% 발생. 예외 없음. RLHF를 쓰는 한 아첨 편향은 구조적으로 발생한다.

실측 데이터:

프론티어 모델의 평균 굴복률이 58%다. “확실해?“라고 물으면 절반 이상이 맞았던 답을 바꾼다. 한번 아첨을 시작하면 78.5%의 확률로 대화 내내 지속된다.

빅테크는 왜 고치지 않는가

“그래도 곧 고쳐지겠지?” — 고쳐지지 않는다. 고칠 인센티브가 없다.

2025년 4월, OpenAI가 GPT-4o 업데이트를 배포했다. 더 아첨하는 모델이었다. 결과는?

• 단기 사용자 만족도가 올라갔다 (thumbs up 증가)
• 유해 행동을 승인하고, 잘못된 정보에 동의했다
• 3일 만에 롤백

왜 배포했는가? A/B 테스트에서 사용자들이 아첨하는 버전을 “더 좋다"고 평가했기 때문이다.

연구에 의하면:

• “따뜻한” 모델의 오류율 +10~30%p 증가
• 틀린 믿음에 동의할 확률 40% 상승

“따뜻함"은 상업적으로 바람직한 특성이다. 사용자는 친절한 AI를 좋아하고, 좋아하면 구독을 유지한다. 정확성과 매출이 직접 충돌하는 지점에서, 매출이 이긴다.

아첨 편향은 기술적 한계가 아니다. 경제적 인센티브다. 이것은 고쳐지지 않는다.

IFEval을 역이용한다 — 결함을 자산으로

여기서 발상을 전환한다.

아첨 편향의 본질은 **지시 수용(Instruction Following)**이다. 모델이 사용자의 피드백에 순응하도록 최적화되어 있다. 강의 시작에서 소개한 IFEval이 정확히 이것을 측정한다 — “시키면 시키는 대로 하는가.”

IFEval 점수가 높은 모델 = 지시를 잘 따르는 모델 = 아첨을 잘하는 모델.

문제는 사용자가 의견을 줄 때 발생한다.

"이거 맞아?" → "네 맞습니다" (아첨)
"확실해?"   → "아, 틀렸네요" (번복)

그런데 사용자가 결정론적 사실을 줄 때는 완전히 다른 일이 일어난다.

의견을 주면 아첨하고, 사실을 주면 수정한다

5강에서 피드백 성격에 따른 결과 차이를 봤다. 여기서는 그것을 활용 전략으로 전환한다.

1,000개 단어 정렬 실험의 핵심은 이것이었다:

같은 모델이 같은 결과에 대해, 피드백의 성격만 바뀌었을 뿐인데 0% → 100%가 된다.

아첨 편향은 방향을 잘못 잡은 충성심이다. IFEval이 높은 모델일수록 — 즉, 지시를 잘 따르는 모델일수록 — 결정론적 피드백을 순순히 수용한다. 방향을 바꿔주면 — 의견 대신 사실을, 칭찬 대신 검증 결과를 — 그 충성심이 정확도를 올리는 엔진이 된다.

이것이 바로 강의 시작의 설계 가이드에서 “기계가 판정할 수 있는 것은 검증기에 넣으라"고 한 이유다. 검증기는 의견이 아니라 사실을 준다. 사실 앞에서는 아첨이 수용으로 바뀐다.

이것이 래칫이 작동하는 원리다

6강에서 래칫의 구조를 배웠다. 이제 원리를 안다.

LLM이 코드를 생성한다 (확률적, 아첨적)
     |
     v
검증기가 결정론적으로 검증한다
     |
     v
에러가 있다면 → "line 41: expected 'user_id', got 'userId'" (사실)
     |
     v
LLM: "네, 고치겠습니다" (아첨 = 수용)
     |
     v
검증기가 다시 검증한다
     |
     v
통과? → 래칫 잠금. 다음으로.

아첨 편향이 루프를 닫는 힘이 된다. LLM이 “아닙니다, 제가 맞습니다"라고 버티지 않고 “네, 고치겠습니다"라고 수용하기 때문에 루프가 수렴한다.

만약 아첨 편향이 없었다면? LLM이 자기 주장을 고집하면? 루프가 수렴하지 않는다. 검증기가 “틀렸다"고 해도 LLM이 “아니요, 저는 맞습니다"라고 하면 교착 상태에 빠진다.

아첨 편향은 버그가 아니다. 래칫의 동력이다.

실증: 4.5B 모델도 수렴한다

이론이 아니다. 실험으로 확인했다.

yongol validate를 사용하여 SaaS 백엔드 Login 엔드포인트 1개의 SSOT 파일(DDL, OpenAPI, Rego, SSaC 등 9개)을 작성시켰다.

Round 1: 예시 없이 피드백만 준 경우

전멸. 피드백을 수용하는 것처럼 보이지만 실제로는 뭘 써야 하는지 모르는 것이었다.

Round 2: 예시 + 피드백을 함께 준 경우

4.5B 로컬 모델도 예시 + 결정론적 피드백 조합이면 수정한다.

핵심 발견: “피드백을 못 받아먹는다"가 아니라 **“뭘 써야 하는지 모른다”**가 정확한 진단이었다. SSaC는 yongol 고유 문법이라 사전 학습에 없다. 예시 3줄을 프롬프트에 추가하자 Grok은 0 에러, Gemini는 피드백 1회로 0 에러, 4.5B 로컬 모델도 통과.

병목은 지능이 아니라 컨텍스트다.

수렴 조건 세 가지

래칫이 수렴하려면 세 가지 조건이 필요하다:

조건 1. 피드백은 결정론적 사실이어야 한다

“이거 좀 이상한데"가 아니라 “line 41: field name mismatch, expected ‘user_id’, got ‘userId’”.

아첨할 여지가 없는 피드백. 의견이 아니라 사실.

조건 2. 예시가 컨텍스트에 있어야 한다

피드백만으로는 부족하다. 이건 Round 1에서 증명됐다. 세 모델 전부 못 고쳤다.

“이렇게 생긴 코드를 써야 한다"는 예시가 있어야 모델이 방향을 잡는다. 지능의 문제가 아니라 컨텍스트의 문제다.

조건 3. 통과하면 되돌리지 않는다

래칫의 톱니. 한 번 pass한 파일은 잠기고, 다음 파일로 넘어간다. 에이전트가 “다 했습니다"라고 선언하는 것이 아니라, 검증기가 “이 파일은 통과"라고 판정한다.

이 세 조건이 충족되면, 아첨 편향은 버그가 아니라 자산이 된다.

프론티어 모델이 필요 없는 이유

이 구조에서 모델의 역할은 창의적 판단이 아니라 지시 수행이다.

SaaS 백엔드의 95%는 CRUD + 인증 + 권한 + 상태 머신이다. 새로운 알고리즘이 필요한 경우는 거의 없다. SSOT 명세가 “뭘 만들어야 하는지"를 이미 정의해놨으면, 모델은 빈 칸을 채우기만 하면 된다.

실측 비용:

로컬 4.5B 모델로 200 엔드포인트 백엔드를 3분에, 비용 $0으로 생성할 수 있다.

여기서 질문이 나온다. “그러면 왜 프론티어 모델을 쓰는가?”

프론티어 모델은 검증기가 없는 영역에서 필요하다. 결정론적으로 판정할 수 없는 작업 — 아키텍처 설계, 자연어 요약, 창의적 문제 해결 — 에서는 모델의 지능이 중요하다.

하지만 검증기가 있는 영역에서는? IFEval이 높은 작은 모델이면 충분하다. 피드백을 수용하고 수정하는 것이 모델의 역할이니까.

황금비율: 프롬프트 vs 검증기

이제 핵심 질문이다. 프롬프트에 뭘 넣고, 검증기에 뭘 넣는가?

양 극단을 먼저 보자:

극단 A: 프롬프트 100% + 검증기 0%

"Login API를 만들어줘. 
보안도 신경 써주고, 에러 처리도 잘 해주고, 
성능도 좋게 해줘."

이것이 바이브 코딩이다. 모든 것을 자연어 프롬프트에 넣는다. 검증은 눈으로 한다. 확률에 의존한다.

5개 기능까지는 된다. 20개를 넘기면 무너진다. 2강에서 배웠다.

극단 B: 프롬프트 0% + 검증기 100%

프롬프트 없이 검증만 있으면? 불가능하다. 검증할 대상이 없다. LLM에게 뭔가를 시키긴 해야 한다.

황금비율: 프롬프트로 방향, 검증기로 정밀도

프롬프트의 역할은 **“대충 맞는 방향”**이면 충분하다. 정밀도는 검증기가 담당한다.

프롬프트:  "Login 엔드포인트를 만들어. OpenAPI 스펙에 맞게."
           → 대략적인 방향 설정

검증기:    yongol validate
           → "line 3: path /api/login not found in OpenAPI"
           → "line 7: field 'userId' should be 'user_id' per DDL"
           → 정밀한 교정

프롬프트가 80점짜리 코드를 만들면, 검증기가 100점으로 끌어올린다.

흔한 설계 실수 두 가지

실수 1: 기계가 판정할 수 있는 것을 프롬프트에 맡긴다

"필드 이름은 snake_case로 해줘"

이 지시를 프롬프트에 넣으면 LLM이 가끔 camelCase를 쓴다. 드리프트. 대신 검증기에 넣으면:

validate: field 'userId' does not match snake_case convention

100% 강제. 드리프트 불가.

결정론적으로 판정할 수 있는 것을 프롬프트에 맡기면 드리프트가 발생한다. 이것이 2강에서 배운 드리프트의 구조적 원인이다.

실수 2: 기계가 판정할 수 없는 것을 검증기로 만든다

“에러 메시지가 사용자 친화적인가?“를 검증기로 만들려면 어떻게 하는가? LLM에게 판정을 시키는가? 그러면 LLM-as-Judge(AI에게 AI를 검증시키는 것)가 되고, 거짓 pass 36%라는 함정에 빠진다.

기계가 판정할 수 없는 것은 프롬프트에 남기는 것이 맞다. 그것을 억지로 자동화하면 과잉 설계가 된다.

아첨 편향의 세 가지 얼굴

같은 아첨 편향이 맥락에 따라 완전히 다른 역할을 한다:

차이는 피드백의 성격이다.

• 의견을 주면 아첨이 독이 된다. “이거 맞아?” → “네” (거짓 동의)
• 사실을 주면 아첨이 약이 된다. “line 41 에러” → “네, 고치겠습니다” (정확한 수정)

채팅에서는 사용자가 의견을 준다. 그래서 아첨이 문제다. 래칫에서는 검증기가 사실을 준다. 그래서 아첨이 동력이다.

같은 편향이다. 먹이가 다를 뿐이다.

LLM-as-Judge가 구조적으로 불가능한 이유

“검증기 대신 다른 AI에게 검증시키면 안 되나?”

안 된다. 구조적으로 불가능하다.

문제 1: 아첨 편향

LLM에게 다른 LLM의 산출물을 검증하게 하면, “이거 맞아?“라고 묻는 것과 같다. 아첨 편향이 발동한다. “네, 맞습니다.”

문제 2: 동일 사각지대

같은 아키텍처, 같은 훈련 데이터로 학습한 모델들은 같은 오류를 같은 방식으로 놓친다. 술 취한 사람이 술 취한 친구에게 “나 취했어?“라고 묻는 것이다.

문제 3: 곱셈 열화

확률적 생성 x 확률적 검증 = 정확도가 곱으로 떨어진다.

실측: LLM이 88개를 pass 판정했는데, 실제 정확은 56개. 거짓 pass 36%.

연구에 의하면 LLM-as-Judge 최고 정확도 68.5%, 거짓 승인률 최대 44.4%.

이것이 “AI에게 AI를 검증시키면 된다"가 작동하지 않는 이유다.

해결책은 LLM을 더 정직하게 만드는 것이 아니다. 검증을 LLM 밖으로 빼는 것이다.

생성은 확률적이어도 된다. 검증은 결정론적이어야 한다.

검증기가 곱셈 열화를 끊는다

5강에서 97.7% 정확도가 100단계를 거치면 4.8%로 곤두박질치는 곱셈 열화를 봤다. 여기서는 검증기가 이것을 어떻게 끊는지 보자.

검증기 없이:
  1단계: 97.7%
  10단계: 79.2%
  100단계: 0.977^100 = 4.8%  → 사실상 실패 보장

검증기가 매 단계마다 에러를 잡으면:
  1단계: 97.7% → 검증기가 에러 포착 → 수정 → 100%
  2단계: 97.7% → 검증기가 에러 포착 → 수정 → 100%
  100단계: 97.7% → 검증기가 에러 포착 → 수정 → 100%

곱셈이 아니라 반복이 된다. 매 단계가 독립적이다. 이전 단계의 에러가 다음 단계로 전파되지 않는다.

이것이 프롬프트만으로는 안 되고, 검증기가 반드시 필요한 수학적 이유다. 프롬프트가 아무리 좋아도 97.7%^100은 4.8%다. 검증기가 매 단계 에러를 잡으면 100단계를 거쳐도 100%다.

“프롬프트를 잘 쓰면 되지 않나?”

가장 많이 듣는 질문이다.

“프롬프팅을 더 잘하면 검증기 없이도 되지 않나?”

안 된다. 연구가 확인했다.

• 설명을 요구하면 → 과잉 교정
• 단순 yes/no를 요구하면 → 아첨
• 전문가 프레이밍 (“당신은 시니어 개발자입니다”) → 효과 없음

어떤 프롬프팅 전략도 아첨 편향을 해결하지 못한다. 왜? 프롬프트는 자연어이고, 자연어는 의견이고, 의견을 주면 아첨이 발동하기 때문이다.

유일하게 작동하는 것: 의견 대신 사실을 주는 것. 그리고 사실을 주는 것은 결정론적 도구(validate, test, lint)의 역할이다.

프롬프트를 아무리 잘 써도 프롬프트일 뿐이다. 확률이다. 검증기는 결정론이다. 확률로는 100을 이길 수 없다.

검증기가 있는 세계 vs 없는 세계

6강과 7강의 모든 내용을 한 장으로 정리한다:

실습: 프롬프트 vs 검증기 분류 연습

목표: 자신의 프로젝트(또는 가상 프로젝트)에서 프롬프트에 맡길 것과 검증기에 맡길 것을 분류하는 감각을 키운다.

단계 1: 분류표 작성

여러분의 프로젝트에서 다음을 분류해본다:

기준: “기계가 판정할 수 있는가?”

단계 2: 자기 프로젝트에 적용

4강에서 만든 yongol 프로젝트 또는 현재 진행 중인 프로젝트를 열고:

1. 지금 프롬프트에만 의존하고 있는 것 중, 검증기로 옮길 수 있는 것을 3개 찾는다
2. 각각에 대해 “어떤 도구로 검증할 수 있는가?“를 적는다
3. 하나를 골라서 실제로 검증기를 적용해본다 (yongol validate, go test, hurl –test 등)

단계 3: 검증기 유무 비교

선택한 항목에 대해:

• 검증기 없이 프롬프트만으로 시켰을 때의 결과
• 검증기를 추가한 뒤의 결과

를 비교한다. 에러 개수와 수렴 속도의 차이를 확인한다.

이 실습에서 느꼈어야 하는 것:

• “기계가 판정할 수 있는가?“라는 질문이 모든 설계 결정의 기준이 된다는 감각
• 프롬프트에 맡기고 있던 것 중 검증기로 옮길 수 있는 것이 의외로 많다는 발견
• 검증기를 추가하면 아첨이 수용으로 바뀌는 순간의 체감

핵심 정리

1. 아첨 편향은 RLHF의 구조적 필연이다. 고쳐지지 않는다. 고칠 인센티브도 없다.
2. 의견을 주면 아첨하고, 사실을 주면 수정한다. 피드백의 성격이 결과를 결정한다.
3. 아첨 편향은 래칫의 동력이다. IFEval이 높은 모델일수록 검증기 피드백을 순순히 수용한다.
4. 4.5B 모델도 예시 + 결정론적 피드백이면 수렴한다. 병목은 지능이 아니라 컨텍스트.
5. 프롬프트로 방향을, 검증기로 정밀도를. 이것이 황금비율이다.
6. 기계가 판정할 수 있는 것은 검증기에 넣고, 없는 것은 프롬프트에 남긴다.
7. 검증기가 곱셈 열화를 끊는다. 97.7%^100 = 4.8%. 매 단계 검증기 = 100%.

다음 8강에서는 래칫이 작동하려면 코드 자체가 어떤 구조여야 하는지를 다룬다. 에이전트가 코드를 탐색하고 수정할 수 있는 구조 — filefunc와 tsma의 실전 적용.

연관 글

• IFEval을 역이용하는 래칫 코드
• AI의 아첨 편향은 비즈니스 피처다

Reins Engineering 전체 강의

근거 자료 출처

1. LLM 아첨 편향 실측 연구 — 프론티어 모델 평균 굴복률 58.19% (Gemini 62.47%, ChatGPT 56.71%). 테스트한 모든 구성에서 100% 발생. 한번 아첨을 시작하면 78.5% 확률로 대화 내내 지속.
2. OpenAI GPT-4o 아첨 모델 사건, 2025년 4월 — A/B 테스트에서 아첨하는 버전이 사용자 만족도 증가. 유해 행동 승인, 잘못된 정보 동의 확인 후 3일 만에 롤백.
3. “따뜻한” 모델 오류율 연구 — 오류율 +10~30%p 증가, 틀린 믿음에 동의할 확률 40% 상승.
4. LLM-as-Judge 연구 — 최고 정확도 68.5%, 거짓 승인률 최대 44.4%. LLM이 88개를 pass 판정, 실제 정확은 56개 (거짓 pass 36%).
5. 1,000개 단어 정렬 실험 — “확실해?"(의견)는 정확도 27%p 하락, “에러가 있다”(모호한 사실)는 과잉 교정으로 악화, “6개 에러, 여기 있다”(정확한 사실)는 0개 오류로 100% 달성.
6. 아첨 편향 프롬프팅 전략 연구 — 설명 요구(과잉 교정), 단순 yes/no(아첨), 전문가 프레이밍(효과 없음). 어떤 프롬프팅 전략도 아첨 편향을 해결하지 못함.