[한영자막] AI에게 지식 업무를 맡기려면 '코딩 에이전트'가 아닌 '지식 에이전트'로 설계해야 합니다

한 줄 핵심

지식 업무용 AI 에이전트는 코딩 에이전트의 확장판이 아니라, 검색·분업·오케스트레이션을 중심으로 설계해야 성능과 확장성이 나온다.

시간별 요약

0:00
코딩 에이전트는 지식 작업의 특수한 사례일 뿐입니다 에이전트의 핵심 과제는 코드 생성이 아니라 지식 탐색과 활용이며, 코딩은 그중 일부에 불과하다. 지식 업무는 정보가 입력이고 판단·결정이 출력인 광범위한 작업이며, 이미 사회 전반의 서비스 노동이 이런 형태로 이루어진다.
3:35
코드가 검색하기 유독 쉬운 이유 코드는 식별자, 파일 경로, 함수 정의처럼 오래 유지되는 단서가 많고 구조도 비교적 명확해서 검색과 분해가 쉽다. 반면 지식 업무는 애초에 기대하는 과제가 더 넓고 모호하기 때문에 같은 방식으로 다루기 어렵다.
4:52
'30일'이라는 단서 하나가 4가지 의미를 가질 때 지식 업무에서는 같은 단서도 마감일, 유예기간, 보존 규칙, 다른 도메인의 수치처럼 여러 의미로 해석될 수 있다. 따라서 검색은 단순 키워드 매칭이 아니라 의도와 맥락을 함께 해석해야 하는 문제다.
5:42
도구의 순환 고리와 조직의 순환 고리 새 지식이 생기면 더 나은 도구가 필요해지고, 더 나은 도구는 새로운 역할과 업무 분화를 만든다. 도구 발전과 조직 재편은 별개가 아니라 서로를 밀어 올리는 하나의 자기강화 순환 구조다.
7:53
도구는 결코 단순한 부가 기능이 아닙니다 도구는 단순히 편의성을 조금 높이는 부가 요소가 아니라, 어떤 작업이 실제로 가능하고 저렴하게 확장될 수 있는지를 결정한다. 카탈로그, 지도, 멀티모달 검색 같은 도구는 아예 업무의 범위와 비용 구조를 바꾼다.
9:09
리더보드로 본 BM25와 도구 최적화의 위력 브라우즈컴플러스 리더보드에서는 BM25 같은 기본 검색기도 제대로 최적화하면 성능이 크게 달라지고, 하이브리드 검색은 더 높은 정확도를 낸다. 특히 도구 호출 수를 줄이면서 정확도를 올리면 비용과 토큰 사용량이 함께 줄어들어 실사용 가치가 커진다.
11:01
로펌이 복잡한 사건을 분업화해 해결하는 방식 실제 지식 업무에서는 파트너가 문제를 이해하고, 서처나 어시스턴트가 자료를 조사해 메모를 만들고, 그 결과를 바탕으로 최종 판단이 내려진다. 즉, 좋은 시스템은 한 에이전트가 모든 것을 직접 해결하는 구조가 아니라 문제 분해와 재조립을 분업으로 처리한다.
12:29
인간조차 도구의 한계에 부딪힐 때 MQA 같은 PDF 기반 벤치마크에서는 BM25를 아무리 최적화해도 인간과 시스템 모두 일정 지점에서 성능이 막힌다. 이는 사람이 못해서가 아니라 현재 도구가 가진 한계 때문에 생기는 병목이며, 더 나은 도구가 다음 단계의 전제임을 보여준다.
13:18
서처 에이전트와 메모, 그리고 오라클 갭(Oracle Gap) 멀티모달 검색 도구와 서처 에이전트를 결합하면 PDF와 표를 직접 읽고, 쿼리를 분해해 여러 하위 검색을 수행한 뒤 메모 형태로 결과를 모을 수 있다. 이 구조는 인간 정답과 시스템 성능 사이의 오라클 갭을 줄여 주며, 단순한 단일 에이전트보다 훨씬 높은 정확도를 만든다.
15:00
프로그래밍이 아닌 진짜 '지식 작업'을 위한 설계 지식 업무용 에이전트는 코딩용 패턴을 그대로 가져오면 안 되며, 검색 도구·프롬프트·오케스트레이션을 함께 설계해야 한다. 특히 컨텍스트는 유한하므로 큰 문제를 잘게 나누고, 적절한 도구를 선택하게 하며, 검색 구조를 체계적으로 운영하는 것이 핵심이다.

실무 인사이트

지식 업무용 에이전트를 만들 때는 먼저 코딩 과제처럼 보이는 문제를 그대로 풀지 말고, 입력 정보의 모호성과 분해 가능한 하위 질문을 기준으로 작업 흐름을 다시 설계해야 한다.
검색 품질은 모델 성능만이 아니라 도구 선택, 쿼리 분해, 호출 횟수 최적화에 크게 좌우되므로, BM25·semantic search·멀티모달 검색을 역할별로 조합하는 구조가 중요하다.
정답률을 높이려면 단일 에이전트의 추론을 길게 늘리는 것보다, 서처 에이전트와 메모를 분리해 오케스트레이션하는 편이 비용 대비 효과가 좋다.