LLM 에이전트(LLM agents)가 개발자 문서를 작성하고 유지 관리하는 비중이 점점 늘어나고 있지만, 그 유용성과 정확성은 종종 추적하기 쉽지 않은 의존성 체인(dependency chains)에 달려 있습니다. 컨텍스트(context) 내에 더 많은 파일이 있더라도, 에이전트는 여전히 어떤 파일 간 의존성을 추적할지 결정해야 합니다. 우리는 LLM 에이전트가 문서를 검토하거나 생성할 때 코드베이스 전반에서 증거를 찾기 위해 쿼리할 수 있는 검색 레이어인 Context-as-a-Service (CaaS)를 제안합니다. CaaS는 소스 코드, API 참조(API references), 상위 문서(upstream documentation)를 인덱싱하며, 키워드 검색과 의미론적 검색(semantic search)을 결합한 도구 호출(tool calls)을 통해 에이전트가 인덱스를 쿼리할 수 있도록 합니다. 우리는 실제 운영 중인 SDK에서 Claude Sonnet 4.6을 사용하여 두 가지 사례 연구를 통해 CaaS를 평가했습니다: 핵심 소스 파일의 API 참조 주석 개선 및 LLM이 생성한 튜토리얼 검증입니다. 두 연구 모두에서 베이스라인(baseline)은 이미 파일 읽기, 키워드 검색, 심볼 탐색(symbol navigation)과 같은 일반적인 저장소 도구들을 갖추고 있었습니다. CaaS는 그 위에 검색 레이어를 추가하므로, 비교 시 기본적인 저장소 접근이 아닌 추가된 검색 기능의 효과를 분리하여 확인할 수 있습니다. API 참조 검토에서 CaaS가 강화된 에이전트는 베이스라인과 동일한 5개의 누락된 문서 수정 사항을 생성했을 뿐만 아니라, 베이스라인이 놓친 4가지 결과(2개의 파일 간 사실 오류 및 2개의 불충분한 API 주석)를 찾아냈습니다. 튜토리얼 검증에서는 베이스라인 파이프라인이 잡아내지 못한 1개의 실행 가능한 버그, 1개의 API 사용 개선 사항, 2개의 누락된 전제 조건(prerequisites)을 찾아냈습니다. 이러한 결과들은 유틸리티 파일, 프레임워크 내부 구조, 사용 예시, 테스트, 그리고 컴포넌트 생성 로직에 걸쳐 명확하지 않은 의존성 체인을 추적해야만 가능했습니다. 조건당 5회 실행 결과, CaaS를 추가함으로써 두 작업 모두에서 실제 소요 시간(wall-clock time)을 22%에서 34%까지 단축했으며 입력 토큰(input-token) 사용량도 줄였습니다.