|
※ 감수인 ★★★ ‘오렌지보드 독점’ 보고서입니다 ★★★
- 주식수가 매년 늘고 있음. 꽤 늘어나는 것으로 보아 주식으로 자금조달하는 듯함. - 주가 3개월 째 조정중.
- 연구개발비가 매출 총이익의 68% 정도임. - 영업이익보다 EBITDA가 더 좋지 않음. 비용이 찐비용일 수 있다는 말임.
=> 고성장 산업이고, 주식발행하여 자금조달하고 있음. 초보 투자자가 쉬이 접근할 수 있는 영역을 아닌 듯함.
주의) 위 의견은 세부 내용을 파악하지 못한 상황에서, 재무적/정황적으로만 판단한 감수인의 대략적인 의견입니다. * 투자포인트, 프리미엄, 포트폴리오 보고서 외의 보고서는 모두 무료 공개입니다. ** 보고서 검토 우선순위 : '속보 -> 보유 -> 독점 -> 요청시기 ' 순입니다 (절대적이지 않음). *** 앱을 설치하시면, 구독하시는 크리에이터에 대한 새글 알림을 받아보실 수 있습니다. |
클라우드 분야의 대표적 플레이어 중 하나인 Confluent(CFLT)의 생태계 내 역할을 알아보고 추후 꾸준히 트래킹해보고자 함. 아직 적자인 기업이라 숫자 측면에서는 좋지 않고, IPO 시 조달한 자금으로 버티고 있어 지금과 같은 고금리 지속 시기에 투자하기에 적절한지는 의문이나 전방산업의 매력도나 회사의 해자는 분명하기에 꾸준히 트래킹할만한 가치가 있음.
1. 데이터 스트리밍과 카프카에 대한 이해
동사의 플랫폼은 Apache Kafka라는 API 기반으로 작동함. 프로덕트의 이해를 위한 배경지식을 탑다운 관점에서 간략히 기술함.
1-1. 클라우드와 클라우드 컴퓨팅
클라우드는 서버, 네트워크, 스토리지, 애플리케이션, 서비스 등의 리소스를 이용할 수 있도록 하는 가상의 환경을, 클라우드 컴퓨팅은 클라우드 상의 IT 리소스들을 바탕으로 행하는 동작 자체를 의미함.
(출처: spiceworks)
클라우드 사용 이유는 비단 하드웨어가 제공하는 단순 저장공간 측면의 확장뿐만 아니라, 우리가 사용하는 애플리케이션, 서비스 등이 점차 고도화되는 것에 존재함.
인공지능을 필두로 한 높은 연산능력을 요구하는 적용처들이 점차 성장하고 큰 비중을 차지해가고 있으며, 이는 고도화된 컴퓨팅 능력을 필요로 함. 클라우드는 사용자들이 보유한 하드웨어 이상의 능력을 제공하며, 사용자들은 클라우드를 사용하지 않을 경우 컴퓨팅에 필요한 자원들(서버, 하드웨어, 소프트웨어 등)을 직접 구축해야하는 어려움이 존재하기 때문에 클라우드 사용 비중이 점차 올라가게 되는 것임.
한편 클라우드와 같은 원격 환경이 아니라 자체적으로 보유한 서버를 바탕으로 애플리케이션을 운영하는 방식을 온프레미스(On-premise)라 칭함.
클라우드는 다음과 같이 분류됨.
1) Public: 서비스 제공업체(AWS, Google Cloud, MS Azure 등)에서 IT 인프라를 소유하는 구조로 사용자는 사용한 부분에 대한 대가만을 지불하는 가장 일반적인 구조임. 비용 절감 및 관련 인프라 유지 관리 용이성 및 안정/확장성 등의 장점을 지님.
2) Private: 단일 그룹을 위한 클라우드 환경으로 해당 그룹의 방화벽으로 타인의 접근을 막음. 온프레미스 구조를 띠고 있는 경우도 존재했으나 오프프레미스에 위치한 임대 데이터센터에 프라이빗 클라우드를 구축하는 경우도 존재함. 조직 전용으로 구축된 환경이기에 향상된 유연성 및 제어능력을 제공함.
3) Hybrid: 여러 환경이 LAN, WAN, VPN, API 등을 통해 연결된 형태. 1개 이상의 프라이빗 + 퍼블릭, 2개 이상의 프라이빗, 2개 이상의 퍼블릭 등을 포함함. 프라이빗-퍼블릭을 오가는 유연성을 통해 리소스 활용도가 증가함.
4) Multi: 2곳 이상의 클라우드 공급업체가 제공하는 2개 이상의 퍼블릭/클라우드 방식을 칭함.
클라우드 인프라를 담당하는 대표적인 3사 등을 포함한 점유율 구도는 아래와 같음. AWS가 32%로 1위(2017년 말 기준 32.2%), MS Azure가 22%로 2위(2017년 말 기준 13.7%), 구글클라우드가 11%로 3위((2017년 말 기준 7.6%)를 차지하는 빅3 구도가 여전히 유지되고 있음.
(출처: Statista)
(출처: Statista)
1-2. 클라우드 네이티브 애플리케이션
Cloud, Native. 말 그대로 기존 온프레미스 환경이 아닌 클라우드에서의 사용을 메인으로 하는, 클라우드의 장점을 극대화시키는 애플리케이션 구축 및 실행 방식을 뜻함. 기존의 온프레미스 방식과 달리 클라우드 기반의 지속적인 개발 및 자동화된 관리를 위해 ‘클라우드 맞춤형’으로 설계된 것.
핵심은 클라우드 맞춤형으로 설계되었기에 애플리케이션의 구조 및 인프라가 바뀌었다는 것이며, 간략한 내용은 아래와 같음.
클라우드 네이티브 애플리케이션 구축에 필요한 요소들은 크게 1) DevOps, 2) 컨테이너, 3) 마이크로서비스 등이 있으며, 이 중 컨테이너와 마이크로서비스는 구조적 필수 요소임.
1) DevOps: 개발(Development)과 운영(Operation)이 합쳐진 단어로, 개발-운영 사이의 협업을 확대시켜 애플리케이션의 개발, 배포 및 업데이트를 가속화시키는 것. 꾸준한 모니터링을 기반으로 개선사항을 찾고, 개발 단계를 자동화시키는 노력을 통해 이를 수행할 수 있음.
2) 컨테이너: 서버 환경을 재구축하는 부가적인 작업 없이 로컬 환경에서 애플리케이션 개발을 지원하는 방식으로 애플리케이션 실행을 위한 컴퓨팅 작업을 패키징하여 다양한 인프라로 쉽게 이동이 가능한 것이 특징임. 서버/OS에 종속받지 않아 가벼우며, OS 환경이 이식되는 패키징 내 포함되지 않는다는 것이 VM 방식과의 차이점임(Cloudmate).
(출처: redhat)
3) 마이크로서비스: 애플리케이션 아키텍쳐의 한 종류로 애플리케이션을 상호독립적인 최소 구성요소로 분할하여 탄력적으로 결합하고 분할해 사용하는 방식임. 서비스를 필요에 따라 확장할 수 있으며 개별서비스들의 변경 역시 탄력적으로 가능하나 구조가 비교적 복잡하고 데이터가 분산되어 있어 관리가 어려운 것이 단점임.
1-3. 애플리케이션 아키텍쳐
애플리케이션 아키텍쳐는 애플리케이션을 설계하고 구축하는 데에 사용하는 패턴 및 기술을 의미함. 다양한 설계 패턴들이 모여 아키텍쳐가 되는 것으로 이해하면 되며, 프론트와 백을 모두 포괄하는 개념임.
대표적인 아키텍쳐의 종류는 다음과 같음.
1) 모놀리식: 모든 요소가 동일한 리소스 및 메모리 공간을 공유하는 방식으로, 모든 요소들이 ‘긴밀하게’ 연결되어 있음. 단일 측면을 업데이트하더라도 전체 기반 인프라에 영향을 미침.
2) N-티어: 온프레미스/엔터프라이즈 애플리케이션 구축 시 사용하는 전통적인 방식으로 주로 3개 가량의 레이어로 구성됨. 레이어는 수평적으로 배열되며(아래 그림에서는 WEB-APP-DATA), 인접한 레이어끼리만 서로 호출이 가능한 구조(WEB-APP, APP-DATA). 대표적인 엔터프라이즈 애플리케이션에서의 사용 예시는 인스타그램, 페이스북, 우버, 에어비앤비 등이 존재함.
3) 마이크로서비스: 위 목차에서 언급한 것과 마찬가지로 상호독립적인 최소 구성요소(마이크로서비스)로 애플리케이션을 분할시킨 구조. 무거운 인프라 없이도 서비스를 필요에 따라 확장할 수 있으며, 클라우드 네이티브 애플리케이션의 기반이 되는 요소임. 분할된 구조로 개발 주기가 단축되며 높은 확장성 및 복구능력을 지니고 있는 것이 특징임.
(출처: Brij kishore)
1-4. 이벤트 드리븐 아키텍쳐
이벤트 드리븐 아키텍쳐는 마이크로서비스의 좀 더 뾰족한 장르로 볼 수 있음. 이벤트 탐지, 커뮤니케이션, 처리에 중점을 두고 있으며 Pub/Sub(펍섭, 게시/구독) 모델 혹은 스트림 모델을 기반으로 함.
그렇다면 메시징(데이터 송수신) 모델에는 어떤 종류가 존재할까?
1) Queues
전통적인 방식으로, 데이터 송신자와 수신자가 지정되어 있음. 속도가 빠르다는 강점이 존재하나 수신 불능 상태일 때 장애가 발생할 가능성이 비교적 높으며 확장성 역시 좋지 않음.
(출처: serverlessland)
2) Pub/Sub
Pub/Sub은 메시징 모델 중 하나로, 데이터를 송수신하는 구조의 종류 중 하나임. 메시지는 데이터 단위를 의미하며 송신자는 퍼블리셔 혹은 프로듀서, 수신자는 서브스크라이버 혹은 컨슈머라 부름.
아래 그림과 같이 중앙에 메시징 시스템 서버를 두고 통신하며, 기존 메시징 시스템과의 가장 큰 차이는 발신자의 메시지에 수신자가 별도로 정해져 있지 않다는 것임. 발신자는 구독자로 칭해지는 수신자들에게 메시지를 전달함.
(출처: serverlessland)
3) Streams
데이터(메시지)가 발생하는대로 처리하는 것을 이야기하며, 실시간 수집 및 처리를 포괄하는 연속적인 데이터의 흐름임. 특정 이벤트를 하나로 보는 것이 아니라 끊기지 않는 하나의 긴 이벤트로서 이를 인식하는 것으로 보면 됨.
이벤트들은 로그에 기록되며 이벤트 소비자(수신자)는 이를 구독하는 것이 아닌 원할 때 원하는 부분에서 읽기를 시작할 수 있음. 클라우드에 자료를 올리고, 접근 권한이 있는 수신자가 자유롭게 접근하여 자료를 받을 수 있는 것과 유사한 구조이며 가장 현대적인 어플리케이션에서 사용함.
(출처: serverlessland)
산업 전반에 걸쳐 실시간 데이터에 대한 수요가 증가하고 있는 추세이며, 대표적인 사용 예시는 다음과 같음. 보고, 분석(대량 데이터 일괄 처리), 모델 학습(머신러닝 인프라의 일부) 등 일괄 처리 방식이 더 유용한 사례는 여전히 존재하나 실시간 데이터에 대한 수요가 꾸준히 증가하고 있다는 것은 자명한 사실임.
- 운송: 실시간 위치 파악, 운전자-승객 매칭, 현지 교통정보 기반의 도착 예정시간 업데이트 등
- 금융: 사기 탐지, 거래 등
- 유통: 실시간 재고 관리 및 개인화
- 콘텐츠: 실시간 추천, 뉴스 피드 개인화, 인앱 결제 등
1-5. 데이터 스트리밍과 API
데이터 스트리밍은 위에서 언급한대로 이벤트 드리븐 아키텍쳐 소프트웨어 모델의 기반이 됨. 현대적인 애플리케이션은 이를 사용해 데이터를 처리/저장/분석하며 금융 거래, IoT, 물류 등 다양한 적용범위를 지님.
데이터 스트리밍이 지니는 주요한 특징은 ‘실시간’인데, 기존의 요청 기반 시스템의 경우 다양한 소스의 빠른 데이터 요청에 신속하게 대응하는 것이 어려웠음. 하지만 이벤트들을 데이터베이스에 저장하는 것이 아니라 로그에 기록하는 본 방식을 취하면서 빠르게 대응할 수 있게 되었음.
(출처: kai-waehner)
그렇다면 Apache Kafka는 무엇일까? 카프카는 데이터 스트리밍 분야의 사실상 표준임. 메시징, 데이터 통합, 처리 등의 기능을 제공하며 10만 개 이상의 조직에서 사용하는 오픈소스임. 카프카를 기반으로 하는 이벤트 기반 아키텍처와 이동 중인 데이터의 등장으로 기업들은 실시간 인프라와 애플리케이션을 구축할 수 있게 되었음.
실시간 데이터 처리는 단순히 ‘실시간 송수신(메시징)’에 국한되지 않음. 통합 및 처리 기능을 추가로 요구하는데, 데이터를 일정 수준의 양까지 모아놓고 일괄 처리하는 방식은 실시간이라고 보기 어려울 것임. 여기서 API라는 개념이 등장함.
API(Application Programming Interface)는 소프트웨어 간, 혹은 소프트웨어-하드웨어 간 통신에 사용되는 언어 혹은 메시지 형식을 이야기함. 요청의 종류, 호출의 방법, 데이터의 형식 및 규칙 등이 정의되어 있는 인터페이스이며 업계에서는 원활한 소통을 위한 표준 API를 지정하여 사용함. SQL, HTTP, J2EE 등의 일반적인 API에서부터 OPC-UA(산업용 IoT), PMML(머신러닝) 등 특정 산업에 대한 표준도 존재함.
위와 같은 표준 API에 더해, 특정 분야의 API를 단일 공급업체 혹은 성공적인 단일 오픈소스 프로젝트가 주도하면서 사실상 표준으로 굳어지게 된 API들 역시 존재함. 대표적으로는 오브젝트 스토리지 분야(계층이 없는 데이터 저장 방식)의 Amazon S3, 이벤트 스트리밍 분야의 Apache Kafka.
(출처: kai-waehner)
1-6. Apache Kafka와 Confluent
위에서 언급한 사실상의 표준 API Apache Kafka는 여러가지 방식으로 공급됨. 아래는 kai-waehner 사이트의 설명을 준용하여 번역 및 일부 내용 추가해 각색한 것임.
카프카는 크게 세가지의 공급방식이 존재하며 필자는 이를 자동차에 비유하였음.
(출처: kai-waehner)
1-1) 카프카 오픈소스는 자동차를 만들 때 들어가는 필수 요소인 엔진이라고 할 수 있음. 그 엔진을 이용해 우리는 차를 설계하고, 그 차를 이용해 사용자들은 데이터를 스트리밍할 수 있게 되는 것임. 오픈소스(엔진)를 이용하여 직접 서비스를 구축 및 관리할 수도 있으나 제한적인 기능 및 관리(운영, 모니터링, 스토리지 관리, 보안 등) 측면의 부담이 존재함.
1-2) 한편 Confluent, Red Hat, Cloudera 등은 각각 Confluent Platform, Red Hat AMQ, Cloudera DataFlow라는 이름으로 운영, 모니터링, 보안 등의 추가도구를 제공하는데, 관리는 자체적으로 수행하면서 일부 추가기능을 제공받는 ‘튜닝된 엔진’의 형태도 존재함.
2) 위에서 언급한 관리 측면의 부담 절감 및 기능 확장을 위해 엔진이 아닌 완성차를 구매하는 경우도 있음. 모든 측면을 자체관리할 경우 많은 비용을 수반하게 되는데, 완성차와 비슷한 본 서비스를 사용함으로써 해당 비용을 절감하는 효과 역시 제공받을 수 있음. 그리고 이와 같은 자동차를 제공하는 다양한 업체들이 존재하는데, 그 중 하나가 이번에 소개하는 기업인 컨플루언트이며 컨플루언트 외 아마존 MSK, Red Hat, Cloudera가 비슷한 공급자 역할을 수행하고 있음.
공급자들은 보다 탄력적이고 확장가능한 인프라를 제공하며, Confluent Platform, Cloudera DataFlow, Red Hat AMQ, Amazon MSK 등의 명칭으로 서비스를 공급함. 앞선 세개의 경우 온프레미스 및 다양한 클라우드 플랫폼에 적용 가능하나 Amazon MSK의 경우 AWS에만 적용 가능하다는 차이가 있음.
완성차를 제공받는다고 하여 주유, 운전, 정비까지 자동으로 수행되는 것이 아닌 것처럼, 사용자들은 여전히 많은 작업을 직접 수행해야 함에 주의해야 함. ‘부분관리’라고 보는 것이 맞을 것임.
3) 마지막으로 자율주행차임. 이는 SaaS 방식으로 제공되는 완전 관리형 제품을 이야기하며, 대표적인 예시로는 Confluent Cloud가 있음. 완전 관리형은 사용자의 관리가 전혀 필요 없고 서버 역시 요구되지 않으며 사용량에 비례한(대체로) 비용을 낼 뿐임.
Confluent Cloud는 유일한 완전 관리형 제품이며, 완전 관리형 제품을 표방하는 경우가 많으나 이는 사실 부분 관리형에 해당함(Amazon MSK Serveless 제품의 경우 추가 리서치가 좀 더 필요함). 특히 Confluent Cloud의 경우엔 다양한 클라우드 제공업체 제품과 연계해 사용 가능하다는 것이 특징임.
(출처: kai-waehner)
2. 기업 개요
2-1. 비즈니스 모델
동사의 사업부문은 1) Confluent Platform- License, 2) Confluent Platform- PCS, 3) Confluent Cloud, 4) Services의 네가지로 분류됨.
1) Confluent Platform- License: 위 언급과 같이 Apache Kafka 기반의 자체관리, 부분관리형 데이터 스트리밍 SaaS 제품임. 고객들은 온프레미스, 퍼블릭 클라우드, 프라이빗 클라우드 등에 동사의 소프트웨어를 적용할 수 있음. 매년 선불로 구독료가 청구되는 구조임(1년 단위). 이 중 라이선스에 할당되는 부문이 본 매출로 잡히며 구독기간에 따라 인식하는 PCS와 별개의 흐름을 보이는 것을 감안하면 초기 신규 계약 체결 시 인식되는 수수료인 것으로 추정됨.
2) Confluent Platform- PCS: 계약 후 고객에 대한 지원, 유지보수, 업그레이드 등으로부터 발생하는 수익이며 계약기간에 비례하여 매출을 인식함.
3) Confluent Cloud: 완전관리형 소프트웨어로 동사의 매출 내 비중이 커지고 있는 분야임. 고객들은 필요한 곳에 한해 Cloud를 부분적으로 적용하곤 하며, 일반적으로 가장 복잡하고 중요한 부분에 Cloud를 적용시키는 경향이 있음. Platform 부문과 혼용하여 사용하는 경우가 많음. 월단위 혹은 연단위 종량제(쓴 만큼 지불)를 기반으로 함.
4) Services: 교육 등에 대한 서비스 명목으로 수취하는 수수료.
(출처: CFLT 제공자료 재가공)
한편 고성장하고 있는 클라우드 부문의 과금체계는 다음과 같으며(23.10), 규모에 따라 변화하는 구조를 띠고 있음.
(출처: CFLT)
한가지 아쉬운 점은, 22년 말 동사에 대해 처음 조사했을 때보다 과금이 약해졌다는 점임. 물론 동사의 프로덕트는 매우 높은 락인효과를 지니고 있기에 많은 배포가 우선시되어야 하며, 이에 따라 동사는 초기 $400 가량의 크레딧을 통한 무료 → 유료 업셀링 전략을 펼치고 있는 것도 맞지만 22년 말 대비 단가가 떨어졌다는 점에 대해서는 추가적인 리서치가 필요할 것임. 물론 가파르게 증가하고 있는 Cloud 매출 부문은 어찌됐든 이 단가 인하 전략이 성공적이었다는 것을 반증하긴 하지만.
(출처: CFLT)
2-2. 실적과 지표
실적은 우상향하는 모습을 보이나 증가율은 떨어지고 있음. 이익단의 경우 꾸준히 개선세를 보이다 23.1Q 주춤하는 모습을 보였는데, 이는 23.01 인수한 Immerok GmbH($54.9m)와 관련한 비용 증가에 기인함. 회사는 인력 및 기술을 위해 대상회사를 인수하였는데, 해당 인건비 및 R&D 비용이 계상되며 운영비용이 증가함. 현재는 매출 상승분으로 이를 메꿔 정상적인 영업비용 절감 궤도에 다시 복귀하였음.
(출처: CFLT 제공자료 재가공)
지역별 매출은 다음과 같음. 미국의 비중이 점점 줄어들고 있긴 하지만 여전히 높은 수준이며, 최근엔 미국 및 미국 외 지역의 성장률이 비슷한 모습을 보이며 매출 비중이 유지되는 모습을 보임.
(출처: CFLT 제공자료 재가공)
부문별 매출 비중임(위 목차에서 언급한 표와 같음). 초기 컨플루언트는 Confleunt Platform 부문을 통해 성장하였으나(물론 여전히 성장 중이지만) 성장폭은 줄어들고 있는 추세이며, 그 성장을 Confluent Cloud 부문이 대체하고 있음.
(출처: CFLT 제공자료 재가공)
부문별 성장률 및 마진은 다음과 같음. Cloud 부문의 성장은 2021년 도입 초기 높은 성장률 대비 하락하여 상대적으로 낮아보이나 절대적으로 yoy 70% 이상의 여전히 높은 수준의 성장률을 보이고 있으며 Platform 부문 역시 20% 가량의 높은 성장률을 기록함. 물론 성장률의 추세가 꺾였다는 것에는 주의해야 함. 부문별 GPM은 Platform과 Cloud 부문을 합쳐 공시하고 있는데, Cloud의 비중이 지속 상승함에 따라 GPM 역시 개선되는 모습을 보이고 있음.
(출처: CFLT 제공자료 재가공)
2-3. 강력한 락인효과
이는 23.1Q 컨콜에서 동사 프로덕트의 지속성에 대해 언급한 내용을 수정 및 추가한 것임.
1) Confluent, 특히 Cloud는 일반적으로 맞춤형 제공 방식을 취하고 있음. 고객은 당사 소프트웨어 적용을 위해 추가적인 ‘초기 비용’을 들여야 하는데, 따라서 적용되는 프로젝트는 일반적으로 고부가가치 및 고객이 집중하고 있는 분야인 경우가 대부분임. 고객이 집중하고 있는 만큼 해당 프로덕트 자체도 오래 지속될 가능성이 높으며, 해당 시스템 지속에 따른 동사 플랫폼 역시 지속될 가능성이 높음.
아래는 동사가 컨콜에서 공개하고 있는 Net Retention Rate(기존 고객의 이전기간 대비 현재기간 매출 확장률)인데, 동사는 분기마다 130%를 기준으로 이를 비트했는지 여부를 공개함. 2022년 4분기 130%를 소폭 하회(just under)하였으나 2023년 다시 이를 상회하였음.
(출처: CFLT 컨콜 참고)
2) Confluent 플랫폼은 하나의 앱을 위한 것이 아닌, 데이터 스트리밍을 통해 다른 애플리케이션 및 팀이 해당 데이터 스트림을 사용할 수 있도록 하는 기술이라는 점임. 이러한 스트리밍의 경우 사용량이 많아질수록 대체가 힘들어지며, 대체할 경우 연관되어 있는 모든 요소를 바꿔야 하는 높은 전환비용을 지니고 있음.
3) 고객에게 사실상의 비용 절감 효과를 제공함. 일반적으로 오픈소스를 사용하는 고객들은 a) Kafka 실행을 위한 클라우드 인프라향 비용(컴퓨팅, 스토리지, 네트워킹 및 추가 도구)과 b) Kafka의 구성/배포/관리를 담당하는 소프트웨어 엔지니어 및 운영 인력에 비용을 지출하게 됨. 여기서 중요한 것은 해당 비용들은 프로젝트 및 애플리케이션의 규모가 커지면 커질수록 매우 큰 증가폭을 보인다는 점임. Confluent는 이러한 측면에서 대규모 프로젝트일수록 비용적 측면에서의 강점이 더 부각되는 구조를 띠고 있으며, 이는 큰 고객들이 유지되는 원동력이 됨. 덧붙이자면 Kafka 관련 인력들은 글로벌 5번째로 높은 임금을 받는 기술로 꼽힌 바 있으며, 이는 관련 인력을 고용해 자체 시스템을 구축하는 것보다 동사 프로덕트의 매력도를 더 높여주는 요소임.
실제로 연간 $1m 이상의 큰 비용을 지출하는 고객 수는 꾸준히 증가하고 있으며, 고객 내 비중 역시 증가 중임. 현재는 3% 가량에 불과하지만 실제 매출 내 차지하는 비중은 최소 25% 수준임(모든 $1m 이상 고객의 매출을 $1m으로 가정하여도 25% 수준).
(출처: CFLT 제공자료 재가공)
3. 리스크
3-1. Apache Pulsar, 카프카에 대응하는 플랫폼?
Monthly Active Contributors는 오픈소스에 기여한 사용자들의 수치를 월별로 취합한 것인데, 카프카와 비슷한 역할을 수행하는 오픈소스 Apache Pulsar의 성장세 역시 뛰어남.
하지만 Pulsar를 주류로 생각하는 사용자들은 거의 없음. Kafka의 대표적인 고객 중국 Tencent는 단 하나의 프로젝트만 Pulsar를 채택하였으며 나머진 전부 Kafka를 선택함. 엔터프라이즈용에서는 Kafka가 압도적 대세이며, 커뮤니티 주도로 이뤄지는 소규모 프로젝트의 경우에 국한해 Pulsar가 부분적으로 사용되는 구조를 보임.
이는 기존 구현되어 있는 인프라뿐 아니라 Kafka의 우수한 성능에 기인함. 아래 왼쪽 그림에서는 Kafka가 Pulsar, RabbitMQ 대비 훨씬 높은 처리량을 보인다는 것을 확인할 수 있으며, 오른쪽 그림을 통해서는 더 높은 처리량에서 가장 낮은 지연시간을 제공함. 모든 처리량 수준에서 Pulsar를 압도하며, RabbitMQ의 경우 30k/s 수준의 처리량에선 높은 성능을 제공하나 처리량이 조금만 올라가도 수치가 크게 저하되는 특성을 지니고 있음. 아래 비교는 CFLT에서 수행한 것이라 어느정도의 숨겨진 편향이 존재할 수도 있으나, Tencent 등 거대고객의 사용 트렌드가 Kafka 쪽으로 기울어있다는 점은 이를 어느정도 증명하는 요소임.
(출처: CFLT)
3-2. 클라우드 수요 둔화
미국의 경우 클라우드 침투율이 이미 50% 가까이(기관마다 수치가 다르긴 함), 일본이 30%, 우리나라가 약 10% 수준으로 알려져 있으며, 클라우드의 신규 배포가 늦어질 경우 컨플루언트의 사용 증가폭 역시 줄어드는 것이 아닐까를 의심할 수도 있음.
하지만 엄밀히 말하면 컨플루언트의 프로덕트는 클라우드의 확산 자체도 중요하지만, 이미 확산되어 있는 고객들의 데이터 사용량 증가가 더욱 중요함. 이는 위 '강력한 락인효과' 부문에서 설명했듯 컨플루언트의 제품을 채택하는 프로젝트가 해당 단체의 주요 어플리케이션이 되는 경우가 많은 것에 기인함. 다시 말해 스타트업 규모의, 소위 이제 막 시작하는 프로젝트에 적용하기보다는 성공할 확률이 높은 제품에 적용되는 경우가 많다는 것인데, 데이터 사용량의 절대적인 증가폭은 당연히 후자가 월등함.
따라서 컨플루언트의 매출은 절대적인 데이터 사용량에 비례하기에 절대적인 신규 고객의 수보다는 일정 규모 이상 고객의 데이터 사용량이 증가하는 것에 좀 더 큰 영향을 받을 것으로 판단되며, 이에 대규모 기업들을 이미 고객으로 확보하고 있는 동사의 해자는 향후 더욱 견고해질 것임.
Disclaimer
- 저자는 보고서 제공 시점 기준 보유하고 있지 않습니다.
- 본 보고서는 오렌지 보드에 독점 기고합니다.
- 당사의 모든 콘텐츠는 저작권법의 보호를 받은바, 무단 전재, 복사, 배포 등을 금합니다.
- 콘텐츠에 수록된 내용은 개인적인 견해로서, 당사 및 크리에이터는 그 정확성이나 완전성을 보장할 수 없습니다. 따라서 어떠한 경우에도 본 콘텐츠는 고객의 투자 결과에 대한 법적 책임소재에 대한 증빙 자료로 사용될 수 없습니다.
- 모든 콘텐츠는 외부의 부당한 압력이나 간섭없이 크리에이터의 의견이 반영되었음을 밝힙니다.
Disclaimer
- 당사의 모든 콘텐츠는 저작권법의 보호를 받은바, 무단 전재, 복사, 배포 등을 금합니다.
- 콘텐츠에 수록된 내용은 개인적인 견해로서, 당사 및 크리에이터는 그 정확성이나 완전성을 보장할 수 없습니다. 따라서 어떠한 경우에도 본 콘텐츠는 고객의 투자 결과에 대한 법적 책임소재에 대한 증빙 자료로 사용될 수 없습니다.
- 모든 콘텐츠는 외부의 부당한 압력이나 간섭없이 크리에이터의 의견이 반영되었음을 밝힙니다.
