나비랑이 Reviewloger에서 실제로 수행한 범위는 어디까지인가요?

서비스 기획과 정보 구조 설계부터 웹 애플리케이션 개발, 62개 체험단 플랫폼 수집 어댑터(현재 61개 활성)와 정규화·중복 제거·마감 처리 파이프라인, 검색·필터 구조, JSON-LD·사이트맵·robots.txt·llms.txt 같은 SEO·AEO 구조, 그리고 AI 검색 발견성 진단까지입니다. 이 글의 구축 범위와 수치는 전부 저장소 코드와 운영 데이터베이스에서 확인한 사실만 적었습니다.

AEO 진단에서 무엇을 확인했나요?

2026년 8월 12일 실제 사용자 관점의 질문으로 테스트한 결과, 질문의 목적과 서비스가 정확히 부합하는데도 AI의 최초 답변 후보에 Reviewloger가 포함되지 않는 현상을 재현했습니다. 서비스 기능의 문제가 아니라 검색과 AI가 후보를 고르는 발견 과정의 문제로 원인 범위를 좁혔고, 먼저 후보로 등장한 경쟁 서비스들의 발견 경로를 비교해 개선 방향을 정의했습니다.

개선 성과 수치는 왜 없나요?

아직 측정 중이기 때문입니다. 동일 질문군을 작업 전후로 반복 측정해 브랜드 언급률, 비브랜드 질문 발견률, 공식 URL 인용 비율 같은 실제 값이 생기면 별도 글로 공개합니다. 측정되지 않은 숫자를 만들지 않는 것이 나비랑의 수치 정책입니다.

Reviewloger 구축 사례 | 웹개발·자동 크롤링·AEO

Q: ChatGPT가 이 분석에 어떻게 쓰였나요?

검색 결과 조사와 비교 분석 도구로 활용했습니다. OpenAI 또는 ChatGPT가 나비랑이나 Reviewloger의 서비스 품질을 인증·보증하거나 공식 추천했다는 의미는 아닙니다.

세 줄 요약

나비랑은 체험단 통합검색 서비스 Reviewloger의 기획부터 웹 개발, 공고 자동 수집(어댑터 62개 중 현재 61개 활성), 데이터 통합, 검색 구조, SEO·AEO 구조까지 전 과정을 구축했습니다.
2026년 8월 12일 기준 진행 중인 공고 6,147건이 하나의 공통 스키마로 통합되어 지역·분야·플랫폼·마감일로 탐색됩니다.
같은 날 진행한 AI 검색 발견성 진단에서, 서비스가 질문 목적에 정확히 부합하는데도 AI의 최초 답변 후보에 들지 못하는 현상을 재현했습니다. 좋은 서비스를 만드는 일과 AI가 그 서비스를 발견하게 만드는 일은 별개의 문제입니다.

Reviewloger는 어떤 서비스인가요?

여러 체험단 플랫폼에 흩어진 모집 공고를 자동으로 수집해, 한곳에서 탐색하고 비교할 수 있게 만든 체험단 공고 통합검색 서비스입니다. 체험단에 지원하려는 사람이 플랫폼을 하나하나 돌지 않아도 되게 하는 것이 서비스의 존재 이유입니다.

사용자는 지역(전국 17개 시도와 시·군·구), 분야(맛집·뷰티·생활·디지털·여행·유아동·패션·반려동물·문화 9개), 검색어로 공고를 찾고, 마감 임박·최신·경쟁률 낮은순·보상 높은순으로 정렬합니다. 공고마다 마감 D-day와 신청 경쟁률이 계산되어 붙습니다.

어떤 문제를 풀려고 했나요?

문제는 두 개였고, 두 번째는 서비스를 다 만든 뒤에 발견됐습니다.

첫 번째는 제품 문제입니다. 체험단 모집 공고는 수십 개 플랫폼에 흩어져 있고, 플랫폼마다 지역·마감·보상 표기가 다릅니다. 원하는 공고를 찾으려면 사이트를 하나하나 방문해야 합니다. Reviewloger가 풀어야 했던 것은 흩어진 공고를 자동으로 수집하고 정리해 한곳에서 찾게 만드는 것이었습니다.

두 번째는 AEO 문제입니다. 서비스가 완성되고 데이터가 쌓인 뒤에도, 사용자가 브랜드명을 모른 채 AI에게 질문하면 AI가 이 서비스를 후보로 가져오지 않았습니다. 좋은 서비스를 만들어 놓는 것과, 브랜드명을 모르는 사용자의 질문에서 AI가 그 서비스를 발견하는 것은 별개의 문제입니다. 이 글의 후반부는 그 간극을 진단한 기록입니다.

나비랑이 구축한 것 — 기획부터 수집·검색·AEO까지

이 절의 구축 범위는 전부 Reviewloger 저장소의 코드와 운영 데이터베이스에서 확인한 사실만 적었습니다. 확인되지 않은 것은 적지 않았습니다.

서비스 설계와 웹 애플리케이션

정보 구조는 “질문 그대로의 탐색 경로”로 설계했습니다. 지역으로 찾는 사람에게는 지역 경로를, 분야로 찾는 사람에게는 분야 경로를, 둘을 조합하는 사람에게는 조합 경로를 정식 URL로 제공합니다.

기술적으로는 Astro 5 서버 사이드 렌더링(SSR)을 Cloudflare Workers 엣지에 배포하고, 데이터는 Supabase(PostgreSQL)에 둡니다. 모든 목록과 필터가 서버에서 HTML로 렌더되기 때문에 자바스크립트를 실행하지 않는 크롤러도 본문 전체를 읽습니다. 필터 칩은 클라이언트 스크립트가 아니라 정식 경로 링크로 구현했습니다 — 사람에게는 버튼이고, 크롤러에게는 페이지입니다.

자동 수집 파이프라인 — 아홉 단계

여러 체험단 사이트의 모집 공고를 자동 수집하는 크롤러 시스템의 핵심입니다. 플랫폼별 수집 어댑터 62개를 구축했고 이 중 61개가 현재 활성입니다. 수집부터 검색까지 다음 단계가 전부 코드로 존재합니다.

단계	하는 일
Source	수집 대상 플랫폼을 설정 한 곳에서 관리합니다. robots.txt가 목록 수집을 막는 1개 플랫폼은 수집 대상에서 제외해 두었습니다
Crawl	robots.txt를 요청 시점마다 확인하고, 식별 가능한 봇 이름으로, 요청 간격을 지켜 수집합니다. 차단 신호(403·429)를 받으면 해당 사이트 수집을 즉시 중단합니다
Parse	플랫폼마다 다른 HTML 구조와 공개 JSON 응답을 각각 해석합니다
Normalize	지역·마감일·모집 인원·신청자 수·보상·유형·채널·분야를 공통 형식으로 변환합니다
Deduplicate	플랫폼과 원본 공고 ID 기준으로 중복을 막습니다 — 데이터베이스 유니크 제약과 적재 로직의 2중 방어입니다
Store	검수 대기 상태로 적재합니다. 원문 제목은 노출하지 않고, 지역·대상·혜택 같은 사실 필드를 조합한 제목과 요약을 자체 생성합니다
Update	재수집 때는 마감일·신청자 수 같은 휘발성 필드만 갱신하고, 검수자가 고친 값은 보존합니다
Expire	마감이 지난 공고를 자동 종료하고, 오래된 공고는 자동 삭제합니다
Search	정리된 데이터를 지역·분야·검색어·정렬 축으로 서버 렌더 탐색에 공급합니다

이 위에 두 단계가 더 얹혀 있습니다. 검수 대기 공고에 정형 사실 기반 요약을 생성해 자동 게시하는 단계와, 조건에 맞는 새 공고를 카카오톡으로 알려주는 알림 단계입니다. 수집 실행은 GitHub Actions 워크플로로 매일 1회 돌도록 구성했습니다.

수집은 준수가 기본값입니다. robots.txt를 요청할 때마다 다시 확인하고, 봇을 식별 가능한 이름으로 밝히고, 요청 간격을 지키고, 차단 신호를 받으면 물러납니다. 차단을 우회하는 장치는 만들지 않았습니다 — 실제로 어댑터 1개는 대상 사이트의 robots.txt 정책 때문에 수집을 중단한 상태로 남아 있습니다.

데이터 통합 — 62개 수집 어댑터, 하나의 스키마

플랫폼마다 지역은 “서울/강남구”, “경기 성남시”, “전국”처럼 제각각이고, 마감은 “31일 남음”, “D-15”, “오늘마감”처럼 표기가 다릅니다. 정규화 계층이 이것을 전부 공통 필드로 변환합니다 — 지역(시도·시군구 코드), 분야 9종, 유형(방문형·배송형·기자단·포장형), 채널(블로그·인스타그램·유튜브·클립/릴스), 마감일, 발표일, 모집 인원, 신청자 수, 보상.

이 통합이 있어야 “부산의 방문형 맛집 체험단만 마감 임박순으로” 같은 요청에 답할 수 있는 데이터가 됩니다. 62개 어댑터가 수집한 서로 다른 구조가 이 지점에서 하나의 질문 가능한 데이터셋으로 바뀝니다.

SEO·AEO 구조

검색엔진과 AI가 이 서비스의 의미를 읽을 수 있도록 처음부터 넣은 구조입니다.

구조화 데이터 9종 — Organization, WebSite(SearchAction 포함), Service, BreadcrumbList, ItemList, FAQPage, Article, AboutPage, Dataset
선별형 사이트맵 — 공고 수가 적은 얇은 지역·조합 페이지는 사이트맵에서 제외합니다. 이름만 바꾼 페이지의 대량 색인 시도는 중복 판정을 부릅니다
수집 공고 상세는 noindex — 원본 플랫폼과의 중복 콘텐츠 신호를 차단합니다. 색인은 원본의 몫이고, 통합 탐색이 이 서비스의 몫입니다
지역·분야 페이지마다 실측 수치 직답 문단 — 총 건수·유형 분포·경쟁률 같은 그 페이지만의 값을 렌더 시점에 계산해 넣습니다. 지역명만 바꾼 템플릿 문장은 페이지끼리 글이 겹치기 때문입니다
robots.txt에서 AI 크롤러 11종 명시 허용, llms.txt 제공, FAQ 22문항(화면과 FAQPage 스키마가 같은 배열을 읽습니다), RSS, IndexNow 색인 요청

이 구조들의 일반 원리는 AEO 실무 시리즈에 정리되어 있습니다.

2026년 8월 12일, AI에게 직접 물었습니다

구축을 마친 서비스가 AI 검색에서 실제로 발견되는지, 실제 사용자 관점의 질문으로 진단했습니다. 대표 질문은 이것입니다.

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

첫 일반 답변에서는 다른 체험단 통합 서비스들이 먼저 후보로 등장했고, Reviewloger는 최초 답변에 포함되지 않았습니다.

이어서 Reviewloger가 이 질문에 맞는 서비스인지 따로 검증했습니다. 여러 체험단 공고를 한곳에서 탐색한다는 질문의 목적과 실제 서비스는 정확히 부합했습니다. 측정일 기준 60개 플랫폼의 진행 공고 6,147건이 실제로 한곳에서 탐색됩니다.

서비스는 질문에 맞는데, AI는 그 서비스를 후보로 가져오지 않는다 — 이 간극이 이 케이스 스터디의 핵심 문제입니다. 이런 일이 생기는 일반적인 원인은 ChatGPT에 우리 회사가 안 나오는 이유에 다섯 가지로 정리해 두었습니다.

발견 → 이해 → 추천 — 다섯 단계로 나눠서 봅니다

나비랑은 이런 간극을 진단할 때 문제를 다섯 단계로 쪼갭니다. 검색엔진이나 AI 회사가 공개한 공식 랭킹 모델이 아니라, 나비랑이 실무에서 진단 순서를 정하기 위해 쓰는 분석 프레임워크입니다.

단계	묻는 것	Reviewloger의 상태 (2026-08-12 진단)
1 존재	웹에 서비스가 존재하는가	통과
2 크롤링·색인	검색 시스템이 접근·수집할 수 있는가	접근 구조 갖춤 — 서버 렌더, 크롤러 허용, 사이트맵
3 이해	검색엔진과 AI가 이 서비스가 무엇인지 아는가	정체성 문서와 구조화 데이터 존재
4 발견	브랜드명이 없는 일반 질문에서 후보로 가져오는가	최초 답변 후보에 없음 — 병목
5 추천	여러 후보 중 실제 답변에 포함하는가	4를 넘지 못하면 도달할 수 없는 단계

이번 진단에서 중요한 관찰은 3단계와 4단계 사이의 간극입니다. 사이트를 읽으면 이해할 수 있는 상태를 만드는 것까지는 사이트 안에서 끝나는 일입니다. 그런데 브랜드명이 없는 질문에서 후보 목록에 오르는 것은 다른 문제입니다 — 외부 웹에서의 언급, 그 서비스가 속한 카테고리와 브랜드의 연결 같은 사이트 바깥의 신호가 함께 작동해야 합니다. 안에서 할 일과 밖에서 할 일을 가르는 경계선이 여기입니다.

이번 진단으로 확인한 것 네 가지

아래는 진단·분석 성과입니다. 개선 결과가 아닙니다.

첫째, 문제를 재현했습니다. 일반 사용자 질문에서 Reviewloger가 최초 후보에 포함되지 않는 현상을 실제 질문으로 확인했습니다. 재현되지 않는 문제는 개선했는지도 확인할 수 없습니다.

둘째, 원인 범위를 좁혔습니다. 서비스가 질문 목적에 부합한다는 것을 따로 검증했기 때문에, 문제는 서비스 기능 부족이 아니라 검색과 AI에서 후보로 발견되는 과정에 있다는 분석 방향을 확보했습니다.

셋째, 경쟁 서비스의 발견 방식을 비교했습니다. 먼저 후보로 등장한 서비스들이 검색 결과 노출, 서비스 정체성 표현, 외부 웹 언급, 랜딩페이지 구성, 브랜드·카테고리 신호에서 어떤 경로로 발견되는지 비교했습니다. 개별 서비스에 대한 평가는 하지 않습니다 — 관찰만 기록합니다.

넷째, 개선 방향을 정의했습니다. 검색엔진과 AI가 “Reviewloger = 여러 체험단 공고를 한곳에서 탐색하는 서비스”로 더 쉽게 읽도록 만들 구조를 정의했습니다. 적용과 측정은 이 글 이후의 일입니다.

구축 성과 — 코드와 데이터로 확인되는 것만 적습니다

아래 수치는 2026년 8월 12일에 서비스가 목록을 렌더링할 때 쓰는 것과 동일한 공개 조회 조건으로 운영 데이터베이스에서 직접 집계한 값입니다.

항목	값 (2026-08-12 기준)
수집 어댑터	62개 구축 · 61개 활성 (1개는 대상 사이트 robots.txt 정책으로 수집 중단)
진행 중 공고	6,147건 — 지역 지정 3,718건 · 전국/배송형 2,429건
진행 공고를 보유한 플랫폼	60개
데이터베이스 보관 공고	20,654건 — 마감 30일 경과분은 자동 삭제되므로 누적 처리량은 이보다 많습니다
탐색 축	지역 17개 시도·시군구 × 분야 9개 × 정렬 4종 + 검색어
구축 기간	2026년 6월 30일 첫 커밋 이후 약 6주

이 표의 수치는 계속 변하는 운영 데이터의 측정일 스냅샷입니다. 나비랑은 발행한 글의 수치를 나중에 고치지 않습니다 — 고치면 그 글이 무엇을 언제 잰 기록인지 사라지기 때문입니다. 변한 값은 새 글로 냅니다.

정리하면 나비랑이 이 프로젝트에서 수행한 것은 다음과 같습니다.

Reviewloger 전체 웹서비스 구축 (기획·정보 구조·프론트엔드·백엔드)
체험단 플랫폼 공고 자동 수집 시스템 구축 (어댑터 62개 중 현재 61개 활성)
플랫폼별 상이한 데이터의 정규화·통합 자동화
수집→검수→게시→마감→삭제의 지속 업데이트 구조
지역·분야·검색어·정렬 탐색 시스템 구축
검색엔진 대응 구조 (선별형 사이트맵·noindex 정책·구조화 데이터 9종)
AI 검색 발견성 진단과 측정 체계 설계

아직 측정 중인 것 — 숫자는 나오면 적습니다

AEO 발견성 개선 결과는 이 글에 없습니다. 동일 질문군을 작업 전후로 반복 측정해서, 다음 지표에 실제 값이 생기면 별도 글로 공개합니다.

ChatGPT·Gemini·Perplexity에서의 브랜드 언급률
브랜드명이 없는 일반 질문에서의 발견률
답변이 Reviewloger 공식 URL을 출처로 인용하는 비율

측정되지 않은 값을 미리 적지 않는 이유는 AEO 성과 수치를 읽는 기준에 적어 둔 것과 같습니다. 측정 조건 없는 수치는 검증할 수 없고, 검증할 수 없는 수치는 남에게 요구할 수도 없습니다.

연구 방법과 출처

항목	내용
분석일	2026년 8월 12일
분석 도구	OpenAI ChatGPT (GPT-5.6 Sol) — AI 지원 조사(AI-assisted research)
분석 방법	실제 사용자 질문 테스트 · 브랜드명 없는 서비스 추천 질문 · 웹 검색 결과 비교 · 경쟁 서비스 발견 경로 비교 · 공식 사이트와 외부 웹 신호 분석 · 서비스 적합성과 AI 발견성 비교
구축 범위 검증	Reviewloger 저장소 코드 분석 · 운영 데이터베이스 공개 조회 집계 (2026-08-12)

OpenAI 또는 ChatGPT가 나비랑이나 Reviewloger의 서비스 품질을 인증·보증하거나 공식 추천했다는 의미는 아닙니다. ChatGPT는 이번 프로젝트의 검색 결과 조사 및 비교 분석 도구로 활용되었습니다.

같은 프로젝트의 기록이 Reviewloger 쪽에는 서비스 운영 관점으로 정리되어 있습니다 — Reviewloger 구축 프로젝트 소개. 이 글은 개발·AEO 수행사 관점의 기록이라 두 글은 서로를 복제하지 않습니다.

이 사례는 Reviewloger를 직접 구축한 주식회사 나비랑이 작성한 기록입니다. 제3자가 검증한 평가가 아니며, 여기서 관찰된 결과가 다른 서비스에서 재현된다는 보장은 없습니다. 본문의 구축 범위와 수치는 저장소 코드와 운영 데이터베이스에서 확인한 값만 적었고, 측정되지 않은 성과는 담지 않았습니다.