25일간 가입자 744명, 실제로 시도한 성장 작업

AI 요약

BeatAPI 팀은 프로젝트를 시작한 지 25일 만에 가입자 744명과 매출 900달러 이상을 기록했습니다. 다만 가입이 곧 제품 가치를 얻었다는 뜻은 아니며, SEO나 소셜 미디어 같은 채널별 가입 성과도 아직 정확히 나누지 못한다고 밝혔습니다. 이 글에서는 실제로 진행한 성장 작업과 아직 모르는 부분을 함께 설명합니다.

개인의 불편에서 제품으로

출발점은 창업자가 AI 영상 여러 편을 만드는 작업에서 겪은 불편이었습니다. 이미지와 영상 생성 API마다 계정과 요청 형식, 결과 반환 방식이 달라 직접 연결하는 일이 번거로웠습니다. 별도 앱을 오가며 작업하기보다 MCP(Model Context Protocol)를 이용해 이미 쓰던 에이전트가 전체 작업을 처리하기를 원했습니다.

먼저 만든 제품은 오픈소스 프로젝트 BeatDesign입니다. 로컬 우선(local-first) 방식의 캔버스와 타임라인, 에셋 보관 공간을 한 프로젝트에 담았습니다. Codex, Claude Code, Cursor처럼 MCP를 지원하는 에이전트가 같은 프로젝트를 다루도록 설계했습니다. 이미지·영상 생성 API를 연결하는 과정에서 BeatAPI가 나왔습니다. 팀은 생성 API 연결만으로 문제를 다 해결하지 못했다고 봤습니다. 여러 모델을 비교하고, 모델 자체에서 얻지 못하는 데이터도 쓰며, 특정 에이전트 호스트에 종속되지 않도록 하나의 계정과 키로 여러 기능을 쓰는 방향으로 제품을 확장했습니다.

콘텐츠 계획 대신 불편 사례 수집

팀은 콘텐츠 달력부터 만들지 않았습니다. 직접 겪은 문제를 기록하고 다른 사용자도 같은 문제를 겪는지 확인하는 ‘불편 사례 목록’을 만들었습니다. BeatAPI의 Social Data API로 X에서 ‘AI’, ‘AI agent’, ‘AI model’을 검색했을 때는 24시간 범위 검색 세 건에서 게시물 60건이 나왔습니다. 중복을 빼고 시간대를 확인하자 실제 범위에 든 게시물은 21건이었습니다. 에이전트가 이를 다섯 가지 주제로 묶었고, 팀은 요약만 받는 대신 원문 게시물도 확인했습니다. 팀은 이 결과가 한 플랫폼의 작은 표본일 뿐이며, Reddit 자료는 같은 수준으로 살펴보지 않았다고 선을 그었습니다.

이후 Reddit과 X에서 AI 에이전트, 모델 API, 콘텐츠 도구 관련 글과 댓글을 조사해 스프레드시트에 모았습니다. 원문과 게시판·계정, 출처 링크, 근거의 강도를 기록하고, 검증이 어렵거나 약한 사례는 표시했습니다. 특정 사용자 유형에만 해당하는 사례도 별도로 남겼습니다. 불만 글이 구매 수요를 증명하지는 않지만, 기획 문서에서 만들어 낸 문제를 콘텐츠로 쓰는 일을 줄이려는 목적입니다.

개발자의 선택을 돕는 자료

API 제품을 만들면 아키텍처를 소개하고 싶어지지만, 개발자가 실제로 알고 싶은 내용은 더 구체적이라고 팀은 설명합니다. 특정 모델이 작업에 맞는지, 같은 요청의 비용은 얼마인지, 공급자를 바꾸려면 얼마나 손이 가는지가 그런 질문입니다. 이에 따라 일반적인 ‘최고의 AI API’ 글 대신 모델 안내서와 동일한 조건의 공급자 비교, 비용 계산기를 만들었습니다.

영상 API 비교에서는 초당 가격만으로 충분하지 않습니다. 어떤 해상도와 길이를 지원하는지, 요청이 비동기 작업을 만드는지, 결과를 어떻게 가져오는지도 확인해야 합니다. 팀은 이런 조건을 비교 자료에 넣고 다른 공급자가 더 적합한 경우도 설명했습니다. BeatAPI를 써볼 이유는 같은 모델과 조건에서 검증된 더 낮은 가격을 찾고 실제 요청을 실행하는 것입니다. 팀은 자료가 가입을 유도하는 광고에 그치지 않고, 가입하지 않는 독자에게도 선택에 도움이 되어야 한다고 말합니다. 페이지별 가입자 수는 아직 파악하지 못했습니다.

AI 검색 도구가 찾는 답도 점검

팀은 검색엔진뿐 아니라 AI 어시스턴트가 질문에 답할 때 어떤 페이지를 열고 무엇을 인용하는지도 살폈습니다. 공급자 추천, 동일 설정의 가격 비교, 통합 과정 같은 질문을 던지고, 출처에 가격 단위나 모델 ID, 요청 예제가 없어 모호한 설명으로 넘어가는 부분을 찾았습니다. 이를 페이지와 문서, 비교 자료를 고치는 목록으로 삼았습니다.

팀은 이를 AEO(Answer Engine Optimization)를 완성한 사례라고 부르지 않습니다. AI 어시스턴트의 추천이 유료 고객으로 이어졌다는 증거가 없기 때문입니다. 다만 근거가 빠진 답변은 사람에게도 신뢰를 얻기 어렵다는 점을 확인했고, 빠진 정보를 채우면 페이지 자체의 설명력이 좋아졌다고 밝혔습니다.

성과 지표와 다음 과제

25일 동안 가입 계정은 744개였지만, 청구된 API 사용 기록이 있는 계정은 284개였고 충전까지 한 사용자는 33명이었습니다. 팀은 가입자를 SEO, AEO, X 활동으로 나누는 데 필요한 출처 추적이 부족하다고 인정했습니다. 이제 관심을 끌어 가입시키는 것보다 첫 유효 API 호출을 돕고, 사용자가 다시 작업하도록 만드는 일이 과제입니다. 가입 후 멈춘 사용자에게 모델 부재, 불분명한 가격, 문서나 첫 API 키 설정 중 무엇이 걸림돌이었는지도 묻고 싶다고 했습니다.

성장 과정은 실제 문제를 찾고, 다른 사람의 사례로 확인한 뒤 근거 있는 답을 만들고, 관련 대화에 참여해 사용자가 실제 작업을 끝내는지 살피는 순서입니다. 다음 25일 동안 어느 단계가 효과가 있고 어느 단계가 바쁘게 보이기만 하는지 확인하겠다는 계획입니다.

Indie Hackers 반응

• @abdullah_markets — 불편 사례 목록이 눈에 들어옵니다. 콘텐츠 달력 대신 실제 불만에서 시작했기 때문에 작업물이 뻔하지 않고 유용하게 느껴지는 것 같습니다. 다음으로는 출처부터 첫 API 호출 성공까지 간단히 추적하면 좋겠습니다. 어떤 주제가 가입만 하는 사람이 아니라 실제로 제품을 쓰는 사람을 데려오는지 알 수 있습니다.
• @lahutchins91 — 가입과 가치 획득을 구분한 점이 솔직해서 좋습니다. 사용 사례마다 첫 성공 API 응답이나 첫 저장 워크플로처럼 구체적인 활성화 이벤트를 하나 정하고, 출처·랜딩 페이지·첫 호출까지 걸린 시간과 함께 기록해 보세요. 출처에서 첫 성공, 두 번째 작업으로 이어지는 코호트를 보면 총 가입자 수보다 어떤 채널에 더 힘을 쏟을지 빨리 알 수 있습니다.
• @iptvkaufen24net — 불편 사례 목록은 만들어 낸 페르소나를 피하는 데 도움이 되겠지만, 포럼에서 큰 목소리로 불평하는 문제가 꼭 돈을 내고 해결할 문제인지는 모르겠습니다. 비교 페이지나 계산기를 만들기 전에 관심이 큰 문제와 구매 의도가 높은 문제를 어떻게 구분하나요? 반복되는 불만, 기존 지출, 다른 신호 가운데 무엇이 가장 강했는지 궁금합니다.
• @minchan — 다른 공급자가 더 잘 맞는 경우까지 보여주면 가입하지 않는 독자에게도 유용한 비교 자료가 됩니다. 독자로서는 다른 작업이 생겼을 때 다시 찾아올 가능성이 높아집니다. 그 점을 포함해 줘서 좋습니다.
• @mehdizare — 불편 사례 목록을 콘텐츠 달력이 아니라 단계가 있는 백로그로 다루면 좋았습니다. 각 항목에 긴급도, 이미 존재하는 수요, 전후 차이를 구체적으로 보여줄 수 있는지 표시하고, 판단해야 할 내용이 가장 분명한 것부터 공개합니다. 페이지마다 가입 수집 이상의 목적이 하나 생겨서 성과 추적도 쉬워집니다.
• @chely — 저희는 제품을 대뜸 홍보하기보다 정확히 같은 불편이 나온 대화에 직접 답글을 달았을 때 성과가 더 좋았습니다. 계속 남은 사람은 고맙다고만 한 게 아니라 후속 질문을 하러 돌아온 사람들이었습니다.
  • @Eric Kang — 네, 저희 팀도 Reddit 같은 커뮤니티에서 시간을 더 쓰려고 합니다. 사람들이 실제로 겪는 문제를 듣고 어떻게 도울지 살펴보겠습니다.
  • @chely — Reddit은 좋은 선택입니다. 다만 새 계정이나 카르마가 낮은 계정은 사이트 전체 스팸 필터에 걸릴 수 있습니다. 저희도 최근에 겪었습니다. 제품을 언급하기 전에 관련 없는 서브레딧에서 카르마를 쌓아 두는 편이 좋습니다.
• @AmandaBrown — 불편 사례 목록은 좋은 출발이고, 744명 중 284명이 청구 사용 기록을 남겼다는 수치가 실제로 살펴볼 만한 질문입니다. 다음 과제는 첫 사용 경험이 사용자가 찾아온 이유에 맞는지 확인하는 일입니다. 개발자 API 제품에서는 가입과 청구 사용의 간극이 가격이나 포지셔닝보다 통합 복잡성에서 생기는 경우가 많습니다. 인증 흐름이 불분명하거나, 기대한 모델이 없거나, 비동기 응답 방식이 예상과 다르거나, 문서에 성공 사례만 있고 흔한 오류 설명이 빠졌을 수 있습니다. 충전한 33명을 집중해서 살펴보세요. 첫 요청으로 무엇을 만들었는지, 계정 생성부터 첫 호출까지 얼마나 걸렸는지, 첫 세션에서 문서나 검색창에 어떤 질문을 입력했는지 확인하면 284명에서 33명으로 줄어드는 이유가 보일 수 있습니다. 출처가 없는 직접 유입도 살펴볼 만합니다. 오래된 포럼 답변을 찾아 들어온 개발자처럼 리퍼러가 남지 않는 경우가 있기 때문입니다.
  • @Eric Kang — 유용한 의견 감사합니다. 저희는 작은 팀이라 지금까지 성장에 대부분의 시간을 썼습니다. 이미 가진 사용 데이터와 충전 후에도 계속 API를 쓰는 실제 워크플로를 더 자세히 살펴보겠습니다.
• @gradusfyi — 가입, 청구 사용, 충전 사용을 구분한 점이 이 글에서 가장 유용합니다. 첫 성공 호출과 두 번째 작업을 활성화 기준으로 삼고, 모든 접점을 완벽히 추적하려 하기보다 출처와 랜딩 페이지별 코호트를 만드는 편이 좋겠습니다. 호출이 막힌 시점에 “무엇 때문에 멈췄나요?”라고 짧게 물으면 기능 부재, 가격 설명, 설정 문제를 나눌 수 있습니다. 불편 사례에서 근거 있는 답변을 만들고 실제 작업 완료까지 이어지는 흐름이 발행량만 늘리는 것보다 오래갈 것 같습니다.
  • @Eric Kang — 세심한 조언 감사합니다. 곧 사용자를 후속 연락해 실제 워크플로에서 막히는 지점을 직접 묻겠습니다. 특히 첫 호출 성공과 두 번째 작업 사이를 살펴보겠습니다.
• @aryan_sinh — 청구 사용 기록이 있는 계정 284개 중 충전한 계정은 33개입니다. 유용한 첫 작업을 끝내는 사용자와 지속적으로 API를 쓰러 돌아오는 사용자를 가르는 행동은 무엇인가요?
  • @Eric Kang — 비용을 지불한 사용자 가운데 약 20~30%는 API를 계속 쓰고 다시 충전했습니다. 긍정적인 신호지만 표본이 작습니다. 어떤 첫 사용 행동이 재방문을 예측하는지 말하려면 사용자와 관찰 기간이 더 필요합니다.
• @kimtqitybxwjynltvwi — 첫 성과가 보이기까지 얼마나 걸렸나요?
  • @Eric Kang — 첫 사용자가 보이기 시작한 건 약 일주일 뒤였습니다. 가입도 반가웠지만 실제 API 사용이 더 의미 있는 신호였습니다. 지금은 사용자가 두 번째 작업으로 돌아오는 이유를 살펴보고 있습니다.
• @EastWest_KonneX — 가입 증가가 허영 지표 목록으로 바뀌지 않도록 신규 계정이나 리드마다 다음 행동을 기록합니다. 출처, 단계, 정확한 후속 연락 날짜 세 가지를 씁니다. 다음 행동을 정할 수 없다면 진행 중인 기회로 세지 않습니다. 금요일마다 30분 동안 가입자와 활성 사용자를 비교하고, 잡음만 만든 채널 하나를 없앱니다. 각 성과나 실패의 이유를 한 문장으로 적어 두면 가격이나 메시지를 바꿀 때 쓸모가 있습니다.

원문: Indie Hackers / 번역·요약: Trawling