스타트업과 1인 기업가를 위한 LLM Wiki

사업 지식은 어디에서 사라지는가

스타트업과 1인 기업가의 가장 큰 문제는 정보가 없다는 것이 아니다. 정보가 너무 많고, 너무 빨리 흩어진다는 것이다.

제품 아이디어는 대표의 메모장에 있다. 고객 피드백은 카카오톡, 이메일, 슬랙, 녹취 파일, CRM에 나뉘어 있다. 경쟁사 정보는 브라우저 북마크와 스크린샷 폴더에 있다. 마케팅 실험 결과는 광고 관리자 화면과 회의록 어딘가에 남는다. 중요한 의사결정은 회의 중에는 분명했지만, 한 달 뒤에는 "왜 그렇게 했더라?"라는 질문만 남는다.

LLM Wiki는 이 흩어진 조각들을 하나의 사업 지식으로 바꾸는 장치다. 단순히 문서를 예쁘게 정리하는 것이 아니다. 사업을 운영하면서 반복해서 묻는 질문에 답할 수 있는 구조를 만드는 일이다.

예를 들면 이런 질문들이다.

• 우리는 정확히 어떤 고객 문제를 풀고 있는가?

• 이 기능은 누구의 어떤 불편에서 나온 것인가?

• 고객들이 반복해서 말하는 불만은 무엇인가?

• 경쟁사는 우리보다 무엇을 더 잘 설명하고 있는가?

• 지난번 마케팅 실험은 왜 실패했는가?

• 이미 버린 아이디어를 왜 다시 검토하고 있는가?

이 질문에 답하지 못하면 팀은 매번 처음부터 토론한다. 반대로 이 질문에 답할 수 있는 위키가 있다면, 작은 팀도 큰 조직처럼 학습할 수 있다.

사업을 페이지 단위로 나누기

스타트업 위키의 기본 단위는 문서가 아니라 사업 판단이다. 그래서 폴더를 만들 때도 부서별로 나누기보다, 사업을 이해하는 데 필요한 핵심 지식 단위로 나누는 편이 좋다.

처음에는 다음 정도면 충분하다.

• wiki/business/product-vision.md: 제품 비전

• wiki/business/customer-problems.md: 고객 문제 목록

• wiki/business/core-hypotheses.md: 핵심 가설

• wiki/features/: 기능 아이디어와 기획

• wiki/customers/: 고객 인터뷰와 세그먼트

• wiki/competitors/: 경쟁사 분석

• wiki/marketing/experiments/: 마케팅 실험 로그

• wiki/decisions/: 의사결정 기록

• wiki/sales/objections.md: 영업 과정에서 나온 반대 의견

중요한 것은 처음부터 완벽한 회사 위키를 만들려고 하지 않는 것이다. 스타트업 위키는 백과사전이 아니다. 지금 사업 판단에 영향을 주는 정보부터 담아야 한다.

제품 비전 페이지에는 거창한 문장이 아니라 판단 기준이 있어야 한다. 예를 들어 다음 항목을 넣을 수 있다.

• 우리가 돕는 고객

• 고객이 겪는 핵심 문제

• 기존 대안이 부족한 이유

• 우리가 제공하는 새로운 방식

• 지금은 하지 않기로 한 것

• 비전을 뒷받침하는 고객 근거

• 아직 검증되지 않은 가정

이 구조가 있으면 LLM에게 단순히 "우리 서비스 소개문 써줘"라고 묻지 않아도 된다. 위키를 읽게 한 뒤 "현재 제품 비전과 충돌하지 않는 랜딩페이지 문구를 제안해줘"라고 요청할 수 있다. 답변의 품질은 훨씬 좋아진다. AI가 사업의 맥락을 갖게 되기 때문이다.

기능 아이디어를 가설로 관리하기

많은 팀이 기능 목록을 쌓는다. 하지만 기능 목록만으로는 사업이 학습하지 않는다. "이 기능을 만들자"는 말보다 중요한 것은 "왜 이 기능이 필요하다고 생각했는가"다.

LLM Wiki에서는 기능 아이디어를 하나의 가설 페이지로 다루는 것이 좋다. 기능 페이지에는 최소한 다음 항목이 들어가야 한다.

• 기능 이름

• 대상 고객

• 해결하려는 문제

• 이 기능이 필요하다고 판단한 근거

• 관련 고객 인터뷰 또는 피드백 링크

• 기대하는 행동 변화

• 성공 지표

• 구현 난이도

• 리스크

• 현재 상태: 아이디어, 검토 중, 실험 중, 개발 중, 보류, 폐기

예를 들어 "자동 리포트 생성 기능"이라는 아이디어가 있다고 하자. 나쁜 기록은 "고객이 원해서 필요함"이라고 적는 것이다. 좋은 기록은 더 구체적이다.

고객은 매주 반복 보고서를 만드는 데 2시간 이상을 쓴다. 특히 데이터 수집보다 문장화에 시간을 많이 쓴다. 세 번의 인터뷰에서 같은 불편이 나왔다. 다만 실제로 돈을 낼 의향은 아직 확인되지 않았다. 그래서 먼저 수동 리포트 대행 형태로 수요를 검증한다.

이렇게 적으면 기능은 단순한 할 일에서 검증 가능한 사업 가설로 바뀐다. 나중에 기능을 만들지 않기로 해도 그 결정은 사라지지 않는다. "왜 안 만들었는지"가 남는다.

고객 인터뷰를 지식으로 바꾸기

고객 인터뷰는 스타트업의 원유와 같다. 하지만 원유 상태로 쌓아두기만 하면 쓸 수 없다. 녹취록과 회의록은 raw에 보관하고, LLM은 그 안에서 반복 패턴을 추출해 wiki를 업데이트해야 한다.

고객 인터뷰를 넣을 때는 요약만 만들지 말고, 다음 정보를 뽑아내게 해야 한다.

• 고객 유형

• 고객이 말한 문제

• 현재 사용 중인 대안

• 불편을 해결하기 위해 쓰는 비용 또는 시간

• 구매 의향의 강도

• 반복해서 나온 표현

• 언급된 경쟁 제품

• 기능 요청

• 영업 과정의 반대 의견

• 새로 생긴 질문

여기서 핵심은 "한 명의 의견"과 "반복 패턴"을 구분하는 것이다. 한 고객이 강하게 말한 요구를 전체 시장의 요구로 착각하면 제품 방향이 흔들린다. 따라서 LLM에게 다음 규칙을 주면 좋다.

• 단일 인터뷰에서 나온 의견은 단일 사례로 표시한다.

• 두 명 이상에게서 반복된 내용은 패턴 후보로 표시한다.

• 세그먼트가 다른 고객의 의견은 섞지 않는다.

• 고객의 실제 표현과 AI의 해석을 분리한다.

• 기능 요청 뒤에 있는 근본 문제를 별도로 추출한다.

예를 들어 고객이 "대시보드에 엑셀 다운로드 버튼이 있으면 좋겠어요"라고 말했다고 하자. 이것을 곧바로 기능 요청으로만 기록하면 위험하다. 실제 문제는 "상사가 엑셀 파일로 보고받기를 원한다"일 수도 있고, "기존 내부 프로세스가 엑셀 중심이다"일 수도 있다. 그러면 해결책은 다운로드 버튼이 아니라 자동 보고 메일, 공유 링크, 사내 템플릿 연동일 수도 있다.

LLM Wiki의 장점은 이런 분리를 계속 누적할 수 있다는 점이다. 고객 발언은 raw에 남기고, 위키에는 문제, 맥락, 가설, 기능 후보를 나누어 기록한다.

경쟁사 분석은 스냅샷이 아니라 변화 추적이다

경쟁사 분석을 한 번 하고 끝내는 팀이 많다. 하지만 시장에서 중요한 것은 현재 상태뿐 아니라 변화의 방향이다. 경쟁사가 가격을 바꾸었는지, 메시지를 바꾸었는지, 특정 고객군을 더 강하게 겨냥하기 시작했는지를 추적해야 한다.

경쟁사 위키는 회사별 페이지와 비교 페이지를 함께 운영하는 방식이 좋다.

회사별 페이지에는 다음을 기록한다.

• 한 줄 포지셔닝

• 주요 고객

• 가격 구조

• 핵심 기능

• 강조하는 메시지

• 온보딩 방식

• 강점

• 약점 또는 빈틈

• 최근 변화

• 출처 raw 링크

비교 페이지에는 여러 경쟁사를 나란히 놓고 본다.

• 가격 비교

• 기능 비교

• 타깃 고객 비교

• 마케팅 메시지 비교

• 무료 플랜 또는 체험 정책 비교

• 우리가 피해야 할 포지션

• 우리가 차별화할 수 있는 지점

여기서 LLM의 역할은 표를 예쁘게 만드는 것이 아니다. 변화와 빈틈을 발견하는 것이다. 예를 들어 매달 경쟁사 페이지를 갱신한 뒤 이렇게 물을 수 있다.

• 지난달과 비교해 메시지가 바뀐 경쟁사는 누구인가?

• 최근 경쟁사들이 공통으로 강조하기 시작한 기능은 무엇인가?

• 가격 정책에서 우리가 불리한 지점은 어디인가?

• 경쟁사들이 아직 명확히 설명하지 못하는 고객 문제는 무엇인가?

이런 질문은 단순 검색으로는 어렵다. 시간이 지나며 쌓인 위키가 있어야 답할 수 있다.

마케팅 실험은 실패 이유까지 기록해야 한다

마케팅 실험은 자주 사라진다. 광고를 돌렸고, 클릭률이 낮았고, 전환이 안 되었고, 그래서 중단했다. 여기까지만 남으면 아무것도 배운 것이 없다. 다음 달에 다른 사람이 비슷한 메시지로 같은 실험을 반복한다.

마케팅 실험 로그에는 결과보다 해석이 중요하다. 최소한 다음 항목을 남긴다.

• 실험 이름

• 실험 날짜

• 목표 고객

• 채널

• 메시지

• 가설

• 사용한 소재

• 예산 또는 투입 시간

• 성공 기준

• 실제 결과

• 실패 또는 성공에 대한 해석

• 다음 행동

• 관련 의사결정 링크

예를 들어 "창업자를 대상으로 한 뉴스레터 광고"가 실패했다면, 단순히 "전환율 낮음"으로 끝내면 안 된다. 실패 원인을 나누어야 한다.

• 고객군이 맞지 않았는가?

• 메시지가 약했는가?

• 제안이 모호했는가?

• 랜딩페이지가 설득하지 못했는가?

• 가격 장벽이 있었는가?

• 아직 문제 인식이 낮은 고객이었는가?

LLM에게 실험 로그와 고객 인터뷰, 랜딩페이지 문구를 함께 읽게 하면 더 좋은 질문을 만들 수 있다. "이 실험은 채널 실패인가, 메시지 실패인가, 고객 세그먼트 실패인가?"처럼 판단을 돕는 질문이다.

스타트업에서 실험은 많이 하는 것보다 제대로 배우는 것이 중요하다. LLM Wiki는 실험을 기억하게 만든다.

의사결정 기록은 미래의 팀원을 위한 설명이다

사업을 하다 보면 모든 결정이 당시에는 합리적으로 보인다. 하지만 시간이 지나면 맥락이 사라진다. 가격을 왜 이렇게 정했는지, 특정 기능을 왜 미뤘는지, 어떤 고객군을 왜 포기했는지 알 수 없게 된다.

그래서 중요한 결정은 별도의 의사결정 기록으로 남겨야 한다. 긴 문서가 필요하지 않다. 다음 항목이면 충분하다.

• 결정한 내용

• 결정 날짜

• 당시 상황

• 검토한 선택지

• 선택한 이유

• 포기한 것

• 기대한 효과

• 우려한 리스크

• 다시 검토할 시점

• 관련 고객 피드백, 실험, 경쟁사 정보 링크

이 문서의 목적은 책임자를 찾는 것이 아니다. 나중에 같은 문제를 다시 만났을 때 더 나은 판단을 하기 위해서다.

예를 들어 "엔터프라이즈 고객보다 1인 사업자를 먼저 공략한다"는 결정을 했다고 하자. 이 결정에는 반드시 이유가 있어야 한다. 영업 주기가 짧아서인지, 제품 구현 범위가 작아서인지, 대표가 직접 고객을 만날 수 있어서인지, 가격 실험이 쉬워서인지 기록해야 한다. 그래야 나중에 엔터프라이즈 문의가 왔을 때 흔들리지 않는다. 또는 상황이 바뀌었을 때 무엇이 바뀌었기 때문에 결정을 재검토하는지 알 수 있다.

대표의 머릿속을 팀 지식으로 바꾸기

초기 스타트업에서는 대표의 머릿속이 가장 큰 데이터베이스다. 고객에 대한 직감, 시장에 대한 판단, 제품 방향, 투자자와의 대화, 팀원에게 아직 말하지 않은 고민이 모두 그 안에 있다.

문제는 머릿속 지식은 공유되지 않는다는 것이다. 대표가 바쁘면 팀은 맥락 없이 실행한다. 팀원이 늘어나면 같은 설명을 반복해야 한다. 외주 개발자나 새 팀원이 들어오면 온보딩에 많은 시간이 든다.

LLM Wiki를 쓰면 대표의 생각을 작은 단위로 외부화할 수 있다. 가장 쉬운 방법은 주 2~3회 음성 메모를 남기는 것이다. 형식은 거칠어도 된다.

• 오늘 고객 미팅에서 느낀 점

• 지금 가장 걱정되는 가설

• 최근 경쟁사에 대해 든 생각

• 이번 주에 하지 않기로 한 일

• 팀에 설명해야 할 맥락

이 메모를 raw에 넣고 LLM에게 위키 업데이트를 맡긴다. AI는 제품 비전, 고객 문제, 기능 아이디어, 의사결정 로그 중 어디를 갱신해야 하는지 제안한다. 사람은 그 제안을 검토하고 승인한다.

이 과정을 반복하면 대표의 직감이 문서가 된다. 문서가 쌓이면 팀의 판단 기준이 된다.

1인 기업가에게 더 필요한 이유

LLM Wiki는 팀이 있는 스타트업에만 필요한 도구가 아니다. 오히려 1인 기업가에게 더 강력할 수 있다. 혼자 일할수록 기억에 의존하기 쉽고, 동시에 모든 역할을 혼자 맡아야 하기 때문이다.

1인 기업가는 제품 기획자이자 마케터이고, 영업 담당자이며, 고객지원 담당자다. 오늘은 콘텐츠를 만들고, 내일은 고객 문의에 답하고, 모레는 가격 정책을 바꾼다. 이때 위키가 없으면 모든 일이 임기응변이 된다.

LLM Wiki는 혼자 일하는 사람에게 가상의 운영팀처럼 작동한다.

• 고객 피드백을 모아 반복 문제를 보여준다.

• 콘텐츠 아이디어를 제품 가설과 연결한다.

• 매출이 발생한 이유와 발생하지 않은 이유를 기록한다.

• 버린 아이디어를 다시 꺼낼 때 과거 판단을 보여준다.

• 다음 주에 집중할 실험을 제안한다.

물론 AI가 대표를 대신해 사업을 판단할 수는 없다. 하지만 판단에 필요한 맥락을 정리해줄 수는 있다. 혼자 일할수록 이 차이는 크다.

운영 루틴: 매일 넣고, 매주 묶고, 매달 판단하기

사업 위키는 한 번 구축해서 끝나는 문서함이 아니다. 운영 루틴이 있어야 한다.

매일 할 일은 단순하다. 흩어진 자료를 raw에 넣는다.

• 고객 통화 메모

• 영업 미팅 요약

• 새로 떠오른 기능 아이디어

• 경쟁사 링크

• 광고 실험 결과

• 대표의 음성 메모

매주 할 일은 묶는 것이다. LLM에게 이번 주 raw를 읽고 다음을 업데이트하게 한다.

• 새로 나온 고객 문제

• 반복된 고객 표현

• 변경이 필요한 기능 페이지

• 추가된 경쟁사 정보

• 마케팅 실험 결과

• 새 의사결정 또는 보류된 결정

매달 할 일은 판단하는 것이다. 위키를 바탕으로 사업의 방향을 점검한다.

• 가장 강하게 검증된 고객 문제는 무엇인가?

• 폐기해야 할 기능 아이디어는 무엇인가?

• 계속 반복되는 영업 반대 의견은 무엇인가?

• 경쟁사 대비 우리의 설명은 충분히 선명한가?

• 지난달의 실패에서 실제로 배운 것은 무엇인가?

• 다음 달 가장 중요한 가설은 무엇인가?

이 루틴이 자리 잡으면 사업 운영은 감각만으로 굴러가지 않는다. 감각은 여전히 중요하지만, 기록과 함께 작동한다.

사업 위키의 최종 목적

스타트업과 1인 기업가를 위한 LLM Wiki의 목적은 문서를 많이 만드는 것이 아니다. 더 나은 결정을 더 빠르게 내리는 것이다.

제품 비전은 기능을 걸러내는 기준이 된다. 고객 인터뷰는 반복 패턴으로 바뀐다. 경쟁사 정보는 포지셔닝 판단에 쓰인다. 마케팅 실험 로그는 실패를 학습으로 바꾼다. 의사결정 기록은 팀이 같은 실수를 반복하지 않게 만든다.

대표의 머릿속에만 있던 지식은 개인의 기억이다. 문서함에 흩어진 지식은 아직 자산이 아니다. AI가 읽고, 연결하고, 갱신할 수 있는 위키가 되었을 때 비로소 사업 지식이 된다.

작은 팀은 모든 것을 체계화할 시간이 없다. 그래서 더더욱 LLM Wiki가 필요하다. 사람이 모든 문서를 정리하려고 하면 지속되지 않는다. 하지만 사람이 방향을 정하고 AI가 정리와 연결을 맡으면, 작은 팀도 지식을 축적하는 조직처럼 일할 수 있다.