원문은 AIdeazz에 게시되었습니다 — canonical 링크와 함께 이곳에 교차 게시되었습니다.

나의 첫 번째 AI 콘텐츠 파이프라인 시도는 의미 있는 트래픽을 전혀 생성하지 못하며 실패했습니다. 시스템은 우아했습니다. 커스텀 에이전트(custom agent)가 콘텐츠 격차(content gaps)를 찾기 위해 Google Search Console (GSC)을 분석하고, 성과가 저조한 상위 15개 쿼리를 Claude 3 Opus에 전달하면, Claude가 기사 초안을 작성하고, 또 다른 에이전트가 이를 포맷팅하여 Dev.to와 나의 개인 사이트인 aideazz.xyz에 게시하는 방식이었습니다. 나는 수동 개입 없이 SEO(검색 엔진 최적화)에 최적화된 포스트를 지속적으로 생성하는 것을 목표로 콘텐츠 전략을 자동화하기 위해 이를 구축했습니다. 3개월 후, GSC 데이터는 신규 콘텐츠에 대해 평탄한 직선(flat line)을 보여주었습니다. 문제는 AI의 글쓰기 품질이나 게시 메커니즘이 아니었습니다. 그것은 내가 정의한 "콘텐츠 격차"와 15개의 GSC 쿼리가 파이프라인을 구동할 수 있다는 근본적인 가정이었습니다.

제한된 데이터로 인한 "콘텐츠 격차"의 오류

나의 초기 GSC 격차 분석 에이전트는 단순했습니다:

1. 노출수(impressions) > 100이지만 평균 순위(average position) > 20인 모든 쿼리를 가져옵니다.
2. 기존 기사에서 이미 다루고 있지 않은 쿼리를 필터링합니다 (URL 매핑 기준).
3. 노출수 순으로 정렬하여 상위 15개를 선택합니다.

이 접근 방식은 기술적으로 _어느 정도_의 격차를 식별하는 데는 타당했지만, aideazz.xyz와 같은 신생 사이트에는 완전히 빗나간 방식이었습니다. 불과 수십 개의 기사만 게시된 상태였기에, 나의 GSC 데이터는 매우 희소했습니다. "노출수 > 100"은 클릭이 0인 쿼리에 대해 101회의 노출을 의미하는 경우가 많았는데, 이는 해당 키워드가 극도로 부적절하거나 내가 공략할 이유가 없는 경쟁이 매우 치열한 키워드임을 나타냈습니다. 나의 에이전트는 사실상 썩어 있는, 따기 쉬운 열매(low-hanging fruit)를 고르고 있었던 셈입니다. Claude가 생성한 기사들은 기술적으로는 정확했지만, 내 사이트가 권위(authority)도 없고, 기존 백링크(backlinks)도 없으며, 순위권에 진입할 가능성도 없는 주제들을 다루고 있었습니다. "격차"는 실재했지만, 그것을 채울 나의 능력은 존재하지 않았습니다.

예를 들어, 상위 15개 쿼리 중 하나는 "Oracle Cloud Infrastructure free tier limits"였습니다. 제 기술 스택(tech stack)과 관련은 있었지만, 제 사이트에는 OCI를 언급하는 기사가 단 하나 있었을 뿐 심층적인 분석(deep dive)은 없었습니다. Claude는 1,500단어 분량의 글을 생성했습니다. 하지만 한 달 동안 노출(impressions)은 3회, 클릭(clicks)은 0회에 그쳤습니다. 경쟁 상대는 Oracle 자체 문서와 주요 클라우드 블로그들이었습니다. 저의 AI 콘텐츠 파이프라인은 고품질이지만 관련성이 없는 콘텐츠를 생성하고 있었던 것입니다.

GSC 격차 분석 에이전트(GSC Gap Analysis Agent) 재설계

해결책은 순수하게 양적인 지표에서 벗어나, 제 사이트의 기존 권위(authority)와 잠재력에 대한 질적인 이해로 전환하는 것이었습니다. 저는 다음과 같은 몇 가지 새로운 필터와 점수 산정 메커니즘을 도입했습니다:

1. 주제 클러스터 친화도 (Topical Cluster Affinity): 단순히 "다루지 않음"으로 분류하는 대신, 이제 에이전트는 후보 쿼리와 제 상위 10개 성과 기사(클릭 수 및 평균 순위 10 미만 기준)의 임베딩(embeddings) 사이의 코사인 유사도(cosine similarity) 점수를 계산합니다. 이 과정에는 sentence-transformers/all-MiniLM-L6-v2가 로컬에서 사용됩니다. 유사도 점수가 0.6 미만인 쿼리는 폐기됩니다. 이를 통해 새로운 콘텐츠가 기존의 주제적 권위(topical authority)를 강화하도록 보장합니다.
2. 키워드 난이도 대리 지표 (Keyword Difficulty Proxy): 키워드 난이도를 위한 간단한 대리 지표를 통합했습니다. 각 후보 쿼리에 대해 에이전트는 Google 검색을 수행하고 고권위 도메인(예: Wikipedia, 주요 기술 블로그, 공식 문서)의 결과 수를 계산합니다. 상위 10개 결과 중 5개 이상이 Moz 도메인 권위(Domain Authority) 70 이상의 도메인에서 나온 경우, 해당 쿼리는 페널티를 받습니다. 이는 경쟁이 매우 치열한 용어들을 걸러내기 위한 투박하지만 효과적인 필터입니다.
3. 클릭률 (CTR) 잠재력: 기존 노출이 있는 쿼리의 경우, 이제 해당 순위에서 평균보다 높은 CTR을 보이는 쿼리를 우선시합니다. 예를 들어, 노출 수가 비슷하다고 가정할 때, CTR 0.5%를 기록하는 30위 쿼리는 CTR 0.1%를 기록하는 25위 쿼리보다 더 흥미로운 대상입니다. 이는 증폭 가능한 기존의 사용자 관심도를 나타냅니다.
4. 롱테일 집중 (Long-Tail Focus): 쿼리에 대한 최소 단어 수 필터(최소 4단어)를 추가했습니다.

짧고 광범위한 키워드(Short, broad keywords)는 소규모 사이트에게 거의 항상 경쟁이 너무 치열합니다.

이렇게 수정된 GSC 에이전트는 이제 15개가 아닌, 우선순위가 지정된 5~7개의 쿼리 목록을 출력합니다. 수량의 감소는 관련성(relevance)과 잠재적 영향력을 높이기 위한 의도적인 트레이드오프 (trade-off)입니다.

멀티 에이전트 오케스트레이션 (Multi-Agent Orchestration): Claude, Groq, 그리고 Oracle Cloud

나의 AI 콘텐츠 파이프라인은 서버리스 함수 (OCI Functions)와 특정 에이전트를 위한 상시 가동 컴퓨팅 인스턴스를 혼합하여 Oracle Cloud Infrastructure (OCI) 상에서 완전히 실행됩니다.

Python으로 작성된 GSC 분석 에이전트는 매주 트리거되는 OCI Function으로 실행됩니다. 이 에이전트는 GSC API를 통해 데이터를 가져오고, 이를 처리한 뒤, 우선순위가 지정된 쿼리를 OCI Object Storage 버킷에 저장합니다.

기사 생성 에이전트는 더 복잡합니다. 이는 다단계 프로세스로 구성됩니다:

1. 주제 선정 (Topic Selection): 전용 에이전트가 Object Storage 버킷을 모니터링합니다. 새로운 쿼리가 나타나면 하나를 선택합니다.
2. 개요 생성 (Outline Generation - Groq): 속도와 비용 효율성을 위해 첫 번째 단계는 상세한 개요를 생성하는 것입니다. 저는 이를 위해 Groq의 Llama 3 8B 모델을 사용합니다. 프롬프트는 간단합니다: "개발자를 대상으로 하는 '[Query]'라는 제목의 기사를 위한 상세하고 SEO에 최적화된 개요를 생성하세요. H2 및 H3 헤딩을 포함하고, aideazz.xyz/portfolio로 연결되는 3~5개의 내부 링크를 제안하세요." Groq는 약 $0.00005의 비용으로 200ms 이내에 이를 반환합니다.
3. 초안 작성 (Drafting - Claude 3 Opus): 그 다음 개요는 Anthropic API를 통해 Claude 3 Opus로 전달됩니다. Claude는 개요를 엄격히 준수하고, 기술적인 톤을 유지하며, 제안된 내부 링크를 통합하여 1,2001,800단어 분량의 기사를 작성하도록 지시받습니다. 저는 Claude 3 Opus가 더 높은 비용($15/M tokens)에도 불구하고, 다른 모델들에 비해 길고 일관성 있는 기술 콘텐츠 작성에 있어 더 우수하다는 것을 발견했습니다. 각 기사 생성에는 약 $2$4의 비용이 듭니다.

검토 및 개선 (Custom Agent): 발행 전, 커스텀 Python 에이전트가 여러 가지 검사를 수행합니다:
- 표절 검사 (Plagiarism Check): 기존 웹 콘텐츠 및 제가 작성한 기사들이 담긴 소규모 내부 데이터베이스를 대상으로 퍼지 매칭 (fuzzy matching)을 결합하여 사용합니다.
- SEO 키워드 밀도 (SEO Keyword Density): 타겟 쿼리와 관련 키워드가 자연스럽게 나타나는지 확인합니다.
- 가독성 점수 (Readability Score): Flesch-Kincaid 학년 수준을 확인합니다 (기술 콘텐츠의 경우 10-12 수준을 목표로 함).
- 코드 스니펫 검증 (Code Snippet Validation): 코드가 포함된 경우, Python의 ast 모듈이나 JavaScript의 esprima를 사용하여 기본적인 구문 검사 (syntax check)를 시도합니다. 이는 약한 검사이지만 명백한 오류를 잡아냅니다.
- 내부 링크 검증 (Internal Link Validation): 제안된 내부 링크가 aideazz.xyz의 유효한 URL인지 확인합니다.

이 개선 에이전트는 문제를 표시하고 저에게 Telegram 알림을 보냅니다. 문제가 없으면 다음 단계로 진행합니다.

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

마지막 단계는 발행입니다. 저는 두 개의 발행 에이전트를 운영합니다:

1. Dev.to 에이전트: 이 Python 스크립트는 Dev.to API를 사용합니다. 개선된 기사를 가져와 Markdown으로 변환하고, 적절한 태그를 추가하며 (소형 로컬 LLM인 phi-3-mini를 사용하여 기사 콘텐츠에서 추출), 캐노니컬 URL (canonical URL)을 aideazz.xyz 버전으로 설정합니다. 그런 다음 기사를 초안 (draft) 상태로 발행하고, 최종 검토를 위한 링크와 함께 저에게 Telegram 알림을 보냅니다. 저는 Dev.to에서 수동으로 "발행" 버튼을 누릅니다. 이 반수동 (semi-manual) 단계는 품질을 유지하고 실수로 인한 스팸을 방지하는 데 매우 중요합니다.
2. aideazz.xyz 캐싱 에이전트 (Caching Agent): 제 개인 사이트는 Hugo로 생성된 정적 사이트 (static site)입니다. 에이전트는 Markdown을 가져와 Hugo와 호환되는 .md 파일로 변환한 뒤 올바른 디렉토리에 배치합니다. 그 다음 제 OCI Code Repository로 git push를 트리거하며, 이는 다시 OCI DevOps 파이프라인을 트리거하여 사이트를 재빌드하고 재배포합니다. 이를 통해 기사가 제 기본 도메인에 라이브 상태로 게시되며 캐노니컬 소스 (canonical source) 역할을 하게 됩니다.

GSC 분석부터 사이트 배포에 이르는 전체 프로세스는 사람의 개입이 마지막 Dev.to 검토 단계에서만 이루어지도록 자동화(hands-off)되도록 설계되었습니다. 모든 API 호출과 OCI 컴퓨팅 비용을 포함한 기사당 비용은 평균 약 5~7달러입니다.

결과 및 향후 반복 (Results and Future Iterations)

수정된 GSC 격차 분석 (gap analysis) 및 멀티 에이전트 파이프라인을 구현한 이후, 눈에 띄는 개선을 확인했습니다. 바이럴 콘텐츠를 생성하고 있지는 않지만, 새로운 기사들이 지속적으로 더 높은 순위(한 달 이내 평균 순위 15-20위)를 기록하며 작지만 꾸준한 클릭 유입을 끌어내고 있습니다. 이 새로운 기사들에 대한 GSC 데이터는 2-3%의 클릭률 (CTR)을 보여주는데, 이는 이전 반복 단계의 0에 가까웠던 CTR에 비해 상당한 개선입니다.

가장 큰 교훈은 "콘텐츠 격차 (content gap)"란 단순히 무엇이 빠져 있는가가 아니라, 당신의 특정 맥락에서 무엇이 "달성 가능한가"의 문제라는 점이었습니다. 규모가 작은 사이트는 광범위하고 경쟁이 치열한 키워드가 아니라, 기존의 권위 (authority) 범위 내에 있는 마이크로 격차 (micro-gaps)를 타겟팅해야 합니다.

다음 반복 단계에서는 다음 사항에 집중할 것입니다:

• 동적 LLM 라우팅 (Dynamic LLM Routing): 초안 작성을 위해 Claude 3 Opus를 고정적으로 사용하는 대신, 개요의 복잡성을 평가하여 Claude 3 Haiku, Sonnet, Opus 중 하나를 동적으로 선택하거나, 비용과 품질을 최적화하기 위해 OCI에서 파인튜닝된 (fine-tuned) Llama 3 모델을 선택하는 라우팅 에이전트를 구현할 것입니다.
• 피드백 루프 통합 (Feedback Loop Integration): GSC 성능 데이터를 에이전트의 쿼리 점수 산정 알고리즘에 다시 통합할 계획입니다. 성과가 좋은 기사는 관련 쿼리에 대한 주제적 친화도 (topical affinity) 점수를 높여, 자기 강화 루프 (self-reinforcing loop)를 생성하게 됩니다.
• 소셜 미디어 홍보 에이전트 (Social Media Promotion Agent): Llama 3 8B와 같은 모델을 사용하여 새 기사로 연결되는 Twitter/LinkedIn/Telegram용 짧은 홍보 게시물을 작성하는 에이전트입니다.

이 AI 콘텐츠 파이프라인은 즉각적인 SEO 지배를 위한 마법의 탄환은 아니지만, 소규모 독립 발행자의 현실을 존중하면서 일관되고 타겟팅된 콘텐츠 생성을 가능하게 하는 강력한 시스템입니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: 왜 갭 분석 (gap analysis)을 위해 상용 SEO 도구를 사용하지 않나요?
A: 상용 도구는 비용이 많이 들고 (월 $100 이상), 종종 일반적인 조언만을 제공합니다. 제가 만든 커스텀 에이전트 (custom agent)는 저의 특정 GSC 데이터와 사이트 권위 (site authority)에 맞춰져 있으며, 비용은 오직 OCI 컴퓨팅 시간 (실행당 몇 푼 수준)만 소요될 뿐만 아니라 로직에 대한 완전한 제어권을 제공합니다.

Q: 왜 개요 (outlines) 작성에는 Groq을 사용하고, 초안 작성 (drafting)에는 Claude를 사용하나요? 왜 모델 하나로 하지 않나요?
A: Groq은 개요와 같이 짧고 구조화된 출력물에 대해 믿을 수 없을 정도로 빠르고 저렴합니다. Claude 3 Opus는 긴 분량의 미묘한 차이가 있는 기술적 글쓰기 (technical writing)에 탁월합니다. 이러한 분할 방식은 각 모델의 강점을 활용하여, 각 작업에서 속도/비용 (Groq)과 품질 (Claude)을 모두 최적화합니다.

Q: 기사를 위한 이미지 생성은 어떻게 처리하나요?
A: 현재로서는 이미지 생성을 자동화하지 않습니다. 관련 스크린샷이나 다이어그램을 수동으로 추가합니다. 자동화된 이미지 생성은 향후 개선 사항이며, DALL-E 3 또는 Stable Diffusion과 같은 모델을 사용할 가능성이 높지만, 아직은 우선순위가 낮은 복잡성과 비용을 추가하게 됩니다.

Q: AI가 사실과 다른 정보를 생성하면 어떻게 되나요?
A: 정제 에이전트 (refinement agent)가 몇 가지 기본적인 오류 (예: 깨진 링크, 구문 오류)를 잡아냅니다. 사실 관계의 정확성을 위해서는 Dev.to에서의 수동 검토가 저의 주요 방어책입니다. 또한 Claude에게 적절한 경우 출처를 인용하도록 프롬프트 (prompt)를 작성하지만, 이것이 완벽하게 방지할 수 있는 것은 아닙니다.

Q: 왜 Dev.to와 본인의 사이트 모두에 게시하나요? 중복 콘텐츠 (duplicate content)가 되지 않나요?
A: Dev.to에 게시함으로써 개발자 중심의 독자층으로 도달 범위를 확장합니다. Dev.to의 표준 URL (canonical URL)을 저의 aideazz.xyz 기사로 설정함으로써, 검색 엔진에 제 사이트가 원본 소스임을 알리고, 중복 콘텐츠 페널티를 피하며 SEO 권위 (SEO authority)를 통합합니다.

— Elena Revicheva · AIdeazz · Portfolio