멀티 에이전트 리서치 어시스턴트는 “검색”, “자료 판단”, “분석”, “최종 보고”를 한 모델 호출에 모두 맡기지 않고 역할별 에이전트로 나눠 처리한다. 복잡한 질문에서 근거 누락과 출처 없는 답변을 줄이는 실용적인 패턴이다.

전체 구조

이 구조의 장점은 실패 지점을 분리할 수 있다는 것이다. 검색이 부족한지, 판단 기준이 느슨한지, 최종 합성이 과장됐는지 추적하기 쉽다.

구현 흐름

1. 환경 설정

Python 가상환경을 만들고 LLM SDK, 검색/스크래핑 API 클라이언트, 구조화 출력용 Pydantic 모델을 설치한다. 튜토리얼 원문은 Olostep 검색·스크래핑 API를 사용하지만, Tavily, Exa, SerpAPI, 자체 크롤러로 바꿔도 구조는 같다.

2. 도구 함수 작성

리서치 에이전트에는 최소 네 가지 도구가 필요하다.

• answer_query: 질문에 대한 직접 답변 시도
• search_web: 쿼리로 후보 문서 검색
• search_with_scrape: 검색 결과 상위 문서 본문까지 추출
• scrape_url: 특정 URL 본문 추출

도구 결과는 자연어 문자열보다 구조화된 객체로 받는 편이 좋다. URL, 제목, 본문 요약, 수집 시각, 신뢰도 같은 필드를 분리하면 Judge Agent가 근거를 더 안정적으로 평가한다.

3. 역할별 에이전트 정의

Judge Agent는 “이 질문에 답하기에 자료가 충분한가”를 판단한다. 부족하면 어떤 추가 검색이 필요한지 반환한다.

Analyst Agent는 자료를 읽고 주장, 근거, 반례, 불확실성을 추출한다.

Manager Agent는 질문을 받고 다음을 반복한다.

1. 초기 검색 실행
2. Judge에게 충분성 평가 요청
3. 부족하면 검색 쿼리 보강
4. Analyst에게 evidence synthesis 요청
5. 최종 답변 생성

4. 추적과 UI 붙이기

Tracing은 선택 사항이 아니라 디버깅 도구다. 리서치 에이전트는 검색 쿼리 하나가 틀어지면 최종 답변 전체가 흔들린다. 어떤 URL을 읽었고, 어떤 근거를 버렸고, 왜 추가 검색을 했는지 기록해야 품질 개선이 가능하다.

간단한 Web UI는 Reflex 등으로 붙일 수 있다. 다만 프로덕션에서는 UI보다 더 중요한 것이 실행 로그, rate limit, 캐시, 재시도 정책이다.

설계 팁

• Manager가 모든 것을 직접 판단하지 않게 한다. 역할을 나누면 프롬프트가 짧아지고 평가가 쉬워진다.
• Judge의 출력은 sufficient: true/false, missing_information, next_queries처럼 구조화한다.
• 출처 URL을 최종 답변에서 제거하지 않는다.
• 검색 결과가 서로 충돌하면 최종 답변에 불확실성을 명시한다.
• 동일 질문 재실행 비용을 줄이기 위해 검색 결과와 스크랩 본문을 캐시한다.

언제 별도 시스템으로 만들 가치가 있는가

단순 Q&A라면 일반 검색+요약으로 충분하다. 하지만 다음 조건이면 멀티 에이전트 구조가 유리하다.

• 질문이 여러 하위 질문으로 나뉜다.
• 근거 품질 평가가 중요하다.
• 출처가 상충할 수 있다.
• 리서치 과정을 감사하거나 재현해야 한다.
• 사용자가 보고서 수준의 답변을 기대한다.

관련 문서

• deep-research-max — 자율 리서치 보고서 생성 에이전트
• ai-q-skill — 에이전트 하네스에 딥리서치 백엔드를 붙이는 NVIDIA 방식
• feynman — 멀티 에이전트 병렬 딥리서치 도구
• rag — 검색 증강 생성 기본 개념

참고 자료

• How to Build a Multi-Agent Research Assistant in Python — MachineLearningMastery (2026-05)