LLM은 왜 적대적 상황에서 무너지는가 — 멀티에이전트 월드 모델이 필요한 이유

"잘 쓴 것 같은데" vs "실전에서 먹히는 것"

재판 전문 변호사에게 "AI가 당신 일을 대체할 수 있냐"고 물으면 쳐다보지도 않음. 반면 스타트업 창업자는 "이미 되고 있다"고 함. 둘 다 같은 결과물을 보고 있는데 판단이 다름.

핵심은 이거임: 아웃사이더는 결과물의 품질(artifact quality)을 보고, 전문가는 적대적 환경에서의 생존력(strategic competence)을 봄.

슬랙 메시지 하나로 보는 차이

새 직장 3주차. 바쁜 리드 디자이너 Priya에게 리뷰를 요청해야 함. ChatGPT한테 시키면 이런 메시지가 나옴:

"안녕하세요 Priya, 시간 되실 때 제 파일 좀 봐주실 수 있을까요? 전혀 급하지 않아요, 편하실 때 부탁드립니다!"

금융권 친구 반응: "완벽하네, 예의 바르고 안 밀어붙이고."

3년차 동료 반응: "보내지 마. Priya는 '급하지 않다'를 '우선순위 낮음'으로 읽음. 15개 다른 메시지 아래로 묻힘. 그리고 '봐주세요'가 너무 모호해서 10분짜리인지 2시간짜리인지 모르니까 회피하게 됨."

동료가 한 건 시뮬레이션임. Priya의 업무량, 트리아지 휴리스틱, 모호함이 주는 비용, "급하지 않다"가 압박 상황에서 어떻게 해석되는지를 머릿속에서 돌린 것임.

완전정보 게임 vs 불완전정보 게임

체스/바둑 = 완전정보 게임. 모든 말이 보이고, 규칙이 동일하고, 숨겨진 상태가 없음. 상대가 누구든 최적 수는 동일함. AlphaZero가 인간 심리를 모델링할 필요가 없었던 이유임.

포커 = 불완전정보 게임. 상대 패를 모름. 블러핑이 존재하고, "나는 상대가 내가 약하다고 생각한다고 생각하니까 트랩을 걸자"라는 재귀적 모델링이 필요함.

Meta의 Pluribus가 포커에서 인간을 이긴 방식이 핵심임. Pluribus는 모든 가능한 핸드에 대해 어떻게 행동할지를 먼저 계산한 다음, 전략을 밸런싱해서 상대가 자기 행동 패턴에서 정보를 추출할 수 없게 만듦. 읽히지 않는 것 자체가 전략이었음.

LLM의 구조적 실패 모드

LLM은 RLHF로 "도움이 되고, 예의 바르고, 균형 잡힌" 응답을 내도록 훈련됨. 1회성 평가에서 높은 점수를 받기 위해 최적화된 것임. 이건 협력 편향(cooperative bias)을 만들고, 적대적 상황에서는 치명적임:

• 공격적 첫 제안 → 모델이 수용 쪽으로 앵커링되는 걸 알고 밀어붙임
• 모호한 상황 → 모델이 선의로 해석하는 걸 알고 이용
• 블러프 → 모델이 액면가로 받아들이는 걸 알고 활용
• 탐침 → 모델이 관찰당하는 것에 적응하지 못하는 걸 알고 패턴 파악

Pluribus의 정반대임. 포커에서 AI는 읽히지 않아서 이겼는데, 현재 LLM 에이전트는 가장 읽히기 쉬운 상대가 될 판임.

"더 똑똑하게" 만들면 해결될까?

안 됨. 모델이 적대적으로 견고하게 행동하려면 4단계가 필요한데:

1. 이 상황이 전략적임을 감지 (협력처럼 보여도)
2. 관련 에이전트와 각자의 최적화 목표 파악
3. 내 행동 후 상대가 어떻게 해석하고 적응할지 시뮬레이션
4. 가능한 반응들 전반에 걸쳐 견고한 행동 선택

2~4단계는 좋은 프롬프팅으로 어느 정도 가능함. 1단계가 진짜 문제임. 모델에게 "협력적 과제"와 "협력처럼 보이지만 적대적으로 평가될 과제"를 구분하는 기본 온톨로지가 없음.

그리고 인과적 지식 자체가 훈련 데이터에 부족함. 투자자가 논문을 발표할 때 빠진 것들: 포지션 사이징, 타이밍, 전략적 은폐, 틀렸을 때의 대응. 텍스트는 행동의 잔여물이지, 행동을 만든 이론이 아님.

코드는 체스, 하지만 프로 SE는 포커

LLM이 지배하는 영역은 "체스 같은" 도메인임:

• 코드 작성: 결정적, 규칙 명시적, 숨겨진 상태 없음, 정답 검증 가능
• 수학 증명, 데이터 변환, 번역, 컴플라이언스 사무 등도 마찬가지

하지만 프로페셔널 소프트웨어 엔지니어링은 체스를 넘어감:

• 모호한 요구사항 → 이해관계자가 실제로 원하는 것 vs 말한 것 모델링
• API 설계 → 다른 개발자가 어떻게 오용할지 예측
• 코드 리뷰 → 리뷰어의 선호와 우려 모델링 (사회적 게임)
• 아키텍처 결정 → 미래 요구사항 + 조직 정치 고려

겉으로 보이는 일은 체스 같고, 실제로 하는 일은 포커 같음.

다가오는 충돌

LLM 에이전트가 구매, 영업, 협상, 정책, 보안 분야에 배치되면 exploitability가 실질적 문제가 됨. 인간 상대는 모델을 "지적으로 이길" 필요 없이 기본 실패 모드로 몰면 됨.

포커 프로, 숙련된 협상가, 소송 변호사는 이미 본능적으로 이걸 함. 상대를 읽고, 패턴을 탐지하고, 일관성을 이용함. LLM 에이전트가 자기들이 만나본 가장 일관적이고 읽기 쉬운 상대라는 걸 깨닫기까지 시간 문제일 뿐임.

해법: 다른 훈련 루프

필요한 건 결과(outcome)로 평가하는 훈련임. 메시지가 합리적으로 들리느냐가 아니라, 리뷰를 실제로 받았느냐, 레버리지를 양보했느냐, 이용당했느냐로 점수를 매기는 것.

이건 멀티에이전트 환경 — 다른 자기이익 추구 에이전트들이 반응하고 탐침하고 적응하는 환경 — 에서의 훈련이 필요함. 언어 생성을 단일 에이전트 출력 문제가 아니라, 숨겨진 상태가 있는 멀티에이전트 게임에서의 행동으로 다뤄야 함.

LLM은 전문가처럼 보이는 결과물을 만듦. 전문가의 검증을 견디는 수(手)는 아직 못 만듦.