Next-BlockChain

워크플로우 vs 에이전트 — 챕터 9 의 결정적 정리, 그리고 "워크플로우 우선" 의 이유이 챕터의 첫 글(#55)에서 우리는 워크플로우와 에이전트를 처음 분류했고, Chaining(#56) → Routing(#57) → Agents and tools(#58) → Environment inspection(#59) 까지 거치면서 양쪽의 구체적 사용법을 익혔습니다. 🎓이제 마지막 정리 시간이에요. "실무에서 둘 중 무엇을 골라야 하나?" 라는 가장 중요한 질문에 답할 준비가 됐습니다. 결론부터 던지면 — "가능하면 워크플로우, 정말 필요할 때만 에이전트." 왜 그런지 본격적으로 풀어볼게요. 🎯🧭 한눈에 보는 정의워크플로우(Workflow)알려진 문제(또는 문제군)를 풀기 위한 사전에 정의된 Claude..

AI 2026. 6. 16. 22:47

환경 점검(Environment Inspection) — 눈먼 에이전트가 시야를 갖는 순간지난 글(#58)에서 우리는 "도구는 추상적이어야 한다" 는 원칙을 다뤘습니다. 좋은 도구 세트만 있으면 에이전트가 강력해진다는 거였죠. 그런데 도구만큼 중요하지만 자주 간과되는 한 가지가 더 있습니다. 👀바로 환경 점검(Environment Inspection) 입니다.핵심 비유부터 던질게요. 도구를 주는 건 손을 달아주는 것이고, 환경 점검을 시키는 건 눈을 달아주는 것 이에요. 손만 있고 눈이 없으면? 어둠 속에서 더듬더듬 할 뿐입니다. 오늘 글은 여러분의 에이전트에게 시야를 달아주는 방법에 관한 이야기예요. 🔍🤔 왜 환경 점검이 그렇게 중요한가?Claude 는 "눈먼 실행자" 다기본 가정을 다시 세팅합시..

AI 2026. 6. 13. 11:10

에이전트와 도구 — 도구를 "추상적으로" 설계해야 에이전트가 똑똑해지는 이유지금까지 우리는 워크플로우의 세 가지 패턴 — Chaining, Routing, Evaluator-Optimizer — 를 살펴봤습니다. 이제 시점이 바뀝니다. 🔄이번 강의부터는 에이전트(Agent) 의 영역이에요. 워크플로우가 "개발자가 단계를 미리 정해놓는" 세계였다면, 에이전트는 "목표와 도구만 던져주고 Claude 가 알아서 푸는" 세계입니다. 그리고 이 세계에선 도구를 어떻게 설계하느냐가 결과의 8할을 결정해요. 🛠️오늘 글의 핵심 메시지: "도구는 추상적일수록 강력하다." 왜 그런지, Claude Code 의 사례까지 끌고 와서 풀어보겠습니다. 🎯🔄 워크플로우에서 에이전트로 — 시점의 전환구분워크플로우에이전트🧭..

AI 2026. 6. 12. 21:26

라우팅(Routing) 워크플로우 — 입력에 따라 다른 길로 보내는 "교통 정리" 패턴체이닝(Chaining)이 "하나씩 순서대로" 였다면, 라우팅(Routing)은 "입력 종류에 따라 다른 길로" 보내는 패턴입니다. 🛤️오늘 글의 핵심 질문은 이거예요. "같은 챗봇 / 같은 도구라도, 사용자 요청 유형이 너무 달라서 하나의 프롬프트로 다 잘 처리할 수 없을 때 어떻게 할까?" 답은 의외로 단순합니다 — 입력을 먼저 분류한 다음, 그에 맞는 전문 파이프라인으로 보낸다. 우리가 평소에 병원 접수처에서 진료과별로 흩어지는 것과 똑같은 아이디어예요. 🏥🤔 왜 라우팅이 필요한가? — 일반 프롬프트의 한계원문 강의의 시나리오로 시작해봅시다. 사용자 주제 → 영상 스크립트 자동 생성 마케팅 도구.사용자 입력적..

AI 2026. 6. 11. 00:18

체이닝(Chaining) 워크플로우 — "한 방에 다 시키지 말고, 한 번에 하나씩" 시키는 기술지난 글(#55) 에서 워크플로우와 에이전트의 큰 그림을 잡았다면, 이번엔 가장 단순하면서도 가장 자주 쓰이는 워크플로우 패턴 — 체이닝(Chaining) 차례입니다. 🔗이름은 직관적이고 심지어 너무 당연해 보여요. 그래서 많은 개발자가 가볍게 여기고 넘어가는데, 사실 Claude API 활용에서 결과 품질을 가장 크게 끌어올리는 한 끗 이 바로 이 패턴입니다. 진짜로요. 오늘 글을 다 읽으면 "하나의 거대한 프롬프트" 라는 유혹과 영영 작별하실 거예요. 👋🤔 체이닝이란?한 줄 정의: 큰 작업을 작고 순차적인 하위 작업들로 쪼개고, 각 단계의 출력을 다음 단계의 입력으로 흘려보내는 패턴.[입력] ▼[..

AI 2026. 6. 10. 07:50

워크플로우(Workflow) vs 에이전트(Agent) — 둘 다 만들 줄 아는 개발자가 되기 위한 분기점이번 챕터로 우리는 마지막 본격 주제에 들어섭니다 — 에이전트와 워크플로우. 이름은 거창하지만 사실 여러분은 이미 둘 다 만들어봤어요. 챕터 4에서 도구를 사용하면서, 챕터 5에서 RAG 파이프라인을 짜면서, 챕터 7에서 MCP 서버를 만들면서. 🛠️오늘 글의 임무는 그 모든 경험을 두 가지 추상화로 깔끔하게 정리하는 것입니다. 그러면 여러분은 다음에 새 기능을 설계할 때 "이건 워크플로우인가, 에이전트인가?" 라는 결정적 질문을 빠르게 던질 수 있게 됩니다. 이 분류 능력이 시니어와 주니어를 가르는 핵심 차이 중 하나예요. 🎯🤔 왜 한 번의 호출로는 부족한가?먼저 출발점을 확인하고 갑시다. 워..

AI 2026. 6. 8. 23:24

MCP 클라이언트에서 리소스 읽기 — @report.pdf 가 Claude 에게 전달되는 진짜 경로지난 강의에서 우리는 MCP 클라이언트의 두 가지 책임 — list_tools() 와 call_tool() 을 구현하며 도구(tools) 사용을 끝냈습니다. 하지만 MCP 서버는 도구 외에도 리소스(resources) 를 노출할 수 있다는 사실, 기억하시죠? 📂오늘은 클라이언트 측에서 리소스를 직접 읽어 들이는 방법 을 다룹니다. 사용자가 채팅창에 @report.pdf 라고 치면, 그 문서의 내용이 자동으로 프롬프트 안에 삽입되어 Claude 에게 전달되는 그 마법의 정체를 풀어볼 시간이에요. ✨🧭 리소스 vs. 도구 — 왜 굳이 따로 있을까?먼저 짚고 가야 할 게 있어요. "문서 내용을 가져오는 일이 ..

AI 2026. 6. 3. 11:49

MCP 클라이언트 직접 구현하기 — stdio 로 서버에 붙는 코드 두 개의 핵심 메서드지금까지 우리는 MCP 서버의 도구 정의 까지 끝내고, Inspector 로 검증까지 마쳤습니다. 이제 진짜 챗봇이 이 서버를 활용할 수 있도록, 클라이언트 쪽 코드를 직접 작성할 차례입니다. 🔗오늘 강의에서는 두 개의 핵심 메서드 — list_tools() 와 call_tool() — 를 구현하면서 Claude ↔ MCP 서버 사이를 잇는 다리를 완성합니다. 챕터 7의 클라이맥스이자, 챗봇이 비로소 살아 움직이기 시작하는 지점이에요. 🎬🏛️ 클라이언트 아키텍처 — 두 개의 컴포넌트⚠️ 다시 한 번 환기: 실제 운영 프로젝트에선 클라이언트 OR 서버 중 하나만 만듭니다. 양쪽 다 만드는 건 학습 목적!우리가 만들..

AI 2026. 6. 3. 10:59