대중적인 서비스 종류, 플랫폼별 프로젝트 난이도
프로젝트 기준별 난이도가 높은 서비스들과 그 이유에 대해서
서비스 종류별, 플랫폼별 프로젝트 난이도에 대한 정리본. 필자가 직접 경험해보거나, 설계 제안서를 통해 구축 난이도를 파악한 것들을 위주의 정리본이다. 모든 서비스를 정리하긴 어려울테니, 대중적인 서비스 종류, 플랫폼별 난이도를 다뤘다고 생각해주면 될 것 같다.
1. 콜센터 / 고객센터 CRM : 난이도 6 / 10
전화를 통해 개별 인원별 고객응대를 진행하는 서비스. 일반적으로 24시간 운영하는 케이스와, 특정 시간에만 운영하는 두가지 방식이 있다. 매뉴얼대로 처리하는 단순작업이기 때문에 추후 AI서비스로 대체될 가능성이 높은 상태다. 또한 문제발생시 화가 난 고객응대를 해야하는 경우가 많고, 그 문제를 해결해줘야한다는 점이 있어 개별 상담자의 경험치가 꽤 중요하다.
개별 상담내역을 모두 녹음해야하며, 상담내역 및 결과를 '요약해야한다는 점' 때문에 개별 상담자의 정보정리 능력이 중요해진다. 다만 Voice to text 형태의 텍스트 추출기능과, GPT 기반의 Text 요약 등의 내용을 바탕으로 기록요약, 카테고리 선택 등을 좀 더 효율적으로 처리할 수 있다. 여러 인원들이 동일한 매뉴얼을 보고 응대하며, 문제발생 건들을 다시 요약해 응대매뉴얼을 업데이트해줘야한다. 또한 개별 인원이 서비스 관제역할을 하는 경우도 있어서, 어드민 페이지와 함께 콜센터 화면이 녹아들어있는 형태가 만들어질 때도 있다.
2. 부동산 매물 정보제공 서비스 : 난이도 7~8 / 10
지도 서비스를 바탕으로 부동산 매물 및 대지 정보를 모아 보여주는 서비스. 대부분의 정보를 국토교통부나 오픈 API 서비스에서 가져올 수 있지만, 수많은 매물들을 계속해서 업데이트해줘야한다. 아파트, 주택, 오피스텔 같은 주거 건물형태부터, 상가, 공장단지, 지식센터 등 다양한 상업용 매물들도 존재한다. 그래서 각 매물들이 갖고있는 각자 정보를 '어디로부터 끌어와서, 어떤 순서로 보여줘야할지'를 체계적으로 정리해야한다.
지도 기반의 무거운 커스터마이징이 많이 들어가기때문에, 지도 커스텀작업 외에 D3.js 라이브러리를 이용한 정보시각화 등의 작업이 필수적이다. 연속지적도나 지역별 경계구분, 건물영역 정리 등의 작업을 추가해줘야하며, 개별 필터링 기준점이 상당히 다양하다. 일반 매매가 아니라 업자 기준의 매매를 도와야하니, 쓰이는 용어나 금액표기단위도 1억단위에서 100억단위까지 다양한 편. 가격이나 위치 기준 검색결과를 필터로 묶어주는 백엔드 DB가 상당히 중요한 서비스다.
3. 구인구직 플랫폼 : 난이도 4~5 / 10
사람을 구하는 업체측과, 직업을 찾는 구직자를 연결시켜주는 서비스 플랫폼. 업체측은 사업자 번호 등을 인증하여 개별 업체정보를 작성해야하며, 가입 후 구인 공고를 작성할 수 있다. 구직자는 가입 후 본인인증이 필수적이며, 이력서 형식의 정보를 저장, 업데이트할 수 있도록 세팅이 필요하다. 각각의 구인공고에 정보를 연결하는 형태이며, 업체나 기업들의 '추가정보'를 입력하지 않아도 끌어올 수 있을지. 또한 입력된 정보를 어떤식으로 수치화해 보여줄 것인지가 관건이 된다. 다만 서비스의 전반적인 구조는 단순한 편이기에 설계 난이도는 높지않다. 대부분의 실제 구인, 면접 등은 별도 전화를 통해 진행되는 경우가 대부분이라, 구인구직의 모든 단계를 다루기보다, 업체와 구직자의 매칭, 정보확인 과정이 가장 중요하다고 보면 된다.
4. 입점형 B2B, B2C 커머스 플랫폼 : 난이도 8~10 / 10
커머스 플랫폼은 '구매자'와 '판매자, 그리고 '관리자' 라는 세가지 타입의 사용자를 고려해야한다. 우리가 자주 접하는 지점은 '구매자' 위주의 서비스가 많기 때문에, 판매자와 관리자 지점을 놓치는 경우가 많다. 커머스 서비스는 크게 입점형과 자사몰 형태의 커머스로 나눌 수 있는데, 가장 큰 차이는 '플랫폼' 안에 '개인사업자'가 들어올 수 있는지. 아니면 고정된 하나의 회사만 제품을 판매하는가에 대한 부분이다.
입점형 커머스는 당연히 판매자 등록과정부터, 제품등록 과정이 복잡하고 개별물품 등록, 재고관리, 판매관리, 배송관리, 정산관리 등 다양한 지점을 고려해야한다. 판매되는 물품이 하나의 비즈니스 범주로 고정되어있는지, 아니면 여러 비즈니스 범주를 모두 포함하는 통합 커머스 타입인지에 따라 복잡도가 더 올라갈 수 있다. 단일 품목의 B2C 커머스는 상대적으로 난이도가 더 낮은 편이며, 통합 커머스 타입인 경우 B2C나 B2B 모두 난이도가 10 이상이라고 생각하면 된다.
5. O2O 서비스 중계 플랫폼 : 난이도 6~7 / 10
O2O 서비스는 실제 업무 제공자와 계약을 맺고, 고객을 서로 연결해주는 형태가 대부분이다. 자체적으로 서비스 제공자를 회사 내부에 두는 경우도 있지만, 대부분 확장성의 문제로 인해 지역별 협업사를 두는 프랜차이즈 형태가 된다. 사람을 연결해주는 과정에서 발생하는 수수료와, 별도 가격견적을 발송하는 입찰형태의 기능이 들어가는 경우가 많다. 대부분의 서비스 요청이 발생하는 지점과, 서비스 제공자들의 실 거주지가 다르기때문에 별도 방문예약이 필요한 경우가 생길수도 있다. 이 경우 UI를 통한 예약과정을 포함할 수 있고, 채팅이나 전화를 통한 추가적인 상담이 필요한 경우가 많다.
별도 서비스 담당자가 예약방문을 해야하는 경우, 방문절차나 예약과정에서 전화번호나 주소정보 등을 확실하게 확인해야한다. 오프라인의 서비스 제공자는 별도의 앱이나, 지령을 받아볼 수 있는 플랫폼을 이용하게된다. 다만 이 경우에도 정보가 충분하지 않아 관제를 요청하는 경우가 많은데, 이런 이유 때문에 관제요원의 경험치가 서비스 진행에 영향을 주는 경우가 많다. 음식배달, 청소 예약 서비스같은 것들이 O2O 서비스 중계 플랫폼에 속한다.
6. 동영상 스트리밍 플랫폼 : 난이도 4~5 / 10
동영상 스트리밍 플랫폼은 말 그대로 동영상들을 끌어다 실시간 스트리밍을 해주는 서비스다. 개별 영상들의 업로드를 서비스 관리자만 할 수 있는지, 아니면 개인회원들이 가능한지에 따라 서비스 설계 난이도가 달라질 수 있다. 다만 전반적으로 설계 난이도는 낮은 편이며, 영상 업로드시 얼마나 다양한 정보를 입력해야하는가에 따라 DB 설계 복잡도도 달라질 수 있다. 또한 비디오 태그와 목록을 검색하거나, 인기도를 보여주는 등 검색기능도 고민해야해서, 이 부분을 AI 기반으로 태깅처리하는 경우도 있다.
일반적인 텍스트나 이미지에 비해 데이터 트래픽이 매우 무겁게 사용되므로, 사용자 수에 따라 유지비용이 정말 어마어마하게 나오는 것이 문제점이다. 그래서 특정 코덱을 통한 영상 변환 압축기술이나, 제한된 시간의 동영상만을 업로드할 수 있게 만드는 등의 제약조건이 꼭 필요하다. 비디오 업로드 이후 개별 영상들을 Public 상태로 오픈할 수 있는 경우, 음란물이나 폭력적 영상 등을 걸러낼 수 있는 검수팀이나, 모니터링 솔루션이 꼭 필요하다. 영상 재생에 쓰이는 동영상 플레이어의 경우, 자체적으로 개발하는게 아닌 이상, 대부분 솔루션 형태로 사용하는 경우가 많다. 만들어진 영상을 정해진 규격으로 업로드하거나, CCTV나 캠코더 등의 별도 영상기기 코덱을 읽어들여 실시간으로 스트리밍 + 저장하는 경우도 존재한다.
7. 사업자 대상 경정청구 서비스 : 난이도 4~5 / 10
사업자들의 세금내역을 바탕으로 환급받을 수 있는 금액이 있는지 체크하고, 세무사에게 계약을 요청할 수 있는 서비스다. 개인사업자와 법인사업자로 크게 두가지 타입을 나눌 수 있다. 개인사업자와 법인 사업자 모두 홈택스 기반의 정보를 불러와 세금납부 여부를 체크하고, 그 정보를 바탕으로 '환급가능 여부'를 확인하게된다. 알고리즘 자체는 단순한 편이나, 홈택스에서 세금납부 정보에 대해 API를 제공하지 않기 때문에 별도 서비스를 사용해야한다. 이 경우 스크래핑 형태의 제 3사 홈택스 API 서비스를 찾아야하며, 업체별로 제공하는 정보 범위나, 이용료가 다르니 주의가 필요하다.
또한 개인사업자와 법인사업자 여부에 따라 기능구현 방식에 차이가 있다. 개인사업자의 경우 간편인증 등을 통해 모바일 환경에서도 홈택스 정보 연동이 가능하다. 하지만 법인사업자는 현재 홈택스가 공인인증서 기반 로그인만을 제공하기에, PC 환경에서만 홈택스 정보 연동이 가능하다. 심지어 법인사업자의 경우 이 공인인증서 로그인을 지원하기 위해, 별도의 설치형 공인인증서 연동 프로그램을 개발해야한다. 이 경우 웹서비스임에도 별도 C언어 기반의 windows 프로그램을 개발해야하므로, 해당 기술을 갖고있는 개발자에게 별도 작업요청이 필요하다. 다만 이런 특이점을 제외하면 전체적인 설계 난이도는 높지 않은 편이다.
8. CPC 리워드 광고집행 관리 서비스 : 난이도 5~6 / 10
광고집행 서비스는 금액을 충전하고, 광고집행을 별도로 요청하는 형태가 대부분이다. 광고집행은 원본이미지와 앱 다운 URL 등 광고대상에 대한 정보가 필요하며, 여러 모바일 환경에 맞게 변형 배너 이미지 작업이 꼭 필요하다. 개별 광고주들은 광고 신청 후 광고용 리소스 제작, 실제 광고 집행까지 대기하게된다. 실제 광고집행 이후에는 광고관리 admin 웹에서 개별 광고진행 상태를 확인할 수 있다. 개별 클릭별 사용되는 금액은 계약시 고정금액으로 정해지는 경우가 많으며, 상황에 따라 클릭별 금액을 변동하거나, 노출 플랫폼 범위를 변경하게 되는 경우도 있다.
광고집행을 위해 사람의 손이 많이 간다는 점에서 효율성이 떨어지지만, 최근에는 이 과정을 일부 자동화한 케이스가 등장하고있다. 광고플랫폼을 위해 갖고있는 자사앱이 얼마나 많은지, 광고 노출이 가능한 지점이 얼마나 다양한지, API 형태의 광고 연동이 가능한지에 따라 서비스 설계 난이도가 달라질 수 있다.
9. 환자의료기록 및 의료진 수가관리 플랫폼 : 난이도 5~6 / 10
환자들의 의료기록에 대한 정리 및 의료진들의 의료행위 기록을 남겨, 개별 수가를 책정해 정산처리하는 서비스다. 정보자체가 익숙치 않아 어렵게 느껴질 수도 있겠지만, 설계 난이도 자체는 높지않은 편이다. 환자들의 신상정보와 병명, 내방기록, 처방명 등의 정보를 다뤄야하며, 별도 사용자 복약관리나 건강상태 체크 등의 기능을 제공하기도 한다. 블루투스 기반의 의료기기 연동을 통해 자동으로 데이터를 입력하는 경우도 있으며, 식단관리 기능까지 포함하는 경우도 있다.
의료진 측에서는 병원 관리자와 의료행위자가 별도로 존재하며, 관리자는 개별 의료행위자 (의사) 의 평균 의료행위 횟수나, 개별 행위의 가격 (수가)에 대한 지점을 별도로 관리하게된다. 대부분 의료행위에 대한 증빙서류를 만들어 실제 수가를 청구할 때 제출하기 위한 용도다. 별도로 환자수에 대한 통계화면을 제공하기도하는데, 규모가 큰 지점별 병원이거나, 의료 행위자 (의사) 수가 많은 경우, 이런 통계화면이 더욱 중요해진다.
10. 비즈니스 관리용 ERP 및 그룹웨어 플랫폼 : 난이도 8~9 / 10
ERP나 그룹웨어는 기업에서 이용되는 재고관리, 업무결재, 이메일, 메신저 등의 내용을 통합적으로 다루는 경우가 많다. 심지어 서비스별로 다뤄야할 비즈니스 아이템의 종류나 유닛 단위가 다르기 때문에, 별도 서비스마다 맞춤형 ERP 제작이 필요해진다. 일반적인 사무용 그룹에서는 더존이나 다우같은 그룹웨어를 사용할 수 있겠지만, 제조업이나 공사현장, 의류업 같은 '공장'에 연관된 서비스들의 경우 일반 사무용 ERP나 그룹웨어를 사용하기가 쉽지 않다. 또한 생산현장에서 창고로, 창고에서 중간 유통으로, 실제 매장으로 옮기는 과정에 대한 납품기록이나, 외부 업체로의 아웃소싱, 개별 업체별 입금 및 정산처리 등의 작업을 모두 고려하여 설계해야한다.
실제 ERP는 설계 지점에서 가장 난이도가 높은 서비스들 중 하나이며, 백엔드 DB 설계가 상당히 복잡한 서비스이기도 하다. 어떤 사람이 어떤 그룹에 속해있고, 다시 그 그룹이 어떤 부서로 나뉘는지. 거기에 연관된 사람은 누구이고 각자가 어떤 역할을 하는지. 그 부서에서 '어떤 업무요청'을 했고, 그 요청이 다시 '어느 지점'의 누구에게 연결되었는지. 해당건을 진행하기 위해 얼마나 되는 금액이 필요하고, 그걸 누가 승인했는지. 승인한 내용들이 다시 '어떤 과정'을 통해 물건을 매입하고, 그 과정에서 소모된 금액은 얼마였는지. 그 소모된 금액에 대한 증빙서류는 무엇이고, 물건의 배송 및 출고 / 입고 상태는 어떠한지. 이런 모든 과정을 제대로 이해해야 서비스를 설계할 수 있다.
-
이외에도 필자가 직접 경험해본 서비스들의 종류가 여럿 있는데, 이번 글에서 모두 다루지는 못할 것 같다. 추후 별도 플랫폼들에 대해서도 정리해볼 예정이다.
