Grok Bot으로 ‘문제 발견 → 검증 → 제품 출시 → 판매’ 자동화 시스템 구축하기

단순히 AI에게 “돈 될 만한 사업 아이디어를 찾아줘”라고 요청하는 것과, 인터넷에서 실제 사업자의 문제를 지속적으로 수집하고 검증한 뒤 제품 출시까지 연결하는 시스템을 만드는 것은 완전히 다른 문제다.

Chris가 공개한 시스템의 핵심은 하나다.

아이디어를 생성하지 말고, 시장에서 반복해서 관찰되는 문제를 찾아라.

하나의 Reddit 글이나 한 사람의 불평만으로 제품을 만들지 않는다. 서로 독립된 여러 데이터 소스에서 동일한 문제가 발견되었을 때만 후보로 승격한다.

전체 구조는 다음과 같다.

인터넷 데이터 수집
       ↓
문제 추출
       ↓
Embedding / Clustering
       ↓
복수 Source Confirmation
       ↓
Scoring
       ↓
사람의 승인
       ↓
사업 전용 Agent 생성
       ↓
Landing Page + Checkout
       ↓
시장 검증
       ↓
제품 구축
       ↓
Outreach / 판매
       ↓
매출·비용 측정
       ↓
Kill / Scale
       ↓
결과를 다시 Scoring에 반영

즉, AI 사업 아이디어 생성기가 아니라 AI 기반 Revenue Discovery Engine에 가깝다.

---

1. 가장 중요한 설계 원칙: Single Source를 믿지 않는다

이 시스템에서 가장 중요한 것은 LLM 자체가 아니다.

Cross-source confirmation, 즉 서로 다른 종류의 데이터가 동일한 문제를 가리키는지를 확인하는 것이다.

예를 들어 Reddit에서 다음 이야기가 나왔다고 하자.

HVAC 업체가 갑자기 결원이 생겼을 때 면허가 있는 대체 기술자를 구하기 어렵다.

이것 하나만으로는 사업 아이디어가 아니다.

하지만 동시에 다음 데이터가 발견된다면 이야기가 달라진다.

Reddit
↓
HVAC 업체 사장이 긴급 대체 인력을 찾기 어렵다고 말함

Indeed
↓
비슷한 업무를 담당할 Dispatcher / Technician 채용 다수

Upwork
↓
긴급 dispatch 관련 반복 업무 의뢰

Podcast
↓
HVAC 운영자가 같은 문제 언급

Google News
↓
폭염으로 HVAC 수요 급증

이 경우 하나의 문제가 여러 시스템에서 독립적으로 검증된다.

Chris의 시스템은 이를 Convergence라고 본다.

---

2. 왜 데이터 수집 시스템을 5개로 나누는가

하나의 Scraper가 인터넷을 뒤지는 구조가 아니다.

각 시스템마다 다른 종류의 증거를 담당한다.

System 1 — 사람들이 이미 돈을 쓰는 문제

가장 가치 있는 신호다.

수집 대상 예:

• Upwork
• Fiverr
• Indeed
• App Store 리뷰
• SaaS 1~3점 리뷰
• Flippa
• Acquire

여기서 찾는 것은 단순한 불만이 아니다.

"이 문제를 해결하기 위해 이미 돈이 나가고 있는가?"

예를 들어 회사가 특정 반복 업무를 처리하기 위해 연봉 $45,000 직원을 고용하고 있다면 그 업무에는 이미 시장 가격이 존재한다.

또 SaaS 리뷰에 다음과 같은 내용이 있다면 강한 신호다.

매월 $130를 내고 있는데
내가 필요한 것은 기능 하나뿐이다.

이 경우 새로운 SaaS 전체를 만드는 것이 아니라 그 사람이 사용하는 핵심 기능 하나만 떼어낸 Micro SaaS가 기회가 될 수 있다.

---

3. System 2 — 전문가와 운영자들이 이야기하는 방향

두 번째 데이터는 Podcast와 YouTube다.

원문에서는 다음 프로그램을 예로 들었다.

• My First Million
• This Week in Startups
• Lenny's Podcast
• AI Daily Brief
• Greg Isenberg 관련 콘텐츠

그러나 중요한 것은 프로그램 이름이 아니다.

자신이 공략하려는 Vertical에 맞춰 채널을 선택해야 한다.

예를 들어 건설업을 대상으로 한다면

SaaS Podcast

보다

Contractor Podcast
HVAC Podcast
Construction Business Podcast
Roofing Operator Channel

같은 데이터가 훨씬 가치 있다.

구조는 단순하다.

YouTube RSS
     ↓
새 Video 감지
     ↓
Transcript 수집
     ↓
LLM Extraction
     ↓
Problem / Tool / Idea 추출
     ↓
기존 Cluster와 비교

Podcast에서 발견된 아이디어는 독립적으로 Candidate가 되지 않는다.

이 시스템에서는 Confirmation Source 역할을 한다.

즉,

Podcast에서만 언급
→ Watching

Reddit 문제 + Podcast 언급
→ Score 상승

Job Posting + Review + Podcast
→ Candidate 가능

이런 구조다.

---

4. System 3 — Timing Catalyst 탐지

사업에서는 문제 자체만큼 중요한 것이 타이밍이다.

예를 들어 다음과 같은 이벤트가 발생할 수 있다.

새로운 규제
보험 정책 변경
폭풍
폭염
가뭄
Permit 정책 변경
보조금 정책
License 규정

이것들이 기존 문제와 결합하면 갑자기 구매 의사가 커진다.

그래서 System 3는 다른 시스템보다 자주 실행한다.

원문의 예시는 2시간 간격이다.

수집 후보:

Google News RSS
County Permit Portal
Business Registration
Contractor License Board
NOAA Weather
Regulation Update

여기서 중요한 데이터는 다음 네 가지다.

Who
어떤 사업자가 영향을 받는가?

Where
어느 지역인가?

Urgency
얼마나 급한가?

Window
기회가 얼마 동안 지속되는가?

예를 들어:

강력한 우박 예보
       ↓
Roofing Contractor
       ↓
향후 2~4주 수요 증가
       ↓
Lead / Scheduling / Financing 문제 증가

기존 Cluster와 Catalyst가 연결되면 즉시 Alert를 발생시킨다.

---

5. System 4 — 사업자의 실제 불만

Reddit과 전문 Forum을 읽는다.

하지만 여기에는 강력한 필터가 필요하다.

수집하지 않는 데이터:

직원 불평
일반 소비자 불만
정치
동기부여 글
성공담
잡담

찾는 것은 Owner 또는 Operator가 말하는 문제다.

특히 다음 문장이 강한 Signal이 된다.

"I wish there was..."

"Is there a tool that..."

"We currently pay..."

"I spend hours every week..."

"Alternative to..."

"Why is there no..."

추출 결과는 최대한 단순하게 만든다.

who: HVAC owner
problem: last-minute licensed technician replacement
vertical: HVAC
severity: 5
quote: "..."
source: URL

전문 산업 Forum은 Reddit보다 더 높은 Signal을 가질 수 있다.

예를 들어 Plumbing Forum에 글을 쓰는 사람은 실제 Plumbing Business 운영자일 가능성이 일반 Reddit보다 높기 때문이다.

---

6. System 5 — 무엇이 빠르게 성장하는가

마지막은 Launch / Trend 감지다.

예:

Product Hunt Top 20
GitHub Trending
Show HN
Ask HN

여기서는 단순히 숫자를 저장하지 않는다.

1,000 stars

보다

출시 48시간
1,000 stars

가 훨씬 의미 있기 때문이다.

따라서 반드시:

traction
+
age

를 함께 저장한다.

---

7. 수집 데이터와 사람이 보는 데이터를 분리한다

원문의 좋은 설계 중 하나가 이 부분이다.

Machine Layer와 Human Layer를 분리한다.

Machine Layer

SQLite 또는 Supabase.

예:

raw_items
problems
problem_embeddings
clusters
cluster_sources
enrichments
verdicts
outcomes
run_logs

예시 스키마:

raw_items
 ├ id
 ├ source_type
 ├ source_url
 ├ raw_text
 ├ author
 └ collected_at

problems
 ├ id
 ├ raw_item_id
 ├ problem
 ├ vertical
 ├ severity
 ├ dollar_amount
 └ embedding

clusters
 ├ id
 ├ canonical_problem
 ├ vertical
 ├ score
 ├ status
 └ updated_at

Vector Search를 사용해 새로운 Problem이 기존 Cluster와 유사한지 판단한다.

---

8. Human Layer는 Obsidian

Chris는 사람이 보는 인터페이스로 Obsidian을 사용한다.

예:

00-Inbox
01-Daily
02-Candidates
03-Watching
04-Proposals
05-Active
06-Outcomes
07-Dossiers
08-Killed

Cluster 하나가 Markdown 파일 하나가 된다.

예:

---
cluster_id: hvac-0021
score: 84.9
systems:
  - jobs
  - forum
vertical: hvac
status: candidate
verdict:
---

본문:

# Problem

HVAC 업체가 긴급 Call-out 상황에서
면허가 있는 대체 기술자를 찾기 어렵다.

## Evidence

Source A
Quote
URL

Source B
Quote
URL

## Diagnostic

...

## Enrichment

...

여기에서 매우 중요한 규칙이 있다.

사람이 변경한 Frontmatter가 항상 우선한다.

Agent가 Obsidian을 업데이트하기 전에 반드시 기존 Frontmatter를 다시 읽는다.

그래야 사람이

status: killed

로 변경한 아이디어를 AI가 다시 Candidate로 되돌려 놓는 문제를 방지할 수 있다.

---

9. 핵심은 Clustering

수백 개 글을 그대로 사람이 읽는 것은 자동화가 아니다.

예를 들어:

576 Raw Items
↓
72 Problems
↓
57 Clusters
↓
1 Candidate

처럼 압축해야 한다.

새로운 Problem이 들어오면:

Problem
   ↓
Embedding
   ↓
Vector Search
   ↓
Existing Cluster?
   ├ YES → attach
   └ NO  → new cluster

여기에 추가로 LLM 판단을 넣을 수 있다.

Semantic Similarity
+
LLM Classification

두 단계를 같이 쓰는 것이 안정적이다.

---

10. Scoring Engine

원문의 가장 중요한 아이디어 중 하나다.

Score는 단순한 LLM 느낌이 아니다.

가장 높은 Weight는

Distinct Systems Confirming

이다.

예를 들면 다음처럼 설계할 수 있다.

Score =

35% Source Diversity
20% Existing Spend Evidence
15% Severity
10% Recurrence
10% Growth Velocity
5% Timing Catalyst
5% Founder Preference

예:

Reddit 30개
Podcast 0
Jobs 0
Reviews 0

→ Source Diversity = 낮음

반대로:

Reddit 2
Indeed 4
Upwork 3
App Review 5

→ Source Diversity = 높음

후자가 훨씬 높은 점수를 받는다.

---

11. 인간 피드백까지 Scoring에 넣는다

사람이 Candidate를 판단할 때 세 가지 Verdict를 내린다.

Pursue
Watch
Kill

그리고 반드시 이유를 입력한다.

예:

Kill

Reason:
시장 규모는 충분하지만
고객 확보 비용이 너무 높을 가능성이 큼.

이 데이터가 쌓이면 다음 후보 평가에도 사용한다.

최근 30개 Verdict
↓
선호 Pattern
↓
Scoring Adjustment

즉 시스템이 시간이 지날수록

"시장에 뭐가 필요한가?"

뿐 아니라

"내가 어떤 사업을 실제로 하는가?"

까지 학습한다.

---

12. Candidate 기준

원문의 예시는 매우 보수적이다.

Score ≥ 70
+
2 Systems

→ Candidate

그리고

Score ≥ 85
+
3 Systems
+
Verified Numbers

→ Build Proposal

즉 50개 문제 중 1~2개만 올라오게 만드는 것이 목적이다.

아이디어가 많이 나오는 것은 좋은 시스템이 아니다.

버릴 것을 많이 버리는 시스템이 좋은 시스템이다.

---

13. Dashboard

사람이 판단하는 화면은 복잡할 필요가 없다.

홈 화면:

Problem                           Vertical   Score  Sources
──────────────────────────────────────────────────────────
Licensed technician shortage     HVAC        84.9     3
Insurance claim rework           Dental      81.2     2
Marketplace payout fee           SaaS        73.7     1

클릭하면:

Problem

Why this matters

Evidence
 ├ Quote
 ├ Source
 └ URL

Enrichment

Score Breakdown

[Pursue]
[Watch]
[Kill]

Reason: __________

여기서 중요한 것은 데이터 시각화보다 Decision Interface라는 점이다.

---

14. Pursue를 누르면 새로운 Agent를 만든다

Candidate Agent와 Business Agent를 분리한다.

Discovery Agent
       ↓
Human Pursue
       ↓
Business Agent 생성

Business Agent가 받는 Context:

Problem
Evidence
Quotes
Source URLs
Vertical
Competitors
Pricing Evidence
Customer List
Catalysts

그리고 각각 독립적으로 관리한다.

Business A
 ├ Revenue
 ├ Cost
 └ Customers

Business B
 ├ Revenue
 ├ Cost
 └ Customers

사업별 P&L을 섞지 않는 것이 중요하다.

---

15. 제품부터 만들지 않는다

가장 중요한 부분이다.

Pursue한 뒤 바로 제품 개발을 시작하지 않는다.

먼저 Test를 만든다.

Evidence
↓
Landing Page
↓
Price
↓
Checkout
↓
Traffic
↓
Payment Intent

Landing Page에는 실제 Evidence에서 나온 표현을 사용한다.

예를 들어 사업자가

"I spend three hours every morning rescheduling technicians."

라고 반복해서 말한다면,

마케팅 문구를 새로 만들어내기보다 문제 표현 자체를 활용한다.

다만 실제 외부 공개 시에는 저작권·개인정보·플랫폼 약관을 별도로 검토해야 한다.

---

16. Waitlist보다 Checkout

원문에서 상당히 강조하는 부분이다.

Waitlist
=
관심

Checkout
=
구매 의도

따라서 Landing Page 단계부터 가격을 제시한다.

예:

Emergency HVAC Dispatch Assistant

$299 / month

그리고 결제 단계까지 이동하는지를 측정한다.

여기서 실제 제품이 완성되지 않았다면 결제 처리 방식과 소비자 보호, 환불, 표시·광고 관련 법적 의무를 반드시 검토해야 한다.

---

17. 제품은 네 가지 형태 중 하나로 분류한다

문제가 검증되었다고 무조건 SaaS를 만들 필요는 없다.

원문에서는 네 가지 Shape로 분류한다.

① Tool

현재 쓰는 Software에 대한 불만이 반복될 때.

기존 제품 전체를 복제
X

불만이 집중된 기능 하나
O

Micro SaaS 형태다.

---

② Service

Job Posting 또는 Freelance Brief가 반복될 때.

기업이 이미 사람에게 맡기고 있는 Outcome을 자동화한다.

예:

Permit Runner

↓

AI + Workflow Automation

↓

Permit Processing Service

---

③ Physical Product

문제가 Screen 밖에서 발생한다면 물리 상품도 가능하다.

예:

작업 현장
매장
창고
차량

---

④ Information Product

반복적으로 동일한 질문이 등장하고 해결책이 지식이라면 정보 상품이다.

Guide
Template
Checklist
Database
Course
Report

---

18. 첫 번째 고객은 이미 데이터베이스에 있다

이 구조에서 상당히 흥미로운 점이다.

Problem Discovery 과정에서 이미 다음 사람들을 찾았다.

문제를 말한 사람
Job Posting을 올린 회사
Freelance Job을 발주한 사람
부정적 SaaS Review 작성자

즉 고객 Discovery와 Problem Discovery가 동시에 일어난다.

따라서 첫 Outreach 대상은:

Cluster Evidence
        ↓
Prospect List

에서 생성한다.

---

19. 그러나 Outreach는 자동 실행하지 않는다

원문에서도 사람에게 연락하거나 돈을 쓰는 행동에는 별도 승인을 둔다.

좋은 Permission Model이다.

Agent 자동 허용

Research
Problem extraction
Clustering
Landing page 작성
Prospect list 작성
Draft 작성
Dashboard 업데이트

Human Approval 필요

Email 전송
DM 전송
광고 집행
우편 발송
결제
가격 변경
환불
송금
외부 게시

즉:

AI can prepare.
Human authorizes irreversible actions.

라는 구조다.

---

20. 모든 사업에는 Kill Metric이 있어야 한다

사업을 시작한 뒤 AI가 계속 낙관적으로 해석하는 것을 막기 위한 장치다.

예:

14일

300명 Landing Page 방문

Checkout Click < 3

Payment = 0

→ Kill

또는

Outreach 100
Reply < 5
Qualified Lead < 2

→ Kill

제품을 만들기 전에 Kill Metric을 정의한다.

이렇게 해야 결과를 사후적으로 합리화하지 않는다.

---

21. Outcome이 다시 Discovery Engine으로 돌아간다

전체 시스템에서 가장 중요한 Feedback Loop다.

Idea
↓
Build
↓
Sell
↓
Outcome
↓
Scoring Engine

예를 들어

Roofing Lead Tool
Score 88
↓
Launch
↓
0 Sales
↓
Killed

결과를 저장한다.

다음에 유사한 Candidate가 나타나면:

Previous failure pattern

으로 반영한다.

반대로:

HVAC Dispatch
Score 86
↓
5 Customers
↓
MRR 발생

한다면 비슷한 특성을 가진 문제의 Score를 높일 수 있다.

이렇게 시스템이 점점 자신의 경험 데이터를 갖게 된다.

---

22. 전체 Cron 구조

예를 들면 다음과 같다.

07:00
System 1
Jobs / Reviews / Freelance

08:00
System 4
Forums / Reddit

08:30
System 5
Product Hunt / GitHub / HN

Every 2 Hours
System 3
News / Regulation / Weather / Permit

Event Driven
System 2
YouTube / Podcast RSS

23:00
Embedding
Clustering
Scoring
Verdict Learning

23:30
Obsidian Update
Dashboard Update

07:30
Morning Brief

---

23. Morning Brief

사람에게는 Raw Data를 전달하지 않는다.

예:

Morning Brief — 2026-08-26

NEW CANDIDATE

HVAC Emergency Technician Marketplace

Score: 86
Systems: 3

Evidence
- Job postings
- HVAC forum
- Upwork

Why now
Heat wave increased emergency callouts.

Expected customer
10~50 technician HVAC shop.

NEXT ACTION

Review proposal.

아무것도 변하지 않았다면:

No meaningful changes today.

한 줄로 끝낸다.

---

24. 구현한다면 Grok에 종속시킬 필요는 없다

이 글에서는 Grok Bot을 중심으로 설명하지만 구조 자체는 특정 LLM과 독립적이다.

예를 들어 다음 구조로 만들 수 있다.

                    ┌───────────────┐
                    │ Data Sources  │
                    └───────┬───────┘
                            ↓
                 ┌───────────────────┐
                 │ Collector Workers │
                 └─────────┬─────────┘
                           ↓
                     PostgreSQL
                           +
                     pgvector
                           ↓
                 Problem Extractor
                           ↓
                     Cluster Engine
                           ↓
                    Scoring Engine
                           ↓
               ┌────────────────────┐
               │ Decision Dashboard │
               └─────────┬──────────┘
                         ↓
                      Pursue
                         ↓
                 Business Agent
                         ↓
             Landing / Checkout Test
                         ↓
                   Sales Outcome
                         ↓
                 Feedback Engine

LLM은 다음 중 무엇이든 사용할 수 있다.

GPT
Claude
Gemini
Grok
Local LLM

핵심 자산은 모델이 아니라:

데이터
+
Cluster history
+
Verdicts
+
Outcomes

이다.

---

25. 현실적으로 가장 먼저 만들어야 할 MVP

처음부터 글의 모든 기능을 구현하는 것은 과도하다.

MVP라면 다음 6개만 있으면 된다.

1단계

Reddit / Forum
Jobs
App Reviews

3개 Source만 수집한다.

2단계

LLM으로 Problem extraction.

3단계

pgvector로 Clustering.

4단계

다음 세 요소만 Scoring.

Source diversity
Dollar evidence
Severity

5단계

Decision Dashboard.

Pursue
Watch
Kill

6단계

Pursue하면 자동으로:

Landing Page Draft
Pricing Proposal
Customer List
Validation Plan

까지만 생성한다.

실제 결제·연락·광고는 사람이 승인한다.

이 정도만 만들어도 원문 시스템의 핵심 가설을 검증할 수 있다.

---

결론

이 글에서 가장 중요한 것은 “Grok으로 사업을 자동으로 여러 개 돌릴 수 있다”는 화려한 문장이 아니다.

더 중요한 부분은 그 앞단의 구조다.

Search
↓
Evidence
↓
Convergence
↓
Filter
↓
Human Decision
↓
Experiment
↓
Revenue
↓
Outcome
↓
Learning

보통 AI 사업 아이디어 시스템은:

AI
↓
아이디어 100개

에서 끝난다.

이 시스템은 반대로:

인터넷 수백 개 Signal
↓
실제 문제 수십 개
↓
Cluster 수십 개
↓
검증된 Candidate 1~2개
↓
시장 테스트

를 목표로 한다.

그래서 이것을 단순한 AI 사업 자동화 Bot이라고 보는 것보다,

Continuous Problem Discovery + Evidence-based Venture Factory

또는

AI Revenue Discovery Engine

이라고 보는 것이 기술적으로 훨씬 정확하다.

그리고 이 구조에서 장기적으로 가장 가치 있는 것은 Agent도 Dashboard도 아니다.

결국 축적되는 핵심 자산은 다음 네 가지다.

1. 어떤 문제가 반복해서 발생했는가
2. 어떤 증거가 실제 매출로 이어졌는가
3. 어떤 아이디어를 왜 죽였는가
4. 어떤 유형의 사업이 실제로 돈을 벌었는가

이 데이터가 계속 축적되면 단순한 인터넷 모니터링 시스템이 아니라 자신의 사업 경험을 학습하는 개인용 Venture Intelligence System으로 발전할 수 있다.

출처 :

X에서 Chris(@everestchris6) 님