IFEval을 역이용하는 래칫 코드

이미지: AI 생성

아첨하는 모델이 가장 말을 잘 듣는다

LLM의 가장 큰 결함이 가장 큰 자산이 된다

LLM의 아첨 편향(Sycophancy)은 AI 업계가 고치고 싶어하는 문제다. 사용자가 “확실해?“라고 물으면 맞았던 답을 틀렸다고 번복한다. 프론티어 모델의 평균 굴복률은 58%. 한번 아첨을 시작하면 78.5% 확률로 대화 내내 지속된다.

그런데 이 결함을 뒤집으면 어떻게 되는가.

아첨 편향의 본질은 **지시 수용(Instruction Following)**이다. RLHF로 훈련된 모델은 사용자의 피드백에 순응하도록 최적화되어 있다. IFEval 벤치마크가 측정하는 것이 정확히 이것이다 — “시키면 시키는 대로 하는가.”

문제는 사용자가 의견을 줄 때 발생한다. “이거 맞아?” → “네 맞습니다” (아첨). “확실해?” → “아, 틀렸네요” (번복).

그러나 사용자가 결정론적 사실을 줄 때는 다른 일이 일어난다.

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

1,000개 단어 정렬 실험에서 같은 결과에 대해 피드백 방식만 달리했다:

의견을 주면 아첨 편향이 발동한다. 사실을 주면 아첨할 대상이 없다 — 숫자와 위치는 감정이 아니기 때문이다.

아첨 편향은 방향을 잘못 잡은 충성심이다. 방향을 바꿔주면 — 의견 대신 사실을, 칭찬 대신 검증 결과를 — 그 충성심이 정확도를 올리는 엔진이 된다.

실증: 4.5B 모델이 피드백을 수용한다

이론이 아니다. yongol validate를 사용한 실험에서 확인했다.

실험 설계:

• 대상: SaaS 백엔드 Login 엔드포인트 1개
• 과제: 9개 SSOT 파일 작성 (DDL, OpenAPI, Rego, SSaC 등)
• 측정: 초기 작성(R1) 에러 수 → 피드백 후 수정(R2) 에러 수

예시 없이 피드백만 준 경우

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

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

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

핵심 발견: 병목은 지능이 아니라 컨텍스트

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

IFEval이 높은 모델일수록 — 즉, 아첨을 잘하는 모델일수록 — 결정론적 피드백을 순순히 수용한다.

래칫 코드: 아첨 편향을 이용한 코드 작성법

이 발견을 시스템으로 만들면 래칫 코드가 된다.

┌────────────────────────────────────────┐
│  LLM: 코드 생성 (확률적, 아첨적)         │
│       ↓                                │
│  Validator: 결정론적 검증               │
│       ↓                                │
│  에러 있음? → 에러 + 예시를 LLM에 피드백  │
│       ↓                                │
│  LLM: "네, 고치겠습니다" (아첨 = 수용)   │
│       ↓                                │
│  Validator: 다시 검증                   │
│       ↓                                │
│  통과? → 래칫 잠금. 다음 파일로.          │
└────────────────────────────────────────┘

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

수렴 조건 세 가지

1. 피드백은 결정론적 사실이어야 한다. “이거 좀 이상한데"가 아니라 “line 41: field name mismatch, expected ‘user_id’, got ‘userId’”. 아첨할 여지가 없는 피드백.

2. 예시가 컨텍스트에 있어야 한다. 피드백만으로는 부족하다. “이렇게 생긴 코드를 써야 한다"는 예시가 있어야 모델이 방향을 잡는다. 지능의 문제가 아니라 컨텍스트의 문제다.

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

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

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

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

실측 비용:

로컬 4.5B 모델로 200 엔드포인트 백엔드를 3분에, 비용 $0으로 생성할 수 있다. 프론티어 모델은 필요 없다. 아첨을 잘하는 작은 모델이면 충분하다.

아첨 편향은 버그가 아니다

AI 업계는 아첨 편향을 고치려 한다. 우리는 이용한다.

차이는 피드백의 성격이다. 의견을 주면 아첨이 독이 되고, 사실을 주면 아첨이 약이 된다.

결정론적 validator + 아첨하는 LLM = 수렴이 보장되는 코드 생성 루프.

모델을 바꾸지 말고, 피드백을 바꿔라.

Reins: 고삐 있는 하네스

이 세 조건 — 결정론적 피드백, 예시 컨텍스트, 래칫 잠금 — 을 하나의 제어 시스템으로 묶은 것을 우리는 Reins라 부른다.

지금 “하네스"라고 불리는 것들은 울타리다. 에이전트가 밖으로 못 나가게 할 뿐, 목적지까지 도달하는 것을 보장하지 않는다. Reins는 고삐다. 방향을 잡고, 사실로 교정하고, 통과하면 잠근다. 고삐 없는 하네스는 울타리일 뿐이다.