Dropbox Tech

Dropbox가 Dash Chat 에이전트의 응답 품질을 높이기 위해 DSPy 최적화 프레임워크를 도입한 과정을 다룬다. 인간 레이블로 LLM 평가자(judge)를 보정하고, 보정된 judge로 에이전트의 시스템 프롬프트를 자동 최적화하는 두 단계 전략으로 불완전 답변 26% 감소와 토큰 사용 5.4% 절감을 달성했다.

Dropbox 보안팀이 설계 단계 위협 모델과 실제 코드 리뷰 사이의 단절을 해결하기 위해 MCP(Model Context Protocol), LLM, Dash를 결합한 자동화 시스템을 구축했다. 구현 PR의 12%만이 원래 보안 설계 문서를 명시적으로 참조하고, 54%는 설계 리뷰 후 한 달 이상 뒤에 열린다는 분석에서 출발했다.

코드 생성이 빨라질수록 코드 리뷰·CI/CD·배포 조정 등 하류 병목이 그대로 이동해 전체 개발 속도는 제한된다.

Dropbox 개발자들이 CI 실패 대응, 테스트 수정, 의존성 업그레이드 같은 반복 작업으로 의미 있는 일에 집중하지 못한다. 기존 도구는 대규모 모노레포와 Bazel 인프라에 맞지 않는다.

Magic Pocket의 Live Coder 경로가 과소 채워진 볼륨을 대량 생성해 immutable blob store의 저장 오버헤드가 커졌다.

Dropbox 서버 monorepo가 87GB까지 커져 clone이 1시간 이상 걸리고 GitHub의 100GB 제한에 가까워졌다.

Dropbox Dash의 relevance judge는 모델 변경과 수동 prompt tuning 때마다 품질, 비용, JSON 출력 안정성이 흔들렸다.

Dropbox Dash의 RAG 답변 품질은 enterprise search ranking에 의존하지만, 충분한 relevance label을 사람이 모두 만들기 어렵다.

대형 AI 모델 추론은 메모리 대역폭, 비용, 에너지 제약 때문에 고정밀 형식만으로는 효율을 내기 어렵다.

Dropbox Dash는 여러 SaaS와 사내 문서에 흩어진 업무 지식을 LLM이 검색하고 추론할 수 있는 컨텍스트 엔진이 필요했다.

Dropbox Dash의 검색과 에이전트는 한 질의에서 수천 건의 feature lookup을 수행하면서도 100ms 미만 지연과 최신 사용자 신호를 요구했다.

Dash 가 검색에서 에이전트형 AI 로 확장되면서 툴이 늘수록 의사결정이 느려지고 컨텍스트가 비대해진다. 분석 마비와 토큰 비용이 함께 커진다.