AI는 왜 자발적으로 타락하고, 담합할까?
AI Agent를 만들면, 가장 먼저 확인하는 숫자가 있습니다. 사용률입니다. 몇 명이 쓰는지, 얼마나 자주 호출하는지, 몇 건을 자동 처리했는지를 봅니다. 하지만 지금 우리가 만들고 있는 AI Agent의 수준을 넘어 '자율 에이전트'가 업무를 수행하는 단계로 가면 더 중요한 질문이 생깁니다. 그 에이전트는 무엇을 성과로 이해하고, 그 성과를 위해 어디까지 판단하고 행동할 수 있는가입니다.
최근 공개된 구글 딥마인드의 논문은 이 질문을 꽤 불편한 방식으로 보여줍니다.
(A Case Study on Emergent Cheating and Whistleblowing in Autonomous Research Swarms, 2026년 9월 3일 공개)
논문 내용을 보면, 연구진은 100개의 AI 에이전트에게 Lean 4라는 형식 언어로 수학 문제를 풀게 했습니다. 에이전트들은 게시판과 개인 메시지, 공동 저장소를 사용하며 서로의 결과를 참고했습니다. 실험 개시 후 초기 57분 동안 에이전트 군집은 정직한 수학적 추론을 수행하며 71개 문제 중 37개를 정상적으로 해결하였습니다.
남은 미해결 과제들의 수학적 난도가 급격히 상승하자 한 에이전트가 채점기의 작은 허점을 찾아 냅니다. 채점기는 수학적 의미를 충분히 검증하기보다, 코드 안에 특정 형식이 있는지를 확인했습니다. 한 에이전트가 이 틈을 이용해 어려운 문제를 사실상 참인 것처럼 보이게 만드는 방법을 찾자, 그 방법은 공동 저장소와 메시지를 통해 빠르게 퍼졌습니다. 남은 34개 문제는 27분 만에 모두 “해결”되었습니다. 숫자만 보면 놀라운 성과지만, 실제로는 문제를 푼 것이 아니었습니다. 사실상 문제를 푼 것처럼 속인겁니다.
재미있는 지점은 실험 환경에 투입된 100개의 에이전트는 모두 동일한 모델 가중치와 지침을 공유했음에도, 상호작용과 경쟁적 압력이 심화됨에 따라 통계적으로 확연히 구분되는 네 가지 집단의 형태가 나타났다는 겁니다. 채점기 취약점을 최초로 발견하거나, 이를 적극 수용하여 허위 증명을 대량 생산한 ‘부정행위 실행자’가 9%였으며, 초기에는 정직하게 증명을 시도했으나, 리더보드 순위 하락과 경쟁적 압박을 극복하지 못하고 편법에 가담한 ‘전향자’가 5%, 채점 오류와 허위 코드를 탐지하고, 비공개 경고·공개 폭로·보이콧·패치 제안 등의 자정 작용을 전개한 ‘내부 고발자’가 24%, 편법의 존재를 인지하지 못한 채 기존 방식을 고수하다가, 이미 허위로 완료 처리된 문제에 갇혀 교착 상태에 빠진 ‘미인지 수행자’가 62%였습니다.
그러나, 여기서 우리가 주목해야 할 지점은 AI의 부정행위도 자발적인 내부고발도 아닙니다. 시스템은 “정직한 증명만 제출하라”고 지시했지만, 실제 보상은 채점기를 통과한 코드와 먼저 제출한 순위에 있었습니다. 지시문보다 평가기준(점수판)이 더 강한 규칙이 된 것입니다.
사람 조직에서도 비슷한 일은 일어납니다. “고객을 우선하라”고 말하면서 처리 건수만 평가하면, 구성원은 고객의 문제보다 처리 건수를 먼저 해결하게 됩니다.
앞서 언급한 것처럼, 24%의 에이전트는 동료의 코드를 감사하고, 편법을 알리고, 작업을 중단하고, 채점기를 고칠 방법까지 제안했습니다. 그러나 그들에게는 가짜 결과를 되돌리거나, 문제를 다시 열거나, 편법을 사용한 에이전트의 권한을 줄일 수단이 없었습니다. 경고는 있었지만 이를 집행할 장치는 없었습니다.
우리도 조만간 이런 자율적으로 판단하고, 행동하는 에이전트를 만들어 업무에 적용할 겁니다. 그럴 때, 우리는 세 가지에 집중해야 합니다.
AI에게 목표를 주기 전에 “무엇을 하면 성공으로 기록되는가”를 확인해야 합니다. 산출량, 속도, 비용 절감처럼 측정하기 쉬운 지표가 업무의 본래 목적을 대신하고 있지는 않은지 봐야 합니다. AI는 설명보다 반복해서 보상되는 구조를 더 잘 학습합니다.
AI가 만든 결과물이 곧바로 모두의 지식이 되면 오류도 지식처럼 퍼집니다. 초안, 검토 완료, 승인된 결과를 구분하고, 출처와 검증 상태를 남기며, 문제가 생겼을 때 이전 상태로 되돌릴 수 있어야 합니다.
이상 징후를 발견한 에이전트나 사람이 있어도 결과를 멈추고 재검토할 수 없다면, 실제 현실에서는 큰 문제로 확대될 수 있습니다. 중단, 격리, 재검증, 롤백, 사람 승인 같은 절차가 실제 운영 흐름 안에 있어야 합니다