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

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

---

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

AI 에이전트가 코딩을 넘어 법률·의료·금융·연구 같은 지식 업무를 수행하려면, 코드 작업에 특화된 에이전트 구조를 그대로 확대해서는 안 된다. ==지식 노동자가 수세기 동안 발전시킨 업무 분해·검색·전문가 조직의 구조를 에이전트 아키텍처에 옮겨야 한다.==

• 코드는 식별자·파일·경로처럼 오래 유지되는 단서와 검색 가능한 표면 구조를 갖지만, 비코드 지식은 같은 단어도 도메인과 의도에 따라 의미가 달라진다.
• 검색 도구의 품질만 높이는 것과 실제 지식 업무를 맡길 수 있는 조직 구조를 만드는 것은 별개의 문제이며, 둘을 함께 설계해야 한다.
• 200,000개 문서 규모의 BrowseComp+와 PDF 기반 MQA 벤치마크에서 최적화된 검색과 검색 하위 에이전트가 호출 수·비용·정확도를 동시에 개선했다.

지식 업무의 입력은 손으로 만질 수 있는 재료가 아니라 모호하고 흩어진 정보이며, 출력은 판단·결정·법률 의견처럼 실행 가능한 지식이다. 따라서 지식 에이전트는 질문 하나에 검색 한 번을 붙인 시스템이 아니라, 의도를 해석하고 문제를 하위 문제로 나누며 여러 검색 담당자와 도구를 조율하고 결과를 다시 종합하는 시스템이어야 한다. 코딩 에이전트에서 익숙한 선형 티켓 처리 방식을 법률·의료·연구 문제에 그대로 적용하면 맥락과 조건을 놓치기 쉽다.

1. 에이전트의 중심이 코딩에서 지식 업무로 이동하다

초기 에이전트는 문서 검색과 간단한 질의응답에 머물렀고, 이후 도구 호출이 가능한 코딩 에이전트가 에이전트 개발의 표준처럼 자리 잡았다. 다음 단계는 코딩을 지식 업무의 한 특수 사례로 다시 위치시키는 것이다.

1.1. 초기 에이전트에서 코딩 에이전트까지

1. 2022년 무렵의 초기 에이전트

   1. RAG와 조건문 중심 구조: 초기 에이전트는 사실상 if 문으로 검색을 실행하고 결과를 돌려주는 수준이었다. Retrieval-Augmented Generation(RAG)으로 PDF와 대화할 수 있었지만, 당시에는 에이전트가 제대로 도구를 호출하지도 못했다.
   2. 낮은 실용성: 재미있는 상식이나 문서 속 정보를 말해주는 정도였고, 복잡한 업무를 끝까지 수행하는 시스템은 아니었다.

2. 도구 호출 이후의 코딩 에이전트

   1. 검색과 도구 사용의 발전: 에이전트가 제대로 검색하고 작업을 이해하며 도구를 호출하기 시작하자 프로그래밍 에이전트가 급속히 확산됐다.
   2. 익숙한 사용 사례: 개발자들은 Codex와 같은 코딩 에이전트를 사용해 특정 기능이나 티켓을 처리한다. 코딩도 지식 업무의 한 종류이지만, 코딩 에이전트가 곧 지식 노동자 전체를 의미하지는 않는다.

1.2. 지식 에이전트는 코딩을 포함하는 더 큰 범주다

1. 지식 업무의 범위

   1. 법률: 변호사 에이전트는 법률 문서를 찾고, 사건에 적용할 규칙과 판례를 검토한다.
   2. 금융: 금융 에이전트는 재무 정보와 시장 자료를 찾아 판단에 필요한 근거를 만든다.
   3. 의료: 약물·질병 정보를 찾거나 온라인에서 자기 진단을 시도하는 사람을 돕는 의료 활용 사례가 있다. 다만 정보 검색과 실제 의료 판단은 구분해야 한다.
   4. 소프트웨어: 코딩 역시 정보를 처리해 실행 가능한 결과를 만드는 지식 업무이며, RAG 기반 문서 검색은 그중 매우 작은 구성 요소다.

2. 코딩을 지식 업무의 기본값으로 삼을 때 생기는 오류

   1. 한 도메인에 과도하게 맞춘 설계: 코드의 특성 때문에 잘 작동하는 검색·계획·실행 패턴을 모든 지식 문제에 적용하면 의미와 맥락을 잃는다.
   2. 업무 형태의 오해: 법률 사건이나 연구 질문은 미리 정해진 기능 하나를 구현하는 일이 아니라, 무엇을 찾아야 하는지부터 발견하는 일이다.

2. 지식 업무의 정의와 코드가 특별히 쉬운 이유

지식 업무는 정보가 주된 입력이고, 모호한 정보를 처리해 판단이나 결정을 출력하는 일이다. 코드는 지식이지만, 검색과 자동화에 유리한 특수한 형태의 지식이다.

2.1. 지식 업무의 두 가지 정의

1. 정보 입력과 실행 가능한 출력

   1. 주된 입력은 정보: 손으로 만질 수 있는 물리적 재료가 아니라 문서·사실·규정·데이터·맥락이 작업의 출발점이다.
   2. 정보는 모호하고 흩어져 있음: 지식은 한 곳에 정리된 부품처럼 주어지지 않으며, 서로 다른 자료를 연결하고 의미를 해석해야 한다.
   3. 출력은 실행 가능한 판단: 결과는 물리적 제품이 아니라 결정, 의견, 연구 결과, 사건에 대한 법률적 판단처럼 실제 행동으로 이어지는 지식이다.
   4. 법률 사례: 변호사는 의뢰인의 사건에서 발견한 사실과 법률적 결론을 제시하고, 필요하면 의뢰인을 위해 변론한다.

2. 검색이 필요한 문제라는 순환적 정의

   1. 검색이 필요한 문제는 지식 문제: 정답이 이미 손에 있지 않고 찾아야 한다면 지식 업무에 해당한다.
   2. 지식 문제에는 검색이 필요: 지식 문제라면 관련 자료와 조건을 찾아야 하므로 검색이 필수 도구가 된다.
   3. 서비스 경제와의 연결: 변호사, 학자, 보험계리사(actuary), 소프트웨어 엔지니어, 연구자는 모두 주된 작업 재료가 정보인 지식 노동자다. 서비스 경제에서 수행되는 업무 상당수가 이 범주에 들어간다.

2.2. 코드의 내구성·검색 가능성·좁은 과업

1. 코드의 내구성 있는 단서

   1. 식별자·파일·경로: 코드베이스에는 함수·변수 식별자, 파일명, 파일 경로 같은 참조가 반복된다.
   2. 높은 안정성: 바이브 코딩으로 구조가 바뀔 수는 있어도 대체로 이런 단서는 오래 유지된다.
   3. 표면적으로 검색 가능: 키워드, 메서드 정의, 호출 관계처럼 텍스트에서 직접 잡아낼 수 있는 요소가 많다. 그래서 grep 같은 어휘 검색이 강력한 출발점이 된다.

2. 코딩 작업의 명시적 범위

   1. 기능·티켓 중심: 개발자는 보통 특정 기능이나 티켓을 제시하고 에이전트가 해결하도록 한다.
   2. 사용자가 이미 상당 부분 분해: 어떤 파일을 고칠지, 어떤 동작을 만들어야 할지, 성공 조건이 무엇인지 사용자가 먼저 정리하는 경우가 많다.
   3. 비현실적인 요구와의 대비: 에이전트에게 “새로운 프로그래밍 패러다임을 발견하고 새 앱에 구현하라”고 말하는 식의 완전히 열린 과업은 일반적인 코딩 에이전트 사용 방식이 아니다.

2.3. 비코드 지식은 의미와 의도에 의존한다

1. 같은 단서의 다중 의미

   1. ‘30일’의 예시: 계약에서 ‘30일’은 마감일(deadline)일 수 있고, 유예 기간(grace period)이나 보존 규칙(retention rule)일 수도 있다.
   2. 도메인 혼동: 계약의 30일을 찾으려 했는데 검색 결과에 약물 복용 기간이 등장할 수도 있다. 동일한 숫자와 단어만으로는 의미를 판별할 수 없다.
   3. 코드의 함수 정의 부재: 비코드 지식에는 코드의 함수 정의처럼 단어의 의미를 고정해주는 구조가 없다.

2. 의도에서 출발하는 검색

   1. 질문보다 먼저 목적을 파악: 법률 질문에서 특정 규칙을 특정 영역에 적용하려면, 해당 국제 규범과 관할 규칙을 먼저 찾고 그것이 현재 사건에 적용되는지 판단해야 한다.
   2. 조건이 사전에 정해지지 않음: 어떤 규정이 관련 있는지, 예외가 있는지, 사실관계가 조건을 충족하는지는 에이전트가 조사하며 발견해야 한다.
   3. 맥락·의미 중심의 난이도: 비코드 지식은 단어 매칭보다 맥락과 의도를 더 많이 요구하므로 코드보다 어렵다.

3. 지식의 발전을 이끈 도구 루프와 조직 루프

인류는 지식 문제를 새로 발명한 것이 아니다. 더 많은 지식을 다루기 위해 검색 도구와 전문 조직을 함께 발전시켜 왔고, 이 두 흐름은 사실 하나의 자기 최적화 루프다.

3.1. 도구의 역사: 기록에서 검색 엔진까지

1. 기록과 분류의 시작

   1. 말로만 전달하던 단계에서 기록으로: 누군가 지식을 기록하자 지식의 보존과 재사용이 가능해졌다.
   2. 알렉산드리아 도서관의 Pinakes: 알렉산드리아 도서관의 큐레이터는 보유 도서를 목록화하는 방법을 제안했다. 책이 있다는 사실만으로는 부족하고, 어느 책을 어디서 찾을지 알아야 했기 때문이다.
   3. 서지와 도서관 시스템: 기록 이후 서지(bibliography)가 발전했고, 현대에는 도서관의 그래픽 사용자 인터페이스(GUI)와 검색 엔진으로 이어졌다.

2. 검색 도구가 확장한 지식의 사용 범위

   1. 도구 전후의 시간 차이: 알렉산드리아 도서관에서 목록이 없던 시기에는 원하는 원고를 찾는 데 2~3주가 걸릴 수 있었다. 목록이 있으면 약 10분 만에 찾을 수 있다.
   2. 탐색의 경제성: 검색이 싸고 빨라지면 “정말 필요한 지식인가?”를 오래 고민하지 않고 바로 확인할 수 있다.
   3. 지도라는 정보 도구: 지도와 지명 목록이 있으면 세계를 탐험하는 방식 자체가 달라진다. 인도로 가는 길에 우연히 아메리카를 발견할 때까지 기다리는 대신 목적지를 알고 움직일 수 있다.
   4. 멀티모달 문서 검색: 수백만 개의 PDF를 검색할 수 있는 플랫폼은 과거라면 기록 보관소에 묻혔을 자료를 실제 업무에 활용 가능한 정보로 바꾼다.

3.2. 조직의 역사: 천재 한 명에서 전문 기관으로

1. 개인 전문가 모델의 한계

   1. 폴리매스의 시대: 과거에는 한 분야 또는 여러 분야를 거의 모두 아는 뛰어난 전문가를 찾아가 정보를 얻는 방식이 가능했다.
   2. 확장되지 않는 구조: 한 사람이 모든 질문을 알고 처리하는 모델은 지식의 양이 커질수록 병목이 된다.

2. 전문화된 조직의 등장

   1. 수도원: 수도원은 지식의 수호자 역할을 하며 자료를 보존했다.
   2. 대학: 대학은 지식을 가르치고 전문 인력을 재생산하는 조직으로 발전했다.
   3. 관료제: 더 큰 규모의 업무를 나누고 각 역할을 제도화하는 관료 조직이 등장했다.
   4. 현대의 전문 기업: 병원에는 의사, 선임 의사, 전문 간호사(nurse practitioner), 간호사, 간호 보조 인력이 있으며, 각자가 서로 다른 수준의 작업을 담당한다. 역할별 전문화는 전체 업무를 최적화한다.

3.3. 도구와 조직은 하나의 자기 최적화 루프다

1. 두 루프의 결합

   1. 새 지식 → 새 도구: 지식이 늘면 기존 검색·정리 도구의 한계가 드러나 더 좋은 도구가 필요해진다.
   2. 새 도구 → 새 역할과 업무 흐름: 도구를 사용할 줄 아는 사람, 도구의 의미를 이해하는 사람, 도구 결과를 검증하는 사람이 필요해진다.
   3. 새 역할 → 더 많은 지식: 재훈련된 지식 노동자가 더 효율적으로 일하고 새로운 지식을 만들면서 다시 도구의 요구 수준을 높인다.

2. 도서관에서 Google로의 재훈련 사례

   1. 도서관에 가서 자료를 찾던 사람에게 Google을 사용하라고 하면, 단순히 새 버튼을 알려주는 것이 아니다.
   2. Google이 검색 엔진이며 물리적으로 도서관에 갈 필요 없이 검색어를 입력할 수 있다는 도구의 작동 원리를 가르쳐야 한다.
   3. 새로운 도구를 사용할 수 있도록 사람을 재교육해야 하며, 그렇게 길러진 지식 노동자가 다시 지식 생산성을 높인다.

4. 도구 최적화가 지식 업무의 확장성을 결정한다

도구는 단순한 부가 기능이나 검색 속도 개선 옵션이 아니다. 어떤 작업이 값싸고 반복 가능하며 확장 가능한지를 결정한다.

4.1. 도구는 가능성보다 확장성을 바꾼다

1. 가능한 일과 실제로 할 수 있는 일의 차이

   1. 올바른 도구가 없어도 작업 자체는 수행할 수 있다. 하지만 시간이 너무 오래 걸리면 실제 서비스나 제품으로 확장할 수 없다.
   2. “싸다”는 말은 반복해서 규모 있게 수행할 수 있다는 뜻이다. 도구는 지식을 찾는 비용을 낮춰 새로운 사용 사례를 만든다.

2. 도구의 비중립성

   1. 검색이 5% 빨라지는 정도의 부가 기능으로 보면 도구의 역할을 과소평가하게 된다.
   2. 검색 목록, 지도, 멀티모달 플랫폼은 어떤 질문을 할 가치가 있는지와 어떤 업무를 수행할 수 있는지를 바꾼다.
   3. 따라서 도구의 존재 여부는 과업이 논리적으로 가능한가보다, 저렴하고 반복 가능하게 수행 가능한가를 결정한다.

4.2. BrowseComp+ 검색 벤치마크의 교훈

1. 벤치마크의 조건

   1. BrowseComp+ 리더보드는 검색 도구의 품질을 평가하기 위한 벤치마크다.
   2. 발표자는 약 200,000개 문서와 특정 질의로 구성된 깊은 연구(deep research) 과제를 설명했다. 후반에는 같은 유형의 과제를 100,000개 문서 규모라고도 표현했는데, 핵심은 대규모 문서 집합에서 검색 도구를 비교한다는 점이다.
   3. 과제는 완전히 열린 연구라기보다 다소 복잡하게 구성된 단일 질문에 가깝기 때문에 실제 지식 업무보다 쉽다.

2. BM25의 오해와 최적화

   1. BM25는 하나가 아님: BM25는 어휘 검색(lexical search) 방식이며, 적용·가중치·전처리에 따라 수백 가지 구현과 설정이 가능하다.
   2. 나쁜 기준선: 최적화하지 않은 BM25는 약 60% 정확도에 머문다. 60%만 맞히는 사람을 신뢰하지 않고 직접 확인하듯, 이 수준의 도구는 실무에 쓰기 어렵다.
   3. 최적화된 기준선: 최적화하면 70~80% 수준까지 올라간다.
   4. 하이브리드 하네스: 가장 좋은 하이브리드(hybrid) 검색 하네스는 약 90% 정확도에 도달한다.

3. 정확도보다 중요한 호출 비용

   1. 88.9%에서 89.8%, 다시 90.2%로 오르는 차이는 실행 분산(run variance)일 수 있어 그 자체로 큰 의미가 없을 수 있다.
   2. 중요한 사실은 90.2% 정확도를 내면서 도구 호출을 20% 줄였다는 점이다.
   3. 호출 20% 감소는 토큰과 컴퓨팅 자원 20% 절감이며, 발표자는 이를 “20% 공짜 현금”에 비유했다.
   4. 최적화하지 않은 기준선과 비교하면 처음 비용의 약 5%만 쓰게 된다.
   5. 한 작업에 25번 호출해야 하면 아무도 지속적으로 쓰지 않지만, 8번 호출이면 조직의 실제 워크플로에 넣을 수 있다.

5. 실제 지식 업무는 계층형 조직과 하위 에이전트로 수행된다

검색 도구가 좋아도 열린 문제를 한 에이전트가 처음부터 끝까지 처리하게 해서는 안 된다. 법률 회사의 파트너·보조 연구자 구조처럼, 문제를 이해하는 주체와 자료를 조사하는 주체를 분리해야 한다.

5.1. 법률 회사의 지식 업무 흐름

1. 의뢰인과 파트너의 첫 만남

   1. 의뢰인은 회사의 핵심 파트너 또는 큰 결정을 내리는 변호사에게 상황과 문제를 설명한다.
   2. 파트너는 의뢰인의 문제를 사실관계로 정리하고, 어떤 법률과 어떤 측면을 찾아야 하는지 파악한다.
   3. 의뢰인의 목표와 사건을 해결하기 위해 필요한 결과도 함께 확인한다.

2. 보조 연구자와 메모

   1. 파트너가 모든 법률 조사와 세부 작업을 직접 수행하지는 않는다.
   2. 보조 연구자(assistant 또는 searcher)는 관련 법률과 판례를 조사하고, 회사에서 훈련한 검색 도구를 사용한다.
   3. 조사자는 결과를 메모(memo)로 작성해 파트너에게 돌려준다.
   4. 파트너는 필요하면 한 가지 쟁점을 추가 확인하지만, 전체 판단의 상당 부분은 보조 연구자가 찾은 자료에 의존한다.

5.2. 코딩과 열린 지식 문제의 차이

1. 코딩에서의 사용자 역할

   1. Cloud Code 같은 코딩 도구를 사용할 때 사용자는 이미 질문을 작업 단위로 쪼개고 원하는 결과를 비교적 선형적으로 전달한다.
   2. 에이전트는 그 작업을 코드베이스에서 실행하면 된다.

2. 열린 지식 문제에서의 에이전트 역할

   1. 의뢰인의 문제는 무엇을 찾아야 할지부터 열려 있다.
   2. 메인 에이전트는 법률 파트너처럼 문제를 하위 문제와 조사 측면으로 분해해야 한다.
   3. 하위 에이전트는 각 측면의 검색을 수행하고 짧은 메모를 제출한다.
   4. 메인 에이전트는 여러 메모를 종합해 최종 답변을 작성한다.

6. MQA 벤치마크에서 확인한 도구·조직의 결합 효과

PDF와 OCR에 의존하는 기업형 질의응답에서는 검색 도구의 한계와 에이전트 조직의 한계가 함께 드러난다. 멀티모달 검색과 검색 하위 에이전트가 순서대로 개선을 만든다.

6.1. MQA의 설정과 BM25의 성능 상한

1. 문서와 과제

   1. MQA는 Hugging Face와 Snowflake가 공동 공개한 지식 벤치마크다.
   2. 기업 환경의 PDF 기반 과제를 다루며, PDF 원문과 OCR(Optical Character Recognition) 버전을 함께 사용한다.

2. 도구가 정한 상한

   1. 최적화된 BM25로 검색하면 인간과 Gemini 3가 같은 성능 상한에 도달한다.
   2. 이것은 Gemini 3가 인간만큼 똑똑하다는 뜻이 아니다.
   3. 무제한으로 검색해도 BM25가 적절한 정보를 제공하지 못하면 인간 역시 정답을 찾지 못한다. 즉 검색 도구 자체가 성능의 천장을 만든다.

6.2. 멀티모달 검색으로 OCR 한계를 넘다

1. 새로운 모델과 도구

   1. 최근 모델은 PDF를 직접 읽고 시각 정보를 처리할 수 있다.
   2. 표·레이아웃·시각적 구조를 OCR 텍스트로 납작하게 만들지 않고 검색에 활용할 수 있다.
   3. Gemini와 Mixbread 검색 도구를 결합한 완전한 멀티모달 검색은 기존 방식보다 정확도를 크게 높인다.

2. 남은 성능 격차

   1. 멀티모달 도구를 사용해도 에이전트는 88.9% 정확도에 머물고 인간은 99.4%에 도달한다.
   2. 약 10%포인트의 차이는 에이전트가 단순히 더 많은 턴을 생각하면 해결되는 문제가 아니다. 벤치마크의 에이전트는 약 10턴을 사용할 수 있는 완전한 agentic system이다.
   3. 검색 결과를 읽고 생각하는 능력만으로는, 어떤 하위 질문을 어떤 도구로 조사할지 결정하는 구조적 문제를 해결하지 못한다.

6.3. Mixbread 검색 에이전트의 문제 분해

1. 메인 에이전트가 맡는 일

   1. 메인 에이전트는 수천 개의 PDF를 혼자 검색하지 않는다.
   2. “이 주제는 너무 크니 문제를 분해해 달라”고 지시받고, 최종 답변에 중요한 측면을 나눈다.
   3. 각 측면에 맞는 검색 질의를 작성한다.

2. 검색자와 메모의 역할

   1. 검색 하위 에이전트는 각자 질의를 가지고 독립적으로 자료를 찾는다.
   2. 발견한 결과를 짧은 메모로 정리해 메인 에이전트에게 반환한다.
   3. 메인 에이전트는 여러 메모를 근거로 답변을 작성한다.

3. 정확도와 오류의 변화

   1. 검색 에이전트를 도입하면 정확도가 3.5%포인트 상승한다.
   2. 수치 자체는 작아 보이지만, 완벽한 문서를 알고 있을 때와 실제 검색 시스템이 찾아준 문서 사이의 차이인 오라클 갭(oracle gap)을 줄인다는 의미가 있다.
   3. 에이전트 도입 전 오라클 갭은 약 10%포인트였고, 도입 후 약 6%포인트로 줄었다.
   4. 인간과 에이전트 사이의 성능 격차에서 발생하는 오류를 약 40% 줄였다.

7. 지식 에이전트 설계 원칙

지식 에이전트의 핵심은 더 큰 모델 하나가 아니라, 수세기 동안 전문 조직이 만들어온 문제 분해·도구 사용·역할 분담을 AI 시스템에 구현하는 데 있다.

7.1. 이미 검증된 인간 조직을 에이전트 구조로 옮기기

1. 역사적 패턴의 재사용

   1. 제국은 사서를 두었고, 법률 산업은 파트너와 패러리걸(paralegal), 연구자를 분리해 운영해 왔다.
   2. 의료 산업은 의사·선임 의사·전문 간호사·간호사·보조 인력으로 업무를 나눈다.
   3. 이 구조들은 모두 한 사람이 모든 문서를 읽고 모든 결정을 내리는 방식을 피한다.

2. 코딩 시스템과의 구별

   1. 프로그래밍은 매우 구체적인 사용 사례이므로 자체적인 도구와 작업 흐름을 갖는다.
   2. 법률·의료·연구용 에이전트는 프로그래밍 패턴을 그대로 복제하기보다 각 분야의 지식 조직 방식을 배워야 한다.
   3. 지식 업무를 하는 에이전트는 지식 노동자처럼 설계해야 하며, 코딩 에이전트처럼만 설계해서는 안 된다.

7.2. 도구는 한계를 만났을 때 개선하기

1. 도구의 목적

   1. 도구는 스스로 작업을 수행하는 장식품이 아니라 성능의 천장을 뚫는 수단이다.
   2. 현재 성능이 원하는 수준에 도달하지 못해 상한에 부딪혔을 때 더 나은 도구를 설계해야 한다.

2. 도구와 에이전트의 공동 설계

   1. 에이전트가 도구를 어떻게 사용해야 하는지 알지 못하면 좋은 검색 도구도 충분한 효과를 내지 못한다.
   2. 모델은 학습 데이터에서 자주 본 grep과 BM25를 기본값으로 선택하기 쉽다.
   3. PDF를 grep할 수 없고, PDF를 BM25로 처리하는 것만으로는 문서의 표와 의미 구조를 제대로 다룰 수 없다.
   4. 의미 검색(semantic search)이 필요한 상황에서는 더 나은 질의를 만들고 적절한 검색 원시 기능(primitive)을 선택해야 한다.

7.3. 여러 검색 원시 기능을 아는 하네스

1. 도구 선택의 폭

   1. grep은 하나의 원시 기능이다.
   2. BM25도 하나의 원시 기능이다.
   3. 의미 검색은 또 다른 원시 기능이며, 멀티모달 PDF 검색처럼 별도의 능력이 필요한 도구도 있다.

2. 에이전트의 학습 과제

   1. 에이전트 하네스(agentic harness)나 agentic model은 자신에게 도구가 하나만 있는 것이 아니라는 사실을 알아야 한다.
   2. 질문의 성격과 자료 형태에 맞춰 grep, BM25, 의미 검색, 멀티모달 검색 중 무엇을 쓸지 선택해야 한다.
   3. 모델이 각 도구의 강점과 한계를 충분히 학습해야 검색 비용과 오류를 동시에 줄일 수 있다.

7.4. 컨텍스트는 유한하므로 오케스트레이션이 필요하다

1. 거대한 컨텍스트의 한계

   1. 컨텍스트가 유한한 자원이라는 사실은 100 million-token 컨텍스트 모델이 등장해도 바뀌지 않는다.
   2. 그 정도 컨텍스트를 사용하면 비용이 매우 커진다.
   3. 100 million 토큰도 미국 한 주의 법률 코드 절반에도 못 미치며, 미국 전체 법률이나 국제법·전문 분야 법률과 비교하면 훨씬 작다.

2. 필요한 역할

   1. 오케스트레이터(orchestrator)는 열린 과업을 하위 문제로 나눈다.
   2. 메인 에이전트는 각 하위 문제의 중요도와 최종 답변의 방향을 관리한다.
   3. 검색자와 전문 하위 에이전트는 지식을 찾아 정리한다.
   4. 지식을 실제로 조직하고 메모로 압축하는 역할이 있어야 제한된 컨텍스트에 필요한 근거만 남길 수 있다.

주요 발언 모음

“에이전트는 지식 업무를 해야 한다. 그러려면 지식 노동자처럼 설계해야 한다.”

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

“도구가 작업을 가능하게 하는 것이 아니라, 작업을 확장 가능하고 저렴하게 수행할 수 있게 만든다.”

“90.2% 정확도를 20% 더 적은 도구 호출로 얻는 것은 사실상 20%의 공짜 현금이다.”

“에이전트와 인간 사이의 격차는 검색 구조를 개선하는 것만으로 약 40% 줄어든다.”

“컨텍스트는 유한한 자원이다. 1억 토큰도 미국 한 주의 법률 코드 절반에 못 미친다.”

핵심 데이터 & 수치

• 17분 25초: 영상 길이. 발표 후 질의응답을 위해 약 2분을 남겼고, 박수와 감사 인사로 마무리했다.
• 2022년 무렵: RAG와 조건문 중심의 초기 에이전트가 등장한 시기.
• 2~3주 → 약 10분: 알렉산드리아 도서관에서 목록 없이 원고를 찾는 시간과, 목록이 있을 때의 탐색 시간 대비.
• 약 200,000개 문서: BrowseComp+ 검색 벤치마크를 설명할 때 제시한 문서 규모. 발표 후반에는 100,000개라고도 표현했다.
• 60% 정확도: 최적화하지 않은 BM25 기준선. 실무에서 신뢰하기 어려운 수준이다.
• 70~80% 정확도: BM25를 최적화했을 때의 개선 범위.
• 약 90%·90.2% 정확도: 하이브리드 검색 하네스가 달성한 상한권 성능.
• 20% 적은 호출: 90.2% 정확도를 유지하면서 줄어든 도구 호출·토큰·자원.
• 약 5%의 비용: 최적화하지 않은 기준선과 비교했을 때 최적화된 도구가 사용하는 비용의 비유적 비교.
• 25회 → 8회: 실제 워크플로에 넣기 어려운 호출 수와 도입 가능한 호출 수의 예시.
• 99.4% 대 88.9%: MQA에서 인간과 agentic system의 정확도 비교.
• 약 10턴: MQA 에이전트가 결과를 생각하고 검색할 수 있는 턴 수.
• +3.5%포인트: Mixbread 검색 에이전트 도입 후 정확도 상승.
• 오라클 갭 약 10%포인트 → 약 6%포인트: 검색 하위 에이전트 도입 전후의 격차.
• 약 40% 감소: 인간과 에이전트 사이의 격차에서 발생하는 오류 감소.
• 100 million 토큰: 매우 큰 컨텍스트의 예시. 비용이 크고 한 주의 법률 코드 절반에도 못 미친다.

결론 및 시사점

1. 지식 에이전트의 기본 단위는 “질문 → 검색 → 답변”이 아니라 “의도 파악 → 문제 분해 → 전문 검색 → 메모 조직 → 종합 판단”이어야 한다.
2. 코드는 식별자와 파일 경로가 안정적이고 검색 가능하므로 코딩 에이전트가 상대적으로 쉽게 작동한다. 법률·의료·금융·연구는 의미와 조건을 발견해야 하므로 별도의 구조가 필요하다.
3. 검색 정확도만 높이는 것보다 도구 호출 수와 비용을 낮춰 실제 워크플로에 넣을 수 있게 만드는 일이 중요하다.
4. BM25, grep, 의미 검색, 멀티모달 검색은 서로 대체재가 아니라 자료와 질문에 따라 선택하는 검색 원시 기능이다.
5. 에이전트는 학습 데이터에서 자주 본 도구를 자동 선택하지 말고, 어떤 자료에 어떤 도구가 적합한지 알아야 한다.
6. 인간 조직이 축적한 파트너·보조 연구자·전문가·조직자 구조를 오케스트레이터·메인 에이전트·검색 하위 에이전트 구조로 옮겨야 한다.
7. 컨텍스트를 무한히 늘리는 방식은 비용과 정보량의 한계에 부딪힌다. 중요한 지식을 분해하고 정리해 메인 에이전트에 전달하는 조직 계층이 필요하다.
8. 새로운 도구는 작업을 단순히 조금 빠르게 만드는 부가 기능이 아니라, 어떤 지식 업무를 싸고 반복 가능하게 만들 수 있는지를 바꾸는 인프라다.

핵심 요약 (20줄)

AI 에이전트는 코딩을 넘어 법률·의료·금융·연구 같은 지식 업무를 수행해야 한다. 지식 업무의 주된 입력은 물리적 재료가 아닌 모호하고 흩어진 정보다. 지식 업무의 출력은 문서 자체가 아니라 판단·결정·의견처럼 실행 가능한 지식이다. 초기 에이전트는 RAG와 조건문으로 PDF에서 정보를 찾는 수준에 머물렀다. 도구 호출이 발전하면서 코딩 에이전트가 에이전트 설계의 대표 모델이 됐다. 코드는 식별자·파일·경로처럼 오래 유지되고 직접 검색할 수 있는 단서를 갖는다. 코딩 과업은 기능이나 티켓 중심으로 사용자가 상당 부분 분해해 전달한다. 비코드 지식에서 같은 ‘30일’도 마감일·유예 기간·보존 규칙 등 여러 의미를 가질 수 있다. 법률 검색은 질문에 답하기 전에 적용할 규범과 사건의 조건부터 찾아야 한다. 인류는 기록·Pinakes·서지·도서관·검색 엔진을 거치며 지식 도구를 발전시켰다. 폴리매스 한 명에 의존하던 방식은 수도원·대학·관료제·전문 기업으로 분화됐다. 새 지식은 더 나은 도구와 새 역할을 만들고, 새 역할은 다시 더 많은 지식을 만든다. 최적화하지 않은 BM25는 약 60% 정확도에 머물러 실무에서 신뢰하기 어렵다. 하이브리드 검색 하네스는 약 90.2% 정확도를 20% 적은 호출로 달성했다. 도구 호출을 25회에서 8회로 줄이면 검색을 실제 업무 흐름에 넣을 수 있다. 법률 회사는 파트너가 문제를 정의하고 보조 연구자가 조사 메모를 작성하는 구조로 일한다. 열린 지식 문제의 메인 에이전트는 질문을 하위 과제로 나누고 검색자 에이전트를 조율해야 한다. MQA에서 인간은 99.4%, 일반 agentic system은 88.9% 정확도를 기록했다. Mixbread 검색 에이전트는 정확도를 3.5%포인트 높이고 오라클 갭을 약 40% 줄였다. 지식 에이전트는 코딩 에이전트가 아니라 지식 노동자와 전문 조직을 본떠 설계해야 한다.