마케팅 플랫폼용 AI 에이전트의 어려운 부분은 모델 자체가 아니라 그 주변 모든 것

• AI 에이전트를 여러 마케팅 클라이언트를 위한 제품에 넣을 때, 대부분의 작업은 프롬프트가 아니라 통합(integrations), 테넌트 격리(tenant isolation), 그리고 사람의 승인 과정에 들어갑니다.
• 저희는 이 시스템들을 다섯 개의 레이어로 구성했습니다: 채널(channels) → 가드레일이 적용된 에이전트(agents with guardrails) → 승인 대기열(approval queue) → 에스컬레이션 라우팅(escalation routing) → 클라이언트별 데이터 저장소(per-client data store).
• 실제 운영 빌드 결과: 1,200개 위치에 걸쳐 리뷰 응답 시간이 18시간에서 4분으로 단축되었고 (6주 빌드), 첫 접촉 단계의 테넌트 문의 중 62%가 사람의 개입 없이 처리되었습니다 (14주 빌드).

문제점: 다른 사람을 대신하여 말하는 에이전트

내부 챗봇은 사용자 자신의 팀 질문에 답합니다. 하지만 에이전트가 에이전시나 마케팅 플랫폼 안에 들어갈 때는 더 위험한 일을 합니다: 클라이언트들을 대신하여, 공개적으로 리뷰 답변, 광고 변형(ad variations), 리드 메시지를 작성하는 것입니다.

이는 엔지니어링 요구사항을 변화시킵니다:

• 다수의 테넌트. 모든 클라이언트는 고유의 브랜드 목소리(brand voice), 금지된 문구(banned phrases), 채널, 그리고 에스컬레이션 규칙을 가지고 있습니다.
• 공개 출력. 나쁜 답변은 슬랙 스레드가 아니라 클라이언트의 Google 리스팅 아래에 게시됩니다.
• 혼합 데이터 소스. 리뷰 사이트, 광고 플랫폼, CRM, 부동산 관리 시스템, 받은 편지함 등 각각 고유한 인증(auth), 제한 사항(limits), 그리고 특이점(quirks)을 가진 곳들입니다.

일곱 가지 에이전트 형태, 하나의 패턴

마케팅 제품 전반에 걸쳐, 저희는 동일한 일곱 가지 형태를 계속 구축하고 있습니다:

코드로 보면, 처음 여섯 가지는 대부분 같은 것입니다: 목표(goal), 일련의 도구(set of tools), 그리고 사람에게 멈춰서 물어볼 시점의 정책입니다. 일곱 번째가 조정 레이어(coordination layer)입니다. 여기서 AI 에이전트 오케스트레이션이 대부분의 작업을 수행합니다: 라우팅, 공유 상태(shared state), 그리고 인계(handoffs).

5개 레이어

1. 채널 통합 (Channel integrations). 리뷰 플랫폼, 광고 네트워크, CRM, PMS, 이메일, SMS 등을 검토합니다.
2. 가드레일을 갖춘 에이전트 레이어 (Agent layer with guardrails). 톤(tone), 금지된 콘텐츠(banned content) 및 신뢰도(confidence)에 대한 생성과 확인 과정을 거칩니다.
3. 인간 승인 대기열 (Human approval queue). 사람이 기다리는 초안들입니다.
4. 상황 에스컬레이션 라우팅 (Escalation routing). 민감한 사례는 적절한 사람에게 빠르게 전달됩니다.
5. 클라이언트 데이터 저장소 (Client data store). 테넌트별(Per-tenant) 컨텍스트, 예시 및 기록입니다.

대부분의 노력은 레이어 1에서 발생합니다. 웹훅(Webhooks) 대 폴링(polling), 속도 제한(rate limits), 토큰 새로고침(token refresh), 그리고 열 가지 다른 '리뷰' 객체를 하나의 스키마로 정규화하는 과정에 몇 주가 소요됩니다. 프로젝트 범위를 설정한다면, API 및 통합 작업을 먼저 범위 지정하세요.

테넌트별 정책 (Per-tenant policy)

에이전트가 내리는 모든 결정은 하드코딩된 기본값(hardcoded defaults)에서 오는 것이 아니라, 테넌트 정책(tenant policy)을 읽어야 합니다.

// 패턴의 단순화된 예시이며, 프로덕션 코드는 아닙니다.
interface TenantPolicy {
  tenantId: string;
...
}

승인 게이트 (The approval gate)

모든 초안은 하나의 라우팅 함수를 거치므로,

• 리뷰 관리 (Review management), 1,200개 지점. 응답 시간이 18시간에서 4분으로 단축되었습니다. 약 2.5명 규모의 팀이 6주에 걸쳐 구축했으며, 3개월 만에 투자 비용을 회수했습니다. 이 시스템은 현대화된 평판 관리 플랫폼 위에 구축되었습니다.
• 아파트 마케팅용 임대(Leasing) 비서. 사람의 개입 없이 첫 접촉 단계 문의 중 62%를 처리합니다. 5명 규모의 팀이 14주에 걸쳐 구축했으며, 다중 테넌트 환경이며 부동산 관리 시스템과 통합되었습니다.
• 다세대 주택(multifamily) 마케팅 에이전시용 확보 엔진 (Acquisition engine). 수동 잠재 고객 리서치 작업을 73% 절감하고 신규 영업 인력 채용 없이 아웃바운드 역량을 3.2배 증가시켰습니다.

고려 사항 및 함정 (Trade-offs and gotchas)

• 가장 많은 시간을 차지하는 것은 통합(Integrations)입니다. 에이전트 수를 세기 전에 채널 수를 먼저 계산하세요.
• 브랜드 보이스 충실도(Brand voice fidelity)에는 비용이 듭니다. 전역적인 프롬프트 하나가 아니라, 각 테넌트별 예시와 평가 세트가 필요합니다.
• 규모가 회수 기간을 결정합니다. 리뷰 프로젝트는 월간 관리 트리아지 시간 약 1,100시간을 대체했기 때문에 성공할 수 있었습니다. 낮은 볼륨의 워크플로우는 맞춤형 구축 비용을 절대 회수하지 못할 수도 있습니다.
• 불안정한 워크플로우를 자동화하지 마세요. 만약 수동 프로세스가 매달 변경된다면, 먼저 그 프로세스를 고치세요.
• 데이터 및 IP 소유권을 미리 결정하세요. 여기에는 프롬프트, 평가 세트, 로그, 그리고 모든 파인튜닝(fine-tuning) 데이터가 포함됩니다.
• 모델보다 측정 지표를 먼저 선택하세요. 응답 시간, 처리된 문의 건수, 절약된 리서치 시간 등. 이것 없이는 작동하는지 알 수 없습니다.

일반적인 전달 과정 (How the delivery usually runs)

이러한 프로젝트는 6~14주가 소요됩니다:

1. 발견 및 타당성 검토 (Discovery and feasibility)
2. 아키텍처 및 데이터 접근 (Architecture and data access)
3. 가드레일(guardrails)을 적용한 구축 (Build with guardrails)
4. 검증 및 프로덕션 배포 (Validation and production)

마무리하며 (Wrapping up)

모델 자체는 쉬운 부분입니다. 이 에이전트들을 안전하게 출시할 수 있게 만드는 것은 그 주변의 인프라(plumbing)입니다: 통합, 테넌트별 정책, 승인 게이트(approval gate), 에스컬레이션(escalation), 그리고 엄격한 데이터 격리(data isolation)가 그것입니다.

본 기사는 AI 도움을 받아 작성되었으며 InterCode 팀이 검토했습니다.