HashiCorp and Platform Engineering

· 799 단어 · 4분 소요

HashiCorp($HCP)의 IBM 피인수가 이번 주 마무리 되고, 주당 $35로 청산됨.

  1. 지난 십여년간 개발 생산성의 가장 유의미한 변화 중 하나는 클라우드였음.

  2. 지난 분기 기준, 클라우드 Big 3는 연간 $234.4B 매출을 냄 (run-rate 기준이고, 순수 클라우드 인프라 비용은 아니긴 함).

  3. 아마존이 AWS 매출을 신고한 게 고작 10년 전이고, 2014년 Q1에 $1B를 간신히 찍었을 정도이니 지난 10년간의 성장은 놀라움.

  4. 기존에 직접 서버를 운영하던 회사들은 본인들 프로그램이 돌아가는 기계를 직접 볼 수도 있었지만, 클라우드는 이들을 “가상화” 시켜주며, 물리적 제약에서 해방시켜 줌.

  5. 기계를 소유해서 사용할 때는, 각각의 기계가 애완동물 (pet) 같았음. 하나하나 이름도 알고, 문제가 생기면 직접 뜯어볼 수도 있을 지경.

  6. 클라우드에서 기계는 사육 동물(cattle)에 가까움. 각각 고유 번호들은 있지만, 하나에 문제가 생기면 다른 기기로 교체됨. 여기서 <Pets vs Cattle>은 업계에서 흔히 쓰이는 비유임.

  7. 항상 같은 수의 서버를 운영할 필요도 없음. 시간당 대여비를 내는 방식이라, 트래픽이 적을 때는 서버 수를 줄여서 비용을 아끼는 것도 가능해짐.

  8. 이렇게 서버가 ephemeral + elastic 해지면, 소프트웨어 운용을 완전히 다른 방식으로 생산성을 높일 가능성이 생김.

  9. 기존의 방식의 생산성이 개선된 것이 아니라, 패러다임을 바꾸는 기술들을 잘 활용하면 생산성을 월등하게 올릴 수 있게 된 것. Docker, k8s, Terraform 등이 주요 예들.

  10. 새로운 환경과 기술을 활용하기 위해, 기업들 내에서는 DevOps, SRE, Platform Engineering 등의 이름을 한 조직들이 생겨남. 이들은 전통적인 IT 부서들보다 더 제품의 전체 lifecycle에 더 깊게 관여하고, 기업의 생산성 개선을 도움.

  11. 요즘에는 그 위에 AI / ML 등을 운영해야 하는 필요가 늘면서 MLOps, LLMOps 등의 이름도 생겨났는데, 본질은 소프트웨어 개발, 테스트, 배포, 운영 전반적인 관리, 클라우드의 활용, 그리고 복잡도 관리라 생각. 지난 10년간 많은 발전이 있었고, 이제는 클라우드를 사용하지 않는 on-prem도 클라우드의 방법론이 생산성 개선에 큰 영향을 주고 있다고 보임.

  12. 2013년쯤 두 명의 UW 학부 졸업생이 만든 $HCP는 그런 패러다임을 이끄는 의미 있는 회사였음. 이들이 발간한 방법론인 <The Tao of HashiCorp>는 종사자라면 특히 읽어볼 만 함.

  13. 그중 가장 의미 있는 방향 중 하나는 Infrastructure-as-Code (IaC). 서버가 어떤 모습을 하고 있어야 하는지 의도(intention)를 declarative 하게 정의하고 운영하는 것임. 기존의 물리적 서버를 운영할 때의 procedural 방식은 서버가 어떻게 (how) 돌아가야 하는지에 초점이 맞춰졌다면, 새로운 방식은 what에 집중할 수 있게 해 줌.

  14. 이들이 이런 혁신을 처음 만들어 낸 것은 아님. 1970년대부터 declarative 한 SQL의 강점은 잘 알려져 있었고, 비슷한 역할을 하는 Ansible이나 Puppet 역시 같은 기반을 갖고 있음.

  15. $HCP의 차별점은 cloud native + vendor neutral 전략이었음. 모든 문제를 푸려고 하는 데신 클라우드에 집중하고, 대신 AWS 같은 하나의 vendor에 종속적이지는 않게 만든 것.

  16. 위에서 언급한 데로 클라우드가 엄청나게 성장하고, Big 3의 경쟁이 심화되면서 이 포지션이 굉장히 강력해짐. $HCP는 그 포지션을 더 공략하며, Vault, Consul 등 전반적인 platform engineering에 필요한 제품들을 계속해서 개발해냄.

  17. 클라우드의 순풍과 코비드 시기 가파른 성장에 힘입어 2021년 12월, 주당 $80로 IPO도 마치고, 연말에는 $102.95 최고점을 찍음. S-1에서는 2026년 진입 가능한 시장 규모 (Total Addressable Market; TAM)이 $73B라 추정. 이 당시 $HCP의 연간 매출은 run-rate로 $259M이었으니, P/S로 50 이상이었지만, 연간 성장률이 75%로 높은 기업 가치가 가능했음.

  18. 금융에 관심 있는 사람이라면 이들의 환상적인 타이밍에 감탄할 수 있음. 3개월 뒤, Fed는 금리를 올리기 시작하며 제로 금리 시대 (zero interest rate policy; ZIRP)는 막을 내리고, 테크 IPO는 한동안 자취를 감춤.

  19. 기업들도 비용 절감을 시작하며 FinOps가 중요해지고, 높은 매출 성장률은 유지가 힘들어짐. $HCP의 연간 성장률은 15%까지 내려오고, 주가도 2023년 11월에 $19.29까지 찍음. 이는 IPO 뿐 아니라 2020년 4월 Series E 가격 $28.92보다도 현저히 낮았음.

  20. 아직 연간 매출이 $0.5B인 규모이고, 이윤(profit)도 나지 않는 상태에서 성장 둔화는 버티기 힘든 문제였음. 제품의 원가랄 게 별게 없으니, Non-GAAP 기준 gross margin은 85%에 달함. 하지만 아직 개발 (r&d)이나 영업(s&m)에 지속적인 투자가 필요한 상황이고, 운영 비용(g&a)도 무시할 수 없으며, 비현금 보상인 주식 보상도 큰 부분을 차지해서 이윤을 내는 회사로는 길이 멀었음.

  21. 결국 2024년 4월 24일 IBM과 주당 $35로 merger agreement에 합의하고, 저번주 합병이 완료됨. $HCP는 업계에서 흔한 차등 의결권(dual class)을 갖고 있었고, 소수의 창업자들과 투자자들이 절반이 넘는 의결권이 있었지만, 당연히 (?) 소액주주들도 같은 금액으로 인수됨.

  22. 소프트웨어 기업의 가치란 무엇인지 생각해 볼 좋은 사례라 생각. 이들의 주요 제품들은 오픈 소스로 누구나 접근 가능함. 하지만 고객들은 여전히 돈을 주고 이들에게 서비스를 구입함. 코드가 기업 가치의 전부는 아니라는 얘기.

  23. 그럼에도 독자 기업으로 번성하기 힘들었던 이유 중 하나는 이들이 노리는 문제의 영역이 너무 큰 것 아니었나 싶음. $HCP를 이용하는 데신 각각의 기업들이 platform engineering 역량에 투자를 하고, 자체적으로 운영하는 게 합리적인 선택이 돼버림.

  24. 절박해진 $HCP가 코드의 라이선스를 Mozilla Public License (MPL)에서 Business Source License (BUSL)로 변경하고, 다른 기업들이 이 코드를 이용해서 사업하는 것도 제한하려 해 보았지만, 바로 Linux Foundation에서 OpenTofu로 fork 해버림.

  25. 이와 반해, $MDB, $GTLB, $ESTC 등은 조금 더 사업하기 유리한 오픈 소스 라이선스로 변경할 수 있었음. 생각해 보면, Slack 같은 제품을 쓰면서 코드가 오픈되어 있는지는 따지지 않음. 오픈 소스라고 무조건 사업하기 어려운 것도 아니고, 문제에 따라 효과적인 전략이 될 수도, 제약이 될 수도 있는 것임.

  26. 여전히 $HCP는 가치 있는 기업이었음. 주가가 더 내려가지 않은 요인 중 하나는 IBM 외에도 구매할만한 회사들이 꽤 있었기 때문. RedHat 등을 갖고, 클라우드 운영에 초점을 맞춘 IBM이 적절한 인수 기업으로 보이긴 함.

저번 글 <개발 업계의 거시 흐름과 커리어 파도타기>에서 적은 것 처럼, 소프트웨어 업계의 거대한 흐름은 다양한 기회를 열고 닫음. 이는 직접 사업을 하지 않는 직원들이나 투자자에게도 마찬가지.

개발자 투자