목표: 대표의 머릿속을 팀의 운영체제로 바꾸기
스타트업의 지식은 처음부터 문서에 있지 않다. 대표의 머릿속, 고객 인터뷰 녹취, 슬랙 대화, 세일즈 메모, 회의록, 피그마 댓글, 노션 임시 페이지에 흩어져 있다. 문제는 흩어져 있다는 사실 자체가 아니다. 시간이 지나면 왜 그런 결정을 했는지, 어떤 고객이 그 기능을 원했는지, 무엇을 실험했고 무엇을 포기했는지 잊힌다는 점이다.
이번 프로젝트의 목표는 제품 비전, 기능 기획, 고객 피드백, 회의록, 의사결정을 하나의 운영 위키로 묶는 것이다. 거창한 사내 포털을 만들 필요는 없다. 작은 팀이라면 Obsidian 호환 Markdown 폴더와 Git 변경 이력만으로도 충분하다. 핵심은 원문을 보존하고, AI가 그 위에 운영 지식층을 계속 갱신하게 만드는 것이다. Karpathy가 제안한 LLM Wiki 패턴의 핵심도 여기에 있다. 원문은 그대로 두고, LLM이 별도의 Markdown 위키를 만들며, Schema가 그 작업 규칙을 정한다1.
1단계: 폴더 구조 만들기
먼저 프로젝트 루트에 다음 구조를 만든다.
startup-wiki/
raw/
meetings/
interviews/
sales/
cs/
research/
competitors/
assets/
wiki/
product/
customers/
features/
feedback/
competitors/
experiments/
decisions/
onboarding/
outputs/
weekly-reviews/
lint-reports/
index.md
log.md
AGENTS.md 또는 CLAUDE.mdraw/는 증거 보관함이다. 회의록 원문, 고객 인터뷰 전문, CS 티켓, 세일즈 메모, 경쟁사 캡처, 리서치 문서를 넣는다. 원문은 수정하지 않는다.
wiki/는 AI가 읽고 정리하고 연결하는 운영 지식층이다. 여기에는 요약, 비교, 판단, 링크, 현재 상태가 들어간다. 예를 들어 고객 인터뷰 한 건은 raw/interviews/에 그대로 보관하고, 그 인터뷰에서 나온 기능 요청은 wiki/feedback/, 관련 기능은 wiki/features/, 관련 고객 세그먼트는 wiki/customers/에 반영한다.
index.md는 전체 지도다. 어떤 페이지가 어디에 있는지, 한 줄 요약은 무엇인지 적는다. log.md는 시간순 기록이다. 어떤 자료를 넣었고, 어떤 페이지가 바뀌었고, 어떤 미결 쟁점이 생겼는지 남긴다.
2단계: 핵심 페이지 6개부터 시작하기
처음부터 모든 페이지를 만들려고 하면 실패한다. 스타트업 운영 위키는 다음 여섯 페이지에서 시작하면 된다.
wiki/product/product-vision.md
wiki/customers/customer-segments.md
wiki/features/feature-roadmap.md
wiki/feedback/customer-feedback-index.md
wiki/competitors/competitor-map.md
wiki/decisions/decision-log.mdproduct-vision.md에는 제품이 해결하려는 문제, 핵심 고객, 하지 않을 일, 성공 지표를 쓴다. 이 페이지는 모든 기획의 기준점이다.
customer-segments.md에는 고객군을 나눈다. 단순히 B2B, B2C처럼 나누지 말고 사용 맥락으로 나눈다. 예를 들어 '대표가 직접 세일즈하는 5인 이하 팀', '고객지원 요청이 많은 SaaS 팀', '문서화가 무너진 개발팀'처럼 적는다.
feature-roadmap.md는 기능 목록이 아니라 판단의 지도여야 한다. 각 기능마다 연결된 고객 문제, 근거가 된 인터뷰, 현재 상태, 담당자, 다음 액션을 적는다.
customer-feedback-index.md는 고객의 목소리를 한곳에 모으는 페이지다. 기능 요청, 불만, 구매 신호, 가격 저항, 사용 맥락, 경쟁 제품 언급을 분류한다.
competitor-map.md는 경쟁사를 표로만 정리하지 않는다. 고객이 우리와 경쟁사를 어떤 기준으로 비교하는지, 경쟁사가 강한 상황과 약한 상황을 함께 적는다.
decision-log.md는 가장 중요하다. 결정은 의견과 다르다. 의견은 토론 중 나온 주장이고, 결정은 팀이 실제로 따르기로 한 선택이다. 이 둘이 섞이면 나중에 AI도 사람도 헷갈린다.
3단계: 회의록 ingest 워크플로 만들기
스타트업 위키에서 가장 먼저 자동화할 자료는 회의록이다. 회의는 결정이 생기는 곳이고, 결정은 시간이 지나면 가장 빨리 사라진다.
회의가 끝나면 원문을 raw/meetings/2026-05-19-growth-weekly.md처럼 저장한다. 그런 다음 AI에게 다음과 같이 요청한다.
raw/meetings/2026-05-19-growth-weekly.md를 ingest하라.
다음 항목을 추출하라.
- 논의 주제
- 결정 사항
- 미결 쟁점
- 담당자
- 마감일
- 후속 액션
- 관련 기능
- 관련 고객 세그먼트
- 관련 의사결정 로그
단순 요약으로 끝내지 말고, 필요한 wiki 페이지를 함께 업데이트하라.
원문은 수정하지 마라.
변경한 페이지 목록을 log.md에 남겨라.
모순이나 출처 없는 주장은 별도 표시하라.좋은 회의록 ingest는 한 파일만 만들지 않는다. 보통 5~10개 페이지를 건드린다. 예를 들어 회의에서 '무료 플랜을 유지하되 사용량 제한을 둔다'는 결정이 나왔다면 다음 페이지가 함께 바뀐다.
wiki/decisions/decision-log.md
wiki/product/pricing-principles.md
wiki/features/free-plan-limits.md
wiki/customers/customer-segments.md
wiki/experiments/pricing-experiments.md
log.md이때 AI가 할 일은 회의록을 예쁘게 요약하는 것이 아니다. 결정이 제품 비전, 고객 정의, 기능 계획, 실험 로그와 어떻게 연결되는지 갱신하는 것이다.
4단계: 고객 피드백을 제품 지식으로 바꾸기
고객 피드백은 스타트업 위키의 연료다. 하지만 원문 그대로 쌓아두면 나중에 찾기 어렵다. 고객 인터뷰, CS 기록, 세일즈 메모, 이탈 사유를 다음 기준으로 분류한다.
| 분류 | 설명 | 연결할 페이지 |
|---|---|---|
| 기능 요청 | 고객이 명시적으로 원한 기능 | wiki/features/ |
| 불만 | 현재 제품에서 막힌 지점 | wiki/feedback/ |
| 구매 신호 | 돈을 낼 가능성을 보인 표현 | wiki/customers/, wiki/sales/ |
| 가격 저항 | 비싸다, 예산이 없다, 가치가 불명확하다는 반응 | wiki/product/pricing-principles.md |
| 사용 맥락 | 언제, 누구와, 어떤 상황에서 쓰는지 | wiki/customers/ |
| 경쟁 제품 언급 | 대안으로 비교한 도구 | wiki/competitors/ |
예를 들어 한 고객이 '회의록은 많은데 다음 주에 뭘 해야 하는지 다시 정리해야 해서 힘들다'고 말했다면, 이는 단순 불만이 아니다. 회의록 ingest, 후속 액션 추출, 팀 위키 자동 갱신, 온보딩 문서 자동화와 연결될 수 있다.
피드백 페이지에는 반드시 링크를 남긴다.
## 피드백 요약
고객은 회의 후 액션 아이템이 흩어지는 문제를 반복해서 언급했다.
## 분류
- 유형: 불만, 기능 요청
- 세그먼트: [[early-stage-b2b-saas-team]]
- 관련 기능: [[meeting-ingest-workflow]], [[action-item-tracker]]
- 관련 실험: [[weekly-meeting-summary-experiment]]
- 원문: raw/interviews/2026-05-18-customer-a.md
## 제품 해석
이 문제는 단순 회의록 요약보다 '결정과 후속 액션을 운영 페이지에 반영하는 기능'에 가깝다.이렇게 해야 피드백이 쌓일수록 제품 판단이 쉬워진다. 같은 기능 요청이 여러 세그먼트에서 반복되는지, 특정 고객군에서만 강하게 나타나는지, 구매 신호와 연결되는지 볼 수 있다.
5단계: AGENTS.md에 운영 규칙 쓰기
AI에게 스타트업 위키를 맡기려면 규칙이 필요하다. Claude Code의 CLAUDE.md처럼 프로젝트별 맥락 파일은 에이전트가 매번 같은 설명을 듣지 않고도 구조, 규칙, 워크플로를 이해하게 해준다2. Codex나 다른 에이전트를 쓴다면 AGENTS.md로 같은 역할을 만들면 된다.
다음 규칙부터 넣는다.
## Startup Wiki Rules
### 원문 보존
- raw/ 아래 파일은 수정하지 않는다.
- 원문에서 가져온 사실은 파일 경로를 남긴다.
### 결정과 의견 구분
- 결정 사항은 wiki/decisions/decision-log.md에 기록한다.
- 회의 중 나온 주장이나 아이디어는 결정으로 쓰지 않는다.
- 결정에는 날짜, 배경, 선택지, 최종 선택, 담당자, 후속 액션을 포함한다.
### 출처와 신뢰성
- 출처 없는 주장은 [출처 필요]로 표시한다.
- 고객 발언, 매출 수치, 경쟁사 정보는 원문 링크를 남긴다.
- 추정과 사실을 구분한다.
### 모순 처리
- 새 자료가 기존 페이지와 충돌하면 임의로 덮어쓰지 않는다.
- 충돌 내용을 log.md에 남기고 사람 검토를 요청한다.
### 민감 정보
- 개인정보, 계약 조건, 내부 재무 정보는 공개용 페이지에 쓰지 않는다.
- 민감 정보가 필요하면 요약하거나 익명화한다.특히 고객 정보와 사내 기밀은 조심해야 한다. OWASP의 LLM 애플리케이션 보안 가이드도 민감정보가 입력·출력 과정에서 노출될 수 있음을 경고하며, 데이터 삭제·스크러빙, 입력 검증, 외부 데이터 소스 접근 제한, 최소 권한 원칙 같은 보호 장치를 권장한다3.
6단계: 온보딩 문서를 자동 생성하기
많은 팀이 온보딩 문서를 별도로 만든다. 문제는 별도 문서는 빨리 낡는다는 것이다. 스타트업에서는 제품 방향, 고객 정의, 실험, 가격 정책이 자주 바뀐다. 그래서 온보딩 문서를 고정 문서로 쓰기보다, 위키의 핵심 페이지를 연결해 생성하는 방식이 좋다.
wiki/onboarding/new-member-guide.md에는 긴 설명을 직접 쓰지 않는다. 다음 링크를 모은다.
## 신규 팀원이 먼저 읽을 것
1. [[product-vision]]
2. [[customer-segments]]
3. [[feature-roadmap]]
4. [[customer-feedback-index]]
5. [[competitor-map]]
6. [[decision-log]]
7. [[current-experiments]]
8. [[team-faq]]
## AI에게 요청할 온보딩 브리핑
위 페이지들을 읽고, 신규 팀원을 위한 30분 온보딩 브리핑을 작성하라.
최근 30일 결정 사항과 현재 진행 중인 실험을 우선 반영하라.이 구조의 장점은 분명하다. 제품 비전이 바뀌면 온보딩 문서를 따로 고칠 필요가 없다. 원천 페이지가 바뀌고, 온보딩 브리핑은 그 최신 내용을 바탕으로 다시 생성된다.
7단계: 주간 lint 루틴으로 위키를 건강하게 유지하기
운영 위키는 방치하면 금방 낡는다. 그래서 매주 한 번 lint를 실행한다. lint는 코드 검사처럼 위키의 건강 상태를 점검하는 작업이다.
요청은 간단하다.
이번 주 스타트업 위키를 lint하라.
다음 항목을 점검하라.
- 오래된 주장
- 서로 모순되는 페이지
- 출처 없는 고객 주장
- 담당자 없는 후속 액션
- 마감일이 지난 액션 아이템
- 중복 기능 페이지
- 링크가 없는 핵심 페이지
- 결정 로그에 반영되지 않은 회의 결정
결과를 outputs/lint-reports/2026-05-19.md에 저장하라.
자동 수정 가능한 것은 제안하고, 중요한 변경은 사람 승인을 요청하라.작은 팀에서 중요한 원칙은 'AI가 정리하고 사람이 승인한다'이다. AI에게 모든 결정을 맡기지 않는다. AI는 누락, 중복, 모순, 오래된 정보를 찾아준다. 사람은 무엇을 유지하고 무엇을 버릴지 판단한다.
Git을 함께 쓰면 변경 이력을 볼 수 있다. AI가 어떤 페이지를 수정했는지 diff로 확인하고, 문제가 있으면 되돌릴 수 있다. Markdown 위키의 장점은 여기에 있다. Obsidian은 Markdown 파일을 기반으로 동작하고 내부 링크와 그래프 뷰를 제공하므로, 사람이 읽기에도 좋고 AI가 수정하기에도 단순하다4.
완성 기준
이 프로젝트가 제대로 작동하는지 확인하는 기준은 예쁜 문서가 아니다. 다음 질문에 답할 수 있어야 한다.
우리는 지금 어떤 고객을 위해 만들고 있는가?
최근 30일 동안 어떤 결정을 했는가?
그 결정의 근거가 된 고객 발언은 어디에 있는가?
가장 많이 반복되는 불만은 무엇인가?
지금 진행 중인 실험은 무엇이고 담당자는 누구인가?
신규 팀원이 들어왔을 때 30분 안에 제품 맥락을 이해할 수 있는가?
이 질문에 답할 수 있다면 스타트업 운영 위키는 이미 효과를 내고 있다. 작은 팀은 지식 관리 전담자를 둘 수 없다. 하지만 AI를 위키 관리자로 두고, 사람은 원문 선택과 최종 판단을 맡을 수 있다.
스타트업은 속도가 중요하다. 그러나 속도는 기억을 희생해서 얻는 것이 아니다. 회의, 고객, 기능, 결정이 하나의 위키에 쌓이면 팀은 매번 처음부터 설명하지 않는다. 어제의 판단이 오늘의 실행을 돕고, 오늘의 피드백이 내일의 제품 방향을 바꾼다. 이것이 작은 팀이 지식을 잃지 않고 빠르게 움직이는 방법이다.
참고
2Using CLAUDE.md files: Customizing Claude Code for your codebase
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.