제 눈으로 보고, AI에게 물어봅니다.
Try Demo를 공개하고 5일. 새 기능이 아니라 버그 수정이 대부분이었다. 혼자 테스트할 때는 안 보였던 것들이, 실제 사용자의 URL이 들어오자마자 하나씩 터지기 시작했다. 버그가 터질 때마다 기분이 나쁘지 않았다 — 쓰는 사람이 있다는 뜻이었으니까.
🔍 LLM Radar로 내 브랜드 지금 바로 확인해보기
공개 직후 3일간 스캔이 45회 쌓였다는 건 14화에서 썼다.
그 45회 안에는 내가 테스트할 때 한 번도 써본 적 없는 URL들이 있었다. 관상 테스트 서비스, 미디어 회사, 개인 블로그, 네이버 블로그, Tistory. 도메인이 .space도 있었고 .kr도 있었고, 브랜드명이 두 글자인 서비스도 있었다.
개발할 때는 주로 voidops.space나 내가 아는 영문 서비스들로만 테스트했다. 당연히 거기서는 잘 됐다.
다른 URL들이 들어오자마자 뭔가 이상하다는 게 보이기 시작했다.
가장 먼저 발견된 건 브랜드명 추출 오류였다.
사용자가 brandname.com을 입력하면, Perplexity에게 던지는 질문이 이렇게 생성됐다:
“brandname란 무엇인가요?”
브랜드의 실제 이름이 아니라 도메인에서 TLD를 뺀 문자열이 그대로 들어갔다. 규칙 기반으로 “도메인 앞부분 = 브랜드명”이라고 가정했기 때문이었다.
네이버 블로그 URL(blog.naver.com/someone)을 입력한 케이스가 있었다. 추출된 브랜드명은 blog였다. “blog란 무엇인가요?”라는 질문이 Perplexity로 날아갔고, 당연히 아무 의미 없는 결과가 돌아왔다.
og:site_name과 <title> 태그를 먼저 파싱하도록 바꿨다. 그러면 대부분의 사이트에서는 실제 서비스명을 잡아낼 수 있었다.
그런데 HTML 파싱이 늘어나면서 새 문제가 생겼다. 사이트를 두 번 fetch하고 있었다. 브랜드명 추출에 한 번, 질문 생성에 또 한 번. 동일한 페이지를 중복으로 가져오는 낭비였다. 한 번만 fetch해서 재사용하도록 바꿨다.
솔직히 이건 처음부터 그렇게 짰어야 했다. 혼자 테스트할 때는 속도를 체감하기 어려워서 그냥 넘어간 것이었다.
detect_mention 로직의 문제였다.
Perplexity가 “해당 브랜드에 대한 정보를 찾을 수 없습니다”라고 답변해도, 그 안에 브랜드명이 들어가 있으면 언급됐다고 판정했다. 부정 맥락을 걸러내는 패턴이 없었기 때문이었다.
실제로 이런 응답이 들어온 케이스가 있었다:
“OO에 대한 정보를 찾을 수 없습니다. 관련 서비스가 아직 AI 검색 데이터베이스에 포함되어 있지 않은 것 같습니다.”
LLM Radar는 이걸 “언급됨”으로 처리했다. 0%가 나왔어야 할 결과가 100%로 나온 것이다.
부정 패턴 목록을 만들었다. “찾을 수 없”, “정보가 없”, “알 수 없”, “확인할 수 없”, “언급되지 않” 등 20개 이상의 패턴. 브랜드명이 등장한 앞뒤 200자 안에 이 패턴이 있으면 언급 안 됨으로 처리하도록 바꿨다.
HTTP 에러 페이지 케이스도 있었다. 접속이 막힌 사이트를 스캔하면, Perplexity가 “Forbidden”, “Access Denied” 같은 표현을 포함한 응답을 돌려줬다. 이것도 부정 패턴에 추가했다.
이건 한국어 특성 때문이었다.
두 글자 브랜드명이 있다고 하자. LLM Radar는 브랜드명이 너무 짧으면 도메인도 같이 확인하는 로직을 갖고 있었다. 조건이 “2자 이하”로 설정돼 있었다.
한글 2자는 바이트로 6바이트다. 영문 2자는 2바이트다. 같은 “2자 이하” 조건인데, 한글 브랜드명이 죄다 require_domain = True로 처리됐다. 도메인과 별개로 존재하는 한글 브랜드명인데도 도메인 검증을 요구하다 오탐이 났다.
조건을 글자 수가 아니라 바이트 수 기준으로 바꿨다. 영문 2바이트 이하일 때만 도메인 필수 확인. 한글은 해당 없음.
고치고 나서 롤백한 게 하나 더 있었다. 인물 이름이나 역사적 사건이 브랜드명과 겹치는 경우의 오탐 방지 로직을 추가했는데, 오히려 정상 케이스에서 오탐이 늘었다. 결국 되돌렸다. 고치려다 망한 것도 과정이다.
이번 주에 가장 크게 느낀 건 이거다.
내가 테스트하는 URL은 내가 예측 가능한 URL이다. 결과가 어떻게 나올지 알고 있고, 어떤 케이스가 들어올지도 짐작할 수 있다.
실제 사용자는 다르다. 두 글자 한글 브랜드, 네이버 블로그, Tistory, 접근이 막힌 사이트 — 예상 못한 URL이 들어오면서 예상 못한 경로로 코드가 실행됐다.
버그는 항상 그 경로에 있었다.
그런데 이상하게도, 버그가 터질 때마다 기분이 나쁘지 않았다.
버그가 있다는 건 — 쓰는 사람이 있다는 뜻이었다. 스캔 데이터를 보면서 “아, 이 사람 네이버 블로그 URL 넣었구나. 관상 서비스 운영하는 분도 있네.” 싶었다. 내가 만든 걸 누군가 실제로 써주고 있었다.
돈을 안 받고 있어서 다행이었다. 오탐이 나오는 결과를 보고 돈까지 냈다면 미안했을 것 같다. 지금은 버그를 고치면서 조금씩 완성도를 높일 수 있다. 그 여유가 있는 게 좋았다.
공개하고 나서 오히려 열심히 하고 싶어졌다. 공개 전엔 “완성된 다음에 보여줘야지”였는데, 공개 후엔 “쓰는 사람이 있으니까 빨리 고쳐야지”로 바뀌었다. 동기가 달라졌다.
공개를 빨리 하는 게 맞다는 걸 다시 확인했다. 불편하지만.
조치 가이드는 아직 만들지 못했다. 버그 수정에 시간이 다 갔다. 이번 주 안에는 해볼 생각이다.
스캔 결과 화면에 “언급률이 0%입니다. 다음 3가지를 해보세요.” 같은 가이드를 붙이는 것. 숫자만 보여주는 게 아니라, 다음 행동을 안내하는 것.
이게 있어야 LLM Radar가 “결과 보는 도구”에서 “실제로 바꾸는 도구”가 된다.
Q. 같은 URL을 다시 스캔하면 결과가 달라질 수 있나요? 네. Perplexity API는 같은 질문에도 매번 조금씩 다른 응답을 돌려줍니다. 24시간 이내 동일 URL은 캐시된 결과를 보여주고, 그 이후엔 실시간으로 다시 스캔합니다.
Q. 브랜드명이 잘못 추출됐어요. 특히 메타 태그가 없거나 플랫폼 기반 블로그에서 오류가 날 수 있습니다. 오류 사례가 있으면 contact@voidops.space로 알려주시면 직접 수정하겠습니다.
Q. 스캔 결과를 어떻게 개선하면 되나요? 현재 결과 화면에 가이드가 없어서 불편하실 것 같습니다. 조치 가이드를 만들고 있습니다. 급하게 개선이 필요하시면 contact@voidops.space로 메일 주시면 직접 분석해드립니다.
Q. 언급률이 0%가 나왔어요. 왜 그런 건가요? AI가 아직 내 브랜드를 모르는 상태입니다. 랜딩페이지에 서비스 소개 텍스트를 추가하고, schema.org 마크업을 추가하는 것부터 시작할 수 있습니다. 더 구체적인 분석이 필요하면 contact@voidops.space로 메일 주세요.
← 이전 화: LLM Radar 만들기 14화: 공개가 무서웠던 이유
→ 다음 화: 준비 중
비슷한 고민 있으시면 편하게 연락주세요. → contact@voidops.space
작가가 직접 만든 AI 검색 분석 도구 → https://voidops.space/llm-radar/