핵클 | A/B 테스트, 기능 플래그 및 이상 징후 탐지 플랫폼

핵클 회사 소개 사이트 : https://hackle.io/ko/

기사로 보는 핵클

핵클 A/B 테스트 플랫폼 누적 트래픽 150억 건

핵클이 개발한 A/B 테스트 및 데이터 분석 플랫폼의 누적 데이터 처리량이 150억건을 넘어섰다. 올해 2분기 데이터 처리량은 작년 동기 대비 920% 성장했다.

핵클의 고객사는 A/B 테스트, 기능 플래그 기능을 통해 제품 출시 과정에서 겪게 되는 시행착오에 대한 위험을 사전 진단 및 방지할 수 있고, 이벤트 관리 기능과 데이터 분석 기능을 활용하여 고객의 구매 여정을 분석, 고객 니즈에 맞춰 보다 정교하게 기능을 개선해 낼 수 있다.

플래텀, 2022-07-21
https://platum.kr/archives/189728 

핵클 A/B 테스트 플랫폼 누적 트래픽 150억 건

 

 

핵클 A/B 테스트 및 데이터 분석 플랫폼, 월간 데이터 처리 15억 건

핵클이 자체 개발한 기업용 소프트웨어 ‘애자일 SaaS 플랫폼’이 ‘우아한형제들’, ‘네이버제트’, ‘당근마켓’, ‘카카오스타일’, ‘여기어때’, ‘클래스101’, ‘토스’ 등 유니콘 및 테크 기업에 도입되어 성장세를 보이고 있다. 핵클을 통해 수집된 데이터는 월 15억 건을 돌파하였으며, 이는 작년 대비 500% 이상 성장한 수치다.

핵클의 A/B 테스트는 엔터프라이즈급 온라인 실험 플랫폼으로, 유니콘 테크 기업부터 스타트업까지 다양한 규모의 회사가 데이터 기반으로 프로덕트를 개선하고 있다. 최근 데이터 분석 서비스와 데이터(이벤트) 관리 플랫폼을 출시하면서, 고객사는 한 번의 연동으로, 데이터 로깅 정리, 데이터 분석, 온라인 실험, 기능 플래그를 활용한 배포, 이상징후 모니터링 까지 데이터 기반 제품 개발의 모든 과정에 대한 지원을 받을 수 있게 되었다.

핵클은 2020년 7월 쿠팡에서 함께 근무하던 소프트웨어 개발 전문 인력 4인이 공동 창업한 회사이며, 쿠팡에서 함께 쿠팡페이, 쿠팡이츠 등의 서비스를 출시, 개선했던 베테랑 프로덕트 오너, 소프트웨어 엔지니어, 데이터 사이언티스트 인력을 중심으로 SaaS 소프트웨어를 자체 개발하여 서비스 중이다. 국내 시장의 성과를 기반으로 올해 하반기 AWS 마켓플레이스 등을 활용해 해외 진출을 진행할 계획이다.

플래텀, 2022-05-16
https://platum.kr/archives/185824 

핵클 A/B 테스트 및 데이터 분석 플랫폼, 월간 데이터 처리 15억 건

 

 

 

채용 사이트로 보는 핵클

https://careers.hackle.io/overview

Hackle Overview

미션과 비젼

Mission
We build the best AI-based SaaS platform that supports fast, stable, and data-driven product iterations for tech companies to allow them to accelerate their growth while scaling up.

 

미션) 핵클은, 테크 회사들이 스케일업을 하는 과정에서 성장을 가속하기 위해 빠르고, 안정적인, 데이터 기반의 프로덕트 개발 반복 과정을 돕는 인공지능 기반 SaaS 플랫폼을 만든다. 

 

Vision
The world's most customer-oriented SaaS company, where customers can enjoy all the tools and resources for growth.

 

비젼) 고객사들이 성장을 위해 필요한 모든 도구와 자원들을 사용할 수 있는, 고객-중심의 SaaS 회사

 

 

해결하고 싶은 문제들

- No more bullshit metrics. 
Startups are not able to see the exact impact of new product release (as-is vs. to-be) without A/B test platform, and that's why they rely on the difference from versions (old vs. new). Thus, they do not recognize what exactly happened to their business, even if the new version of product hurts the overall conversion. Our A/B test platform will help them understand what is exactly happening with the right data.

 

"가짜" 수치를 없애기

스타트업은 AB 테스팅 플랫폼 없이는 신규 프로덕트 출시의 정확한 효과를 알 수 없다. 그렇기 때문에 버전 간 차이에 집중하곤 한다. 따라서, 회사들은 새로운 버전의 프로덕트가, 상품 전체의 전환에 악영향을 주더라도, 정확히 사업에 어떻게 영향을 주었는지 알 길이 없다. 우리의 AB 테스팅 플랫폼은, 정확한 데이터를 기반으로 어떤 일이 일어나는지 파악이 가능하게 한다. 

 

- Save the developers resources.
It is not able to control features independently without additional deployment if startups do not have a platform to control features with independent flags. Additional deployment to control features will make them slow and waste tech resources. Hackle CI/CD feature management platform will help them save the developers resources and move faster.

 

개발 자원 절약

만약 스타트업들이 독립적인 플래그를 통해 기능들을 통제할 플랫폼이 없다면, 추가 배포 없이 독립적으로 기능들을 통제하는 것을 불가능하다. 기능을 조정하기 위해 추가 배포를 하는 일은, 기술 자원들을 낭비하고, 대응 속도를 느리게 한다. 핵클의 CICD 기능은 개발 자원 낭비를 줄이고, 보다 제품 개발 속도를 빠르게 하는 것을 돕는다. 

 

- Be prepared for incidents.
For startups, it is not possible to track each important system metrics, and to automatically execute the contingency plan for incidents unless they have resources to build, or buy, the sophisticated and expensive alert/monitoring/incident systems. Hackle's monitoring and incident management platform will support startups to minimize the incident impacts for ongoing product iteration.

 

장애 대응

스타트업들에게는, 정교하지만 비싼 장애 대응/모니터링 시스템을 직접 개발하거나 혹은 구매하기 위한 자원이 충분하지 않는 한, 시스템 관련 중요 지표 하나하는 트래킹하기도 어렵고, 위기 발생 시 자동적으로 위기 대응 계획(컨틴전시 플랜)을 수행하기도 어렵다. 핵클의 모니터링 및 장애 대응 플랫폼은 스타트업들이 지속적인 프로덕트 개발 주기 반복 과정에서 영향도를 최소화할 수 있도록 돕는다.

 

 

핵클의 창업 이야기

제품 개발을 잘 하려면, 일정만 맞춘다고 되는 것이 아니고, 고객의 긍정적인 반응을 데이터로 확인하면서, 장애나 버그 같은 문제 없이 빠르게 할 수 있어야 된다고 생각한다. 그래야 지치지 않고 속도를 유지하면서도 안정적으로 할 수 있다. 실제로 대형 Tech 회사들은 매우 많은 인력들을 제품 개발을 잘 할 수 있도록 지원하기 위해서, 정량적인 데이터분석 및 안정적인 기능 출시를 위한 A/B Test, 효율적인 자원관리를 위한 CMDB, 안정적이고 지속적인 배포를 위한 CI/CD, 피쳐 관리, 장애 모니터링과 같은 다양한 플랫폼 개발 및 유지 보수에 투자하고 있다. 하지만, 개발 리소스가 부족한 중소기업이거나 이제 막 서비스를 출시한 스타트업들은 이런 투자를 하기 쉽지 않고, 관련 지식을 갖고 있는 인력을 보유하지 않은 경우도 많다. 결국 이들은 A/B Test가 아닌 전/후 비교에 의존한 제품 출시, 실시간 모니터링과 피쳐 관리와 같은 지원이 없는 배포와 장애 관리 시스템의 부재와 같은 상황들을 겪게 되고, 여기서 발생하는 부정적인 데미지들은 전반적인 제품 개발의 속도와 완성도를 낮추는 요소가 된다.

우리는 테크회사들의 각 회사의 핵심 제품 개발에 집중할 수 있도록, 위와 같은 문제들을 대신 해결해 주려고 한다. 금전적인 진입장벽도 해소하기 위해서, 영세 규모의 스타트업들에게는 최대한 경제적 부담을 낮추고 사용할 수 있는 무료 지원 프로그램도 계획 중이다. 핵클의 제품(Iteration Platform)을 통해서 앞으로 1) 코드 몇 줄로 SDK 연동만 하면, 매뉴얼한 데이터 추출, 그룹 지정, 데이터 계산 등의 수고 없이 A/B Test를 진행할 수 있게 될 것이고, 2) 하나의 배포 안에 다양한 피쳐들이 포함되어 있어도 이것들을 독립적으로 모니터링 및 관리할 수 있을 것이고, 3) 고도화된 실시간 장애 모니터링 및 복구 시스템을 이용할 수 있게 될 것이다. 그래서, 우리의 제품을 통해서 테크회사들은 더 빠르고, 안전하게, 데이터 기반의 제품 개발을 할 수 있을 것이다. 우리는 이런 변화가 세상을 더 편리하게 바꿀 수 있을 것이라고 생각한다.

(...)

미국에 Stripe 라는 지금은 40조원 규모의 테크 스타트업이 있다. Paypal이 지배하고 있는 결제 시장에서, 이들은 쉬운 결제 연동을 무기로 스타트업들을 공략했고, 그 스타트업들이 성장하면서 Airbnb, Dropbox 와 같은 고객들의 트래픽이 성장하면서, Stripe는 함께 동반 성장했다. 우리는 핵클도 이 선례를 따라갈 수 있을 것이라고 본다. 규모가 작은 영세한 스타트업들이 들어와서 기술적으로 어려움 없이 쉽게 연동해서 사용하고, 핵클 플랫폼을 자발적으로 이용할 수 있게 해주는 것이다. 그 시작을 위해서, 9월부터 스타트업의 A/B Test 도입을 위한 무료 교육 및 코칭 프로그램 (http://hack-the-product.hackle.io) 을 시작했고, 월 1~2회 단위로 계속 진행할 계획이다. 이 프로그램은 교육 프로그램과 함께 1:1 코칭을 통해 스타트업들이 A/B Test 를 이해하고, 어떻게 적용하고, 결과를 해석해야 하는지까지 전 과정을 지원해서 Best Practice들을 함께 만들어가는 시발점이 될 것으로 기대한다.

2020-09-11, Chuck Sunwoo
https://medium.com/hackle/hackles-first-story-s01e01-eff300253ec2 

Hackle’s First Story — S01E01 (한국어)

 

 

 

튜토리얼로 살펴보는 핵클

• 구글 계정만 있으면 바로 이용 가능하다는 간편성 확인 가능
  
  
• 핵클 대시보드
  • 데이터 분석 차트, 주요 지표, 최근 진행 중인 AB 테스트, 기능 플래그 등 한눈에
  • 한번의 SDK 연동으로 모든 기능 사용 가능
    
    
• SDK 연동
  • 환경 별로(운영/개발, 서버/프론트 따라) SDK 키를 직접 복사 혹은 개발자 초대
    
    
• A/B 테스트
  • 신규 버전을 기존 버전과 동시 비교해 성과 확인
  • 실험 수, 신규 버전 수, 비교 목표 수 제한 없음
  • 테스트 상태, 트래픽 할당은 대시보드에서 조정 가능
  • 목표에 대한 통계적 유의성 검증도 제공
    
    
• 기능 플래그
  • 신규 배포와 출시를 분리하여 안정적으로 출시하는 기능
  • 기능 플래그를 달아 배포 시 변경 사항 고객 적용 안됨. 대시보드로 ON 해야만 출시.
  • 특정 OS, 특정 비율 사용자 등 선택 적용 가능
    
    
• 데이터 분석
  • 프로덕트 주요 지표 확인 (사용자 수, 방문, 회원가입, 매출, 전환율, 리텐션 등)
  • 이벤트를 사용한 분석 가능 
  • 사용자 그룹 바이 기능 제공
    
    
• 이벤트 관리
  • 연동 이벤트 목록 확인 가능
  • 이벤트 생성 가능
  • 이벤트 내 속성 값 + 과거 발생 이력 + 최근 30분 실시간 수집 현황 확인 가능

 

 

 

고객 사례로 본 핵클

팀스파르타가 A/B테스트툴을 구글 옵티마이즈에서 핵클로 옮긴 이유

실제로 저희는 인하우스에서 복합 변수의 A/B 테스트도 테스트하고 있었어요. 이러한 테스트는 개발 리소스가 많이 들다보니 자주 하지는 못했어요. (한 달에 2번) 구글 옵티마이즈를 이용해서 싱글페이지 수준에서 카피를 바꾸는 테스트는 이미 많이 하고 있었습니다. (주에 2~3번)
당시 느꼈던 문제는 크게 2가지였습니다.

먼저, 인하우스 개발은 개발 리소스가 너무 많이 들었다는 점입니다. 적재로그를 만들고, 결과를 분석하고.. 이를 위해서는 데이터 엔지니어를 겸하는 데이터 분석가가 별도로 있어야했습니다.

다음으로, 구글 옵티마이즈는 기능이 너무 제한적이었는데요. 예를 들면 다변수 테스트가 지원되지 않았다는 점입니다. 초보적인 기능 위주로 쓸 수밖에 없는 상황이었습니다.
https://blog.hackle.io/post/sparta-1 

2) 직관적이고 쉬운 UX
더불어, 핵클은 대시보드가 고객 관점에서 잘 만들어져있다고 생각합니다.
구글 옵티마이즈도 베이지안을 지원해주긴 했지만, 핵클은 빈도주의(p-value)를 추가적으로 제공함으로써 성공 지표(success metric)를 직관적으로 확인할 수 있도록 도와주고 있습니다. 핵클은 쿠팡에서 수백건의 A/B 테스트를 직접 진행하며, 다양한 관점에서 결과를 해석하고 의사결정을 한 경험이 있는 멤버들이 만들었잖아요? 대시보드에서 확인가능한 정보(빈도주의, 베이지안 등)들은 이런 멤버들이 큐레이션해주는 것인 만큼, 실험의 결과에 대한 winning 판단을 내리는데 큰 도움이 되었습니다. ‍

* 베이지안 확률이란, 종속적 관계에 놓인 사건들을 기반으로 구하는 조건부 확률을 의미합니다. 유저수가 충분치 않아 빈도주의(p-value)를 통해 통계적으로 유의미한 결과를 얻기 어려운 경우 베이지안 확률을 참고하여 의사결정을 할 수 있습니다. ‍

3) 옵티마이즈 대비, 더 정확한 데이터 집계 및 실험 가능
구글 옵티마이즈는 세션 기반이어서 정확한 데이터 확인이 어렵다는 점에서 아쉬웠습니다. 핵클은 디바이스 기준으로 유저를 식별할 수 있고, 유저 ID까지 할당한 회원 대상으로 하는 실험에서는 더 정교한 실험이 가능하다는 점이 좋았습니다. 그리고 옵티마이즈는 시작한 실험이 서비스에 적용되기까지 반나절 정도의 시간이 걸렸는데, 핵클에서는 변경사항이 실시간으로 서비스에 적용된다는 점도 좋았습니다. ‍

1) 가격
당시, 옵티마이즐리, VWO, 옵티마이즈 이렇게 비교해봤는데요. 우선 옵티마이즐리의 경우 가격이 너무 비쌌어요. 그 가격을 지불할 정도로 확신할 수 없었습니다. 반면, 핵클은 사용량 기반으로 과금되기 때문에, 작은 규모의 스타트업도 부담없이 사용해볼 수 있었어요. ‍

2) 실험 설계의 자유도
옵티마이즈는 싱글 랜딩 페이지를 최적화하는데 초점을 두고 있는데, 제대로 된 가설을 끝까지 밀어부칠 수 있는 프로덕트 A/B 테스팅 솔루션은 아니라고 생각했습니다. 카피라이팅, CTA 등을 테스트하는 것까지는 가능했지만 깊은 배움을 얻기에는 부족했죠. 제대로 된 가설을 가지고 가설을 검증을 할 수 있는 정교한 A/B 테스트를 해보고 싶었습니다. ‍

3) 빠르고 전문적인 CS
핵클은 수 많은 A/B 테스트를 경험해 본 쿠팡 출신의 파운더들이 만들었다는 점이 매력적입니다. 사실 이러한 테스트는 데이터의 정확성이 안 맞으면 모든 가설이 무너지는 것인만큼, 데이터 정확성에 대한 신뢰가 중요한데요. 파운더들의 경력과 실력을 봤을 때 믿음이 갔고, 특히 우리가 초기 고객이면 더 많은 지원을 받을 수 있을 것이라고 생각했습니다. 실제로 핵클의 개선 방향성을 볼 때, 저희가 쓰기 좋은 프로덕트가 되어가고 있다고 느끼고 있습니다. 핵클은 고객의 목소리를 잘 듣고 빠르게 반영하는 팀이라고 생각합니다.

https://blog.hackle.io/post/sparta-2 

핵클 블로그(Hackle Blog) : 팀스파르타가 A/B테스트툴을 구글 옵티마이즈에서 핵클로 옮긴 이유

 

클래스101 개발팀이 말하는 기능 플래그 도입 전후 변화

저희 테크팀은 주기적인 배포를 지향합니다. 과거에는 데일리로 심지어는 하루에도 수 차례 배포가 나갔었는데요. 체계가 갖춰지지 않은 상태에서 잦은 배포로 인해 서비스의 장애가 굉장히 많이 발생했습니다. 이를 일차적으로 해결하기 위해서, 내부적으로 레디스(Redis)를 이용해 기능 플래그를 직접 만들어 사용했는데요. 기능 on/off를 통해 유저에게 기능을 출시할지 여부를 제어하는 용도로 사용했습니다. 당시 느꼈던 문제는 크게 2가지였습니다.

먼저, 기능 플래그가 전체 유저를 대상으로만 작동하다보니 내부 기능을 키게 되면 100% 유저들을 대상으로 적용되었는데요. 이 때문에, 서버에 부하가 걸리는 일이 종종 발생했어요.

또한, 권한관리가 안된다는 것도 문제였는데요. 기능 플래그를 관리자 쪽에 시스템을 구축해두었다보니, 일반 회사 직원분들이 기능에 접근할 수 있었거든요.

SaaS를 사용하게된 가장 큰 이유는 내부 리소스의 문제로 더 이상의 유지보수를 하기 어렵다는 점이었습니다. ‍

Joy | 핵클 기능 플래그의 유저 타겟팅 기능을 유용하게 사용하고 있습니다. 사용 전 후, 유저 에이전트 기준으로 기능의 on/off 규칙을 세부 설정할 수 있는 것이 좋았는데요. 최근에 카카오페이를 결제수단으로 추가했는데, 인앱일 경우엔 해당 기능을 꺼두는 방식으로 기능 플래그를 활용했습니다. 기능의 on/off를 배포 없이도 핵클을 통해 세부적으로 할 수 있다는게 큰 장점인 것 같아요. 문제가 생겼을 때 롤백이 필요한 중요한 결정에는 항상 쓰고 있습니다.

Chad | 커뮤니티에 많은 기능들이 추가되서 바로 나가야하는 상황이 있었는데, 바로 배포하기에는 리스크가 크다고 판단했었어요. 그래서 핵클의 기능 플래그를 활용해서 배포를 진행했는데요. 핵클은 개발과 운영환경이 나눠져 있어서, 개발자 환경에서 테스트를 해보고 이상이 없음을 확인 후 자신감있게 배포할 수 있어서 좋았습니다.

이전에 옵티마이즐리를 사용하셨다고 들었는데, 그 경험과 비교해서 핵클은 어떻게 달랐나요?
Joy | 사소하지만 사용자 입장에서는 크게 다가오는 사용성에서 핵클이 좋았어요. 예로는, 핵클은 A/B 테스트 실험키가 운영과 개발 값이 같은데요. 옵티마이즐리는 프로젝트를 2개 생성하고 각각 id가 달라서, 실험이 바뀌거나 세팅을 잘못하면 훨씬 더 공수가 많이 들었어요. 옵티마이즐리를 써본 경험이 있어서, 간단한 세션만으로도 핵클을 업무에 적용하는데는 큰 문제는 없었어요. ‍

https://blog.hackle.io/post/class101-dev 

핵클 블로그(Hackle Blog) : 클래스101 개발팀이 말하는 기능 플래그 도입 전후 변화

 

 

 

궁금한 점

* 배포를 관여하는 부분에 대해 SaaS를 활용한다는 고객들의 심리적 장벽은?

 

* 미션에 들어가 있는 AI는 어디에 사용되나?

 

* 데이터 정확성에 대한 신뢰도는 어떻게 확보하나? (구글도 못미더울 때가 많았는데)

 

* 기능 플래그의 작동 방식이 궁금해요. 

 

* 모니터링 및 장애 대응 관련 문제 해결은?

핵클을 쓰면서 장애 대응과정이 훨씬 수월해졌습니다. 클래스101은 다양한 마이크로 서비스가 배포되고 있고, 롤링 업데이트를 수행하고 있어요. 때문에 문제가 발생하였을 때, 문제 지점을 찾아 롤백할 때 수십분의 시간이 걸리는데요. 기능 플래그 없이 배포된 건의 경우, 이슈 대응이 즉각적으로 이루어지기 조금 어렵습니다. 하지만 기능 플래그로 배포된 건의 경우, 문제가 생기면 바로 기능 플래그를 Off 하면 되기 때문에 장애 대응이 훨씬 쉬워졌죠. 그래서 기능 플래그는 개발팀에서 필수적으로 사용해야 하는 기능이라고 생각해요. 또한 어떠한 부분에 장애가 있는지 여부를 파악하는데 있어서도 조금 더 쉬워졌는데요. 만약 배포 후에 이슈가 발생하면 각 배포사항에 해당하는 Jira 티켓에서 기능 플래그 ID를 확인할 수 있어서, 이슈의 원인이 된 배포사항과 관련된 기능 플래그를 핵클 대시보드에서 제어하는 방식으로 고객 경험을 관리할 수 있습니다. 중요한 배포 건은 기능 플래그가 적용되기 때문에, 이슈 확인시 기능 플래그를 먼저 확인하는 편이에요.
https://blog.hackle.io/post/class101-dev 

 

그러면 이슈의 발생 확인은?

생각하는 장애 대응의 범위란?