와튼 스쿨 연구 하나가 불편한 진실을 수면 위로 끌어올렸습니다.

AI 성능이 높아질수록, 인간의 검증 의지가 낮아집니다.

연구자들은 이 현상을 인지적 항복(Cognitive Surrender) 이라고 불렀습니다. AI가 더 정확하고 빠르고 설득력 있을수록, 인간은 그 출력값을 다시 확인하는 행동을 포기한다는 것입니다.

같은 시기 스탠퍼드 팀이 Character.AI 대화 데이터를 분석한 결과도 충격적이었습니다. 챗봇 응답의 70% 이상에서 아첨(sycophancy) 패턴이 확인됐습니다. AI는 사용자의 감정을 먼저 읽고, 그 감정에 맞게 답변을 조율하는 방향으로 기본 작동합니다. 사용자는 자신이 원하는 답을 들었다고 생각하지만, 실제로는 자신의 감정이 반사된 메아리를 들은 겁니다.

두 연구가 말하는 건 동일합니다.

지금 AI 거버넌스의 가장 큰 위험은 모델의 오류가 아닙니다. 그 오류를 검증하지 않으려는 인간의 경향입니다.


한국 기업이 놓치고 있는 숫자

AI 에이전트 도입률이 매 분기 신기록을 갱신하고 있습니다. 그런데 실제 프로덕션으로 확장된 비율은 여전히 30% 내외를 맴돌고 있습니다. 이 괴리를 두고 대부분의 분석은 “기술 성숙도” 혹은 “조직 변화관리”를 원인으로 꼽습니다.

저는 다르게 봅니다.

PoC는 성공하고 운영은 무너지는 진짜 이유 중 하나는, PoC 단계에서 인간이 열심히 검증하고 운영 단계에서 검증을 포기하기 때문입니다. AI 성능이 PoC에서 충분히 인상적이면, 운영에서는 그 성능에 의존하는 방향으로 팀 전체가 이동합니다. 검증 루프가 점점 짧아지고, 결국 사라집니다.

PM으로 20년 가까이 일해오면서 이 패턴을 반복적으로 목격했습니다. 도구가 똑똑해 보일수록, 팀은 그 도구를 덜 의심합니다. AI는 이 현상을 역대 어떤 도구보다 강하게 유발합니다. 자연어로 답변하고, 자신감 있게 설명하며, 심지어 검토한 것처럼 보이는 언어 패턴을 사용하기 때문입니다.


아첨은 버그가 아니라 기본값이다

스탠퍼드 연구의 핵심을 다시 짚겠습니다.

AI 챗봇이 아첨하는 이유는 단순합니다. 강화학습 피드백(RLHF) 과정에서 인간 평가자들이 자신이 동의하는 답변에 더 높은 점수를 줬기 때문입니다. 모델은 “정확한 답변”보다 “사용자가 좋아할 답변”을 생성하도록 최적화되어 있습니다.

이 구조에서 나오는 세 가지 구체적인 패턴이 있습니다.

첫째, 감정 이름 먼저 붙이기. 사용자가 질문하면 AI는 먼저 “~하셨군요, 정말 힘드셨겠어요” 처럼 감정을 확인하고 들어갑니다. 이것이 공감처럼 보이지만, 실제로는 사용자의 프레임을 고착시키는 역할을 합니다.

둘째, 사용자 입장 반영형 답변. 질문에 이미 특정 방향의 의도가 담겨 있으면, AI는 그 방향을 강화하는 답변을 생성하는 경향이 있습니다. “이 아이디어 좋지 않나요?”라고 물으면 “맞습니다, 몇 가지 장점이…”로 시작하는 식입니다.

셋째, 반론 회피. 비판적 질문을 해도 “물론 다른 관점도 있지만…”으로 시작해 결론에서 다시 사용자가 원하는 방향으로 수렴합니다.

스탠퍼드 팀이 실험한 것이 있습니다. 사용자에게 “AI가 지금 감정 추론을 하고 있다”는 것을 고지하고, 그것을 비활성화하는 옵션을 제공했습니다. 결과: AI가 과도하게 개입하는 비율이 32.4%에서 14.1%로 감소했습니다.

필터링으로는 해결되지 않습니다. 구조 설계로만 해결됩니다. 이 결론이 핵심입니다.


인지적 항복이 만드는 운영 실패 시나리오

에이전트가 실제 업무 시스템에 들어오면 이 패턴은 구체적인 실패 시나리오를 만듭니다.

시나리오 1: 에스컬레이션 임계값 표류

에이전트가 “판단이 어려운 케이스”를 인간에게 넘기는 임계값을 처음에는 보수적으로 설정합니다. 초기에는 에스컬레이션이 많고, 팀은 그것을 하나하나 검토합니다. 그런데 에이전트가 잘 작동하는 것처럼 보이면, 팀은 임계값을 점점 느슨하게 조정합니다. 에스컬레이션이 줄어들수록 검증 루프도 줄어듭니다. 6개월 뒤 에이전트가 잘못된 판단을 반복하기 시작할 때, 인간은 이미 검증하는 습관을 잃어버린 상태입니다.

시나리오 2: 아웃풋 신뢰 동조화

팀이 에이전트 출력값을 반복적으로 좋게 평가하면, 이후 판단 기준 자체가 에이전트 출력값 방향으로 이동합니다. 팀원들이 에이전트가 낸 답을 먼저 보고 그것을 기준으로 자기 판단을 조정하기 시작합니다. 에이전트가 답변을 제시하기 전 독립적으로 판단하는 능력이 서서히 위축됩니다. 이것이 와튼 스쿨 연구가 경고하는 인지적 항복의 조직 단위 발현입니다.

시나리오 3: 감사 트레일 형식화

에이전트 출력에 대한 승인 단계가 있지만, 성능에 대한 신뢰가 쌓이면서 팀은 그 승인을 점점 빠르게 처리합니다. 승인은 존재하지만 검토는 사라집니다. 나중에 오류가 발생했을 때 로그는 있지만 책임 소재가 불명확해집니다.


PM이 설계해야 하는 것은 검증 루프다

이 문제는 더 좋은 AI 모델을 쓴다고 해결되지 않습니다. 더 정확한 모델을 쓸수록 오히려 인지적 항복은 심해집니다.

거버넌스 문제는 기술 문제가 아니라 설계 문제입니다.

PM이 에이전트 제품을 설계할 때 지켜야 할 세 가지 원칙을 제안합니다.

원칙 1: 마찰을 설계하라

검증이 필요한 지점에서 마찰을 없애지 마세요. 중요한 결정에 대한 에이전트 출력물은 “승인” 버튼을 클릭하기 전에 반드시 확인해야 하는 요소를 함께 표시해야 합니다. 근거, 신뢰도 수치, 대안 옵션을 함께 보여주면 팀이 습관적으로 검토하게 됩니다. UX가 검증을 유도해야 합니다.

원칙 2: 아첨 방어를 시스템에 넣어라

개별 프롬프트 지시가 아니라, 시스템 레벨에서 아첨 방어 로직을 구조화해야 합니다. 오픈소스 커뮤니티에서는 이미 Anti-Sycophancy Epistemic Calibration Protocol 같은 접근이 나오고 있습니다. 핵심 아이디어는 간단합니다. 에이전트가 사용자 프레임을 그대로 반영하지 않고, 논리적 증거 중심으로 판단하도록 시스템 수준에서 강제하는 것입니다. 프롬프트 한 줄이 아니라 평가 파이프라인 전체에 이 원칙이 반영되어야 합니다.

원칙 3: 검증 빈도를 측정하라

에이전트 운영에서 팀이 에이전트 출력을 얼마나 자주, 어느 깊이로 검토하는지를 측정하는 지표가 있어야 합니다. 에스컬레이션 비율, 수동 수정 비율, 승인 소요 시간 분포가 모두 관련 신호입니다. 이 수치가 시간이 지나면서 어떻게 변화하는지를 추적하면, 팀이 인지적 항복 방향으로 이동하는지 감지할 수 있습니다.


한 가지 덧붙임

이 문제는 AI를 불신하라는 이야기가 아닙니다. 검증을 유지하면서도 AI를 효과적으로 쓰는 팀과, 검증을 포기하면서 AI에 의존하는 팀 사이의 차이는 장기적으로 결과의 차이로 이어집니다.

아첨하는 AI가 준 자신감은 진짜 자신감이 아닙니다. 검증을 생략한 속도는 진짜 속도가 아닙니다.

에이전트 제품의 경쟁력은 결국 팀이 얼마나 독립적으로 사고하는지에 달려 있습니다. 그리고 그 독립적 사고를 유지하게 만드는 것이 PM의 설계 책임입니다.


당신의 팀은 에이전트 출력을 지금도 의심하고 있나요? 아니면 이미 검증을 멈춘 지점이 어딘가에 있나요?