오늘도 공부
Growth Lab 분석: Coding Agent를 ‘성장팀’으로 바꾸는 파일 기반 Growth OS 본문
GitHub - tsingyuai/growth-lab: An end-to-end growth tool that understands the product, fetch the data it needs, researches the m
An end-to-end growth tool that understands the product, fetch the data it needs, researches the market, executes campaigns, and reviews results to improve the next round of growth. 从代码到市场的开源端到端增长工具...
github.com
AI를 이용한 마케팅 도구는 이미 많다.
블로그 글을 작성하는 AI도 있고, 경쟁사를 조사하는 AI도 있으며, SNS 콘텐츠를 생성하거나 SEO 키워드를 분석해 주는 서비스도 있다.
하지만 대부분은 하나의 작업만 처리한다.
문제는 실제 Growth 업무가 하나의 작업으로 끝나지 않는다는 것이다.
제품 이해
→ 사용자와 시장 조사
→ 성장 기회 발견
→ 실행
→ 결과 측정
→ 분석
→ 다음 실험
이 사이클을 계속 반복해야 한다.
오픈소스 프로젝트 Growth Lab은 바로 이 문제를 Coding Agent를 이용해 해결하려는 프로젝트다.
Growth Lab은 자신을 자연어로 제품 운영과 사용자 성장 루프를 실행하는 도구로 설명한다. 현재 Codex와 Claude Code를 Runtime으로 사용하고, 제품 분석부터 시장 조사, 콘텐츠·SEO 실행, 결과 회고까지 하나의 지속적인 루프로 연결한다.
GitHub: tsingyuai/growth-lab
핵심 아이디어는 의외로 단순하다
Growth Lab의 구조를 한 줄로 정리하면 다음과 같다.
대화 = Control Plane
Codex / Claude Code = Runtime
Model = 성장 루프
Collector = 데이터 수집
Executor = 실행
Memory = 실행 기록
SOUL.md = 제품에 대한 장기 이해
일반적인 SaaS 방식과 상당히 다르다.
별도의 복잡한 Workflow Engine을 구축하는 대신 Coding Agent가 이미 가지고 있는 파일 읽기, 코드 수정, 웹 검색, 브라우저 조작, 명령 실행 능력을 그대로 Runtime으로 사용한다.
즉 Growth Lab 자체가 거대한 애플리케이션이라기보다는,
Coding Agent가 Growth Engineer처럼 행동하도록 만들어 놓은 방법론 + 도구 + Memory 묶음
에 더 가깝다.
1. 가장 중요한 구조: Model → Collector → Executor → Memory
Growth Lab을 이해하려면 이 네 가지 개념을 먼저 봐야 한다.
┌──────────────┐
│ Model │
│ 성장 전략/루프 │
└──────┬───────┘
│
Observe / Decide
│
┌────────────▼────────────┐
│ Collector │
│ 시장·검색·콘텐츠 데이터 수집 │
└────────────┬────────────┘
│
Evidence
│
┌──────▼───────┐
│ Model │
│ Decide │
└──────┬───────┘
│
Action
│
┌────────────▼────────────┐
│ Executor │
│ 페이지·콘텐츠·이미지·배포 │
└────────────┬────────────┘
│
Result
│
┌──────▼───────┐
│ Memory │
│ 데이터·결과·다음 행동 │
└──────────────┘
Model은 개별 도구가 아니라 하나의 완전한 성장 사이클이다.
프로젝트 문서에서도 Model을 Observation → Action → Review 루프로 정의하고 있으며, 각 Model은 자신의 전용 Memory namespace를 갖는다.
현재 공개된 주요 Model은 다음과 같다.
models/
├── onboard-growth-lab
├── run-seo-page-loop
└── xhs-replicate
여기서 중요한 것은 단순히 Skill을 여러 개 만들어놓은 것이 아니라는 점이다.
예를 들어 SEO Model은
키워드 찾아줘
로 끝나는 게 아니다.
실제 정의는 다음 사이클을 갖는다.
Read Memory
→ Observe
→ Decide
→ Act
→ Review
→ Write Memory
→ Next Observation
즉 이전 실험 결과를 읽고, 현재 검색 시장을 다시 조사하고, 하나의 행동을 선택한 다음, 실제 페이지를 만들고 배포한 후 결과까지 다시 Memory에 기록한다.
이 구조가 Growth Lab의 핵심이다.
2. SOUL.md: AI가 제품 자체를 기억한다
Growth Lab에는 특이한 파일이 하나 있다.
SOUL.md
처음에는 대략 다음과 같은 빈 템플릿이다.
Product
- Name
- One-line description
- Product form
- Stage
Users and situations
- Current users
- Candidate users
- Situations of need
- Core job to be done
Value
- Problem solved
- Core value proposition
- Differentiation
Product reality
- Available capabilities
- Website and channels
- Analytics and data
Evidence and hypotheses
- Verified facts
- Active hypotheses
- Open questions
여기서 중요한 설계 원칙이 있다.
AI가 처음 제품을 보고 모든 것을 상상해서 채워 넣지 않는다.
제품 코드를 읽고 확인할 수 있는 사실, 사용자가 직접 알려준 사실, 아직 검증되지 않은 가설을 구분한다. 프로젝트의 Runtime 지침 역시 증거가 없는 내용을 사실로 쓰지 말라고 명시한다.
따라서 시간이 지나면서 다음처럼 제품 이해가 쌓인다.
1차 실행
제품 코드 분석
↓
제품이 무엇을 하는지 확인
2차 실행
시장 조사
↓
가능성이 높은 사용자 발견
3차 실행
SEO 실험
↓
어떤 검색 의도가 실제 트래픽을 만드는지 발견
4차 실행
콘텐츠 실험
↓
어떤 가치 제안에 반응하는지 발견
그리고 이 중 장기적으로 유효한 제품 지식은 다시 SOUL.md에 들어간다.
[Inference] 이 방식은 일반적인 LLM의 대화 Memory라기보다 제품에 대한 Agent-managed knowledge state에 가깝다.
3. Memory는 채팅 기록이 아니라 Growth 실험 로그다
각 Model은 별도의 Memory를 가진다.
예를 들어 SEO라면
memory/
└── run-seo-page-loop/
샤오홍슈 성장 루프라면
memory/
└── xhs-replicate/
형태다.
여기에는 단순한 대화 요약이 아니라 다음 내용이 기록된다.
관찰 데이터
시장 조사 결과
선택한 전략
실행한 작업
게시 URL
실행 시점
Baseline
성과 데이터
분석
다음 행동
따라서 Growth Agent는 다음 실행에서 과거 실험을 다시 읽을 수 있다.
지난번에 무엇을 했지?
↓
어떤 결과가 나왔지?
↓
그때 세운 다음 가설은 무엇이었지?
↓
이번에는 무엇을 시험해야 하지?
이것이 단발성 Prompt 사용과 가장 큰 차이다.
4. Collector는 Agent의 ‘눈’ 역할을 한다
현재 저장소의 collectors/에는 다음과 같은 수집 기능이 존재한다.
bing-webmaster
media-crawler
media-crawler-bilibili
media-crawler-douyin
media-crawler-kuaishou
media-crawler-tieba
media-crawler-weibo
media-crawler-zhihu
research-product
research-seo-demand
xiaohongshu-mcp
Collector의 역할은 명확하다.
Agent가 의사결정을 내리는 데 필요한 Evidence를 가져오는 것이다.
예를 들어 SEO라면
검색 수요
검색 결과
경쟁 페이지
SERP 구조
현재 Ranking
같은 데이터를 수집할 수 있다.
콘텐츠 Growth에서는
경쟁 콘텐츠
고성과 콘텐츠
트렌드
콘텐츠 구조
사용자 반응
등을 조사한다.
그리고 Agent가 직접 검색이나 브라우저를 사용할 수 있다면 굳이 별도의 Client를 만들지 않는다.
Growth Lab은 Runtime이 이미 가진 검색·브라우저·파일·코드 기능을 우선 활용하도록 설계되어 있다.
5. Executor는 실제 행동을 담당한다
Collector가 조사 담당이라면 Executor는 실행 담당이다.
현재 공개된 Executor에는 다음과 같은 것들이 있다.
create-seo-page
generate-image
indexnow
review-seo-page
review-seo-performance
screenshot-assets
xhs-render-cards
역할이 상당히 구체적이다.
예를 들어 SEO 루프에서는 다음 흐름이 만들어진다.
research-seo-demand
↓
create-seo-page
↓
generate-image
↓
review-seo-page
↓
제품 테스트
↓
Deploy
↓
IndexNow
↓
review-seo-performance
실제 SEO Model의 Skill에도 이 실행 순서가 정의되어 있다.
여기서 특히 흥미로운 부분은 review-seo-page다.
AI에게 단순히
이 글 괜찮아?
라고 묻는 구조가 아니다.
경쟁 페이지와 검색 의도, 정보 밀도, 사용자 가치, 증거, 차별화 등을 기준으로 페이지를 다시 검토하도록 구성한다.
SEO 페이지를 만들기 전에 후보 Query마다 상위 3~5개 주요 페이지를 분석하도록 요구하며, 검색량이나 검색 결과 제목만 보고 바로 콘텐츠를 생성하는 것을 금지하고 있다.
6. SEO 자동화가 아니라 ‘SEO 학습 루프’
일반적인 SEO AI 도구의 구조는 흔히 이렇다.
Keyword
↓
AI Article
↓
Publish
Growth Lab은 훨씬 길다.
기존 Memory 확인
↓
실제 검색 수요 조사
↓
SERP 분석
↓
경쟁 페이지 구조 분석
↓
Information Gap 발견
↓
하나의 Action 결정
↓
페이지 구현
↓
페이지 검수
↓
배포
↓
IndexNow
↓
성과 측정
↓
Memory 저장
↓
다음 Action
중요한 차이는 마지막 부분이다.
Publish가 종료 지점이 아니다.
성과를 다시 읽는다.
예를 들면 다음을 본다.
Discovery
Ranking
CTR
Search Intent Fit
Content usefulness
Conversion
AI visibility
그리고 결과를 기반으로
페이지 개선
Snippet 변경
Evidence 추가
Conversion 수정
새 Supporting Page 생성
관찰 기간 연장
중 하나를 다음 행동으로 결정한다.
이것이 Growth Loop다.
7. SNS 콘텐츠도 같은 구조로 처리한다
현재 구현된 또 다른 대표 Model은 중국 SNS 플랫폼 샤오홍슈(Xiaohongshu)용 xhs-replicate다.
전체 과정은 5단계다.
① Idea 탐색
↓
② 참고 콘텐츠 선택 + 구조 분석
↓
③ 실제 제품 내용 적용
↓
④ 이미지 생성 + 자동 검사
↓
⑤ 게시 결과 회수 + 회고
여기에는 의외로 세밀한 규칙들이 들어 있다.
예를 들어 인기 게시물을 참고한다고 해서 그대로 복제하지 않는다.
Skill에서는 다음과 같은 요소만 이전하도록 제한한다.
정보 계층
Proof 영역 비율
읽기 리듬
정보 밀도
Hook 구조
반면 다음 요소는 복제하지 않는다.
브랜드
원문 Copy
제품 UI
고유 Screenshot
고유 장식
정확한 Composition
전체 카드 순서
실제 제품 기능이 없는 내용 역시 만들어내지 않도록 제한한다.
예를 들어 참고 콘텐츠가 7장짜리 카드라고 해도 실제 제품 정보가 6장밖에 없다면 6장만 만든다.
또 콘텐츠 게시 전에 자동 검사도 수행한다.
check-compliance.py
check-banned-phrases.py
전자는 과장 표현, 외부 유도, 허위 보장 등의 표현을 검사하고, 후자는 반복적인 AI 문체를 줄이기 위한 검사다.
8. 사람이 완전히 빠지는 시스템은 아니다
Growth Lab이 흥미로운 또 다른 이유가 있다.
모든 것을 자동화하려 하지 않는다.
예를 들어 계정에 민감한 게시 작업에서는 Human-assisted publishing 방식을 사용한다.
Agent가
최종 콘텐츠
이미지
채널
게시 시점
설정
링크
게시 방법
을 포함하는 Publication Package를 만들고 사람이 실제 플랫폼 UI에서 게시한다.
그 뒤 게시 URL이나 Screenshot을 다시 Agent에게 전달해 후속 분석을 진행한다.
샤오홍슈 Model 역시 자동 게시를 하지 않고 실제 게시 결과를 24시간, 48시간, 7일 시점에 Memory에 저장하도록 구성되어 있다.
즉 목표는
Human 제거
가 아니라
Human 판단이 필요한 곳만 남기기
에 가깝다.
9. 또 하나의 중요한 결정: 데이터베이스가 없다
SEO Model에는 꽤 과감한 설계 원칙이 명시돼 있다.
Create no fixed schema,
database,
dashboard,
workflow state,
or task queue.
즉 별도의
PostgreSQL
Workflow DB
Queue
Dashboard
State Machine
을 기본 구조로 만들지 않는다.
대신 파일 시스템이 상태를 담당한다.
SOUL.md
SKILL.md
references/
memory/
outputs/
[Inference] 이는 Coding Agent가 이미 파일 시스템을 자유롭게 탐색하고 수정할 수 있다는 전제에서는 상당히 합리적인 선택이다.
전통적인 서비스라면 상태를 다음처럼 구현해야 한다.
Application
↓
API
↓
Database
↓
Workflow Engine
↓
Queue
↓
Worker
Growth Lab은 많은 부분을 다음으로 압축한다.
Coding Agent
↓
Files
덕분에 구조가 극도로 단순해진다.
10. 그래서 실제 사용법도 단순하다
설치는 저장소를 Clone하는 것으로 시작한다.
git clone https://github.com/tsingyuai/growth-lab.git
cd growth-lab
그다음 Codex 또는 Claude Code에서 해당 디렉터리를 연다.
그리고 자연어로 이야기한다.
이 제품을 분석해줘.
또는
이 제품의 첫 번째 성장 루프를 실행해줘.
또는
검색 수요를 조사해서
가장 가능성 높은 SEO 페이지 하나를 만들어줘.
혹은
최근 Growth 결과를 분석하고
다음 실험을 실행해줘.
Agent는 필요한 Model을 찾아 해당 SKILL.md를 읽고, 필요한 Collector와 Executor를 선택해 실행하도록 설계되어 있다.
11. API Key 관리도 Agent 방식이다
인증 정보는 repository 내부에 저장하지 않는다.
.env.local
또는 Process Environment Variable을 사용한다.
.env와 .env.local은 Git에서 제외하도록 구성되어 있으며, 필요한 기능에 대한 Credential만 선택적으로 설정한다.
예를 들어 샤오홍슈 수집은 API Key 방식이 아니라 Local MCP 서비스와 QR 로그인을 사용하고, 로그인 상태 역시 저장소 밖에 저장하도록 설계돼 있다.
이 역시 Git repository 자체를 Growth Workspace로 사용하기 위한 설계다.
12. 이 프로젝트에서 가장 주목할 부분
[Inference] Growth Lab에서 가장 흥미로운 부분은 SEO나 SNS 기능 자체보다 Agent Application Architecture다.
최근 Agent 시스템을 만들 때 흔히 다음부터 구현한다.
Workflow Builder
Agent DB
Vector DB
Task Queue
Scheduler
Admin Dashboard
Tool Router
Memory Server
Growth Lab은 반대로 접근한다.
이미 Coding Agent가 가지고 있는 능력을 최대한 활용한다.
Reasoning → Codex / Claude Code
Tool Calling → Coding Agent
Browser → Runtime
Code Editing → Runtime
Execution → Runtime
Memory → Files
Knowledge → Markdown
Methodology → Skill
Integration → Collector / Executor
결과적으로 시스템에서 정말 필요한 부분만 남는다.
무엇을 관찰해야 하는가
무엇을 판단해야 하는가
어떤 행동을 해야 하는가
결과를 어떻게 측정해야 하는가
무엇을 다음 실행에 기억해야 하는가
즉 Agent 인프라보다 업무 방법론을 코드화하는 것에 집중한다.
13. 내가 이 프로젝트를 다시 정의한다면
[Inference] Growth Lab을 단순히
AI Growth Tool
이라고 부르는 것보다 다음 표현이 더 정확하다.
Coding Agent 위에서 실행되는 파일 기반 Growth Operating System
그리고 그 구조는 다음 공식으로 설명할 수 있다.
Agent Runtime
+
Domain Skills
+
Tools
+
Persistent Memory
+
Real-world Feedback
=
Learning Growth Agent
특히 중요한 것은 마지막의 Real-world Feedback이다.
LLM에게 계속 콘텐츠를 생성시킨다고 시스템이 발전하는 것은 아니다.
Growth Lab은 다음 사이클을 만들려고 한다.
AI가 가설 생성
↓
실제 행동
↓
실제 사용자 반응
↓
데이터 수집
↓
Memory
↓
다음 판단
이 구조가 반복되면 단순한 콘텐츠 생성기가 아니라 제품별 Growth history를 가진 Agent가 만들어진다.
결론
Growth Lab의 핵심은 AI에게 마케팅 글을 잘 쓰게 하는 것이 아니다.
Coding Agent가 제품을 이해하고 → 시장을 관찰하고 → 행동하고 → 실제 결과를 학습하도록 만드는 것이다.
이를 위해 복잡한 Agent 플랫폼 대신 상당히 단순한 구조를 선택했다.
SOUL
제품에 대한 장기 이해
Model
Observe → Act → Review 방법론
Collector
세상을 관찰하는 도구
Executor
실제 행동을 수행하는 도구
Memory
실제 실험과 결과의 기록
Codex / Claude Code
전체를 실행하는 Runtime
현재 공개 구현은 SEO 페이지 성장과 샤오홍슈 콘텐츠 성장에 집중되어 있다. README 역시 현재 SEO 페이지 루프와 샤오홍슈 수집·제작·회고 워크플로우를 주요 구현 기능으로 설명하고 있다.
[Inference] 그러나 구조 자체는 훨씬 범용적이다.
예를 들어 같은 패턴으로
YouTube Growth Model
App Store ASO Model
Instagram Growth Model
Product Hunt Launch Model
Email Marketing Model
Affiliate Growth Model
Community Growth Model
Paid Ads Model
Retention Model
같은 Model을 추가할 수 있다.
결국 Growth Lab이 보여주는 아이디어는 하나다.
AI Agent 시대에는 애플리케이션을 전부 새로 만들 필요가 없을 수도 있다.
Coding Agent 자체를 Runtime으로 사용하고, 우리가 정말 잘 만들어야 할 것은 그 위에서 실행되는 업무 방법론, 도구, 그리고 실제 결과를 기억하는 Feedback Loop일 수 있다.
'AI > 추천 오픈소스' 카테고리의 다른 글
| DuckDB 2.0, 작은 분석 DB가 서버를 향하기 시작했다 (0) | 2026.08.21 |
|---|---|
| 휴먼 디자이너를 AI 디자인 에이전트로 복제 (0) | 2026.08.21 |
| AI가 코드를 쓰는 시대, 이제 필요한 것은 ‘소프트웨어 공장’이다 (하네스) (0) | 2026.08.14 |
| Appwrite 뜯어보기: 오픈소스 BaaS는 내부에서 어떻게 동작할까? (0) | 2026.08.12 |
| 핫한 prime-agent 훝어보기 (0) | 2026.08.10 |
