가상의 온라인 대출 비교 서비스 기획 연습

서비스 기획 시 지금까지 이야기했던 내용들이 어떻게 응용될 수 있는지 사례를 통해 정리해 보겠습니다. 우선 온라인 비교 대출 서비스를 통해 서비스 기획 프로세스와 각 항목들을 어떻게 작업하는지 알아보려 합니다. 이번을 시작으로 앞으로 더 많은 케이스를 스터디해 보도록 하겠습니다.

 

 

서비스 니즈와 환경분석

먼저 서비스 니즈는 당연히 온라인 대출 비교 서비스를 진행한다는 것입니다. 이에 대한 결정은 사업 기획을 통해서 확정되었을 것입니다. 단순히 사업적인 가능성을 보았을 수도 있습니다. 그러나 금융 회사에서 이를 진행하기로 했다면, 기존 금융 사업과의 시너지와 상품 개발 등의 시너지를 고려했을 수도 있습니다.

 

 

서비스 니즈 : 온라인 대출 비교 서비스

서비스 기획자는 기업의 서비스 니즈를 간단히 위와 같이 정리할 수 있습니다. 이에 따라 사업 기획에서 조사한 자료 및 수립한 전략 등이 함께 제공될 수도 있습니다. 우리는 여기서 이 내용은 없다고 가정합니다. 단지 온라인 대출 비교 서비스를 한다는 것만 전달된 상황으로 가정합니다.

 

보통 서비스와 관련한 기업 내 의사 결정은 복잡한 과정과 의사 결정을 통해 이루어질 것입니다. 하지만 결론은 간단합니다. 어떤 서비스를 진행한다는 것으로 정리될 수 있습니다.

 

우리가 스터디할 케이스인 온라인 대출 비교 서비스를 진행하는 것으로 결정했더라도, 기업에 따라 여러 부가적인 조건이 붙을 수도 있습니다. 그러나 결론은 온라인 대출 비교 서비스를 한다는 사실 하나입니다.

 

각 기업의 상황이나 전략적 선택 사항은 다양할 수 있으므로 여기서는 가장 기본이 되는 서비스 니즈인 온라인 대출 비교 서비스 진행만 가정합니다.

 

  

서비스 환경 분석

서비스 환경은 우리가 앞서 살펴보았듯이 크게 내부 환경과 외부 환경으로 구분하여 볼 수 있습니다. 내부 환경은 기업 내부의 서비스 진행 자원과 관련이 있습니다. 그리고 외부 환경은 서비스 시장 사용자와 경쟁 서비스 등과 관련이 있습니다. 

 

서비스 환경과 관련한 기본 자료들은 사업 기획 시 환경 분석 및 전략 내용에 담겨 있습니다. 또한 비즈니스 모델 캔버스를 통해서도 잘 정리되어 제공될 것입니다.

 

서비스 기획자는 이렇게 사전 정리된 자료를 토대로 향후 진행할 구체적인 온라인 서비스 환경과 관련한 세부 정보를 추가로 좀 더 면밀히 수집하고 분석하는 작업을 합니다.

 

 

서비스 내부 환경

여기서는 온라인 대출 비교 서비스와 관련한 가치를 생성하고 이 가치를 관리할 수 있는 기업의 자원이 내부 환경입니다.

 

자원은 물질이나 시스템, 투자금일 수도 있습니다. 그리고 인력이나 기술력일 수도 있습니다. 기획자가 확인해야 하는 내부 환경은 서비스 가치 알고리즘과 관련하여 기업 내 자원의 유무와 경쟁력입니다.

 

일반적으로 대출 비교를 위해서는 다른 금융사의 대출 상품 정보가 필요합니다. 이를 서비스 기업이 직접 각 금융사와 컨택을 해서 개발할 수도 있을 것입니다. 그러나 이를 해결하기 위해서는 시간과 개발 비용이 들어갈 것입니다.

 

여러 금융사의 대출 상품 정보와 연동을 쿠콘과 같이 서비스를 통해 해결할 수도 있습니다. 쿠콘 API를 활용한다면 개발 시간은 단축되지만, 사용자가 대출 비교를 할 때마다 비용이 발생할 것입니다. 물론 초기 비용은 적을 수도 있지만 사용자가 많아지면 질수록 비용은 커질 것입니다. 또한 대출 비교 서비스의 중요한 부분이 쿠콘에 종속될 수도 있습니다.

 

자원 효율성은 이러한 여러 상황에 대한 의사결정을 포함하고 있습니다. 내부 개발은 어느 정도로 하고, 외부 API는 어느 수준으로 활용할 것인지에 대한 결정은 기업이 목표로 한 서비스 가치와 사용자 경험의 수익성 측면, 그리고 다음에 다루는 경쟁자 상황에 따라 달라집니다.

 

 

서비스 외부 경쟁 상황

대출 비교 서비스는 핀다와 같은 핀테크 스타트업뿐 아니라 토스와 같이 이미 핀테크 유니콘을 넘어선 스타트업, 그리고 시럽 등 기존 IT 대기업에 이르기까지 다양한 기업이 제공하고 있습니다. 이미 이런 기업들은 서비스를 운영 중이므로 지금 막 시작하려는 기업에 비해 유리한 점이 있을 것입니다.

 

이미 많은 대출이 필요한 사용자들은 대출 비교 서비스를 사용해 본 상황입니다. 핀다 같은 스타트업은 물론 토스나 시럽 같이 기존 가입자 레버리지를 활용할 수 있는 기업들도 적극적인 홍보와 마케팅 프로모션을 이미 진행하고 있는 상황입니다.

 

중요한 사실 중 하나는 현재 기업이 대출 비교 서비스를 개발할 때 고려하고 있는 쿠콘과 같은 대출 비교 API 서비스가 이미 제공 중이라는 사실입니다.

 

이는 마음만 먹는다면 누구나 대출 비교 서비스를 진행할 수 있다는 것을 의미하며, 이미 시장은 초기 시작되어 경쟁 기어들이 별로 없는 상황에서 가파르게 시장은 성장하는 블루오션 시기는 지났음을 의미하기도 합니다.

 

이는 대출 비교 자체가 서비스의 핵심 경쟁우위 역량이 되기 어려움을 의미하기도 합니다. 기본적으로 대출 자체가 서비스 플랫폼이 만들 수 없는, 연동 금융사들이 제공하는 상품을 연결해 주는 것이기 때문입니다.

 

 

서비스 가설

 이미 온라인 대출 비교 서비스를 하기로 결정된 이상 적절하고, 시장 유효한 서비스를 제공하는 것이 필요합니다. 그런데 앞서 서비스 환경에서 보았듯이 대출 비교 자체만으로 차별화를 구현하기 어려울 수 있기에 이와 연결되는 서비스 가치 형성 요소의 고려가 필요합니다.

 

핀다와 같은 경우 사용자 인식에 대한 우위를 통해 온라인 대출 비교 서비스의 우위를 형성할 수 있을 것입니다. 시장 인식 우위 요소를 기반으로 투자를 받아 부가 가치가 형성되는 연결 서비스를 추가로 고민할 수도 있습니다. 그렇다면 비록 대출 비교 사업으로 시작되었지만, 시너지의 폭발은 다른 곳에서도 발생할 가능성이 있습니다. 이는 각 서비스 구성 내용의 시너지와 밸런스를 얼마큼 형성할 수 있고 유지할 수 있는가의 문제가 될 수도 있습니다. 기업 규모가 커질수록 기능과 조직은 분화하기 때문에 이에 따른 조율 역량이 더 필요해질 것입니다.

 

토스와 같은 기업은 대출 비교 서비스를 통한 매출 기대보다 토스 앱을 더 자주 사용하게 하는데 관심이 있을 수 있습니다. 투자 여력이 더 나을 수도 있지만 비교 대출 서비스 부문의 목표가 직접적인 수익성이 아니므로 더 많은 전략과 전술적 판단을 할 수 있을 것입니다.

 

그렇다면 이러한 상황에서 지금 우리 기업이 하려는 대출 비교 서비스가 어떻게 경쟁력을 가질 수 있는 것일까요?

 

이에 대한 설계를 우리는 온라인 대출 비교 서비스 가설이라고 부릅니다.

 

       

사용자에서 시작하는

너무나 당연하지만 어려운 것이 서비스의 설계를 사용자에서 하는 것입니다. 일단 기획자는 사용자가 아닙니다. 그리고 다른 서비스를 사용했었다고 해도 우리 서비스가 없는 상황에서 사용이기에 변수가 다릅니다. 또 자신이 우리 서비스를 기획하고 있다는 상황(위치) 변수 또한 이를 어렵게 합니다.

 

그래서 사용하는 방법이 페르소나를 활용하여 가상의 사용자를 형성하고 이 페르소나의 성격에 기반하여 서비스를 구성하는 것입니다. 이런 활동은 기본적으로 가상의 사용자를 기반으로 하고, 앞으로 서비스를 대상으로 한다는 점에서 서비스 사설 수립이라 할 수 있습니다.

 

 

핵심 사용자 정보

사용자 페르소나는 데이터에 기반하여 형상화합니다. 일종의 인공지능(AI) 챗봇이 데이터 학습에 의해 성향을 나타내는 것과 비슷한 것이라 보면 됩니다. (아예 인공지능(AI)을 가지고 특정 사용자 데이터 세트를 통해 학습을 하여 가상의 사용자를 만들어 낼 수도 있을 것 같습니다)

 

핵심 사용자 정보에 기반한 페르소나는 서비스를 통한 사용자 경험을 설계할 때 유용합니다. 

 

예를 들어 대출이 필요한 사용자와 관련한 데이터를 통해 대출 비교 플랫폼의 사용을 촉진한다든지, 반복 사용을 유도할 수 있을 것입니다. 또한 서로 다른 대출 관련 선호가 있는 사용자를 파악하여 시장을 세분화한다든지, 기존 경쟁 서비스의 약점을 파고드는 서비스 내용을 구성할 수도 있을 것입니다.

 

앞서 서비스 환경 분석 시 현시점 표준화된 API의 사용이나, 여러 금융사와의 연동 정보에 기반하는 대출 비교 서비스 특성상 핵심 기능이라 할 수 있는 대출 비교에서 차별화가 쉽지 않을 수 있다고 했습니다. 그러나 대출을 원하는 사용자의 전반적인 취향과 라이프스타일 등 다른 요소를 통해 서비스 플랫폼 차별화는 가능합니다.

 

이런 방법 중 하나가 기존 서비스와 연결하여 가치를 증가시키는 것이 있을 수 있습니다. 또 다른 하나로 원스톱 대출 지원 프로세스를 서비스 플랫폼 안에서 진행할 수 있도록 지원할 수 것입니다. 대출 관리 기능을 추가할 수도 있을 것입니다. 대출받은 자금의 운영과 상환 관리, 더 나은 조건의 대출이 나오면 전환 지원 등의 서비스 기능을 지원할 수 있을 것입니다.

 

이러한 서비스 아이디어는 핵심 사용자 페르소나를 통해 시뮬레이션하여 우선순위나 적용 여부를 결정하게 됩니다.

 

    

서비스 지향 가치와 경험 구체화

서비스 가설은 결국 어떤 서비스를 제공할 것인가를 위한 작업입니다. 그리고 이 내용이 사용자와 만나면 구체적인 서비스 경험이 됩니다.

 

서비스 경험은 서비스와 사용자의 상호 작용, 즉 관계 속에서 나타납니다. 이는 사용자가 대출 비교 서비스를 이용하는 앱에서 이루어질 수도 있고, 앱의 다양한 이벤트와 혜택을 통해 커질 수도 있습니다. 대출이라는 돈이 이동하는 특성상 개인 정보의 안전이나 대출 피드백 속도, 금융사의 요구에 대한 처리, 사용자의 문의 처리 등의 여러 요소가 사용자의 이용 안정감과 함께 만족을 향상할 수 있습니다.

 

그렇다고 시장 사용자들이 이용하는 모든 기능을 탑재하는 것은 비효율적입니다. 이는 사용자 성향에 따라 대출 비교 서비스 이용이 복잡하게 느껴질 수 있으며, 불편함을 느끼게 할 수도 있습니다. 

 

그렇다고 서비스 기능을 너무 심플하게 하는 것은 사용자의 서비스에 대한 부족함을 불러올 수도 있고, 다른 서비스로의 이탈을 만들 수도 있습니다.

 

이러한 부분의 결정이 바로 서비스 경험 구체화 계획이며, 이 기준은 서비스가 지향하는 가치에 기반해야 합니다.   

 

 

서비스 정책

대출 비교 서비스와 관련하여 회원 가입 정보 입력과 보관, 로그인 방식, 대출 데이터 처리 및 대출 정보 보관 기간 등의 정책을 결정해야 합니다. 이러한 서비스 정책은 법률에 정함이 있다면 이에 따라야 합니다. 그러나 법률에 정함이 없다거나 법률의 정함보다 타이트한 정책은 기획자의 결정사항입니다.

 

 이러한 서비스 정책 사항은 앱 정책과 다릅니다. 서비스 정책은 내부 개발을 할지, 외부 개발을 할지 같은 것뿐 아니라, 고객 센터 운영과 제휴 금융사 우선순위, 제휴 시 협의 내역 등에 이르기까지 앱을 통한 서비스 운영 전반을 커버합니다. 그러나 앱 정책은 주로 앱과 관련한 이용 정책, 관리 정책 등 앱에 한정되게 됩니다.

 

간단히 회원 정책을 생각해 보겠습니다. 우선 가입 시 받는 정보를 정해야 합니다. 기본적으로 대출을 위한 서비스이므로 많은 개인정보가 필요할 수 있습니다. 또한 다양한 정보를 통해 금융 서비스 확장성을 확보할 수도 있습니다. 그러나 너무 많은 정보를 가입 시부터 요구하면 회원 가입율이 떨어질 수 있습니다. 그리고 아이디와 비밀번호를 통한 로그인 적용할지, 간편 인증을 통한 로그인을 사용할 지도 다르게 정할 수 있습니다.

 

대출 비교가 빈번히 사용이 일어나는 것이 아니라는 측면에서 비회원 사용을 가능하게 할 수도 있습니다. 이때도 개인 정보에 대한 요구/관리 관련 사항을 정해야 합니다. 회원 보다 비회원의 정보의 보관 기간은 짧게 가져갈 수도 있고, 대출 관련 개인 정보의 기간은 회원과 동일하게 가져갈 수도 있습니다.

 

이러한 전반적인 서비스 관련 정책을 수립해야 합니다. 대출 같이 개인 정보가 많이 사용되는 서비스 관련 정책은 매우 복잡하고 광범위할 수도 있습니다. 분명한 것은 정보를 요구하고 사용되는 기능 부분에 있어서는 명확해야 합니다.

 

 

서비스 기능  

언뜻 대출 비교 서비스와 관련하여 생각나는 기능은 대출 비교 기능입니다.

 

이 기능이 쿠콘 API를 통해 이루어진다면 연동 규격에 대한 정의가 필요합니다. 이때는 기능이 작동되는 케이스 별로 API 요소를 정리해 놓으면 편리합니다.

 

그리고 만약 각 금융사와 직접 연동을 통해 이루어진다면 금융사마다 필요한 연속 규약을 각각 맺어 관리해야 합니다. 이 또한 정리를 해 놓으면 향후 서비스 유지/보수, 업그레이드 시 유용할 것입니다.

 

이외 대출 비교 플랫폼에서 제공하려는 기능들은 각각 정의와 플로우 설계를 진행해야 합니다. 이런 부분은 앱 개발 전 서비스 기획 시 어떤 서비스를 계획하는지에 대한 부분이라 할 수 있습니다. 서비스 기획에서 서비스 프로세스 작업을 하는 이유가 바로 여기에 있습니다.

 

 

서비스 구조

서비스 가설에 따라 서비스 정책과 기능이 정리되면 이를 통해 전반적인 서비스 구조를 먼저 설계합니다. 이를 통해 서비스 가설과 정책, 기능의 빠진 부분, 부족한 부분을 체크한 후 좀 더 세부적인 서비스  구조 작업을 진행합니다. 물론 MVP 같이 핵심 기능 위주 서비스 진행을 한다면 추가적인 서비스 구조 설계 작업은 필요하지 않을 수 있습니다.

 

서비스 구조 작업이 완료되면 각 서비스 기능 부분의 플로우(프로세스) 설계를 진행합니다. 이때 정책과 기능 정리 내용을 참고하여 작업하게 됩니다.

 

아래의 그림은 제가 상상을 통해 간단히 그려본 서비스 구조입니다. 대출 비교와 이에 대한 정보, 결과 처리와 정산 등의 간단한 구조로 되어 있습니다. 

 

가상의 온라인 대출 비교 서비스 대출 비교 진행 그림

 

 실제 대출 비교 서비스의 구조는 위의 이미지보다 더 복잡할 것입니다. 그리고 위 그림에서도 추가해야 할 세부 프로세스가 있을 것입니다.

 

서비스 기획자는 사업 기획자와 함께 이에 대한 세세한 필요 처리 내용과 대응되는 서비스 정책 등을 수립해야 합니다. 이에 따라 서비스가 기획되고 개발될 뿐 아니라, 관리자 페이지 및 관리 기능도 설계되고 개발됩니다.

 

 

※ 본 글은 연습을 위해 제공되는 사례입니다. 실제 서비스 기획의 상세한 내용은 아닙니다.

연습을 위해 제공되는 예시입니다.

실제 서비스 기획 작업이 필요하시면 문의 해 주세요.