[실패기-2] 폐쇄망에서 안정적인 수익이 발생하고 있는 제품을 공개망으로 전환하려면?

앞서

[실패기-1] 폐쇄망에서 안정적인 수익이 발생하고 있는 제품을 공개망으로 전환하려면?

개발을 진행하는데 곤란했었던 경험

• 앞서 실패기-1 에서 개발에 대해 주로 이야기 하였으나, 요구사항을 구체화하고, 기능에 대해 개발하는 작업은 어렵지 않습니다. 시간만 주어진다면 다 할 수 있죠.

• 개발을 진행하는데 가장 곤란을 겪은 문제는 2개로 이야기할 수 있습니다.

  • 결제 시스템 연계

  • 서비스 법률 검토

• 결제 시스템의 경우 nicepay나 kakaopay, kg이니시스와 같은 결제서비스와 연계할 수 있습니다.

  • 다양한 결제서비스를 연계하기 위해 아임포트(현재는 포트원)나 스텝페이와 같은 개발 편의 서비스를 사용하여 개발을 더 쉽게 할 수 있습니다.

  • 이런 결제서비스와 연계시 테스트 mode를 사용하여 개발은 금방 할 수 있습니다.

  • 하지만 문제가 되는 지점은 기업의 신용을 확인해야 하는 PG사의 심사입니다.

  • 이 과정은 PG사 마다 방식이 조금씩 다르며, 경우에 따라 주주명부를 요구하거나 대표이사와 통화를 요청하는 일도 있습니다.

• 서비스를 하게 되면, 제공되는 서비스를 악용하게 되었을 때의 문제나 사용자의 정보를 수집하는 과정에서 발생하는 법적 문제가 발생할 수 있습니다.

  • 우리 나라에서는 개인정보 포털이나 개인정보보호의원회를 통해 표준 양식을 받아 진행할 수 있습니다.

  • 하지만 이 양식을 그대로 사용하는데 법률 검토를 직접할 수 있는 역량은 없기 때문에 외주로 법률 검토를 진행하였습니다.

  • 이 과정은 비용이 상당히 발생하기 때문에 개발팀의 입장에서는 승인과정이 번거롭거나 어렵습니다.

  • 추가로 미국이나 유럽을 대상으로 약관을 생성할때는 국내 법률사무소에 검토가 불가하여 미국 사무소를 통해 진행하기도 했습니다.

• 프로젝트 자체가 개발팀의 주도로 진행되는 경우에 발생하는 문제이며, 회사의 규모가 커지면 커질수록 이러한 문제는 더 생기지 않을까요?

  • 주도 부서가 강력한 권한이 있거나 TF가 꾸려지면, 그래도 낫지 않을까 생각됩니다.

인프라 구성과 비용에 관하여

• 실패기-1 에 작성된 내용처럼 DB의 안정성을 위해 replica를 구성하거나 sharding을 하고, 서비스간 메시지를 안정적으로 전달하기 위해 kafaka와 같이 cluster를 구성하고, 서비스의 사용량에 따라 유연한 구성을 위해 k8s를 사용하게 되면 어떻게 될까요?

• 아래는 저희가 런칭한 cover cloud의 대략적인 인프라 사용과 서비스 구성입니다.

• 많은 기능이 있지 않지만, 이 정도의 구성만 하더라도 최소 2~4core / 4~16G spec의 서버 20대 이상이 필요합니다.

  • 매달 IaaS 비용만 수백이 필요합니다.

• 개발을 진행하는 인원들은 다양한 기술을 사용하여 재미있게 할 수 있지만, 예산을 설정하고 사용하는 제 입장에서는 회사에 보고하기 어려운 사항 중 하나 입니다.

• 개발하는 제품의 방향에 따라 위와 같은 구성이 맞을 수 있으나, 저희와 같이 인증을 받아야 하는 경우가 아니라면 초기 구성은 가벼운 docker 정도로 구성하거나 monolithic 구성이 훨씬 낮은 비용으로 세팅할 수 있습니다.

모니터링

• 초기 모니터링은 k8s 내 istio를 설치하고 sidecar 형식을 빌려 모니터링을 시작하였습니다.

• 이러한 proxy 의 성격을 사용하여 prometheus 와 연계하여 모니터링하고, 한참 유행하던 ELK stack을 사용하여 모니터링을 구성하였습니다.

  • 하지만 elasticsearch의 경우 2021년 유료화 되었기 때문에 대체 sw로 아마존의 OpenSearch를 선택하여 진행했습니다.

• 그 외에도 google analytics, grafana와 IaaS 내에서 제공하는 모니터링을 사용하여 아래와 같은 모니터링을 진행하였습니다.

  • landing page와 service 유입량/사용량을 측정하고

  • 서버 사용량 모니터링

  • 서비스 장애 검사

• 그리고 상시로 이러한 모니터링을 보지 않기 위해 notification을 mail을 우선 연계하고, 이후 slack의 #xxx-alarm 채널을 생성하여 연동을 진행했습니다.

마케팅

• 이 프로젝트는 개발팀에서 기 제품을 사용하여 B2B를 B2B2C로 전환하고자 하는 의지를 가지고 진행되었습니다.

• 이러한 맥락 때문인지 마케팅 활동은 소소하게 아래와 같이 진행되었습니다.

  • 기존에 확보하고 있는 고객 db 활용하여 콜드 메일

  • 제품 출시 보도자료 배포

  • 기업간 네트웍을 활용한 홍보

  • 웨비나

• 마케팅 컨설팅 등

후속 작업

• 회사 내부의 자세한 사정을 이야기할 수는 없지만, 서비스를 런칭하고 실제로 이렇다 할 적극적인 제품 홍보활동이나 사업이 진행되고 있지 않습니다.

• 망할때는 확실히 망해야 한다고, 이도 저도 아닌 상태에 있지 않기 위해 이번 PMC S24에도 참여하게 되었습니다.

• 좋은 관계를 가지고 있는 교육기관과 기업들을 통해 사업 활동을 확장하는 계획도 만들고 말이죠.

• 기존에 COVER를 10년 이상 사용하고 있는 금융권에서도 최근 망개방 정책 소식이 있기 때문에 미리미리 준비해야겠다고 생각됩니다.

  • with 공공망 개방 정책도 최근 행안부/기무사/국정원 협의를 통해 진행되고 있습니다.

정리하며

• 주어진 시간에 최대한 만은 사람들에게 도움이 될 수 있을만한 내용을 작성하려고 하였습니다.

• 정부과제를 통해 진행하거나, 미국 지사를 통한 마케팅, 해외 결제 연계의 어려움에 따른 stipe 사용기 등 여러 진행과정이나 에피소드도 기회가 있으면 포스팅 해 보겠습니다.

• 개발팀에서 기술적인 욕구와 기존 사업의 확장에 대해 고민하면서 진행된 프로젝트가 실제 시장에 출시했을 때 구체적인 마케팅 기획이 없이 진행했을 때의 어려움을 나타내고 싶었는데, 필력이 부족하여 잘 드러내진 못해 아쉽습니다.

• 지금와서 생각하는 통찰은

  • 우리가 할 수 있는 일을 하는 것보다는

  • 실제 특정 환경에서 사람/기업/조직이 겪고 있는 어려움을 어떻게 우리가 기여할 수 있을까?에 대한 고민이 훨씬 중요하다는 점입니다.

다음은

• 이번 PMC S24를 진행하면서 COVER cloud service를 무료로 사용할 수 있도록 개방하였습니다.

• 이 과정에서 수행한 내용과 얻은 인사이트를 포스팅할 예정입니다. 😁