멀티 에이전트

멀티 에이전트란?

멀티 에이전트를 붙이면 가장 먼저 달라지는 것은 결과물의 품질이 아니라 작업을 쪼개는 단위입니다. 프롬프트 하나에 조사부터 작성까지 다 밀어 넣던 방식은 결과가 시원찮을 때 어디서 틀어졌는지 알 길이 없어, 지시문만 계속 고쳐 쓰게 됩니다. 역할을 나누면 단계마다 중간 산출물이 남습니다. 자료가 부실했는지, 초안이 겉돌았는지, 검토가 헐거웠는지 실패한 칸을 지목해 그 칸만 손볼 수 있습니다. 정확도보다 관리 가능성이 먼저 올라가는 셈입니다.

구조는 크게 셋으로 나뉩니다. 오케스트레이터가 일을 배분하고 결과를 합치는 감독형, 앞 에이전트의 출력이 그대로 뒤로 넘어가는 순차형, 같은 문제를 둘 이상이 각자 풀고 답을 맞춰 보는 교차검증형입니다. 국내 기업이 실제로 굴리는 건 감독형에 순차형을 얹은 절충안이 대부분입니다. 대신 값을 치릅니다. 에이전트를 하나 늘릴 때마다 모델 호출과 토큰이 단순 합이 아니라 곱으로 불어나고, 응답 대기도 단계 수만큼 쌓입니다. 단계가 서넛, 도구가 두어 개인 일이라면 단일 에이전트가 더 빠르고 쌉니다.

에이전틱 워크플로우와의 경계도 자주 헷갈립니다. 워크플로우는 한 에이전트가 계획을 세우고 도구를 번갈아 쓰며 스스로 반복하는 것이고, 멀티 에이전트는 각자 다른 지시문과 권한, 도구 목록을 가진 주체가 여럿인 구조입니다. 쪼갤 때인지 판단하는 기준은 의외로 단순합니다. 한 지시문 안에 상충하는 규칙이 섞이기 시작할 때입니다. '간결하게 써라'와 '근거를 전부 각주로 달아라'가 한 프롬프트에 같이 들어가면 모델은 매번 다르게 타협합니다. 사내 DB를 읽는 권한과 외부 웹을 뒤지는 권한을 갈라 둬야 할 때도 마찬가지입니다.

가장 흔한 오해는 에이전트를 많이 붙일수록 똑똑해진다는 생각입니다. 실제로는 앞 단계가 숫자 하나를 잘못 옮겨도 뒤 단계는 그것을 사실로 받아 그럴듯한 문장으로 다듬어 놓습니다. 검토 에이전트도 원본을 다시 열지 않으면 이 오류를 잡지 못합니다. 종료 조건을 걸지 않아 두 에이전트가 보완 요청을 주고받다 호출만 수십 번 쌓이고, 그 사실을 월말 청구서로 확인하는 경우도 있습니다. 착수 전에 에이전트별 입출력 형식과 재시도 횟수, 사람이 끊고 들어가는 지점을 문서로 못 박아 두십시오.