마케팅 자동화를 하나의 거대한 프롬프트로 만들면 처음에는 빨리 되지만 금방 무너집니다. 한 군데를 고치면 다른 데가 흔들리고, 어디서 틀렸는지 추적이 안 됩니다. 이 글은 실제 의료 마케팅 시스템에서 멀티에이전트 마케팅 자동화를 어떻게 여러 에이전트로 나누고, 계층을 어디서 갈랐는지 정리한 것입니다.
멀티에이전트 마케팅 자동화란 어떻게 나누는가
멀티에이전트 마케팅 자동화란, 콘텐츠 파이프라인을 역할이 분명한 여러 에이전트로 쪼개고 각자 자기 일만 하게 하는 것입니다. 이 시스템은 여섯 역할로 나눴습니다.
- Planner(기획): 과목 비율, 최근 성과, 주간 트렌드를 결합해 주제를 자동 기획.
- Copy(카피): 블로그·쇼츠·인스타·커뮤니티 4채널 문안을 한 번에 생성.
- Law(검수): 카피의 의료광고법 위반을 룰베이스와 다른 모델로 이중 검수.
- Cards/Video(디자인·영상): 카드뉴스 자동 디자인, 롱폼의 숏폼 자동 편집.
- Analyst(분석): 성과를 통계로 판정해 프롬프트를 갱신.
각 에이전트는 구조화된 데이터로만 다음 단계와 대화합니다. 그래서 한 역할을 고쳐도 다른 역할이 영향을 받지 않고, 어느 단계에서 문제가 났는지 로그로 바로 짚힙니다.
Dify와 Make를 왜 분리하나
계층도 나눴습니다. 이 시스템은 오케스트레이션(Dify)과 SaaS 글루(Make.com), 비즈니스 로직(Python), 서빙(Fly.io)을 분리합니다.
- Dify: LLM 워크플로우(기획·카피·검수·분석)와 브랜드 톤 지식(RAG)을 담당. "무엇을 만들지"를 맡습니다.
- Make.com: 시트 트리거, 주간 잡, KPI 수집 같은 배선을 담당. "언제·무엇을 이어붙일지"를 맡습니다.
- Python 패키지: 시트 읽기·쓰기, 룰베이스 검수, 카드/영상 렌더, 슬랙 봇, 복원력을 소유. "실제로 무엇을 실행할지"를 맡습니다.
- Fly.io: 상시 워커를 유휴 시 0대로 줄이는 방식으로 저비용 무인 서빙.
이렇게 나누면 각 도구가 가장 잘하는 일만 맡습니다. LLM 오케스트레이션은 Dify가, 반복 배선은 Make가, 검증이 필요한 데이터 조작은 Python이 담당합니다.
신뢰 경계: LLM에 데이터 권한을 주지 않는다
가장 중요한 설계는 신뢰 경계입니다. 주제 기획은 Dify의 LLM이 하지만, 그 계층에는 구글 시트 자격 증명을 주지 않습니다. LLM은 무엇을 만들지 순수한 JSON으로 제안할 뿐이고, 그 결과를 시트에 적재할지 말지는 Python 계층만 결정합니다.
이 경계가 왜 중요하냐면, LLM은 프롬프트 주입에 취약하기 때문입니다. 만약 LLM이 시트를 직접 쓸 수 있다면, 조작된 입력 한 줄이 통제실 데이터를 오염시킬 수 있습니다. 데이터 조작 권한을 검증된 코드에만 두면, LLM이 무엇을 제안하든 최종 적재는 규칙을 통과한 값만 들어갑니다. 실제로 입력을 받을 때 주제는 앞 200자, 트렌드 키워드는 앞 20개로 잘라 주입 표면을 줄입니다.
통제실은 구글 시트 9종
전 파이프라인의 상태는 구글 시트 9종(INPUT·STATUS·OUTPUT·LAW_LOG·COST·TREND·KPI·PROMPT_LOG·CONFIG)에 모입니다. 여기에 서빙링크·영상 탭이 더해져, 어떤 주제가 어디까지 갔고 무엇이 막혔는지 한곳에서 보입니다.
시트를 통제실로 삼은 것은 의도된 선택입니다. 별도 관리 화면을 만들지 않아도 원장과 운영자가 이미 익숙한 도구로 전 과정을 들여다보고, 필요하면 값을 직접 고칠 수 있기 때문입니다. 다만 시트에 수식을 넣을 수 있다는 점 때문에 외부 텍스트가 수식으로 해석되는 위험이 있어, 사용자·모델이 만든 텍스트가 등호나 기호로 시작하면 앞에 따옴표를 붙여 수식 주입을 막습니다. 통제실이 편리하면서도 안전하도록, 데이터가 시트에 적히는 마지막 순간까지 검증을 놓지 않은 것입니다. 브랜드 톤을 학습해 카피 품질을 유지하는 방법은 브랜드 톤을 학습시키는 마케팅 RAG 지식창고에서, 사람이 개입하는 승인 단계는 슬랙 승인 한 번으로 여는 4채널 무인 발행 게이트에서 다룹니다. 전체 사례는 의료 마케팅 자동화 OS 사례에서 볼 수 있습니다.
자주 묻는 질문
마케팅 자동화를 왜 멀티에이전트로 나누나요?
한 프롬프트에 모든 일을 몰아넣으면 한 군데를 고칠 때 다른 데가 흔들리고 디버깅이 어렵습니다. 기획·카피·검수·디자인·영상·분석을 역할별 에이전트로 나누면 각자 자기 일만 하고 구조화된 데이터로 넘겨, 수정과 추적이 쉬워집니다.
Dify와 Make를 왜 따로 쓰나요?
Dify는 LLM 워크플로우와 지식 검색을 맡고, Make는 시트 트리거·주간 잡·KPI 수집 같은 반복 배선을 맡습니다. 도구마다 가장 잘하는 일이 달라, LLM 오케스트레이션과 SaaS 글루를 분리하면 각 계층을 독립적으로 고칠 수 있습니다.
신뢰 경계를 둔다는 게 무슨 뜻인가요?
LLM에 데이터 조작 권한을 주지 않는다는 뜻입니다. 이 시스템은 LLM이 무엇을 만들지 제안만 하게 하고, 시트에 실제로 적재하는 일은 검증된 Python 코드만 하도록 나눴습니다. 프롬프트 주입이 통제실 데이터를 오염시키지 못하게 하는 안전장치입니다.
이 아키텍처는 의료 분야에만 쓸 수 있나요?
아닙니다. 역할 분리와 신뢰 경계, 검수 관문이라는 뼈대는 규제가 있거나 브랜드 일관성이 중요한 어떤 콘텐츠 도메인에도 적용됩니다. 의료에서는 그 검수 관문이 의료광고법 검수가 될 뿐입니다.