Design PerplexityAI, 답변을 만드는 서비스가 아니라, 출처 신뢰도를 실시간으로 운영하는 인프라다
LLM 호출보다 어려운 건, 사용자가 이 답을 지금 검증할 수 있게 8초 안에 근거를 붙이는 일이다
Introduction & Requirements
아래 설계는 Perplexity의 공개 API 문서와 검색형 AI 제품 특성을 바탕으로 한 시스템 디자인 가정이며, Perplexity 내부 구현을 그대로 설명하는 글은 아닙니다.
Perplexity AI를 시스템 디자인 문제로 받으면, 주니어 엔지니어가 가장 먼저 하는 실수가 있습니다. 문제를 너무 작게 잡습니다.
“사용자가 질문을 입력하면 LLM이 답변을 만들고, 그 답변을 저장하면 되지 않을까요?”
이렇게 말하면 면접관은 바로 다음 질문을 던질 겁니다.
“그 답변은 어디서 나온 건가요?”
Perplexity AI는 단순 생성형 답변 UI가 아닙니다. Perplexity의 공식 API 문서도 Search API를 실시간 웹 검색 결과, 랭킹 결과, 도메인 필터, 다중 쿼리 검색, 콘텐츠 추출을 제공하는 경로로 설명합니다. 그리고 Sonar는 웹 기반 응답, citation, conversation context, streaming을 제공하는 경로로 설명합니다. 즉 이 시스템의 설계 대상은 “답변 생성”이 아니라 “검색, 출처 선별, 생성, 인용, 스트리밍을 하나의 응답으로 묶는 실시간 답변 엔진”입니다.
면접에서 먼저 잡아야 할 질문은 이겁니다.
“우리가 설계하는 것은 단순 질의 응답인가요, 아니면 citation이 붙은 source-grounded answer engine인가요?”
이 질문이 먼저 나와야 합니다. 왜냐하면 citation이 붙는 순간 시스템의 중심 축이 달라집니다. answer text만 저장하면 되는 게 아닙니다. 어떤 검색 후보가 들어왔는지, 어떤 source가 최종 context에 들어갔는지, 답변의 어느 문장이 어느 source에 기대고 있는지, source가 나중에 접근 불가능해졌을 때 citation을 어떻게 표시할지까지 설계해야 합니다.
두 번째 질문은 이겁니다.
“모든 질문이 실시간 검색을 타야 하나요, 아니면 캐시된 검색 결과를 허용하나요?”
이 질문은 비용과 latency를 가릅니다. 모든 질문을 실시간 검색, 문서 추출, reranking, LLM 생성, citation mapping으로 태우면 답변 품질은 좋아 보일 수 있습니다. 하지만 피크 시간대에는 Search Orchestrator, Document Extractor, Ranking Service, Model Gateway, Stream Gateway가 동시에 압박받습니다. 반대로 캐시를 적극적으로 쓰면 latency와 비용은 줄어듭니다. 하지만 source freshness가 떨어질 수 있습니다.
아키텍트는 이 시점에서 냉정한 결단을 내려야 합니다. 모든 질문에 같은 신선도와 같은 검색 깊이를 주는 설계는 보기에는 공평합니다. 하지만 운영에서는 정상 작동하기 어렵습니다. 사용자의 질문 의도에 따라 fast path와 deep research path를 나눠야 합니다.
세 번째 질문은 이겁니다.
“사용자는 완성된 답변만 받아야 하나요, 아니면 처리 상태와 partial answer를 streaming으로 받아야 하나요?”
Perplexity AI 같은 서비스에서 streaming은 단순 UI 장식이 아닙니다. 인간의 인지적 한계를 이용하는 UX 계약에 가깝습니다. 긴 분산 작업을 사용자가 이해 가능한 작은 상태 변화로 쪼개 보여주는 방식입니다. 사용자는 전체 답변 완료 시간이 8초여도, 1.5초 안에 첫 문장을 보면 시스템이 빠르다고 느낍니다. 그런데 이 UX 계약은 인프라 비용을 가져옵니다. streaming connection은 오래 열려 있습니다. client network가 약하면 서버 buffer가 쌓입니다. 재연결이 늘어나면 Event Sync API도 같이 바빠집니다.
네 번째 질문은 이겁니다.
“답변 생성 이후에도 source freshness를 다시 확인해야 하나요?”
이 질문이 중요합니다. source는 답변 생성 시점에는 접근 가능했지만, 사용자가 나중에 다시 열었을 때는 접근 불가능할 수 있습니다. 그래서 answer와 source status를 분리해야 합니다. answer는 과거 생성 결과로 보존할 수 있습니다. 하지만 citation은 현재 validation status를 반영해야 합니다. 특히 notification이나 shared preview처럼 시스템이 사용자에게 먼저 밀어내는 경로에서는 Send-time Validation이 필요합니다.