마케팅 에이전트 아키텍처

SaaS 도구 vs AI 에이전트 비교, 오케스트레이션 패턴, MCP 서버 연동 아키텍처

왜 에이전트인가 — SaaS vs 에이전트

기존 마케팅 SaaS(HubSpot, Mailchimp, SEMrush 등)는 도구별로 분리된 워크플로우를 제공합니다. AI 에이전트는 이 워크플로우를 하나의 오케스트레이션 레이어로 통합해 의사결정 속도를 높입니다.

기준	SaaS 도구	AI 에이전트
데이터 흐름	도구 간 수동 연동 (Zapier 등)	에이전트가 직접 API 호출·파싱
의사결정	대시보드 확인 → 사람이 판단	에이전트가 분석 → 추천 → 사람이 승인
확장성	기능별 구독료 누적	프롬프트 + 도구 정의로 확장
커스터마이징	설정 범위 내 제한적	프롬프트 수정으로 무한 커스텀
학습 곡선	도구별 UI 학습 필요	자연어 인터페이스

하이브리드 접근

SaaS를 완전히 대체하는 것이 아니라, SaaS의 데이터를 에이전트가 읽고 분석하는 하이브리드 모델이 현실적입니다. 예: Google Analytics 데이터 → 에이전트 분석 → Slack 리포트 자동 발송

🇰🇷 한국 시장

국내에서는 네이버 검색광고, 카카오모먼트, 당근마켓 광고 등 로컬 플랫폼 연동이 중요합니다. 글로벌 SaaS(HubSpot, SEMrush 등)와 함께 네이버 검색 API, 카카오 비즈니스 API 등 한국 플랫폼 MCP 서버를 병행 구성하면 더 정확한 국내 시장 분석이 가능합니다.

마케팅 오케스트레이터 패턴

마케팅 에이전트 시스템은 하나의 오케스트레이터가 하위 에이전트들을 조율하는 구조입니다.

오케스트레이션 패턴 3가지

1. 직렬 패턴 (Sequential)

시장 분석 → 퍼소나 생성 → 키워드 리서치 → 콘텐츠 초안

이전 단계의 출력이 다음 단계의 입력이 되는 순차적 파이프라인입니다. 장점: 데이터 의존성이 명확할 때 안정적. 단점: 전체 실행 시간이 길어짐.

2. 병렬 패턴 (Fan-out / Fan-in)

오케스트레이터 → [경쟁사 분석 | 키워드 분석 | 소셜 리스닝] → 통합 리포트

독립적인 분석 작업을 동시에 실행하고 결과를 합칩니다. 장점: 실행 시간 단축. 단점: 결과 통합 로직이 복잡할 수 있음.

초안 생성 → 평가 → 수정 → 평가 → ... → 최종 승인

품질 기준을 충족할 때까지 반복합니다. 광고 카피, 이메일 제목 등에 적합합니다. 장점: 결과물 품질이 높음. 단점: 토큰 소비가 많아질 수 있음.

위 JSON에 등장하는 @anthropic/mcp-ga4, @anthropic/mcp-search-console 등의 패키지명은 설명을 위한 예시입니다. 실제 구현 시에는 MCP 레지스트리(https://github.com/modelcontextprotocol/servers)에서 공식·커뮤니티 서버 목록을 확인하고, 사용하려는 패키지의 정확한 이름·버전·라이선스를 검증하세요.

에이전트 도구 정의 패턴

각 하위 에이전트는 자신만의 도구(Tool) 세트를 가집니다.

// marketing-orchestrator 도구 예시
const tools = [
  {
    name: 'analyze_market',
    description: '시장 규모와 성장률을 분석합니다',
    parameters: {
      industry: 'string',
      region: 'string',
      timeframe: 'string',
    },
  },
  {
    name: 'generate_persona',
    description: '타겟 고객 퍼소나를 생성합니다',
    parameters: {
      segment: 'string',
      data_source: 'string',
    },
  },
  {
    name: 'audit_seo',
    description: '웹사이트 SEO 감사를 실행합니다',
    parameters: {
      url: 'string',
      depth: 'number',
    },
  },
]

에이전트 운영 원칙

1. 사람-in-the-loop

에이전트가 분석하고 추천하되, 최종 의사결정은 사람이 합니다.

자동화 수준	설명	예시
Level 0	사람이 직접 실행	수동 키워드 리서치
Level 1	에이전트가 초안 → 사람이 검토	블로그 초안 생성
Level 2	에이전트가 실행 → 사람이 승인	이메일 시퀀스 발송
Level 3	에이전트가 자율 실행 → 사후 리포트	A/B 테스트 자동 종료

2. 비용 모니터링

\text{월간 에이전트 비용} = \sum(\text{에이전트별 토큰 사용량} \times \text{단가})

\text{ROI} = \frac{\text{에이전트로 절약한 인건비} + \text{매출 증가분}}{\text{에이전트 운영 비용}}

3. 프롬프트 버전 관리

마케팅 에이전트의 프롬프트는 코드와 동일하게 Git으로 버전 관리합니다. 프롬프트 변경 시 A/B 테스트를 통해 성과를 비교합니다.

디렉토리 구조 예시

prompts/
├── market-analysis/
│   ├── v1.0-market-sizing.md          # 초기 버전
│   ├── v1.1-market-sizing.md          # 출력 형식 개선
│   └── v2.0-market-sizing.md          # TAM/SAM/SOM 분리 분석 추가
├── persona/
│   ├── v1.0-persona-simulator.md
│   └── v1.1-persona-simulator.md      # JTBD 컨텍스트 추가
├── content/
│   └── v1.0-blog-draft.md
└── CHANGELOG.md                        # 전체 변경 이력

Git 기반 관리 실천 사항

브랜치 전략: 프롬프트 변경도 feature 브랜치에서 작업 후 PR을 통해 머지합니다.
변경 이력 기록: CHANGELOG.md에 날짜, 변경 사항, 변경 사유, A/B 테스트 결과를 기록합니다.
태그 활용: 주요 버전(성과가 검증된 프롬프트)은 Git 태그로 표시하여 롤백이 용이하도록 합니다.

<!-- CHANGELOG.md 예시 -->

## 2026-03-10 — market-sizing v2.0

- 변경: TAM/SAM/SOM을 별도 단계로 분리 분석
- 사유: 단일 프롬프트에서 SOM 추정 정확도가 낮았음
- A/B 결과: 분석 정확도 +18%, 토큰 사용량 +12%

4. 에이전트 실패 처리 (Error Handling)

에이전트는 외부 API 호출, 대규모 데이터 처리, 비결정적 LLM 출력 등으로 인해 실패할 수 있습니다. 안정적인 운영을 위해 체계적인 실패 처리 전략이 필수입니다.

폴백 전략 (Graceful Degradation)

에이전트가 실패할 경우 전체 파이프라인이 중단되지 않도록 단계별 폴백을 설계합니다. 예를 들어 실시간 경쟁사 크롤링이 실패하면 최근 캐시 데이터를 활용하고, 캐시도 없으면 수동 입력을 요청하는 식입니다.

1순위: 실시간 데이터 수집 시도
2순위: 최근 캐시/스냅샷 활용 (24시간 이내)
3순위: 기본값(baseline) 사용 + 경고 플래그
4순위: 해당 단계 건너뛰기 + 사람에게 에스컬레이션

재시도와 지수 백오프 (Exponential Backoff)

외부 API 호출 실패 시 즉시 재시도하면 rate limit에 걸리거나 비용이 급증할 수 있습니다. 지수 백오프 방식으로 재시도 간격을 점진적으로 늘립니다(예: 1초 → 2초 → 4초 → 8초). 최대 재시도 횟수(보통 3~5회)를 설정하여 무한 루프를 방지합니다.

사람 에스컬레이션 트리거

다음 상황에서는 에이전트가 자동으로 담당자에게 알림을 보내고 작업을 중단합니다:

신뢰도 미달: LLM 출력의 자체 평가 점수가 임계값(예: 60점) 미만인 경우
데이터 이상: 입력 데이터가 예상 범위를 크게 벗어난 경우 (예: 시장 규모가 음수)
반복 실패: 동일 작업이 최대 재시도 횟수를 초과한 경우
승인 필요: Level 2 이상의 자동화 작업에서 최종 실행 전

비용 서킷 브레이커

에이전트가 무한 루프에 빠지거나 예상치 못한 대량 호출을 하면 비용이 급증할 수 있습니다. 서킷 브레이커를 설정하여 일정 임계값을 초과하면 자동으로 실행을 중단합니다.

임계값 유형	예시 설정	동작
단일 실행	토큰 50,000개 초과	해당 에이전트 중단
시간당 비용	$5 초과	전체 오케스트레이터 일시 중지
일일 비용	$50 초과	당일 자동 실행 전면 중단
월간 예산	설정 예산의 80% 도달	경고 알림 발송

다음 단계

에이전트 아키텍처를 설계했으니, 다음으로 시장 분석과 경쟁 인텔리전스 챕터에서 첫 번째 하위 에이전트를 구축하고 경쟁 인텔리전스를 자동화하는 방법을 다룹니다.

왜 에이전트인가 — SaaS vs 에이전트

기준	SaaS 도구	AI 에이전트
데이터 흐름	도구 간 수동 연동 (Zapier 등)	에이전트가 직접 API 호출·파싱
의사결정	대시보드 확인 → 사람이 판단	에이전트가 분석 → 추천 → 사람이 승인
확장성	기능별 구독료 누적	프롬프트 + 도구 정의로 확장
커스터마이징	설정 범위 내 제한적	프롬프트 수정으로 무한 커스텀
학습 곡선	도구별 UI 학습 필요	자연어 인터페이스

하이브리드 접근

🇰🇷 한국 시장

시장 분석 → 퍼소나 생성 → 키워드 리서치 → 콘텐츠 초안

이전 단계의 출력이 다음 단계의 입력이 되는 순차적 파이프라인입니다. 장점: 데이터 의존성이 명확할 때 안정적. 단점: 전체 실행 시간이 길어짐.

2. 병렬 패턴 (Fan-out / Fan-in)

오케스트레이터 → [경쟁사 분석 | 키워드 분석 | 소셜 리스닝] → 통합 리포트

독립적인 분석 작업을 동시에 실행하고 결과를 합칩니다. 장점: 실행 시간 단축. 단점: 결과 통합 로직이 복잡할 수 있음.

초안 생성 → 평가 → 수정 → 평가 → ... → 최종 승인

품질 기준을 충족할 때까지 반복합니다. 광고 카피, 이메일 제목 등에 적합합니다. 장점: 결과물 품질이 높음. 단점: 토큰 소비가 많아질 수 있음.

MCP 서버 연동 아키텍처

Model Context Protocol(MCP)을 활용하면 에이전트가 외부 데이터 소스에 표준화된 인터페이스로 접근할 수 있습니다.

MCP 서버 구성 예시

{
  "mcpServers": {
    "google-analytics": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-ga4"],
      "env": {
        "GA4_PROPERTY_ID": "properties/123456789",
        "GOOGLE_APPLICATION_CREDENTIALS": "./credentials.json"
      }
    },
    "search-console": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-search-console"],
      "env": {
        "SITE_URL": "https://example.com"
      }
    }
  }
}

⚖️ 법률·컴플라이언스

에이전트 도구 정의 패턴

각 하위 에이전트는 자신만의 도구(Tool) 세트를 가집니다.

// marketing-orchestrator 도구 예시
const tools = [
  {
    name: 'analyze_market',
    description: '시장 규모와 성장률을 분석합니다',
    parameters: {
      industry: 'string',
      region: 'string',
      timeframe: 'string',
    },
  },
  {
    name: 'generate_persona',
    description: '타겟 고객 퍼소나를 생성합니다',
    parameters: {
      segment: 'string',
      data_source: 'string',
    },
  },
  {
    name: 'audit_seo',
    description: '웹사이트 SEO 감사를 실행합니다',
    parameters: {
      url: 'string',
      depth: 'number',
    },
  },
]

에이전트 운영 원칙

1. 사람-in-the-loop

에이전트가 분석하고 추천하되, 최종 의사결정은 사람이 합니다.

자동화 수준	설명	예시
Level 0	사람이 직접 실행	수동 키워드 리서치
Level 1	에이전트가 초안 → 사람이 검토	블로그 초안 생성
Level 2	에이전트가 실행 → 사람이 승인	이메일 시퀀스 발송
Level 3	에이전트가 자율 실행 → 사후 리포트	A/B 테스트 자동 종료

2. 비용 모니터링

\text{월간 에이전트 비용} = \sum(\text{에이전트별 토큰 사용량} \times \text{단가})

\text{ROI} = \frac{\text{에이전트로 절약한 인건비} + \text{매출 증가분}}{\text{에이전트 운영 비용}}

3. 프롬프트 버전 관리

마케팅 에이전트의 프롬프트는 코드와 동일하게 Git으로 버전 관리합니다. 프롬프트 변경 시 A/B 테스트를 통해 성과를 비교합니다.

디렉토리 구조 예시

prompts/
├── market-analysis/
│   ├── v1.0-market-sizing.md          # 초기 버전
│   ├── v1.1-market-sizing.md          # 출력 형식 개선
│   └── v2.0-market-sizing.md          # TAM/SAM/SOM 분리 분석 추가
├── persona/
│   ├── v1.0-persona-simulator.md
│   └── v1.1-persona-simulator.md      # JTBD 컨텍스트 추가
├── content/
│   └── v1.0-blog-draft.md
└── CHANGELOG.md                        # 전체 변경 이력

Git 기반 관리 실천 사항

브랜치 전략: 프롬프트 변경도 feature 브랜치에서 작업 후 PR을 통해 머지합니다.
변경 이력 기록: CHANGELOG.md에 날짜, 변경 사항, 변경 사유, A/B 테스트 결과를 기록합니다.
태그 활용: 주요 버전(성과가 검증된 프롬프트)은 Git 태그로 표시하여 롤백이 용이하도록 합니다.

<!-- CHANGELOG.md 예시 -->

## 2026-03-10 — market-sizing v2.0

- 변경: TAM/SAM/SOM을 별도 단계로 분리 분석
- 사유: 단일 프롬프트에서 SOM 추정 정확도가 낮았음
- A/B 결과: 분석 정확도 +18%, 토큰 사용량 +12%

4. 에이전트 실패 처리 (Error Handling)

폴백 전략 (Graceful Degradation)

1순위: 실시간 데이터 수집 시도
2순위: 최근 캐시/스냅샷 활용 (24시간 이내)
3순위: 기본값(baseline) 사용 + 경고 플래그
4순위: 해당 단계 건너뛰기 + 사람에게 에스컬레이션

재시도와 지수 백오프 (Exponential Backoff)

사람 에스컬레이션 트리거

다음 상황에서는 에이전트가 자동으로 담당자에게 알림을 보내고 작업을 중단합니다:

신뢰도 미달: LLM 출력의 자체 평가 점수가 임계값(예: 60점) 미만인 경우
데이터 이상: 입력 데이터가 예상 범위를 크게 벗어난 경우 (예: 시장 규모가 음수)
반복 실패: 동일 작업이 최대 재시도 횟수를 초과한 경우
승인 필요: Level 2 이상의 자동화 작업에서 최종 실행 전

비용 서킷 브레이커

임계값 유형	예시 설정	동작
단일 실행	토큰 50,000개 초과	해당 에이전트 중단
시간당 비용	$5 초과	전체 오케스트레이터 일시 중지
일일 비용	$50 초과	당일 자동 실행 전면 중단
월간 예산	설정 예산의 80% 도달	경고 알림 발송

마케팅 에이전트 아키텍처

목차

마케팅 에이전트 아키텍처

목차