박재현님의 아티클

[실패기-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를 무료로 사용할 수 있도록 개방하였습니다.

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

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

먼저?

• 폐쇄망에서 사용되는 많은 솔루션은 고객사에 고비용에 납품되는 경향이 있습니다.

  • 기술지원 포함

  • 경우에 따라 상주 인력 지원

  • 커스터마이즈

  • 관례 ...

• 폐쇄망에서는 많이 사용되는데, 공개망에서는 잘 사용되지 않는 경우가 많습니다.

  • 비용

  • 보안

  • 대안 (open source or freeware) ...

• 제가 재직 중인 슈어소프트에서는 주로 Mission Critical Domain에서 사용할 수 있는 테스트 자동화 제품을 만들고 있습니다.

  • Mission Critical Domain 은 자동차나 항공, 원자력 등 생산한 물품에 문제가 발생할 경우 치명적 손실(인명, 재산 등)이 발생하는 도메인을 지칭합니다.

  • 그리고 이 도메인의 특성 상 주로 폐쇄망에서 개발이 이루어 집니다.

본론으로 들어가서

• 저희가 개발하는 제품은 주로 위에서 언급한 한번에 큰 비용을 지불할 수 있는 폐쇄망의 Mission Critical Domain의 고객을 대상으로 판매되고 있습니다.

• 하지만 2010년 중반부터 Extreme Programming, TDD, DevOps 등 개발 문화의 변화와 사람이 손수 테스트하는 것에서 탈피하여 테스트 자동화를 하려는 움직임이 강하게 일어 났습니다.

• 이러한 움직임 속에서 Software Clean Code Platform으로 사용되는 SonarQube 같은 경우 연 매출이 2000억을 넘는 결과를 냈습니다.

• 이러한 제품은 설치 과정이나 설정 과정이 복잡한 경우가 많아, 개발자들은 간단하게 셀프 구축하고, 기업에서는 파트너사를 통해 요구사항에 맞춰 구성하는 경우가 많습니다.

• 이런 과정을 간소화하기 위해 cloud service를 고려하게 됩니다.

그래서 뭘 전환하는가?

• 저희가 개발하는 제품은 앱을 구성하는 코드 레벨의 검사와 장치간 인터페이스 검사, 신호 교란을 일으켜 제품의 강건성을 확인하는 검사 등 다양한 제품이 있습니다.

• 하지만... 어디 회사 일이 하고 싶다고 돌아가는 것은 아니기 때문에 기존에 만든 제품 중에 전환이 가능한 제품을 선정했습니다.

• 그리고 회사에서 이루어 지는 작업인 만큼 리스크 최소화를 위해 정부과제와 연계하였습니다.

  • 과제명 : "NIPA 핵심산업 클라우드 플래그십 프로젝트"

• 선정된 제품은 "COVER" 이고, 사용자들이 평소와 동일한 개발과 테스트를 수행할 때 테스트의 정도를 정량적 수치(테스트 커버리지)를 측정하고, 테스트가 부족한 지점을 알려줍니다.

  • 주로 은행이나 보험사, 무기체계, 자동차 개발에 사용되고 있습니다.

갑자기 개발로 넘어가면?

• 테스트 커버리지 측정 제품인 COVER는 Enterprise 개발환경을 위한 SERVER형 제품과 Embedded 개발환경을 위한 Standalone 제품이 있습니다.

• 내부 논의 과정과 정부 과제를 진행해야 하는 점이 있어 Monolithic 구조의 COVER SERVER 제품을 SaaS(공개망형 제품)로 전환하기로 결정하였습니다.

• 기존 Monolithic 구조에서 SaaS 구조로 변경한 중간 구조도 입니다.

  

  • 개발시 ISO/IEC 17789 에 기반하는 클라우드 서비스 개발이 목표로 되어 있어, 기존에 개발한 구조를 대부분 버리고 새로 개발하게 되는 일이 벌어집니다. (개발 리소스 증가 이슈)

• 평소에 개발하는 과정은 전통적인 패키지 소프트웨어 개발에 근간을 두고 있었고, 제품을 개발하고 1개월 이상 테스트하는 시간을 거치고 고객에게 배포하였습니다.

• 하지만 공개망에 배포하는 경우 훨씬 더 짧은 주기의 배포와 시험이 필요하고, 배포 버전 관리와 롤백이 필요하여 k8s와 helm의 도움을 얻어 개발이 진행되었습니다.

• to be continue ...

시간 상 1편을 마칩니다.

• 다음편에서 제품을 개발하는 과정과 대외 홍보 방식, 그리고 모니터링과 후속 작업에서 겪은 실패기를 작성합니다.

• 그리고 정부과제를 통해 제품 런칭을 진행하는 것에 대한 회고(KPT)도 같이 공유합니다.