AI 제품 첫 100명 사용자가 드러내는 문제는? 8가지 문제 영역과 출시 전 자체 점검

「사용자가 100명인데, 10명일 때보다 더 혼란스럽다」——많은 AI 창업 팀의 솔직한 고민입니다. 처음 10명은 친구, 클로즈드 베타, Demo Day 유입이 대부분이라 관대하고, 상상한 대로 쓰며 피드백도 정중합니다. 100명이 되면 사용자는 자기만의 쓰임을 발명하기 시작합니다. Agent를 7×24 크롤러로 쓰거나, 200MB PDF를 올려 「요약해줘」라고 하거나, ChatGPT처럼 뭐든 답해주길 기대합니다——첫 100명은 AI 제품이 「돌아간다」에서 「살아남는다」로 넘어가는 첫 스트레스 테스트입니다.

이 글은 기술형 창업자와 1~5인 AI 제품 팀을 위해 0→100 단계에서 집중적으로 드러나는 8가지 문제를 정리하고, 실행 가능한 자체 점검 목록을 제공합니다. 인프라 런웨이도 함께 계산 중이라면 AI 창업 첫해 서버 비용과 대조하세요. Agent 청구서가 먼저 왔다면 Agent 시대 청구서 분해도 참고하세요.

왜 「100」인가——10도 1000도 아닌 이유

세 수준마다 드러나는 문제 유형이 다릅니다:

• 0~10명: 「누가라도 써볼 의향이 있는가」를 검증. 문제는 제품 방향과 핵심 플로우 통과 여부가 중심이며, 인프라·비용은 거의 보이지 않음.
• 10~100명: 「낯선 사람이 남고, 돈을 내는가」를 검증. 사용법이 갈라지고 모델 분산, 청구 기울기, 지원 부채, 보안 경계가 동시에 부상——이 글의 초점 구간.
• 100~1000명: 과제는 스케일로 이동. 멀티테넌트 격리, SLA, 전담 지원, 컴플라이언스 감사. 100명 때 깔아둬야 할 스위치를 1000명에서야 붙이면 비용은 10배가 되기 쉬움.

8가지 문제 영역 개요

아래 표는 0→100에서 가장 자주 터지는 「폭발 지점」입니다. 전부 해당할 필요는 없지만, 3개 이상이면 잠시 멈추고 101번째 사용자를 급히 끌어오지 마세요.

1. 제품과 PMF: 사용 패턴의 분열

클로즈드 베타에서는 「영업 후속 메일 쓰는 Copilot」이라 생각했는데, 100명이 되면 논문 작성, API 일괄 실행, CRM 전체 대체를 기대합니다. 첫 100명은 「누구에게, 어떤 구체적 일을 해결하는가」에 답하게 만듭니다.

드러나기 쉬운 구체적 문제

• 활성화 절벽: 가입에서 「첫 가치 있는 출력」까지 전환이 기대보다 낮음. onboarding이 prompt·데이터 준비를 전제로 하는 경우가 많음.
• 리텐션 양극화: 10%는 매일 쓰고 90%는 한 번에 이탈——모델 탓이 아니라 repeatable job을 못 찾은 것.
• 기능 요청 폭발: 모두 「작은 기능」을 요구해 합치면 세 제품 로드맵. 100명 단계에서는 「아니오」 또는 「X는 안 함」을 분명히 해야 함.
• 기대치 관리 실패: 사용자가 범용 AGI로 보고 한 번 실패하면 이탈. 제품 안에서 능력 경계(할 수 있는 것·없는 것·신뢰도 표시)를 명시해야 함.

대응은 기능 추가가 아니라 ICP를 좁히고 「성공 세션」 지표를 정의하는 것. 예: 「5분 안에 보낼 수 있는 후속 메일 1통 완성」——모델·데이터·UI 개선은 모두 이 한 가지에 맞춤.

2. 모델과 AI 계층: 비결정성의 역풍

전통 SaaS 버그는 재현 가능합니다. AI 제품의 「버그」는 확률적——같은 입력도 어제는 맞고 오늘은 틀립니다. 10명이면 prompt를 손으로 고칠 수 있지만, 100명이면 분산이 입소문을 망칩니다.

고빈도 노출 지점

100명 단계 최소 구성: 30~50개 golden case eval 세트(입력 + 기대 출력 또는 rubric)를 만들고, prompt·모델·RAG 변경마다 실행. 사용자에게 보이는 출력에 인용 출처와 「불확실하면 확인하세요」 폴백 문구를 붙이세요.

3. 인프라와 비용: 롱테일 사용자가 마진을 깎음

100명 중 5명의 헤비 유저가 token의 80%를 소비하는 경우가 많습니다. seat로 과금하고 token으로 비용이 나가면, 첫 100명이 유닛 이코노믹스 성립 여부를 알려줍니다.

• 청구 기울기 통제 불가: 월 API 비용이 6만원에서 60만원으로 뛰는데 MRR은 10만원만 증가——6버킷 비용 모델 참고.
• per-user / per-tenant 쿼터 없음: 한 사용자가 Agent를 7×24 돌려 전체 rate limit을 깨뜨림.
• 캐시 부재: 같은 질문을 매번 추론. RAG 검색 결과도 캐시 없이 매번 full embedding 쿼리.
• staging과 prod 혼용: 베타와 유료가 같은 API 키, 알림 분리 불가.
• 콜드 스타트와 대기열: 100명이 동시에 데모 실행, P99 지연 폭발——대규모 이벤트 전에 경험이 먼저 무너짐.

대응: 첫 유료 사용자부터 tenant별 청구 분리. hard limit + 소프트 알림. 헤비 유저에는 「용량 패키지」나 enterprise 플랜을 개별 협상하고, 무료 티어로 슈퍼 유저를 subsidize하지 마세요.

4. 데이터와 RAG: 쓰레기 입력, 쓰레기 출력

지식베이스 / 문서 Q&A / 버티컬 Copilot이라면, 100명이 올리는 실제 문서 품질은 창업자가 준비한 10개 샘플보다 한 단계 낮은 경우가 많습니다.

• 청크와 파싱: 스캔 PDF, 2단 편집, 표가 잘게 쪼개짐——검색 chunk 의미 불완전, 모델은 억지로 채움.
• 권한과 멀티테넌트: 사용자 A 질문에 사용자 B 문서 조각 히트——100명이어도 「소사고」지만 신뢰에는 치명타.
• 인덱스 노후: Google Doc은 업데이트했는데 제품은 지난주 버전——「AI가 부정확」은 동기화 lag인 경우가 많음.
• 부정 피드백 폐루프 없음: 비추천 후 데이터가 eval이나 re-index 큐로 돌아가지 않음.

100명 단계에서 가장 복잡한 RAG는 필수는 아니지만, 업로드 → 검색 가능 → 인용 가능 → 삭제 가능 루프가 관측 가능해야 합니다. 권한 필터는 검색 계층에서 하고, prompt의 「남의 데이터 내지 마」에만 의존하지 마세요.

5. 보안·컴플라이언스·악용

사용자가 늘면 악의와 오용도 늘어납니다——반드시 해커는 아니고, 직원이 고객 명단을 공개 데모에 붙여넣는 경우도 있습니다.

첫 엔터프라이즈 고객은 50~150명 사이에서 자주 등장——설문, SOC2, 데이터 삭제 SLA를 요구합니다. 100명 전에 「보안 1페이지」와 삭제 절차를 갖추는 편이 임시 땜질보다 10배 신뢰됩니다.

6. 지원과 온보딩: 수동 대응은 지속 불가

AI 제품 지원 비용은 전통 SaaS보다 높은 편입니다. 사용자는 「제품이 고장」인지 「모델이 멍청」인지 「prompt를 모름」인지 구분 못 합니다.

• 에러 메시지 무의미: 프론트는 「생성 실패」만 표시——사용자는 당신에게밖에 못 물어봄.
• 셀프 트러블슈팅 없음: 상태 페이지, 「흔한 실패 원인」, 사용량 대시보드 없음.
• 창업자 = 고객지원: 100명 × 주 1 DM = 개발 시간 20% 손실.
• 온보딩이 대면 의존: 신규 고객마다 1시간 교육——스케일 불가.

투자 우선순위: 사용자에게 보이는 trace id(에러 시 복사해 지원에 전달), 제품 내 사용량·쿼터 표시, 3~5개 시나리오 템플릿 prompt / 원클릭 예시——DM 답변을 제품화로 대체.

7. 가격과 유닛 이코노믹스

100명은 가격 모델을 검증하는 첫 「통계적으로 그럴듯한」 표본(여전히 작지만 10명보다 낫습니다).

• seat 과금 vs token 비용: 월 1만 9천원 무제한 Q&A, 로펌 인턴이 긴 문서를 매일 돌림——건당 마진 마이너스.
• 무료 티어가 과함: 90명 무료·10명 유료, CAC가 안 맞음.
• 사용량 가시성 없음: 초과 후에야 놀람——신뢰 손상이 수익 손실보다 큼.
• Enterprise 견적 표준 없음: 첫 대형 고객이 「프라이빗 배포 + 커스텀 모델」 요구, 현장 견적——적자 계약 위험.

100명 전에 명확히: 과금 단위(seat / 메시지 수 / token 패키지 / 문서 GB), 초과 정책(중단 vs 종량 vs 업그레이드 안내), 사용자당 월 COGS 상한. 스프레드시트로 「20%가 슈퍼 유저」여도 흑자인지 시뮬레이션하세요.

8. 팀과 프로세스: 창업자가 병목이 됨

100명 단계 기술 부채는 종종 인적 부채로 나타납니다:

• prompt 수정, Langfuse 조회, 벡터 인덱스 롤백을 할 수 있는 사람이 1명뿐;
• 릴리스 checklist 없음: 금요일 밤 모델 파라미터 변경, 월요일 사용자 집단 불만;
• 모니터링은 「서비스 생존」만 있고 「답변 품질」 비즈니스 지표 없음;
• 이슈가 단체 채팅에 흩어져 회고·우선순위 불가.

풀 편성은 필요 없지만 크리티컬 패스 문서화: 누가 on-call인지, 실패한 generation을 어떻게 추적하는지, fallback 모델로 어떻게 전환하는지. 2인 팀도 가능——100명 때 이미 빚을 지고 있다고 인정하고, 아직 hackathon인 척하지 않는 것이 전제.

파워 유저 분포: 누가 쓰고, 누가 태움

첫 100명을 분석할 때 간단한 표 1장(PostHog, Mixpanel, DB 집계 모두 가능):

첫 100명에서 가장 시간 쓸 가치가 있는 건 5~15% 헤비 유저——그들이 제품의 진짜 가치와 비용 상한을 정의합니다. 30분 인터뷰를 요청하는 편이 등록 1000건 구매보다 쌉니다.

출시 전 14항목 자체 점검(100명 돌파 전)

1. 「누가, 어떤 상황에서, 무엇을 완료하는가」를 한 문장으로 말할 수 있는가? 아니면 확장을 멈춤.
2. 「성공 세션」에 정량 정의와 계측이 있는가?
3. golden eval 30개 이상이고, 최근 prompt 변경 후 실행했는가?
4. 사용자 출력에 인용 또는 신뢰도 표시가 있는가?
5. API / 모델 청구를 tenant별로 분해할 수 있는가?
6. org·user rate limit + hard cap이 있는가?
7. RAG 권한을 검색 계층에서 필터하는가(prompt만이 아닌)?
8. 문서 삭제 후 인덱스가 SLA 내 무효화되는가?
9. 에러 화면에 trace id와 사용자가 이해할 다음 단계가 있는가?
10. 로그가 마스킹되고, 지원이 full prompt 없이 조사 가능한가?
11. 가격이 「20% 슈퍼 유저」에서도 흑자인가?
12. fallback 모델 또는 저하 전략(타임아웃 / 상류 장애)이 있는가?
13. 보안 1페이지와 데이터 삭제 절차가 있는가?
14. 릴리스 전 누군가 eval 회귀를 검토하는가(창업자 감각만이 아닌)?

자주 묻는 질문(FAQ)

Q1: 100명이면 pmf인가?
충분한 검증은 아니지만 첫 번째 필터입니다. 100명의 실제 사용자에서 리텐션·유료화가 극도로 나쁘면 1000명으로 키워도 문제만 증폭됩니다. 헤비 유저가 돈을 내고 추천하는지를 보세요.

Q2: 제품과 모델 중 무엇을 먼저 고칠까?
활성화 <15%면 제품·온보딩 우선. 활성화는 높은데 평판이 나쁘면 eval, RAG, 환각 우선. 만능의 「더 큰 모델로 교체」로 프로세스 문제를 가리지 마세요.

Q3: 무료 사용자 비율은 어느 정도가 적당한가?
초기엔 높아도 되지만 전환 경로와 비용 상한이 필요합니다. 무료 티어는 사용량·기능을 제한해 슈퍼 유저를 장기 subsidize하지 마세요.

Q4: 첫 고객지원은 언제 채용할까?
창업자가 주 10시간 이상 반복 문의에 쓰이고, 문서·제품 내 셀프헬프로도 티켓이 줄지 않을 때——보통 80~200명 구간. 그 전에 트러블슈팅을 제품화하세요.

Q5: 100명에 전담 DevOps가 필요한가?
대부분 필요 없습니다. 관측 가능성 + 한도 + 릴리스 규율이 필요합니다. 자체 GPU 호스팅 중이면 그때 전담 또는 매니지드 검토.

Q6: 첫 100명은 어디서 오는가?
수보다 ICP 일치가 중요합니다. 맞지 않는 100명보다 맞는 헤비 유저 20명이 낫습니다. 수직 커뮤니티, 기존 고객 소개, 콘텐츠 SEO——범용 광고보다.