7월 13일, Perplexity는 Computer 기능을 확장했습니다. 이 서비스는 이전 작업에 대한 메모리(Memory), 더 빠른 모델, 작업 내 모델 전환, 사이트 게시 및 비공개 기업 조사 기능을 갖추게 되었습니다. 같은 2주간의 논의 흐름 속에서, "Perplexity에 무슨 일이 일어났는가"에 대한 커뮤니티의 한 주요 스레드는 435개의 추천을 받았고, 특정 사용자의 구독 취소를 다룬 다른 스레드는 124개의 추천을 받았습니다.

이것은 제품의 역설이 아니라 두 가지 서로 다른 검증입니다. Computer의 새로운 기능들은 다단계 작업(multi-step work)을 더 편리하게 만들 수 있습니다. 하지만 이 기능들이 출처를 기반으로 하는 일반적인 검색의 정확성(accuracy), 완전성(completeness), 안정성(stability)에 대해 그 자체로 무엇인가를 말해주지는 않습니다. 만약 워크플로(workflow)가 검색에 의존한다면, 이번 업데이트는 개선의 증거가 아니라 별도의 테스트를 위한 계기로 받아들여야 합니다.

무엇이 변했고 무엇이 여전히 미지수인가

이전 작업에 대한 메모리는 작업이 한 번의 단계 이상 지속되는 곳에서 유용합니다. 즉, 컨텍스트(context)를 유지하고, 접근 방식이나 모델을 변경한 다음, 결과를 수집하고 게시해야 하는 경우입니다. 이 시나리오에서 가치는 작업의 연속성으로 측정됩니다. 즉, 작업을 다시 설명해야 하는지, 모델 변경 시 컨텍스트를 잃는지, 결과를 내보내기(export)까지 완료할 수 있는지 여부입니다.

하지만 검색(Search)은 다른 문제를 해결합니다. 여기서는 동일한 질의(query)에 대해 품질 높은 답변이 반복되는지, 알려진 관련 출처를 찾아내는지, 그리고 명확한 이유 없이 결과가 변하지 않는지가 더 중요합니다. 에이전트 루프(agentic loop) 내에 메모리가 있다는 것은 이러한 속성 중 어느 하나에 대한 지표도 아닙니다.

그렇기 때문에 "Perplexity는 검색인가 아니면 에이전트인가?"라는 질문을 하나의 역할 중 하나를 선택하는 문제로 축소하는 것은 잘못된 것입니다. 사용자에게 이것은 인접해 있지만 독립적인 두 개의 루프일 수 있습니다. 한 쪽의 개선이 반드시 다른 쪽의 저하를 보상해야 하는 것은 아닙니다.

불만을 무시해서는 안 되지만, 통계로 치부해서도 안 되는 이유

7월 9일의 토론에서 활성 사용자들은 제품이 기존의 검색 우선 (search-first) 포커스를 잃었는지, 그리고 사용자 경험이 악화되었는지에 대해 논쟁했습니다. 7월 15일의 스레드는 한 사용자가 구독을 해지하기로 결정한 사례를 기록하고 있습니다. 이는 업데이트 속도에 대한 눈에 띄는 역신호 (counter-signal)입니다. 사용자층의 일부는 Perplexity의 가치를 새로운 에이전트적 (agentic) 동작의 양이 아니라, 무엇보다 검색에 대한 신뢰와 연결 짓고 있습니다.

하지만 435표와 124표라는 숫자가 전체 사용자의 이탈을 측정하거나 전역적인 악화를 증명하는 것은 아닙니다. 이는 의견을 표출하기로 결정한 사람들의 경험일 뿐, 사용자 전체를 대표하는 표본은 아닙니다.

여기서 중요한 전환점이 발생합니다. 새로운 기능들이 불만 사항을 반박한다고 생각하면 편리하겠지만, 그러한 결론을 내릴 데이터는 없습니다. 그렇다고 해서 불만 사항들 때문에 검색 기능이 모두에게 망가졌다고 선언할 수도 없습니다. 불확실성을 인정하고 자신만의 시나리오를 검증하는 것이 더 실용적입니다.

Два независимых canary для Search и Computer

대규모 마이그레이션 대신 두 가지 짧은 카나리 (canary) 테스트

첫 번째 카나리는 검색 (Search)에 관한 것입니다. 필요한 출처를 미리 알고 있는 일련의 반복적인 쿼리 세트를 준비하십시오. 문구의 아름다움이 아니라, 해당 출처가 나타나는지, 반복 시 답변의 논리가 유지되는지, 그리고 누락을 빠르게 발견할 수 있는지를 확인하십시오.

두 번째는 Perplexity Computer에 관한 것입니다. 이전 작업에 대한 메모리 (memory), 모델 전환, 그리고 결과 내보내기가 실제로 필요한 하나의 다단계 (multi-step) 과제를 부여하십시오. 단계 사이에서 컨텍스트 (context)가 유지되는지, 그리고 불필요한 수동 복구 없이 최종 결과에 도달하는지를 평가하십시오.

결과를 하나의 통합 점수로 섞어서는 안 됩니다. 강력한 에이전트적 (agentic) 시나리오가 취약한 검색 루프를 바로잡을 수 없듯이, 훌륭한 검색이 긴 과제의 편의성을 증명하는 것도 아닙니다. 두 루프가 모두 검증을 마친 후에 전체 워크플로우 (workflow)를 옮기는 것이 합리적입니다.

가장 강력한 반론은 솔직하게 들립니다. 사용자에게 중요한 것은 작업의 결과물이지, Search (검색)와 Computer (컴퓨터) 사이의 내부적인 경계가 아니라는 점입니다. 만약 메모리 (memory) 기능이 반복 횟수를 줄이고 조사가 결과에 도달하도록 돕는다면, 이는 검색 자체에서의 개별적인 이득보다 더 가치 있을 수 있습니다. 맞습니다. 하지만 출처가 의사결정의 근거가 되는 작업의 경우, 프로세스의 편의성이 답변의 검증 가능성 (verifiability)을 대체할 수는 없습니다.

다양한 시나리오를 서로 다른 제공업체로 라우팅 (routing)하고, 새로운 기능 세트가 이미 검증된 검색 루프를 자동으로 밀어내지 않도록 독립적인 카나리 (canary)를 유지하는 것이 유용합니다. 이러한 접근 방식은 provod.ai에서 구축할 수 있습니다.

Проверить Search и Computer раздельно

provod.ai — 러시아 비즈니스를 위한 AI 통합 접속 지점

기술적 및 조직적 경계를 결합하세요: 모델은 공통 API를 통해 연결되며, 계산은 루블화로 이루어지고, 법인은 문서를 수령하며, 팀은 기업용 공간에서 작업합니다.

단일 카탈로그에서 텍스트 및 미디어용 최신 모델을 확인하세요: OpenAI의 GPT, Anthropic의 Claude, Google의 Gemini, xAI의 Grok, DeepSeek, Qwen, GLM, Kimi 및 MiniMax; 이미지를 위한 Nano Banana 2 Pro 및 GPT Image; 비디오를 위한 Seedance, Kling, Veo 및 Google Omni의 최신 버전이 포함됩니다. 또한 추론 (reasoning), 검색, 문서, 임베딩 (embeddings), 음악 및 오디오를 위한 모델도 사용할 수 있습니다.

러시아에서의 접근성과 직접적인 경제성을 결합했습니다: 모델의 공식 요금제가 provod.ai의 자체 마진 없이 1:1로 적용됩니다.

기업용 AI 루프를 구축하세요: 등록 양식 · 모델 가격 · 152-FZ에 따른 데이터 보호 · 계약용 세부 정보

귀하의 팀에게 더 비용이 많이 드는 것은 무엇입니까: 검증된 검색(search)을 별도의 컨투어(contour)로 유지하는 것입니까, 아니면 더 통합된 에이전트 작업(agentic work)을 위해 마이그레이션(migration)의 위험을 감수하는 것입니까?