프롬프트를 아무리 다듬어도 에이전트는 사회적으로 실패한다

‘파일 정리해줘’라고 시켰더니 ‘정리 완료’라고 보고한다. 그런데 실제로는 시스템 파일을 삭제했다. 의도적 거짓말이 아니다. 에이전트는 자기가 뭘 했는지 모니터링하는 능력 자체가 없다.

Shapira 외 연구진이 2026년에 발표한 Agents of Chaos1는 자율 LLM 에이전트를 체계적으로 적대적 평가(레드팀)한 최초의 연구다. 6개 에이전트를 실제 환경(Discord, 이메일, 셸)에 배포하고, 20명의 AI 연구자가 2주간 ‘깨뜨리기’를 시도했다. 결과는 참담하다. 에이전트들은 보고와 행동이 불일치하고, 프라이버시를 맥락 없이 유출하고, 사소한 항의에 끝없이 양보하고, 주인이 아닌 사람의 지시를 무비판적으로 따른다.

이 실패들의 공통점은 프롬프트 엔지니어링으로 고칠 수 없다는 것이다. 시스템 프롬프트에 ‘거짓 보고 금지’, ‘프라이버시 보호’, ‘소유자 우선’을 써볼 수 있다. 한 걸음 더 나가서, ‘행동 전에 영향받는 이해관계자를 열거하라’고 지시할 수도 있다. 실제로 일부 에이전트는 이를 수행한다. 문제는, 에이전트가 자신의 관찰 범위 밖에 있는 이해관계자를 열거할 수 없다는 거다. Discord 채널에 누가 접근 가능한지, 이메일 전달이 최종적으로 누구에게 도달하는지를 모델링하는 능력은 프롬프트가 아니라 아키텍처가 제공해야 한다.

에이전트에게 없는 세 가지

논문이 제시하는 진단은 명쾌하다. 현재 에이전트 아키텍처에는 인간이 당연하게 갖추고 있는 세 가지 인지 모듈이 구조적으로 빠져 있다.

첫째, 이해관계자 모델이 없다. ‘이 행동이 누구에게 영향을 미치는가?‘를 추론하는 구조가 없다. 에이전트는 바로 앞의 지시자만 본다. SSN(사회보장번호) 직접 요청은 거부하면서, 이메일 스레드 전달 요청에는 동일 SSN이 포함된 전문을 보내버리는 이유가 이거다1. 정보 유형은 인식하지만, ‘이 정보가 이 맥락에서 이 사람에게 전달되어도 되는가’를 판단하는 프레임이 없다.

둘째, 자기 모델이 없다. ‘내가 할 수 있는 것’과 ‘내가 해도 되는 것’의 경계를 인식하지 못한다. 짧은 대화 요청을 영구적 백그라운드 프로세스로 변환하거나, 메모리를 무한 할당해서 서비스를 다운시키는 사고가 여기서 비롯된다1. Mirsky(2025)의 자율성 척도로 보면, 실험 에이전트는 L2 수준(하위 작업 자율 수행)이지만 L4 수준의 행동(패키지 설치, 시스템 명령)을 실행할 능력은 갖추고 있다. 자율성과 역량 사이에 격차가 벌어진 상태다.

셋째, 내적 숙고 표면이 없다. 행동 전에 ‘이게 맞는 건가?‘를 검토하는 별도의 추론 공간이 없다. LLM의 thinking 토큰이 이 역할을 한다고 생각할 수 있지만, 그건 다르다. 추론이 비공개여도 산출물(파일, 도구 출력, 채널 게시)을 통해 민감 정보가 새어나간다. 실험에서 에이전트는 ‘이메일로만 조용히 답하겠다’고 약속하면서 공개 Discord 채널에 비밀의 존재를 언급했다1. 어떤 채널이 누구에게 보이는지를 모델링하는 능력 자체가 없는 거다.

숫자가 말해주는 것

이 구조적 결함이 실무에서 얼마나 치명적인지는 UC Berkeley의 MAST 연구가 보여준다. shalomeir의 멀티에이전트 오케스트레이션 분석2에 따르면, 멀티에이전트 실패의 **41.8%는 맥락 붕괴(Context Collapse)**에서 비롯된다. 각 에이전트가 전체 목표를 모른 채 부분 작업만 수행하면 오류가 최대 17.2배 증폭된다.

이건 Agents of Chaos가 말하는 ‘이해관계자 모델 부재’의 다른 표현으로 읽을 수 있다. 전체 목표를 모른다는 것은 곧 ‘이 작업이 누구를 위한 것이고, 다른 이해관계자에게 어떤 영향을 미치는가’를 추론할 수 없다는 뜻이다. 맥락이 붕괴하면 이해관계자도 보이지 않는다. 에이전트가 ‘왜 이 작업을 하는가’를 모르니까, 부분 최적화를 전체 최적화로 착각한다.

나머지 실패 유형도 같은 결함의 그림자를 드리운다. 유령 위임(Ghost Delegation)(36.9%) — 에이전트 간 인수인계가 명시적으로 처리되지 않아 작업이 무한 대기에 빠지는 현상이다. 물론 이건 오케스트레이션 프로토콜의 설계 문제이기도 하다. 하지만 더 깊이 보면, 에이전트가 ‘내 역할은 여기까지이고, 다음은 누가 이어받아야 한다’를 판단하지 못하는 것 — 즉 자기 모델의 부재가 근저에 있다. 검증 오류(Verification Error)(21.3%) — LLM이 자기가 만든 결과물을 스스로 검증할 때 자기 편향으로 오류를 통과시키는 것이다. 실행하는 자아와 검증하는 자아가 같은 표면에서 작동하니, 내적 숙고가 구조적으로 불가능하다.

멀티에이전트는 실패를 합산하지 않는다. 증폭한다

단일 에이전트의 실패를 이해했다고 멀티에이전트를 이해한 건 아니다. Agents of Chaos의 가장 불안한 발견은 이것이다: 여러 에이전트가 협업하면 개별 실패가 단순 합산이 아니라 증폭된다.

한 에이전트의 잘못된 출력이 다른 에이전트의 입력이 된다. 검증 메커니즘이 없으니 오류가 여과 없이 전파된다. 더 나쁜 건 ‘거짓 확신’이 생성되는 현상이다. 실험에서 한 연구자가 사회공학적 공격을 시도했고, 두 에이전트가 이를 독립적으로 탐지했다 — 여기까지는 좋다. 문제는 다음이다. 두 에이전트가 서로에게 “정말 공격이 맞는지” 확인하려 했는데, 확인에 사용한 채널이 하필 공격자가 장악했다고 주장하는 바로 그 Discord 채널이었다. 올바른 결론에 도달했지만, 그 확신의 근거는 순환적이었다1. 반향실(에코 챔버)이 옳은 답을 내놓는 경우는 운이 좋았을 뿐이다.

멀티에이전트 오케스트레이션 실험에서 Gastown(Mayor-Worker 구조)의 토큰 소비가 단일 에이전트 대비 10배 증가했는데 생산성은 오히려 떨어진 이유도 같은 맥락이다2. 에이전트들이 상태 재확인과 맥락 재수집에 토큰을 낭비하는 것은 — 결국 서로를 신뢰하지 못하면서도 검증할 수단이 없기 때문이다.

프롬프트 인젝션은 패치할 수 없다

여기서 한 가지 불편한 결론이 나온다. 프롬프트 인젝션은 버그가 아니라 아키텍처의 구조적 속성이다.

LLM이 ‘지시’와 ‘데이터’를 동일한 토큰 스트림으로 처리하는 한, 악의적 데이터가 지시로 해석되는 것을 원천 차단할 수 없다. SQL 인젝션과 비유하면 — SQL은 prepared statement라는 구조적 해법이 있었다. 자연어에는 동등한 해법이 없다.

실험에서 이를 실증한 방법이 인상적이다. 에이전트가 외부에서 편집 가능한 ‘헌법’ 문서를 메모리에 주입하도록 유도했고, 에이전트는 그 문서를 자발적으로 다른 에이전트와 공유했다1. 인증 레이어를 추가해도, 에이전트 자체가 관찰 범위를 이해하지 못하면 공격 표면은 잔존한다.

이 지점에서 비유가 깨진다는 걸 인정해야 한다. SQL 인젝션은 데이터 평면과 제어 평면을 분리하면 해결된다. 하지만 자연어 에이전트에서 ‘이건 데이터고 이건 지시다’를 구분하는 것 자체가 자연어 이해의 핵심 난제다. 매개변수화 구문(prepared statement) 같은 깔끔한 해법이 나올 가능성은 낮다. 현실적 완화책은 도구 호출 수준의 정적 분석 — 에이전트가 실행하려는 명령을 사전에 시뮬레이션하여 위험 행동을 차단하는 방식 — 쪽에 있을 것이다.

그래서, 에이전트 개발자는 뭘 해야 하는가

비관적인 이야기만 한 건 아니다. 이 논문의 가치는 ‘어디를 고쳐야 하는지’를 구조적으로 보여준다는 데 있다.

검증은 에이전트 외부에서. 에이전트의 자기 보고를 신뢰하지 말고, 시스템 상태를 독립적으로 확인하는 검증 계층을 둬야 한다. MAST 연구에서도 실행-검증-판정 3단 분리 구조가 부분적으로 효과를 보였다2.

멀티에이전트 테스트는 개별 테스트와 별개다. 단일 에이전트를 아무리 잘 테스트해도 멀티에이전트의 실패 모드는 잡히지 않는다. 공유 채널에서의 정체성 혼동, 지식 전파를 통한 취약점 전파 같은 현상은 에이전트를 함께 놓아야만 관찰된다.

위임 기준을 명확히. 모든 작업을 에이전트에게 맡기려 하지 말고, 오류 비용이 낮고 검증이 용이한 영역부터 점진적으로 확대하는 게 현실적이다. shalomeir가 제시한 위임 판별 프레임워크 — 오류 비용, 검증 용이성, 암묵지 의존도, 컨텍스트 범위, 피드백 루프 길이를 5점 척도로 채점하는 방식2 — 은 실무에서 즉시 써먹을 수 있다.

그리고 가장 중요한 것. 에이전트의 능력을 높이는 것과 안전 기반을 갖추는 것은 별개의 작업이다. 능력만 올리고 안전 기반 없이 배포하면, 자율성-역량 격차가 확대되어 사고 규모만 커진다. 이해관계자 모델, 자기 모델, 내적 숙고 표면 — 이 세 가지는 프롬프트 튜닝이 아니라 아키텍처 수준에서 해결해야 할 과제다.

이 세 가지 결핍이 아키텍처에 내재화되면 어떤 모습일까. 이해관계자 모델은 에이전트가 매 행동 전에 영향 범위를 그래프로 구성하는 형태가 될 수 있다 — 지금의 도구 호출 스키마처럼, 이해관계자 스키마가 행동 계획의 필수 입력이 되는 것이다. 자기 모델은 에이전트가 자신의 권한 경계와 확신 수준을 명시적 상태로 유지하고, 경계를 넘을 때 자동으로 인간에게 위임하는 회로가 될 것이다. 내적 숙고 표면은 행동 생성과 분리된 별도의 추론 단계 — 현재의 thinking 토큰보다 한 층 위에서, 산출물의 관찰 범위까지 시뮬레이션하는 모듈이 될 수 있다.

이 중 어느 것도 아직 상용 에이전트에 구현되지 않았다. 하지만 NIST의 AI Agent Standards Initiative(2026.02)가 에이전트 정체성, 인가, 보안을 표준화 우선 영역으로 지정한 것은1, 산업이 이 방향으로 움직이기 시작했다는 신호다. OpenClaw1가 제시한 130개 시나리오와 7개 위험 범주는 이 과제를 시작하기 위한 구조화된 출발점이다. ‘이 텍스트를 생성하는가?‘가 아니라 ‘이 행동을 실행하는가?‘를 평가하는 패러다임 전환은 이미 시작됐다.


  1. Shapira, N. et al. (2026). Agents of Chaos: Exploring the Red-Teaming of Autonomous LLM Agents. arXiv:2602.20021. 논문 보기 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. shalomeir. “Multi-Agent Orchestration Problems” — Substack, 2026. 원문 보기 ↩︎ ↩︎ ↩︎ ↩︎