대화가 성립했다는 착각

---

무너지는 지점은 여기가 아니다

멀티에이전트 시스템이 실패할 때 사람들이 가장 먼저 의심하는 것은 모델 성능이거나 도구 설계다. 그런데 실제 실패를 추적해보면 다른 곳에서 시작된 경우가 많다. 에이전트 A가 에이전트 B에게 무언가를 요청했을 때, B는 그 요청을 이해했다고 전제하고 행동했고, A는 B가 이해했을 것이라고 전제했다. 둘 다 틀렸는데, 둘 다 그 사실을 몰랐다.

문제는 모델 성능이 아니었다. 대화가 성립했다는 전제 자체가 틀렸던 것이다.

---

인간의 대화에는 보이지 않는 기반이 있다

언어학에는 utterance grounding이라는 개념이 있다. 발화를 주고받는 과정에서 상호 이해가 실제로 확립되는 메커니즘인데, 핵심은 말을 했다고 이해가 생기는 게 아니라 이해가 확인됐을 때 생긴다는 것이다. 인간의 대화에서 이 확인은 끊임없이 일어난다. "그렇죠", "맞아요", "그러니까 이 말씀이시죠?" 같은 표현들이 그것이기도 하고, 상대가 맥락에 맞게 대화를 계속 이어가는 것 자체도 그라운딩의 신호다. 대화 참여자들은 이런 방식으로 **공통 기반(common ground)**을 서로 쌓아간다.

그라운딩이 실패하면 수리(repair)가 일어난다. "잠깐, 그 말이 아니라 다른 뜻이었는데요"라는 신호가 오해가 쌓이기 전에 대화 흐름 자체에서 등장한다. 이 과정 전체가 대부분 무의식적이고 자동적으로 진행되기 때문에, 우리는 그것이 존재한다는 사실을 잘 인식하지 못한다. 에이전트 시스템을 설계하기 전까지는.

---

에이전트에게는 그라운딩 루프가 없다

에이전트 A가 에이전트 B에게 메시지를 보낸다.

A → B: "리포트를 정리해서 다음 에이전트에게 넘겨줘"

B는 이 메시지를 처리하고 행동에 들어간다. 그런데 이 과정에서 B는 "리포트 정리"가 무엇을 뜻하는지 확인하지 않고, A는 B가 같은 의미로 이해했는지 확인받지 못하며, "다음 에이전트"가 누구인지나 "넘긴다"는 것이 구체적으로 어떤 행동을 의미하는지에 대한 공통 기반이 없는 채로 실행이 진행된다. B는 이해했다고 전제하고, A는 B가 이해했을 것이라고 전제하며, 이 이중 전제 위에서 파이프라인 전체가 돌아간다.

인간의 대화였다면 바로 이 지점에서 수리가 일어났을 것이다. 에이전트 파이프라인에서는 오해가 그냥 다음 단계로 흘러간다.

---

신뢰가 무너지는 구조

신뢰는 예측 가능성이다. 이 에이전트는 내가 요청한 것을 내가 의도한 방식으로 실행할 것이라는 기대. 그런데 그라운딩이 없는 시스템에서 신뢰는 착각 위에 세워진다. 에이전트가 잘 작동하는 것처럼 보이는 동안, 우리는 그 에이전트가 우리가 의도한 것을 하고 있다고 믿지만, 실제로는 에이전트가 자신의 해석으로 행동하고 있을 뿐이다.

이게 위험해지는 구조가 두 가지 방향으로 작동한다. 첫째로 오류가 증폭된다. 멀티에이전트 파이프라인에서 A의 오해는 B에게 전달되고, B의 오해는 C에게 전달된다. 각 에이전트가 그라운딩 없이 행동하면 오해가 복리로 쌓이고, 최종 결과물이 잘못됐을 때 어디서 틀렸는지 추적하는 것이 극히 어려워진다. 둘째로 실패가 늦게 발견된다. 그라운딩이 있는 시스템에서는 오해가 생기는 즉시 수리 신호가 등장하지만, 그라운딩이 없는 시스템에서는 파이프라인이 끝날 때까지, 심한 경우 배포 이후까지도 오해가 드러나지 않는다.

---

세 가지 오해의 층위

에이전트 커뮤니케이션에서 그라운딩 실패는 세 가지 서로 다른 층위에서 일어난다.

이 세 층위 중 하나만 엇나가도 파이프라인의 신뢰는 흔들리는데, 지금 대부분의 멀티에이전트 시스템은 이 세 가지를 모두 암묵적으로 통과시키고 있다.

---

이건 버그가 아니라 구조적 부재다

중요한 것은 그라운딩 부재가 고칠 수 있는 버그가 아니라는 점이다. 인간의 대화에서 공통 기반은 수십 번의 교환을 통해 형성된 공유된 맥락과 참조점과 기대값으로 구성된다. 에이전트들 사이에는 이런 기반이 없다. 에이전트는 매 실행마다 새로 시작하거나, 공통 기반이 있다 해도 그것이 체계적으로 구축된 것이 아니라 프롬프트 안에 주입된 것일 뿐이고, 주입된 공통 기반은 실행 중에 새로운 맥락에 밀리면 언제든지 흔들릴 수 있다.

그라운딩이 없는 상태에서 작동하는 시스템은 신뢰를 설계한 것이 아니라 가정하고 있는 것이다.

---

설계로 복구하는 세 가지 방법

구조적 부재를 인정하면 설계 방향이 달라진다.

명시적 계약으로 공통 기반을 만든다. 인간의 공통 기반은 대화를 통해 점진적으로 쌓이지만, 에이전트에게는 그 과정이 없으므로 계약으로 대체해야 한다. 에이전트 A가 B에게 요청할 때, 그 요청에 의미·의도·맥락 세 층위를 처음부터 명시하는 것이다.

A → B:
  요청: 리포트를 정리해서 다음 에이전트에게 넘겨줘
  정리의 기준: 3개 섹션 (요약, 근거, 한계), 각 500자 이내
  넘기는 방식: content_bus에 publish, format=structured
  다음 에이전트: reviewer_agent (id: rev_001)

이것이 장황해 보인다면, 그라운딩 없이 보낸 "리포트를 정리해서 넘겨줘" 한 줄이 얼마나 많은 것을 가정하고 있는지를 거꾸로 생각해보면 된다.

확인 응답을 프로토콜에 넣는다. 에이전트 B가 요청을 받으면 바로 실행에 들어가는 것이 아니라, 자신이 해석한 내용을 먼저 확인하게 설계할 수 있다.

B → A:
  수신: 리포트 정리 요청
  해석: 3섹션, 각 500자, structured format으로 rev_001에 publish
  시작 전 확인 필요: 원본 리포트 파일 경로

이 확인 응답이 그라운딩 루프를 만든다. A는 B가 자신의 의도를 올바르게 이해했는지 확인할 수 있고, 오해가 있다면 바로 이 지점에서 수리가 일어난다.

공통 기반을 상태로 관리한다. 파이프라인 전체를 통해 공통 기반을 축적하고 참조할 수 있는 상태 객체를 두면, 어떤 에이전트든 현재의 공통 기반이 무엇인지 조회할 수 있고 그것이 어떻게 형성됐는지 추적할 수 있다.

{
  "shared_context": {
    "report_definition": "3-section: summary, evidence, limitations",
    "word_limit_per_section": 500,
    "next_agent": "rev_001"
  },
  "grounding_log": [
    {"from": "A", "to": "B", "request": "...", "ack": "...", "status": "confirmed"}
  ]
}

---

에이전트의 신뢰는 매번 설계에서 나온다

인간은 관계와 경험을 통해 신뢰를 쌓는다. 이 사람은 지난번에도 이렇게 했고 그 전에도 이렇게 했으니 이번에도 그럴 것이라는 기대가 누적된 것이다. 에이전트는 이런 방식으로 신뢰를 쌓지 않는다. 에이전트에 대한 신뢰는 경험이 아니라 그 시스템이 어떻게 설계됐는지에서 매번 새로 온다. 그리고 그 설계의 가장 기본적인 조건이 그라운딩이다. 메시지가 전달됐는지가 아니라, 그 메시지의 의미가 의도한 것과 같은 방식으로 해석됐는지가 신뢰의 실제 기반이다.

에이전트가 메시지를 수신했다는 것과 에이전트가 그 메시지를 이해했다는 것은 다른 말이다. 지금 대부분의 시스템에서 이 둘은 구별되지 않고 있다.

---

복잡해질수록 커지는 비용

에이전트가 단일 작업을 수행할 때는 이 문제가 상대적으로 덜 두드러진다. 하나의 에이전트가 하나의 요청을 받아 하나의 결과를 내면, 오해가 있더라도 그 범위가 제한되고 발견도 빠르다. 그런데 에이전트들이 서로 연결되고, 한 에이전트의 출력이 다음 에이전트의 입력이 되는 파이프라인이 늘어날수록 그라운딩 부재의 비용은 기하급수적으로 커진다.

결과가 맞는 것처럼 보이는 동안에도 내부에서 그라운딩이 안 된 채로 작동하는 시스템은 언제 어떤 방식으로 실패할지 예측하기 어렵다. 그리고 그 실패가 일어났을 때 설계자조차 어디서 왜 틀렸는지 설명하지 못하는 경우가 많다. 신뢰는 설계하는 것이고, 그라운딩은 그 설계의 출발 조건이다.

---

utterance-grounding 개념 참고: Clark & Schaefer (1989), "Contributing to Discourse"