LLM과 에이전트를 설계하는 실무 실험실
공모전에 낼 외환 MCP를 짜면서 도구 하나하나에 대해 “이건 안 만든다”를 먼저 정한 기록 필자는 핀테크에서 AI를 다룬다. 그동안 MCP는 쓰는 쪽이었다. Claude Code에 서버를 붙이고 남이 만든 도구를 호출하고. 가끔 응답이 이상하면 로그를 들여다보는 정도. 만드는 쪽은 처음이었다. 마침 카카오에서 여는 에이전트 공모전이 있었고 “외환 환율을 다루는 MCP 서버”를 출품해 보기로 했다. (나는 환전업 … 더 읽기
– 금융 도메인에서 Tool 권한을 설계하며 배운 것들 지난 글에서 Orchestrator와 Agent의 역할을 분리하는 이야기를 했다. 그 글 마지막에 이렇게 썼다. “다음 글에서는 Agent에게 어떤 Tool을 어떻게 제한적으로 열어줬는지를 정리해보려 한다.” 이번 글은 그 이야기다. 1. Tool을 열어주는 순간, 통제권이 넘어간다 Agent에게 Tool을 주는 건 생각보다 무거운 결정이다. LLM이 텍스트만 생성할 때는 최악의 경우가 “이상한 … 더 읽기
— 멀티 에이전트에서 State와 메시지 버스로 상태를 관리하며 겪은 혼란 멀티 에이전트를 설계하기 시작하면자연스럽게 이런 생각이 든다. “각자 역할을 나눠서 서로 이야기하게 하면 되지 않을까?” 사람 팀처럼 말이다. 내가 만들던 멀티 에이전트 구조도 그랬다.Planner가 계획을 세우고,Executor가 코드를 실행하고,Reviewer가 결과를 검토한다. 겉으로 보면 꽤 그럴듯한 협업 구조다.단일 Agent보다 더 똑똑해 보이기도 하고실제로 역할 분담도 명확해 보였다. … 더 읽기
LLM은 “판단하는 도구”이지,시스템의 규칙과 책임까지 대신 설계해주지는 않는다. LangChain으로 Agent를 설계하다 보면 어느 순간부터 이런 프롬프트를 쓰고 있는 나를 발견하게 된다 “적절히 판단해서 처리해줘” “상황에 맞게 알아서 결정해줘” 이게 나만의 문제는 아니라고 생각한다 LLM은 너무 똑똑해보이고 실제로 웬만한 질문에는 그럴듯한답을 내놓기 때문이다. 특히 멀티 에이전트 구조를 만들 때는 더 그렇다 각 에이전트가 역할을 나눠서 추론하고, … 더 읽기
튜토리얼은 따라가는데 혼자 설계하려면 손이 멈추는 이유 AI 개발자에 입문하면 가장 많이 듣는 툴, LangChain. LangChain 공식 튜토리얼을 보면 에이전트를 만드는 건 생각보다 쉬워 보인다. Tool 붙이고, Memory 추가하고, Agent를 하나 선언하면 끝이다. 그런데 막상 내 문제를 풀어보려고 하면 손이 멈춘다. “뭐부터 해야 하지?” 이 글은 에이전트가 무엇인지 설명하려는 글이 아니다. 왜 혼자 설계하려고 하면 … 더 읽기