AI 에이전트에게 검색은 지금까지 블랙박스였습니다. 쿼리를 던지면 결과가 나오고, 그걸 그냥 받아서 쓰는 구조였죠. 그런데 에이전트가 수천 번의 검색을 한 번의 작업 안에서 수행해야 하는 시대가 되자, 이 계약이 삐걱거리기 시작했습니다.

Perplexity Research가 새로운 검색 아키텍처를 발표했습니다. 이름은 Search as Code(SaC). 에이전트가 검색 결과를 소비하는 것을 넘어, 검색 파이프라인 자체를 Python 코드로 직접 조립하고 실행하는 방식입니다. 5개 벤치마크 중 4개에서 OpenAI·Anthropic 등 경쟁 시스템을 앞섰고, 특히 복잡한 연구 작업에서는 차점 시스템 대비 2.5배 높은 성능을 기록했습니다.

출처: Rethinking Search as Code Generation – Perplexity Research

기존 검색이 에이전트에게 맞지 않는 이유

지금까지 AI 시스템의 검색 방식은 단순했습니다. 모델이 쿼리를 던지면 검색 엔진이 미리 정해진 파이프라인을 돌리고, 모델은 그 결과를 문맥으로 소비합니다. 사람이 검색창에 키워드를 치던 시절과 구조가 크게 다르지 않죠.

이 방식은 단순한 요청에는 잘 작동합니다. 문제는 에이전트가 복잡한 작업을 수행할 때입니다. Perplexity는 자사 Computer 에이전트에서 하나의 작업이 수분 안에 수백 번에서 수천 번의 검색을 호출하는 사례를 확인했습니다. 이런 환경에서 기존 방식의 한계는 세 가지로 압축됩니다.

1. 거친 컨텍스트 — 모델이 정밀한 정보 한 조각이 필요해도, 엔드-투-엔드 파이프라인은 관련 없는 정보를 대거 끼워 넣습니다. 반대로 다양한 전략이 필요한 작업에선 같은 파이프라인을 반복 호출해야 해 비용과 노이즈가 급증합니다.
2. 도메인 지식 활용 불가 — 모델이 학습이나 이전 추론 과정에서 얻은 지식(예: “이 주제는 특정 소스를 우선해야 한다”)을 검색 전략에 반영할 방법이 없습니다.
3. 비효율적 제어 흐름 — 병렬 검색, 결과 중복 제거, 조건부 실행 같은 작업이 자연스럽게 필요한데, 기존 방식은 이를 모델 턴을 반복하며 순차적으로 처리해야 합니다. 지연이 쌓이고 컨텍스트가 노이즈로 오염됩니다.

검색을 코드로 짠다는 것의 의미

SaC의 핵심 아이디어는 간단합니다. 검색 엔진을 통째로 호출하는 대신, 검색 스택의 구성 요소들을 SDK 형태로 쪼개서 모델에게 직접 노출합니다. 모델은 각 작업에 맞는 파이프라인을 Python 코드로 그때그때 조립해 실행합니다.

SaC는 세 레이어로 구성됩니다.

1. 모델(제어 플레인) — 작업을 분석하고 어떤 검색 전략이 필요한지 판단한 뒤, 그 전략을 코드로 생성합니다.
2. 컴퓨트 샌드박스 — 생성된 코드를 안전하게 실행합니다. 병렬 처리, 배치, 필터링, 집계 같은 결정론적 연산을 담당합니다.
3. Agentic Search SDK — Perplexity 검색 스택을 원자 단위로 쪼갠 도구 모음입니다. 저수준 검색부터 의미 파싱까지, 단일 추론 턴 안에서 수천 개 작업을 오케스트레이션할 수 있습니다.

이 구조에서 모델은 더 이상 검색 결과의 수동적 소비자가 아닙니다. 검색 과정 자체에 능동적으로 개입하는 오케스트레이터가 됩니다. SDK에 없는 기능도 코드로 직접 구현할 수 있어, SDK를 불필요하게 비대하게 만들지 않고도 맞춤형 검색 로직을 실행할 수 있습니다.

실제로 어떻게 작동하나

Perplexity가 공개한 사례는 200건 이상의 고위험도 CVE(보안 취약점)를 특정 벤더 어드바이저리에서 찾아 정리하는 작업입니다. 각 항목마다 영향받는 제품, 수정 버전, 해당 CVE와의 연결 관계를 벤더가 직접 작성한 텍스트에서 확인해야 했습니다.

SaC 에이전트는 먼저 쿼리 전략을 코드로 설계했습니다. 벤더별 어드바이저리 URL 패턴을 직접 코드에 인코딩하고, NVD나 MITRE 같은 집계 사이트는 처음부터 배제했습니다. 그런 다음 중간 결과를 분석해 커버리지가 부족한 벤더-연도 조합을 확인하고, LLM을 서브루틴으로 활용해 추가 쿼리를 생성했습니다. 마지막 단계에서는 CVE와 수정 버전의 연결 관계를 검증하는 로직도 코드로 직접 정의했습니다.

결과는 정확도 100%였고, 토큰 사용량은 기존 방식 대비 85.1% 감소했습니다(288.7K → 42.9K 토큰). 다른 시스템들은 모두 25% 미만의 정확도를 기록했습니다.

검색 아키텍처가 바뀐다는 것

SaC가 흥미로운 이유는 단순히 Perplexity의 제품 성능 개선에 그치지 않아서입니다. 이 접근은 AI 시스템이 외부 정보를 다루는 방식에 대한 더 근본적인 질문을 던집니다.

지금까지 검색은 모델 위에 있었습니다. 모델이 검색을 호출하고, 검색이 결과를 돌려주면 끝이었죠. SaC는 모델이 검색 스택 안으로 내려가 직접 파이프라인을 구성합니다. 추론과 결정론적 연산, 그리고 정보 접근이 하나의 실행 흐름 안에서 긴밀하게 맞물리는 구조입니다.

Perplexity는 이를 “두 가지 연산 형태의 결합”으로 설명합니다. 토큰 공간의 추론(모델이 잘하는 것)과 결정론적 연산(샌드박스가 잘하는 것)이 각자의 강점을 극대화하도록 설계된 시스템이죠. 에이전트 검색의 다음 세대는 이 방향을 향하고 있을 가능성이 높습니다.

벤치마크 상세 결과와 아키텍처 설계 결정에 대한 더 깊은 분석은 원문에서 확인할 수 있습니다.

참고자료:

• Agent API: A Managed Runtime for Agentic Workflows – SaC가 현재 탑재된 Agent API 발표 글
• Architecting and Evaluating an AI-First Search API – SaC의 전신에 해당하는 Perplexity 검색 아키텍처 논문 (2025년 9월)