# Alejandro Rioja — KO > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/ko/ Author: Alejandro Rioja Language: ko --- ## 인간 감독이 포함된 AI 에이전트: 승인 게이트를 구축할 때와 그렇지 않을 때 Source: https://alejandrorioja.com/ko/human-in-the-loop-ai-agents-when-to-build-an-approval-gate/ Published: 2026-07-23 Tags: AI Agents, Operations TL;DR: 오류가 비용이 많이 들고, 되돌릴 수 없거나, 고객 대면일 때 — 그리고 인간이 제때 오류를 발견할 수 있을 때 승인 게이트는 의미가 있다. 검토하기에 너무 많은 양이거나, 오류 수정 비용이 낮거나, 사람들이 읽지 않고 승인할 때는 의미가 없다. 나는 네 가지 질문으로 결정하며, 내 30개 이상의 프로덕션 에이전트 대부분에는 승인 게이트가 없다. ## 목차 _2026년 7월 게시._ **요약:** 오류가 비용이 많이 들고, 되돌릴 수 없거나, 고객 대면이며, 인간이 제때 오류를 발견할 수 있을 때 승인 게이트는 의미가 있다. 검토하기에 너무 많은 양이거나, 오류가 저렴하게 수정되거나, 사람들이 읽지 않고 승인할 때는 의미가 없다. 네 가지 질문으로 결정하며, 내 30개 이상의 프로덕션 에이전트 대부분은 완전 자동화로 실행된다. **운영자 메모:** 나는 두 사업체에서 에이전트를 운영한다 — 컨설팅 브랜드와 텍사스주 플루거빌에 있는 피클볼 시설 Pickleland. 처음에는 "안전하다"는 느낌에 모든 곳에 승인 게이트를 설치했다. 몇 주 만에 아무도 읽지 않는 알림으로 가득 찬 Slack 채널과, 기술적으로는 감독되지만 실질적으로는 감독 없이 운영되는 에이전트가 생겼다. 이것은 게이트 없는 것보다 나쁘다: 실질 없는 감독의 환상. 이 글은 내가 지금 이 결정을 어떻게 생각하는지를 설명한다. ## 인간 감독 게이트란 무엇인가 가장 단순하게 말하면, 승인 게이트는 에이전트가 계속하기 전에 인간이 확인해야 하는 에이전트 워크플로의 일시 정지다. 에이전트가 이메일 초안을 작성한다 — 인간이 전송 전에 승인한다. 에이전트가 거래에 플래그를 세운다 — 인간이 환불 처리 전에 검토한다. 게이트는 동기식(누군가 승인할 때까지 에이전트가 차단)이거나 비동기식(에이전트가 작업을 대기열에 넣고, 알림을 보내며, 인간이 대시보드나 Slack 메시지에서 자신의 속도로 승인)일 수 있다. 시간이 중요하지 않은 것들에는 비동기식이 거의 항상 낫다. 동기식 게이트는 대기열에 역압을 만들고 에이전트의 신뢰성 보장을 깨뜨린다. 게이트가 아닌 것: 재시도 루프, 신뢰도 임계값, 또는 더 단순한 모델로의 폴백. 이것들은 에이전트 내부의 오류 처리 메커니즘이다. 승인 게이트는 인간의 판단이 루프에 들어오는 것에 관한 것이다 — 의도적으로, 특정 지점에서, 이유를 가지고. ## 내가 묻는 네 가지 질문 게이트를 추가하기 전에 네 가지 질문을 검토한다. 어느 하나라도 "예"이면 게이트를 고려하는 신호다. 전부 "예"이면 게이트가 구조적으로 필요하다. **1. 작업이 되돌릴 수 없는가(또는 되돌리는 데 비용이 많이 드는가)?** 10,000명에게 이메일을 보내는 것은 취소할 수 없다. 결제를 제출하는 것은 쉽게 회수할 수 없다. 백업 없이 데이터베이스 레코드를 삭제하는 것은 영구적이다. 되돌릴 수 없음은 게이트에 대한 가장 강력한 논거다. 비교: 수신 문의에 카테고리 태그를 붙이는 것. 태그가 잘못되면 두 번의 클릭으로 수정된다. 게이트 필요 없음. **2. 에이전트가 틀리면 누가 비용을 치르는가?** 내부 레이블 오류 — 몇 초 수정에 내가 비용 치름. 고객 대면 이메일 오류 — 고객이 나쁜 경험으로, 나는 신뢰 손실로 비용 치름. 금융 거래 오류 — 실제 돈과 잠재적 규정 준수 위험으로 비용 치름. 내부 시스템에만 영향을 미치는 에이전트는 게이트 없이 더 많은 오류를 허용할 수 있다. 고객이나 돈에 관여하는 에이전트는 무인 운영 권리를 얻어야 한다. **3. 인간이 중요해지기 전에 실제로 오류를 감지할 수 있는가?** 이것이 대부분의 사람들이 건너뛰는 질문이며, 다른 어떤 질문보다 많은 게이트를 없애는 질문이다. 에이전트가 시간당 500개를 처리하고 항목당 Slack 알림을 받는다면, 아무도 500개를 다 읽지 않는다. 감독이 아닌 알림 피로를 만들고 있다. 계산은 단순하다: 인간이 이용 가능한 시간 창 내에 현실적으로 플래그된 항목을 검토할 수 있을 때만 게이트가 가치를 더한다. **4. 인간이 에이전트가 제시하는 것을 신뢰할 수 있게 읽는가?** 승인 대기열이 가득 차고 사람들이 읽지 않고 승인한다면, 게이트는 게이트 없는 것보다 나쁘다 — 인간이 작업을 확인했다는 거짓 신뢰를 만든다. ## 게이트가 명확히 의미 있는 때 예외 없이 항상 게이트를 추가하는 패턴들: - **되돌릴 수 없는 외부 통신** — 실제 사람들에게 가는 이메일, SMS, 소셜 미디어 게시물. 에이전트가 초안 작성; 인간이 전송. 볼륨에 따라. - **임계값 이상의 금융 작업** — 돈을 이동시키는 모든 것은 내가 컨텍스트별로 설정한 금액 최소값 이상이면 게이트를 받는다. - **에이전트가 본 적 없는 새 패턴** — 에이전트의 분류기가 무언가를 "알 수 없음" 또는 훈련 분포 밖으로 플래그하면, 그것은 강제 에스컬레이션이다. - **규정 준수에 민감한 출력** — HIPAA, PCI, 법적 통지 또는 규제된 금융 콘텐츠에 관여하는 모든 것은 사람이 검토한다. ## 게이트가 제품을 조용히 죽이는 때 게이트가 안전해 보이지만 조용히 채택을 깨는 패턴들: - **대용량의 되돌릴 수 있는 작업** — 두 번의 클릭으로 취소할 수 있고 하루에 200번 발생한다면, 검토 피로가 이긴다. - **시간에 민감한 워크플로** — 30초 내에 수신 고객 문의에 응답하는 에이전트는 동기식 게이트를 가져서는 안 된다. - **인간이 에이전트보다 컨텍스트가 적은 작업** — 에이전트가 분류를 위해 50페이지 컨텍스트를 읽었는데 검토자가 한 줄 요약을 받는다면, 검토는 형식에 불과하다. - **내부 보강 및 레이블링** — CRM 레코드 태그, 비용 분류, 회의록 요약. 위험이 방해를 정당화하지 않는다. ## 실제로 배포하는 세 가지 게이트 패턴 게이트가 정당화될 때, 세 가지 구현 중 하나를 선택한다: **1. Slack/이메일을 통한 비동기 승인** 에이전트가 초안을 완성하고, 제안된 작업과 승인/거부 버튼이 있는 메시지를 지정된 Slack 채널에 게시하고 일시 정지한다. Cloudflare Queues를 사용하여 대기 중인 작업을 보유하고, 재개 전에 승인 웹훅을 듣는 별도의 Worker를 사용한다. 잘 작동하는 용도: 이메일 초안, 소셜 콘텐츠, 중요한 CRM 업데이트. **2. 신뢰도 기반 에스컬레이션** 에이전트는 고신뢰도 출력(예: 구조화된 스키마에서 ≥0.85 신뢰도)에 대해 완전 자동화로 실행하고 저신뢰도 항목을 인간 대기열로 라우팅한다. 잘 작동하는 용도: 분류, 라우팅, 트리아지. **3. 일괄 승인이 있는 대시보드 검토** 항목당 게이트 대신, 모든 에이전트 출력이 검토 대시보드에 모인다. 인간이 일괄 검토한다 — 예를 들어 매일 아침 — 그리고 그룹으로 승인하거나 수정한다. 잘 작동하는 용도: 콘텐츠 생성, 보고서 초안, 예약된 요약. ## 알림 피로 함정 추가하는 모든 게이트는 누군가의 주의에 대한 영구적인 세금이다. 위험은 하나의 게이트가 무시되는 것만이 아니다 — 세 개의 게이트가 시끄러운 Slack 채널을 만들어 사람들이 모든 알림을 무시하도록 훈련시키고, 미래에 정말 중요한 게이트도 무시되는 것이다. 내가 구축한 규율: 모든 게이트에는 명시적인 소유자와 명시적인 SLA가 있다. SLA 내에서 일관되게 검토하는 사람이 없다면, 게이트는 감사 추적으로 대체된다. 모든 승인 대기열을 월별로 감사한다. ## 에이전트 신뢰성과의 연결 게이트는 신뢰성 스택의 한 레이어이지 전체 스택이 아니다. 프로덕션 에이전트의 전체 신뢰성 스택: 1. **평가 하네스** — 배포 전 올바른 출력 확인. 2. **스키마 검증이 있는 구조화된 출력** — 에이전트의 출력이 타입된 스키마로 제한됨. 3. **신뢰도 임계값** — 저신뢰도 출력은 인간 검토로 이동. 4. **감사 로그** — 에이전트의 모든 작업이 입력, 출력, 모델 호출 메타데이터와 함께 기록됨. 5. **인간 승인 게이트** — 위로 충분하지 않은 작업에만. ## 나의 경험 법칙 주니어 직원이 먼저 나에게 확인하지 않고 이것을 하기를 원하지 않는다면, 에이전트에는 게이트가 필요하다. 주니어 직원이 두 번 생각하지 않고 하도록 두겠다면, 에이전트는 감독 없이 실행되어야 한다. ## FAQ ### 승인이 필요하지만 대용량으로 실행되는 에이전트를 어떻게 처리하는가? 아키텍처를 변경하라: 항목당 승인을 요구하지 말고 패턴당 승인을 요구하라. 에이전트를 실행하되, 인간 검토를 위한 통계적 이상값을 표면화하게 하라. ### 오류가 심각한 피해를 일으킬 수 있지만 완전한 인간 검토를 감당할 수 없다면? 이것은 보통 해당 작업에 에이전트를 아직 배포하지 말라는 신호다. 또는 에이전트가 매우 확신할 때만 행동하고 나머지는 에스컬레이션하는 신뢰도 임계값을 사용하라. [Claude](/recommends/claude)를 모델 레이어로 사용한다면, Anthropic SDK의 도구 사용 패턴을 통해 신뢰도가 부족할 때 에이전트가 호출할 수 있는 "에스컬레이션" 도구를 쉽게 정의할 수 있다. --- ## Claude Tool Use: 내 AI 에이전트에 실제 기능을 부여하는 방법 Source: https://alejandrorioja.com/ko/claude-tool-use-production-agents/ Published: 2026-07-21 Tags: AI Agents, Claude TL;DR: Claude tool use를 통해 에이전트가 텍스트 생성이 아닌 실제 작업을 수행할 수 있습니다. 도구를 JSON 스키마로 정의하면 Claude가 언제 호출할지 결정하고 코드가 실제 작업을 실행합니다. 루프는 3단계입니다: 메시지 전송 → tool_use 블록 수신 → 실행 후 결과 반환. Cloudflare Workers의 15개 이상 프로덕션 에이전트에 이를 구현했습니다. 장애 지점은 거의 AI가 아니라 도구에서 반환되는 모호한 결과에 있습니다. ## 목차 _2026년 7월 업데이트._ **TL;DR:** Claude tool use를 통해 에이전트가 텍스트 생성이 아닌 실제 작업을 수행할 수 있습니다. 도구를 JSON 스키마로 정의하면 Claude가 언제 호출할지 결정하고 코드가 실제 작업을 실행합니다. 루프는 3단계입니다: 메시지 전송 → tool_use 블록 수신 → 실행 후 결과 반환. Cloudflare Workers의 15개 이상 프로덕션 에이전트에 이를 구현했습니다. 장애 지점은 거의 AI가 아니라 도구에서 반환되는 모호한 결과에 있습니다. **[운영자 관점]** 컨설팅 브랜드와 텍사스주 플루거빌의 피클볼 시설인 Pickleland에서 30개 이상의 프로덕션 AI 에이전트를 운영합니다. 절반 정도가 tool use를 사용합니다 — 모델이 코드에서 정의한 함수를 호출할 수 있게 하는 Claude API 기능입니다. 프로덕션에서 구현하고 반복하며 수렴한 패턴을 소개합니다. ## Tool use가 에이전트의 능력을 바꾸는 이유 도구 없이 에이전트는 텍스트만 생성할 수 있습니다. 요약, 초안 작성, 분류에는 유용하지만 대부분의 비즈니스 자동화가 실제로 필요로 하는 것은 아닙니다. 비즈니스 자동화는 정보 조회, 데이터베이스 쓰기, API 호출, 메시지 전송이 필요합니다. Tool use는 Claude에게 이러한 접근 권한을 부여하는 방법입니다. JSON 스키마로 도구 세트를 정의합니다. Claude가 스키마를 읽고 어떤 도구를 어떤 인수로 호출할지 결정하여 구조화된 `tool_use` 콘텐츠 블록을 반환합니다. 코드가 실제 함수를 실행합니다. Claude가 결과를 받아 다음에 할 일을 결정합니다 — 다른 도구를 호출하거나 최종 텍스트 응답을 생성하는 것을 포함합니다. 핵심: **Claude가 언제 그리고 도구를 호출할지 여부를 결정합니다.** 능력을 정의하는 것은 당신입니다. 모델이 사용 시점을 추론합니다. ## API 흐름 작동 방식 Tool use 루프에는 3단계가 있습니다. 모델이 수행하는 도구 호출 수에 따라 이 루프를 한 번 또는 여러 번 실행합니다. **1단계: 정의된 도구와 함께 메시지 전송** ```typescript const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ { name: "check_court_availability", description: "Check if a court is available at a given date, time, and duration", input_schema: { type: "object", properties: { date: { type: "string", description: "Date in YYYY-MM-DD format", }, time: { type: "string", description: "Start time in HH:MM format (24h)", }, duration_minutes: { type: "number", description: "Duration of the booking in minutes", }, }, required: ["date", "time", "duration_minutes"], }, }, ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, ], }); ``` **2단계: Claude가 도구를 호출하려는지 확인** ```typescript if (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find( (block): block is Anthropic.ToolUseBlock => block.type === "tool_use" ); if (!toolUseBlock) throw new Error("Expected tool_use block"); // Run your actual function const toolResult = await checkCourtAvailability( toolUseBlock.input as CourtAvailabilityInput ); // Step 3: Return the result to Claude const finalResponse = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ /* same tools as before */ ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, { role: "assistant", content: response.content }, { role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(toolResult), }, ], }, ], }); // finalResponse.content now has the text answer } ``` 이것이 전체 패턴입니다. 도구 호출당 3번의 API 상호작용: 도구 정의 → `tool_use` 블록 수신 → 결과 반환. ## 실제 예시: Pickleland 가용성 확인기 Pickleland는 피클볼 시설입니다. Facebook Messenger, 댓글, 챗봇으로 예약 문의를 받습니다. 질문은 거의 항상 "토요일 오후 3시에 여시나요?" 또는 "8인 그룹용 코트를 예약할 수 있나요?"의 변형입니다. 가용성 확인 에이전트는 정형화된 응답 대신 tool use를 사용하여 실시간으로 실제 예약 시스템을 조회합니다. 전체 에이전트를 보여드립니다 — 간소화되었지만 프로덕션에 충실합니다: ```typescript // workers/availability-checker.ts import Anthropic from "@anthropic-ai/sdk"; const anthropic = new Anthropic(); const AVAILABILITY_TOOLS: Anthropic.Tool[] = [ { name: "check_availability", description: "Check court availability for a date, time, and group size. Returns available courts and their prices.", input_schema: { type: "object", properties: { date: { type: "string", description: "YYYY-MM-DD" }, start_time: { type: "string", description: "HH:MM (24h)" }, duration_minutes: { type: "number" }, players: { type: "number", description: "Number of players" }, }, required: ["date", "start_time", "duration_minutes"], }, }, { name: "get_pricing", description: "Get current pricing for court rentals and open play sessions", input_schema: { type: "object", properties: { session_type: { type: "string", enum: ["court_rental", "open_play", "clinics"], }, }, required: ["session_type"], }, }, ]; export async function handleInquiry( userMessage: string, env: Env ): Promise { const messages: Anthropic.MessageParam[] = [ { role: "user", content: userMessage }, ]; // Agentic loop — keep going until stop_reason is "end_turn" while (true) { const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 512, system: "You are the booking assistant for Pickleland, a pickleball facility in Pflugerville, TX. " + "Use the tools to look up real availability and pricing. Never make up availability or prices. " + "If the customer wants to book, direct them to pickleland.com/book.", tools: AVAILABILITY_TOOLS, messages, }); // Push the assistant's response into message history messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const textBlock = response.content.find( (b): b is Anthropic.TextBlock => b.type === "text" ); return ( textBlock?.text ?? "I wasn't able to answer that — please call us directly." ); } if (response.stop_reason === "tool_use") { // Process ALL tool calls in this response (Claude can request multiple at once) const toolResults: Anthropic.ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; let result: unknown; switch (block.name) { case "check_availability": result = await checkAvailability( block.input as AvailabilityInput, env ); break; case "get_pricing": result = await getPricing(block.input as PricingInput, env); break; default: result = { error: `Unknown tool: ${block.name}` }; } toolResults.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(result), }); } // Return all tool results in a single user message messages.push({ role: "user", content: toolResults }); } } } ``` 여기서 두 가지를 강조하고 싶습니다. **에이전트 루프.** `stop_reason === "end_turn"`이 될 때까지 계속합니다. Claude가 `check_availability`를 호출하고 가격도 필요하다고 판단하여 `get_pricing`을 호출한 다음 최종 답변을 생성할 수 있습니다 — 이는 하나의 사용자 메시지에 대한 세 번의 API 호출입니다. 루프는 특별한 로직 없이 이를 처리합니다. **턴당 여러 도구 호출.** Claude는 단일 응답에서 여러 `tool_use` 블록을 반환할 수 있습니다. 모두 처리하고 단일 `user` 메시지로 모든 결과를 반환합니다. 하나씩 처리하여 개별적으로 반환하면 대화 흐름이 끊기고 토큰을 낭비합니다. ## 실제 예시: 리드 조사 에이전트 컨설팅 브랜드에서는 대화 전에 인바운드 리드를 풍부하게 만드는 조사 에이전트를 사용합니다. 누군가 연락 양식을 작성하면 에이전트가 회사를 조사하고 통화 전에 알아야 할 내용을 추출합니다. 이 도구 정의에는 쓰기 도구가 포함됩니다 — 패턴이 흥미로워지는 부분입니다: ```typescript const RESEARCH_TOOLS: Anthropic.Tool[] = [ { name: "search_company", description: "Search for information about a company", input_schema: { type: "object", properties: { company_name: { type: "string" }, website: { type: "string", description: "Company website if known" }, }, required: ["company_name"], }, }, { name: "save_research", description: "Save the completed research summary to Airtable. Call this when all research is complete.", input_schema: { type: "object", properties: { company_summary: { type: "string" }, estimated_size: { type: "string", enum: ["1-10", "11-50", "51-200", "200+"], }, likely_use_case: { type: "string" }, priority: { type: "string", enum: ["high", "medium", "low"] }, notes: { type: "string" }, }, required: [ "company_summary", "estimated_size", "likely_use_case", "priority", ], }, }, ]; ``` `save_research`는 **쓰기 도구**라고 부릅니다 — 정보를 가져오는 것이 아니라 Claude의 출력을 구조화된 형태로 데이터베이스에 커밋하는 것이 목적입니다. 텍스트 응답에서 JSON을 파싱하는 대신 이 패턴을 사용합니다. Claude는 조사가 완료되면 알고 올바르게 타입이 지정된 필드로 `save_research`를 호출합니다. 파서를 작성할 필요가 없습니다. 이것이 tool use의 가장 깔끔한 적용입니다: 원하는 정확한 스키마로 "최종 액션" 도구를 정의하면 Claude가 도구 호출을 통해 구조화된 출력을 제공합니다. 텍스트 파싱 없음, 정규식 없음, 자유 텍스트 출력의 JSONSchema 검증 없음. ## 하나의 도구 vs. 여러 개 Tool use를 시작할 때의 본능은 모든 것을 처리하는 거대한 도구를 만드는 것입니다. 이를 저항하세요. 작고 집중된 도구가 세 가지 이유로 더 좋습니다: 1. **Claude는 작은 도구에 대해 더 잘 추론합니다.** 가용성을 반환하는 `get_court_status`라는 도구가 `mode` 매개변수를 받고 내부적으로 분기하는 `manage_facility`보다 모델이 처리하기 더 쉽습니다. 2. **작은 도구는 테스트하기 더 쉽습니다.** 각 도구는 LLM과 독립적으로 단위 테스트할 수 있는 TypeScript 함수입니다. 그래야 합니다 — 도구 버그는 라이브 대화에서 디버그하기 어렵습니다. 3. **Claude는 작은 도구를 병렬화할 수 있습니다.** 두 도구가 서로 의존하지 않는 경우 Claude는 같은 응답에서 호출하고 병렬로 처리할 수 있습니다. 이는 도구가 진정으로 독립적인 경우에만 작동합니다. 예외: 많은 공유 내부 상태에 접근해야 하는 도구. 함수가 동일한 데이터 소스에서 10개의 변수가 필요하면 각각 별도로 데이터베이스에 접근하는 10개의 도구보다 더 풍부한 스키마를 가진 하나의 도구가 낫습니다. 경험 법칙: 서로 다른 기능당 하나의 도구로 시작합니다. 모든 요청에서 함께 호출하는 것을 볼 때만 도구를 병합합니다. ## 비용 영향 Tool use는 토큰을 추가합니다. 각 도구 정의는 시스템 프롬프트 컨텍스트에 들어갑니다. 각 `tool_use` 및 `tool_result` 블록은 대화 기록의 토큰을 소비합니다. 멀티턴 에이전트 루프에서는 이것이 빠르게 쌓입니다. Pickleland 가용성 확인기의 경우 일반적인 대화는 총 3-4번의 API 호출(초기 메시지 + 1-2번의 도구 호출 + 최종 답변)을 실행하며 각각 600-900개의 토큰을 처리합니다. Haiku 가격 기준으로 요청당 $0.001 미만입니다. [AI 에이전트 비용 계산 게시물](/ai-agent-cost-math-when-haiku-beats-sonnet/)에서 설명한 것처럼 Haiku는 잘 정의된 도구 호출 작업을 안정적으로 처리하며 동일한 토큰 양에 대해 Sonnet보다 10배 저렴합니다. 리드 조사 에이전트는 Sonnet에서 실행됩니다. 왜냐하면 판단 결정 — 리드 우선순위 지정, 적합성 추정 — 은 Haiku가 오픈 입력에서 안정적으로 제공하는 것보다 더 많은 추론 능력이 필요하기 때문입니다. 드물게 실행되므로(하루에 수천 번이 아닌 주에 몇 번) 계산이 여전히 작동합니다. 모델 선택은 개인 선호도가 아닌 작업 복잡성을 따릅니다. ## 아무도 이야기하지 않는 장애 지점 프로덕션 tool use에서 가장 일반적으로 보이는 장애 지점은 Claude가 잘못된 도구를 호출하는 것이 아닙니다. Claude가 명확하게 추론할 수 없는 것을 도구가 반환하는 것입니다. 도구가 40개 필드를 가진 원시 데이터베이스 객체를 반환하면 Claude는 어떤 필드가 중요한지 혼란스러워합니다. 도구가 예외를 발생시키면(도구 결과가 아닌 Worker 충돌로 나타남) 루프가 조용히 끊깁니다. 도구가 "결과 없음"을 의미할 때 `null`을 반환하면 Claude는 재시도할지 포기할지 모릅니다. 도구 결과에 대한 세 가지 규칙: **간결하고 명시적인 결과 반환.** `{ available: true, courts: ["Court 3", "Court 5"], price_per_hour: 20 }` — 전체 데이터베이스 행이 아닙니다. **도구 함수 내에서 오류를 포착하고 구조화된 결과로 반환.** `{ error: "booking system timeout", retry: true }` — Worker를 충돌시키는 발생된 예외가 아닙니다. **"결과 없음"을 명시적으로 만들기.** `{ available: false, next_available: "2026-07-23T14:00:00Z" }` — 컨텍스트 없는 `null`이나 빈 배열이 아닙니다. Claude는 모호한 반환 값보다 명확한 신호에 대해 훨씬 더 잘 추론합니다. 프로덕션에서 tool use를 디버그하는 데 소비한 모든 시간은 모델의 추론이 아닌 불명확한 결과에 관한 것이었습니다. ## 운영자의 결론 Tool use는 Claude를 텍스트 생성기에서 운영자로 변환하는 기능입니다. 명확한 입력 스키마로 집중된 도구를 정의합니다. 모델에 대한 단일 응답에서 모든 `tool_use` 블록을 처리합니다. `stop_reason === "end_turn"`이 될 때까지 에이전트 루프를 실행합니다. 도구 함수에서 깨끗하고 간결한 결과를 반환합니다 — 원시 데이터 객체, 발생된 예외, 모호한 null이 아닙니다. 모델이 추론을 담당합니다. 코드가 실제 작업을 담당합니다. 이 두 가지 역할을 명확하게 분리하면 도구를 추가해도 아키텍처가 유지 가능합니다. 첫 번째 tool use 에이전트를 구축하는 경우 위의 가용성 확인기 패턴으로 시작하세요 — 하나의 도구, 하나의 목적, 하나의 에이전트 루프. 그것을 배포합니다. 그런 다음 두 번째 도구를 추가합니다. --- **관련:** [30개 이상의 프로덕션 에이전트를 실행하는 데 사용하는 에이전트 스택](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Haiku vs Sonnet: 에이전트 작업의 비용 계산](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [이벤트 트리거 vs 예약 에이전트: 어떤 패턴이 어떤 작업에 맞는지](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) **Tool use 에이전트를 구축하다 막혔나요?** [연락하기](/contact/) — 운영팀을 위한 프로덕션 에이전트 아키텍처를 설계하고 구축합니다. ## FAQ ### Claude tool use는 모든 모델에서 작동합니까? 예 — tool use는 모든 현재 Claude 모델에서 지원됩니다. [Claude](/recommends/claude) Haiku는 명확한 스키마로 잘 정의된 도구를 안정적으로 처리하며 대용량 작업 유형에 가장 저렴한 옵션입니다. Sonnet은 더 모호하거나 개방형 도구 호출 결정을 더 잘 처리합니다. Haiku로 시작하고 출력 품질이 부족하면 업그레이드합니다. ### Claude tool use와 OpenAI 함수 호출의 차이점은 무엇입니까? 기계적으로 동일합니다. OpenAI가 "function calling"을 만들었고 Anthropic은 "tool use"라고 부릅니다. 두 경우 모두: JSON 스키마를 정의하고 모델이 구조화된 호출을 반환하며 코드가 함수를 실행합니다. API 형태는 다르지만 개념은 같습니다. ### Claude가 단일 응답에서 여러 도구를 호출할 수 있습니까? 예. Claude는 단일 `assistant` 응답에서 여러 `tool_use` 블록을 반환할 수 있습니다. 모두 처리하고 단일 `user` 메시지에 모든 결과를 반환합니다. 위의 Pickleland 예시에서 에이전트 루프 패턴을 참조하세요 — `response.content`의 `for` 루프가 이를 올바르게 처리합니다. ### 에이전트당 몇 개의 도구를 정의해야 합니까? 에이전트당 8-10개 미만으로 유지합니다. 그 이상에서는 Claude가 첫 번째 시도에서 잘못된 도구를 선택하는 경우가 있어 수정 루프에서 토큰을 낭비합니다. 10개 이상의 기능이 필요한 경우 모든 것을 아는 하나의 에이전트를 구축하는 대신 전문화된 도구 세트를 가진 여러 에이전트로 나눕니다. ### 구조화된 출력을 위해 tool use를 사용해야 합니까? 예 — `save_research` 쓰기 도구 패턴은 Claude에게 텍스트 블록에서 JSON을 반환하도록 요청한 다음 파싱하는 것보다 깔끔합니다. 원하는 정확한 스키마로 "최종 액션" 도구를 정의합니다. Claude가 완료되면 올바르게 타입이 지정된 필드로 호출합니다. 파서가 필요 없습니다. --- ## 2026년 검색 엔진이 실제로 콘텐츠 품질을 평가하는 방법 Source: https://alejandrorioja.com/ko/how-search-engines-evaluate-content-quality/ Published: 2026-07-20 Tags: SEO, GEO ## 목차 _2026년 7월 업데이트._ **요약(TL;DR):** 검색 엔진과 AI 엔진 모두 더 이상 페이지를 개별적으로 평가하지 않습니다. 이들은 사이트를 평가합니다 — 한 주제에 대한 커버리지의 깊이, 검증을 견뎌내는 신뢰 신호, 그리고 뛰어난 글 한 편이 아니라 몇 달에 걸친 일관성. 저는 384개의 영어 게시물을 13개 언어로 운영하며 매주 ChatGPT, Perplexity, Google AI Overviews에서 인용되고 있는지 추적합니다. 패턴은 일관됩니다: 고립된 게시물은 정체되고, 클러스터는 복리로 쌓이며, 인용률을 움직이는 신뢰 신호는 지루할 정도로 구조적이고 만들기 저렴합니다. **운영자의 시각:** 저는 콘텐츠 품질을 이론화하고 있는 게 아닙니다 — 저는 이 사이트의 콘텐츠 엔진을 직접 운영하며, 무언가를 바꿀 때 인용률에 무슨 일이 일어나는지 지켜봅니다. 이 글은 전적으로 alejandrorioja.com에서 제가 실제로 측정한 것들로 구성되어 있습니다: 실제 클러스터 크기, 실제 6주간의 인용 실험, 실제 schema 마크업 테스트. 여기에는 알고리즘이 "아마도" 어떻게 작동할지에 대한 추측이 전혀 없습니다. ## 품질은 이미 오래전에 페이지 단위 질문이 아니게 되었다 대부분이 여전히 갖고 있는 사고 모델은 이렇습니다: 좋은 글을 쓰면, 순위가 오른다. 그것은 애초에 완전히 사실이었던 적이 없고, 좁은 롱테일 키워드를 벗어나는 순간 지금은 명백히 오해를 부르는 생각이 됩니다. 저는 제 사이트에서 이것을 직접 확인할 방법을 갖고 있습니다. 저는 몇 개의 실제 클러스터를 통해 게시물을 발행합니다 — 29개 게시물로 구성된 AI 에이전트·Claude 클러스터, 20개 게시물까지 늘어난 "X는 어떻게 돈을 버는가" 비즈니스 모델 설명 클러스터(Google, OpenAI, Anthropic, Uber, Salesforce 등을 다룹니다), 그리고 태그 수 기준으로 사이트 전체에서 가장 큰 SEO/GEO 클러스터. 제가 단 한 번만 다룬 주제 안의 독립된 게시물은, 그 글이 객관적으로 더 잘 쓰였더라도, 이런 클러스터 안에 있는 게시물과는 완전히 다르게 행동합니다. 클러스터에 속한 게시물은 더 많이 인용되고, 순위가 더 안정적으로 유지되며, 알고리즘 업데이트 이후 더 빠르게 회복됩니다. 고립된 게시물은 스파이크가 나거나 나지 않으며, 나지 않을 때는 기댈 만한 주변 권위가 없습니다. 이것이 흔히 [AI 토픽 권위 전략](https://www.linkbuildinghq.com/blog/how-to-build-topical-authority-for-ai/)이라는 이름으로 팔리는 것 뒤에 있는 실제 메커니즘입니다 — 신비로운 신뢰 점수가 아니라, 같은 주제를 다루는 다른 28개 페이지 옆에 놓인 페이지가 Google의 크롤러와 LLM의 검색 단계 모두에게 기댈 수 있는 더 많은 확증 컨텍스트를 준다는 단순한 사실입니다. 저는 [그 구조의 전체 메커니즘](/pillar-content/)을 의도적으로 정리해 두었습니다 — 요약하자면, 클러스터는 그 안의 모든 게시물이 필러로 링크하고 필러가 다시 밖으로 링크할 때만 작동합니다. 그래야 토픽 지도가 크롤러가 재구성해야 하는 무언가가 아니라 명시적인 것이 됩니다. 새 글을 발행하기 전에 제가 적용하는 실질적인 테스트는 이렇습니다: 이 게시물이 제가 이미 가진 클러스터를 확장하는가, 아니면 새로운 단발성 글을 시작하는가? 단발성 글이 금지된 것은 아닙니다 — 어떤 쿼리는 정말로 페이지 하나만 필요합니다 — 하지만 단발성 글은 클러스터 게시물이 공짜로 얻는 복리 효과 없이 페이지 단위 신호만으로 경쟁한다는 것을 저는 처음부터 알고 시작합니다. ## "진짜 가치, 필러가 아니다"는 느낌이 아니라 검증 가능한 주장이다 이 조언의 일반적인 버전은 "깊이와 맥락을 더하고, 흔히 구할 수 있는 정보를 반복하지 말라"고 말합니다. 맞는 말이지만, 확인할 방법이 없으면 쓸모가 없습니다. 이것이 제가 실제 규모에서 운영하는 실질적인 테스트입니다: 저는 384개의 영어 게시물을 갖고 있습니다. 각 게시물은 [바로 그 목적으로 제가 만든 에이전트](/how-to-translate-one-blog-post-into-13-languages-with-one-agent/)를 통해 다른 12개 언어로 번역됩니다. 번역은 저렴합니다 — 341개 게시물 전체 백로그를 처리하는 데 Haiku API 호출 비용이 약 1.70달러였습니다. 글쓰기는 그렇지 않습니다. 만약 같은 아이디어를 열 가지 다른 프레이밍으로 살짝 다시 쓰는 방식으로 볼륨을 부풀릴 수 있었다면, 그 에이전트는 번역을 확장하는 것만큼 쉽게 중복을 확장하게 해줬을 겁니다. 저는 그렇게 하지 않습니다. 왜냐하면 프레이밍만 다른 중복은 실제 테스트를 통과하지 못하기 때문입니다: 이 페이지는 제 사이트의 다른 어떤 페이지도 이미 그만큼 잘, 혹은 더 잘 답하지 못한 질문에 답하는가? 이것이 어떤 스타일 가이드라인보다 중요한 필터입니다. "필러"는 톤의 문제가 아니라 중복의 문제입니다 — 새로운 각도, 숫자, 예시를 더하지 않고 이웃 페이지를 되풀이하는 페이지입니다. 저는 발행 전에 이 새 게시물이 새로운 인용 표면을 더하는 대신 기존 게시물의 인용을 잠식하지는 않는지 물어보며 이를 점검합니다. 제 사이트의 두 게시물이 같은 쿼리를 똑같이 잘 만족시킨다면, 아무리 잘 쓰였더라도 그중 하나는 필러입니다. ## 제가 실제로 만들고 측정한 신뢰 신호 "신뢰성"은 모든 일반적인 SEO 글에서 가장 모호한 용어이며, 보통 "출처를 인용하라, 전문성을 보여줘라, 정확성을 유지하라" 같은 목록이 뒤따르지만 그중 무엇이 실제로 무언가를 움직였는지 검증할 방법은 없습니다. 제가 실제로 운영하는 구체적인 버전은 schema 마크업입니다. AI 엔진이 추론하는 게 아니라 기계적으로 파싱하는 유일한 신뢰 신호이기 때문입니다. 저는 [전체 구현 방법](/schema-markup-for-geo/)을 다른 글에서 정리했고, [실제로 성과를 내는 타입들](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/)에 대해서는 더 깊이 다뤘습니다. 요약하자면: 실명이 있는 저자와 정직한 `dateModified`를 갖춘 `Article`/`BlogPosting`은 저작권 앵커 역할을 합니다. `FAQPage`와 `HowTo`는 모델이 산문에서 답을 추론하게 만드는 대신 미리 답이 준비된 질문이나 미리 구조화된 절차를 건네주기 때문에 가장 상승폭이 큰 타입입니다. `Person`과 `Organization` schema는 모델이 저를 이름이 같은 다른 사람과 혼동하지 않게 하기 위해 존재합니다. 이 중 무엇도 저에게는 추상적이지 않습니다 — 실제 결과 뒤에 있는 개입입니다. 이미 Google AI Overviews를 트리거하고 있던 필러 게시물 41개에 4단계 구조적 오버레이(TL;DR 블록, 번호 매긴 단계, FAQ 섹션, 1차 출처 인용)를 적용하자, 6주 동안 인용 빈도가 41개 중 4개에서 41개 중 19개로 올라갔습니다 — [6주간 전체 테스트는 여기에 정리되어 있습니다](/google-ai-overview-citation-case-study/). 이것은 "신뢰 신호를 추가하고 기대하기"가 아닙니다. 제 페이지에서 측정한 전후 비교이며, 그 글 자체가 명확히 밝히는 단서도 있습니다: 이미 유기적으로 상위 5위 안에 순위가 잡혀 있던 페이지에서만 효과가 있었다는 점입니다. 구조는 기존 신호를 증폭시킵니다. 아무것도 없는 곳에서 신호를 만들어내지는 않습니다. ## 일관성은 복리로 쌓이지만, "일관성"이 끊임없는 업데이트를 뜻하지는 않는다 이 부분의 일반적인 주장은 보통 "신선함이 중요하지만 모든 글을 업데이트할 필요는 없다"이며, 실제 주기는 딱히 언급되지 않습니다. 제 주기는 이렇습니다. 저는 발행 후 대부분의 게시물을 손대지 않습니다. 다만 필러 게시물들은 계속 관리하며, 근본적인 사실이 바뀔 때마다 — 새 모델이 나오거나, 툴 가격이 바뀌거나, 통계가 낡아질 때 — 6~12개월마다 업데이트합니다. `dateModified`는 콘텐츠가 실제로 바뀔 때만 변경됩니다. 저는 이걸 위조해본 적이 있는데 효과가 없습니다 — 엔진은 실질적인 편집 없이 날짜만 올린 것을 간파합니다. 이는 AI Overview 사례 연구에서도 정확히 발견된 것과 같습니다. 제가 실제로 매주 지켜보는 일관성 신호는 발행 주기가 아니라 인용 커버리지입니다. 저는 비즈니스에 중요한 쿼리 목록을 추적하며 매주 ChatGPT, Perplexity, Google에 돌려보고 인용되고 있는지 기록합니다 — [방법론은 여기에 있습니다](/how-to-measure-ai-search-traffic/). 인용 커버리지는 선행 지표입니다 — 리퍼럴 트래픽이나 브랜드 검색 상승보다 먼저 움직이므로, 클러스터가 시간이 지나며 실제로 권위를 얻고 있는지, 아니면 그저 정체되어 있는지를 알려주는 숫자입니다. 한 번 발행하고 조용해지는 사이트는 그 주간 점검에서 두 번째 기회를 얻지 못합니다. 클러스터를 계속 확장하는 사이트는 그렇지 않습니다. ## "사이트 단위" 평가가 실제로 보상하는 것, 계층별로 제가 추적하는 세 엔진은 같은 신호에 동일한 가중치를 두지 않습니다. 어디에 노력을 투자할지 결정할 때 제가 머릿속에 담아두는 실질적인 표는 이렇습니다. | 품질 계층 | 실제로 어떤 모습인가 | 제가 측정한 곳 | | --- | --- | --- | | 토픽 깊이 | 한 주제에 대한 20~30개 이상의 상호 연결된 게시물, 모든 클러스터 게시물로 링크하고 다시 받는 필러 | AI 에이전트 클러스터(29개 게시물), "X는 어떻게 돈을 버는가" 클러스터(20개 게시물) | | 구조적 추출 용이성 | TL;DR 블록, 번호 매긴 단계, FAQ, 실제 사용자 표현에 맞춘 구성 | 6주 만에 4/41 → 19/41 AI Overview 인용 | | 저작권/신뢰 | 실명 저자 + 정확한 `dateModified` + Person/Organization schema | GEO를 위한 schema 마크업, schema 타입 분석 | | 시간에 걸친 일관성 | 끊임없는 재작성이 아니라 엔진 전반의 주간 인용 추적 | AI 검색 측정 방법론 | 일반적인 조언에서 가장 자주 보이는 실패 방식은 이 계층들을 하나의 미분화된 "품질" 점수로 취급하는 것입니다. 그렇지 않습니다. 어떤 페이지는 구조적 추출 용이성을 완벽히 갖추고도 토픽 깊이가 더 큰 경쟁사에 밀릴 수 있습니다. 어떤 페이지는 깊은 클러스터 안에 있으면서도 더 신선하고 schema가 더 잘 갖춰진 경쟁사에게 특정 인용을 빼앗길 수 있습니다. 특정 페이지에서 실제로 병목인 계층이 무엇인지 아는 것이 작업의 대부분입니다. ## 이 프레임워크가 깨지는 지점 — 솔직한 단서들 패턴을 과대포장하기보다는 한계를 짚어두는 편이 낫습니다. - **도메인 권위는 여전히 관문입니다.** AI Overview 개입은 이미 유기적으로 상위 5위 안에 순위가 잡혀 있던 페이지에서만 효과가 있었습니다. 구조는 기존 신호를 증폭시켰을 뿐, 차가운 페이지에서 권위를 만들어내지는 않았습니다. - **엔진들은 무엇을 보상하는지에서 갈립니다.** 동일한 50개 헤드 키워드를 ChatGPT와 Google에 돌려본 결과, 어떤 출처가 인용되는지에서 약 40%만 겹쳤습니다 — [전체 분석은 여기](/chatgpt-search-vs-google-50-term-test/). "검색 엔진"을 하나의 단일 타겟으로 최적화한다는 프레임 자체가 이미 잘못된 것입니다. 기본에는 동의하지만 나머지에서는 갈리는 여러 엔진을 상대로 최적화하고 있는 것입니다. - **일부 카테고리는 정말로 클러스터가 필요 없습니다.** 제 사이트에서 성과가 가장 좋은 페이지 중 몇 개는 진짜 단발성 글입니다. 깊이는 지렛대이지 보편적인 요구사항이 아닙니다 — 쿼리 공간이 뒷받침하지 않는 곳에 억지로 클러스터를 만들면, 이 프레임워크 전체가 피하려는 얇고 부풀려진 콘텐츠가 정확히 나옵니다. ## 자주 묻는 질문 ### 뛰어난 글 한 편이 평범한 클러스터를 이길 때도 있나요? 네, 경쟁이 낮은 충분히 좁은 쿼리라면 그렇습니다. 하지만 경쟁이 실제로 존재하는 헤드 키워드라면, 장기적으로 순위를 유지하는 페이지는 거의 항상 클러스터의 뒷받침을 받습니다. 저는 고립된 게시물이 클러스터 게시물과는 다른 방식으로 스파이크가 났다가 사그라드는 것을 지켜봤습니다. ### 진짜 클러스터로 인정받으려면 게시물이 몇 개나 필요한가요? 정해진 숫자는 없지만, 제 데이터에서는 같은 주제의 하위 주제를 다루는 진정으로 구별되는 게시물이 8~10개쯤 되는 지점에서 효과가 뚜렷하게 나타나기 시작합니다 — 필러가 의미 있게 밖으로 링크할 수 있고, 더 깊이가 필요한 독자를 각 클러스터 게시물이 구체적으로 보낼 곳이 생길 만큼입니다. ### schema 마크업이 정말 필요한가요, 아니면 좋은 글이면 충분한가요? 좋은 글은 필요조건이지만, AI 엔진 인용에는 그것만으로 충분하지 않습니다. 엔진은 산문보다 `FAQPage`와 `HowTo` schema에서 구조화된 사실을 훨씬 더 안정적으로 추출합니다. schema가 추론 단계를 없애기 때문입니다. 저는 schema가 전혀 없던 게시물에 이를 추가했을 때 한 자릿수 후반에서 10퍼센트대 중반까지의 인용 상승을 측정했습니다. ### 새 글을 발행하는 대신 기존 콘텐츠를 얼마나 자주 업데이트해야 하나요? 저는 실제 사실이 바뀔 때 필러 게시물을 6~12개월마다 업데이트하며, 실질적인 편집 없이 `dateModified`를 올리는 일은 절대 하지 않습니다. 제 콘텐츠 예산 대부분은 재작성이 아니라 클러스터를 확장하는 새 게시물에 들어갑니다 — 신선함은 중요하지만, 토픽 깊이와 구조에 비하면 지배적인 지렛대는 아닙니다. ### 가장 먼저 손봐야 할, 가장 레버리지가 큰 것은 무엇인가요? 이미 유기적으로 어느 정도 순위가 잡혀 있는데 AI 엔진에 인용되지 않고 있다면, 헤드 쿼리에 직접 답하는 깔끔한 TL;DR 블록을 추가하세요. 제 6주간 테스트에서 이것은 단연 가장 큰 단일 지렛대였습니다 — FAQ schema보다도, 1차 출처 인용보다도, 번호 매긴 단계보다도 컸습니다. ## 결론 콘텐츠 품질 평가는 페이지에서 사이트로 이동했고, 실제로 결과를 움직이는 사이트 단위 신호는 신비로운 것이 아니라 측정 가능합니다: 셀 수 있는 클러스터 깊이, A/B 테스트할 수 있는 구조적 오버레이, 검증할 수 있는 schema, 매주 추적할 수 있는 인용 커버리지 숫자. 이 중 어느 것도 알고리즘이 "원하는 것"을 추측할 필요가 없습니다. 필요한 것은 실제 토픽 구조 안에서 발행하고, 엔진이 추론하게 만드는 대신 깔끔하게 추출 가능한 답을 주고, 효과가 있는지 알 만큼 자주 결과를 확인하는 것입니다. 저는 이 네 가지 원칙 모두를 이 사이트에서 매주 실행하고 있으며, 위의 숫자들은 그것이 실제로 만들어낸 결과입니다 — 일반적인 가이드가 그래야 한다고 주장하는 것이 아니라요. --- ## 2026년 비즈니스를 위한 Claude 대 ChatGPT: 운영자의 솔직한 평가 Source: https://alejandrorioja.com/ko/claude-vs-chatgpt-for-business-2026/ Published: 2026-07-18 Tags: AI Agents, Productivity TL;DR: Claude는 에이전트 구축, 긴 컨텍스트 작업, 코딩, 그리고 규모에서 프로덕션으로 실행되는 모든 것에서 승리합니다. ChatGPT는 소비자 통합, 음성 모드, 그리고 워크플로우가 채팅 인터페이스에 있는 경우 더 넓은 플러그인 생태계에서 승리합니다. 자동화 워크플로우나 AI 에이전트를 구축하고 있다면 Claude가 더 나은 기반입니다. 더 많은 서드파티 연결이 있는 유능한 채팅 어시스턴트를 원한다면 ChatGPT가 유리합니다. 대부분의 사업자에게 진짜 질문은: AI와 대화하고 있는가, 아니면 AI로 구축하고 있는가? 그 답이 도구를 결정합니다. ## 목차 _2026년 7월 게시._ **TL;DR:** Claude는 에이전트 구축, 긴 컨텍스트 작업, 코딩, 그리고 규모에서 프로덕션으로 실행되는 모든 것에서 승리합니다. ChatGPT는 소비자 통합, 음성 모드, 그리고 워크플로우가 채팅 인터페이스에 있는 경우 더 넓은 플러그인 생태계에서 승리합니다. 자동화 워크플로우나 AI 에이전트를 구축하고 있다면 Claude가 더 나은 기반입니다. 더 많은 서드파티 연결이 있는 유능한 채팅 어시스턴트를 원한다면 ChatGPT가 유리합니다. 대부분의 사업자에게 진짜 질문은: AI와 대화하고 있는가, 아니면 AI로 구축하고 있는가? 그 답이 도구를 결정합니다. **[운영자의 관점]** 저는 두 개의 사업을 운영합니다 — 컨설팅 브랜드와 텍사스주 플루거빌의 피클볼 시설 Pickleland — 소셜 미디어 답변, 이벤트 프로모션, 예약 후속 조치, 뉴스레터 초안 등을 처리하는 30개 이상의 AI 에이전트를 프로덕션에서 운영하고 있습니다. 제 에이전트 스택 전체가 [Claude](/recommends/claude) 위에 구축되어 있습니다. ChatGPT도 각각의 실패 지점을 파악할 만큼 충분히 사용했습니다. 이것은 벤치마크 리뷰가 아닙니다. 실무자의 관점입니다. ## 실제로 중요한 질문 대부분의 비교는 "어떤 모델이 더 스마트한가?"를 묻습니다. 이것은 비즈니스 용도에서 잘못된 질문입니다. 올바른 질문은: **무엇을 구축하고 있으며, 그것이 규모에서 무엇을 신뢰성 있게 해야 하는가?** AI가 카피 작성을 도와주길 원하는 마케팅 매니저는 자동화된 리드 자격 부여 파이프라인을 구축하는 창업자와 다른 요구사항을 가집니다. 회의 준비에 AI를 사용하는 솔로프리너는 주당 500건의 고객 요청을 처리하는 에이전트를 구축하는 운영자와 다른 필요를 가집니다. 한 쪽에서 이기는 도구는 종종 다른 쪽에는 잘못된 것입니다. 이 프레임이 아래의 모든 것을 결정합니다. ## Claude가 이기는 곳 ### 1. 긴 컨텍스트 작업 Claude의 기본 컨텍스트 창 — 200K 토큰 — 은 다른 모델을 깨뜨리는 것들을 처리합니다. 저는 정기적으로 전체 고객 대화 기록, 전체 계약 초안, 또는 다중 문서 연구 브리핑을 Claude에 전달하고 종합 또는 교차 참조를 요청합니다. 스레드를 유지합니다. 경쟁 모델들이 이제 기술적으로 긴 컨텍스트를 지원하지만 복잡한 작업에서의 실제 성능 저하는 여전히 Claude보다 나쁩니다. 긴 문서 읽기, 밀도 높은 데이터 내보내기 분석, 또는 긴 워크플로우에서 일관성 유지와 관련된 비즈니스 작업에서 Claude는 진정한 우위를 가집니다. ### 2. 프로덕션에서의 에이전트 동작 Claude를 에이전트로 실행할 때 — 도구 호출, 루프에서 결정, 데이터베이스 쓰기, 오류 처리 — 제 경험에서 ChatGPT보다 더 일관되게 동작합니다. 시스템 프롬프트 지시를 더 신뢰성 있게 따르고, 파싱하기 더 쉬운 구조화된 출력을 생성하며, 컨텍스트가 길어질 때 작업에서 벗어날 가능성이 낮습니다. 이것은 에이전트에게 엄청나게 중요합니다. 시스템 프롬프트를 95% 대 99% 시간 동안 따르는 모델은 비슷하게 들립니다. 하루 500번 호출에서 그것은 감지하고 정리해야 할 하루 25건의 이탈 사례입니다. [프로덕션에서 실패하지 않는 AI 에이전트 시스템 프롬프트 작성법](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/)에 대해 쓴 글이 이를 자세히 다루지만, 짧은 버전은: 시스템 프롬프트 수준에서의 Claude의 지시 준수는 제가 테스트한 중 최고입니다. ### 3. 코딩 및 기술 작업 저는 거의 모든 것을 Cloudflare Workers에서 TypeScript로 구축합니다. Claude Code는 제 일상 개발 도구입니다 — 그리고 단순히 "충분히 좋은" 것이 아니라 진정으로 유용합니다. 아키텍처 질문, 디버깅, 리팩토링, 스크래치에서 에이전트 로직 작성에서 Claude는 ChatGPT 동등품에서 사용한 것을 지속적으로 능가합니다. 이것은 단지 Claude Code 대 ChatGPT Chat 비교가 아닙니다. API를 통한 순수 Claude Opus 4.8도 동일한 작업에서 GPT-4o 동등품보다 환각 임포트가 적은 더 깔끔한 코드를 작성합니다. ### 4. API에서의 개발자 경험 API로 구축하는 경우 — 단순히 채팅하는 것이 아니라 — 2026년에는 Claude의 개발자 경험이 더 낫습니다. Anthropic SDK는 깔끔하고, 토큰 카운팅 엔드포인트는 비용 추정에 진정으로 유용하며, 프롬프트 캐싱은 잘 구현되어 반복되는 컨텍스트에서 실제 비용을 절약하며, 오류 처리는 예측 가능합니다. 프로그래밍 방식으로 에이전트를 구축하는 모든 사람에게 API 품질 차이가 중요합니다. 크지는 않지만 일관됩니다. ### 5. 복잡한 프롬프트에서의 지시 충실성 Claude는 여러 조건을 가진 미묘한 시스템 프롬프트를 ChatGPT보다 더 잘 처리합니다. 에이전트가 규칙 세트를 따르도록 할 때 — "댓글이 질문이면 X를 하고; 불만이면 Y를 하고; 경쟁사를 언급하면 사람 검토를 위해 플래그 달기" — Claude는 해당 분기들을 더 일관되게 파싱하고 적용합니다. 간단한 프롬프트에서는 차이가 최소입니다. 시스템 프롬프트에 내장된 복잡한 조건 로직에서는 Claude가 더 신뢰할 수 있습니다. ## ChatGPT가 이기는 곳 ### 1. 소비자 통합 및 플러그인 ChatGPT의 플러그인 생태계와 기본 인터페이스를 통해 사용 가능한 도구 범위가 더 넓습니다. 워크플로우가 이미 ChatGPT 기본 통합이 있는 도구 — 특정 CRM, 생산성 앱, 연구 도구 — 에 있고 주로 채팅 인터페이스를 통해 작업한다면 ChatGPT의 기본 제공 연결이 마찰을 절약합니다. 사용자 정의 통합을 구축하지 않고 채팅 UI에서 모든 것을 하고 싶은 파워 유저에게 이것이 중요합니다. ### 2. 음성 모드 ChatGPT의 Advanced Voice Mode는 진정으로 탁월합니다. 모바일 사용, 아이디어를 구두로 작업하거나 운전 중 통화 준비를 위해 제가 사용한 최고의 음성 AI 인터페이스입니다. Claude에는 음성 입력이 있지만 2026년 중반 기준 GPT-4o의 완전한 대화형 음성 모드에 필적하는 것은 없습니다. 음성이 사용 사례의 주요 인터페이스라면 ChatGPT가 명확하게 이깁니다. ### 3. 이미지 생성 (DALL-E를 통해) ChatGPT Plus는 동일한 구독에 DALL-E를 통한 이미지 생성을 포함합니다. Claude는 기본적으로 이미지를 생성하지 않습니다. Midjourney나 다른 서비스를 추가하지 않고 텍스트와 이미지 작업을 위한 단일 도구를 원한다면 ChatGPT가 유리합니다. ### 4. 친숙함과 채택 더 많은 사람들이 ChatGPT를 사용했습니다. AI 경험이 없는 팀에 AI 도구를 소개한다면 ChatGPT로 시작하는 것이 더 적은 마찰을 만듭니다 — 대부분의 사람들이 적어도 한 번은 열었습니다. 이것은 기능 상의 이점이 아니지만 온보딩 속도는 실제 운영 요소입니다. ## 비용 비교 여기서 상황이 미묘해지고 대부분의 비교가 오해를 불러일으키는 곳입니다. 두 플랫폼 모두 계층형 가격 책정이 있습니다. API 수준에서: - **Claude Haiku 4.5**와 **GPT-4o mini**는 고용량 단순 작업을 위한 저렴한 워크호스입니다. 가격 범위에서 비교 가능하며 선택은 주로 작업 요구사항에 의해 결정됩니다. - **Claude Sonnet/Opus**와 **GPT-4o**는 중간에서 높은 계층입니다. Claude에는 반복되는 컨텍스트 워크플로우에서 비용을 크게 줄이는 [프롬프트 캐싱](/prompt-caching-cut-your-claude-costs-without-switching-models/)이 있습니다 — 에이전트가 호출 간에 동일한 시스템 프롬프트와 컨텍스트 창을 재사용한다면 Claude의 캐시 가격이 비캐시 요율보다 50~80% 저렴할 수 있습니다. ChatGPT에는 직접적인 동등품이 없습니다. - 최상위 수준에서 Claude Fable 5와 최신 GPT-4 변형은 동일한 기본 비용 범위에 있지만 토크나이저 차이가 중요합니다 — Fable 5에는 이전 모델과 다르게 토큰을 계산하는 토크나이저가 있어 참조 토큰 수가 직접 변환되지 않습니다. 비용 결론: **고호출 볼륨의 프로덕션 에이전트의 경우 Claude의 프롬프트 캐싱이 컨텍스트를 재사용하는 워크로드에서 실질적으로 저렴하게 만듭니다.** 새로운 컨텍스트에서의 순수 호출당 지불의 경우 정가가 아닌 성능이 선택을 이끌어야 할 만큼 충분히 가깝습니다. 이를 평가하는 데 사용하는 프레임워크는 [AI 에이전트 비용 수학 글](/ai-agent-cost-math-when-haiku-beats-sonnet/)에 있습니다. ## 의사 결정 매트릭스 | 사용 사례 | 승자 | |---|---| | 프로덕션에서 AI 에이전트 구축 | Claude | | 복잡한 코딩 및 아키텍처 | Claude | | 긴 컨텍스트 문서 분석 | Claude | | 플러그인 통합이 있는 채팅 어시스턴트 | ChatGPT | | 음성이 주요 인터페이스인 워크플로우 | ChatGPT | | 하나의 인터페이스에서 이미지 + 텍스트 | ChatGPT | | 규모에서 API 기반 자동화 | Claude | | AI 경험 없이 팀 온보딩 | ChatGPT | | 프로덕션에서 고객 대면 에이전트 | Claude | | 고용량 파이프라인에서 비용 효율성 | Claude (캐싱 포함) | ## 저의 실제 답변 저는 프로덕션의 모든 것에 [Claude](/recommends/claude)를 사용합니다. 모든 벤치마크에서 이기기 때문이 아니라 — 그렇지 않습니다 — 다음과 같은 이유에서입니다: 1. 에이전트가 시스템 프롬프트 지시를 충분히 신뢰성 있게 따르기 때문에 환각되거나 작업 외의 출력을 정리하는 데 거의 시간을 쓰지 않습니다. 2. Cloudflare Workers + Claude API 스택이 합산 워크로드에 월 $100 미만이며 프롬프트 캐싱이 가장 무거운 워크플로우의 비용을 절반 이상 줄였습니다. 3. Claude Code가 주요 코딩 인터페이스가 되었으며 개발과 프로덕션 모두에 동일한 모델을 사용하면 정신적 모델이 단순해집니다. 4. 긴 컨텍스트 작업 — PDF 읽기, 문서 간 종합, 다단계 워크플로우에서 일관성 유지 — Claude는 전체 200K 창을 다른 곳에서 경험한 것보다 더 잘 처리합니다. 커스텀 인프라를 구축하지 않고 AI 보조 도구가 필요한 팀을 이끈다면 아마 ChatGPT Plus에 두었을 것입니다 — 기본 제공 플러그인 폭과 음성 모드는 소비자 수준에서 진정으로 유용합니다. 그러나 단순히 사용하는 것이 아니라 무언가를 구축하기 위해서는 Claude가 올바른 기반입니다. ## 자주 묻는 질문 ### Claude가 ChatGPT보다 더 똑똑한가요? 어느 것도 보편적으로 더 똑똑하지 않습니다. Claude는 긴 컨텍스트 추론, 지시 준수, 코딩에서 더 낫습니다. ChatGPT(GPT-4o)는 이미지와 음성을 포함하는 멀티모달 작업에서 더 낫습니다. 특정 벤치마크는 각 모델 출시마다 그들 사이에서 앞뒤로 바뀝니다. 더 유용한 질문은 특정 작업에 어떤 모델이 더 나은지입니다. ### Claude와 ChatGPT 둘 다 사용할 수 있나요? 네, 일부 워크플로우에서는 그렇게 하고 싶을 수 있습니다. Claude API와 OpenAI API 모두 통합하기 간단합니다. 일부 팀은 에이전트 백엔드에 Claude를 사용하고 통합이 있는 사용자 대면 채팅 인터페이스에 ChatGPT를 사용합니다. 그렇게 말해, 두 AI 제공자를 운영하면 운영 복잡성이 증가합니다 — 자격 증명 관리, 비용 추적, 관리해야 할 동작 차이. 하나로 시작하세요. ### 콘텐츠 작성에는 어느 것이 더 낫나요? 제 경험에서는 Claude입니다. 덜 일반적으로 들리는 출력을 생성하고, 예제가 제공될 때 특정 스타일을 더 잘 유지하며, 장문 콘텐츠를 더 일관되게 처리합니다. 어느 것이든 작동할 짧은 소셜 콘텐츠나 이메일에서는 차이가 작습니다. ### Claude에는 무료 티어가 있나요? 네 — Claude.ai에는 메시지 제한이 있는 무료 티어가 있습니다. [Claude Pro 및 Max 구독](/recommends/claude)은 제한을 제거하고 우선 액세스, 파일 업로드, 전체 컨텍스트 창을 추가합니다. ChatGPT도 마찬가지로 사용 제한 GPT-4o 액세스가 있는 무료 티어가 있습니다. ### ChatGPT에서 Claude로 전환해야 하나요? 주로 AI를 채팅 인터페이스로 사용하고 ChatGPT에 만족한다면 Claude가 더 잘 처리하는 특정 필요가 없는 한 전환 비용이 가치 없을 수 있습니다. 자동화, 에이전트를 구축하거나 코딩 작업을 하고 있다면 Claude를 시도해 볼 것을 강력히 권장합니다 — 에이전트 동작과 개발자 경험이 프로덕션 워크로드에서 큰 차이를 만듭니다. --- ## 제품화된 서비스 구축 방법: 전문성을 확장 가능한 수익으로 전환하는 나의 프레임워크 Source: https://alejandrorioja.com/ko/productized-service-how-to-package-your-expertise/ Published: 2026-07-16 Tags: Entrepreneurship, Marketing TL;DR: 제품화된 서비스란 매번 같은 방식으로 제공하는 고정 범위, 고정 가격의 서비스입니다. 네 가지 단계: 고객이 이미 반복해서 의뢰하는 업무를 찾고, 범위 경계를 명확하게 정의하며, 시간이 아닌 결과 가치를 기반으로 가격을 책정하고, 다음 고객에게 판매하기 전에 제공 시스템을 구축합니다. 대부분의 컨설턴트는 네 번째 단계를 건너뛰고 계속 시간을 돈으로 교환합니다. 그것이 실제로 규모를 만드는 유일한 단계입니다. ## 목차 _2026년 7월 게시._ **TL;DR:** 제품화된 서비스란 매번 같은 방식으로 제공하는 고정 범위, 고정 가격의 서비스입니다. 네 가지 단계: 고객이 이미 반복해서 의뢰하는 업무를 찾고, 범위 경계를 명확하게 정의하며, 시간이 아닌 결과 가치를 기반으로 가격을 책정하고, 다음 고객에게 판매하기 전에 제공 시스템을 구축합니다. 대부분의 컨설턴트는 네 번째 단계를 건너뛰고 계속 시간을 돈으로 교환합니다. 그것이 실제로 규모를 만드는 유일한 단계입니다. **[운영자 노트]** 저는 수년간 맞춤형 컨설팅 업무를 수행해 왔습니다 — 각각 다른 범위, 다른 가격, 다른 제공 방식으로. 결과는 모든 프로젝트에서 직접적인 주의가 필요한 비즈니스였습니다. 제품화가 그것을 바꿨습니다: 가장 많이 요청되는 업무를 명확한 결과물, 고정 가격, 반복 가능한 제공 플레이북이 있는 정의된 서비스로 전환함으로써. 여기에 정확한 프레임워크와 구축하면서 저지른 실수들이 있습니다. ## 제품화된 서비스란 실제로 무엇인가 제품화된 서비스는 리테이너가 아닙니다. 구독이 아닙니다. 고정 범위, 고정 가격, 그리고 매번 같은 방식으로 작동할 만큼 충분히 문서화된 제공 프로세스를 가진 정의되고 반복 가능한 서비스입니다. 맞춤형 컨설팅과의 대조: "범위에 따라 $X~Y에 AI 자동화 전략을 제공합니다" 대신, "AI 자동화 로드맵: 5개 워크플로우의 서면 감사, 우선 순위 지정된 구축 권장 사항, 30분 제공 통화, $2,500"을 판매합니다. 범위 고정. 가격 고정. 일정 고정. 유일한 변수는 고객이 예스를 말하는지 여부입니다. 리테이너와의 차이는 프로젝트 기반이라는 것입니다. 명확한 시작. 명확한 끝. 개방형 월별 청구 없음, 범위 확대 없음, 사후의 "이것도 봐줄 수 있나요?" 대화 없음. 확장 가능하게 만드는 것: 서비스가 아닌 시스템입니다. 고정 가격 서비스는 단지 재가격화된 맞춤 작업입니다. 제품화된 서비스 뒤에는 제공 플레이북이 있습니다. ## 1단계: 고객이 이미 의뢰하는 업무를 찾아라 구축하기 가장 쉬운 제품화된 서비스는 이미 반복해서 제공하고 있지만 매번 맞춤 작업으로 취급하는 서비스입니다. 최근 10~15개의 고객 또는 프로젝트를 살펴보고 패턴을 찾으세요: - 가장 자주 나타나는 문제는 무엇인가요? - 가장 자주 생산하는 결과물은 무엇인가요? - 어떤 유형의 업무가 가장 원활하게 진행되고 최고의 고객 피드백을 받나요? 저에게는 패턴이 명확했습니다: 고객들이 계속 같은 것을 요청했습니다 — 프로세스 매핑, 자동화할 프로세스 선택, 구축을 위한 올바른 도구 선택. 반복해서 했지만 매번 다른 범위로. 그 패턴이 당신의 출발점입니다. 시장이 필요로 한다고 생각하는 새로운 서비스가 아닙니다. 이미 하고 있는 것입니다. 하나의 필터: 모든 고객에게 결과가 거의 동일한 작업만 제품화하세요. 각 고객이 완전히 다른 결과물을 받는다면 그 작업은 아직 제품화할 수 없습니다 — 여전히 진정한 맞춤 작업입니다. 괜찮습니다. 그것은 단지 정의 작업이 먼저 와야 한다는 것을 의미합니다. ## 2단계: 범위 경계를 정의하고 지켜라 여기서 대부분의 컨설턴트가 실패합니다. 서비스를 모호하게 정의하고, 범위를 해석에 열어두고, 이전과 같은 범위 확대 대화에 빠집니다. 제품화된 서비스에는 명확한 범위 경계가 필요합니다. 첫 번째 영업 통화 전에 서면으로 포함되는 것과 포함되지 않는 것을 정의합니다. AI 자동화 전략 스프린트에 대한 범위 정의 예시: **포함:** - 60분 구조화된 인테이크 통화 - 최대 5개 워크플로우의 서면 감사 - 도구 권장 사항이 포함된 우선 순위 지정된 자동화 로드맵 - 상위 3개 후보에 대한 구축 대 구매 평가 - 30분 제공 워크스루 통화 **포함되지 않음:** - 구현 (에이전트 또는 통합 구축) - 제공 후 수정 - 5개 이상의 워크플로우 - 합의된 자동화 범위 외 작업 "포함되지 않음" 목록은 "포함" 목록만큼 중요합니다. 고객이 경계 밖의 것을 요청하면 두 가지 선택이 있습니다: 이 서비스의 범위 밖이라고 말하거나, 고유한 가격으로 범위가 지정된 추가 서비스를 만드는 것입니다. 하지 않을 것은 그것을 흡수하는 것입니다. 처음에는 불편하게 느껴집니다. 고객을 만족시키기 위해 예스라고 말하는 데 익숙합니다. 제품화는 "그것은 별도의 프로젝트입니다"라고 말하는 것을 요구합니다 — 그리고 일관되게 그것을 의미하는 것을. ## 3단계: 시간이 아닌 결과 가치를 기반으로 가격을 책정하라 시간당 청구와 제품화된 서비스는 혼합되지 않습니다. 시간을 기반으로 계산하기 시작하는 순간, 다시 맞춤 작업으로 만든 것입니다. 제품화된 서비스 가격 책정을 위한 세 가지 변수: 1. **고객이 문제를 해결하지 않을 경우의 비용.** 월 $4,000의 운영 효율성을 창출하는 AI 자동화 로드맵은 구매자에게 수천 달러의 가치가 있습니다. 당신의 8시간 작업은 잘못된 가격 앵커입니다. 2. **구매자가 유사한 결과에 지출하는 것.** 경쟁업체가 부과하는 것이 아닌 — 고객이 컨설턴트, 분수 임원, 또는 문제를 부분적으로 해결하는 소프트웨어에서 유사한 결과에 실제로 지출하는 것. 이것이 상한선을 설정합니다. 3. **최소 하한선.** 제공 시간, 고객 관리, 간접비를 고려할 때 이 서비스에서 주의를 기울일 만큼 얼마나 벌어야 합니까? 이것이 하한선을 설정합니다. 그 범위 내에서 가격을 설정하세요. 초기 제품화된 서비스의 경우 중간에서 시작하세요. 추천사를 수집하고 제공 속도를 개선함에 따라 상한선을 향해 이동하세요. 할인하지 마세요. 누군가 서비스를 감당할 수 없다면, 그들은 그것에 맞는 고객이 아닙니다. 다른 세그먼트를 위한 저가 서비스를 구축할 수 있습니다 — 하지만 임시 할인으로 기본 서비스를 희석하지 마세요, 그렇지 않으면 맞춤형 가격 책정으로 돌아갑니다. ## 4단계: 다음 판매 전에 제공 시스템을 구축하라 이 단계가 제품화된 서비스가 있는지 아니면 단순히 고정 가격 프로젝트가 있는지를 결정합니다. 첫 번째 제공 후 — 다음에 판매하기 전에 — 이것을 하세요: 1. **순서대로 모든 단계를 문서화하세요.** 모호한 개요가 아닙니다. 도메인에 익숙한 누군가가 프로세스의 80%를 실행할 수 있을 만큼 상세한 체크리스트. 이것들을 [Notion](/recommends/notion)에 보관합니다 — 워크플로우 단계당 한 페이지, 템플릿, 출력 예시, 어려운 판단을 위한 의사결정 트리 포함. 2. **예상보다 오래 걸린 것을 파악하세요.** 모든 첫 번째 제공은 필요한 것보다 느립니다. 병목 현상을 찾고 체계화하세요: 인테이크 양식, 결과물 템플릿, 사전 구축된 프레임워크. 3. **구조화된 인테이크 프로세스를 구축하세요.** 통화 전에 표준화된 양식으로 고객 정보를 얻는 것이 제공을 예측 가능하게 만드는 것입니다. 통화는 명확화 질문을 위한 것이지 정보 수집을 위한 것이 아닙니다. 4. **결과물 템플릿을 만드세요.** 모든 고객이 동일한 출력 구조를 받습니다. 내용은 다를 수 있지만 구조는 다르지 않습니다. 이것은 제공을 빠르게 하고 출력을 매번 일관되고 전문적으로 보이게 합니다. 이 단계를 건너뛰고 그냥 다음에 판매한다면, 여전히 맞춤 작업을 하고 있는 것입니다 — 그것에 고정 가격만 부여했을 뿐입니다. 시스템이 실제로 확장 가능하게 만드는 것입니다. ## 제품화가 실제로 열어주는 것 주요 이점은 더 높은 수익이 아닙니다. 더 나은 수익입니다: 예측 가능한 수요, 더 빠른 제공, 더 적은 협상 대화, 그리고 서비스 범위 밖의 것을 원하는 고객에게 아니오라고 말할 수 있는 능력. 두 번째 이점: 제공 문서가 지적 재산이 됩니다. 제품화된 컨설팅 서비스를 위해 구축하는 플레이북은 코스나 교육 프로그램 내용의 대부분입니다. 저는 AI 자동화 컨설팅으로 이것을 했습니다 — 제공 플레이북이 직접 제 AI Agents for Beginners 코스의 교육과정 골격이 되었습니다. 세 번째 이점: 레버리지. 문서화된 시스템을 통해 인테이크 및 제공 통화에 집중하면서 제공의 일부 — 감사, 연구, 문서 작성 — 를 실행하도록 누군가를 교육할 수 있습니다. 그것이 일대일 시간 대 돈 트레드밀에서 벗어나기 시작하는 것입니다. ## 제품화된 서비스 관리에 사용하는 도구 **[Airtable](/recommends/airtable)** — 고객 프로젝트당 한 행, 상태, 결과물 링크, 지불 추적. 복잡성 없이 한 명에서 오십 명의 고객으로 확장됩니다. **[Notion](/recommends/notion)** — 제공 플레이북과 고객 중심 워크스페이스. 각 고객은 반복적인 제공을 통해 다듬어진 템플릿에서 구축된 공유 Notion 워크스페이스를 받습니다. **[ConvertKit](/recommends/convertkit)** — 대기 목록 관리 및 후속 시퀀스. 서비스가 가득 찼을 때 (고정 범위 작업에서는 용량이 빨리 채워집니다), 대기 목록 시퀀스는 다음 오프닝까지 따뜻한 리드의 참여를 유지합니다. ## 가장 자주 보는 실수 **충분히 제공하기 전에 제품화하기.** 이 작업을 3~5번 하지 않았다면 실제 범위를 아직 모릅니다. 먼저 맞춤 작업으로 제공하세요. 경계가 어디에 있는지 배우세요. 그런 다음 제품을 정의하세요. **범위를 모호하게 두기.** 정의되지 않은 범위를 가진 제품화된 서비스는 고정 가격 맞춤 프로젝트입니다 — 이것은 두 세계의 최악입니다. 포함되는 것을 정의하고, 포함되지 않는 것을 정의하고, 서면으로 작성하고, 판매 페이지에 올리세요. **범위 외 요청에 예스 말하기.** 고객이 더 많은 것을 요청하면 고유한 범위와 가격으로 추가 서비스를 만드세요. 이번 한 번만 흡수하지 마세요. **제공 시스템 건너뛰기.** 첫 번째 제공 후에 완료되지 않았습니다. 두 번째를 판매하기 전에 플레이북을 구축하세요. 시스템이 제품을 만드는 것입니다. ## FAQ ### 제품화된 서비스를 몇 개로 시작해야 하나요? 하나. 구축하고, 제공하고, 시스템을 다듬고, 추천사를 수집한 다음 두 번째를 고려하세요. 동시에 두 개를 출시하는 대부분의 사람들은 두 개 모두 반쯤 구축된 시스템과 어느 쪽에도 추천사가 없는 상태로 끝납니다. ### 판매를 시작하기 전에 랜딩 페이지가 필요한가요? 아니요. 처음 5~10번의 판매를 위해서는 한 페이지 PDF나 잘 작성된 이메일로 충분합니다. 웹사이트 구축이 아직 아무것도 판매하지 않은 이유가 되지 않도록 하세요. ### 고객이 범위 밖의 것을 원한다면 어떻게 하나요? 그것은 별도의 프로젝트라고 말하세요. 그 자리에서 추가 서비스를 견적 내거나 범위 확정 통화를 예약하세요. 현재 프로젝트에 흡수하지 마세요. 범위를 유지하는 규율이 모델을 작동하게 하는 것입니다. ### 첫 번째 고객을 어떻게 확보하나요? 당신의 일을 아는 10명에게 서비스에 대해 말하세요 — 당신을 신뢰하거나 필요로 하는 사람을 아는 사람들과의 따뜻한 대화. 첫 번째 판매는 거의 항상 랜딩 페이지가 아닌 직접적인 대화에서 옵니다. 하나의 케이스 스터디가 생기면 [창업자 주도 영업 접근 방식](/founder-led-sales-how-to-reach-decision-makers/)이 그것을 확장하기 시작합니다. ### 한 번만 한 것을 제품화할 수 있나요? 아니요. 아직 실제 범위를 이해하지 못합니다. 맞춤 작업으로 두세 번 더 제공한 다음, 배운 것을 제품으로 공식화하세요. --- **다음 단계:** 제 [AI Agents for Beginners 코스](/course/)는 제품화된 제공을 확장 가능하게 만드는 자동화 시스템을 다룹니다. [코워크 프로그램](/cowork/)은 시스템 중심 비즈니스를 구축하고 구조화된 환경에서 그것을 하고 싶은 운영자를 위한 것입니다. --- ## LinkedIn 리드 생성 전략: 유료 광고 없이 B2B 클라이언트를 얻는 방법 Source: https://alejandrorioja.com/ko/linkedin-lead-generation-strategy/ Published: 2026-07-14 Tags: Marketing, Growth, Entrepreneurship TL;DR: LinkedIn은 B2B 리드 생성에서 가장 높은 레버리지를 제공하는 무료 채널입니다 — 대규모 콜드 아웃리치 기계가 아닌 신뢰 엔진으로 취급한다면. 프로필을 랜딩 페이지처럼 최적화하고, 전문성의 한 각도에서 일관되게 게시하며, 가치를 앞세운 짧은 접촉 시퀀스를 구축하세요. 복리 효과는 60~90일이 지나면 느껴지고, 이후에는 거의 자동으로 작동합니다. 유료 광고는 선택사항이지만 날카로운 프로필과 유용한 콘텐츠 피드는 그렇지 않습니다. ## 목차 _2026년 7월 게시._ **TL;DR:** LinkedIn은 B2B 리드 생성에서 가장 높은 레버리지를 제공하는 무료 채널입니다 — 대규모 콜드 아웃리치 기계가 아닌 신뢰 엔진으로 취급한다면. 프로필을 랜딩 페이지처럼 최적화하고, 전문성의 한 각도에서 일관되게 게시하며, 가치를 앞세운 짧은 접촉 시퀀스를 구축하세요. 복리 효과는 60~90일이 지나면 느껴지고, 이후에는 거의 자동으로 작동합니다. 유료 광고는 선택사항이지만 날카로운 프로필과 유용한 콘텐츠 피드는 그렇지 않습니다. **운영자의 관점:** 저는 LinkedIn을 사용해 컨설팅 문의, 강좌 구매자, 파트너십 대화를 생성했습니다 — 모두 광고 한 건 없이. 작동하는 것은 해킹이나 도구가 아닙니다. 구매자들이 이미 모여 있는 공간에서 진정으로 유용한 사람으로 나타나는 것입니다. 이것이 제가 사용하는 정확한 플레이북이며, 오늘 처음부터 시작한다면 실행할 순서입니다. ## 2026년에 LinkedIn인 이유 LinkedIn의 유기적 도달률은 거의 다른 모든 플랫폼보다 더 잘 유지되고 있습니다. 관련성 높은 팔로워 수백 명을 가진 사람의 게시물도 수천 명의 타겟 전문가에게 도달할 수 있습니다 — 대부분의 다른 채널에서는 실제 돈이 필요한 일입니다. 알고리즘은 단순한 좋아요가 아닌 저장과 공유를 유도하는 전문 지식이 풍부한 콘텐츠를 계속 보상합니다. B2B 특히, LinkedIn은 신뢰할 만한 대안이 없습니다: - 의사결정자들은 어떤 다른 플랫폼보다 이곳에서 더 접근하기 쉽습니다. - 의도 신호는 전문적입니다 — 사람들은 목적 없이 스크롤하는 것이 아니라 "업무 모드"에 있습니다. - 댓글이나 게시물은 잠재 고객이 몇 주 또는 몇 달 후에 찾을 수 있는 당신의 사고에 대한 공개 기록을 만듭니다. - InMail과 연결 요청은 여전히 가장 낮은 획득 비용 아웃리치 메커니즘 중 하나입니다. 주의사항: LinkedIn을 가치 있게 만드는 동일한 개방성이 대규모 아웃리치, 일반적인 사상 리더십 게시물, 투명한 영업 피치로도 넘쳐납니다. 눈에 띄기 위한 기준은 낮습니다. 대부분의 사람들은 그것조차 충족하지 못합니다. ## 1단계: 무언가를 게시하기 전에 프로필을 고치세요 LinkedIn 프로필은 잠재 고객이 연결 요청을 받거나 당신이 작성한 게시물을 우연히 발견할 때 가장 먼저 읽는 것입니다. 누구를 돕고 어떻게 돕는지를 즉시 전달하지 못하면, 그 외에 하는 모든 것이 훼손됩니다. 가장 중요한 네 가지 포인트: 1. **헤드라인** — 직책이 아닙니다. 작동하는 공식: _[내가 하는 것] [누구를 위해] 그들이 [결과]할 수 있도록_. "영업 팀 없이 B2B SaaS 창업자가 첫 10건의 엔터프라이즈 거래를 성사시키도록 돕는다"는 검색 가능하고, 구체적이며, 즉시 자기 자격 확인이 됩니다. 2. **배너 이미지** — 같은 메시지를 강화하는 데 사용하세요. 틈새 시장이나 짧은 증거 문구가 있는 깔끔한 비주얼이 일반적인 그라디언트보다 낫습니다. 3. **소개 섹션** — 1인칭으로 작성하세요. 두 개의 짧은 단락: 무엇을 하는지와 누구를 위해, 그 다음 하나 또는 두 개의 증거 포인트 (고객, 결과, 성과 — 실제). "X를 하려고 한다면 DM을 보내주세요"라는 명확한 행동 촉구로 마무리하세요. 4. **추천 섹션** — 한두 개를 고정하세요: 리드 마그넷, 최고의 게시물, 사례 연구, 예약 링크. 대부분의 사람들이 비워두는 최고의 공간입니다. 테스트: 낯선 사람처럼 자신의 프로필을 읽으세요. 10초 이내에 무엇을 하는지, 누구를 위해 하는지, 다음에 무엇을 해야 하는지 알 수 있습니까? 그렇지 않다면 계속 편집하세요. ## 2단계: 하나의 각도에서 일관되게 게시하세요 가장 흔한 LinkedIn 실수는 무작위로 게시하는 것입니다 — 월요일에 마케팅 팁, 수요일에 동기부여 인용구, 금요일에 제품 피치. 알고리즘은 당신을 무시하고 독자도 마찬가지입니다. 작동하는 것은 전문성의 특정 각도 하나를 선택하고 그것을 소유하는 것입니다. 90일 동안 그 각도에서 주당 3~4회 게시하세요. 초기 단계에서는 양과 일관성이 영감과 세련됨을 이깁니다. ### 복리 효과를 만드는 콘텐츠 믹스 | 형식 | 용도 | 효과가 있는 이유 | | --- | --- | --- | | 짧은 텍스트 게시물 (3~5줄) | 반직관적 견해, 빠른 프레임워크, 최근 업무에서 얻은 교훈 | 높은 도달률, 소비 장벽이 낮음, 댓글 유발 | | 리스트 게시물 | 단계별 분석, 비교, 도구 | 저장 및 공유; 알고리즘 선호 | | 스토리 게시물 | 경험한 구체적인 상황, 내가 한 일, 무슨 일이 일어났는지 | 다른 어떤 형식보다 빠르게 신뢰 구축 | | 긴 글 | 심층 가이드, 에버그린 설명 | 검색에 인덱싱; 시간이 지남에 따라 전문가로 포지셔닝 | | 캐러셀 (문서) | 시각적 프레임워크, 긴 게시물 요약 | 모든 형식 중 가장 높은 저장률 | 내가 사용하는 비율: 70% 짧은 게시물과 리스트, 20% 스토리, 10% 긴 글 또는 캐러셀. 긴 글 게시물은 많은 도달률을 얻지 못하지만 수개월에 걸쳐 검색과 DM 공유에서 축적됩니다. ## 3단계: 의도적으로 연결 기반을 구축하세요 LinkedIn에서 올바른 팔로워를 늘리는 것은 단순히 수를 늘리는 것과 다릅니다. 정확히 당신의 구매자인 1,000명의 팔로워는 동료나 무작위 관찰자인 10,000명보다 더 가치 있습니다. 내 타겟팅 기준: - 내가 서비스하는 산업의 의사결정자들 - 내가 일하는 수익 범위의 회사 창업자 및 운영자 - 기존 고객 및 협력자의 2차 연결 (가장 따뜻한 소스) - 내 공간의 경쟁자나 동료와 상호작용하는 사람들 하루에 15~20개의 연결 요청을 보내며, 각각 연결하는 이유를 명시한 한 줄 메모를 첨부합니다. 피치가 아닌 맥락: "[주제]에 대한 댓글을 봤습니다. 제 업무와 관련이 있어서 — 연결하게 되어 기쁩니다." 이 메모는 수락률을 ~30% (일반)에서 ~55~65% (구체적)로 높입니다. 메모는 최대 두 문장입니다. 모두와 연결하지 마세요. 자격이 없는 계정으로 가득 찬 부풀려진 연결 목록은 실제로 해를 끼칩니다 — LinkedIn의 알고리즘은 부분적으로 연결에게 게시물을 배포하므로, 낮은 품질의 독자는 도달률을 억제합니다. ## 4단계: 아웃리치 시퀀싱 — 세 번의 접촉 방법 누군가가 연결되면 즉시 피치하는 것이 목표가 아닙니다. 시간이 지남에 따라 미팅으로 이어질 수 있는 대화를 시작하는 것입니다. 연결을 영업 덱을 붙여넣는 허가로 취급하는 사람들은 이후의 모든 접점을 오염시킵니다. 내가 사용하는 시퀀스: **접촉 1 (1일차, 연결 후 24시간 이내):** 짧고 따뜻한 환영 메시지를 보내세요. 연결한 이유를 언급하고 그들이 공유한 것과 관련된 유용한 리소스 — 게시물, 프레임워크, 기사 — 를 공유하세요. 요청 없음. 질문이 아닌 진술로 끝내세요. **접촉 2 (5~7일차):** 그들의 게시물 중 하나에 진실되게 참여하세요 — 단순한 좋아요가 아닌 대화에 기여하는 실제로 사려 깊은 댓글. 이것은 다른 DM을 보내지 않고도 그들의 피드에서 당신의 이름을 눈에 띄게 유지합니다. **접촉 3 (14~21일차):** 부드럽고 구체적인 요청으로 DM을 팔로업하세요. 그들의 업무에서 발견한 관련 사항과 연결된 명확하고 답하기 쉬운 질문. 타이밍이 맞고 고통이 실제라면, 여기서 미팅이 예약됩니다. 그렇지 않으면 계속 진행하세요 — 계정은 따뜻해졌고 그들은 당신의 이름을 알고 있습니다. 제가 지속적으로 보는 실수: 접촉 1과 2를 건너뛰고 누군가가 연결되는 순간 CTA 메시지로 바로 뛰어드는 것. 그것은 리드 생성이 아닙니다; 명성에 대한 세금입니다. ## 5단계: 대화를 미팅으로 전환하세요 DM에서의 좋은 대화는 캘린더 초대로의 깨끗한 출구가 필요합니다. 누군가가 진정한 관심을 보이는 순간 — 후속 질문을 하거나, 문제를 직접 언급하거나, 솔루션에 반응할 때 — 그것이 요청할 때입니다. 전환하는 메시지: > "[그들이 말한 구체적인 것]이 당신에게 실제라고 들립니다. 비슷한 상황의 회사 몇 곳을 도왔습니다 — 피치 없이 어떻게 접근했는지 20분 동안 설명해도 괜찮습니다, 그저 관련이 있는지 보려고요. [예약 링크] — 유용하다면 슬롯을 잡으세요." 짧고, 부담이 적으며, 예스하기 쉽습니다. 예약 링크는 발생해야 할 미팅의 절반을 죽이는 일정 조율 마찰을 제거합니다. ## 하지 말아야 할 것들 계정이 무시되고, 신고되거나, 정지되게 하는 행동들: 1. **맥락 없는 대량 연결 요청** — LinkedIn이 계정을 제한하고 수락률이 떨어집니다. 2. **피치 먼저 DM** — 첫 번째 메시지는 제품, 가격 또는 캘린더 링크를 소개하는 곳이 아닙니다. 3. **인게이지먼트 팟** — 가짜 참여는 허영 지표를 부풀리고 알고리즘적으로 페널티를 받습니다. 4. **관점 없이 매일 게시** — 관점 없는 양은 소음입니다. 진정한 통찰이 있는 주 1회 게시물이 실질 없는 주 7개의 "핫 테이크"를 이깁니다. 5. **아웃리치 자동화** — LinkedIn의 봇 감지가 공격적이 되었습니다. 대규모 자동화 연결 도구와 AI가 작성한 DM 시퀀스는 플래그 처리됩니다. 4단계의 시퀀스는 하루 약 30분이 걸리며 어떤 도구도 매칭할 수 없는 신호 대 노이즈 비율을 가집니다. ## 실제로 중요한 것 측정 무시할 허영 지표: 노출, 프로필 방문 수, 팔로워 수. 시스템이 작동하는지 알려주는 숫자: - **연결 수락률** — 메모 포함 50% 이상 목표; 30% 미만이면 메모를 다시 쓰세요. - **팔로업 메시지 답변률** — 잘 타겟팅된 목록에서 20~30%는 건강합니다. - **월 수신 DM** — 콘텐츠 때문에 연락하는 사람들. 매월 추적하세요. - **LinkedIn에서 예약된 월 통화** — 수익과 상관 관계가 있는 유일한 숫자. 저는 이것을 간단한 Notion 테이블에서 추적합니다. 처음 90일의 목표는 LinkedIn만으로 주당 하나의 수신 DM과 월 하나의 예약 통화에 도달하는 것입니다. 3개월째에는 콘텐츠가 효과를 발휘하면 이 숫자들이 비례적으로 더 많은 노력 없이 올라갑니다. ## 운영자의 결론 LinkedIn이 B2B 리드 생성에 효과적인 이유는 유기적 도달률이 여전히 무게감을 가지고 있으며 당신의 명성이 시간이 지남에 따라 공개적으로 축적되는 유일한 전문 네트워크이기 때문입니다. 메카닉은 간단합니다: 당신이 누구를 돕는지 설명하는 프로필, 당신이 무엇을 알고 있는지 증명하는 콘텐츠, 그리고 피치 대신 가치를 앞세우는 접촉 시퀀스. 90일 동안 일관되게 실행하면 인바운드가 도착하기 시작합니다. 1년 동안 실행하면 광고 예산 없이 가장 신뢰할 수 있는 자격 있는 대화 소스 중 하나가 됩니다. --- **관련:** [창업자 주도 영업](/founder-led-sales-how-to-reach-decision-makers/) · [개인 브랜드 구축 방법](/how-to-build-a-personal-brand/) · [아웃리치 전략](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) --- ## Courtlines를 만든 방법: Claude로 개발한 클럽 관리 SaaS Source: https://alejandrorioja.com/ko/how-i-built-courtlines-a-club-management-saas-with-claude/ Published: 2026-07-11 Tags: AI Agents, Case Study TL;DR: Courtlines는 라켓 스포츠 클럽과 스튜디오를 위한 운영 체제입니다 — 예약, 멤버십, 코칭, POS, 이벤트를 하나의 브랜드 아래에 담았습니다. 저는 Claude를 엔지니어링 파트너로 삼아 1인 운영자로서 이것을 만들었습니다. 교훈은 이렇습니다: AI는 단지 코딩을 더 빠르게 해준 것이 아니라, 한 사람이 신뢰할 수 있게 출시하고 운영할 수 있는 제품의 규모 자체를 바꿔놓았습니다. ## 목차 _2026년 7월 업데이트._ **요약:** Courtlines는 라켓 스포츠 클럽과 스튜디오를 위한 운영 체제입니다 — 예약, 멤버십, 코칭, POS, 이벤트를 하나의 브랜드 아래에 담았습니다. 저는 Claude를 엔지니어링 파트너로 삼아 1인 운영자로서 이것을 만들었습니다. 교훈은 이렇습니다: AI는 단지 코딩을 더 빠르게 해준 것이 아니라, 한 사람이 신뢰할 수 있게 출시하고 운영할 수 있는 제품의 규모 자체를 바꿔놓았습니다. **[운영자의 시각]** 저는 컨설팅 브랜드와, 제가 텍사스 오스틴 광역권에서 운영하는 피클볼 시설 Pickleland에 걸쳐 30개 이상의 프로덕션 에이전트를 운영합니다. 실제 시설을 운영하다 보니 저 같은 클럽을 위한 소프트웨어가 얼마나 형편없는지 정확히 배우게 됐습니다 — 그래서 제가 원했던 소프트웨어를 직접 만들었습니다. 이 글은 [Courtlines](https://courtlines.com)에 관한 이야기이자, 그것이 무엇을 하는지, 그리고 Claude에 기대어 한 사람이 어떻게 보통은 팀이 필요한 것을 만들 수 있었는지에 관한 이야기입니다. ## 클럽에 필요한 것은 앱이 아니라 운영 체제인 이유 스포츠 시설을 운영해 본 적이 없다면 소프트웨어 문제는 눈에 보이지 않습니다. 밖에서 보면 "사람들이 코트를 예약한다" 정도로 보입니다. 안에서 보면 클럽은 서로 앞뒤가 맞아떨어져야 하는 수십 개의 움직이는 부품으로 이루어진, 작고 복잡한 사업체입니다. 회원이 코트를 예약합니다. 그 예약은 회원이 멤버십 플랜에 가입되어 있는지, 크레딧이 있는지, 그 코트가 이미 클리닉을 위해 잡혀 있는지, 코치가 배정되어 있는지, 프런트 데스크가 가격을 임의로 조정했는지를 알아야 합니다. 회원이 방문하면 누군가 카운터에서 공 한 통을 계산합니다 — 그게 POS입니다. 자녀를 주니어 프로그램에 등록시킵니다 — 그게 이벤트와 가족 계정입니다. 레슨 10회 패키지를 구매합니다 — 그건 코치에게 별도의 정산 로직이 딸린 코칭 패키지입니다. 친구를 추천합니다 — 그건 멤버십 유입 경로입니다. 대부분의 클럽은 이것을 서로 연결되지 않은 서너 개의 도구와 스프레드시트, 그리고 단체 문자로 운영합니다. 예약 시스템은 POS를 모릅니다. POS는 멤버십을 모릅니다. 월말이 되면 그 누구의 숫자도 맞아떨어지지 않습니다. **Courtlines는 "이 모든 게 하나의 시스템이라면 어떨까?"에 대한 답입니다.** 이것은 기능을 덧붙인 예약 앱이 아니라 — 캘린더, 멤버십, 계산대, 코칭 정산, 공개 이벤트 페이지가 모두 동일한 기반 데이터 위에 있는 단일 운영 체제입니다. 그것이 전체 논지이자 사이트에 걸린 태그라인입니다: 클럽과 스튜디오를 위한 운영 체제. ## Courtlines가 실제로 하는 일 큰 틀에서 [Courtlines](https://courtlines.com)는 클럽에게 다음을 제공합니다: - **드래그 앤 드롭 코트 그리드** — 프런트 데스크를 위한 것으로, 모든 예약, 클리닉, 홀드를 관리자가 실시간으로 재배치할 수 있는 한 화면에 담습니다. - **예약과 오픈 플레이** — 회원을 위한 것으로, 어색하지만 꼭 필요한 예외 상황까지 포함합니다: 반복 예약, 대기자 명단, 취소 가능 기간, 크레딧. - **멤버십과 결제** — 플랜, 가족 계정, 부모 계정에 연결된 주니어/아동 로그인, 그리고 매출이 조용히 새어 나가지 않게 막는 미납 관리. - **코칭** — 레슨 패키지, 일정 관리, 그리고 독립 코치에게 지급되는 자동 정산. - **POS** — 프로 숍과 카페를 위한 실제 계산대로, 다른 모든 것과 동일한 고객 레코드에 연결됩니다. - **이벤트와 공개 페이지** — 사람들이 찾아서 신청할 수 있는 공개 페이지를 갖춘 클리닉, 리그, 토너먼트. 설계 목표는 플랫폼이 보이지 않게 사라지는 것입니다. 클럽은 자신의 브랜드를 위에 씌우고, 회원들에게는 그저 "우리 클럽 앱"처럼 느껴집니다 — "우리가 돈 주고 쓰는 어떤 SaaS"가 아니라. 이는 이 분야의 기존 업체들 — CourtReserve와 Skedda 같은 곳들 — 과 의도적으로 대비되는 지점입니다. 그런 곳들에서는 소프트웨어가 브랜드이고 클럽은 임차인일 뿐입니다. Pickleland는 첫 번째 테넌트입니다. 저는 데모 뒤에 숨을 수 없습니다. 이것은 제가 개인적으로 책임지는 시설을 실제로 운영해야 합니다. 그 제약이 제가 겪어본 최고의 프로덕트 매니저였습니다. [여기서 Pickleland를 볼 수 있습니다](https://pickleland.com) — 이곳은 현실 세계의 검증장이며, 회원이 부딪히는 모든 거친 모서리는 제가 그날 바로 느끼는 버그입니다. ## 나를 놀라게 한 부분: 이제 한 명의 운영자가 출시할 수 있는 것 이 이야기의 솔직한 버전이자, 제가 조용히 출시하는 대신 이 글을 쓰는 이유입니다. 결제, POS, 역할 기반 접근 제어, 코칭 정산, 공개 이벤트 시스템을 갖춘 멀티 테넌트 SaaS는 주말 프로젝트가 아닙니다. 10년 전이라면 이것은 시드 투자를 받은 다섯에서 여덟 명 규모의 엔지니어링 팀이 1년 동안 매달릴 일입니다. 1인 창업자라면 보통 친절하게도 기능 하나로 범위를 좁히고 투자를 받으라는 조언을 듣는 그런 규모입니다. 저는 이것을 한 사람으로서, **Claude를 주력 엔지니어링 파트너로 삼아** 만들었습니다. "가끔 ChatGPT에 코드 조각을 물어봤다"는 뜻이 아닙니다 — Claude가 이 시스템의 코드 대부분을 작성했다는 뜻입니다. 제가 소유한 사양과 제품 결정을 바탕으로 말이죠. 제 역할은 *구현을 타이핑하는 것*에서 *무엇이 참인지 결정하는 것*으로 옮겨갔습니다: 데이터 모델이 어떠해야 하는지, 특정 역할이 무엇을 할 수 있는지, 한 기능에서 "완료"란 무엇을 의미하는지, 그리고 무엇을 출시하는 것이 안전한지. 흥미로운 변화는 속도가 아닙니다 — 물론 더 빠르긴 하지만요. 그것은 **규모**입니다. AI는 같은 규모의 제품에서 저를 2배 개발자로 만든 게 아닙니다. 제가 신뢰할 수 있게 만들 수 있는, 그리고 못지않게 중요하게는 혼자서 *운영하고 유지보수할* 수 있는 제품의 규모를 바꿔놓았습니다. 오직 한 사람만이 작성한 코드베이스는 자기 무게에 짓눌려 무너질 것입니다. AI 파트너가 구현 세부 사항을 쥐고 제가 아키텍처와 안전장치를 쥐는 코드베이스는 진정으로 다른 종류의 것입니다 — 그리고 그것이 이제 한 명의 운영자가 예전에는 회사가 필요했던 카테고리에 도전할 수 있는 이유입니다. 저는 Courtlines를 운영하는 정확한 방식을 여기에 의도적으로 공개하지 않습니다 — 그것은 제가 경쟁 우위로 여기는 부분이며, 저는 경쟁자들이 이것이 큰 팀을 필요로 한다고 계속 믿기를 바랍니다. 하지만 제가 실제 프로젝트에서 Claude를 운용하는 *구체적인 방법*을 자세히 보고 싶다면, 훨씬 작은 프로젝트에 대해 전부 기록해 두었습니다: 제가 앱 스토어에 출시한 모바일 게임입니다. [Claude로 모바일 보드게임 Quads를 만든 방법](/how-i-built-quads-a-mobile-board-game-with-claude/)을 보세요 — 같은 작업 방식이고, 숨기는 것 없이 모든 요령을 테이블 위에 올려놓았습니다. ## 내가 타협하지 않는 원칙들 플레이북을 비공개로 유지하더라도, AI로 진지한 소프트웨어를 만드는 누구에게나 적용되기 때문에 짚어둘 만한 몇 가지 원칙이 있습니다: **위험한 펜은 사람이 쥔다.** 실수가 비싸고 되돌리기 어려운 소수의 작업이 있습니다 — 스키마 변경, 배포, 돈이나 프로덕션 데이터를 건드리는 모든 것. 그런 것들은 확고하게 제 몫으로 남습니다. AI는 그것을 제안할 수 있지만, 실행할 수는 없습니다. 그 경계를 명확하게 긋는 것이야말로 다른 모든 곳에서 AI에게 많은 자유를 주는 것을 안전하게 만듭니다. **초록불 테스트는 필요조건이지 충분조건이 아니다.** 모든 단위 테스트를 통과하는 예약 흐름도 실제 브라우저에서는 눈에 띄게 망가져 있을 수 있습니다. UI가 있는 제품에서 가장 중요한 검증은 사람 — 또는 감독받는 프로세스 — 이 현실적인 데이터를 상대로 실제로 클릭해 보는 것입니다. 테스트는 상황이 더 나빠지지 않게 막아주는 기울기일 뿐, 기능이 작동한다는 증명이 아닙니다. 저는 이것을 비싼 대가를 치르고 배웠고, 그것은 제가 "완료"를 정의하는 방식을 영구히 바꿔놓았습니다. **사양이 진짜 인터페이스다.** 지렛대는 영리한 프롬프팅에 있지 않습니다 — 시스템이 무엇이고 각 부분이 무엇을 해야 하는지에 대한 명확하고 최신의 문서를 유지하는 데 있습니다. 그것들을 정확하게 유지하는 데 쓴 시간은 앞으로의 모든 세션에 걸쳐 여러 배로 돌아옵니다. 이것의 더 깊은 버전을 원한다면, [프로덕션에서 실패하지 않는 AI 에이전트 시스템 프롬프트를 작성하는 법](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/)에서 설명한 것과 동일한 규율입니다. **직접 감당해야 하는 것을 만들어라.** 최고의 결정 하나는 Courtlines가 제가 소유한 시설을 운영하게 만든 것이었습니다. 사람들을 감탄시키는 데모를 출시하기는 쉽습니다. 하지만 자신의 회원들이 의존하는 소프트웨어로부터 숨는 것은 불가능합니다. AI로 무언가를 만든다면, 당신이 개인적으로 느끼는 문제를 겨냥하세요 — 그 현실 점검은 어떤 테스트 스위트보다 값집니다. ## 이것이 내가 만드는 다른 모든 것과 어떻게 맞물리는가 Courtlines는 홀로 존재하지 않습니다. 그것은 제가 구축하고 있는 작은 라켓 스포츠 생태계의 일부입니다: [The Court Scout](https://thecourtscout.com)는 검증된 피클볼 코트 디렉터리로, 경쟁 상대인 스크래핑 기반 디렉터리보다 진정으로 더 정확하도록 만들어졌으며, Pickleland는 모든 것이 검증되는 대표 시설입니다. 디렉터리는 선수들이 코트를 찾도록 돕고, Courtlines는 그 코트 뒤에 있는 클럽들이 실제로 운영되도록 돕습니다. 이 모든 것을 관통하는 연결 조직은 동일한 운영 모델입니다: AI로 증폭된 1인 운영자가, 역사적으로 1인 운영자가 감당할 수 있었던 것보다 더 넓은 영역을 운영하는 것. Courtlines는 지금까지 그 모델의 가장 야심 찬 표현입니다 — 몇 년 전이었다면 저 혼자서는 아예 시도조차 하지 않았을 완전한 SaaS 플랫폼입니다. 라켓 스포츠 클럽이나 스튜디오를 운영하는데 네 개의 도구를 이어 붙이는 데 지쳤다면, [Courtlines](https://courtlines.com)를 한번 살펴보세요. 그리고 실제 제품에서 AI를 얼마나 멀리 밀어붙일 수 있는지 궁금한 빌더라면, 그것이 바로 이 글의 요점입니다: 아마 당신이 생각하는 것보다 훨씬 더 멀리. ## 자주 묻는 질문 ### Courtlines가 무엇인가요? Courtlines는 라켓 스포츠 클럽과 스튜디오를 위한 멀티 테넌트 운영 체제입니다 — 피클볼, 테니스, 파델, 그 너머까지. 예약, 멤버십, 코칭, POS, 이벤트 관리를 하나의 브랜드 플랫폼에 결합해, 클럽이 서로 연결되지 않은 네 개의 도구 대신 단일 시스템에서 사업 전체를 운영할 수 있게 합니다. [courtlines.com](https://courtlines.com)에서 확인할 수 있습니다. ### 정말로 Claude가 코드 대부분을 작성했나요? 네. Claude는 제 주력 엔지니어링 파트너였고, 제가 소유하고 통제하는 사양, 아키텍처, 제품 결정을 바탕으로 구현의 대부분을 작성했습니다. 저는 스키마, 배포, 그리고 "완료"의 정의를 쥐고, AI는 구현 세부 사항을 쥡니다. 그 분업이 이 규모의 1인 제작 SaaS를 유지보수 가능하게 만드는 요소입니다. ### 정말로 한 사람이 AI로 이렇게 큰 SaaS를 만들고 운영할 수 있나요? 만드는 것은 이제 진정으로 실현 가능합니다 — 그게 놀라운 부분입니다. 더 큰 도전은 운영하고 유지보수하는 것인데, 큰 코드베이스는 AI가 세부 사항을 작성했더라도 아키텍처를 이해하는 누군가가 필요하기 때문입니다. 핵심은 명확한 사양을 유지하고, 사람이 반드시 소유해야 하는 소수의 고위험 작업에 대해 확고하게 선을 지키는 것입니다. 그렇게 하면 한 명의 운영자가 유지보수할 수 있는 영역은 예전보다 훨씬 넓어집니다. ### CourtReserve나 Skedda를 쓰는 대신 직접 클럽 소프트웨어를 만든 이유는 무엇인가요? Pickleland를 운영하면서 기존 도구들이 정확히 어디서 부족한지 알게 됐기 때문입니다: 예약 시스템, 계산대, 멤버십이 하나의 진실 원천을 공유하지 않아서 아무것도 깔끔하게 맞아떨어지지 않습니다. 저는 이 모든 것이 동일한 기반 데이터이고, 회원들이 보는 것이 소프트웨어 공급업체의 브랜드가 아니라 클럽의 브랜드인 시스템을 원했습니다. 그것이 Courtlines가 메우려는 간극입니다. ### 당신이 실제로 Claude와 매일 어떻게 일하는지 어디서 배울 수 있나요? 경쟁상의 이유로 자세한 Courtlines 플레이북은 비공개로 유지하지만, 완전히 공개된 더 작은 프로젝트 — Quads라는 모바일 보드게임 — 에서 정확히 같은 작업 방식을 기록했습니다. 구체적인 방법은 [Claude로 모바일 보드게임 Quads를 만든 방법](/how-i-built-quads-a-mobile-board-game-with-claude/)을 읽어보시고, 제가 출시하는 모든 것 뒤에 있는 ROI 사고방식은 [자동화를 만들 가치가 있는지 어떻게 판단하는가](/ai-agent-roi-how-i-decide-whether-automation-worth-building/)를 읽어보세요. --- ## Claude로 모바일 보드게임 Quads를 만든 방법 — 2시간 해커톤에서 앱 스토어까지 Source: https://alejandrorioja.com/ko/how-i-built-quads-a-mobile-board-game-with-claude/ Published: 2026-07-11 Tags: AI Agents TL;DR: Quads는 모바일 보드게임입니다 — 고전 추상 게임 Quarto를 깔끔하게 재해석한 것으로, 콜롬비아에서 친구와 한 2시간 해커톤에서 시작해 앱 스토어에 출시되었습니다. 이 글은 제가 Claude로 만드는 방식을 완전히 공개한 버전입니다: 병렬 에이전트 worktree, 진짜 (LLM이 아닌) 게임 AI, 오프라인 우선 설계, 그리고 제 시간을 잡아먹은 구체적인 함정들. ## 목차 _2026년 7월 업데이트._ **요약:** Quads는 모바일 보드게임입니다 — 고전 추상 게임 Quarto를 깔끔하게 재해석한 것으로, 콜롬비아에서 친구와 한 2시간 해커톤에서 시작해 앱 스토어에 출시되었습니다. 이 글은 제가 Claude로 만드는 방식을 완전히 공개한 버전입니다: 병렬 에이전트 worktree, 진짜 (LLM이 아닌) 게임 AI, 오프라인 우선 설계, 그리고 제 시간을 잡아먹은 구체적인 함정들. **[운영자의 시각]** 저는 컨설팅 브랜드와, 오스틴 광역권에 있는 제 피클볼 시설 Pickleland에 걸쳐 30개 이상의 프로덕션 에이전트를 운영합니다. 제가 만드는 것 대부분은 플레이북을 비공개로 유지하는 진지한 비즈니스 소프트웨어입니다. Quads는 그 반대입니다 — 처음부터 끝까지 보여드릴 수 있는 재미있는 사이드 프로젝트입니다. 제가 Claude와 어떻게 일하는지 아무것도 깎아내지 않고 정확히 보고 싶다면, 이 글이 바로 그것입니다. 게임은 [playquads.com](https://playquads.com)에서 찾을 수 있습니다. ## 콜롬비아에서 2시간 해커톤으로 시작했다 시작은 거의 민망할 만큼 즉흥적이었습니다. 저는 콜롬비아로 여행 중이었고, 친구와 저는 스스로에게 2시간 해커톤을 걸었습니다: 작은 걸 하나 골라 AI로 만들고, 얼마나 멀리 가는지 보자. 우리는 Quarto에 정착했습니다 — 배우기 쉽고 놀랍도록 깊은, 아름답고 작은 추상 전략 게임입니다. 두 시간 뒤 우리에게는 플레이 가능한 프로토타입이 생겼고, 그 아이디어는 노트북에 남겨두기엔 너무 좋았습니다. 시간제한을 건 도전으로 시작한 것이 iOS와 Android에 출시된 진짜 모바일 앱이 되었습니다. 그 궤적 — *농담 같은 프로토타입에서 스토어 등록까지* — 이야말로 제가 이 프로젝트가 글로 쓸 가치가 있다고 생각하는 이유입니다. "재미있는 아이디어"와 "낯선 사람이 다운로드할 수 있는 것" 사이의 거리는 무너져 내렸고, Quads는 그 방법에 대한 깔끔한 사례 연구입니다. 먼저, 이름에 대해 잠깐 짚고 넘어가겠습니다. 이 게임은 **Quarto**의 재구현인데, Quarto는 Gigamic이 소유한 상표 등록된 게임입니다. 그래서 아주 첫 번째 비코드 결정은 고객이 볼 수 있는 어느 곳에서도 그것을 Quarto라고 *부르지 않는* 것이었습니다. 이름은 Quarto(메커니즘)에서 몇 개의 임시 이름을 거쳐 **Quads** — 제가 마음대로 쓸 수 있는 이름 — 로 바뀌었습니다. 고전을 재구현하고 있다면, 이름과 사랑에 빠지기 전에 상표 문제부터 정리하세요. ## Quads가 실제로 무엇인가 입문자를 위해: Quads는 16개의 고유한 말이 있는 4×4 보드에서 플레이합니다. 모든 말은 네 개의 이진 속성을 가집니다 — 큰지 작은지, 어두운지 밝은지, 사각인지 원형인지, 꽉 찼는지 비었는지 — 그리고 16개의 말은 가능한 모든 조합을 정확히 한 번씩 덮습니다. *어느 하나의* 속성을 공유하는 네 개의 말로 한 줄을 완성하면 이깁니다. 이 게임을 탁월하게 만드는 반전: **당신은 놓을 말을 고르지 않습니다. 상대가 당신에게 건네줍니다.** 그러면 당신도 상대에게 말을 건넵니다. 그래서 매 턴은 이중 구속입니다 — 당신은 건네받은 말을 승리를 만들지 않으면서 놓으려 애쓰는 동시에, 상대에게 게임을 넘겨주지 않는 말을 골라 건네야 합니다. 우아하면서도 정말로 어렵습니다. 앱은 네 가지 플레이 방식을 제공하며, 모두 완전히 오프라인입니다: 다섯 단계 난이도의 컴퓨터 대전, 한 기기에서 하는 패스 앤 플레이, 데일리 퍼즐, 그리고 비동기식 "친구에게 도전" 모드. 계정도, 서버도, 로그인도 없습니다. 그 오프라인 우선 결정이 많은 엔지니어링을 이끌었고, 1인 제작이 감당 가능했던 큰 이유이기도 합니다. ## 게임 로직: 비트 연산에서 떨어져 나오는 규칙 전체 이건 제가 가장 좋아하는 부분입니다. AI가 작성했든 아니든 만족스러운 종류의 것이기 때문입니다. 16개의 말 각각은 그저 0부터 15까지의 정수입니다. 네 개의 비트 각각이 하나의 속성입니다. 그게 전부입니다 — 말 세트 전체가 숫자 0–15입니다. 네 개의 비트가 정확히 16개의 조합을 주기 때문입니다. 그러면 승리 판정은 거의 사소해집니다. 네 개의 말로 이루어진 어떤 줄이든, 두 개의 누산기를 유지합니다: *모든* 말에서 `1`인 비트들과, *모든* 말에서 `0`인 비트들. 네 개 모두를 처리한 후 어느 누산기든 0이 아니라면, 그 말들은 최소한 하나의 속성에서 일치하는 것입니다 — 그게 승리입니다. 규칙 전체가 몇 개의 비트 AND 연산으로 압축됩니다. 로직이 정수에 대한 순수 함수 — 프레임워크도, UI도, 상태도 없는 — 이기 때문에, 직접 단위 테스트가 가능하고, 확장하기도 아주 쉽습니다. Quads는 심지어 아홉 개의 2×2 정사각형도 승리 형태로 인정하는 하우스 룰 변형까지 제공하는데, 이는 같은 비트 트릭 위에 두 줄만 추가하면 됩니다. 당신과 AI 파트너가 핵심 로직을 이렇게 깔끔하게 유지하면, 기능을 추가하는 일은 위험이 아니라 즐거움이 됩니다. ## AI 상대는 LLM이 아니다 (그리고 그게 옳은 선택이다) 여기 제가 아끼는 교훈이 있습니다: **모든 "AI"가 거대 언어 모델이어야 하는 것은 아닙니다.** Quads의 상대는 순수한 고전 게임 AI이며, 마땅히 그래야 합니다. 매 턴 두 가지 결정을 내립니다 — 건네받은 말을 어디에 놓을지, 그리고 어떤 말을 되돌려 건넬지 — 그리고 난이도는 얼마나 깊이 생각하는지를 조절합니다: - **루키**는 사실상 무작위로 플레이하며 당신에게 승리를 넘겨줄 것입니다. - 중간 단계는 휴리스틱을 더합니다: 즉시 이길 수 있는 수가 있으면 취하고, 상대가 이길 수 있는 말을 건네지 않도록 피하며, 미래의 위협을 가장 적게 무장시키는 말을 선호합니다. - **마스터와 그랜드마스터**는 제한된 negamax 탐색 — 진짜 게임 트리 탐색 — 을 실행하지만, 한 수가 절대로 폰의 메인 스레드를 멈추게 할 수 없도록 엄격한 **노드 예산**을 둡니다. 완벽한 탐색이 불가능한 게임 초반에는 빠른 휴리스틱으로 되돌아가고, 트리가 충분히 작은 후반에는 실제로 탐색합니다. 여기서 훔쳐 갈 만한 두 가지. 첫째, 언어 모델은 여기서 *더 나쁠* 것입니다 — 50줄짜리 negamax보다 더 느리고, 더 비싸고, 비결정적이며, 이기기 쉽습니다. 도구를 문제에 맞추세요. 둘째, 노드 예산이야말로 진짜 엔지니어링입니다: 모바일 기기에서 "정확하지만 가끔 4초 동안 멈춘다"는 실패한 기능입니다. 한 수가 항상 빠르도록 — 가끔 최적이 아니더라도 — 탐색을 제한하는 것이 장난감과 제품의 차이입니다. *언제* LLM을 꺼내 들어야 하는지 아는 것은 제가 모든 자동화에 적용하는 것과 동일한 판단입니다 — 그것이 [AI 빌드가 그럴 가치가 있는지 어떻게 판단하는가](/ai-agent-roi-how-i-decide-whether-automation-worth-building/)의 핵심입니다. ## 내가 실제로 Claude를 운용하는 방법: worktree 안의 병렬 에이전트 이제 제가 더 큰 제품에서는 비공개로 유지하지만 여기서는 완전히 보여드릴 수 있는 부분입니다. 저는 한 번에 하나의 Claude 세션으로 만들지 않습니다. 저는 **여러 개를 병렬로** 실행하며, 각각을 자기만의 브랜치 위 자기만의 git worktree에서 돌립니다. 한 에이전트는 국제화를 추가하고, 다른 하나는 데일리 퍼즐 시스템을 만들고, 또 다른 하나는 색맹 모드를 하고, 또 하나는 사운드를 연결합니다 — 각각이 자기만의 작업 사본에 격리되어 서로를 덮어쓸 수 없고, 초록불이 되면 각각 다시 병합됩니다. Quads의 git 히스토리는 `Merge branch 'worktree-agent-…'` 커밋의 벽이며, 그 워크플로가 밖에서 보이는 모습이 정확히 그렇습니다. worktree가 중요한 이유는 간단합니다: 같은 작업 디렉터리를 편집하는 병렬 에이전트는 즉시 서로를 짓밟습니다. 각각에게 격리된 체크아웃을 주면 진정으로 네 개의 기능을 동시에 진행하다가, 다른 여느 브랜치처럼 병합할 수 있습니다. 그것은 제 작업 방식에서 지렛대가 가장 큰 단 하나의 변화입니다 — 저는 하나의 대화, 하나의 기능에서 작은 함대로 옮겨갔습니다. 그 에이전트들이 돌아가는 프롬프트 뒤의 규율을 원한다면, 그것은 [프로덕션에서 실패하지 않는 AI 에이전트 시스템 프롬프트를 작성하는 법](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/)에서 설명한 것과 동일합니다: 지렛대는 영리한 표현이 아니라 명확하고 최신인 사양에 있습니다. ## 나에게 한 시간을 잡아먹은 함정 (그래서 당신에게는 잡아먹지 않도록) 모든 프로젝트는 멍청하고 값비싼 교훈 하나를 가르쳐 줍니다. Quads에서는 이것이었습니다: **미리보기 도구가 당신이 생각하는 브랜치를 항상 보여주는 것은 아니다.** 여러 worktree에서 여러 에이전트를 실행하고 그들의 작업을 미리 볼 때, 미리보기는 현재 세션이 있는 디렉터리와 *다른* 디렉터리에서 실행될 수 있습니다 — 그래서 앱을 스크린샷 찍고, 변경 사항이 하나도 보이지 않아, 애초에 사라진 적도 없는 "사라진" UI를 디버깅하기 시작합니다. 기능은 멀쩡했습니다. 미리보기가 잘못된 체크아웃을 가리키고 있었을 뿐입니다. 무슨 일이 벌어지는지 알아내기 전까지 저는 실제 시간을 잃었고, 미래의 저 자신(그리고 제가 저장소를 넘겨줄 어떤 에이전트든)이 유령 버그를 디버깅하기 *전에* 미리보기 대상을 확인하도록 프로젝트 자체의 노트에 이것을 적어두었습니다. 관련된 함정: 그 미리보기를 정의하는 설정 파일은 병렬 세션 전반에 공유되므로, 두 에이전트가 동시에 그것을 편집하면 서로의 항목을 조용히 덮어쓸 수 있습니다. 함대를 운영할 거라면, 공유 설정을 경합 자원으로 취급하세요 — 그것은 딱 한 번 당신을 물 것이고, 교훈을 적어두면 그다음부터는 절대 물지 않습니다. 그 습관 — 힘들게 얻은 모든 함정을 다음 세션이 읽을 지속적인 파일에 담아두는 것 — 은 어떤 규모에서든 AI로 만드는 일의 조용한 근간입니다. 맥락은 세션 사이에 증발합니다. 적어둔 교훈은 그렇지 않습니다. ## 내가 자랑스러워하는 오프라인 우선 기법들 Quads에는 백엔드가 없기 때문에, 몇 가지 문제는 영리한 서버리스 답이 필요했습니다: - **데일리 퍼즐**은 로컬의 연중 며칠째인지로부터 결정론적으로 선택되어, 전 세계 모든 플레이어가 서버 조율 없이 동일한 퍼즐을 받습니다. (보너스 교훈: 저는 그 날짜 계산에서 서머타임으로 인한 하나 차이 오류를 출시했다가 곧바로 고쳤습니다. 날짜는 언제나 보이는 것보다 어렵습니다.) - **"친구에게 도전"**은 퍼즐을 짧은 텍스트 코드 — `QC1-01-03-3` 같은 것 — 로 인코딩하며, 오타가 유효하지만 잘못된 도전을 만들어낼 수 없도록 체크섬으로 보호합니다. 친구는 자기 앱 사본에 그것을 입력하고 정확히 같은 국면을 완전히 오프라인으로 플레이합니다. 계정도, 매치메이킹도, 서버도 없습니다. - **리치 링크 미리보기**는 제가 아주 약간의 서버 코드를 실제로 사용한 유일한 곳입니다. 도전 링크를 공유하면, 하나의 Cloudflare Pages Function이 코드별 Open Graph 태그를 렌더링해 링크가 iMessage나 WhatsApp에서 멋지게 펼쳐지도록 합니다. 소셜 크롤러는 JavaScript를 실행하지 않으므로, 클라이언트에서 렌더링한 미리보기는 모든 링크에 대해 동일하게 보일 것입니다 — 하나의 작은 함수가 진짜 백엔드 없이 그것을 해결합니다. 이것들 중 어느 것도 일단 보고 나면 어렵지 않지만, 각각은 게으른 답이 "서버와 데이터베이스를 띄운다"이고 더 나은 답이 "영리한 오프라인 방식을 한다"인 지점입니다. 백엔드를 완전히 피한 것이 한 사람이 이것을 출시하고 유지보수할 수 있었던 이유입니다. ## 해커톤에서 스토어 등록까지 마지막 구간 — "2시간 프로젝트"에 대해 아무도 말해주지 않는 부분 — 은 "내 폰에서 작동한다"와 "낯선 사람이 다운로드할 수 있다" 사이의 모든 것입니다. 한 번의 작업으로 여덟 개 언어에 걸친 국제화. 상표 등록된 이름을 절대 쓰지 않는 스토어 문구. 스토어 심사에서 반려당하지 않게 해주는 앱 스토어 빌드 도구, 버전 관리, 그리고 플랫폼별 권한 정리. 이것은 화려하지 않고, 많은 사이드 프로젝트가 조용히 죽는 곳입니다. Claude와 함께 그것을 하는 것이 체크리스트를 짧게 만들어주지는 않았지만, 각 항목을 충분히 저렴하게 만들어 제가 실제로 끝낼 수 있게 해주었습니다. 그것이 Quads의 진짜 이야기입니다: AI가 보드게임을 작성했다는 것이 아니라 — 많은 사람이 하나쯤 프로토타입을 만들 수 있습니다 — *마지막 한 마일*의 비용을 충분히 낮춰서 해커톤 농담이 출시된 제품이 되게 했다는 것입니다. 붙잡고만 있던 작은 아이디어가 있다면, 그게 제 전부의 권유입니다. 2시간짜리 버전을 시작하세요. 결승선이 얼마나 가까이 옮겨왔는지 놀라실 겁니다. 그리고 이 동일한 작업 방식이 규모에서 얼마나 위로 올라가는지 보고 싶다면, 저는 그것을 완전한 멀티 테넌트 SaaS까지 끌고 갔습니다 — [Claude로 클럽 관리 플랫폼 Courtlines를 만든 방법](/how-i-built-courtlines-a-club-management-saas-with-claude/). Quads를 [playquads.com](https://playquads.com)에서 플레이하세요. ## 자주 묻는 질문 ### Quads가 무엇인가요? Quads는 iOS와 Android용 모바일 보드게임입니다 — 고전 추상 전략 게임 Quarto를 깔끔하게 재구현한 것입니다. 16개의 고유한 말이 있는 4×4 보드에서 플레이하며, 반전은 당신이 놓아야 할 말을 상대가 고른다는 점입니다. 무료로 플레이할 수 있고 솔로, 패스 앤 플레이, 데일리 퍼즐, 비동기 도전 모드가 있습니다. [playquads.com](https://playquads.com)에서 찾으세요. ### Claude가 게임 전체를 작성했나요? Claude가 코드 대부분을 작성했습니다. 제가 소유한 디자인과 결정을 바탕으로 말이죠. 저는 여러 Claude 세션을 병렬로 실행했고, 각각을 자기만의 git worktree에서 돌려 서로 다른 기능을 만든 뒤 합쳤습니다. 게임 로직, AI 상대, 국제화, 사운드, 퍼즐 시스템은 대부분 이런 방식으로 만들어졌고 제가 검토했습니다. ### 게임 내 AI 상대는 LLM으로 구동되나요? 아니요 — 그리고 의도적으로 그렇습니다. 상대는 고전 게임 AI를 사용합니다: 낮은 난이도에서는 휴리스틱을, 최상위 단계에서는 제한된 negamax 탐색을 쓰며, 한 수가 절대 기기를 멈추게 하지 않도록 엄격한 노드 예산을 둡니다. 언어 모델은 이 작업에 더 느리고, 더 비싸고, 더 약할 것입니다. 문제에 맞는 종류의 AI를 고르는 것이 항상 가장 큰 모델을 꺼내 드는 것보다 더 중요합니다. ### Quads를 만드는 데 얼마나 걸렸나요? 첫 플레이 가능한 프로토타입은 콜롬비아 여행 중 친구와 한 2시간 해커톤에서 나왔습니다. 그 프로토타입을 국제화, 진짜 AI 상대, 오프라인 도전, 스토어 규정 준수를 갖춰 두 앱 스토어 모두에 출시 가능한 다듬어진 앱으로 바꾸는 데는 상당히 더 오래 걸렸지만, 각 개별 단계가 AI로 충분히 저렴해서 프로젝트가 실제로 결승선에 도달했습니다. ### Claude로 Quads를 만들면서 얻은 가장 큰 교훈은 무엇인가요? 두 가지입니다. 첫째, 여러 기능을 서로 짓밟지 않고 병렬로 만들 수 있도록 에이전트를 격리된 git worktree에서 실행하세요. 둘째, 다음 세션이 읽을 지속적인 파일에 모든 함정을 적어두세요 — 맥락은 세션 사이에 증발하지만, 적어둔 교훈은 복리로 쌓입니다. 이 작업 방식의 더 큰 그림은 [Claude로 Courtlines를 만든 방법](/how-i-built-courtlines-a-club-management-saas-with-claude/)을 보세요. --- ## 프로덕션에서 실패하지 않는 AI 에이전트 시스템 프롬프트 작성법 Source: https://alejandrorioja.com/ko/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/ Published: 2026-07-11 Tags: AI Agents TL;DR: 프로덕션 시스템 프롬프트는 5개의 레이어로 구성된다: 정체성(에이전트가 누구이고 무엇을 할 수 없는지), 컨텍스트(환경에 대해 무엇을 아는지), 작업(성공이 단계별로 어떻게 보이는지), 출력 형식(가장 과소평가된 레이어), 엣지 케이스(입력이 실패할 때 무엇을 할지). 대부분의 프롬프트는 레이어 4와 5를 건너뛰기 때문에 실패한다. 출력 형식을 먼저 작성하라 — 실제로 원하는 것을 정확하게 생각하도록 강제한다. ## 목차 _2026년 7월 업데이트._ **TL;DR:** 프로덕션 시스템 프롬프트는 5개의 레이어로 구성된다: 정체성(에이전트가 누구이고 무엇을 할 수 없는지), 컨텍스트(환경에 대해 무엇을 아는지), 작업(성공이 단계별로 어떻게 보이는지), 출력 형식(가장 과소평가된 레이어), 엣지 케이스(입력이 실패할 때 무엇을 할지). 대부분의 프롬프트는 레이어 4와 5를 건너뛰기 때문에 실패한다. 출력 형식을 먼저 작성하라 — 실제로 원하는 것을 정확하게 생각하도록 강제한다. **[운영자 관점]** 나는 컨설팅 브랜드와 Pickleland(텍사스주 플루거빌에 있는 피클볼 시설)에서 30개 이상의 AI 에이전트를 프로덕션에서 운영하고 있다. 내가 새로 작성한 것보다 다시 작성한 시스템 프롬프트가 더 많다. 대부분 첫 번째 버전이 테스트에서는 잘 작동하다가 프로덕션에서 조용히 품질이 저하되기 때문이다. 오래 지속되는 프롬프트를 작성하는 방법에 대해 내가 배운 것이다. ## 아무도 인정하지 않는 시스템 프롬프트 문제 대부분의 에이전트 시스템 프롬프트는 약 20분 만에 작성되고, 두세 가지 예시로 테스트되고, 그 후에는 다시 건드리지 않는다. 모델이 배포된다. 잠시 동안은 잘 작동한다. 그러다가 무언가가 바뀐다 — 입력이 더 지저분해지고, 모델이 업데이트되고, 새로운 엣지 케이스가 나타난다 — 그러면 에이전트는 쓰레기를 생성하기 시작한다. 조용하게. 대규모로. 문제는 원래 프롬프트가 나빴던 게 아니다. 대부분의 프롬프트가 '행복한 경로'를 보여주기 위해 작성된다는 것이다. 에이전트를 구축할 때 염두에 두었던 입력을 위해 설계되었지, 에이전트가 실제로 볼 전체 입력 분포를 위한 게 아니다. ## 프로덕션 시스템 프롬프트의 5개 레이어 내가 작성하는 모든 시스템 프롬프트를 5개의 레이어로 생각한다. 이 순서로 나타날 필요는 없지만 모두 존재해야 한다. ### 레이어 1: 정체성 정체성은 모델에게 자신이 누구인지와 운영상의 제약이 무엇인지를 알려준다. 롤플레이 캐릭터가 아니라 — 이 에이전트가 무엇을 하고 하지 않는지에 대한 기능적 정의다. 강력한 정체성 레이어는 세 가지 질문에 답한다: - 이 에이전트는 무엇을 담당하는가? - 명시적으로 담당**하지 않는** 것은 무엇인가(에스컬레이션하거나 거부해야 하는)? - 어떤 기준을 유지하는가? '하지 않는' 범위를 명시하는 것이 대부분의 운영자가 건너뛰는 부분이다. 이것 없이는 모델이 자신의 영역 밖에서 도움이 되려고 할 것이고 — 그게 바로 문제가 생기는 지점이다. ### 레이어 2: 컨텍스트 컨텍스트는 에이전트가 자신의 환경에 대해 알고 있지만 사용자 메시지에는 없는 것이다. 현재 날짜와 시간(동적으로 주입 — 모델의 내부 시간 감각은 절대 믿지 말 것), 외부 시스템의 관련 상태, 작업 설명에서 명확하지 않은 비즈니스 규칙이 포함된다. 내가 검토하는 대부분의 에이전트는 컨텍스트가 부족하다. 가정하지 마라. 주입하라. ### 레이어 3: 작업 작업 레이어는 에이전트가 단계별로 무엇을 하는지 설명한다. "고객 돕기"가 아니라 — 실제 의사결정 흐름이다. 지시문이 아니라 순서도처럼 작성하라. 순서도는 모호한 경우에 원하는 것을 추론할 필요성을 줄이기 때문에 더 견고하다. ### 레이어 4: 출력 형식 이것이 가장 과소평가된 레이어이며 무음 실패에 가장 책임이 있는 것이다. 출력 형식을 정확하게 지정하지 않으면 모델은 사람 독자에게는 올바르게 보이지만 다운스트림 파싱을 깨트릴 만큼 일관성이 없는 출력을 생성한다. 출력 형식을 먼저 작성하라. 구조화된 출력에는 정확한 스키마를 지정하라. 산문 출력에는 구조, 길이, 톤 제약을 지정하라. 고위험 에이전트에는 정의된 JSON 스키마와 함께 [Claude](/recommends/claude)의 구조화된 출력을 사용한다. ### 레이어 5: 엣지 케이스 엣지 케이스 레이어가 답하는 질문: 입력이 모호하거나, 불완전하거나, 잘못된 언어이거나, 적대적이거나, 명확히 잘못된 경우 에이전트는 무엇을 하는가? 각 엣지 케이스에 대해 모델에게 명시적인 응답 경로를 제공하라. ## 시간이 지나면서 시스템 프롬프트를 유지하는 방법 프로덕션 시스템 프롬프트는 살아있는 문서다: 1. **주간 스팟 체크.** 각 고위험 에이전트의 5~10개의 무작위 출력을 예상 출력과 대조하여 검토한다. 2. **모델 업데이트 후 검토.** 기반 모델 버전이 바뀔 때마다 [평가 프레임워크](/how-i-measure-whether-an-ai-agent-is-actually-working/)의 전체 골든 세트에 대해 에이전트를 실행한다. 3. **엣지 케이스 로그.** 에이전트가 잘못 처리한 입력에 대한 지속적인 로그를 유지한다. 세 개 이상의 항목이 패턴을 공유할 때 명시적인 규칙을 추가한다. 4. **프롬프트 버전 관리.** 모든 중요한 변경사항은 프롬프트 파일 상단에 버전 주석을 받는다. ## 자주 묻는 질문 ### 프로덕션 시스템 프롬프트는 얼마나 길어야 하나요? 5개 레이어를 모두 커버할 만큼 충분히 길게. 2분 안에 읽고 드리프트를 발견할 만큼 충분히 짧게. 대부분의 에이전트에서 200~600단어다. ### 복잡한 작업을 여러 에이전트로 분할해야 하는 시점은 언제인가요? 작업에 다른 컨텍스트, 다른 출력 형식, 또는 다른 오류 처리가 필요한 두 가지 이상의 별개 모드가 있을 때. 패턴에 대해서는 [이벤트 트리거 대 스케줄 에이전트](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/)를 참조하라. ### 테스트에서 작동했던 프롬프트가 프로덕션에서 실패하는 가장 일반적인 이유는 무엇인가요? 테스트 입력이 프로덕션 분포를 대표하지 않았다. 상상된 입력이 아닌 실제 프로덕션 트래픽에서 테스트 세트를 구축하라. --- ## AI 에이전트 ROI: 자동화를 구축할 가치가 있는지 결정하는 방법 Source: https://alejandrorioja.com/ko/ai-agent-roi-how-i-decide-whether-automation-worth-building/ Published: 2026-07-09 Tags: AI Agents, Operations TL;DR: AI 에이전트를 구축하기 전에 4단계 ROI 검사를 실시합니다: 수동 비용 정량화, 구축 비용 추정, 운영 비용 예측, 유지 관리 세금 추가. 결과는 회수 기간입니다. 비전략적 작업에서 6개월을 초과하면 중단합니다. 대부분의 에이전트 아이디어는 이 테스트를 통과하지 못합니다 — 그것이 핵심입니다. 잘못된 자동화를 구축하는 것은 아무것도 구축하지 않는 것보다 나쁩니다. ## 목차 _2026년 7월 업데이트._ **TL;DR:** AI 에이전트를 구축하기 전에 4단계 ROI 검사를 실시합니다: 수동 비용 정량화, 구축 비용 추정, 운영 비용 예측, 유지 관리 세금 추가. 결과는 회수 기간입니다. 비전략적 작업에서 6개월을 초과하면 중단합니다. 대부분의 에이전트 아이디어는 이 테스트를 통과하지 못합니다. **[운영자 관점]** 저는 컨설팅 브랜드와 텍사스주 프플러그빌에 있는 피클볼 시설 Pickleland에서 30개 이상의 AI 에이전트를 프로덕션으로 운영하고 있습니다. 출시한 것만큼 많은 에이전트를 중단했습니다. 중단된 것들은 나쁜 아이디어가 아니었습니다 — 수학 검증을 통과하지 못한 좋은 아이디어들이었습니다. ## 아무도 먼저 하지 않는 질문 2026년에 모든 사람이 "이것을 어떻게 자동화하나요?"라고 묻습니다. 더 나은 질문은 "이것을 자동화해야 하나요, 그리고 언제 회수되나요?"입니다. AI 에이전트는 무료가 아닙니다. 구축에 시간이 걸리고, 운영에 돈이 들고, 유지 관리에 지속적인 주의가 필요합니다. 자동화가 수동 대안보다 빠르게 그 비용을 회수하지 못하면, 운영을 더 복잡하고 비싸게 만들었을 뿐입니다. ## 1단계: 수동 기준선 정량화 첫 번째 수치는 현재 프로세스의 연간 비용입니다. ``` 연간_수동_비용 = (인스턴스당_시간 × 시급 × 연간_빈도) + 연간_오류_비용 ``` **인스턴스당 시간**은 누군가가 실제로 소비하는 시계 시간입니다. **시급**은 작업을 수행하는 사람의 전체 비용입니다. 본인의 시간이라면 영(0)이 아닌 컨설팅 또는 기회비용 요율을 사용하세요. **연간 빈도**는 이 작업이 실제로 실행되는 횟수입니다. **오류 비용**은 대부분의 사람들이 잊어버리는 요소입니다. Pickleland의 실제 사례: Facebook 이벤트 홍보를 수동으로 발송하는 데 주당 45분이 걸렸습니다. 기회비용 요율로 이는 주당 $45 또는 연간 $2,340입니다. 이것이 기준선입니다. ## 2단계: 구축 비용의 솔직한 추정 구축 비용은 거의 항상 과소평가됩니다. ``` 구축_비용 = (개발_시간 × 시급) + 도구_설정_비용 + 테스트_및_반복_시간 × 시급 + 통합_디버깅_시간 × 시급 ``` Pickleland 이벤트 홍보 도구의 경우: 구축 6시간, 테스트 및 조정 3시간, 통합 디버깅 2시간으로 추정했습니다. 제 요율로 이는 구축 비용 $990입니다. ## 3단계: 운영 비용 예측 ``` 연간_운영_비용 = (연간_API_호출_수 × 호출당_비용) + 연간_인프라_비용 + 인간_검토_시간 × 시급 ``` **API 호출**은 Claude/LLM 호출과 타사 API입니다. 실제 토큰 수를 기반으로 계산하세요. **인프라**는 Cloudflare Workers + Queues에서 중간 볼륨에 대해 월 $5 미만이 많습니다. **인간 검토**는 사람들이 가장 자주 잊어버리는 비용입니다. Pickleland 홍보 도구의 경우: 연간 약 1,000회 Claude API 호출. 인간 검토는 연 약 $800. 총 운영 비용: 연 약 $810. ## 4단계: 유지 관리 세금 적용 이것은 모든 에이전트 ROI 계산에서 가장 과소평가된 요소입니다. 에이전트는 고장납니다. 구축 비용의 20%를 연간 유지 관리 세금으로 적용합니다. ``` 연간_유지_관리_비용 = 구축_비용 × 유지_관리_비율 ``` Pickleland 홍보 도구의 경우: $990 × 20% = $198/년. ## 회수 공식 ``` 연간_순_절약 = 연간_수동_비용 − 연간_운영_비용 − 연간_유지_관리_비용 회수_개월 = (구축_비용 ÷ 연간_순_절약) × 12 ``` Pickleland 이벤트 홍보 도구의 경우: - 수동 비용: $2,340/년 - 운영 비용: $810/년 - 유지 관리: $198/년 - 연간 순 절약: $1,332/년 - 구축 비용: $990 - **회수 기간: 8.9개월** 이것은 경계선입니다. 비전략적 자동화의 임계값은 6개월입니다. ## 내 회수 기간 임계값 - **3개월 미만:** 즉시 구축. 이런 경우는 드뭅니다. - **3~6개월:** 명확한 예스. 복리 효과가 있는 자동화입니다. - **6~12개월:** 전략적으로 중요하면 구축. 그렇지 않으면 중단. - **12개월 초과:** 거의 항상 중단. ## 자동화하지 말아야 할 때 팀이 범하는 가장 비싼 실수는 불안정한 프로세스를 자동화하는 것입니다. 자동화 전에 확인하세요: 이 프로세스가 최소 3개월 동안 안정적이었나요? 두 번째 실수는 낮은 빈도와 높은 위험도의 작업을 자동화하는 것입니다. 세 번째: 대화를 피하기 위해 자동화하지 마세요. ## 이 자동화를 실행하는 에이전트 스택 프로덕션에서 실행하는 대부분의 자동화는 [Claude](/recommends/claude)를 LLM으로 사용하는 Cloudflare Workers + Queues에 있습니다. ## FAQ ### 내 시간에 어떤 시급을 사용해야 하나요? 기회비용을 사용하세요. 영(0)을 사용하지 마세요. ### 아무것도 구축하기 전에 Claude API 비용을 어떻게 추정하나요? 실제 입력의 대표적인 샘플과 대상 모델을 사용하여 Claude의 토큰 계수 엔드포인트를 사용하세요. ### "전략적" 자동화란 무엇인가요? 전략적 자동화는 (1) 보존 또는 전환에 영향을 미치는 방식으로 고객에게 직접 서비스하거나, (2) 수동으로는 달성할 수 없는 운영 규모를 가능하게 하거나, (3) 더 나은 결정을 유도하는 데이터를 생성합니다. ### 에이전트 모니터링에 소비하는 시간을 계산해야 하나요? 예. 모니터링 시간은 실제 지속적인 비용입니다. ### 그냥 하기 싫은 작업이라면 어떻게 하나요? 작업을 싫어하는 것은 실제 비용이 있습니다. 진심으로 싫어하는 작업에 대해서는 더 긴 회수 기간을 받아들이지만, 그것은 백지 위임장이 아닙니다. --- ## 창업자 주도 영업: 팀을 키우기 전에 올바른 구매자를 찾아 접촉하는 법 Source: https://alejandrorioja.com/ko/founder-led-sales-how-to-reach-decision-makers/ Published: 2026-07-09 Tags: Entrepreneurship, Growth, Marketing TL;DR: 영업팀을 채용하기 전에, 먼저 스스로 팔 수 있다는 걸 증명해야 한다. 창업자 주도 영업은 결국 세 가지로 귀결된다. 실제로 예스라고 말할 수 있는 단 한 사람을 찾아내고, 답장을 받을 만큼 리서치하고, 채널을 순서대로 배치하는 것 — 요청은 이메일, 시급한 후속은 전화, 따뜻한 소개는 LinkedIn. 대부분의 거래가 멈추는 이유는 피치가 약해서가 아니라 엉뚱한 받은편지함에 도착했기 때문이다. 그 함정을 우회하면, 유급 영업사원도 못 잡을 미팅을 잡게 된다. ## 목차 _2026년 7월 게재._ **요약:** 영업팀을 채용하기 전에, 먼저 스스로 팔 수 있다는 걸 증명해야 한다. 창업자 주도 영업은 결국 세 가지로 귀결된다. 실제로 예스라고 말할 수 있는 단 한 사람을 찾아내고, 답장을 받을 만큼 리서치하고, 채널을 순서대로 배치하는 것 — 요청은 이메일, 시급한 후속은 전화, 따뜻한 소개는 LinkedIn. 대부분의 거래가 멈추는 이유는 피치가 약해서가 아니라 엉뚱한 받은편지함에 도착했기 때문이다. 그 함정을 우회하면, 유급 영업사원도 못 잡을 미팅을 잡게 된다. **[운영자의 시선]** 내가 지켜본, 진짜 회사를 세운 창업자들은 모두 첫 거래를 직접 팔았다 — 처음엔 대개 서툴렀고, 그다음엔 잘했다. 이 과정을 건너뛸 지름길은 없다. 한 번도 직접 돌려보지 않은 영업 방식을 남에게 넘길 수는 없다. 당신의 구매자가 실제로 무엇에 반응하는지 아직 모르기 때문이다. 이것은 내가 직접 쓰고, 또 창업자들에게 코칭하는 프로세스다. 올바른 사람을 찾는 법, 답장을 받을 만큼만 리서치하는 법, 그리고 낯선 이들에게 무차별로 뿌리거나 스크래핑 도구를 사지 않고도 그들에게 닿는 법. ## 왜 창업자가 먼저 팔아야 하는가 한 번도 돌려본 적 없는 방식을 위임할 수는 없다. 스스로 몇 건의 거래를 성사시키기도 전에 영업사원을 채용한다면, 당신은 프로세스를 확장하는 게 아니라 프로세스의 발견을 외주로 넘기는 것이고, 공짜로 배웠어야 할 것을 배우라고 월급을 주는 셈이다. 창업자 주도 영업은 영업사원을 감당할 형편이 될 때까지 참고 견디는 단계가 아니다. 그것은 당신의 구매자가 쓰는 정확한 단어, 열 건 중 아홉 건을 죽이는 반론, 그리고 상대를 몸 기울이게 만드는 그 한 문장을 배우는 방법이다. 그 지식이 나중에 대본이 되고, 플레이북이 되고, 채용 기준이 된다. 이걸 건너뛰면 당신의 첫 영업 채용자는 추측을 물려받게 된다. 좋은 소식은, 창업자인 당신에게는 영업사원이 결코 가질 수 없는 불공정한 우위가 있다는 것이다. 당신이 그것을 직접 만들었다. 어떤 질문에도 답할 수 있고, 통화 중에 로드맵을 구부릴 수 있으며, 할당량을 짊어진 낯선 사람은 흉내조차 낼 수 없는 신뢰성으로 말할 수 있다. 당신의 일은 그 우위가 통할 만큼 자주 올바른 사람 앞에 서는 것이다. ## 1단계: 예스라고 말할 수 있는 단 한 사람을 찾아라 아웃리치가 실패하는 가장 흔한 이유는 엉뚱한 역할에게 도착한다는 것이다. 당신의 메시지는 거절당하는 게 아니라 — 애초에 그것에 대해 행동할 권한이 없는 사람에게 받아들여지고, 조용히 죽는다. 대부분의 회사에서, 당신과 거래 사이에는 세 유형의 사람이 있다. - **챔피언** — 당신의 제품이 해결하는 고통을 직접 느끼고 그것이 고쳐지길 원하는 사람. 대개 고위직은 아니지만, 사내에서 당신의 명분을 짊어질 사람이다. - **경제적 구매자** — 예산을 통제하고 지출을 승인할 수 있는 사람. 결국 예스라고 말하는 사람이다. - **차단자 / 게이트키퍼** — 소음을 걸러내는 것이 일인 구매 담당자, 비서, IT, 혹은 회의적인 부관. 당신의 적은 아니지만, 당신의 목표도 아니다. 누구에게든 연락하기 전에, 어느 쪽을 겨냥하는지 그리고 왜 그런지 결정하라. 첫 미팅에서는 대개 챔피언이나 경제적 구매자를 원해야 한다 — 그저 찾기 쉬워서 이름을 발견한 아무 직원이어서는 안 된다. 엉뚱한 사람에게 닿으면 메시지만 낭비되는 게 아니다. 그 계정을 통째로 태워버릴 수 있다. 이제 당신의 이름이 잘못 겨냥된 콜드 피치에 붙어버렸기 때문이다. 특정 인물이 왜 올바른 연락처인지 설명할 수 없다면, 당신은 아직 연락할 준비가 안 된 것이다. ## 2단계: 답장을 받을 만큼 리서치하라 접촉 리서치는 "이메일 주소를 찾는 것"이 아니다. 그것은 당신의 메시지가 오직 그 한 사람에게만 쓰였을 수 있을 만큼의 맥락을 모으는 일이다. 그것이 일주일에 쉰 통의 피치를 받는 받은편지함에서 답장을 이끌어내는 것이다. 무언가를 초안 잡기 전에, 다음을 알아야 한다. 1. **트리거** — 왜 지금인가? 투자 라운드, 관련 직무의 신규 채용, 제품 출시, 공개된 불만, 공백을 드러내는 채용 공고. *그들에게* 이 타이밍이 말이 되는 이유. 2. **구체적인 고통** — "당신 같은 회사들은 X에 어려움을 겪는다"가 아니라, *이* 회사가 그렇다는 증거. 3. **연결 조직** — 공통의 인맥, 그들의 영역에 있는 고객, 템플릿으로는 흉내 낼 수 없는, 당신이 알아챈 무언가. 공개된 출처만으로도 특별한 도구 없이 이 대부분을 얻을 수 있다. 회사 자체 웹사이트와 채용 페이지, LinkedIn, 최근 언론 보도, 팟캐스트 출연, 상장사의 경우 실적 발표, 그리고 당신의 구매자가 실제로 모이는 커뮤니티. 시장을 제대로 검증했다면, 당신은 이미 이 작업의 일부를 해둔 셈이다 — 영업 정보로도 두 배의 역할을 하는 수요·경쟁사 리서치는 [사업 아이디어를 만들기 전에 검증하는 법](/how-to-validate-a-business-idea/)을 참고하라. 충분히 했는지 판단하는 기준은 이렇다. 메시지의 첫 두 문장을, 다른 어떤 회사에 보내면 *전혀 말이 안 될* 방식으로 쓸 수 있는가? 그렇다면 준비된 것이다. 당신의 첫 문장이 백 개의 회사에도 통할 법하다면, 계속 리서치하라. ## 3단계: 채널을 순서대로 배치하라 — 이메일, 전화, LinkedIn 단 하나의 최고 채널은 없다. 각 순간마다 최고의 채널이 있을 뿐이다. 실수는 하나를 골라 그것만 두드리는 것이다. 기술은 각 채널이 실제로 잘하는 일을 하도록 순서대로 배치하는 것이다. | 채널 | 최적 용도 | 잘못 쓸 때의 리스크 | | --- | --- | --- | | 이메일 | 핵심 요청, 상세한 후속, 구매자가 사내에 전달해야 하는 모든 것 | 템플릿처럼 읽히면 즉시 무시됨 | | 전화 | 시급한 후속, 예약됐지만 표류 중인 거래의 일정 잡기, 걸라고 지시받은 따뜻한 추천 | 사전 맥락이나 이유 없이는 침입처럼 느껴짐 | | LinkedIn | 부드러운 첫 접촉, 콜드 컨택트를 데우기, 이메일 사이에 존재감 유지 | 붐비고, 느리고, 다른 모든 피치처럼 보이기 쉬움 | | 따뜻한 소개 | 얻을 수 있다면, 무엇이든 | 소개자의 신뢰가 걸려 있다 — 낭비하지 마라 | 실전에서 통하는 순서는 이렇다. 당신이 찾은 트리거에 엮인 짧고 구체적인 이메일로 시작하라. 답장이 없으면 LinkedIn에서 가치를 더하라 — 진심 어린 댓글, 유용한 자료, 맥락을 담은 연결 요청 — 그래서 당신의 이름이 차가운 놀라움이 되지 않도록. 진짜 이유가 있을 때만 전화 통화로 격상하라. 마감, 추천, 관심을 보인 뒤 조용해진 거래. 당신 이름을 한 번도 들어본 적 없는 사람에게 뜬금없이 거는 전화는 스팸으로 분류되는 가장 빠른 길이다. 그리고 얻어낼 수 있을 때는 언제나 따뜻한 소개를 우선하라. 구매자가 신뢰하는 사람의 소개 한 번은, 완벽하게 다듬은 콜드 이메일 스무 통을 능가한다. 콜드로 나서기 전에, 당신의 네트워크에서 누가 어느 문을 열 수 있는지 지도를 그리는 데 진짜 노력을 쏟아라. ## 4단계: 답장을 받는 메시지를 써라 연락할 자격을 얻었다면, 메시지를 짧게 유지하고 예스라고 말하기 쉽게 만들어라. 낯선 사람의 긴 피치는 읽히지 않는다. 보관함으로 넘어갈 뿐이다. 좋은 콜드 이메일은 90단어 안에서 네 가지를 한다. 1. **트리거를 짚는다** — 당신이 주의를 기울이고 있으며 이것이 무차별 발송이 아님을 증명한다. 2. **관련된 고통을 진술한다** — 한 문장으로, 당신의 것이 아니라 그들의 것으로 틀 지어서. 3. **작은 요청 하나를 한다** — "파트너십을 함께 모색해보자"가 아니라 15분 통화. 4. **쉬운 탈출구를 준다** — "이게 담당이 아니시라면, 담당자를 알려주실 수 있을까요?" 형태는 이렇다. > "Priya님 안녕하세요 — RevOps 팀에 방금 두 자리를 여신 걸 봤는데, 보통 이건 리포팅이 인력 충원으로 해결되는 속도보다 더 빨리 고통스러워지고 있다는 뜻이더라고요. 저희는 시리즈 B 팀들이 스택을 뜯어내지 않고도 수작업 리포팅 시간을 약 60% 줄이도록 돕고 있습니다. 관련이 있을지 다음 주에 15분 정도 볼 만할까요? 그리고 담당 영역이 아니시라면, 담당자를 알려주시면 정말 감사하겠습니다." 이것은 구체적이고, 그들의 시간을 존중하며, 답하기가 지극히 쉽다 — "노"조차도 유용하다. 그것이 당신을 올바른 사람에게 안내하기 때문이다. 같은 원칙이 채널 전반에 적용된다. 플래그되거나 무시당하지 않고 대규모로 아웃리치하는 더 깊은 작동 원리를 원한다면, 나는 그것을 [성공적인 아웃리치 전략 만들기](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/)에서 분해해두었다. ## 5단계: 이 미팅이 당신이 얻을 유일한 미팅인 것처럼 준비하라 접근은 기회를 열어준다. 준비는 다음 단계를 벌어들인다. 창업자들은 흔히 몇 주 동안 싸워서 미팅을 얻고는, 구매자의 세계를 충분히 생각하지 않은 채로 들어간다 — 그리고 거래는 관심의 부족이 아니라 준비의 부족으로 죽는다. 어떤 통화든 하기 전에, 즉석에서 답할 수 있어야 한다. - 이 사람의 하루는 어떻게 생겼고, 내 제품은 그 안 어디에 들어맞는가? - 그들이 신경 쓰는, 내가 움직일 수 있는 단 하나의 결과는 무엇인가? - 그들이 제기할 두 가지 반론은 무엇이고, 내 정직한 답은 무엇인가? - 그들이 관심은 있지만 아직 준비가 안 됐다면, 내가 요청할 수 있는 가장 작은 다음 단계는 무엇인가? 당신이 제품을 만들었으니 데모는 쉽다. 어려운 부분은 당신의 우선순위가 아니라 구매자의 우선순위를 머릿속에 붙들고 있는 것이다. 아웃리치를 매출로 전환하는 창업자들은, 마치 이미 그 비즈니스를 이해하고 있는 것처럼 들리게 나타나는 사람들이다 — 그들은 2단계에서 그 작업을 해뒀기 때문이다. ## 연락하지 말아야 할 때 공격적인 아웃리치는 만들어내는 것보다 더 많은 파이프라인을 태운다. 다음의 경우엔 콜드 접촉을 건너뛰거나 — 속도를 늦춰라. - 이 특정 인물이 왜 올바른 연락처인지 말할 수 없을 때. - 답이 없는데 이미 두 번 넘게 후속했을 때. (넘어가라. 시장은 크다.) - 당신의 첫 문장이 다른 백 개의 회사에 보내도 통할 법할 때. - 정상적인 업무 시간 밖에, 혹은 사전 맥락 없이 전화를 걸게 될 때. - 이 사람을 고른 유일한 이유가 그들의 연락처를 찾기 쉬웠다는 것일 때. 좋은 아웃리치는, 숙제를 해온 사람이 시의적절하고 관련성 있게 보낸 쪽지처럼 느껴진다. 나쁜 아웃리치는, 타겟팅만 더 나은 스팸처럼 느껴진다. 그 차이는 전적으로 리서치와 절제에 있다. ## 창업자 주도 영업 스택 내가 이 일에 기대는 도구와 습관들, 그 어느 것도 영업팀을 필요로 하지 않는다. - **리서치:** 회사 자체 웹사이트와 채용 페이지, LinkedIn, 최근 언론 보도, 그리고 당신의 구매자들이 실제로 이야기하는 커뮤니티 - **CRM:** 당신이 실제로 업데이트할 무엇이든 — 무시하게 될 엔터프라이즈 CRM보다 간단한 Notion 보드나 Airtable이 낫다 - **순서 관리:** 누가 어느 단계에 있고 다음 접촉이 무엇인지 추적하는 가벼운 트래커 — 그래야 아무것도 표류하지 않는다 - **이메일:** 진짜로, 예열된 발송 주소와 평문 메시지 — 이미지 없이, 추적 픽셀 없이, "캠페인"이라고 소리치는 것 하나 없이 - **캘린더:** "예스"가 다섯 통의 답장 이메일이 아니라 한 번의 클릭으로 미팅이 되도록 하는 예약 링크 ## 운영자의 결론 팔기 시작하는 데 영업팀은 필요 없다. 필요한 건 정확히 누가 예스라고 말할 수 있는지 아는 것, 당신의 메시지가 오직 그 사람에게만 쓰였을 수 있을 만큼 리서치하는 것, 그리고 각 채널이 제 일을 하도록 순서대로 배치하는 것이다. 이메일이 요청을 나르고, LinkedIn이 지반을 데우고, 전화가 시급한 틈을 메우며, 따뜻한 소개가 그 모두를 이긴다. 무엇이 실제로 통하는지 배울 만큼 충분히 오래 직접 반복하라 — 그런 다음에야, 오직 그런 다음에야, 힘들게 얻어낸 그 플레이북을 당신의 첫 채용자에게 넘겨라. --- **관련 글:** [성공적인 아웃리치 전략 만들기](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) · [사업 아이디어를 검증하는 법](/how-to-validate-a-business-idea/) · [그로스 마케팅 전략 가이드](/growth-marketing-strategies-guide/) --- ## 소로프레너 비즈니스 구축 방법: 2026년 완벽 가이드 Source: https://alejandrorioja.com/ko/how-to-build-a-solopreneur-business/ Published: 2026-07-07 Tags: Entrepreneurship, Growth TL;DR: 비즈니스 모델을 하나 선택하고(콘텐츠, 서비스, SaaS, 또는 디지털 제품), 특정 니치를 중심으로 오디언스를 구축한 다음, 주요 모델이 전환되면 2차 수익원을 추가하세요. 함정은 네 가지를 동시에 시작하는 것입니다 — 가장 수동적으로 들리는 것이 아니라 이미 알고 있는 것에 맞는 모델을 선택하세요. ## 목차 _2026년 7월 업데이트._ **TL;DR:** 비즈니스 모델을 하나 선택하고(콘텐츠, 서비스, SaaS, 또는 디지털 제품), 특정 니치를 중심으로 오디언스를 구축한 다음, 주요 모델이 전환되면 2차 수익원을 추가하세요. 함정은 네 가지를 동시에 시작하는 것입니다 — 가장 수동적으로 들리는 것이 아니라 이미 알고 있는 것에 맞는 모델을 선택하세요. **[운영자의 관점]** 저는 이 사이트를 운영하고, 강좌를 판매하고, 정규직 직원 없이 수년간 제휴 수익을 관리해 왔습니다. 이 중 어느 것도 큰 계획으로 시작하지 않았습니다 — 효과가 있는 한 가지로 시작해서 거기서부터 의도적으로 확장했습니다. 이 가이드는 모든 것을 한꺼번에 하려고 시도하기 전에 읽었으면 좋겠다고 생각하는 것입니다. ## 소로프레너 비즈니스란 실제로 무엇인가 소로프레너는 혼자 비즈니스를 운영합니다 — 공동 창업자도 직원도 없고, 거래량이 필요할 때만 계약자를 쓸 수도 있습니다. 목표는 인원수가 아니라 전문성과 시스템으로 운영되는 비즈니스입니다. 이것은 프리랜싱과 다릅니다. 프리랜서는 시간을 팝니다. 소로프레너는 벌어들인 돈 한 푼 한 푼에 자신의 시간이 필요 없이 수익을 창출하는 시스템을 구축합니다. ## 소로프레너의 4가지 비즈니스 모델 모든 1인 기업은 대략 이 중 하나에 해당합니다: 1. **콘텐츠 비즈니스.** 블로그, 뉴스레터, YouTube, 팟캐스트 등을 발행하고 광고, 제휴 수익, 스폰서십, 자체 제품을 통해 수익화합니다. 가장 낮은 진입 장벽, 가장 긴 성장 시간. 2. **서비스 비즈니스.** 고객에게 특정 결과를 제공합니다 — 컨설팅, 분획적 역할, done-for-you 서비스. 월 1,000만 원으로 가는 가장 빠른 길, 가장 확장하기 어려운 모델. 3. **디지털 제품.** 강좌, 템플릿, 전자책, 도구. 일단 만들면 높은 레버리지지만, 기존 오디언스 없이는 트래픽을 유도하기 어렵습니다. 4. **마이크로 SaaS.** 하나의 특정 문제를 해결하는 소규모 소프트웨어 제품. 가장 높은 상한선, 가장 높은 기술적 진입 장벽. 올바른 모델은 이미 가지고 있는 것—스킬, 오디언스, 또는 자본—에 따라 달라집니다. ## 1단계: 진정한 깊이가 있는 니치를 선택하세요 넓은 니치(마케팅, 금융, 건강)는 트래픽이 있지만 치열한 경쟁이 있습니다. 좁은 니치(이커머스 창업자를 위한 AI 도구, 신규 간호사를 위한 개인 재무)는 더 잘 전환되고 빠르게 순위를 올립니다. 제가 사용하는 테스트: 아이디어가 고갈되지 않고 이 주제에 대해 50편의 진정으로 유용한 콘텐츠를 쓸 수 있습니까? 그렇다면 니치에 깊이가 있습니다. 20개를 열거하는 것도 어렵다면, 너무 좁거나 충분히 알지 못하는 것입니다. 당신의 니치는 다음의 교차점에 위치해야 합니다: - 조사가 아닌 경험에서 알고 있는 것 - 돈이나 시간을 쓸 여유가 있는 오디언스 - 한 번의 해결책이 아닌 반복적인 문제 ## 2단계: 필요하기 전에 오디언스를 구축하세요 제가 흔히 보는 가장 큰 실수: 오디언스가 전혀 없는 상태에서 제품을 출시하는 것. 오디언스 먼저, 제품 나중이 원칙입니다. 실제로 효과가 있는 것: 1. **하나의 배포 채널을 선택하고 깊이 파고드세요.** 블로그 + SEO는 느리지만 지속적입니다. 뉴스레터는 빠르게 수익화됩니다. 숏폼 비디오는 상한선이 높지만 알고리즘에 의존합니다. 1년째에는 네 개의 플랫폼으로 주의를 나누지 마세요. 2. **팔 것이 없어도 꾸준히 발행하세요.** 팔 것이 없을 때 구축한 오디언스는 마침내 팔 때 당신을 신뢰합니다. 3. **첫날부터 이메일 리스트를 구축하세요.** 소셜 미디어 팔로워는 임대한 땅입니다. 이메일 리스트는 당신의 것입니다. 저는 [ConvertKit](/recommends/convertkit)을 사용합니다 — 방해 없이 시퀀스와 브로드캐스트를 처리합니다. 유용한 기준: 1,000명의 진정한 팬(모든 이메일을 여는 이메일 구독자)은 디지털 제품으로 연간 1억 원 이상을 창출하기에 충분합니다. ## 3단계: 먼저 주요 수익원을 최적화하세요 오디언스(또는 서비스의 클라이언트)가 생기면, 2차 수익원을 추가하기 전에 주요 수익원에 두 배로 집중하세요. **콘텐츠 비즈니스의 경우:** 제휴 수익이 가장 빠른 첫 번째 수익입니다. 사용하는 도구에 대해 쓰고, 추천 페이지를 통해 연결하고, 비율을 삽니다. 만들 제품도, 고객 지원도 없습니다. 상한선은 현실적입니다 — 수익성 있는 니치의 고트래픽 사이트는 월 500만~3,000만 원을 벌 수 있습니다 — 하지만 제가 찾은 최고의 부트스트랩 메커니즘입니다. **서비스 비즈니스의 경우:** 편안하게 느껴지는 것보다 더 많이 청구하세요. 저가 책정은 소로프레너의 가장 흔한 실수입니다. 클로징 비율이 100%라면 너무 저렴한 것입니다. **디지털 제품의 경우:** 범위를 좁게 유지하세요. 집중된 97달러 강좌가 전환율과 완료율에서 범위가 넓은 497달러 강좌를 능가합니다. **마이크로 SaaS의 경우:** 직접 겪고 있는 고통을 위해 구축하세요. 자신이 타겟 고객일 때 공감 우위는 실재합니다. ## 4단계: 2차 수익원을 쌓으세요 주요 모델이 전환되기 시작하면, 비례하는 시간이 필요 없는 수익원을 추가하세요: - **제휴 수익** — 서비스 비즈니스와 SaaS 운영자도 콘텐츠에서 제휴 수익을 얻을 수 있습니다 - **디지털 제품** — 주로 서비스 비즈니스라도 강좌나 템플릿 세트가 잠자는 동안 수익을 올릴 수 있습니다 - **스폰서십** — 오디언스가 ~5,000명의 참여도 높은 구독자를 넘어설 때 - **라이선싱** — 시스템이나 도구를 구축했다면 인접한 니치의 다른 사람에게 라이선스를 부여하세요 스택은 전략이 아닌 결과입니다. 먼저 하나의 흐름이 작동하게 만드세요. ## 소로프레너 테크 스택 저는 이 전체 운영을 여섯 가지 도구로 운영합니다: | 도구 | 기능 | |---|---| | [Claude](/recommends/claude) | 콘텐츠, 이메일, 코드의 초안 작성 | | [ConvertKit](/recommends/convertkit) | 이메일 리스트, 자동화, 브로드캐스트 | | [Notion](/recommends/notion) | 편집 캘린더, 클라이언트 문서, SOP | | [Canva](/recommends/canva) | 소셜 그래픽 및 썸네일 디자인 | | [Airtable](/recommends/airtable) | 제휴 추적, CRM, 콘텐츠 데이터베이스 | | [SEMrush](/recommends/semrush) | 키워드 리서치 및 순위 추적 | 월 총 비용: 300달러 미만. 이 스택을 대체하는 팀은 급여만으로 월 1,500만 원 이상이 들 것입니다. ## 소로프레너 비즈니스를 죽이는 3가지 실수 1. **섣부른 확장.** 비즈니스 모델이 증명되기 전에 채용하면 반복 가능한 수익이 생기기 전에 리소스를 소진하고 관리 오버헤드가 추가됩니다. 2. **너무 이른 다각화.** 반쪽짜리 수익원 네 개는 완전히 최적화된 하나보다 적은 수익을 냅니다. 1년째에는 더 넓게가 아니라 더 깊이 파세요. 3. **배포 없이 구축하기.** 오디언스 없는 최고의 제품은 크고 참여도 높은 리스트를 가진 평범한 제품을 이기지 못합니다. 배포가 해자입니다. ## 운영자의 결론 소로프레너 비즈니스는 팀의 복잡성을 소유권과 마진으로 교환하는 의도적인 선택입니다. 제가 일관되게 효과적임을 본 비즈니스는 모두 같은 패턴을 공유합니다: 하나의 모델, 하나의 니치, 하나의 배포 채널, 복리로 성장하기에 충분히 오랫동안 유지. 기존 스킬에 맞는 모델을 선택하세요. 필요하기 전에 오디언스를 구축하세요. 주요 수익원이 전환된 후에만 수익원을 추가하세요. 나머지는 실행입니다. --- **관련 글:** [비즈니스 아이디어를 검증하는 방법](/how-to-validate-a-business-idea/) · [뉴스레터로 수익을 창출하는 방법](/how-to-monetize-a-newsletter/) · [퍼스널 브랜드 구축 방법](/how-to-build-a-personal-brand/) --- ## AI 에이전트로 소규모 비즈니스를 자동화하는 방법: 실무 가이드 Source: https://alejandrorioja.com/ko/how-to-automate-your-small-business-with-ai-agents/ Published: 2026-07-04 Tags: AI Agents, Entrepreneurship, Operations TL;DR: AI 에이전트로 소규모 비즈니스를 자동화하는 것은 사람을 대체하는 것이 아니라, 반복적인 규칙 기반 업무를 위임하여 당신만이 내릴 수 있는 결정에 시간을 쓸 수 있게 하는 것입니다. 하나의 작업부터 시작하고, 모든 것을 기록하고, 돈이나 고객에 직접 관련된 것은 인간이 루프에 있도록 유지하고, 거기서 확장하세요. 제가 두 비즈니스에서 사용하는 스택은 월 총 100달러 미만입니다. ## 목차 _2026년 7월 업데이트._ **TL;DR:** AI 에이전트로 소규모 비즈니스를 자동화하는 것은 사람을 대체하는 것이 아니라, 반복적인 규칙 기반 업무를 위임하여 당신만이 내릴 수 있는 결정에 시간을 쓸 수 있게 하는 것입니다. 하나의 작업부터 시작하고, 모든 것을 기록하고, 돈이나 고객에 직접 관련된 것은 인간이 루프에 있도록 유지하고, 거기서 확장하세요. 제가 두 비즈니스에서 사용하는 스택은 월 총 100달러 미만입니다. **운영자 노트:** 저는 두 개의 비즈니스를 운영합니다 — 텍사스주 플루거빌에 있는 9코트 실내 피클볼 시설(Pickleland)과 컨설팅 브랜드. 합쳐서 소셜 미디어 댓글 답변부터 이벤트 홍보, 뉴스레터 초안, 예약 후속 조치까지 처리하는 30개 이상의 AI 에이전트가 프로덕션에서 실행 중입니다. 이것은 실제로 무엇이 작동하는지, 무엇이 시간을 낭비하는지, 그리고 개발자를 고용하지 않고 어떻게 시작하는지에 대한 솔직한 가이드입니다. 솔직한 설명: 소규모 비즈니스를 위한 AI 에이전트는 마법이 아닙니다. 고객 관계, 제품 품질, 전략적 판단력의 어려운 작업을 대체하지 않습니다. 그들이 하는 것은 모든 운영자가 하루에 2~3시간을 소비하는 행정적인 잡무 — 받은 편지함 분류, 복사-붙여넣기 보고서, 소셜 답변, 데이터 포맷팅 — 를 제거하는 것입니다. 그것만으로도 차이를 만들기에 충분합니다. ## 자동화가 잘 되는 4가지 작업 유형 무엇이든 구축하기 전에, 작업 부하를 네 가지 범주로 분류하세요. 그 중 하나만 AI 에이전트에 적합합니다. ### 1. 규칙 기반, 반복적, 텍스트 입력 / 텍스트 출력 이것이 최적의 포인트입니다. 고객 이메일 분류, 소셜 미디어 댓글에 대한 답변 초안 작성, 일주일치 예약을 글머리 기호 목록으로 요약, CSV를 보고서로 재포맷. 입력은 텍스트, 출력은 텍스트, 규칙은 일관됩니다. 이러한 작업은 단일 프롬프트와 API의 얇은 래퍼로 자동화됩니다. **Pickleland의 예시:** - 코트 문의 이메일 분류 (질문 / 불만 / 예약 / 기타) - 다가오는 이벤트에 대한 Facebook 그룹 게시물 초안 작성 - 예약 시스템에서 주간 점유율 요약 생성 ### 2. 명확한 인계를 갖춘 다단계 파이프라인 세 단계를 가진 작업 — 데이터 가져오기, 변환하기, 알림 보내기 — 각 단계에 명확한 입력과 출력이 있는 것. 이것은 가벼운 오케스트레이션 레이어와 잘 작동합니다 (저는 Cloudflare Workers Queues를 사용합니다). 핵심은 각 단계가 독립적으로 실패할 수 있고 전체 작업을 다시 하지 않고 재시도할 수 있다는 것입니다. **Pickleland의 예시:** - 새 예약 → CRM 업데이트 → 확인 이메일 → Slack 알림 - 양식 제출 → 분류 → 지정 답변 초안 → 인간 검토 대기열 ### 3. 모니터링 및 경고 조건을 모니터링하고 발생 시 알려주는 에이전트. 이것은 대시보드를 수동으로 확인하는 인지적 부담을 대체하기 때문에 ROI가 가장 높은 AI 자동화 중 일부입니다. 또한 가장 단순한 것들 중 일부이기도 합니다: 로직은 단순히 "X가 임계값을 초과했는가? 예라면, 경고하라."입니다. **제 컨설팅 브랜드의 예시:** - Google Analytics 이상 경고 (트래픽 감소, 급증) - 예약 취소율이 주간 기준을 초과 - 새 리뷰 게시됨 — 인간 답변을 위해 플래그 지정 ### 4. 콘텐츠 첫 초안 (최종 제품 아님) AI 에이전트는 유용한 품질로 소셜 게시물, 이메일 뉴스레터, 블로그 개요, 제품 설명을 초안 작성할 수 있습니다. 단점: 편집 판단력을 대체할 수 없습니다. 모든 초안은 인간 검토 단계를 거칩니다. ROI는 빈 화면 대신 70%의 완성도에서 시작할 수 있다는 데서 옵니다. **자동화가 잘 안 되는 것:** 고객 관계 관리, 가격 결정, 영업 대화, 채용, 그리고 잘못된 출력이 실제 사람에게 실제 비용이 드는 모든 것. 이러한 작업에는 인간을 유지하세요. ## 실제로 사용하는 스택 이를 위해 기업용 소프트웨어가 필요하지 않습니다. 제 자동화를 구동하는 것들입니다: 1. **[Claude](/recommends/claude)** — 모든 AI 작업을 위한 모델 레이어. GUI가 아닌 API를 직접 사용합니다. 달러당 품질은 테스트한 것 중 최고이며, [프롬프트 캐싱](/prompt-caching-cut-your-claude-costs-without-switching-models/)은 시스템 프롬프트가 반복될 때 비용을 더 줄입니다. 2. **Cloudflare Workers** — 에이전트가 사는 곳. 서버리스, 전 세계 분산, 그리고 무료 티어가 대부분의 소규모 비즈니스 워크로드를 커버합니다. `scheduled` 핸들러는 cron 작업을 실행하고, `fetch` 핸들러는 이벤트 트리거 흐름을 위한 webhook을 받습니다. 3. **Airtable** — 데이터 백본. 모든 에이전트가 Airtable 테이블에서 읽고 씁니다. 작업 상태, 검토 대기열, 운영 데이터가 여기에 있습니다. 비개발자도 코드를 건드리지 않고 데이터를 편집할 수 있습니다. 4. **Kit (구 ConvertKit)** — 이메일 및 뉴스레터 자동화. 뉴스레터 초안 에이전트가 Kit 초안에 작성하면, 제가 검토하고 보냅니다. 두 비즈니스에서 30개 이상의 에이전트에 대한 월별 총 비용: 100달러 미만. 가장 큰 항목은 Claude API 사용료입니다. 나머지는 무료 티어이거나 거의 무료입니다. ## 실제 예시: Pickleland 자동화 ### 이벤트 프로모터 매주 일요일, 예약된 에이전트가 예약 시스템을 확인하여 다음 4일간의 이벤트를 확인합니다. 각 이벤트를 관련 로컬 Facebook 그룹과 매칭하고 각 그룹에 적합한 홍보 게시물을 초안 작성합니다. 초안은 Airtable 검토 테이블에 들어갑니다. 저는 5분간 검토하고 "승인"을 클릭합니다 — 에이전트가 40분의 초안 작업을 합니다. 제 승인 없이는 자동으로 게시되는 것이 없습니다. 이것은 [예약된 에이전트 패턴](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/)입니다 — 일정에 따라 실행하고, 배치 작업을 수행하고, 인간 검토를 위한 초안을 제시합니다. ### 소셜 댓글 분류기 모니터링 중인 Facebook 게시물에 새 댓글이 오면 webhook이 발동되고 에이전트가 의도를 분류합니다: 질문, 불만, 칭찬, 또는 스팸. 신뢰도 임계값 이상의 질문과 불만에 대해서는 답변을 초안 작성하고 검토를 위해 플래그를 지정합니다. 칭찬은 기록됩니다. 스팸은 억제됩니다. 댓글에서 초안까지 30초 사이클. 에이전트 없이는 각 댓글이 수동 컨텍스트 전환이었습니다; 이제 미리 초안 작성된 답변 대기열은 30분이 아닌 5분이면 됩니다. 이것은 [이벤트 트리거 에이전트 패턴](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/)입니다 — webhook으로 활성화되고, 빠르게 응답해야 합니다. ### 주간 운영 브리핑 매주 월요일 아침, 에이전트가 지난 주 예약 데이터, 취소율, 코트 유형별 점유율, 플래그된 이상 항목을 가져옵니다. 5점 요약을 포맷하고 Notion 페이지에 저장합니다. 커피를 마시며 읽으면 20분이 아닌 2분에 필요한 운영 맥락을 파악할 수 있습니다. ## 어디서 시작할까: 4단계 ### 1단계: 매주 하는 가장 마찰이 많은 반복 작업 선택 가장 화려한 것이나 가장 전략적인 것이 아니라 — 가장 불편한 것. 세 곳에서 복사-붙여넣기하는 주간 보고서. 한 시간을 소비하는 소셜 답변. 하나씩 보내는 후속 이메일. 그것이 첫 번째 에이전트입니다. ### 2단계: 작업을 입력과 출력으로 매핑 다음을 작성하세요: - 작업을 트리거하는 것 (시계, 이벤트, 양식 제출) - 필요한 입력 (데이터 소스, 텍스트, 컨텍스트) - 출력은 무엇인가 (초안, 알림, 데이터베이스 행) - 인간 검토 단계는 무엇인가 (모든 첫 번째 에이전트는 이것이 있어야 함) 명확하게 매핑할 수 없다면, 작업이 자동화하기에 충분히 잘 정의되지 않은 것입니다. 먼저 수동으로 프로세스를 명확히 하세요. ### 3단계: 가능한 가장 작은 버전 구축 시스템이 아닙니다. 하나의 프롬프트, 하나의 API 호출, 하나의 출력. 입력을 받아 Claude를 호출하고 초안을 반환하는 TypeScript 함수. 데이터베이스 없이, webhook 없이, 대기열 없이 — 핵심 로직만. 수동으로 다섯 번 실행하세요. 출력 품질이 유지됩니까? 그렇다면 작동하는 에이전트가 있는 것입니다. 그런 다음 인프라를 추가하세요. ```typescript // 가장 단순한 첫 번째 에이전트: 이벤트 프로모 초안 async function draftEventPromo(event: PadklelandEvent, env: Env): Promise { const msg = await env.ANTHROPIC.messages.create({ model: "claude-opus-4-8", max_tokens: 400, system: `You write Facebook event promo posts for Pickleland, an indoor pickleball facility in Pflugerville, TX. Tone: friendly, local, community-focused. Max 150 words.`, messages: [ { role: "user", content: `Write a promo post for this event: ${JSON.stringify(event)}`, }, ], }); return (msg.content[0] as { text: string }).text; } ``` ### 4단계: 더 많은 기능을 추가하기 전에 관찰 가능성 추가 모든 실행을 trace ID로 기록하세요. 입력, 출력, 타임스탬프를 기록하세요. 정교한 도구가 필요하지 않습니다 — stdout으로의 구조화된 JSON으로 시작하면 충분합니다. 이유: 첫 번째 에이전트는 예상치 못한 방식으로 실패할 것입니다. 그럴 때 메모리에서 상태를 재구성하지 않고 무슨 일이 있었는지 볼 수 있어야 합니다. 이것이 에이전트 스택을 확장하는 운영자와 나쁜 경험 후 포기하는 운영자를 구분하는 습관입니다. [프로덕션에서 AI 에이전트를 디버그하는 방법](/how-to-debug-an-ai-agent-in-production/)에서 이에 대해 자세히 다룹니다. ## 흔한 실수 (와 피하는 방법) **프로세스를 이해하기 전에 자동화하기.** 스스로 작업을 일관되게 수행할 수 없다면, AI 에이전트는 규모에서 일관되지 않게 수행할 것입니다. 먼저 프로세스를 수동으로 문서화한 다음 자동화하세요. **인간 검토 단계를 너무 일찍 제거하기.** 모든 에이전트를 인간 루프 검토로 시작하세요. 2주간 실행하고, 모든 출력을 확인하고, 완전히 자동화되기 전에 신뢰를 쌓으세요. 예외는 저위험이고 쉽게 되돌릴 수 있는 작업 (폴더에 초안 작성 등)입니다. **핵심을 검증하기 전에 전체 시스템 구축하기.** 먼저 가장 단순한 버전을 구축하세요. 하나의 프롬프트로 핵심 품질이 없다면, 더 많은 인프라도 고치지 못합니다. **비용 무시하기.** AI API 비용은 사용량에 따라 증가합니다. 대량으로 배포하기 전에 실행당 비용을 알아두세요. 주당 수천 번의 실행을 할 때 [Haiku vs Sonnet 비용 계산](/ai-agent-cost-math-when-haiku-beats-sonnet/)이 중요합니다. **실패를 재앙으로 취급하기.** 에이전트는 실패합니다. 프롬프트는 퇴보합니다. API는 다운됩니다. 재시도 로직을 구축하고, [평가 하네스](/the-eval-harness-i-use-to-ship-ai-agents/)를 구축하고, 실패를 데이터로, 재앙으로 취급하지 마세요. ## 모든 것을 바꾸는 마인드셋 전환 소규모 비즈니스의 병목은 거의 항상 돈이 아닙니다 — 소유자의 시간과 주의력입니다. 에이전트가 처리할 수 있는 작업에 소비하는 모든 시간은 고객, 제품, 전략에 쓰지 않은 시간입니다. 제가 사용하는 프레임: 작업을 명확한 입력과 출력을 가진 반복 가능한 프로세스로 작성할 수 있다면, 에이전트 후보입니다. 판단, 관계, 창의성이 필요한 모든 것은 저에게 남습니다. 에이전트가 전자를 처리하므로 저는 후자에 집중할 수 있습니다. AI 에이전트를 시작하는 데 기술적 공동창업자, 6자리 소프트웨어 예산, 또는 몇 달의 구축 시간이 필요하지 않습니다. 마찰이 높은 작업 하나를 선택하고, 작동하는 최소 버전을 구축하고, 출력에서 배우는 것이 필요합니다. 대부분의 운영자는 주말에 첫 번째 작동하는 에이전트를 찾습니다. 거기서 두 번째는 오후 하나면 됩니다. ## FAQ ### 소규모 비즈니스를 위한 AI 에이전트 실행 비용은 얼마인가요? 제 스택은 월 100달러 미만으로 30개 이상의 에이전트를 실행합니다. 가장 큰 비용은 AI API 사용 (Claude)입니다. Cloudflare Workers는 하루 100,000건의 요청까지 무료이며 그 이후 월 5달러입니다. Airtable은 대부분의 소규모 비즈니스 데이터 요구를 커버하는 무료 티어가 있습니다. 비용은 사용량에 따라 증가합니다 — 주 몇 번 실행되는 단일 에이전트는 무시할 수 있는 수준입니다. ### AI 에이전트를 구축하려면 개발자가 필요한가요? 기본 패턴 — 예약된 cron, webhook 핸들러, 단순한 프롬프트 — 은 약간의 JavaScript와 문서를 읽으려는 의지면 충분합니다. 더 복잡한 파이프라인, 오케스트레이션, 프로덕션 수준의 관찰 가능성에는 개발자가 작업을 빠르게 합니다. 제 과정 ([AI 에이전트 초보자 가이드](/ai-agents-for-beginners-cowork-codex-guide/))은 운영자를 위한 노코드 및 로우코드 경로를 가르칩니다. ### 소규모 비즈니스에 첫 번째 AI 에이전트로 무엇이 가장 좋은가요? 주간 운영 브리핑. 일정에 따라 실행되고, 명확한 입력 (데이터 소스)이 있고, 일관된 출력 (포맷된 요약)을 생성하고, 하방 리스크가 없습니다 — 초안이 잘못되면 그냥 읽지 않으면 됩니다. 고객이나 운영에 리스크 없이 에이전트가 할 수 있는 것과 없는 것에 대한 직관을 쌓습니다. ### 비즈니스 자동화에 어떤 AI 모델을 사용해야 하나요? 거의 모든 에이전트 작업에 Claude를 사용합니다. API 품질, 신뢰성, 운영자 친화적인 가격 책정 (특히 [프롬프트 캐싱](/prompt-caching-cut-your-claude-costs-without-switching-models/)과 함께)이 프로덕션 사용에 적합한 선택입니다. 저렴하고 고용량 분류 작업에는 Claude Haiku 4.5가 빠르고 경제적입니다. 초안 작성과 미묘한 작업에는 Claude Sonnet 또는 Opus. ### AI 에이전트가 비즈니스에 해가 되는 실수를 하지 않도록 어떻게 방지할 수 있나요? 세 가지 실천: 고객이나 돈에 직접 영향을 미치는 모든 것에 인간을 루프에 유지하고; 무엇이 잘못되었는지 추적할 수 있도록 모든 실행을 기록하고; 프롬프트 변경이 조용히 프로덕션을 망가뜨리지 않도록 [평가 하네스](/the-eval-harness-i-use-to-ship-ai-agents/)를 구축하세요. 저위험 내부 작업으로 시작하고 출력 품질을 신뢰한 후에만 확장하세요. --- ## 온라인에서 퍼스널 브랜드 구축하는 방법: 2026 실전 플레이북 Source: https://alejandrorioja.com/ko/how-to-build-a-personal-brand/ Published: 2026-07-02 Tags: Entrepreneurship, Growth TL;DR: 퍼스널 브랜드는 특정 타겟 오디언스를 선택하고, 하나의 채널에서 유용한 콘텐츠를 꾸준히 발행하고, 명확한 관점을 갖는 것으로 구축된다 — LinkedIn 프로필을 최적화하는 게 아니다. 니치를 좁히고, 실제 경험에서 글을 쓰고, 이메일 리스트를 유일한 소유 채널로 구축하고, 적합한 사람들이 당신을 무시할 수 없을 때까지 반복하라. ## 목차 _2026년 7월 업데이트._ **TL;DR:** 퍼스널 브랜드는 특정 타겟 오디언스를 선택하고, 하나의 채널에서 유용한 콘텐츠를 꾸준히 발행하고, 명확한 관점을 갖는 것으로 구축된다 — LinkedIn 프로필을 최적화하는 게 아니다. 니치를 좁히고, 실제 경험에서 글을 쓰고, 이메일 리스트를 유일한 소유 채널로 구축하고, 적합한 사람들이 당신을 무시할 수 없을 때까지 반복하라. **[실전자 노트]** 나는 여러 비즈니스 — Pickleland, AI 에이전트 컨설팅, 이 사이트 — 를 통해 공개적으로 구축해왔다. 반복적으로 보이는 패턴은 항상 동일하다: 인지도 있는 퍼스널 브랜드를 구축하는 사람들은 가장 재능이 많은 사람들이 아니다. 그들은 가장 구체적이고 가장 꾸준하다. 내가 사용하고 추천하는 프레임워크를 소개한다. ## 퍼스널 브랜드가 실제로 무엇인가 (그리고 무엇이 아닌가) 퍼스널 브랜드는 하나의 질문에 대한 답이다: *당신이 없는 자리에서 사람들은 당신에 대해 뭐라고 하는가?* 로고가 아니다. 색상 팔레트가 아니다. 팔로워 수가 아니다. 퍼스널 브랜드는 사람들이 당신의 이름을 들었을 때 형성하는 정신적 지름길 — 그들이 당신이 해결할 수 있다고 생각하는 특정 문제, 그들이 당신에게 기대하는 관점이다. 대부분의 사람이 범하는 실수: 관점을 발전시키기 전에 브랜드를 구축하려 한다. 브랜드는 실제 일을 하고 거기서 배운 것에 대해 구체적이 됨으로써 쌓이는 것 — 미리 만들어내는 게 아니다. 처음부터 통제할 수 있는 것: 1. 누구에게 말하는가 2. 그들을 위해 어떤 문제를 해결하는가 3. 그들이 어디서 당신을 찾는가 4. 얼마나 꾸준히 나타나는가 시간이 지나면서 쌓이는 것: - 특정 유형의 전문성에 대한 평판 - 당신의 판단을 신뢰하는 오디언스 - 쫓아다니지 않아도 오는 인바운드 기회 ## 1단계: 살아갈 수 있는 가장 좁은 니치를 선택하라 퍼스널 브랜딩에서 가장 흔한 실패 패턴은 너무 넓게 잡는 것이다. "마케팅 전문가." "비즈니스 컨설턴트." "테크 창업가." 이런 라벨은 모두가 가지고 있는 세상에서 의미 없는 레이블이다. 좁을수록 더 빨리 평판이 쌓인다. 이 필터로 니치를 테스트하라: - **검색될 만큼 구체적인가.** 누군가 Google에서 당신의 니치를 검색해 실제 커뮤니티를 찾을 수 있는가? - **추천될 만큼 구체적인가.** 누군가 당신과 똑같은 문제를 가진 사람을 만났을 때, 그들이 당신을 먼저 생각하는가? - **2년 이상 콘텐츠를 생산할 만큼 넓은가.** [Semrush](/recommends/semrush) 같은 키워드 도구로 당신의 니치가 검색되는지 확인하라. ## 2단계: 하나의 주요 채널을 선택하라 동시에 모든 곳에 있으려는 것은 모든 곳에서 평범해지는 보장된 방법이다. 처음에는 하나의 채널을 선택해 깊이 파고들어라. - **글로 쓴 콘텐츠 (블로그/뉴스레터):** 분석적·실전적 오디언스에게 최적. SEO를 통해 시간이 지날수록 복리 성장. - **LinkedIn:** B2B 및 전문직 오디언스에게 최적. - **YouTube/비디오:** 시각적 시연이 효과적인 주제에 최적. - **X/Twitter:** 퍼지는 아이디어에 최적. ## 3단계: 당신의 관점을 찾아라 관점 없는 콘텐츠는 소음이다. 인용되고, 추천되고, 찾아지는 퍼스널 브랜드를 구별하는 것은 뚜렷한 관점 — 실제 경험에서 비롯된, 세상이 어떻게 돌아가는지에 대한 의견이다. 강한 관점은 다음 속성을 가진다: - 단순히 읽은 것이 아니라 실제로 한 것에 기반한다 - 오디언스의 최소 하나의 통념적 가정에 도전한다 - 일부 사람들이 동의하지 않을 만큼 구체적이다 ## 4단계: 소유한 오디언스를 구축하라 당신이 구축하는 모든 플랫폼은 알고리즘을 바꾸거나, 계정을 정지하거나, 문을 닫을 수 있다. 당신이 진정으로 소유하는 유일한 배포 채널은 이메일 리스트다. 첫날부터 구축을 시작하라. 이메일에는 [ConvertKit](/recommends/convertkit)을 사용한다 — 크리에이터 뉴스레터를 위해 설계된 도구다. 퍼스널 브랜드에서 이메일 리스트를 가장 빠르게 키우는 방법: 1. **진정으로 유용한 리드 마그넷을 만들어라.** 오디언스가 직면한 특정 문제를 해결하는 체크리스트, 템플릿 또는 짧은 가이드. 2. **모든 콘텐츠 페이지의 폴드 위에 옵트인을 추가하라.** 3. **3통의 웰컴 이메일 시퀀스를 써라.** 4. **모든 콘텐츠에서 리스트를 언급하라.** ## 5단계: 꾸준히 발행하라 — 복리의 수학 매주 하나의 긴 형식 콘텐츠를 발행하면: - **1~8주:** 거의 아무도 읽지 않는다. 정상이다. - **3~4개월:** 일부 콘텐츠가 오가닉 트래픽을 받기 시작한다. - **6~9개월:** 검색 트래픽이 복리로 성장한다. 인바운드 문의가 나타나기 시작한다. - **2년차:** 100개의 콘텐츠. 이름이 검색 결과와 AI 답변에 나타난다. 나의 규칙: 효과가 있는지 평가하기 전에 6개월을 헌신하라. ## 비주얼 브랜드에 대한 생각 최소한의 비주얼 브랜드: - 얼굴이 명확히 보이는 프로페셔널한 프로필 사진 - 모든 플랫폼에서 통일된 프로필 사진 - 명확한 태그라인과 이메일 옵트인이 있는 간단한 웹사이트 [Canva](/recommends/canva)는 소셜 그래픽과 간단한 디자인에 충분하다. ## 흔한 실수 1. **모든 사람을 대상으로 하려는 것.** "창업가"를 위해 쓴다면 아무도 위해 쓰지 않는 것이다. 2. **배포 없이 발행하는 것.** 포스트를 쓰고 트래픽을 기다리는 건 전략이 아니다. 3. **매 분기 포커스를 바꾸는 것.** 퍼스널 브랜드 모멘텀의 가장 큰 파괴자. 4. **허영 지표를 측정하는 것.** 좋아요 수가 아니라 리스트 크기와 전환율을 측정하라. 5. **"충분히 전문가가 될 때"를 기다리는 것.** 해당 주제의 세계적 권위자일 필요는 없다. ## 퍼스널 브랜드 스택 - **이메일 플랫폼:** [ConvertKit](/recommends/convertkit) - **SEO 리서치:** [Semrush](/recommends/semrush) - **콘텐츠 제작:** [Claude](/recommends/claude) - **디자인:** [Canva](/recommends/canva) ## FAQ ### 퍼스널 브랜드를 구축하는 데 얼마나 걸리나? 현실적으로, 의미 있는 인바운드 기회를 갖기 전까지 12~24개월의 꾸준한 발행이 필요하다. ### 모든 소셜 플랫폼에 있어야 하나? 아니다. 하나의 플랫폼에서의 깊이가 다섯 개에서의 얕은 존재감보다 낫다. ### 콘텐츠 품질과 발행 빈도 중 무엇이 더 중요한가? 둘 다이지만 동등하지는 않다. 품질이 하한선을 정한다. 빈도가 개선에 필요한 반복을 얻을 수 있는지 결정한다. ### 실명을 써야 할까, 브랜드명을 써야 할까? 실명을 사용하라. 실제 사람에게 연결된 퍼스널 브랜드가 알고리즘 변화에서 더 잘 살아남는다. ### 퍼스널 브랜드를 어떻게 수익화하나? 네 가지 신뢰할 수 있는 경로: (1) 강좌/디지털 제품, (2) 컨설팅 및 어드바이저리, (3) 제휴 파트너십, (4) 스폰서드 콘텐츠. --- **관련 글:** [만들기 전에 비즈니스 아이디어를 검증하는 방법](/how-to-validate-a-business-idea/) · [제로에서 이메일 리스트 구축하는 방법](/how-to-build-an-email-list/) · [뉴스레터 수익화하는 방법](/how-to-monetize-a-newsletter/) --- ## AI 에이전트에 메모리 추가하는 방법: 프로덕션용 상태 지속성 패턴 Source: https://alejandrorioja.com/ko/how-to-add-memory-to-an-ai-agent/ Published: 2026-06-30 Tags: AI Agents TL;DR: 상태 비저장 에이전트——Worker가 종료될 때 모든 것을 잊는 유형——는 일회성 작업에 적합합니다. 에이전트가 어제 무슨 일이 있었는지 기억하거나, 재방문 고객을 인식하거나, 이전 출력을 기반으로 작업해야 하는 순간, 메모리가 필요합니다. 세 가지 패턴이 있습니다: 워킹 메모리(실행 중 컨텍스트, 실행 기간 동안 KV에 저장), 에피소딕 메모리(무엇이 언제 일어났는지, 쿼리 가능한 로그), 시맨틱 메모리(당신이 아는 것, 벡터 검색이나 구조화된 데이터로 검색). 올바른 패턴을 올바른 작업에 연결하세요. ## 목차 _2026년 6월 업데이트._ **TL;DR:** 상태 비저장 에이전트——Worker가 종료될 때 모든 것을 잊는 유형——는 일회성 작업에 적합합니다. 에이전트가 어제 무슨 일이 있었는지 기억하거나, 재방문 고객을 인식하거나, 이전 출력을 기반으로 작업해야 하는 순간, 메모리가 필요합니다. 세 가지 패턴이 있습니다: 워킹 메모리(실행 중 컨텍스트, 실행 기간 동안 KV에 저장), 에피소딕 메모리(무엇이 언제 일어났는지, 쿼리 가능한 로그), 시맨틱 메모리(당신이 아는 것, 벡터 검색이나 구조화된 데이터로 검색). 올바른 패턴을 올바른 작업에 연결하세요. **[운영자의 관점]** 상태 비저장의 벽에 한두 번 이상 부딪혔습니다. 소셜 답장 에이전트가 20번씩 대화한 고객에게 계속 자기소개를 했습니다. 데일리 브리프 에이전트는 어제 플래그했다는 기억이 없어 같은 문제를 나흘 연속으로 플래그했습니다. 올바른 종류의 메모리를 추가하자 두 가지 모두 해결되었습니다. 이것이 제가 사용하는 방법입니다. ## 상태 비저장 에이전트가 계속 실패하는 이유 상태 비저장 에이전트는 명시적으로 전달한 내용으로만 각 실행을 시작합니다: 시스템 프롬프트, 사용자 메시지, 호출 시 새로 가져온 데이터. 이전 실행, 이전 사용자, 이전 결정에 대한 인식이 없습니다. 일회성 분류 작업——댓글을 읽어 카테고리를 반환하는——에는 상태 비저장이 맞습니다. 빠르고, 저렴하고, 예측 가능합니다. 연속성이 필요한 순간 장애 표면이 나타납니다: - 고객의 이력을 인식하지 못하는 고객 대면 에이전트 - 지난주에 이미 추천한 기사를 추천하는 콘텐츠 에이전트 - 해결된 케이스를 계속 재에스컬레이션하는 모더레이션 에이전트 - 무한정 같은 오래된 알림을 표시하는 데일리 브리프 이 모든 것은 같은 문제의 증상입니다: 에이전트가 실행 간에 컨텍스트를 전달할 방법이 없습니다. ## 세 가지 메모리 유형 프로덕션에서 유용하게 사용하는 프레임워크: 1. **워킹 메모리** — 에이전트가 단일 실행 중 _지금_ 알고 있는 것. 호출 생애 동안 KV나 메모리에 보관됩니다. 2. **에피소딕 메모리** — 무엇이 언제 일어났는지. 각 실행 시작 시 에이전트가 읽어 방향을 잡는 구조화된 로그. 3. **시맨틱 메모리** — 세계, 고객, 또는 지식 베이스에 대해 알고 있는 것. 관련될 때 구조화된 쿼리나 벡터 검색으로 검색됩니다. 항상 세 가지 모두 필요한 것은 아닙니다. 제가 실행하는 대부분의 에이전트는 워킹 + 에피소딕이 필요합니다. 시맨틱 메모리는 구축하기 가장 어려우며 지식 베이스가 컨텍스트 윈도우에 들어가기에 너무 클 때만 자리를 차지합니다. ## 워킹 메모리: 실행 중 컨텍스트 워킹 메모리는 에이전트 실행 기간 동안 존재하는 상태입니다. 가장 단순한 형태는 함수 스코프의 변수입니다. 더 흥미로운 형태는 같은 실행 내의 서브태스크들이 읽고 쓰는 공유 KV 키입니다. 소셜 답장 에이전트는 하나의 큐 메시지에서 댓글 배치를 처리하는 동안 컨텍스트를 축적하기 위해 워킹 메모리를 사용합니다. 시작 시 각 고객의 최근 대화 이력을 KV에서 읽고, 처리하면서 새 컨텍스트를 추가하고, 끝에 다시 씁니다. ```typescript // workers/social-reply.ts async function processComment( comment: SocialCommentEvent, env: Env ): Promise { // 이 고객의 최근 이력을 KV에서 로드 (워킹 메모리) const historyKey = `customer:${comment.userId}:history`; const rawHistory = await env.AGENT_KV.get(historyKey); const history: ConversationTurn[] = rawHistory ? JSON.parse(rawHistory) : []; // 이력에서 컨텍스트 인식 시스템 프롬프트 구성 const systemPrompt = buildSystemPrompt(history); const response = await anthropic.messages.create({ model: "claude-opus-4-8", max_tokens: 512, system: systemPrompt, messages: [{ role: "user", content: comment.text }], }); const reply = response.content[0].type === "text" ? response.content[0].text : ""; // 이력 업데이트 — 마지막 10턴 유지, TTL 30일 const updatedHistory: ConversationTurn[] = [ ...history.slice(-9), { role: "assistant", content: reply, timestamp: comment.timestamp }, ]; await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), { expirationTtl: 60 * 60 * 24 * 30, }); await postReply(comment, reply, env); } ``` 두 가지를 주목하세요. 이력은 10턴으로 제한됩니다——슬라이딩 윈도우를 삽입하고, 무한정 늘리지 마세요. TTL은 30일: 고객이 한 달 동안 침묵하면 이력이 만료되고 에이전트가 새로 시작합니다. 둘 다 의도적입니다. ## 에피소딕 메모리: 무엇이 언제 일어났는지 에피소딕 메모리는 에이전트의 로그입니다. 각 새로운 실행 시작 시 에이전트가 읽어 반복을 피하기 위한 과거 실행의 구조화된 기록입니다. 데일리 브리프 에이전트는 각 실행이 이미 플래그된 것에 대한 인식이 없어 매일 같은 오래된 알림을 표시했습니다. 해결책: 에이전트가 브리프를 생성하기 전에 읽는 과거 알림의 구조화된 로그입니다. ```typescript // workers/daily-brief.ts interface AlertLogEntry { id: string; surfacedAt: string; // ISO 타임스탬프 resolvedAt?: string; summary: string; } async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); // 에피소딕 메모리 로드: 이미 플래그된 것 const rawLog = await env.AGENT_KV.get("brief:alert-log"); const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : []; // 최근 미해결 알림만 필터링 const sevenDaysAgo = new Date( Date.now() - 7 * 24 * 60 * 60 * 1000 ).toISOString(); const recentAlerts = alertLog.filter( (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt ); const brief = await synthesizeBrief( { emails, calendar, tasks, recentAlerts }, env ); // 이 실행에서 플래그된 새 알림으로 로그 업데이트 const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({ id: crypto.randomUUID(), surfacedAt: new Date().toISOString(), summary: a, })); const updatedLog = [...alertLog, ...newAlerts].slice(-100); // 마지막 100개 유지 await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog)); await writeToWorkspace(brief.content, env); } ``` 에이전트는 이제 자신이 무엇을 말했는지 알고 있습니다. 중복 알림은 기저 문제가 바뀔 때까지 브리프에서 제외됩니다. 알림을 해결됨으로 표시하면 활성 목록에서 사라집니다. 이 패턴은 일반화됩니다: 결정, 플래그, 추천을 생성하는 모든 에이전트는 로그의 혜택을 받습니다. 로그는 저렴하고(KV에 수 KB), 보상은 높습니다(더 이상 중복 출력 없음). ## 시맨틱 메모리: 당신이 아는 것 시맨틱 메모리는 지식 베이스입니다. 모든 것을 시스템 프롬프트에 미리 채워 넣는 대신, 쿼리 시점에 "X에 대해 무엇을 알고 있나요?"에 답합니다. 가장 단순한 형태는 KV나 데이터베이스의 구조화된 조회입니다. Pickleland 예약 에이전트는 확인서를 작성하기 전에 고객 프로필과 코트 선호도를 조회합니다: ```typescript // workers/booking-agent.ts interface CustomerProfile { userId: string; preferredCourts: string[]; experienceLevel: "beginner" | "intermediate" | "advanced"; specialNotes: string; } async function draftConfirmation( booking: BookingEvent, env: Env ): Promise { // KV에서 고객 프로필 가져오기 (시맨틱 메모리——사실적 지식) const profileKey = `customer:${booking.userId}:profile`; const rawProfile = await env.AGENT_KV.get(profileKey); const profile: CustomerProfile | null = rawProfile ? JSON.parse(rawProfile) : null; const systemPrompt = profile ? `개인화된 예약 확인서를 작성합니다. 이 고객은 ${profile.preferredCourts.join(", ")}을 선호하며, ${profile.experienceLevel} 레벨의 선수입니다. ${profile.specialNotes}` : "피클볼 시설의 예약 확인서를 작성합니다."; const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 256, system: systemPrompt, messages: [ { role: "user", content: `다음에 대한 확인서를 작성하세요: ${JSON.stringify(booking)}`, }, ], }); return response.content[0].type === "text" ? response.content[0].text : ""; } ``` 더 큰 지식 베이스——제품 문서, 지원 지식 베이스, 컨텍스트 윈도우에 들어가기에 너무 큰 것——에는 벡터 스토어가 필요합니다. 워크플로는: 쿼리를 임베딩하고, 가장 관련성 높은 k개의 청크를 검색하고, 컨텍스트에 주입합니다. Cloudflare Vectorize는 이미 Workers를 사용 중이라면 이를 네이티브로 처리합니다. 더 큰 인덱스에는 Upstash Vector를 사용했습니다. 선택은 규모에 달려 있으며, 원칙이 아닙니다. 시맨틱 메모리에 대한 솔직한 메모: 세 가지 중 구축하고 유지하기 가장 어렵습니다. 인덱스는 최신 상태를 유지해야 합니다. 검색 품질이 다양합니다. 구조화된 조회——KV, D1의 테이블——에서 시작하고, 구조화된 접근 방식이 필요한 지식 표면을 커버할 수 없을 때만 벡터 검색으로 넘어가세요. ## 메모리 의사결정 프레임워크 에이전트에 메모리를 추가하기 전에, 세 가지 질문에 답하세요: 1. **에이전트가 실행 간에 기억해야 하나요?** 각 호출이 진정으로 독립적이라면——번역, 분류, 일회성 생성——메모리를 건너뛰세요. 상태 비저장이 더 간단하고 저렴합니다. 2. **에이전트가 자신의 이력에 눈을 감고 반복하고 있나요?** 그렇다면, 먼저 에피소딕 메모리를 추가하세요. 가장 적은 노력으로 수정할 수 있으며, "에이전트가 X를 계속 한다"는 불만의 대부분을 해결합니다. 3. **에이전트가 그러면 안 될 때 모든 사용자나 엔티티를 동일하게 대하고 있나요?** 그렇다면, 워킹 메모리(고객 이력, 사용자 프로필)나 시맨틱 메모리(검색 또는 검색 시스템)를 추가하세요. 제가 가장 많이 보는 실수: 누군가가 에피소딕 메모리가 없어서——이미 한 일의 로그가 없어서——실패하던 에이전트에 거대한 지식 베이스(시맨틱 메모리)를 추가합니다. 복잡성이 문제와 일치하지 않습니다. ## 프로덕션에서 실제로 사용하는 것 30개 이상의 에이전트 중: - **모두** 최소한 워킹 메모리를 가지고 있습니다——그것이 단지 컨텍스트 윈도우 자체일지라도, 실행 내 어떤 형태의 상태. - **약 절반**이 에피소딕 메모리를 가지고 있습니다——과거 실행, 결정, 플래그의 로그. 이것은 거의 항상 추가할 가치가 있습니다. - **서너 개**가 벡터 스토어로 뒷받침되는 진정한 시맨틱 메모리를 가지고 있습니다. 이것들은 크고 동적인 지식 베이스에 대해 질문에 답하는 에이전트입니다. Cloudflare KV는 워킹 메모리와 에피소딕 메모리를 위한 기본 스토어입니다. 빠르고, 저렴하고, Workers에 네이티브로 통합되어 있습니다——추가 클라이언트 없이, 별도의 자격 증명 없이. 제한 사항: KV는 결국 일관성이 있으며 고빈도 쓰기에는 적합하지 않습니다. 초당 여러 번 상태를 쓰는 에이전트에는 대신 Durable Objects나 D1 데이터베이스를 사용합니다. 벡터로 뒷받침되는 시맨틱 메모리에는 소~중형 인덱스(~10만 벡터 미만)에 Cloudflare Vectorize를, 더 큰 것에는 Upstash Vector를 사용합니다. 둘 다 일류 JavaScript 클라이언트를 가지고 있습니다. ## 운영자의 결론 상태 비저장 동작이 실제 문제를 야기할 때만 에이전트에 메모리를 추가하세요——반복 출력, 고객 이력의 맹점, 과거 결정에 대한 무지. 그런 다음 올바른 레이어를 선택하세요: 실행 중 컨텍스트에는 워킹 메모리, 역사적으로 일어난 것에는 에피소딕 메모리, 아는 것에는 시맨틱 메모리. 확신이 없다면 에피소딕부터 시작하세요——가장 적은 복잡성으로 가장 흔한 장애 모드를 수정합니다. 구조화된 조회를 소진할 때까지 벡터 데이터베이스를 사용하지 마세요. 최고의 메모리 시스템은 에이전트가 올바르게 동작하게 만드는 가장 단순한 것입니다. --- **관련:** [30개 이상의 프로덕션 에이전트를 실행하는 에이전트 스택](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [이벤트 트리거 에이전트 vs 스케줄 에이전트](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [AI 에이전트가 실제로 작동하는지 측정하는 방법](/how-i-measure-whether-an-ai-agent-is-actually-working/) **귀하의 사용 사례를 위한 에이전트 메모리 설계에 도움이 필요하신가요?** [연락하기](/contact/) — 운영자 팀을 위한 프로덕션 에이전트 시스템을 설계합니다. --- ## 이메일 리스트를 제로에서 구축하는 방법: 2026 플레이북 Source: https://alejandrorioja.com/ko/how-to-build-an-email-list/ Published: 2026-06-27 Tags: Entrepreneurship, Growth TL;DR: 이메일 리스트는 당신이 진정으로 소유할 수 있는 유일한 배포 채널입니다. 특정 문제를 해결하는 리드 마그넷으로 시작하고, 옵트인을 상단에 배치하며, 누군가 구독하는 즉시 3통의 환영 이메일을 발송하세요. 질은 항상 양을 이깁니다 — 1,000명의 활성 구독자가 10,000명의 냉담한 구독자보다 낫습니다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** 이메일 리스트는 당신이 진정으로 소유할 수 있는 유일한 배포 채널입니다. 특정 문제를 해결하는 리드 마그넷으로 시작하고, 옵트인을 상단에 배치하며, 누군가 구독하는 즉시 3통의 환영 이메일을 발송하세요. 질은 항상 양을 이깁니다 — 1,000명의 활성 구독자가 10,000명의 냉담한 구독자보다 낫습니다. **[운영자 관점]** 내가 관여했던 지속 가능한 수익 엔진을 구축한 모든 비즈니스에는 한 가지 공통점이 있었습니다: 리스트. 팔로워가 아닙니다. 노출이 아닙니다. 당신의 이야기를 듣기 원한다고 요청한 사람들의 리스트입니다. 여기 제로에서 구축하는 방법이 있습니다. ## 진정으로 소유할 수 있는 유일한 자산 다른 모든 배포 채널은 사라질 수 있습니다. Google 알고리즘 업데이트가 검색 순위를 지웁니다. 플랫폼 정책 변경이 Facebook 도달 범위를 없앱니다. 광고 계정이 경고 없이 정지됩니다. 이메일 리스트는 예외입니다. 이메일 리스트를 소유하면 전송을 제어할 수 있습니다. 어떤 알고리즘도 누가 콘텐츠를 볼지 결정하지 않습니다. 오디언스에 도달하려 할 때마다 수수료를 부과하는 플랫폼도 없습니다. 이것이 내가 모든 창업자에게 가장 먼저 이메일 리스트 구축을 말하는 이유입니다 — SEO 전에, 유료 광고 전에, 소셜 미디어 전에. ## 1단계: 이메일 플랫폼 선택 주소를 하나라도 수집하기 전에 저장하고 발송할 플랫폼이 필요합니다. Gmail을 사용하지 마세요. 비즈니스 이메일을 사용하지 마세요. 적절한 컴플라이언스와 전달성 인프라를 갖춘 전용 도구를 사용하세요. 2026년 나의 두 가지 선택: **[ConvertKit](/recommends/convertkit)** — 크리에이터와 솔로 운영자에게 최적. 구독자 태깅 및 세분화 시스템이 진정으로 탁월합니다. 구독자 1,000명까지 무료. **[Moosend](/recommends/moosend)** — ConvertKit 가격 없이 자동화를 원하는 소기업에 최적. 견고한 드래그 앤 드롭 빌더와 일관되게 좋은 전달성. 제로에서 시작한다면 두 플랫폼 모두 처음 수백 명의 구독자를 커버하는 무료 티어가 있습니다. 무엇이든 발송하기 전에 도메인에 DKIM, SPF, DMARC 인증을 설정하세요 — 2024년부터 대량 발송자에게 Gmail과 Yahoo가 요구하고 있으며, 첫날부터 발신자 평판을 보호합니다. ## 2단계: 다운로드할 가치 있는 리드 마그넷 만들기 리드 마그넷은 누군가의 이메일 주소와 교환으로 제공하는 것입니다. 대부분의 사람들이 저지르는 실수: 일반적인 것을 제공하는 것. "뉴스레터 구독하기"는 리드 마그넷이 아닙니다. 아무것도 돌려주지 않는 신뢰 요청입니다. 리드 마그넷은 특정 사람의 특정 문제를 해결해야 합니다. 더 구체적일수록 더 잘 전환됩니다. **2026년에 효과적인 형식:** 1. **치트 시트와 템플릿** — 누군가 즉시 사용할 수 있는 1페이지 리소스. 플러그 앤 플레이일수록 좋습니다. 2. **미니 코스 (3~5개 이메일)** — 한 가지 기술을 가르치는 짧은 시퀀스로 자동 전달됩니다. 리스트와 관계를 동시에 구축합니다. 3. **계산기 또는 스프레드시트** — 높은 인식 가치. 시장 규모 측정 도구, 가격 모델, 예산 템플릿. 실제 작업을 절약하기 때문에 전환됩니다. 4. **독점 데이터 또는 리서치** — 독창적인 설문 결과나 벤치마크 보고서. 복제하기 어렵고 높은 신뢰도. 5. **스와이프 파일** — 실제 예시 모음 (광고 카피, 제목 줄, 랜딩 페이지 헤드라인). 실무자들이 이것에 돈을 지불합니다. 6. **웨비나 또는 트레이닝 다시보기** — 기존 녹화물을 옵트인으로 재활용합니다. 설정에 20분 걸립니다. 절대 타협할 수 없는 조건: 리드 마그넷은 이메일로 이야기할 내용과 직접 관련되어야 합니다. B2B SaaS 뉴스레터를 위해 구독자를 모으는 Facebook 광고 템플릿은 리스트 품질 재앙이 기다리고 있습니다. ## 3단계: 효과적인 위치에 옵트인 폼 배치 폼 배치가 카피보다 전환을 더 많이 이끕니다. 이미 주의가 집중된 곳에 옵트인 폼을 배치하세요: 1. **홈페이지 스크롤 위** — 푸터가 아닙니다. 사이드바가 아닙니다. 그들이 받을 것에 대한 명확한 설명과 함께 스크롤 위. 2. **모든 블로그 게시물 끝** — 게시물 전체를 읽은 사람은 사전 자격을 갖추었습니다. 아직 참여하고 있을 때 잡으세요. 3. **이탈 의도 팝업** — 방문자가 탭을 닫으려 할 때 트리거됩니다. 논란이 있지만 효과가 있습니다. 4. **전용 랜딩 페이지** — 내비게이션이 없는 독립 페이지. 여기에 유료 트래픽을 보냅니다. 5. **콘텐츠 업그레이드** — 특정 게시물을 향상시키는 리소스. TAM/SAM/SOM 가이드 내의 시장 규모 스프레드시트는 같은 페이지의 일반 제안보다 3~5배 높게 전환됩니다. 카피 팁: 형식이 아닌 결과로 시작하세요. "5페이지 가이드 받기"는 "VC처럼 시장 규모를 파악하기"보다 약합니다. ## 4단계: 환영 시퀀스 작성 누군가 구독하는 순간, 그들의 최대 주의를 갖게 됩니다. 침묵으로 낭비하지 마세요. 최소 3통의 이메일을 보내세요: **이메일 1 (즉시):** 리드 마그넷을 전달하세요. 그들이 무엇을 위해 등록했는지 확인하세요. 앞으로 올 것에 대한 기대를 설정하세요. **이메일 2 (2일차):** 최고의 콘텐츠 — 게시물, 케이스 스터디, 프레임워크. 피치 없음. 구독이 가치 있었다는 증명만. **이메일 3 (4~5일차):** 창업 스토리와 관점. 왜 이 주제에 관심을 갖는가? 당신 분야의 대부분의 사람들이 믿지 않지만 당신이 믿는 것은 무엇인가? 여기서 신뢰가 구축됩니다. 그 이후로는 일관된 케이던스를 유지하세요. 주간이 표준입니다. 주간 품질을 유지할 수 없다면 격주도 효과적입니다. 최악의 실수는 런칭 시 한 번 이메일을 보내고 3개월간 사라지는 것입니다. ## 5단계: 옵트인으로 트래픽 유도 트래픽 없는 폼은 아무도 전환하지 못합니다. 가장 신뢰할 수 있는 성장 채널: **오가닉 검색** — 리드 마그넷이 해결하는 문제로 순위를 매기는 블로그 게시물. 당신의 주제를 검색하고 게시물을 찾는 사람은 제안에 대해 사전 자격을 갖추었습니다. 이것은 비용이 가장 낮고 유지율이 가장 높은 채널입니다. **소셜 미디어 (오가닉)** — LinkedIn 게시물, Twitter/X 스레드, 또는 사람들을 옵트인 페이지로 이끄는 숏폼 비디오. 모든 게시물은 티저여야 하며 전체 이야기가 아닙니다. **뉴스레터 스왑 및 공동 프로모션** — 인접 공간의 뉴스레터를 찾아 언급을 교환하세요. 당신이 그들의 리스트를 홍보하고; 그들이 당신의 리스트를 홍보합니다. 이것은 구독자 500명에서 5,000명으로 성장하는 가장 빠른 방법 중 하나입니다. **팟캐스트 게스트 출연** — 과소평가됩니다. 2,000명의 니치 청취자에게 보내진 30분 에피소드는 당신이 보내는 모든 이메일을 열 가능성이 더 높은 50~100명의 깊은 관심 구독자를 추가할 수 있습니다. **유료 광고** — 검증되지 않은 제안에 광고를 내지 마세요. 먼저 옵트인 페이지가 오가닉하게 전환되게 하고, 그 다음 유료 트래픽으로 확장하세요. ## 6단계: 리스트 청결 유지 이메일 리스트는 저하됩니다. 사람들은 직업, 이메일, 관심사를 바꿉니다. 리스트를 정리하지 않으면 전달성이 저하됩니다 — 즉 참여한 구독자들도 이메일을 못 보게 됩니다. 모범 사례: - **6개월마다 재참여 캠페인** — 90일 이상 열지 않은 모든 사람에게 이메일을 보냅니다. 머물 이유를 주세요. 참여하지 않으면 제거하세요. - **하드 바운스 즉시 제거** — 높은 바운스율은 받은 편지함 제공자에게 리스트가 더럽다는 신호를 보냅니다. - **참여도별 세분화** — 활성 구독자와 냉담한 구독자에 별도로 태그를 붙이세요. 시간에 민감한 캠페인은 활성 세그먼트에만 보내세요. 구독자를 삭제하면 무언가를 잃는 것처럼 느껴집니다. 실제로는 유지하고 싶은 구독자를 보호합니다. ## 솔직한 주의사항 **구축에는 시간이 걸립니다.** 오가닉 방법으로만 제로에서 시작하면 구독자 1,000명에 도달하는 데 3~6개월이 걸립니다. 몇 주 안에 수천 명을 약속하는 사람은 허영 지표나 원하지 않는 냉담하고 비참여적인 연락처를 판매하고 있습니다. **니치가 중요합니다.** B2B 오디언스는 데이터와 케이스 스터디에 반응합니다. 소비자 오디언스는 할인과 엔터테인먼트에 반응합니다. 리드 마그넷과 콘텐츠 케이던스는 오디언스와 일치해야 합니다. **리드 마그넷은 노후화됩니다.** 오늘 잘 전환되는 것이 경쟁자들이 형식을 복사하면 18개월 후에 시대에 뒤떨어질 수 있습니다. 리드 마그넷을 매년 새로 고칠 계획을 세우세요. ## 현실적인 벤치마크 | 지표 | 업계 평균 | 우수 | |--------|-----------------|------| | 팝업 옵트인 비율 | 2~4% | 5~8% | | 랜딩 페이지 옵트인 비율 | 20~30% | 40~60% | | 환영 이메일 열람률 | 50~60% | 70%+ | | 지속 열람률 | 20~25% | 35~45% | | 클릭률 | 2~3% | 5~10% | 처음 90일 동안은 이 숫자들을 최적화하지 마세요. 인프라를 구축하고, 리드 마그넷을 실행하고, 일관되게 발송하세요. 그 다음 반복합니다. ## 2026년 6월 업데이트 **AI 생성 리드 마그넷** — Claude 같은 도구는 몇 분 안에 10페이지 PDF 가이드, 스와이프 파일, 또는 템플릿을 작성할 수 있습니다. 고품질 리드 마그넷 생성 장벽은 거의 제로입니다. 이제 차별화 요소는 약속의 구체성과 오디언스와의 관련성입니다. **Gmail과 Yahoo 인증** — 2024년부터 하루 1,000개 이상의 주소에 이메일을 보내는 발신자에게 DKIM, SPF, DMARC가 필요합니다. [ConvertKit](/recommends/convertkit)과 [Moosend](/recommends/moosend) 모두 온보딩 중에 설정을 안내합니다. 필요하기 전에 하세요. **AI 검색 트래픽** — 명확한 TL;DR과 검색 쿼리에 대한 직접적인 답변을 가진 잘 구조화된 옵트인 페이지는 ChatGPT, Perplexity, Google AI Overviews에 표시될 수 있습니다. SEO 작업 없이 AI 검색에서 지속적인 트래픽을 받는 옵트인 랜딩 페이지를 봤습니다 — 페이지가 특정 질문에 직접 답하기 때문입니다. ## 자주 묻는 질문 **수익화하려면 구독자가 몇 명이나 필요한가요?** 보편적인 숫자는 없습니다. 높은 의도 니치에서 500명의 깊이 참여한 구독자를 가진 뉴스레터가 20,000명의 일반 연락처 리스트를 능가하는 것을 봤습니다. 문제는 구독자들이 문제를 가지고 있는지, 그리고 당신이 그것을 해결할 수 있다고 신뢰하는지입니다. **이메일 리스트를 구매해야 하나요?** 아니요. 구매한 리스트는 참여율이 끔찍하고, 스팸으로 표시되며, 계정을 정지시킬 수 있습니다. 지름길은 없습니다. **얼마나 자주 이메일을 보내야 하나요?** 품질을 유지하면서 가능한 한 자주. 주간이 마음에 남습니다. 가장 큰 실수는 몇 달간 침묵하다 피치와 함께 돌아오는 것입니다. **더블 옵트인이나 싱글 옵트인?** 대부분의 경우 더블 옵트인. 확인이 리스트 크기를 줄이지만 참여도와 전달성을 극적으로 향상시킵니다. 예외는 특정 소스에서 높은 의도의 검증된 트래픽을 유도할 때입니다. **초보자에게 가장 좋은 이메일 플랫폼은?** 개인 브랜드나 콘텐츠 비즈니스를 구축하는 크리에이터에게 [ConvertKit](/recommends/convertkit). 저렴함과 자동화를 원하는 소기업에 [Moosend](/recommends/moosend). 둘 다 Gmail을 사용하려는 것보다 훨씬 낫습니다. ## 다음으로 가져갈 곳 이메일 리스트는 고립되어 있지 않습니다. 가장 성과가 좋은 게시물에는 콘텐츠 업그레이드가 있어야 합니다. 이메일은 심층 가이드로 다시 링크해야 합니다. 리드 마그넷은 트래픽이 가장 많은 페이지가 다루는 정확한 문제를 해결해야 합니다. 그 루프 — 트래픽 → 옵트인 → 양성 → 신뢰 → 제안 — 은 내가 관여했던 모든 지속 가능한 온라인 비즈니스의 토대입니다. 특정 상황에 맞게 이것을 어떻게 연결할지 이야기하고 싶다면, [연락처 페이지](/contact)가 시작하기에 적합한 곳입니다. --- ## 뉴스레터 수익화 방법: 실제로 효과적인 5가지 수익 모델 Source: https://alejandrorioja.com/ko/how-to-monetize-a-newsletter/ Published: 2026-06-25 Tags: Entrepreneurship, Growth TL;DR: 대부분의 뉴스레터가 수익화에 실패하는 이유는 리스트 규모에 맞지 않는 모델을 추구하기 때문입니다. 실제로 작동하는 5가지 모델: 유료 구독(니치 권위에 최적), 스폰서십(구독자 5,000명 이상에서 최적), 제휴 추천(어떤 규모에서도 마찰 최소), 강좌 및 제품 퍼널(수익 상한이 가장 높음), 서비스 업셀(실제 수익으로 가는 가장 빠른 경로). 하나로 시작하세요. 첫 번째가 작동할 때만 두 번째를 추가하세요. ## Table of contents _2026년 6월 업데이트._ **TL;DR:** 대부분의 뉴스레터가 수익화에 실패하는 이유는 리스트 규모에 맞지 않는 모델을 추구하기 때문입니다. 실제로 작동하는 5가지 모델: 유료 구독(니치 권위에 최적), 스폰서십(구독자 5,000명 이상에서 최적), 제휴 추천(어떤 규모에서도 마찰 최소), 강좌 및 제품 퍼널(수익 상한이 가장 높음), 서비스 업셀(실제 수익으로 가는 가장 빠른 경로). 하나로 시작하세요. 첫 번째가 작동할 때만 두 번째를 추가하세요. **[운영자 시각]** 저는 뉴스레터를 "뉴스레터 비즈니스"라고 부르는 것이 유행하기 전부터 운영해 왔습니다. 솔직한 여정: 모든 것을 한 번에 하려고 했고, 거의 아무것도 벌지 못했으며, 하나의 모델로 줄인 후에야 수익이 나기 시작했습니다. 제가 배운 것과 함께 일하는 운영자들에게서 꾸준히 효과를 보는 것을 공유합니다. ## 대부분의 뉴스레터가 왜 한 푼도 벌지 못하는가 수익화 문제는 대개 순서의 문제입니다. 사람들은 뉴스레터를 시작하고, 천천히 성장시킨 다음, 모든 수익 흐름을 한 번에 추가하려고 합니다 — 여기에 유료 등급, 저기에 스폰서 슬롯, 매 호마다 제휴 링크. 결과는 쇼핑몰처럼 느껴지는 뉴스레터: 모든 것이 판매 중이고, 아무것도 진실하게 느껴지지 않으며, 독자들이 떠납니다. 꾸준히 수익을 내는 뉴스레터는 먼저 한 가지를 잘합니다. 특정 오디언스에게 하나의 모델이 작동한다는 것을 증명합니다. 그런 다음 — 그리고 오직 그때만 — 두 번째를 추가합니다. 리스트 규모도 어떤 모델이 실현 가능한지를 결정합니다. 구독자 500명 리스트는 스폰서를 찾는 데 잘못된 도구입니다. 구독자 50,000명 리스트가 제휴 링크만 운영하면 상당한 돈을 놓치고 있는 것입니다. 모델은 리스트와 일치해야 합니다. ## 모델 1: 유료 구독 **최적:** 정의된 전문적이거나 고관심 오디언스를 가진 니치 권위 뉴스레터. 유료 구독은 가장 순수한 뉴스레터 수익화 형태입니다: 독자가 콘텐츠에 직접 비용을 지불합니다. Beehiiv와 Substack 같은 플랫폼이 이를 무료 리스트에 쉽게 추가할 수 있게 해줍니다. 작동하게 만드는 것: - 정보가 희소하거나 시간을 절약하는 특정 고가치 니치(금융 분석, 산업 인텔리전스, 운영자 수준의 전술) - "유료 구독자는 무료로 얻을 수 없는 무엇을 받는가?"에 대한 명확한 답변 - 진정으로 가치 있는 무료 등급 — 희석된 버전이 아니라 유료 등급 접근 방식의 맛보기 이를 망치는 것: - 긴급성이 낮은 일반 주제("마케팅 팁", "자기 개발") - 무료 구독자들이 콘텐츠를 지속적으로 읽는다는 증거 없이 유료 출시 현실적인 수익: 구독자당 월 $5–$20. 2,000명 리스트에서 5% 전환으로 100명 유료 구독자, 월 $10 = 월 $1,000 MRR. 작지만 실제이며, 복리로 늘어납니다. ## 모델 2: 스폰서십과 네이티브 광고 **최적:** 5,000명 이상의 구독자와 정의된 오디언스 인구통계를 가진 뉴스레터. 스폰서십은 가장 가시적인 모델입니다 — 오디언스에게 관련된 브랜드에 판매되는 단일 호 슬롯. 효과가 있을 때는 잘 작동합니다: 니치 B2B나 고소득 오디언스에 대해 $100–$500+ CPM(천 명당 비용)이 일반적입니다. 솔직한 제약: 스폰서는 규모와 구체성을 원합니다. "마케팅에 관심 있는 구독자 1,000명이 있습니다"는 거래를 성사시키지 못합니다. "10–500명 규모 회사의 마케팅 매니저 6,000명이 구독 중이며 오픈율 52%입니다"는 성사시킵니다. 거기에 도달하는 방법: 1. **오디언스를 정의하세요** 관심사 용어가 아닌 인구통계적 용어로 2. **5,000명 구독자에 도달하세요** 스폰서 피칭 전 최소 신뢰성 기준으로 3. **인게이지먼트를 증명하세요** — 40% 이상의 오픈율이 진정한 차별화 요소 4. **미디어 킷을 만드세요** — 구독자 수, 오픈율, 오디언스 프로필, 스폰서십 패키지가 담긴 1페이지 PDF 5. **인바운드부터 시작하세요** — 아웃바운드 영업 프로세스를 구축하기 전에 스폰서십 마켓플레이스에 등록 CPM 현실 확인: 리스트가 45% 오픈율로 전환되고 $200 CPM에 호당 스폰서 슬롯 하나를 판매한다면, 구독자 5,000명 리스트는 스폰서 호당 $1,000을 생성합니다. 월 4호에 하나의 스폰서 슬롯으로 월 $4,000. 두 슬롯으로는 월 $8,000. 수학은 규모에서 작동합니다. ## 모델 3: 제휴 추천 **최적:** 어떤 리스트 규모, 도구와 서비스를 진정으로 사용하는 어떤 니치. 제휴 마케팅은 시작하기에 가장 마찰이 적은 모델입니다: 실제로 사용하는 제품을 추천하고, 독자가 클릭하면 구매에 대한 커미션을 받습니다. 관리할 스폰서 관계 없음, 구축할 제품 없음, 유지할 유료 등급 없음. 핵심 제약은 신뢰입니다. 제휴 추천은 추천이 진정으로 유용하고 신뢰할 수 있는 출처에서 나올 때만 전환됩니다. 사용해본 적 없는 제품으로 가득 찬 "추천 목록" 섹션은 성과가 저조하거나, 더 나쁜 경우 리스트를 손상시킵니다. 작동하는 것: - 자신의 스택에서 사용하는 도구 추천(저의 경우: 이메일 관리에 [ConvertKit](/recommends/convertkit), SEO와 콘텐츠 조사에 [Semrush](/recommends/semrush)) - 맥락적 배치 — 독자들이 스킵하도록 훈련된 고정 "이번 호 스폰서" 블록이 아니라 콘텐츠에 관련된 곳에서 도구 언급 - 진짜 의견 제공: 좋아하는 것, 좋아하지 않는 것, 누구에게 맞지 않는지 수익 상한: 제휴 커미션은 다양합니다 — SaaS 도구는 일반적으로 전환된 구독자에 대해 20–40%를 지속적으로 지급하며 복리 효과가 있습니다. 독자의 2%가 30% 커미션으로 월 $50 SaaS에 전환되는 1,000명 구독자 리스트 = 남아 있는 새 가입자와 함께 성장하는 월 $300 반복 수익. ## 모델 4: 강좌와 디지털 제품 퍼널 **최적:** 특정 도메인에서 교육적 권위를 가진 운영자. 뉴스레터는 퍼널의 상단이고; 강좌나 디지털 제품이 전환 이벤트입니다. 매호를 열어볼 만큼 당신을 신뢰하는 독자들이 당신이 아는 것을 가르쳐주는 유료 제품에 가장 자격이 있는 리드입니다. 이것은 겸손한 리스트와 결합할 때도 가장 높은 수익 상한을 가진 모델입니다. 5,000명 리스트의 2%에게 판매되는 $497 강좌는 출시당 $49,700입니다. 리스트 성장과 함께 연간 3번의 출시로 공격적으로 복리가 됩니다. 필요한 것: - 특정 도메인에서의 진정한 교육적 권위 — 단순히 "마케팅을 안다"가 아니라 "이 특정 성장 플레이북으로 세 개의 B2B 기업을 성장시켰다" - 주마다 권위를 증명하는 콘텐츠(큐레이션된 링크뿐만 아니라 — 원본 프레임워크와 케이스 스터디) - 리스트가 준비되어 있는 출시 시퀀스 — 콘텐츠만 받는 리스트에 보내는 차가운 "내 강좌를 사세요" 이메일이 아님 이것이 제 자신의 작업에서 가장 많이 의존하는 모델입니다. 뉴스레터가 신뢰를 구축하고; 강좌가 그것을 전환합니다. ## 모델 5: 서비스 업셀 **최적:** 운영자가 컨설팅, 코칭, 또는 대행 서비스를 제공하는 초기 단계 뉴스레터. 이 모델은 작은 리스트 규모에서 실제 수익으로 가는 가장 빠른 경로이며, 가장 저활용되어 있습니다. 뉴스레터가 당신을 전문가로 포지셔닝하고; 서비스는 실제로 일하는 전문가입니다. 성장 마케팅에 관한 뉴스레터를 500명이 읽고 매월 생각을 보여주는 호를 발행하면, 그 500명의 독자 중 1–2명이 주기적으로 손을 들고 컨설팅을 하는지 물어볼 것입니다. 제공하지 않으면 수익을 놓친 것입니다. 명시적으로 만드는 방법: - 뉴스레터 푸터에 이 줄을 추가하세요: "저는 분기마다 소수의 클라이언트와 [특정 결과]에 대해 일합니다. 탐색해 보고 싶다면 이 이메일에 답장하세요." - 관련 호에서 클라이언트 결과(익명화)를 언급하세요 — 자랑이 아니라 프레임워크가 실제로 작동한다는 증거로 - 용량을 의도적으로 제한하세요 — 여기서 희소성은 만들어진 것이 아닌 실제입니다; 당신의 시간은 제한되어 있습니다 수익 현실: 월 $5,000 컨설팅 클라이언트 1명과 200명 뉴스레터는 분산된 제휴 수익으로 구독자당 $0.01를 버는 50,000명 구독자보다 더 나은 경제성을 가집니다. 여기서 시작하기 위해 규모를 기다리지 마세요. ## 올바른 모델을 선택하는 방법 결정 프레임워크: | 리스트 규모 | 최선의 시작 모델 | 추가할 두 번째 모델 | |-----------|---------------|-----------------| | 0–1,000 | 서비스 업셀 | 제휴 추천 | | 1,000–5,000 | 제휴 + 강좌 대기자 명단 | 유료 구독 | | 5,000–20,000 | 스폰서십 | 강좌 출시 | | 20,000+ | 스폰서십 + 강좌 | 유료 등급 | 어떤 규모에서도 변하지 않는 하나의 제약: 먼저 하나를 선택하세요. 모델 분산은 모든 모델의 전환을 동시에 죽입니다. ## 뉴스레터 운영자 스택 뉴스레터 비즈니스를 구축하기 위해 사용하고 추천하는 도구: - **이메일 플랫폼:** [ConvertKit](/recommends/convertkit) — 구매자와 독자를 구분하는 구독자 태깅, 세그멘테이션, 자동화 시퀀스 - **SEO 및 주제 조사:** [Semrush](/recommends/semrush) — 콘텐츠를 작성하기 전에 타겟 오디언스가 검색하는 것을 파악 - **디자인:** [Canva](/recommends/canva) — 디자이너 없이 미디어 킷, 강좌 표지 자산, 소셜 콘텐츠 - **결제:** Stripe — 유료 구독 등급 또는 강좌 체크아웃용 ## 운영자의 결론 뉴스레터는 2026년에 구축할 수 있는 레버리지가 가장 높은 콘텐츠 자산입니다: 이메일 받은편지함 주의는 소셜 피드가 가지지 못한 방식으로 희소하고 가치 있습니다. 하지만 자산이 수익으로 전환되는 것은 리스트 규모에 맞는 모델을 선택하고, 진정한 추천과 실제 권위로 실행하며, 한 번에 모든 수익화 방법에 분산되려는 충동에 저항할 때만입니다. 오늘의 위치에 맞는 모델로 시작하세요. 지속적으로, 복리 결과와 함께 작동할 때 — 다음 것을 추가하세요. --- **관련:** [구축하기 전에 비즈니스 아이디어를 검증하는 방법](/how-to-validate-a-business-idea/) · [성장 마케팅 전략 가이드](/growth-marketing-strategies-guide/) · [중소기업을 위한 최고의 이메일 마케팅 서비스 6가지](/6-best-email-marketing-services-for-small-business/) --- ## 첫 번째 MCP 서버 만들기: 실전 가이드 Source: https://alejandrorioja.com/ko/how-to-build-your-first-mcp-server/ Published: 2026-06-23 Tags: AI Agents TL;DR: MCP(Model Context Protocol)는 컨텍스트 윈도우를 채우지 않고도 데이터베이스, 파일, API 등 외부 툴과 데이터에 대한 구조화된 접근 권한을 Claude에 부여하는 방법입니다. 서버는 생각보다 간단합니다: SDK 설치, 툴을 JSON 스키마로 정의, 핸들러 구현, stdio로 연결. 30분 이내에 Claude가 커스텀 툴을 호출할 수 있습니다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** MCP(Model Context Protocol)는 컨텍스트 윈도우를 채우지 않고도 데이터베이스, 파일, API 등 외부 툴과 데이터에 대한 구조화된 접근 권한을 [Claude](/recommends/claude)에 부여하는 방법입니다. 서버는 생각보다 간단합니다: SDK 설치, 툴을 JSON 스키마로 정의, 핸들러 구현, stdio로 연결. 30분 이내에 Claude가 커스텀 툴을 호출할 수 있습니다. **[운영자 관점]** 저는 정기적으로 에이전트에 새 툴을 연결하는데, MCP는 이제 그것을 깔끔하게 하는 표준 방법입니다. 서버가 한 번 구축되면 MCP를 지원하는 모든 클라이언트 — Claude Desktop, Claude Code, Anthropic SDK를 사용하는 모든 앱 — 가 호출 코드 변경 없이 사용할 수 있습니다. 이게 바로 가치입니다: 한 번 만들고, 어디서나 재사용. ## MCP가 실제로 무엇인가 **Model Context Protocol**은 AI 모델이 외부 컨텍스트와 툴에 연결하는 방법을 표준화하는 오픈 프로토콜입니다. AI 통합을 위한 USB-C 표준이라고 생각하세요: 이전에는 Claude가 데이터베이스를 읽거나 API를 호출하게 하려는 모든 앱이 자체 솔루션을 발명해야 했습니다. 이후에는 MCP 서버 하나를 만들면 호환되는 모든 호스트가 사용할 수 있습니다. MCP는 서버가 제공할 수 있는 세 가지를 정의합니다: - **툴** — Claude가 호출할 수 있는 함수 (파일 읽기, DB 쿼리, Slack 메시지 보내기) - **리소스** — Claude가 읽을 수 있는 데이터 (문서, 데이터베이스 행, 파일 트리) - **프롬프트** — 호스트가 주입할 수 있는 재사용 가능한 프롬프트 템플릿 대부분의 운영자 사용 사례에서는 **툴 서버**를 구축합니다. 리소스와 프롬프트는 기본이 작동한 후에 옵니다. 아키텍처는 클라이언트-서버이며, 클라이언트 (Claude Desktop, Claude Code, 커스텀 앱)가 모든 것을 제어합니다. 서버는 수동적 — 툴 호출 요청을 기다리고 결과를 반환하기만 합니다. ## 모든 MCP 서버의 세 가지 구성 요소 구축하는 모든 MCP 서버는 동일한 구조를 갖습니다: 1. **서버 객체** — 서버의 이름, 버전, 제공하는 기능 (툴, 리소스, 프롬프트)을 선언 2. **툴 정의** — 입력을 위한 이름, 설명, JSON 스키마가 있는 툴 목록 3. **요청 핸들러** — Claude가 툴을 호출할 때 실행되는 함수 그게 전부입니다. 시작하는 데 데이터베이스, HTTP 스택, auth 레이어가 필요 없습니다. 최소 서버는 TypeScript 30줄 미만입니다. ## 사전 요구 사항 (2분) - **Node.js 18+** — `node --version`으로 확인 - **TypeScript 5+** (아래에 dev 의존성으로 포함) - 테스트용 MCP 클라이언트 — Claude Desktop은 무료이고 서버가 작동하는 것을 볼 수 있는 가장 쉬운 방법 MCP 서버 자체를 실행하는 데 Anthropic API 키가 필요하지 않습니다. API 키는 클라이언트 (Claude Desktop)에 있으며, 서버에는 없습니다. ## 1단계: 프로젝트 설정 (3분) ```bash mkdir my-mcp-server && cd my-mcp-server npm init -y npm install @modelcontextprotocol/sdk npm install -D typescript tsx @types/node ``` `package.json`에 추가: ```json { "type": "module", "scripts": { "build": "tsc", "dev": "tsx src/index.ts" } } ``` `tsconfig.json` 생성: ```json { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "./build", "strict": true }, "include": ["src/**/*"] } ``` ## 2단계: 최소 서버 작성 (5분) `src/index.ts` 생성: ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { CallToolRequestSchema, ListToolsRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; const server = new Server( { name: "my-mcp-server", version: "1.0.0" }, { capabilities: { tools: {} } } ); // 이 서버가 제공하는 툴 선언 server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: "get_word_count", description: "텍스트 블록의 단어 수를 셉니다.", inputSchema: { type: "object", properties: { text: { type: "string", description: "단어를 세는 텍스트", }, }, required: ["text"], }, }, ], })); // 클라이언트의 툴 호출 처리 server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; if (name === "get_word_count") { const { text } = args as { text: string }; const count = text.trim().split(/\s+/).filter(Boolean).length; return { content: [{ type: "text", text: `단어 수: ${count}` }], }; } throw new Error(`알 수 없는 툴: ${name}`); }); // stdio를 통해 연결 — Claude Desktop이 서버와 통신하는 방법 const transport = new StdioServerTransport(); await server.connect(transport); ``` 이것이 전체 서버입니다. 하나의 툴 (`get_word_count`)을 등록하고 구현합니다. 구조가 중요합니다. ## 3단계: 빌드하고 Claude Desktop에 등록 (5분) TypeScript 빌드: ```bash npm run build ``` Claude Desktop 설정 파일에 등록합니다. **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json` **Windows**: `%APPDATA%\Claude\claude_desktop_config.json` 파일이 없으면 생성: ```json { "mcpServers": { "my-mcp-server": { "command": "node", "args": ["/absolute/path/to/my-mcp-server/build/index.js"] } } } ``` 절대 경로를 사용합니다. 저장 후 Claude Desktop을 재시작합니다. 메시지 입력에 망치 아이콘 (🔨)이 보이면 Claude가 툴을 발견했다는 의미입니다. ## 4단계: 유용한 툴 만들기 단어 세기는 설명을 위한 것입니다. 더 유용한 툴은 프로젝트 디렉토리에서 파일 읽기 — 코드베이스, changelog, 설정 파일을 요약하는 컨텍스트 주입 에이전트에 사용합니다. ```typescript import { readFileSync, readdirSync } from "fs"; import { join, extname } from "path"; const ALLOWED_EXTENSIONS = [".md", ".txt", ".ts", ".json", ".yaml"]; const PROJECT_DIR = process.env.PROJECT_DIR ?? process.cwd(); ``` 로직은 동일합니다: 정확한 JSON 스키마로 툴 정의, 핸들러 구현, path traversal 방지 위한 입력 검증, 클라이언트에 텍스트 반환. ## 내가 겪은 문제들 (당신이 겪지 않도록) **경로는 절대 경로여야 합니다.** Claude Desktop 설정의 상대 경로는 예상대로 해석되지 않습니다. 항상 전체 경로 `/home/user/...`를 사용하세요. **stdio는 서버에서 `console.log`를 사용할 수 없다는 의미입니다.** Claude Desktop은 stdin/stdout을 통해 서버와 통신합니다. 디버그 `console.log`는 JSON-RPC 스트림을 손상시킵니다. 대신 stderr에 로그하세요: ```typescript process.stderr.write(`디버그: ${message}\n`); ``` **설정 변경 후마다 Claude Desktop을 재시작하세요.** MCP 서버는 시작 시 로드됩니다. 편집된 설정 파일은 앱을 닫고 다시 열기 전까지 아무것도 하지 않습니다. **툴 설명이 제품입니다.** Claude는 `description` 필드를 기반으로 툴을 호출할지 결정합니다. 모호한 설명은 Claude가 언제 사용해야 하는지 모른다는 의미입니다. 정확한 설명은 Claude가 적절한 순간에 사용한다는 의미입니다. 구현보다 설명에 더 많은 시간을 투자하세요. ## 프로덕션에서 MCP 서버 사용 방법 stdio 패턴은 Claude Desktop과 Claude Code (로컬)에 잘 작동합니다. 프로덕션 에이전트 — [Cloudflare Workers에서 실행하는 30개 이상](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — 에는 단계별로 [Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet)으로 라우팅하는 유연성이 필요하기 때문에 Anthropic SDK의 tool-use API를 직접 사용합니다. 실제로 사용하는 패턴: 1. **로컬 개발 툴링** — 프로젝트별 툴을 노출하는 Claude Code용 MCP 서버 2. **컨텍스트 주입** — 수동 복사 없이 관련 문서를 미리 로드하는 MCP 서버 3. **프로토타입-to-API 브리지** — MCP를 먼저 구축하고 (반복이 빠름), 프로덕션을 위해 SDK tool-use로 로직 포팅 ## 다음에 만들 것 서버 구조가 이해되면, 유용한 툴은 Claude의 외부 컨텍스트에 접근하는 것들입니다: - **데이터베이스 리더** — 읽기 전용 SQL 쿼리를 실행하고 JSON으로 결과 반환 - **Slack 리더** — 채널에서 마지막 N개 메시지 가져오기 - **GitHub 리더** — 오픈 PR 목록, 특정 커밋의 파일 읽기 - **내부 API 래퍼** — auth 헤더가 포함된 REST API 호출 ## 자주 묻는 질문 ### MCP 서버를 만들려면 Anthropic API 키가 필요한가요? 아니요. MCP 서버는 Anthropic API를 호출하지 않습니다. 클라이언트의 툴 호출 요청에 응답하기만 합니다. API 키는 클라이언트에 있으며, 서버에는 없습니다. ### MCP 서버가 외부 API를 호출할 수 있나요? 예 — 핸들러는 단순히 비동기 TypeScript 코드입니다. 날씨 API를 가져오고, 데이터베이스를 쿼리하고, 파일에 작성합니다. 서버는 핸들러가 내부적으로 무엇을 하는지 신경 쓰지 않습니다. ### stdio와 HTTP 전송의 차이는 무엇인가요? stdio는 로컬 서버용 — Claude Desktop 또는 Claude Code와 동일한 기기. HTTP with SSE는 웹 서비스로 배포할 수 있는 원격 서버용. stdio로 시작하세요; 디버그가 더 간단합니다. ### Claude는 내 툴을 언제 호출해야 하는지 어떻게 알까요? Claude는 툴의 `description` 필드와 대화 컨텍스트를 기반으로 결정합니다. Claude가 계속 툴을 무시하면, 설명을 더 정밀하게 만드세요. --- ## 비즈니스 아이디어를 구축하기 전에 검증하는 방법 Source: https://alejandrorioja.com/ko/how-to-validate-a-business-idea/ Published: 2026-06-20 Tags: Entrepreneurship, Growth TL;DR: 대부분의 비즈니스 아이디어는 나쁜 실행 때문이 아니라 검증을 건너뛰었기 때문에 실패합니다. 가장 빠른 경로: 검색 수요와 포럼 증거를 통해 문제가 존재함을 확인하고, 경쟁사를 분석해 누군가가 이미 돈을 벌고 있음을 증명하고, 가능한 가장 작은 스모크 테스트를 구축하고, 무언가를 만들기 전에 약속(보증금, 대기자 명단 등록, 의향서)을 받으세요. 단 한 명도 약속하게 할 수 없다면 아이디어는 아직 준비되지 않은 것입니다. ## Table of contents _2026년 6월 업데이트._ **TL;DR:** 대부분의 비즈니스 아이디어는 나쁜 실행 때문이 아니라 검증을 건너뛰었기 때문에 실패합니다. 가장 빠른 경로: 검색 수요와 포럼 증거를 통해 문제가 존재함을 확인하고, 경쟁사를 분석해 누군가가 이미 돈을 벌고 있음을 증명하고, 가능한 가장 작은 스모크 테스트를 구축하고, 무언가를 만들기 전에 약속(보증금, 대기자 명단 등록, 의향서)을 받으세요. 단 한 명도 약속하게 할 수 없다면 아이디어는 아직 준비되지 않은 것입니다. **[운영자의 관점]** 저는 함께 일한 창업자들과 제 자신의 프로젝트에서 이 패턴을 수십 번 보았습니다: 아이디어는 설득력이 있고, 창업자는 열정적이며, 실행은 탄탄합니다 — 그리고 그들은 침묵 속에 런칭합니다. 잘못된 것을 만들었기 때문이 아니라 6개월을 투자하기 전에 알려줬을 단 하나의 단계를 건너뛰었기 때문입니다. 여기 제가 사용하고 추천하는 검증 프레임워크가 있습니다. ## 대부분의 검증 노력이 실패하는 이유 명백한 실패 방식은 전혀 검증하지 않는 것입니다 — 먼저 만들고 나중에 질문하기. 하지만 더 미묘한 함정은 검증 연극입니다: 설문조사를 실시하고, 친구들과 이야기하고, 막연한 "좋은 아이디어!" 반응을 수집하고 그것을 신호라고 부르는 것. 설문조사는 거짓말을 합니다. 사람들은 예의 바릅니다. 가상의 맥락에서 "이것에 50달러를 내겠습니까?"라고 물으면 대답은 거의 항상 예입니다. 중요한 유일한 신호는 약속입니다: 실제로 돈, 시간, 또는 서면 의향서를 주는 사람. 그 외 모든 것은 노이즈 감소이지 검증이 아닙니다. ## 1단계: 문제가 실제로 대규모로 존재함을 확인하세요 솔루션을 검증하기 전에 문제가 실제이고 검색되고 있는지 검증하세요. **검색 수요가 가장 빠른 프록시입니다.** Google에 문제를 입력하세요. 자동완성 제안, "사람들도 묻는 것" 섹션, 최상위 랭킹 페이지를 확인하세요. 결과가 없다면 아무도 검색하지 않는 것입니다 — 아무도 찾지 않는 문제를 해결하는 비즈니스는 전환 대신 교육에 모든 에너지를 쏟게 됩니다. 실제 월간 검색량을 확인하려면 [Semrush](/recommends/semrush)와 같은 키워드 도구를 사용하세요. 타겟 시장에서 월 1,000~10,000건의 검색이 있는 문제는 실행 가능합니다. 월 20건의 문제는 유통 문제가 있는 틈새 제품입니다. **포럼 증거는 추가적인 질적 레이어입니다.** Reddit, Quora, 틈새 Facebook 그룹, Discord 커뮤니티에서 문제를 검색하세요. 사람들이 적극적으로 불평하고 있습니까? 해결책을 찾고 있습니까? 대안은요? 진짜 좌절감은 금입니다 — 고통이 사람들을 공개적으로 도움을 구하도록 동기를 부여할 만큼 충분히 강하다는 것을 의미합니다. 문제를 설명하는 실제 사람들의 포럼 스레드 20개를 찾을 수 없다면 회의적이 되세요. ## 2단계: 경쟁사 분석 — 이미 돈이 존재한다는 증거 흔한 창업자의 본능: "경쟁이 없으니 내가 시장을 지배할 것이다." 이것은 거의 항상 틀립니다. 경쟁이 없다는 것은 보통 시장이 없다는 것을 의미합니다. 경쟁은 고객이 존재하고 지불할 것이라는 증거입니다. Google에서 솔루션 카테고리를 검색하세요. 누가 랭킹하고 있습니까? 그들의 랜딩 페이지는 무엇을 약속합니까? 얼마를 청구합니까? 그들의 증언과 리뷰를 읽으세요 — 특히 부정적인 것들을. 부정적인 리뷰는 제품 로드맵입니다: 시장이 원하지만 얻지 못하는 것이 정확히 무엇인지 알려줍니다. 실제 제품과 실제 고객을 보유한 3~5개의 확립된 경쟁사를 찾으면 좋은 신호입니다. 하나도 없다면 시장이 존재하지 않는다고 결론 내리기 전에 더 깊이 파고들거나 빨간 신호로 취급하세요. **답해야 할 핵심 질문:** 1. 상위 3~5개 업체는 누구입니까? 2. 얼마를 청구합니까? 3. 리뷰어들이 무엇을 비판하고 있습니까? 4. 제가 차지할 수 있는 포지셔닝 공백이 있습니까? ## 3단계: 가능한 가장 작은 스모크 테스트를 구축하세요 문제가 존재하고 시장에 돈이 있다는 것을 알면, *귀하의* 버전이 트랙션을 얻는지 테스트하는 데 필요한 최소한의 아티팩트를 구축하세요. 이것은 완전한 제품이 아닙니다. 신호 캡처 메커니즘입니다. **옵션 A: 이메일 캡처가 있는 랜딩 페이지.** "대기자 명단에 참여" 또는 "조기 액세스 받기" CTA와 함께 문제와 솔루션을 설명하는 한 페이지 사이트. 전환율이 포지셔닝이 공감되는지 알려줍니다. Webflow, Carrd 또는 공개 Notion 페이지와 같은 도구도 잘 작동합니다 — 과도하게 복잡하게 만들지 마세요. **옵션 B: 사전 판매.** 실제 돈으로 실제 결제 흐름. 이것이 최고 품질의 신호입니다. 누군가가 아직 존재하지 않는 것에 돈을 준다면 그들은 솔루션을 믿습니다. 환불 가능한 보증금도 효과가 있습니다. **옵션 C: 컨시어지 MVP.** 자동화하기 전에 수동으로 하세요. SaaS 대신 컨설팅. 소프트웨어 도구 대신 맞춤형 스프레드시트. AI 생성 대신 수동으로 큐레이션된 뉴스레터. 소수의 고객을 강제로 서비스하고, 그들이 무엇을 소중히 여기는지 정확히 배우고, 그것을 중심으로 제품을 구축합니다. ## 4단계: 구축하기 전에 약속을 받으세요 이것이 진짜 검증과 희망적 사고를 구분하는 관문입니다. 스모크 테스트를 실행하기 전에 아이디어에 대한 "약속"이 무엇을 의미하는지 정의하세요: - **SaaS / 소프트웨어:** 할인 가격으로 사전 판매 또는 서명된 의향서 - **콘텐츠 / 미디어:** 참여하기 위해 클릭한 이메일 구독자 (팔로워만이 아닌) - **서비스 / 컨설팅:** 유료 발견 통화 또는 서명된 제안 - **물리적 제품:** Kickstarter 보증금 또는 사전 주문 할인이 있어도, 환불 보증이 있어도 적어도 한 명이라도 약속하게 할 수 없다면 아이디어는 준비되지 않은 것입니다. 이건 실패가 아닙니다. 그것은 시스템이 작동하는 것입니다. 몇 달의 구축 시간을 절약했습니다. ## 5단계: 시작하기 전에 합격/불합격 임계값을 설정하세요 함정은 이렇습니다: 스모크 테스트를 실행하고, 미지근한 결과를 얻고, 어쨌든 진행하도록 자신을 설득합니다. "랜딩 페이지 카피가 좋지 않았다." "충분히 홍보하지 않았다." "그냥 더 많은 시간이 필요할 뿐이다." 멈추세요. 테스트를 실행하기 전에 임계값을 적어두세요: > "유료 광고 없이 14일 내에 50개의 대기자 명단 등록을 받으면 구축합니다. 50개에 도달하지 못하면 구축하지 않습니다 — 포지셔닝을 바꾸거나 아이디어를 없앱니다." 적어두세요. 친구에게 말하세요. 가능하면 공개하세요. 그리고 지키세요. 숫자는 임의적입니다. 중요한 것은 미리 결정하고 데이터가 차갑게 들어올 때 골대를 움직이지 않는 것입니다. ## 흔한 검증 실수 1. **사람들에게 살 것인지 물어보기.** 예의 바르기 위해 거의 항상 예라고 말합니다. 중요한 유일한 질문: "지금 사겠습니까?" 2. **친구와 가족으로 검증하기.** 그들은 당신을 응원합니다. 그들은 당신의 고객이 아닙니다. 3. **다른 사람들도 그것을 가지고 있는지 확인하지 않고 자신의 문제 해결하기.** 귀하의 문제는 귀하에게만 고유할 수 있습니다. 포럼을 확인하세요. 4. **설문 응답을 검증이라고 부르기.** 설문은 아이디어를 생성할 수 있습니다. 수요를 검증할 수는 없습니다. 오직 돈이나 진정한 약속만이 할 수 있습니다. 5. **완벽한 정보를 기다리기.** 검증은 불확실성을 완전히 제거하는 것이 아니라 다음 단계를 위한 충분한 신호를 얻는 것입니다. ## "진행" 신호가 의미하는 것 다음의 조합을 찾고 있습니다: 1. 핵심 문제 키워드에 대해 월간 1,000건 이상의 검색량 2. 경쟁 활동 — 실제 돈을 청구하는 3개 이상의 실제 플레이어 3. 문제에 대한 적극적인 좌절감을 보여주는 포럼 또는 커뮤니티 스레드 최소 20개 4. 타겟 트래픽에서 5% 이상의 스모크 테스트 전환율 5. 구걸 없이 적어도 한 명이 약속합니다 — 지불하거나, 서명하거나, 보증금을 냅니다 5개 모두 달성하면 실행 가능한 방향이 있습니다. 2~3개 달성하면 개선할 가치가 있는 신호가 있습니다. 0개 달성하면 근본적으로 다른 아이디어나 청중이 필요합니다. ## 검증 스택 이 프로세스에서 제가 사용하고 추천하는 도구: - **검색 수요:** [Semrush](/recommends/semrush) — 한 곳에서 키워드 볼륨, 경쟁사 분석, 콘텐츠 공백 - **포럼 리서치:** Reddit, Quora, 틈새 Facebook 그룹, Discord 커뮤니티 - **랜딩 페이지:** Carrd (무료, 빠름) 또는 더 많은 디자인 제어를 위한 Webflow - **이메일 캡처 / 대기자 명단:** Kit (ConvertKit)로 검증하면서 목록 구축 시작 - **결제:** Stripe — 제품 구축 전 결제로 직접 링크 - **애널리틱스:** 스모크 테스트 페이지의 Google Analytics로 실제 행동 추적 ## 운영자의 결론 구축할 수 있는 가장 비싼 것은 아무도 원하지 않는 제품입니다. 검증은 위험을 제거하는 것이 아닙니다 — 프로덕션에서 느리게 실패하는 대신 종이 위에서 빠르게 실패하는 것입니다. 스모크 테스트를 실행하고, 약속을 받고, 시작하기 전에 임계값을 설정하고, 결과를 존중하세요. 신호가 있으면 알 것입니다. 없다면 그것도 알 것입니다. --- **관련:** [수익성 있는 비즈니스 구축 방법](/how-to-build-profitable-business/) · [성장 마케팅 전략 가이드](/growth-marketing-strategies-guide/) · [기업가가 되는 방법](/how-to-become-an-entrepreneur/) --- ## Claude API의 프롬프트 캐싱: 모델을 바꾸지 않고 입력 비용 줄이기 Source: https://alejandrorioja.com/ko/prompt-caching-cut-your-claude-costs-without-switching-models/ Published: 2026-06-18 Updated: 2026-06-18 Tags: AI Agents, Operations TL;DR: 프롬프트 캐싱은 크고 안정적인 입력 — 시스템 프롬프트, 도구 정의, 퓨샷 예시 — 의 비용을 반복 요청 시 일반 입력 가격의 약 10% 수준으로 낮춥니다. 작동 원리는 접두사 일치입니다. 안정적인 콘텐츠의 끝에 cache_control 마커를 두고, 그 뒤에 변동되는 모든 것을 배치하세요. 캐시 적중률을 망치는 실수는 타임스탬프나 UUID가 접두사 안으로 흘러 들어가게 두는 것입니다. ## Table of contents _2026년 6월 업데이트._ **요약:** 프롬프트 캐싱은 크고 안정적인 입력 — 시스템 프롬프트, 도구 정의, 퓨샷 예시 — 의 비용을 반복 요청 시 일반 입력 가격의 약 10% 수준으로 낮춥니다. 작동 원리는 접두사 일치입니다. 안정적인 콘텐츠의 끝에 `cache_control` 마커를 두고, 그 뒤에 변동되는 모든 것을 배치하세요. 캐시 적중률을 망치는 실수는 타임스탬프나 UUID가 접두사 안으로 흘러 들어가게 두는 것입니다. **[운영자의 관점]** 저는 컨설팅 브랜드와 Pickleland에 걸쳐 100개가 넘는 에이전트를 운영합니다. 가장 큰 비용 항목은 모델 등급이 아니라 — 요청마다 똑같은 4,000토큰짜리 시스템 프롬프트를 얼마나 자주 다시 보내는가입니다. 프롬프트 캐싱은 모델이나 출력 품질을 건드리지 않고도 고빈도 에이전트에서 그 비용을 거의 0에 가깝게 줄여주었습니다. 정확히 어떻게 작동하는지, 그리고 함정이 어디에 있는지 살펴봅니다. ## 프롬프트 캐싱이 실제로 하는 일 [Claude](/recommends/claude) API에 대한 모든 호출은 토큰을 전송합니다. 캐싱이 없으면 요청 안의 모든 토큰 — 시스템 프롬프트, 도구 정의, 퓨샷 예시, 사용자 메시지 — 이 일반 입력 요율로 과금됩니다. 캐싱을 사용하면 첫 요청 이후 그 토큰의 접두사가 Anthropic 서버에 저장됩니다. 정확히 동일한 접두사를 공유하는 이후 요청에서는 토큰을 처음부터 다시 처리하는 대신 캐시 *읽기* 가격을 지불합니다. 비용 차이는 실제로 큽니다: - **캐시 쓰기:** 기본 입력 가격의 약 1.25배 (5분 TTL) 또는 약 2배 (1시간 TTL) - **캐시 읽기:** 기본 입력 가격의 약 0.1배 - **손익분기점:** 5분 TTL에서는 2회 요청, 1시간 TTL에서는 3회 요청 손익분기점을 넘기면 — 하루에 몇 번 이상 실행되는 에이전트라면 금세 넘깁니다 — 추가되는 모든 캐시 적중은 해당 토큰에 대해 약 90%의 할인을 의미합니다. ## 접두사 일치 불변식 이것이 나머지 모든 것을 좌우하는 단 하나의 규칙입니다: **캐시 키는 렌더링된 프롬프트의 접두사 일치다.** Anthropic 서버는 프롬프트의 시작부터 `cache_control` 마커까지 렌더링된 콘텐츠를 저장합니다. 다음 요청에서 캐시 적중이 일어나려면 프롬프트 시작부터 그 마커까지의 모든 토큰이 동일해야 합니다 — 바이트 단위로 똑같아야 합니다. 접두사 일치를 위한 렌더링 순서는 다음과 같습니다: tools → system → messages. 즉, tools 배열이 먼저 해시되고, 그다음 system 블록, 그다음 messages가 순서대로 처리됩니다. 이것이 실무에서 의미하는 바: 안정적인 콘텐츠가 먼저 와야 합니다. 시스템 프롬프트가 무언가 동적인 것 — 현재 날짜, 사용자 ID, 요청 추적 ID — 을 참조하고 그것이 `cache_control` 마커보다 *앞에* 나타나면, 접두사가 계속 바뀌기 때문에 모든 요청에서 캐시가 빗나갑니다. ## 어디에 캐시 마커를 둘 것인가 가장 효과가 큰 대상은 다음과 같습니다: **1. 시스템 프롬프트** 시스템 프롬프트는 보통 가장 큰 안정적 블록입니다. 상세한 에이전트 페르소나, 행동 규칙 목록, 출력 형식 지침 — 이 모든 것은 같은 에이전트를 호출할 때마다 동일합니다. 마커를 다세요: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, system: [ { type: "text", text: `You are a content operations agent for alejandrorioja.com. Your job is to draft blog posts in Alejandro's voice: direct, practitioner, first-person, numbered lists, honest caveats. No hedging. No filler. Every section must earn its place. [... 2000 more tokens of stable instructions ...]`, cache_control: { type: "ephemeral" }, }, ], messages: [ { role: "user", content: "Draft a post about prompt caching.", }, ], }); ``` system 블록의 `cache_control: { type: "ephemeral" }`는 그 블록까지 포함한 모든 것을 캐싱하라고 Claude에게 지시합니다. `messages` 배열은 변동적이어서 — 요청마다 다릅니다 — 캐시 경계 바깥에 머뭅니다. **2. 도구 정의** 에이전트가 도구를 사용한다면 그 정의는 꽤 클 수 있습니다. 설명, 매개변수 이름, 열거형 값을 잘 갖춘 도구 스키마는 도구 하나당 500~1,000토큰에 이를 수 있습니다. 도구가 5개라면 호출마다 다시 처리하는 데 비용을 치르는 토큰이 최대 5,000토큰입니다: ```typescript const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, tools: [ { name: "search_airtable", description: "Search the Airtable content queue...", input_schema: { type: "object", properties: { query: { type: "string" } } }, }, // ... more tools ... { name: "post_to_kit", description: "Schedule a broadcast via the Kit API...", input_schema: { /* ... */ }, // Mark the last tool to cache the entire tools array } as Anthropic.Tool & { cache_control: { type: "ephemeral" } }, ], system: "...", messages: [...], }); ``` 배열의 *마지막* 도구에 마커를 다세요. 접두사 일치가 그 지점부터 전체 tools 배열을 포괄합니다. **3. messages 안의 퓨샷 예시** 정적인 퓨샷 예시를 `messages` 배열의 앞쪽 메시지로 전달한다면 그것도 캐싱할 수 있습니다. 이를 처음 N개의 메시지로 구성하고 마지막 예시 턴에 마커를 다세요: ```typescript const messages: Anthropic.MessageParam[] = [ { role: "user", content: [ { type: "text", text: "Here are examples of posts in my voice:\n\n[Example 1...]\n\n[Example 2...]", cache_control: { type: "ephemeral" }, } as Anthropic.TextBlockParam & { cache_control: { type: "ephemeral" } }, ], }, { role: "assistant", content: "Understood. I'll follow that voice.", }, // The actual user turn follows — this is volatile, no cache marker { role: "user", content: actualUserRequest, }, ]; ``` ## 무엇을 캐싱하지 말 것인가 (조용한 무효화 요인) 이들은 안정적으로 보이지만 그렇지 않은 것들입니다 — 그리고 적중률을 조용히 망가뜨립니다. API는 경고해 주지 않습니다. 매 요청마다 `cache_creation_input_tokens`가 보이는 것을 그저 지켜보며 왜 그런지 의아해할 뿐입니다. **시스템 프롬프트의 타임스탬프.** 가장 흔한 단일 실수: ```typescript // This invalidates the cache on every request const system = `You are an agent. Current time: ${new Date().toISOString()}`; ``` 타임스탬프는 마땅히 있어야 할 곳, 즉 사용자 메시지로 옮기세요: ```typescript // Stable system prompt — cacheable const system = `You are an agent. Use the current time provided by the user.`; // Volatile user message — not cached const userMessage = `Current time: ${new Date().toISOString()}. Run the daily brief.`; ``` **무작위 UUID와 추적 ID.** 같은 문제입니다. 로깅을 위해 추적 ID를 system 블록에 주입하면 매 요청마다 새로운 접두사가 생깁니다. **비결정적 JSON 직렬화.** 객체를 시스템 프롬프트로 직렬화할 때 키 순서가 보장되지 않으면, 기저 데이터가 같더라도 렌더링된 문자열이 달라질 수 있습니다. 안정적인 키 순서로 직렬화하거나 템플릿 문자열을 사용하세요. **동적 퓨샷 선택.** 현재 쿼리에 따라 퓨샷 예시를 골라 캐싱된 접두사에 넣고 있다면, "안정적" 접두사를 쿼리 의존적으로 만든 셈입니다. 캐시 계층에는 고정 예시를 쓰기로 결정하거나, 동적 예시는 캐싱되지 않는 메시지 턴으로 옮기세요. ## 캐시 적중률 확인하기 모든 응답에는 사용량 메타데이터가 포함됩니다. 그것을 확인하세요: ```typescript const response = await client.messages.create({ /* ... */ }); console.log({ inputTokens: response.usage.input_tokens, cacheRead: response.usage.cache_read_input_tokens, cacheWrite: response.usage.cache_creation_input_tokens, outputTokens: response.usage.output_tokens, }); ``` 첫 요청에서는: `cache_creation_input_tokens`가 0이 아니고 `cache_read_input_tokens`는 0입니다. 그것이 쓰기입니다. 캐시 적중 시: `cache_read_input_tokens`가 0이 아니고 `cache_creation_input_tokens`는 0입니다. 그것이 읽기입니다. 매 요청마다 `cache_creation_input_tokens`가 보인다면 접두사가 바뀌고 있는 것입니다. 각 호출 전에 렌더링된 시스템 프롬프트의 처음 200자를 출력하는 로그 문장을 추가하세요 — 떠다니는 타임스탬프가 즉시 눈에 띌 것입니다. ## 1시간 TTL: 추가 쓰기 비용이 가치 있을 때 기본 TTL은 5분입니다. 에이전트가 저빈도로 — 5분에 한 번 미만으로 — 실행된다면, 읽기를 얻지 못한 채 대부분의 요청에서 캐시 쓰기 비용을 치르게 됩니다. ```typescript // Opt into a 1-hour TTL cache_control: { type: "ephemeral", ttl: "1h" } ``` 1시간 쓰기는 1.25배가 아니라 기본 입력 가격의 약 2배가 듭니다. 계산은 이렇습니다: 시간당 3회 이상 캐시에 적중한다면 1시간 TTL이 비용을 절약합니다. 에이전트가 하루에 한 번 실행된다면(제 데일리 브리핑처럼) 1시간 TTL조차 도움이 되지 않습니다 — 매번 쓰기 비용을 치르기 때문입니다. 그런 경우 시스템 프롬프트가 엄청나게 크지 않은 한 캐싱의 이점은 미미합니다. 제 데일리 브리핑 에이전트는 3,000토큰짜리 시스템 프롬프트가 있지만 하루에 한 번 실행됩니다. 캐싱이 도움이 되지 않습니다. 제 뉴스레터 에이전트는 초안을 작성하는 동안 세션당 수십 번 실행됩니다 — 캐싱이 상당한 비용을 절약합니다. ## 사전 예열: 첫 요청을 저렴하게 만들기 알려진 트래픽 급증이 예정되어 있다면 — 배치 작업, API 출시 등 — 저비용 더미 요청으로 캐시를 미리 예열할 수 있습니다: ```typescript // Pre-warm: write the cache at near-zero output cost await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1, // minimal output system: [{ type: "text", text: stableSystemPrompt, cache_control: { type: "ephemeral" } }], messages: [{ role: "user", content: "ping" }], }); // Now the real requests read from cache ``` 이는 주로 여러 병렬 요청을 띄우면서 각각이 캐시를 쓰려고 경쟁하기보다 따뜻한 캐시에 적중하기를 원하는 배치 처리에 유용합니다. ## 에이전트 루프에서의 프롬프트 캐싱 다중 턴 에이전트 루프에서는 대화 기록이 매 턴마다 늘어납니다. 캐시는 이를 처리할 만큼 영리합니다: 20블록 룩백 윈도를 사용해 마지막 20개 콘텐츠 블록 안에서 가장 긴 일치 접두사를 찾습니다. 실무적 함의: 안정적인 콘텐츠(시스템 프롬프트, 도구 정의)를 맨 위에 고정해 두세요. messages 배열 끝에서 늘어나는 대화 기록은 안정적 블록의 접두사 일치를 깨뜨리지 않습니다 — 그것들은 변동 콘텐츠보다 앞에 있고, 접두사 일치는 맨 위에서 시작하기 때문입니다. 실무에서 제 에이전트는 턴을 이렇게 구성합니다: ``` System (cached) → Tools (cached) → Few-shot (cached) → Turn 1 → Turn 2 → ... → Current turn ``` 캐시는 퓨샷 마커까지의 모든 것을 포괄합니다. 그 뒤에서 늘어나는 턴 기록은 매번 다시 처리되지만, 그래도 괜찮습니다 — 그 토큰들은 세션 고유이며 안정적 접두사에 비해 작습니다. ## 청구서에서는 어떻게 보이는가 고빈도 에이전트를 예로 들어봅시다: 하루 100회 호출, 4,000토큰짜리 시스템 프롬프트, Sonnet 가격. 캐싱 없이: - 100 × 4,000 토큰 × $3/1M = **하루 $1.20** 캐싱 사용 (5분 TTL, 피크 시 시간당 50회 호출 가정): - 5분당 쓰기 1회 × $3.75/1M × 4,000 토큰 = 쓰기로 하루 약 $0.02 - 하루 약 98회 읽기 × $0.30/1M × 4,000 토큰 = **읽기로 하루 $0.12** 해당 입력 토큰에 대해 대략 90% 절감입니다. 규모가 커지면 — 하루 1,000회 호출 — 그 차이는 더욱 누적됩니다. 그리고 이것은 [Haiku 대 Sonnet 계산](/ai-agent-cost-math-when-haiku-beats-sonnet)에서 나오는 모델 라우팅 절감 위에 추가되는 것입니다: 캐싱은 모든 등급에서 작동합니다. ## 운영자의 결론 프롬프트 캐싱은 Claude API에서 가장 쉬운 비용 최적화입니다: 이미 작성하고 있는 콘텐츠 블록에 필드 하나를 더하는 것뿐입니다. 제약은 접두사 안정성에 대한 규율 — 캐시 마커 앞에 동적인 것을 두지 않는 것 — 입니다. 시스템 프롬프트, 도구, 정적 예시를 변동 콘텐츠로부터 깨끗하게 유지할 수 있다면, 모든 캐시 적중에서 일반 입력 비용의 약 10%만 지불하게 됩니다. 크고 안정적인 프롬프트를 쓰는 고빈도 에이전트에게 이것은 모델 등급을 바꾸는 것보다 더 큰 지렛대입니다. --- **관련 글:** [AI 에이전트 비용 계산: Haiku가 Sonnet을 이길 때](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [이벤트 트리거 vs 예약 에이전트](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [내 비즈니스를 운영하는 데 실제로 쓰는 5가지 AI 도구](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) --- ## Claude Fable 5 첫인상: 어느 운영자의 관점 Source: https://alejandrorioja.com/ko/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5는 Anthropic의 가장 강력한 모델이며, 어렵고 장기 호흡이 필요한 에이전트 작업에서 그 진가가 드러난다 — 하지만 기본 업그레이드 대상은 아니다. 토큰당 비용이 더 비싸고, 토큰 수를 약 30% 부풀리는 새 tokenizer를 쓰며, 끌 수 없는 상시 thinking이 돌아가고, 분류기 단계에서 요청을 거부할 수 있다. 대부분의 워크로드에는 여전히 Opus 4.8이 정답이다. 작업이 정말로 어려울 때 Fable 5를 꺼내라. ## 목차 _2026년 6월 업데이트._ **TL;DR:** Fable 5는 Anthropic의 가장 강력한 모델이며, 어렵고 장기 호흡이 필요한 에이전트 작업에서 그 진가가 드러난다 — 하지만 기본 업그레이드 대상은 아니다. 토큰당 비용이 더 비싸고, 토큰 수를 약 30% 부풀리는 새 tokenizer를 쓰며, 끌 수 없는 상시 thinking이 돌아가고, 분류기 단계에서 요청을 거부할 수 있다. 대부분의 워크로드에는 여전히 Opus 4.8이 정답이다. 작업이 정말로 어려울 때 Fable 5를 꺼내라. **[운영자의 시선]** 나는 컨설팅 브랜드와 피클볼 시설에 걸쳐 30개 이상의 프로덕션 에이전트를 운영한다. 그래서 새 플래그십 모델은 나에게 벤치마크가 아니라 — 비용 항목이자 마이그레이션이다. 실제로 그중 몇 개에 Fable 5를 연결했을 때 무엇이 바뀌었는지, 그리고 어디에는 Opus 4.8을 그대로 남겨 두었는지 이야기해 보겠다. ## Fable 5는 실제로 무엇인가 [Claude](/recommends/claude) Fable 5는 Anthropic이 폭넓게 출시한 가장 강력한 모델이다. 까다로운 영역의 끝단을 겨냥한다: 깊은 추론과 장기 호흡의 에이전트 작업 — 에이전트가 수십 번의 도구 호출에 걸쳐 흐름을 놓치지 않고 계획을 유지해야 하는 그런 실행들이다. API 표면은 Opus 4.7/4.8과 거의 동일해서 테스트하기 쉬웠다. 기본 1M 토큰 컨텍스트 윈도우, 요청당 최대 128K 출력 토큰. 최근 Opus 라인에서 무언가를 만들어 본 적이 있다면 요청 형태는 익숙할 것이다. 차이는 세부에 있고, 그 세부에 돈과 의외의 함정이 숨어 있다. 혼동하지 않도록 작명에 관한 메모 하나: **Mythos 5**는 같은 모델이다 — 같은 성능, 같은 가격, 같은 동작 — Anthropic의 Project Glasswing 프로그램을 통해서만 제공된다. 그 프로그램에 속해 있지 않다면, 당신이 원하는 모델은 `claude-fable-5`다. 아래 내용은 둘 다에 적용된다. ## 진짜로 더 나은 지점 가장 어려운 에이전트 작업을 먼저 던졌다: 여러 출처를 읽고, 주장을 교차 검증하며, 인용을 단 브리프를 작성하는 다단계 리서치-종합 실행이다. 약한 모델이 표류하는 부류의 작업이다 — 열 번쯤 도구를 호출하고 나면 어떤 주장이 어느 출처에서 나왔는지 추적을 잃는다. Fable 5는 흐름을 붙들었다. 종합이 더 탄탄했고, 인용은 올바른 주장에 계속 붙어 있었으며, 내 Opus 4.8 버전이 조용히 평균값으로 뭉개고 있던 출처 간 모순 두 건을 잡아냈다. 길고 구조화된 추론에서는 진짜 한 단계 도약이다 — 미미한 벤치마크 상승이 아니다. 이것이 솔직한 옹호의 근거다. 당신 에이전트의 실패 양상이 "어려운 10%에서 무너진다"라면, Fable 5는 그 격차를 좁혀 준다. 당신 에이전트가 뉴스레터를 요약하거나 소셜 게시물 초안을 쓰는 일을 한다면, 차이를 느끼지 못할 것이다 — 그리고 쓰지도 않을 성능에 비용을 치르게 된다. ## 아무도 경고해 주지 않는 비용 함정 릴리스 노트를 대충 훑었다면 발목을 잡힐 바로 그 지점이다. Fable 5는 **새 tokenizer**를 탑재했고, 같은 콘텐츠가 Opus 라인보다 대략 **30% 더 많은 토큰**으로 토큰화된다. 가격과 복리로 맞물리니 다시 한번 읽어 보라. Fable 5는 애초에 Opus 등급보다 높게 책정돼 있다(입력 토큰 100만 개당 $10, 출력 100만 개당 $50). 이제 모든 프롬프트와 완성 결과 위에 약 30%의 토큰 인플레이션을 얹는다. 변하지 않은 워크로드 — 같은 프롬프트, 같은 출력 — 라도 에이전트가 하는 일을 단 하나도 바꾸기 전에, 마이그레이션 후 의미 있게 더 비싸질 수 있다. 그러니 예전 수치를 재사용하지 마라. 당신의 `max_tokens` 설정, 컨텍스트 윈도우 예산, 실행당 비용 추정치 — 모두 다른 tokenizer로 측정된 것이다. 좋은 소식: `model: "claude-fable-5"`를 넘기면 토큰 카운팅 엔드포인트가 **두** tokenizer 모두에서의 카운트를 반환하므로, 무언가를 바꾸기 전에 실제 프롬프트에서 그 차이를 측정할 수 있다. ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` 나는 가장 무거운 프롬프트부터 이걸 돌려 봤다. 차이는 균일하지 않았다 — 콘텐츠에 따라 달라진다 — 하지만 "약 30% 더 잡고, 거기에 가격 프리미엄을 더하라"가 올바른 사고 모델이었다. ## thinking은 상시 켜져 있다 — 그리고 끌 수 없다 Fable 5에서는 적응형 thinking이 항상 돌아간다. Opus 라인 대비 새로 생긴 단 하나의 호환성 깨짐: 명시적으로 `thinking: {type: "disabled"}`를 보내면 400을 받는다. 해법은 간단하다 — `thinking` 파라미터를 통째로 생략하면 된다 — 하지만 저렴하고 빠른 호출을 위해 thinking을 명시적으로 비활성화하던 코드가 있었다면, 그 코드는 이제 오류를 낸다. 원시 사고 사슬(chain of thought)도 그대로 돌려받지 못한다. Fable 5는 그것을 보호한다: 정상적인 `thinking` 블록을 받고, `display: "summarized"`로 읽기 좋은 요약을 요청할 수 있지만, 필터링되지 않은 추론은 결코 노출되지 않는다. 대부분의 앱에는 문제가 되지 않는다 — 가시성이 필요하면 요약을 읽으면 된다. 중요해지는 곳은 **멀티턴 에이전트**다: 같은 모델에서 대화를 이어 갈 때 thinking 블록을 **변경 없이** 그대로 다시 넘겨야 한다. 그걸 빠뜨리거나 편집하면 해당 턴이 깨진다. 에이전트 루프를 만든다면 thinking 블록을 그대로 들고 가는 불투명 토큰으로 취급하라. ## 거부(refusal)는 이제 제어 흐름의 문제다 모델 주변에 코드를 어떻게 작성하는지에 가장 큰 영향을 주는 변화다. Fable 5는 들어오는 요청에 안전 분류기를 돌리는데, 주로 연구용 생물학과 대부분의 사이버보안 콘텐츠를 겨냥한다. 요청이 거절되면 `stop_reason: "refusal"`과 함께 **성공적인 HTTP 200**을 받는다 — 오류도, 예외도 아니다. `content` 배열은 비어 있을 수 있다. 당신의 코드가 `stop_reason`을 먼저 확인하지 않고 `response.content[0].text`를 한다면, 요청이 거부되는 날 충돌할 것이다. 그리고 인접한 무해한 작업 — 정당한 보안 도구, 생명과학 작업 — 이 가끔 오탐을 일으킬 수 있으니, 이건 수상한 짓을 하는 사람만의 문제가 아니다. 규칙은 이렇다: **`stop_reason`으로 분기하고, 절대 `stop_details`로 분기하지 마라.** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` 프로덕션에는 더 깔끔한 길이 있다: 거부된 요청을 같은 왕복 안에서 `claude-opus-4-8`로 자동 재시도하고, 크레딧 방식의 재가격 책정을 적용하는 서버 사이드 `fallbacks` 파라미터(베타)다. 에이전트를 무인으로 돌린다면, 단 한 번의 오탐 거부가 실행 전체를 막다른 골목으로 몰지 않도록 이걸 연결해 두라. 이것은 [프로덕션에서 계속 실패하는](/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/) 에이전트에 관해 내가 거듭 다시 배우는 바로 그 교훈이다: 모델이 똑똑해진다고 해서 엣지 케이스를 처리해야 할 필요가 사라지는 게 아니라 — 엣지 케이스의 위치를 옮길 뿐이다. ## 마이그레이션 세부 사항 둘 더 내 시간을 잡아먹었던 작은 것들 몇 가지, 당신의 시간은 잡아먹지 않도록 적어 둔다: - **어시스턴트 프리필 없음.** 마지막 어시스턴트 턴을 프리필해서 출력을 유도하고 있었다면, 그 패턴은 사라졌다. 대신 구조화된 출력(`output_config.format`)이나 시스템 프롬프트 지시를 사용하라. - **30일 데이터 보존 필수.** Fable 5는 제로 데이터 보존(zero-data-retention)으로 제공되지 않는다. 규정 준수 이유로 ZDR을 쓰고 있다면, Fable 5는 선택지에서 빠지고 Opus 4.8이 당신의 천장으로 남는다. 마이그레이션을 계획한 *뒤*가 아니라 *전에* 이것을 확인하라. ## 정말 갈아타야 할까? 함께 지내 본 뒤 내 운영자로서의 판단은 이렇다. **Fable 5는 기본적인 "최신 모델로 업그레이드" 대상이 아니다 — Opus 4.8이 그렇다.** 사람들이 놀라지만, 이게 올바른 틀이다. Opus 4.8은 4.7에서 새로운 호환성 깨짐 없이 모델 ID만 바꾸면 되고, 더 저렴하며, 압도적 다수의 에이전트 작업에서 출력 품질이 구별되지 않는다. Fable 5는 정말로 어려운 작업에서 제값을 한다: 여러 단계에 걸쳐 일관성을 유지해야 하는 장기 호흡 에이전트, 깊은 다중 출처 추론, 죽이려는 실패가 미묘한 그런 실행들. 그런 경우 성능은 진짜이고 프리미엄을 치를 가치가 있다. 그 외 모든 것 — 콘텐츠 초안 작성, 분류, 라우팅, 요약 — 에서는 체감하지도 못할 품질에 더 많은 토큰을 더 높은 가격으로 치르는 셈이다. 결국 나는 둘 다 돌리게 됐다. 리서치-종합 에이전트는 Fable 5로 옮겼다. 나머지는 전부 Opus 4.8에 남았다. 그 분리가 바로 핵심이다: 유행이 아니라 작업별로 모델을 골라라. 에이전트 함대를 운영한다면, 내가 [2026 운영자 스택](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/)에서 쓴 것과 같은 규율이 적용된다 — 어려운 일은 비싼 모델로 보내고, 쉬운 일에 과하게 지불하기를 멈춰라. ## 운영자의 결론 다른 무엇에 손대기 전에 가장 어려운 단 하나의 작업에서 Fable 5를 테스트하라 — 거기가 본전을 뽑는 지점이고, 거기서 바늘이 움직이지 않는다면 어디서도 움직이지 않는다. 실제 프롬프트에 토큰 카운터를 돌려서 약 30%의 tokenizer 인플레이션과 가격 프리미엄이 청구서에서 당신을 놀라게 하지 않도록 하라. Fable 5가 프로덕션에 닿는 모든 곳에 `stop_reason: "refusal"` 확인(또는 Opus 4.8로의 서버 사이드 폴백)을 추가하라. 그런 다음 의도적으로 라우팅하라: 어려운 10%에는 Fable 5, 나머지에는 Opus 4.8. 최고의 모델은 가장 강력한 모델이 아니라 — 작업에 맞춰진 모델이다. --- ## AI 에이전트 초보자 완벽 가이드: Cowork, Codex, 그리고 실제로 일을 처리하는 도구들 Source: https://alejandrorioja.com/ko/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: AI 에이전트는 챗봇을 넘어선 다음 단계입니다. 일상 언어로 목표를 주면 에이전트가 일을 처리합니다 — 파일을 읽고, 초안을 작성하며, 정리하고, 코드를 작성해 실행합니다. Cowork는 노코드 입문 경로이고, Codex와 Claude Code는 코드베이스를 다루는 사람을 위한 도구입니다. 중요한 기술은 프로그래밍을 배우는 게 아니라 명확하고 범위가 잘 정의된 지시를 작성하는 것입니다. ## Table of contents _2026년 6월 업데이트._ **TL;DR:** AI 에이전트는 챗봇을 넘어선 다음 단계입니다. 평범한 언어로 목표를 주면 에이전트가 일을 처리합니다 — 파일을 읽고, 초안을 작성하며, 정리하고, 코드를 작성해 실행하고, 자신의 결과물을 확인합니다. **Cowork**는 비기술자를 위한 노코드 입문 경로이고, **Codex**와 **Claude Code**는 코드베이스를 다루는 사람을 위한 도구입니다. 유일하게 중요한 기술은 프로그래밍을 배우는 것이 아니라 명확하고 범위가 잘 정의된 지시를 작성하는 것입니다. **[저자 노트]** 저는 매일 30개 이상의 코드화된 에이전트를 운용하지만, 대부분의 사람들은 코드 없이도 가치의 80%를 얻을 수 있습니다. 필요한 것은 명확한 지시와 그것을 실행할 공간입니다. 이 가이드는 코드 한 줄도 작성해본 적 없는 영리한 친구에게 건넬 입문서입니다. ## "AI 에이전트"가 실제로 무엇인가 챗봇은 질문에 답합니다. **에이전트**는 작업을 완료합니다. 차이는 에이전트가 루프 안에서 행동을 취할 수 있다는 것입니다 — 문서를 읽고, 다음에 할 일을 결정하고, 파일을 작성하고, 명령을 실행하고, 결과를 확인하고, 문제를 수정하는 것을 — 당신이 매 단계를 지시하지 않아도 됩니다. 구체적으로: "이 스프레드시트를 어떻게 정리하나요?"라고 묻지 않습니다. "스프레드시트를 드릴게요 — 중복 항목을 제거하고, 날짜 형식을 수정하고, 이메일이 없는 행에 표시해주세요"라고 말하면 에이전트가 처리하고 정리된 파일을 돌려줍니다. *조언*에서 *완성된 작업*으로의 전환 — 그것이 핵심입니다. ## 두 가지 도구 패밀리 이 세계로 들어가는 문은 두 개이며, 자신의 업무에 맞는 문 하나만 선택하면 됩니다. ### 문 1: 노코드 에이전트 (코드를 작성하지 않는다면 여기서 시작) **Claude Cowork**는 Claude에게 목표와 자료 — 파일, 링크, 메모 — 를 주면 당신이 검토하고 사용할 결과물을 생성하는 작업 공간입니다: 초안, 요약, 계획, 정리된 스프레드시트. 코드가 아닌 지시를 작성합니다. "프로그래밍 도구"가 아니라 "빠르게 읽고 절대 피로해지지 않는 매우 유능한 조수"라고 생각하세요. 마케터, 창업자, 운영자, 작가, 분석가 — 업무가 주로 문서, 리서치, 의사결정으로 구성된 모든 사람에게 올바른 출발점입니다. ### 문 2: 코딩 에이전트 (코드베이스가 관여되면 이것을 사용) **OpenAI Codex**와 **Claude Code**는 소프트웨어가 만들어지는 곳 — 터미널, IDE, 클라우드 — 에 사는 에이전트입니다. 변경 사항을 설명하면("다크 모드 토글 추가해줘", "이 실패하는 테스트 고쳐줘", "이 파일을 새 API로 마이그레이션해줘") 에이전트가 코드를 수정하고, 실행하고, 작동할 때까지 반복합니다. 당신은 모든 것을 검토하고, 에이전트는 타이핑을 담당합니다. 시니어 엔지니어가 아니어도 사용할 수 있습니다. 많은 비개발자들이 코딩 에이전트를 사용해 소규모 웹사이트를 구축하고, 스프레드시트를 스크립트로 자동화하며, 자신이 작성하지 않은 도구의 버그를 수정합니다. 하지만 실제 학습 곡선이 있으므로, 대부분의 초보자는 문 1에서 시작해 진짜 코드가 필요한 작업을 만났을 때 문 2로 넘어가는 것이 좋습니다. ## 첫 번째 성과 (오늘 당장) 자주 하는 작고 귀찮은 작업을 하나 골라보세요. 좋은 첫 번째 후보: - 지저분한 회의 녹취록을 깔끔한 노트와 액션 아이템 목록으로 변환하기. - 긴 PDF를 5개의 핵심 사항과 3개의 가치 있는 질문으로 요약하기. - 거친 이메일 초안을 명확하고 따뜻하며 120자 이하로 다시 작성하기. 그런 다음 에이전트를 예측 불가능하지 않고 신뢰할 수 있게 만드는 구조를 사용하세요 — **역할 → 입력 → 정확한 지시 → 제약 → 확인**: > 당신은 저의 조수입니다. 아래에 [회의 녹취록/PDF/이메일 초안]을 붙여넣겠습니다. 다음을 해주세요: [굵은 글씨 \"액션 아이템\" 목록이 있는 깔끔한 노트로 변환/5개 항목 + 3개 후속 질문으로 요약/명확하고 따뜻하며 120자 이하로 다시 작성]. 저의 목소리를 유지해주세요. 시작하기 전에 모호한 점이 있으면 질문 하나만 해주세요. > > [여기에 내용을 붙여넣으세요] 끝입니다. 방금 작업을 위임했습니다. 구조가 전부입니다 — Cowork, ChatGPT, 코딩 에이전트 어디서든 동일하게 작동합니다. ## 에이전트를 신뢰할 수 있게 만드는 4단계 프롬프트 초보자들은 비결이 마법 같은 문구라고 생각합니다. 그렇지 않습니다. 구체성이 핵심입니다. 신뢰할 수 있는 에이전트 지시에는 네 가지 요소가 있습니다: 1. **역할** — 이 작업에서 에이전트가 누구인지 ("당신은 저의 리서치 조수입니다"). 2. **맥락** — 자료와 *이유* ("저는 핀테크 창업자와의 영업 통화를 준비하고 있습니다"). 3. **작업** — 정확하고 범위가 정의된 행동 ("최근 투자 라운드 사실 3가지를 찾고 두 가지 오프닝 질문을 작성해주세요"). 4. **제약 + 확인** — 형식, 길이, 톤, 그리고 추측하기 전에 물어보라는 지시 ("글머리 기호만, 출처 인용, 회사명이 모호하면 확인 질문 하나만 해주세요"). 모호하게 넣으면 모호하게 나옵니다. 에이전트가 더 많이 *할 수 있을수록* 당신의 명확성이 더 중요합니다 — 잘못 이해한 챗봇은 문장 하나를 낭비하지만, 잘못 이해한 에이전트는 취소해야 할 오후 내내의 작업을 낭비합니다. ## 건너뛸 초보자 실수 - **검색엔진처럼 취급하기.** 한 줄짜리 질문은 하지 마세요. 실제 파일로 실제 작업을 주세요. - **제약 생략하기.** "계획을 작성해줘"는 텍스트 벽을 돌려줍니다. "세 단계와 작업별 담당자가 있는 한 페이지 계획을 작성해줘"는 쓸 수 있는 무언가를 돌려줍니다. - **확인 요청하지 않기.** "모호한 점이 있으면 하나만 질문해주세요"를 추가하면 에이전트가 실행되기 *전에* 오해를 잡을 수 있습니다, 이후가 아니라. - **중요한 코드에서 코딩 에이전트를 무인으로 실행하기.** diff를 검토하세요. 에이전트는 빠르고 대부분 맞지만, "대부분"이라는 단어가 그 문장에서 작업을 하고 있습니다 — 배포되는 모든 것에 사람을 루프에 유지하세요. - **너무 일찍 문 2로 넘어가기.** 작업이 문서와 의사결정이라면 터미널을 열 필요가 전혀 없습니다. ## 첫 번째 도구 선택 방법 - **업무가 문서, 리서치, 글쓰기** → **Cowork**로 시작하세요 (또는 이미 결제하고 있는 챗 제품을 에이전트 모드로 사용). - **소프트웨어를 구축하거나 수정하고 싶다면** → **Claude Code** 또는 **OpenAI Codex**. - **반복적이고 자동화된 작업을 원한다면** (일일 다이제스트, 주간 보고서) → 프롬프트를 수동으로 마스터한 후 **[스케줄된 작업](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)**으로 이전하세요. ## AI 에이전트 초보자 FAQ — 2026 ### AI 에이전트를 사용하려면 프로그래밍을 알아야 하나요? 아니요. Claude Cowork 같은 노코드 에이전트는 비기술 사용자를 위해 만들어졌습니다 — 평범한 언어로 지시를 작성합니다. Codex와 Claude Code 같은 코딩 에이전트는 학습 곡선이 있지만, 그것도 자신을 프로그래머로 생각하지 않는 사람들이 점점 더 많이 사용하고 있습니다. 노코드로 시작하고, 작업에 필요할 때만 코드로 이동하세요. ### 챗봇과 AI 에이전트의 차이점은 무엇인가요? 챗봇은 질문에 답하고, 에이전트는 작업을 완료합니다. 에이전트는 루프 안에서 일련의 행동을 취할 수 있습니다 — 읽고, 결정하고, 행동하고, 확인하고, 수정하며 — 조언이 아닌 완성된 작업을 생성합니다. 실제로 같은 제품이 두 가지를 모두 하는 경우가 많으며, "에이전트 모드"가 에이전트 동작입니다. ### Cowork가 Codex보다 낫나요? 다른 작업을 위한 도구이지 더 낫거나 나쁜 것이 아닙니다. Cowork는 문서, 리서치, 운영을 위한 노코드 작업 공간입니다. Codex (와 Claude Code)는 소프트웨어 구축 및 수정을 위한 코딩 에이전트입니다. 자신의 작업에 맞는 것을 선택하세요. ### AI 에이전트에서 좋은 결과를 얻으려면 어떻게 해야 하나요? 구체성입니다. 4단계 구조를 사용하세요: 역할, 맥락, 정확한 작업, 제약 및 확인. 실제 자료를 제공하고, 원하는 형식을 알려주고, 시작 전에 모호한 점을 표시하도록 요청하세요. 명확한 지시는 어떤 "마법 프롬프트"보다 더 중요합니다. ### AI 에이전트를 스스로 실행하게 두는 것이 안전한가요? 낮은 위험도의 되돌릴 수 있는 작업 (초안 작성, 요약, 정리)에는 안전합니다 — 출력을 검토하고 계속 진행하세요. 실제 시스템을 변경하는 것 (코드 배포, 메시지 전송, 데이터 삭제)에는 루프에 사람을 유지하고 행동하기 전에 검토하세요. 되돌릴 수 있는 정도가 올바른 기준입니다: 취소하기 쉬울수록 더 안전하게 더 많은 자율성을 가질 수 있습니다. **관련 읽기:** [ChatGPT 답변에 인용되는 방법](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [llms.txt 플레이북](https://alejandrorioja.com/llms-txt-playbook/) · [Claude 스케줄된 작업 사용 방법](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **비즈니스에서 에이전트를 활용하는 데 도움이 필요하신가요?** 운영팀을 위한 AI 에이전트 시스템을 구축합니다 — [연락하기](https://alejandrorioja.com/contact/) 또는 [저의 사고방식](https://alejandrorioja.com/seo-tips/)에 대해 더 읽어보세요. --- ## Anthropic은 어떻게 돈을 버나요? Claude 비즈니스 모델 설명 Source: https://alejandrorioja.com/ko/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic은 다섯 가지 주요 채널을 통해 Claude AI 모델에 대한 접근권을 판매합니다: 사용량 기반 API(토큰당 요금), 소비자 구독(Claude Pro 및 Max), 엔터프라이즈 플랜(Team 및 Enterprise 시트), 개발자를 위한 Claude Code, 그리고 Amazon Bedrock 및 Google Vertex와 같은 클라우드 마켓플레이스를 통한 배포. 소비자 앱이 아닌 API와 엔터프라이즈 사업이 가장 큰 수익 동력입니다. ## Table of contents _2026년 6월 업데이트._ **TL;DR:** Anthropic은 다섯 가지 주요 채널을 통해 Claude AI 모델에 대한 접근권을 판매합니다: **사용량 기반 API**(토큰당 요금), **소비자 구독**(Claude Pro 및 Max), **엔터프라이즈 플랜**(Team 및 Enterprise 시트), 개발자를 위한 **Claude Code**, 그리고 Amazon Bedrock 및 Google Vertex AI와 같은 **클라우드 마켓플레이스를 통한 배포**. 소비자 채팅 앱이 아닌 API와 엔터프라이즈 사업이 가장 큰 수익 동력입니다. **[운영자 노트]** 저는 매일 Anthropic의 API를 사용해 개발하므로, 미터 안쪽에서 비즈니스를 바라봅니다. 이해해야 할 핵심: Anthropic은 소비자 접점을 가진 B2B 기업입니다. 여러분이 사용하는 채팅 앱은 마케팅이자 하나의 수익 라인이지만, 진짜 돈은 API를 통해 토큰을 측정하고 규모에 맞게 시트 비용을 지불하는 개발자와 기업에 있습니다. ## Anthropic이란 Anthropic은 2021년에 설립된 AI 안전성 및 연구 회사로, **Claude** 계열의 대형 언어 모델을 개발합니다. 이 모델들과 주변 도구들을 소비자, 개발자, 기업에 판매합니다. Amazon과 Google을 포함한 전략적 투자자들의 강력한 지원을 받는 비공개 기업으로, 두 회사는 클라우드 및 배포 파트너로도 기능합니다. 제품은 서비스로서의 인텔리전스입니다: 박스에 담긴 소프트웨어를 구매하는 것이 아니라, 여러분을 대신해 읽고, 쓰고, 추론하고, 행동하는 모델에 대한 접근권을 임대하는 것입니다. 아래의 각 채널은 동일한 핵심 자산을 둘러싼 서로 다른 포장입니다. ## Anthropic은 어떻게 돈을 버나요? ### 1. API(사용량 기반, 핵심 엔진) 비즈니스의 토대입니다. 개발자와 기업은 API를 통해 Claude를 호출하고 **토큰당** 비용을 냅니다 — 대략적으로, 입력 및 출력 텍스트 청크당 요금이 부과됩니다. 가격은 모델 성능에 따라 달라집니다: - **Claude Opus**(가장 강력한 등급)가 가장 비싸며 — 입력 토큰 100만 개당 수 달러, 출력은 그 몇 배 수준입니다. - **Claude Sonnet**(균형잡힌 주력 모델)은 중간 가격대입니다. - **Claude Haiku**(빠르고 저렴한 등급)는 가장 저렴하며, 대량의 단순 작업에 적합합니다. 출력 토큰이 입력 토큰보다 비싸며, 긴 컨텍스트, 프롬프트 캐싱, 배치 처리 같은 기능은 별도의 요금이 적용됩니다. 핵심 역학: **수익은 사용량에 정비례하여 증가합니다**. Claude를 제품에 내장하고 수백만 명의 사용자로 성장한 스타트업은 Anthropic이 새 계약을 체결하지 않아도 매달 더 많은 API 수익을 창출합니다. 이 사용량 기반 모델이 AI 랩들이 "런레이트 수익"이 이렇게 빠르게 성장하고 있다고 말하는 이유입니다 — 고객 자신의 성장과 함께 복리로 늘어납니다. ### 2. 소비자 구독(Claude Pro 및 Max) Claude 앱(웹, 데스크톱, 모바일)은 무료로 체험할 수 있으며, 헤비 유저를 위한 유료 등급이 있습니다: - **Claude Pro** — 더 높은 사용량 한도, 최상급 모델 접근권, 더 큰 컨텍스트 및 우선 접근 같은 기능을 위한 월정액. - **Claude Max** — Pro 한도에 도달하는 파워 유저를 위한 고가 등급으로, 사용량 여유가 대폭 증가합니다. 이는 Anthropic에서 가장 가시적인 부분이지만, 고객의 대부분이 다른 기업인 회사에게는 API 및 엔터프라이즈 라인보다 작은 비중입니다. 그 전략적 가치는 수익원만큼이나 퍼널과 브랜드 접점으로서의 역할에 있습니다. ### 3. 엔터프라이즈(Team 및 Enterprise 시트) 지속적인 수익의 상당 부분이 여기 있습니다. 기업들은 조직을 위해 설계된 플랜으로 직원들을 위해 **시트당** Claude를 구매합니다: - **Team** — 중소기업용: 공유 사용량, 중앙 집중식 청구, 협업 기능. - **Enterprise** — 대형 조직용: 더 높은 보안 및 규정 준수, 싱글 사인온, 더 큰 컨텍스트 창, 관리자 제어, 사용량 보장. 엔터프라이즈 계약은 재귀적이고 시간이 지남에 따라 확장되며(더 많은 시트, 더 많은 사용량), 수익을 안정적으로 만드는 전환 비용이 따릅니다. 이는 모델 위에 얹힌 전형적인 SaaS 움직임입니다. ### 4. Claude Code(개발자 도구) **Claude Code**는 Anthropic의 에이전틱 코딩 도구로 — 터미널, IDE 또는 클라우드에서 코드를 작성, 편집, 실행하는 에이전트입니다. 동일한 구독 및 사용량 레일을 통해 수익화됩니다(Pro/Max/Team/Enterprise 등급에 포함되어 플랜에 카운트됩니다). 전략적으로 두 가지 역할을 합니다: 독자적인 수익 라인이자, 코딩 에이전트가 대량의 모델 용량을 소비하기 때문에 높은 가치의 토큰 사용을 대량으로 유도합니다. ### 5. 클라우드 마켓플레이스 배포(AWS, Google 등) Anthropic은 Claude를 직접 판매하는 것에 그치지 않고 주요 클라우드 플랫폼을 통해 배포합니다: - **Amazon Bedrock**과 **Claude Platform on AWS** — 이미 AWS를 사용하는 고객들이 Amazon의 인프라 및 청구 시스템을 통해 Claude에 접근합니다. - **Google Vertex AI**와 **Microsoft Foundry** — Google Cloud와 Microsoft 플랫폼에서도 동일한 개념. 이 채널들은 기업이 이미 클라우드 지출과 조달이 이루어지는 곳에서 그들을 만나, Claude 도입의 마찰을 줄입니다. 수익은 플랫폼과 공유되지만 도달 범위는 엄청나며 — Amazon과 Google의 깊은 투자는 이 파트너십을 단순한 상업적 관계가 아닌 전략적 관계로 만듭니다. ### 6. 부상하는 에이전트 플랫폼 점점 더 Anthropic은 단순한 모델 호출이 아니라 **에이전트 인프라**를 판매합니다 — Anthropic이 에이전트 루프를 실행하고 에이전트가 작업을 수행하는 환경을 호스팅하는 관리형 서비스입니다. 더 많은 고객이 "모델에게 질문하기"에서 "에이전트에게 일을 시키기"로 전환할수록, 이 상위 레이어는 토큰당 핵심 위에서 가치를 포착하는 새로운 장소가 됩니다. ## Anthropic은 흑자인가요? Anthropic은 비공개 기업으로 감사된 재무제표를 공개하지 않지만, 공개된 그림은 동종 업계와 동일합니다: **수익이 매우 빠르게 성장하는** 동시에, 회사는 컴퓨팅(모델 훈련 및 서빙)과 연구 인재에 엄청난 금액을 지출하고 있습니다. 다른 프론티어 AI 랩들처럼, 현재의 수익이 아닌 매출 성장이 헤드라인인 대규모 투자 단계에 있습니다. 투자자들이 하는 베팅은 AI가 더 많은 소프트웨어에 엮이면서 사용량 기반 수익이 계속 복리 성장하여 결국 컴퓨팅 비용을 앞지를 것이라는 것입니다. ## OpenAI와의 비교 형태는 비슷합니다 — 두 회사 모두 소비자 구독, 사용량 기반 API, 엔터프라이즈 시트, 개발자 도구를 통해 수익화합니다. 차이점은 강조점과 파트너십에 있습니다: Anthropic은 개발자/엔터프라이즈 API에 강하게 베팅하며 Amazon과 Google의 지원을 받고 있고; OpenAI는 더 큰 소비자 기반과 깊은 Microsoft 파트너십을 갖고 있습니다. 비교의 반대편을 보고 싶다면 [OpenAI가 어떻게 돈을 버는지](https://alejandrorioja.com/how-does-openai-make-money/)를 확인하세요. ## Anthropic 수익 모델 — 2026년 FAQ ### Anthropic의 주요 수익원은 무엇인가요? **사용량 기반 API**와 **엔터프라이즈 계약**이 가장 큰 동력입니다. 개발자와 기업은 Claude를 호출하기 위해 토큰당 비용을 내고, 조직들은 팀을 위한 시트당 플랜을 구매합니다. 소비자 Claude 구독은 가장 가시적인 제품이지만 비즈니스 라인보다 수익에서 차지하는 비중이 작습니다. ### Claude API 요금은 어떻게 작동하나요? 토큰당 요금을 냅니다 — 입력과 출력을 텍스트 청크 단위로 측정합니다. 더 강력한 모델(Opus)은 균형형(Sonnet)이나 고속형(Haiku) 모델보다 토큰당 비용이 높으며, 출력 토큰은 입력 토큰보다 비쌉니다. 긴 컨텍스트, 프롬프트 캐싱, 배치 처리 같은 기능은 별도의 요금이 있습니다. 수익은 고객이 모델을 얼마나 사용하느냐에 직접 비례해 증가합니다. ### Anthropic은 상장 기업인가요? 아니요. Anthropic은 Amazon과 Google을 포함한 전략적 및 벤처 투자자들이 지원하는 비공개 기업입니다. 주식은 공개 증권 거래소에서 거래되지 않으며, 확정된 IPO 계획도 없습니다. ### Anthropic은 무료 Claude 앱으로 돈을 버나요? 무료 사용자에게서 직접 수익을 얻지는 않습니다 — 무료 등급은 퍼널입니다. 무료 사용자가 **Pro** 또는 **Max**로 업그레이드할 때, 팀이 **엔터프라이즈 시트**를 구매할 때, 특히 개발자들이 **API**를 기반으로 개발할 때 수익이 발생합니다. 무료 앱의 역할은 도달 범위와 브랜드이며; 유료 등급과 API가 전환이 일어나는 곳입니다. ### Anthropic의 최대 고객은 누구인가요? 주로 다른 기업들입니다: API를 통해 자사 제품에 Claude를 내장하는 소프트웨어 회사들, 그리고 직원들에게 Claude를 배포하는 기업들. AWS, Google, Microsoft를 통한 클라우드 마켓플레이스 배포도 기존 클라우드 공급자를 통해 구매하는 대형 엔터프라이즈 고객을 끌어옵니다. **관련 읽기:** [OpenAI는 어떻게 돈을 버나요](https://alejandrorioja.com/how-does-openai-make-money/) · [AI 에이전트 초보자 가이드](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [ChatGPT 답변에서 인용되는 방법](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## 짧은 버전 Anthropic은 Claude 모델에 대한 접근권을 임대합니다. 개발자들은 API를 통해 토큰당 요금을 내고, 소비자들은 Pro와 Max를 위해 매달 요금을 내고, 기업들은 Team과 Enterprise를 위해 시트당 요금을 내고, 엔지니어들은 동일한 플랜에서 Claude Code를 사용하며, 클라우드 거인들(AWS, Google, Microsoft)은 마켓플레이스를 통해 기업에 Claude를 재판매합니다. 소비자 접점을 가진 B2B 비즈니스입니다 — 그리고 채팅 앱이 아닌 미터가 돈이 있는 곳입니다. --- ## OpenAI는 어떻게 돈을 버나요? ChatGPT와 API 비즈니스 모델 Source: https://alejandrorioja.com/ko/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI는 네 가지 주요 방식으로 수익을 창출합니다: ChatGPT 구독(Plus, Pro, Team, Enterprise, Edu), 개발자가 토큰당 비용을 지불하는 사용량 기반 API, 대규모 기업 계약, 그리고 Microsoft 파트너십(유통 및 수익 공유 계약). 대부분의 AI 연구소와 달리, OpenAI의 소비자 구독 사업이 가장 큰 단일 수익원이며, ChatGPT의 규모가 바로 그 엔진입니다. ## Table of contents _2026년 6월 업데이트._ **TL;DR:** OpenAI는 네 가지 주요 방식으로 수익을 창출합니다: **ChatGPT 구독**(Plus, Pro, Team, Enterprise, Edu), 개발자가 토큰당 비용을 지불하는 **사용량 기반 API**, 대규모 **기업 계약**, 그리고 **Microsoft 파트너십**(유통 및 수익 공유 계약). 대부분의 AI 연구소와 달리, OpenAI의 소비자 구독 사업이 가장 큰 단일 수익원이며, ChatGPT의 방대한 규모가 바로 그 엔진입니다. **[운영자 시각]** OpenAI는 전형적인 기업용 AI 회사의 반대입니다: 먼저 소비자 현상을 만들고, 그다음에 개발자/기업 비즈니스를 구축했습니다. 수억 명의 ChatGPT 사용자는 브랜드이자 현금 창출 기계입니다. 이 공간의 다른 모든 경쟁자들은 이런 수준의 상단 퍼널을 갖기를 원합니다. ## OpenAI란 무엇인가? OpenAI는 **ChatGPT**와 **GPT** 모델 패밀리, 그리고 Sora 비디오 모델, 이미지 생성, Codex 코딩 에이전트 같은 제품을 만든 AI 연구 회사입니다. 2015년에 설립되어 2022년 말 ChatGPT가 출시되면서 역사상 가장 빠르게 성장한 소비자 제품 중 하나가 되며 주류 인지도를 획득했습니다. 구조가 독특합니다: 비영리 단체로 시작해 프론티어 모델 훈련에 필요한 막대한 자본을 조달하기 위해 이익 상한이 있는 영리 부문을 만들었습니다. 상장되지 않았으며, 컴퓨팅 인프라, 유통, 자본을 제공하는 **Microsoft**와 깊고 다년간의 파트너십을 맺고 있습니다. 제품은 모든 AI 연구소와 마찬가지로 서비스로서의 지능(Intelligence-as-a-Service)이며, 소비자, 개발자, 기업 채널을 통해 판매됩니다. ## OpenAI는 어떻게 돈을 버나요? ### 1. ChatGPT 구독 (가장 큰 수익원) 이것이 OpenAI를 경쟁사와 차별화하는 요소입니다. ChatGPT는 무료로 사용할 수 있으며, 유료 티어가 방대한 사용자 기반의 일부를 반복 수익으로 전환합니다: - **ChatGPT Plus** — 최고의 모델 접근, 더 높은 한도, 프리미엄 기능을 위한 정액 월정액. 대중 시장 티어. - **ChatGPT Pro** — 최대 사용량과 가장 강력한 모델 설정을 원하는 파워유저를 위한 고가 티어. - **ChatGPT Team** — 공유 워크스페이스와 관리 도구를 갖춘 소규모 기업을 위한 좌석당 플랜. - **ChatGPT Enterprise** — 대규모 조직을 위한: 고급 보안, 컴플라이언스, SSO, 더 큰 컨텍스트, 사용량 보장. - **ChatGPT Edu** — 대학 및 학교에 맞춤화된 버전. ChatGPT가 주간 수억 명의 사용자에게 도달하기 때문에, 유료 플랜으로의 전환율이 한 자릿수 낮은 비율이어도 거대한 구독 사업이 만들어집니다. 이 소비자 규모가 OpenAI의 결정적인 강점이며, 구독이 가장 큰 수익원이라는 보도가 있습니다. ### 2. API (사용량 기반, 개발자용) 개발자와 기업들은 OpenAI의 모델을 자신의 제품에 통합하고 처리되는 텍스트(또는 이미지, 오디오) 청크당 즉 **토큰당** 비용을 지불합니다. 가격은 모델 능력에 따라 달라집니다: 플래그십 추론 모델은 작고 빠르고 저렴한 모델보다 토큰당 비용이 더 높으며, 출력은 입력보다 높은 가격이 책정됩니다. API는 GPT 위에 구축하는 모든 회사를 사용량이 늘어날수록 청구액이 증가하는 계측 고객으로 만듭니다. 이것은 모든 AI 연구소가 의존하는 동일한 복리 역학입니다: OpenAI를 통합하고 수백만 사용자로 성장한 스타트업은 새로운 계약 없이도 매달 더 많은 API 수익을 창출합니다. ### 3. 기업 계약 셀프서비스 API와 Team 플랜 외에도, OpenAI는 대기업과 대규모 맞춤형 거래를 체결합니다 — 대량 사용, 전용 용량, 맞춤형 지원, 보안/컴플라이언스 약속. 이러한 계약은 반복적이고, 시간이 지남에 따라 확장되며, 회사가 모델 위에 중요한 워크플로우를 구축하면 교체하기 어려워집니다. 이 기업 모션은 소비자 사업과 함께 주요 성장 영역입니다. ### 4. Microsoft 파트너십 Microsoft는 OpenAI의 가장 큰 전략적 파트너입니다. 관계는 여러 축에서 작동합니다: - **컴퓨팅** — Microsoft의 Azure 클라우드는 OpenAI가 모델을 훈련하고 제공하는 인프라의 많은 부분을 제공합니다. - **유통** — OpenAI의 모델은 Microsoft의 플랫폼(Azure AI 서비스, Copilot 제품)을 통해 제공되어 Microsoft의 거대한 기업 고객 기반 앞에 GPT를 놓습니다. - **수익 공유** — 두 회사는 상업적 계약에 따라 수익을 공유하며, Microsoft는 OpenAI에 막대한 투자를 해왔습니다. 이 파트너십은 부분적으로 자본이고, 부분적으로 GTM(시장 진입)입니다: OpenAI가 직접 판매하려면 수년이 걸릴 기업들에 대한 접근성을 제공합니다. ### 5. 신규 및 인접 제품 OpenAI는 수익화할 수 있는 영역을 계속 확장하고 있습니다: - **Codex** — 에이전틱 코딩 도구로, 구독과 API 사용을 통해 수익화됩니다(그리고 대량 토큰 소비의 동인). - **Sora** — 비디오 생성으로, 유료 티어 내에서 그리고 독립 제품으로 제공됩니다. - **이미지 생성 및 기타 모달리티** — 구독에 번들로 포함되고 API를 통해 계측됩니다. - **개발자/에이전트 에코시스템** — 맞춤형 GPT, 에이전트 플랫폼, 기업이 OpenAI의 모델 위에 구축할 수 있는 도구들. 이 각각은 동일한 핵심 자산의 또 다른 래퍼로, 사용자와 개발자가 기꺼이 지불하고자 하는 것을 더 많이 포착하는 것을 목표로 합니다. ## OpenAI는 수익을 내고 있나요? OpenAI는 비공개 기업이며 감사된 재무제표를 공개하지 않습니다. 널리 알려진 그림: **수익은 매우 크고 빠르게 성장하고 있지만**, 비용도 마찬가지입니다 — 프론티어 모델을 훈련하고 수억 명의 사용자에게 서비스를 제공하는 데는 엄청난 양의 컴퓨팅이 소비됩니다. 경쟁사들과 마찬가지로 OpenAI는 우선순위가 단기 수익이 아닌 성장과 역량인 대규모 투자 단계에 있습니다. 베팅은 규모와 기업 채택 증가가 결국 컴퓨팅 비용을 앞지른다는 것입니다. ## Anthropic과의 비교 빌딩 블록은 비슷합니다 — 소비자 구독, 사용량 기반 API, 기업 거래, 코딩 도구 — 하지만 강조점이 다릅니다. OpenAI의 결정적인 우위는 **소비자 규모**(ChatGPT)와 **Microsoft** 파트너십이고, Anthropic은 **개발자/기업 API**에 더 집중하며 Amazon과 Google의 지원을 받습니다. 비교의 다른 면은 [Anthropic이 어떻게 돈을 버는지](https://alejandrorioja.com/how-does-anthropic-make-money/)에서 확인하세요. ## OpenAI 수익 모델 — 2026 FAQ ### OpenAI의 가장 큰 수익원은 무엇인가요? **ChatGPT 구독.** ChatGPT가 수억 명의 사용자에게 도달하기 때문에, 유료 티어(Plus, Pro, Team, Enterprise, Edu)가 OpenAI의 가장 큰 단일 수익 라인을 구성합니다 — 소비자보다 API와 기업에서 더 많이 버는 대부분의 AI 연구소와 다른 이례적인 프로필입니다. ### OpenAI의 API는 어떻게 돈을 버나요? 개발자들은 자신의 앱에서 OpenAI의 모델을 사용하기 위해 **토큰당** 비용을 지불합니다 — 처리되는 텍스트, 이미지 또는 오디오 청크당. 더 유능한 모델은 토큰당 더 많은 비용이 들고, 출력은 입력보다 높은 가격이 책정됩니다. 고객 자신의 사용량이 증가함에 따라 수익이 자동으로 성장합니다. ### OpenAI는 상장되어 있나요? OpenAI 주식을 살 수 있나요? 아니요. OpenAI는 비공개 기업이며 주식은 공개 거래소에서 구매할 수 없습니다. 대부분의 사람들은 직접 투자할 수 없습니다. Microsoft는 파트너십을 통해 큰 지분을 보유하고 있지만, 그것이 OpenAI가 상장되었다는 것과 같지 않습니다. ### Microsoft 파트너십은 OpenAI에 어떻게 돈을 가져다 주나요? Microsoft는 Azure 컴퓨팅을 제공하고, 자사 제품과 클라우드를 통해 방대한 기업 고객 기반에 OpenAI의 모델을 유통하며, 두 회사는 상업적 계약 하에 수익을 공유합니다. Microsoft는 또한 OpenAI에 막대한 투자를 해왔습니다. 자금 조달원이자 유통 채널 두 가지 역할을 합니다. ### OpenAI는 ChatGPT 무료 사용자로부터 돈을 버나요? 직접적으로는 아닙니다 — 무료 티어는 퍼널입니다. 수익은 무료 사용자가 **Plus** 또는 **Pro**로 업그레이드할 때, 기업이 **Team** 또는 **Enterprise** 좌석을 구매할 때, 개발자가 **API** 위에 구축할 때 발생합니다. 무료 제품의 역할은 도달 범위이며, 유료 티어와 API가 그것을 전환합니다. **관련 읽을거리:** [Anthropic은 어떻게 돈을 버나요](https://alejandrorioja.com/how-does-anthropic-make-money/) · [SpaceX는 어떻게 돈을 버나요](https://alejandrorioja.com/how-does-spacex-make-money/) · [AI 에이전트 초보자 가이드](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## 짧은 버전 OpenAI는 ChatGPT의 방대한 사용자 기반을 구독 수익(Plus, Pro, Team, Enterprise)으로 전환하고, API를 통해 개발자에게 토큰당 요금을 청구하며, 대규모 기업 계약을 체결하고, 컴퓨팅, 유통 및 공유 수익을 위해 Microsoft에 의존합니다. 이의 결정적인 특성은 소비자 규모입니다 — 대부분의 AI 연구소는 먼저 개발자에게 수익을 창출하지만, OpenAI는 소비자 현상을 먼저 만들고 그 뒤에 비즈니스를 구축했습니다. --- ## SpaceX는 어떻게 돈을 버는가? 발사 서비스, Starlink, 그리고 IPO 문제 Source: https://alejandrorioja.com/ko/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX는 세 가지 방법으로 돈을 법니다: 발사 서비스(재사용 Falcon 로켓으로 궤도 탑승권 판매), Starlink(소비자·기업·해상/항공·정부 대상 위성 인터넷), 정부 계약(NASA 유인·화물 수송, 달 착륙 시스템, 국가 안보 발사). Starlink가 현재 가장 큰 수익원입니다. SpaceX는 비공개 기업으로 유지되며 SpaceX 자체의 IPO는 임박하지 않았지만 Starlink의 미래 분사 상장은 오래전부터 거론되어 왔습니다. ## Table of contents _2026년 6월 업데이트._ **TL;DR:** SpaceX는 세 가지 방법으로 돈을 법니다: **발사 서비스**(재사용 Falcon 로켓으로 궤도 탑승권 판매), **Starlink**(소비자·기업·해상/항공·정부 대상 위성 인터넷), **정부 계약**(NASA 유인·화물 수송, 달 착륙 시스템, 국가 안보 발사). Starlink가 현재 가장 큰 수익원입니다. SpaceX는 비공개 기업으로 유지되며 SpaceX 자체의 IPO는 임박하지 않았지만 Starlink의 미래 분사 상장은 오래전부터 거론되었다가 반복적으로 부정되어 왔습니다. **[운영자의 해석]** SpaceX는 하드웨어 기술 해자(재사용 로켓)를 활용해 소프트웨어 경제 구조의 사업(위성 인터넷)을 그 위에 구축한 가장 명확한 현대적 사례입니다. 발사 사업은 존재할 권리를 획득하는 것이고, Starlink는 반복적이고 확장 가능한 수익이 실현되는 곳입니다. 이것이 한 문장으로 압축한 전체 이야기입니다. ## SpaceX란 무엇인가 SpaceX(스페이스 익스플로레이션 테크놀로지스)는 로켓과 우주선을 설계·제작·운용하며, Starlink 위성 인터넷 네트워크를 운영합니다. 2002년 인류를 다행성 종으로 만들겠다는 장기 목표로 설립되어, 아무도 규모 있게 해내지 못했던 일——궤도 로켓의 1단 부스터 착륙 및 재사용——을 실현함으로써 우주 접근 비용을 대폭 낮추며 세계 최대 발사 서비스 공급자가 되었습니다. 이 비용 우위가 모든 것의 원동력입니다. 저렴하고 빈번하며 신뢰할 수 있는 발사가 7,000개 이상의 위성 군집을 경제적으로 가능하게 만들며, 이 군집이 불규칙한 프로젝트 기반의 발사 사업을 반복 수익 사업으로 전환시킵니다. ## SpaceX는 어떻게 돈을 버는가? ### 1. 발사 서비스 최초의 사업입니다. SpaceX는 세 종류의 고객에게 발사를 판매합니다: - **상업 위성 운영업체** — 궤도에 탑재체를 올려야 하는 기업은 전용 발사 비용을 지불하거나 **라이드쉐어** 미션(한 로켓에 소형 위성 다수 탑재, 킬로그램당 요금)의 슬롯을 구매합니다. - **정부 및 군** — 국가 안보 탑재체와 과학 임무로, 신뢰성과 보증에 대한 프리미엄이 붙는 경우가 많습니다. - **다른 우주 기업** — 가장 저렴하고 이용 가능한 탑승 수단인 SpaceX에 여전히 의존하는 경쟁사들도 점점 포함됩니다. 단위 경제가 작동하는 것은 **재사용성** 덕분입니다. 동일한 1단 부스터가 여러 번 비행하므로 발사 한 번의 한계 비용이 가격을 훨씬 밑돕니다. Falcon 9이 주력 기종이고 Falcon Heavy가 가장 무거운 탑재체를 담당합니다. ### 2. Starlink (반복 수익 머신) Starlink는 지상 브로드밴드가 닿지 않거나 서비스되지 않는 곳에 고속 인터넷을 제공하는 수천 개의 저지구 궤도 위성 군집입니다. 이제 SpaceX에서 진정한 구독 사업처럼 보이는 부문으로 여러 레이어로 구성됩니다: - **소비자** — 가정은 디쉬(하드웨어)와 월간 구독료를 납부합니다. - **기업 및 모빌리티** — 기업, 해사(선박, 요트), **항공**(항공사와의 기내 Wi-Fi 계약) 대상의 고가 요금제. - **정부** — 군사 및 정부 고객에게 판매되는 방위 중심 변형인 **Starshield** 포함. - **다이렉트 투 셀** — 음영 지역의 일반 휴대폰에 직접 위성 연결을 제공하기 위한 이동통신사와의 파트너십. Starlink는 수백만 가입자를 대상으로 하드웨어 판매(단말기)와 월간 반복 수익(구독)을 결합합니다——행성 규모의 고전적인 '면도기와 면도날' 구조입니다. 그래서 대부분의 추정치는 현재 Starlink를 발사 서비스를 앞서는 SpaceX 최대 수익원으로 평가합니다. ### 3. 정부 계약 발사와 중복되지만 별도로 살펴볼 가치가 있는, 독립적이고 매우 큰 부문입니다: - **NASA** — SpaceX는 **Commercial Crew** 프로그램(Crew Dragon)으로 우주비행사를 국제우주정거장에 수송하고 **Cargo Dragon**으로 보급합니다. NASA의 달 탐사 계획을 위한 **Starship** 기반 유인 달 착륙 시스템 제작 계약도 수주했습니다. - **국가 안보** — 방위 및 정보 탑재체를 위한 정기 발사 계약. 이 계약들은 고가치·다년간 계약으로, 상업 부문에 도움이 되는 많은 개발 비용을 충당합니다. ### 4. Starship (미래의 엔진, 아직 수익 중심은 아님) Starship은 SpaceX의 완전 재사용 초대형 발사체로, Falcon의 장기적 대체제이자 달/화성 임무와 차세대 대형 Starlink 위성 모두의 열쇠입니다. 현재는 다른 세 사업으로 자금을 조달하는 비용 센터입니다. 정기 비행에 도달하면 발사 비용을 다시 대폭 낮추고 훨씬 더 큰 규모의 Starlink 배치를 가능하게 합니다——이것이 투자자들이 실제로 베팅하는 시나리오입니다. ## SpaceX는 수익성이 있는가? SpaceX는 비공개 기업으로 감사받은 재무제표를 공개하지 않아 정확한 수치는 모두 추정치입니다. 널리 알려진 그림: 재사용성 덕분에 발사는 임무 단위에서 수익성이 있고, 가입자 기반 확대와 함께 Starlink는 현금 흐름 흑자 구간에 진입했습니다. 회사는 Starship 개발에 막대한 자금을 재투자하므로 '이익'은 이 R&D를 어떻게 처리하느냐에 크게 달려 있습니다. 발전 방향——지배적 발사 사업 위에 성장하는 Starlink 반복 수익——이 회사의 막대한 사기업 평가액을 지지하고 있습니다. ## IPO 문제 모두가 묻는 부분이므로 솔직한 버전을 소개합니다. **SpaceX가 곧 IPO할 것으로 예상되지 않습니다.** Elon Musk는 Starship과 화성 프로그램이 자본 집약적이고 장기적인 시야를 요구하는 동안에는 SpaceX를 비공개로 유지하는 것을 선호한다고 반복적으로 밝혔습니다——공개 시장의 분기별 압박은 수십 년 단위의 임무에 맞지 않습니다. 대신 SpaceX는 정기적인 **텐더 오퍼**(회사가 정해진 가격에 주식 매도를 중개)를 통해 직원과 초기 투자자에게 유동성을 제공해, 공개 상장 없이도 현금화할 수 있게 합니다. 이러한 2차 매도가 헤드라인 평가 수치를 만들어내며——SpaceX는 최근 라운드에서 수천억 달러로 평가받았습니다. **Starlink 분사 IPO는 오래전부터 거론됩니다**——Musk 자신이 수년 전 Starlink 수익이 안정적이고 예측 가능해지면 상장을 검토할 수 있다고 암시했습니다. 하지만 단기 타임라인에 대해서는 반복적으로 부정해 왔습니다. 2026년 기준 Starlink는 IPO하지 않았으며 확정된 날짜도 없습니다. 회사 측에서 직접 발표한 것이 아닌 한 어떤 'Starlink IPO 날짜' 헤드라인도 의심하며 대하세요. ## 결론 SpaceX의 모델은 스택입니다: 재사용 발사가 비용 해자를 만들고, 그 해자가 Starlink를 경제적으로 가능하게 하며, Starlink가 전체를 반복 수익 사업으로 전환하고, 정부 계약이 비용 곡선을 다시 재설정하는 최전선 작업(Starship)에 자금을 공급합니다. 회사는 의도적으로 비공개를 유지하며 IPO 대신 텐더 오퍼를 활용합니다——공개 시장으로 가는 가장 가능성 높은 경로는 SpaceX 전체가 아닌 미래의 Starlink 단독 상장이며, 시기는 회사가 적절하다고 판단할 때입니다. ## SpaceX 수익 모델 — 2026년 FAQ ### SpaceX의 가장 큰 수익원은 무엇인가요? 대부분의 추정치는 이제 **Starlink**를 발사 서비스를 앞서는 SpaceX 최대 수익원으로 평가하며, 수백만 건의 소비자·기업·모빌리티·정부 구독과 단말 하드웨어 판매가 그 원동력입니다. 발사 서비스도 여전히 규모가 크고 임무당 수익성이 높지만, Starlink의 반복 모델이 더 빠르게 확장됩니다. ### SpaceX는 주식 시장에 상장되어 있나요? SpaceX 주식을 살 수 있나요? 아닙니다. SpaceX는 비공개 기업이며 주식은 공개 증권거래소에서 구매할 수 없습니다. 대부분의 사람은 직접 투자할 수 없으며, 접근은 일반적으로 사모 라운드나 텐더 오퍼에 참여하는 직원과 적격 투자자로 제한됩니다. 그렇지 않다고 암시하는 'SpaceX 주식' 제안에 주의하세요. ### SpaceX나 Starlink가 IPO를 할 예정인가요? SpaceX가 단기적으로 상장할 것으로 예상되지 않습니다——Musk는 Starship/화성 자본 집약적 단계에서 비공개를 유지하고 싶다고 밝혔습니다. **Starlink** IPO는 수익이 예측 가능해지면 가능성이 있는 것으로 수년간 논의되어 왔지만 2026년 기준 확정된 날짜는 없습니다. 구체적인 'IPO 날짜' 주장은 회사에서 나온 것이 아닌 한 회의적으로 대해야 합니다. ### Starlink는 어떻게 돈을 버나요? Starlink는 고객에게 위성 디쉬(하드웨어)와 월간 구독료를 청구하며, 소비자·기업·해사·항공·정부 등 다양한 등급을 제공합니다——방위 중심의 Starshield와 다이렉트 투 셀 통신사 파트너십 포함. 면도기와 면도날 모델입니다: 하드웨어를 선납, 이후 반복 수익. ### 재사용성은 SpaceX의 이익에 어떻게 도움이 되나요? 동일한 로켓 부스터를 여러 번 착륙·재비행시키면 각 발사의 한계 비용이 청구 가격을 훨씬 밑돌게 됩니다. 이 비용 우위가 SpaceX를 가장 저렴한 발사 공급자로 만들고, 수천 개 위성으로 구성된 Starlink 군집 배치를 경제적으로 실행 가능하게 합니다. **관련 읽을거리:** [Uber는 어떻게 돈을 버는가](https://alejandrorioja.com/how-does-uber-make-money/) · [Shopify의 수익 모델](https://alejandrorioja.com/how-shopify-makes-money/) · [PayPal은 어떻게 돈을 버는가](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## 짧은 버전 SpaceX는 로켓을 재사용해 저렴하게 궤도 탑승권을 판매하고, 그 비용 우위를 활용해 Starlink——지금은 최대 수익원인 위성 인터넷 구독 사업——을 운영하며, 정부 계약은 차세대 Starship에 자금을 공급합니다. 의도적으로 비공개를 유지하며, SpaceX 전체가 아닌 Starlink IPO가 공개 시장으로 가는 최종적으로 가장 가능성 높은 경로입니다. --- ## Claude 예약 작업 사용법: cron으로 반복 작업 자동화하기 Source: https://alejandrorioja.com/ko/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: 예약 작업은 일회성 Claude 프롬프트를 반복 작업으로 바꿔줍니다. cron 방식의 일정에 따라 실행되어 작업을 처리하고 결과를 전달합니다. 개인 반복 프롬프트(아침 다이제스트, 주간 요약)에는 Claude 앱을, 클라우드에서 실행되는 개발자 자동화에는 Claude Code 루틴 또는 Managed Agents 배포를 사용하세요. 매일 또는 매주 수동으로 반복하던 작업을 자동화하는 것이 핵심 이점입니다. ## Table of contents _2026년 6월 업데이트._ **TL;DR:** 예약 작업은 일회성 Claude 프롬프트를 반복 작업으로 바꿔줍니다. cron 방식의 일정에 따라 실행되어 작업을 처리하고 결과를 전달합니다. 개인 반복 프롬프트(아침 다이제스트, 주간 요약)에는 **Claude 앱**을, 클라우드에서 실행되는 개발자 자동화에는 **Claude Code 루틴** 또는 **Managed Agents 배포**를 사용하세요. 매일 또는 매주 수동으로 반복하던 작업을 자동화하는 것이 핵심 이점입니다. **[운영자 참고]** 레버리지가 가장 높은 자동화는 화려하지 않습니다 — 매일 조용히 20분을 잡아먹는 작은 반복 작업들이죠. 예약 작업은 그런 작업들을 한 번 Claude에게 넘기고 다시는 생각하지 않아도 되는 방법입니다. 저는 여러 개를 운영하고 있습니다: 아침 경쟁사 스캔, 야간 PR 상태 확인, 주간 콘텐츠 파이프라인 초안. 어느 것도 설정에 10분 이상 걸리지 않았습니다. ## 예약 작업이란 일반적인 Claude 세션은 동기적입니다: 입력하면 응답하고, 당신이 그 자리에 있습니다. **예약 작업**은 비동기적이고 반복적입니다: 프롬프트(또는 전체 에이전트 워크플로우)와 일정을 정의하면, Claude가 스스로 실행합니다 — 평일 매일 오전 7시, 매주 월요일, 매시간 — 완료되면 결과를 전달합니다. 내부적으로는 LLM을 중심에 둔 cron 작업입니다. API를 연결하는 코드를 작성할 필요 없이, 자연어로 결과를 설명하면 에이전트가 실행될 때마다 스스로 단계를 파악합니다. ## 설정하는 세 가지 장소 단일 버튼이 있는 것이 아닙니다 — 사용자 유형에 맞춘 세 가지 인터페이스가 있습니다. ### 1. Claude 앱 (누구나 사용 가능) 소비자용 Claude 앱은 반복 작업을 지원합니다: 프롬프트와 주기를 저장하면, Claude가 일정에 따라 실행하고 결과를 알림으로 전달합니다. 이것이 코드 없는 경로입니다 — 매일 브리핑, 반복 리서치, "매일 아침 읽지 않은 뉴스레터 요약" 같은 용도에 이상적입니다. 개발자가 아니라면 여기서 시작하세요. ### 2. Claude Code 루틴 (터미널에서 사는 사람들을 위해) **Claude Code**를 사용한다면, 프롬프트나 슬래시 명령어를 cron 주기로 클라우드 에이전트로 실행하도록 예약할 수 있습니다 — "루틴"이라고 합니다. 서버 사이드에서 당신의 저장소나 워크스페이스에서 실행되므로 노트북이 꺼져 있어도 작동합니다. 일반적인 사용 사례: 열린 풀 리퀘스트 모니터링, 야간 lint-및-수정 패스 실행, 매일 아침 검토용 초안 포스트 생성. 일정과 작업을 정의하면 Claude Code가 실행과 실행 기록을 관리합니다. ### 3. Managed Agents 배포 (제품을 만드는 개발자를 위해) Claude API 위에서 개발하는 팀을 위해 **예약 배포**가 있습니다. 반복적인 cron 일정에 따라 에이전트를 실행합니다 — 각 실행마다 자율적으로 작업을 수행하는 세션이 시작됩니다(야간 규정 준수 스캔, 주간 보고서, 시간별 모니터). 실행당 실행 기록을 통해 성공과 실패를 감사할 수 있습니다. 이것이 같은 아이디어의 프로그래밍 방식, 프로덕션 수준 버전입니다. ## 일정을 생각하는 방법 세 가지 모두 같은 멘탈 모델을 사용합니다 — **어떤 작업, 얼마나 자주, 결과를 어떻게 처리할지**: 1. **작업** — 좋은 에이전트 프롬프트를 작성하는 방식으로 작성하세요: 역할, 컨텍스트, 정확한 액션, 제약 조건, 그리고 확인 사항. 예약 작업은 실행 중간에 명확화 질문을 할 수 없으므로, *미리 완전히 지정*되어야 합니다. 이것이 인터랙티브 사용과의 가장 큰 차이점입니다. 2. **주기** — 매일, 매주, 매시간, 평일만, 시간대 기준 특정 시간. 기본 대상이 실제로 변하는 속도에 맞춰 조정하세요. 주간 업데이트 소스에 대한 "매일" 다이제스트는 낭비된 실행입니다. 3. **전달** — 결과가 도달하는 위치(알림, 파일, 메시지, 초안). 출력이 도착하는 순간 유용하도록 미리 결정해두세요. ## 실제로 효과적인 패턴 - **아침 다이제스트.** "평일 매일 오전 7시에, [주제]에 대한 최신 정보를 가져와서 중요한 세 가지를 요약하고 5가지 요점 브리핑을 보내줘." 수동 스캔 20분을 대체합니다. - **주간 보고서.** "매주 월요일에, [지표]를 무엇이 변했고 왜인지를 포함한 한 페이지 요약으로 정리해줘." 반복 잡무를 검토로 전환합니다. - **야간 작업자.** 당신이 자는 동안 길고 잘 지정된 작업을 실행하는 코드 루틴 — 리팩토링, 테스트 스위프, 데이터 정리 — 검토 가능한 결과와 함께 아침을 맞이합니다. - **모니터.** "매시간 [항목]을 확인하고, [조건]이 참인 경우에만 메시지를 보내줘." 최고의 자동화는 대부분 침묵하고 중요할 때만 말합니다. ## 프로덕션 운영에서 얻은 설정 팁 - **프롬프트를 과도하게 상세히 작성하세요.** 실행 중간에 명확화 질문은 불가능합니다. 형식, 소스, 제약 조건, 엣지 케이스 처리 방법을 명시하세요. - **수동 테스트로 시작하세요.** 정확한 프롬프트를 한 번 손으로 실행하세요. 인터랙티브하게 원하는 결과가 나오면 예약하세요. 그렇지 않다면 먼저 프롬프트를 수정하세요 — 나쁜 프롬프트를 예약하면 안정적으로 나쁜 결과만 생성합니다. - **주기를 변화 속도에 맞추세요.** 주간 업데이트되는 것에 시간별 실행을 설정하지 마세요. - **위험도가 높을 때는 출력을 초안으로 유지하세요.** 외부로 나가는 모든 것 — 게시된 포스트, 발송된 이메일 — 에 대해서는 라이브 액션이 아닌 검토를 위한 *초안*을 생성하도록 작업을 설정하세요. 완전 자율적인 "그냥 해줘"는 위험도가 낮고 되돌릴 수 있는 작업에만 예약하세요. - **처음 몇 번의 실행을 주시하세요.** 예약 작업은 점점 벗어납니다 — 소스가 형식을 바꾸고, 피드가 조용해집니다. 초기 실행 기록을 확인한 후 신뢰하세요. ## Claude 예약 작업 — 2026년 FAQ ### Claude 예약 작업이란 무엇인가요? 반복 작업입니다: 프롬프트 또는 에이전트 워크플로우와 cron 방식의 일정을 정의하면, Claude가 자동으로 실행합니다 — 매일, 매주, 매시간 — 키보드 앞에 없어도 결과를 전달합니다. 소비자용 Claude 앱(개인 반복 프롬프트용), Claude Code(클라우드 루틴으로), Claude API(Managed Agents 배포로)에 존재합니다. ### 개발자여야 사용할 수 있나요? 아니요. Claude 앱은 코드 없이 반복 작업을 지원합니다 — 저장된 프롬프트와 주기만 있으면 됩니다. Claude Code 루틴과 Managed Agents 배포는 코드와 제품 워크플로우를 자동화하는 개발자 지향 버전입니다. ### 예약 작업은 일반 Claude 채팅과 어떻게 다른가요? 일반 채팅은 인터랙티브합니다 — 후속 질문에 답하기 위해 당신이 그 자리에 있습니다. 예약 작업은 자율적이고 반복적이므로, 프롬프트는 미리 완전히 지정되어야 합니다. Claude는 실행 중간에 일시 정지하여 질문할 수 없습니다. 일정에 따라 실행되고, 작업을 완료하고, 결과를 전달합니다. ### 처음 시작하기 좋은 예약 작업은 무엇인가요? 아침 다이제스트입니다. "평일 매일 오전 7시에, [관심 주제]에 대한 최신 정보를 다섯 가지 요점으로 요약해줘." 위험도가 낮고, 확인하기 쉬우며, 반복적인 수동 잡무를 즉시 대체합니다 — 더 큰 것을 자동화하기 전에 워크플로우를 익히기에 완벽한 템플릿입니다. ### 예약 작업이 이메일 전송 같은 실제 액션을 수행할 수 있나요? 네, 하지만 신중하게 사용하세요. 되돌릴 수 있는 위험도 낮은 작업에는 실행하게 두세요. 외부를 향하거나 되돌리기 어려운 것에는 자동으로 실행하는 대신 승인할 초안을 생성하도록 설정하세요 — 특히 무인 실행 시에는. 되돌릴 수 있는지 여부가 얼마나 많은 자율성을 부여할지 판단하는 올바른 기준입니다. **관련 읽기:** [AI 에이전트 초보자 가이드](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Anthropic은 어떻게 수익을 창출하나](https://alejandrorioja.com/how-does-anthropic-make-money/) · [ChatGPT 답변에 인용되는 방법](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **반복 작업을 관리하는 예약 에이전트 시스템을 원하시나요?** 그것이 제가 구축하는 것입니다 — [문의하기](https://alejandrorioja.com/contact/). --- ## AI 에이전트 비용 계산: 언제 Haiku가 Sonnet를 이기는가 (그리고 언제 아닌가) Source: https://alejandrorioja.com/ko/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Sonnet 대신 Claude Haiku를 선택하면 호출당 비용을 극적으로 줄일 수 있지만, 작업이 더 낮은 성공률을 감내할 수 있을 때만 그렇습니다. 진짜 지표는 호출당 비용이 아니라 재시도와 사람의 정리 작업까지 포함한 '성공한 결과당 비용'입니다. 나는 기본값이 아니라 작업별로 라우팅합니다. ## 목차 _2026년 6월 업데이트._ **요약:** Sonnet 대신 Claude Haiku를 선택하면 호출당 비용을 한 자릿수만큼 줄일 수 있지만, 작업이 Haiku의 더 낮은 성공률을 감내할 수 있을 때만 그렇습니다. 중요한 지표는 **성공한 결과당 비용** — 호출 비용에 재시도와 사람의 정리 작업을 더한 것 — 이지, 토큰당 표시 가격이 아닙니다. 나는 작업별로 라우팅하며, 판단이 필요한 작업은 Sonnet에 남겨두고 고볼륨 단계의 상당 부분을 Haiku에서 돌립니다. **운영자의 시각:** 나는 100개 이상의 에이전트를 운영하며, 추론은 실제 비용 항목입니다. 하지만 모든 것을 가장 싼 모델에 밀어 넣어 "돈을 아꼈다"고 여긴 뒤, 재시도·에스컬레이션·화난 고객의 형태로 비용을 치르는 팀들을 봐 왔습니다. 비용 계산은 깔때기 전체를 측정할 때만 성립합니다. 가장 싼 모델은 토큰당 단가가 가장 낮은 모델이 아닙니다. 일을 제대로 끝내는 데 드는 총비용이 가장 낮은 모델입니다. 이 둘은 서로 다른 숫자이며, 그 사이의 간극이야말로 대부분의 에이전트 비용 결정이 어긋나는 지점입니다. ## 토큰 경제학을, 솔직하게 말하면 Anthropic은 Claude를 100만 토큰 단위로 과금하며, 입력과 출력을 따로 청구하고, 출력은 입력보다 몇 배 더 비쌉니다. 정확한 수치는 시간이 지나며 바뀌니 Anthropic의 현재 가격을 확인하세요 — 하지만 결정을 좌우하는 것은 **구조**입니다: - **Haiku**는 값싸고 빠른 등급 — 제품군 내에서 단연 가장 낮은 토큰당 비용. - **Sonnet**은 중간 — Haiku보다 뚜렷이 비싸고, Opus보다 뚜렷이 쌉니다. - **Opus**는 가장 어려운 추론을 위한 프리미엄 등급. 여기서 두 가지가 따라옵니다. 첫째, 생성 작업에서는 출력 토큰이 비용을 지배하므로, 장황한 모델은 같은 토큰 단가에서도 더 비쌉니다. 둘째, Haiku와 Sonnet 사이의 토큰당 가격 차이는 고볼륨 단계에서는 청구서에 확실히 드러날 만큼 큽니다. 이것이 Haiku를 택하는 *근거*입니다. 이제 택하지 않는 근거를. ## 정말로 중요한 지표: 성공한 결과당 비용 호출당 비용은 허영의 숫자입니다. 내가 실제로 쓰는 공식은 다음과 같습니다: ``` 성공당_비용 = (호출_비용 × 시도횟수) + 정리_비용 ÷ 성공률 ``` 여기서 `시도횟수`는 재시도를 반영하고, `정리_비용`은 빠져나간 실패를 사람이 바로잡는 데 드는 기대 비용입니다. 이것이 비교에 무슨 일을 하는지 보세요. Haiku가 호출당 Sonnet의 약 10분의 1 비용이라고 합시다. 어떤 작업에서 Haiku가 80%, Sonnet이 98% 성공한다면, 호출당 절감은 막대해 보입니다. 하지만 Haiku의 실패마다 재시도가 한 번씩 발생하고 10건 중 1건은 여전히 실제 돈이 드는 사람이 필요하다면, 정리 항목이 토큰 절감을 집어삼킬 수 있습니다. 저위험·고볼륨 작업에서는 계산이 압도적으로 Haiku에 유리합니다. 실패하면 엉뚱한 고객에게 이메일이 가는 작업에서는, 완전히 뒤집힐 수 있습니다. 이 결정은 모델별 성공률을 측정하지 않고는 내릴 수 없습니다 — 그것이 바로 [평가 하니스](/the-eval-harness-i-use-to-ship-ai-agents/)가 제공하는 것입니다. 같은 평가 세트를 두 모델에 돌리고 같은 잣대로 성공률을 읽으세요. ## Haiku가 결정적으로 이기는 곳 작업이 **좁고, 구조화되어 있고, 검증 가능**할 때 Haiku가 정답입니다: - **분류와 라우팅** — "이 수신 메시지는 예약인가, 불만인가, 스팸인가?" 세 갈래, 검증이 쉬움, 끊임없이 돌아감. 하루 종일 Haiku. - **스키마 기반 추출** — 텍스트에서 날짜·이름·금액을 뽑아 Zod로 검증. 출력이 파싱되면 거의 확실히 옳습니다. - **짧은 리라이트와 서식 지정** — 톤 조정, 좋다고 알려진 입력의 요약, 데이터 정규화. - **1차 필터링** — Haiku가 분류하고, 모호한 경우만 Sonnet으로 에스컬레이션됩니다. 이것이 가장 레버리지가 높은 패턴입니다. 공통된 맥락: Haiku 실수의 비용은 낮고 실수는 싸게 잡힙니다. 검증이 싸고 위험이 낮을 때, 값싼 모델이 이깁니다. ## Sonnet이 제값을 하는 곳 작업이 **개방형이거나, 여러 단계거나, 틀리면 비싸게 먹힐** 때 Sonnet(때로는 Opus)은 그만한 값을 합니다: - **다중 도구 에이전트 루프**에서 잘못된 도구 호출 하나가 연쇄를 일으키는 경우. 높은 추론 신뢰성은 단계를 거쳐 누적됩니다 — [멀티 에이전트 오케스트레이션](/multi-agent-orchestration-patterns-queues-state-handoffs/)에서 다루는 오케스트레이션 패턴은 모델이 흐름을 놓치지 않는 데 기댑니다. - **고객 대면 생성**에서 나쁜 출력이 재시도가 아니라 신뢰를 잃게 하는 경우. - **검증 자체가 어려운 모든 것.** 출력이 옳은지 싸게 판단할 수 없다면, 자주 틀리는 모델을 감당할 여유가 없습니다. 여기서의 실패는 재시도 한 번으로 끝나지 않습니다 — 환불, 이탈하는 고객, 혹은 내 시간이 듭니다. 그에 비하면 토큰당 할증은 반올림 오차입니다. ## 내가 실제로 출시하는 라우팅 규칙 나는 에이전트마다 하나의 모델을 고르지 않습니다. 에이전트 안에서 **작업**별로 라우팅하며, 보통은 값싼 분류기가 어느 하위 모델이 작업을 처리할지 결정합니다: ```typescript function pickModel(task: Task): string { // 저렴, 검증 가능, 고볼륨 → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // 개방형 또는 고객 대면 → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // 기본값은 안전한 선택 } ``` 여기에는 두 가지 원칙이 새겨져 있습니다. **기본값은 안전한 모델로**, 값싼 모델이 아니라 — 비용은 작동하는 기준선에서 *아래로* 최적화하는 것이지, 망가진 상태에서 신뢰성을 *위로* 끌어올리는 것이 아닙니다. 그리고 **도박하지 말고 에스컬레이션하라**: 쉬운 80%는 Haiku에 맡기고 어려운 20%는 Sonnet에 넘기세요. 이 하이브리드는 두 모델 중 하나로만 전부 돌리는 것을 거의 항상 이깁니다. 그 위에 얹을 수 있는 프롬프트 캐싱도 있습니다: 시스템 프롬프트가 크고 재사용된다면, 캐싱은 등급과 무관하게 입력 비용을 상당히 줄이며, 때로는 Sonnet을 충분히 싸게 만들어 Haiku 문제 자체를 무의미하게 합니다. ## 내 스택에서 가져온 실제 예시 고볼륨 수신 트리아지 단계를 봅시다. 수천 번 돌고, 작업은 세 갈래 분류이며, 놓쳐도 항목이 검토 큐에 떨어질 뿐 — 싸게 잡히고 위험이 낮습니다. 교과서적인 Haiku 작업이며, 이를 Sonnet에서 빼내자 중요한 결과에 측정 가능한 타격 없이 그 단계의 비용을 눈에 띄게 줄일 수 있었습니다. 이제 실제 고객 회신을 작성하는 단계를 봅시다. 볼륨은 낮고, 개방형이며, 나쁜 초안이 나가면 신뢰를 잃습니다. 그것은 Sonnet에 남겨둡니다. 같은 에이전트, 두 모델, 위험에 따라 라우팅. 나는 [AI 에이전트가 실제로 작동하는지 어떻게 측정하는가](/how-i-measure-whether-an-ai-agent-is-actually-working/)에서 설명한 방식으로 둘의 실행당 비용과 성공 지표를 지켜봅니다 — 그리고 평가가 "더 싼 모델이 성공률을 유지한다"고 말한 뒤에만 단계를 한 등급 낮춥니다. ## 자주 묻는 질문 ### 실무에서 Claude Haiku는 항상 Sonnet보다 쌉니까? 토큰당으로는, 예 — 큰 차이로. 성공한 결과당으로는, 항상 그렇지는 않습니다. Haiku의 낮은 성공률이 재시도와 사람의 정리 작업을 유발하면, 실수를 잡거나 고치는 데 비용이 드는 작업에서는 총비용이 Sonnet을 넘어설 수 있습니다. ### 주어진 작업에서 Haiku와 Sonnet을 어떻게 결정합니까? 작업을 두 축으로 채점하세요: 출력이 얼마나 검증 가능한지, 그리고 실수가 얼마나 비싼지. 검증이 싸고 저위험·고볼륨인 작업은 Haiku로; 개방형, 고객 대면, 또는 검증이 어려운 작업은 Sonnet으로. 에이전트별이 아니라 작업별로 라우팅하세요. ### 추적해야 할 단 하나의 비용 지표는 무엇입니까? 성공한 결과당 비용 — 호출 비용 곱하기 시도 횟수에 기대 정리 비용을 더하고, 성공률로 나눈 값. 호출당 가격만으로는 재시도와 사람의 시간이 가려지며, 바로 그곳에서 값싼 모델이 조용히 비싸집니다. ### 한 에이전트에서 두 모델을 모두 쓸 수 있습니까? 예, 그리고 대개 그래야 합니다. 가장 강력한 패턴은 값싼 1차 처리(Haiku가 분류 또는 필터링)가 모호한 경우만 Sonnet으로 에스컬레이션하는 것입니다. 이 하이브리드는 보통 단일 등급으로 전부 돌리는 것을 이깁니다. --- ## 프로덕션에서 AI 에이전트를 디버깅하는 방법 (현장 가이드) Source: https://alejandrorioja.com/ko/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 프로덕션 AI 에이전트를 디버깅하는 것은 대부분 어느 레이어가 실패했는지 — 프롬프트, 도구, 모델, 오케스트레이션 — 분리하는 일이다. 나는 모든 단계를 트레이스 ID로 로깅하고, 정확히 같은 입력을 리플레이하며, 이분 탐색한다. 내 에이전트에서는 'AI 버그'의 약 70%가 모델 버그가 아니라 배관 버그로 드러난다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** 프로덕션 AI 에이전트를 디버깅하는 것은 대부분 어느 레이어가 실패했는지 — 프롬프트, 도구 호출, 모델 출력, 오케스트레이션 — 분리하는 일이다. 나는 모든 단계를 트레이스 ID로 로깅하고, 정확히 같은 입력을 리플레이하며, 거기서부터 이분 탐색한다. 내 에이전트에서는 "AI 버그"처럼 보이는 것의 약 70%가 배관으로 드러난다 — 잘못된 형식의 도구 결과, 잘린 입력, 조용히 삼켜진 예외다. **운영자의 시각:** 나는 100개가 넘는 프로덕션 에이전트를 운영한다 — Pickleland의 예약 플로우, 콘텐츠 파이프라인, 받은편지함 분류기다. 그것들은 모든 소프트웨어가 망가지는 방식으로 망가지고, 거기에 몇 가지 새로운 방식이 더해진다. 이것은 내가 가지고 있었으면 했던 현장 가이드다. 토큰의 벽을 응시하지 않고 실패한 레이어를 찾는 방법이다. 에이전트가 프로덕션에서 오작동하면 본능적으로 모델을 탓하게 된다. "Claude가 환각을 일으켰다." 가끔은 사실이다. 대개는 아니다. 모델은 다섯 개나 여섯 개로 된 스택의 한 레이어이며, 버그는 Anthropic이 출시한 레이어보다 당신이 작성한 레이어에 있는 경우가 훨씬 많다. 이 글은 내가 그것을 찾는 체계적인 방법이다. ## 무엇이든 디버깅하기 전에 모든 실행을 추적 가능하게 만들어라 볼 수 없는 것은 디버깅할 수 없다. 가장 큰 레버리지가 되는 일은 — 특정 버그가 나타나기 전에 — 모든 에이전트 실행에 트레이스 ID를 붙이고 그것이 밟는 모든 단계를 로깅하는 것이다. "단계"는 경계를 넘는 모든 것이다. 들어오는 트리거, 각 모델 호출(전체 메시지 배열 포함), 각 도구 호출(인자 포함), 각 도구 결과, 그리고 최종 출력. 그것들을 트레이스 ID로 키를 매긴 구조화된 JSON으로 로깅하라. ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` Cloudflare Workers에서는 이것들을 큐와 테이블로 보내고, 로컬에서는 stdout으로 보낸다. 규칙은 절대적이다. 단계가 로깅되지 않았다면, 디버깅에 관한 한 그것은 일어나지 않은 것이다. 이것은 [내가 사용하는 에이전트 스택](/the-agent-stack-i-use-to-run-30-production-agents-no-python/)에서 설명한 계측을 반영한다 — 트레이스 ID는 다른 모든 것이 매달려 있는 척추다. ## 레이어를 분리하라: 프롬프트, 도구, 모델, 오케스트레이션 트레이스가 있으면 디버깅은 이분 탐색이 된다. 레이어는 네 개이고, 버그는 대부분의 경우 그중 정확히 하나에 산다. ### 1. 입력 레이어 (가장 흔한 범인) 실패한 모델 호출에 들어간 정확히 같은 `messages` 배열을 꺼내라. 재구성이 아니라 — 로그의 문자 그대로의 페이로드다. 그런 다음 낯선 사람이 읽듯이 읽어라. "모델이 지시를 무시했다"는 내 버그의 절반은 실제로 다음과 같다. - 무언가가 잘못 문자열화되어 `"[object Object]"` 로 돌아온 도구 결과. - 컨텍스트 윈도우를 초과해 순진한 슬라이스가 잘라낸 탓에 문장 중간에 잘린 입력. - `undefined` 로 보간되어 조용히 프롬프트를 오염시킨 변수. 입력이 잘못되었다면, 모델은 쓰레기에 대해 완벽하게 제 일을 한 것이다. 배관을 고쳐라. ### 2. 도구 레이어 입력이 깨끗해 보이면, 도구가 에이전트가 성공으로 취급한 오류를 반환했는지 확인하라. 전형적인 예: API가 `{ "error": "rate limited" }` 본문과 함께 `200` 을 반환하고, 당신의 도구 래퍼가 본문을 확인하지 않으며, 에이전트가 오류 메시지에 자신만만하게 행동한다. 도구 결과를 원본 그대로 로깅하고 그 형태를 검증하라. ### 3. 모델 레이어 1과 2를 배제한 뒤에야 나는 모델을 의심한다. 그때조차 "모델 버그"는 대개 "내 프롬프트가 모호하다"를 뜻한다. 실패한 정확히 같은 입력을 가져다 같은 모델과 온도에 대해 일회성 스크립트에 넣고 재현되는지 보라. 재현된다면 해결책은 프롬프트 작업이나 [더 엄격한 eval](/the-eval-harness-i-use-to-ship-ai-agents/)이지, 다급한 모델 교체가 아니다. ### 4. 오케스트레이션 레이어 단일 단계가 격리 상태에서는 괜찮은데 다단계 실행이 실패한다면, 버그는 인계에 있다 — 단계 사이에서 잃어버린 상태, 경쟁 조건, 멱등하지 않은 작업을 재실행한 재시도다. 이것들이 가장 고약하며, 나는 [멀티 에이전트 오케스트레이션 패턴](/multi-agent-orchestration-patterns-queues-state-handoffs/)에서 그 패턴들을 다룬다. ## 비결정성과 싸우지 말고 재현하라 에이전트를 디버깅 불가능하게 느끼게 하는 것은 비결정성이다. 같은 입력이 실행마다 다른 출력을 낸다. 그것은 길들일 수 있다. 첫째, **고정할 수 있는 것을 고정하라.** 디버깅하는 동안 `temperature: 0` 으로 설정하라. Claude를 완전히 결정론적으로 만들지는 않지만, 분산을 크게 좁혀서 진짜 버그를 샘플링 노이즈와 구분할 수 있게 한다. 둘째, **N번 실행하라.** 실패가 20번에 1번 재현된다면, 정확히 같은 입력을 50번 반복하고 모든 출력을 캡처하라. 이제 일화가 아니라 샘플을 갖게 된다. 5%의 확률로 터지는 버그는 진짜 버그다 — 그것을 보려면 양이 필요할 뿐이다. ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # 그런 다음 실패를 센다 grep -c '"status":"fail"' runs.jsonl ``` 셋째, **성공한 실행과 실패한 실행을 비교하라.** 온도를 고정하고 입력이 같다면, 출력의 차이는 당신이 아직 발견하지 못한 입력의 차이를 의미한다 — 프롬프트 안의 타임스탬프, 변하는 도구 결과, 바뀐 검색 문서다. ## 리플레이 하니스를 만들어 프로덕션에서 디버깅하는 것을 멈춰라 라이브 에이전트를 다시 트리거하며 디버깅하는 것은 느리고 위험하다 — 실제 이메일을 보내고, 실제 코트를 예약한다. 대신 트레이스를 캡처해 오프라인에서 리플레이하라. 리플레이 하니스는 로깅된 트레이스를 불러와, 어떤 단계든 그에 대한 정확히 같은 입력을 재구성하고, 그 단계만 모델에 대해 재실행한다. 전체 `messages` 배열을 로깅해 두었으므로 상류 시스템은 전혀 필요 없다. 이것은 프로덕션에서의 10분 왕복을 2초짜리 로컬 루프로 바꾸며, 내 디버깅 워크플로에서 가장 큰 속도 향상이다. 좋은 리플레이 하니스는 또한 **변형하고 재실행**하게 해준다. 시스템 프롬프트의 한 줄을 바꾸고, 같은 50개의 실패 트레이스를 리플레이하여 이제 몇 개가 통과하는지 보라. 이것이 디버깅에서 eval로 가는 다리다 — 실패 트레이스의 코퍼스가 생기면 회귀 스위트의 시작이 손에 들어온다. ## 실제로 고장을 예측하는 지표를 관찰하라 어떤 실패는 결코 예외를 던지지 않는다. 에이전트는 실행되고, 그럴듯한 무언가를 반환하며, 조용히 잘못된 일을 한다. 그것들을 잡으려면 오류율만이 아니라 행동 지표를 관찰하라. - **도구 호출 성공률**(도구별). 여기서의 하락은 종종 눈에 보이는 실패에 앞선다. - **출력 스키마 유효성** — 출력의 몇 %가 기대 구조에 대해 파싱되는가. 나는 모든 출력을 Zod로 검증하고 유효성이 떨어지면 알림을 보낸다. - **루프 길이** — 실행당 평균 단계 수. 갑작스러운 급증은 대개 에이전트가 재시도에 갇혀 있음을 뜻한다. - **실행당 비용** — 폭주하는 루프는 불만으로 나타나기 전에 비용 급증으로 나타난다. (비용이 중요할 때는 [Haiku 대 Sonnet 계산](/ai-agent-cost-math-when-haiku-beats-sonnet)을 알아둘 가치가 있다.) 나는 이것들을 다른 모든 것과 같은 방식으로 추적한다 — [AI 에이전트가 실제로 작동하는지 어떻게 측정하는가](/how-i-measure-whether-an-ai-agent-is-actually-working/)를 보라. 조용한 실패를 잡는 지표는 시끄러운 실패를 잡는 지표 열 개의 가치가 있다. ## 5분 분류 체크리스트 에이전트가 망가지고 시간에 쫓길 때, 나는 이것을 순서대로 실행한다. 1. 실패한 실행의 **트레이스 ID를 확보하라.** 2. 실패한 단계에 대한 **정확히 같은 입력을 읽어라.** 잘 구성되어 있는가? (여기서 약 50%의 경우가 해결된다.) 3. 그 트레이스에서 **도구 결과를 확인하고** 성공으로 위장한 오류를 찾아라. 4. `temperature: 0` 에서 **단계를 오프라인으로 리플레이하라.** 재현되는가? 5. **재현되면,** 프롬프트/모델 문제다 — 고치고 트레이스 코퍼스를 재실행하라. **아니면,** 비결정성이거나 상태/오케스트레이션 버그다 — 50번 반복해 특성을 파악하라. 규율 있는 분리는 매번 영리한 프롬프팅을 이긴다. 모델이 문제인 경우는 드물다. 대개 문제는 그 주변의 시스템이다. ## 자주 묻는 질문 ### 가끔씩만 실패하는 AI 에이전트는 어떻게 디버깅하나요? 로깅된 트레이스에서 정확히 같은 입력을 캡처해 온도 0에서 50번 이상 리플레이하라. 간헐적 실패는 발화율이 낮은 진짜 버그다 — 양이 일화를 비교하고 고칠 수 있는 재현 가능한 샘플로 바꾼다. ### 버그는 보통 모델에 있나요, 아니면 제 코드에 있나요? 내 프로덕션 에이전트에서는 겉보기 "AI 버그"의 약 70%가 배관이다. 잘못된 형식의 도구 결과, 잘린 입력, 삼켜진 예외, 단계 사이에서 잃어버린 상태다. 모델을 의심하기 전에 입력 레이어와 도구 레이어를 배제하라. ### 에이전트를 디버깅하는 데 필요한 최소한의 로깅은 무엇인가요? 모든 실행의 트레이스 ID, 더해서 트리거, 각 모델 호출(전체 메시지 배열), 각 도구 호출과 그 원본 결과, 그리고 최종 출력의 구조화된 로그. 단계가 로깅되지 않으면 그것을 디버깅할 수 없다. ### 라이브 프로덕션에 대고 디버깅하는 것을 어떻게 멈추나요? 로깅된 트레이스를 불러와 캡처한 입력을 사용해 어떤 단일 단계든 오프라인으로 재실행하는 리플레이 하니스를 만들어라. 그것은 느리고 위험한 프로덕션 왕복을 빠른 로컬 루프로 바꾸며 회귀 스위트의 씨앗이 된다. --- ## AI 검색이 실제로 트래픽을 보내고 있는지 측정하는 방법 Source: https://alejandrorioja.com/ko/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: 대부분의 AI 검색 트래픽은 chatgpt.com, perplexity.ai, claude.ai에서 오는 가느다란 리퍼럴의 흐름으로 나타납니다 — 하지만 더 큰 효과는 다크합니다: 사람들은 AI의 답변을 읽고 결코 클릭하지 않습니다. 저는 둘 다 측정하며, 클릭에는 리퍼러를, 영향력에는 브랜드 검색 상승을 사용합니다. ## 목차 _2026년 6월 업데이트._ **요약(TL;DR):** 대부분의 AI 검색 트래픽은 `chatgpt.com`, `perplexity.ai`, `claude.ai`에서 오는 가느다란 리퍼럴의 흐름으로 도착합니다 — 어디를 봐야 할지 알면 세기 쉽습니다. 하지만 더 큰 효과는 **다크**합니다: 사람들은 AI의 답변을 읽고, 당신의 브랜드를 흡수하며, 결코 클릭하지 않습니다. 저는 클릭을 리퍼러 세그먼트로, 영향력을 브랜드 검색 상승, 다이렉트 트래픽 변화, 인용 모니터링으로 추적합니다. 클릭만 세면 AI 검색을 심각하게 과소평가하게 됩니다. **운영자의 시각:** 저는 콘텐츠 엔진을 운영하며 그 분석을 매일 지켜봅니다. "AI 검색이 트래픽을 보내고 있는가?"라는 질문에는 답답한 답이 있습니다: 그렇습니다, 하지만 가치의 대부분은 세션 보고서에 나타나지 않습니다. 여기서 나타나는 부분을 어떻게 측정하고 나타나지 않는 부분을 어떻게 추론하는지 보여드립니다. 모두가 하나의 숫자를 원합니다 — "ChatGPT가 나에게 얼마나 많은 트래픽을 보내고 있는가?". 정직한 답은 AI 검색이 매우 다른 두 가지 효과를 만들어내며, 두 가지 다른 측정이 필요하다는 것입니다. 이를 혼동하면 패닉에 빠지거나(클릭이 미미해 보입니다) 자신을 속이게 됩니다(실제 영향을 놓칩니다). ## 효과 1: 다이렉트 리퍼럴 — 셀 수 있지만, 기대보다 작다 누군가 ChatGPT, Perplexity, 또는 Claude 답변 안의 인용을 클릭하면, 당신의 분석은 리퍼러를 기록합니다. 이는 실제이며 귀속 가능한 세션입니다. GA4나 어떤 분석 도구에서든 AI 엔진을 포착하는 세그먼트를 구축하세요: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` 이를 "AI 검색" 채널로 저장하고 시간에 따라 관찰하세요. 사람들이 걸려 넘어지는 몇 가지 주의사항: - **리퍼러는 새어 나갑니다.** 일부 AI 서피스는 리퍼러를 제거하거나 변형시켜, 진짜 AI 클릭의 일부가 대신 "다이렉트"에 떨어집니다. 당신의 리퍼럴 수는 바닥이지, 진실이 아닙니다. - **답변 노출 수에 비해 볼륨이 낮습니다.** AI 엔진은 페이지에서 질문에 답합니다. 호기심 많은 소수만이 클릭해 들어옵니다. 하루 몇 건의 리퍼럴이 당신이 인용된 것을 본 훨씬 더 많은 사람들에 해당할 수 있습니다. 따라서 리퍼럴 세그먼트는 필요하지만 충분하지 않습니다. AI 검색이 *얼마간*의 트래픽을 보내고 있다고 알려줍니다. 영향력은 심각하게 과소 집계합니다. ## 효과 2: 다크 영향 — 더 크고 보기 어려운 절반 진짜 움직임은 제로 클릭입니다. 누군가 ChatGPT에 질문하고, 당신의 브랜드가 답변에 추천 출처로 나타나며, 결코 클릭하지 않습니다 — 그저 당신을 기억할 뿐입니다. 그것은 나중에 **브랜드 검색**이나 **다이렉트 방문**으로 나타나며, 아무것에도 귀속되지 않습니다. 이는 추천 스니펫의 측정을 답답하게 만들었던 것과 같은 역학이, 증폭된 것입니다. 다크 영향을 직접 측정할 수는 없지만, 삼각측량할 수는 있습니다: 1. **브랜드 검색 볼륨.** Google Search Console에서 당신의 이름/브랜드에 대한 검색을 시간에 따라 추적하세요. AI 엔진에 인용되기 시작하고 대응하는 캠페인 없이 브랜드 노출이 상승하면, 그 상승은 AI 영향의 지문입니다. 2. **다이렉트 트래픽 추세.** 어떤 캠페인도 따라가지 않는 "다이렉트" 세션의 지속적인 상승은 종종 리퍼러가 벗겨진 AI 리퍼럴과 AI 언급 후 당신을 직접 입력하는 사람들을 반영합니다. 3. **기여 전환.** AI 검색 세션이, 비록 드물더라도, 전환되는 여정에서 *첫* 접점으로 나타나는지 보세요. 라스트 클릭으로는 미미한 채널이 퍼스트 터치로는 의미 있을 수 있습니다. 이들 중 어느 것도 깨끗한 숫자가 아닙니다. 함께 보면 다크한 절반이 움직이는지 알려줍니다. ## 클릭이 아니라 인용을 추적하라 이것이 AI 검색에 대해 제가 가장 중요하게 여기는 지표이며, 당신의 분석에는 전혀 없습니다 — **나는 인용되고 있는가, 그리고 어떤 쿼리에 대해?** 비즈니스에 중요한 20-40개의 쿼리 목록을 유지하고 일정에 따라 ChatGPT, Perplexity, Claude에 통과시키세요 — 주간이면 충분합니다. 각 쿼리와 엔진에 대해 기록하세요: 인용되고 있는가, 그리고 어떤 위치에서? 이는 순위 추적의 GEO 버전이며, 선행 지표입니다. 인용은 하류 트래픽과 브랜드 상승*보다 먼저* 움직이므로, 여기서 당신의 [로컬 비즈니스를 위한 GEO 작업](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/)이 효과를 내고 있는지 보입니다. 저는 이 점검을 실행하고 결과를 기록하는 작은 에이전트를 만들었습니다 — 에이전트 스택을 갖추면 사소한 일입니다. 손으로 하고 싶다면, 스프레드시트와 주간 30분 패스로 시작하기에 충분하고, 직접 에이전트를 만들고 싶지 않다면 [mentioned.at](https://mentioned.at) 같은 전용 체커를 사용해도 좋습니다. 방법론은 제 [ChatGPT 대 Google 인용 테스트](/chatgpt-search-vs-google-50-term-test/)를 반영하되, 한 번이 아니라 지속적으로 실행합니다. ## 대시보드 구축하기: 네 개의 숫자, 주간 저는 지표에 빠져 익사하지 않습니다. AI 검색에 대해 네 가지를 지켜보고 주간으로 검토합니다: 1. **AI 리퍼럴 세션** — 리퍼러 세그먼트에서 셀 수 있는 클릭. 절대값이 아니라 추세. 2. **인용 커버리지** — 세 엔진 전체에서 인용되는, 추적 중인 쿼리의 %. 선행 지표. 3. **브랜드 검색 노출** — Search Console에서, 다크 영향의 대리 지표로서. 4. **AI 출처 전환** — 작더라도, AI 세션이 전환 여정을 시작한 적이 있는지. 인용 커버리지는 상승하는데 리퍼럴 세션이 평탄하다면, 그것은 *실패가 아닙니다* — 대개 다크한 절반이 성장하고 있다는 뜻이며 브랜드 검색 숫자가 뒤따라야 합니다. 인용 커버리지가 떨어지고 있다면, 어떤 트래픽 숫자가 움직이기 전에 대응해야 할 조기 경고입니다. 이는 제가 에이전트에 적용하는 것과 같은 "선행 지표를 측정하라" 규율로, [AI 에이전트가 실제로 작동하는지 어떻게 측정하는가](/how-i-measure-whether-an-ai-agent-is-actually-working/)에서 다룹니다. ## 숫자로 무엇을 할 것인가 측정은 당신의 행동을 바꿔야만 유용합니다. 플레이북: - **신경 쓰는 쿼리에 대해 인용 커버리지가 낮은가?** 그것은 콘텐츠 + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/) 문제입니다. 페이지가 존재하지 않거나, 추출용으로 구조화되지 않았거나, 답변에 끌려 들어갈 만큼 권위 있지 않은 것입니다. - **인용되었지만 리퍼럴 트래픽이 없는가?** 예상된 일이고 괜찮습니다 — AI 검색은 클릭 작업이 아니라 브랜드 작업을 하고 있습니다. 클릭을 쫓아 "고치려" 하지 마세요. 인용되는 출처가 되는 데 베팅하세요. - **한 엔진에서는 리퍼럴이 오지만 다른 엔진에서는 오지 않는가?** 엔진은 출처에서 크게 갈립니다(ChatGPT와 Google 사이 약 40% 중복을 측정했습니다). 하나에 인용된다고 다른 것들이 얻어지지 않습니다 — 각 엔진의 커버리지를 별도로 작업하세요. ## 귀속의 정직함에 관한 메모 가지지 않은 정밀도를 주장하려는 충동에 저항하세요. 2026년의 AI 검색 측정은 귀속이 아니라 삼각측량입니다. "ChatGPT가 당신에게 X 달러를 가져다주었다"라는 깨끗한 숫자를 파는 사람은 알 수 있는 것을 과장하고 있습니다. 리퍼러는 새어 나가고 가장 큰 효과는 설계상 제로 클릭이기 때문입니다. 올바른 자세: 셀 수 있는 것을 세고, 셀 수 없는 것은 대리 지표를 지켜보며, 추세로 결정하라. 절대값이 신뢰할 수 없을 때도 추세는 신뢰할 수 있습니다. ## 자주 묻는 질문 ### GA4에서 ChatGPT나 Perplexity로부터의 트래픽을 어떻게 보나요? AI 엔진 도메인 — chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com — 을 세션 소스로 일치시키는 채널/세그먼트를 구축하세요. 이는 클릭스루 리퍼럴을 포착하지만, 일부는 "다이렉트"로 벗겨지므로 그 수를 바닥으로 취급하세요. ### 제 AI 검색 리퍼럴 트래픽이 왜 이렇게 낮나요? AI 검색은 대부분 제로 클릭이기 때문입니다 — 엔진이 페이지에서 답하고 소수만이 클릭해 들어옵니다. 낮은 리퍼럴 수는 종종 훨씬 더 큰 인용 노출과 동시에 나타납니다. 리퍼럴이 놓치는 부분을 보려면 인용과 브랜드 검색 상승을 측정하세요. ### AI 검색을 위한 최고의 선행 지표는? 인용 커버리지입니다: ChatGPT, Perplexity, Claude 전체에서 인용되는, 비즈니스에 중요한 추적 중 쿼리의 비율. 트래픽과 브랜드 상승보다 먼저 움직이므로, GEO 작업이 효과를 내고 있는지 일찍 알려줍니다. ### AI 검색에서 정확한 매출 귀속을 얻을 수 있나요? 아니요, 2026년에는 신뢰할 만하게 얻을 수 없습니다. 리퍼러는 다이렉트로 새어 나가고 영향의 대부분은 설계상 제로 클릭입니다. AI 검색 측정을 삼각측량으로 취급하세요 — 클릭을 세고, 브랜드 검색과 다이렉트 트래픽 대리 지표를 지켜보며, 거짓 정밀의 달러 수치가 아니라 추세로 결정하세요. --- ## 멀티 에이전트 오케스트레이션 패턴: 큐, 상태, 핸드오프 Source: https://alejandrorioja.com/ko/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 신뢰할 수 있는 멀티 에이전트 시스템은 영리한 프롬프트에 달린 게 아니라 지루한 분산 시스템 규율에 달려 있다. 에이전트 사이의 내구성 있는 큐, 모델 밖에 보관하는 상태, 재시도에도 견디는 멱등한 핸드오프. 모델은 워커, 큐는 등뼈다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** 신뢰할 수 있는 멀티 에이전트 시스템은 영리한 프롬프트로 얻는 게 아니라 지루한 분산 시스템 규율로 얻는다. 에이전트 사이에 내구성 있는 **큐**를 두고, **상태를 모델 밖**에 보관하며, 재시도가 이중으로 동작하지 않도록 모든 **핸드오프를 멱등하게** 만들어라. 모델은 워커, 큐는 등뼈다. 이 세 가지를 제대로 잡으면 오케스트레이션은 더 이상 두렵지 않다. **운영자의 시각:** 내 100개가 넘는 에이전트 대부분은 단일 단계다. 그렇지 않은 것들 — 분류한 뒤 보강하고 그다음 행동하는 파이프라인 — 은 "프롬프트 체인"으로 생각하기를 멈추고 "LLM 워커를 가진 작업 큐"로 생각하기 시작했을 때 비로소 신뢰할 수 있게 되었다. 이건 프롬프트 엔지니어링이 아니라 아키텍처다. "멀티 에이전트"는 에이전트들이 서로 대화하는 것처럼 들린다. 실제로 신뢰할 수 있는 버전은 그 반대다. 에이전트는 전혀 직접 통신하지 않는다. 큐에 메시지를 떨어뜨리고 큐에서 작업을 집어 들며, 오케스트레이션은 그들 사이의 배관에 깃든다. 프로덕션에서 버티는 패턴들을 소개한다. ## 패턴 1: 모든 에이전트 사이에 내구성 있는 큐를 두라 첫 본능은 에이전트 A 안에서 에이전트 B를 직접 호출하는 것이다. 그러지 마라. 직접 호출은 둘을 결합한다. B가 느리면 A가 막히고, B가 실패하면 A의 작업이 사라지며, B를 확장하려 해도 A를 건드리지 않고는 할 수 없다. 대신 A는 자기 작업을 끝내고 B를 위해 **메시지를 큐에 넣는다**. B는 별도의 워커로, 자기 속도로 큐를 비운다. ```typescript // 에이전트 A가 끝나고 큐를 통해 핸드오프한다 — B를 직접 호출하지 않음 await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // A의 작업은 완료. B가 독립적으로 이것을 집어 든다. ``` Cloudflare에서는 바로 이 목적으로 Workers Queues를 쓴다 — [내가 사용하는 에이전트 스택](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) 뒤에 있는 것과 같은 프리미티브다. 큐는 네 가지를 공짜로 준다. **버퍼링**(B가 다운돼도 작업을 잃지 않음), **재시도**(실패한 메시지는 재전달됨), **백프레셔**(급증분이 크래시 대신 큐에 쌓임), **디커플링**(A를 건드리지 않고 B를 확장하거나 재배포). 이들 하나하나가 그렇지 않으면 직접 만들고 틀려야 하는 것들이다. ## 패턴 2: 상태는 항상 모델 밖에 보관하라 가장 흔한 멀티 에이전트 버그는 모델이 단계 사이에 무언가를 기억한다고 가정하는 것이다. 기억하지 않는다. 모든 모델 호출은 상태가 없으며, 유일한 기억은 프롬프트에 넣은 것뿐이다. 그러므로 "이 작업이 파이프라인의 어디에 있는가"의 진실의 원천은 대화가 아니라 데이터베이스에 깃들어야 한다. 나는 모든 에이전트가 읽고 갱신하는 단일 작업 레코드를 유지한다. ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` 각 에이전트는 같은 루프를 돈다. 작업 상태를 **읽고**, 자기 일을 하고, 새 상태를 **쓰고**, 다음 단계를 큐에 넣는다. 모델은 결코 상태를 쥐지 않는다 — 관련된 조각을 입력으로 받아 결과를 반환한다. 이것이 시스템을 재시작 가능하게 만든다. 워커가 작업 도중에 죽어도 상태 레코드는 여전히 상황이 어디까지였는지 정확히 말해주고, 재전달된 큐 메시지가 거기서부터 이어받는다. 디버깅도 다루기 쉬워진다. 상태 테이블이 모든 작업의 여정을 질의 가능한 기록으로 남기기 때문이다 — [에이전트가 실제로 작동하는지 어떻게 측정하는가](/how-i-measure-whether-an-ai-agent-is-actually-working/)와 같은 계측 마인드셋이다. ## 패턴 3: 모든 핸드오프를 멱등하게 만들라 큐는 *최소 한 번* 전달을 보장하지, 정확히 한 번이 아니다. 즉 메시지는 두 번 전달될 수 있다 — 네트워크 끊김, 재시도, 재배포. 에이전트의 액션이 멱등하지 않으면 이중 전달은 이중으로 동작한다. 확인 이메일 두 통, 예약 두 건, 결제 두 번. 이것은 가장 고약한 부류의 오케스트레이션 버그이며, 팀들이 프로덕션에서 발견하는 것이다. 해결책은 키를 써서 액션을 멱등하게 만드는 것이다. ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // 이미 이 단계를 지나 처리됨 — 중복 전달이다. 건너뛴다. return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` 단계 검사는 연산을 두 번 실행해도 안전하게 만든다. 두 번째 전달은 작업이 이미 진행됐음을 보고 아무 일도 하지 않는다. 외부 부작용(이메일 발송, 카드 결제)에 대해서는 다운스트림 API에 멱등성 키를 넘겨 *그쪽에서도* 중복을 제거하게 하라. 모든 메시지가 두 번 전달된다고 가정하고 그것이 무해하도록 설계하라 — 결국 그렇게 될 테니까. ## 패턴 4: 오케스트레이터 대 코레오그래피 — 의도적으로 선택하라 흐름을 배선하는 방법은 두 가지이고, 올바른 선택은 복잡도에 달려 있다. **코레오그래피**(내 기본값): 각 에이전트는 다음 단계만 알고 그것을 큐에 넣는다. 흐름은 체인에서 창발한다. 단순하고 탈중앙적이며 확장하기 쉽다 — 큐를 삽입해 단계를 추가한다. 단점은 전체 흐름을 기술하는 단일한 곳이 없어서, 복잡한 파이프라인은 추론하기 어려워질 수 있다는 것이다. **오케스트레이션**(중앙 코디네이터): 하나의 오케스트레이터가 흐름을 소유하고, 각 에이전트를 차례로 호출하며, 결과에 따라 다음을 결정한다. 전체 흐름이 읽기 쉬운 한 곳에 깃들고 분기 로직이 명시적이다. 대가는 그 자체로 내구성이 있어야 하는 중앙 컴포넌트다 — 오케스트레이터 자신의 상태가 외부화되지 않으면(패턴 2) 단일 장애점이 된다. 내 규칙: **분기가 복잡해질 때까지는 코레오그래피, 그다음에는 내구성 있는 오케스트레이터.** 선형 3단계 파이프라인은 코레오그래피다. 조건부 라우팅, 병렬 팬아웃, 조인이 있는 흐름은 크래시 후 재개할 수 있도록 상태가 데이터베이스에 깃든 오케스트레이터를 원한다. ## 패턴 5: 조각을 잃지 않는 팬아웃, 팬인 한 작업이 N개의 병렬 하위 작업을 낳고(레코드 50개 보강, 문서 20개 요약) 계속하기 전에 그 모두를 기다려야 할 때, **조인**이 필요하다. 비결은 작업 상태의 카운터다. 1. 부모가 N개의 자식 메시지를 큐에 넣고 작업 레코드에 `expected: N, completed: 0` 을 쓴다. 2. 각 자식이 자기 일을 하고 `completed` 를 **원자적으로 증가**시킨다. 3. `completed` 를 `expected` 와 같아지게 올린 자식이 다음 단계를 큐에 넣는다. 이 원자적 증가가 핵심이다 — 그것이 없으면 동시에 끝나는 두 자식이 둘 다 자신이 마지막이 아니라고 여겨 조인이 결코 발화하지 않는다. 데이터스토어가 원자적으로 증가시킬 수 있는 카운터, 또는 트랜잭션을 쓰라. 이 패턴은 파이프라인의 비싼 중간부를 병렬화하면서(흔히 Haiku로 저렴하게 처리되는 작업 — [Haiku 대 Sonnet 비용 계산](/ai-agent-cost-math-when-haiku-beats-sonnet) 참조) 끝에서 깔끔한 조인을 유지하게 해준다. ## 내가 생략하는 것 이 중 무엇을 하든 무거운 에이전트 프레임워크는 필요 없다. 큐, 상태 테이블, 멱등성 키는 모든 플랫폼에 이미 있는 프리미티브다. 큐가 공짜로 주는 기능을 얻으려고 정교한 멀티 에이전트 프레임워크에 손을 뻗었다가, 대체한 배관보다 디버깅하기 어려운 블랙박스를 떠안는 팀들을 봐왔다. 지루한 프리미티브부터 시작하라. 프레임워크에 손을 뻗는 것은 그것이 해결하는 구체적인 고통을 느꼈을 때만으로 하라. 요약: 에이전트는 상태 없는 워커, 큐는 내구성 있는 등뼈, 상태는 데이터베이스에 깃들고, 모든 핸드오프는 두 번 실행해도 안전하다. 이것이 게임의 전부다. ## 자주 묻는 질문 ### 에이전트는 서로를 직접 호출해야 할까, 아니면 큐를 거쳐야 할까? 큐를 거쳐야 한다. 직접 호출은 에이전트를 결합한다 — 한쪽의 실패나 느림이 다른 쪽으로 전파되고, 독립적으로 확장하거나 재배포할 수 없다. 내구성 있는 큐는 버퍼링, 재시도, 백프레셔, 디커플링을 공짜로 준다. ### 멀티 에이전트 상태는 어디에 깃들어야 할까? 모델 밖, 데이터베이스 안에, 각 에이전트가 읽고 갱신하는 작업 레코드로. 모델 호출은 상태가 없으므로 파이프라인 진행의 진실의 원천은 외부여야 한다 — 그것이 크래시 후 시스템을 재시작 가능하게 만든다. ### 같은 작업에 대해 에이전트가 두 번 동작하는 것을 어떻게 막을까? 핸드오프를 멱등하게 만들라. 행동하기 전에 작업의 단계를 확인하고 이미 진행됐으면 아무것도 하지 말며, 외부 API에 멱등성 키를 넘겨라. 큐는 최소 한 번 전달하므로 모든 메시지가 두 번 도착할 수 있다고 가정하고 중복이 무해하도록 설계하라. ### 멀티 에이전트 프레임워크가 필요할까? 대개는 아니다. 내구성 있는 큐, 상태 테이블, 멱등성 키면 플랫폼이 이미 제공하는 프리미티브로 대부분의 프로덕션 요구를 충족한다. 프레임워크는 그것이 고유하게 해결하는 구체적인 문제에 부딪혔을 때만 도입하고, 기본값으로 도입하지 마라. --- ## 두려움 없이 AI 에이전트를 배포하기 위해 쓰는 평가 하니스 Source: https://alejandrorioja.com/ko/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 두려움 없이 에이전트를 배포하는 것은 단 한 가지, 평가 하니스에서 나온다. 채점된 테스트 케이스의 고정된 집합을 자동으로 점수화하고(어서션과 LLM 심판), 모든 프롬프트나 모델 변경 전에 실행한다. 점수가 유지되면 배포한다. 테스트 세트는 실제 운영 장애로부터 구축된다. ## 목차 _2026년 6월 업데이트._ **요약:** 운영 중인 에이전트에서 프롬프트를 바꾸거나 모델을 교체하면서도 숨을 죽이지 않아도 되는 이유는 단 한 가지, **평가 하니스**다. 채점된 테스트 케이스의 고정된 집합을 자동으로 점수화한다 — 쓸 수 있는 곳에는 엄격한 어서션을, 쓸 수 없는 곳에는 LLM 심판을 — 그리고 모든 변경 전에 실행한다. 점수가 유지되면 배포한다. 점수가 떨어지면 배포하지 않는다. 테스트 세트는 합성이 아니다. 실제 운영 장애로부터 구축되므로, 모든 버그가 영구적인 회귀 테스트가 된다. **운영자의 해석:** 100개가 넘는 에이전트를 거치면서, 자신 있게 손대는 것과 두려운 것의 차이는 평가가 있느냐다. 평가 하니스가 없으면 모든 프롬프트 조정이 도박이다. 평가 하니스는 "이게 더 나은 것 같다"를 "이건 측정 가능하게 4점 더 낫고 아무것도 망가뜨리지 않았다"로 바꾼다. 그것이 잠금 해제의 전부다. 테스트 없이 코드를 배포하지는 않을 것이다. 사람들은 평가 없이 에이전트를 끊임없이 배포하고, 그러고는 "사소한 프롬프트 조정"이 왜 운영을 망가뜨렸는지 의아해한다. 평가 하니스는 비결정론적 소프트웨어를 위한 테스트 스위트다. 이것이 내가 실제로 돌리는 것이다. ## 실제 장애로부터 구축한 테스트 세트로 시작하라 하니스는 그 테스트 케이스만큼만 좋고, 최고의 테스트 케이스는 상상이 아니라 운영에서 나온다. 에이전트가 현장에서 실패할 때마다, 나는 정확한 입력을 포착하고(모든 실행을 트레이스 ID와 함께 로깅한다 — [운영에서 에이전트를 디버깅하는 법](/how-to-debug-an-ai-agent-in-production) 참조), 그것을 평가 케이스로 바꾼다. ```typescript interface EvalCase { id: string; input: AgentInput; // 정확한 운영 입력 expected?: string; // 정답이 있을 때의 그라운드 트루스 assertions: Assertion[]; // 통과해야 하는 엄격한 검사 rubric?: string; // 출력이 개방형일 때 LLM 심판용 } ``` 여기서 중요한 실천이 둘이다. **운영에서 끌어와라.** 그래야 평가가 추측한 것이 아니라 실제로 망가지는 것을 테스트한다. 그리고 **범위를 넓게 덮어라** — 해피 패스, 엣지 케이스, 적대적 입력, 그리고 조용한 실패를 일으키는 빈/잘못된 입력. 잘 고른 30~50개 케이스의 테스트 세트는 게으른 500개보다 훨씬 많이 잡아낸다. 모두 같은 쉬운 경로를 테스트하는 천 개보다, 각각이 실제 실패 모드를 대표하는 40개 케이스를 갖는 편이 낫다. ## 먼저 어서션으로, 다음에 LLM 심판으로 채점하라 모든 출력에 모델 채점이 필요한 것은 아니다. 나는 작동하는 가장 저렴한 채점기에 손을 뻗는다. 구조화된 모든 것에는 **엄격한 어서션**을. 출력이 유효한 JSON으로 파싱되는가? 필수 필드를 담고 있는가? 추출된 날짜가 범위 안에 있는가? 올바른 인수로 올바른 도구를 호출했는가? 이것들은 결정론적이고, 무료이며, 명확하다 — 쓸 수 있는 만큼 써라. ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` 개방형인 나머지에는 **LLM 심판**을 — 어조, 유용성, "이것이 정말 질문에 답했는가". 여기서는 모델에 입력, 출력, 루브릭을 주고 채점을 요청한다. 심판을 정직하게 유지하는 규칙은 둘이다. 루브릭을 **구체적**으로 만들 것(설명된 기준점이 있는 1~5 척도가 "품질을 평가하라"보다 낫다), 그리고 **강한 모델을 심판으로 쓸 것** — 판단은 추론 과제이므로, 에이전트 자체가 [비용 계산](/ai-agent-cost-math-when-haiku-beats-sonnet)에 따라 Haiku로 돌더라도 나는 여기서 기꺼이 Sonnet 비용을 지불한다. 모호한 루브릭이나 약한 심판은 신호처럼 보이는 잡음을 준다. ## 모든 변경 전에 하니스를 실행하라 하니스는 한 가지 질문에 답하기 위해 존재한다. *이 변경이 에이전트를 더 좋게 만들었는가 나쁘게 만들었는가?* 그래서 나는 모든 프롬프트 편집, 모델 교체, 도구 변경 전에 그것을 실행한다. ```bash # main의 베이스라인 npm run eval -- --suite=booking-agent > baseline.json # 변경한 다음 다시 실행 npm run eval -- --suite=booking-agent > candidate.json # 비교 npm run eval:diff baseline.json candidate.json ``` diff는 집계 점수, 케이스별 합격/불합격, 그리고 — 결정적으로 — **어떤 특정 케이스가 회귀했는지**를 보여준다. 세 케이스가 조용히 깨지는 동안 집계가 올라가는 것은 개선이 아니다. 그것은 내가 보고 승인하고 싶은 트레이드오프이지, 몰래 통과하는 것이 아니다. 케이스별 diff를 지켜보는 것이 "하나 고치고 둘 깨뜨리기" — 사람들이 자기 프롬프트를 두려워하게 만드는 실패 모드 — 를 피하는 방법이다. ## 회귀 게이트를 설정하고 차단하게 하라 하니스를 신뢰하게 되면, 그것을 게이트로서 운영으로 가는 경로에 연결하라. 내 규칙은 단호하다. **점수를 베이스라인 임계값 아래로 떨어뜨리는 변경은 배포하지 않는다.** "나중에 살펴볼게"가 아니다 — 실패한 CI 테스트와 똑같이 차단된다. ```typescript const PASS_THRESHOLD = 0.90; // 케이스의 90%가 통과해야 한다 if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` 이것이 평가를 "있으면 좋은 것"에서 빠르게 움직일 수 있게 해주는 것으로 바꾼다. 게이트는 "두려움 없이 배포한다"를 문자 그대로 참으로 만든다. 나쁜 변경의 최악의 경우는 빨간 평가 실행이지, 운영 사고가 아니다. 그리고 테스트 세트는 무언가 깨질 때마다 자라므로, 게이트는 시간이 지나며 스스로 더 엄격하고 더 보호적이 된다. ## 채점에서 비결정성을 고려하라 사람들이 걸려 넘어지는 미묘한 점. 같은 입력도 실행마다 다르게 점수가 나올 수 있다. 모델이 다르게 샘플링하기 때문이다. 각 케이스를 한 번만 실행하면 유령 회귀를 보게 된다 — "깨진" 케이스가 실은 그저 샘플링 잡음이다. 완화책 둘. 분산을 줄이기 위해 평가를 **`temperature: 0`**으로 실행하라(완전히 없애지는 못한다). 그리고 깜빡이는 것을 본 케이스는, 단일 합격/불합격이 아니라 **N번 실행하고 합격률을 취하라**. 10번 중 9번 통과하는 케이스는, 둘 다 단일 실행에서 초록을 보일 수 있더라도, 10번 중 5번 통과하는 케이스보다 상태가 낫다. 이것은 [간헐적 실패를 디버깅할](/how-to-debug-an-ai-agent-in-production) 때 쓰는 것과 같은, 일화보다 물량의 원칙이다 — 한 번의 실행은 의견이고, 쉰 번의 실행은 데이터다. ## 운영 모니터링으로 루프를 닫아라 평가 하니스는 알려진 케이스에 대해 테스트한다. 운영은 새로운 케이스를 던진다. 그래서 루프는 이렇다. 실시간 동작을 모니터링하고, 새 실패 모드를 잡고, 그것을 평가 케이스로 바꾸고, 고치면, 이제 그것은 영구적으로 보호된다. 모니터링 측면 — 실시간 트래픽에서 성공률, 출력 유효성, 실행당 비용을 추적하는 것 — 은 [AI 에이전트가 실제로 작동하는지 어떻게 측정하는가](/how-i-measure-whether-an-ai-agent-is-actually-working/)에서 다룬다. 평가와 모니터링은 같은 시스템의 두 절반이다. 모니터링이 버그를 찾고, 평가가 그것들이 죽은 채로 있게 보장한다. 그 피드백 루프가 진짜 제품이다. 어떤 단일 평가 세트든 낡는다. 하지만 모든 운영 장애를 영구적인 테스트로 변환하는 *프로세스*는 매주 강해진다. 이것이 에이전트가 "손대기 무서운" 것에서 금요일 오후에 움찔하지 않고 리팩터링할 무언가로 바뀌는 방식이다. ## 자주 묻는 질문 ### AI 에이전트 평가 세트에는 무엇이 들어가는가? 실제 운영 입력을 채점된 케이스로 바꾼 것 — 해피 패스, 엣지 케이스, 적대적 및 잘못된 입력 — 각각에 엄격한 어서션을, 개방형 출력에는 LLM 심판 루브릭을 붙인다. 실제 장애에서 끌어온 30~50개 케이스가 모두 쉬운 경로를 테스트하는 수백 개의 합성 케이스를 이긴다. ### 에이전트 출력을 채점하는 데 LLM을 써야 하는가? 출력이 구조화된 곳(유효한 JSON, 올바른 필드, 올바른 도구 호출)이면 어디서든 엄격한 어서션을 써라 — 무료이고 결정론적이다. 어조와 유용성 같은 개방형 특성에는, 구체적인 루브릭과 강한 심판 모델을 갖춘 LLM 심판을 아껴 두어라. 그래야 잡음이 아닌 신호를 얻는다. ### 프롬프트 변경이 운영을 조용히 망가뜨리는 것을 어떻게 막는가? 모든 변경 전에 평가 하니스를 실행하고 베이스라인과 diff를 내며, 집계 점수만이 아니라 케이스별 회귀를 지켜봐라. 그런 다음 결과로 배포를 게이트하여, 베이스라인 임계값 아래로 떨어지는 어떤 변경이든 실패한 테스트처럼 차단하라. ### 평가에서 비결정성을 어떻게 다루는가? 분산을 줄이기 위해 온도 0으로 실행하고, 깜빡이는 케이스는 여러 번 실행하여 단일 실행 대신 합격률로 채점하라. 10번 중 9번 통과하는 케이스는, 단일 실행이 둘 다 초록으로 보이더라도, 10번 중 5번 통과하는 케이스보다 건강하다. --- ## AI 에이전트로 뉴스레터를 자동화하는 방법 Source: https://alejandrorioja.com/ko/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-18 Tags: AI Agents, Growth TL;DR: Claude 에이전트가 콘텐츠 큐를 읽고, 주간 최적의 각도를 선택하며, 내 목소리로 뉴스레터를 초안 작성하고, 참여도 계층별로 목록을 세분화하며, Kit API를 통해 발송을 예약합니다 — 내가 에디터를 열지 않아도 됩니다. 렌더링된 미리보기를 확인하고 승인을 누르면 됩니다. 어려운 창의적 작업은 내 몫이고, 기계적 실행은 에이전트의 몫입니다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** Claude 에이전트가 콘텐츠 큐를 읽고, 주간 최적의 각도를 선택하며, 내 목소리로 뉴스레터를 초안 작성하고, 참여도 계층별로 목록을 세분화하며, Kit API를 통해 발송을 예약합니다 — 내가 에디터를 열지 않아도 됩니다. 렌더링된 미리보기를 확인하고 승인을 누르면 됩니다. 어려운 창의적 작업은 내 몫이고, 기계적 실행은 에이전트의 몫입니다. **[운영자 노트]** 일관되게 발송되는 뉴스레터가 "더 좋지만" 영감이 올 때만 발송되는 것보다 낫습니다. 제약은 아이디어가 아니라 실행 오버헤드였습니다. 아이디어는 있었지만 매주 형식을 잡고, 일정을 잡고, 세분화할 여력이 없었습니다. 에이전트가 그 격차를 없앴습니다. ## 대부분의 뉴스레터 워크플로우의 실제 병목 대부분의 뉴스레터 자동화 조언은 잘못된 것에 집중합니다: 환영 시퀀스, 자동화, 태깅 로직. 나쁘지 않지만 주 단위 창작 문제를 해결하지 못합니다. 실제 걸림돌은 이것입니다: 무슨 말을 할지는 알지만, 앉아서 형식을 잡고, 제목 줄 변형을 작성하고, 올바른 세그먼트를 선택하고, 올바른 시간에 예약하면 주당 2-3시간의 컨텍스트 전환이 필요합니다. 52주를 곱하면 뉴스레터를 *발송*하는 데만 꼬박 1주일을 쓴 셈입니다. 에이전트는 "이번 주 각도가 무엇인지 알겠다" 이후의 모든 단계를 처리합니다. ## 사용 중인 스택 - **[Kit](/recommends/convertkit)**(이전 ConvertKit) — 이메일 플랫폼. 훌륭한 API, 견고한 구독자 태깅, 깔끔한 분석. 에이전트 친화적인 API가 결정적이었습니다. - **Claude (Anthropic SDK)** — 생성 레이어 - **Cloudflare Workers** — 예약 트리거(매주 화요일 오전 8시 CT 실행) - **Airtable** — 콘텐츠 큐 및 승인 수신함 Kit를 사용하지 않더라도 브로드캐스트를 생성하고 예약할 REST API가 있는 플랫폼이라면 같은 패턴이 작동합니다. ## 1단계: 콘텐츠 큐 에이전트는 "무엇을 쓸 것인지"에 대한 진실의 원천이 필요합니다. 제 것은 다음 열을 가진 [Airtable](/recommends/airtable) 테이블입니다: - `Topic` — 각도 또는 질문 - `Status` — Queue / Approved / Sent - `Tier` — 모든 구독자용인지 참여도 높은 구독자만인지 - `Notes` — 모든 제약 사항(이 톤 피하기, 이 링크 포함하기 등) 매주 10분을 들여 큐에 2-3개의 주제를 추가합니다. 그것이 제 창의적 기여입니다. 나머지는 에이전트의 일입니다. ## 2단계: 초안 에이전트 ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## 3단계: 승인 단계 에이전트는 Kit의 초안 상태로 브로드캐스트를 생성하고 Airtable 레코드를 "Approved"로 표시합니다. Kit가 미리보기 링크가 포함된 알림을 보냅니다. 클릭해서 읽고, 괜찮아 보이면 발송을 확인합니다. 변경하고 싶으면 Kit에서 직접 편집합니다. 이것이 에이전트가 발신 이메일에서 완전히 자율적이 되지 않도록 막는 게이트입니다. 초안을 약 90%의 시간 동안 신뢰합니다. 검토에서 발견하는 10% — 약간 어긋난 톤, 확인하고 싶은 통계, 추가하고 싶은 링크 — 는 3분 검토의 가치가 있습니다. ## 에이전트가 처리하는, 다시는 하고 싶지 않은 것들 - 제목 줄 변형 작성 및 최선의 것 선택 - 프리헤더 텍스트 형식 지정 - 올바른 발송 시간 계산(내 독자는 목요일 오전에 열람한다; 에이전트는 이것을 안다) - 주제 계층을 기반으로 올바르게 세분화 - 기록을 위해 모든 것을 Airtable에 기록 ## 여전히 내 것인 것 *아이디어*. 큐의 주제는 내 것입니다. 각도는 내 것입니다. 에이전트는 명확한 브리프의 훌륭한 실행자입니다. 전략 레이어가 아닙니다. 큐에 나쁜 주제를 넣으면 나쁜 주제에 대해 잘 쓰인 뉴스레터를 얻습니다. 또한: 첫 번째 검토 게이트. 모든 발송은 내 눈을 통해 나가기 전에 확인됩니다. 이것은 바뀌지 않을 것입니다. ## 운영자의 결론 뉴스레터 기계적 작업 — 형식 지정, 일정 잡기, 세분화 — 에 주당 1시간 이상을 쓰고 있다면 자동화해야 합니다. Kit API는 깔끔하고, Worker cron 트리거는 바위처럼 견고하며, Claude 초안 품질은 약 90%의 첫 초안을 변경 없이 승인할 수 있을 만큼 높습니다. Airtable에서 큐를 구축하고, Worker를 연결하고, 발송을 실행하는 대신 아이디어를 만드는 일로 돌아가십시오. --- ## 새 블로그 포스트 하나 쓰지 않고 AI 검색에서 순위 올리는 방법 Source: https://alejandrorioja.com/ko/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-19 Tags: GEO, SEO TL;DR: AI 엔진은 질문에 직접 답하고, 명확한 저자권을 주장하며, 검색을 쉽게 만드는 방식으로 지식을 구조화하는 콘텐츠를 인용합니다. 대부분의 기존 블로그 게시물은 재작성이 아닌 편집으로 세 가지 기준을 모두 충족하도록 개조할 수 있습니다. 플레이북: 직접적인 TL;DR 추가, 엔티티 신호 강화, FAQ 스키마 추가, llms.txt에 제출. 새 콘텐츠는 선택 사항이지만 재구조화는 필수입니다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** AI 엔진은 질문에 직접 답하고, 명확한 저자권을 주장하며, 검색을 쉽게 만드는 방식으로 지식을 구조화하는 콘텐츠를 인용합니다. 대부분의 기존 블로그 게시물은 재작성이 아닌 편집으로 세 가지 기준을 모두 충족하도록 개조할 수 있습니다. 플레이북: 직접적인 TL;DR 추가, 엔티티 신호 강화, FAQ 스키마 추가, llms.txt에 제출. 새 콘텐츠는 선택 사항이지만 재구조화는 필수입니다. **[운영자 관점]** GEO 지향 새 기사를 한 편 쓰기 전에 341개의 기존 게시물에 이 프로세스를 적용했습니다. ChatGPT와 Perplexity에서의 인용이 늘었습니다. 새 콘텐츠가 성과를 가속화했지만 기존 콘텐츠 감사가 시작점이었고, 예상보다 빨리 결과가 나왔습니다. ## AI 엔진이 기존 콘텐츠를 인용하지 않는 이유 새로운 것을 쓰기 전에 먼저 물어보세요: 이미 가진 것이 왜 인용되지 않는가? 답은 거의 "콘텐츠가 존재하지 않아서"가 아닙니다. 보통 다음 중 하나입니다: 1. **맨 위에 직접적인 답이 없음** — 게시물이 6번째 단락에 답을 묻어놓음 2. **저자 신호 약함** — 명확한 저자 엔티티 없음, 콘텐츠에 자격증명 없음 3. **구조적 소음** — 긴 서론, 관련 없는 섹션, 명확한 제목 계층 없음 4. **기계 가독 Q&A 없음** — AI 엔진은 구조화된 질문-답변 쌍을 선호하지만 대부분의 블로그 게시물에는 없음 5. **AI 가독 인덱스에 없음** — llms.txt 없음, 크롤러가 찾을 사이트맵 없음 다섯 가지 모두 기존 콘텐츠에서 수정 가능합니다. 새 게시물이 필요한 것은 하나도 없습니다. ## 4단계 개조 프로세스 ### 1단계: 처음 100단어 안에 직접적인 TL;DR 추가 AI 엔진은 당신이 빠르게 훑을 때 하는 것과 유사한 일을 합니다 — 더 깊이 들어가기 전에 직접적인 답을 찾습니다. 게시물이 이야기, 질문 또는 맥락 설정으로 시작한다면, 모델이 실제 답을 찾을 만큼 멀리 읽지 않을 수 있습니다. 수정: 처음 100단어 안에 **TL;DR** 블록을 추가합니다. 형식: 요점 → 이유 → 제약이나 주의사항. 2~4문장. 군더더기 없이. 개조 전 예시: > *왜 일부 기업들이 구글 검색 결과를 지배하는 것처럼 보이는지 궁금했던 적이 있나요? 이 게시물에서는 상위 랭킹 사이트들이 사용하는 전략을 탐구합니다...* 개조 후 예시: > **TL;DR:** 2026년 로컬 SEO에서 차이를 만드는 세 가지: Google 비즈니스 프로필 완성도, 디렉토리 전체의 인용 일관성, NAP 데이터에 대한 구조화된 스키마. "매일 게시하기", "빠르게 100개 리뷰 받기" 같은 전술은 이 세 가지에 비해 부차적입니다. 상한은 GBP 정확도입니다 — 먼저 그것을 수정하세요. 재작성이 더 길지 않습니다. 그냥 앞에 배치된 것입니다. ### 2단계: 엔티티 신호 강화 AI 엔진은 지식 그래프를 구축합니다. 누가 이것을 썼는지, 무엇에 관한 것인지, 저자는 이 주제에서 신뢰할 수 있는지 알고 싶어합니다. 저자 엔티티를 위해: About 페이지가 모든 게시물에서 링크되는지 확인하고, 저자 스키마에 LinkedIn과 Twitter로의 `sameAs` 링크를 포함하며, 각 게시물의 저자 소개가 구체적인 자격증명을 언급하도록 합니다 ("마케팅 전문가"가 아니라 "세 SaaS 기업의 SEO를 0에서 월 100K 방문자로 운영한"). 주제 엔티티를 위해: 청중이 검색하는 정확한 용어를 사용하세요. "GEO"(생성 엔진 최적화)를 다루고 있다면, 약어만 쓰지 말고 어딘가에 "생성 엔진 최적화"라고 말하세요. 모델은 콘텐츠를 분류하기 위해 용어 공출현을 사용합니다. ### 3단계: 질문에 답하는 모든 게시물에 FAQ 스키마 추가 FAQPage 스키마는 GEO 인용에 가장 효과적인 스키마 유형입니다. 모델이 직접 파싱할 수 있는 형식으로 질문과 답변을 명시적으로 매핑하기 때문입니다. 게시물이 암시적으로 답하는 3~5개의 질문을 취해 명시적으로 만드세요: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` 이것을 게시물의 `` 또는 CMS의 스키마 필드를 통해 추가하세요. 모든 주요 AI 엔진이 이것을 크롤링하고 파싱합니다. ### 4단계: llms.txt와 플랫폼의 AI 인덱스에 제출 `llms.txt`는 신흥 표준입니다 — `yoursite.com/llms.txt`의 플레인텍스트 파일로 AI 크롤러에게 어떤 콘텐츠가 고품질이고 우선순위를 어떻게 지정하는지 알려줍니다. LLM을 위한 `robots.txt`와 유사합니다. 기본 llms.txt: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` `lastmod` 타임스탬프가 포함된 깔끔한 사이트맵과 함께 사용하세요. AI 크롤러는 오래된 것처럼 보이는 콘텐츠의 우선순위를 낮춥니다. ## 어떤 게시물을 개조할지 우선순위 정하는 방법 모든 게시물이 개조할 가치가 있는 것은 아닙니다. 첫 번째 라운드를 다음에 집중하세요: 1. **질문 형식 키워드에서 이미 1페이지에 랭크된 게시물** — 이것들이 인용에 가장 가깝습니다; 구조 수정만 필요합니다 2. **검증 가능하게 신뢰할 수 있는 주제의 게시물** — AI 엔진은 저자권에 큰 비중을 둡니다; 당신의 자격증명이 관련된 게시물은 엔티티 신호로 인용 향상을 얻습니다 3. **직접 질문에 답하는 게시물 vs 정보를 제공하는 게시물** — "X 하는 방법"과 "X란 무엇인가"가 목록 게시물이나 의견 글보다 개조 효과가 좋습니다 Search Console 데이터를 사용하세요: 질문 형식의 쿼리(how, what, why, best way to)로 필터링합니다. 해당 쿼리에서 5~15위인 게시물이 최적의 개조 후보입니다 — 관련성은 있지만 인용되기 위한 최상위에는 아직 충분히 가깝지 않습니다. ## 대부분의 사람들이 저지르는 실수 기존 아카이브를 개조하기 전에 AI 검색에 최적화된 새 게시물을 씁니다. 새 콘텐츠는 도움이 되지만, 기존 게시물에는 나이, 백링크, 크롤 역사가 있습니다. 잘 구조화된 3년 된 게시물이 같은 주제의 새 게시물을 몇 달간 능가할 것입니다. 먼저 개조하세요. 진정한 격차가 있는 곳 — 기존 게시물이 전혀 답하지 않는 질문 — 에 새 콘텐츠를 쓰세요. 그때가 새것이 오래된 것보다 나을 때입니다. ## 운영자의 최종 결론 20개 이상의 기존 블로그 게시물이 있다면, GEO 작업은 콘텐츠 캘린더가 아닌 감사와 개조로 시작합니다. 새로운 것을 쓰기 전에 상위 20개 게시물에 TL;DR을 추가하고, 엔티티 신호를 강화하고, FAQ 스키마를 추가하고, llms.txt에 제출하세요. 수개월이 아닌 수주 내에 인용 개선을 보게 될 것이며 — 새 콘텐츠가 실제로 지표를 움직이는지 측정하기 위한 더 깔끔한 기준선을 갖게 됩니다. --- ## Facebook 광고를 운영하는 Claude 스킬을 만들었다 — 코드 공개 Source: https://alejandrorioja.com/ko/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-25 Tags: AI Agents TL;DR: Graph API를 통해 Meta Ads 계정을 읽고, 저성과 광고를 식별하고, 브랜드 보이스로 광고 카피를 다시 쓰고, 광고 관리자를 건드리지 않고 새 광고 세트를 만드는 Claude 스킬을 구축했다. 전체 코드는 300줄 미만의 TypeScript다. 효과는 즉각적이었다: 주간 광고 관리 시간을 약 3시간에서 약 20분으로 줄였다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** Graph API를 통해 Meta Ads 계정을 읽고, 저성과 광고를 식별하고, 브랜드 보이스로 광고 카피를 다시 쓰고, 광고 관리자를 건드리지 않고 새 광고 세트를 만드는 Claude 스킬을 구축했다. 전체 코드는 300줄 미만의 TypeScript다. 효과는 즉각적이었다: 주간 광고 관리 시간을 약 3시간에서 약 20분으로 줄였다. **[운영자의 시각]** Pickleland와 내 컨설팅 브랜드를 위해 광고를 운영한다. 두 계정, 다른 타깃, 끊임없는 크리에이티브 피로. 모델이 해야 할 일을 하면서 일요일 오후를 광고 관리자에서 보내고 있었다. 그래서 자동화했다. ## Facebook 광고를 수동으로 관리하는 것을 그만둔 이유 Facebook 광고를 운영하는 실제 작업은 세 가지로 나뉜다: 1. **모니터링** — 어떤 광고 세트가 돈을 태우고 있는지, 벌고 있는지 확인하기 2. **진단** — *왜* 성과가 저조한지 파악하기 (크리에이티브 피로? 잘못된 타겟팅? 랜딩 페이지?) 3. **반복** — 새 카피 작성, 새 광고 세트 생성, 예산 조정 작업 1은 기계적이다. 작업 3도 대부분 기계적이다 (보이스 제약이 있지만). 작업 2는 판단이 필요하다 — 사람이 루프에 있을 때 이점이 있는 유일한 것이다. Claude 스킬은 1과 3을 수행할 수 있다. 나는 무언가 게시되기 전에 작업 2의 결과를 검토한다. 이것이 내가 선택한 아키텍처다. ## Meta Graph API 설정 (귀찮은 부분) 코드보다 먼저: Meta Business 계정, 시스템 사용자, 영구 액세스 토큰이 필요하다. Facebook의 개발자 포털은 불편하지만 경로는 이렇다: 1. developers.facebook.com에서 **Meta App** 생성 (유형: Business) 2. **Marketing API** 제품 추가 3. 비즈니스 포트폴리오 → 설정 → 사용자 → 시스템 사용자에서 시스템 사용자를 생성하고 광고 계정에 `ADVERTISER` 역할 부여 4. 다음 권한으로 토큰 생성: `ads_read`, `ads_management`, `business_management` 토큰을 `META_ACCESS_TOKEN`으로, 광고 계정 ID(형식: `act_XXXXXXXX`)를 `META_AD_ACCOUNT_ID`로 `.env`에 저장한다. ## 스킬 파일 구조 ``` .claude/skills/fb-ads/ SKILL.md ← Claude가 읽는 지침 index.ts ← 실제 도구 구현 types.ts ← 공유 타입 ``` `SKILL.md`는 Claude에게 스킬을 언제 어떻게 사용할지 알려준다. 내 것은 이렇다: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` "절대 자동으로 활성화하지 않는다"는 제약은 협상의 여지가 없다. 이 스킬은 PAUSED 상태로 항목을 만든다. 내가 검토하고 수동으로 활성화한다. 라이브 광고 지출에 닿는 모든 것에는 사람의 체크포인트가 필요하다. ## TypeScript 핵심 코드 (코드 블록은 영어로 유지 — 주변 텍스트만 번역한다.) ## 일상적인 사용 방법 스킬은 Claude Code(내 일상 도구)에서 호출된다. 전형적인 월요일 아침 세션: ``` > check my ads from the last 7 days ``` Claude가 `runAdsReport(7)`를 실행하고, 결과를 테이블로 포맷하고, 저성과자를 표시하고, 다시 쓰기를 원하는지 묻는다. "예"라고 한다. 새 카피를 생성하고, 두 버전을 나란히 보여주고, 새 크리에이티브로 PAUSED 광고 세트를 만든다. 광고 관리자에서 검토하고, 마음에 드는 것을 활성화하고, 실패한 것을 보관한다. 총 시간: 20분. 광고 관리자에서 보내는 일요일 오후는 제로. ## 이것이 대체할 수 없는 것 스킬은 제품-시장 적합성 문제가 카피 문제로 위장하고 있는지 알려줄 수 없다. ROAS가 전반적으로 나쁘다면, 그것은 퍼널이나 제품 문제이지 헤드라인 문제가 아니다. Claude는 망가진 퍼널 위에서 카피를 충실하게 다시 쓸 것이다 — 그리고 다시 쓰기로는 구할 수 없다. 진단 단계는 여전히 내 것이다. 보고서를 읽고, 퍼널 데이터를 보고, 크리에이티브를 반복할 것인지 상류에서 무언가를 해결할 것인지 결정한다. 에이전트는 그 판단 *외에는* 모든 것에서 빠르다. ## 운영자의 결론 광고를 수동으로 관리하고 주에 두 번 이상 광고 관리자를 건드리고 있다면, 스크립트가 해야 할 운영 작업을 하고 있는 것이다. Graph API는 잘 문서화되어 있고 Meta 권한 흐름은 귀찮지만 한 번만 설정하면 된다. 오후 하나로 스킬을 만들어라. 되찾은 시간으로 얻는 보상은 첫 주에 나타난다. --- ## 내가 실제로 비즈니스 운영에 사용하는 AI 도구 5가지 (2026) Source: https://alejandrorioja.com/ko/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-18 Tags: AI Agents, Growth TL;DR: 다섯 가지 도구: Claude(운영자 레이어+코딩), Cursor(TypeScript 개발), Airtable(모든 에이전트의 데이터 기반), Kit(뉴스레터+이메일 자동화), Cloudflare Workers(에이전트 호스팅). 시도해본 다른 것들은 모두 이 중 하나로 대체되거나 완전히 제거되었습니다. 오늘 다시 시작해야 한다면 재구축할 스택이 바로 이것입니다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** 다섯 가지 도구: Claude(운영자 레이어+코딩), Cursor(TypeScript 개발), [Airtable](/recommends/airtable)(모든 에이전트의 데이터 기반), [Kit](/recommends/convertkit)(뉴스레터+이메일 자동화), Cloudflare Workers(에이전트 호스팅). 시도해본 다른 것들은 모두 이 중 하나로 대체되거나 완전히 제거되었습니다. 오늘 다시 시작해야 한다면 재구축할 스택이 바로 이것입니다. **[운영자 관점]** 저는 두 가지 비즈니스를 운영합니다: 개인 AI 컨설팅 브랜드(alejandrorioja.com)와 텍사스주 플루거빌에 있는 피클볼 시설 Pickleland. 다른 맥락, 다른 고객, 다른 운영. 이 다섯 가지 도구가 둘 다 운영합니다. 유행하기 때문에 나열하는 게 아닙니다. 대안들을 삭제했기 때문에 나열하는 것입니다. ## 1. Claude — 운영자 레이어 Claude(Claude Code와 Anthropic SDK를 통해)는 움직이는 모든 것의 두뇌입니다. 세 가지 모드로 사용합니다: **Claude Code**는 일상 개발 드라이버입니다. TypeScript를 작성하고, 에이전트를 구축하고, 인프라 문제를 디버그하고, 콘텐츠를 관리합니다 — 모두 Claude Code 인터페이스에서. 단순한 자동완성이 아닙니다. 500줄 파일을 읽고, 의도를 이해하고, 제가 고려하지 않은 리팩터링을 제안할 수 있는 협력자입니다. **Anthropic SDK**는 제가 구축한 모든 에이전트를 구동합니다. 뉴스레터 에이전트, Facebook 광고 스킬, 콘텐츠 파이프라인, OG 카드 생성기 — 백엔드 모두 Claude입니다. 모델 품질이 충분히 높아서 약 85%의 시간 동안 첫 번째 초안을 신뢰합니다. **Claude의 보이스와 브랜드** 판단은 과소평가되어 있습니다. 나다운 글을 써야 할 때, Claude + 상세한 시스템 프롬프트가 테스트한 다른 모든 모델보다 낫다는 것을 알게 되었습니다. 비결은 구체적이고 의견이 담긴 시스템 프롬프트입니다 — "캐주얼한 톤으로 써"가 아니라 "Alejandro처럼 써: 직접적, 실무자, 과장 없음, 번호 매기기, 1인칭, 솔직한 주의사항 포함." Claude Max를 구독합니다. 가장 많이 사용하는 구독이고, ROI는 비교가 안 됩니다. ## 2. Cursor — TypeScript가 작성되는 곳 Cursor는 IDE입니다. 약 1년 전에 VS Code에서 전환하고 돌아보지 않았습니다. 탭 완성이 충분히 빠르게 코드 작성 방식을 실제로 바꿉니다 — 더 높은 수준에서 생각하고 Cursor가 구문적 보일러플레이트를 처리하게 합니다. AI 제안에 대한 diff 뷰는 깔끔합니다. 다중 파일 컨텍스트 창 덕분에 함수 업데이트를 요청하면 호출자도 업데이트합니다. 아키텍처 결정에는 Cursor를 사용하지 않습니다. 여전히 종이나 Claude에서 스케치합니다. 하지만 설계가 명확해지면, Cursor는 설계에서 실행 가능한 TypeScript로 가는 가장 빠른 경로입니다. 최고의 잠금 해제: Cursor + Claude Code 병렬 사용. 고수준 계획과 에이전트 오케스트레이션에는 Claude Code; 구현 세부 작업에는 Cursor. 충돌하지 않습니다 — 다른 고도를 커버합니다. ## 3. Airtable — 데이터 기반 운영하는 모든 AI 에이전트는 읽고 쓸 장소가 필요합니다. 그 장소가 [Airtable](/recommends/airtable)입니다. 두 비즈니스에서 사용하는 용도: - **콘텐츠 큐** — 진행 중인 게시물과 뉴스레터 주제, 상태 추적 포함 - **예약 기록** — 예약 시스템에서 동기화된 Pickleland 코트 예약 - **제휴 링크 카탈로그** — 콘텐츠 에이전트가 생성 시 읽는 메타데이터가 있는 105개 이상의 슬러그 - **에이전트 감사 로그** — 무엇이 실행되었는지, 언제, 무엇을 생산했는지, 오류 API는 깔끔하고 빠릅니다. Airtable은 고처리량 워크로드를 위한 데이터베이스가 아닙니다 — 하지만 에이전트 사이드 테이블, 검토 큐, 사람이 참여하는 승인 워크플로에는 딱 맞는 도구입니다. 시각적 인터페이스 덕분에 쿼리 없이 모든 테이블을 검사할 수 있습니다. 시도한 대안: Notion 데이터베이스. Notion API는 더 느리고 데이터 모델은 에이전트 읽기에 더 번거롭습니다. 에이전트 인접 데이터에는 Airtable이 승리합니다. ## 4. Kit — 뉴스레터와 이메일 자동화 [Kit](/recommends/convertkit)(이전 ConvertKit)로 전환한 이유는 하나: API가 실제로 좋습니다. 대부분의 이메일 플랫폼은 API를 사후 생각으로 취급합니다. Kit는 1등급 제품으로 취급합니다. 방송 생성, 전송 예약, 태그별 세분화, 분석 읽기 — 모두 프로그래밍 방식으로 가능합니다. 뉴스레터 에이전트가 작성기를 만지지 않고 이 모든 것을 합니다. 사용하는 Kit 특정 기능: - **방송 API** — 에이전트가 매주 프로그래밍 방식으로 예약 방송 생성 - **구독자 태깅** — 행동으로 구독자 태그 (최근 5번 전송 열람=「활성」; 60일 미열람=「위험」) 에이전트가 세그먼트 타겟팅 - **양식+랜딩 페이지** — 깔끔하고 빠른 로딩, 노코드. 이것들을 프로그래밍 방식으로 건드리지 않습니다; 그냥 작동합니다. Mailchimp나 레거시 플랫폼에 있다면: 마이그레이션할 가치가 있습니다. Mailchimp API는 Kit가 하나로 하는 것을 세 번의 추가 호출이 필요합니다. ## 5. Cloudflare Workers — 에이전트가 사는 곳 모든 예약 에이전트는 Cloudflare Workers에서 실행됩니다. 논거: 전 세계 엣지 배포, 무료 티어에서 제로 콜드 스타트, 실제로 작동하는 cron 트리거 시스템. 에이전트들은 서버가 필요 없습니다. 안정적으로 실행되고, 외부 API 호출이 가능하며, 내 규모에서 거의 비용이 들지 않는 예약 함수가 필요합니다. Workers가 답입니다. Workers에서 실행 중인 것: - **콘텐츠 파이프라인** — 영문 게시물 생성, 12개 번역으로 배포, OG 카드 생성 - **뉴스레터 에이전트** — 주간 전송 초안 작성 및 예약 - **Facebook 광고 모니터** — 성과 읽기, 저조한 항목 플래그, 알림 - **Pickleland 점유율 보고기** — 예약 데이터 읽기, 일일 요약 전송 이 모든 것의 월간 총 비용: ~$5. 유료 Workers 플랜입니다. 에이전트는 cron 일정에 따라 안정적으로 실행됩니다; 6개월 동안 한 번의 실패가 있었습니다 (Meta 측의 DNS 문제, 내 것이 아님). ## 제거한 것과 이유 **Zapier** — Workers + 각 플랫폼 API로 직접 대체. Zapier는 지연을 추가하고, 규모에서 더 비싸며, Workers에는 없는 상한선이 있습니다. **ChatGPT** — Claude의 컨텍스트 창, 도구 사용, 시스템 프롬프트 품질이 운영자 사용 사례에 더 좋습니다. 빠른 웹 검색용으로 ChatGPT 탭을 유지하지만 그 위에 구축하지는 않습니다. **Webflow** — 사이트를 Astro + Cloudflare Pages로 이전. 더 많은 제어, 더 좋은 성능, 스크립트 가능한 빌드 프로세스. **Grammarly** — Claude가 Grammarly가 하는 모든 것을 하고 내 목소리를 더 잘 유지합니다. ## 운영자의 최종 결론 위 다섯 가지 도구는 가장 새로운 것도 가장 많이 논의되는 것도 아닙니다. 두 가지 다른 비즈니스에서 일상적인 프로덕션 사용을 견뎌낸 것들입니다. 스택에 새 도구를 추가하기 전에 물어보세요: 이 다섯 가지 중 어느 것이 이 작업을 할 수 있는가? "이미 그 중 하나가 할 수 있다"는 답이 얼마나 자주 나오는지 놀랄 것입니다. --- ## AI 에이전트가 프로덕션에서 계속 실패하는 이유 (그리고 수정 방법) Source: https://alejandrorioja.com/ko/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-25 Tags: AI Agents TL;DR: 대부분의 프로덕션 에이전트 실패는 다섯 가지 원인에서 옵니다: 엣지 케이스를 처리하지 못하는 취약한 프롬프트, 일시적 API 오류에 대한 재시도 로직 부재, 무엇이 고장났는지 볼 수 없는 관측 가능성 부재, 종료 조건 없는 폭주 루프, 그리고 모델이 잘못된 것을 선택할 만큼 모호한 도구 정의. 다섯 가지 모두 모델이나 프레임워크를 변경하지 않고 수정 가능합니다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** 대부분의 프로덕션 에이전트 실패는 다섯 가지 원인에서 옵니다: 엣지 케이스를 처리하지 못하는 취약한 프롬프트, 일시적 API 오류에 대한 재시도 로직 부재, 무엇이 고장났는지 볼 수 없는 관측 가능성 부재, 종료 조건 없는 폭주 루프, 그리고 모델이 잘못된 것을 선택할 만큼 모호한 도구 정의. 다섯 가지 모두 모델이나 프레임워크를 변경하지 않고 수정 가능합니다. **[운영자 관점]** 프로덕션에서 30개 이상의 에이전트를 운영합니다. 이런 실패를 모두 경험했습니다. 가장 많은 시간을 소모한 것들은 신기한 문제가 아니었습니다——이미 처리했다고 생각했던 지루한 인프라 실패들이었습니다. ## 실패 1: 엣지 케이스 입력에서 깨지는 취약한 프롬프트 테스트 케이스에서 작동하는 프롬프트는 예상하지 못한 입력에서 실패합니다. 이것은 모델 한계가 아닙니다——명령 작성 문제입니다. **증상:** 에이전트가 무의미한 출력을 생성하거나, 잘못된 도구를 호출하거나, 테스트한 것과 입력이 약간 다를 때 형식이 잘못된 JSON을 출력합니다. **근본 원인:** 시스템 프롬프트가 해피 패스만 설명합니다. 데이터가 없거나, 형식이 잘못되거나, 모호할 때 모델에게 무엇을 해야 하는지 말하지 않습니다. **수정:** 시스템 프롬프트에 명시적인 엣지 케이스 처리를 추가합니다: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` 모델은 엣지 케이스에 대한 명시적 지침을 안정적으로 따릅니다. 실수는 해피 패스 지침이 지저분한 케이스를 처리하기 위해 일반화될 것이라고 가정하는 것입니다. ## 실패 2: 일시적 API 오류에 대한 재시도 로직 없음 에이전트가 호출하는 모든 외부 API는 언젠가 실패합니다. Claude API, Meta Graph API, 데이터베이스——모두 5xx 오류를 반환하거나, 타임아웃하거나, 속도 제한합니다. 에이전트에 재시도 로직이 없으면 하나의 일시적 오류가 전체 실행을 종료시킵니다. **증상:** 에이전트 실행이 다른 단계에서 임의로 실패합니다. 로그에 503 또는 429가 표시되고 후속 시도가 없습니다. **수정:** 모든 외부 호출을 지수 백오프 재시도로 래핑합니다: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` 지수 백오프를 포함한 세 번의 재시도는 일시적 실패의 약 99%를 처리합니다. 이것을 모든 외부 호출에 추가하면 임의 실패의 절반이 사라집니다. ## 실패 3: 관측 가능성 없음——무엇이 고장났는지 볼 수 없음 이것이 프로덕션에서 가장 일반적인 실패 모드이자 디버깅에 가장 많은 시간이 드는 것입니다: 에이전트가 조용히 실패하거나 잘못된 출력을 생성하는데, 체인의 어디서 잘못됐는지 알 수 없습니다. **증상:** 뭔가 잘못됐다는 것은 알지만 단계를 식별할 수 없습니다. `console.log` 구문을 추가하고 수동으로 재실행하며 재현을 시도합니다. **수정:** 모든 단계에서 구조화된 로깅, 전체 실행을 추적하는 실행 ID 포함: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` Cloudflare Workers를 사용하는 경우 이 로그는 Logpush 또는 Workers Tail로 갑니다. 로컬이나 VPS에서 실행 중이면 로그 집계기로 파이프합니다. 구조화된 JSON은 `runId`로 필터링하여 단일 실행에서 무슨 일이 있었는지 정확히 볼 수 있음을 의미합니다. ## 실패 4: 종료 조건 없는 폭주 루프 에이전트 루프——모델이 도구를 호출하고 조건이 충족될 때까지 반복하는——조건이 충족되지 않거나 모델이 잘못 식별하면 영원히 실행될 수 있습니다. **증상:** 에이전트가 타임아웃 전에 수백 달러의 API 비용을 지출합니다. 또는 진전 없이 같은 도구 호출을 반복합니다. **수정:** 항상 하드 반복 상한과 진행 확인을 갖습니다: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` 이것은 "너무 오래 실행됨"과 "제자리에서 맴돔" 두 가지 실패 모드를 모두 포착합니다. 상한은 해피 패스에는 충분히 너그럽지만 폭발 반경을 제한할 만큼 타이트해야 합니다. ## 실패 5: 모델이 잘못 해결하는 모호한 도구 정의 모델에게 설명이 겹치는 두 가지 도구를 주면 때때로 잘못된 것을 호출합니다. 이것은 `search_database` 대 `get_record` 또는 `send_email` 대 `create_draft` 같은 도구에서 특히 일반적입니다. **증상:** 모델이 올바른 카테고리의 도구를 호출하지만 잘못된 특정 도구를 선택합니다. 또는 잘못된 컨텍스트에서 도구를 호출합니다 (읽기만 적절할 때 쓰기 도구 사용). **수정:** 도구 설명을 상호 배타적으로 만들고 명시적으로 "언제 사용하지 말아야 하는지"를 추가합니다: ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` "X일 때 사용하지 말아야 한다" 조항은 대부분의 사람들이 건너뛰는 부분입니다. 이것이 가장 중요한 부분입니다. 모델은 긍정적인 설명에서 추론하는 것보다 명시적인 부정적 제약을 따르는 것을 더 잘합니다. ## 한 가지 더: 나쁜 입력으로 에이전트 테스트하기 대부분의 에이전트는 깨끗한 해피 패스 입력에서만 테스트됩니다. 프로덕션에는 지저분한 입력이 있습니다: 빈 문자열, null 필드, 유니코드 엣지 케이스, 200을 반환하지만 예상치 못한 스키마를 가진 API 응답. 다음을 명시적으로 테스트하는 테스트 스위트를 추가합니다: - 빈 또는 null 입력 - 예상 최대 길이의 입력 - 특수 문자 또는 비ASCII 텍스트가 있는 입력 - 예상치 못한 응답 형태를 반환하는 외부 API 에이전트가 이 중 어느 것에서 깨지면 라이브 전에 수정하세요. 프로덕션 환경이 당신이 한 모든 가정을 찾아낼 것입니다. ## 운영자의 최종 결론 프로덕션에서의 대부분의 에이전트 실패는 모델 문제로 위장한 인프라 문제입니다. 모델을 전환하기 전에 프롬프트에 재시도, 구조화된 로깅, 루프 상한, 명시적인 엣지 케이스 처리를 추가하세요. 모호한 도구 정의를 수정하세요. 그런 다음 나쁜 입력으로 테스트하세요. 모델을 탓하기 전에 이 모든 것을 하세요——내 경험상, 모델은 보통 마지막으로 변경이 필요한 것입니다. --- ## 15분 만에 첫 AI 에이전트 만드는 법 Source: https://alejandrorioja.com/ko/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-18 Tags: AI Agents TL;DR: 프레임워크도, 강의도, 박사 학위도 필요 없습니다. 필요한 것은 Node.js, Anthropic SDK, 그리고 25줄의 TypeScript뿐입니다. 이 튜토리얼은 실제로 작동하는 에이전트—같은 세션 안에서 Cloudflare에 배포할 수 있는 구조화된 콘텐츠 요약기—를 만듭니다. 유일한 전제 조건은 무료 API 키입니다. ## 목차 _2026년 6월 업데이트._ **TL;DR:** 프레임워크도, 강의도, 박사 학위도 필요 없습니다. 필요한 것은 Node.js, Anthropic SDK, 그리고 25줄의 TypeScript뿐입니다. 이 튜토리얼은 실제로 작동하는 에이전트—같은 세션 안에서 Cloudflare에 배포할 수 있는 구조화된 콘텐츠 요약기—를 만듭니다. 유일한 전제 조건은 무료 API 키입니다. **[운영자의 시각]** AI로 자동화하고 싶어 하는 창업자들에게서 가장 자주 듣는 말은 "먼저 더 배워야 한다"입니다. 그럴 필요 없습니다. 에이전트 패턴은 단순하고, 그것을 이해하는 가장 빠른 방법은 직접 하나 만들어 보는 것입니다. 오늘 제가 처음부터 시작한다면 택할 정확한 경로를 소개합니다. ## 왜 대부분의 "AI 에이전트 만들기" 튜토리얼은 도움이 되지 않는가 그것들은 Python을 사용하거나(ML 엔지니어에게는 괜찮지만 그 외 모두에게는 마찰이 됩니다), LangChain 같은 프레임워크 뒤에 실제 코드를 숨기거나, 실제 업무에 연결하기에는 너무 추상적인 것을 만듭니다. 이 튜토리얼은 세 가지를 다르게 합니다. 1. **TypeScript만 사용** — JavaScript를 써 본 적이 있다면 이것을 따라올 수 있습니다 2. **프레임워크 없음** — 모델에 닿는 모든 코드 줄을 보게 됩니다 3. **유용한 결과물** — 고객 이메일, 리뷰, 회의 메모에 실제로 사용할 수 있는 구조화된 요약기를 만듭니다 ## 무엇을 만드는가 **콘텐츠 요약 에이전트**: 어떤 텍스트 블록이든 붙여 넣으면 일관된 형식의 구조화된 요약이 돌아옵니다. HTTP 요청 하나가 들어가고, 깔끔한 요약 하나가 나옵니다. 이것을 첫 프로젝트로 삼는 이유: 이 패턴—시스템 프롬프트 + 사용자 입력 → 구조화된 출력—은 제가 운영하는 모든 에이전트의 토대입니다. 시스템 프롬프트만 바꾸면 질문 응답기, 어조 재작성기, 분류기, 초안 생성기가 됩니다. 이것을 한 번 익히면 프로덕션 에이전트가 실제로 하는 일의 80%를 배운 셈입니다. ## 사전 준비물 (2분) - **Node.js 18 이상** — `node --version`으로 확인하세요. 필요하면 nodejs.org에서 설치하세요. - **Anthropic API 키** — [Claude](/recommends/claude)에서 가입하고 콘솔에서 키를 받으세요. 무료 티어로 작동합니다. - 터미널과 텍스트 편집기. Docker 없음. 가상 환경 없음. `pip install`도 전혀 없음. ## 1단계: 프로젝트 생성 (2분) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` 에이전트를 쉽게 실행할 수 있도록 `package.json`에 스크립트를 추가합니다. ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## 2단계: 에이전트 작성 (5분) `agent.ts`를 만들고 이것을 붙여 넣으세요. ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## 3단계: 실행하기 (1분) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` 예상 출력: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` 이것이 작동하는 AI 에이전트입니다. 실제 입력, 맞춤 시스템 프롬프트, 구조화된 출력. 전체가 30줄의 코드입니다. ## 4단계: 당신의 사용 사례에 맞게 커스터마이즈하기 시스템 프롬프트는 이 에이전트를 당신만의 것으로 만드는 유일한 요소입니다. 바로 끼워 넣어 쓸 수 있는 세 가지 대안을 소개합니다. **고객 리뷰 분류기:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: