맨땅에 헤딩하던 개발자가 Perplexity로 실무 리서치 시간을 줄인 이야기

요즘 퇴근하고 집에 오면, 솔직히 손가락 하나 까딱하기 싫은 날이 꽤 많습니다. 마흔 넘어서 그런가요. 예전에는 새벽까지 문서 뒤지고 샘플 코드 돌려보는 것도 나름 재밌었는데, 이제는 체력도 생각해야 하고, 주말에 어디 바람이라도 쐬러 가려면 평일 에너지를 조금은 아껴야 하더라고요. 그런데 회사 일은 참 신기합니다. 내가 좀 쉬고 싶다 싶으면 꼭 새로운 기술 스택이 들어와요. RAG니 Vector DB니 LLMOps니, 이름만 들어도 또 공부할 게 한 보따리입니다.

예전에는 이런 걸 만나면 그냥 구글부터 켰습니다. 검색어 바꿔가며 공식 문서 찾고, 블로그 글 보고, GitHub Issue 뒤지고, Stack Overflow도 몇 번 훑고요. 그런데 어느 순간부터 검색 결과 상단에 광고성 글이나 얕은 요약글이 너무 많이 보이더라고요. 정작 필요한 건 “이걸 실무에 써도 되는가”, “장애가 나면 어디서 터지는가”, “운영 비용은 감당 가능한가” 같은 건데 말이죠. 그러다 최근에 Perplexity를 제대로 써보기 시작했는데, 아, 이건 그냥 검색 대체용 장난감이 아니구나 싶었습니다. 오늘은 제가 개발자 입장에서 Perplexity를 실무 리서치 도구로 어떻게 쓰고 있는지, 그리고 쓰면서 느낀 좋은 점과 조심할 점을 친구한테 얘기하듯 편하게 풀어보려고 합니다.

ChatGPT도 있고 Claude도 있는데, 왜 굳이 Perplexity를 쓰냐고요?

저도 처음엔 똑같이 생각했습니다. “그냥 ChatGPT나 Claude 쓰면 되는 거 아닌가?” 싶었죠. 실제로 코드 초안 만들거나, 복잡한 로직 설명시키거나, 글 구조 잡을 때는 ChatGPT나 Claude가 정말 좋습니다. 특히 Claude는 긴 문맥을 잡고 차분하게 코드 설명해줄 때 꽤 믿음직스럽고요.

그런데 최신 기술 리서치로 넘어가면 얘기가 조금 달라집니다. 예를 들어 어떤 라이브러리가 최근 버전에서 API가 바뀌었는지, 특정 오픈소스가 지금도 활발히 관리되고 있는지, 운영 환경에서 사람들이 어떤 문제를 겪고 있는지 확인하려면 결국 웹에 있는 실제 자료를 봐야 하거든요. 여기서 Perplexity가 꽤 빛납니다. 답변 옆에 출처 링크를 붙여주니까요. 이게 별거 아닌 것 같아도, 실무에서는 엄청 큽니다.

비교 항목	ChatGPT	Claude	Perplexity
제가 주로 쓰는 용도	아이디어 정리, 코드 초안, 문서 초안	긴 코드 리뷰, 설계 설명, 글 다듬기	최신 기술 조사, 출처 기반 비교, 팩트 체크
최신 정보 확인	가능은 하지만 답변 검증이 필요함	학습 데이터 한계가 느껴질 때가 있음	웹 검색 기반이라 최신 자료 추적에 강함
출처 확인	링크가 애매하거나 확인이 필요한 경우가 있음	기본적으로 출처 중심 도구는 아님	답변과 함께 출처를 바로 확인하기 좋음
실무 리서치 만족도	좋지만 최신성 검증이 귀찮음	깊이 있는 설명은 좋음	자료 찾는 시간을 확 줄여줌

제 느낌으로 말하면, ChatGPT나 Claude는 “옆자리 똑똑한 동료”에 가깝고, Perplexity는 “인터넷 자료를 대신 뒤져서 책상 위에 착착 정리해주는 리서치 비서”에 가깝습니다. 둘 중 뭐가 더 좋다기보다는 쓰임새가 다릅니다. 저는 코드 짤 때는 ChatGPT나 Claude를 많이 쓰고, 기술 선택 전에 자료를 모을 때는 Perplexity를 먼저 켭니다. 이 흐름이 꽤 괜찮더라고요.

실무에서 제일 도움 됐던 사례: Vector DB 비교 리서치

최근에 사내에서 AI 기반 검색 기능을 붙이는 프로젝트가 있었습니다. 흔히 말하는 시맨틱 검색 쪽이었고, 후보로는 pgvector, Milvus, Qdrant 정도가 올라왔습니다. 여기서 문제는 늘 그렇듯 시간이었습니다. “다음 회의 때까지 대략적인 비교 자료 좀 볼 수 있을까요?” 이런 말, 개발자분들은 익숙하시죠. 말은 대략인데, 막상 회의 들어가면 꽤 구체적인 질문이 날아옵니다.

예전 같으면 각 프로젝트 공식 문서 들어가고, GitHub 저장소에서 최근 커밋 보고, Issue 탭에서 장애 사례 읽고, Reddit이나 Hacker News 반응까지 살폈을 겁니다. 그러면 하루가 훅 갑니다. 집중 잘 되는 날도 반나절은 그냥 사라져요. 그런데 이번에는 Perplexity를 API로 붙여서 작은 리서치 스크립트를 만들었습니다. 거창한 건 아니고, 반복해서 물어볼 내용을 코드로 정리해둔 정도입니다.

제가 대충 이렇게 폴더를 잡았습니다. 사실 이런 작은 도구도 폴더를 나눠두면 나중에 또 써먹기 좋습니다. 저는 이런 걸 개인적으로 “퇴근 시간을 지켜주는 잡동사니 도구함”이라고 부릅니다.

tech-research-agent/
├── config/
│   └── settings.py
├── core/
│   ├── perplexity_client.py
│   └── report_generator.py
├── output/
│   └── vector_db_comparison_report.md
├── requirements.txt
└── main.py

핵심은 perplexity_client.py 쪽입니다. 아래 코드는 제가 실험용으로 만들었던 형태를 조금 다듬은 버전입니다. 실무에서는 API Key를 환경 변수로 빼고, 에러 처리도 조금 더 꼼꼼히 해야 합니다. 그래도 전체 흐름은 이 정도면 충분히 감이 오실 거예요.

import requests
import os

class PerplexityClient:
    def __init__(self):
        self.api_key = os.getenv("PERPLEXITY_API_KEY")
        self.url = "https://api.perplexity.ai/chat/completions"
        self.headers = {
            "Authorization": f"Bearer {self.api_key}",
            "Content-Type": "application/json"
        }

    def fetch_tech_research(self, topic: str) -> str:
        payload = {
            "model": "sonar-pro",
            "messages": [
                {
                    "role": "system",
                    "content": (
                        "You are a senior backend architect. "
                        "Compare technologies using official docs, GitHub repositories, "
                        "real-world production cases, and recent community discussions. "
                        "Focus on performance, scaling, self-hosting complexity, "
                        "operational risks, and long-term maintenance."
                    )
                },
                {
                    "role": "user",
                    "content": (
                        f"Compare {topic}. "
                        "Give me a practical recommendation for a startup backend team. "
                        "Include citations and explain what can go wrong in production."
                    )
                }
            ],
            "temperature": 0.2,
            "max_tokens": 2500
        }

        response = requests.post(self.url, json=payload, headers=self.headers, timeout=60)
        response.raise_for_status()

        result = response.json()
        return result["choices"][0]["message"]["content"]

여기서 제가 일부러 넣은 문장이 있습니다. “what can go wrong in production” 이 부분입니다. 이게 꽤 중요해요. 많은 AI 답변이 장점 위주로 예쁘게 정리되는데, 실무에서 진짜 필요한 건 “도입하면 어디서 피곤해질까?”거든요. 운영 중 메모리 튀는지, 백업은 쉬운지, 클러스터 구성하다가 삽질할 가능성이 있는지, 장애 났을 때 팀원이 감당할 수 있는지. 이런 게 회의에서 훨씬 더 중요하게 먹힙니다.

당시 제가 뽑아본 비교 결과는 대략 이런 식이었습니다. 물론 실제 의사결정은 내부 인프라 상황과 팀 역량까지 같이 봐야 합니다.

후보	좋았던 점	걱정됐던 점	제 판단
pgvector	PostgreSQL 안에서 바로 쓸 수 있어서 운영 부담이 낮음	대규모 벡터 검색 전용 엔진만큼 확장성이 좋다고 보긴 어려움	초기 MVP나 데이터 규모가 작은 팀에 현실적
Qdrant	API가 깔끔하고 Rust 기반이라 성능 기대감이 좋음	운영 경험이 없는 팀이면 백업, 모니터링 설계를 따로 챙겨야 함	전용 Vector DB를 쓰고 싶다면 꽤 균형 잡힌 선택
Milvus	대규모 검색과 분산 환경 쪽 자료가 풍부함	구성 요소가 많아서 작은 팀에는 운영 부담이 크게 느껴질 수 있음	규모가 커질 게 확실한 조직에 더 어울림

이런 식으로 초안을 뽑아두고, 출처 링크를 열어보면서 공식 문서와 GitHub 상태를 다시 확인했습니다. 완전히 AI에게 맡기진 않았어요. 저는 이게 중요하다고 봅니다. AI가 대신 결정하게 두는 게 아니라, 내가 결정할 시간을 벌어주는 도구로 쓰는 겁니다. 이 차이를 놓치면 위험합니다.

Perplexity 프롬프트는 “질문”보다 “검증 기준”이 더 중요하더라고요

처음에는 저도 그냥 이렇게 물었습니다. “Qdrant랑 Milvus 비교해줘.” 그러면 답이 나오긴 나옵니다. 그런데 좀 밍밍해요. 누구나 할 수 있는 말이 섞입니다. “Qdrant는 가볍고 Milvus는 확장성이 좋습니다” 같은 답변이요. 틀린 말은 아닌데, 회의에 가져가긴 약합니다. 개발자가 원하는 건 그보다 더 구체적인 근거잖아요.

몇 번 삽질하다 보니 요령이 생겼습니다. Perplexity에는 단순 질문보다 판단 기준을 같이 던지는 방식이 훨씬 잘 먹힙니다.

운영 기준을 넣기: “Kubernetes 환경에서 운영할 때 백업, 모니터링, 장애 대응 관점으로 비교해줘.”

팀 규모를 넣기: “백엔드 개발자 4명, DevOps 전담 인력 없음, 월 100만 건 이하 검색 요청 기준으로 추천해줘.”

출처를 강제하기: “공식 문서, GitHub Issue, 최근 1년 내 커뮤니티 논의를 출처로 나눠서 표로 정리해줘.”

반대 의견을 요구하기: “추천하지 않는 이유도 같이 써줘. 특히 도입 후 후회할 수 있는 상황을 알려줘.”

버전 기준을 박아두기: “2025년 현재 기준으로 최근 버전의 기능과 운영 이슈를 확인해줘.”

제가 자주 쓰는 프롬프트는 이런 느낌입니다.

우리 팀은 백엔드 개발자 4명이고, DevOps 전담 인력은 없습니다.
Kubernetes는 사용하지만 복잡한 분산 시스템 운영 경험은 많지 않습니다.

Qdrant, Milvus, pgvector를 다음 기준으로 비교해 주세요.

1. 초기 구축 난이도
2. 운영 중 장애 가능성이 높은 지점
3. 백업과 복구 난이도
4. 검색 성능보다 유지보수 관점의 장단점
5. 최근 1년 내 GitHub Issue나 공식 문서에서 확인되는 주요 변화

답변 마지막에는 출처를 공식 문서, GitHub, 커뮤니티 글로 나눠 표로 정리해 주세요.
괜히 중립적으로 말하지 말고, 우리 팀 상황에 맞는 선택지를 하나 추천해 주세요.

여기서 포인트는 “괜히 중립적으로 말하지 말고”입니다. AI 도구들은 기본적으로 안전하게 말하려는 경향이 있습니다. “상황에 따라 다릅니다”라는 말, 맞긴 맞죠. 그런데 매번 그 말만 들으면 사람이 지칩니다. 저는 그래서 일부러 선택을 요구합니다. 물론 그 선택을 그대로 믿지는 않고, 왜 그렇게 판단했는지 근거를 봅니다.

그래도 Perplexity를 100% 믿으면 안 됩니다

이 얘기는 꼭 하고 싶습니다. Perplexity가 출처를 잘 보여준다고 해서 답변이 무조건 맞는 건 아닙니다. 검색 기반이라 오히려 생기는 문제가 있어요. 인터넷에 틀린 글이 많으면, 그 틀린 글을 그럴싸하게 요약해줄 수도 있습니다. 저는 이걸 혼자 검색 기반 환각이라고 부릅니다. 영어로는 Search Hallucination이라고 해도 될 것 같고요.

실제로 한 번은 특정 라이브러리의 deprecated 옵션을 찾다가 Perplexity 답변만 보고 설정을 넣었는데, 막상 최신 버전에서는 동작이 달랐습니다. 출처를 눌러보니 오래된 블로그 글이었고, 공식 문서는 이미 바뀌어 있더라고요. 순간 좀 허탈했습니다. “아, 역시 사람 손이 마지막엔 들어가야 하는구나.” 싶었죠.

그래서 저는 Perplexity로 리서치할 때 작은 체크리스트를 씁니다. 별거 아닌데 습관 들이면 삽질을 꽤 줄여줍니다.

공식 문서 링크가 있는지 먼저 본다. 없으면 답변 신뢰도를 낮게 잡습니다.

GitHub Issue는 날짜를 꼭 확인한다. 3년 전 이슈는 지금 상황과 다를 수 있습니다.

개인 블로그만 근거로 삼지 않는다. 경험담은 좋지만, 최종 판단 근거로는 약합니다.

버전 번호를 확인한다. 특히 SDK, ORM, 클라우드 서비스는 버전 차이가 큽니다.

운영 관련 주장은 한 번 더 검색한다. 장애, 비용, 성능 이야기는 반드시 교차 검증합니다.

저는 이걸 더블 체크 룰이라고 부릅니다. Perplexity가 답을 주면, 답변 자체보다 옆에 붙은 출처를 먼저 봅니다. 공식 문서인지, GitHub인지, 신뢰할 만한 기술 블로그인지 확인하고요. 이 과정이 귀찮아 보여도 구글 검색으로 처음부터 헤매는 것보다는 훨씬 빠릅니다. 뭐랄까, 예전에는 산 전체를 뒤졌다면 이제는 지도에 표시된 지점만 확인하는 느낌입니다.

API로 붙일 때 은근히 놓치기 쉬운 부분

웹에서 직접 쓰는 Perplexity도 좋지만, 실무에서는 API로 붙여두면 반복 작업에 꽤 쓸만합니다. 다만 몇 가지 조심할 점이 있습니다. 특히 회사 비용으로 쓰거나 CI 같은 자동화 흐름에 넣을 때는 더 그렇습니다.

주의할 점	제가 겪은 느낌	대처 방법
비용	긴 리서치를 여러 번 돌리면 생각보다 빨리 쌓입니다.	토큰 제한을 걸고, 초안 리서치와 정밀 리서치를 나눕니다.
응답 시간	웹 검색이 들어가다 보니 일반 LLM 호출보다 늦을 수 있습니다.	timeout을 넉넉히 잡고, 재시도 로직을 둡니다.
출처 품질	가끔 오래된 글이나 얕은 글이 섞입니다.	공식 문서 우선, 최신 날짜 우선으로 재질문합니다.
사내 정보 유출	무심코 내부 서비스명이나 장애 로그를 넣기 쉽습니다.	민감한 값은 익명화하고, 사내 정책을 먼저 확인합니다.

특히 사내 정보는 정말 조심해야 합니다. “에러 로그 좀 넣고 물어보면 빠르겠지” 하다가 내부 도메인, 고객 ID, 토큰 비슷한 값이 섞일 수 있거든요. 저는 그래서 외부 AI에 넣기 전에 로그를 한 번 정리합니다. 서비스명은 service-a, 고객 식별자는 user-123 이런 식으로 바꾸고요. 좀 귀찮지만, 이건 습관의 영역입니다. 나중에 사고 나는 것보다 백 배 낫습니다.

여행 계획 짤 때도 비슷하게 쓰고 있습니다

제가 여행 좋아한다고 앞에서 살짝 얘기했죠. 사실 Perplexity는 개발 리서치뿐 아니라 여행 계획 세울 때도 꽤 유용했습니다. 물론 이 글의 중심은 개발 실무 이야기라 길게 엮고 싶진 않은데, 리서치라는 관점에서는 묘하게 닮아 있습니다. 낯선 도시에서 좋은 식당 찾는 것도, 낯선 기술 스택에서 믿을 만한 선택지를 찾는 것도 결국 “자료를 모으고, 걸러내고, 내 상황에 맞게 판단하는 일”이니까요.

얼마 전 오키나와에 3박 4일로 다녀올 일이 있었습니다. 나하 공항에서 렌터카를 빌려서 북부 쪽까지 올라가야 했는데, 이동 동선이 은근히 애매했습니다. 그때 이렇게 물어봤습니다.

오키나와 나하 공항에서 출발해서 츄라우미 수족관까지 렌터카로 이동할 예정입니다.
중간에 들를 만한 로컬 식당을 추천해 주세요.

조건은 아래와 같습니다.
구글 맵 평점 4.3 이상
주차가 비교적 편한 곳
너무 관광객 전용 느낌이 아닌 곳
이동 동선에서 크게 벗어나지 않는 곳
최근 후기를 확인할 수 있는 곳

이렇게 물어보니 단순히 맛집 이름만 던져주는 게 아니라, 동선과 주차 여부, 최근 후기 분위기를 같이 정리해줘서 편했습니다. 물론 여기도 똑같습니다. 마지막에는 구글 맵을 직접 열어서 영업시간과 휴무일을 확인해야 합니다. AI가 아무리 똑똑해도 가게 문 닫은 날 앞에서 멍하니 서 있는 건 결국 제 몫이니까요. 그런 경험, 한 번쯤 있으시잖아요.

Perplexity를 개발자 리서치에 쓸 때 제일 좋은 흐름

제가 요즘 제일 자주 쓰는 흐름은 이렇습니다. 거창한 방법론은 아닙니다. 그냥 몇 번 삽질하면서 손에 붙은 방식입니다.

처음에는 넓게 묻습니다. “이 기술이 뭔지”보다 “어떤 상황에서 쓰고, 어디서 조심해야 하는지”를 묻습니다.

그다음 비교 기준을 좁힙니다. 성능, 비용, 운영 난이도, 팀 역량 같은 기준을 넣습니다.

출처를 확인합니다. 공식 문서와 GitHub를 먼저 보고, 블로그는 참고 자료로 봅니다.

반대 질문을 던집니다. “왜 이 기술을 쓰면 안 되는가?”를 꼭 물어봅니다.

최종 결정은 사람이 합니다. AI 답변은 판단 재료이지, 결재권자가 아닙니다.

이 방식이 좋은 이유는 리서치 시간이 확 줄어든다는 겁니다. 예전에는 자료를 찾는 데 힘을 다 쓰고, 정작 판단할 때는 지쳐 있었습니다. 요즘은 Perplexity로 1차 자료를 모으고, 저는 그 자료가 맞는지 확인하면서 판단에 집중합니다. 이게 생각보다 차이가 큽니다. 퇴근 시간이 30분만 빨라져도 기분이 다르잖아요. 괜히 집에 가는 길에 커피 한 잔 사 마시고 싶어지고요.

이런 분들이 쓰면 특히 만족도가 높을 겁니다

Perplexity는 새로운 기술을 빠르게 훑어봐야 하는 개발자에게 꽤 좋은 도구입니다. 특히 공식 문서, GitHub Issue, 최근 커뮤니티 반응을 한 번에 보고 싶은 분들께 잘 맞습니다. 시니어 개발자나 아키텍트처럼 기술 선택의 근거를 빨리 정리해야 하는 분들에게도 좋고, 맨땅에 헤딩하면서 도메인 지식을 흡수해야 하는 주니어 개발자에게도 도움이 됩니다.

다만 너무 믿고 맡기면 안 됩니다. 이건 정말 제 주관이 뚜렷한 부분인데요. AI 도구는 내 머리를 대체하는 물건이 아니라, 내 시간을 아껴주는 물건에 가깝습니다. Perplexity가 찾아준 자료를 보고, 출처를 확인하고, 내 팀 상황에 맞게 판단하는 건 여전히 개발자의 몫입니다. 그 선만 잘 지키면, 구글 검색창에서 광고 글 넘기느라 지치는 시간을 꽤 많이 줄일 수 있습니다.

저처럼 퇴근 후 체력은 예전 같지 않은데, 그래도 새 기술은 계속 따라가야 하는 40대 개발자라면 한 번 써보셔도 좋겠습니다. 젊은 개발자분들도 마찬가지고요. 자료 찾는 데 모든 에너지를 쓰지 말고, 판단하고 만드는 데 에너지를 남겨두는 것. 요즘 제가 AI 도구를 쓰면서 가장 크게 느끼는 방향입니다. 남는 시간에는 코드 한 줄 더 잘 짜도 좋고, 저처럼 훌쩍 바람 쐬러 나가도 좋고요. 뭐, 결국 오래 개발하려면 그런 숨 쉴 틈도 필요하니까요.

👨‍💻

작성자: 20년 경력 IT 전문 아키텍트

실무 개발과 아키텍처 설계를 거쳐 현재는 AI 바이브 코딩과 개발 자동화를 연구하고 있습니다. 직접 삽질하며 깨달은 실전 꿀팁과 에러 극복 사례만 투명하게 공유합니다.

🔍 관련 정보 더 보기

Iros

이 블로그 검색

Featured Post