AI 에이전트에게 더 많은 기능을 주면 더 똑똑해질 거라고 생각하기 쉽습니다. 하지만 Dropbox의 AI 어시스턴트 Dash 팀은 정반대의 현실을 마주했죠. 도구를 추가할수록 AI의 의사결정은 느려지고, 정확도는 떨어졌습니다. 마치 선택지가 너무 많아 결정을 못 내리는 사람처럼요.

Dropbox 엔지니어링 팀이 Dash를 에이전트 AI로 발전시키면서 발견한 핵심 문제와 해결 전략을 정리한 글입니다. RAG 파이프라인에서 시작한 Dash가 “검색”을 넘어 “행동하는” AI로 진화하면서, 단순히 정보를 많이 주는 것보다 적절한 정보를 적시에 주는 것이 훨씬 중요하다는 걸 깨달았습니다.

출처: How Dash uses context engineering for smarter AI – Dropbox Tech Blog

문제의 발견: 분석 마비

Dash에 새로운 기능(컨텍스트 검색, 문서 편집 등)을 추가하면서 이상한 현상이 나타났습니다. 도구가 늘어날수록 AI가 결정을 내리는 데 더 오래 걸리고, 정확도도 떨어진 거죠. 여기서 “도구”란 AI가 호출할 수 있는 검색, 조회, 요약 같은 외부 기능을 말합니다.

문제는 망가진 도구가 아니었습니다. 너무 많은 좋은 도구들이었어요. Dash는 인간으로 치면 “분석 마비(analysis paralysis)” 상태에 빠진 셈이었습니다. 실제로 작업이 길어질수록 정확도가 떨어지는 Context Rot 현상도 관찰됐죠.

더 큰 문제는 MCP(Model Context Protocol) 같은 표준 프로토콜을 써도 근본적 한계가 있다는 점이었습니다. 각 도구의 설명과 파라미터 정의만으로도 모델의 컨텍스트 윈도우(AI가 한 번에 처리할 수 있는 정보량)를 상당히 소비했고, 이게 비용과 성능 모두에 영향을 미쳤습니다.

세 가지 해결 전략

Dropbox 팀은 “더 많은 컨텍스트”가 아닌 “더 나은 컨텍스트”로 방향을 틀었습니다. 핵심은 AI가 가장 중요한 것에 집중하도록 돕는 거였죠.

1. 도구 정의 수 제한: 여러 API를 하나로 통합

Dash는 Confluence, Google Docs, Jira 등 여러 앱과 연결됩니다. 초기에는 각 앱마다 별도의 검색 도구를 제공했는데, AI는 이 모든 도구를 일일이 호출해야 했고 그마저도 신뢰성이 떨어졌습니다.

해결책은 의외로 단순했습니다. 모든 검색 도구를 하나의 유니버설 검색 인덱스로 통합한 거예요. 수십 개의 API 중에서 선택하게 하는 대신, 모든 서비스를 아우르는 단일 인터페이스를 만들었죠. AI에게 일관된 방식으로 정보를 찾을 수 있게 하니 추론이 명확해지고, 계획이 효율적이며, 컨텍스트 사용이 집중됐습니다.

이 접근법은 Dash MCP 서버 설계에도 반영됐습니다. Claude, Cursor, Goose 같은 MCP 호환 앱에서 단 하나의 도구로 Dash의 검색 기능을 쓸 수 있게 했죠.

2. 관련성 있는 컨텍스트만 필터링: 지식 그래프 활용

여러 API에서 가져온 데이터가 모두 유용한 건 아닙니다. 결과를 랭킹하고 필터링해서 정말 관련 있는 정보만 AI에게 전달해야 했어요.

Dash는 여러 소스의 데이터를 하나의 통합 인덱스로 만들고, 그 위에 지식 그래프를 얹었습니다. 이 그래프는 사람, 활동, 콘텐츠 간의 관계를 매핑해서 각 쿼리와 사용자에게 가장 중요한 결과를 랭킹합니다. AI는 플랫폼이 이미 관련성이 높다고 판단한 콘텐츠만 보게 되니, 모든 컨텍스트가 의미를 갖게 되는 거죠.

핵심은 이겁니다. 검색된 모든 것이 AI의 추론을 형성하기 때문에, 관련성이야말로 AI를 효율적으로 가이드하는 핵심입니다.

3. 복잡한 작업엔 전문 에이전트 투입

어떤 도구는 너무 복잡해서 AI가 제대로 쓰려면 엄청난 컨텍스트와 예시가 필요했습니다. Dash Search 도구가 점점 고도화되면서 이 문제가 불거졌죠. 쿼리 구성만 해도 사용자 의도 파악, 인덱스 필드 매핑, 쿼리 재작성, 오타나 동의어 처리 등 복잡한 작업이었습니다.

도구가 강력해질수록 AI는 그걸 올바르게 쓰는 방법에 대한 설명으로 컨텍스트 윈도우의 상당 부분을 써야 했습니다. “어떻게 검색할까”에 집중하느라 “검색 결과로 뭘 할까”를 생각할 여유가 없었던 거죠.

해결책은 검색을 별도의 전문 에이전트로 분리한 것입니다. 메인 에이전트는 언제 검색이 필요한지만 판단하고, 실제 쿼리 구성은 자체 프롬프트를 가진 검색 전문 에이전트에게 위임했습니다. 이렇게 분리하니 메인 에이전트는 계획과 실행에 집중할 수 있고, 검색 에이전트는 검색의 세부사항만 처리하면 됐죠.

교훈은 명확합니다. 도구를 효과적으로 쓰려면 너무 많은 설명이나 컨텍스트가 필요하다면, 차라리 그걸 전용 프롬프트를 가진 독립적인 에이전트로 만드는 게 낫습니다.

작은 컨텍스트가 더 똑똑한 AI를 만든다

Dropbox 팀의 결론은 단순하지만 강력합니다. 컨텍스트는 비용, 속도, AI의 집중력 모두에 영향을 미칩니다. 더 적은 컨텍스트가 단순히 자원을 아끼는 게 아니라 AI를 더 똑똑하게 만든다는 거죠.

이들은 지금 검색 도구에서 얻은 교훈을 사용자 프로필, 회사 정보, 장단기 메모리 같은 다른 영역에도 적용하고 있습니다. 특히 더 작고 빠른 모델로 실험하면서 이런 영역을 다듬으면 더 큰 성능 향상을 기대할 수 있다고 보고 있어요.

MCP 같은 프로토콜은 견고하지만, 효과적인 확장은 결국 도구 남발을 줄이고, 전문 에이전트에 투자하며, 필요할 땐 LLM이 코드 기반 도구를 생성하게 하는 데 달려 있습니다. AI 에이전트의 미래는 “얼마나 많이 아느냐”가 아니라 “얼마나 집중해서 아느냐”에 달린 것 같습니다.

Like?