원래 AIdeazz에 게시되었습니다 — 정식 링크(canonical link)와 함께 이곳에 교차 게시되었습니다.

자동화된 콘텐츠 파이프라인(content pipeline)을 시도했던 저의 첫 번째 시도는 유의미한 변화를 만들어내지 못했습니다. 30개의 기사를 위해 API 호출 비용으로 120달러를 썼지만, Google Search Console (GSC) 노출수(impressions)는 거의 움직이지 않았습니다. 문제는 LLM 출력물이 아니라 입력값이었습니다. "콘텐츠 갭 (content gap)"은 키워드 조사 도구로 해결할 수 있는 모호한 개념이 아닙니다. GSC 쿼리가 15개뿐인 신규 사이트의 경우, 그것은 정확히 그 15개의 쿼리를 의미합니다. 저의 초기 에이전트(agent)는 사람들이 검색할 수도 있는 것을 추측하려 했기에 너무 광범위했습니다. 사람들이 내 사이트에서 찾지 못하고 실제로 검색하고 있는 것을 다루어야 했습니다.

현재 AIdeazz.xyz와 Dev.to를 위해 매주 3~5개의 기사를 게시하고 있는 이 파이프라인의 반복 버전은 초정밀 GSC 갭 분석(gap analysis)에 집중합니다. 노출수는 있지만 클릭수가 0인 쿼리를 식별하고, Claude 3 Opus를 사용하여 기사 초안을 작성하며(가능한 경우 속도를 위해 Groq을 통해 라우팅), 이를 게시하고 콘텐츠를 캐싱(cache)합니다. GSC 데이터 수집부터 라이브 기사 게시까지의 전체 프로세스는 평균 12분이 소요됩니다.

GSC 갭: 클릭 없는 노출

신생 사이트의 "콘텐츠 갭"은 검색량이 많은 키워드로 기존의 강자들과 경쟁하는 것이 아닙니다. 그것은 Google이 이미 당신에게 보내주고 있는 사용자들에게 서비스를 제공하는 것에 관한 것입니다. 저의 GSC 데이터는 노출수가 5에서 50 사이이지만 클릭수는 0인 15~20개의 쿼리를 보여주었습니다. 이것들은 AI 에이전트(AI agents), Oracle Cloud, 또는 저의 특정 기술 스택(tech stack)과 관련된 롱테일(long-tail)의 구체적인 질문들이었습니다. 예를 들어, "oracle cloud always free arm instance setup" 또는 "groq api claude 3 opus routing"과 같은 것들입니다.

제 에이전트의 첫 번째 작업은 지난 28일 동안의 GSC 데이터를 가져오는 것입니다. 에이전트는 clicks = 0 이고 impressions > 3인 쿼리를 필터링합니다. 이는 임의적인 설정이 아닙니다. impressions > 3은 어느 정도의 신호(signal)가 있음을 보장하며, clicks = 0은 전환에 완전히 실패했음을 확인합니다. 그런 다음 에이전트는 노출수(impression count)에 따라 이러한 쿼리의 순위를 매겨, 가시성 격차(visibility gaps)가 가장 큰 것부터 우선순위를 둡니다. 만약 해당되는 쿼리가 없다면, 에이전트는 24시간 동안 일시 중지합니다. 이는 단순히 콘텐츠를 만들기 위한 콘텐츠 생성을 방지하기 위함입니다.

에이전트 오케스트레이션 (Agent Orchestration): 쿼리에서 초안까지

대상 쿼리가 식별되면 (예: "oracle cloud always free arm instance setup"), 오케스트레이션(orchestration)이 시작됩니다. 저는 Python을 사용하여 Oracle Cloud Infrastructure (OCI) 기반의 멀티 에이전트 시스템(multi-agent system)을 사용합니다. 각 에이전트는 Docker 컨테이너이며, OCI Container Instances에 의해 관리되고 Redis 메시지 큐(message queue)를 통해 통신합니다.

1. GSC 쿼리 에이전트 (GSC Query Agent): 프로세스를 시작하고, 데이터를 가져오며, 가장 큰 격차를 보이는 쿼리를 식별합니다. 그런 다음 이 쿼리를 "리서치 에이전트 (Research Agent)" 큐로 보냅니다.
2. 리서치 에이전트 (Research Agent): 이 에이전트의 역할은 맥락(context)을 수집하는 것입니다. 식별된 쿼리에 대해 타겟팅된 Google 검색을 수행하고, 상위 3~5개의 검색 결과를 스크래핑(scraping)합니다. 또한 중복을 피하고 내부 링크(internal linking) 기회를 확보하기 위해 기존 사이트의 사이트맵(sitemap)과 내부 지식 베이스(과거 기사와 노트의 벡터 스토어(vector store))를 조회합니다. 이러한 리서치는 LLM의 근거(grounding)를 마련하는 데 매우 중요합니다. 이것이 없다면 LLM은 환각(hallucination)을 일으키거나 일반적인 조언만을 제공하게 됩니다. 에이전트는 이 리서치 내용을 구조화된 JSON 객체로 컴파일합니다: {"query": "...", "top_results_summaries": [...], "internal_context": "..."}. 이 JSON은 이후 "드래프팅 에이전트 (Drafting Agent)" 큐로 전달됩니다.
3. 드래프팅 에이전트 (Drafting Agent): 여기서 LLM이 투입됩니다. 저는 긴 컨텍스트 창(context window)과 추론 능력을 위해 주로 Claude 3 Opus를 사용하지만, 더 간단한 쿼리이거나 Opus가 느릴 때를 대비하여 Groq의 Mixtral 8x7B로 전환되는 폴백(fallback) 기능을 구축해 두었습니다. 에이전트는 먼저 쿼리의 복잡성을 확인합니다. 만약 단순한 "방법(how-to)"에 관한 것이라면, Groq으로 라우팅(route)을 시도합니다.

더 깊은 분석이나 종합(synthesis)이 필요한 경우, 기본적으로 Claude 3 Opus로 라우팅됩니다. 프롬프트는 매우 구조화되어 있습니다:

```
당신은 전문 기술 작가(technical writer)입니다. 당신의 작업은 사용자의 쿼리를 다루는 상세하고 실용적인 블로그 포스트를 작성하는 것입니다.
타겟 독자: 개발자, 기술 창업자. 이들이 AI의 과장된 광고(hype)에 회의적이며 구체적인 예시를 가치 있게 여긴다고 가정하십시오.
톤: 직설적이고 사실적이며, 군더더기(fluff)나 스타트업의 상투적인 문구(clichés)를 배제하십시오.

...
```

그 후 에이전트는 LLM의 출력을 가져와 "검토 에이전트(Review Agent)" 대기열로 전달합니다.

검토 및 게시: Human-in-the-Loop 및 자동 배포

매우 구조화된 프롬프트를 사용하더라도 LLM의 출력은 완벽하지 않습니다. 저의 "검토 에이전트(Review Agent)"는 사람입니다.

1. 검토 에이전트 (사람): 초안이 준비되면 "작성 에이전트(Drafting Agent)"가 저의 Telegram 봇으로 알림을 보냅니다. 저는 정확성, 톤, 명확성을 위해 기사를 검토합니다. 이 과정은 보통 2~5분 정도 소요됩니다. 저는 사소한 편집을 수행하고, 필요한 경우 특정 코드 스니펫(code snippets)을 추가하며, 기사가 저의 브랜드 보이스와 일치하는지 확인합니다. 이러한 인간의 손길(human touch)은 품질과 신뢰를 유지하는 데 매우 중요합니다. 승인이 완료되면 Telegram 봇의 버튼을 통해 다음 단계를 실행합니다.
2. 게시 에이전트 (Publishing Agent): 이 에이전트는 승인된 Markdown을 전달받습니다. 에이전트는 두 가지 핵심 작업을 수행합니다:
   • Dev.to API: Dev.to API를 사용하여 새 포스트를 생성합니다. 기사는 처음에 초안(draft) 상태로 게시되어 플랫폼에서 최종 확인을 할 수 있도록 합니다. 확인이 완료되면 published: true로 설정됩니다.
   • AIdeazz.xyz 캐시 (Cache): 기사는 또한 저의 AIdeazz.xyz 콘텐츠 캐시(OCI Block Volume 상의 간단한 파일 기반 캐시)에도 저장됩니다. 이를 통해 즉시 공개되지 않더라도 제 사이트에 정식 버전(canonical version)을 보유할 수 있습니다. 이는 향후 내부 링크 연결 및 콘텐츠 분석도 가능하게 합니다.
   • 사이트맵 업데이트 (Sitemap Update): 게시 후, 에이전트는 AIdeazz.xyz의 사이트맵 업데이트를 트리거하고 Google Search Console에 핑(ping)을 보내 재색인(re-index)을 요청합니다. 이를 통해 새로운 콘텐츠가 빠르게 발견될 수 있도록 합니다.

비용 및 성능 지표

전체 파이프라인은 가능한 경우 OCI Always Free 티어(Redis, 일부 컴퓨팅 인스턴스)와 에이전트를 위한 OCI Container Instances에서 실행됩니다.

• OCI Container Instances: 각 에이전트는 1 OCPU, 1GB RAM 인스턴스에서 실행됩니다. 비용은 무시할 수 있는 수준이며, 일반적으로 활성 에이전트당 시간당 $0.01 미만입니다.
• LLM APIs: 이것이 주요 가변 비용입니다.
  • Claude 3 Opus: 입력 1M 토큰당 약 $15, 출력 1M 토큰당 약 $75. 1500단어 분량의 기사(약 2000 토큰)는 기사당 약 $0.15~$0.20가 소요됩니다.
  • Groq Mixtral 8x7B: 입력 1M 토큰당 약 $0.27, 출력 1M 토큰당 약 $0.27. 1500단어 분량의 기사는 $0.001 미만입니다.
  • 저의 라우팅 로직(routing logic)은 기사의 약 30%에 Groq를 사용하도록 보장하여, LLM 지출을 크게 줄여줍니다.
• Google Search Console API: 무료.
• Dev.to API: 무료.
• 기사당 총 비용: 주로 LLM API 호출로 인해 평균 $0.10 - $0.25가 소요됩니다.
• 게시까지 걸리는 시간: 12분 (인간의 검토를 포함한 평균).
• 영향: 이 특정 GSC 갭 전략을 구현한 지 2주 이내에, 타겟 쿼리에 대한 저의 클릭률(CTR)이 0%에서 평균 8-12%로 증가했습니다. AIdeazz.xyz의 전체 사이트 노출수(impressions)는 전월 대비 15% 증가했습니다.

이 파이프라인은 무한한 콘텐츠를 생성하는 것이 목적이 아닙니다. Google이 이미 제 사이트에 대해 식별한 특정 사용자 니즈를 정밀하게 해결하는 것이 목적입니다. 이는 기존의 노출을 클릭으로 전환하는 것이며, 최소한의 수동 노력과 비용으로 이를 수행하는 것입니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: Dev.to와 본인의 사이트 양쪽에 게시할 경우 중복 콘텐츠 문제를 어떻게 처리하나요?
A: Dev.to는 표준 URL(canonical URL)을 지정할 수 있도록 허용합니다. 저는 항상 표준 URL을 AIdeazz.xyz의 기사로 설정합니다. 이를 통해 검색 엔진에 제 사이트가 원본 소스임을 알려 중복 콘텐츠 페널티를 방지합니다.

Q: GSC 쿼리가 너무 광범위하거나 LLM이 처리하기에 무의미하다면 어떻게 하나요?
A: "리서치 에이전트 (Research Agent)"가 이를 필터링하는 데 도움을 줍니다. 특정 쿼리에 대한 Google 검색 결과가 완전히 관련이 없거나 부족한 경우, 에이전트가 이를 플래그(flag) 처리합니다. 또한, 저의 인간 검토(human review) 단계를 통해 주제에서 벗어나거나 게시할 수 없는 LLM 출력물을 잡아내며, 수동으로 폐기하거나 다시 프롬프트를 작성(re-prompt)할 수 있습니다.

Q: LLM이 단순히 스크래핑된 조사 내용만을 그대로 되풀이하지 않도록 어떻게 보장하나요?
A: 프롬프트에서 "요약할 콘텐츠"가 아닌 "리서치 컨텍스트 (research context)"를 제공하며, 명시적으로 "상세하고 실용적인 블로그 포스트"를 요청합니다. 또한, 저의 기존 관점과 결합된 합성을 장려하기 위해 "내부 지식 (internal knowledge)"을 포함합니다. 단순히 내용을 재탕하는 것이 아니라 독창적인 통찰력을 확보하기 위해서는 이 인간 검토 단계가 매우 중요합니다.

Q: 왜 이 특정 설정을 위해 Oracle Cloud를 사용하나요?
A: Redis와 일부 컴퓨팅 자원을 위해 OCI Always Free 티어를 활용하고 있으며, 이를 통해 운영 비용을 거의 제로에 가깝게 유지합니다. OCI Container Instances는 Kubernetes를 관리할 필요 없이 Docker 컨테이너를 실행할 수 있는 간단한 서버리스(serverless) 방식을 제공하며, 이는 이러한 독립적인 이벤트 기반 에이전트(event-driven agents)에 이상적입니다.

Q: 현재 파이프라인에서 가장 큰 병목 현상(bottleneck)은 무엇인가요?
A: 인간 검토 단계입니다. 빠르기는 하지만 여전히 수동 게이트(manual gate) 역할을 합니다. 저는 초기 품질 검사를 수행하고 명백한 문제를 플래그 처리하여 검토 시간을 더욱 단축하기 위해, 더 작고 빠른 LLM(예: Groq 상의 Llama 3 8B)을 사용하는 추가 에이전트를 탐색하고 있습니다.

— Elena Revicheva · AIdeazz · Portfolio