검색을 할 줄 아는 AI와 조사를 할 줄 아는 AI는 다르다. 전자는 질문을 받으면 그럴듯한 답을 빨리 내놓는다. 후자는 질문을 작은 문제로 나누고, 필요한 정보를 찾고, 출처를 붙잡고, 서로 충돌하는 근거를 비교한 뒤, 어디까지가 사실이고 어디부터가 해석인지 구분해서 말한다. 좋은 리서치 에이전트는 바로 이 두 번째에 가깝다.
이 장의 목표는 검색형 AI를 단순한 요약기가 아니라 근거 중심 조사 도구로 바꾸는 것이다. 핵심은 모델이 똑똑한 척하게 만드는 데 있지 않다. 오히려 반대다. 모르면 찾게 하고, 찾았으면 출처를 남기게 하고, 출처가 약하면 자신 있게 단정하지 못하게 만드는 데 있다.
리서치 에이전트는 무엇을 해야 하는가
리서치 에이전트의 일은 생각보다 소박하다. 사용자의 큰 질문을 바로 정답으로 바꾸지 않고, 먼저 조사 가능한 작업으로 번역하는 것이다. LangChain의 딥 리서치 예제도 이 흐름을 분명하게 보여 준다. 질문을 하위 과제로 분해하고, 각각을 별도 맥락에서 조사하게 한 뒤, 결과를 다시 모아 인용이 포함된 최종 보고서로 합친다.1
여기서 중요한 점은 "검색"이 중심이 아니라는 것이다. 중심은 조사 과정의 설계다. 어떤 순서로 찾을지, 무엇을 먼저 확인할지, 언제 추가 검색을 할지, 어느 시점에서 충분하다고 판단할지를 정해야 한다. 즉 리서치 에이전트는 답변 생성기라기보다 작은 조사팀의 진행자에 가깝다.
기본 구조는 질문에서 보고서까지 이어지는 파이프라인이다
실전에서 가장 안정적인 구조는 다음과 같다.
질문 이해
질문 분해
검색 쿼리 생성
출처 수집과 정리
근거 기반 요약
인용과 불확실성 표시
이 순서를 대충 섞으면 문제가 생긴다. 예를 들어 아직 질문 분해가 끝나지 않았는데 검색부터 하면, 넓지만 얕은 결과만 잔뜩 모인다. 반대로 출처를 정리하지 않고 요약부터 하면, 마지막에 "이 문장은 어디서 왔지?"라는 재난이 시작된다.
LangChain은 이런 작업을 만들 때 고정된 코드 경로를 따르는 워크플로와, 도구를 사용하며 스스로 다음 행동을 정하는 에이전트를 구분한다. 리서치 작업은 둘을 적절히 섞는 편이 좋다. 큰 틀은 워크플로처럼 관리하되, 검색과 후속 탐색은 에이전트처럼 유연하게 움직이게 만드는 방식이다.2
첫 단계는 답을 찾는 것이 아니라 질문을 분해하는 것이다
복잡한 질문은 한 번에 검색하면 잘 안 잡힌다. 이유는 간단하다. 질문 속에 비교, 기간, 원인, 예외, 맥락이 한꺼번에 들어 있기 때문이다. 검색 엔진도, 벡터 검색도, LLM도 이런 복합 질문을 한 덩어리로 처리하면 중요한 신호를 놓치기 쉽다.
예를 들어 사용자가 "RAG와 파인튜닝의 차이를 실제 운영 비용, 최신성, 보안 관점에서 비교해 달라"고 묻는다고 해 보자. 이 질문은 사실 하나가 아니다. 적어도 다음과 같은 하위 질문으로 나눌 수 있다.
RAG의 특징과 장단점은 무엇인가
파인튜닝의 특징과 장단점은 무엇인가
운영 비용은 어떤 항목으로 비교해야 하는가
최신성 문제는 두 방식에서 어떻게 다르게 나타나는가
보안과 데이터 통제 측면에서 차이는 무엇인가
이렇게 쪼개면 검색의 품질이 바로 좋아진다. NVIDIA 문서도 질의 분해가 다단계 추론이나 맥락이 많은 질문의 정확도를 높인다고 설명한다. 반대로 단순 사실 질문에는 오히려 과한 비용과 지연만 늘릴 수 있다고 말한다.3 즉 분해는 만능 기술이 아니라 복잡한 질문에만 켜는 선택적 장치여야 한다.
최근 연구도 같은 방향을 보여 준다. 질문을 하위 질문으로 분해하고, 각 하위 질문에 대해 문서를 검색한 뒤, 결과를 다시 재정렬하면 다중 문서에 흩어진 근거를 더 잘 모을 수 있고 답변 정확도도 올라간다.4
질문 분해는 세 종류로 나누면 실무에서 다루기 쉽다
질문 분해를 막연히 하지 말고, 세 가지 유형으로 구분하면 설계가 쉬워진다.
첫째는 병렬형 분해다. 서로 독립적인 하위 질문으로 나누는 방식이다. "A와 B의 차이"처럼 비교형 질문이 대표적이다. 이런 경우에는 여러 검색 작업을 동시에 돌리기 좋다.
둘째는 순차형 분해다. 앞의 답을 알아야 뒤를 물을 수 있는 경우다. "Slack을 인수한 회사의 현재 CEO는 누구인가" 같은 질문이 여기에 속한다. 먼저 인수 주체를 찾고, 그다음 CEO를 찾아야 한다.
셋째는 관점형 분해다. 하나의 주제를 비용, 성능, 법률, 사용자 경험처럼 서로 다른 렌즈로 나누는 방식이다. 보고서형 조사에서 특히 강력하다.
좋은 리서치 에이전트는 이 세 유형을 구분해 다르게 처리한다. 병렬형은 동시에, 순차형은 단계적으로, 관점형은 섹션별로 조사하게 만든다.
검색 쿼리는 하나가 아니라 묶음으로 설계해야 한다
초보자는 좋은 질문 하나를 좋은 검색어 하나로 바꾸려 한다. 하지만 실전 리서치는 그렇게 되지 않는다. 하나의 질문에는 보통 여러 종류의 검색 쿼리가 필요하다.
예를 들어 쿼리 묶음은 보통 이런 식으로 구성된다.
주제 확인용 쿼리: 개념 정의와 큰 그림을 잡는다.
정밀 확인용 쿼리: 특정 수치, 날짜, 정책, 기능을 검증한다.
비교용 쿼리: 두 대상의 차이를 같은 기준으로 찾는다.
최신성 확인용 쿼리: 최근 변경, 업데이트, 발표를 확인한다.
반례 탐색용 쿼리: 내가 세운 가설과 반대되는 근거를 일부러 찾는다.
이 다섯 가지를 함께 써야 검색 결과가 덜 편향된다. 특히 반례 탐색용 쿼리는 꼭 필요하다. AI는 처음 잡은 방향을 계속 강화하는 경향이 있다. 그러니 시스템 차원에서 "반대 근거도 찾아라"를 넣어 두는 편이 안전하다.
쿼리를 만들 때는 사용자의 원문을 그대로 재사용하기보다, 검색 엔진이 잘 먹는 형태로 다시 써야 한다. 너무 긴 문장은 쪼개고, 핵심 개체명은 앞에 두고, 비교 기준과 기간은 분명히 넣는다. "좋은 문장"보다 "찾기 쉬운 문장"이 중요하다.
여러 검색 결과를 그냥 붙이면 조사 품질은 오히려 떨어진다
검색 결과가 많다고 좋은 보고서가 되는 것은 아니다. 오히려 출처가 섞이고, 같은 내용이 반복되고, 약한 출처가 강한 출처인 척 끼어들기 쉽다. 그래서 리서치 에이전트에는 출처 수집 단계가 따로 있어야 한다.
이 단계에서 에이전트는 검색 결과를 단순 저장하지 말고, 최소한 다음 정보를 묶어서 관리해야 한다.
문서 제목과 URL
발행 주체와 문서 유형
작성일 또는 최신 수정일
핵심 주장 요약
관련 문장 또는 발췌
어떤 하위 질문에 대응하는 출처인지
신뢰도 메모
이 구조가 있으면 나중에 최종 요약에서 "무슨 말을 할 수 있는가"뿐 아니라 "왜 그렇게 말하는가"를 추적할 수 있다. 이 추적 가능성이 리서치 에이전트의 생명줄이다.
출처는 많이 모으는 것보다 다르게 모으는 것이 중요하다
좋은 조사자는 출처의 개수보다 출처의 역할 분담을 본다. 같은 주장만 반복하는 블로그 다섯 개보다, 원문 정책 문서 하나와 공식 문서 하나, 그리고 이를 해설하는 분석 글 하나가 더 낫다.
실무에서는 출처를 대략 네 층으로 구분해 두면 편하다.
1차 자료: 공식 발표, 원문 문서, 논문, 법령, 제품 문서
2차 자료: 전문 매체의 해설, 기술 블로그, 연구 요약
3차 자료: 커뮤니티 정리, 포럼, 개인 블로그
메타 자료: 비교표, 벤치마크, 인용 데이터베이스
리서치 에이전트는 가능하면 1차 자료를 우선하고, 2차 자료는 맥락 설명에 쓰고, 3차 자료는 아이디어 탐색이나 추가 쿼리 생성의 단서로 제한하는 편이 좋다. 출처의 위계를 무시하면 보고서 문체는 그럴듯한데 근거가 푹신푹신한 상태가 된다.
작은 조사원 여러 명이 한꺼번에 움직이게 하라
질문이 커질수록 한 에이전트에게 모든 것을 맡기면 맥락이 금방 오염된다. 방금 읽은 출처와 지금 읽는 출처가 뒤섞이고, 초반 가설이 후반 조사에 계속 영향을 준다. 그래서 실전에서는 오케스트레이터-워커 구조가 매우 유용하다. 상위 에이전트가 조사 계획을 세우고, 하위 조사 에이전트가 각 하위 질문을 따로 맡아 조사한 뒤, 상위 에이전트가 다시 결과를 합치는 구조다.2
LangChain의 딥 리서치 예제도 하위 조사 에이전트를 분리된 컨텍스트에서 돌리는 방식을 강조한다.1 이 방식이 좋은 이유는 단순히 병렬 처리라서 빠르기 때문만이 아니다. 더 중요한 이유는 오염 방지다. 경쟁 기술 A를 조사하는 에이전트와 기술 B를 조사하는 에이전트가 서로의 초기 편견을 공유하지 않게 만들 수 있다.
작게 나눈 에이전트는 다음처럼 역할을 분리할 수 있다.
플래너: 질문을 분해하고 조사 순서를 정한다.
서처: 검색 쿼리를 만들고 웹이나 데이터베이스를 뒤진다.
리더: 긴 문서를 읽고 핵심 근거를 뽑는다.
시서사이저: 서로 다른 근거를 엮어 답을 만든다.
베리파이어: 인용 누락, 과장, 최신성 문제를 점검한다.
이렇게 나누면 한 모델이 모든 판단을 한 번에 떠안지 않아도 된다.
조사 메모는 최종 답보다 먼저 만들어야 한다
리서치 에이전트 설계에서 자주 빠지는 단계가 있다. 바로 조사 메모다. 검색 결과를 읽고 나서 바로 답을 쓰게 하면, 모델은 자기가 읽은 자료를 머릿속에서 섞어 한 문장으로 봉합해 버린다. 그 순간 출처 추적은 어려워진다.
그래서 중간 단계로 메모를 남겨야 한다. 형식은 단순해도 좋다. 예를 들면 이런 식이다.
"하위 질문: RAG의 최신성 장점은 무엇인가 / 핵심 근거: 외부 지식 베이스를 갱신하면 모델 재학습 없이 반영 가능 / 출처: 공식 문서 A, 분석 글 B / 주의: 검색 품질이 낮으면 잘못된 정보가 유입될 수 있음"
이런 메모는 최종 문장보다 덜 화려하지만 훨씬 중요하다. 왜냐하면 나중에 보고서를 쓸 때, 모델이 메모를 근거 단위로 조립할 수 있기 때문이다. 조사 메모는 리서치 에이전트의 스크래치패드이자 재료 창고다.
근거 기반 요약은 "멋진 문장"보다 "추적 가능한 문장"이 우선이다
이제 가장 중요한 단계다. 리서치 에이전트는 수집한 자료를 단순히 줄이는 것이 아니라, 주장과 근거를 연결한 상태로 요약해야 한다. 이때 원칙은 분명하다. 중요한 문장일수록 근거가 가까이에 있어야 한다.
Cohere의 grounded summarization 가이드는 요약에 인용을 도입하면 사용자가 전체 문서를 다 읽지 않아도 사실성을 점검할 수 있다고 설명한다.5 즉 인용은 장식이 아니라 검증 인터페이스다.
실제로 좋은 요약은 다음과 같은 특징을 가진다.
첫째, 사실과 해석을 구분한다. 예를 들어 "2025년 3월 기능이 추가되었다"는 사실이고, "따라서 시장 우위가 강화될 가능성이 있다"는 해석이다. 둘은 같은 문단에 있어도 라벨이 달라야 한다.
둘째, 충돌하는 근거를 숨기지 않는다. 공식 문서는 장점을 말하고, 사용자 리뷰는 운영상의 불편을 지적할 수 있다. 이 경우 한쪽만 고르면 요약이 아니라 홍보다.
셋째, 비어 있는 부분을 인정한다. 충분한 출처가 없으면 결론을 약하게 말해야 한다. 리서치 에이전트가 신뢰를 얻는 순간은 무엇이든 아는 척할 때가 아니라, 모르는 범위를 정확히 그을 때다.
인용은 문단 끝 장식이 아니라 주장 단위 연결이어야 한다
인용을 붙일 때 흔히 하는 실수는 문단 하나 끝에 출처 세 개를 몰아넣는 것이다. 이렇게 쓰면 독자는 어느 문장이 어느 출처를 근거로 하는지 알기 어렵다. 더 좋은 방식은 주장 단위 인용이다.
예를 들어 이렇게 쓸 수 있다.
RAG는 외부 지식을 갱신해 최신 정보를 반영하기 쉽지만, 검색 단계가 불안정하면 근거 품질이 전체 답변 품질을 좌우한다.34
이 문장은 왜 괜찮을까. 핵심 주장 바로 뒤에 출처가 붙어 있어 독자가 근거를 좇기 쉽기 때문이다.
세밀한 인용 품질이 중요하다는 점은 인용 생성 연구에서도 반복해서 강조된다. FRONT 연구는 단순한 문서 번호 수준이 아니라, 더 세분화된 근거 연결이 인용의 품질과 지지 가능성을 높인다고 보여 준다.6 우리 책의 목적은 논문 시스템을 만드는 것이 아니지만, 교훈은 분명하다. 인용은 가능한 한 촘촘하게, 그리고 사람이 확인하기 쉽게 붙여야 한다.
불확실성 표시는 리서치 에이전트의 품격이다
리서치 보고서에서 가장 위험한 문장은 틀린 문장보다 애매한 확신이다. 그래서 리서치 에이전트는 사실상 두 개의 결과를 내야 한다. 하나는 답변이고, 다른 하나는 확신의 정도다.
실전에서는 문장을 세 단계로 나누면 좋다.
확인됨: 여러 신뢰 가능한 출처가 일치한다.
유력함: 근거는 있으나 출처 수가 적거나 최신성이 약하다.
미확인: 단서 수준이며 추가 검증이 필요하다.
이 구분만 있어도 사용자는 AI를 훨씬 더 잘 활용할 수 있다. 특히 기업 조사, 제품 비교, 정책 해석처럼 잘못된 확신이 비싼 실수를 부르는 영역에서는 더 중요하다.
리서치 에이전트의 출력 형식은 처음부터 정해 두는 편이 좋다
조사형 워크플로는 결과 형식이 흐트러지면 바로 품질이 떨어진다. 그래서 출력 형식은 마지막에 꾸미는 문제가 아니라 처음에 설계하는 문제다.
예를 들어 다음과 같은 구조가 실용적이다.
한 줄 결론
핵심 발견 3~5개
근거와 출처
상충 정보 또는 예외
아직 확인되지 않은 점
다음 검색 제안
이 형식이 좋은 이유는 "답"과 "근거"와 "한계"가 분리되기 때문이다. 특히 마지막의 "아직 확인되지 않은 점"은 중요하다. 이 한 줄이 있어야 리서치 에이전트가 한 번의 답변 기계가 아니라 다음 조사로 이어지는 시스템이 된다.
간단한 예시로 전체 흐름을 보자
사용자 질문이 "2026년 기준으로 오픈소스 딥 리서치 에이전트를 만들 때 핵심 설계 요소는 무엇인가"라고 해 보자.
먼저 플래너는 질문을 분해한다. 계획 수립, 질의 분해, 검색 도구, 하위 에이전트 분리, 메모리와 압축, 인용 보고서 생성 같은 하위 주제가 나온다. 그다음 서처는 각 주제별로 검색 쿼리를 만든다. 예를 들어 어떤 쿼리는 공식 문서를 찾고, 어떤 쿼리는 구현 예제와 벤치마크를 찾는다. 리더는 각 문서에서 핵심 주장과 발췌를 메모로 만든다. 시서사이저는 중복을 제거하고 공통 패턴을 묶는다. 마지막으로 베리파이어는 최신성, 인용 누락, 과도한 일반화를 검사한다.
최종 보고서는 이렇게 요약될 수 있다. "좋은 딥 리서치 에이전트는 질문 분해, 컨텍스트 분리, 단계별 검색과 재계획, 근거 중심 종합, 인용 가능한 보고서 생성을 핵심 구성요소로 갖는다. 특히 하위 조사 작업을 분리된 컨텍스트에서 병렬로 처리하는 구조가 장기 작업의 안정성을 높인다.12"
이 한 문장은 그럴듯해 보이는 문장이 아니라, 조사 흐름을 통과해 살아남은 문장이다.
자주 실패하는 설계는 대체로 네 가지다
첫 번째 실패는 검색 결과 과적재다. 너무 많은 링크와 본문을 한 번에 넣어 모델을 질식시킨다.
두 번째 실패는 출처와 주장 분리다. 메모는 열심히 했는데 최종 문장에 어떤 출처가 연결되는지 잃어버린다.
세 번째 실패는 질문 분해 남용이다. 간단한 질문에도 하위 질문을 여섯 개씩 만들어 속도와 비용만 늘린다.
네 번째 실패는 불확실성 삭제다. 근거가 약한데도 매끈한 문체로 확정적으로 써 버린다.
이 네 가지를 피하면 리서치 에이전트의 품질은 생각보다 빠르게 올라간다.
좋은 리서치 에이전트는 답변보다 조사 습관을 설계한다
결국 리서치 에이전트 설계의 핵심은 대단한 프롬프트 한 줄이 아니다. 좋은 조사 습관을 시스템 안에 심는 것이다. 복잡한 질문이면 먼저 쪼개고, 출처는 역할별로 모으고, 메모를 남기고, 요약에는 근거를 달고, 모르는 것은 모른다고 쓰게 만드는 것. 이 습관이 들어간 시스템은 시간이 갈수록 더 믿을 만해진다.
검색형 AI를 잘 쓰는 사람과, 조사형 AI를 설계하는 사람의 차이는 여기서 갈린다. 전자는 빨리 답을 얻는다. 후자는 검증 가능한 답을 만든다. 그리고 실무에서 결국 오래 살아남는 쪽은 거의 항상 후자다.
참고
3Query Decomposition for NVIDIA RAG Blueprint
4Question Decomposition for Retrieval-Augmented Generation
5Grounded Summarization Using Command R
6Learning Fine-Grained Grounded Citations for Attributed Large Language Models
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.