멀티에이전트를 들으면 먼저 복잡한 그래프를 떠올렸다
지난 몇 년간 에이전트 플로우는 LangChain과 LangGraph로 짜 왔습니다. 상태를 노드에 담고 조건부 엣지로 분기를 만들고 실패하면 어디서부터 되감을지 그래프 위에 미리 그려두는 방식에 익숙해졌습니다. 그래서 "멀티에이전트"라는 말을 들으면 반사적으로 상태 스키마와 라우팅 로직부터 떠올렸습니다. 에이전트가 늘어나면 그래프도 함께 커진다고 생각했습니다.
2026년 8월 16일 파이콘 코리아에서 들은 세션은 그 전제를 흔들었습니다. 발표자는 온콜 알람이 울릴 때마다 모니터링, 배포 이력, 슬랙 공지, 티켓, 뉴스를 한 사람이 순서대로 확인해야 했던 문제로 발표를 시작했습니다. 다섯 곳을 다 보고 나서야 장애인지 아닌지 판단이 났다고 했습니다. 이 문제를 어떻게 자동화했는지 들으면서 제가 멀티에이전트를 그래프의 문제로만 좁혀서 보고 있었다는 걸 깨달았습니다.
발표가 보여준 것은 거대한 오케스트레이션이 아니었다
발표에서 소개한 구조는 판단을 맡는 메인 에이전트 하나와, 데이터 소스별로 하나씩 붙는 도구 에이전트 여러 개였습니다. 모니터링, 배포툴, 슬랙, 티켓, 뉴스마다 각자의 API와 쿼리 문법을 아는 에이전트가 따로 있고 메인 에이전트는 그 문법을 전혀 모릅니다. 메인 에이전트가 가진 도구는 ask(target_agent, query) 하나뿐입니다. "이 알람이 최근 배포와 관련 있는지 확인해줘" 같은 자연어 질문을 던지면 해당 도구 에이전트가 알아서 자기 소스를 조회하고 결과를 돌려줍니다.
이 구조가 눈에 들어온 이유는 단일 에이전트에 API를 전부 직결했을 때 생기는 문제와 대비됐기 때문입니다. 도구가 많아질수록 스키마와 쿼리 문법이 전부 메인 프롬프트로 들어가면서 컨텍스트가 커지고 어떤 도구를 골라야 할지 LLM의 선택 정확도도 떨어집니다. 도구 에이전트로 쪼개면 새 데이터 소스를 추가할 때 드는 비용이 "도구 에이전트 하나와 메인 프롬프트 한 줄"로 고정됩니다. LangGraph에서 노드와 엣지를 늘리는 것과 완전히 다른 확장 방식은 아니지만 그래프를 먼저 설계하지 않고도 같은 효과를 얻는다는 점이 새로웠습니다.
이 패턴이 모든 경우에 낫다는 뜻은 아닙니다. 발표자는 규칙이 닫혀 있는지(예외를 다 나열할 수 있는지) 열려 있는지(휴리스틱이 필요한지)를 기준으로 코드로 짤지 에이전트에 맡길지를 나눈다고 했습니다. 판단을 통째로 에이전트에 위임하는 게 아니라, 그 경계를 계속 관찰하면서 좁혀가는 운영 방식이었습니다.
내가 멈춰서 본 지점은 출력의 모양이었다
가장 눈여겨본 부분은 따로 있었습니다. PydanticAI는 각 에이전트의 출력 타입을 Pydantic 모델로 고정합니다.
class Finding(BaseModel):
suspicious: bool
opinion: str
evidence: str
agent = Agent(
"openai:gpt-5-mini",
instructions="알람 시각과 배포가 겹치면 의심하라",
output_type=Finding,
)output_type을 지정하면 응답이 이 스키마를 벗어날 때 프레임워크가 알아서 재시도합니다. 인상 깊었던 이유는 파싱 오류가 줄어든다는 점 자체보다, 다음 단계가 무엇을 받을지 미리 알 수 있다는 점이었습니다. 메인 에이전트의 ask() 함수는 도구 에이전트가 무엇을 돌려줄지 정확히 알고 그 위에서 종합 판단을 짭니다.
@main_agent.tool_plain
async def ask(target_agent: str, query: str):
"""도구 에이전트에게 자연어로 질의"""
return await AGENTS[target_agent].run(query)LangGraph에서도 상태 스키마를 TypedDict나 Pydantic으로 정의해서 비슷한 걸 할 수 있습니다. 다만 그 스키마가 그래프 상태 전체에 걸쳐 있는 것과, 에이전트 하나의 출력 계약으로 국소적으로 붙어 있는 것은 체감이 달랐습니다. 도구 에이전트를 새로 추가할 때 건드릴 게 그 에이전트의 스펙과 출력 타입뿐이라는 점이, 그래프에 노드 하나를 끼워 넣고 앞뒤 엣지를 다시 확인하는 작업보다 가벼워 보였습니다.
발표에서는 다섯 도구 에이전트를 병렬로 호출해서 순차 처리로 22초 걸리던 걸 11초로 줄였다는 사례도 소개했습니다. 이 수치는 발표에서 소개한 운영 사례이고 제가 직접 검증한 것은 아닙니다.
다음 워크플로에서 검증해 볼 것
아직 기존 워크플로를 PydanticAI로 옮기지는 않았습니다. LangGraph로 짜둔 상태 관리와 복구 경로가 지금 당장 문제를 일으키고 있는 것도 아니라서, 전체 마이그레이션을 검토할 이유는 없습니다.
다음으로 시험해볼 것은 좁고 비파괴적인 한 흐름입니다. 여러 에이전트가 관여하는 파이프라인 중 하나를 골라, 도구 에이전트의 출력을 Pydantic 모델로 고정하고 메인 에이전트가 그 계약 위에서만 판단하게 만드는 구조를 실험해볼 생각입니다. 그래프를 먼저 그리지 않고도 시작할 수 있는지, 그 얇은 위임 구조가 실제로 유지보수를 가볍게 만드는지 확인한 다음에야 더 넓은 범위로 가져갈지 판단할 것 같습니다.