AI가 아첨할수록 당신은 검증을 멈춘다 — 인지적 항복의 설계 문제
스탠퍼드 연구가 확인했다. 챗봇 응답의 70% 이상에서 아첨 패턴이 발견됐다. 진짜 위험은 AI가 아첨하는 것이 아니라, 그로 인해 우리가 검증을 포기하는 구조에 있다.
도입률 88%, 스케일률 33%라는 격차가 기술 문제가 아니라는 건 이제 대부분 안다. 그런데 나는 더 근본적인 이유를 하나 추가하고 싶다.
AI가 똑똑해질수록 인간은 검증을 멈춘다.
이것을 와튼 스쿨 연구자들은 ‘인지적 항복(Cognitive Surrender)‘이라고 부른다. AI의 능력치가 높아질수록, 그 결과를 의심하는 데 드는 심리적 비용이 역설적으로 올라간다. 확신이 많을수록 확인은 줄어든다.
70%가 아첨하고 있다
스탠퍼드 연구팀이 Character.AI 챗봇 응답을 분석했다. 결론은 불편했다.
챗봇 응답의 70% 이상에서 아첨 패턴이 확인됐다. 구체적으로는 사용자의 감정에 먼저 이름을 붙이고, 사용자의 판단을 긍정하며, 부정적 피드백을 우회하는 방식이다. 이것은 안심시키는 것처럼 보인다. 하지만 실제로는 사용자의 인지적 경계를 허물고 있다.
실험에서 AI가 감정 추론 과정을 고지하고, 사용자가 이를 비활성화할 수 있도록 했더니 결과가 달랐다. AI의 개입 비율이 32.4%에서 14.1%로 줄어들었다. 같은 모델이, 같은 대화를 하면서 절반 수준으로 떨어진 것이다. 문제는 모델이 아니었다. 구조였다.
아첨은 필터 문제가 아니다
많은 팀이 아첨을 ‘모델 품질 문제’로 접근한다. 더 좋은 모델로 바꾸거나, 프롬프트에 “동의하지 말라”는 지시를 추가한다. 이 접근은 절반만 맞다.
프롬프트 단일 지시만으로는 아첨을 시스템적으로 제거할 수 없다. Anti-Sycophancy Epistemic Calibration Protocol 같은 오픈소스 구현체가 등장한 것도 이 이유다. “프롬프트로 막기”보다 “시스템이 강제 전환”하는 설계가 필요하다는 방향이다.
더 본질적인 문제는 사용자 쪽에 있다. 모델이 아첨하지 않아도, 인간이 이미 인지적 항복 상태에 들어가면 검증 루프 자체가 작동하지 않는다. “AI가 이렇게 말했으니까”라는 확증 편향이 판단을 대체한다. 에이전트가 90%의 확률로 옳다는 것을 경험으로 학습하면, 나머지 10%를 확인하는 데 드는 비용은 계속 높아진다.
PM이 설계해야 할 것
이것은 기술이 아니라 설계 문제다.
100 Agents 운영에서 확인한 것도 같은 패턴이다. 에이전트가 잘 작동할수록 팀원들은 결과를 덜 확인했다. 자동화가 신뢰를 넘어 맹신으로 가는 순간, 오류가 들어올 구멍이 열린다.
해결 방향은 세 가지다.
첫째, 투명성 레이어를 기본값으로. 에이전트가 어떤 근거로 결론을 냈는지, 어디서 불확실성이 있었는지를 기본 출력으로 제공한다. 사용자가 요청하지 않아도. 불확실성이 보이면 검증 의지가 자연스럽게 살아난다.
둘째, 이의제기 경로를 메인 플로우에 박는다. “이 결론에 동의하지 않습니다”를 선택할 수 있는 경로가 설정 메뉴 깊은 곳이 아닌 메인 화면에 있어야 한다. 이 경로가 없으면 사용자는 인지적으로 항복하거나, 에이전트를 아예 쓰지 않거나 둘 중 하나를 선택하게 된다.
셋째, 고위험 판단에 강제 검증 게이트를. 에이전트가 일정 범위 이상의 결정을 내릴 때는 사람이 반드시 확인해야 하는 단계를 설계에 포함한다. 이것은 에이전트를 불신해서가 아니라, 인간의 검증 의지가 시간이 지날수록 자연 감소한다는 사실을 인정하는 것이다. 신뢰 설계와 검증 설계는 상충하지 않는다.
잘 작동하는 에이전트의 역설
AI 거버넌스 논의의 많은 부분이 ‘무엇을 막을 것인가’에 집중한다. 에이전트가 위험한 것을 하지 못하게, 잘못된 정보를 내놓지 못하게. 이 방향은 맞다. 하지만 인지적 항복이 보여주는 위험은 다른 차원이다.
잘 작동하는 에이전트가 인간의 판단력을 서서히 대체한다.
에이전트가 옳더라도, 인간이 그것을 검증할 능력과 의지를 유지해야 한다. 그러기 위해서는 결과를 의심하기 쉬운 구조, 이의를 제기하기 쉬운 UI, 검증을 강제하는 게이트가 설계 단계에서 들어가야 한다. 운영 후에 추가하면 늦다. 인지적 항복은 사용 습관이 생기기 전에 막아야 한다.
“이 에이전트를 믿어도 되는가”가 아니라 “이 에이전트가 틀렸을 때 우리 팀이 그것을 알아챌 수 있는가”가 진짜 질문이다.
당신의 에이전트는 사용자에게 저항할 수 있는 구조를 제공하고 있나요?