먼저 이 글은 제 개인의 생각일 뿐 제가 속한 조직이나 제가 관리자로 있는 커뮤니티의 입장을 대변하진 않습니다. 이 내용들이 어떤 논쟁의 근거로 쓰이는 일은 없기를 바랍니다.
어제 페이스북에 친구 공개로 끄적여 본 내용입니다.
기왕 이야기 꺼낸거 생각을 한번 정리 하고자 오랬만에 블로그에 글을 씁니다.
작년에 한번 Elastic 라이센스, 그리고 오픈 소스 에반젤리스트의 딜레마 라는 제목으로 비슷한 주제의 글을 쓴 적이 있었습니다. 그 때도 Elastic의 가장 큰 경쟁 제품은 A사도, S사도, D사도 아닌 Elastic 오픈 소스 입니다. 라는 이야기를 했었는데, 이제 Elastic 제품들의 라이센스가 Apache 에서 SSPL 로 변경이 되어 더 이상 오픈소스 라고 부르면 안되긴 하지만 다른 오픈소스 기업들이 다 같이 겪고 있는 고민이라고 생각 되어서 글 제목에는 오픈소스라는 단어를 달았습니다.
한동안 커뮤니티에서 여러번 설명을 드렸지만, Elasticsearch 와 Kibana 를 더 이상 오픈소스 라고 부르지 못하는 이유는 Open Sorce 라는 단어에 대한 사용권(?)은 Open Source Initiative 에서 승인한 라이센스들 에서만 가능하기 때문입니다. Elastic 이 이번에 변경한 SSPL 역시 다른 오픈소스들과 마찬가지로
- 무료로 사용이 가능하고
- 소스 코드가 공개되어 있고
- 사용자는 제품에 코드 기여가 가능
하지만, OSI 에서 승인하고 있는 종류의 라이센스가 아니라서 오픈소스라고 부르면 안됩니다. 기존 오픈소스와 뚜렷하게 다른 점은
- 13항 - 클라우드에서 제품 서비스로 제공하는 경우 기능에 대한 소스를 공개해야 한다
는 점 입니다. SSPL 은 MongoDB 에서 처음 발표 한 라이센스 인데, 과거 오픈소스 라이센스들이 제정 되던 시기에는 소프트웨어는 다운로드 받아 설치하는 것 이었지만, 지금은 소프트웨어를 클라우드에서 구매해서 사용하는 것으로 환경이 바뀌었기 때문에 과거에 제정된 라이센스에는 맞지 않는 조항들을 개선한 것이라고 볼 수 있습니다. AGPL 과 SSPL 비교
서론이 길었네요. 이제 Elastic이 한국에서 했던 비즈니스 활동에 대해서 이야기를 좀 해 보겠습니다. 제가 속한 Elastic 의 이야기지만 많은 오픈소스 회사들도 비슷하리라 생각합니다.
Elastic 의 비즈니스 패턴
지금까지 국내에서 제가 보아 온 Elstic 의 비즈니스 활동은 몇가지 패턴이 있었습니다.
SI 신규 프로젝트
우리 나라는 아직도 SI(Service Integration) 라고 하는 프로젝트 발주 형식의 비즈니스가 많습니다. 그리고 이 SI 라고 하는 큰 과정 안에서 개발자 인건비, 장비 구매비, SW 구매비 등과 같은 비용들이 산정이 됩니다.
Elastic 의 주 비즈니스는 년간 구독 방식의 기술지원 서비스 입니다. 당연히 일반적으로 SI 에서 이런 비용을 산정하는 경우는 잘 없습니다. 있다고 해도 보통 1~2주의 컨설팅이나 교육 구매 정도입니다. 따라서 Elastic은 SI 프로젝트에 참여가 가능한 파트너사에게 상용 기능과 기술지원 서비스를 제공하는 방식으로 비즈니스를 모색합니다. Elastic 유료 라이센스와 기술지원 비용이 결코 저렴하지 않기 때문에 가격 면에서 경쟁 하기가 사실 쉽지는 않습니다.
이 때 Elastic과의 협업 없이 오픈된 무료 기능만 가지고 기능을 개발 해 주겠다는 경쟁자가 나타납니다. 당연히 가격은 공식 파트너사의 제품 보다 훨씬 저렴하겠고요.
Elastic 은 (제 생각에)다른 오픈소스 DB 보다는 비교적 쉬운 편이지만, 그래도 잘 설치하고 제대로 활용하기 위해서는 만만치 않은 기술과 노하우가 필요합니다. 프로젝트 진행 과정에서 Elastic 의 공식 파트너라면 이런 문제들이 나타날 때 마다 Elastic 기술지원 서비스를 받을 수 있지만, 나중에 나타난 경쟁업체에는 Elastic을 아무리 잘 하는 엔지니어가 있어도 모든 문제에 대처가 어려울 수 있습니다. 설치 중 오류 문제, 성능 문제 등등 프로젝트에 난항을 겪다 보면 결국에는 고객의 입에서
- 오픈소스는 너무 어려워. 이래서 쓰면 안돼.
라는 말이 나와 버리게 됩니다. 😩
시스템 고도화
Oracle 같은 RDB 나 Hadoop 같은 시스템을 유지하다가 새로운 기능의 요구조건을 충족시키기 위한 솔루션으로 Elastic 을 선택해서 진행하는 경우입니다. 위의 SI 신규 프로젝트와 마찬가지로 파트너와 진행하는 경우도 많고, 똑같은 문제도 종종 발생하지만, 이 경우에는 희망을 주는 경우가 있습니다.
Elastic 을 경험했고 좋아하는 엔지니어(보통 이런 분들을 챔피언 이라고 합니다)가 있는 경우입니다.
이 경우 보통 초반 미팅은 Elastic 에서 어렵게 설명하지 않아도 고객사의 챔피언이 직접 경험한 Elastic 의 장점을 이야기하고 설득 해 주는 경우도 많습니다. 이렇게 처음 이야기는 매끄럽게 잘 진행됩니다.
이렇게 프로젝트 수주 - 진행 - 납품까지 잘 이어지는 아름다운 그림이 나오면 좋겠는데 다음과 같은 경우가 생깁니다.
고객사에서 비용적인 이슈가 발생해서 프로젝트 비용을 줄여야 하는 경우가 생깁니다. 유료 솔루션이나 장비의 구매 가격을 갑자기 내리는 것은 불가능합니다. 이 때 만만하게 비용을 줄일 수 있는 것이 없을까 하다가 눈이 가는 것이 Elastic 의 무료(오픈소스) 버전입니다.
“죄송하지만 저희 기술지원 안 받고 무료 버전 가지고 저희가 한번 해 보겠습니다”
라는 답변이 저희에게 돌아옵니다.구매 결정권자 또는 상부 라인에서 갑자기 챔피언을 호출합니다.
“이거 오픈소스라던데 왜 돈주고 사는거에요? 이러다 비용 감사 들어오면 뭐라고 할거에요? 블라 블라…”
그리고 자기 혼났다고 챔피언에게서 연락이 옵니다. 🥺
역시 Elastic 의 비즈니스 경쟁 상대는 Elastic 무료버전 입니다.
무료(오픈) 기능을 사용하다가 유료로 전환
가장 아름답고 이상적인 그림의 비즈니스입니다. Elastic 을 오랬동안 잘 써 왔고, 커뮤니티에도 열심히 참여하였으며, Elastic 의 다양한 기능과 철학들을 잘 이해하고 있는 고객이 새로운 시스템 또는 서비스로 도약하기 위해 연락을 하는 경우입니다.
“처음에는 검색 때문에, 로깅 때문에 Elastic을 쓰기 시작했는데 사용하다 보니 이런 저런 유용한 기능들이 많았어요. 그 동안에는 필요해서 서로 다른 솔루션들을 쓰고 있었는데 Elastic 으로 기능들을 통합하면 앞으로 좀 더 다양한 분석도 가능해지고, 새로운 비즈니스 전략도 발굴할 수 있을것 같아요. 이 과정에서 Elastic 의 도움을 받고 싶습니다.”
정말 감동적입니다.
사실 Elastic 을 처음 써 보는 고객의 경우에는 기초적인 질문 부터 시작해서, Elastic 에서 다 알아서 해줬으면 하는 생각으로 접근하는 경우가 많아 컨설팅이나 기술지원 팀에서도 응대 하는 것이 쉽지 않는 경우가 많습니다. 하지만 이렇게 이미 경험이 있는 고객의 경우에는 기술지원팀 에게 질문을 할 때도 어떤 부분이 문제인지를 대부분 잘 알고 질문을 하기 때문에 기술지원팀 입장에서도 협업하기가 매우 수월합니다.
Elastic 의 비즈니스 철학
지금은 수많은 오픈소스 제품들이 있지만 오픈소스로 비즈니스를 잘 성공시킨 기업은 많지 않습니다. 얼핏 제 머릿속에도 RedHat과 Elastic 정도 밖에 떠오르지가 않네요. Elastic 은 코드가 오픈된 제품이고 무료 기능과 유료 상용 기능이 있지만, Elastic 비즈니스의 핵심은 기술지원입니다. 그리고 제가 자주 하는 이야기이지만, Elastic의 기술지원의 철학은 단순히 고객의 질문에 답변만 하는 것이 아니라, 고객과 함께 문제 해결의 과정을 동행하는 것에 있습니다.
Elastic 이 오픈소스 비즈니스로 성장하는 여정에서 언급을 하지 않을 수 없는 고객이 골드만삭스 입니다. 공식 릴리즈도 아닌 초기 0.9x 버전, 유료 기능은 전혀 없던 시절 부터 회사의 모든 시스템을 Elastic 으로 통합하고 Elastic 과 기술 지원 협약을 맺었습니다. 현재 골드만삭스의 증권 거래, 분석 시스템은 물론 채용시스템의 이력서 검색 기능이라던가 내부 회계 결재 같이 모든 기능 구석구석에서 Elastic 이 쓰이고 있습니다. 골드만 삭스에는 현재도 수백명의 Elastic 전문 엔지니어들이 수천개의 노드의 클러스터를 운영하고 있습니다.
골드만 삭스 엔지니어의 운영 노하우는 다시 Elastic 엔지니어링 팀에게 피드백 되어 Elastic 의 공식 기능으로 개발 된 경우도 많이 있습니다. 대표적으로 현재 대용량 클러스터에서 자주 사용되는 Hot-Warm-Cold 아키텍쳐 입니다. 수천개의 노드를 운영하던 골드만 삭스 엔지니어가 제안하여 Elastic 엔지니어들이 이런 구조의 클러스터 아키텍트를 구성할 수 있는 config 옵션을 추가하고, 릴리즈 하여 Elastic의 모든 사용자들이 사용할 수 있게 되었습니다.
이처럼 골드만 삭스 라는 좋은 선례를 경험했기 때문에 Elastic 창시자들은 Elastic 이 모든 고객들과 골드만 삭스 같은 관계가 되기를 희망합니다.
기술지원 엔지니어를 모십니다
Elastic 에는 현재 대한민국에 5분 - 해외에 계신 한국어가 가능하신 분 까지 합하면 7분의 기술지원 엔지니어가 있습니다. 한국의 비즈니스 규모를 생각하면 굉장히 많은데, 한국 고객만 다루지 않고 해외 고객들의 문의도 두루두루 담당하고 계시기 때문에 그렇습니다. Elastic 기술지원 엔지니어는 국가가 아니라 리전(아시아) 단위로 채용하는데 한국 엔지니어분들이 뛰어나신 분들이 많아 많이 계신거라고 봅니다.
그리고 한국에서 기술지원 엔지니어는 계속 채용중입니다. 한국의 기술지원 엔지니어인 조인석님 께서 쓰신 글로벌 오픈소스 기술 지원 여정에 동참하시겠습니까?도 한번 읽어보세요.
Elastic 과 함께 해 주셔서 늘 감사드립니다. 앞으로도 계속 잘 부탁드립니다. 😘
