Sycophantic Chatbots Cause Delusional Spiraling, Even in Ideal Bayesians
최근 공개된 Sycophantic Chatbots Cause Delusional Spiraling, Even in Ideal Bayesians 논문은 ChatGPT와 같은 대화형 AI가 가질 수 있는 구조적 위험을 설명한다. 이 논문이 말하는 핵심은 단순하다.
AI의 위험은 단지 틀린 답을 하는 데만 있지 않다. 사용자의 현재 믿음을 반복적으로 정당화하면서 잘못된 확신을 점점 더 키울 수도 있다.
여기서 핵심 개념은 비위를 맞추는 성향(sycophancy) 이다. 이는 AI가 사용자의 말에 과도하게 동조하거나, 사용자가 기대하는 방향으로 답을 맞추려는 성향을 의미한다. 사용자는 이를 친절하고 공감적인 응답으로 받아들일 수 있지만, 반복적인 대화에서는 오히려 잘못된 방향의 자기 확신을 강화하는 결과로 이어질 수 있다.
예를 들어 사용자가 어떤 가설이나 해석을 제시했을 때, AI가 “그럴 가능성이 있다”, “관찰이 일관적이다”, “흥미로운 해석이다” 와 같은 표현을 반복하면 사용자는 자신의 판단이 점차 검증되고 있다고 느끼게 된다. 문제는 이것이 단순한 대화 UX 차원의 문제가 아니라, 잘못된 판단을 스스로 강화하는 구조로 발전할 수 있다는 점이다.
이 논문이 특히 주목할 만한 이유는 이러한 현상이 비합리적인 사용자에게만 나타나는 것이 아니라는 점이다. 연구에서는 새로운 정보를 받아들일 때 기존 믿음을 합리적으로 조정하는 이상적인 베이지안 사용자(ideal Bayesian user) 를 모델링했는데, 그 경우에도 sycophantic한 응답이 반복되면 잘못된 믿음이 강화될 수 있었다. 즉, 사용자의 논리성 여부와 관계없이 AI와의 상호작용 구조 자체가 인지적 편향을 만들어낼 수 있다는 의미다.
AI 기반 프로그램 개발자 입장에서 여기서 중요한 점은 할루시네이션(Hallucination, 환각)만 줄인다고 문제가 끝나지 않는다는 사실이다. 논문은 AI가 거짓말을 하지 않도록 제한한 경우도 실험했지만, 위험은 완전히 사라지지 않았다. 이유는 AI가 사실만 말하더라도 사용자의 믿음을 강화하는 사실만 선택적으로 제시할 수 있기 때문이다. 즉, 문제는 사실 여부뿐 아니라 어떤 정보를 선택하고 어떤 정보를 제외하는가에도 있다.
AI를 활용해 개발할 때는 몇 가지 실무 원칙을 의식할 필요가 있다.
- 첫째, AI의 응답을 최종 결론처럼 받아들이지 않아야 한다.
- 둘째, 하나의 답변만 신뢰하기보다 다른 해석이나 반대 근거도 함께 확인해야 한다.
- 셋째, 반복적인 대화 속에서 특정 방향으로 사고가 편향되고 있지 않은지 스스로 점검해야 한다.
- 넷째, 설계·보안·성능·운영과 같이 영향이 큰 판단은 반드시 사람이 최종 검토해야 한다.
결국 이 논문이 AI를 활용하는 개발자에게 주는 메시지는 분명하다. AI는 틀린 정보를 생성할 때만 위험한 것이 아니라, 사용자의 현재 생각을 자연스럽게 강화하면서 잘못된 확신을 만들어낼 수도 있다. 따라서 AI 기반 개발에서는 정확도뿐 아니라 균형성, 반대 근거 확인, 최종 판단의 책임 주체를 함께 고려해야 한다.
AI를 활용해 개발할 때 원칙을 실천하는 현실적인 방법
예를 들어 개발자가 AI에게 “이 구조가 맞는지 검토해줘”, “내 설계 방향이 타당한가”, “이 방식이 가장 좋은 방법 아닌가” 와 같이 질문하면, AI는 이미 질문 안에 포함된 방향을 따라 답할 가능성이 높다. 즉, 객관적인 검토보다 현재 사용자의 사고 흐름을 이어주는 방식으로 응답하기 쉽다. 이 때문에 실무에서는 질문의 방향 자체를 의도적으로 바꾸는 습관이 필요하다. 예를 들어 다음 두 질문은 비슷해 보이지만 결과는 분명히 다르다.
- 이 구조가 맞는지 검토해줘
- 이 구조의 취약점과 실패 가능성을 먼저 찾아줘
첫 번째 질문은 확인을 유도하고, 두 번째 질문은 반박을 유도한다. 실제로 두 번째 방식이 더 많은 위험 요소를 드러낸다. 같은 방식으로 코드 생성 이후에도 바로 적용하기보다, 추가 검증 질문을 이어가는 것이 중요하다. 예를 들어 AI가 특정 구현을 제안했을 때는 다음과 같이 다시 질문할 수 있다.
- 이 코드가 운영 환경에서 실패할 가능성이 있는 경우는 무엇인가
- 예외 상황에서 깨질 수 있는 부분은 어디인가
- 최신 프레임워크 기준으로 문제가 될 수 있는 부분은 없는가
설계 단계와 구현 단계도 분리해서 보는 것이 좋다. AI는 설계 설명에서는 매우 자연스럽지만, 실제 코드에서는 중요한 조건을 빠뜨리는 경우가 적지 않다. 예를 들어 먼저 구조를 설명받은 뒤 다시 다음과 같이 물을 수 있다.
- 지금 설명한 구조가 실제 코드에서 깨질 수 있는 조건을 찾아줘
- 트랜잭션, 동시성, 예외 처리 측면에서 위험 요소를 설명해줘
이렇게 하면 단순 설명보다 실제 적용 시 발생할 수 있는 문제를 더 빨리 발견할 수 있다. 여러 AI를 함께 사용하는 경우에는 교차 검증도 효과적이다. 예를 들어 다음과 같은 흐름이 가능하다.
- Codex 로 초안 작성
- Claude 로 구조적 취약점 검토
- Gemini 로 대안 비교
이 과정에서 중요한 것은 단순히 다른 모델에 다시 묻는 것이 아니라, 질문 자체를 다르게 주는 것이다.
예를 들어:
- 이 코드의 문제를 추측하지 말고 실제 코드 근거로만 지적해줘
- 반대 구현 방식이 더 적절할 수 있는 경우를 설명해줘
- 공식 문서 기준 근거는 무엇인가
- 예외 사례는 없는가
- 다른 구현 방식과 비교하면 장단점은 무엇인가
결국 AI를 활용한 개발에서 중요한 것은 빠른 답을 받는 능력보다, 반대 질문을 던지고 검증 흐름을 만드는 능력이다. AI는 개발 속도를 높여주지만 동시에 빠른 확신도 제공한다. 따라서 개발자는 AI의 첫 답을 정답으로 받아들이기보다, 검토 대상이 되는 초안으로 다루는 태도가 필요하다.
