Perplexity Computer 완전 해부: 19개 AI 모델을 조율하는 멀티-모델 오케스트레이션 아키텍처
솔직히 말하면, 처음 "19개 AI 모델을 동시에 쓴다"는 말을 들었을 때 마케팅 과장이라고 생각했습니다. 그런데 직접 파고들어보니 이건 단순한 모델 연결이 아니라, 아키텍처 수준의 패러다임 전환이더군요. 2026년 2월 Perplexity AI가 공개한 Perplexity Computer는 "어떤 모델이 제일 좋냐"는 질문 자체를 구식으로 만드는 시스템입니다. 이 글에서는 그 오케스트레이션 구조가 어떻게 동작하는지, 그리고 AI 도구 도입을 검토 중인 백엔드 개발자 입장에서 실제로 무엇을 얻을 수 있는지를 깊이 파봅니다.
기존 AI 도구들은 대부분 단일 모델에 의존합니다. GPT를 쓰든 Claude를 쓰든, 결국 하나의 두뇌에 모든 걸 맡기는 구조죠. Perplexity Computer는 다릅니다. 복잡한 목표를 입력하면 시스템이 이를 하위 작업으로 자동 분해하고, 각 작업에 가장 적합한 모델을 골라 병렬로 실행한 뒤, 결과를 하나로 합쳐서 돌려줍니다.
$200/월이라는 진입 장벽이 있어서 "일단 써보고 결정하자"가 쉽지 않은 제품이기도 합니다. 이 글을 읽고 나면 Perplexity Computer가 자신의 워크플로에 실제로 맞는 도구인지 스스로 판단할 수 있을 것입니다.
핵심 개념
오케스트레이션 레이어와 모델 레이어의 분리
Perplexity Computer의 설계 철학은 소프트웨어 공학의 오래된 원칙에서 출발합니다.
관심사 분리 (Separation of Concerns): 오케스트레이션 레이어(작업 분해·상태 관리)와 모델 레이어(실제 연산)를 명확하게 분리하여, 더 좋은 모델이 등장해도 전체 아키텍처를 바꾸지 않고 해당 모델만 교체할 수 있도록 설계하는 방식
마이크로서비스 아키텍처를 떠올려보면 이해가 빠릅니다. 각 서비스가 자신의 역할에만 집중하고 API 계약만 지키면 내부 구현은 자유롭게 바꿀 수 있는 것처럼, Perplexity Computer도 오케스트레이터는 "무엇을 누구에게 맡길지"만 결정하고 실제 연산은 모델들이 담당합니다. 전체 시스템 흐름을 도식화하면 이렇습니다.
사용자 목표 (자연어)
↓
[오케스트레이션 레이어 — Model Council]
├─ 작업 분해 (Task Decomposition)
├─ 모델 라우팅 (PARL 기반)
└─ 상태 관리 및 결과 합성
↓
[모델 레이어 — 조건별 선택·병렬 실행]
├─ 추론 전문 모델 → 복잡한 논리·분석
├─ 리서치 전문 모델 → 대규모 정보 수집
├─ 장문 처리 모델 → 긴 문서·광범위 검색
├─ 경량 고속 모델 → 단순 반복, 빠른 응답
└─ 멀티미디어 모델 → 비디오·이미지 생성
↓
통합 결과 반환Model Council과 PARL
Perplexity가 독자 개발한 두 가지 핵심 컴포넌트가 이 시스템을 움직입니다.
Model Council은 오케스트레이션 프레임워크입니다. 들어온 목표를 분석해서 어떤 하위 작업이 필요한지 파악하고, 각 작업에 적합한 모델을 배정하며, 전체 실행 상태를 추적합니다. 개발자 관점에서 보면 일종의 "AI 프로젝트 매니저"인 셈이죠.
**PARL (Parallel-Agent Reinforcement Learning)**은 라우팅 최적화 엔진입니다. 어떤 작업을 어느 모델에 보냈을 때 결과가 좋았는지를 강화학습으로 계속 업데이트하면서 라우팅 결정의 품질을 점진적으로 개선합니다. 공개된 정보 기준으로, 보상 함수의 세부 구성(사용자 평점 기반인지, 태스크 완료율 기반인지)이나 온라인·오프라인 학습 방식은 아직 공식 문서에서 확인되지 않은 부분입니다.
강화학습 기반 라우팅이 실무에서 의미하는 것: 처음에는 휴리스틱 기반으로 모델을 배정하더라도, 피드백이 쌓일수록 라우팅 정확도가 올라갑니다. 사용자가 많아질수록 시스템이 더 정교해지는 구조입니다.
한 가지 궁금했던 점이 있는데요, 모델 하나가 타임아웃되면 어떻게 되는 걸까 싶었습니다. 공식 문서에서 명시된 내용은 아니지만, 감사 및 롤백 지원이 포함되어 있는 것으로 보아 장애 발생 시 재시도나 대체 모델 전환 메커니즘이 있을 가능성이 높습니다. 다만 결과 합성 단계에서 모델 간 품질 충돌을 어떻게 해소하는지는 공개된 자료에서 아직 확인하기 어렵습니다.
모델 스택 전체 구성
저도 처음엔 "19개 모델이 다 동시에 뜨는 건가?"라고 헷갈렸는데, 실제로는 작업 유형에 따라 필요한 모델만 선택적으로 활성화됩니다. 아래 표는 공개된 정보 기준으로 정리한 것으로, 일부 모델명과 버전은 공식 확인이 필요한 항목입니다.
| 모델 (공개 정보 기준) | 주요 역할 | 활성화 시나리오 |
|---|---|---|
| Claude Opus | 핵심 추론 엔진 | 복잡한 논리·분석 작업 |
| Gemini | 심층 리서치·서브에이전트 생성 | 대규모 정보 수집 |
| GPT 계열 | 장문 컨텍스트 처리 | 긴 문서 분석·광범위 검색 |
| Grok | 경량 고속 처리 | 단순 반복 작업, 빠른 응답 필요 시 |
| 비디오 생성 모델 | 시각 콘텐츠 생성 | 동영상 관련 요청 |
| 이미지 생성 모델 | 이미지 관련 작업 | 이미지 생성·편집 요청 |
Personal Computer for Mac — 로컬 에이전트의 등장
클라우드 기반 Perplexity Computer와 별개로, 2026년 4월부터 롤아웃 중인 Personal Computer for Mac은 결이 좀 다릅니다. Mac에 로컬 설치되어 iMessage, Mail, Calendar 같은 네이티브 앱에 24/7 상시 접근하는 에이전트입니다.
클라우드에 올리기 민감한 데이터(개인 메일, 캘린더 등)를 로컬에서 처리할 수 있다는 점에서 엔터프라이즈 환경에서도 관심을 받고 있습니다. 주제 특성상 분량이 상당해서, Personal Computer for Mac 상세 활용법은 별도 글에서 다룰 예정입니다.
실전 적용
예시 1: 대규모 데이터 수집 자동화
실무에서 자주 맞닥뜨리는 상황인데, 경쟁사 제품 수십 개의 가격·스펙 정보를 스프레드시트로 정리해야 하는 경우입니다. 기존이라면 크롤러 짜고, 데이터 정제하고, 구조화하는 데 최소 1주일은 잡아야 했죠.
Perplexity Computer에서는 자연어 목표 기술만으로 시작할 수 있습니다.
목표 입력 예시:
"다음 50개 SaaS 제품의 가격 플랜, 주요 기능, 타겟 고객군을
조사해서 비교 스프레드시트로 정리해줘.
공식 사이트, G2, Capterra를 모두 참고해줘."내부적으로 일어나는 일을 분해하면 이렇습니다.
| 단계 | 담당 레이어 | 수행 내용 |
|---|---|---|
| 작업 분해 | Model Council | 50개 제품을 병렬 처리 가능한 배치로 분할 |
| 웹 크롤링 | 장문 처리 모델 | 각 제품 공식 사이트 정보 수집 |
| 리뷰 수집 | 리서치 전문 모델 | G2·Capterra 리뷰 및 평점 크롤링 |
| 데이터 정제·구조화 | 추론 전문 모델 | 수집 데이터 표준화 및 비교 포맷 생성 |
| 결과 합성 | Model Council | 통합 스프레드시트 산출 |
실제 사용자 사례에서는 이 작업이 하룻밤 만에 완료된 것으로 보고되었습니다. 에이전트 설정 파일이나 라우팅 로직을 별도로 작성할 필요가 없다는 점이 개발자 입장에서 가장 인상적인 부분입니다.
주의: 수치·통계 결과는 원본 출처를 직접 확인하는 것이 좋습니다. 멀티-모델 시스템이라도 환각(hallucination)은 발생하며, 특히 법률·재무 관련 정보에서는 검증 단계가 반드시 필요합니다.
예시 2: Slack 기반 팀 워크플로 자동화
Slack 엔터프라이즈 연동이 공개된 이후로 팀 단위 활용 패턴이 흥미롭습니다. @computer 멘션 하나로 복잡한 리서치를 위임할 수 있습니다.
# Slack 채널에서의 사용 패턴 (구조 설명용 예시)
[PM] @computer
내일 투자자 미팅 전에 경쟁사 3곳(Notion, Confluence, Linear)의
최근 6개월 제품 업데이트 동향 정리해줘.
주요 기능 추가·가격 변화·사용자 반응 포함해서.
[Perplexity Computer]
분석 시작합니다. 예상 소요 시간: 12분
├─ Notion: 공식 블로그, Product Hunt, Reddit 크롤링 중...
├─ Confluence: Atlassian 릴리스 노트, G2 리뷰 수집 중...
└─ Linear: 체인지로그, HN 스레드 분석 중...MCP(Model Context Protocol) 기반 커스텀 커넥터를 활용하면 자체 내부 데이터베이스나 사내 API도 에이전트 컨텍스트에 연결할 수 있습니다.
MCP (Model Context Protocol): AI 모델이 외부 도구·데이터 소스에 표준화된 방식으로 접근할 수 있게 해주는 프로토콜. Anthropic이 제안한 오픈 스펙으로, 커스텀 엔터프라이즈 커넥터 개발에 활용됩니다.
예시 3: 코드 생성에서 배포까지
요구사항을 입력하면 코드 생성 → 테스트 → 배포 단계가 순차적으로 자동화되는 시나리오입니다. 아래 코드는 Perplexity Computer의 실제 출력을 그대로 옮긴 것이 아니라, 이 유형의 요청에서 어떤 구조의 코드가 산출되는지를 설명하기 위한 예시입니다.
목표 입력:
"Python FastAPI로 JWT 인증이 포함된 간단한 사용자 관리 API를 만들어줘.
CRUD 엔드포인트, pytest 테스트, Docker Compose 설정 포함.
완성되면 내 GitHub 레포에 PR 열어줘."# 구조 설명용 코드 예시 (시스템 출력 아님)
import os
from fastapi import FastAPI, Depends, HTTPException, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
import jwt
app = FastAPI()
security = HTTPBearer()
SECRET_KEY = os.getenv("SECRET_KEY") # 환경변수로 주입 필수
async def verify_token(credentials: HTTPAuthorizationCredentials = Depends(security)):
try:
payload = jwt.decode(
credentials.credentials,
SECRET_KEY,
algorithms=["HS256"]
)
return payload
except jwt.ExpiredSignatureError:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Token expired"
)
@app.get("/users/me")
async def get_current_user(token_data: dict = Depends(verify_token)):
return {"user_id": token_data["sub"]}이 시나리오에서 오케스트레이터는 코드 생성, 테스트 작성, Docker 설정, GitHub API 호출을 각각 적절한 서브에이전트에 위임하고 전체 흐름을 조율합니다.
장단점 분석
장점
| 항목 | 내용 |
|---|---|
| 멀티-모델 최적 라우팅 | 작업 유형별로 가장 적합한 모델이 자동 배정되어 단일 모델 대비 결과 품질 향상 |
| 재현 가능한 클라우드 샌드박스 | "내 로컬에서만 된다" 문제 없이 동일한 실행 환경 보장 |
| 400+ 앱 커넥터 기본 제공 | Snowflake, Salesforce, HubSpot 등 주요 엔터프라이즈 툴 연동 즉시 사용 가능 |
| 병렬 처리 | 웹·학술·이미지·소셜 등 7종 검색 유형 동시 병렬 실행으로 속도 확보 |
| 인간 통제 유지 | 민감한 작업 전 사람 확인 요청, 작업 감사 및 롤백 지원 |
| 에이전트 설정 불필요 | 자연어 목표 기술만으로 서브에이전트 스핀업·모델 배정·결과 합성 자동 처리 |
단점 및 주의사항
제가 실제로 가장 먼저 부딪힌 문제는 사용량 한도 불투명이었습니다. 크레딧이 어떻게 소모되는지 명확히 알 수 없는 상태에서 대규모 작업을 돌리는 건 꽤 불안한 경험이더군요.
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| 높은 진입 비용 | $200/월 — 가끔 사용자는 ROI 확보 어려움 | 팀 단위 공유 또는 반복 가능한 워크플로가 확실한 경우에만 도입 검토 |
| 사용량 한도 불투명 | 크레딧 소모 방식이나 상세 한도 미공개 | 소규모 작업부터 시작해 실제 소모량 파악 후 확장 |
| 초기 안정성 문제 | 2026년 2월 출시 제품, 일부 커넥터 불안정 | 중요 워크플로는 반드시 인간 검토 단계 포함 |
| 법적 리스크 | Amazon 금지 명령(2026년 3월), Reddit·Forbes 소송이 진행 중인 것으로 알려짐 | 크롤링 결과 상업적 활용 시 데이터 출처 및 저작권 확인 필요 |
| 개인정보 우려 | 브라우저 오픈 시 입력 내용 즉시 로깅 사례가 보고된 바 있음 | 민감한 내부 데이터는 Personal Computer(로컬) 활용 검토 |
스텔스 크롤링 이슈: Cloudflare가 Perplexity Computer의 크롤링 방식을 지적한 사안으로, 봇 차단을 우회하는 방식으로 웹 콘텐츠를 수집한다는 논란입니다. 크롤링 결과를 상업적으로 활용할 경우 법적 리스크가 따를 수 있어 주의가 필요합니다.
실무에서 가장 흔한 실수
- 결과를 무검증으로 신뢰하는 것 — 멀티-모델 시스템이라도 환각(hallucination)은 발생합니다. 수치·통계·법률 관련 결과는 원본 출처를 직접 확인하는 것이 좋습니다.
- 목표를 너무 광범위하게 던지는 것 — 목표가 불명확하면 작업 분해가 비효율적으로 이루어질 수 있습니다. 명확한 성공 기준과 범위를 함께 기술하면 결과 품질이 눈에 띄게 달라집니다.
- 민감한 데이터를 클라우드 버전에 그대로 입력하는 것 — 개인정보나 내부 기밀 데이터는 클라우드 버전보다 Personal Computer for Mac(로컬) 쪽을 고려해보시는 것이 안전합니다.
마치며
Perplexity Computer는 "어떤 AI 모델을 쓸까"라는 질문을 "어떤 목표를 달성할까"로 바꿔버리는 시스템입니다. 오케스트레이션과 모델 레이어를 분리한 아키텍처 덕분에, 더 좋은 모델이 등장해도 시스템 전체를 갈아엎지 않고 모듈 단위로 업그레이드할 수 있다는 점이 장기적으로 매력적입니다.
지금 바로 시작해볼 수 있는 3단계:
- 데모 영상으로 맥락을 먼저 파악하세요 — Perplexity 공식 블로그에서 실제 동작하는 4,000행 스프레드시트 생성 케이스를 보시면 "이 시스템이 실제로 무엇을 할 수 있는가"에 대한 감이 잡힙니다.
- 팀 내 반복 작업 하나를 골라 ROI를 계산해보세요 — 주 2회 이상 수작업으로 처리하는 리서치·데이터 수집 업무가 있다면, 해당 작업의 시간 비용과 $200/월을 비교해보시면 도입 여부를 판단하기 수월합니다.
- MCP 커스텀 커넥터 스펙을 미리 익혀두세요 — 내부 API나 DB를 에이전트 컨텍스트에 연결하는 커스텀 커넥터 개발을 위해, MCP 공식 스펙을 살펴두시면 좋습니다. 엔터프라이즈 도입 시 가장 먼저 필요한 부분이 여기입니다.
참고 자료
- Introducing Perplexity Computer | Perplexity 공식 블로그
- What is Computer? | Perplexity Help Center
- Perplexity's new Computer is another bet that users need many AI models | TechCrunch
- Perplexity's Personal Computer AI assistant feature launches on Mac | 9to5Mac
- Perplexity takes its 'Computer' AI agent into the enterprise | VentureBeat
- Perplexity Computer: 19 AI Models, One System | Till Freitag
- Perplexity Computer Review 2026 | aigyani.com
- Perplexity Computer Multi-Model Agent Orchestration Guide | Zen van Riel
