[PyCon Korea 2026] 멀티 에이전트 진입장벽 낮추기 PydanticAI로 구축·운영·모니터링까지- 이채승
조회수 126회·1개월 전·길이 미제공
아직 이 영상의 타임라인이 없어요.
영상 설명 원문 보기
Summary 3 AM, a CPU 95% alarm. You can't tell whether it's an actual incident just by looking at the alarm. The on-call engineer checks five or more tools in sequence - monitoring, deploy tools, communication channels, tickets, news - before concluding "incident or not." The problem: that checklist isn't written down anywhere. It's a heuristic that varies with each engineer's experience. This talk introduces an on-call support agent that automates that heuristic judgment with natural language. Introduction 1. Building Agents with PydanticAI No new DSL or graph syntax: a Pydantic model becomes the output contract A simple Agent definition covering MCP connections, role prompts, and output types 2. Why and How to Split a Single Agent into Multiple Agents "Register one function that calls tool agents as the main agent's tool" What goes wrong when you attach dozens of tools to one agent: context bloat and degraded tool selection accuracy One decision agent + five tool agents, one per data source A rule for what to delegate to agents (open rules) versus what to write as code (closed rules) 3. Three Sample Cases A traffic surge caused by an earthquake, a disk fault, and a never-before-seen alarm resolved by a maintenance notice How the five agents' findings intersect to reach the root cause 4. Operations and Monitoring Langfuse integration that starts with a single line, observing parallel execution and cost An improvement cycle: spot repeated judgments in traces, confirm them as closed rules, and push them down into code Target Audience Anyone who felt the learning curve of frameworks like LangChain was too steep Anyone who has been putting off multi-agents as "too complex" Anyone who wants to automate repeated judgments in their daily work (Optional) Familiarity with basic Python and LLM APIs --- 요약 새벽 3시, CPU 95% 알람. 이게 장애인지 아닌지는 알람만 봐서는 알 수 없습니다. 온콜 담당자는 모니터링, 배포툴, 커뮤니케이션 채널, 티켓, 뉴스.. 다섯개 이상의 도구를 순서대로 확인한 뒤에야 "장애다 / 아니다"를 판단합니다. 그런데 그 확인 절차는 문서에 없고, 담당자의 경험에 따라 달라지는 휴리스틱입니다. 이 휴리스틱 판단을 자연어로 자동화한 온콜 서포트 에이전트를 소개합니다. 소개 내용 1. PydanticAI로 에이전트 만들기 새 DSL이나 그래프 문법 없이, Pydantic 모델이 곧 출력 계약이 되는 구조 MCP 연결, 역할 프롬프트, 출력 타입까지 간단한 Agent 정의 2. 단일 에이전트를 멀티로 나누는 이유와 패턴 "툴 에이전트를 호출하는 함수 하나를 메인의 도구로 등록한다" 툴 수십 개를 한 에이전트에 붙이면 생기는 컨텍스트 비대화와 툴 선택 정확도 하락 판단 에이전트 하나 + 데이터소스별 툴 에이전트 다섯 에이전트에 시킬 일(열린 규칙)과 코드로 짤 일(닫힌 규칙)을 가르는 기준 3. 샘플 케이스 세 가지 지진으로 인한 트래픽 급증, 디스크 Fault, 처음 보는 알람과 작업 공지 다섯 에이전트의 의견이 교차하며 Root Cause에 도달하는 과정 4. 운영과 모니터링 한 줄로 시작하는 Langfuse 연동, 병렬 실행과 비용까지 관측 trace에서 반복 판단을 발견하면 닫힌 규칙으로 확정하고 코드로 내리는 개선 사이클 대상 청중 LangChain 등 기존 프레임워크의 학습 곡선에 부담을 느낀 분 멀티 에이전트를 "복잡한 것"으로 미뤄두고 있던 분 다양한 업무의 반복 판단을 자동화하고 싶은 분 (선택) Python 기본 문법과 LLM API 사용 경험이 있는 분 --- argon I'm Chaeseung Lee (argon), working at LINE Plus on OpenChat SRE, AWX administration, and AI agent development. --- 이채승 라인플러스에서 Openchat SRE와 AWX Admin, 그리고 AI Agent 개발을 담당하고 있는 이채승입니다.