perplexity

perplexity skill 개요

perplexity skill은 softaworks/agent-toolkit 안에서 Perplexity 기반 웹 리서치를 어떤 경로로 실행할지 판단하고, 어떻게 써야 하는지 안내하는 라우팅/사용 가이드입니다. 역할은 단순히 “웹 검색”에 그치지 않습니다. 요청에 맞는 Perplexity 도구를 고르고, 결과 양이 과도하게 불어나지 않게 제어하며, 더 적합한 전용 도구가 있을 때는 웹 검색을 쓰지 않도록 에이전트를 도와주는 데 핵심 가치가 있습니다.

어떤 사용자에게 맞는 perplexity skill인가

이 perplexity skill은 다음이 필요한 사용자에게 잘 맞습니다.

• 최신 웹 정보
• 자료 탐색과 출처 URL 확보
• 폭넓은 주제에 대한 가벼운 조사
• 단순한 “search the web” 프롬프트보다 나은 기본 동작

특히 빠른 검색, 대화형 답변, 더 깊은 조사 사이에서 에이전트가 스스로 적절한 경로를 고르되 토큰을 낭비하지 않게 하고 싶다면 유용합니다.

사용자가 perplexity에서 실제로 얻는 것

여기서 perplexity의 진짜 가치는 워크플로 규율에 있습니다.

• 링크와 최신 출처가 필요하면 Perplexity Search
• 바로 답을 받고 싶으면 Perplexity Ask
• 여러 단계를 거치는 깊은 조사가 필요하면 Researcher agent

이 구분은 중요합니다. 많은 에이전트가 과하게 검색하거나, 결과를 너무 많이 반환하거나, 사실은 문서나 워크스페이스 도구로 해결해야 할 작업까지 웹 검색으로 처리하려 하기 때문입니다.

가장 잘 맞는 작업 유형

perplexity는 이런 작업에 적합합니다.

• “최근에 나온 … 관련 글 찾아줘”
• “…에 대한 현재 베스트 프랙티스 찾아줘”
• “… 관련 튜토리얼/리소스 검색해줘”
• “… 최신 동향이 뭐야?”
• “Perplexity로 …를 짧게 요약해줘”

목표가 최신성이 중요한 웹 리서치라면 이 skill은 꽤 잘 맞습니다.

설치 전에 알아야 할 중요한 경계

이 skill은 의도적으로 범위를 좁혀 두었습니다. 다음 용도에는 Perplexity를 쓰지 말라고 안내합니다.

• 라이브러리/프레임워크 문서 조회 → Context7
• 워크스페이스 특화 질문 → Nx MCP
• Graphite gt CLI 관련 질문 → Graphite MCP
• 이미 알고 있는 특정 URL 조회 → URL crawler
• 기본적으로 깊은 조사 필요 → /research <topic>

이 점 때문에 perplexity는 흔한 범용 검색 래퍼보다 더 실용적입니다. 잘못된 도구 선택을 줄여 주기 때문입니다.

일반적인 프롬프팅과 무엇이 다른가

보통 프롬프트는 “X를 웹에서 검색해” 정도로 끝납니다. 하지만 이 skill은 품질을 높이는 운영 가이드를 추가합니다.

• 컨텍스트 비대화를 막기 위해 낮은 검색 제한값에서 시작
• search / answer / research를 구분
• “쓰면 안 되는 경우”를 명확히 제시
• 웹 리서치를 기본 반사 동작이 아니라 범위가 정해진 도구로 취급

설치 여부를 판단할 때, 가장 큰 장점은 바로 이 점입니다.

perplexity skill 사용 방법

perplexity 설치 맥락

toolkit의 표준 설치 흐름을 쓰고 있다면 아래 명령으로 skill을 추가하면 됩니다.

npx skills add softaworks/agent-toolkit --skill perplexity

그다음 아래 파일을 읽으세요.

1. skills/perplexity/SKILL.md
2. skills/perplexity/README.md

SKILL.md는 빠르게 참고할 수 있는 운영용 문서이고, README.md는 배경 설명이 더 많습니다.

먼저 읽어야 할 저장소 파일

시작은 아래 두 파일이면 충분합니다.

• 라우팅 규칙과 기본 파라미터는 SKILL.md
• 사용 의도와 맥락은 README.md

이 skill에는 큰 rules/나 resources/ 트리가 따로 없어서, 실질적으로 필요한 정보 대부분이 이 두 파일에 바로 들어 있습니다.

어떤 Perplexity 경로를 쓸지 먼저 결정하기

저장소는 실무적으로 세 가지 경로를 분명히 구분합니다.

• Perplexity Search: URL, 출처, 최신 글이 필요할 때 가장 적합
• Perplexity Ask: 직접적인 대화형 답변이 필요할 때 가장 적합
• /research <topic>를 통한 Researcher agent: 더 깊고 넓은 조사에 가장 적합

간단한 선택 기준은 이렇습니다.

• 링크가 필요하다면 Search
• 간결한 답이 필요하다면 Ask
• 여러 관점을 종합해야 한다면 Researcher

perplexity는 맞는 트리거 표현일 때만 쓰기

이 skill은 아래 같은 요청을 염두에 두고 설계되었습니다.

• “search”
• “find”
• “look up”
• “ask”
• “research”
• “what’s the latest”

당연해 보여도 중요합니다. 애매한 질문마다 무조건 웹 리서치를 돌려 버리는 흔한 실패 패턴을 막아 주기 때문입니다.

기본 검색 제한값에서 시작하기

이 perplexity 가이드에서 가장 실용적인 조언은 작은 제한값으로 시작하라는 점입니다. 저장소는 아래 값을 명시적으로 권장합니다.

• max_results: 3
• max_tokens_per_page: 512

왜 중요하냐면:

• 답변 초점을 유지하고
• 잡음 많은 출처 나열을 줄이며
• 가치가 낮은 페이지에 토큰을 낭비하지 않고
• 1차 조사 속도를 높여 주기 때문입니다

초기 검색이 분명히 부족했거나 사용자가 더 넓은 커버리지를 명시적으로 원할 때만 제한값을 늘리세요.

좋은 perplexity 입력에 필요한 정보

좋은 perplexity 사용법의 핵심은 입력을 구체화하는 데 있습니다. 가능하면 아래 정보를 포함하세요.

• 정확한 주제
• 최신성 요구 여부
• 원하는 출력 형태
• 출처 유형이나 범위에 대한 제약

약한 입력:

• “search AI agents”

더 나은 입력:

• “Search for recent 2024–2025 articles on enterprise AI agent evaluation frameworks. Return 3 strong sources with URLs and a one-line reason each.”

두 번째 예시는 무엇을 찾을지, 얼마나 최신이어야 하는지, 어떤 결과가 성공인지까지 분명히 지정합니다.

막연한 목표를 더 좋은 프롬프트로 바꾸기

perplexity for Web Research에서 잘 통하는 패턴은 다음과 같습니다.

Goal + time frame + source preference + output format

예시:

• “Find recent best-practice articles on RAG evaluation from the last 12 months. Prefer practical engineering sources. Return 3 URLs and summarize the main evaluation criteria.”

이 방식이 아래보다 낫습니다.

• “research RAG evaluation”

최신성, 출처 유형, 응답 구조를 함께 좁혀 주기 때문입니다.

실무형 perplexity 사용 워크플로

안정적인 워크플로는 아래와 같습니다.

1. Perplexity Search로 시작한다
2. 상위 3개 결과가 관련성이 있는지 확인한다
3. 해석이나 설명이 더 필요하면 Perplexity Ask로 전환한다
4. 그래도 범위가 얕다면 /research <topic>로 넘긴다

처음부터 과도하게 깊은 조사로 바로 들어가는 것보다 이 단계적 접근이 낫습니다.

결과 제한을 늘려야 하는 시점

검색 범위를 넓히는 건 아래 경우에만 하세요.

• 1차 검색에서 건질 만한 결과가 거의 없었을 때
• 주제가 유난히 파편화되어 있을 때
• 사용자가 포괄적인 커버리지를 요구했을 때
• 여러 관점이나 출처가 꼭 필요할 때

단지 “결과가 많을수록 안전해 보인다”는 이유로 제한을 늘리지는 마세요. 실제로는 답변 품질이 떨어지는 경우가 많습니다.

도입에 맞지 않는 경우

이 perplexity skill을 범용 리서치 레이어로 기대하고 설치하면 실망할 수 있습니다. 아래 작업이 대부분이라면 적합도가 낮습니다.

• 공식 API/프레임워크 문서 조회
• 저장소나 워크스페이스 내부 분석
• 고정된 URL에서 정보 추출
• 기본적으로 깊은 문헌형 종합이 필요한 작업

이 경우 저장소 자체 가이드도 다른 도구를 쓰라고 안내합니다.

실전용 예시 프롬프트

시작용으로 강한 프롬프트 예시는 아래와 같습니다.

“Use perplexity to search for recent guidance on AI product analytics instrumentation. I need 3 high-quality sources with URLs, published recently if possible, plus a short note on why each source is worth reading.”

좋은 이유:

• 도구 사용 의도가 명확하고
• 최신 정보가 필요하다는 신호가 있으며
• 결과 수가 관리 가능하고
• 출력 형식이 분명하고
• 출처 품질 기대치가 들어 있기 때문입니다

perplexity skill FAQ

perplexity는 주로 검색 도구인가, 리서치 도구인가?

둘 다이지만 같은 방식은 아닙니다. 이 저장소에서는 perplexity를 가벼운 웹 리서치 레이어로 보는 것이 가장 적절합니다.

• URL과 최신 출처를 찾을 때는 Search
• 직접적인 답이 필요할 때는 Ask
• 깊은 조사는 /research로 넘기기

일반적인 “search the web” 프롬프트보다 낫나?

일관된 동작을 원한다면 그렇습니다. 이 skill은 아래 요소를 추가합니다.

• 도구 선택 규칙
• 명시적인 비권장 사용 사례
• 더 낮은 기본 검색 제한
• 상위 단계로 올리는 기준

바로 이런 부분이 시행착오를 줄여 줍니다.

초보자에게도 괜찮은가?

네. 범위가 좁고, 라우팅 규칙도 따라가기 쉽습니다. 초보자가 기억해야 할 핵심은 하나입니다. 범용 웹 리서치에는 쓰되, 문서 조회나 워크스페이스 질문, 이미 알고 있는 URL 조회에는 쓰지 않는다는 점입니다.

언제 이 perplexity skill을 쓰지 말아야 하나?

아래 작업이라면 건너뛰는 편이 낫습니다.

• 공식 문서 조회
• 워크스페이스 특화 분석
• 특정 URL 가져오기
• 이미 researcher 워크플로가 필요한 깊은 조사

이건 저장소에서 가장 강하게 주는 신호 중 하나이며, 그대로 따를수록 결과가 좋아집니다.

perplexity가 문서 도구를 대체하나?

아닙니다. 이 perplexity 가이드는 문서 관련 질문은 Perplexity가 아니라 Context7로 보내야 한다고 분명히 말합니다. 이 경계는 중요합니다. 웹 결과는 공식 문서보다 잡음이 섞이기 쉬우니까요.

토큰 사용량에 대한 분명한 입장이 있나?

있습니다. 의도적으로 더 빡빡한 검색 제한값에서 시작합니다. 이는 기능 부족이 아니라 설계된 특성입니다. 목표는 컨텍스트 창을 넘치게 하지 않으면서도 쓸 만한 1차 조사 결과를 얻는 것입니다.

perplexity skill 개선 방법

perplexity에는 단편적인 주제가 아니라 리서치 브리프를 주기

더 나은 결과는 보통 아래를 함께 지정할 때 나옵니다.

• 주제
• 최신성
• 대상 독자나 사용 맥락
• 선호하는 출처 유형
• 원하는 결과 형식

예를 들어 아래 대신:

• “find MCP resources”

이렇게 쓰세요:

• “Find recent implementation-focused resources on MCP server design for engineering teams. Return 3 URLs, and note which are best for architecture vs hands-on setup.”

처음부터 출력 구조를 요구하기

간단한 구조 지정만으로도 perplexity 사용법의 품질이 많이 올라갑니다.

• “3 sources”
• “one-line takeaway each”
• “include URL”
• “compare them”
• “flag which source is most current”

이렇게 하면 장황한 요약을 줄이고 결과를 바로 활용하기 쉬워집니다.

가장 흔한 실패 원인인 잘못된 도구 선택 막기

약한 결과는 검색 실행 전에 이미 시작되는 경우가 많습니다. 아래를 먼저 점검하면 품질이 좋아집니다.

• 이게 정말 범용 웹 리서치인가?
• Context7가 더 적합하지 않은가?
• 이미 알고 있는 URL 작업인가?
• 사실상 깊은 조사에 해당하지 않는가?

나쁜 출력의 상당수는 검색 실패가 아니라 라우팅 실패입니다.

첫 패스는 좁게, 그다음 반복 개선하기

perplexity를 개선하는 가장 좋은 방법은 대개 아래 순서입니다.

1. 작은 검색부터 실행한다
2. 관련성을 확인한다
3. 질의를 다듬는다
4. 그다음에만 범위를 넓힌다

처음부터 넓게 시작하는 것보다 낫습니다. 출처가 더 깔끔해지고, 무엇이 빠졌는지 파악하기도 쉬워집니다.

빠진 차원을 추가해 질의 다듬기

첫 결과가 약하다면 아래 요소를 하나 이상 추가해 보세요.

• 날짜 범위
• 지역
• 대상 독자
• 출처 유형
• 기술 깊이
• 비교 대상

예시 개선:

• first pass: “search AI eval frameworks”
• improved: “Search for recent engineering-focused AI evaluation frameworks for LLM apps, emphasizing production monitoring and offline eval.”

출처 품질은 명시적인 선호로 끌어올리기

신뢰도가 중요하다면 분명히 말하세요.

• 공식 회사 엔지니어링 블로그 우선
• 의견 글보다 구현 가이드 우선
• 최신 출처 우선
• 가능하면 vendor landing page 제외

이런 지정은 단순히 “더 많은 결과를 달라”고 하는 것보다 품질에 훨씬 큰 영향을 줍니다.

언제 perplexity를 넘어서 상위 단계로 가야 하는지 알기

아래가 필요하다면:

• 많은 하위 주제를 아우르는 폭넓은 종합
• 여러 라운드에 걸친 증거 수집
• 빠른 발견이 아니라 리서치 메모 수준의 산출물

이때는 perplexity skill에서 Researcher agent로 넘어가세요. 잘 쓰는 방법에는 가벼운 도구를 언제 더 밀어붙이지 말아야 하는지 아는 것도 포함됩니다.

유지보수 중이라면 로컬에서 skill 개선하기

저장소를 직접 수정하고 있다면, 가장 효과적인 개선은 아래와 같습니다.

• Search와 Ask 각각에 대한 완성형 프롬프트 예시 1~2개 추가
• Perplexity Ask도 Search와 같은 수준으로 구체적으로 문서화
• “search / ask / research / not Perplexity”를 한눈에 보는 짧은 결정 표 추가
• 나쁜 질의 하나와 그 개선 버전 하나를 함께 제시

이런 추가는 일반론적인 설명을 더 늘리는 것보다 훨씬 빠르게 모호함을 줄여 줍니다.