.png)
실무에 AI Agent를 넣는 법: 쿠폰 발행으로 본 설정 Copilot 패턴
기획연재 2편 : 고객 10만 명을 LLM에게 직접 판단시키지 마라. Agent가 조건을 제안하고, 시스템이 결과를 검증하고, Agent가 다시 설정을 고도화하는 루프가 더 안전하고 저렴하다.
📚 연재 안내 | 이 글은 2부작 연재의 마지막 2편입니다.
① LLM에 Tool Calling만 붙인다고 Agent가 되지 않는 이유
② 실무에 AI Agent를 넣는 법 — 설정 Copilot 패턴(현재 글)
지난 1편에서 우리는 AI Agent를 LLM과 동일시하면 안 된다고 이야기했습니다. Agent는 좋은 모델에 RAG와 Tool Calling을 붙인 것이 아니라, 업무 시스템의 데이터 모델·권한·상태·검증·비용 통제와 결합될 때 비로소 제품이 됩니다. 그렇다면 이 관점을 실제 업무에는 어떻게 적용해야 할까요?
이번 글에서는 마케팅 자동화에서 자주 등장하는 문제를 예로 들겠습니다.
특정 제품 홍보 페이지에 접속한 사용자 중 구매 가능성이 높은 고객을 선별해 할인 쿠폰을 발행하고, 구매 전환율을 높이고 싶다.
단순해 보이는 요구사항입니다. 하지만 AI Agent를 잘못 넣으면 순식간에 위험한 시스템이 됩니다.
모든 것을 쥔 Agent-as-Executor가 아니라, 업무 파이프라인 속 한 구간에 얌전히 꽂힌 '설정 Copilot'이 더 안전합니다.
기존 방식: 룰 엔진으로 고객을 선별한다
기존 마케팅 자동화는 이런 업무를 보통 룰 엔진으로 처리했습니다. 요즘은 이 룰 엔진이 대개 로우코드/노코드 자동화 시스템 안에 들어 있어, 마케터가 화면에서 세그먼트 조건과 발송 흐름을 직접 구성합니다. 조건은 이렇게 조합합니다.
📝 [기존 룰 엔진 — 조건 조합 예시]
제품 A 홍보 페이지를 최근 7일 내 3회 이상 방문
AND 최근 30일 내 구매 없음
AND 장바구니 추가 이력 있음
AND 마케팅 수신 동의 있음
AND 최근 7일 내 쿠폰 미발급
AND VIP 등급 제외
→ 10% 할인 쿠폰 발행
이 방식의 장점은 분명합니다. 조건이 결정적입니다. 같은 데이터에 같은 룰을 적용하면 같은 결과가 나오고, 예산·빈도·수신 동의·중복 발급 같은 제약을 코드와 정책으로 강제할 수 있습니다.
하지만 한계도 있습니다. 구매 가능성을 더 정교하게 판단하려면 조건이 끝없이 늘어납니다. 과거 구매 패턴, 가격 민감도, 관심 카테고리, 방문 시간대, 이전 쿠폰 반응, 유사 고객군의 전환 패턴까지 반영하려면 마케터가 그 모든 조건을 직접 정의해야 합니다.
이때 AI가 매력적으로 보입니다. "이 고객이 살 가능성이 높은지 AI가 판단하면 되지 않을까?" 하는 기대입니다. 방향은 맞지만 한 가지 구분이 필요합니다. 고객별 구매 가능성을 대량으로 점수화하는 일은 사실 LLM보다 검증된 예측·통계 모델이 더 잘하고, Agent가 잘하는 것은 그 점수와 결과를 해석해 조건·세그먼트·전략으로 옮기는 일입니다. 그리고 무엇보다 AI가 잘하는 영역과 시스템이 반드시 통제해야 하는 영역을 섞으면 안 됩니다.
나쁜 설계: 모든 것을 Agent에게 맡긴다
가장 위험한 접근은 Agent에게 전부 맡기는 것입니다. 방문 로그·고객 데이터·상품 정보를 주고, 구매 가능성 판단부터 대상자 선정, 쿠폰 금액 결정, 발행 API 호출, 메시지 작성·발송까지 한 번에 시키는 구조입니다.
표면적으로는 멋있어 보입니다. 하지만 프로덕션에서는 매우 위험합니다.
여기서 가장 큰 문제는 AI가 "똑똑하지 않다" 가 아닙니다. AI가 너무 많은 권한을 갖는다는 것입니다.
Agent에게 "알아서 좋은 고객을 골라 쿠폰을 발행해줘" 라고 시키는 순간, 우리는 마케팅 자동화를 만든 것이 아니라 비결정적인 발송 시스템을 만든 것입니다.
Agent가 데이터·쿠폰 API·메시지·CRM을 모두 직접 쥐고 즉시 실행하면, 시스템은 사고를 사후에야 발견합니다.
더 실용적인 설계: Agent를 '설정 Copilot'으로 쓴다
AI Agent를 쿠폰 발행에 도입한다고 하면, 많은 분이 먼저 "AI가 고객을 직접 골라주는 그림" 을 떠올립니다. 하지만 실무에서는 이 방식이 항상 최선은 아닙니다. 고객 수가 많아질수록 비용과 지연 시간이 빠르게 늘고, 같은 고객을 같은 조건으로 다시 평가했을 때 같은 결과가 나온다는 보장도 약하기 때문입니다.
여기서 한 가지 더 주의할 점이 있습니다. 캠페인의 목표는 단순히 '구매 확률이 높은 고객'을 찾는 것이 아닙니다. 이미 살 가능성이 높은 고객은 쿠폰이 없어도 구매할 수 있고, 이들에게 할인하면 전환은 늘리지 못한 채 마진만 줄어들 수 있습니다. 더 중요한 것은 쿠폰을 받았을 때 행동이 달라질 고객, 즉 쿠폰의 증분 효과(uplift)가 큰 고객을 찾는 것입니다. 이는 단순 구매 확률 예측(propensity)보다 처치 효과를 추정하는 uplift 모델에 가까운 문제입니다[1]. 따라서 고객별 우선순위가 필요하다면 LLM이 직접 구매 여부를 판단하게 하기보다, 검증된 propensity·uplift 모델을 활용하고 Agent가 그 결과를 해석해 세그먼트 조건과 캠페인 전략에 반영하는 편이 적절합니다.
더 자주, 더 안전하게 쓸 수 있는 방식은 다릅니다. Agent가 고객 한 명 한 명을 직접 고르는 것이 아니라, 로우코드/노코드 자동화 시스템(과 그 안의 룰 엔진)에서 쓸 세그먼트 조건·발송 흐름을 제안하고, 그 결과를 검증하며, 다시 조건을 고도화하게 하는 것입니다. 즉 Agent의 역할이 '실행자'가 아니라 설정 설계자(Configuration Copilot)에 가까워집니다.
Agent는 룰로 표현하기 어려운 마케팅 의도를 해석합니다. 예를 들어 "제품 A에 관심은 높지만 아직 구매를 망설이는 고객" 이라는 모호한 목표를, 실제 시스템이 실행할 수 있는 조건 조합으로 바꿉니다.
📝 [Agent가 마케팅 의도를 조건으로 변환한 예시]
최근 7일 내 제품 A 페이지 2회 이상 방문
AND 장바구니 추가 이력 있음
AND 최근 30일 내 구매 없음
AND 최근 14일 내 쿠폰 미발급
AND 마케팅 수신 동의 있음
AND VIP 등급 제외
그다음 시스템이 이 조건을 실제 데이터에 적용해 대상자 수·예상 비용·중복 여부·정책 위반 여부를 계산합니다. Agent는 그 결과를 다시 보고 "대상자가 너무 많아 예산을 초과하니 방문 횟수를 3회 이상으로 올리자", "10% 쿠폰 대신 상위 관심 고객에게만 15%를 주고 나머지는 무료배송으로 나누자" 처럼 조건을 고도화합니다.
여기서 중요한 차이가 있습니다.
Agent가 직접 쿠폰을 발급하는 것이 아니라, Agent가 쿠폰 발급 시스템이 실행할 '조건과 흐름'을 더 잘 만들게 하는 것입니다.
이 방식은 비용 면에서도 훨씬 유리합니다. 고객 10만 명을 Agent가 직접 판단하면 LLM 호출이 고객 수에 비례합니다. 반면 Agent가 조건 조합을 설계하고 룰 엔진이 대상자를 계산하면, LLM 호출은 고객 수가 아니라 설정 반복 횟수에 비례합니다.
나쁜 방식: 고객 수 × Agent 판단 비용 × 검증 비용
좋은 방식: 조건 설계 횟수 × Agent 판단 비용 + 고객 수 × 룰 엔진 계산 비용
대량 고객을 다루는 마케팅 자동화에서는 이 차이가 매우 큽니다. 그래서 프로덕션 Agent 설계에서 먼저 고민해야 할 질문은 "AI가 누구를 골라야 하는가?" 가 아닙니다. 더 좋은 질문은 이것입니다.
AI가 어떤 조건 조합을 제안하고, 시스템이 그 조건을 어떻게 검증하며, 결과를 바탕으로 다시 어떻게 고도화할 것인가?
Rule Refinement Loop: 설정 → 결과 검증 → 설정 고도화
이 패턴을 Rule Refinement Loop(룰 정제 루프)라고 부를 수 있습니다. Agent가 룰을 만들고, 시스템이 결과를 검증하고, Agent가 다시 룰을 고도화하는 순환입니다.
설정:
Agent가 자연어 목표를 룰 조건·세그먼트·자동화 노드로 변환
결과 검증:
룰 엔진이 대상자 수·예산·중복·수신 동의·제외 조건을 계산하고, 시뮬레이터가 예상 도달·비용·전환을 표시
설정 고도화:
Agent가 결과를 해석해 너무 넓은 조건은 좁히고, 너무 좁은 조건은 완화하며, 과거 성과를 반영해 조건을 개선
승인:
사람이 대상자 수·비용·리스크·예상 효과를 보고 승인
결정론적 실행:
실행 엔진이 outbox·멱등성·재시도·감사 로그로 발급/발송
이 루프에서 Agent는 두 번 등장합니다. 한 번은 자연어 목표를 실행 가능한 설정으로 바꾸는 단계, 다른 한 번은 시뮬레이션 결과를 해석해 조건을 고도화하는 단계입니다. 하지만 실제 쿠폰 발급과 메시지 발송은 Agent가 직접 하지 않습니다. 실행은 결정론적 시스템이 담당합니다.
Agent는 실행을 대신하는 것이 아니라, 실행 가능한 설정을 더 잘 만들게 한다.
Agent는 조건을 제안하고, 시스템이 결과를 검증하고, Agent가 다시 고도화합니다. 실제 실행은 결정론적 런타임이 담당합니다.
좋은 설계는 업무 시스템 안에 Agent를 넣는다
좋은 설계는 Agent가 업무 시스템 밖에서 모든 것을 지시하는 구조가 아니라, Agent가 업무 시스템 안에 들어와 특정 구간에서 판단과 설정 고도화를 돕는 구조입니다. 단계마다 Agent가 잘하는 일과 시스템이 잘하는 일이 분리됩니다.
저희 MetaFlyer Campaign의 구조도 이 방향과 잘 맞습니다. 캠페인은 설계 모델(campaign)과 실행 모델(campaignRun)을 분리하고, run이 시작되면 캠페인의 자동 흐름을 그 시점 상태로 불변 복제해 실행 중인 발송이 이후 편집의 영향을 받지 않게 합니다. 발송·후속 발송·게시·광고 동기화·정산 같은 부수효과는 즉석 처리하지 않고 트랜잭션 아웃박스(campaignOutbox)에 적재한 뒤 비동기·멱등·재시도(기본 5회, 초과 시 dead-letter) 방식으로 처리합니다. 받는 사람도 포함/제외 세그먼트 조합과 중복 제거로 산출되므로, Agent가 고객을 직접 확정하기보다 세그먼트 조건을 제안하고 시스템이 대상자를 산출하는 구조가 자연스럽습니다.
여기서 자동화는 Agent의 경쟁자가 아닙니다. "Agent와 Automation 중 무엇이 주인공인가?" 라는 질문은 빗나가 있습니다. 더 정확한 질문은 "Agent의 판단과 설정 제안을 실제 업무로 연결하려면 어떤 실행 골격이 필요한가?" 입니다. AI Insight Studio도 이 관점으로 설계됩니다. Agent Builder가 Agent의 목적·프롬프트·도구·KB/KG/분석 소스·MCP/A2A 연결·메모리·출력 계약·승인 정책을 구성하고, Automation Studio가 Agent 실행·조건 분기·스케줄·이벤트 트리거·메시지 발송·승인·후속 액션을 프로세스 흐름으로 엮으며, 실행 엔진이 타임아웃·재시도·dead-letter·승인 인박스·실행 로그·도구 감사·비용 지표까지 포함합니다.
Agent는 판단하고 설정을 제안한다.
업무 시스템은 상태와 권한을 관리한다.
자동화는 그 판단과 설정을 언제·어떤 조건에서·어떤 승인과 검증을 거쳐 실행할지 정한다.
이 세 가지가 분리되어야 프로덕션에서 안전하게 동작합니다.
결정론과 비결정론을 명확히 나눠라
AI Agent 설계에서 가장 중요한 선 긋기는 이것입니다. 비즈니스 트랜잭션은 결정론적이어야 하고, AI 판단은 확률적이어도 되지만 실행은 확률적이면 안 됩니다.
예산 한도·수신 동의·중복 발급 방지·발송 이력은 LLM이 판단하거나 기억할 일이 아닙니다. 이들은 코드·정책 엔진·상태 머신·DB 제약·이벤트 로그가 보장해야 합니다. 반대로 구매 가능성 판단, 추천 이유 생성, 메시지 초안, 캠페인 전략 제안, 조건 조합 고도화는 AI가 잘할 수 있는 영역입니다. 이 원칙을 지키지 않으면 Agent는 곧바로 운영 리스크가 됩니다.
조금 더 현실적으로 보면, '구매 가능성을 판단한다'는 일도 LLM이 고객 테이블을 직접 읽어 한 명씩 평가하는 것이 아닙니다. 대량 점수화는 예측 모델이 맡고, Agent는 그 결과를 해석하는 역할을 합니다. 즉 역할은 다음 세 계층으로 나뉩니다.
Agent는 목표를 룰로 번역하고, 예측 모델은 고객별 점수를 계산하며, 업무 시스템은 정책과 실행을 보장한다
사람의 통제권은 마지막에 붙이는 UX가 아니라 아키텍처다
많은 시스템이 "Human-in-the-loop" 를 UI 기능처럼 생각합니다. 승인 버튼 하나를 만들면 안전해진다고 여깁니다. 하지만 사람의 통제권은 버튼이 아니라 아키텍처입니다.
저희가 만든 ICE5 AI DevOps도 같은 원칙을 갖습니다. 이슈 접수, AI 명확도 점검, AI 코드 작업, 배포, AI 자동 테스트 검증, 운영 모니터링, 자동 개선을 하나의 흐름으로 묶되, "사람이 결정하고 AI가 실행한다" 는 원칙을 강조합니다. AI는 초안을 만들고 실행하지만, 저장·승인·전환은 사람이 결정합니다.
프로덕션 Agent도 마찬가지입니다. 사람이 모든 실행을 수동으로 처리할 필요는 없습니다. 하지만 고위험·고비용·고객에게 직접 영향을 주는 실행은 사람이 통제할 수 있어야 합니다. 이 통제권은 실행 전 시뮬레이션, 예상 대상자 수, 예상 비용, 위험 케이스 요약, Agent 판단 근거, 조건 변경 이력, 정책 위반 항목, 승인/반려/수정 요청, 승인 이력 감사 로그의 형태로 구현되어야 합니다.
여기서 한 가지 구분이 중요합니다. 미리보기에 들어가는 수치 중 일부는 결정적으로 계산되지만, 일부는 모델이 만든 예측값입니다. 둘을 섞어 보여 주면 사람은 '확정된 사실'과 '추정'을 구분하기 어려워집니다. 그래서 미리보기는 다음처럼 나눠 제시하는 편이 좋습니다.
결정적 미리보기 (시스템이 계산)
- 대상자 수
- 중복 제거 수
- 수신 동의 통과 수
- 최대 쿠폰 비용
- 예산 초과 여부
예측값 (모델이 추정)
- 예상 전환율
- 예상 증분 매출(uplift)
- 모델 신뢰구간과 주요 가정
사람은 AI의 모든 추론 과정을 읽을 필요는 없습니다. 하지만 어떤 조건으로, 어떤 고객에게, 어떤 비용으로, 어떤 부수효과가 발생하는지는 볼 수 있어야 합니다.
검증 피라미드: LLM 검증은 마지막 안전망이어야 한다
멀티 Agent 설계에서는 검증 Agent를 줄줄이 붙이는 패턴이 자주 등장합니다. Planner → Executor → Verifier → Reviewer → Policy Agent로 이어지는 식입니다. 안전해 보이지만, 1편에서 본 것처럼 가장 먼저 터지는 문제는 비용과 속도입니다. 고객 후보가 10만 명일 때 고객마다 판단 → 검증 → 예산 → 메시지 → 리뷰 Agent를 거치면 비용과 지연은 고객 수 × Agent 수 × 도구 호출 수 × 재시도 수만큼 늘어납니다. 반면 Rule Refinement Loop에서는 LLM 호출이 고객 수가 아니라 설정 반복 횟수에 비례합니다.
그래서 프로덕션에서 검증은 "또 다른 Agent에게 물어보는 것" 이 아닙니다. 검증 Agent는 모든 검증의 기본값이 아니라 마지막 안전망이어야 합니다. 가능한 한 결정적 시스템으로 처리하고, LLM 검증 Agent는 정말 애매하거나 고위험인 케이스에만 써야 합니다.
(최하단) 결정론적 검증 / 실행:
권한, 예산, 수신 동의, 중복 발급, 출력 스키마, 멱등성, 요청 제한, 감사 로그. 반드시 코드와 정책이 담당.
(아래) 경량 모델 / 스코어링:
구매 가능성 점수, 리스크 분류, 우선순위 산정, 메시지 품질 분류
(위) Agent 보조 설정 고도화:
조건 조합 제안, 세그먼트 조정, A/B 실험안 생성, 결과 해석
(최상단) LLM 검증 Agent:
고위험 예외, 근거 충돌, 정책 해석, 승인 전 리스크 요약
예산 한도도, 수신 동의도, 중복 발급 방지도 LLM이 해석하거나 기억할 일이 아닙니다. 출력 형식은 JSON Schema나 열거형 검증으로 확인할 수 있습니다. Agent에게 맡길 일은 위쪽 — 정말 추론이 필요한 영역에 있어야 합니다.
검증 Agent는 마지막 안전망이어야지, 첫 번째 검증 수단이 되어서는 안 됩니다.
결정론적 검증이 바닥을 받치고, LLM 검증 Agent는 고위험·예외에만 쓰는 마지막 안전망이어야 합니다.
비용 인지형 오케스트레이션: Agent를 얼마나 호출할지 설계하라
프로덕션 Agent 설계에서는 비용도 아키텍처의 일부입니다. Agent가 얼마나 똑똑한가만 볼 것이 아니라, 얼마나 자주 호출되는지, 어떤 모델을 쓰는지, 몇 번 재시도하는지, 하위 Agent를 몇 개까지 부르는지, 실행 전 예상 비용을 알 수 있는지까지 설계해야 합니다. 최대 깊이·최대 팬아웃·최대 도구 호출 수·토큰 예산·비용 미리보기·모델 라우팅·조기 종료·샘플링 검증·사람 승인 게이트 같은 통제 장치가 그래서 필요합니다.
Gartner가 말했듯 루틴·고빈도 작업은 작은 모델이나 도메인 특화 모델로 보내고, 비싼 frontier 추론은 복잡하고 고부가가치인 작업에만 제한해야 합니다[2]. 이 원칙을 쿠폰 발행에 적용하면 다음과 같습니다.
📝 [비용 인지형 실행 파이프라인]
1. 전체 고객 100만 명
↓
2. 결정적 필터로 후보 5만 명 압축
(수신 동의 · 최근 구매 제외 · 쿠폰 중복 제외 · 예산 범위)
↓
3. 경량 스코어링으로 상위 5천 명 선정
(방문 빈도 · 장바구니 이력 · 가격 민감도 · 과거 반응)
↓
4. AI Agent는 조건 조합과 애매한 케이스를 해석
(세그먼트 조건 개선 · 쿠폰 등급 조정 · 메시지 초안)
↓
5. LLM 검증 Agent는 고위험·충돌 케이스만 검토
↓
6. 결정적 정책 게이트 통과 후 실행
Agent가 모든 고객을 다 판단하지도, 모든 판단을 다 검증하지도 않습니다. 업무 시스템이 먼저 대상을 줄이고 결정적 제약을 적용하고, Agent는 추론 가치가 높은 구간에만 집중합니다. 이것이 비용 인지형 오케스트레이션입니다.
프로덕션 Agent 구현 체크리스트
실제 설계에 들어가기 전, 아래 질문을 확인해 보시길 권합니다.
- 범위 — Agent가 할 수 있는 일과 절대 하면 안 되는 일이 정의되어 있는가?
- 데이터 경계 — 접근 가능한 고객·캠페인·사이트·조직 범위가 제한되는가?
- 결정적 사전 필터 — 수신 동의·제외 고객·중복 발급·예산 한도가 룰로 먼저 걸러지는가?
- 구조화된 출력 — Agent 판단 결과가 스키마로 검증되는가?
- 시뮬레이션 — 조건 적용 결과의 대상자 수·비용·정책 위반 여부를 사전에 계산하는가?
- 예산 가드 — 총 예산·1인 한도·캠페인 한도가 시스템 레벨에서 강제되는가?
- 사람 승인 — 고위험 실행 전 승인 게이트가 있는가?
- 멱등성 — 같은 작업이 두 번 실행되어도 쿠폰이 중복 발급되지 않는가?
- 추적·감사 — 왜 이 조건이 선택됐고 어떤 근거로 실행됐는지 추적 가능한가?
- 비용 통제 — 토큰 예산·모델 라우팅·팬아웃 제한이 있는가?
- 공정성 — 민감 속성이나 그 대리 변수가 쿠폰 차등 지급 조건에 부당하게 사용되지 않는가?
이 체크리스트의 핵심은 하나입니다. AI가 잘못 판단해도 시스템이 바로 실행하지 않게, AI가 맞게 판단해도 시스템이 검증 없이 실행하지 않게 만드는 것입니다.
마치며: 좋은 Agent는 많이 실행하는 Agent가 아니다
프로덕션 AI Agent의 핵심은 Agent에게 더 많은 권한을 주는 것이 아닙니다. 오히려 반대입니다. 업무 시스템이 결정적으로 처리해야 할 것과, AI Agent가 도와야 할 것을 분리하는 것입니다.
예산·권한·수신 동의·중복 발급·멱등성·감사 로그는 LLM이 아니라 시스템이 보장해야 합니다. Agent는 룰로 표현하기 어려운 구매 의도 해석, 조건 조합 제안, 메시지 초안 생성, 실행 결과 해석에 집중해야 합니다. 특히 기존 룰 엔진이나 로우코드/노코드 자동화가 있다면, Agent를 실행자로 두기보다 설정 Copilot으로 두는 편이 더 실용적입니다.
좋은 프로덕션 Agent는 가장 많은 Agent가 협업하는 시스템이 아닙니다. 좋은 프로덕션 Agent는 다음을 잘 구분하는 시스템입니다 — LLM이 필요한 판단과 필요 없는 검증, AI가 제안할 설정과 시스템이 강제할 제약, Agent가 고도화할 조건과 룰 엔진이 결정적으로 실행할 조건, 사람이 승인할 일과 자동으로 실행할 일.
AI Agent는 업무 시스템을 대체하지 않습니다. 업무 시스템을 더 똑똑하게 만듭니다. 다시 말해, 프로덕션 AI Agent의 목표는 "무법자 AI" 를 만드는 것이 아니라, 업무 시스템 안에서 안전하게 일하는 지능형 실행 컴포넌트를 만드는 것입니다.
프로덕션에서 Agent의 가장 실용적인 역할은 모든 실행을 대신하는 것이 아니라, 룰·조건·자동화 설정을 제안하고 검증 결과를 바탕으로 계속 고도화하는 것입니다.
참고자료
[1] Multiple Treatment Modeling for Target Marketing Campaigns — Information Systems Frontiers, Springer (https://link.springer.com/article/10.1007/s10796-022-10283-4)
[2] Gartner — By 2030, Inference on a 1-Trillion-Parameter LLM Will Cost GenAI Providers Over 90% Less Than in 2025, 2026.03.25 (https://www.gartner.com/en/newsroom/press-releases/2026-03-25-gartner-predicts-that-by-2030-performing-inference-on-an-llm-with-1-trillion-parameters-will-cost-genai-providers-over-90-percent-less-than-in-2025)
