블로그로 돌아가기
외주 가이드2026년 5월 5일171

AI 개발팀이 마케팅 자동화 외주 대신 직접 만든 결과: 7채널 1.5개월 실측

9명 AI 개발팀이 외주 대신 직접 구축한 AI 마케팅 자동화 1.5개월 실측 보고서. 월 1,800만 원 외주 견적 vs 330만 원 자체 구축 비용 구조, 7채널 자동화 파이프라인 흐름, 멀티채널 ROI 비선형 효과, 외주·자체 구축 결정 매트릭스를 정리해 공개합니다.

작은 AI 개발팀이 외주를 쓰지 않고 직접 AI 마케팅 자동화 파이프라인을 굴린 지 1.5개월이 지났습니다. 우리는 SEO·콘텐츠 마케팅을 전혀 모르던 9명짜리 팀이었고, 첫 한 달은 의미 있는 숫자가 거의 나오지 않았습니다. 그런데 7개 이상의 채널에서 자동화 파이프라인이 자리를 잡기 시작하자 백링크가 누적되고, GA 그래프가 우상향 구간을 만들고, 메인 사이트가 아닌 여러 채널에서 동시에 문의가 들어오기 시작했습니다. 같은 결과를 외주로 만들려고 했다면 비용은 어땠을까, 그리고 어떤 회사는 자체 구축이 맞고 어떤 회사는 외주가 합리적일까 — 발주 담당자가 의사결정을 내릴 때 필요한 AI 마케팅 자동화 사례를 실측 숫자 그대로 공유합니다.

!엔지니어 팀의 AI 마케팅 자동화 1.5개월 실측 그래프

마케팅 자동화 외주는 왜 AI 개발팀에 맞지 않는가

국내 마케팅 자동화 외주 시장은 크게 세 묶음입니다. (1) 퍼포먼스 광고 대행 — 월 200~500만 원에 광고비 별도, (2) 콘텐츠 마케팅 대행 — 블로그 8~12편/월에 월 300~700만 원, (3) 풀스택 마케팅 자동화 컨설팅 — 초기 셋업 1,500~3,000만 원 + 월 500만 원 운영비. 우리가 처음 받았던 견적의 평균이 그랬습니다.

문제는 AI 개발팀의 콘텐츠는 본질적으로 외주가 어렵다는 점이었습니다. Playwright MCP를 4주 운영하며 토큰을 어떻게 줄였는지, RAG 챗봇을 클라이언트 환경에 어떻게 격리해 배포했는지 같은 글은 실제 코드를 짠 사람이 아니면 쓸 수 없습니다. 외주 카피라이터가 인터뷰로 받아쓰는 순간 글은 표면적인 트렌드 요약이 되고, 검색 의도(intent)는 "도구 소개"로 굳어집니다. 그러면 동일 키워드를 노리는 미디엄 글 수백 개와 경쟁하게 되고, 백링크가 붙지 않습니다.

또 하나의 변수는 채널 다양성이었습니다. 외주 한 곳이 7개 채널을 동시에 운영하지 않습니다. treesoop.com 본진 외에 LinkedIn(2개 계정), Brunch, Medium, Velog, Hashnode, Dev.to까지 관리하려면 사실상 채널별 외주를 따로 붙여야 하고, 그 순간 단가는 합산이 아니라 곱셈으로 늘어납니다. 채널마다 등록 절차, 톤, 인증 방식이 모두 달라서 한 곳을 추가할 때마다 외주 계약을 다시 짜야 하는 구조이기도 합니다. 자동화로 풀면 새 채널 추가 비용은 코드 한 모듈 작성 시간으로 끝나지만, 외주에서는 매번 신규 SOW가 됩니다.

외주 견적 vs 자체 구축: 1.5개월 실측 비용 비교

같은 1.5개월의 산출물을 두 시나리오로 환산해봤습니다.

항목외주 시나리오(월)자체 구축(월)
콘텐츠 제작 (8편/월, 7채널 배포)약 600만 원LLM API + 인프라 약 80만 원
자동화 셋업 (초기 1회)약 2,000만 원 (분할 시 월 333만 원)엔지니어 0.3 FTE 분 약 250만 원
채널 운영 (LinkedIn, Brunch, Medium 등)채널당 100~200만 원 × 7 ≈ 900만 원자동화 스크립트로 인건 거의 0
합계약 1,833만 원/월약 330만 원/월

자체 구축 쪽 인건비는 풀타임이 아니라 0.3 FTE — 즉, 전담이 아니라 시니어 엔지니어 한 명이 하루 2시간씩 쓰는 분량입니다. 우리는 이 시간조차 자동화 코드를 다듬는 데 들어가지, 글을 직접 쓰는 데는 거의 들어가지 않습니다. 1.5개월간 8.4편을 공개했는데, 그중 사람이 1차 드래프트부터 쓴 글은 0편입니다. 모두 LinkedIn 원본 회고를 LLM으로 확장해 검수만 사람이 보는 흐름이었습니다.

7채널 자동화 파이프라인은 어떻게 동작하는가

핵심 구조는 단순합니다. 매일 LinkedIn 활동 피드를 스크랩 → 가장 인사이트가 강한 포스트를 토픽으로 선정 → treesoop.com 원본 마크다운 생성 → 채널별 포맷으로 변환 → API/headless browser로 발행. 의사결정만 단계마다 LLM이 맡습니다.

```python

# distribute/orchestrator/steps.py (요지)

def daily_pipeline(date: str) -> RunStatus:

source = scrape_linkedin_activity(account="dion-nam")

decision = decide_publish_or_skip(source, recent_history)

if decision.action == "SKIP":

return RunStatus.skipped(decision.reason)

topic = select_topic(source, decision.pillar)

draft = draft_treesoop_post(topic, source, voice="founder")

publish_treesoop(draft) # canonical

publish_medium(draft, lang="ko") # 크로스포스트

publish_velog(draft)

publish_hashnode(draft)

publish_brunch(rewrite_for_brunch(draft)) # 독립 톤

notify_linkedin_article_queue(draft) # 금요일 수동

return RunStatus.success()

```

decision 단계에서 가장 중요한 규칙은 자기복제 방지입니다. 최근 7일 내 동일 메인 키워드를 발행했으면 SKIP, 동일 pillar(예: 외주 가이드)를 연속 사용하지 않도록 교대 — 이런 규칙을 DSL이 아니라 평범한 파이썬 함수로 박아둡니다. Google Search Console 데이터를 매주 Search Analytics API로 끌어와 클릭이 붙는 키워드와 안 붙는 키워드를 갈라내고, 다음 주 토픽 선정에 가중치로 넣습니다.

사람이 자주 손대는 부분은 두 군데뿐입니다. (1) 톤이 너무 "AI 같다"고 느껴질 때 첫 문단 1~2줄을 손으로 다시 쓰기, (2) 코드 블록의 사실관계 체크. 나머지는 모두 자동화입니다. 매일 아침 launchd가 파이프라인을 깨우면 약 8~12분 안에 7개 채널 발행이 끝나고, 실패한 단계만 Slack으로 알림이 옵니다. 누적 실패율은 2주 차 이후 5% 아래로 떨어졌고, 그중 절반은 채널 측 rate limit이라 재시도로 자동 복구됩니다. 외주 계약에서 흔한 "월간 발행 계획 회의"가 0회로 줄어든 것도 큰 변화였습니다.

한 채널 집중 vs 멀티채널 동시 운영, ROI 차이는?

흔한 조언은 "초반엔 한 채널에 집중해라"입니다. 자원이 한정된 팀에는 맞는 말이지만, AI 개발팀에는 한 가지 변수가 다릅니다 — 자동화로 인한 한계 비용이 거의 0에 수렴한다는 점.

1.5개월간 채널별 인바운드를 보면, 단일 채널만 운영했을 때보다 7채널 동시 운영의 효과가 합산이 아니라 비선형으로 컸습니다. treesoop.com 메인은 검색 노출이 늦게 붙는 대신 백링크가 도메인 권위로 누적됐고, LinkedIn은 1~2주 단위로 짧은 인바운드를 끊임없이 가져왔습니다. Brunch는 비개발자 의사결정자(C레벨, 마케팅 디렉터)에게 닿았고, Medium·Hashnode·Velog는 개발자 채용 풀에 자연스럽게 노출됐습니다. AI 개발팀 마케팅 자동화 ROI의 핵심은 "한 채널의 1배"가 아니라 "7채널의 0.3배 × 7"이 만드는 면적입니다.

이 면적이 의미가 있으려면 채널마다 검색 의도를 다르게 가져가야 합니다. 같은 글을 7곳에 그대로 복사하면 Google이 canonical로 묶고, 결국 한 채널 분량의 노출만 받습니다. 우리는 treesoop.com을 canonical로 두고 Medium·Velog·Hashnode는 명시적으로 cross-post 라벨을 달되, Brunch는 같은 주제라도 1인칭을 모두 제거하고 3인칭 에디토리얼로 다시 씁니다. 같은 글이 아니라 같은 인사이트의 다른 패키지인 셈입니다. 1.5개월 데이터에서 의미 있던 또 다른 발견은, 채널별 인바운드의 "직군 분포"가 거의 겹치지 않는다는 점이었습니다. LinkedIn에서는 C레벨과 PM, Brunch에서는 비기술 의사결정자, Medium·Velog에서는 시니어 엔지니어가 들어왔습니다. 한 채널만 운영했다면 같은 자원으로 닿을 수 있는 직군이 1/3 이하로 줄었을 겁니다.

AI 개발팀이 직접 만들 때만 가능한 LLM 활용 5가지

  1. 자기 코드를 톤 가이드로 쓰기 — 우리 깃 히스토리와 PR 코멘트를 LLM에 학습 컨텍스트로 넣으면, 외주가 절대 흉내 낼 수 없는 founder voice가 나옵니다.
  2. 에러 로그 → 블로그 토픽 — 실제로 막힌 버그를 LLM이 일반화해 "X에서 Y 에러가 날 때" 형태의 롱테일 키워드를 만듭니다.
  3. A/B 헤드라인 자동 생성·검증 — 같은 글에 헤드라인 5개를 만들고 1주 뒤 GSC CTR로 자동 채택. 외주 사이클로는 불가능한 속도입니다.
  4. GSC 노출/클릭 차이로 description 패치 — 노출은 많은데 클릭이 안 붙는 글의 description만 매주 자동 재작성합니다.
  5. 자체 도구 자체가 콘텐츠 — 우리가 만든 Playwright MCP 워크플로 같은 OSS는 그 자체가 백링크 자석이 됩니다. 외주는 이런 자산을 만들 수 없습니다.

외주가 합리적인 경우 vs 자체 구축이 합리적인 경우

마케팅 자동화 외주 vs 자체 구축의 결정 매트릭스는 단순합니다.

  • 팀에 풀스택 엔지니어가 1명도 없다 → 외주.
  • 콘텐츠 주제가 비기술 일반론(라이프스타일, 식음료, 패션) → 외주가 빠릅니다.
  • 콘텐츠 주제가 자사 코드/제품 기반의 깊은 기술 → 자체 구축이 거의 유일한 선택지.
  • 분기 안에 결과를 내야 한다 → 단기 퍼포먼스 광고 외주 + 장기 콘텐츠 자체 구축의 하이브리드.
  • 1.5개월 이상 기다릴 수 있고, 엔지니어 0.3 FTE를 뽑을 수 있다 → 자체 구축이 압도적으로 저렴합니다.

다음 단계

이 글은 우리가 운영 중인 파이프라인의 비용·구조를 공개한 첫 번째 회고입니다. 채널별 발행 빈도, decision 단계 규칙, 톤 가이드 같은 더 구체적인 운영 데이터는 다음 글에서 풀어보겠습니다. 자체 구축을 검토 중이거나, 외주 견적과 비교가 필요한 팀은 treesoop.com 문의로 실측 데이터를 더 공유받을 수 있습니다.