원문은 AIdeazz에 처음 게시되었으며, 정식 링크(canonical link)와 함께 이곳에 교차 게시되었습니다.

나의 첫 번째 AI 콘텐츠 파이프라인 시도는 성과를 내지 못했습니다. 한 달 동안 Claude 3 Opus에 120달러를 지출하며 30개의 기사를 생성했지만, 유기적 트래픽(organic traffic)에는 전혀 영향이 없었습니다. 문제는 LLM의 출력 품질이 아니라 입력(input)이었습니다. 나의 "콘텐츠 갭 분석(content gap analysis)"은 Google Search Console (GSC)에서 노출(impressions)은 있지만 클릭(clicks)이 낮은 쿼리를 수동으로 스캔한 뒤, 그저 적절해 보이는 것을 선택하는 방식이었습니다. 이러한 접근 방식은 전략이 아니라 동전 던지기와 같습니다.

진정한 제약 사항은 AI의 글쓰기 능력이 아니라, 어떤 콘텐츠가 실제로 성과를 낼지 식별하는 나의 능력이었습니다. 노출은 있지만 클릭이 없는 15개의 GSC 쿼리가 있다면, "콘텐츠 갭"은 모호한 개념이 아니라 구체적이고 측정 가능한 기회입니다. 나는 이러한 갭을 프로그래밍 방식으로 식별하고, 콘텐츠를 생성하며, 나의 직접적인 개입 없이도 발행할 수 있는 시스템이 필요했습니다. 이것이 내가 AIdeazz를 위해 구축한 방식이며, Groq와 Claude 3 Opus를 사용하여 Oracle Cloud Infrastructure (OCI)에서 실행되며, Dev.to에 발행하고 내 사이트에 캐싱합니다.

진정한 콘텐츠 갭 식별하기: 수동 GSC 스캔을 넘어서

초기 실패를 통해 나는 "콘텐츠 갭"이 주관적인 느낌이 아니라는 것을 배웠습니다. 그것은 데이터 포인트입니다. 구체적으로, 특정 URL에 대해 impressions > 0이고 clicks = 0인 GSC 쿼리이거나, 높은 노출을 기록하지만 클릭률 (CTR)이 낮고 기존 콘텐츠가 사용자의 의도(user intent)를 충분히 충족하지 못하는 쿼리입니다.

나의 에이전트인 GSC_Analyzer_Agent는 API를 통해 매일 GSC에서 데이터를 가져옵니다. 나는 aideazz.xyz와 dev.to/aideazz에 대한 쿼리에 집중합니다. 에이전트는 다음 조건으로 필터링합니다:

1. 지난 30일 동안 impressions > 50이고 clicks = 0인 쿼리.
2. impressions > 100이고 CTR < 1%이며, 순위가 매겨진 URL이 해당 쿼리에 직접적으로 최적화되어 있지 않은 쿼리.

식별된 각 격차(gap)에 대해 에이전트는 해당 검색어(query), 현재 순위 URL(있을 경우), 그리고 평균 순위를 추출합니다. 이 출력물은 각 격차마다 {'query': '...', 'current_url': '...', 'avg_position': '...'} 형태의 구조화된 JSON 객체가 되며, 다음 단계의 프롬프트가 됩니다. 바로 여기서 '15개의 GSC 검색어'는 단순한 데이터 포인트가 아니라 실행 가능한 작업(actionable tasks)이 됩니다.

기사 생성을 위한 LLM 오케스트레이션 (Orchestrating LLMs for Article Generation)

콘텐츠 생성의 핵심은 다중 에이전트 시스템입니다. 저는 작업 복잡도와 비용에 따라 LLM을 선택하기 위해 사용자 지정 라우터(router)를 사용합니다. 초기 브레인스토밍 및 개요 생성을 위해서는 속도와 낮은 비용 때문에 Groq으로 연결하는 경우가 많습니다. 전체 기사 초안의 경우, 긴 컨텍스트 창과 미묘한 글쓰기 스타일 덕분에 Claude 3 Opus가 현재 선호하는 모델입니다. 특히 기술적인 주제에 적합합니다.

Article_Generator_Agent는 격차 분석 출력을 받습니다. 각 격차에 대해 다음과 같은 단계를 수행합니다:

1. 개요 생성 (Groq): 프롬프트: '키워드 '[¸query¿]'를 목표로 하는 기사의 상세한 개요를 작성해 주세요. 57개의 주요 섹션과 각 주요 섹션당 35개의 하위 섹션을 포함해야 합니다. 개발자를 위한 실용적인 조언에 초점을 맞춰주세요.'
2. 초안 작성 (Claude 3 Opus): 프롬프트: '다음 개요를 기반으로 포괄적이고 기술적인 기사를 작성해 주세요: [¸outline JSON¿]. 구체적인 예시, 코드 스니펫(적용 가능한 경우), 그리고 일반적인 함정들을 포함시켜 주십시오. 어조는 직접적이며 실무자 중심이어야 합니다. 목표 독자는 숙련된 개발자와 기술 창업가입니다. 단어 수: 1500~2000단어.'
3. SEO 최적화 (Claude 3 Haiku): 초안이 준비되면, SEO_Optimizer_Agent가 역할을 이어받습니다. 이 에이전트는 Claude 3 Haiku(작은 작업에 더 저렴하고 빠름)를 사용하여 목표 검색어와 비교하며 초안을 검토합니다. 제목 개선, 메타 설명, 내부 링크 기회, 키워드 밀도 조정 등을 제안합니다. 또한 이 에이전트는 자신이 작성하는 기사에서 사용하는 구조를 모방하여 FAQ 섹션을 위한 관련 질문과 답변 3~5개를 생성하기도 합니다.

이러한 멀티 LLM (Multi-LLM) 접근 방식은 비용과 성능을 최적화할 수 있게 해줍니다. Groq은 빠르고 반복적인 작업을 처리하고, Claude 3 Opus는 고품질의 긴 글(long-form content)을 생성합니다.

Dev.to 및 AIdeazz.xyz로의 자동 발행

발행은 Publisher_Agent가 담당합니다. 이 에이전트는 두 가지 주요 작업을 수행합니다.

1. Dev.to API 통합: Dev.to는 기사 발행을 위한 강력한 API를 제공합니다. 에이전트는 생성된 마크다운 (Markdown)을 필요한 JSON 형식으로 변환하고, 적절한 태그(기사 내용 및 타겟 쿼리에서 추출됨)를 추가하며, published 상태를 true로 설정합니다. 여기서 오류 처리 (Error handling)가 매우 중요합니다. 저는 429 Too Many Requests 오류에 대해 지수 백오프 (exponential backoff)를 적용한 재시도 로직을 구현했으며, 401 Unauthorized (API 키 문제) 또는 422 Unprocessable Entity (잘못된 형식의 콘텐츠)에 대한 특정 로깅을 구현했습니다.
2. AIdeazz.xyz 캐싱: Dev.to는 도달 범위를 넓히기에 훌륭한 플랫폼이지만, 장기적인 SEO (검색 엔진 최적화) 이점과 제어권을 위해 제 개인 사이트에도 콘텐츠를 보관하고 싶었습니다. 에이전트는 aideazz.xyz의 내부 API 엔드포인트로 간단한 POST 요청을 보냅니다. 이 엔드포인트는 마크다운 콘텐츠를 수신하고, 고유한 슬러그 (slug)를 생성하며, 이를 저의 Oracle Autonomous Database에 저장합니다. 저는 이 캐싱된 기사들을 렌더링하기 위해 가벼운 SvelteKit 프론트엔드를 사용합니다. 이를 통해 Dev.to가 정책을 변경하거나 서비스가 중단되더라도 콘텐츠에 대한 소유권을 유지할 수 있습니다.

GSC 갭 식별부터 자동 발행에 이르는 전체 프로세스는 OCI 컴퓨팅 인스턴스에서 cron 작업으로 실행되는 중앙 Python 스크립트에 의해 오케스트레이션 (orchestrated)됩니다. 이 시스템은 멱등성 (idempotent)을 갖도록 설계되었습니다. 특정 GSC 갭에 대한 기사가 이미 발행되었다면 해당 기사는 건너뜁니다.

인프라 및 비용 고려 사항

이 파이프라인을 실행하려면 세심한 리소스 관리가 필요합니다.

• OCI Compute: 단일 VM.Standard.E4.Flex 인스턴스(1 OCPU, 16GB RAM)면 충분합니다. 비용: 월 약 $50.
• Oracle Autonomous Database: GSC 데이터, 기사 개요(outline), 발행된 콘텐츠 메타데이터를 저장하기 위해 Always Free 티어를 사용합니다. 이는 직접적인 비용 없이 영구 저장소를 확보하기 위한 핵심 구성 요소입니다.
• LLM APIs: 이는 가변 비용입니다.
  • Claude 3 Opus: 입력 100만(M) 토큰당 약 $15, 출력 100만(M) 토큰당 약 $75. 2,000단어 분량의 기사(약 3,000 토큰) 초안 작성 비용은 기사당 약 $0.30~$0.50입니다.
  • Claude 3 Haiku: 입력 100만(M) 토큰당 약 $0.25, 출력 100만(M) 토큰당 약 $1.25. 2,000단어 분량의 기사에 대한 SEO 최적화 비용은 매우 저렴합니다.
  • Groq: LLaMA3 8B 기준 입력 100만(M) 토큰당 약 $0.13, 출력 100만(M) 토큰당 약 $0.13. 개요(outline) 생성은 매우 저렴하며, 종종 $0.01 미만입니다.
• GSC API: 무료.
• Dev.to API: 무료.

1015개의 기사를 생성하는 이 자동화된 콘텐츠 파이프라인의 현재 총 월간 비용은 주로 LLM 사용량에 따라 약 $60$80입니다. 이는 이전에 아무런 결과 없이 지출했던 $120에 비해 크게 개선된 수치입니다. 핵심은 단순히 콘텐츠를 생성하는 것이 아니라, 실제 콘텐츠 갭(content gap)을 정밀하게 타겟팅하는 것입니다.

"콘텐츠 갭(Content Gap)"은 피드백 루프입니다

초기의 실패는 AI의 실패가 아니라 프로세스의 실패였습니다. "콘텐츠 갭"은 정적인 목표가 아니라 역동적인 피드백 루프입니다. GSC_Analyzer_Agent는 성능을 지속적으로 모니터링합니다. 특정 쿼리에 대해 새로 발행된 기사가 노출(impression)은 늘어나기 시작했지만 클릭(click)이 여전히 낮다면, 재평가를 트리거합니다. 그러면 시스템은 다음과 같은 작업을 수행할 수 있습니다:

1. 수정 제안: SEO_Optimizer_Agent가 기존 기사를 분석하고, 클릭률(CTR)을 높이기 위해 제목, 메타 설명(meta description) 또는 콘텐츠 섹션에 대한 구체적인 개선 사항을 제안하도록 프롬프트를 작성할 수 있습니다.
2. 후속 콘텐츠 생성: 초기 기사가 광범위한 쿼리를 부분적으로만 다루고 있다면, 시스템은 하위 갭(sub-gaps)을 식별하고 더 집중적인 기사를 생성할 수 있습니다.

이러한 반복적인 프로세스는 매우 중요합니다. 자동화된 발행은 "설정하고 잊어버리는 (set it and forget it)" 솔루션이 아니라, "설정하고 지속적으로 최적화하는 (set it and continuously optimize it)" 시스템입니다. 목표는 단순히 발행하는 것이 아니라, 효과적으로 발행하는 것입니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: Dev.to와 본인 사이트 간의 잠재적인 중복 콘텐츠 문제를 어떻게 처리하나요?
A: Dev.to는 표준 URL (canonical URLs)을 허용합니다. 저의 Publisher_Agent는 Dev.to API 요청의 canonical_url 필드를 aideazz.xyz에 있는 해당 기사의 URL로 지정합니다. 이는 검색 엔진에 aideazz.xyz가 기본 소스임을 알리는 신호가 됩니다.

Q: LLM이 기술적인 주제에 대해 사실과 다르거나 오래된 정보를 생성하면 어떻게 하나요?
A: 이는 매우 중요한 리스크입니다. 매우 민감한 기술 콘텐츠의 경우, Article_Generator_Agent의 출력이 Publisher_Agent로 전달되기 전에 사람이 검토하는 단계를 거칩니다. 덜 중요한 주제의 경우, LLM의 일반적인 지식과 프롬프트 엔지니어링 (prompt engineering)에 의존하여 정확성을 강조하고 가능한 경우 출처를 인용합니다. 또한, LLM의 응답을 특정 검증된 문서에 기반하도록 만들기 위해 RAG (검색 증강 생성, Retrieval Augmented Generation)를 실험하고 있습니다.

Q: 파이프라인이 저품질이거나 관련 없는 기사를 발행하는 것을 어떻게 방지하나요?
A: 품질은 관련 있는 갭을 식별하는 GSC_Analyzer_Agent의 정밀도에서 시작됩니다. Article_Generator_Agent는 구조와 톤을 위해 상세한 프롬프트를 사용합니다. 또한 가독성 지표(예: Flesch-Kincaid)와 키워드 밀도를 기반으로 한 간단한 콘텐츠 품질 점수를 구현하였으며, 점수가 너무 낮으면 LLM이 초안을 다시 작성하도록 트리거할 수 있습니다.

Q: 이 자동화된 파이프라인을 구축하면서 직면한 가장 큰 과제는 무엇이었나요?
A: 서로 다른 LLM들을 오케스트레이션 (orchestrating)하고 에이전트 간의 원활한 데이터 흐름을 보장하는 것이 가장 큰 과제였습니다. 각 LLM은 고유한 API, 속도 제한 (rate limits), 그리고 프롬프트 엔지니어링의 미묘한 차이를 가지고 있습니다. 각 API 호출에 대해 견고한 라우터 (router)와 에러 핸들링 (error handling)을 구축하는 데 상당한 노력이 필요했습니다.

Q: LLM API 키를 어떻게 안전하게 관리하나요?
A: 모든 API 키는 OCI 컴퓨트 인스턴스 (compute instance)의 환경 변수 (environment variables)로 저장되며, 보안 비밀 관리 서비스 (OCI Vault)를 통해 접근합니다. 애플리케이션 로직에 하드코딩 (hardcoded)하는 일은 절대 없습니다.

— Elena Revicheva · AIdeazz · Portfolio