Intune 운영의 번거로움을 한 점 돌파. 노코드 SaaS 'Pckgr'가 월매출 1,245만 엔에 이르기까지

※ 달러 표기 숫자에는 1달러=150엔 환산 기준을 함께 표기하고 있다.

“Google Chrome을 배포하고 싶다? Pckgr에 등록해 Intune에 연결하고 Chrome을 선택해 배포한다. 그게 전부다”——호주 멜버른의 Thomas Mahony가 만든 Pckgr의 설명은 이것으로 끝이다. 기업의 Windows 단말을 Microsoft Intune으로 관리하는 IT 담당자에게, 앱을 배포 가능한 형태로 ‘패키징’하고 업데이트할 때마다 다시 만드는 작업은 지루하고 끝이 없는 부담이다. 그 한 공정만을 자동화하는 도구가 월매출 8만 3,000달러(약 1,245만 엔), 연매출 환산으로 100만 달러 이상에 도달했다.

어디서 과제를 발견했나

원문은 각 단계의 정확한 연도를 세세하게는 밝히지 않는다. 확실한 것은 출발점이 2017년의 5인 규모 헬프데스크였고, 거기서부터 대기업 프로젝트까지 Intune 운영 현장을 위아래로 넘나든 경험 그 자체가 제품의 씨앗이 되고 있다는 점이다. 고객의 규모대는 “100대 미만부터 10만 대 이상까지” 폭넓으며, 소규모 IT 부서와 MSP가 중심이다.

전환점은 “무료로 뿌린다”고 결정한 데 있다

Pckgr의 궤도를 결정한 것은 공개 시점에 가격을 제로로 둔 것이다. 그는 “초기 사용자를 모으고, 실제 환경에서 제품이 어떻게 작동하는지 배우기 위해” 완전 무료로 내놓았다. 그리고 배포할 곳을 Intune 관리자들이 이미 논의를 나누고 있는 subreddit과 Facebook 그룹으로 한정했다. 널리 홍보하지는 않았다.

무료 기간에 결함을 다 찾아낸 뒤 월 25달러를 도입하고, 첫 유료 고객이 나온 단계에서 풀타임으로 전환했다. 여기가 두 번째 분기점이다. “만들고 나서 팔릴지 생각한다”도 “팔린 뒤에 만든다”도 아닌, 무료로 실제 운영에 노출해 망가지는 부분을 잡고, 망가지지 않게 된 뒤 값을 매긴다는 순서를 밟고 있다.

그리고 세 번째. 단일 플랜에서 4단계로의 이행과 가격 인상에 대해 그는 “가격 인상이 성장에 크게 기여했다”고 명언한다. 월 25달러 그대로였다면 월매출 8만 3,000달러에는 도달하지 못한다. 같은 고객층에 대해 몫을 늘릴 여지가 남아 있었다는 것이다.

왜 이 순서가 효과가 있었나

무료 공개가 효과를 낸 이유는 집객이 아니라 검증의 질에 있다. Intune 산하의 단말 환경은 기업마다 편차가 크고, 개발자의 손에서는 재현되지 않는 실패가 반드시 나온다. 무료로 사용하게 하는 동안 실제 환경이라는 시험장을 빌려, 과금을 시작할 무렵에는 “작동하지 않았다”는 클레임의 주요 원인을 다 잡아낸 상태다. 유료로 내놨다면 같은 결함이 환불과 평판 훼손으로 이어졌을 것이다.

투하할 곳의 선정도 구조적이다. IT 관리자용 도구는 검색 광고로 발견되는 것보다 “같은 과제로 불평을 나누고 있는 장소”에 두는 편이 빠르다. subreddit과 Facebook 그룹은 구매 결정권자가 이미 자신의 과제를 언어화한 상태로 머물러 있는 장소이며, 설명 비용이 거의 제로가 된다.

가장 효과를 낸 집객 채널로 그가 꼽는 것은 Microsoft MVP(동사가 인정하는 기술 전문가)에 대한 접근이다. MVP에게 제품을 시연하게 하고, 그것이 유튜브에 올라간다. 이 형식이 강력한 것은 두 가지 이유 때문이다. MVP의 시청자는 Intune 관리자로 고도로 좁혀져 있고, 동영상은 공개된 후에도 계속 남아 나중에 검색해 찾아온 사람을 데려온다. 그는 이 “공개된 지 오래 지나도 고객을 데려온다”는 성질을 효과의 중심에 두고 있다.

기술 구성도 일관되게 가볍다. UI와 로직은 노코드 도구 Bubble, 패키징과 테스트는 GitHub Actions, 백엔드는 Microsoft Azure의 서버리스 함수·스토리지·Microsoft Graph 연동. 클라우드의 무료 티어를 최대한 활용해 비용을 억제하면서 시작했다. 프런트를 Bubble로 해결한 것은 Intune 연동이라는 본체에 개발 시간을 집중하는 판단이기도 했다.

꺾일 뻔한 순간과 남는 리스크

개발 중에 Microsoft 자체가 경쟁 플랫폼을 발표했다. 그는 “완전히 의욕을 잃고 출시를 포기할 뻔했다”고 회상한다. 결국 하룻밤 자고 나서 계속했고, “벽에 부딪혀도 다음 날에는 뭔가 아이디어가 떠올라 계속 나아갔다”고 말하지만, 이 사례의 리스크의 본질은 바로 거기에 있다. Pckgr는 플랫폼 제공자 옆에서, 제공자가 메우지 않은 구멍을 메우는 사업이다. 구멍이 메워지는 날 가치가 사라지는 구조는 지금도 변하지 않았다.

진입 장벽에 대한 본인의 견해도 솔직하다. AI 도구의 보급으로 “진입 장벽은 믿을 수 없을 만큼 낮게 느껴지고, 경쟁은 늘고 있다”는 한편 “MVP를 만드는 것은 그 어느 때보다 쉬워졌다.” 이 양면성은 후발 주자가 같은 니치를 노리기 쉬워졌다는 것도 의미한다.

무엇을 흉내 낼 수 있고 무엇을 흉내 낼 수 없나

흉내 낼 수 있는 것은 순서와 장소의 선택 방식이다. 무료로 실제 환경에 노출해 망가지는 부분을 잡고, 그 후에 가격을 매기고, 나아가 단계를 나눠 올려간다. 투하할 곳을 “대상자가 이미 모여 있는 장소”로 좁힌다. 이 두 가지는 업종을 불문하고 적용할 수 있다. 노코드로 전면을 만들고 차별화의 핵심만 직접 만드는 구성도 마찬가지다.

흉내 내기 어려운 것은 과제의 출처다. 그가 Pckgr의 필요성을 확신할 수 있었던 것은 5인 MSP부터 대기업 프로젝트까지 Intune 운영 현장을 실제로 경험했기 때문이며, 이 판단 재료는 밖에서 시장 조사를 해도 손에 들어오지 않는다. Microsoft MVP가 상대해 준 것도 업계 내의 언어와 신용을 공유하고 있었기 때문이다. 게다가 Microsoft 생태계라는 “대기업이 토대를 갖고 있고, 주변을 메울 여지가 구조적으로 계속 생겨나는” 지형의 존재도, 고르려고 마음먹는다고 고를 수 있는 것이 아니다. 그는 다음으로 Windows 단말을 통째로 관리하는 ‘Pckgr RMM’을 구상하고 있으며, 같은 지형을 더 깊이 파는 방향으로 나아가고 있다.

함께 읽으면 좋은 글

• ScrapingBee — 개발자용 니치 SaaS의 도달점
• Plausible — 광고비 제로·4명이서 $1M ARR