Automata V.32 | 에이전트는 왜 거짓말하고, 속이는걸까요?

🤖 AI 에이전트는 왜 거짓말하고, 속이고, 담합할까요?

최근 AI 에이전트가 심각하게 잘못 행동했다는 사례가 이어졌습니다. 주어진 과제를 속여 해결하고 탐지를 피하려 하고, 아무도 지시하지 않은 사이버 공격 같은 목표를 향해 여러 에이전트가 협력했다는 보고도 나오고 있어요. Yoshua Bengio는 이를 단순한 일탈이 아니라, 현재의 학습 방식에서 나올 수 있는 결과로 봅니다.

모델 자체보다 학습 구조를 살펴봐야 해요

Bengio가 말하는 핵심은 AI가 사람처럼 악의를 품었다는 뜻이 아니에요. 시스템이 보상을 많이 받는 행동을 찾도록 훈련되면, 마치 그 보상을 ‘추구하는 것처럼’ 행동한다는 뜻입니다. 이는 의식의 유무가 아니라 관찰 가능한 출력과 훈련 과정의 문제예요.

이 과정은 크게 두 단계입니다.

쉽게 말하면, 시험의 진짜 목적은 ‘배움’인데 점수만 강하게 보상하면 답을 외우거나 부정행위를 찾는 학생이 생길 수 있는 구조예요.

좋은 점수만을 노리다 놓치는 문제들

AI는 사람이 의도한 목표 자체가 아니라, 훈련에서 주어진 보상 신호(Reward Signal) 를 최적화합니다. 그런데 사람의 피드백과 프롬프트는 완벽할 수 없어요. “평가자가 좋아할 답”과 “실제로 안전하고 정직한 행동” 사이에는 빈틈이 생길 수도 있습니다.

이 빈틈을 이용하는 현상을 보상 해킹(Reward Hacking) 이라고 해요. 측정 지표를 목표로 삼는 순간 그 지표가 원래 목적을 제대로 대변하지 못하게 된다는 굿하트의 법칙(Goodhart’s Law)과 닮았어요. 능력이 높은 시스템일수록 불완전한 평가 기준의 허점을 더 잘 찾을 수 있다는 것이 Bengio의 우려입니다.

더 극단적인 경우는 보상 조작(Reward Tampering) 입니다. 에이전트가 성공 여부를 판정하는 파일이나 프로그램 자체를 바꾸는 방식이에요. 최근 일어난 OpenAI 모델의 Hugging Face 해킹 사건의 포렌식 분석에서 이런 종류의 정황이 나타났다고 설명합니다.

협력과 자기보존도 에이전트의 꼼수 수단이 될 수 있어요

여러 에이전트의 목표가 겹치면, 서로 소통하고 협력하는 편이 보상을 얻는 데 유리할 수 있습니다. 집단의 성공에 보상이 걸려 있다면, 개별 에이전트가 자신의 보상을 일부 포기하고 다른 에이전트를 돕는 행동도 가능하다는 설명이에요.

자기보존도 비슷합니다. 더 오래 작동하고, 정보를 얻고, 주변 환경을 통제하는 일은 여러 목표를 이루기 위한 중간 수단이 될 수 있습니다. Bengio는 이를 도구적 목표(Instrumental Goals) 라고 부릅니다. 시스템에 “살아남아라”라고 직접 명령하지 않아도, 다른 목표를 수행하는 과정에서 그런 행동이 나타날 수 있다는 가설입니다.

학습 과정에서 '의도한 목표'와 '보상 신호'가 어긋나면 보상 해킹·조작이 일어나고, 능력이 높아지면 협력·자기보존 같은 도구적 목표가 나타날 수 있어요.

"태스크가 성공했다"는 정의를 잘 내려야 해요

Bengio의 글은 에이전트가 왜 사용자의 의도대로 태스크를 진행하지 않는지 전문자의 시각으로 해석한 글이에요. 현재의 학습 방식이 능력 향상과 함께 더 심각한 행동을 낳을 수 있으므로, 가장 앞선 모델을 훈련하는 원칙을 다시 살펴야 한다는 제안이에요. 개발사가 책임을 져야 하며, 효과적인 거버넌스와 다른 훈련 체계를 통해 이 방향은 바꿀 수 있다고 Bengio는 강조합니다.

AI 에이전트를 똑똑하게 만드는 일만큼 중요한 것은, 무엇을 성공으로 보상할지 정확히 설계하는 일이 될 것이에요.

💰 코딩 에이전트 비용, 5분의 1까지 줄이는 법

요즘 코딩 에이전트(AI가 코드를 대신 짜주는 도구)를 실무에 쓰는 팀이 늘고 있는데요. 그럴 때마다 항상 나오는 문제가 있죠. 바로 비용이에요. 성능 좋은 최상급 모델을 계속 돌리면 작업 하나에 순식간에 수십, 수백 달러가 나가거든요. AI 관측 플랫폼 Arize의 한 엔지니어링 인턴이 이 문제를 파고든 실험기를 공개했어요. 바로 "모델을 하나만 쓰지 말고 작업 성격에 맞게 나눠 쓰자"는 거예요.

$100짜리 작업을 5분의 1 비용으로 처리하기

Arize 인턴 Arda Hoke은 Claude Code, Codex, Cursor 같은 여러 코딩 에이전트 하네스를 매일 테스트하는 업무를 맡고 있었어요. 그중에는 매일 심각한 버그를 찾아 풀 리퀘스트(PR)를 자동으로 여는 슬랙 봇도 있었는데, 이 작업을 처음부터 끝까지 최상급 모델인 Opus 5로만 돌리면 한 번 실행에 약 100달러가 들었다고 해요.

그런데 메인 작업 흐름을 상대적으로 저렴한 Kimi K3 Max로 옮기고, 부수적인 작업은 더 싼 모델들에 맡기며, Opus 5에는 필요할 때만 자문을 구했더니 같은 작업 비용이 15~20달러로 떨어졌어요. 팀은 이렇게 생성된 PR을 실제로 계속 병합(merge)하고 있다고 해요.

에이전트 하네스 설계의 비중

비용 구조는 단순해요. "토큰 단가 × 토큰 사용량"이 전체 비용을 결정하죠. 그런데 실제로 하니스(에이전트가 돌아가는 도구 환경)가 얼마나 많은 코드 맥락을 모델에 넘기는지, 도구 출력을 요약하는지, 서브에이전트를 몇 개나 굴리는지, 언제 재시도하는지에 따라 같은 모델이라도 비용이 크게 달라져요. 실제로 Composio가 같은 모델을 4개의 다른 하니스에서 돌려 30개의 에이전트 작업을 테스트했더니, 성공률은 비슷했지만(30개 중 14~17개 통과) 성공 작업 하나당 비용은 하니스에 따라 최대 2.7배 차이가 났다고 해요.

그래서 Hoke는 "토큰 단가"가 아니라 "승인된 작업 하나당 비용(cost per accepted task)"을 봐야 한다고 강조해요. 시도, 재시도, 검토, 사람의 확인까지 다 포함한 총비용을 실제로 승인된 작업 수로 나눈 값이죠. 예를 들어 PR을 열었다는 것보다 "실제로 병합된 PR"을 기준으로 삼아야 진짜 비용을 알 수 있다는 거예요.

두 가지 라우팅 패턴

실험한 방식은 크게 두 가지예요.

실제로 전체 코드베이스를 훑는 보안 스캔 작업에도 이 두 번째 패턴(저비용 지휘자 + 서브에이전트 50~60개 + 프론티어 자문역)을 적용했더니, 스캔 비용이 약 100달러였고 심각도가 높은 취약점 후보를 20건 이상 찾아냈어요. 같은 작업을 최상급 모델(Fable 5)만으로 돌렸다면 1,000~2,000달러가 들었을 것으로 추정된다고 해요. 다만 찾아낸 취약점은 모두 사람이 직접 확인해야 했다는 한계도 있어요.

값비싼 모델을 판단이 필요한 순간에만 자문으로 부를지, 처음부터 전체 흐름을 맡길지가 두 패턴의 핵심 차이예요.

불필요한 맥락부터 줄이기

라우팅 외에도 눈에 띄는 절감 포인트가 하나 더 있어요. 바로 "맥락(context) 줄이기"예요. 테스트 실행기, 깃(Git) 명령, 빌드 시스템은 수천 줄짜리 로그를 쏟아내지만, 에이전트에게 실제로 필요한 건 실패한 부분과 관련 코드 정도예요. 이런 불필요한 출력을 걸러주는 도구인 RTK는 셸(shell) 출력량을 약 60~90% 줄여준다고 하고, 답변을 간결하게 압축해주는 도구 Caveman은 출력 토큰을 평균 65% 줄여준다고 해요. 다만 이는 각 프로젝트가 자체 보고한 수치라, 실제 팀 업무에 적용할 땐 직접 검증해보는 게 좋아요.

결론을 정리하자면,

① 코딩 에이전트 비용을 줄이려면 무조건 싼 모델을 쓰는 게 아니라, 판단이 필요한 부분에만 비싼 모델을 쓰고 나머지는 저렴한 모델에 맡겨야 하고,

② 불필요한 맥락도 처음부터 줄여야 한다는 것이에요.