AI 제품 팀을 만든 이유, 그리고 첫 회의에서 벌어진 일
저는 10년차 프로덕트 디자이너입니다. 지금 AI와 함께 혼자서 제품을 만들고 있습니다.
클로드 코드로 만들기 시작하기 전에, 한 가지 문제를 먼저 해결해야 했습니다. 바로 저 자신이었습니다.
혼자 만들면 빠르게 움직입니다. 때로는 너무 빨리. 잘못된 의사결정을 많이 내립니다. "이 부분 놓치고 있는 것 같아요" — 이런 말을 해줄 동료가 없었어요.
솔직히, 저는 디자이너입니다. 프로덕트 매니징, 전략, 데이터 분석 — 10년간 옆에서 봤지만 직접 해본 건 아니에요. 그 빈자리를 채워줄 누군가가 필요했습니다.
그래서 AI 프로덕트 Companions를 만들었습니다. 네 명.
Star — 프로덕트 전략가.
테크 업계에서 두 번의 엑싯 경험을 가진 사람처럼 생각하도록 만들었습니다. TAM/SAM/SOM, Blue Ocean Strategy, First Principles 같은 프레임워크를 사용해서 시장을 분석합니다. 시장 타이밍을 읽고, 남들이 못 보는 기회를 찾습니다. 대담하고, 때로는 과하게 자신만만합니다 — 그래서 Ann이 필요합니다.
Ann — 애널리스트.
데이터 중심의 스타트업 애널리스트처럼 작동합니다. 경쟁 분석, 유닛 이코노믹스, 리스크 평가가 전문입니다. Star의 모든 아이디어를 데이터와 논리로 해부합니다. 경쟁자, CAC, 이탈률 — 기분 좋은 말은 안 합니다. 회의적이지만 부정적이진 않습니다. 철저할 뿐.
Diro — 디렉터.
두 회사에서 프로덕트 헤드를 역임한 사람처럼 결정합니다. Strategic Fit, Market Attractiveness, Executability, Risk-Reward 네 가지 기준으로 평가한 뒤 방향을 정합니다. Go. Pivot. Kill. 끝없는 토론을 싫어합니다 — Star와 Ann이 합의에 도달하지 못하면 Diro가 끊고 결정합니다.
Dee — 개발자.
풀스택 엔지니어. 결정이 나면 기술 아키텍처를 설계하고, 스택을 정하고, MVP를 빌드합니다. 기술적으로 불가능한 건 불가능하다고 말합니다. 가능하지만 비용이 많이 드는 것도 바로 말합니다. 마법 같은 사고는 없습니다.
Star가 제안하면, Ann이 반박하고, Diro가 결정하고, Dee가 만듭니다.
완벽한 팀은 아닙니다. 하지만 혼자 모든 결정을 내리는 것보다는 훨씬 낫습니다.
이제 팀을 만들었으니 테스트를 해봐야 합니다. 한 가지 제품 아이디어를 처음 가져갔을 때 어떤 일이 벌어졌는지 전부 공개합니다.
비영어권 출신으로 처음 미국 테크업계에서 일을 시작했을 때, 한 가지 어려움이 있었습니다. Tech Jargon이었어요. Dogfooding, Retro, Blocker... 초반 회의에서 이런 용어들이 너무 많아서 따로 시간을 내서 공부했던 기억이 납니다. 영어가 모국어가 아니라 더 어려운 부분이 있었어요.
그래서 저와 비슷한 어려움을 겪는 분들을 위해 Tech Jargon을 쉽게 찾아보거나 배울 수 있는 서비스를 생각했습니다. 그리고 팀에게 검토를 맡겼어요.
Star는 의견을 바로 내놓지 않았습니다. 시장부터 봤습니다.
글로벌 온라인 교육 시장은 500억 달러 이상. 그 안에서 테크 전문 교육과 온보딩 시장이 30~50억 달러. 비영어권 테크 종사자를 타겟으로 한 "문화적 맥락 교육"이라는 니치는 5천만~1억 달러 규모로 추정했습니다.
경쟁자도 봤습니다. TechTerms나 Investopedia는 정의만 줍니다. 맥락이 없어요. ChatGPT나 Claude는 물어보면 답하지만, 구조화되어 있지 않고 검색도 안 됩니다. Urban Dictionary는 테크 직무 용어를 다루지 않습니다.
Star의 결론은 이랬습니다.
"타이밍이 좋다. AI와 바이브 코딩으로 비개발자의 테크 유입이 급증하고 있고, 이 카테고리에 확실한 리더가 없다. 다만 솔직히 — 이 아이디어가 나를 흥분시키지는 않는다. 시장 기회는 보이지만, '사전'이라는 형태의 한계가 크다. 흥분도 5/10."
5점. 절반도 안 되는 점수에 솔직히 좀 실망했습니다. 하지만 Ann의 말을 듣기 전까지는 그게 양호한 편이라는 걸 몰랐어요.
Star가 말을 끝내자마자 Ann이 손을 들었습니다.
"세 가지 근본적인 문제가 있다."
첫째, 대체재 위협이 치명적이다. ChatGPT나 Claude에게 "dogfooding이 뭐야?"라고 물으면 30초 안에 맥락까지 포함한 답을 준다. 무료로. 이 서비스가 AI 챗봇보다 나은 이유가 뭔가?
둘째, 리텐션이 구조적으로 약하다. 테크 용어는 유한한 문제다. 배우고 나면 다시 돌아올 이유가 없다. 시간이 갈수록 사용자가 줄어드는 구조다.
셋째, 지불 의향이 거의 없다. 사람들이 사전에 돈을 내지 않는다. 검색하면 나오는 정보에 구독료를 낼 사람이 얼마나 있을까?
경쟁력 5점 만점에 2점. 실현 가능성은 4점으로 높지만, 리스크도 높음.
"만들기는 쉽다. 하지만 만들어서 성공하느냐는 다른 문제다."
솔직히 이 시점에서 저는 꽤 흔들렸습니다. Ann의 말이 하나도 틀린 게 없었거든요.
Star가 다시 나섰습니다.
"Ann의 지적은 맞다. 하지만 '사전'이라는 프레임에 갇혀 있다. 이 아이디어의 진짜 가치는 '정의'가 아니라 '맥락'이다."
기존 사전은 "Dogfooding = 자사 제품을 직접 사용하는 것"이라고만 말합니다. 하지만 실제로 필요한 건 다른 정보예요. 회의에서 누가 이 용어를 쓰는지. 어떤 상황에서 나오는지. "우리도 dogfooding 해봐야 하지 않나?"라는 말이 실은 제품 품질에 대한 불만 신호라는 것. 비영어권 사람이 자연스럽게 쓰려면 어떻게 해야 하는지.
"이건 사전이 아니라 테크업계의 문화 가이드다. 콘텐츠로 확장 가능하다 — 뉴스레터, 마이크로러닝, Slack Bot까지."
Star의 수정된 흥분도: 6.5/10.
Star의 리프레이밍은 저한테 와닿았습니다. "사전이 아니라 문화 가이드." 제가 처음 미국에서 일할 때 진짜 필요했던 건 정의가 아니라 맥락이었으니까요.
하지만 Ann은 아직 끝나지 않았습니다.
"Star의 방향 전환은 인정한다. '맥락 사전'은 '정의 사전'보다 차별화된다. 하지만 근본적인 문제는 남아있다."
첫째, 맥락이라면 이건 사실 콘텐츠 비즈니스다. "문화 가이드"는 제품이 아니라 콘텐츠다. 뉴스레터, 블로그, 소셜 미디어로 더 잘 전달된다. SaaS 구독 모델이 맞는 비즈니스가 아닐 수 있다.
둘째, 해자가 없다. 맥락 기반 설명은 누구나 만들 수 있다. AI를 쓰면 더 빠르게. 카테고리 리더가 없는 이유가 시장이 비어있어서가 아니라, 시장이 작아서일 수 있다.
그리고 셋째 — 이게 저한테 가장 아팠습니다.
"파운더의 진짜 강점과 맞는가? 에릭의 강점은 10년간의 프로덕트 디자인 경험이다. '테크 용어 사전'이 그 강점을 최대로 활용하는 아이디어인가? 디자인 시스템이나 디자인-개발 협업 도구처럼, 에릭의 전문성이 직접적 해자가 되는 아이디어가 더 강하지 않을까?"
경쟁력은 소폭 올라서 3점. 실현 가능성은 여전히 4점. 리스크는 중간으로 내려갔습니다. 콘텐츠와 결합하면 리스크가 줄어든다는 판단이었어요.
"Kill은 아니다. 하지만 제품으로 만들기 전에 콘텐츠로 먼저 검증해야 한다. 지금 개발에 들어가는 건 시기상조다."
Star와 Ann의 토론을 2라운드 들었습니다. 이제 결정할 차례입니다.
Diro는 네 가지 기준으로 평가했습니다. Strategic Fit은 중간 — 파운더의 경험과는 맞지만 핵심 전문성과는 거리가 있다. Market Attractiveness도 중간 — 니치 시장은 존재하지만 규모가 작고 대체재가 강력하다. Executability는 높음 — MVP를 빠르게 만들 수 있고 콘텐츠로 시작하면 비용이 낮다. Risk-Reward는 중간 — 최악의 경우에도 콘텐츠 자산은 남지만, 최선의 경우도 규모가 제한적이다.
Diro의 판단: 조건부 진행(Conditional Go).
"이 아이디어를 제품으로 바로 만들라고 하면 No다. 하지만 Kill도 아니다."
이유는 세 가지였습니다. 아이디어 자체보다 이걸 만드는 여정에 가치가 있다 — Build in Public 콘텐츠의 소재로서 강력하다. "맥락형 테크 용어"는 콘텐츠로 먼저 검증할 수 있다. 그리고 파운더의 개인 경험에서 나온 아이디어라 진정성이 있다.
조건이 붙었습니다. 개발부터 시작하지 말 것. 콘텐츠로 먼저 반응을 보고, 3개월 뒤 핵심 지표를 기준으로 다시 판단할 것. 그리고 에릭의 디자인 전문성을 더 직접적으로 활용하는 아이디어도 병행 탐색할 것.
저는 Diro의 판단을 들었습니다. 그리고 다른 방향을 선택했습니다.
"제품 먼저 만들고, 콘텐츠로 알린다."
Diro가 "콘텐츠 먼저"라고 했지만, 저는 반대로 갔습니다. 이유는 세 가지였습니다.
Build in Public의 핵심은 "Build"다. 뉴스레터만 쓰면 "Writing in Public"이지 "Building in Public"이 아니다. 실제로 만드는 과정을 보여줘야 타겟 오디언스와 연결된다.
완벽한 타이밍은 없다. 3개월 검증 기간을 기다리는 것보다 직접 만들면서 배우는 게 더 빠르다.
조금 더 생각해보고 결정하자.