고객지원 에이전트 아키텍처
고객-facing 챗/지원 에이전트를 AI SDK, AI Gateway, MCP, escalation 구조로 설계하는 방법을 정리합니다.
핵심 요약
- 고객지원 에이전트의 기본축은
App -> AI SDK -> AI Gateway -> MCP resources이며, 고객-facing 경로는 read-only 중심으로 유지합니다. - 정확도보다 응답 시간·잘못된 액션 방지·상담원 전환·고객별 비용 추적에 먼저 부딪힙니다.
- 실시간 채팅에는
streamText와 fast tier를 쓰고, fallback 모델은 1단계 이내로 제한합니다. - 환불·권한변경 같은 side effect는 자동화하지 않고 escalation 또는 별도 approval path로 분리합니다.
- tenant/session 태그를 Gateway usage에 남겨 고객별 비용·품질을 추적하고, low confidence 시 상담원으로 escalation합니다.
AI SDK 7 관측과 요청 경계
아래 messages는 검증된 ModelMessage 배열이라는 전제의 스켈레톤입니다. UIMessage 요청은 먼저 검증·변환하고 tenant·사용자·session의 권한은 로그인한 서버 세션에서 구합니다. client가 보낸 tenantId를 검색 scope·과금 권한으로 신뢰하지 않습니다.
telemetry만 설정해서는 OTel exporter가 등록되지 않습니다. 관측성·평가의 integration bootstrap을 먼저 적용합니다. streaming 응답은 해당 프로토콜에 맞는 stateless helper로 변환합니다.
고객지원 에이전트는 누구나 가장 먼저 떠올리는 AI 유스케이스지만, 막상 운영해 보면 난이도가 생각보다 높습니다.
정확도보다 먼저 부딪히는 건 응답 시간, 잘못된 액션 방지, 사람 상담원 전환, 고객별 비용 추적입니다.
언제 이 패턴을 쓰는가
| 조건 | 적합도 | 이유 |
|---|---|---|
| 실시간 웹 채팅이 필요함 | 높음 | streamText와 fast tier가 잘 맞음 |
| 고객 계정/주문/정책 조회가 필요함 | 높음 | MCP read-only resources 구조가 자연스러움 |
| 환불/권한변경 같은 side effect가 많음 | 중간 | 별도 approval flow 분리가 필요 |
| 응답보다 분석이 더 중요함 | 낮음 | research 패턴이 더 적합 |
권장 아키텍처
계층별 책임
| 계층 | 책임 | 구현 포인트 |
|---|---|---|
| App | 입력 수집, 스트리밍 UI, 세션 관리 | Next.js Route Handler |
| Agent Runtime | retrieval + 답변 루프 | streamText, schema checks |
| Model Control | 모델 선택, fallback, usage tagging | AI Gateway |
| Data Layer | FAQ, policy, order status 조회 | MCP resources |
| Escalation Layer | low confidence / policy fail 처리 | CRM 티켓 생성 또는 상담원 전환 |
요청 흐름
| 단계 | 동작 | 핵심 통제 |
|---|---|---|
| 1 | 고객 메시지 수신 | tenant, session 식별 |
| 2 | 정책/리소스 조회 | read-only resources |
| 3 | AI Gateway로 모델 호출 | fast primary + fallback |
| 4 | 응답 confidence / policy 검사 | unsafe answer 차단 |
| 5 | 즉시 응답 또는 escalation | human handoff |
최소 구현 스켈레톤
import { createUIMessageStreamResponse, streamText, toUIMessageStream } from 'ai'
export async function POST(req: Request) {
const { messages, tenantId, sessionId } = await req.json()
const result = streamText({
model: 'openai/gpt-6.1-sol',
messages,
providerOptions: {
gateway: {
user: sessionId,
tags: [`tenant:${tenantId}`, `session:${sessionId}`, 'surface:web-chat'],
},
},
telemetry: {
isEnabled: true,
functionId: 'customer-support-chat',
},
})
return createUIMessageStreamResponse({
stream: toUIMessageStream({ stream: result.stream }),
})
}보안·거버넌스 포인트
| 통제 | 이유 |
|---|---|
| MCP resources read-only | 잘못된 쓰기 차단 |
| tool 최소화 | prompt injection 공격면 축소 |
| WAF / BotID | abusive traffic 방어 |
| tenant tag / api key 분리 | 고객별 비용·품질 추적 |
실패 모드와 fallback
| 실패 모드 | 대응 |
|---|---|
| primary 모델 timeout | fallback 모델 1회 전환 |
| retrieval 실패 | 제한된 답변 + 재질문 유도 |
| low confidence | 상담원 escalation |
| schema failure | canned apology + ticket 생성 |
운영 지표
| 지표 | 목표 예시 |
|---|---|
| p95 응답 시간 | 4초 이하 |
| escalation 비율 | 10~20% 내에서 관리 |
| retrieval miss rate | 5% 이하 |
| 고객별 월 spend | plan tier 예산 내 |
ADR 스타일 결론
Decision
고객지원 에이전트는 App -> AI SDK -> AI Gateway -> MCP resources를 기본축으로 두고, 고객-facing
경로는 read-only 중심으로 유지합니다. 고객에게 직접적인 side effect는 즉시 자동화하지 않고 escalation
또는 별도 approval path로 분리합니다.
실무 체크리스트
- 고객-facing 경로에서 write tool이 제거되어 있는가
- fallback 모델이 1단계 이내로 제한되는가
- low confidence 시 escalation 경로가 있는가
- tenant/session 태그가 Gateway usage에 반영되는가