본문 바로가기
기획 일반

앱 서비스, 웹 서비스 수익

by 애플_피시 2023. 10. 11.

수익을 계산하는 방법은 간단합니다. 매출에서 비용을 빼면 됩니다. 그러나 수익을 만드는 것은 매우 어렵습니다. 특히 앱/웹과 같은 온라인 서비스의 수익은 더 어렵습니다. 많은 서비스들이 사용자를 확보하는 데 조차 어려움을 겪기 때문입니다. 사용자는 이미 성공한 앱/웹 서비스를 이용하고 있기에 당연하게 보일 뿐입니다.

 

 

 

앱 서비스, 웹 서비스 수익화 과정 

 

앱과 웹 서비스가 수익을 내기 위해서는 먼저 개발을 해야 합니다. 물론 앱/웹 개발을 했다고 해서 수익이 나오는 것은 아닙니다.

 

막 개발된 앱과 웹은 아직 사용자가 거의 없기에 매출조차 나오지 않는 상태입니다. 사용자가 있다고 해도 대부분 개발자 지인을 가능성이 큽니다. 지금은 인기 앱 서비스인 당근마켓조차 첫 1000명의 사용자를 확보하는데 매우 어려웠습니다. 

 

당근마켓조차 이러한데 일반 앱/웹 서비스들은 사용자를 모으는 게 더 어려울 것이라는 점은 알 수 있습니다.

 

일정 이상 사용자를 확보하기 위해 앱/웹 서비스 운영자는 광고도 하고 이벤트도 합니다. 많은 서비스들이 가입자를 유치하는데 광고 외에도 신규 사입자가 가입하거나, 추천하는 경우 보상을 지급하기도 합니다. 과거 소셜 데이팅 앱은 여성 가입자를 모으기 위해 명품 가방을 추첨으로 주는 이벤트를 진행하기도 했습니다.    

 

이렇게 어렵게 사용자를 확보하였다고 해도 매출이 나오는 것은 아닙니다. 일정 이상 사용자가 누적되기 전까지는 매출이 아니라 비용이 증가합니다. 사용자가 일정이상 되었을 때 비로소 의미 있는 매출이 나오기는 하지만 이 때도 매출은 비용에 비해 현저히 작은 경우가 대부분입니다.

 

그럼에도 SNS나 동영상 플랫폼에 비하여 이커머스 서비스는 바로 작으나마 매출이 나오기에 좋기는 합니다. 그래도 이커머스에서 조차 매출 보다 비용이 많은 경우가 대부분입니다. 대부분의 크고 작은 이커머스 서비스들이 매출 규모는 상당하나 적자에 허덕이는 이유도 여기에 있습니다.

 

일정 이상 매출 규모를 달성했음에도 앱/웹 서비스 수익성이 여전히 낮은 이유는 여기에 있습니다. 월간, 분기 간, 연간 비용이 매출보다 큰 경우 매출이 아무리 크더라도 앱/웹의 수익성은 좋지 않습니다.

 

충분한 매출 규모를 확보했다면 비용을 효율화하거나 매출을 더 올리는 방법만이 수익화의 방법이 됩니다.

 

 

 

앱/웹 서비스 비용과 매출

 

간단히 앱/웹 서비스에서 비용 부분과 매출 부분을 정리해 보면 다음과 같습니다.

 

일단 가장 먼저 발생하는 앱/웹 서비스 관련 비용은 개발 비용입니다. 앱/웹 서비스 특성상 개발 시 발생하는 대부분의 비용은 인건비입니다. 특히 개발자 인건비가 올라간 지금 개발 비용은 크게 증가했습니다.

 

물론 인건비 외에도 개발에 필요한 프로그램 비용, 설루션 비용 등이 개발 시 추가되기 합니다. 그래도 인건비에 비하면 크다고 할 수는 없을 것입니다.

 

예를 들어 평균 6000만 원 연봉의 인력 10명이 18개월 개발을 한다면 인건비만 9억 원에 달하게 됩니다. 스타트업이 아닌 이상 많은 앱/웹 서비스들이 10명 이상 개발자가 투입되며, 연봉도 6000만 원 이상되는 경우가 많습니다.

 

실제 앱/웹 서비스 시장에 공급되는 개발자가 많아지면서 실제는 초급 수준의 개발자들이 많아짐에 따라 실수에 따른 개발 비용이 상승하고 있습니다. 그러므로 전체 개발 비용 측면에서 더 연봉을 주고 검증된 중급 이상 개발자 채용하는 것이 오히려 전체 개발비를 낮추는 것이 되기도 합니다.

 

개발이 되었다면 광고/홍보/이벤트 등의 프로모션 비용이 추가됩니다. 투자를 받아 투자사의 홍보 네트워크를 활용할 수 있는 상황이 아니라면 앱/웹 서비스 프로모션 비용은 개발비만큼 들어가기도 합니다.

 

이미 모바일 게임의 경우 개발비가 100억 이상 되는 시기가 되었으며, 프로모션 비용도 100억을 넘는 게임도 상당히 존재합니다. 

 

여기에 서비스를 유지 운영하기 위한 비용도 상당합니다. 동영상 콘텐츠처럼 용량이 상대적으로 큰 경우, 일간 이용자가 사용자가 많은 경우 앱/웹 서비스를 유지하기 위한 비용도 상당합니다.

 

인지도 있는 앱/웹 서비스가 청산하는 경우 종종 서버비가 밀렸다는 뉴스를 볼 때가 있습니다. 이때 언급되는 비용이 최소 수십억 원에 달하는 경우가 많아 온라인 서비스 기업에게 서비스 유지에 필요한 서버 비용도 상당하다는 것을 알 수 있습니다.

 

이렇게 다양하고 많은 비용을 견지고 사용자를 확보하고 모은 이후에야 비로소 충분한 매출을 올릴 수 있는 상황이 마련됩니다.

     

충분히 많은 사용자와 트래픽이 확보되었다면 매출을 올릴 수 있는 준비가 된 것입니다. 특히 무료 서비스의 경우 광고를 붙일 수 있게 됩니다. 

 

물론 광고를 붙일 수 있다는 것이 충분한 매출을 장담하는 것은 아니지만, 최소 서비스 매출을 올리 수 있다는 것이 지금까지 비용 상황을 보면 기대할 만한 순간이 된 것입니다.

 

이커머스 같이 작은 사용자로도 매출을 올릴 수 있는 경우에도 충분한 사용자와 트래픽은 매출 규모는 물론 더 많은 판매자를 유입하는데 도움이 됩니다. 즉 이전 매출과는 비교할 수 없는 미래 매출의 기반을 만든 것입니다.

 

그런데 매출을 이야기할 때 항상 충분한 사용자와 함께 트래픽을 언급한 것을 주목해야 합니다. 아무리 DB에는 가입자가 많더라도 이들이 1달에 한 번도 방문하지 않는 사용자라면 매출은 기대하기 어려워집니다.

 

그런데 많은 가입자가 아닌 활성 사용자는 이미 개발 전에 결정되는 경우가 대부분입니다.    

 

 

 

수익화는 개발에서부터 시작해야 하는 이유 

 

사용자의 앱/웹 서비스 이용과 관련한 것들은 이미 개발 이전 설계 완료됩니다. 앱/웹의 개발은 이 설계를 바탕으로 진행하는 것에 지나지 않습니다. 물론 개발에 문제가 있어 사용자 이용 시 에러가 있다거나 서비스가 다운된다면 문제가 있을 것입니다. 하지만 그렇지 않더라도 한번 설계된 서비스를 바꾸는 것은 농구장을 축구 경기장으로 만드는 것 이상 어렵습니다.

 

이는 단지 보이는 화면과 확인 가능한 기능을 변화시키는 것에 그치지 않습니다. 게임의 룰과 상호 관계, 밸런스를 조정해야 하는 일이 있습니다. 국민 스타크래프트가 서비스된 이후에도 계속 밸런스 조정을 했던 것에서도 어려움을 알 수 있습니다.

 

밸런스가 게임성에 영향을 미치듯이 서비스 정책과 기능 프로세스, 화면 구성, 이용 보상 등의 밸런스는 사용자의 서비스 경험에 영향을 미치게 됩니다.

 

이러한 요소들은 하나가 전체에 영향을 주기도 하고, 그렇지 않기도 합니다. 그러므로 이러한 설계는 개발 전에 완료되어 있어야 합니다. 이를 서비스 기획이라 부릅니다.

 

결국 온라인 서비스 기획에서 앱/웹이 개발된 이후 이용할 사용자 경험의 상당 부분이 계획되는 것입니다. 개발은 이를 구체화하는 작업입니다.

 

그러기에 앱/웹 트래픽은 개발의 문제보다는 서비스 기획의 문제인 경우가 많습니다.

 

물론 애자일 개발, MVP를 통해 최소의 서비스 가설을 기반으로 최소 기능 개발 후 사용자 반응을 보며 개발을 추가하는 방법을 취할 수도 있습니다. 이 때도 애자일이나 MVP에 적합한 서비스 설계가 필요합니다. 이때는 일종의 반응형 설계로 기존 기본적인 서비스 설계와는 다릅니다.

 

가입자를 늘리는 것은 광고와 보상을 통해 유도할 수 있습니다. 그러나 아무리 앱/웹에 가입했더라도 충분한 이용 가치, 사용자 경험이 뒷받침되지 않는다면 보상만 받고 서비스를 떠날 것입니다.

 

가장 많은 개발자 편견 중 안정적으로 더 나은 기술로 개발되면 사용자가 이용할 것이라는 것이 있습니다. 디자이너 편견 중 트렌디하고 완성도 높은 디자인을 적용하면 서비스 가치가 향상될 것이라는 것이 있습니다.

 

물론 사용자 입장에서 안정적 앱/웹과 기술이 이용 경험에 의미가 있는 경우, 앱/웹 디자인이 사용자 가치에 의미가 있는 경우라면 당연히 트래픽도 늘어날 것입니다.

 

그러나 대부분의 사용자는 개발자도 아니고 디자이너도 아닙니다. 그렇기에 이런 일이 일어나는 것은 길을 걷다가 오만 원을 줍는 확률처럼 매우 낮은 편입니다.

 

그리고 이미 서비스 기획 시 서비스 가설을 통해 사용자 가치와 경험에 대한 분석과 설계를 했습니다. 그럼에도 이와는 별개로 다시 개발과 디자인에서 이를 한다는 것은 마치 기획자가 코딩하고 개발자가 디자인하는 것만큼 비효율적이고 퍼포먼스 안나는 일이라는 사실은 분명합니다.

 

결론은 이미 서비스 기획 시 사용자 경험, 가치 설계가 된다는 것입니다. 그럼에도 만약 사용자와 트래픽이 예상보다 낮다면 가설 검증과 분석, 재설계의 과정을 거쳐야 합니다. 그리고 오차 이유를 찾아 개발에 반영해야 합니다. 그래서 가볍고 빠른 MVP 개발을 추천하는 것이기도 합니다.       

   

 

 

댓글