숫자로 이야기하는 회의를 위해 개발자가 할 수 있는 일
SQL 사내교육, Zeppelin 구축, 그리고 실제 DB에 적용하기
많은 스타트업이 그렇듯, 저희 팀 역시 늘 결정의 기로에 섭니다. 버튼 위치부터 KPI 설정까지 잠깐, 길게, 앉아서, 서서, 밥먹다가, 양치하다가 이야기가 끊이질 않는데요. 서로를 설득하는 지난한 과정을 거치며, 객관적인 지표로 이야기하면 더 정확하고 빠르게 논의를 마칠 수 있지 않을까 생각했습니다.
데이터도 감이 있어야
의사 결정의 근거가 필요할 때면 백엔드 개발자인 제가 주로 데이터를 가공하여 공유하지만, 사실 데이터에 대한 감각은 가장 떨어진다고 느꼈습니다. 같은 데이터를 봐도, 기획팀이나 운영팀이 뽑아내는 인사이트가 더 근사했기 때문입니다. 제가 데이터 엄청나게 돌려서 결과를 짜잔 가져갔는데, 이미 다 알고 계시더라고요.
그 후로도 제가 전혀 생각지 못한 가설을 운영팀에서 세우는 걸 여러번 겪었어요. 곧 DB에 가까운 사람보다 유저에 가까운 사람이 데이터를 봐야한다는 확신이 들었습니다. 이 글은 지난 3개월 간 그 확신을 실행에 옮긴 이야기입니다.
DB 공유의 장애물
DB에 대한 접근권을 비개발팀에게 공유하기 위해 세가지를 해결해야 했습니다. 비개발팀에서 데이터 분석을 위해 SQL을 학습하는 일, 데이터 분석을 위한 툴을 구축하는 일, 그리고 실제 서비스에 영향이 가지 않는 DB 접근 방식을 찾는 일이었습니다.
1) 겁먹지 말아요 SQL
먼저 매주 2시간 씩 5주 동안 기획팀과 운영팀을 대상으로 SQL 사내교육을 실시했습니다. 테이블 생성, 데이터 추가 및 수정과 같은 부분은 모두 제외하고, 철저히 데이터를 추출하는 문법에 집중했습니다.
1주차부터 실제 상용 DB의 스냅샷으로 복사본을 띄우고 Sequel Pro를 이용해 접속했습니다. 매 세션 이후에는 실제 데이터에 대한 과제를 내드리고, 그 다음 세션에 같이 풀어봤어요. 예를 들면 지난주 가입자가 몇명이었는지, 가입한 사람들이 올린 이미지는 몇장이나 되는지 같은 것들이었습니다.
1주차: SQL 문법 I (select, from, where, limit, order by, and, or, not)
2주차: SQL 문법 II (join, group by, having, count, sum)
3주차: DB 구조 분석
- 실제 DB에서 기획팀과 운영팀에서 궁금해할 데이터가 어디에 위치하고 있는지 설명했습니다.
4주차: 기본 통계 분석
- 매주 팀에 공유되는 기본적인 통계들을 직접 뽑아보고, 개발자들이 작성해둔 쿼리를 읽고 어떤 데이터를 뽑는지 분석했습니다.
5주차: 가설 증명
- 기획팀이나 운영팀에서 어떤 프로젝트를 시작하기 전에 정말 필요한 조치인지, 그리고 사후에 실제로 효과가 있었는지를 함께 분석했습니다.
특히 5주차에는 증명하고 싶은 가설이 있는지 여쭤봤는데, 화면 상단에 노출되었을 때 판매가 얼마나 증가하는지 보고 싶다고 하셨어요. 동일 상품에 대해 노출 기간 중 매출과 그 외 기간의 매출을 비교해 약 17배 가까운 차이가 있음을 확인했습니다. 역시 데이터 패턴에 대한 감각이 좋으시더라고요.
2) Apache Zeppelin으로 시너지 내기
SQL 사내교육 때부터 Apache Zeppelin(이하 Zeppelin)을 활용하기 시작했습니다. 도입한 이유는 세 가지 정도가 있었는데요.
- 쿼리의 재활용
자주 보게 되는 주요 지표들 (가입자, 소셜 액션, 판매액 등)은 같은 쿼리에 날짜만 수정해서 씁니다. 그래서 다음과 같이 변수로 지정해두고 확인하면 반복적인 업무를 줄였습니다.
2. 같은 데이터에 대한 다각화된 관점의 축적
최근 장바구니 기능을 개발하게 되면서 매출 쪽 지표들을 다시 살펴보았습니다. 그 지표들을 조합하다가 1분 내에 반복적으로 구매해야해서 불편했던 유저가 얼마나 될지를 개선해야할 지표로 삼았습니다. 쿼리를 남기면 같은 데이터셋에 대한 여러 분석방식이 쌓이기 때문에, 다각화된 관점이 함께 쌓입니다.
3.시각화
Jupyter Notebook 등 다양한 노트북 제품 중 Zeppelin을 선택한 이유는 시각화때문이었습니다. 간단한 차트로 데이터들의 흐름을 빠르게 파악할 수 있습니다.
노트북에 쿼리를 저장하면 분석한 관점이 쌓이고 노하우가 쌓입니다. 분석 과정을 공유해 서로에게 배우는 일은 더 큰 시너지를 일으킬 거에요.
3) 최종 빌런: 실제 DB에 적용하기
- Snapshot을 이용한 DB 복사본 접근
상용화 단계에서는 어떻게 하면 서비스에 영향이 가지 않는, 안정적인 접근을 열 수 있을지가 가장 중요했습니다. 처음에는 읽기 전용으로 계정을 분리하는 방법을 고려했는데, 복잡한 쿼리가 실행되어 서비스가 느려지는 경우를 막을 수는 없었습니다. 그래서 Snapshot을 이용해 Zeppelin이 복사본에 접근하도록 구현했습니다. 복사본이니 수정하거나 삭제하거나 익혀먹거나 서비스엔 아무 영향도 없습니다.
복사본 역시 실제 데이터로 민감한 부분들이 있습니다. 보안 그룹을 지정하여 사무실 밖에서는 접근할 수 없게 막아두고, Zeppelin에 계정을 생성해 로그인을 필수로 지정했습니다.
2. DB 복사본 생성 자동화
Snapshot을 통해 복사본을 생성하고 Zeppelin 인스턴스를 구동하는 일이 반복적이었기 때문에, AWS Lambda(이하 Lambda)를 활용해 자동화했습니다.
3. 출근 시 서버를 구축하고 퇴근 시 해체하도록 스케줄링하여 비용 절감
데이터분석을 위해 추가적인 서버 스택을 운용하게 되었기 때문에 비용의 부담이 있었습니다. 해당 스택을 합리적인 수준에서 사용하기 위해서 출퇴근 시간에 맞춰 켜고 끌 수 있게 Cloudwatch와 Lambda를 연결했습니다. 상시 구동하는 것에 비해 25% 이하의 비용으로 운용할 수 있습니다.
매번 서버가 새로 구축되며 도메인이 바뀌기 때문에 그 주소를 공유하기 위해텔레그램봇을 이용했습니다.
마지막으로 퇴근 시간에는 DB 복사본을 삭제하고 Zeppelin 인스턴스는 종료합니다.
이런 걸 한 번 기대해봅니다
- 변화에 대한 빠른 파악
스냅샷을 구동하기 때문에 실시간은 아니지만 데이터에 대한 접근은 훨씬 용이해졌습니다. 변화하는 데이터를 더욱 능동적으로 감지할 수 있습니다. 개발자 이외에도 모두가 자주 들여다보고 변화에 더 기민하게 반응할 수 있게 될거에요.
2. 문제 해결의 과정 공유
OGQ는 같은 미션 아래 디지털 에셋을 판매하는 프로덕트를 여럿 개발하고 있습니다. 각기 다른 팀이 유사한 문제를 반복적으로 부딪힐 확률이 높죠. 어떻게 데이터를 분석했고 어떤 실행을 했는지 축적하면, 전사적으로 노하우가 쌓일 것입니다.
3. 데이터에 기반한 의사결정
팀에서 거의 모든 것을 결정하고 있기 때문에 굵직한 결정사항이 많습니다. 경험과 감각이 옳을 때도 있지만, 객관적인 커뮤니케이션에 데이터는 필수입니다. 왜 이 일을 해야하는지, 어떤 지표로 우리의 성과를 측정할지, 그리고 지금 우리가 잘하고 있는지 모두 데이터로 이야기할 수 있습니다. 연차, 직급, 직무 불문하고 가장 공정한 잣대입니다.
SQL 사내교육에 참여했던 한 기획자는 최근 DB에서 데이터를 가공하여 새로운 기능 추가의 근거를 마련했습니다. 일하면서 배우는 것보다 빠른 학습은 없다고 느낍니다. 실무에서 SQL과 데이터 분석이 차차 더 많이 등장하기를 바래봅니다.
