진정한 실험 조직의 탄생

안녕하세요 뱅크샐러드 데이터 파운데이션의 실험 플랫폼 팀 Product Manager 장한솔입니다.

데이터 파운데이션은 뱅크샐러드의 모든 조직이 데이터 기반의 의사결정을 할 수 있도록 인프라와 각 내부 서비스를 구축하고 가이드 하는 조직입니다. 실험 플랫폼 팀은 모든 조직이 가설을 검증하고, 정확하게 고객 임팩트를 측정할 수 있도록 실험 문화와 실험 플랫폼을 만들어나가고 있습니다.

주차별 누적 실험 생성 추이
Figure 1 | 주차별 누적 실험 생성 추이

뱅크샐러드는 2020년 1분기부터 모든 조직이 가설을 검증하고, 정확하게 고객 임팩트를 측정하기 위한 준비를 차근차근 해왔습니다. 그러한 모습은 위 그래프의 주차별 누적 실험 생성 추이를 통해 체감하실 수 있습니다. 1분기만 해도 분기에 약 7개의 실험이 생성되고 진행되는 데에 그쳤다면, 3분기에는 이미 100개가 넘는 실험이 진행되고 있습니다. 이제는 진정한 실험 조직이라고 할 만큼 실험을 너무나 자유롭게, 또 당연하게 진행합니다.

오늘은 뱅크샐러드가 어떻게 이런 실험 조직으로 거듭났는지, 문화적인 측면에 대해 집중해서 이야기 드리고자 합니다. 실험 조직으로 재탄생하기 위한 인프라 구축 과정에 대해선 추후 다른 글로 소개해 드릴 계획입니다. 오늘 소개해 드리는 내용을 통해 실험이 왜 중요하고, 실험을 기반으로 성장하는 조직이 어떤 모습인지 느끼실 수 있길 기대합니다.


🧪 실험은 무엇인가요?

실험 = (Online Controlled) Experiment = A/B Test
Figure 2 | 실험(Online Controlled Experiment)에 대한 설명

실험(Online controlled experiment)은 고객이 마주하는 변화의 임팩트를 측정하는 과정입니다. 흔히 A/B 테스트라고도 불리며, 서비스 기획과 개발을 통해 구현되는 특정 기능이 유저에게 미치는 영향을 정확하게 파악하기 위한 과정을 의미합니다. 이를 위해 실험은 1개의 대조군(Control Group)과 1개 이상의 실험군들(Treatment Groups)로 구성됩니다. 현재의 제품(또는 기능)을 보통 대조군으로 설정하고, 가설을 통해 검증하고자 하는 개선된 제품(또는 기능)을 실험군으로 설정합니다.


🤷 왜 실험을 해야 하나요?

위의 실험에 대한 정의를 충분히 이해하셨다면, 왜 실험을 해야 하는지도 자연스럽게 이해할 수 있습니다. 실험은 고객이 마주하는 변화(개선 기능 등)의 임팩트를 가장 정확하게 측정하는 방법입니다. 즉, 제품/기능을 구현할 때 가지고 있던 가설이 실제로 맞는지 실험을 통해 검증할 수 있습니다.

실험이 말해주는 불편한 진실
Figure 3 | 실험이 말해주는 불편한 진실

이전의 뱅크샐러드 구성원들은 위의 이미지에서 왼쪽 그래프처럼 실험 없이 서비스를 배포하고, 장밋빛 미래를 예상하였습니다. 그러나 실험을 해보면 항상 예상처럼 좋은 결과가 나오지 않는다는 걸 알 수 있습니다. 실제로는 저희가 예상한 결과보다 작은 결과가 나오기도 하고, 예상하지 못했던 부분에 악영향을 주는 경우를 발견하기도 합니다.

실험은 고객이 실제로 반응한 결과로 평가하는 활동입니다. 뱅크샐러드가 모든 것을 실험하는 전사 문화를 갖고 있는 이유는, 일정 내로 제품을 구현하거나 리더십이 원하는 기능을 만들었다고 좋은 평가를 받는 것이 아니라 고객이 원하는 제품을 만들어낸 성과만으로 평가하기 위함입니다. 즉, 실험은 모든 조직이 고객 임팩트만을 바라보고 일하기 위한 수단입니다. 뱅크샐러드에서는 고객이 마주하는 모든 변화를 실험을 통해 성과를 측정/검증하고 있습니다.


⛏ 실험 조직의 기초를 다지다

실험을 전혀 하지 않던 조직이 실험 조직으로 거듭나기 위한 첫 번째 단계는, 모든 조직 구성원의 데이터 역량을 높이고 데이터를 보는 문화를 만들어가는 것이었습니다. 실험 그 자체의 경험도 필요했지만, 실험을 통해 고객 임팩트를 정량적으로 측정하고 검증하려면 전사 구성원들 누구나 데이터를 살펴보고, 데이터를 기반으로 결정하는 역량 증진이 필요하기 때문입니다.

데이터 교육 자료 이미지
Figure 4 | 데이터 교육/가이드 자료

실험 플랫폼 팀은 전사의 실험 문화를 전파하겠다는 미션을 가지고, 이에 뱅크샐러드 구성원이라면 누구나 데이터를 조회하고 분석할 수 있는 역량을 가질 수 있도록 1분기 내내 각종 가이드를 만들고 데이터 관련 교육을 진행하였습니다. 1분기 동안 총 12개의 가이드를 만들고, 5번의 교육을 제공했습니다. 아직 데이터 조회를 어려워하거나 고도화된 분석이 필요한 분들을 위해 “데이터 자문 서비스”를 만들어 어려움을 겪는 분들을 돕고자 했습니다. 이 중에서 기초적인 내용을 모아서, 신규 입사자들을 대상으로 뱅크샐러드 데이터 활용하는 온보딩 강의를 진행하고 있습니다.

1분기 동안 전사 데이터 조회 Query 추이
Figure 5 | 1분기 동안 전사 데이터 조회 Query 추이

2019년 말까지는 뱅크샐러드의 사용자 데이터와 자산 데이터 등 가설과 인사이트를 뽑아낼 여러 데이터와 데이터 조회를 돕는 툴이 있었음에도 데이터 직군들만 데이터를 살펴보고 있었습니다. 데이터 직군들이 열심히 데이터를 살펴보고 분석해왔지만, 2019년 말에 데이터를 조회하는 전체 Query 수는 현재 수준의 ¼ 밖에 되지 않았습니다. 여러 교육 및 가이드를 통해 조직 구성원들이 점차 데이터를 보는 방법에 익숙해지자, 더 많은 사람이 더 자주 데이터를 살펴보기 시작했고, 자연스럽게 Total Query 횟수와 Average Query Run per User가 증가하였습니다. 이렇게 진정한 실험 조직으로 가기 위한 기본적인 데이터 역량을 전사 구성원들이 스스로 만들어가고 있었습니다.

코드 PR로 실험 생성/수정하기
Figure 6 | 코드 PR로 실험 생성/수정 하기

전사 구성원들이 실험을 하기 위한 데이터 역량을 쌓아가고 있었지만, 전사 구성원들이 사용할 수 있는 인하우스 실험 플랫폼을 순식간에 만들어갈 순 없었습니다. 전사 구성원들이 쉽게 사용하기 위해서는 UI로 실험을 설정하고 생성할 수 있는 내부 웹 서비스가 필요하였습니다. 실험 플랫폼을 웹 형태로 구축하기엔 시간이 오래 걸리니, 우선 실험을 경험할 수 있도록 실험을 추가하려는 개발자가 PR을 통해 코드로 실험을 생성하고 수정할 수 있도록 서비스를 구성하였습니다. 1분기에는 실험 플랫폼 팀이 개발자들을 위한 실험 생성 가이드, 배포 가이드 등을 제공하였고, 각 스쿼드에서는 개발자분들의 도움을 받아 실험을 생성하고 진행할 수 있었습니다.

인하우스 실험 인프라를 이용한 첫 실험
Figure 7 | 인하우스 실험 인프라를 이용한 첫 실험

위 실험은 1분기에 처음으로 인하우스 실험 플랫폼 인프라를 통한 첫 실험 사례입니다. 기존에 너무 많은 정보를 텍스트로 제공하던 자산 탭을 정말 필요한 정보만 노출하고 가독성을 높이는 방향으로 개선한 실험이었습니다. 이 실험을 하나의 사례로 언급하며, 다른 팀들에 실험을 진행해볼 것을 제안해나갔습니다. 실험을 제안하다 보니, 처음에 계획했던 클라이언트(iOS, Android) 사이드 실험 외에도 웹뷰/서버 사이드 실험을 지원할 필요가 있었습니다. 이에 1분기에는 어떤 팀이든 실험을 한 번이라도 경험하도록 만드는 데 초점을 두고, 다양한 실험이 진행될 수 있도록 지원하는 데에 집중하였습니다. 그렇게, 조금씩 실험을 경험하는 조직들이 생겨나기 시작했습니다.


🐥 실험 조직으로 다시 태어나기 위한 진통을 극복하다

실험 인프라와 데이터 교육들을 마련하고 실험을 시작하는 조직들이 생겨나기 시작했으니, 점점 많은 구성원이 활발하게 실험을 진행할 거라고 기대하였습니다. 그러나 기대와는 달리 팀의 사정, 실험에 대해 이해하는 정도, 직군마다 가지고 있는 어려움에 따라 실험의 필요성을 다르게 받아들였습니다. 대부분의 구성원들이 실험을 해야 되는 것에는 동의하나 부족한 리소스로 인해 실험 진행의 부담을 느끼는 경우도 있었고, 실험 프로세스에 대한 이해가 부족하여 오해하는 경우들도 있었습니다. 실험 아래는 대표적으로 실험에 대해 오해하여 발생한 커뮤니케이션을 모아봤습니다.

실험과 관련한 miscommunication
Figure 8 | 실험과 관련한 오해들

위의 내용은 실험에 대한 이해나 경험이 부족한 사람이라면 누구나 던질 수 있는 질문입니다. 각 질문에 대한 답변은 아래와 같습니다.

Q1. 이건 누가 봐도 당연한 결과가 예상되는데 실험을 진행해야 하나요?

A) 네, 실험은 당연한 결과가 예상되더라도 진행해야 합니다. 실험이라는 단어를 측정이나 검증이라고 바꾼다면 실험을 해야 하는 이유가 좀 더 쉽게 설명됩니다. 우리가 만든 제품을 고객들한테 내놓을 때 고객이 어떤 반응을 보이는지 측정하고 검증해야 우리는 그다음 방향을 정할 수 있습니다. 실험을 통해 우리는 가장 정확하게 고객 반응을 측정할 수 있습니다.

Q2. 일정 너무 빠듯한데 실험까지 챙기고 분기 처리해야 해서 너무 힘듭니다. 다음부터 실험하면 안 될까요?

A) 가능하다면 실험하는걸 권장해 드립니다. 실험은 개발 일정이나 배포 일정에 blocker가 되지 않습니다. 처음이라 실험을 준비하는 과정이 조금 어렵다고 느껴지신다면, 실험 플랫폼 팀에 언제든 도움을 요청하시면 적극 도와드리겠습니다. 점점 많은 실험들을 진행하게 될 것이고, 클라이언트에서 분기된 코드도 많아지게 됩니다. 앞으로는 실험 분기 코드를 잘 관리하고 수용하는 것이 조직과 개발자의 역량이 될 겁니다.

Q3. iOS 실험 일정 보니, 9월 4일에 실험 100% 노출된다고 들었습니다. 9월 4일부터 해당 기능 마케팅하면 되는 거죠?

A) 아닙니다. 대조군과 실험군 두 그룹만 있는 실험이 100% 노출된다는 의미는 대조군 50%, 실험군 50%에게 개선 기능이 노출된다는 의미입니다. 실험 분석 결과가 나와, 실험이 종료되어 실험군으로 100% 배포되었을 때 마케팅을 진행하시면 됩니다.

Q4. 고객이 고객센터로 문의했는데요. Android 실험 일정 보니 A 실험이 예정되어 있습니다. A 기능 때문에 문의한 것 같은데, 맞는 건가요?

A) 아닙니다. A 실험은 아직 노출되지 않아, 어느 고객도 개선 기능을 보고 있지 않습니다. 앞으로 다양한 실험이 진행될 예정이라, 고객 센터로 문의한 고객이 어떤 실험에 어떤 실험군으로 할당되었는지 실험 플랫폼을 통해 확인할 수 있도록 준비하고 있습니다.


실험 문화 적응을 돕기 위한 가이드 문서들
Figure 9 | 실험 문화 적응을 돕기 위한 가이드 문서들

질문이 들어오면 빠르게 답변하면서 단기간의 이슈들을 해결해 나갔지만, 매번 실험과 관련된 문의를 받을 때마다 답변하는 식으로는 모든 구성원이 실험을 필수적인 과정으로 받아들이고 실험으로 인해 변화하는 일하는 방식까지 적응시킬 수 없었습니다. 이에 가장 먼저, 실험을 진행하고자 하는 팀들을 타겟으로 실험 문화에 적응해 나갈 수 있도록 아래와 같은 노력을 해나갔습니다.

  • 실험 설계에 작성하는 내용을 최대한 간소하게 변경하여, 누구나 실험 설계 문서를 작성하고 피드백을 통해 고도화할 수 있게 하였습니다.
  • 제품 배포 막바지에 실험 설계하는 경우에는 최대한 빨리 실험 설계 리뷰를 마쳐, 제품 배포 일정 연기를 방지하였습니다.
  • 실험 생성/수정을 할 때 실험 코드 작성에 익숙하지 않은 개발자들을 대상으로 실험 설계가 완료된 경우 실험 플랫폼 팀에서 실험 생성 및 수정하는 코드 작업을 지원하였습니다.
  • 실험이 진행되면 매주 실험 지표 결과를 분석하여, 실험 진행/종료 의사결정을 함께하며 실험 분석 과정 및 결과에 적응하도록 도왔습니다.
  • 조직 구성원들이 자주 묻는 내용(FAQ)을 정리하고, 실험 배포 가이드, 모니터링 가이드, 실험 기술 용어들을 정리하여 누구나 실험에 대해 궁금할 때마다 꺼내 볼 수 있게 문서화하였습니다.

실험 진행을 적극적으로 지원하면서, 실험을 진행하는 팀의 이해도는 높아져 갔지만 그렇지 않은 팀은 여전히 실험 문화에 쉽게 적응하지 못했습니다. 실험을 진행하면서 제품을 배포하는 프로세스가 변경되었고, 이에 따라 QA 방식, 고객 문의 대응 프로세스, 마케팅 시점, 로드맵 일정 등 기존에 조직 구성원들이 수행하던 업무에 변화가 필요했습니다. 이를 위해선 전사 구성원이 실험에 대해 이해하고, 변화된 방식에 맞게 실험 플랫폼을 자유자재로 활용할 수 있어야 했습니다.

온라인 실험 및 실험 플랫폼 이해 세션
Figure 10 | 온라인 실험 및 실험 플랫폼 이해 세션

이런 필요성에 따라, 전사 구성원을 대상으로 두 차례의 실험 및 실험 플랫폼 교육 세션을 가졌습니다. 해당 세션은 영상으로 녹화하여 혹시라도 세션에 참석하지 못한 경우엔 찾아볼 수 있게 만들었습니다. 또한, 신규로 입사하는 분들을 대상으로 하는 온보딩 강의 중 하나로 추가하였습니다. 뱅크샐러드에 입사하는 분이라면 누구나 실험에 대해 이해하고 실험 플랫폼을 사용할 수 있어야 하기 때문입니다.

CX 파운데이션의 개선 요청과 실험 플랫폼팀의 대응
Figure 11 | CX 파운데이션의 개선 요청과 실험 플랫폼 팀의 대응

또한, 실험으로 인해 기존의 업무 방식이 변화하면서 각 팀에서 실험 플랫폼에 요청하는 내용들을 빠르게 대응해나갔습니다. 예상하지 못한 기능이었지만, 실험 문화 안착을 위해서는 필수적인 기능들이었기 때문입니다. 관련 팀들과 미팅을 하고 필요로 하는 기능들의 우선순위를 정하여 차근차근 대응해나갔습니다. 대표적으로 고객이 고객센터로 문의했을 때, 어떤 실험에 어떤 실험그룹에 속해있는지 조회하는 기능을 실험 플랫폼에 구현하였습니다. 이를 통해 CX팀에서는 실험을 통한 정성적인 고객의 피드백을 빠르게 수집하고, 고객이 겪는 어려움을 정확하게 파악할 수 있게 되었습니다.


🚀 진정한 실험 조직으로 재탄생하다

뱅크샐러드 인하우스 실험 플랫폼 웹
Figure 12 | 뱅크샐러드 인하우스 실험 플랫폼 웹

전사 구성원들이 점차 실험 문화에 적응해나가기 시작할 무렵, 실험 플랫폼 웹이 배포되었습니다. 이전에는 개발자분들이 코드로 실험을 생성하고 수정하고, github repository에서 진행 중인 실험들을 확인할 수 있었으나 실험 플랫폼 웹 배포 이후에는 누구나 실험을 생성/수정하고 진행 중인 실험을 확인할 수 있게 되었습니다.

실험 플랫폼에 대한 Shoutout
Figure 13 | 실험 플랫폼에 대한 Shoutout

실험 문화가 어느 정도 자리 잡은 상태에서 실험 생성과 관리가 쉬워지니, 생각했던 것보다 훨씬 파급력이 컸습니다. 실험 플랫폼 UI에서 실험을 경험한 사람들은 실험 진행이 이전보다 훨씬 쉽고 매끄러워졌다는 사실을 깨달아갔습니다. 자연스럽게 더 많은 PO, PM, 디자이너, 개발자분들이 실험을 경험하게 되었고 제품을 배포할 때 실험을 필수적인 과정으로 여기기 시작했습니다. 거기다 3분기부터 BPL (Banksalad Product Language)이 도입되면서 각 스쿼드에서 이전보다 훨씬 빠르게 제품을 개발해나갔습니다. 제품을 빠르게 만들어 실험하고, 지표를 보고 또 빠르게 개선 사항을 실험으로 검증하는 선순환이 돌기 시작했습니다.

주간 실험 리뷰 회의
Figure 14 | 재택근무기간에도 진행되었던 주간 실험 리뷰 회의

실험이 많아지면서 실험 결과 분석도 좀 더 체계적으로 이루어질 필요가 있었습니다. 이전에는 실험 플랫폼에서 실험 분석 결과(지표)를 제공할 순 없는 상태라 매 실험 설계마다 설정한 지표들을 BI 툴을 통해 확인하고 있었습니다. 더 정확하고 신뢰도 있는 실험 문화를 구축하고자 주간 실험 리뷰 회의를 구성하였습니다. 데이터 사이언티스트들이 매주 진행 중인 실험들의 지표를 추출하고, 통계적 검정력, 통계적 유의성과 함께 실험 결과를 분석하였습니다. 주간 실험 리뷰 회의에서는 실험과 관련된 이해관계자가 참석하여 의사결정이 필요한 실험 및 진행 중인 실험들의 지표 현황을 공유하고 next action을 결정지었습니다. 이 회의를 통해, 성공적인 실험의 인사이트를 모두가 나누고, 실험 노하우를 학습하며 그다음 실험을 어떻게 진행할지 조언을 구하기도 했습니다.

P2P 상품 이미지 실험
Figure 15 | P2P 상품 이미지 실험

실험을 진행하고 실험 결과를 분석하며, 드디어 고객들한테 성적표를 받기 시작했습니다. 너무나 당연한 결과를 예상하고 있던 경우에서 대조군이 더 나은 지표를 보이기도 했고, 예상보다 실험군에서 훨씬 개선된 지표가 발견되는 경우도 있었습니다. 위 이미지에서 P2P 상품의 실제 건물 이미지를 노출하는 실험을 진행했으나, 진행 전에는 당연히 실험군(건물 이미지가 노출되는 그룹)을 더 많이 클릭할 거라 예상했지만 실제로는 대조군과 큰 차이가 없었습니다. 다행히도 뱅크샐러드 구성원들은 예상했던 지표가 나오지 않았다고 좌절하거나 실패한 실험이라고 치부하지 않았습니다. 실험 결과로 얻어갈 수 있는 lesson을 공유했고, 추가 실험을 통해 어떻게 고도화할지 고민하였습니다.

실험 경험/노하우 발표 내용
Figure 16 | 실험 경험/노하우 발표 내용

실제로, 매월 진행되는 뱅크샐러드 사내 콘퍼런스인 테크 올 핸즈에서는 실험을 통해 배운 lesson을 공유하는 분들이 나타나기 시작했습니다. 보험 스쿼드에서는 3분기 성과를 내야 하는 급박한 일정 속에서 여러 차례로 실험을 나눠 설계한 방법과 보험 상품 신청 클릭 수가 400% 증가한 성과를 공유해주었습니다. iOS 팀에서는 실험이 너무 어렵게 느껴지고 불필요하다고 여겨졌지만, 실제로 해보니 그렇지 않다며 본인이 쌓은 노하우를 공유하였습니다. 그리고 공통적으로 실험을 통해 얻은 결과를 자신감 있게 이야기하였습니다. 그 누구도 부정할 수 없는 정량적인 성과였기 때문입니다.

뱅크샐러드 각 조직의 성과/계획 발표 양식
Figure 17 | Alignment Day의 성과/계획 발표 양식

뱅크샐러드의 전 구성원이 모여 지난 분기 성과와 다음 분기 계획을 을 공유하는 Alignment Day도 실험 결과를 중심으로 진행되고 있습니다. 각 스쿼드, 조직에서의 성과를 실험의 결과로 정량적으로 증명할 수 있기 때문입니다. Alignment Day에서는 각 조직이 지난 분기 동안 어떤 실험을 진행했고, 성공한 실험에 대해선 성과를 발표하고, 실패한 실험은 lesson learned를 공유합니다. 이를 통해, 서로 다른 팀끼리 실험 사례와 결과를 공유하여 다음 분기 제품 전략에 활용하고 있습니다. 이제는 어느 한 팀, 조직에서만 실험을 하는 게 아니라 전사에서 실험을 기반으로 의사 결정 하는 단계로 나아가고 있습니다. 뱅크샐러드는 어느덧 진정한 실험 조직으로 거듭나고 있었습니다.


😄 마무리하며

뱅크샐러드의 실험 플랫폼이 갈 길은 아직 멀었습니다. 하루에 천 번 배포하며 천 번 모두 실험을 진행하는 조직이 되기 위해선 실험 인프라도 고도화되어야 하고, 더 성숙한 실험 문화로 발전시켜나가야 합니다. 그럼에도 오늘 이 글을 공유하게 된 배경은, 이제는 정말 실험을 통해 가설을 검증하고 데이터 기반으로 의사 결정 하는 조직으로 변모했기 때문입니다. 뱅크샐러드라는 제품이 마이 데이터 플랫폼을 지향하듯, 뱅크샐러드라는 조직은 끊임없이 실험하고 고객 임팩트를 좇아 성장하는 조직을 지향합니다. 이제는 그 방향으로 성큼성큼 달려 나가는 일만 남았습니다. 더 많은 분이 저희와 함께 실험하고 성장해나가길 고대합니다.


보다 빠르게 뱅크샐러드에 도달하는 방법 🚀

지원하기