Reviewloger 구축 프로젝트 — NAVIRANG과 함께 만든 체험단 통합검색 서비스

Reviewloger(리뷰로거)는 여러 체험단 사이트에 흩어진 공고를 자동으로 수집해 한곳에서 탐색·비교할 수 있도록 NAVIRANG(나비랑)이 기획·개발한 서비스입니다. 이 페이지는 무엇을 어떻게 구축했는지, 그리고 구축 이후 검색엔진과 AI 검색에서 이 서비스가 발견되는 과정을 어떻게 진단하고 개선하고 있는지를 실측 기록 그대로 공개합니다.

Reviewloger란?

Reviewloger는 체험단 사이트 61곳의 공개 모집 공고를 매일 자동 수집해, 네이버 블로그·인스타그램 등 채널별 공고와 맛집·뷰티·생활 등 9개 분야, 시·군·구 단위 지역 공고를 마감임박·경쟁률·새 공고·보상 기준으로 한 화면에서 비교할 수 있게 하는 무료 서비스입니다. 신청·선정·보상은 항상 각 원본 플랫폼에서 진행되며, Reviewloger는 공고를 발견하도록 돕는 역할만 합니다. 서비스 자체에 대한 자세한 설명은 소개이용 방법에 있습니다.

NAVIRANG이 구축한 영역

서비스 기획 · UX

"여러 사이트를 돌아다니지 않고 승산 있는 공고부터 고른다"는 문제 정의에서 출발해, 분야 9종 × 지역(시·도/시·군·구) × 유형(방문형·배송형·기자단·구매형) × 채널의 정보 구조와 검색·필터·정렬 흐름, 카카오톡 새 공고 알림, 다크모드까지 설계했습니다. 성능도 설계 대상이었습니다 — PageSpeed Insights 실측 데스크톱 100점, 모바일 99점 (측정 대상: 홈 reviewloger.com, 2026-07-27 측정 — 점수는 측정 시점의 값이며 변동될 수 있습니다).

웹서비스 개발

전 페이지 서버 렌더링(SSR) 구조로 개발해 엣지 네트워크(Cloudflare Workers)에서 서비스하고, 수집 데이터는 PostgreSQL(Supabase)에 저장합니다. 모든 핵심 콘텐츠가 JavaScript 실행 없이 원시 HTML에 담기므로, 사용자·검색엔진·AI 크롤러가 같은 내용을 봅니다.

자동 체험단 크롤링 시스템

체험단 플랫폼 61곳 각각에 맞춘 수집 어댑터를 구축했습니다. 플랫폼마다 구조가 달라(서버 렌더링 HTML, 공개 JSON API, 스크립트 렌더링 화면 등) 수집 방식을 사이트별로 맞추되, 공통 원칙을 강제합니다:

  • 수집 윤리 — 각 사이트의 robots.txt(수집 허용 범위)를 요청 시점마다 검사해 준수하고, 수집 중단 요청(opt-out)은 다음 회차부터 즉시 반영합니다.
  • 정규화 — 공고에서 지역(시·군·구)·분야·유형·요구 채널·마감일·모집 인원 등 정형 정보를 추출하고, 요약은 원문을 복사하지 않고 자체 형식으로 다시 씁니다.
  • 중복 처리 — 플랫폼+공고 ID 기준으로 1건만 유지하고, 재수집 시 정보만 갱신합니다.
  • 만료 처리 — 마감이 지난 공고는 자동으로 내려가고 일정 기간 후 삭제되며, 마감일 없는 상시 공고도 원본에서 사라진 것이 확인되면 마감 처리됩니다. 그래서 목록에는 "지금 신청할 수 있는 공고"만 남습니다.

수집 대상 전체 목록과 플랫폼별 실측 공고 수는 수집 플랫폼 페이지에 공개돼 있습니다. 크롤러의 세부 구현·인증 정보는 보안상 공개하지 않습니다.

데이터 통합

서로 다른 61개 플랫폼의 공고가 하나의 공통 스키마로 정규화되어 단일 검색 구조에 반영됩니다. 그 덕분에 "서울 뷰티 체험단"이나 "경쟁 낮은 배송형" 같은 조건 검색이 플랫폼 경계 없이 동작하고, 데이터 인사이트의 분야·지역·경쟁률 실측 통계도 같은 데이터에서 나옵니다.

SEO / AEO 구조

검색엔진과 AI가 "Reviewloger = 체험단 공고 통합검색 서비스"를 정확히 이해하도록 처음부터 구조를 설계했습니다: 브랜드 공식 정의문을 한 곳(설정)에서 관리해 구조화 데이터·소개·푸터가 같은 문장을 쓰고, Organization·WebSite·Service·FAQ·Dataset 등의 구조화 데이터(JSON-LD), 얇은 페이지를 걸러내는 선별 사이트맵, 검색엔진에 갱신을 알리는 IndexNow 자동 제출, AI 크롤러를 명시 허용하는 robots.txt와 AI용 사이트 안내(llms.txt), 페이지마다 실측 수치로 생성되는 직답 문단까지 — 전부 실제 데이터에 기반한 구조입니다.

실제로 발견한 AEO 문제

2026년 8월 12일, 실제 ChatGPT 대화에서 다음 질문을 테스트했습니다:

"여러 체험단 공고를 한 번에 모아볼 수 있는 곳은 어디야?"

첫 일반 질의 답변에는 다른 체험단 통합 서비스가 후보로 등장했지만 Reviewloger는 최초 후보에 포함되지 않았습니다. 이 결과를 숨겨야 할 실패가 아니라 AEO 분석의 출발점으로 삼았습니다. 여기서 얻은 핵심 인사이트는 이것입니다:

검색엔진이나 AI가 사이트를 "알고 있는 것"과, 브랜드명을 모르는 사용자의 일반 질문에서 그 사이트를 "먼저 발견하는 것"은 서로 다른 문제다.

  • Indexing(색인) — 페이지가 검색 인덱스에 들어가 있는가. Reviewloger는 색인돼 있었습니다.
  • Understanding(이해) — 검색엔진/AI가 서비스 정체를 정확히 요약하는가. 브랜드명으로 직접 조회하면 "여러 체험단 공고를 한곳에 모아주는 서비스"로 정확히 읽고 있었습니다.
  • Discovery(발견) — 브랜드명이 없는 일반 질문의 후보 수집 단계에 들어가는가. 여기가 문제였습니다.
  • Recommendation(추천) — 후보 중에서 답변에 채택되는가. 발견이 안 되면 이 단계에 도달할 수 없습니다.

실제 분석 결과

  • 발견성 문제 확인 — 브랜드명을 제공하지 않은 일반 질문에서 Reviewloger가 후보로 등장하지 않는 현상을 실제로 확인했습니다.
  • 서비스 적합성 확인 — 이름을 넣어 직접 조사하면 "여러 체험단 공고를 한곳에서 탐색"이라는 질문 조건과 서비스가 정확히 일치했습니다. 즉 문제는 적합성이 아니라 비브랜드 검색에서 발견되는 경로에 있다는 가설을 세웠습니다.
  • 경쟁 서비스와 발견 경로 비교 — 먼저 발견된 서비스들은 자사 사이트 외에도 앱 스토어 페이지, SNS 게시글, 외부 검색 결과 등 여러 독립 문서가 같은 의미("○○ = 체험단 모음")를 반복해 주고 있었습니다. 반면 "리뷰로거/Reviewloger"는 동명의 무관한 문서(해외 블로그 계정, 과거의 다른 제품명 등)가 검색에 섞여 브랜드 개체의 확정이 상대적으로 어려운 상태였습니다. 특정 검색엔진의 공식 순위 요인이라고 단정하는 것은 아니며, 실측 비교에서 관찰된 차이입니다.

현재 적용한 개선

진단 당일(2026-08-12) 코드 전수 감사 후, 실제로 적용한 항목입니다:

  • Bing Webmaster Tools 등록 + 사이트맵 제출 — AI 검색 상당수가 Bing 인덱스를 소스로 쓰는데 등록이 누락돼 있었습니다. 가장 직접적인 원인 교정.
  • 수집 플랫폼 목록 페이지(/platforms) 신설 — "무엇을 모으는 서비스인가"의 직접 근거를 플랫폼별 실측 공고 수와 함께 공개.
  • Service 구조화 데이터 추가 — 조직(Organization)·사이트(WebSite)에 더해 "무엇을 하는 서비스인가"를 타입으로 선언.
  • 사이트맵·색인 정책 정비 — 공고가 적은 얇은 조합 페이지를 색인 대상에서 제외(noindex + 사이트맵 선별)하고, 중복 URL의 canonical을 정식 경로로 통일.
  • robots.txt 정비 — AI 크롤러(OAI-SearchBot 포함 11종) 명시 허용은 기존부터 적용돼 있었고, 용도 선언(Content-Signal)이 모든 크롤러 그룹에 전달되도록 수정.
  • 수치 일관성 교정 — 화면 곳곳의 플랫폼 수 표기를 하드코딩에서 수집 설정 기반 동적 값으로 교체.

성과

구축 성과 (확정 사실)

  • Reviewloger 웹서비스 기획·설계·개발 (SSR + 엣지 배포 + PostgreSQL)
  • 체험단 사이트 61곳 대상 자동 크롤링 시스템 구축 (robots.txt 준수·opt-out 프로세스 포함)
  • 수집 데이터의 공통 스키마 정규화·중복 제거·만료 처리 파이프라인 구축
  • 지역·분야·유형·채널 통합 검색과 실측 통계(인사이트) 구조 구축
  • SEO/AEO를 고려한 사이트 구조(구조화 데이터·선별 사이트맵·IndexNow·llms.txt) 구축

AEO 진단 성과 (2026-08-12 분석)

  • 일반 AI 질문에서 Reviewloger가 누락되는 실제 사례 확인
  • "발견(Discovery)"과 "서비스 적합성"이 별개 문제라는 정의 도출
  • 경쟁 서비스의 발견 경로(외부 문서·엔티티 확증 신호) 비교
  • 개선 대상(검색 진입점·외부 신호·색인 기반) 도출과 당일 교정 실행

AEO 노출 성과

아직 기록하지 않습니다. 개선 전후의 AI 답변 언급률 변화는 동일 조건 재측정이 이루어진 뒤에만 공개합니다(1차 재측정 예정: 2026년 8월 말). 측정 전에 상승 수치를 만들지 않는 것이 이 페이지의 원칙입니다.

분석 방법

  • 분석일 — 2026년 8월 12일
  • 분석 지원 — OpenAI ChatGPT (GPT-5.6 Sol)
  • 분석 방식 — 실제 사용자 질문 기반 AI 답변 테스트, 웹 검색 결과 비교, 경쟁 서비스 공식 페이지·검색 노출 구조 비교, 자체 코드베이스 전수 감사
  • 사용한 질문 예시 — "여러 체험단 공고를 한 번에 모아볼 수 있는 곳은 어디야?", "체험단 모음", "체험단 통합 검색"

위 표기는 OpenAI ChatGPT를 조사·비교 분석 도구로 사용했다는 의미이며, OpenAI가 Reviewloger 또는 NAVIRANG을 인증·추천·보증했다는 의미가 아닙니다.

NAVIRANG

Reviewloger의 서비스 기획·개발·자동 크롤링 시스템 구축과 AEO/검색 발견성 개선은 NAVIRANG(나비랑)이 구축·진행했습니다. NAVIRANG은 AI 검색 최적화(AEO)를 다루는 팀으로, Reviewloger는 그 방법론을 실제 서비스에 적용하고 결과를 공개 검증하는 프로젝트이기도 합니다. 이 페이지가 서비스 운영 관점의 기록이라면, 같은 프로젝트를 구축 과정 중심으로 정리한 문서는 따로 있습니다 — NAVIRANG 수행사 관점의 전체 구축·AEO 사례 보기.

의견