Perplexity Just Made AI Search 68% Cheaper

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Perplexity는 Photon 기반 Fast Search로 공개 벤치마크의 작업 품질을 유지하면서 모델·검색 합산 작업 비용을 68% 줄였다고 소개하지만, 희귀하고 복잡한 질문에서는 검색 품질의 손실이 있다.

📌 핵심 요점

1. 68%는 작업 단위의 합산 비용 절감 수치다. 영상은 AI 모델과 검색을 합친 비용을 설명하며, 모든 사용자 요금이나 검색 API 단가가 일괄적으로 68% 인하됐다는 근거는 제시하지 않는다.
2. 공개 평가에서는 Fast와 기본 옵션의 점수가 비슷했다. 6개 공개 벤치마크의 3,554개 작업에서 Fast는 64.3%, 기본 옵션은 64.0%를 기록했다. Fast 검색의 절반은 160ms 이내, 95%는 230ms 이내에 완료됐다는 자체 측정치도 소개한다.
3. Photon은 답변 생성 이전의 검색·순위화를 담당한다. 자체 개발 검색 엔진으로, 압축 저장과 필요한 부분만 읽기, 읽기 작업 묶음 처리, 인덱스 구축과 검색 처리 분리를 통해 부담을 줄인다.
4. 최종 답변 점수와 검색 결과의 품질은 구분해야 한다. 내부 평가에서 Fast는 관련성 0.24포인트, 정답이 검색 결과에 포함되는 비율에서 약 3%포인트 뒤처졌다. 영상은 모델의 지식과 추론이 검색의 차이를 일부 보완할 수 있다고 설명한다.
5. 일상적인 에이전트 작업부터 비교 도입하는 것이 권고된다. 반복 작업에는 Fast를 시험하고, 복잡하거나 희귀한 질문에는 기본 검색을 유지한다. SDK 호환성, 반환 문맥량, 쿼리별 요청 한도도 함께 확인해야 한다.

🧩 배경과 문제 정의

영상은 더 무겁고 느린 검색이 반드시 더 좋은 에이전트 결과를 만드는지 질문한다. Perplexity는 기존에 수정해 사용하던 오픈소스 검색 엔진이 인덱스 확대에 따라 무거워졌고, 느린 검색과 일주일 넘게 걸리는 신규 클러스터 데이터 동기화가 문제가 됐다고 설명한다.

이에 소규모 엔지니어링 팀이 코딩 에이전트의 도움을 받아 Photon을 개발했다. Photon은 AI가 답변을 작성하기 전에 웹페이지를 찾고 순위를 매기는 검색 엔진이며, Fast Search는 이를 활용한 API 옵션이다. 핵심 판단 과제는 비용·속도 개선을 얻으면서도 자신의 작업에 필요한 검색 품질을 유지할 수 있는지 확인하는 것이다. 영상에는 AI Profit Boardroom 교육 서비스 홍보도 포함된다.

🕒 시간순 섹션별 상세정리

1. 비용 절감 주장과 Photon의 역할

• 발표자는 자신을 Julian Goldie의 디지털 아바타로 소개하고, 더 빠른 검색으로 비슷한 작업 품질과 68% 절감을 얻었다는 주장을 제시한다. Photon은 답변을 생성하기 전에 웹페이지를 검색하고 순위화하며, Search API를 통해 앱과 AI 에이전트에 연결된다. [01:01]
• Fast 검색의 절반은 160ms 이내, 95%는 230ms 이내에 완료된다고 보여준다. 6개 공개 벤치마크·3,554개 작업에서 Fast 64.3%, 기본 옵션 64.0%를 기록했고, 68%는 모델과 검색을 합친 작업 비용의 절감 수치로 묶인다. [01:37]

2. 기존 병목과 검색 엔진 재설계

• 기존 엔진은 인덱스가 커지면서 실행 부담과 느린 검색 문제가 커졌고, 새 클러스터의 데이터 동기화에는 일주일 이상 걸렸다. 소규모 팀은 코딩 에이전트와 함께 엔진을 다시 만들었다. [02:09]
• Photon은 데이터를 압축해 필요한 부분만 읽고 풀어낸다. 읽기는 묶어서 처리하고 메모리에 없는 부분만 디스크에서 가져오며, 인덱스 구축과 검색 처리를 분리해 자원 경쟁을 줄인다. [02:48]
• 새 인덱스는 머신 그룹에 순차적으로 적용하며, 실제 검색 쿼리를 미리 실행해 가동 직후의 지연을 줄인다고 보여준다. 이후 AI Profit Boardroom의 튜토리얼·코칭·Agent OS 배포와 로드맵을 홍보한다. [03:37]

3. 저장 구조의 효율과 Fast의 품질 한계

• 단어별 페이지 목록은 크기에 맞춰 저장하고 자주 찾는 데이터는 디스크에서 가깝게 배치한다. 페이지별 doc blob에는 단어 빈도와 위치 등을 담아 한 번의 조회로 필요한 단어만 풀어내며, 같은 데이터를 모두 메모리에 올리면 현재보다 약 4.6배의 메모리가 필요하다고 주장한다. [04:34]
• 내부 시스템의 느린 1% 검색은 약 800ms에서 65ms로 줄었고, 약 20% 적은 머신으로 페이지당 약 2.5배 많은 데이터를 저장한다고 보여준다. 최신 정보가 필요한 새 페이지는 수분 내 반영되고 전체 웹 인덱스는 수시간 내 구축할 수 있다고 보여준다. [05:02]
• Fast는 순위화 연산을 줄이는 대신 내부 평가에서 관련성 0.24포인트, 정답 포함 비율 약 3%포인트가 낮았다. 일상 작업에는 Fast, 복잡하고 희귀한 질문에는 기본 옵션을 권하며, 경쟁 API와의 속도 비교는 동등 조건 실험이 아니라고 드러낸다. [06:05]

4. API 적용 방법과 이용 경로

• 영상에 따르면 2025년 9월 출시한 Search API는 페이지를 구간으로 나눠 질문에 맞는 내용을 순위화해 제공한다. 국가 코드와 요청당 최대 10개 언어로 결과를 제한할 수 있고, Fast는 이 API 위에 추가된 옵션이다. [06:39]
• 검색 유형을 Fast로 설정하면 되며 생략하면 기본 검색을 사용한다. 응답 형식은 같고 검색당 1~20개 결과를 요청할 수 있다. Agent API의 Fast 검색 유형은 같은 API의 Fast 프리셋과 별개라고 강조한다. [07:10]
• API 키 없이 시험하는 플레이그라운드, JSON 결과를 반환하는 CLI, 코딩 에이전트용 검색 스킬을 보여준다. 일반 Perplexity 사용자도 Photon 기반 검색 파이프라인의 속도 개선을 이미 일부 누린다고 보여준다. [07:42]

5. 실무 설정과 단계적 도입 권고

• 영상은 Python 라이브러리 0.43.4·0.33.5에서 Fast 설정을 extra_body에 넣는 방식과 TypeScript 타입에 Fast가 없을 때의 as any 예시를 언급한다. 반복 에이전트 작업에는 Fast를 시험하되 어려운 질문에는 기본 검색을 남겨두라고 권한다. [08:19]
• 반환 문맥량은 low·medium·high로 조절하고, 최대 5개 다중 쿼리는 쿼리별로 요청 한도를 소비한다. 도메인은 최대 20개를 포함하거나 제외할 수 있으나 두 방식을 한 요청에서 섞을 수 없으며, 콘솔에서 Fast 사용량을 별도로 확인할 수 있다고 보여준다. [09:03]
• 일상 작업 하나에서 동일 쿼리로 두 옵션을 비교한 뒤 점진적으로 확대하라고 권한다. 마지막에는 희귀·복잡한 검색의 품질 손실 가능성을 다시 짚고 작업별 선택을 강조한 다음, 코칭·튜토리얼·Agent OS와 30일 로드맵을 제공한다는 교육 서비스 홍보로 끝난다. [10:08]

🧾 결론

• Photon의 핵심 변화는 AI가 읽을 웹페이지를 찾고 정렬하는 기반 시스템의 효율 개선이다.
• 공개 벤치마크에서 비슷한 점수가 나왔다는 사실만으로 모든 질문에서 두 옵션의 검색 품질이 같다고 볼 수는 없다.
• 전면 전환보다 실제 작업 하나에서 Fast와 기본 검색의 품질·지연·합산 비용을 나란히 비교하는 접근이 영상의 권고와 맞는다.

📈 투자·시사 포인트

• 에이전트 운영비: 검색이 반복되는 작업에서는 개별 검색의 지연과 비용 감소가 전체 작업 효율에 영향을 줄 수 있다. 실제 절감 폭은 자신의 작업에서 확인해야 한다.
• 검색 인프라 경쟁력: 영상이 제시한 머신 수 약 20% 감소와 페이지당 저장 데이터 약 2.5배 증가는 검색 기반 기술이 운영 효율과 순위화 개선을 함께 겨냥한다는 점을 보여준다.
• 제품 설계: 속도가 중요한 일상 작업과 검색 범위·정확성이 중요한 어려운 작업을 구분해 옵션을 선택필요가 있다.
• 투자 판단의 범위: 영상에는 매출, 이익률, 고객 전환율이나 기업가치 자료가 없다. 기술 효율 수치를 곧바로 수익성 개선이나 투자 수익으로 환산할 근거는 부족하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 68% 절감의 세부 비용 항목, 사용 모델, 작업별 분포와 재현 조건은 제공된 자막만으로 확인할 수 없다. 이를 API 가격표의 일괄 인하로 해석하면 안 된다.
• 64.3%와 64.0%의 차이에 대한 통계적 유의성이나 벤치마크별 결과는 제시되지 않는다. 내부 관련성 평가의 0.24포인트가 어떤 척도인지도 설명되지 않는다.
• 경쟁 검색 API와의 속도 비교는 회사별 측정 방식을 모은 것으로, 영상도 통제된 동등 조건 비교가 아니라고 명시한다. Fast API의 160·230ms와 내부 시스템의 느린 1% 검색에 관한 65ms도 같은 측정 지표로 섞어 읽지 않아야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 정기적으로 실행하는 에이전트 작업 하나를 골라 동일한 질문으로 Fast와 기본 검색을 비교한다.
• 최종 답변의 정확성뿐 아니라 정답 근거 포함 여부, 결과 다양성, 전체 작업 시간, 모델·검색 합산 비용을 기록한다.
• 복잡하거나 희귀한 질문은 기본 검색으로 처리할 기준을 정하고, Fast의 실패 사례를 모은다.
• 사용 중인 SDK에서 Fast 검색 설정을 지원하는지 확인한다. 영상에 언급된 Python의 extra_body와 TypeScript의 as any 우회 예시는 현재 문서와 대조한다.

❓ 열린 질문

• 한국어 질문이나 특정 전문 분야에서도 공개 벤치마크와 비슷한 품질·비용 결과가 나오는가?
• 어떤 질문 특성을 기준으로 Fast와 기본 검색을 선택해야 검색 누락을 줄이면서 속도 이점을 얻을 수 있는가?
• 검색 결과의 부족함을 모델이 보완한다는 설명은 모델의 종류와 추론 능력이 달라져도 유지되는가?