코딩 에이전트가 아닌 지식 에이전트로 AI 업무 설계하기

URL: https://www.youtube.com/watch?v=uRE_cAq--Lo 날짜: 2026-09-21 채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트가 코딩 에이전트의 작업 방식을 모든 지식 업무에 그대로 적용해서는 안 되며, 법률·의료·금융·연구처럼 맥락과 판단이 중요한 업무에는 지식 노동자와 지식 조직을 본떠 설계한 지식 에이전트(knowledge agent)가 필요하다.==

• 코드는 식별자·파일 경로·함수 정의처럼 검색 가능한 단서가 오래 유지되고, 대부분의 코딩 요청도 기능이나 티켓 단위로 이미 잘 쪼개져 있다.
• 비코드 지식은 같은 단어가 상황에 따라 전혀 다른 뜻을 갖고, 답변에 필요한 규칙·예외·목표를 에이전트가 스스로 찾아야 한다.
• 인류는 도서 목록, 검색 도구, 전문가 조직, 전문화된 역할을 수세기 동안 발전시켜 왔으며, AI 에이전트도 이 도구 루프와 조직 루프를 활용해야 한다.
• 실제 검색 벤치마크에서 검색 도구의 품질과 검색을 분담하는 에이전트 조직을 함께 개선하자 정확도가 오르고 도구 호출·토큰 비용이 줄어들었다.

지식 업무는 물리적 재료보다 정보를 주된 입력으로 삼아 모호하고 흩어진 정보를 판단·결정·실행 가능한 결과로 바꾸는 일이다. 따라서 에이전트는 한 번에 모든 문서를 컨텍스트에 넣는 코더처럼 행동하기보다, 문제를 분해하고 여러 검색 도구와 전문 검색 에이전트를 조율해 메모를 만든 뒤 최종 판단을 내려야 한다.

1. 에이전트의 출발점과 지식 업무로의 확장

에이전트의 역사는 PDF와 대화하는 단순한 검색에서 코딩 에이전트로, 그리고 모든 전문 지식 업무를 다루는 지식 에이전트로 확장되고 있다.

1.1. 2022년의 단순한 RAG에서 코딩 에이전트까지

1. 초기 에이전트는 검색과 문서 대화에 머물렀다

   1. 초기의 기술 수준: 2022년 무렵에는 사실상 RAG(Retrieval-Augmented Generation)만 사용할 수 있었고, 에이전트가 도구를 호출하지도 못했다.
   2. 작동 방식: 검색을 실행할지 결정하는 if 문에 가까웠으며, 사용자는 자신의 PDF와 대화할 수 있었지만 실용성은 높지 않았다.
   3. 한계: 이런 형태는 에이전트적 작업의 가장 초기 형태였을 뿐이며, 발표자는 이 단계에 오래 머물 필요가 없다고 했다.

2. 도구 호출이 코딩 에이전트를 만들었다

   1. 검색 능력의 발전: 에이전트가 제대로 검색하고, 대상을 이해하고, 작업을 수행하고, 도구를 호출할 수 있게 되면서 프로그래밍 에이전트가 등장했다.
   2. 대중화: 코딩 에이전트는 발표장에 있는 거의 모든 사람이 쓰는 도구가 되었고, 발표자는 Codex 등을 예로 들었다.
   3. 범위의 오해: 코딩도 지식 업무이지만, 그동안 에이전트는 지식 노동자라기보다 코딩 에이전트로만 설계되어 왔다.

1.2. 지식 에이전트가 포괄하는 업무

1. 지식 업무는 코딩보다 큰 상위 집합이다

   1. 법률: 법률 문서를 찾고 사건의 규칙과 적용 가능성을 판단하는 변호사 에이전트가 해당한다.
   2. 금융: 금융 자료와 시장 정보를 찾아 분석하고 결정을 돕는 금융 에이전트가 해당한다.
   3. 의료: 약물·의학 정보를 찾거나 온라인에서 자가 진단을 시도하는 용도처럼 의료 지식을 다루는 일도 지식 에이전트의 영역이다.

2. 코딩과 RAG는 전체 지식 업무 중 일부다

   1. 공통 기반: 코딩도 지식을 활용하고, 초기 RAG도 지식을 검색한다는 점에서 지식 업무의 일부다.
   2. 더 넓은 문제: 특정 도메인의 문서 검색만으로는 지식의 전체 구조와 맥락, 목표, 판단 과정을 다룰 수 없다.
   3. 설계 방향: 에이전트를 코딩 에이전트의 확장판으로 보는 대신 지식 에이전트로 설계하고, 코딩을 그중 하나의 특수 사례로 봐야 한다.

2. 지식 업무의 정의와 코드의 특수성

지식 업무의 입력은 모호한 정보이고 출력은 실행 가능한 판단이므로, 검색 가능한 단서가 풍부한 코드보다 훨씬 맥락 의존적이다.

2.1. 지식 업무란 무엇인가

1. 정보를 판단으로 바꾸는 일

   1. 입력: 주된 입력은 만질 수 있는 물리적 재료가 아니라 정보다.
   2. 처리 과정: 정보는 본질적으로 모호하고 흩어져 있기 때문에 여러 자료를 해석하고 맥락을 연결해야 한다.
   3. 출력: 결과는 실행 가능한 사고, 판단, 결정이다. 변호사의 경우 사건에 대한 소견과 의뢰인을 위해 법정에서 주장할 방향이 결과가 될 수 있다.

2. 검색과 지식 문제의 순환적 정의

   1. 실용적 정의: 검색이 필요하면 지식 문제이고, 지식 문제라면 검색이 필요하다고 볼 수 있다.
   2. 현실의 직업: 변호사, 학자, 보험계리사(actuary), 소프트웨어 엔지니어, 연구자는 모두 정보와 판단을 다루는 지식 노동자다.
   3. 사회적 중요성: 서비스 경제의 상당 부분이 지식 업무이므로, 사회는 지식 업무를 수행하는 방법과 워크플로를 계속 정교하게 다듬어 왔다.

2.2. 코드는 왜 에이전트에게 상대적으로 쉬운가

1. 코드에는 오래 유지되는 검색 단서가 있다

   1. 내구성 있는 참조: 코드베이스에는 식별자(identifier), 파일, 경로, 함수·메서드 정의 같은 참조가 반복적으로 나타난다.
   2. 검색 가능성: 키워드와 메서드 정의가 표면에 드러나 있어 코드는 본질적으로 검색 가능한(grapable) 구조를 가진다.
   3. 변화의 정도: 바이브 코딩으로 구조가 바뀔 수는 있지만, 일반적으로 이런 참조가 짧은 시간에 전부 바뀌지는 않는다.

2. 코딩 요청은 이미 잘게 쪼개져 있다

   1. 작업 단위: 사용자는 대개 특정 기능(feature)이나 티켓(ticket)을 요청한다.
   2. 기대 수준: 누구도 코딩 에이전트에게 새로운 프로그래밍 패러다임을 발견하고 그것으로 새 앱을 만들라고 막연하게 맡기지는 않는다.
   3. 사용자의 사전 작업: Cloud Code 같은 코딩 도구를 쓸 때 사용자는 이미 해야 할 일을 분해하고, 에이전트에 전달할 선형적인 작업 항목을 마련한 경우가 많다.

2.3. 비코드 지식은 맥락과 의도에서 의미가 결정된다

1. 동일한 단서의 의미가 달라진다

   1. 30일의 예시: 검색 결과에 30 days가 나오더라도 그것이 기한(deadline)인지, 유예 기간(grace period)인지, 보존 규칙(retention rule)인지 알 수 없다.
   2. 도메인 혼동: 계약서에서 30일을 찾는 중인데 검색 결과가 약물 정보의 30일 복용 기간일 수도 있다.
   3. 필요한 맥락: 지식 업무에는 단어 자체보다 해당 단어가 어느 문서·도메인·목표에 연결되는지가 중요하다.

2. 검색은 의도에서 시작한다

   1. 법률 사례: 특정 규칙을 특정 영역에 적용하려면 먼저 관련 국제 규범과 법적 기준을 찾고, 그것이 현재 사건에 적용되는지 검토해야 한다.
   2. 조건부 정보: 어떤 정보가 필요한지는 처음부터 작업에 명시되어 있지 않고, 에이전트가 검색을 진행하면서 발견해야 한다.
   3. 핵심 차이: 비코드 지식은 의미와 맥락에 의해 결정되므로 코드보다 훨씬 어렵고, 검색 작업 자체를 에이전트가 설계해야 한다.

3. 지식의 도구 루프와 조직 루프

인류의 지식 노동은 도구와 역할을 서로 촉발하는 자기 최적화 루프를 통해 발전했으며, 에이전트도 이 역사적 패턴을 재사용해야 한다.

3.1. 도구가 지식을 찾는 방식을 바꾼 역사

1. 기록과 목록화의 발전

   1. 기록의 시작: 사람들이 대화를 기록해야 한다는 생각을 하면서 지식을 글로 남기기 시작했다.
   2. 알렉산드리아 도서관: 알렉산드리아 도서관의 큐레이터였던 칼리마코스가 도서관의 책을 목록화하는 피나케스(Pinakes)를 만들자는 발상을 냈다.
   3. 현대적 검색: 글쓰기와 서지(bibliography)를 거쳐 도서관의 그래픽 인터페이스와 검색 엔진으로 발전했다.

2. 도구는 가능한 일의 비용과 규모를 바꾼다

   1. 목록이 없을 때: 알렉산드리아 도서관에서 원하는 원고를 찾는 일은 가능하지만 2~3주가 걸릴 수 있다.
   2. 목록이 있을 때: 도서 목록이 있으면 같은 탐색이 10분으로 줄어들어, 더 많은 사람이 지식을 활용할 수 있다.
   3. 지도 비유: 지도나 지도 목록이 있으면 인도를 찾아가다 우연히 아메리카를 발견하는 식으로 헤매지 않고 목적지를 알고 탐험할 수 있다.
   4. 멀티모달 검색: 여러 형태를 이해하는 검색 플랫폼은 과거에는 불가능했던 방식으로 수백만 개의 PDF를 검색하게 해, “아카이브에 있으니 건드리지 말자”던 자료를 실제 업무에 쓸 수 있게 한다.

3.2. 전문가 조직과 역할 분화의 발전

1. 한 명의 만능 전문가에서 조직으로

   1. 폴리매스 단계: 과거에는 한 분야 또는 여러 분야를 모두 아는 뛰어난 전문가 한 명에게 질문하면 됐다.
   2. 확장성의 한계: 지식이 늘어나자 한 사람이 모든 내용을 아는 방식은 확장되지 않았다.
   3. 조직의 등장: 수도원은 지식의 수호자가 되었고, 이후 대학과 관료제가 생겼다.

2. 현대의 전문화된 병원 모델

   1. 다층적 역할: 병원에는 의사, 선임 의사, nurse practitioner, 간호사, healthcare assistant가 존재한다.
   2. 업무 분담: 각 역할은 서로 다른 수준과 종류의 작업을 전문화한다.
   3. 최적화의 의미: 업무를 잘게 나누고 전문 도구를 쓰게 하는 조직 구조는 지식 처리량을 높이는 강력한 최적화다.

3.3. 두 루프는 하나의 자기 최적화 루프다

1. 지식이 도구를 만들고 도구가 조직을 만든다

   1. 새 지식의 압력: 새 지식이 생기면 그것을 다루기 위해 더 나은 도구가 필요해진다.
   2. 새 역할의 필요: 도구가 생기면 그 도구를 이해하고 사용할 수 있도록 새로운 워크플로와 역할, 훈련받은 사람이 필요해진다.
   3. 생산성의 재투자: 새 도구를 익힌 지식 노동자는 더 효율적으로 일하고 더 많은 지식을 만들며, 다시 더 나은 도구를 요구한다.

2. Google 사례

   1. 기존 지식: 도서관에 직접 가는 법을 아는 사람에게 Google을 사용하라고 하면 Google이 무엇인지부터 가르쳐야 한다.
   2. 새로운 사용법: Google은 물리적으로 도서관에 갈 필요 없이 검색창에 질문을 입력하는 검색 엔진이라는 지식이 필요하다.
   3. 결과: 검색 도구에 맞게 사람을 재훈련하면 지식 업무가 더 효율적으로 되고, 더 많은 지식이 생성된다.

4. 검색 도구 품질이 지식 업무의 경제성을 결정한다

도구의 품질은 검색 결과를 조금 개선하는 부가 기능이 아니라, 어떤 지식 업무를 규모 있게 수행할 수 있는지를 결정하는 조건이다.

4.1. BrowseComp+ 벤치마크의 교훈

1. 벤치마크의 구성

   1. 목적: BrowseComp+는 제한된(deep research) 연구 과제에서 검색 도구의 품질을 평가하는 벤치마크다.
   2. 자료와 질문: 약 20만 개의 문서와 구체적인 질의를 사용한다.
   3. 현실과의 차이: 실제 지식 업무보다 단순하다. 문서가 텍스트 중심이고 질문 하나를 다루며, 완전히 열린 문제라기보다 약간 복잡하게 구성된 문제다.

2. BM25 최적화의 효과

   1. 단일 BM25는 없다: BM25는 lexical search 방식이며, 최적화한 구현과 최적화하지 않은 구현 등 수백 가지 변형이 있을 수 있다.
   2. 나쁜 도구: 최적화하지 않은 도구는 정확도가 약 60%에 그쳐, 사람이 60%만 맞히는 조언을 계속 믿지 않는 것처럼 실무에서 쓰기 어렵다.
   3. 최적화된 도구: 도구를 최적화하면 정확도가 70~80%대로 상승한다.
   4. 하이브리드 검색: 가장 좋은 hybrid harness는 약 90.2% 정확도를 냈다. 89.8%에서 90.2%로의 작은 상승 자체는 실행 분산에 가까워 핵심이 아니다.

3. 호출 수가 비용을 바꾼다

   1. 동일 정확도, 20% 적은 호출: 90.2% 정확도에 도달한 도구는 20% 적은 tool call로 같은 성능을 냈다.
   2. 자원 절감: 이는 토큰과 컴퓨팅 자원을 20% 줄이는 효과이며, 발표자는 이를 “20%의 공짜 현금”에 비유했다.
   3. 기준선 대비 절감: 최적화하지 않은 기준선과 비교하면 처음 지출의 약 5%만 쓰는 수준까지 내려간다.
   4. 도입 가능한 워크플로: 25번 호출해야 하는 도구는 쓰기 어렵지만 8번 호출이면 실제 업무에 도입할 수 있는 워크플로가 된다.

4.2. 도구는 중립적인 부가 기능이 아니다

1. 가능한 일과 확장 가능한 일은 다르다

   1. 도구가 없어도 가능: 도서관 목록이 없어도 원고를 찾을 수 있고, 지도 없이도 세계를 탐험할 수 있다.
   2. 도구가 결정하는 것: 도구의 유무는 과업 자체의 가능 여부보다 그 과업을 싸고 반복적으로 수행할 수 있는지, 즉 확장 가능한지를 결정한다.
   3. 경제성의 기준: 싸게 수행할 수 있는 일이 많은 사람에게 반복될 수 있고, 그때 비로소 업무 자동화의 가치가 생긴다.

2. 도구 최적화는 성능의 천장을 올린다

   1. 천장 개념: 검색 시스템이 계속 틀리는 지점은 모델의 노력만으로 넘을 수 없는 도구의 성능 천장일 수 있다.
   2. 개선 시점: 도구는 무조건 추가하는 것이 아니라 원하는 성능에 도달하지 못하고 천장에 부딪힐 때 개선해야 한다.
   3. 조직과의 결합: 도구만 좋아져도 충분하지 않고, 문제를 나누고 결과를 합치는 조직 방식과 함께 설계해야 한다.

5. 실제 지식 업무는 계층적 조직과 검색 에이전트를 요구한다

법률 회사의 의뢰 처리처럼 실제 문제는 열린 질문에서 시작하므로, 주 에이전트가 질문을 분해하고 하위 검색 에이전트가 전문 조사를 수행하는 구조가 필요하다.

5.1. 파트너-연구자 구조의 법률 사례

1. 큰 그림을 잡는 파트너

   1. 의뢰 접수: 고객은 기관의 대표 변호사나 로펌 파트너에게 자신의 상황과 문제를 설명한다.
   2. 문제 구조화: 파트너는 사실관계와 문제를 파악하고, 필요한 법률·관련 측면·고객 목표를 정리한다.
   3. 직접 조사하지 않음: 파트너가 법률 조사 모든 단계를 직접 수행하지는 않는다.

2. 훈련된 보조자와 메모

   1. 역할 분담: 보조자 또는 연구자는 파트너가 정한 측면을 조사하고, 훈련받은 검색 도구를 사용한다.
   2. 산출물: 조사자는 결과를 메모(memo)로 작성해 파트너에게 돌려준다.
   3. 최종 판단: 파트너는 메모를 주된 근거로 답변하고, 필요한 경우 한 가지 명확화 지점만 추가로 조사한다.

5.2. 코딩 에이전트와의 대비

1. 코딩은 사용자가 이미 문제를 줄여 준다

   1. 명확한 작업: 기능이나 수정 항목처럼 이미 범위가 정해진 일을 에이전트에 전달한다.
   2. 직접 분해: 사용자가 무엇을 원하는지 알고 있어, 에이전트에 주는 질의가 선형적이고 구체적이다.
   3. 제한된 탐색: 에이전트는 새로운 문제를 정의하기보다 정해진 코드베이스에서 구현·수정하는 데 집중한다.

2. 열린 지식 문제는 에이전트가 분해해야 한다

   1. 문제의 출발점: 실제 고객의 질문은 수천 개의 문서와 여러 조건을 포함하는 열린 문제다.
   2. 하위 과제: 주 에이전트는 질문을 법률·사실·목표 등 측면으로 분해하고 각 측면에 필요한 검색 질의를 작성해야 한다.
   3. 계층적 실행: 하위 검색 에이전트가 각자 조사하고 메모를 반환하면 주 에이전트가 이를 종합해 답변한다.

6. MQA 벤치마크와 검색 에이전트 아키텍처

PDF와 OCR을 포함한 기업형 과제에서는 멀티모달 도구와 검색을 분담하는 에이전트 조직을 함께 써야 인간 수준에 가까워진다.

6.1. 도구만으로도 생기는 성능 천장

1. MQA의 구성

   1. 출처와 과제: MQA는 Hugging Face와 Snowflake가 공동 공개한 지식 질의응답(knowledge benchmark)이다.
   2. 기업형 문서: PDF와 그 PDF의 OCR 버전을 사용하는 엔터프라이즈 과제다.
   3. 핵심 관찰: 단순한 BM25를 아무리 최적화해도 사람과 Gemini 3가 같은 천장에 부딪힌다.

2. 인간도 나쁜 도구의 한계를 넘지 못한다

   1. 오해 금지: 사람과 Gemini 3가 같은 점수라는 말은 Gemini 3가 인간만큼 똑똑하다는 뜻이 아니다.
   2. 도구의 한계: 무제한 검색을 허용해도 BM25가 올바른 정보를 찾아주지 못하면 인간도 그 천장을 넘을 수 없다.
   3. 결론: 도구 최적화는 에이전트 성능만이 아니라 인간과 AI 모두의 정보 접근 상한을 높이는 과정이다.

6.2. 멀티모달 검색과 남은 오라클 격차

1. PDF를 직접 이해하는 도구

   1. OCR 의존 탈피: 모델이 PDF를 직접 처리하고 비전(vision)을 사용할 수 있게 되면 OCR 텍스트만 읽을 필요가 없다.
   2. Mixbread 검색 도구: Gemini와 Mixbread의 완전 멀티모달 검색 도구는 PDF의 본문뿐 아니라 표와 시각적 정보를 검색 과정에 포함한다.
   3. 정확도 상승: 이 변화는 텍스트 검색만 사용할 때보다 큰 정확도 상승을 만든다.

2. 에이전트와 인간 사이의 격차

   1. 점수: 멀티모달 도구를 쓰는 에이전트는 약 88.9%, 인간은 99.4%를 기록했다.
   2. 남은 문제: 에이전트가 결과를 최대 10턴 동안 생각할 수 있는 완전한 agentic system인데도 약 10%포인트가 남는다.
   3. 해석: 모델의 추론만 늘리는 것으로는 충분하지 않고, 검색 업무를 어떻게 조직하는지가 추가로 필요하다.

6.3. Mixbread Search Agent의 분업 방식

1. 주 에이전트가 질의를 분해한다

   1. 문제 인식: 주 에이전트가 “이 주제는 너무 크고 PDF가 수천 개이므로 직접 전부 검색하지 않겠다”고 판단한다.
   2. 검색 계획: 답변에 중요한 측면을 정하고 각 측면에 대한 질의를 작성한다.
   3. 전문 에이전트 호출: 검색자(searcher)들이 독립적으로 해당 질의를 실행해 관련 결과를 찾는다.

2. 메모를 모아 최종 답변을 만든다

   1. 중간 산출물: 검색자는 찾은 결과를 짧은 메모 형태로 주 에이전트에게 전달한다.
   2. 종합: 주 에이전트는 여러 메모를 비교하고 질문의 전체 맥락에 맞게 답변을 작성한다.
   3. 효과: 이 아키텍처는 정확도를 3.5%포인트 끌어올렸다.

3. 오라클 격차를 줄인다

   1. 정의: 오라클 격차(oracle gap)는 완벽한 문서를 알고 있을 때의 성능과 실제 검색 시스템이 찾아낸 문서로 얻는 성능의 차이다.
   2. 변화: 검색 에이전트를 쓰기 전 격차는 약 10%포인트였고, 사용 후 약 6%포인트로 줄었다.
   3. 의미: 더 나은 검색 아키텍처만으로 실수가 약 40% 줄고, 인간과 에이전트 사이의 격차도 40% 감소했다.

주요 발언 모음

“에이전트는 지식 업무를 해야 하고, 지식 노동자처럼 설계해야 한다. 코딩 에이전트처럼 설계해서는 안 된다.”

“코드는 지식이지만, 모든 지식이 코드인 것은 아니다.”

“도구는 작업을 혼자 수행하기 위해 존재하는 것이 아니라, 성능의 천장을 넘기 위해 존재한다.”

“도구는 에이전트와 함께 공동 설계되어야 한다.”

“컨텍스트는 유한한 자원이다.”

“25번 호출해야 하는 도구라면 쓰지 않겠지만, 8번 호출이면 도입할 수 있는 워크플로가 된다.”

핵심 데이터 & 수치

• 초기 에이전트 시기: 2022년 무렵에는 RAG 중심이었고 도구 호출이 불가능했다.
• BrowseComp+ 규모: 약 20만 개 문서와 구체적인 딥 리서치 질의를 사용한다.
• 검색 정확도: 최적화되지 않은 BM25는 약 60%, 최적화한 도구는 70~80%대, 최적의 hybrid harness는 약 90.2%다.
• 도구 호출 절감: 90.2% 정확도에 도달한 검색 도구는 20% 적은 호출로 같은 성능을 냈다.
• 비용 절감: 최적화되지 않은 기준선과 비교하면 도구 비용이 처음의 약 5% 수준으로 줄었다.
• 실제 호출 예시: 25회 호출은 부담스럽지만 8회 호출은 실무 워크플로로 도입할 수 있는 수준이다.
• MQA 정확도: 멀티모달 검색 에이전트는 88.9%, 인간은 99.4%를 기록했다.
• 검색 에이전트 효과: 정확도가 3.5%포인트 상승하고, 오라클 격차가 약 10%포인트에서 6%포인트로 줄어 실수가 약 40% 감소했다.
• 멀티모달 범위: 거대한 컨텍스트 창이 있어도 1개 주의 법률 코드 절반도 채우기 어렵고, 미국 전체 법률이나 국제법·전문 과정까지 담을 수는 없다.

결론 및 시사점

1. 코딩은 일반 모델이 아니라 특수 사례로 취급해야 한다: 코드의 검색 가능한 구조와 이미 분해된 티켓 중심 작업은 모든 지식 업무의 표준이 아니다.
2. 지식 노동자의 조직을 에이전트 아키텍처로 옮겨야 한다: 파트너가 문제를 정의하고 연구자가 조사해 메모를 만드는 법률 조직처럼, 주 에이전트·검색 에이전트·사람의 역할을 분리한다.
3. 검색 도구는 작업의 경제성을 결정한다: 정확도뿐 아니라 호출 수, 토큰, 비용을 줄여야 지식 업무가 실제로 확장된다.
4. 여러 검색 primitive를 함께 훈련해야 한다: grep과 BM25는 lexical search의 primitive이고, PDF에는 semantic search와 멀티모달 검색이 필요하다. 에이전트가 학습 데이터에 자주 보이는 BM25 질의만 자동으로 쓰지 않도록 각 도구의 적합성을 알아야 한다.
5. 도구와 에이전트를 공동 설계한다: 검색 도구의 인터페이스와 에이전트의 질의 분해·결과 평가 방식은 서로 맞물려야 한다.
6. 컨텍스트를 무한히 늘리는 전략은 답이 아니다: 1억 토큰 컨텍스트도 비용이 매우 크고 법률 지식 전체를 담기에는 부족하므로, 오케스트레이터가 문제를 나누고 주 에이전트가 하위 조사 결과를 조합해야 한다.
7. 수세기의 지식 조직 경험을 재사용한다: 도서 목록, 검색 엔진, 대학, 전문 회사와 병원이 발전시킨 도구·훈련·역할 분화가 지식 에이전트 설계의 청사진이다.

핵심 요약 (20줄)

1. 지식 에이전트는 코딩 에이전트의 기능을 확장하는 수준이 아니라 지식 노동자와 조직의 구조를 본떠 설계해야 한다.
2. 2022년 초기 에이전트는 RAG와 단순 검색에 머물렀고 도구 호출조차 제대로 수행하지 못했다.
3. 코딩 에이전트는 검색과 도구 호출이 발전하면서 대중화됐지만 지식 업무 전체를 대표하지는 않는다.
4. 법률·금융·의료·연구 업무는 정보 검색과 맥락 해석, 판단과 결정을 함께 요구한다.
5. 지식 업무는 물리적 재료가 아닌 모호하고 흩어진 정보를 실행 가능한 결과로 바꾸는 일이다.
6. 코드는 식별자·파일 경로·함수 정의처럼 오래 유지되는 검색 단서가 많아 에이전트가 다루기 상대적으로 쉽다.
7. 코딩 요청은 기능이나 티켓 단위로 이미 분해되어 있어 에이전트가 해결할 범위가 비교적 분명하다.
8. 비코드 지식에서 같은 30일이라는 표현은 기한·유예 기간·보존 규칙 등 서로 다른 뜻을 가질 수 있다.
9. 법률 검색은 특정 규칙을 찾는 데서 끝나지 않고 국제 규범과 사건의 적용 조건을 함께 검토해야 한다.
10. 글쓰기·목록화·서지·검색 엔진의 발전은 지식을 찾는 비용을 낮추며 새로운 업무를 가능하게 했다.
11. 폴리매스 한 명에게 의존하던 지식 조직은 수도원·대학·관료제와 전문화된 기업으로 진화했다.
12. 새 지식은 더 나은 도구를 만들고, 새 도구는 새로운 역할과 훈련을 만들며, 그 결과 더 많은 지식이 생산된다.
13. BrowseComp+는 약 20만 개 문서에서 검색 도구의 정확도와 비용을 비교하는 딥 리서치 벤치마크다.
14. 최적화되지 않은 BM25의 정확도는 약 60%였지만 최적화와 하이브리드 검색으로 약 90.2%까지 높아졌다.
15. 90.2% 정확도에 도달한 검색 방식은 도구 호출을 20% 줄였고 기준선 대비 비용을 약 5%로 낮췄다.
16. 실제 법률 업무처럼 열린 질문을 다루려면 파트너가 문제를 구조화하고 연구자가 메모를 작성하는 분업이 필요하다.
17. MQA에서 멀티모달 검색 에이전트는 88.9%, 인간은 99.4%를 기록해 도구와 조직의 추가 개선 여지를 보였다.
18. Mixbread Search Agent는 주 에이전트가 질의를 쪼개고 검색 에이전트들이 메모를 모으도록 해 정확도를 3.5%포인트 높였다.
19. 검색 에이전트 아키텍처는 오라클 격차를 약 10%포인트에서 6%포인트로 줄여 실수를 약 40% 감소시켰다.
20. 유한한 컨텍스트를 효율적으로 쓰려면 lexical·semantic·멀티모달 도구를 에이전트가 구분해 사용하고 검색을 오케스트레이션해야 한다.