답변에 포함된 유용한 링크 하나는 데모 단계에서는 저렴하지만, 일상적인 흐름 속에서는 예상치 못한 비용을 발생시킬 수 있습니다. "기능에 검색 추가"를 클릭하고 20개의 테스트 요청을 실행한 뒤, 콘솔에서 몇 센트의 비용을 확인하면 "저렴하다"고 판단하고 체크 표시를 하게 됩니다. 하지만 한 달 뒤, 실제 부하가 걸린 동일한 기능은 유닛 경제성 (Unit Economics)에 아무도 반영하지 않았던 청구서를 생성하게 됩니다. 그 이유는 벤더의 탐욕 때문이 아니라, 검색 응답 (Search Response)이 일반적인 언어 모델 (LLM) 호출과는 다르며, 과금 방식 또한 다르기 때문입니다.

이 글은 채팅 모델 간의 비교나 "누가 더 똑똑한가"에 대한 리뷰가 아닙니다. 이것은 운영 예산안입니다. 검색 제품 관리자(Product Manager)가 통합 전에 예상되는 검색 활동을 예산이 감당할 수 있는지, 그리고 어떤 임계값을 설정해야 기능을 아예 활성화하지 말아야 할지를 계산하는 방법입니다. 아래의 모든 수치는 2026년 7월 18일 기준 docs.perplexity.ai의 실제 페이지에서 가져왔습니다. 이는 고정된 계약이 아닌 특정 시점의 스냅샷입니다. Perplexity는 이미 이 인터페이스를 한 차례 재편성한 적이 있으므로, 정확한 수치로 계산기를 돌리기 전에 콘솔을 통해 다시 한번 확인하십시오.

혼란을 방지하기 위해 경계를 명확히 말씀드리겠습니다. 제품의 비검색 부분, 즉 일반적인 모델 응답은 별도의 경로를 통해 결제됩니다. 러시아에서는 루블 잔액을 사용하는 provod.ai (OpenRouter의 러시아 대안)를 통해 이용할 수 있습니다. 이는 Perplexity의 검색 계약을 대체하는 것이 아니며, 아래의 모든 예산안은 Perplexity에 관한 것입니다.

검색 응답이 일반적인 LLM 호출과 다른 점은 무엇인가?

예산을 망가뜨리는 논쟁적인 가정은 다음과 같습니다: 검색 응답을 일반적인 모델 요청으로 간주할 수 있다는 점입니다. 인터페이스상으로는 동일한 chat-completions, 동일한 입력 및 출력 토큰(Tokens)처럼 보입니다. 하지만 Perplexity의 요금제에서 검색 모델인 Sonar에는 순수 생성 호출에는 없는 두 번째 항목이 존재합니다.

첫 번째 항목은 다른 곳과 마찬가지로 토큰 (tokens)입니다. Perplexity의 가격 정책(docs.perplexity.ai, 2026.07.18)에 따르면: Sonar는 입력 1M당 $1, 출력 1M당 $1이며, Sonar Pro는 $3/$15, Sonar Reasoning Pro는 $2/$8입니다. 두 번째 항목은 search_context_size 파라미터 값(low, medium, high)에 따라 달라지는 1,000회 요청당 별도 비용입니다. Sonar의 경우 1,000회 요청당 $5/$8/$12이며, Sonar Pro 및 Sonar Reasoning Pro는 1,000회 요청당 $6/$10/$14입니다. 이 비용은 토큰 비용과는 별개로 존재하며 매 호출마다 부과됩니다.

여기에 기본 설정(default)의 함정이 숨어 있습니다. Perplexity의 문서에 따르면, 호출하는 코드에서 값을 명시적으로 설정하지 않으면 search_context_size는 기본적으로 "low"로 설정됩니다. 답변의 품질을 위해 컨텍스트를 medium 또는 high로 높이는 순간, 토큰 가격은 변하지 않으면서 이후의 모든 요청에 대한 비용이 증가하게 됩니다. "답변을 더 똑똑하게 만들자"라는 결정이 향후 모든 호출 빈도에 대해 고정 비용을 배가시키는 셈입니다.

실질적인 결론은 간단합니다. 모든 perplexity sonar api 호출은 단일 토큰 계산 방식이 아니라 "토큰 플러스 요청당 비용"으로 계산해야 합니다. 20번의 요청을 수행하는 데모에서는 1,000회당 비용이 거의 눈에 띄지 않습니다. 하지만 하루에 수만 건의 요청이 발생하는 대규모 트래픽 상황에서는 이것이 예산의 주요 항목이 되며, 바로 이 비용이 검색 기능을 정기적인 운영 비용(OPEX) 항목으로 탈바꿈시킵니다.

부하 상황에서의 수치를 살펴보기 전에, 이를 시각적인 비교표로 정리해 보겠습니다.

계산기: 요청 유형, 빈도, 비용, 한도

이후부터는 Perplexity의 실제 데이터가 아닌 저의 모델링이 시작됩니다. 벤더(Vendor)는 요금제를 공개하지만, 여러분의 기능이 하루에 얼마나 많은 요청을 생성할지는 여러분의 가설일 뿐입니다. 계산기가 필요한 이유는 바로 이 가설의 생존 가능성을 검증하기 위해서입니다. 네 가지 입력값은 다음과 같습니다: 요청 유형 (어떤 모델과 어떤 search_context_size를 사용하는지), 빈도 (일일 요청 수), 비용 (토큰 비용 + 수수료), 한도 (여러분이 감내할 수 있는 상한선).

시나리오를 하나 가정해 보겠습니다. 모델은 Sonar Pro, 컨텍스트는 medium, 수수료는 1,000회 요청당 $10입니다. 빈도는 제가 임의로 설정하겠습니다. 하루 10,000회의 검색 응답이라고 가정해 보죠. 이는 관찰된 수치가 아닌 모델링된 수치입니다. 이 경우 요청 수수료만으로도 10,000 × $10 / 1,000 = 하루 $100가 발생합니다. 여기에 토큰 비용을 더해 보겠습니다. 응답당 입력 500 토큰, 출력 800 토큰이라고 가정합니다. 입력은 5M 토큰 × $3 = $15, 출력은 8M × $15 = $120입니다. 총합은 하루 약 $235이며, 이 중 거의 절반은 일반적인 채팅 호출에는 존재하지 않는 바로 그 요청 수수료입니다.

이제 동일한 볼륨을 'low' 컨텍스트로 설정해 보겠습니다. 수수료가 1,000회당 $6라면 하루 $60가 되어, 기존 $100 대신 $60가 됩니다. 매개변수 값 하나만 바뀌었을 뿐인데 이 시나리오에서는 하루에 $40의 차이가 발생하며, 이는 한 달이면 천 달러가 넘는 금액입니다. 이것이 바로 관리 가능한 레버리지(Leverage)입니다. 컨텍스트의 품질은 빈도에 따라 선형적으로 비용이 발생하므로, 기본값(Default)으로 두지 말고 의식적으로 할당해야 합니다.

중요한 방법론적 주의 사항이 있습니다. Perplexity는 한도 관련 문서에 분당 요청 수(RPM) 상한선만 공개하고 있습니다. Sonar 모델에 대해 분당 토큰 제한이나 일일 토큰 제한은 문서에 명시되어 있지 않습니다. 즉, 부하 모델은 토큰 양이 아닌 요청 양을 기준으로 구축됩니다. 이는 계산기 입장에서 편리합니다. 요청 빈도가 주요 변수가 되며, 바로 이 빈도는 실제로 측정한 범위를 벗어나서 외삽(Extrapolate)해서는 안 되는 값이기 때문입니다.

자동화(Automation)는 별도로 계산해야 합니다. 검색은 실제 사용자(Live user)가 직접 수행하는 경우가 드뭅니다. 대부분은 n8n과 Perplexity를 워크플로우에 통합하거나, 고객 문의용 WhatsApp Perplexity 봇을 운영하거나, Perplexity Web API MCP를 통해 도구를 연결하는 방식입니다. 이 세 가지 경우 모두 빈도는 사람이 아닌 시나리오에 의해 결정됩니다. 하나의 질문이 3~4단계의 검색 단계(Search steps)로 전개될 수 있으며, 각 단계는 고유한 비용이 발생하는 별도의 유료 요청(Paid request)입니다. 따라서 대화(Dialogues)가 아닌 호출(Calls) 횟수를 기준으로 계산해야 합니다. 그렇지 않으면 체인(Chain) 내의 단계 수만큼 예산이 과소 책정됩니다.

코드 수준에서 예산을 세우기 전에, 하나의 컨텍스트(Context) 값이 일일 비용을 어떻게 변화시키는지 살펴볼 필요가 있습니다.

코드 수준의 예산: 명시적 컨텍스트와 키(Keys)

머릿속으로 계산하는 것은 무의미합니다. 예산은 호출 시 설정하는 파라미터(Parameters)에 의해 결정됩니다. 코드 수준에서 Perplexity API는 OpenAI와 호환되는 chat-completions 방식이며, 선택하지 않은 기본값(Default)에 대해 비용을 지불하지 않도록 모델과 search_context_size를 명시적으로 설정해야 합니다. 아래는 명시적 컨텍스트를 사용한 호출의 최소한의 초안입니다. API 키(Perplexity API key)는 코드 내에 두지 않고 환경 변수(Environment variable)에 보관합니다.

import os
from openai import OpenAI

...

호출 형식을 주의 깊게 보십시오. 이는 base_url만 변경된 동일한 OpenAI 클라이언트입니다. 따라서 제품의 비검색 부분(Claude, GPT, Gemini, DeepSeek 또는 Qwen의 일반적인 응답)은 단 두 줄의 수정만으로 다른 결제 경로로 전환할 수 있습니다. provod.ai는 OpenAI 및 Anthropic SDK와 호환되며, 추가 수수료 없이 제공업체의 공식 가격으로 루블(Rubles) 결제를 지원합니다.

from openai import OpenAI

client = OpenAI(
...

따라서 이 두 가지 항목은 서로 다른 회로로 분리됩니다. 검색 부분인 perplexity ai api는 Perplexity와의 계약 및 요청당 비용에 따르며, 생성 부분은 러시아에서 결제하기 더 편리한 곳을 이용합니다. 이 둘은 과금 단위가 다르기 때문에 하나의 견적서에 섞어서 계산할 수 없습니다.

데모에서 숨기고 있는 제한 사항과 요금은 무엇인가?

빈도는 예산뿐만 아니라 상한선(ceiling)에도 부딪힙니다. Sonar의 RPM(Requests Per Minute) 제한은 전체 기간 동안 구매한 크레딧(credits)의 총액에 따라 결정됩니다. $0부터 시작하는 Tier 0부터 $5,000 이상인 Tier 5까지 총 6개의 티어(tier)가 존재합니다. sonar-pro의 경우 상한선은 티어 계단에 따라 50 → 150 → 500 → 1000 → 4000 → 4000 RPM으로 증가하며, sonar-deep-research는 이보다 눈에 띄게 낮은 5–100 RPM으로 제한됩니다 (docs.perplexity.ai, 2026.07.18). 즉, 검색이 더 집중적일수록 더 빨리 한도를 "추가 구매"해야 하며, 이는 계산기에 또 하나의 변수로 들어오게 됩니다.

데이터에 대한 유의사항: 검증된 RPM 표에는 sonar-pro, sonar-reasoning-pro, sonar-deep-research가 기재되어 있었으나, 기본 모델인 "sonar" 자체의 상한선은 별도로 구분되어 있지 않았습니다. 정확히 기본 트래픽을 모델링하는 계산기를 만들기 위해서는 이 수치를 임의로 추측하지 말고 실제 콘솔에서 다시 확인해야 합니다.

이제 가장 가혹한 거절 상황에 대해 말씀드리겠습니다. API 빌링(billing)은 선불 방식입니다. 비용은 크레딧 잔액에서 차감되며, 잔액이 0에 도달하면 키(key)가 완전히 차단됩니다. 이는 속도를 조절하는 스로틀링(throttling)이 아니라 강제 중단입니다. Perplexity는 빌링 문서에서 이러한 시나리오를 방지하기 위해 설정된 임계값에서 자동 충전(auto-recharge)을 활성화할 것을 직접 권장합니다. 프로덕트 매니저(product manager)에게 이는 예산과 임계값을 모니터링하지 않으면, 검색 기능이 단순히 "비싸지는" 것이 아니라 운영 중인 프로덕션(production) 환경에서 어느 날 갑자기 꺼져버릴 수 있음을 의미합니다.

선불 메커니즘으로 인해 구매 시 혼동하기 쉬운 용어상의 교정도 필요합니다. 사람들이 "perplexity api 구매"를 검색할 때, 실제로는 크레딧 잔액을 충전하는 방법을 찾는 것입니다. 키는 콘솔에서 발급되며 그 자체로는 비용이 들지 않습니다. "perplexity 키 구매"라는 표현은 부정확한 설명입니다. 당신은 키가 아니라 크레딧에 비용을 지불하는 것이며, 바로 이 전체 기간 동안 구매한 크레딧의 총액이 당신을 더 높은 티어 계단으로 이동시킵니다.

여기서 저의 규범적인 입장은 이렇습니다: 관찰 가능한 예산과 제한(limit) 없이 검색 기능을 통합하지 마십시오. 이는 논쟁의 여지가 있는 절충안입니다. 임계값(threshold)을 설정하면 일부 요청이 차단되어 피크 타임의 사용자 경험이 저하됩니다. 하지만 '임계값 없이 검색을 실행하는' 대안은 시작부터 실패합니다. 견적(estimate)에 넣는 빈도는 전혀 측정되지 않았으며, 데모(demo)를 통해 이를 파악할 수도 없기 때문입니다.

정확히 무엇을 통합하고 있습니까: Sonar, Agent API, 아니면 Search API인가요?

대상 제품이 잘못되었다면 견적은 무의미합니다. Perplexity에는 현재 세 가지의 서로 다른 검색 인터페이스(surface)가 있으며, 각각 과금 방식이 다릅니다. Sonar-chat은 위에서 설명한 대로 토큰(token)과 요청당 수수료가 부과됩니다. 하지만 현재 공개된 내용에 따르면 Sonar는 공식적으로 "유지 관리 모드(maintenance mode)"로 표시되어 있으며, 문서는 새로운 통합의 경우 Agent API로 시작할 것을 권장하고 있습니다.

웹 기반 통합(web-grounded integrations)을 위한 권장 후계자인 Agent API는 자체적인 종량제(pay-as-you-go) 과금 방식을 가진 별도의 멀티 프로바이더(multi-provider) 사양입니다. Agent API의 퀵스타트(quickstart)에는 Sonar를 제어하는 search_context_size 계단식 구조나 1,000회 요청당 수수료 방식이 포함되어 있지 않습니다. 즉, Sonar의 가격표를 기반으로 구축된 계산기는 Agent API로 자동 전환되지 않으며, 다른 과금 모델에 맞춰 다시 구축해야 합니다.

세 번째 인터페이스는 LLM의 합성(synthesis) 없이 가공되지 않은 랭킹된 웹 결과(raw ranked web results)를 반환하는 별도의 perplexity search api이며, 이 또한 자체적인 종량제(pay-as-you-go) 방식을 따릅니다. 따라서 견적의 첫 번째 질문은 "검색 비용이 얼마인가"가 아니라 "내가 정확히 어떤 제품을 통합하고 있는가"가 되어야 합니다: Sonar 채팅인가, Agent API인가, 아니면 Search API인가? 이 세 가지 답변에 따라 세 가지의 서로 다른 견적이 나옵니다.

이러한 갈림길 때문에 요금제를 대조하는 것 자체가 별도의 작업이 되어버리며, 러시아어 검색 결과가 이를 방해합니다. 제품 설명들은 Perplexity API를 'perplexity api'라고 쓰기도 하고 'perplexity апи'라고 쓰기도 하며, 세 가지 인터페이스 중 정확히 어떤 것을 말하는지 명시하는 경우가 거의 없습니다. 그 옆에는 Perplexity Pro API라는 용어도 등장하는데, 저자의 절반은 이를 웹 버전 구독으로 오해하곤 합니다. 이는 API 빌링 (API billing)과는 전혀 무관한 것입니다. 심지어 'perplexity api price'나 'perplexity api pricing'이라는 제목의 페이지들조차 서로 다른 인터페이스나 다른 날짜의 정보를 다루기도 합니다. 따라서 제목이 아니라 요금 단위 (tariff unit)를 확인해야 합니다. 1,000회 요청당 과금이 없고 search_context_size 계단식 구조가 없다면, 당신 앞에 있는 것은 Sonar가 아닙니다.

그리고 솔직한 비즈니스적 주의 사항을 덧붙입니다. 제가 'Sonar의 기본 조건'이라고 부르는 것은, Perplexity가 통합 개발자들을 유지보수 모드로 유도하고 있는 제품의 조건입니다. 요금제는 변경될 수 있으며, 제품은 라이프사이클 (lifecycle)에 따라 더 멀리 이동할 수 있습니다. 유지보수 모드 (maintenance-mode)에 있는 제품을 기반으로 장기적인 기능을 구축하는 것이 불가능한 것은 아니지만, 이는 명확히 인지하고 내려야 할 결정입니다.