by
Jun 02. 2019
스타트업에서 adhoc 분석 체계 만들기
firebase와 bigquery의 악몽을 회고하며
스타트업에서 데이터 다루는 일과 씨름하고 있습니다. 이 글은 다른 분들처럼 그간 쌓아온 인사이트를 알려드리는 글이라기 보다는 그 과정에서 고생하며 느낀 삽질기에 가깝습니다. 한 사람의 성장기라고 생각하시고 가볍게 봐주시면 감사하겠습니다.
들어가며
"스타트업에서 adhoc 분석 체계 만들기"라는 거창한 말을 썼지만, 사실상 지난 반년간의 업무에 대한 회고 글에 가까울 예정이다. 컨설팅에서 스타트업으로 자리를 옮긴 뒤 멋지게 화려한 머신러닝과 로그 데이터로 분석에 집중할 것이라고 상상하던 것이 무색할 정도로 다른 파트 팀원들의 데이터 요청을 들어주기 바빴다. 이번 글은 이들에 대한 회고이다.
adhoc 업무라고 하면 보통 IT 계열의 회사나 스타트업에서는 데이터추출 요청, 데이터분석 요청 정도로 통용된다. adhoc은 라틴어로 "특별한 목적을 위해서"라는 의미로 쓰이며 위키를 참고해보면
어떤 다른 목적에 적응시킬 수 없는 해결책
로도 쓰인다는 것을 알 수 있다. 특정 데이터 추출 솔루션(Google Analytics와 같은 분석툴)로 알 수 없는 질문들에 대한 대답을 데이터담당에게 요청한다는 맥락인 것이다.
이러한 분석들은 주로 SQL Query로 이루어진다. 위에서 언급했던 adhoc의 사례는 보통 일반직군 담당자들이 DB에 접근할 권한이 없거나 접근할 수 있더라도 쿼리를 작성하는 데에 어려움을 느끼는 경우가 많기 때문이다. 그래서 데이터 담당 혹은 데이터 분석가에게 담당 업무에 필요한 리서치를 위임하는 개념이다.
adhoc은 생각보다 어렵다.
SQL 좀 다룰줄 아는 사람이라면 사실 대부분의 질문에 대한 답을 찾는게 크게 어렵지 않다. 쿼리(Query)언어라는 것이 상대적으로 진입장벽도 낮은 편이고 (그렇다고 쉬운 언어라는 뜻은 절대절대 아니다) Syntax도 단순명료하기 때문이다.
하지만 adhoc 업무의 본질적인 어려움은 내가 생각한 질문에 대한 대답을 찾는게 아니라 남이 원하는 것이 무엇인지를 정확히 캐치해내야 한다는 부분에 있다. 데이터가 알고 싶은 영업팀 담당자는 도대체 어떻게 요청을 해야 원하는 데이터를 받을 수 있을지, 어디까지 알 수 있는 것인지에 대해 전혀 감이 없다. 요청을 받는 입장에서도 백그라운드 지식을 어디까지 설명해줘야 하는지, 이게 왜 오래 걸리는 작업인지 등에 대해 여러가지 고민이 생긴다.
혜민 스님도 그랬다. 내가 원해서 주도적으로 하는 일은 신나도 남이 주도하는 것에 질질 끌려가는 것은 고통이라고. 고통까지는 아니지만 분석하는, 데이터를 추출하는 입장에서의 adhoc이 딱 그렇다. 내가 생각하기에는 이쪽 데이터를 더 살펴봐야 할 것 같은데 자꾸만 이쪽으로 요청이 들어오면 별 수 없이 들어온 요청을 우선순위에 두고 내가 알고 싶은 것은 후순위로 밀릴 수 밖에 없다. 그러다보면 퇴근시간이 다가오고 내 호기심은 퇴근을 하고 싶은 욕구를 절대 이길 수 없기 때문에 그 다음날에 와서는 그 호기심은 벌써 떠나가버리는 상황이 반복되는 것이다.
다른 업무를 담당하는 사람들의 시선들도 심리적인 부담에 한 몫한다. 가장 대표적인 것은 "이게 이렇게 오래걸릴 일이야?" 와 같은 시선인데, 그들은 왜 지역별(읍면동까지 구분된) 가입 회원수를 추출하는 데에 시간이 오래걸리는지 이해하지 못한다. 중구가 서울에만 있는게 아니라 대구에도 있기 때문에 지역구분자를 세팅하는 작업을 알지 못하며, 우리 DB에 쌓여있는 주소 데이터는 구글신께서 외국인이라서 그런지 가끔씩 주시는 주소중에 영어 주소도 섞여있어서 이들을 정제해야 한다는 사실을 알지 못한다. (이 경우에도 사실 답은 없다 그냥 꾸역꾸역 해서 빨리 던질 수 밖에 없다.)
하지만 무엇보다 어려운건 바로 나 자신이다. 요청 하나를 처리하는 시간이 좀 오래걸린다 싶을 때 마다 불쑥불쑥 찾아오는 것은 스스로에 대한 의심이다. "내가 진짜 이걸 할 자격이 있나?"와 같은 것들이 나를 괴롭힌다. 이전 프로젝트 정황상 코드를 다루는 업무를 반년간 쉬었던 것도 한 몫할 것이다. 다시 자신감있게 다루기 시작했던 것은 입사 후 4개월 정도 즈음 어느정도 회사에 적응했을 때 였다. (불쑥불쑥 찾아오는 의심을 마주할 때도 역시 별 수 없다. 그저 꾸역꾸역할 수 밖에. 열심히 돈 벌어서 저녁에 치킨 먹어야 된다.)
Firebase는 데이터 파트에게는 불청객이다.
SQL과 우리 서비스의 DB 스키마에 어느정도 익숙해져서 컬럼이나 테이블명들을 거의 다 외워서 업무를 진행할 무렵에 서비스를 AWS에서 Firebase로 이전한다는 결정이 있었다. 워낙 소규모로 운영되는 팀이다보니 백엔드 리소스를 최소화하기 위해서 서버리스 체계를 가능하게 해주는 구글신의 Firebase를 쓰자는 것이 도입 배경이었다. (이 때 말렸어야 했다. 물론 내가 말린다고 말려지지 않았을 것을 알고 있다.)
구글의 신기술이라는 달콤한 속삭임에 넘어가 와 그러면 우리도 어서 구글의 최신 기술을 경험해봐요라고 했던 과거의 나를 후회한다. (하지만 그간 SNS를 통해 빅쿼리의 존재를 많이 들어왔기 때문에 사실 한번 써보고 싶었던 것도 사실이다. 지금와서 비유해보자면 mysql이 소나타라면 빅쿼리는 한 다마스쯤 되는 것 같다.)
빅쿼리의 경우 Legacy SQL과 Standard SQL을 지원하는데 대부분은 StandardSQL을 쓴다. 아주 초기의 SQL 버전정도로 이해하면 편한데, 이들을 쓰다보니 우리가 쓰는 mysql 혹은 oracle SQL 등은 자동화가 많이 되어있구나 하는 것을 느낄 수 있었다. 가령, 시간관련 rawdata에서 일자 혹은 월별로 추출을 하려 할 때 쓰게되는 substr의 경우 mysql 환경에서는 datetime 자료형에 substr을 써도 무방했지만, 빅쿼리 환경 하에서는 datetime을 string으로 cast 해주지 않으면 자동으로 형변환이 이루어지지 않는다. 그리고 데이터가 저장된 리전이 있는 국가의 시간대로 저장되기 때문에 GMT 시간에 대한 리전별 시간조정하는 연산도 수행해줘야 한다.
무엇보다 작업을 어렵게 했던 것은 서비스 개발이 처음부터 Firebase 환경이 아닌 AWS에서 점진적으로 데이터를 이전하는 방식으로 작업이 이루어지다보니 분석 차원에서는 작업의 어려움이 커졌는데, 회원정보는 AWS에 있고 그 이의 모든 정보는 Firebase의 NoSQL 서버에 저장되어 있기 때문에 두 정보간의 Join이 필요한 경우에는 그 많은 데이터를 csv로 내려서 로컬 상에서 R studio로 불러와서 작업하는 웃지못할 작업 환경이 구축된 것이다. 이 과정에서 나름대로 파일명을 통해 버전관리에 힘써본다고 힘써봤지만 제목 오입력으로 제목과 파일 내의 데이터가 불일치하는 아주 위험한 환경이 되어버린 것이다.
일단은 Jupyter다.
위와 같이 데이터를 내려받은 뒤에 관리하는 것은 여러가지 이유에서 안전하지 못하다는 생각이 들어 방법을 이리저리 찾아봤었는데 아무래도 Jupyter 환경 하에서 AWS RDS 서버와 Bigquery 서버를 연동하여 노트북환경하에서 쿼리를 작동하는 것이 그나마 가장 통합된 환경을 제공하지 않나 싶다. AWS 계열의 경우 기존의 sqlalchemy 라이브러리 설치만 해주면 손 쉽게 연동해서 쓸 수 있고 빅쿼리역시 구글 다큐먼트를 참고하면 몇 번의 에러를 거치면 연동이 어렵지 않게 가능하다.
Jupyter는 여러 언어로 사용할 수 있지만 그 중에서도 Python에 꽤 특화되어있는 것 같은데 Pandas 라이브러리의 DataFrame은 데이터정제를 쉽게 할 수 있도록 도와준다. R에 익숙한 사람이라면 보다 빠르게 사용법을 익힐 수 있을 것 같은데, 데이터 핸들링하는 방법이 R의 데이터타입인 Dataframe과 거의 똑같기 때문이다. 다만 컬럼을 추가하는 방식이라던지, 특정 조건 하의 컬럼 값을 갱신한다던지 하는 것들은 조금 구글링을 해서 익숙해져야 하는 부분인 것 같다.
아무래도 데이터가 클 수록 기존 RDB 방식에서 돌아가는 경우는 거의 없다고 봐야할 것 같다. NoSQL 형식의 데이터 환경 하에서 adhoc을 처리하는 방법은 지속적으로 관심을 두고 어떻게 하면 요청접수 시점과 결과전달 간의 시차를 줄일 수 있을지 해결하는 키가 아닐까 싶다.
끝
인프런에서 SQL강의를 진행하고 있습니다. 글을 재미있게 읽으셨다면 아래 링크에도 한번 오셔서 SQL 강의를 확인해보세요. 저에게 큰 힘이 됩니다. 강의 구경하러가기
