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

대화형 AI 에이전트가 내부적으로 작동하는 방식 (OpenClaw 아키텍처)

대화형 AI 에이전트가 실제로 어떻게 작동하는지, 턴 바이 턴으로? 이 포스트는 OpenClaw의 블랙박스를 열어봅니다: 고객의 메시지가 WhatsApp에 도착하는 순간부터 에이전트가 다시 작성하는 텍스트까지. 기술적일 것입니다. 제품 아키텍처를 결정하는 경우, 솔루션을 구매하려고 하고 깊이 있게 평가하고 싶은 경우, 또는 대화 뒤에서 무슨 일이 일어나고 있는지 알고 싶어하는 경우 가치가 있습니다.

TL;DR: 각 턴은 6개의 단계를 거칩니다 — ingest, 컨텍스트 해결, 스킬 선택, 다음 작업 결정, guard-rails로 실행, 메모리 유지. 전체 사이클은 고정 서버 없이 Cloudflare 엣지에서 <2초 안에 실행됩니다.

---

아키텍처가 중요한 이유

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

1. 높은 지연 시간 — 고객이 응답을 기다리는 데 8초, 대화가 죽습니다.
2. 제어되지 않는 환각 — 에이전트가 가격, 시간, 정책을 만들어냅니다.
3. 손실된 컨텍스트 — 고객이 2일 후 돌아오면 에이전트가 모든 것을 "잊습니다".
4. 제어되지 않는 비용 — 각 긴 대화가 프롬프트를 채우고 토큰에 막대한 비용을 지불합니다.

4가지 모두 모델의 제한이 아닌 아키텍처 선택입니다. OpenClaw는 4가지를 모두 피하기 위해 구축되었습니다 — 이를 이해하는 방법은 턴의 사이클을 살펴보는 것입니다.

---

턴의 사이클 (6개 단계)

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

단계 1 — Ingest (엣지 워커, <50ms)

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

워커는 세 가지를 수행합니다:

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

단계 1의 끝에서 다음 단계를 위해 준비된 {tenant_id, conversation_id, user_message} 객체가 있습니다.

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

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

• 대화의 최근 기록 (관련된 마지막 N개 턴).
• 클라이언트의 장기 메모리 (선호도, 구매 기록, 메모).
• 에이전트 상태 (페르소나, 활성화된 스킬, 규칙).

모두 D1(Cloudflare의 분산 SQLite)에서 가져옵니다. D1은 기존 Postgres/Mongo를 대체합니다 — 유지할 데이터베이스 서버 없음, 워커에서 몇 ms 내에 액세스 가능, tenant_id로 멀티테넌트 지원.

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

단계 3 — 스킬 선택 (정책 엔진, ~20ms)

각 에이전트는 사용 가능한 스킬 세트를 가지고 있습니다 — 호출할 수 있는 함수입니다. 예: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

메시지 "quero marcar pra sábado de manhã"가 주어지면, 정책 엔진은 다음을 필터링합니다:

• 감지된 의도와 호환되는 스킬 (일정 예약).
• 이 대화 단계에서 허용되는 스킬 (모든 스킬이 항상 사용 가능한 것은 아님).
• 이 테넌트가 활성화한 스킬 (테넌트가 통합한 경우에만 캘린더가 나타남).

결국 모델에 전달되는 스킬의 작은 부분집합을 얻습니다 — 가능한 50개가 아니라 여기서 의미 있는 4개만. 이는 모델이 잘못된 스킬을 호출할 가능성을 크게 줄입니다.

단계 4 — 결정 (LLM 호출, 400-1200ms)

이제 모델이 들어갑니다. OpenClaw는 경계 LLM(Anthropic Claude, OpenAI GPT, Google Gemini — 테넌트별로 구성 가능)에 단일 호출을 수행합니다:

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

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

• 최종 응답 (클라이언트에게 직접 전송되는 텍스트).
• Tool call (특정 스킬을 매개변수와 함께 실행하도록 요청).

"quero marcar pra sábado de manhã" 예제에서 모델은 일반적으로 다음을 반환합니다:

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

단계 5 — 가드레일을 포함한 실행 (가변, ~100-500ms)

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

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

왜 이것이 중요한가? 모델이 절대 결과를 만들어내지 않기 때문입니다. 캘린더가 [10h, 11h]를 반환하면, 정확히 그것이 다음 호출로 전달됩니다. 스킬이 실패하면, 모델은 실패했다는 것을 알 수 있습니다. 에이전트가 실제로 없는 9시에 "시간이 있다"고 "꾸며낼" 위험이 전혀 없습니다.

민감한 정보(가격, 기한, 고객명)가 포함된 경우, 파이프라인은 tool call을 강제합니다 — 모델이 자신의 "지식"으로 응답하도록 허용하지 않습니다. 이것이 상용 에이전트에서 가장 흔한 환각 클래스를 제거합니다.

단계 6 — 응답 및 지속성 (~50ms)

스킬의 결과를 손에 들고, 모델은 두 번째 호출을 수행합니다 — 이제 고객을 위한 최종 응답을 형성하기 위해. 예:

"토요일 10시와 11시가 있습니다. 어느 것을 선호하시나요?"

동시에, 워커는:

1. 메시지를 WhatsApp API를 통해 다시 전송합니다.
2. 전체 턴을 D1에 지속(사용자 + 어시스턴트 + 도구 호출 + 소요 시간).
3. 턴이 새로운 사실을 생성한 경우 장기 메모리 업데이트(예: "고객이 토요일을 선호").
4. 관찰성 이벤트 발행(지연 시간 메트릭, 토큰 비용, 에스컬레이션 비율).

모든 것이 병렬로 실행됩니다. 지속성은 메시지 전송을 차단하지 않습니다 — 고객이 D1을 기다리지 않습니다.

---

환각에 대한 방어가 어디에 있는가

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

1. 강제된 정보 출처. 사실 데이터(가격, 시간, 이름)는 항상 스킬에서만 오고, 모델 단독으로는 절대 아닙니다.
2. 민감한 데이터의 이중 검증. 일정은 지속하기 전에 고객과 확인됩니다. 결제는 액세스를 허용하기 전에 확인됩니다.
3. 명시적 부정 규칙. 각 에이전트의 페르소나에는 "절대 X, Y, Z를 꾸며내지 마"가 포함되어 있습니다 — 모델이 따릅니다.
4. 인간으로의 폴백. 어떤 스킬도 질문을 다루지 않을 때, 에이전트는 "팀과 확인해 보겠습니다"라고 말하고 티켓을 엽니다 — 추측하지 않습니다.

지난 6개월간 수행한 감사(수동으로 검토한 실제 대화)에서, 사실 환각 비율은 턴의 0.3% 미만이었습니다 — 거의 모든 경우가 설정(테넌트가 관련 스킬 활성화를 잊음)으로 인한 것이지, 모델 오류가 아닙니다.

---

대화당 비용

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