The Rise of CaaS: Context-as-a-Service for Agentic AI — Omer Primor, Bright Data

한 줄 핵심

웹은 단순한 데이터 소스가 아니라 에이전트가 계속 재사용할 수 있는 컨텍스트의 원천이며, 일회성 검색·대여형 접근보다 반복 사용이 많은 업무에서는 자체 구축한 컨텍스트 자산이 장기적으로 더 유리하다는 주장이다.

시간별 요약

1. 0:12
   Bright Data는 대규모 웹 데이터 추출을 통해 AI 랩과 기업들의 정보 수집을 지원하며, 최근에는 AI와 웹이 빠르게 결합하고 있다는 점을 전제로 논의를 시작한다. 웹은 더 이상 단순한 데이터 저장소가 아니라 지식 작업을 수행하는 에이전트의 컨텍스트 공급원으로 재해석되어야 한다.
2. 2:00
   웹 데이터는 구조화되어 있지 않고 자주 변하므로, 한 번 모아두는 방식으로는 충분하지 않다. 데이터는 빠르게 노후화되며, 검색만으로는 가격 변화나 인사 변동처럼 시간에 따라 누적되는 맥락을 충분히 다루지 못한다.
3. 6:01
   이 문제를 해결하기 위해 CaaS(Context as a Service)라는 범주가 등장했으며, MCP·CLI·API로 에이전트가 접근해 지식 작업에 필요한 컨텍스트를 공급한다. 이들은 단순 검색을 넘어서 knowledge graph, 중복 제거, 다중 소스 병합으로 엔티티를 구조화해 vertical search engine처럼 동작한다.
4. 10:01
   회사 엔터티의 25개 필드를 채우는 테스트에서 검색형 접근과 CaaS는 대체로 비슷한 정확도를 보였지만, 각 방식의 강점과 한계가 분명하게 갈렸다. 검색형은 새로운 정보를 더 넓게 찾는 데 강하고, CaaS는 이미 수집한 범위 안에서는 효율적이지만 범위를 벗어난 최신 정보에는 약하다.
5. 16:02
   같은 데이터를 직접 수집해 벡터DB에 넣고 전용 scrapers로 구조화하면 초기 설정 비용은 들지만, 이후 반복 조회는 토큰 비용 없이 처리할 수 있다. 반복 빈도가 높고 업무가 지속적일수록 대여형 컨텍스트보다 소유한 컨텍스트가 비용과 품질 모두에서 유리해지는 tipping point가 생긴다.
6. 19:02
   결론적으로 AI search와 CaaS는 ad hoc 작업에는 매우 유용하지만, 자주 반복되는 지식 작업에서는 비용 누적과 데이터 감가상각 때문에 한계가 온다. 따라서 web context engineering의 핵심은 작업 빈도와 지속성을 기준으로 검색, CaaS, 자체 구축을 혼합 설계하는 것이다.

실무 인사이트

• 반복 조회가 많은 업무라면 월간·주간 단위로 검색할지, 자체 데이터 파이프라인을 만들지 먼저 빈도 기준으로 손익분기점을 계산해야 한다.
• 에이전트용 컨텍스트는 최신성만이 아니라 엔티티 구조화, 중복 제거, 소스 병합까지 포함해 설계해야 실제 지식 작업 성능이 나온다.
• 일회성 질의는 AI search로 해결하고, 계속 누적되는 핵심 업무는 owned context로 전환하는 이원화 전략이 비용 효율적이다.