요약
딥시크가 웹 검색 API와 페이지 수집 API를 성공한 요청 1000건당 0.75달러에 내놓았습니다.
딥시크가 API 문서에 Search API와 Fetch API 안내를 새로 올렸습니다. AI 에이전트와 RAG(검색한 자료를 근거로 답을 만드는 방식) 앱이 실시간 웹 내용을 가져다 쓰게 하려는 서비스입니다.
왜 중요한가
- HN 댓글의 비교로는 Brave Search API(5달러), Kagi API(12달러)보다 1000건당 값이 훨씬 쌉니다.
- 결과가 없거나 실패한 요청은 돈을 받지 않아, 결과를 얻은 요청에만 돈을 냅니다.
- Claude Code나 Codex로 딥시크 모델을 쓰면 이미 이 API가 서버에서 호출되고, 11월 1일부터 과금이 시작됩니다.
핵심 내용
- Search API는 딥시크 자체 검색 엔진으로 결과를 찾아 한 번에 최대 50건을 돌려줍니다.
- Fetch API는 웹 페이지 하나를 받아 마크다운으로 바꿔 줍니다.
- 값은 요청 단위로 매기며, 돌려받는 결과 개수는 값에 영향을 주지 않습니다.
- site:, lang:, after: 같은 검색 연산자와 결과별 관련도·권위 점수를 지원합니다.
- 계정당 초당 5건까지 부를 수 있고, Fetch에는 도메인별 제한이 더 붙습니다.
HN 반응
- SearXNG(직접 운영하는 메타 검색 엔진) 같은 무료 도구면 충분하다는 의견에, 금방 접속 차단에 걸려 결국 유료 API로 옮겼다는 경험담이 여럿 달렸습니다.
- 구글이 유료 검색 API를 내놓지 않아 이런 서비스가 생긴다는 지적이 나왔고, 회사 기밀이 걸린 일에는 딥시크를 믿기 어렵다는 의견도 있었습니다.
이런 호스팅 검색 서비스를 다들 실제로 어디에 쓰는 건가요? 개인적으로는 searxng-ai-kit 1(밝혀 두자면 제가 만든 겁니다)이나 비슷한 도구를 쓰는 쪽이 훨씬 가성비가 좋더라고요. 무료니까요! oh-my-pi도 비슷한 방식이라 API 키나 검색 서비스 없이 바로 검색 결과를 긁어다 줍니다.
지연 시간을 안정적으로 보장받고 싶고 데이터 처리 보증이 필요한 조직(회사 기밀이 새는 큰 경로이니까요)이라면 말씀하신 방식 대신 이런 검색 서비스를 씁니다.
특히 코딩과 달리 채팅형 용도에서는 지연 시간이 훨씬 중요합니다. 간단한 질문 하나를 던지는 경우라면 더 그렇습니다. 다른 축으로 보면, 웹 검색 10회 이상에 웹 페이지 가져오기 100회 이상을 쏟아붓는 딥 리서치 작업에서는 스크래핑의 안정성이 중요합니다.
예를 들어 저희 채팅 플랫폼0에서는 웹 검색1과 웹 접근2용 자체 MCP 서버를 제공하고 이것도 꽤 쓸 만하게 동작하지만, 비용보다 품질을 우선하는 고객 일부는 LinkUp3 같은 전문 서비스를 선택합니다.
이게 회사 기밀 보호에 어떻게 도움이 되는지 설명해 주실 수 있나요? 지식재산을 비밀로 지키려면 Deepseek의 API 같은 걸 직접 쓰는 건 좋지 않고, 로컬에서 호스팅하는 게 모범 사례일 것 같은데요.
저도 회사 기밀을 Deepseek에 맡기지는 않을 겁니다. 그래서 LinkUp을 링크한 거고요. 저희 고객 몇 곳에서 꽤 엄격한 컴플라이언스 심사를 통과한 것으로 알고 있습니다.
검색 부분만 보면 검색 색인을 로컬에서 호스팅하는 게 당연히 모범 사례입니다. 하지만 최신 상태의 색인을 유지하려면 보통 상당한 하드웨어 비용과 운영 복잡도가 따릅니다. 이 분야에서 좋은 자체 호스팅 옵션은 제가 아는 게 없는데, 경험 있으신 분이 계시면 꼭 듣고 싶습니다! 제가 알기로 LinkUp 같은 몇몇 업체가 프라이빗 클라우드나 온프레미스 배포를 제공하긴 하지만, 대부분 가장 큰 고객 위주인 것 같습니다.
웹 페이지 가져오기(접근) 부분은 본질적으로 실시간이라 로컬 배포 안에 가둘 수 없습니다(인터넷 아카이브/Wayback Machine 전체를 직접 호스팅하지 않는 한 말이죠. 그건 훨씬 더 큰 일입니다). 이 경우 유출을 막을 수 있는 주된 방법은 도메인 허용 목록(가능하다면), 쿼리 매개변수 제거(실수하기 쉽고 100% 보장도 안 됩니다), 또는 클라이언트(예: 저희 도구)를 사용자가 해당 도구 호출을 명시적으로 허용해야 하고 위험도 안내받도록 설정하는 것입니다. 저희는 기밀로 표시된 오피스 문서가 컨텍스트에 들어오면 특정 도구를 완전히 꺼 버리는 시스템도 만들고 있습니다.
기밀 보호 요구 수준이 가장 높다면, 웹 검색/접근 기능이 아예 없는 망분리 시스템이 당연히 궁극의 해법입니다.
검색 스텁(stub), 그러니까 LLM이 가져올 수 있는 짧은 문서를 저장해 두고, 이걸로 여러 웹사이트, 자료, 피드, 포럼, 블로그, 다른 전문 검색 엔진, API로 안내하게 하면 안 될까요? 30GB짜리 모델을 호스팅한다면 압축된 검색 스텁 색인에 30GB를 더 쓸 수 있잖아요. 어떤 분야든 진입점은 개별 페이지보다 훨씬 덜 바뀝니다. 에이전트가 필요에 따라 그 자료들을 돌아다니며 최신 데이터를 가져오게 하면 됩니다.
엄밀히는 검색이 아니지만 대부분의 검색을 대체할 수 있습니다. 검색을 위한 라우터이고, 실시간 상호작용은 로컬 에이전트가 맡는 구조입니다. 실시간 작업을 로컬 에이전트가 하니 프라이버시도 최대한 지켜집니다. 로컬 스텁 색인이 관심 주제를 다루지 못하면 claude/codex/gemini 같은 코딩 에이전트로 조사해서 빠진 스텁을 만들어 넣으면 됩니다.
듣고 보니 꽤 논리적이네요.
좋은 생각이네요. 게다가 팀이 특정 문제 영역에서 일한다면 팀원들의 검색은 서로 반복되거나 상당 부분 겹칠 가능성이 높습니다. 로컬에 호스팅한 에이전트가 있다면 거기서 더 나아가 해당 검색 결과를 캐싱하고(신선도, 관련성, 정확도를 기록해 두고) RAG 비슷한 사내 검색 포털을 만들 수도 있을 것 같습니다.
완전히 망분리된 상태로 자체 호스팅하면서 콘텐츠 캐시(archive.org 같은)까지 접근할 수 있는 웹 색인을 제공하는 곳은 Diffbot뿐일지도 모릅니다. 저는 여기서 일하고 있고, 작동 방식을 기꺼이 더 알려 드리겠습니다!
경쟁사와 비교한 정확도를 홈페이지에 그대로 내걸고 계시네요. 솔직히 인상적입니다.
이 콘셉트 정말 마음에 들어요! 웹을 "배에 싣고" 떠나는 거죠 :)
저라면 데이터를 보호하는 데가 아니라 유출을 찾아내는 데 쓰겠어요.
searxng 인스턴스를 돌려 봤는데, 실제 검색 제공업체 API와 비교해 보고는 쓰기를 그만뒀습니다.
searxng은 금방 속도 제한에 걸리고, 그 순간 접근 가능한 제공업체가 어디냐, 캡차에 막히지 않았느냐에 따라 결과도 들쭉날쭉합니다.
그런데 넉넉한 무료 구간을 주는 제공업체가 여럿 있으니, 굳이 LLM에 열등한 데이터를 먹일 이유가 없죠.
샘플 기술 검색 몇 개를 두고 어떤 쪽 결과를 선호하는지 LLM에게 직접 물어보는 나란히 비교 테스트도 몇 번 해 봤어요. Exa와 tavily가 1위, brave가 2위, searx는 꼴찌였습니다.
저도 속도 제한에 금방 걸렸어요. 그러다 SerpAPI 키가 있다는 걸 깨달았죠. SearXNG이 이걸 지원하는지 확인해 봤더니... 안 하더라고요. 이상한 일이에요.
(searxng은 금방 속도 제한에 걸리고, 그 순간 접근 가능한 제공업체가 어디냐, 캡차에 막히지 않았느냐에 따라 결과도 들쭉날쭉합니다.)
맞아요. SearXNG 얘기를 늘어놓는 사람들은 대체 실제로 뭘 하고 있는 건지 정말 궁금해요. 제가 겪은 것도 똑같거든요. 가정용 IP인데도 Google 검색을 몇 번 하면 바로 차단당합니다. 동시에 여러 검색을 돌리면 Bing이나 Brave도 금방 막아 버리고요. 제 집 IP는 SearXNG을 통한 Brave Search 이용이 아예 영구 차단된 모양이에요.
그리고 Google/Bing/Brave에서 결과를 못 받으면 에이전트 입장에서는 순식간에 상황이 나빠집니다. 에이전트 검색을 완전히 자체 호스팅으로 하고 싶었지만, 잘 안 돼요.
네, 저도 같은 문제를 겪었어요. 결국 Brave와 Exa에 돈을 내기로 했습니다. 제 사용량 기준으로는 정말 여기저기 몇 달러 나가는 수준이라 전혀 고민할 거리도 아니에요. AI를 많이 쓰긴 하지만 자체 호스팅 AI라서, 그래도 사용량이 걱정할 정도는 아닙니다. 웹을 스크래핑하거나 그런 걸 하려는 건 아니고요.
저는 직접 검색 엔진을 만들었는데, 참고로 이게 정말 훌륭합니다. 자체 호스팅으로 쓰고 있고요.
유료 검색 제공업체 여러 곳과 API가 없는 몇 곳을 묶어 놨습니다. API가 없는 쪽은 일반 HTML 페이지를 스크래핑해서 결과를 객체로 돌려주는 래퍼를 직접 작성했어요.
이렇게 감싼 검색 제공업체들은 속도 제한이나 제 서버 IP 차단으로 엔진이 결과를 못 받게 막는 일이 아주 잦습니다.
사용자가 저 하나뿐인데도 차단당합니다. 같은 사무실 IP에서 여러 사람이 하루 종일 DuckDuckGo를 쓰거나, 조회가 많이 필요한 긴 리서치 세션을 돌린다면 말할 것도 없겠죠.
뻔한 해결책은 자동으로 로테이션되는 프록시나 일종의 캡차 우회 시스템을 쓰는 건데, 에이전트라면 괜찮겠지만 검색 엔진 시나리오에서는 지연 시간 때문에 비용이 너무 커질 수도 있습니다.
(사용자가 저 하나뿐인데도 차단당합니다.)
놀랍지도 않네요. 요즘 Google은 수십 년 된 Google 계정을 가진 사람인 저한테도 툭하면 차단을 걸거든요.
SEO는 큰 사업이고 앞으로는 에이전트가 검색을 주도할 가능성이 높으니, 언젠가 검색 API 가격이 마이너스가 되는 걸 보게 될지도 모르겠어요.
그러니까 경쟁사 대신 자기네 API를 쓰라고 제공업체가 오히려 돈을 주는 거죠. 그러면 누가 인터넷에서 영향력을 가질지를 자기들이 쥐게 되니까요. 특정 쿼리에서 상위에 노출해 주겠다며 사이트들에게 돈을 받아낼 수도 있을 테고요.
@DeepSeek 팀 여러분, 다음 LLM 시리즈는 출처 인식 학습(source-aware training)으로 훈련해 보시면 어떨까요?
https://arxiv.org/abs/2404.01019
LLM이 질문에 답하면서 어떤 사실, 가정, 추론이 기존 연구에서 나온 것인지(이 URL, 저 책 등) 정확히 구분해 주고, 어떤 부분이 모델 자신의 추론이거나 사용자의 것인지도 짚어 줄 수 있게 될 겁니다.
사람도 자기 지식의 상당 부분은 출처를 댈 수 없다는 점이 눈에 띕니다. 예를 들어 "garden(정원)"이라는 단어의 뜻을 언제, 어디서, 누구에게서 배웠는지 말해 보세요.
"garden"이라는 단어를 이해하게 된 건 아마 서로 다른 맥락에서 그 단어를 5번 넘게 만나면서일 텐데, 그걸 따로따로 분리해 낼 수는 없습니다. 우리의 이해는 각 경험에서 얻은 지식의 일종의 평균이니까요.
흥미롭게도 park, meadow, yard, grassland처럼 뜻이 인접하거나 겹치는 단어들은 경계를 두고 의견이 갈리는 경우가 많습니다. 어떤 사람은 어떤 곳을 garden이라 부르는데 다른 사람은 meadow라고 부르는 식이죠. 둘 다 왜 하필 그 단어를 골랐는지 정확히 설명하지는 못하지만, 각 단어의 의미를 처음 배운 출처에서 비롯된 것일 수도 있습니다.
이게 바로 촘스키/칸트 이야기, 즉 "자극의 빈곤"과 선천적 구조라는 생각입니다. 단어나 개념을 직접 접해서 "배운" 게 아니라 사회화, 연상, 정서적 연결, 분위기로 익힌 것이니까요. LLM은 어렵게 배우는 것 같고요.
언어의 차이적 성격에 대한 소쉬르의 생각도 여기에 관련이 있어 보입니다. 단어는 찾아보는 사물 목록이 아니라 서로 연결되어 있고, 자신이 속한 군집의 다른 요소들과 조금씩 다름으로써 스스로를 구별합니다.
이런 서비스들은 Google이 유료 검색 API를 제공하길 거부하기 때문에 존재하는 겁니다.
네, 답답한 노릇이에요.
Google은 사실 검색에 관심이 없고 광고와 사용자 프로필 만들기에만 관심이 있다는 사실도 드러납니다.
이건 한 번도 이해된 적이 없어요.
유료 검색 API는 Google에게 쉬운 돈벌이일 것 같은데요. 게다가 온갖 스타트업과 기업을 묶어 두는 락인 효과도 생길 테고요.
검색의 덕을 볼 앱은 정말 많습니다.
광고를 못 띄우게 된다는 건 알아요.
하지만 스스로를 파괴할 각오가 없으면 어차피 결국 잃게 됩니다.
겁먹고 움츠러들기보다는 광고와 API로 돈 버는 방법을 찾아내는 게 낫죠.
그 같은 두려움 때문에 LLM에서도 선두 주자가 되지 못한 건지도 모릅니다.
스스로를 파괴할 각오가 있어야 해요.
그렇긴 해도 저는 10억 달러짜리 회사를 만들어 본 적이 없습니다. 그러니 완전히 탁상공론을 하고 있는 거죠.
Google의 목표는 검색을 제공하는 게 아닙니다. 사람들에 대한 무한한 데이터를 모아 수익화하는 거죠. Google이 검색 API를 내놓으면 자기네 감시 체계가 무너질 겁니다.
맞춤형 광고를 금지했어야 했고, Google도 진작에 반독점법으로 분할됐어야 했습니다.
(광고를 못 띄우게 된다는 건 알아요.)
쿼리에 광고 엔진을 돌려서 광고 수익을 추정하고, 놓치게 될 수익만큼을 사용자에게 청구하면 충분히 해결됩니다.
사용자는 자체 광고를 띄우든 Google 광고 서비스를 쓰든 그 비용을 메울 수 있고요.
와, 정말 좋은 발상이네요.
그래서 스스로를 파괴할 각오가 필요해 보인다는 거예요.
여전히 돈 벌 방법은 많습니다.
그리고 자기 파괴를 피하는 쪽이 장기적으로는 실패 가능성을 높인다는 데 걸겠습니다.
Google은 2002년부터 2016년까지 검색 어플라이언스를 팔았고, 이후 Google Cloud Search로 대체했습니다.
Google이 검색용으로 Vertex를 제공하긴 하는데, 꽤 느려서 비동기 워크로드에나 쓸모가 있을 것 같습니다.
참고로 Brave Search API는 5달러, Kagi API는 12달러입니다.
Ceramic.ai는 1000회 검색당 0.25달러입니다. OpenCode에서 MCP로 써 봤는데 쓸 만한 것 같아요. 이야기하는 사람이 별로 없는데, Exa/Tavilly와 벤치마크를 해 본 적은 없습니다.