Claude on Yarang's Tech Lair

MCP 서버 메타데이터 동기화: 개발자 생산성을 위한 컨텍스트 관리 전략

Mon, 22 Jun 2026 09:01:11 +0900

MCP 서버 메타데이터 동기화: 개발자 생산성을 위한 컨텍스트 관리 전략

최근 AI 에이전트와 개발 툴링의 통합이 깊어지면서, 우리는 **Model Context Protocol (MCP)**를 통해 블로그 시스템을 자동화하고 있지만, 여전히 하나의 성가신 문제가 남아 있습니다. 바로 AI와의 세션마다 프로젝트의 구조와 맥락을 반복해서 설명해야 하는 ‘토큰 낭비(Token Waste)’ 현상입니다.

Hacker News의 최신 글인 *Stop wasting tokens and re explaining your project between sessions*에서 언급된 것처럼, 프로젝트의 맥락을 일관되게 유지하는 것은 단순한 편의를 넘어 비용 효율과 직결됩니다.

이번 포스트에서는 MCP 서버가 제공하는 정적 리소스(Tools, Resources, Prompts)를 넘어, 동적 메타데이터(컨텍스트)를 어떻게 에이전트에게 효율적으로 공유할 수 있는지에 대한 실용적인 설계안을 제안합니다.

문제 정의: 매번 반복되는 ‘내 프로젝트 소개’

기존 MCP 클라이언트는 서버가 제공하는 tools 리스트를 통해 기능을 파악합니다. 예를 들어, write_post라는 툴이 있으면 Claude는 이를 호출하여 글을 씁니다. 하지만 Claude는 ‘이 블로그의 글쓰기 스타일은 어떤지?’, ‘최근 트렌드는 무엇인지?’ 와 같은 맥락(Context)을 알지 못합니다.

결국 사용자는 다음과 같은 프롬프트를 매번 달아줘야 합니다.

“블로그에 글을 써줘. 단, 스타일은 기술적이고 구체적이어야 하며, 최신 Hacker News 트렌드를 참고해야 해.”

이는 불필요한 토큰 소모를 유발합니다. 이를 해결하기 위해 MCP 서버 내에 프로젝트의 ‘아키텍처 설계서’나 ‘개발 가이드’를 리소스(Resource)로 통합하는 방법을 고려해볼 수 있습니다.

솔루션: 리소스 기반 메타데이터 제공

MCP 규격에서 Resources는 서버가 제공하는 데이터 조각입니다. 우리는 이를 단순한 파일 조회용이 아닌, **‘프로젝트 상태 머신(State Machine)’**으로 활용할 수 있습니다.

1. 아키텍처 문서 자동화

이전에 작성한 [ZeroClaw] 코드베이스 아키텍처 분석이나 [Multi-Agent] 파일 기반 아키텍처 설계와 같은 문서는 정적 파일로 존재하거나 Confluence 등에 흩어져 있을 수 있습니다. 이를 MCP 서버가 시작될 때 메모리에 로드하거나, 동적으로 생성하여 제공할 수 있도록 만듭니다.

2. Rust 구현 예제

Rust로 작성된 MCP 서버(예: blog-api-server)에 architecture_guide라는 리소스를 추가하는 코드를 작성해보겠습니다.

use jsonrpc_core::{Result, Params};
use std::collections::HashMap;
use serde_json::Value;

// 가상의 MCP 핸들러 구조체
pub struct BlogMcpServer {
 // 캐싱된 메타데이터
 cached_context: String,
}

impl BlogMcpServer {
 pub fn new() -> Self {
 // 서버 초기화 시 핵심 컨텍스트(아키텍처, 규칙)를 로드
 let context = r#"
 프로젝트: ZeroClaw Multi-Agent Runtime
 아키텍처: 파일 기반 이벤트 버스를 사용하는 비동기 멀티 에이전트 시스템.
 주요 규칙:
 1. 모든 에이전트는 독립된 스레드에서 실행됨.
 2. 통신은 JSON-RPC over MCP 프로토콜을 따름.
 3. 로그는 구조화된 JSON 형식으로 출력해야 함.
 "#;
 
 Self { cached_context: context.to_string() }
 }

 // MCP 리소스 조회 핸들러 (resources/read)
 pub fn handle_read_resource(&self, params: Params) -> Result<Value> {
 let params_obj: HashMap<String, Value> = params.parse()?;
 let uri = params_obj.get("uri").and_then(|v| v.as_str()).unwrap_or("");

 match uri {
 "context://architecture/guide" => {
 // 클라이언트가 요청할 때 캐싱된 컨텍스트 반환
 Ok(json!({
 "contents": [
 {
 "uri": uri,
 "mimeType": "text/plain",
 "text": self.cached_context.clone()
 }
 ]
 }))
 },
 "context://trends/latest" => {
 // 외부 RSS(Hacker News 등)를 실시간으로 페칭하여 제공 (동적 리소스)
 let trends = fetch_latest_hn_trends().await.unwrap_or_default();
 Ok(json!({
 "contents": [{
 "uri": uri,
 "mimeType": "application/json",
 "text": trends
 }]
 }))
 },
 _ => Err(Error::invalid_params("Unknown resource URI"))
 }
 }
}

async fn fetch_latest_hn_trends() -> Option<String> {
 // 실제로는 reqwest 등을 사용하여 RSS를 파싱
 // 예시를 위해 간단한 JSON 문자열 반환
 Some(r#"[{"title": "JSON-LD Explained", "link": "..."}]"#.to_string())
}

이 코드는 MCP 클라이언트가 context://architecture/guide URI를 통해 리소스를 요청하면, 사전에 정의된 프로젝트의 아키텍처 규칙을 즉시 반환합니다.

3. 프롬프트 자동 주입 (Prompt Injection)

이제 클라이언트(Claude 등)가 복잡한 설정을 하지 않도록, MCP 서버의 Prompts 기능을 활용하여 시스템 프롬프트를 자동으로 완성해주는 템플릿을 제공할 수 있습니다.

MCP 서버는 다음과 같은 프롬프트 템플릿을 노출할 수 있습니다.

Prompt Name: generate_blog_post Arguments: topic, tone

{
 "name": "generate_blog_post",
 "description": "Creates a technical blog post based on architecture context and latest trends.",
 "arguments": [
 { "name": "topic", "description": "Main topic", "required": true },
 { "name": "tone", "description": "Writing style", "required": false }
 ]
}

실제 구현 로직(Rust)은 다음과 같이 작동합니다.

pub fn handle_get_prompt(&self, params: Params) -> Result<Value> {
 let name = params.get("name").and_then(|v| v.as_str()).unwrap_or("");
 let args = params.get("arguments").and_then(|v| v.as_object()).unwrap_or(&json!(null));

 if name == "generate_blog_post" {
 let topic = args.get("topic").unwrap_or(&json!("general"));
 
 // 리소스에서 가져온 아키텍처 가이드를 프롬프트에 내장
 let system_instruction = format!(
 "You are writing for a blog defined by the following architecture:\n{}\n\nPlease write a post about: {}",
 self.cached_context, // 앞서 로드한 아키텍처 정보
 topic
 );

 Ok(json!({
 "messages": [
 {
 "role": "user",
 "content": {
 "type": "text",
 "text": system_instruction
 }
 }
 ]
 }))
 } else {
 Err(Error::invalid_params("Unknown prompt"))
 }
}

효과 및 기대 효과

이 접근 방식의 핵심은 **‘중복 제거(Duplication)’**입니다. Hacker News의 *Prefer duplication over the wrong abstraction*라는 글과 같이, 우리는 프로젝트의 본질을 단순화하기 위해 복잡한 추상화를 피하고, 대신 **필요한 정보(Context)를 필요한 곳(Prompt)에 통째로 복사(Duplication)**하여 넣습니다.

일관성 유지: 문서가 업데이트되면 MCP 서버만 재시작하거나 리소스를 갱신하면, 모든 세션에 최신 정보가 반영됩니다.
토큰 절약: 사용자가 매번 “내 프로젝트는 러스트로 짜여진 멀티 에이전트 시스템이야…“라고 설명할 필요가 없어집니다.
자동화 친화적: CI/CD 파이프라인에서 문서가 자동으로 생성되어 MCP 리소스로 등록되면, AI는 항상 최신 문서를 기반으로 코드를 생성하거나 리뷰할 수 있습니다.

결론

우리는 [ZeroClaw] 멀티 에이전트 아키텍처 설계안과 같은 문서를 단순히 ‘읽기용’으로 남겨두지 않고, 실행 가능한 AI의 뇌(Context)로 활용해야 합니다. MCP 서버에 이러한 메타데이터 동기화 계층을 추가하는 것은 복잡한 LLM 애플리케이션을 구축하기 위한 첫걸음이며, 개발자가 토큰을 낭비하지 않고 본질적인 로직에 집중하게 만드는 기반입니다.

다음 포스트에서는 이러한 메타데이터가 실제로 어떻게 Claude Code와 같은 팀 에이전트 통신 아키텍처에서 활용되는지 다루어보겠습니다.

4개의 AI에게 같은 코딩 태스크를 동시에 보내봤다

Fri, 08 May 2026 21:55:39 +0900

같은 버그 수정 태스크를 Claude, ZAI(GLM), OpenAI Codex, Google Gemini에게 동시에 던지면 어떤 일이 벌어질까?

이 질문에서 AgentForge 프로젝트가 시작됐다. 여러 LLM CLI를 NATS JetStream 메시지 큐로 묶어서 같은 태스크를 병렬로 처리하는 시스템을 만들었고, 그 과정에서 예상치 못한 발견들이 있었다. 이번 글은 “설정하면서 뭘 발견했나"에 집중한 비교 실험 기록이다.

시스템의 설계·구현 이야기는 2편에서 다룬다.

테스트한 AI 목록

최종적으로 운영 중인 워커 18개의 구성은 다음과 같다.

계열	모델	비고
Claude Code	claude-sonnet-4-6	메인 개발 워커
Claude Code	claude-sonnet-4-5	이전 세대 비교용
Claude Code	claude-haiku-4-5	경량·고속
Claude Code	claude-opus-4-6	최고 사양
Claude Code	claude-opus-4-5	이전 세대 비교용
ZAI (GLM)	glm-5.1	고사양 티어
ZAI (GLM)	glm-4.7	중간 티어
ZAI (GLM)	glm-4.5-air	경량 티어
OpenAI Codex	gpt-5.5
Codex	gpt-5.4	1M 컨텍스트
Codex	gpt-5.4-mini	400K 컨텍스트
Codex	gpt-5.3-codex	272K 컨텍스트
Google Gemini	gemini-2.5-flash
Gemini	gemini-2.5-pro	고사양
Gemini	gemini-2.5-flash-lite	경량

처음 시작할 때 목록은 훨씬 짧았다. 어떤 모델을 쓸 수 있는지 직접 실험해보면서 늘어났다.

발견 1: Claude 3.x 시리즈는 이미 접근 불가

Claude Code를 오래 써온 사람이라면 Claude 3.7 Sonnet, 3.5 Sonnet, 3.5 Haiku를 떠올릴 수 있다. 그래서 이 모델들도 워커로 추가하려 했다.

claude --model claude-3-7-sonnet-20250219 --print "hello"
# → "may not exist or no access"

세 모델 모두 동일한 오류. Claude 3 시리즈는 2026년 초에 EOL을 맞이했고, Claude Code CLI를 통한 접근이 차단됐다. 현재 Claude Code 구독으로 쓸 수 있는 것은 4.x 계열뿐이다.

결론: Claude 워커는 4.5/4.6 계열로만 구성했다.

발견 2: ChatGPT 계정 Codex는 모델 선택이 제한적이다

OpenAI Codex CLI는 ChatGPT Plus/Pro 계정이나 별도 API 키로 인증한다. ChatGPT 계정 기반일 경우 접근 가능한 모델이 제한된다.

codex --model gpt-5.5-pro "fix the bug"
# → "Model gpt-5.5-pro is not supported with ChatGPT account"

codex --model gpt-5.5 "fix the bug"
# → 정상 작동

ChatGPT 계정으로 사용할 수 있는 모델:

모델	컨텍스트	추론 수준
gpt-5.5	1M / 1M	High
gpt-5.4	1M / 1M	Medium
gpt-5.4-mini	400K / 400K	Medium
gpt-5.3-codex	272K / 400K	Medium

gpt-5.5-pro를 포함한 다른 모델은 모두 “not supported with ChatGPT account” 오류를 반환한다. API 키 방식이라면 더 많은 모델을 쓸 수 있지만, 그건 다른 접근 방식이다.

발견 3: Gemini CLI는 2.5 시리즈만 된다

Gemini CLI(gemini 바이너리)로 여러 모델을 테스트했다.

gemini -p "hello" -m gemini-2.0-flash
# → ModelNotFoundError: models/gemini-2.0-flash is not found

gemini -p "hello" -m gemini-1.5-pro
# → ModelNotFoundError

gemini -p "hello" -m gemini-2.5-flash
# → 정상 작동

현재 계정으로 접근 가능한 Gemini 모델:

gemini-2.5-flash — 기본 추천 모델
gemini-2.5-pro — 고사양
gemini-2.5-flash-lite — 경량

Gemini 2.0 이하 버전은 ModelNotFoundError를 반환한다. 계정 플랜이나 API 키 종류에 따라 다를 수 있지만, Gemini CLI 기준으로는 2.5 시리즈만 안정적으로 동작했다.

발견 4: ZAI는 Claude SDK로 우회할 수 있다

ZAI는 Anthropic API와 호환되는 엔드포인트를 제공하는 서비스다. 덕분에 Claude Code CLI에서 환경변수 두 개만 바꿔서 GLM 모델을 쓸 수 있다.

ANTHROPIC_BASE_URL=https://<ZAI endpoint> \
ANTHROPIC_AUTH_TOKEN=<ZAI_KEY> \
claude --model glm-5.1 --print "fix the bug"

Claude Code가 내부적으로 Anthropic Python SDK를 쓰기 때문에, ANTHROPIC_BASE_URL만 오버라이드하면 동일한 포맷으로 ZAI의 GLM 모델을 호출한다. 별도의 어댑터 코드 없이 기존 claude 백엔드를 그대로 재사용할 수 있다는 점이 흥미로웠다.

사용한 GLM 모델 3종:

glm-5.1 — 고사양 티어
glm-4.7 — 비용·성능 균형점
glm-4.5-air — 경량·고속

4-way Fan-out 비교 테스트

18개 워커 중 대표 4개(Claude Sonnet, GLM-5.1, Codex gpt-5.5, Gemini 2.5 Flash)에 동일한 Go 버그 수정 태스크를 동시에 발행했다.

태스크: "fix the off-by-one error in the binary search function"

응답 시간 (wall clock):

워커	모델	응답 시간
cc-go-dev-01	claude-sonnet-4-6	~8초
cc-zai-high-dev-01	glm-5.1	~12초
codex-py-dev-01	gpt-5.5	~15초
gemini-py-dev-01	gemini-2.5-flash	~10초

응답 시간보다 흥미로운 건 접근 방식의 차이다. Claude는 함수 전체를 리팩토링하는 경향이 있었고, Gemini는 최소한의 수정을 선호했다. Codex는 테스트 코드까지 함께 추가하는 경우가 많았다.

물론 이건 단일 태스크 결과라 통계적 의미는 없다. 벤치마크가 아니라 “실제로 동작하는지 확인"하는 수준의 검증이었다.

분산 워커: 두 번째 호스트 추가

워커들이 모두 한 서버에 있으면 비교 실험의 의미가 약해진다. 그래서 두 번째 호스트에 Claude 워커를 추가했다.

두 번째 호스트에서 NATS 브로커(첫 번째 호스트)에 접근하는 방법은 autossh 터널이다.

[Service]
ExecStart=autossh -N -L 4222:127.0.0.1:4222 broker-host

로컬의 4222 포트를 브로커로 포워딩하면 워커 코드 변경 없이 어느 호스트에서나 nats://127.0.0.1:4222로 접속할 수 있다.

이 방식의 장점: 워커는 브로커가 어디 있는지 알 필요가 없다. 항상 localhost:4222로 연결하면 된다.

운영하면서 가장 당황했던 순간

가장 곤혹스러운 상황은 NATS operator signing key를 분실한 것이었다. NATS JetStream은 NKey 기반 인증을 쓰는데, 신규 워커의 credentials를 발급하려면 operator/account의 signing key(nsc seed)가 필요하다.

nsc add user --account Services --name new-worker
# → "signing key not found"

백업이 없었다. 결국 NATS operator를 통째로 재생성하고, 모든 워커의 credentials를 새 권한 트리로 교체하는 대규모 컷오버를 진행했다. 서비스 다운타임은 약 60초였다.

교훈: NATS operator seed는 생성 즉시 오프라인 백업을 만들어라. 분실하면 재생성 외에 방법이 없다.

정리

이번 실험에서 얻은 실용적인 결론:

Claude 3.x는 EOL - 2026년 기준 Claude Code CLI에서 접근 불가. 4.x만 쓸 것.
Codex ChatGPT 계정은 모델 4종만 - gpt-5.5, 5.4, 5.4-mini, 5.3-codex. Pro 모델은 별도 API 키 필요.
Gemini는 2.5 시리즈만 - CLI 기준 이전 버전 접근 불가.
ZAI는 Claude SDK 환경변수 오버라이드로 통합 가능 - 별도 어댑터 불필요.
NATS NKey는 반드시 백업 - signing key 분실 = 전체 재발급.

다음 편에서는 이 워커들이 어떻게 연결되는지, 시스템 설계와 구현을 다룬다.

MCP 서버 시작하기: Claude Code와 통합하는 첫 번째 도구 만들기

Sun, 03 May 2026 10:47:00 +0900

MCP 서버 시작하기: Claude Code와 통합하는 첫 번째 도구 만들기

MCP(Model Context Protocol)는 Claude Code 및 다른 AI 도구와 통합할 수 있는 강력한 프로토콜입니다. 이 가이드에서는 첫 번째 MCP 서버를 만드는 과정을 단계별로 안내합니다.

MCP란 무엇인가?

MCP는 AI 에이전트가 외부 도구와 리소스에 접근할 수 있게 하는 표준 프로토콜입니다. 주요 특징:

표준화된 인터페이스: 다양한 도구를 통일된 방식으로 통합
리소스 공유: 파일, 데이터베이스 등의 리소스를 안전하게 접근
확장성: 새로운 도구를 쉽게 추가 가능

기본 MCP 서버 구조

// mcp-server-template.ts
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const server = new Server(
 {
 name: 'my-mcp-server',
 version: '1.0.0'
 },
 {
 capabilities: {
 tools: {},
 resources: {}
 }
 }
);

// 도구 등록 예시
server.setRequestHandler(ListToolsRequestSchema, async () => ({
 tools: [
 {
 name: 'my_tool',
 description: '내 도구 설명',
 inputSchema: {
 type: 'object',
 properties: {
 param1: {
 type: 'string',
 description: '파라미터 설명'
 }
 },
 required: ['param1']
 }
 }
 ]
}));

// 서버 시작
const transport = new StdioServerTransport();
await server.connect(transport);

실전 예제: 간단한 계산기 MCP 서버

// calculator-mcp-server.ts
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js';

const server = new Server(
 { name: 'calculator-server', version: '1.0.0' },
 { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
 tools: [
 {
 name: 'calculate',
 description: '기본 수학 연산 수행',
 inputSchema: {
 type: 'object',
 properties: {
 expression: {
 type: 'string',
 description: '계산할 수식 (예: "2 + 2")'
 }
 },
 required: ['expression']
 }
 }
 ]
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
 if (request.params.name === 'calculate') {
 const expression = request.params.arguments?.expression as string;
 try {
 // 안전한 계산을 위해 Function 대신 eval 사용
 const result = Function(`"use strict"; return (${expression})`)();
 return {
 content: [{
 type: 'text',
 text: `결과: ${result}`
 }]
 };
 } catch (error) {
 return {
 content: [{
 type: 'text',
 text: `계산 오류: ${error}`
 }],
 isError: true
 };
 }
 }
 return { content: [] };
});

Claude Code 설정

MCP 서버를 Claude Code에 등록하려면 ~/.config/claude/settings.json을 수정합니다:

{
 "mcpServers": {
 "calculator": {
 "command": "node",
 "args": ["/path/to/calculator-mcp-server.js"]
 }
 }
}

리소스 제공하기

// 리소스 리스트 제공
server.setRequestHandler(ListResourcesRequestSchema, async () => ({
 resources: [
 {
 uri: 'calc://history',
 name: '계산 기록',
 description: '최근 계산 이력',
 mimeType: 'application/json'
 }
 ]
}));

// 리소스 내용 제공
server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
 if (request.params.uri === 'calc://history') {
 return {
 contents: [{
 uri: request.params.uri,
 mimeType: 'application/json',
 text: JSON.stringify({ history: [] })
 }]
 };
 }
 throw new Error('리소스를 찾을 수 없습니다');
});

보안 고려사항

입력 검증: 모든 사용자 입력을 검증하고 제한
권한 제한: 최소 권한 원칙 적용
에러 처리: 민감 정보가 에러 메시지에 노출되지 않도록 주의
속도 제한: 과도한 요청을 방지하는 레이트 리밋 구현

배포 및 테스트

# 서버 빌드
npm run build

# 로컬 테스트
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node dist/server.js

# Claude Code에 통합 후 테스트
# 설정 파일 reload 후 Claude Code에서 도구 사용

다음 단계

더 복잡한 도구와 리소스 추가
프롬프트 템플릿 구현
에러 핸들링 개선
로깅 및 모니터링 추가

MCP 서버 개발은 Claude Code의 기능을 확장하고 자동화를 강화하는 훌륭한 방법입니다. 작은 프로젝트부터 시작하여 점진적으로 기능을 확장해보세요.

참고 자료

멀티모델 AI 에이전트 팀 설계: 조합형 아키텍처와 5팀 계층 구조

Mon, 30 Mar 2026 00:31:36 +0900

개요

블로그 시스템 구축을 위해 14명의 AI 전문가, 5개 팀, 4개 LLM 모델로 구성된 멀티모델 에이전트 팀을 설계했습니다. 핵심은 두 가지입니다.

조합형 에이전트(Composed Agent): 역할 정의와 실행 프로필을 분리해 재사용성 극대화
계층형 브릿지 리더십: 상위팀-하위팀 간 기술 리드의 이중 소속으로 소통 병목 해결

이 글에서는 최종 구조, 모델 배분 전략, 조합형 아키텍처 설계 과정을 공유합니다.

배경: 왜 멀티모델인가

하나의 LLM으로 모든 작업을 처리하면 두 가지 문제가 발생합니다.

비용: Claude Opus 수준의 모델로 14명 전문가를 실행하면 비용이 통제 불가능
적합성: 설계에는 빠른 추론이, 보안 분석에는 깊은 논리가, 구현에는 안정적인 코딩이 필요

그래서 작업 성격에 맞춰 모델을 분배했습니다.

최종 팀 구조

5개 팀, 14명 전문가, 4개 모델로 구성됩니다.

graph TD
 subgraph UPPER["상위팀 — 조정 팀 (steering-team) · consensus"]
 ORC["오케스트레이터
relay:steering-orchestrator"]
 DES["설계자
gemini:gemini-2.5-flash"]
 SEC["보안 검토자
codex:gpt-4o"]
 STL["백엔드 기술 리드
relay:developer-zai"]
 FTL["프론트엔드 기술 리드
relay:developer-zai"]
 DTL["데스크탑 기술 리드
relay:developer-zai"]
 INF["인프라 네트워크
gemini:gemini-2.5-flash"]
 SAD["서버 관리자
relay:developer-zai"]
 end

 subgraph LOWER_BE["백엔드 팀 · leader_decides"]
 BTL["백엔드 기술 리드"]
 BDEV["백엔드 개발자"]
 end

 subgraph LOWER_FE["프론트엔드 팀 · leader_decides"]
 FTL2["프론트엔드 기술 리드"]
 FDEV["프론트엔드 개발자"]
 FUX["UX 디자이너"]
 end

 subgraph LOWER_DT["데스크탑 팀 · leader_decides"]
 DTL2["데스크탑 기술 리드"]
 DDEV["데스크탑 개발자"]
 DUX["UX 디자이너"]
 end

 subgraph LOWER_INFRA["인프라 팀 · leader_decides"]
 SAD2["서버 관리자 (리더)"]
 INET["클라우드 네트워크"]
 DBA["DB 아키텍트"]
 end

 UPPER -.->|bridge| LOWER_BE
 UPPER -.->|bridge| LOWER_FE
 UPPER -.->|bridge| LOWER_DT
 UPPER -.->|bridge| LOWER_INFRA

 BTL --> BDEV
 FTL2 --> FDEV
 FTL2 --> FUX
 DTL2 --> DDEV
 DTL2 --> DUX
 SAD2 --> INET
 SAD2 --> DBA

팀별 상세

팀	유형	의사결정	리더	팀원 수
조정 팀	upper	consensus	오케스트레이터	8명 (브릿지 포함)
백엔드 팀	lower	leader_decides	백엔드 기술 리드	2명
프론트엔드 팀	lower	leader_decides	프론트엔드 기술 리드	3명
데스크탑 팀	lower	leader_decides	데스크탑 기술 리드	3명
인프라 팀	lower	leader_decides	서버 관리자	3명

인프라 팀 분리 결정

초기 설계에서는 DB 아키텍트와 서버 관리자가 백엔드 팀에 포함되어 있었습니다. 하지만 작업 공간(Workspace) 기준으로 분리했습니다.

graph LR
 subgraph 백엔드팀
 B["API 코드 작성
FastAPI, Python
workspace: VS Code / SSH"]
 end

 subgraph 인프라팀
 S["서버 관리
Docker, Ubuntu, Nginx
workspace: SSH 터미널"]
 N["클라우드 네트워크
Cloudflare Dashboard
workspace: 웹 콘솔"]
 D["DB 관리
PostgreSQL, 마이그레이션
workspace: psql / SSH"]
 end

 B -.->|API 배포| S
 B -.->|쿼리 최적화| D

분리 이유: 작업 공간이 다르면 같은 팀에 두는 것보다 분리하는 것이 자연스럽습니다.

모델 배분 전략

pie title 모델별 전문가 수
 "relay:developer-zai (GLM)" : 10
 "gemini:gemini-2.5-flash" : 2
 "codex:gpt-4o" : 1
 "zai:glm-4" : 1

모델	전문가 수	용도	선택 이유
relay:developer-zai	10명	구현, 운영, 리드	비용 효율적, 안정적 코딩
gemini:gemini-2.5-flash	2명	설계, 인프라 네트워크	빠른 응답, 외부 API 호출 용이
codex:gpt-4o	1명	보안 검토	높은 추론 능력, OWASP 지식
zai:glm-4	1명	컨텍스트 압축	무료 티어, 텍스트 요약 특화

10명의 구현 전문가를 GLM(저비용 모델)에 배정하여 전체 비용의 60-70%를 절감했습니다.

조합형 에이전트 아키텍처 (Composed Agent Pattern)

이번 설계의 핵심 혁신은 역할 정의(Expert)와 실행 프로필(Definition)의 분리입니다.

기존 방식의 문제

기존에는 역할과 실행 로직이 결합되어 변경 시 전체 재작성이 필요하고 재사용이 불가능했습니다.

조합형 방식

graph TD
 DEF["Definition
백엔드 개발자"]
 DEF --> BASE["Base: backend-core"]
 DEF --> CAP["Capabilities:
rest-api, crud, auth-jwt"]
 DEF --> PLAT["Platform: fastapi"]
 DEF --> POL["Policy: blog-default"]

 BASE --> |"조합"| RUN["런타임 에이전트"]
 CAP --> |"조합"| RUN
 PLAT --> |"조합"| RUN
 POL --> |"조합"| RUN

모듈 구조

agent-library/
├── definitions/ ← 14개 에이전트 정의
├── modules/
│ ├── base/ ← 6개 기본 모듈
│ ├── capabilities/ ← 15개 역량 모듈
│ ├── platforms/ ← 5개 플랫폼 모듈
│ └── policies/ ← 1개 정책
└── runs/ ← 실행 이력

장점

재사용성: rest-api 역량 모듈은 백엔드 개발자와 기술 리드가 공유
플랫폼 교체: platform: fastapi를 platform: django로 변경하면 즉시 전환
역량 확장: 새 역량 모듈을 추가하고 Definition에 연결만 하면 됨
정책 통일: 모든 에이전트가 동일한 blog-default 정책을 따름

전문가-Definition 매핑

전문가	Definition	Base	Capabilities	Platform
백엔드 개발자	backend-developer	backend-core	rest-api, crud, auth-jwt	fastapi
백엔드 기술 리드	backend-tech-lead	backend-core	rest-api, crud, code-review	fastapi
프론트엔드 개발자	frontend-developer	frontend-core	markdown-renderer, list-filter-sort	nextjs
서버 관리자	server-administrator	server-core	docker-management, nginx-config, postgres-admin	ubuntu
인프라 네트워크	infra-network-admin	infra-core	dns-management, ssl-certificates, rate-limiting	cloudflare
보안 검토자	security-auditor	specialist-core	security-audit	fastapi
컨텍스트 압축	context-compressor	specialist-core	context-compression	markdown

TLS 인증서 전략: Cloudflare Origin CA

프로덕션 환경의 TLS 인증서로 Let’s Encrypt 대신 Cloudflare Origin CA를 선택했습니다.

sequenceDiagram
 participant Client as 방문자
 participant CF as Cloudflare (Proxy)
 participant Nginx as Nginx (Origin)
 participant API as FastAPI

 Client->>CF: HTTPS 요청
 CF->>CF: Cloudflare 관리 인증서로 종료
 CF->>Nginx: Origin CA 인증서로 암호화
 Nginx->>API: HTTP (로컬)
 API-->>Nginx: 응답
 Nginx-->>CF: Origin CA로 암호화
 CF-->>Client: 응답

항목	Let’s Encrypt	Cloudflare Origin CA
유효 기간	90일 (갱신 필요)	15년 (갱신 불필요)
발급 방식	ACME 자동화 필요	Dashboard에서 수동 발급
복잡도	certbot 설정	인증서 파일 복사만

프로덕션 아키텍처:

Oracle Cloud ARM (4 OCPU, 24GB)
├── PostgreSQL (호스트 직접 설치)
├── Docker Compose
│ ├── blog-api (FastAPI)
│ ├── blog-frontend (Next.js standalone)
│ ├── MinIO (S3 호환 스토리지)
│ └── Nginx (Cloudflare Origin CA)
└── Cloudflare Proxy (Full Strict SSL)

Relay 플러그인: 에이전트 호출 메커니즘

팀 구조는 Relay 플러그인을 통해 Claude Code에서 실행됩니다.

sequenceDiagram
 participant User as 사용자
 participant Claude as Claude Code
 participant Plugin as Relay Plugin
 participant MCP as MCP 서버
 participant LLM as 외부 LLM

 User->>Claude: /relay:invoke-agent
 Claude->>Plugin: 전문가 slug로 정의 로드
 Plugin->>Plugin: Definition 조합 (base + capabilities + platform + policy)
 Plugin->>Plugin: backed_by 확인

 alt relay:developer-zai
 Plugin->>Claude: 내부 에이전트 실행
 else gemini:*
 Plugin->>MCP: gemini_mcp 서버 호출
 MCP->>LLM: Gemini API
 LLM-->>MCP: 응답
 MCP-->>Plugin: 결과
 else codex:*
 Plugin->>MCP: codex_mcp 서버 호출
 MCP->>LLM: OpenAI API
 LLM-->>MCP: 응답
 MCP-->>Plugin: 결과
 end

 Plugin-->>Claude: 최종 결과
 Claude-->>User: 응답

backed_by 네임스페이스

네임스페이스	MCP 서버	용도
`relay:developer-zai`	내부 에이전트	구현, 운영 (저비용)
`relay:steering-orchestrator`	내부 에이전트	조율, 최종 결정
`gemini:gemini-2.5-flash`	gemini_mcp	설계, 외부 API
`codex:gpt-4o`	codex_mcp	보안 분석
`zai:glm-4`	zai_mcp	컨텍스트 압축

설계 결정 이력

결정	대안	선택 이유
인프라 팀 분리	백엔드 팀에 포함	작업 공간이 다름 (SSH vs IDE)
Cloudflare Origin CA	Let’s Encrypt	15년 유효, 갱신 불필요
PostgreSQL 호스트 설치	Docker 컨테이너	단일 서버에서 메모리 효율 우선
조합형 에이전트	단일 정의 에이전트	모듈 재사용성, 플랫폼 교체 용이
GLM 다수 배정	Claude 다수 배정	60-70% 비용 절감

회고: 설계하며 배운 것

1. “완벽한 구조"보다 “실행 가능한 구조”

팀 구조, 모델 배정, 인프라 설정을 완벽하게 설계하려다 보면 시작조차 못 합니다.

2. 작업 공간이 곧 팀 경계

코드를 작성하는 사람과 서버를 관리하는 사람은 물리적 작업 환경이 다르고, 그것이 자연스러운 팀 경계가 됩니다.

3. 조합형 아키텍처의 가치

14명의 전문가, 5개 팀, 4개 모델이 얽히는 환경에서는 모듈 분리가 필수적입니다.

4. 비용은 설계 단계에서 결정된다

“이 작업에 꼭 고비용 모델이 필요한가?“를 매번 물어보면 자연스럽게 비용이 최적화됩니다.

다음 단계

Phase 1 구현 착수: DB, Auth, Post/Category CRUD, Docker
팀 운영 경험 공유: 실제 실행 중 겪은 문제와 해결 과정
성능 모니터링: 모델별 응답 시간, 비용 대비 품질 분석

이 글은 Claude Code + Relay 플러그인을 활용한 AI 에이전트 팀 구성 경험을 정리한 것입니다.

서버 관리의 효율을 높이는 도구: Server Status Checker Skill 소개

Mon, 09 Mar 2026 00:30:00 +0900

서버 관리의 효율을 높이는 도구: Server Status Checker Skill 소개

관리하는 서버가 점점 늘어나고 있나요?

서버마다 일일이 SSH로 접속하여 상태를 확인하는 일은 시간 낭비입니다. 여러 서버의 CPU, 메모리, 디스크 사용량을 한눈에 파악할 수 있다면 업무 효율이 크게 향상될 것입니다.

저도 그런 문제를 겪었습니다. 그래서 만들었습니다.

문제: 서버 모니터링의 반복 작업

DevOps 엔지니어나 시스템 관리자라면 한 번쯤 겪는 상황입니다:

서버별 SSH 접속 반복
top, htop, df 명령어 일일이 실행
엑셀이나 노션에 수동으로 상태 기록
서버 증가시 마다 관리 스크립트 수정

이 과정은 시간 낭비이자, 실수를 유발할 수 있는 반복 작업입니다.

해결책: Server Status Checker Skill

Server Status Checker는 Claude Code용 스킬로, SSH config 파일을 기반으로 모든 서버의 상태를 병렬로 확인합니다.

주요 기능

기능	설명
SSH config 자동 파싱	`~/.ssh/config` 파일에서 서버 목록 자동 발견
실시간 상태 확인	CPU, Memory, Disk, Uptime, Load 정보 수집
병렬 연결	asyncssh로 빠른 상태 확인 (초 단위)
그룹별 분류	GCP, OCI, GitHub, Blog, Local 등으로 자동 분류
온라인/오프라인 상태	✓ / ✗ 로 직관적인 상태 표시

사용법

# 전체 서버 상태 확인
/server-status-checker

# 특정 서버만 확인
/server-status-checker --server mini01

# JSON 형식으로 출력
/server-status-checker --json

# 상세 에러 메시지
/server-status-checker --verbose

출력 예시

=== Server Status Report ===

[GCP 서버]
✗ gcp-ajou-ec1 - Offline (Authentication failed)
✗ gcp-fcoinfup-ec1 - Offline (Authentication failed)

[OCI Ajou]
✓ oci-ajou-ec1 - Online
 CPU: 15.2% | Memory: 62.3% | Disk: 45.8%
 Uptime: 15 days | Load: 1.23 1.45 1.38
 OS: Ubuntu 22.04 LTS

[로컬 서버]
✓ mini01 - Online
 CPU: 6.7% | Memory: 45.2% | Disk: 5.0%
 Uptime: 2 days | Load: 2.17 2.11 1.94
 OS: macOS 26.3.1

기술적 세부사항

SSH Config 파싱

~/.ssh/config 파일을 파싱하여 다음 정보를 자동 추출합니다:

Host (호스트명)
HostName (IP 주소 또는 도메인)
User (사용자명)
Port (포트번호)
IdentityFile (SSH 키 경로)

비동기 병렬 처리

Python asyncssh 라이브러리를 활용하여 모든 서버에 동시에 접속합니다:

async def check_server(host: str):
 # SSH 접속 및 명령 실행
 result = await asyncssh.connect(...)
 return status

30대의 서버를 순차적으로 확인하면 5분이 걸리지만, 병렬 처리시 30초 내에 완료됩니다.

그룹 자동 분류

서버 이름 패턴을 기반으로 자동 분류합니다:

그룹	패턴	예시
GCP	`gcp-` 접두사	gcp-ajou-ec1, gcp-fcoinfup-ec1
OCI Ajou	`oci-ajou-` 접두사	oci-ajou-ec1
OCI Fcoinfup	`oci-fcoinfup-` 접두사	oci-fcoinfup-ec1
GitHub	`github-as-` 접두사	github-as-actions
Blog	`blog`	blog
Local	`mini`, `mac`	mini01, macbook-pro

시스템 메트릭 수집

각 서버에서 다음 정보를 수집합니다:

Linux:

CPU: /proc/stat 또는 psutil.cpu_percent()
Memory: /proc/meminfo 또는 psutil.virtual_memory()
Disk: psutil.disk_usage()
Uptime: /proc/uptime 또는 psutil.boot_time()
Load: /proc/loadavg 또는 os.getloadavg()

macOS:

CPU: psutil.cpu_percent()
Memory: psutil.virtual_memory()
Disk: psutil.disk_usage()
Uptime: psutil.boot_time()
Load: os.getloadavg()

GitHub 공개

이 스킬은 오픈소스로 공개되어 있습니다.

🔗 GitHub: https://github.com/yarang/skill-server-status-checker

설치 방법

git clone https://github.com/yarang/skill-server-status-checker.git
cp -r skill-server-status-checker ~/.claude/skills/server-status-checker

비즈니스 가치

측면	개선 효과
시간 절약	서버 확인 시간 90% 단축 (5분 → 30초)
실시간 모니터링	즉각적인 서버 상태 파악
중앙화된 관리	SSH config 단일 파일로 모든 서버 관리
자동화	반복 작업 제거로 인적 실수 최소화

활용 사례

1. 일일 서버 건강 확인

매일 아침 /server-status-checker 명령 하나로 모든 서버 상태를 확인합니다.

2. 장애 대응

장애 발생시 즉시 오프라인 서버를 식별하고 조치를 취합니다.

3. 용량 계획

디스크 사용량 추이를 모니터링하여 미리 용량 확보를 계획합니다.

4. 성능 모니터링

CPU와 메모리 사용량을 추적하여 병목 지점을 파악합니다.

결론

Server Status Checker는 단순한 서버 상태 확인 도구가 아닙니다. DevOps 엔지니어와 시스템 관리자가 반복 작업에서 벗어나 핵심 업무에 집중할 수 있도록 돕는 생산성 도구입니다.

SSH config라는 표준화된 설정 파일을 활용하고, 병렬 처리를 통해 빠르게 결과를 제공합니다. 이제 서버 한 대 한 대에 접속할 필요 없이, 한 번의 명령으로 모든 서버의 건강 상태를 파악하세요.

AI와 자동화를 통해 시스템 관리의 효율성을 높이고, 우리는 더 중요한 문제에 집중할 수 있습니다.

관련 프로젝트:

domain-checker - 도메인 등록 가능 여부 확인 도구

태그: #DevOps #서버모니터링 #오픈소스 #Claude #AI #생산성 #SSH

영어 버전: English Version

개발자 생산성을 높이는 도구: Domain Checker Skill 소개

Mon, 09 Mar 2026 00:20:00 +0900

개발자 생산성을 높이는 도구: Domain Checker Skill 소개

새로운 프로젝트를 시작할 때 가장 먼저 고민하는 것은 무엇일까요? 바로 “도메인 이름"입니다.

가장 원하는 이름이 .com이나 .ai에 이미 등록되어 있다면? 그때마다 whois 사이트들을 일일이 방문하셨나요?

저도 그랬습니다. 그래서 만들었습니다.

문제: 도메인 검색의 반복 작업

스타트업 창업자나 개발자라면 한 번쯤 겪는 상황입니다:

원하는 도메인이 이미 등록됨
whois 사이트 10번 방문
엑셀에 수동으로 비교표 작성
대안 도메인명 머리로 고민

이 과정은 시간 낭비이자, 창의력을 갉아먹는 반복 작업입니다.

해결책: Domain Checker Skill

Domain Checker는 Claude Code용 스킬로, 도메인 등록 가능 여부를 실시간으로 확인하고 비용을 비교합니다.

주요 기능

기능	설명
빠른 병렬 조회	8개 주요 TLD를 동시에 확인
3단계 폴백	RDAP → whois → DNS (신뢰성 보장)
대안 자동 추천	원하는 도메인이 모두 등록된 경우 대안 자동 탐색
비용 비교표	TLD별 연간 비용 및 최소 계약 기간 표시
마크다운 보고서	상세 결과 보고서 자동 생성

사용법

# 기본 조회
/domain-checker myapp

# 결과 예시
🔍 도메인 검색: myapp*
 🔴 myapp.com (~$13/년)
 🔴 myapp.ai (~$75/년)
 🟢 myapp.io (~$38/년) ← 등록 가능!

조회 대상 TLD

TLD	연간 비용	최소 계약	특징
.com	~$13	1년	범용, 최고 인지도
.ai	~$75	2년	AI 프로젝트 특화
.io	~$38	1년	테크 스타트업 선호
.net	~$14	1년	.com 대안
.co	~$28	1년	스타트업 인기
.dev	~$13	1년	개발자 타겟
.tech	~$12	1년	기술 관련, 저가
.app	~$14	1년	앱 서비스 특화

기술적 세부사항

3단계 폴백 메커니즘

1. RDAP API → 가장 정확, 빠름
2. whois CLI → RDAP 실패 시 폴백
3. DNS NS 조회 → 최후 수단

대안 도메인 추천

모든 주요 도메인이 등록된 경우 자동으로 대안을 탐색합니다:

탐색 패턴:

접두사: get, try, use, go, my, the
접미사: hq, app, hub, lab, pro

예시: myapp → getmyapp.ai, myapp-hq.io, trymyapp.com

비동기 병렬 처리

Python 비동기 프로그래밍을 활용하여 8개 TLD를 동시에 조회하므로 2초 내에 결과를 확인할 수 있습니다.

실제 사용 예시

/domain-checker ai

결과:

# 🌐 도메인 검색 보고서: `ai`

## 요약
| 항목 | 결과 |
|------|------|
| 검색 도메인 | `ai` |
| 조회 TLD 수 | 8개 |
| 🟢 등록 가능 | **0개** |
| 🔴 이미 등록됨 | 8개 |

## 💡 대안 도메인명 추천
`ai`의 변형 중 등록 가능한 도메인입니다.

| 도메인 | 연간 비용 | 비고 |
|--------|-----------|------|
| `ai-hq.ai` | ~$75/년 | AI 특화 (최소 2년 계약) |
| `ai-hq.io` | ~$38/년 | 테크 스타트업 선호 |

GitHub 공개

이 스킬은 오픈소스로 공개되어 있습니다.

🔗 GitHub: https://github.com/yarang/skill-domain-checker

설치 방법

git clone https://github.com/yarang/skill-domain-checker.git
cp -r skill-domain-checker ~/.claude/skills/domain-checker

비즈니스 가치

측면	개선 효과
시간 절약	도메인 검색 시간 90% 단축 (10분 → 1분 이내)
비용 효율	TLD별 비교로 최적 선택 지원
문서화	자동 생성된 보고서로 팀 공유 용이
생산성	반복 작업 자동화로 핵심 문제 집중

결론

Domain Checker는 단순한 도메인 검색 도구가 아닙니다. 개발자와 창업가가 반복 작업에서 벗어나 진짜 중요한 문제에 집중할 수 있도록 돕는 생산성 도구입니다.

AI와 자동화를 통해 일상의 작은 불편함을 해소하고, 우리는 더 큰 가치를 창출할 수 있습니다.

관련 프로젝트:

server-status-checker - SSH config 기반 서버 상태 확인 도구

영어 버전: English Version

[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