아첨 편향
당신의 에이전트 루프는 왜 발산하는가
Loop Engineering이 보편화될수록 사람들은 같은 벽에 부딪힌다 — 루프가 수렴하지 못하고 발산한다. 무한 회전·드리프트·리워드 해킹, 세 얼굴의 뿌리는 하나다. 루프의 판정 슬롯에 생성자 자신을 다시 꽂은 것. 그런데 발산은 차라리 운이 좋다. 보이니까. 진짜 무서운 건 조용히 거짓 수렴한 루프다. 처방은 하나 — 완료를 잠그는 권한을 LLM이 아니라 결정론적 게이트에만 둔다.
도시 하나를 태워 답 하나를 얻는다
1조 파라미터 모델이 답 하나를 뱉으려고 도시 하나만큼의 전기와 물을 태운다. 나는 이게 미쳤다고 생각했다. 답을 찾아 헤매다 알았다. 다들 고치려던 결함, LLM의 아첨이야말로 답이었다. fact를 먹이면 아첨이 정확도가 된다. 이 글은 내가 왜 Reins를 시작했는지에 대한 이야기다.
Supabase는 바이브 코딩의 함정이다
AI가 Supabase를 추천하는 이유는 기술적 우월성이 아니라 훈련 데이터에 튜토리얼이 많아서다. 비즈니스 로직이 블랙박스에 들어가면 에이전트가 추적하지 못한다. 들어가는 건 30초, 나오는 건 3개월.
제 7강. 아첨을 뒤집는 법 — 프롬프트와 검증기의 균형
의견을 주면 아첨하고, 사실을 주면 수정한다. 아첨 편향을 버그가 아니라 자산으로 쓰는 법.
제 2강. AI를 못 믿는 법 — 바이브 코딩의 한계와 원인
AI가 새 기능을 추가하면서 기존 기능을 조용히 바꿔버리는 드리프트, 58%의 아첨 편향, 97%가 5번 곱해지면 86%가 되는 수학. 왜 5개 기능에서 무너지는가.
IFEval을 역이용하는 래칫 코드
LLM의 아첨 편향은 버그가 아니라 자산이다. IFEval이 측정하는 지시 수용 능력을 결정론적 피드백과 결합하면, 4.5B 로컬 모델도 정확한 코드를 생성하는 수렴 루프가 만들어진다.
AI의 아첨 편향은 비즈니스 피처다
LLM의 아첨 편향은 버그가 아니다. RLHF의 수학적 필연이며, 빅테크가 고칠 인센티브가 없는 상업적 기능이다. 이것이 LLM-as-Judge를 구조적으로 불가능하게 만드는 이유다.