Reality Check: AI로 스타트업 아이디어 시장포화도 분석 웹

reality check

 

사업을 구상하다보면 "내 아이디어는 이미 레드오션이 아닐까?", "이런 아이디어를 세상에 내놨을 때 괜찮으려나?" 하는 생각이 들 것이다.

이런 불안을 단 몇 초만에 보여주는 웹 서비스를 만들었다

 

Reality Check

 

 

1. 왜 만들었나?

스타트업 생태계에서 가장 흔한 실수라고 한다면 생태계 조사 하나 없이 이미 포화된 시장에 그냥 뛰어드는 것이다.

경쟁자 분석, 시장 조사에만 보통 몇 일 ~ 몇 주가 걸리기도 한다.

하지만 빠르게 진행하고 싶은 초기 창업자의 경우 이런 과정을 건너뛰기도 한다.

그리고 아직 아이디어 검증을 필요로 하는 예비 창업자의 경우 자신의 아이디어를 검증 받고 싶어 할 것이다.

 

Reality Check는 아이디어를 입력하면 AI가 실시간으로 시장을 검색하고, 유사 제품을 찾고, 포화도/차별성/생존 확률을 점수로 보여주는 서비스이다.

 

 

2. 기술 스택

코어 : Next.js / Google Gemini API / Tavily Search API

 

Server Component와 Route Handler로 API key를 보호하고 싶었기에 Next.js를 선택했고, JSON Schema 응답을 지원하고, 빠른 응답 속도를 낼 수 있는 Google Gemini API(gemini-2.5-flash)와 실시간 웹 검색으로 근거 기반 분석을 할 수 있는 Tavily Search API를 사용했다.

 

3. 핵심 아키텍처: 분석 파이프라인

사용자가 아이디어를 입력하면 단일 API 호출로 4단계 파이프라인이 실행된다.

[ 사용자 입력 ] → [ Tavily 웹 검색 ] → [ Gemini LLM 분석 ] → [ 점수 계산 ] → [ 데이터 보강 ] → [ 결과 페이지 렌더링 ]

 

Step 1 : Tavily 웹 검색

아이디어와 카테고리, 타겟을 가지고 경쟁자와 대안 10개를 검색한다.

 

Step 2: Gemini LLM 분석

검색 결과를 근거로 구조화된 시장 분석 JSON을 생성한다.

 

Step 3: 점수 계산

saturation(포화도), differentiation(차별성), survivalOdds(생존 확률)를 산출해낸다.

 

Step 4: 데이터 보강

검색 결과와 유사한 제품을 매칭한다.

 

4. UX를 높이기 위한 트릭

분석을 돌려보니 단일 API 호출이 10~20초 정도 소요 됐다.

이건 너무 많은 시간을 잡아먹고, 유저의 이탈을 야기시킬 수 있다.

하지만 유저는 눈 앞에 무언가가 진행되고 있다는 것을 보게 되면 그 시간을 기다려줄 수 있다.

그래서 5단계 Progress Stepper를 보여주도록 했다.

Step 1: "Extracting keywords…"             (0초)
Step 2: "Scanning similar products…"       (3초)
Step 3: "Analyzing competitive landscape…" (7초)
Step 4: "Calculating saturation scores…"   (12초)
Step 5: "Generating verdict…"              (17초)

 

setTimeout 기반의 명령형 제어와 DOM 직접 조작을 위해서 GSAP를 이용했고, 각 단계를 시간차 애니메이션 처리하고, 경과 시간을 실시간으로 표시했다. 그리고 API 응답이 도착하면 즉시 모든 단계를 완료 처리 하도록 만들었다.

 

 

5. 공유 데이터 URL 인코딩

Reality Check의 KPI는 공유와 유입이지 결제전환이 아니다. 그러다보니 해당 URL을 공유 할 수 있도록 하는 것이 중요했다.

또 하나, Reality Check에는 데이터베이스가 없다. 즉, 분석 결과를 저장하지 않는다.

그런데 "링크 복사" 버튼을 통해서 다른 사람에게 결과를 공유할 수 있어야한다.

 

여기에는 모순이 있다. 데이터베이스는 없는데 다른 사람에게 결과를 공유한다는 모순이다.

이를 해결하기 위해서 DB 없이도 결과를 공유할 수 있도록 결과 데이터 자체를 URL 쿼리 파라미터에 인코딩해서 넣어버렸다.

 

유저가 "Copy Link" 버튼을 클릭하면 점수와 verdict를 JSON으로 만든 뒤, base64로 변환해서 URL 쿼리 파라미터에 붙이도록 했다.

그리고 디코딩을 통해서 결과를 복원할 수 있도록 했다.

이 방식의 트레이드 오프라면 DB 없이 결과가 공유 가능하지만 URL이 길어진다는 단점이 있다.

 

 

6. 배운 점과 트레이드 오프

잘한 점

• LLM 분석과 점수 계산을 분리 : 재현 가능한 점수 + 풍부한 텍스트 분석을 동시에 달성
• 가짜 진행 상태 UI : 최소 비용으로 UX를 높임으로써 체감 속도를 개선
• OG 이미지 동적 생성 : 공유 시 자동으로 결과 미리보기가 생성되어 바이럴 유도
• URL 기반 데이터 공유 : DB 없이 결과 공유 가능

 

트레이드 오프

• 인메모리 rate limit : Serverless 환경에서 인스턴스 간 공유 불가 
• DB 없는 구조 : 분석 결과 영속성 없음, URL 파라미터로 대체
• API 의존성 : Tavily API가 다운되면 분석 불가 → Fallback 검색엔진 필요