If we want them to do Knowledge Work, design them as Knowledge Agents — Benjamin Clavié, Mixedbread

한 줄 핵심

코딩 에이전트에 맞춘 설계만으로는 부족하며, 지식 업무의 핵심인 검색·분해·조직화에 맞춰 에이전트를 설계해야 더 정확하고 확장 가능한 결과를 얻을 수 있다.

시간별 요약

1. 0:00
   코딩 에이전트는 지식 업무의 특수한 경우다 에이전트는 본질적으로 지식을 찾고 활용하는 지식 노동을 수행해야 하며, 코딩은 그중 일부에 불과하다. 법률, 금융, 의료처럼 입력이 정보이고 출력이 판단·결정인 업무 전반이 더 넓은 지식 에이전트의 범주에 들어간다.
2. 3:48
   코드는 왜 유난히 검색하기 쉬운가 코드는 식별자, 파일 경로, 함수 정의처럼 지속적인 단서가 많고 표면적으로도 잘 구조화되어 있어 검색이 상대적으로 쉽다. 또한 코딩 에이전트에 주어지는 과제는 대체로 범위가 좁고 암묵적으로 잘 정의되어 있어 일반 지식 업무보다 다루기 편하다.
3. 5:05
   30일과 한 단서가 네 가지 의미를 가질 때 비코드 지식 업무는 같은 표현도 마감일, 유예 기간, 보존 규칙처럼 여러 의미를 가질 수 있어 맥락 의존성이 크다. 검색은 명시된 정답을 찾는 작업이 아니라, 애초에 의도를 해석하고 조건을 판별하는 과정까지 포함하므로 훨씬 어렵다.
4. 5:55
   도구 루프와 조직 루프 지식이 늘수록 더 나은 도구가 필요해지고, 더 나은 도구는 새로운 역할과 워크플로를 만든다. 도구의 발전과 조직의 재편은 따로가 아니라 서로를 밀어 올리는 하나의 자기강화 루프로 작동한다.
5. 8:06
   도구는 결코 중립적인 부가물이 아니다 도구의 유무는 업무의 가능 여부보다도, 그 일을 싸고 빠르게 확장 가능하게 만드는지를 결정한다. 도서관 목록, 지도, 대규모 문서 검색처럼 도구가 생기면 이전에는 비현실적이던 작업이 실무로 바뀐다.
6. 9:22
   리더보드와 두 가지 BM25 검색 도구는 최적화 여부에 따라 성능과 비용이 크게 달라지며, 최적화되지 않은 도구는 실제 업무에서 사실상 쓸 수 없다. BM25도 하나의 고정된 기준이 아니라 수많은 구현과 최적화가 존재하며, 성능 향상은 정확도뿐 아니라 tool call 수와 비용 절감에서 더 중요하게 드러난다.
7. 11:14
   법무법인이 사건을 쪼개는 방식 실제 지식 업무에서는 파트너가 문제를 이해하고, 실무자와 보조 인력이 검색과 정리를 분담해 memo를 만든 뒤 다시 상위 판단으로 돌아간다. 코딩 에이전트처럼 사용자가 이미 과제를 잘게 쪼개 주는 상황과 달리, 현실의 지식 업무는 에이전트 스스로도 문제를 분해하고 하위 작업을 배치해야 한다.
8. 12:42
   인간조차 도구 한계에 부딪힌다 BM25를 아무리 최적화해도 인간과 Gemini 3 모두 같은 한계에 닿는 구간이 나타나며, 이는 검색 품질이 도구 수준에서 막히는 지점이 있음을 보여준다. PDF와 OCR, 멀티모달 검색 같은 더 나은 도구를 도입하면 정확도는 올라가지만, 여전히 에이전트 성능은 인간에 미치지 못한다.
9. 13:31
   검색자 에이전트, memo, 그리고 오라클 간극 메인 에이전트가 직접 다 찾으려 하지 말고, 쟁점을 분해해 여러 searcher agents가 각각 검색한 뒤 memo를 합치게 하면 정확도가 더 올라간다. 이런 구조는 완벽한 문서 집합과 실제 검색 시스템의 차이인 oracle gap을 줄이며, 인간 대비 오류를 의미 있게 낮춘다.
10. 15:13
    프로그래밍이 아니라 지식 업무를 위해 설계하라 에이전트 설계의 기준은 코딩의 특수성이 아니라 법률, 의료, 행정처럼 이미 수십 년간 축적된 지식 업무의 조직 방식이어야 한다. 도구는 성능 한계를 넘기 위한 수단이며, 에이전트와 함께 공동 설계되어야 하며, 큰 컨텍스트만으로 해결하려 하지 말고 작업 분해와 오케스트레이션을 기본값으로 삼아야 한다.

실무 인사이트

• 에이전트의 기본 단위를 '한 번에 답하기'가 아니라 '문제를 분해하고 검색을 위임한 뒤 memo로 합치기'로 바꾸면 실무 적합도가 크게 올라간다.
• 검색 도구 평가는 정확도만 보지 말고 tool call 수, 토큰 비용, 사람이 실제로 채택할 수 있는 워크플로까지 함께 봐야 한다.
• 큰 컨텍스트를 전제로 설계하기보다, 검색·분해·요약·재조합을 전제로 한 지식 업무용 하네스를 먼저 설계하는 것이 더 현실적이다.