Originally published on AIdeazz — cross-posted here with canonical link.

제 블로그 트래픽이 정체되었습니다. 단순히 성장이 느린 정도가 아니라, 정말로 무섭게 수평을 이루는 상태였습니다. 한 달 동안 Google Search Console (GSC)에는 제 AIdeazz 포트폴리오에 대한 새로운 노출(impressions)이 전혀 기록되지 않았습니다. 문제는 콘텐츠 부족이 아니었습니다. 구글이 정의하는 '관련성' 있는 콘텐츠가 부족했던 것입니다. 저의 해결책은 더 많은 글을 쓰는 것이 아니라, GSC 콘텐츠 격차를 식별하고, 기사를 초안 작성하며, 심지어 제가 직접 개입하지 않고도 게시할 수 있는 AI 에이전트를 구축하는 것이었습니다. 이것은 단순히 'AI가 블로그를 써주는' 막연한 개념에 관한 것이 아닙니다. Oracle Cloud Infrastructure (OCI)와 다중 에이전트 아키텍처(multi-agent architecture)를 사용하여 GSC 검색어를 Dev.to와 제 사이트에 게시된 기사로 변환하는 생산 시스템에 관한 것입니다.

15개 GSC 검색어로 '콘텐츠 격차' 정의하기

GSC를 볼 때 '콘텐츠 격차(content gap)'는 추상적인 개념이 아닙니다. 이는 노출은 있지만 클릭률(CTR)이 낮은 특정 검색어 세트, 또는 페이지 2나 3에 순위가 있는 검색어를 의미합니다. 저의 초기 수동 분석은 고통스러웠습니다. GSC 데이터를 내보내고, impressions > 100, position > 10, 그리고 CTR < 1%로 필터링해야 했습니다. 이를 통해 매주 약 15~20개의 타겟 검색어를 얻을 수 있었습니다. 문제는 이 수동 작업의 노력 자체가었습니다. 분석에 30분, 초안 작성에 2시간, 게시물 발행에 15분이 걸렸습니다. 이것을 10개 기사에 곱하면, 제 전체 주가 사라지는 것이었습니다.

저의 에이전트, 저는 이를

필터링된 결과로부터, 이 에이전트는 해당 기준을 충족하면서 노출 수 (impression count)가 가장 높은 상위 5개 쿼리를 선택합니다. 이 5개의 쿼리는 다음 발행 주기를 위한 "콘텐츠 격차 (content gaps)"가 됩니다. 그런 다음 에이전트는 이 쿼리들을 다음 단계인 "기사 초안 작성기 (Article-Drafter)"로 전달합니다.

OCI 기반의 멀티 에이전트 아키텍처 (Multi-Agent Architecture)

저의 전체 AIdeazz 인프라는 OCI 위에서 실행되며, 주로 Ampere A1 컴퓨팅 인스턴스를 사용합니다. 이 설정은 비용 제어에 매우 중요합니다. 저는 벤처 캐피털 (VC) 투자 없이 운영하고 있기 때문입니다. 에이전트들은 OCI에서 실행되는 Redis 기반의 커스텀 메시지 큐 (message queue)를 통해 통신합니다.

파이프라인은 세 가지 주요 에이전트로 구성됩니다:

1. GSC-Gap-Finder (Python/GSC API):

   • 입력 (Input): 예약된 크론 잡 (cron job, 매일).
   • 프로세스 (Process): aideazz.xyz 데이터를 위해 GSC API에 쿼리합니다. 노출 수 (impressions), 순위 (position), 클릭률 (CTR)을 기준으로 쿼리를 필터링합니다. 상위 5개를 선택합니다.
   • 출력 (Output): 5개의 타겟 쿼리를 포함하는 JSON 객체이며, Redis 큐로 전달됩니다.

2. Article-Drafter (Python/LangChain/Claude 3 Opus/Groq):

   • 입력 (Input): Redis로부터 받은 5개의 쿼리가 담긴 JSON 객체.
   • 프로세스 (Process): 각 쿼리에 대해 초안 작성 프로세스를 시작합니다. 저는 다음과 같은 동적 라우팅 (dynamic routing) 메커니즘을 사용합니다:
     • 초안 작성 (Initial Draft): 복잡한 주제는 Claude 3 Opus를 사용하고, 더 단순하고 사실 중심적인 쿼리는 Groq를 사용합니다. 이 결정은 쿼리의 복잡성 (토큰 수, 기술 용어 포함 여부)을 기반으로 미세 조정된 (fine-tuned) 소형 LLM (Mistral 7B)에 의해 이루어집니다.
     • 프롬프트 엔지니어링 (Prompt Engineering): 프롬프트는 단순히 "X에 대해 기사를 써줘"가 아닙니다. 여기에는 다음 내용이 포함됩니다:
       • 타겟 오디언스 (기술 창업자, 개발자).
       • 필수 구조 (H2 헤딩, 불렛 포인트, 관련이 있는 경우 코드 예시).
       • GSC 쿼리에서 추출한 특정 키워드의 필수 포함.
       • 흔한 AI 글쓰기 상투어 (clichés)를 피하기 위한 네거티브 프롬프트 (negative prompt).
       • 특정 단어 수 요청 (1500-2000 단어).

• 반복적 개선 (Iterative Refinement): 초기 초안은

저의 라우팅 에이전트(routing agent)인 미세 조정(fine-tuned)된 Mistral 7B 모델은 입력된 쿼리와 aideazz.xyz에 있는 기존 기사의 작은 샘플을 분석합니다. 그리고 다음과 같이 이진 결정(binary decision)을 내립니다:

• 쿼리에 "multi-agent system", "Oracle Cloud Infrastructure", "Kubernetes", "vector database"와 같은 용어가 포함되어 있거나, (어간 추출(stemming) 후) 토큰 수가 15개 초과인 경우: Claude 3 Opus로 라우팅합니다. 이는 더 깊은 기술적 설명과 잠재적인 코드 예시가 필요함을 나타냅니다.
• 쿼리가 "how to use Redis cache", "Python logging best practices"와 같이 더 단순하거나, 단일하고 잘 정의된 개념에 집중하는 경우: Groq로 라우팅합니다. 이러한 기사들은 종종 튜토리얼 형식이며 Groq의 속도로부터 이점을 얻습니다.

이러한 라우팅은 상당한 비용을 절감해 줍니다. 일반적인 Claude 3 Opus 초안 비용은 약 $0.50~$0.70인 반면, Groq 초안은 $0.02~$0.05입니다. 기사의 60%를 Groq로 라우팅함으로써, 기사당 평균 LLM 비용을 40% 절감합니다.

"Human in the Loop" (거의 없음)

저는 외부 투자 없이 사업을 운영하는 싱글맘입니다. 저의 시간은 가장 가치 있고 희소한 자원입니다. 이 파이프라인에서 유일한 인간의 개입은 게시하기 전 Dev.to 초안을 빠르게 검토하는 것입니다. 이는 기사당 약 2분이 소요됩니다. 저는 다음 사항들을 확인합니다:

• 심각한 사실 오류 (Egregious factual errors): AI가 정말로 잘못된 내용을 환각(hallucination)했는가? (Claude 3 Opus에서는 드물지만, 이전 모델들에서는 더 흔함).
• 톤과 목소리 (Tone and voice): 제가 쓴 글처럼 들리는가? (이 부분은 저의 프롬프트 엔지니어링 (prompt engineering)이 도움을 줍니다).
• 포맷팅 문제 (Formatting issues): Markdown 헤딩이 올바른가? 코드 블록이 제대로 포맷팅되었는가?

사소한 문제가 있다면 Dev.to에서 직접 수정합니다. 만약 구조적인 큰 문제가 있다면, 해당 기사를 폐기하고 개선된 부정 프롬프트 (negative prompts)와 함께 쿼리를 다시 파이프라인에 넣습니다. 지난 한 달 동안 이런 일이 두 번 있었습니다.

이 자동화된 콘텐츠 파이프라인 덕분에 지난 한 달 동안 30개의 기사를 발행할 수 있었으며, 이는 수동 작업으로는 불가능한 성과입니다. 현재 저의 GSC 노출수(impressions)는 지속적인 상승세를 보이고 있으며, 타겟 쿼리에 대한 클릭률(CTR)은 1% 미만에서 평균 3.2%로 향상되었습니다. 시스템이 완벽하지는 않지만, 실제 비즈니스 문제를 해결하기 위한 프로덕션급(production-grade) 솔루션입니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: Dev.to와 aideazz.xyz 사이의 중복 콘텐츠 문제를 어떻게 처리하나요?
A: Dev.to에서는 표준 URL (canonical URL)을 지정할 수 있습니다. 저의 Publisher 에이전트는 자동으로 표준 URL을 aideazz.xyz 버전의 기사로 설정하여, Google이 원본 소스를 이해하고 중복 콘텐츠로 인한 페널티를 피할 수 있도록 합니다.

Q: LLM이 너무 짧거나 너무 긴 기사를 생성하면 어떻게 되나요?
A: 저의 프롬프트에는 목표 단어 수 범위(예: 1500-2000 단어)가 포함되어 있습니다. Critique 에이전트가 이 제약 조건을 확인합니다. 만약 기사가 범위를 벗어나면, 반복적인 개선 루프(iterative refinement loop) 동안 Drafter 에이전트가 특정 섹션을 확장하거나 축소하도록 지시받습니다.

Q: 기사가 기존 콘텐츠의 재탕이 아닌 독창적인 내용임을 어떻게 보장하나요?
A: GSC 쿼리 자체가 독특한 관점(제 사이트의 커버리지에서 발생하는 특정 격차)을 제공합니다. 또한, 프롬프트에는 "새로운 통찰력을 제공하라" 또는 "실무자의 관점에서 설명하라"라는 지침이 포함되어 있어, LLM이 단순히 요약하는 대신 정보를 합성하도록 유도합니다. 또한 로컬 임베딩 모델 (local embedding model)을 사용하여 생성된 기사의 임베딩을 기존 기사 코퍼스(corpus)와 비교함으로써 유사도가 높은 경우를 식별합니다.

Q: 이 파이프라인을 구축하면서 직면한 가장 큰 어려움은 무엇이었나요?
A: 비용 최적화가 가장 중요했습니다. Claude 3 Opus의 품질과 Groq의 속도 및 비용 효율성 사이의 균형을 맞추고, OCI의 Ampere A1 인스턴스 위에서 구축하는 과정에는 신중한 아키텍처 결정과 토큰 사용량 및 컴퓨팅 사이클에 대한 지속적인 모니터링이 필요했습니다.

— Elena Revicheva · AIdeazz · Portfolio