고등학생의 유료 Discord 봇이 월 이익 1.2만 엔 — 원가 320엔에 월 500엔을 매긴 근거를 읽다

무료가 당연한 시장에, 고등학생이 유료로 진입했다

Discord 음성 채팅에서 텍스트를 읽어주는 봇은 2021년 시점에 이미 무료인 것이 여러 개 존재했다. 거기에 월 500엔 구독으로 진입해, 공개 2년 차에 월 약 1만 2,000엔의 이익을 낸 것이, 당시 고등학교 3학년이던 sizumita 씨의 BardBot(bardbot.net)이다. 본 기사는 같은 인물이 Zenn에 공개한 운영 기록을 바탕으로, 이 작은 흑자가 어떤 계산 위에 서 있는지를 분해한다.

금액 자체는 크지 않다. 그럼에도 다루는 이유는, 원가가 명시되고 가격의 근거가 설명되며 가입 페이스까지 구체적인 빈도로 나와 있는 개인 개발 기록이 국내에 거의 없기 때문이다. 이 사례의 가치는 벌어들인 액수가 아니라 단가 설계의 투명함 쪽에 있다.

공개된 숫자

매출액 자체는 공개되어 있지 않다. 나와 있는 것은 “월 12k 정도의 이익”이라는 결과값과 단가뿐이므로, 본 기사에서도 회원 수나 월 매출을 역산하지는 않는다. 추정을 거듭하면, 이 사례에서 유일하게 확실한 “원가와 가격의 관계”까지 모호해지기 때문이다.

팔고 있는 것은 기능이 아니라 “혼잡하지 않다는 것”

BardBot이 만들어진 동기는 기능의 부족과는 다른 곳에 있다. 본인의 설명은 이렇다. 무료 읽어주기 봇은 “어느 것이든 이용하는 사람 수가 너무 많아서 제한이 있거나 읽어주기가 느려지는 문제”가 있었다. 즉 무료 봇의 약점은 개발자의 태만이 아니라, 공유 자원을 무료로 개방하는 것 그 자체에 있다. 이용자가 늘수록 1인당 몫이 줄어 품질이 떨어진다. 이는 운영 노력으로는 풀 수 없는 구조적 제약이다.

유료화는 이 제약을 돈으로 분리하는 행위였다. 과금액에 따라 읽어주기 문자 수의 한도를 확보하는 모델이라면, 사용자가 늘어나도 기존 사용자의 품질은 떨어지지 않는다. 가용성 99%라는 숫자를 내걸 수 있는 것도, 수익이 인프라 비용에 연결되어 있기 때문이다. 여기서 팔리고 있는 것은 읽어주기 기능이 아니라, “타인의 이용량에 품질을 잠식당하지 않는 상태”라고 바꿔 말할 수 있다.

가격이 먼저가 아니라, 원가가 먼저였다

가격 책정 설명이 명쾌하다. Google Cloud Text-to-Speech의 단가는 100만 자당 1,600엔. 상한인 20만 자를 다 쓴 경우의 원가는 약 320엔. “거기에 서버비가 든다고 하면, 이 정도가 적정하다”고 하여 월 500엔이 정해졌다.

이 구조에서 중요한 것은 320엔이 상한 케이스의 원가라는 점이다. 20만 자는 어디까지나 월간 한도로, 모든 사용자가 매달 다 쓰지는 않는다. 실제 평균 소비가 한도를 밑돌수록 건당 실효 원가는 320엔보다 작아지고, 매출총이익률은 올라간다. 종량 과금의 원가에 정액 한도를 씌우는 모델은 이 차액이 이익이 된다. 반대로 말하면, 한도를 너무 크게 잡거나 원가 단가가 개정되면 매출총이익은 단번에 사라진다. 500엔이라는 가격은 감으로 정한 것이 아니라, 이 하나의 계산식으로 뒷받침되고 있다.

흐름이 바뀐 것은 “다른 사람의 글에 실렸을 때”

운영 기록에는 “좀처럼 구독 가입자가 늘지 않는다”는 소제목이 있다. 대책으로 나온 것은 세 가지. 트위터 계정 개설, note 글쓰기를 통한 유도, 그리고 이미 많이 읽히고 있는 다른 사람의 글에 게재해 받는 것이다. 그리고 본인은 이렇게 쓴다. “덕분에 4일에 1~2명 페이스로 구독에 가입해 주시게 되었습니다.”

전후의 수치가 둘 다 나와 있는 것은 아니다(전은 “늘지 않는다”는 정성적 표현뿐). 그래도 가입 페이스가 구체적인 빈도로 말할 수 있게 된 지점이 여기라는 인과는 본인이 명시하고 있다. 자신의 계정을 키우는 것이 아니라, 이미 독자가 있는 곳에 자신의 프로덕트를 놓게 하는 것, 채널을 만드는 게 아니라 빌리는 판단이, 이 사례에서의 전환점이다. 개인 개발에서 가장 빠지기 쉬운 것이 집객임을 감안하면, 월 12k의 흑자는 기술력이 아니라 이 한 수로 결정된다.

기술 선택은 “멈추지 않는 것”에 대한 투자였다

가용성 99%는 결과적으로 나온 숫자가 아니다. 첫 봇은 Python으로 작성되어 있었지만, Discord API 래퍼가 개발 종료된 데다 메모리 사용량이 하루에 5%씩 상승하는 문제를 안고 있었다. 다음으로 F#을 시도했지만 래퍼가 작동하지 않아 포기하고, 최종적으로 Rust + Serenity로 다시 작성했다. 설정을 여러 봇 사이에서 즉시 반영시키기 위한 내부 API에는 Go + Echo, 웹은 Next.js + Firebase, 캐시에는 Redis, 호스팅은 ECS on EC2(t3.micro, 예약 인스턴스)라는 구성이다.

비용 의식도 일관되어 있다. 데이터베이스는 Cloud SQL을 “비용이 너무 비싸서 포기”하고 Firestore를 채택했다. 로그 기반은 Kibana + Elasticsearch를 무료 한도로 사용할 수 있는 Oracle의 ARM 인스턴스(메모리 24GB, 4vCPU)에 셀프 호스팅하고 있다. 과금은 Stripe Checkout과 Billing Portal에 맡기고, Webhook을 받는 Firebase Functions가 Firestore를 자동으로 업데이트한다. 결제 관련을 직접 만들지 않음으로써, 혼자서도 운영이 돌아가는 형태로 만들어 두었다.

한편 웹 호스팅은 “Hobby와 뭐가 다른지 모르겠어서 Hobby로 하고 싶지만, 영리 목적이라 어쩔 수 없다”며 Vercel Pro를 사용하고 있다. 건당 매출총이익이 몇백 엔 규모인 사업에서 이러한 고정비는 무겁다. 월 12k라는 이익은 원가를 깎는 노력의 축적 위에 남은 숫자다.

약점은 어디에 있는가

가장 큰 약점은 사업이 Discord라는 하나의 플랫폼 위에만 존재한다는 것이다. API 사양이나 약관이 바뀌면 수익은 통째로 영향을 받는다. 단가도 얇다. 월 500엔짜리 상품으로 이익을 두 배로 만들려면 회원 수를 두 배로 만드는 수밖에 없어, 영업 레버리지가 잘 작동하지 않는다. 여기에 더해 운영자의 가처분 시간이 학업에 직결된다. 글 안에서도 “대학 입시가 끝날 때까지는 유지보수 정도밖에 할 수 없다”고 명언되어 있어, 성장이 본인의 생애 단계에 강하게 묶여 있다.

해외 진출을 위한 i18n 대응, 입시 이후의 신기능 개발, 기업용 Discord 봇이라는 세 가지 구상은 언급되어 있지만, 어느 쪽도 글 시점에서는 착수되지 않았다. 본 기사는 이것들을 성과로 다루지 않는다.

이 사례의 어디를 이식할 수 있는가

이식할 수 있는 것은 원가에서 가격을 이끌어내는 순서다. 종량 과금 API를 사용하는 프로덕트라면, 상한 케이스의 원가를 산출하고, 거기에 고정비를 얹고, 딱 떨어지는 금액으로 반올림한다. 이 절차는 누구나 밟을 수 있다. 무료 대체품이 존재하는 시장이라도, 그 무료가 “공유 자원의 혼잡”으로 품질을 떨어뜨리고 있다면 유료가 파고들 여지가 있다는 해석도 다른 시장에 그대로 들고 갈 수 있다.

이식하기 어려운 것은 두 가지다. 하나는 Rust로의 재작성이나 여러 언어로의 구현을 고등학생 때 혼자서 해낼 수 있는 기술력. 다른 하나는 많이 읽히는 다른 사람의 글에 실어줄 수 있는 관계성으로, 이는 미토 주니어 채택자라는 커뮤니티 내 입지와 무관하지 않다. 가입 페이스가 바뀐 전환점 부분이야말로 가장 재현하기 어려운 요소로 봐야 할 것이다.

그리고 규모의 한계도 직시해 둘 필요가 있다. 월 12,000엔은 삶을 바꿀 만한 금액이 못 된다. 다만 원가와 가격의 관계가 올바르게 설계된 서비스는, 회원 수가 늘어났을 때 이익이 비례해서 늘어난다. 이 사례가 보여준 것은 도달점이 아니라, 늘어날 수 있는 형태로 되어 있는가를 검사하는 방법이다.

함께 읽으면 좋은 글

• Sidekiq — OSS의 무료판과 유료판을 혼자서 양립시킨 수익 설계
• Plausible — 무료의 거인이 있는 시장에서 유료 프로덕트가 ARR 100만 달러에 도달하기까지