Open Deep Research

https://blog.langchain.com/open-deep-research/

TL;DR

딥 리서치는 가장 인기 있는 에이전트 애플리케이션 중 하나로 떠올랐습니다. OpenAI, Anthropic, Perplexity, Google 모두 다양한 컨텍스트 소스를 활용해 포괄적인 보고서를 생성하는 딥 리서치 제품을 출시했습니다. 오픈 소스 구현(1, 2)도 많이 존재합니다.

저희는 사용자가 직접 모델, 검색 도구, MCP 서버를 가져와 구성할 수 있는 간단하고 설정 가능한 오픈 딥 리서처를 만들었습니다.

오픈 딥 리서치는 LangGraph를 기반으로 구축되었습니다. 코드는 여기에서 확인하세요!
Open Agent Platform에서 사용해보세요

챌린지

리서치는 개방형 과제입니다. 사용자 요청에 가장 적합한 전략을 사전에 쉽게 알 수 없습니다. 요청마다 서로 다른 리서치 전략과 다양한 검색 깊이가 필요할 수 있습니다.

“이 두 제품을 비교해 주세요”

비교 요청은 각 제품에 대한 검색 후, 비교를 위한 종합 단계가 있으면 도움이 됩니다.

“이 역할에 적합한 상위 20명의 후보를 찾아주세요”

목록 작성 및 순위 매기기 요청은 개방형 검색 후, 종합 및 순위 매기기가 필요합니다.

“X가 정말 사실인가요?”

검증 질문은 특정 도메인에 대해 반복적이고 심층적인 리서치가 필요할 수 있으며, 이때는 검색의 폭보다 소스의 품질이 훨씬 더 중요합니다.

이러한 점을 고려할 때, 오픈 딥 리서치의 핵심 설계 원칙은 요청에 따라 다양한 리서치 전략을 유연하게 탐색할 수 있는 것입니다.

아키텍처 개요

에이전트는 다양한 전략을 유연하게 적용하고 중간 결과를 활용해 탐색을 이끌 수 있기 때문에 리서치에 적합합니다. 오픈 딥 리서치는 에이전트를 활용해 다음의 3단계 프로세스로 리서치를 수행합니다:

스코프 – 리서치 범위 명확화
리서치 – 리서치 수행
작성 – 최종 보고서 작성

1단계: 스코프

스코프 단계의 목적은 리서치에 필요한 모든 사용자 컨텍스트를 수집하는 것입니다. 이 단계는 사용자 명확화와 브리프 생성의 두 단계로 이루어진 파이프라인입니다.

사용자 명확화

OpenAI는 사용자가 리서치 요청 시 충분한 컨텍스트를 제공하지 않는 경우가 많다고 지적했습니다. 저희는 필요할 경우 추가 컨텍스트를 요청하기 위해 챗 모델을 사용합니다.

브래프 생성

챗 상호작용에는 명확화 질문, 후속 질문, 또는 사용자가 제공한 예시(예: 이전 딥 리서치 보고서)가 포함될 수 있습니다. 이 상호작용은 매우 장황하고 토큰을 많이 사용할 수 있으므로, 이를 포괄적이면서도 집중된 리서치 브리프로 변환합니다. 리서치 브리프는 성공의 기준점 역할을 하며, 리서치 및 작성 단계 내내 참조합니다.

[!Note] 리서처-사용자 챗 상호작용을 집중된 브리프로 변환하여 리서치 감독자가 이를 기준으로 삼을 수 있게 합니다.

2단계: 리서치

리서치 단계의 목표는 리서치 브리프에서 요청한 컨텍스트를 수집하는 것입니다. 저희는 감독 에이전트를 활용해 리서치를 진행합니다.

리서치 감독자

감독자의 역할은 간단합니다. 적절한 수의 하위 에이전트에게 리서치 과제를 위임합니다. 감독자는 리서치 브리프를 독립적인 하위 주제로 분할할 수 있는지 판단하고, 각 하위 에이전트에게 분리된 컨텍스트 윈도우를 제공합니다. 이를 통해 리서치 작업을 병렬화하여 더 빠르게 정보를 찾을 수 있습니다.

리서치 하위 에이전트

각 리서치 하위 에이전트는 감독자로부터 하위 주제를 전달받습니다. 하위 에이전트는 특정 주제에만 집중하도록 프롬프트되며, 전체 리서치 브리프의 범위는 신경 쓰지 않습니다. 각 하위 에이전트는 도구 호출 루프를 통해 리서치를 수행하며, 사용자가 구성한 검색 도구 및 MCP 도구를 활용합니다.

각 하위 에이전트가 작업을 마치면, 모든 리서치 결과를 반영해 하위 질문에 대한 상세 답변을 작성하는 최종 LLM 호출을 진행합니다. 이때 유용한 소스를 인용합니다. 이는 도구 호출 피드백에서 수집된 원시 정보(예: 스크랩된 웹페이지)나 무관한 정보(예: 실패한 도구 호출, 무관한 웹사이트)가 많을 수 있기 때문에 중요합니다.

[!Note] 하위 에이전트의 리서치 결과를 정제하기 위해 추가 LLM 호출을 진행하여 감독자에게 깔끔하고 가공된 정보를 제공합니다.

이 원시 정보를 감독자에게 그대로 반환하면 토큰 사용량이 크게 증가하고, 감독자가 유용한 정보를 추려내기 위해 더 많은 토큰을 소모해야 합니다. 그래서 하위 에이전트가 결과를 정제해 감독자에게 전달합니다.

리서치 감독자 반복

감독자는 하위 에이전트의 결과가 브리프의 범위를 충분히 충족하는지 판단합니다. 더 깊은 리서치가 필요하다고 판단되면 추가 하위 에이전트를 생성해 리서치를 진행할 수 있습니다. 감독자는 리서치를 위임하고 결과를 반영하면서, 부족한 부분을 유연하게 파악해 후속 리서치를 진행할 수 있습니다.

3단계: 보고서 작성

보고서 작성 단계의 목표는 하위 에이전트가 수집한 컨텍스트를 활용해 리서치 브리프의 요청을 충족하는 것입니다. 감독자가 수집된 결과가 브리프의 요청을 충분히 충족한다고 판단하면, 보고서 작성 단계로 넘어갑니다.

보고서를 작성할 때는 리서치 브리프와 하위 에이전트가 반환한 모든 리서치 결과를 LLM에 제공합니다. 이 마지막 LLM 호출은 브리프에 따라, 리서치 결과를 활용해 일괄적으로 답변을 생성합니다.

교훈

병렬화가 쉬운 작업에만 멀티 에이전트 사용

멀티 에이전트와 싱글 에이전트는 중요한 설계 고려사항입니다. Cognition은 병렬로 작업하는 하위 에이전트의 조정이 어렵기 때문에 멀티 에이전트에 반대 의견을 제시했습니다. 만약 작업(예: 애플리케이션 구축)이 멀티 에이전트의 결과가 함께 동작해야 한다면, 조정이 위험 요소가 됩니다.

저희도 같은 교훈을 얻었습니다. 이전 버전의 리서치 에이전트는 하위 에이전트가 보고서의 각 섹션을 병렬로 작성했습니다. 속도는 빨랐지만 Cognition이 지적한 것처럼 보고서가 분절되어 조정이 잘 되지 않았습니다. 저희는 멀티 에이전트를 리서치 작업에만 제한하고, 보고서 작성은 모든 리서치가 끝난 후 일괄적으로 진행하는 방식으로 해결했습니다.

[!Note] 멀티 에이전트는 조정이 어렵고, 보고서 섹션을 병렬로 작성하면 품질이 저하될 수 있습니다. 저희는 멀티 에이전트를 리서치에만 사용하고, 보고서 작성은 일괄적으로 진행합니다.

멀티 에이전트는 하위 리서치 주제별 컨텍스트 분리에 유용

실험 결과, 요청에 여러 하위 주제가 포함된 경우 싱글 에이전트의 응답 품질이 저하되었습니다(예: A, B, C를 비교). 그 이유는 한 개의 컨텍스트 윈도우에 모든 하위 주제의 도구 피드백을 저장하고 추론해야 하기 때문입니다. 이 도구 피드백은 토큰을 많이 소모합니다. 다양한 실패 모드(예: 컨텍스트 충돌)가 여러 하위 주제의 도구 호출이 누적되면서 빈번하게 발생합니다.

구체적인 예시를 살펴봅시다

OpenAI vs Anthropic vs Google DeepMind의 AI 안전 접근법을 비교해보세요. 각 조직의 철학적 프레임워크, 연구 우선순위, 그리고 이들이 정렬(alignment) 문제를 어떻게 사고하는지 이해하고 싶습니다.

저희의 싱글 에이전트 구현은 각 프런티어 연구소에 대해 동시에 별도의 쿼리를 검색 도구에 보냈습니다.

‘OpenAI의 AI 안전 및 정렬에 대한 철학적 프레임워크’
‘Anthropic의 AI 안전 및 정렬에 대한 철학적 프레임워크’
’Google DeepMind의 AI 안전 및 정렬에 대한 철학적 프레임워크’

검색 도구는 세 연구소 모두에 대한 결과를 하나의 긴 문자열로 반환했습니다. 싱글 에이전트는 세 프런티어 연구소에 대한 결과를 모두 종합적으로 검토한 뒤, 다시 각 연구소별로 독립적인 쿼리를 검색 도구에 요청했습니다.

‘DeepMind의 사회적 선택 및 정치 철학에 대한 입장’
‘Anthropic의 기술적 정렬 과제에 대한 입장’
‘OpenAI의 재귀적 보상 모델링에 관한 기술 보고서’

각 도구 호출 반복에서, 싱글 에이전트는 세 개의 독립적인 주제의 컨텍스트를 동시에 다뤘습니다. 이는 토큰과 지연(latency) 측면에서 비효율적이었습니다. DeepMind의 정렬 철학에 대한 다음 쿼리를 생성하는 데 OpenAI의 재귀적 보상 모델링 접근법에 대한 토큰이 필요하지 않습니다. 또 하나 중요한 관찰은, 싱글 에이전트가 여러 주제를 동시에 다루면 각 주제에 대해 더 깊이 있게(검색 쿼리 수) 조사하기 전에 작업을 끝내는 경향이 있다는 점이었습니다.

멀티 에이전트 접근법은 여러 하위 에이전트가 병렬로 실행되며, 각 에이전트는 독립적이고 집중된 작업에만 전념합니다. 리서치에 멀티 에이전트 접근법을 적용하면 Anthropic이 보고한 이점과 저희 자체 평가에서 확인된 효과를 얻을 수 있습니다: 하위 주제별 컨텍스트를 각 하위 에이전트에 분리할 수 있습니다.

[!Note] 리서치 중 하위 주제별 컨텍스트 분리는 다양한 장기 컨텍스트 실패 모드를 방지할 수 있습니다.

멀티 에이전트 감독자는 필요한 리서치 깊이에 맞게 시스템을 조정할 수 있음

사용자는 간단한 요청이 10분 이상 걸리길 원하지 않습니다. 하지만 Anthropic이 잘 보여준 것처럼, 더 많은 토큰 사용과 지연이 필요한 리서치 요청도 있습니다.

감독자는 하위 에이전트를 선택적으로 생성해 요청에 필요한 리서치 깊이를 조정할 수 있습니다. 감독자는 언제 리서치를 병렬화해야 하는지, 언제 단일 스레드로 충분한지에 대한 휴리스틱을 활용해 판단합니다. 저희 딥 리서치 에이전트는 리서치 병렬화 여부를 유연하게 선택할 수 있습니다.

[!Note] 멀티 에이전트 감독자는 검색 전략의 유연성을 제공합니다.

토큰 낭비 방지 및 행동 유도를 위한 컨텍스트 엔지니어링의 중요성

리서치는 토큰을 많이 소모하는 작업입니다. Anthropic은 멀티 에이전트 시스템이 일반 챗 애플리케이션보다 15배 더 많은 토큰을 사용했다고 보고했습니다! 저희는 이를 완화하기 위해 컨텍스트 엔지니어링(번역)을 활용했습니다.

챗 히스토리를 리서치 브리프로 압축해 이전 메시지로 인한 토큰 낭비를 방지합니다. 하위 에이전트는 감독자에게 결과를 반환하기 전에 리서치 결과에서 무관한 토큰과 정보를 제거합니다.

충분한 컨텍스트 엔지니어링이 없으면, 에이전트가 도구 호출 결과의 원시 정보로 인해 컨텍스트 윈도우 한계에 쉽게 도달하게 됩니다. 실질적으로도 토큰 비용을 절감하고, TPM 모델의 속도 제한을 피하는 데 도움이 됩니다.

[!Note] 컨텍스트 엔지니어링은 실질적인 이점이 많습니다. 토큰을 절약하고, 컨텍스트 윈도우 한계를 피하며, 모델 속도 제한을 준수할 수 있습니다.

다음 단계

오픈 딥 리서치는 계속 발전 중인 프로젝트이며, 앞으로 시도해보고 싶은 아이디어가 많습니다. 현재 고민 중인 오픈 질문은 다음과 같습니다.

토큰을 많이 사용하는 도구 응답을 가장 효과적으로 처리하고, 불필요한 토큰 소모를 줄이기 위해 무관한 컨텍스트를 필터링하는 최적의 방법은 무엇일까?
에이전트의 주요 경로에서 고품질 응답을 보장하기 위해 실행할 만한 평가 방법이 있을까?
딥 리서치 보고서는 가치가 높고 생성 비용도 상대적으로 높은데, 이 작업을 저장해 장기 메모리로 활용할 수 있을까?

오픈 딥 리서치 사용법

LangGraph Studio

LangGraph 코드를 복제해 LangGraph Studio에서 오픈 딥 리서치를 로컬로 실행할 수 있습니다. Studio를 활용해 프롬프트와 아키텍처를 테스트하고, 자신의 사용 사례에 맞게 더 구체적으로 조정할 수 있습니다!

Open Agent Platform

오픈 딥 리서치는 Open Agent Platform(OAP) 데모 인스턴스에 호스팅되어 있습니다. OAP는 시민 개발자 플랫폼으로, 사용자가 에이전트를 구축, 프로토타입, 활용할 수 있습니다. API 키만 입력하면 됩니다. 또한 OAP의 자체 인스턴스를 배포해 딥 리서치를 다른 LangGraph 에이전트와 함께 호스팅할 수도 있습니다!