책에 포함된 노트AI 에이전트 하네스 설계: 모델을 제품으로 바꾸는 실행 환경의 기술

리서치 에이전트 하네스

2026-04-30Views 17약 10분생성형 AI 활용

리서치 에이전트는 똑똑하게 말하는 시스템이 아니다. 더 정확히 말하면, 찾고, 읽고, 비교하고, 의심하고, 출처를 남기는 시스템이어야 한다. 여기서 많은 팀이 처음부터 실수한다. 검색 결과 몇 개를 읽고 바로 멋진 문장을 만들어내면, 그럴듯한 보고서는 나올 수 있다. 하지만 실무에서 필요한 것은 그럴듯함이 아니라 근거가 따라오는 답변이다.

좋은 리서치 에이전트는 천재 학생보다 잘 훈련된 조사팀에 가깝다. 누군가는 검색을 맡고, 누군가는 문서를 읽고, 누군가는 요약하고, 마지막에는 사실 확인 담당이 다시 본다. 이 역할 분리가 바로 하네스 설계의 핵심이다. Anthropic은 자사 에이전트 설계 경험에서 수집, 실행, 검증의 루프를 분리해 다루는 것이 중요하다고 설명했고, 특히 깊은 리서치 작업에서도 같은 원리가 통한다고 밝혔다.¹

리서치 에이전트 하네스

리서치 에이전트가 자주 틀리는 이유

리서치 자동화가 실패하는 가장 흔한 이유는 모델이 멍청해서가 아니다. 한 번에 너무 많은 역할을 맡기기 때문이다. 같은 모델이 질문을 해석하고, 검색어를 만들고, 자료를 읽고, 요약하고, 결론까지 내리면 어떤 일이 벌어질까. 처음 떠올린 가설을 스스로 강화하는 방향으로 움직이기 쉽다. 쉽게 말해, 답을 먼저 정해 놓고 자료를 끌어오는 습관이 생긴다.

이 문제는 특히 다음 상황에서 심해진다.

검색 단계에서 이미 특정 결론을 전제한 키워드를 사용한다.
읽기 단계에서 중요한 문장보다 인상적인 문장을 더 크게 받아들인다.
요약 단계에서 출처별 차이를 지우고 평균적인 말로 뭉개 버린다.
최종 답변 단계에서 근거가 부족한 문장을 자연스럽게 메워 넣는다.

그래서 리서치 하네스의 첫 원칙은 단순하다. 답변 생성과 근거 수집을 분리하라. 리서치 자동화의 핵심은 말을 잘하게 만드는 것이 아니라, 말하기 전에 충분히 찾아보고 의심하게 만드는 것이다.

리서치 하네스의 기본 구조

리서치 에이전트 하네스는 하나의 거대한 두뇌보다, 여러 작업대를 연결한 공정에 가깝다. 실무에서는 다음 순서가 가장 안정적이다.

질문 정제: 사용자의 요청을 조사 가능한 질문으로 바꾼다. 범위, 기간, 대상, 필요한 산출물을 분명히 한다.
검색 계획 수립: 어떤 키워드로, 어떤 소스군을, 어떤 우선순위로 찾을지 정한다.
후보 자료 수집: 웹, 문서 저장소, 내부 파일, 데이터베이스에서 자료를 모은다.
읽기와 정보 추출: 문서를 읽고 핵심 주장, 수치, 날짜, 출처 성격을 구조화한다.
근거 카드 생성: "무슨 주장인지, 어디서 왔는지, 얼마나 최신인지"를 한 장씩 정리한다.
종합 초안 작성: 근거 카드만 보고 초안을 쓴다. 이때 원문 전체를 다시 뒤섞지 않는다.
검증 및 반론 확인: 별도 검증 단계에서 인용 적합성, 최신성, 상충 여부를 다시 점검한다.
최종 보고서 생성: 결론뿐 아니라 출처, 불확실성, 추가 확인이 필요한 지점까지 함께 제공한다.

이 구조가 좋은 이유는 단계마다 실패를 잡아낼 수 있기 때문이다. 검색이 잘못되면 읽기 단계 전에 멈출 수 있고, 읽기에서 근거가 비면 초안 단계에서 허점을 볼 수 있다. 반대로 이 단계를 섞어 버리면 마지막에만 "뭔가 이상한데?"라는 막연한 느낌만 남는다.

검색과 읽기를 분리하라

리서치 하네스에서 검색은 답변을 만드는 단계가 아니다. 검색의 목적은 후보 자료를 넓고 균형 있게 모으는 것이다. 여기서 바로 요약을 시작하면 검색 엔진이 사실상 편집자가 되어 버린다.

좋은 검색 단계는 최소한 세 갈래로 나뉜다.

넓게 찾기: 주제를 둘러싼 대표 자료와 기준 문서를 모은다.
정확히 찾기: 특정 쟁점, 수치, 날짜, 정책 변경 같은 확인 포인트를 찾는다.
반대로 찾기: 현재 가설을 뒤집는 자료나 반대 입장을 일부러 खोज는다.

이 세 번째가 특히 중요하다. 리서치 에이전트는 대체로 협조적이어서 사용자의 기대에 맞는 자료를 더 쉽게 모은다. 따라서 하네스가 일부러 "반례를 찾는 검색"을 넣어 주어야 한다. 그래야 보고서가 광고문이 아니라 조사 결과가 된다.

읽기 단계는 또 다르다. 읽기의 목적은 문서 전체를 멋지게 요약하는 것이 아니라, 문서가 실제로 무엇을 주장하는지 뽑아내는 것이다. 이때는 문장을 예쁘게 줄이는 능력보다 정보 추출 능력이 중요하다. 예를 들어 다음과 같은 항목을 구조화하면 좋다.

문서 제목과 링크
발행일 또는 최종 수정일
1차 자료인지 2차 해설인지
핵심 주장
근거 수치와 단위
적용 범위와 조건
직접 인용이 필요한 문장
아직 불확실한 부분

LangChain은 에이전트 하네스에서 파일시스템, 검색, 맥락 오프로딩, 서브에이전트 분리가 중요한 이유를 설명하면서, 긴 작업일수록 자료를 외부 작업공간에 저장하고 필요한 내용만 다시 가져오는 방식이 성능과 안정성에 유리하다고 정리했다.³ 리서치 에이전트도 같다. 검색 결과 전문을 전부 컨텍스트에 밀어 넣는 대신, 후보 문서를 저장하고 읽기 결과만 구조화해 넘겨야 한다.

요약보다 먼저 근거 카드를 만들어라

많은 팀이 검색 다음 단계로 바로 "요약"을 떠올린다. 하지만 실제로 더 중요한 것은 요약이 아니라 근거 카드다. 근거 카드란 하나의 주장과 그 출처를 묶어 둔 작은 단위다. 일종의 조사 메모라고 생각하면 쉽다.

예를 들어 "A 회사는 2026년 3월부터 가격 정책을 변경했다"라는 문장이 있다면, 좋은 하네스는 이 문장을 그냥 기억하지 않는다. 대신 다음처럼 저장한다.

주장: A 회사는 2026년 3월 가격 정책을 변경했다.
출처: 공식 가격 페이지 또는 공지
날짜: 2026-03-xx
출처 유형: 1차 자료
확인 방식: 직접 명시
신뢰도: 높음
비고: 지역별 가격 차이 여부 추가 확인 필요

이 카드가 쌓이면 나중에 보고서를 쓸 때 "내가 왜 이런 말을 했지?"라는 질문에 바로 답할 수 있다. 반대로 카드 없이 긴 요약문만 남기면, 마지막 단계에서 문장과 출처의 연결이 끊어진다. 그러면 출처는 달려 있는데 실제로는 출처가 그 말을 하지 않은, 이상한 보고서가 나온다.

리서치 에이전트용 스킬과 사례들은 검색 신뢰성을 높이려면 교차 검증과 명확한 감사 흔적이 필요하다고 강조한다.⁴ 근거 카드는 바로 그 감사 흔적의 최소 단위다.

출처 관리는 장식이 아니라 제동장치다

출처는 보고서를 있어 보이게 만드는 장식이 아니다. 잘 설계된 리서치 하네스에서는 출처 관리가 환각을 줄이는 제동장치가 된다.

좋은 출처 관리에는 세 가지 규칙이 있다.

첫째, 문장 단위로 출처가 연결되어야 한다. 문단 맨 끝에 참고 링크 몇 개를 몰아 넣는 방식은 사람 눈에는 그럴듯해도, 검증 단계에서는 거의 도움이 되지 않는다.

둘째, 출처의 종류를 구분해야 한다. 공식 문서, 보도자료, 연구 논문, 언론 기사, 블로그 글, 포럼 댓글은 같은 링크가 아니다. 모두 "자료"이긴 하지만 무게가 다르다.

셋째, 출처가 말하는 범위와 보고서 문장의 범위가 일치해야 한다. 예를 들어 미국 정책 문서를 읽고 전 세계 규칙처럼 쓰면 안 된다. 특정 버전의 API 문서를 보고 전체 제품의 영구 원칙인 것처럼 써도 안 된다.

실무에서는 출처 우선순위를 미리 정해 두면 좋다. 보통은 1차 자료가 가장 우선이고, 그다음이 신뢰할 만한 2차 요약, 마지막이 해설이나 의견이다. 물론 항상 1차 자료만 있는 것은 아니다. 하지만 없을수록 보고서는 더 신중한 표현을 써야 한다. "확정적 사실"이 아니라 "현재 확인 가능한 자료에 따르면" 같은 문장으로 톤을 낮춰야 한다.

검증 에이전트는 반드시 따로 둬라

리서치 에이전트 하네스에서 가장 큰 품질 차이를 만드는 지점은 검증이다. 그리고 검증은 가능하면 생성 단계와 분리된 다른 역할이 맡아야 한다. Anthropic은 장시간 작업용 하네스에서 생성자와 평가자를 분리했을 때 자기 칭찬식 평가를 줄이고 더 현실적인 피드백을 만들 수 있었다고 설명한다.²

리서치에서도 똑같다. 초안을 쓴 에이전트에게 "이 보고서 문제없지?"라고 물으면 대개 문제없다고 답한다. 사람도 자기 글을 쓰고 바로 검수하면 오탈자를 놓치는데, 에이전트라고 다르지 않다.

좋은 검증 에이전트는 친절한 조수가 아니라 약간 까다로운 데스크 편집자처럼 행동해야 한다. 최소한 다음 질문을 던져야 한다.

이 문장은 실제로 인용한 출처에서 확인되는가?
같은 주장을 뒷받침하는 독립 출처가 있는가?
반대 자료나 예외 조건은 누락되지 않았는가?
날짜가 오래되어 현재 상태를 설명하지 못하는 것은 아닌가?
결론의 확신 수준이 근거의 강도보다 과장되어 있지 않은가?

여기서 중요한 것은 "틀렸는지"만 보는 것이 아니다. 근거 대비 표현 강도를 보는 것이다. 근거가 약한데 문장이 너무 단정적이면, 그 자체로 품질 문제가 된다.

상충하는 자료를 만나면 평균내지 마라

리서치 하네스는 종종 두 개의 상충하는 자료를 만나면 둘을 부드럽게 섞어 버린다. 하지만 현실의 좋은 조사자는 그렇게 하지 않는다. 충돌은 제거할 대상이 아니라 드러낼 대상이다.

예를 들어 한 공식 문서는 "기능 제공"이라고 쓰고, 최근 공지에는 "베타 종료 후 중단"이라고 되어 있을 수 있다. 이때 좋은 하네스는 둘을 합쳐 "일부 환경에서 제공될 수 있다" 같은 어정쩡한 문장을 만들지 않는다. 대신 이렇게 정리해야 한다.

서로 다른 주장이 있다는 사실을 표시한다.
각 주장의 날짜와 출처 유형을 비교한다.
더 최근이고 적용 범위가 분명한 자료를 우선한다.
그래도 애매하면 불확실성 자체를 결과에 남긴다.

이 원칙은 리서치 결과를 덜 매끈하게 만들 수 있다. 하지만 훨씬 더 믿을 만하게 만든다. 현실의 정보는 종종 깔끔하게 정리되지 않는다. 좋은 리서치 에이전트는 그 지저분함을 지우지 않고 관리한다.

리서치 로그가 있어야 다시 믿을 수 있다

보고서만 남고 조사 과정이 남지 않으면, 다음 번에는 처음부터 다시 시작해야 한다. 그래서 리서치 에이전트 하네스에는 리서치 로그가 필요하다. 로그는 단순한 디버깅용 기록이 아니라 재현성과 감사 가능성을 위한 장치다.

리서치 로그에는 적어도 다음 내용이 남아야 한다.

어떤 질문을 받았는가
어떤 검색어를 사용했는가
어떤 자료를 후보로 채택했고 무엇을 제외했는가
제외 이유는 무엇인가
어떤 주장을 어떤 출처로 확인했는가
충돌하는 자료는 무엇이었는가
마지막 확인 시점은 언제인가

이 로그가 있으면 같은 주제로 후속 질문이 왔을 때 훨씬 빨라진다. 이전 결과를 그냥 재사용하는 것이 아니라, 어디를 다시 확인해야 하는지를 빠르게 알 수 있다. 리서치 자동화가 단발성 답변보다 운영 가능한 시스템이 되려면, 답변보다 로그가 더 중요할 때가 많다.

보고서는 결론만이 아니라 불확실성도 전달해야 한다

리서치 에이전트의 최종 산출물은 "정답"이 아니다. 더 정확히 말하면 현재까지 확인된 근거를 바탕으로 한 판단이다. 따라서 좋은 보고서는 결론만 말하지 않는다. 무엇이 확실하고, 무엇이 덜 확실하며, 무엇은 아직 비어 있는지도 함께 말한다.

실무용 보고서라면 다음 요소가 들어가면 좋다.

핵심 결론
결론을 지지하는 주요 근거
반대 근거나 예외 조건
최신성 판단과 마지막 확인 시점
신뢰도 수준
추가 확인이 필요한 항목

이 형식은 처음엔 조금 답답해 보일 수 있다. 하지만 실제 의사결정에서는 이런 답변이 훨씬 유용하다. "확실히 맞는 말처럼 보이는 답변"보다 "어디까지 확인했고 어디는 아직 모른다고 밝히는 답변"이 훨씬 안전하기 때문이다.

실전에서 잘 작동하는 리서치 하네스 패턴

리서치 에이전트는 모든 상황에서 같은 모양일 필요가 없다. 다만 몇 가지 패턴은 반복해서 잘 작동한다.

브리핑 패턴

짧은 시간 안에 핵심만 정리해야 할 때 쓰는 구조다. 검색 범위를 좁게 잡고, 1차 자료 우선으로 3~5개 핵심 출처만 읽는다. 장점은 빠르다는 것이고, 단점은 깊이가 제한된다는 점이다. 따라서 "빠른 상황 파악"에는 좋지만, 전략 보고서나 대외 발표용 근거로는 부족할 수 있다.

심층 조사 패턴

복수의 서브에이전트가 주제별로 자료를 나눠 읽고, 상위 에이전트가 근거 카드를 합쳐 종합한다. 긴 작업에서는 이런 분리가 특히 중요하다. Anthropic과 LangChain이 설명한 것처럼, 긴 작업일수록 맥락 창 하나에 모든 자료를 넣기보다 작업을 쪼개고 외부 작업공간을 활용하는 편이 안정적이다.¹³

모니터링 패턴

한 번 조사하고 끝나는 주제가 아니라, 정책 변경이나 경쟁사 업데이트처럼 계속 변하는 주제에 مناسب하다. 이전 리서치 로그와 근거 카드를 저장해 두고, 다음 실행에서는 새 문서만 추가로 검사한다. 이 패턴에서는 "다시 처음부터 요약"보다 "무엇이 바뀌었는지 찾기"가 더 중요하다.

실패하는 리서치 에이전트의 전형적인 모습

현장에서 자주 보이는 실패 패턴은 의외로 비슷하다.

답변 우선형: 근거를 모으기 전에 결론부터 쓴다.
출처 세탁형: 문장 뒤에 링크는 붙어 있지만 실제로는 그 문장을 지지하지 않는다.
단일 소스 의존형: 첫 번째로 찾은 자료를 사실상 유일한 진실처럼 취급한다.
최신성 착각형: 최근에 검색했으니 정보도 최신일 것이라고 착각한다.
충돌 삭제형: 상충하는 자료를 만나면 차이를 설명하지 않고 적당히 섞어 버린다.

이 다섯 가지는 대부분 하네스 문제다. 모델이 더 좋아지면 어느 정도 완화되겠지만, 원칙 없이 사라지지는 않는다. 그래서 리서치 자동화에서는 더 좋은 모델보다 더 좋은 공정이 먼저다.

좋은 리서치 에이전트는 답변기가 아니라 조사 체계다

리서치 에이전트를 설계할 때 가장 중요한 관점 전환은 이것이다. 최종 답변은 결과물이고, 진짜 제품은 그 답변에 이르는 조사 체계라는 점이다.

검색은 넓게, 읽기는 구조화해서, 요약은 근거 카드 위에서, 검증은 별도 역할로, 최신성은 따로 판별하고, 출처는 문장 단위로 연결해야 한다. 이 여섯 가지가 갖춰지면 리서치 에이전트는 "말 잘하는 챗봇"에서 "믿고 맡길 수 있는 조사 도구"로 바뀐다.

결국 리서치 자동화의 핵심은 더 유창하게 쓰는 기술이 아니다. 근거를 모으는 일과 결론을 만드는 일을 분리하는 기술이다. 좋은 리서치 하네스는 에이전트가 성급하게 대답하지 못하게 하고, 대신 차근차근 찾아서 말하게 만든다. 바로 그 느린 성실함이, 실전에서는 가장 빠른 길이 된다.