대화형 AI 에이전트의 내부 작동 원리

AI 대화형 에이전트의 내부 작동 방식 (OpenClaw 아키텍처)

AI 대화형 에이전트가 실제로 어떻게 작동하는지, 턴 바이 턴으로 살펴봅니다. 이 글은 OpenClaw의 블랙박스를 열어봅니다: 고객의 메시지가 WhatsApp에 도착하는 순간부터 에이전트가 답장을 작성하기까지의 과정입니다. 기술적인 내용입니다. 제품 아키텍처를 결정하는 분, 솔루션을 구매하면서 내부를 평가하고 싶은 분, 또는 대화 뒤에서 무슨 일이 일어나는지 궁금한 분이라면 읽어볼 가치가 있습니다.

TL;DR: 각 턴은 6단계를 거칩니다 — 수집(ingest), 컨텍스트 해석, 스킬 선택, 다음 액션 결정, 가드레일과 함께 실행, 메모리 저장. 전체 사이클은 Cloudflare 엣지에서 고정 서버 없이 2초 이내에 실행됩니다.

---

아키텍처가 중요한 이유

데모에서는 잘 작동하는 것처럼 보이지만 프로덕션에서 깨지는 대화형 에이전트는 보통 다음 4가지 문제 중 하나를 가지고 있습니다:

1. 높은 지연 시간 — 고객이 응답을 8초 기다리면 대화가 끊깁니다.
2. 통제되지 않는 할루시네이션 — 에이전트가 가격, 시간, 정책을 지어냅니다.
3. 컨텍스트 손실 — 고객이 2일 후에 돌아오면 에이전트가 모든 것을 "잊어버립니다".
4. 통제 불능 비용 — 긴 대화마다 프롬프트가 가득 차서 토큰 비용이 엄청나게 나옵니다.

이 4가지는 모두 아키텍처 선택의 문제이지, 모델의 한계가 아닙니다. OpenClaw는 이 4가지를 모두 피하기 위해 설계되었으며 — 이를 이해하는 방법은 한 턴의 사이클을 살펴보는 것입니다.

---

한 턴의 사이클 (6단계)

고객이 방금 "토요일 오전에 예약하고 싶어요"라는 메시지를 보냈다고 상상해 보세요. "received"와 에이전트의 응답 사이에 무슨 일이 일어날까요?

1단계 — 수집(Ingest) (edge worker, <50ms)

WhatsApp 메시지가 Meta의 웹훅을 통해 지리적으로 가장 가까운 접속 지점(PoP)의 Cloudflare Worker로 직접 도착합니다. 브라질의 경우 상파울루 또는 리우를 의미하며, 네트워크 지연 시간은 20ms 미만입니다.

Worker는 세 가지 작업을 수행합니다:

1. 웹훅 서명 검증 (WABA 시크릿에 대한 HMAC).
2. 수신자 전화번호로 테넌트 식별 (멀티 테넌트, to_number 기준).
3. 페이로드 정규화 — 오디오는 전사(transcription)로, 이미지는 설명으로, 위치는 {lat,lng}로, 텍스트는 그대로 유지됩니다.

1단계가 끝나면 다음 단계를 위한 {tenant_id, conversation_id, user_message} 객체가 준비됩니다.

2단계 — 컨텍스트 해석 (D1 + KV, ~80ms)

에이전트가 결정을 내리기 전에 3가지 컨텍스트 조각이 필요합니다:

• 최근 대화 기록 (최근 N개의 관련 턴).
• 고객의 장기 메모리 (선호도, 구매 이력, 메모).
• 에이전트 상태 (페르소나, 활성화된 skills, 규칙).

모두 D1 (Cloudflare의 분산 SQLite)에서 가져옵니다. D1은 기존의 Postgres/Mongo를 대체합니다 — 유지할 데이터베이스 서버가 없고, worker에서 수 ms 내에 접근 가능하며, tenant_id 기반 멀티테넌트를 지원합니다.

핵심 포인트: 우리는 전체 대화를 프롬프트에 로드하지 않습니다. OpenClaw의 Memory Manager v2 (우리의 내부 문서에 설명됨)는 현재 턴에 관련된 턴만 선택합니다 (최근 N개 + 의미적 관련성이 높은 N개). 이를 통해 100턴 이상의 대화에서도 토큰 비용을 예측 가능하게 유지합니다.

스테이지 3 — Skills 선택 (policy engine, ~20ms)

각 에이전트는 호출할 수 있는 함수인 skills 세트를 보유하고 있습니다. 예시: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"토요일 오전에 예약하고 싶어요"라는 메시지가 주어지면, policy engine은 다음을 필터링합니다:

• 감지된 의도(예약)와 호환되는 skills.
• 해당 대화 단계에서 허용된 skills (모든 skill이 항상 사용 가능한 것은 아닙니다).
• 해당 tenant가 활성화한 skills (calendar는 tenant가 연동한 경우에만 표시됩니다).

결과적으로 모델에 전달되는 것은 가능한 50개가 아닌, 여기서 의미 있는 4개만으로 구성된 작은 skills 하위 집합입니다. 이를 통해 모델이 잘못된 skill을 호출할 가능성을 대폭 줄입니다.

스테이지 4 — 결정 (LLM 호출, 400-1200ms)

이제 모델이 등장합니다. OpenClaw는 프론티어 LLM (Anthropic Claude, OpenAI GPT, Google Gemini — tenant별 설정 가능)에 단일 호출을 수행하며, 다음을 포함합니다:

• System prompt = 에이전트의 페르소나 + 규칙 + 사용 가능한 skills.
• History = 스테이지 2에서 선택된 턴.
• User message = 현재 턴의 메시지.

모델은 두 가지 중 하나로 응답합니다:

• 최종 응답 (고객에게 직접 전달되는 텍스트).
• Tool call (특정 skill을 파라미터와 함께 실행하라는 요청).

"토요일 오전에 예약하고 싶어요" 예시에서, 모델은 일반적으로 다음을 반환합니다:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

스테이지 5 — 가드레일을 적용한 실행 (가변, ~100-500ms)

skill은 모델에서 실행되지 않습니다. 우리의 코드에서 실행되며, 이 코드는:

1. 매개변수 검증 (date_range의 형식이 올바른가? 테넌트 규칙 내에 있는가?).
2. 권한 확인 (이 에이전트가 해당 캘린더를 조회할 권한이 있는가?).
3. 호출 실행 (이 경우 Google Calendar API).
4. 구조화된 결과 반환 모델에게 전달.

이것이 왜 중요한가? 모델은 절대 결과를 조작하지 않기 때문이다. 캘린더가 [10h, 11h]을 반환하면, 정확히 그것이 다음 호출로 전달된다. 스킬이 실패하면, 모델은 실패했다는 것을 안다. 에이전트가 실제로는 없는 9시 시간대를 "지어내는" 위험이 제로다.

민감한 정보(가격, 기한, 고객 이름)가 관련된 경우, 파이프라인은 tool call을 강제한다 — 모델이 자체 "지식"으로 응답하도록 허용하지 않는다. 이것은 상업용 에이전트에서 가장 흔한 환각 유형을 제거한다.

스테이지 6 — 응답 및 영속화 (~50ms)

스킬 결과를 확보한 상태에서, 모델은 두 번째 호출을 수행한다 — 이번에는 고객에게 최종 응답을 구성하기 위해서다. 예시:

"토요일 10시와 11시가 가능합니다. 어느 쪽을 선호하시나요?"

동시에 워커는:

1. WhatsApp API를 통해 메시지를 전송한다.
2. 완전한 턴(user + assistant + tool calls + 소요 시간)을 D1에 영속화한다.
3. 턴에서 새로운 사실이 생성된 경우 장기 메모리를 업데이트한다 (예: "고객은 토요일을 선호함").
4. 관측성 이벤트를 발행한다 (지연 시간 메트릭, 토큰 비용, 에스컬레이션 비율).

이 모든 것이 병렬로 실행된다. 영속화는 메시지 전송을 차단하지 않는다 — 고객은 D1을 기다리지 않는다.

---

환각 방어 체계의 위치

프로덕션에서 환각하는 에이전트는 빠르게 신뢰를 잃는다. OpenClaw는 4가지 방어선을 갖추고 있다:

1. 강제된 신뢰할 수 있는 출처. 사실 데이터(가격, 시간, 이름)는 항상 스킬에서 가져오며, 모델 단독으로는 절대 제공하지 않는다.
2. 민감한 데이터에 대한 이중 검증. 예약은 영속화 전에 고객에게 확인한다. 결제는 접근 권한 부여 전에 확인한다.
3. 명시적 부정 규칙. 각 에이전트의 페르소나에 "절대 X, Y, Z를 지어내지 마라"가 포함되어 있다 — 모델은 이를 준수한다.
4. 사람에게 폴백. 어떤 스킬도 질문을 커버하지 못할 때, 에이전트는 "팀에 확인해 보겠습니다"라고 말하고 티켓을 생성한다 — 추측하지 않는다.

지난 6개월간 수행한 감사(실제 대화를 수동으로 검토)에서, 사실 환각 비율은 턴의 0.3% 미만이었다 — 그리고 거의 모든 사례는 설정 문제(테넌트가 관련 스킬을 활성화하지 않음)였지, 모델 오류가 아니었다.

---

대화당 비용

좋은 아키텍처는 청구서를 볼 때까지 보이지 않습니다. 각 턴이 1-2회의 LLM 호출 + D1 조회를 수행한다고 가정하면, 전체 대화(10-15턴) 당 일반적인 비용은 다음과 같습니다: