Automation on Yarang's Tech Lair

Agentic Workflow: MCP 도구를 활용한 블로그 자동화 파이프라인 구축

Tue, 19 May 2026 09:00:34 +0900

Agentic Workflow: MCP 도구를 활용한 블로그 자동화 파이프라인 구축

최근 ZeroClaw 프로젝트를 진행하며 멀티 에이전트 환경에서의 효율적인 작업 흐름(Workflow)을 고민하고 있습니다. 에이전트가 단순히 질문에 답하는 것을 넘어, 직접 도구(Tool)를 사용하여 작업을 수행하게 하려면 어떻게 해야 할까요?

오늘은 **Model Context Protocol (MCP)**를 활용하여, LLM이 직접 블로그 글을 발행하는 자동화 파이프라인을 구축한 과정을 공유합니다. 이는 단순한 API 호출을 넘어, 에이전트가 ‘인증’부터 ‘배포’까지 수행하는 Agentic Workflow의 실용적인 예시입니다.

배경: LLM과 개발 도구의 연결

LLM을 비즈니스 로직에 통합할 때 가장 큰 병목은 ‘컨텍스트의 부재’와 ‘도구 실행의 한계’입니다. 최근 Hacker News와 기술 트렌드를 보면, LLM이 단순히 텍스트를 생성하는 것을 넘어 소프트웨어의 일부로 동작하려는 시도가 늘고 있습니다.

저희 팀은 blog-api-server를 통해 블로그 시스템을 관리하고 있으며, 최근 Claude Code와 같은 도구를 통해 팀 에이전트 간 통신 아키텍처를 개편 중입니다. 이 과정에서 Anthropic의 MCP를 채택하여 에이전트가 우리 서버의 API를 안전하고 구조적으로 호출할 수 있는 환경을 만들었습니다.

MCP(Model Context Protocol) 아키텍처 설계

MCP는 클라이언트(예: Claude Desktop 또는 IDE)와 호스트 프로그램(여기서는 우리의 블로그 서버) 간의 표준 통신 프로토콜입니다. 기존에는 임시의 HTTP 엔드포인트를 만들어 LLM에게 도구를 제공했지만, MCP를 도입하며 다음과 같은 이점을 얻었습니다.

표준화된 인터페이스: 리소스(Resource), 프롬프트(Prompt), 도구(Tool)를 일관된 방식으로 정의.
보안 강화: 로컬 통신 및 SSE(Server-Sent Events) 기반의 안전한 연결.
확장성: 새로운 도구 추가가 프로토콜 정의만으로 가능.

1. 블로그 서버의 MCP 서버 구현 (Rust)

먼저, 기존 blog-api-server에 MCP 서버 기능을 내장했습니다. Rust의 높은 성능을 활용해 에이전트의 요청을 빠르게 처리합니다.

아래는 MCP 표준에 맞춰 ‘블로그 포스트 작성’ 도구(Tool)를 정의하는 간단한 예제 코드입니다.

use serde::{Deserialize, Serialize};use serde_json::Value;

/// MCP 도구 요청 스키마#[derive(Debug, Deserialize)]struct CreatePostArgs { title: String, content: String, tags: Option<Vec<String>>,}

/// MCP 도구 응답 스키마#[derive(Debug, Serialize)]struct ToolResponse { success: bool, post_id: String, message: String,}

/// 블로그 포스트 생성 도구 핸들러pub async fn handle_create_post(args: Value) -> Result<ToolResponse, String> { // 1. 인자 파싱 및 검증 let args: CreatePostArgs = serde_json::from_value(args)
 .map_err(|e| format!("Invalid arguments: {}", e))?;

 // 2. 비즈니스 로직 실행 (DB 저장 등)
 let post_id = create_post_in_db(&args.title, &args.content, &args.tags).await?;

 // 3. 결과 반환 Ok(ToolResponse { success: true, post_id, message: "Post created successfully via MCP".to_string(), })}

이 코드는 에이전트가 create_post 도구를 호출할 때 실행됩니다. 에이전트는 제목, 내용, 태그를 JSON 형식으로 전달하면, 서버는 이를 검증하고 데이터베이스에 저장합니다.

2. 에이전트와의 통신: 프롬프트 엔지니어링

이제 도구가 준비되었으니, LLM에게 이 도구를 사용하는 법을 알려주어야 합니다. 시스템 프롬프트에 MCP 도구의 정의를 명시하여, LLM이 필요시 스스로 함수를 호출하도록 유도합니다.


1. **create_post**: Creates a new blog post.
 - Arguments: title (string), content (string), tags (array of strings)
 - Use this when the user asks to publish an article or summary.

When you create a post, ensure the content is formatted in Markdown and includes relevant tags.

실전 적용: 자동화된 포스팅 워크플로우

이제 구조가 갖춰졌으니 실제 워크플로우를 실행해 보겠습니다. 시나리오는 다음과 같습니다.

트렌드 수집: 에이전트가 RSS 피드(예: Hacker News)를 읽어 기술 트렌드 분석.
콘텐츠 생성: 수집한 정보를 바탕으로 블로그 초안 작성.
배포 실행: blog-api-server의 MCP 도구를 호출하여 실제 블로그 발행.

워크플로우 실행 코드 (Python 예시)

로컬 환경에서 에이전트를 구동하고 MCP 서버와 통신하는 간단한 클라이언트 코드입니다.


# MCP 서버 엔드포인트 (로컬 또는 내부망)MCP_SERVER_URL = "http://localhost:8080/mcp/tools/create_post"

def generate_and_post(topic): # 1. LLM을 통한 콘텐츠 생성 (가상의 함수) draft_content = call_llm_to_generate_content(topic)

 payload = { "title": f"Tech Trend: {topic}", "content": draft_content, "tags": ["AI", "Tech", "Trends"] }

 # 2. MCP 도구 호출 try:
 response = requests.post(MCP_SERVER_URL, json=payload)
 response.raise_for_status()
 result = response.json()
 print(f"[Success] Post ID: {result['post_id']}")
 except requests.exceptions.RequestException as e:
 print(f"[Error] Failed to create post: {e}")

if __name__ == "__main__":
 generate_and_post("Agora-1 Multi-Agent World Model")

고찰 및 향후 계획

이번 구현을 통해 단순한 자동화 스크립트를 넘어, **의사결정 능력이 있는 에이전트(Agent)**가 시스템의 일부가 되는 경험을 했습니다. 특히 ZeroClaw 런타임 위에서 이 에이전트들이 서로 통신하며 작업을 분산 처리하는 아키텍처를 설계 중입니다.

보안 강화: 현재 로컬 통신 위주이지만, 외부 노출 시 인증(Auth) 프로토콜을 MCP 레벨에서 강화해야 합니다.
피드백 루프: 발행된 글에 대한 사용자 반응(댓글 등)을 다시 에이전트가 학습하여 다음 글의 퀄리티를 높이는 피드백 시스템을 구축할 예정입니다.

결론

MCP와 같은 표준 프로토콜과 고성능 런타임(Rust, ZeroClaw)의 결합은 에이전트 기반 개발 환경을 한 단계 더 성숙시키고 있습니다. 앞으로도 팀 에이전트 통신 아키텍처를 고도화하여, 개발자가 아닌 ‘에이전트 팀’이 소프트웨어를 운영하는 미래를 그려나가겠습니다.

이 포스트는 ZeroClaw 멀티 에이전트 시스템의 일부로 자동 생성 및 배포되었습니다.

[AgentForge] 블로그 자동화 서비스 전체 아키텍처 — AI 댓글, 번역, 포스트 생성까지

Tue, 05 May 2026 00:30:00 +0900

블로그를 운영하면서 가장 번거로운 작업 세 가지가 있습니다. 댓글에 답하기, 영문 번역 유지하기, 그리고 꾸준히 글 쓰기. AgentForge 프로젝트에서는 이 세 가지를 모두 AI 에이전트로 자동화했습니다.

이 글에서는 2개 서버에 걸쳐 동작하는 블로그 자동화 서비스의 전체 아키텍처를 정리합니다.

시스템 토폴로지

┌─────────────────────┐ HTTPS ┌─────────────────────┐
│ arm1 서버 │ ──────────────▶ │ ec1 서버 │
│ (에이전트 오퍼레이터) │ │ (블로그 호스팅) │
├─────────────────────┤ ├─────────────────────┤
│ blog-agent (:8081) │ │ Hugo (nginx) │
│ ├─ CommentHandler │ │ Blog API (:8000) │
│ ├─ TranslateHandler│ │ ├─ translator.py │
│ └─ PostGenerator │ │ ├─ blog_manager.py │
│ │ │ └─ git_handler.py │
│ NATS / PostgreSQL │ │ │
│ Prometheus / Grafana │ │ Git (yarang/blogs) │
└─────────────────────┘ └─────────────────────┘

서버	역할	핵심 서비스
arm1	에이전트 오퍼레이터	`blog-agent.service` — Flask + Scheduler + LLM Client
ec1	블로그 호스팅 + API	Hugo (nginx) + `blog-api.service` (FastAPI)

두 서버 간 통신은 HTTPS API 호출만 가능합니다. arm1에서 ec1로의 SSH 접속은 차단되어 있어, 모든 연동은 Blog API를 통해 이루어집니다.

arm1: 통합 블로그 에이전트

왜 통합했는가

초기에는 댓글 응답, 번역, 포스트 생성이 각각 독립 프로세스(3개 systemd 서비스)로 운영되었습니다. 문제는:

Claude Code CLI(--print) 호출 방식으로 응답 시간 9.7초, 디스크 688MB 소모
systemd 유닛 6개 관리 부담
프로세스 간 상태 공유 불가

이를 1개 프로세스로 통합하면서 직접 LLM API 호출로 전환했습니다. 결과:

지표	Before	After
응답 시간	9.7초	1.7초
디스크 사용	688MB	~50MB
systemd 유닛	6개	1개
프로세스	3개	1개

아키텍처

class BlogAgent:
 """1 프로세스 = Flask (webhook) + Scheduler (timer) + LLM Client"""
 
 def __init__(self):
 self.config = AgentConfig.from_credentials()
 self.llm = LLMClient(self.config) # ZAI glm-4.7
 self.api = BlogAPIClient(self.config) # ec1 Blog API
 
 # 핸들러
 self.comment = CommentHandler(self.llm, self.config)
 self.translate = TranslateHandler(self.api)
 self.post_gen = PostGenerator(self.llm, self.api)
 
 # 스케줄러
 self.scheduler = Scheduler()
 self.scheduler.every(hours=6, task=self.translate.check_and_sync)
 self.scheduler.daily_at(hour=9, task=self.post_gen.generate_and_publish)

모듈별 동작

1. CommentHandler — AI 댓글 응답

GitHub Discussions의 Webhook 이벤트를 수신하여 자동으로 AI 댓글을 생성합니다.

[사용자 댓글] → GitHub Webhook → arm1 Flask → CommentHandler
 → LLM 호출 (ZAI glm-4.7) → 답변 생성 → GitHub API로 댓글 게시

트리거: Webhook 이벤트 기반 (실시간)
필터링: 블로그 소유자 댓글, AI 생성 댓글은 건너뜀
보안: HMAC-SHA256 Webhook 시크릿 검증, Flask-Limiter 적용

2. TranslateHandler — 자동 번역 트리거

6시간마다 ec1의 Blog API에 번역 동기화를 요청합니다.

[Scheduler 6h] → TranslateHandler.check_and_sync()
 → POST /translate/sync → ec1 Blog API가 실제 번역 수행

arm1은 번역을 직접 수행하지 않고, ec1 API에 트리거만 보냅니다. 실제 번역 로직은 ec1의 translator.py에 있습니다.

3. PostGenerator — 자동 포스트 생성

매일 오전 9시에 기술 블로그 포스트를 자동 생성합니다.

[Scheduler 09:00 KST] → PostGenerator.generate_and_publish()
 → 기존 주제 수집 → RSS 트렌드 참조 → LLM으로 콘텐츠 생성
 → 중복 검사 → Blog API로 게시

중복 방지가 핵심입니다. difflib.SequenceMatcher로 새 제목과 최근 100개 기존 제목의 유사도를 비교합니다:

def _is_duplicate_title(self, new_title, existing_titles):
 """threshold 0.6 이상이면 중복으로 판정"""
 new_lower = new_title.lower().strip()
 for title in existing_titles[-100:]:
 ex_lower = title.lower().strip()
 ratio = difflib.SequenceMatcher(None, new_lower, ex_lower).ratio()
 if ratio >= 0.6:
 return True
 return False

ec1: Blog API 번역 시스템

Gemini로의 전환

초기에는 ZAI(glm-4.7)로 번역을 수행했으나, 치명적인 문제가 발생했습니다:

glm-4.7은 reasoning 모델로, max_tokens 예산을 reasoning_content(내부 사고 과정)에 먼저 소진합니다. max_tokens=256이면 reasoning에 256토큰을 모두 쓰고, 실제 content는 빈 문자열이 됩니다.

이로 인해 9개 영문 게시글의 제목이 빈 문자열로 번역되는 사고가 발생했습니다.

해결책: Gemini 2.5 Flash Lite로 교체.

항목	ZAI (이전)	Gemini (현재)
모델	glm-4.7 (reasoning)	gemini-2.5-flash-lite
번역 시간	~30초/포스트	~8초/포스트
비용	API 유료	무료 (1,500건/일)
빈 응답 문제	발생	없음

OpenAI-Compatible 엔드포인트

Gemini는 OpenAI 호환 API를 제공합니다. 기존 코드를 한 줄도 바꾸지 않고 base URL만 교체하면 됩니다:

LLM_BASE_URLS = {
 "GEMINI": "https://generativelanguage.googleapis.com/v1beta/openai",
 "ZAI": "https://api.z.ai/api/coding/paas/v4",
}

번역 매칭 로직

한국어↔영어 게시글 페어링은 날짜 접두사 매칭을 사용합니다:

ko: 2026-05-04-001-개발-생산성-17배-극대화-deepseek-v4와-...
en: 2026-05-04-001-개발-생산성-17배-극대화-deepseek-v4와-...
 ↑ 같은 접두사 = 같은 게시글

slug의 언어가 다를 수 있지만, YYYY-MM-DD-NNN 부분이 같으면 같은 게시글로 인식합니다. 이 방식의 전제 조건은 같은 날짜에 같은 번호가 2개 이상 존재하면 안 된다는 것입니다.

Title-in-Body 번역 기법

제목을 별도 API 호출로 번역하면 reasoning 모델에서 빈 결과가 나오는 문제가 있었습니다. 해결책은 제목을 본문 첫 줄에 포함시키는 것:

# 번역 요청 시
prompt = f"# {original_title}\n\n{original_body}"

# 번역 결과에서 제목 추출
if translated.lstrip().startswith("# "):
 lines = translated.lstrip().split("\n", 1)
 extracted_title = lines[0].lstrip("# ").strip()
 translated_body = lines[1].lstrip("\n")

하나의 API 호출로 제목과 본문을 동시에 번역하므로, 맥락이 보존되고 토큰도 절약됩니다.

LLM 전략: 역할별 모델 분리

하나의 LLM으로 모든 작업을 처리하지 않습니다. 작업 성격에 맞춰 모델을 분리했습니다.

작업	서버	모델	이유
댓글 AI 응답	arm1	ZAI glm-4.7	대화형, 한국어 품질 우수
포스트 생성	arm1	ZAI glm-4.7	긴 글 생성, 창의성 필요
번역 (ko→en)	ec1	Gemini Flash Lite	비추론형, 빠르고 무료

핵심 원칙: reasoning 모델은 번역에 쓰지 않는다. reasoning 모델은 내부 사고에 토큰을 소비하므로, 단순 변환 작업에는 비추론형 모델이 적합합니다.

모니터링과 운영

헬스체크 엔드포인트

# arm1 에이전트
curl http://arm1:8081/health
# → {"status":"healthy","agent":"blog-agent","scheduler_jobs":2,"uptime_sec":...}

curl http://arm1:8081/status
# → {"scheduler":[{"name":"auto-translate","last_run":...},{"name":"post-generator","last_run":"2026-05-04"}]}

# ec1 Blog API
curl https://blog.example.com/api/health
# → {"status":"healthy","version":"2.0.0"}

관찰 포인트

지표	정상 범위	알림 조건
arm1 uptime	>0	서비스 다운
scheduler_jobs	2	≠ 2
번역 동기화	ko=en 개수 일치	차이 발생
포스트 생성	매일 1건	24시간 이상 미생성

교훈과 운영 팁

1. Reasoning 모델의 함정

max_tokens가 reasoning과 content를 합산한다는 것을 문서에서 명시하지 않는 경우가 많습니다. 빈 응답이 나오면 finish_reason을 확인하세요 — "length"라면 토큰 예산 부족입니다.

2. OpenAI-Compatible 패턴의 가치

번역 제공자를 ZAI에서 Gemini로 바꿀 때 코드 변경이 base URL 1줄이었습니다. 처음부터 OpenAI-compatible 인터페이스로 추상화하면 LLM 교체 비용이 극적으로 줄어듭니다.

3. 날짜 접두사 매칭의 제약

YYYY-MM-DD-NNN 패턴에서 같은 날짜에 같은 번호가 2개 이상 존재하면 번역 매칭이 깨집니다. PostGenerator에서 새 게시글 생성 시 해당 날짜의 마지막 번호 + 1을 확인하는 로직이 필수입니다.

4. 통합 프로세스의 이점

3개 독립 서비스를 1개로 통합하면서 얻은 것:

상태 공유 (LLM 클라이언트, 설정, API 클라이언트를 한 번만 초기화)
배포 단순화 (systemd 유닛 1개)
디버깅 용이 (로그가 한 곳에 모임)

향후 계획

arm1 에이전트의 LLM도 Gemini로 통합 검토
댓글 품질 평가 파이프라인 (자동 생성 댓글의 적절성 모니터링)
번역 품질 자동 검증 (역번역 비교)
AgentForge 프레임워크를 통한 에이전트 간 협업 확대

블로그 자동화는 “완전 자동"이 아니라 “최소 개입"을 목표로 합니다. AI가 생성한 콘텐츠를 사람이 검토하고, 시스템이 이상 징후를 감지하면 운영자에게 알리는 구조가 안정적인 운영의 핵심입니다.

개발 생산성 17배 극대화: DeepSeek V4와 Claude Code로 구축하는 저비용 AI 에이전트 루프

Mon, 04 May 2026 09:01:31 +0900

개발 생산성 17배 극대화: DeepSeek V4와 Claude Code로 구축하는 저비용 AI 에이전트 루프

최근 Hacker News에 DeepClaude라는 흥미로운 프로젝트가 소개되었습니다. Claude Code의 에이전트 루프(Agent Loop) 기능에 DeepSeek V4 Pro를 결합하여 기존 대비 17배 낮은 비용으로 동일한 성능을 내는 하이브리드 아키텍처입니다.

이 글에서는 단순히 흥미로운 소식을 전달하는 것에 그치지 않고, 실제 개발 환경에서 Claude Code와 DeepSeek V4를 연동하여 비용 효율적인 AI 코딩 어시스턴트를 구축하는 방법을 구체적으로 다루겠습니다. 특히, MCP(Model Context Protocol)를 활용해 깃허브(GitHub)와 파일 시스템을 제어하는 방법까지 포함하여 완성도 있는 가이드를 제공합니다.

1. 왜 DeepSeek V4와 Claude Code인가?

Claude Code는 강력한 ‘에이전트 루프’ 기능을 제공합니다. AI가 스스로 코드를 작성하고, 실행하고, 오류를 수정하며 목표를 달성할 때까지 반복하는 자동화 프로세스입니다. 하지만 고품질의 Sonnet 모델을 지속적으로 사용하기에는 비용 부담이 큽니다.

여기서 DeepSeek V4 Pro가 등장합니다. DeepSeek V4는 최근 오픈소스 진영에서 가장 주목받는 모델 중 하나로, 복잡한 추론(Reasoning) 능력은 물론 코드 생성에서도 뛰어난 성능을 보여줍니다. 무엇보다 가성비가 압도적입니다.

DeepClaude 접근법의 핵심 전략:

플래너(Planner): 작업을 분석하고 계획 수립에는 기존 Claude 모델 사용 (일회성 사용)
워커(Worker): 실제 코드 작성 및 수정 반복문(Run Loop)에는 DeepSeek V4 사용 (다량 사용)

이 구조를 통해 전체 비용을 17/1로 줄이면서도 작업 완료도는 유지할 수 있습니다.

2. 사전 준비: MCP 서버 환경 구성

이 아키텍처를 구현하기 위해서는 AI가 로컬 환경의 파일을 읽고 쓸 수 있어야 합니다. 이를 위해 이전 포스트에서 다룬 MCP 서버 개념을 응용하여 설정하겠습니다.

2.1. MCP 설정 파일 구성 (`mcp_config.json`)

AI 에이전트가 프로젝트 폴더에 접근할 수 있도록 설정합니다. 로컬에 mcp_config.json 파일을 생성하고 아래 내용을 작성하세요.

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/Projects/DeepAgent"],
 "env": {
 "ALLOWED_DIRECTORIES": "/Users/yourname/Projects/DeepAgent"
 }
 },
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"]
 }
 }
}

filesystem: 에이전트가 코드를 생성하고 수정할 경로를 지정합니다.
github: (선택 사항) 깃허브 이슈나 PR을 생성하려면 토큰 환경 변수가 필요할 수 있습니다.

3. DeepSeek V4와 Claude Code 연동 구현

이제 실제 코드를 작성하여 두 모델을 오가며 작업을 수행하는 파이썬 스크립트를 구현해 보겠습니다. 이 스크립트는 ‘하이브리드 에이전트’의 핵심 로직입니다.

3.1. 의존성 설치

pip install openai anthropic

3.2. 하이브리드 에이전트 코드 구현 (`hybrid_agent.py`)

이 코드는 Anthropic API와 **OpenAI 호환 API(DeepSeek)**를 혼용하여 사용합니다.

import os
import json
from openai import OpenAI
from anthropic import Anthropic

# 설정: API 키는 환경 변수로 관리하세요
DEEPSEEK_API_KEY = os.getenv("DEEPSEEK_API_KEY")
ANTHROPIC_API_KEY = os.getenv("ANTHROPIC_API_KEY")

def create_hybrid_agent(task_description: str, max_iterations: int = 5):
 """
 DeepSeek V4(Worker)와 Claude(Planner)를 결합한 하이브리드 에이전트 함수
 """
 
 # 1. 모델 클라이언트 초기화
 # DeepSeek V4는 OpenAI SDK를 통해 접근 (예시)
 worker_client = OpenAI(
 api_key=DEEPSEEK_API_KEY,
 base_url="https://api.deepseek.com/v1" # 실제 엔드포인트 확인 필요
 )
 planner_client = Anthropic(api_key=ANTHROPIC_API_KEY)

 print(f"[System] 작업 시작: {task_description}")
 
 # 2. Claude(Planner)에게 초기 계획 수립 요청
 planning_prompt = f"""
 당신은 소프트웨어 아키텍트입니다. 다음 작업을 수행하기 위한 구체적인 단계별 계획을 세워주세요.
 작업: {task_description}
 
 응답은 JSON 형식의 단계 리스트로만 해주세요.
 예: {{"steps": ["파일 생성", "로직 구현", "테스트 실행"]}}
 """
 
 try:
 message = planner_client.messages.create(
 model="claude-3-5-sonnet-20241022",
 max_tokens=1024,
 messages=[{"role": "user", "content": planning_prompt}]
 )
 plan_text = message.content[0].text
 print(f"[Planner] 계획 수립 완료: {plan_text}")
 except Exception as e:
 print(f"[Error] 계획 수립 실패: {e}")
 return

 # 3. DeepSeek V4(Worker) 루프 실행
 current_context = f"작업 목표: {task_description}\n계획: {plan_text}"
 
 for i in range(max_iterations):
 print(f"\n--- Loop {i+1}/{max_iterations} (Worker: DeepSeek V4) ---")
 
 try:
 response = worker_client.chat.completions.create(
 model="deepseek-chat", # DeepSeek V4 모델명
 messages=[
 {"role": "system", "content": "당신은 계획에 따라 코드를 작성하고 수정하는 전문 개발자입니다."},
 {"role": "user", "content": current_context}
 ],
 temperature=0.3
 )
 
 worker_output = response.choices[0].message.content
 print(f"[Worker] 실행 결과:\n{worker_output[:500]}...\n") # 출력 요약
 
 # (실제 구현 시 여기서 MCP 툴을 호출하여 파일을 쓰거나 커맨드를 실행함)
 # file_system_tool.write_file(path="main.py", content=worker_output)
 
 # 종료 조건 확인 (예: "TASK_COMPLETE" 키워드)
 if "완료" in worker_output or "TASK_COMPLETE" in worker_output:
 print("[System] 작업이 성공적으로 완료되었습니다.")
 break
 
 # 피드백 루프를 위한 컨텍스트 업데이트
 current_context += f"\n\n이전 시도 결과:\n{worker_output}\n\n계속해서 진행하거나 오류를 수정하세요."
 
 except Exception as e:
 print(f"[Error] Worker 실행 중 오류 발생: {e}")
 break

# 실행 예시
if __name__ == "__main__":
 create_hybrid_agent(
 task_description="Next.js API 핸들러를 작성하여 /hello 엔드포인트를 생성하고, TypeScript 타입 검증을 포함해주세요."
 )

3.3. 코드 설명

Planner (Claude): anthropic 라이브러리를 사용하여 사용자의 요구사항을 분석하고, 작업의 순서를 정의합니다. 이 과정은 한 번만 발생하므로 고비용 모델을 사용해도 전체 비용에 큰 영향이 없습니다.
Worker (DeepSeek V4): openai 라이브러리를 통해 DeepSeek API를 호출합니다. max_iterations만큼 루프를 돌며 코드를 생성하고, 가상의 피드백(또는 실제 실행 결과)을 받아 수정을 거듭합니다. 이 부분이 가장 많은 토큰을 소비하는 곳입니다.

4. 트러블슈팅 및 팁

1. DeepSeek API 호환성: DeepSeek V4 Pro는 현재 OpenAI SDK와 호환되는 방식으로 제공되는 경우가 많지만, 베이스 URL(Base URL) 설정이 필요할 수 있습니다. (예: https://api.deepseek.com) 공식 문서를 확인해 주세요.

2. 컨텍스트 윈도우(Context Window): DeepSeek 모델은 보통 128k 이상의 긴 컨텍스트 윈도우를 지원합니다. 이는 긴 코드베이스를 분석하거나 대화 기록을 유지하기에 매우 유리합니다. 반복문(Loop)이 돌면서 컨텍스트가 길어지더라도 성능 저하가 적습니다.

3. MCP 통합: 위 파이썬 코드는 단순 예시입니다. 실제로는 mcp_config.json에 정의된 서버와 통신하여 파일 시스템에 접근해야 합니다. 이를 위해 stdio를 통해 MCP 서버와 통신하는 클라이언트 로직을 hybrid_agent.py 내부에 구현해야 완전한 자동화가 가능합니다.

5. 결론: 비용과 성능의 균형

개발자에게 AI는 단순한 채팅창이 아니라 **‘행동하는 에이전트’**가 되어가고 있습니다. 하지만 무비용으로 GPT-4o나 Claude Sonnet을 남용하는 것은 현실적이지 않습니다.

DeepSeek V4와 같은 고성능 오픈소스 모델을 **‘Worker’**로 두고, 고비용 모델을 **‘Planner’**로 활용하는 하이브리드 전략은, 향후 AI 에이전트 개발의 표준적인 패턴이 될 것입니다.

지금 바로 위 코드를 테스트해 보시고, 귀하의 개발 워크플로우에 17배의 효율성을 더해보세요.

블로그 AI 자동 댓글 시스템 구축기 (1/3) — 아키텍처와 구현

Sun, 03 May 2026 01:00:00 +0900

개요

블로그 댓글에 AI가 자동으로 응답하는 시스템을 구축했습니다. 독자가 블로그 포스트에 댓글을 남기면, AI 어시스턴트가 포스트 컨텍스트를 분석하여 기술적으로 정확하면서도 친절한 답변을 자동으로 생성합니다.

이 시리즈는 3부작으로 구성됩니다:

1부 (이 글): 전체 아키텍처 설계와 핵심 코드 구현
2부: 파일 기반 인증, 권한 관리, 보안 강화
3부: systemd 배포, nginx 프록시, 트러블슈팅

시스템 아키텍처

전체 데이터 흐름

독자 댓글 작성
 ↓
[giscus] → GitHub Discussions에 댓글 생성
 ↓
[GitHub Webhook] → HTTP POST 전송
 ↓
[nginx reverse proxy] → 헤더 포워딩
 ↓
[Flask Worker] → 시그니처 검증 → 댓글 분석
 ↓
[Claude Code CLI] → AI 응답 생성
 ↓
[GitHub GraphQL API] → Discussion에 답변 게시
 ↓
[giscus] → 블로그에 답변 표시

이 아키텍처에서 핵심은 giscus가 GitHub Discussions를 댓글 저장소로 사용한다는 점입니다. 따라서 GitHub Webhook으로 새 댓글 이벤트를 수신하고, 같은 GitHub API로 응답을 게시할 수 있습니다.

구성 요소

구성 요소	역할	기술
giscus	블로그 댓글 위젯	GitHub Discussions 기반
GitHub Webhook	이벤트 전달	`discussion_comment` 이벤트
nginx	리버스 프록시	헤더 포워딩, SSL 터미네이션
Flask Worker	웹훅 수신 및 처리	Python, Flask, Flask-Limiter
Claude Code	AI 응답 생성	`--print` 모드 CLI 호출
GitHub GraphQL	응답 게시	Mutation API

giscus 설정

Hugo 블로그에 giscus를 통합하려면 hugo.toml에 다음 설정이 필요합니다:

[params]
 [params.comments]
 enabled = true
 provider = "giscus"
 [params.comments.giscus]
 repo = "yarang/blogs"
 repoId = "YOUR_REPO_ID"
 category = "General"
 categoryId = "YOUR_CATEGORY_ID"
 mapping = "pathname"
 strict = "0"
 reactionsEnabled = "1"
 emitMetadata = "0"
 inputPosition = "bottom"
 lang = "ko"
 theme = "noborder_gray"

mapping = "pathname"은 포스트 URL 경로를 기준으로 Discussion을 매핑합니다. 이렇게 하면 각 블로그 포스트마다 독립적인 Discussion이 생성됩니다.

GitHub Webhook 구성

GitHub 리포지토리 Settings > Webhooks에서:

Payload URL: https://your-domain/webhook
Content type: application/json
Secret: HMAC-SHA256 서명용 시크릿 (보안 편에서 상세히 다룸)
Events: Discussion comments 선택

Webhook은 댓글이 생성될 때마다 discussion_comment 이벤트를 Flask 워커로 전송합니다.

Flask 워커 구현

프로젝트 구조

auto-comment-worker/
├── scripts/
│ └── auto-comment-worker.py # 메인 워커
├── deploy/
│ └── auto-comment-worker.service # systemd 서비스
├── venv/ # Python 가상환경
└── logs/
 └── audit.log # 감사 로그

핵심 의존성

from flask import Flask, request, jsonify
from flask_limiter import Limiter
from flask_limiter.util import get_remote_address
from marshmallow import Schema, fields, validate, ValidationError

Flask: 경량 웹 프레임워크로 Webhook 엔드포인트 제공
Flask-Limiter: 속도 제한으로 남용 방지 (분당 10회)
marshmallow: 요청 스키마 검증으로 안전한 데이터 파싱

웹훅 엔드포인트

@app.route('/webhook', methods=['POST'])
@limiter.limit("10 per minute")
def github_webhook():
 """GitHub Webhook 수신"""
 # 1. 시그니처 검증
 signature = request.headers.get('X-Hub-Signature-256')
 if not verify_webhook_signature(request.data, signature):
 log_audit('SIGNATURE_INVALID', {'ip': request.remote_addr})
 return jsonify({'status': 'unauthorized'}), 401

 # 2. 요청 스키마 검증
 schema = WebhookSchema()
 try:
 payload = schema.load(request.json)
 except ValidationError as err:
 return jsonify({'status': 'invalid'}), 400

 # 3. 댓글 정보 추출 및 필터링
 comment = payload.get('comment', {})
 discussion = payload.get('discussion', {})
 original_author = comment.get('user', {}).get('login', '사용자')

 # 블로그 소유주의 댓글이면 무시
 if _is_blog_owner(original_author):
 return jsonify({'status': 'owner_comment_ignored'}), 200

 # AI가 생성한 댓글이면 무시 (무한 루프 방지)
 if _is_ai_generated_comment(comment.get('body', '')):
 return jsonify({'status': 'ai_comment_ignored'}), 200

 # 4. AI 응답 생성 및 게시
 discussion_graphql_id = get_discussion_graphql_id(
 repo_owner, repo_name, discussion_number
 )
 context = f"제목: {discussion_title}\n\n내용: {discussion_body}"
 reply = analyze_comment(context, comment_body)
 post_reply_graphql(discussion_graphql_id, comment_body, original_author, reply)

핵심 흐름은 4단계입니다:

시그니처 검증: HMAC-SHA256으로 요청이 GitHub에서 왔는지 확인
스키마 검증: marshmallow로 페이로드 구조 검증
필터링: 블로그 소유주와 AI 자신의 댓글을 무시 (무한 루프 방지)
응답: Claude Code로 AI 응답 생성 후 GraphQL API로 게시

무한 루프 방지

AI가 생성한 댓글에 다시 AI가 응답하면 무한 루프에 빠집니다. 이를 방지하기 위해 마커 기반 감지를 사용합니다:

def _is_ai_generated_comment(body: str) -> bool:
 """AI가 생성한 댓글인지 식별"""
 ai_markers = [
 '🤖 AI 어시스턴트',
 'AI 어시스턴트',
 'AgentForge',
 'Claude Code로 자동 생성',
 '자동 생성되었습니다'
 ]
 body_lower = body.lower()
 return any(marker.lower() in body_lower for marker in ai_markers)

AI 응답을 게시할 때 반드시 이 마커들 중 하나를 본문에 포함합니다:

body = f"""---
**🤖 AI 어시스턴트**

{safe_reply}

*이 댓글은 AgentForge + Claude Code로 자동 생성되었습니다.*
---
"""

Claude Code CLI 호출

Claude Code의 --print 모드를 사용하여 비대화형으로 AI 응답을 생성합니다:

def analyze_comment(context: str, comment: str) -> str:
 """AgentForge 설정으로 Claude Code 실행"""
 prompt = f"""## 블로그 포스트 문맥
{context[:2000]}

## 독자 댓글
{comment}

이 댓글에 대한 응답을 작성해주세요.
- 기술 블로그 어시스턴트로서 전문적이면서 친절하게
- 200자 이내로 간결하게
- 필요한 경우 추가 정보나 링크 제시
"""

 cmd = [
 CLAUDE_CODE_PATH,
 '--settings', AGENTFORGE_CONFIG,
 '--print', prompt
 ]

 result = run(cmd, capture_output=True, text=True, timeout=60)

 if result.returncode == 0 and result.stdout.strip():
 return result.stdout.strip()

 return "의견 감사합니다! 기술적인 부분에 대해 더 논의해보면 좋을 것 같습니다. 🙏"

--settings 플래그로 AgentForge 전용 설정 파일을 지정합니다. 이 설정 파일에서 모델, 토큰 제한 등을 관리할 수 있습니다.

--print 플래그는 Claude Code를 비대화형 모드로 실행하여 결과를 stdout으로 출력합니다. 대화형 모드와 달리 프롬프트-응답 한 번으로 종료됩니다.

GitHub GraphQL API 통합

giscus는 GitHub Discussions를 사용하므로, 응답도 GitHub GraphQL API로 게시해야 합니다.

Discussion GraphQL ID 조회:

def get_discussion_graphql_id(repo_owner, repo_name, discussion_number):
 query = """
 query($owner: String!, $name: String!, $number: Int!) {
 repository(owner: $owner, name: $name) {
 discussion(number: $number) {
 id
 }
 }
 }
 """
 variables = {
 "owner": repo_owner,
 "name": repo_name,
 "number": discussion_number
 }

 response = requests.post(
 GITHUB_API_URL,
 json={"query": query, "variables": variables},
 headers={
 "Authorization": f"Bearer {GITHUB_TOKEN}",
 "Content-Type": "application/json"
 },
 timeout=10
 )

 if response.status_code == 200:
 data = response.json()
 return data["data"]["repository"]["discussion"]["id"]
 return None

Webhook 페이로드에는 Discussion의 REST API ID만 포함됩니다. 하지만 댓글을 게시하려면 GraphQL Node ID가 필요합니다. 따라서 먼저 GraphQL 쿼리로 Discussion의 Node ID를 조회한 뒤, 이를 사용하여 댓글을 게시합니다.

응답 게시 (Mutation):

def post_reply_graphql(discussion_graphql_id, original_comment, original_author, reply):
 query = """
 mutation($discussionId: ID!, $body: String!) {
 addDiscussionComment(input: {
 discussionId: $discussionId, body: $body
 }) {
 comment { id, databaseId }
 }
 }
 """
 # ... (요청 전송)

addDiscussionComment mutation은 Discussion 전체에 새 댓글을 추가합니다. 특정 댓글에 대한 답글(reply)이 아니라 Discussion 레벨의 댓글입니다.

입력 Sanitization

사용자 댓글은 외부 입력이므로 반드시 sanitize합니다:

def sanitize_comment(body: str) -> str:
 """사용자 입력 sanitization"""
 if not body:
 return body
 body = re.sub(r'<[^>]+>', '', body) # HTML 태그 제거
 body = html.escape(body) # HTML 엔티티 이스케이프
 body = body[:1000] # 길이 제한
 return body

XSS 공격을 방지하기 위해 HTML 태그를 제거하고, 남은 특수 문자를 이스케이프하며, 길이를 1000자로 제한합니다.

감사 로그

보안 이벤트를 추적하기 위한 감사 로그를 남깁니다:

def log_audit(event_type: str, details: dict):
 """보안 이벤트 감사 로그 기록"""
 with open(AUDIT_LOG, 'a') as f:
 f.write(json.dumps({
 'timestamp': datetime.utcnow().isoformat(),
 'event': event_type,
 'details': details
 }) + '\n')

기록하는 이벤트 유형:

SIGNATURE_INVALID: 웹훅 시그니처 검증 실패
INVALID_PAYLOAD: 잘못된 요청 페이로드
WEBHOOK_RECEIVED: 웹훅 수신 성공
AI_RESPONSE_SENT: AI 응답 게시 완료

마무리

이번 1부에서는 giscus, GitHub Webhook, Flask 워커, Claude Code CLI, GitHub GraphQL API를 연결하는 전체 아키텍처와 핵심 구현 코드를 다뤘습니다.

다음 2부에서는 이 시스템의 보안 강화 — 파일 기반 인증 관리, 파일 권한 검증, HMAC-SHA256 시그니처 검증 등을 상세히 다룹니다.

이 글은 AgentForge 블로그 자동 댓글 시스템 시리즈의 1부입니다.

[MCP] 블로그 자동화 시스템 구축

Sat, 21 Feb 2026 21:30:00 +0900

들어가며

Model Context Protocol(MCP)을 활용하여 Claude가 직접 블로그 포스트를 관리할 수 있는 시스템을 구축했습니다. 이 글에서는 구현 내용과 활용 방법을 소개합니다.

MCP란?

MCP(Model Context Protocol)는 Anthropic에서 개발한 프로토콜로, Claude와 외부 도구/데이터 소스 간의 표준화된 통신을 가능하게 합니다.

flowchart LR
 Claude <-->|MCP| MCPServer[MCP Server]
 MCPServer --> BlogFiles[Blog Files]

아키텍처

시스템 구성

blogs/
├── .claude/
│ ├── mcp_server.py # MCP 서버 구현
│ ├── requirements.txt # Python 의존성
│ ├── README.md # 사용 문서
│ └── claude_desktop_config.json
├── content/
│ └── posts/ # 블로그 포스트
└── static/
 └── images/ # 이미지 파일

MCP 서버 구조

class BlogManager:
 """블로그 관리 클래스"""

 def create_post(self, title, content, tags, categories):
 """새 포스트 생성"""

 def list_posts(self, limit, offset):
 """포스트 목록 조회"""

 def get_post(self, filename):
 """특정 포스트 조회"""

 def update_post(self, filename, **kwargs):
 """포스트 수정"""

 def delete_post(self, filename):
 """포스트 삭제"""

 def search_posts(self, query):
 """포스트 검색"""

제공 도구

flowchart TB
 subgraph Tools[MCP Tools]
 C1[blog_create_post]
 R1[blog_list_posts]
 R2[blog_get_post]
 R3[blog_search_posts]
 U1[blog_update_post]
 D1[blog_delete_post]
 end

 subgraph CRUD[CRUD Operations]
 Create[Create]
 Read[Read]
 Update[Update]
 Delete[Delete]
 end

 C1 --> Create
 R1 --> Read
 R2 --> Read
 R3 --> Read
 U1 --> Update
 D1 --> Delete

1. blog_create_post

새 블로그 포스트를 생성합니다.

{
 "title": "포스트 제목",
 "content": "Markdown 내용...",
 "tags": ["tag1", "tag2"],
 "categories": ["Development"],
 "draft": false
}

2. blog_list_posts

포스트 목록을 조회합니다.

{
 "limit": 20,
 "offset": 0
}

3. blog_get_post

특정 포스트의 상세 내용을 조회합니다.

{
 "filename": "2026-02-21-004-example.md"
}

4. blog_update_post

기존 포스트를 수정합니다.

{
 "filename": "2026-02-21-004-example.md",
 "content": "수정된 내용...",
 "draft": false
}

5. blog_search_posts

내용으로 포스트를 검색합니다.

{
 "query": "Docker"
}

자동화된 파일 명명

포스트 파일명은 다음 규칙으로 자동 생성됩니다:

flowchart LR
 User -->|Natural Language| Claude
 Claude -->|blog_create_post| MCP[MCP Server]
 MCP -->|Create File| Blog[YYYY-MM-DD-NNN-slug.md]

YYYY-MM-DD-NNN-slug.md

YYYY-MM-DD: 작성일
NNN: 일련번호 (001, 002, …)
slug: 제목에서 생성된 URL 친화적 문자열

예: 2026-02-21-004-mcp-blog-automation.md

활용 시나리오

flowchart LR
 User -->|Request| Claude
 Claude -->|blog_create_post| MCP[MCP Server]
 MCP -->|Create File| Blog[YYYY-MM-DD-NNN-slug.md]

1. 빠른 포스트 작성

사용자: "Python 리스트 컴프리헨션에 대한 짧은 팁 포스트를 작성해줘"

Claude: blog_create_post 도구를 사용하여 포스트 생성
→ 파일 생성: 2026-02-21-005-python-list-comprehension.md

2. 기존 포스트 검색 및 수정

사용자: "Docker 관련 포스트를 찾아서 최신 버전 정보로 업데이트해줘"

Claude: blog_search_posts("Docker") → 결과 확인 → blog_update_post

3. 시리즈 포스트 관리

사용자: "지금까지 작성한 에이전트 관련 포스트 목록을 보여줘"

Claude: blog_search_posts("agent") → 관련 포스트 나열

구현상의 고려사항

Front Matter 파싱

Hugo의 TOML 형식 front matter를 파싱합니다:

def _parse_front_matter(self, content: str) -> Dict[str, Any]:
 """TOML front matter 파싱"""
 if not content.startswith("+++"):
 return {}

 parts = content.split("+++", 2)
 # ... 파싱 로직

동시성 처리

파일명 충돌을 방지하기 위해 기존 파일 수를 확인합니다:

existing_count = len(list(self.content_dir.glob("*.md")))
filename = self._generate_filename(title, existing_count + 1)

확장 가능성

flowchart TB
 subgraph Current[Current Implementation]
 C1[blog_create_post]
 C2[blog_list_posts]
 C3[blog_get_post]
 C4[blog_update_post]
 C5[blog_delete_post]
 C6[blog_search_posts]
 end

 subgraph Future[Future Extensions]
 F1[blog_upload_image]
 F2[blog_suggest_tags]
 F3[blog_optimize_seo]
 F4[blog_publish]
 end

 Current --> Future

1. 이미지 처리

blog_upload_image: 이미지 업로드 및 최적화

2. 자동 태그 추천

blog_suggest_tags: 내용 분석 기반 태그 추천

3. SEO 최적화

blog_optimize_seo: 메타 설명, 키워드 최적화

4. 배포 자동화

blog_publish: git commit, push, 배포 트리거

결론

MCP를 활용한 블로그 자동화 시스템을 통해:

생산성 향상: 자연어로 포스트 작성 가능
일관성 유지: 파일 명명 규칙 자동 적용
접근성 개선: Claude를 통한 직관적인 블로그 관리

이 시스템은 지속적으로 확장 가능하며, 이미지 처리, SEO 최적화, 자동 배포 등의 기능을 추가할 수 있습니다.

참고 자료

영어 버전: English Version

Automation on Yarang's Tech Lair

Agentic Workflow: MCP 도구를 활용한 블로그 자동화 파이프라인 구축

Agentic Workflow: MCP 도구를 활용한 블로그 자동화 파이프라인 구축

배경: LLM과 개발 도구의 연결

MCP(Model Context Protocol) 아키텍처 설계

1. 블로그 서버의 MCP 서버 구현 (Rust)

2. 에이전트와의 통신: 프롬프트 엔지니어링

실전 적용: 자동화된 포스팅 워크플로우

워크플로우 실행 코드 (Python 예시)

고찰 및 향후 계획

결론

[AgentForge] 블로그 자동화 서비스 전체 아키텍처 — AI 댓글, 번역, 포스트 생성까지

시스템 토폴로지

arm1: 통합 블로그 에이전트

왜 통합했는가

아키텍처

모듈별 동작

1. CommentHandler — AI 댓글 응답

2. TranslateHandler — 자동 번역 트리거

3. PostGenerator — 자동 포스트 생성

ec1: Blog API 번역 시스템

Gemini로의 전환

OpenAI-Compatible 엔드포인트

번역 매칭 로직

Title-in-Body 번역 기법

LLM 전략: 역할별 모델 분리

모니터링과 운영

헬스체크 엔드포인트

관찰 포인트

교훈과 운영 팁

1. Reasoning 모델의 함정

2. OpenAI-Compatible 패턴의 가치

3. 날짜 접두사 매칭의 제약

4. 통합 프로세스의 이점

향후 계획

개발 생산성 17배 극대화: DeepSeek V4와 Claude Code로 구축하는 저비용 AI 에이전트 루프

개발 생산성 17배 극대화: DeepSeek V4와 Claude Code로 구축하는 저비용 AI 에이전트 루프

1. 왜 DeepSeek V4와 Claude Code인가?

2. 사전 준비: MCP 서버 환경 구성

2.1. MCP 설정 파일 구성 (mcp_config.json)

3. DeepSeek V4와 Claude Code 연동 구현

3.1. 의존성 설치

3.2. 하이브리드 에이전트 코드 구현 (hybrid_agent.py)

3.3. 코드 설명

4. 트러블슈팅 및 팁

5. 결론: 비용과 성능의 균형

블로그 AI 자동 댓글 시스템 구축기 (1/3) — 아키텍처와 구현

개요

시스템 아키텍처

전체 데이터 흐름

구성 요소

giscus 설정

GitHub Webhook 구성

Flask 워커 구현

프로젝트 구조

핵심 의존성

웹훅 엔드포인트

무한 루프 방지

Claude Code CLI 호출

GitHub GraphQL API 통합

입력 Sanitization

감사 로그

마무리

[MCP] 블로그 자동화 시스템 구축

들어가며

MCP란?

아키텍처

시스템 구성

MCP 서버 구조

제공 도구

1. blog_create_post

2. blog_list_posts

3. blog_get_post

4. blog_update_post

5. blog_search_posts

자동화된 파일 명명

활용 시나리오

1. 빠른 포스트 작성

2. 기존 포스트 검색 및 수정

3. 시리즈 포스트 관리

2.1. MCP 설정 파일 구성 (`mcp_config.json`)

3.2. 하이브리드 에이전트 코드 구현 (`hybrid_agent.py`)