'이건 어찌 보면 당연한 말이잖아.' '그래서 결국 결론이 뭐지'

꼼꼼하게 기록한 로그 문서도, 긴 고민 끝에 분석하고 정리한 결과도 시간을 두고 다시 읽어보면 그렇게 시간과 노력을 오래 들인 만큼 의미 있는 내용이었나, 확신이 들지 않았다. 그렇다고 잘 아는 척하며 어물쩍 넘어가는 사람이 되고 싶지도 않았다. '이건 내가 해봐서 아는데~ 이건 당연히 ~ 예요' 같은 말을 하는 나 자신을 도저히 용납할 수 없었다. 그건 정말이지 내가 가장 되고 싶지 않은 종류의 모습이었다.

계절이 바뀌고 오랫동안 방치된 방구석 청소를 시작하듯, 글또를 시작하면서 비로소 케케묵은 고민들을 펼쳐놓고 정리란 것을 시작했다.

글또 10기에 작성한 글

1. 글또 10기를 시작하며

2. 대시보드는 언제 필요할까

3. 실수의 재구성

4. 모듈 로깅하기

5. 태블로, LOOKUP 함수의 쓸모

지금 글을 포함하면 총 12회 중 6개.. 글을 작성했다. 일주일 전에 무슨 일이 일어났는지도 솔직히 가물가물한데, 한동안 머릿속에 둥둥 떠다녔던 고민이 휘발되지 않고 기록으로 남게 되어 다행이다. 한번 기록으로 정리하고 나니까 누군가에게 고민을 이야기하며 조언을 구할 때 조금 더 정돈되고 체계적인 방식으로(?) 질문할 수 있다는 장점도 있었다.

그렇지만 개인적으로 아쉬운 점도 많다. 우선 커피챗이나 오프라인 행사에 적극적으로 참여하지 못한 것이 아쉽다. (이번에 글또 슬랙에 자주 안 들어가는 바람에 오프라인 행사를 대부분 놓쳤다) 전체 회차 중 절반만 제출했기 때문에 지속성 측면에서 아쉽고, 카테고리를 골고루 작성하지 못했으며, 특히나 공부하고 새로 배운 내용을 정리하는 글은 거의 작성하지 못했다. 최근 6개월 동안 내가 그다지 성장했다는 느낌이 들지 않아서 후회된다.

앞으로

그럼 글또를 마무리하며 나는 어떤 방향의 성장을 추구하나? 를 고민해 보았다. 만약 이 질문에 대한 답을 할 수 없다면, 나는 그저 '저 사람보다 잘해야지' 하고 남과 나를 끊임없이 비교하는 방식으로만 나아가는 인생을 보낼 것 같았기 때문이다.

나는 하나의 정답을 찾기보단, 여러 방법의 장단점을 알아가고 상황에 따라 다른 선택할 줄 아는 사람이 되고 싶다. 조금 추상적인 목표일 수 있지만 블로그에 쓴 글로 예를 들면, 나는 시간이 지나 내가 쓴 글의 내용을 엎는 또 다른 글을 작성해 보고 싶다. 글또에서 작성한 글 역시 내가 한동안 깊게 고민하며 정리한 결론들이지만, 시간이 지나 경험의 폭이 넓어지고 지금과 또 다른 견해를 가지게 될 수도 있다.

나는 내가 썼던 글을 다시 읽었을 때 '그래 이거야'하고 만족하는 순간보다, 나의 주장에서 구린 점을 발견하고 새로운 견해로 업데이트하는 과정에서 큰 재미를 느낀다는 것을 알게 되었다. 과거 주장을 번복하려면 일단 당시 생각을 정리해 놓은 무언가가 있어야 하는데 만약 글또가 없었더라면 이런 글을 작성하지 못했을 것이다. 그래서 글또에 신청하길 정말 잘한 것 같고, 출석률이 높지 않지만 그래도 완주해서 다행이라는 생각이 든다.

대시보드에 숫자가 굉장히 많을 때, 이런 설명이 함께 있으면 이해에 도움이 되는 것 같다.

• 전월 동기간 대비 n% 증가
• 이번달 목표 대비 m% 달성
• 전체 가입자수 대비 n% 달성

이중 "전월 동기간 대비 n%" 를 표시하고 싶을 때 가장 단순한 방법은 태블로로 추출할 마트 테이블에 컬럼을 추가하는 것이다. 예를 들면 LAG 함수를 써서 지난달에 해당하는 값을 row마다 가져오는 방식이다.

하지만 한창 대시보드를 만들고 있다가 뒤늦게 지표를 추가하려고 하면, 마트를 다시 만들어야하는 과정이 매우 번거롭다. 이때 태블로에서 사용 가능한 LOOKUP 함수를 알게되어 사용법을 정리해보았다.

데이터는 태블로 클라우드의 기본 데이터 Superstore Datasource를 이용했다.

2. 필요한 것은?

• 기준일자를 조정하면서
• 지난주 같은 요일 대비 증감을 확인하고 싶다.
• (디자인도 개선이 필요하지만 일단 이건 패스..)

2.1 매개변수 만들기

최신 데이터만 보여주지 않고, 기준일자를 조정하는 리모컨을 만들고 싶다면 매개변수를 만들면 된다.

좌측 상단 메뉴에서 매개변수 만들기를 누르고, 데이터 유형 및 기본값을 정의한다. 태블로 데스크탑 유료 제품에선 통합 문서가 열릴 때의 값을 max_date (추출된 데이터중 가장 최근값)으로 지정 가능한 것 같은데 여긴 클라우드라서 안 되는 것인지? 아니면 데이터 자체가 추출방식으로 가져오는 것이 아니라서 그런 것인지 잘 모르겠다.

그리고 매개변수 이하 날짜들만 보여줄 것이므로 새로 boolean 변수를 생성한다.

• order date가 기준일자 이하면 참, 초과하면 거짓

그리고 필터에 추가하여 "참"일 때만 보여준다. "매개변수 표시"한 다음, 매개변수(target date)의 날짜를 조정하면 해당 날짜까지의 데이터만 노출된다.

2.2 지난주 대비 변화

기준일자 or 기준일자 - 7days 일자만 필터에서 변화를 표현하고 싶다. 이것도 boolean으로 정의한다.

함수 사용법이 헷갈릴 땐 오른쪽 함수 검색을 사용한다.

방금 정의한 boolean 변수와 Order Date를 같이 행에 올린 다음, 측정값(Quantity)는 셀에 올린다.

{기준일자}와 {기준일자 일주일 전} 데이터만 나타난 것을 확인할 수 있다.

이제 변화한 양을 계산할 것인데

• LOOKUP : 한 단계 다음 값을 가져옴. 쿼리에서 LEAD 함수와 유사하다. (그림처럼 offset이 음수라면? LAG 함수처럼 이전 단계 값을 가져온다.)
• ZN : if x is null then 0 else x (NULL 대신 0을 반환하는 함수)

여기서 주의할 점은 LOOKUP 함수는 입력값이 반드시 집계치여야한다는 것이다. (x 가 아니고 SUM(x) 여야함)

이 데이터의 경우 date 일자별로 quantity 값이 중복은 아니기에 SUM 함수를 씌워도 무방하다. (SUM을 씌울 때는 항상 row 가 중복이 아닌지 체크)

2.3 레이블 편집

만약 증가했다면 빨간색으로, 감소했다면 파란색으로 색상을 표시하고 싶다면 변수를 추가로 정의한다.

• amount_change_plus : if amount change >= 0 then amount change end
• amount_change_minus : if amount change < 0 then amount change end

그리고 이렇게 레이블 편집을 하면, 양수라면 빨간색으로 음수라면 파란색으로 표시가 될 것이다

.. 라고 적어놓고 보니 다른 대안은 정말 없는 것일까..? ㅎㅎ

사용자 서식으로 기호도 추가 가능하다. 자세히 알아보기를 눌러서 태블로 문서를 읽어보니, 구문은 세미콜론으로 구분하며 차례대로 양수, 음수, 0 이렇게 세 부분으로 구성된다고 한다.

그리고 이제 기준일자만 표시하기 위해 지난주에 해당하는 날짜는 "숨기기" 처리를 해준다.

참고로 '제외', '이 항목만 유지' 는 필터 조정 기능이다. 그래서 '제외'를 사용하면 지난주 수치가 필터로 제외되기 때문에 LOOKUP 함수가 제대로 작동하지 않는다.

그런데.. 여기까지 진행한 다음, 매개변수로 날짜를 또 다른 값으로 조정하면 지난주 값이 숨겨지지 않고 다시 화면에 나타나는 (?) 현상을 겪게 될 것이다.

방금 "지난주 날짜"를 숨기지 않고 특정 일자 셀(2024.08.26)을 숨겼기 때문이다.

특정 날짜를 숨기는 대신 "지난주" 값을 숨기려면, boolean 값으로 target_date 인지 여부를 새로 정의한다.

그 다음 boolean 값이 target_date 가 아닐 때 "숨기기"를 적용한다.

이제 매개변수를 조정할 때마다 기준일자의 Quantity와 지난주 같은 요일 대비 증감이 변화하는 것을 확인할 수 있다.

3. 마무리하며

시각화 관점에서 파이썬과 태블로를 난이도로 비교하면, 나에겐 태블로가 더 어렵고 구글링 자체도 쉽지 않은 것 같다. 태블로의 기본 용어가 익숙하지 않은 상태이다보니, 구글 검색보다는 chat gpt에게 물어보는 것이 좀 더 의도한 답변을 얻는 경우가 많았다.

오히려 누군가가 만든 대시보드를 로컬에 다운 받아 변수 생성과 세팅을 그대로 따라하는 것도 괜찮은 방법 같다. LOOKUP 함수도 누군가의 태블로의 대시보드를 뜯어보다가 알게 되었다. 깨달음을 주신 귀인들에게 감사함을 느끼며 이 글을 바친다..

모듈이란? 여러 종류의 서비스를 만들다보면 제품마다 공통적으로 필요한 기능들이 있다.

이런 기능의 동작을 일관된 경험으로 제공하도록 모듈을 만든다면? 제품팀에서는 플랫폼팀에서 이미 만들어놓은 모듈을 적용함으로써 적은 비용으로 안정적인 제품을 만들 수 있다. 유저 입장에서는 여러 서비스를 사용하더라도 동일한 모듈을 만나게 될테니 일관된 경험을 할 수 있다.

이렇듯 모듈은 장점이 많으니 무엇이든지 모듈화면 좋을 것 같지만, 플랫폼 팀 입장에서는 여러 고민이 든다. 안정적이고 일관된 제품을 만들기 위해서 정책은 어떻게 단순화하면 좋을까? 어디까지 커스텀을 허용할까? (A팀의 요구사항이 앞으로 다른 팀에서도 필요할까?) 등등..

앱로그를 정의하는 입장에서도 어디까지 로그를 남길 것인지, 이후 로그 관리는 어떻게 해야할지 고민이 되었다. 오늘은 모듈 데이터를 분석하는 상황을 가정하고 어떤 점을 고민하며 모듈 앱로그를 정의하고 관리했는지 정리했다.

식별 key 값 정의하기

모듈은 여러 제품에서 사용한다. 그래서 특정 서비스 A의 모듈 데이터를 보고 싶다면, 모듈이 사용된 위치를 식별하기 위한 id 값을 꼭 남겨야한다.

우선 서비스와 모듈 관계가 1:1 인지 확인한다. 만약 서비스마다 모듈이 최대 1개만 노출된다면 service_id (서비스 식별값)을 key 로 남길 수 있을 것이다.

하지만 하나의 서비스에서 여러 위치에서 모듈을 노출시키는 경우도 많다. 이런 경우 모듈을 식별할 값을 새로 정의한다. 서버 개발자와 논의하여 제품에서 사용하는 key 값을 앱로그에도 동일하게 사용하면 좋다. 되도록이면 서버 개발자가 생성한 디멘젼 테이블의 값을 그대로 사용하면 가장 좋다. 앱로그와 테이블을 동일한 key 값으로 바로 join 해서 볼 수 있어 활용하기 좋고 추후 값을 관리하기도 좋기 때문이다.

플랫폼마다 로그가 동일한 방식으로 남는가

모듈에서 제공하는 플랫폼은 크게 3가지가 있었다. 안드로이드 화면, iOS 화면, Web 화면.

앱로그를 사용하는 사람이 누굴까? 제품팀 사람들이다. 그들은 제품을 출시후 데이터 빠르게 확인해서 제품 개선 지점을 파악하려고 한다. 그리고 모듈은 그 퍼널중 일부분이다. 그런데 모듈 앱로그가 플랫폼마다 다르게 남는다면 데이터를 조회하고 분석하는 과정에 비효율을 초래할 것이다. 그래서 '플랫폼마다 동일한 방식으로 로그가 남는가'를 중요하게 생각하고 모든 플랫폼마다 로그 QA를 진행했다.

물론 100% 동일하게 남지는 않는다. 예를 들어 이탈 동작 로그가 다를 수 있다. 안드로이드는 우측 하단에 백버튼이 있고, iOS는 백스와이프로 이탈할 수 있는 등 이탈 방식 자체가 달라서 어쩔 수 없는 부분도 있다. 하지만 퍼널 전환율에 사용되는 로그만큼은 동일한 방식으로 남도록 관리했다.

로그 이슈 재발 방지를 위해 모니터링

모듈은 로그 QA를 완료했더라도 코드 리팩토링 과정이나 특정 서비스 환경에서 언제든지 이슈가 발생 가능하다.

모듈 제품을 출시 후 여러 팀으로부터 로그 이슈를 제보받았다. 초기에는 이슈 로그를 대체해서 볼 수 있는 방법을 제공하는 등 일회성 대응에 머물렀다. 하지만 시간이 지나고 보니 반복되는 이슈들이 몇 가지 있었다. 이런 중요 로그 이슈를 감지하는 슬랙봇 얼럿을 만들어 모니터링을 구축하기 시작했다. 이로인해 적어도 동일한 이슈가 재발할 때 바로 개발자분들과 확인하여 문제를 신속하게 해결할 수 있게 되었다.

마무리하며

모듈 로그가 없던 시절과 대비해서 지금 가능해진 것은?

• 사용자가 모듈에서 어떤 문구를 보고, 그중 어떤 버튼을 클릭했는지, 어떤 방식으로 이탈했는지 등등 퍼널 전환율을 볼 때 중요한 로그들은 일관된 기준으로 자동으로 남게 되었다.
• 특정 위치에 뜨는 모듈의 지표를 확인하고 싶을 때 표준화된 key 값으로 데이터를 조회 가능해졌다.
• 서비스가 달라도, 플랫폼이 달라도(Android, iOS, web) 로그가 동일한 방식으로 남게되었다.
• 개별 제품팀에 속한 데이터 직군의 로그 QA시간이 줄어들었다.

다음 글에서는 모듈 앱로그를 마트화하고 대시보드를 만들어 제품팀에 공유하는 과정에서 들었던 고민을 정리해보겠다.

사건 요약

• 퍼널 전환율 개선을 위해 실험을 오픈했고, 나는 로그 정의와 실험 집계를 맡았다.
• 사용자가 시도를 할 때마다 발번되는 session id 값이 있었다. 이것을 기준으로 처음과 끝을 left join하여 전환율을 구했다.
• 그런데 알고 보니.. 중간 단계에서 session id값이 재발급되는 로직이 있었다. 한번 생성된 값이 그대로 유지된다고 인지하고 있었기 때문에 실험 결과 지표가 과소집계되고 있었다.
• 실험 종료를 앞둔 시점에 분석 결과를 개발자와 DA에게 공유하며 같이 결과를 해석하는 과정에서 이 사실을 발견했다.

무엇을 놓쳤나

쿼리 검증을 여러번 했다면 이 실수를 좀더 빨리 발견할 수 있었을까? 그럴 확률은 매우 희박해보였다. 다시 이런 실수를 반복하지 않기 위해 무엇을 바로잡아야할까 고민하던중.. 마침 읽고 있던 책인 <유시만의 글쓰기 특강>에서 내 생황에 일대일로 대응되는(?) 부분을 발견했다.

아래는 "주장은 반드시 논증하라" 챕터에서 발췌하고 내가 겪은 상황을 적용해본 글이다.

*가설은 반드시 논증되어야한다. *

• 논증하려면 근거나 이유를 밝혀야한다. 먼저 기준이 되는 지표를 제시한다. 정한 지표 기반으로 데이터를 요약함으로써 가설을 증명한다.

  • 이럴 경우 다른 사람은 그 가설에 동의할 수도 있고 반박할 수도 있다. 가장 손쉬운 방법은 지표에 이의를 제기하고 다른 지표를 제안하는 것이다. 지표는 받아들이면서 다른 근거로 반박할 수도 있다. 예컨대 기존에 A라는 전환율이 70% 라는 것을 알고 있는데, 실험 결과를 계산해보니 A의 전환율이 50%였다면, 집계 과정의 오류를 의심하거나 표본이 대표성을 띄지 못한다고 이의를 제기할 수 있는 것이다.

이렇듯 주장을 하기 위해서는 가설과 논증의 과정을 반복하는 과정이 꼭 필요하다. 이 과정을 혼자 진행하면 객관성이 떨어질 수 있고 분명 한계가 있기 때문에, 다른 사람에게 검증을 요청하는 것도 좋은 방법이다. 처음에 미리 구상해놓은 큰그림에 데이터를 이리저리 끼워맞추는 일만큼은 절대 하면 안 된다. 논증하지 않은 가설은 일종의 취향에 불과하다.

그래서 실험 오픈을 위해 해야할 것

실험 오픈전 해야할 일

• 1) 로그 정의, 로그 QA하기
• 2) 어떤 지표로 위너 선정할지 핵심 지표 정하기
• 3) 실험과 상관 없이 변동이 생기면 안 되는 가드레일 지표 정하기
• 4) 핵심 지표와 가드레일 지표가 기존에는 어느정도 수준인지 확인하기

이번에 놓쳤던 부분이 4번이다. 이번에는 실험에 편입된 기존안과 실험안의 전환율만 비교했다. 평소에 이 전환율이 어느 정도라는 것을 실험 오픈 전에 알고 있었다면, 실험 결과에서 기존안의 전환율이 유독 낮은 이유를 이상하다고 생각했을 것이고 좀 더 빠르게 집계 오류를 찾을 수 있었을 것이다.

평소에 이 지표를 대시보드로 모니터링하고 있었다면 바로 확인 가능할 것이고, 그렇지 않다면 실험 오픈 전에 기존 지표가 어느정도인지 미리 집계해서 확인해야한다. 실험 기간을 산정하기 위해 대략적으로 계산하는 것이 아니라, 세부 조건까지 확인해서 정확하게 확인해야한다. (e.g. OS간 차이가 있지는 않은지, 실험 대상 한정하기 위해 분모의 조건을 더 세밀하게 정의할 필요는 없는지)

실험 오픈 후 1~2일 후 해야할 일

• 1) 기존안과 실험안 로그가 기대했던 대로 남는가 (e.g. 실험안 로그가 기존안에도 남고 있지는 않은가)
• 2) 실험 오픈전에 집계했던 수치와, 실험 오픈 후 기존안의 수치가 어느정도 비슷한가
• 3) 실험 세팅이 잘 되어 있는가 (e.g. 실험 타겟 설정)
• 4) 집계 쿼리 로직이 정확한가

당연한 것 아냐? 라고 생각했던 투두리스트지만, 뼈아프게도 내가 한번씩 실수해본 경험이 있는 항목들이다.. 일련의 크고 작은 경험들로 인해 나는 더이상 나를 믿지 않기로 했다..! 적어도 지금까지 한 실수는 다시 반복하지 않도록 당분간 이 점검 리스트를 실험 오픈할 때마다 캘박해놓고 습관으로 만들어야겠다.

대시보드는 날마다 숫자가 자동으로 업데이트되는 편리한 도구다. 배포 이후 사용자가 제품을 잘 사용하고 있는지 보기 위해, 우리 팀이 목표한 지표를 현재 어느 정도 달성했는지 확인하고 싶어서, 그리고 주기적으로 추출하고 확인해야할 대상이 있을 때 등등.. 다양한 배경으로 대시보드를 요청받는다.

그러나 시간이 지나, '이 대시보드가 필요했었나?'라고 질문해 보면 모든 순간이 꼭 그렇지는 않았다. 만들어놓고 나만 보는 대시보드도 있고, 관리를 해주지 않아 신뢰를 잃어버리고 잊히는 대시보드도 있다.

그런데 대시보드 하나 만들기 위해서는 수많은 시간이 들어간다. 앱로그가 잘 들어오는지 로그 qa를 하고, 예상과 다르게 들어오는 데이터를 발견하면 이유를 찾기 위해 하나하나 까보기도 하고, 전반적으로 데이터 정합성이 의심되는 경우 앱로그와 서버테이블을 대조하여 검증하기도 하며, 대시보드를 그리다가 테이블 구조의 변경이 필요해서 마트 한판을 다시 만들어야 할 때도 있다. 그리고 대부분 이러한 작업이 or 조건이 아니라 and 조건으로 필요하다.

대시보드는 제작 목적이 명확해야한다, 가 머리로는 이해되지만 여전히 새로운 대시보드 요청을 받는 순간 고민이 든다. '주기적으로 모니터링할 만큼 중요한 지표일까?'를 판단하기 위한 근거가 마땅히 떠오르지 않기 때문이다. 그래서 요즘은 일단 요청을 받은 대로 대시보드를 만들어보고, 어떤 지표가 문제 상황마다 잘 사용되는지 혹은 시간이 지나 아무도 궁금해하지 않는지 메모해 보기로 했다.

대시보드도 제품인가?

내 생각에는 SSAP 그렇다. 이 제품의 사용자는 내 동료들이고, 대시보드로 시각화하고자 하는 문제 상황에 대해 나보다 더 깊게 고민해 봤을 확률이 높다. 최근에 팀원들로부터 받은 피드백을 토대로 대시보드를 업데이트할 기회가 있었는데, 이때 질문받은 내용과 몇 가지 개선했던 것들을 정리했다.

1. 여기서 무엇을 봐야하나요

처음에는 사람들이 대시보드를 어떻게 사용할지 상상했다. 앞으로 제품을 여러 차례 개선하게 될 텐데, 액션 전후로 무엇이 달라졌는지 다각도로 살펴볼 수 있어야 하지 않을까? 그래서 '뭘 좋아할지 몰라 다 준비'했다. 주요 클릭율과 전환율을 리스트업하고 대시보드에 꽉 차게 배치했다. 하지만 팀원들에게 초안을 공유했을 때 돌아오는 반응은 예상과 달랐다. '무엇을 봐야 하는지 헷갈린다'는 의견이 대다수였다.

여러 지표를 그려야 했기 때문에 초안을 만들기까지 이미 시간도 오래 걸린 상황이었다. 피드백을 듣고 다시 대시보드를 들여다보니 팀원의 말에 공감이 갔다. 무엇이 가장 중요한지 눈에 들어오지 않았고, 지표가 많아서 어느 순서대로 봐야 할지 전반적으로 헷갈렸다. 만일 회의 중에 A를 확인하기 위해 대시보드를 열어본 상황을 가정했을 때, 'A를 어떻게 봐야하지..' 두 눈이 흔들리고 길을 잃어버리는 혼돈의 상황이 상상되었다.

그래서 참고용 지표는 상세 대시보드로 빼고, 일별로 변동이 크지 않은 수치는 아예 제외했다. 최근 회의 시간을 떠올리며 자주 소비된 지표만 메인 대시보드에 남겨두었다. 그리고 개선된 대시보드를 팀원들에게 공유하며 최근에 진행한 액션을 예로 들어 A 지표가 이전과 대비해서 몇 퍼센트 개선된 것인지 함께 설명했다.

전환율 A가 20%p 개선되었는데, 이는 매일 서비스에 진입하는 사람이 10만 명이라고 가정할 때 매일 전환되는 사람이 2만 명 늘어나는 효과예요.

중요하지 않은 지표는 제외하고, 메인 지표를 위주로 공유했을 때 팀원들이 더 잘 이해한다는 느낌을 받았다. (=후속 질문을 더 많이 받았다)

이렇게 핵심 지표로 요약하는 방식은 여러 액션의 성과를 비교하기에도 좋았다. 매번 새로운 지표로 성과를 측정하는 것이 아니라, 일관성 있는 뷰로 바라볼 때 '우리 팀의 방향은 A를 높이는 것인데, 예전 실험보다 이번 실험의 성과가 더 좋네요'라고 바로 비교할 수 있기 때문이다.

데이터를 파묘하다보면 이렇게도 볼 수 있고 저렇게도 볼 수 있는 것이 사실이다. 그렇지만 한층 더 깊게 분석하는 작업은 메인 지표가 기대와 달리 움직이지 않을 때 진행되어도 늦지 않은 것 같다.

2. 일 단위로 이만큼이면, 주 단위로는 얼만큼이죠?

타깃 대상자가 앞으로 얼마나 늘어날지 대시보드로 확인하고 싶다는 요청이었다. 큰 폭으로 늘어나는 시점을 예상하고 미리 대응하기 위해서다. 먼저 daily로 지표를 그려서 회의에 가져가니, 주 단위 월 단위의 변화는 어떠할지 질문을 받았다. 대시보드에 표를 추가로 그려야하나 고민을 하고 있던 찰나, 마침 옆자리 동료분이 태블로에 매개변수 기능이 있다는 것을 알려주셨다.

매개변수는 리모컨 같은 도구다.

• 집계 기준을 여러 가지로 세팅이 가능하다. (ex. daily/weekly/monthly, pv/uv, 연령별/성별 등등 group by 변수를 조정할 수 있다.)
• 집계 일자를 조정할 수 있다.
• 하이라이트를 할 수 있다. (ex. 건수가 1만이 넘었을 때 하이라이트)

매개변수는 항상 필요한가? 그건 아니다. 하지만 자주 받는 질문을 리스트업하고 대시보드에 추가 반영해 놓으면, 회의할 때 당황하지 않고 바로 필터를 조정해서 수치를 확인하고 의사결정할 수 있다는 장점이 있는 것 같다.

마무리하며

지금 대시보드가 필요한가? 라는 질문에 답하려면, 지속적으로 모니터링할 중요한 지표가 무엇일지 우선 파악해야한다. 이 문제는 내가 혼자 고민하는 것이 아니라 대시보드를 요청한 사람과 여러번 논의해서 결정해야하는 것 같다.

만일 내가 어떠한 형태의 대시보드를 요청받아도 2시간 이내에 무조건 만들 수 있는 능력자라면 이런 고민을 하지 않고 일단 다 만들어둘 수도 있었을 것 같다. 하지만 나는 그런 능력을 가지고 있지 않고 대시보드를 만드는 데 시간이 꽤 걸린다. 대시보드에 n시간을 더 투자하는 만큼 다른 업무를 할 수 있는 시간이 n시간이 줄어든다. 그래서 중요한 것이 무엇인지 요약하고, 모르는 것은 물어보고 파악하면서 최대한 시간을 효율적으로 쓰는 연습도 이제 해야할 것 같다.

_출처 : 미생 유튜브 클립 _

이 글을 쓰면서 미생의 한 장면이 생각났다..ㅋㅋ 철강팀에서 강대리가 장백기에게 문장 줄이기 과제를 주는 장면인데 업무를 할 때도 문득 생각난다. 문장 줄이기는 정말 정말 어렵다. 내용을 깊이 이해하고 누군가를 이해시킬 수 있도록 설명할 수 있는 단계까지 도달해야, 전달이 잘 되는 요약을 해낼 수 있는 것 같다.

지난 8기를 시작할 때는 취준을 하고 있었는데 10기를 시작하는 지금은 어느덧 일을 시작한 지 2년 차가 되었다. 글또를 하면서 2주간 글감을 고민하다 일요일이 되어서야 글쓰기를 시작했던 기억을 떠올리면 이번에도 분명 무한 고통 지옥이 예상되지만, 글또를 통해 얻은 것 역시 많기 때문에 이번 활동도 기대가 된다.

이때에만 할 수 있는 생각, 지금이라서 해볼 수 있는 시도가 있다

글또에 참여하며 가장 좋았던 점은 내가 당시에 어떤 고민을 했는지, 지금과는 무엇이 다른지 비교해 볼 수 있다는 것이다. 나는 회고를 거의 하지 않지만 (게을러서..) 그래도 가끔 메모장에 지금 하고 있는 고민을 적어둔다. 그러다 6개월 전에 작성했던 메모를 들여다보기도 하는데, 거기에 써둔 고민 중 하나라도 달라지거나 나아진 점이 있다면 '그럼에도 불구하고 조금 나아지고 있다'라고 동기부여를 얻는 것 같다.

취준을 할 때도 '아직 내가 일한 경험도 없는데 뭘 써야 하나' 싶다가도, 당시 주요 일과가 포폴 고치기였기 때문에 프로젝트를 정리하며 발견한 문제점들을 '지금 다시 프로젝트를 한다면 어떻게 개선할지'에 대해 글을 써보기로 했다. 글또를 하면서 프로젝트 회고 글을 작성한 덕분에 면접의 기회가 더 많이 생겼고, 결국 원하는 곳에 취업도 할 수 있었다고 생각한다.

요즘 하는 고민

아직 업무 경험이 많지 않기 때문에 이번 글또 기수에서도 수박 겉핥는 느낌이 낭낭한 글을 작성하게 되겠지만, 이것 또한 지금의 내가 할 수 있는 진지한 고민이기 때문에 되도록 가벼운 마음으로 기록하고 싶다.

Q1. 이거 좋은데.. 왜 좋지?

일하다 보면 '이 사람의 분석 결과는 뭔가 다르다'는 생각이 자주 들 때가 있는데, 내가 왜 이걸 좋다고 느낀 것인지 말로 표현하기 어려운 때가 종종 있다. 그래서 퇴근 후 '이게 왜 좋았나'를 일반화하여 짧게 메모해 두고 며칠 뒤 나의 작업에도 조금씩 적용해 보기도 하는데, 이렇게 따라 하는 과정이 재미있기도 하고 내가 몰랐던 내용을 체화할 수 있는 방법이기도 한 것 같다. 예를 들어 "좋은 시각화 예시를 정리하고 업무에 적용하기" 같은 글을 작성하려고 한다.

Q2. 이거 별론데.. 왜 별로지?

무엇을 시도 했을 때 결과가 괜찮았는지 혹은 별로였는지를 도식화하고, 이를 미래에 적용하는 글을 써보고 싶다. 히스토리를 뒤지다가 슬랙 검색을 통해 6개월, 3개월전 내가 작성한 스레드를 발견할 때가 있는데 왠지 모르게 구리다고 느낀 적이 많다. 망한 분석 결과가 장기적으로 어떤 악영향을 줬는지, 별로였다면 왜 별로였는지 돌아보고 지금 한다면 어떤식으로 다르게 해볼 수 있을지 회고하는 글을 작성해보고 싶다.

마무리하며

위에 거창하게 다짐을 해보았지만 사실 무엇보다 이루고 싶은 목표는 완주다.. 이번 글또 10기가 마지막 기수라고 해서 더욱더 중도 포기만은 피하고 싶다. 그러기 위해선 미리미리 작성하는 습관을 들여야하는데.. 주말에 유튜브 보는 것을 좀 줄이고 앉아서 뭐라도 써보는 습관을 들여야겠다. 화이팅!!

글또 7기와 비교해서 이번 기수에서 스스로에게 크고 작은 아쉬운점이 많았던 것 같다. <글또 8기를 시작하며> 글을 읽어보니 더 그런 생각이 든다. 8기를 하기 전과 현재의 나는 어떤 부분이 달라졌는가. 우선 환경이 많이 달라졌다. 하지만 변화한 환경에 비해 내가 계획했던 많은 것들을 이루지 못했다.

1년 넘게 취준생으로 살다가 대학원을 알아보던 와중, 면접에 합격하여 일을 배우기 시작했다. 감사한 마음을 가득 안고 글또 활동을 더 열심히 해야겠다고 생각했다. 그동안은 취준생으로서 내가 얻은것이 많았는데, 드디어 글또를 통해 누군가에게 기여할 수 있겠다는 기대감이 있었기 때문이다.

그런데 결과적으로 목적을 달성하는 데 실패했다.

글또를 통해 분석가로 일하시는 분들을 만나면서 그분들이 어떤 일을 하시는지, 평소에는 어떤 고민을 하고 계시는지 알 수 있었다. 그런 말을 듣다보니 분석가의 역할이 분석에서 그치지 않을 가능성이 매우 클 것이라 생각했다. 그래서 로그 정의, 집계 방식 결정, 분석 환경 세팅 등의 업무를 할 수 있어야겠다고 판단하여 데이터엔지니어링 공부를 계획… 했으나 제대로 해보지 못했다. 내가 게을렀기 때문이기도 하지만.. 생각이 조금 달라진 것도 있다. 데이터 분석가가 엔지니어링 스킬도 있으면 물론 좋겠지만, 더 중요한 것은 문제정의하는 역량이라는 것이다. 분석가는 배포 혹은 실험 이후에 벌어지는 다양한 상황들을 보고 가설을 세워 확인해야하긴한데, 이러한 업무가 한꺼번에 몰려오다보면 때로는 여러 문제들중 가장 임팩트가 높은 문제를 선택하는 등 우선순위를 관리하는 역량도 필요해보인다. 그런데 이게 말이 쉽지.. 머리로는 이해되는데 구체적을 어떻게 그런 역량을 키울 수 있는지 깊게 와닿지 않긴 하다. (그래서 다른 분들이 이전에 분석하고 공유해놓으신 자료들을 읽으면서, 이거는 왜 이렇게 했는지? 다른 방법 A도 있을 것 같은데 왜 택하지 않았는지? 질문하면서 그런 역량을 연마해나갈 수 있지 않을까.. 추측을 해봄)

2. 그럼에도 성공한 것

이력서를 업데이트하다가 이전 프젝에서의 문제점을 발견하고 개선사항을 글로 작성했다. 이전까지 포장지만 바꾸다가 내용을 바꾼 것은 이 때가 처음이었는데, 시도해보길 잘했다는 생각이 들었다. 아무리 만족스로운 프로젝트더라도 문제는 반드시 존재하기 마련이니, 시간이 지나 개선할 포인트를 찾아 고민하는 과정이 재밌다는 것을 느꼈다. 앞으로도 계약 또는 정해진 기간동안 1회성 업무를 진행하는 일을 선택하기보단, 서비스 배포 사이클에 여러번 참여하며 서비스 개선에 기여하는 일을 하고싶단 생각이 들었다.

커피챗으로 좋은 인연을 만든 것도 감사하다. 글또에서 만난 분들의 이야기를 들으며, 나는 분석가가 왜 되고 싶고 어떤 일에 흥미를 느끼는가.. 를 깊게 고민할 수 있었다. 입사 후 첫 3개월동안 정신없는 시간들을 보내면서 공부나 회고 등 개인적인 시간을 갖지 못했는데, 글또 커피챗을 통해 잠시 하던일을 멈추고 내가 지금 하고 있는 이게 맞나? 라는 고민을 할 수 있었던 것 같아 커피챗 글또분들에게 굉장히 감사하다.

전체 앱로그 유저 중에서 table a에 특정 기간동안에 기록된 유저를 제외하는 목적으로 NOT EXISTS 가 쓰이고 있었다. 언뜻 이해했을 때는 NOT IN 과 유사해보였으나 다른 부분이 있었다. exists, not exists 는 언제 쓰이는지 예시를 확인하고 in, not in 과 무엇이 다른지 알아보았다.

Exists?

exists의 기본적인 형태는 다음과 같다.

-- table_1 중에서 table_2 에도 있는 row만 추출하기
SELECT 
    column1
FROM 
    table_1
WHERE -- 메인쿼리 조건문
    EXISTS ( SELECT 
                1 
            FROM 
                table_2 
            WHERE 
                column_2 = table_1.column_1);

exists 뒤에 서브쿼리가 따라오는 구조다. 서브쿼리의 조건문에는 메인쿼리의 table_1.column 도 포함된다. 보통 이런 구조를 correlated subquery라 부른다고 한다.

exists 뒤 서브쿼리에서 적어도 하나의 행이 리턴되면, 메인쿼리의 조건문은 true을 반환하고, 서브쿼리에서 어떠한 행도 리턴하지 못하면 메인쿼리 조건문은 false를 리턴한다.

이 때 주의할 것이, 서브쿼리가 NULL을 리턴하더라도 메인쿼리의 조건문 결과는 true이라는 것이다. (NULL이라도 행을 리턴하긴 했으므로)

참고로 서브쿼리의 select 문은 어떠한 형태라도 상관이 없다. (행이 하나라도 존재하는지 여부만 중요) 아래 세 가지 쿼리의 결과는 동일하다.

• SELECT column1 FROM t1 WHERE EXISTS (SELECT * FROM t2);
• SELECT column1 FROM t1 WHERE EXISTS (SELECT 1 FROM t2);
• SELECT column1 FROM t1 WHERE EXISTS (SELECT column1 FROM t2);

사용 예시

총 두가지 테이블이 있다고 하자.

• customer 테이블: 고객 id, 고객 이름
• payment 테이블 : 구매 id, 고객 id, 수량

전체 고객 중 10개 이상의 수량을 구매해본 이력이 있는 고객을 찾는다고 가정하자.

추출하는 방법은 여러가지가 가능하다. 고객 정보 테이블을 기준으로 구매 이력 테이블을 left join 하는 방법도 있고, 아래처럼 exists를 쓸 수도 있다.

SELECT name
FROM customer c
WHERE EXISTS 
    (SELECT 1
     FROM payment p
     WHERE p.customer_id = c.customer_id -- payment 테이블에 기록된 고객인가
       AND amount >= 10 ) -- 그리고 이 때 구매 수량이 10개 이상인가
ORDER BY name;

메인쿼리에서 customer 테이블의 각 name 마다, 서브쿼리 결과가 true인지, false 인지 여부를 조회한다.

반대로 수량을 10개 이상으로 구매해본적 없는 고객을 추출하려면? 아래와 같이 not exists 를 이용하여 찾을 수 있다.

SELECT name
FROM customer c
WHERE NOT EXISTS -- 메인쿼리 조건문
    (SELECT 1
     FROM payment p
     WHERE p.customer_id = c.customer_id
       AND amount >= 10 )
ORDER BY name;

• 만약 서브쿼리가 어떠한 row도 리턴하지 않는다면? 메인쿼리의 조건문(where not exists ~)은 true를 리턴한다.

not exists와 not in의 차이점

아래 쿼리처럼 서브쿼리가 NULL을 리턴하면 exists는 true를 리턴한다.

-- 아래 쿼리의 결과는 select name from customer 와 동일하다.
SELECT
    name
FROM
    customer
WHERE
    EXISTS( SELECT NULL )
;

서브쿼리에 NULL이 리턴되는 상황에서 NOT IN vs NOT EXISTS 사이 차이가 발생한다.
예를 들어 아래와 같은 테이블이 있다고 하자.

with customer as (
    select 100 as customer_id, 'a' as name
    union all
    select 200 as customer_id, 'b' as name
    union all
    select 300 as customer_id, 'c' as name
), payment as (
    select 100 as customer_id, 15 as amount
    union all
    select 300 as customer_id, 7 as amount
    union all
    select NULL as customer_id, 10 as amount -- customer_id NULL 존재
)

customer 테이블에 기록된 고객 중 구매 기록이 없는 고객의 customer_id를 찾고자 한다. 구매기록은 payment 테이블에 기록되어 있다.

customer

• customer_id
• name

  payment

• customer_id
• amount

간단하게 NOT IN을 쓰면 되지 않을까?

-- 1) not in 을 사용한 경우
select name
from customer
where customer_id not in (
                select customer_id
                from payment
);

그런데 위 쿼리를 실행하면 아무런 행도 추출되지 않는다. payment 테이블의 customer_id 에는 NULL값이 포함되어 있기 때문이다. NOT IN 이하 서브쿼리가 먼저 실행되는데 서브퀴리 결과물 중 NULL이 포함되어 있다. 그래서 NOT IN (SELECT NULL)의 조건문의 결과 0개의 행이 추출된다.

-- 2) not exists 를 사용한 경우
select name
from customer
where not exists (
                select 1
                from payment
                where payment.customer_id = customer.customer_id
);

반면 not exists 를 사용한 경우, name='b' 인 행이 추출된다. not exists는 customer 테이블의 customer_id마다 payment 테이블에 존재하는지 여부를 조회한다. 따라서 payment.customer_id에 NULL이 있든 없든 동일한 결과가 추출된다.

참고 자료 :

• https://dev.mysql.com/doc/refman/8.0/en/exists-and-not-exists-subqueries.html
• https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-exists/

그런 의미로 최근 수행한 로깅 업무를 돌아보는 글을 쓰고자 한다. 하나의 제품을 출시하기 위해 디자이너, 개발자, PO 등이 핑퐁 논의를 하고, 그 결과 만들어진 화면에서 로그를 정의하면 되는 일이기에 처음에는 쉬워보였다. 하지만 막상 해보니, 로그 정의는 고민이 꼬리에 꼬리를 무는 어려운 일이었다. 로깅을 하면서 어떤 어려움이 있었고, 무엇을 배웠는지 돌아보았다.

1. 어디까지 남겨야하나

나는 직무 특성상 여러 팀의 로그 QA와 로그 정의 업무를 하고 있다. 그렇다보니 나는 제품을 만드는 메이커가 아닐뿐더러, 로그 데이터를 분석하는 주체라기에도 애매하다. 그래서 로깅할 때 어떤 목적으로 로그를 정의해야할지, 내가 정의한 로그를 미래에 어떻게 활용할 수 있을지 가늠하는 것이 가장 어려웠다. 내가 로깅 경험이 부족해서 생긴 문제일 수 있다. 하지만 시간이 지나면 저절로 해결되는 문제일까? 그렇지도 않아보인다.

로그 정의처럼 정답이 없는 문제일수록 팀원(데이터 분석가, PO, 개발자 등)들에게 의견을 물어보고 결정하는 것이 더 효율적인 방법 같다. 어려워서 하루 넘게 붙들고 있기보단, 내가 어디에서 막혔는지 정확히 파악하고 같이 일하는 팀원 혹은 위클리 미팅을 통해서 도움을 받아서 했더라면 여러날에 걸쳐 마친 업무가 하루만에 끝났을 수도 있겠다 싶었다. 이렇게 의견을 구하는 것 자체가 중요한 스킬이라는 생각이 들고(하지만 나는 여전히 부족한..) 내가 생각하지 못했던 맥락을 빠르게 이해해 우선순위를 파악하기 좋은 것 같다.

2. 이것까지 남겨야하나?

화면에 진입하는 유저가 어떤 행동을 하느냐에 따라 다양한 이벤트 로그를 정의할 수 있다. 예를 들어 click, impression, scroll 등을 남길 수 있다. 그 중 impression 로그를 남기는 목적은 무엇일까? impression 로그는 일반적으로 어떤 요소가 유저에게 노출되었는지 구분하기 위해 쓰인다. 예를 들어, 배너 A가 유저마다 노출 여부가 다른 경우 특정 유저에게 해당 배너가 노출되었는지 여부를 남길 때도 쓰이고, 유저가 여러 항목이 포함된 리스트에서 한 아이템을 클릭하기까지 어떤 아이템들이 노출되었는지 로깅할 수도 있다.

이것까지 로그를 남겨야햐나, 말아야하나 고민이 들 때는 직접 실행해볼 수 있는 테스트 스킴을 개발자에게 요청해서 확인하면 좋다.

스킴이란?

• 스킴은 특정 페이지로 바로 이동할 수 있는 url이다.
• 스킴을 통한 이동은 크게 1. 네이티브 앱 화면으로 이동과 2. 웹뷰로 만든 화면으로 이동으로 나눌 수 있다.
• 개발된 기능을 테스트할 때 쓰이고, 푸시를 통해 사용자를 진입시킬 때도 스킴이 쓰인다.

프레이머나 피그마를 통해 디자인으로 보고 바로 로깅하기보단, 스킴을 통해 직접 퍼널을 타보며 한번 더 확인하는 작업이 필요하다. 최근에는 스킴으로 앱을 실행해보다가 내가 빠트린 로그를 발견한적이 있다. 퍼널 중간 즈음에 뒤로가기를 눌렀는데 예상했던 것과 다른 화면으로 랜딩되었던 것이다.

스킴으로 앱을 직접 실행하다보면 로깅 시점을 파악하기도 편하다. 예를 들어 유저가 생년월일과 주소를 차례대로 입력하는 화면이 있다고 할 때, 주소 입력 단계를 impression 로깅한다고 하자. 그럼 로그를 남겨야하는 시점은 언제일까? 유저가 주소 입력 화면을 만났을 때가 될 수도 있고 유저가 주소를 입력하기 시작하는 시점일 수도 있다. 만약 “유저가 주소 정보를 입력하다가 거부감을 느껴 이탈한다” 라는 가설을 확인해보고 싶다면 유저가 입력을 시작하는 시점에 로그를 남길 수도 있겠지만 그러한 원인 파악이 중요하지 않다면 유저가 해당 화면을 보는 시점에만 로그를 남겨도 될 것이다. 최종적으로 내가 정의한 시점대로 로그를 남기는 것이 가능할지 개발자와 소통하며 확인해야하고, 이때 논의한 내용은 추후 로그가 예상한 시점대로 들어오는지 확인하는 QA 과정에서 중요하다.

3. 마무리하며

로깅을 하다가 이전 로그 중 비슷한 제품을 찾아 참고하기도 한다. (아니 거의 매일 참고한다..) 간단하게는 로그 이름을 어떻게 정의했는지부터 어떤 이벤트 로그를 남겼는지 등을 참고하고 있다. 과거에 누군가 로깅한 자료들을 보면, 로깅 방식과 로그 종류의 장단점을 배울 수 있다. 로그 정의 경험이 늘어날수록 로깅 정답을 더 많이 알게 된다기보단, 특정 로그를 포함할지 말지,에 대해 장단점을 폭넓게 이야기할 수 있게 되는 것 같다. 그래서 나의 가까운 목표는 로그 정의 경험을 쌓으며 해당 로그를 추가하면 어떤 분석에 활용할 수 있는지 설명하고, 각 로깅 방식마다 장단점을 제시할 수 있는 사람이 되는 것이다.

데이터 관련 업무 경험은 이곳이 처음이라, 입사일을 앞두고 막막함과 경직됨을 느꼈다. 이제까지의 경험을 미루어보았을 때, 나는 보고 듣는 것보다 직접 부딪히고 적용할 때 더 많이 배우는 편이라, 입사 초기에는 무엇이든 부딪히고 해결해 나가며 유연하게 적응하는 것이 목표였다.

2주가 지난 지금은 내가 무언가를 해결한다.. 는 먼 이야기 같고, 대신 나의 역량이 얼마나 부족한가를 매일매일 느끼는 중이다. 2주 차에는 QA 업무를 배우고 조금씩 해보기 시작했는데, 나에게 병목이 발생하면 안 된다는 생각에 급하게 QA를 하다 보니 문득 생각 없이 주어진 일을 하고 있는 내 모습을 발견했다. 내가 그동안 어떻게 QA를 하고 있는지 실수했던 것 위주로 점검해 보고, 앞으로의 수습 3개월 동안의 목표를 세워 보았다.

나의 QA 일지

1. 누락된 로그와 파라미터 점검

사내 제품의 각 퍼널마다 어떤 로그와 파라미터가 남는지 파악 가능한 저장소가 있다. 이를 실시간으로 쌓이는 로그와 비교해 가며 누락된 로그와 파라미터가 있는지, 파라미터값은 예상대로 찍히고 있는지 확인한다. 만약 누락되는 로그가 있거나 파라미터 값이 정의한 대로 기록되지 않는다면, 이어지는 분석 업무에 큰 영향을 줄 수 있으므로 꼼꼼히 확인해야 하는 중요한 작업이다.

2. 순서대로 찍히는지 점검

퍼널마다 순서대로 로그가 찍히고 있는지 확인한다. 예를 들어, 노출 이벤트 다음 클릭 이벤트가 찍혀야 하는데, 로그가 찍힌 순서가 반대라면 문제가 된다. 이때 주의해야 할 점은 정렬 기준인 시간 필드인데, 이게 프로세스 시간인지 이벤트 시간인지 구분해야 한다. 클라이언트 상에서 로그가 생성된 시간을 이벤트 시간이라 하고, 서버가 처리하는 시간을 프로세스 시간이라고 한다. 데이터 분석은 이벤트 시간을 기준으로 하기 때문에, 시간 순서대로 확인하려면 (프로세스 시간이 아니라) 이벤트 시간을 기준으로 정렬해야 한다.

3. 예상된 시나리오대로 찍히고 있는지 점검

처음에는 퍼널을 정의하고, 테스트 기기를 사용해 일반적인 방식으로 퍼널을 타서 로그가 예상대로 찍히는지 확인하면 되는 줄 알았다. 그런데 그게 아니라, 어떤 시나리오로 퍼널을 타는지에 따라 유입 파라미터값이 다를 수 있고 특정 로그가 아예 안 찍힐 수도 있다는 것을 알게 되었다. 그래서 QA하기 전에 미리 여러 가지 가능성을 고려하여 시나리오를 짜고, 실제로 예상대로 로그가 쌓이고 있는지 또는 로그가 중복으로 발생하진 않는지 확인해야한다. 시나리오에 따라 파라미터값이 다르게 찍힐 수도 있기 때문에, QA를 시작하기 전에 시나리오별 파라미터 예상값을 기록해 두는 것이 QA 시간을 줄여준다.

앞으로의 목표

4월 목표 :

1. 업무툴(kibana, jira, hue, 사내 툴 등)에 대한 이해를 높이고 그 밖의 새로운 기술에 대한 빠른 학습과 활용 감각 키워나가기.

2. 담당 서비스의 퍼널을 파악하고 로그 QA 참여

   • 로그와 파라미터가 어떤 목적(ex. 분석, 실험)으로 활용되는지 파악

5월 목표:

1. 담당 서비스의 로그 정의
   • 로그 정의 후 활용되는 과정 추적
   • 로그 정의 단계에서 다른 대안이 없었는지 논의
2. QA 진행 중 실수 문서화
   • 빠트린 작업이나 실수를 방지하고자 기록
   • 로그 모니터링 방식이 상황마다 무엇이 다른지 파악하고, 각 방식의 장단점 설명하기

6월 목표:

1. 로그 모니터링 단계에서 병목을 확인하고 효율적으로 개선할 방안 제시
2. 로그 관련 사내 툴 개선 아이디어 도출

마무리하며

입사 2주가 지나고 있는데 현재 내가 무슨 일을 하는지, 팀에게 어떤 기여를 할 수 있을지 여전히 명확하지 않은 막막한 상황이다. 아직 업무 이해도 부족하고 경험도 부족하지만, 좌절하고 아무것도 안 하는 것보단 현재 상황을 스냅샷으로 남겨 앞으로 개선해 나가는 것이 나은 선택이라는 생각이 들었다. 입사 3개월이 지난 시점에 오늘 작성한 부분에서 어떤 접근방식이 잘못되었고, 어떻게 개선했는지 회고하는 글을 써야겠다.

인프런 강의들은 유튜브 영상처럼 마냥 자유로운 공유는 아니고, 평점이나 리뷰로 콘텐츠가 평가받는다. 나의 경우도 인프런에서 강의를 고를 때 리뷰나 평점을 많이 참고하는 편인데 유저가 강의를 클릭해 상세 페이지로 넘어가기 전, 평점/리뷰/수준레벨 정보에따라 유저가 어떻게 반응하는지 궁금해졌다.

그중 로드맵 서비스에서 유저 분석을 한다면, (가상이지만) 어떤 과정으로 진행할 수 있을지에 대해 고민하고 정리했다.

로드맵은?

🔍 로드맵 페이지 : https://www.inflearn.com/roadmaps

유저의 수준, 원하는 스킬과 커리어패스에 맞는 학습을 할 수 있게끔 강의를 로드맵 형태로 제공한다.

서비스의 타겟은?

• 묶음 할인으로 결제하고 싶은 유저
• 자신에게 필요한 스킬이나 수준을 탐색해 학습하고 싶은 유저

타켓 유저가 로드맵을 통해 기대했던 학습 경험을 하기 위해선, 유저 스스로 수준을 진단하고 이를 기반으로 로드맵에서 탐색하기 수월해야한다. 현재 로드맵 페이지를 통해 유저가 탐색할 수 있는 정보는 크게 5가지였다.

• 검색 (원하는 스킬, 지식공유자명, 로드맵명 등)
• 분야 카테고리 선택 (ex. 개발 · 프로그래밍, 보안 · 네트워크, 데이터 사이언스)
• 시작 레벨 선택 (입문, 초급, 중급)
• 정렬 선택 (추천순, 학생수순, 공유순, 최신순, 오래된순)
• 콘텐츠 (로드맵명, 썸네일, 지식공유자명, 시작수준, 스킬, 강의수, 로드맵 참여자수 등)

문제 정의와 가설 수립

예를 들어 다음과 같은 문제를 정의한다고 가정하자.

문제 정의 : 로드맵 썸네일 CTR이 감소했다.

문제를 정의한 후에는 현황 파악 및 평가를 하고 원인을 분석한 다음 해결방안을 검토하는 순서로 진행한다.

• 원인 아이디어 1 : 로드맵 페이지로 유입되는 경로의 개수 (ex. 뉴스레터, 홈 배너 등등)가 줄어들었기 때문이다.
• 아이디어 부정 : 근데 유입 경로 개수의 문제가 아니라면?
• 원인 아이디어 2 : 유입 경로 개수를 늘려도 문제가 해결되지 않는다면, 유저에게 도달하지 않았을 가능성이 있는 건 아닌가? 그렇다면 유입 경로 개수는 관계가 없을지도 모른다.
• 아이디어 부정 : 유입 경로 개수는 충분하며, 퍼널별 전환율을 살펴보았을 때 유저에게 잘 도달하고 있다고 가정하고. 그럼에도 썸네일 CTR이 줄어든다면?
• 원인 아이디어 3 : 로드맵 썸네일 정보에 문제가 있나? (ex. 난이도를 가늠하기 어렵다)

가설 수립

위와 같은 과정으로 문제의 원인을 "유저가 로드맵 난이도를 파악하기 어렵다"이라고 분석했다고 하자. 이를 토대로 다음과 같은 가설을 수립해볼 수 있다.

• 현재 로드맵 썸네일 예시

가설 : 시작과 마지막 강의의 난이도 차이를 표시하면 로드맵 썸네일 클릭율(CTR)이 증가할 것이다.

하나의 로드맵은 여러 난이도의 강의들로 구성되어 있다. 로드맵 썸네일에 '시작 강의'와 '마지막 강의'의 난이도 차이를 표시한다면, 로드맵 학습 이후의 실력 변화를 유저가 가늠할 수 있어, 로드맵을 탐색 하기 수월할 것이다. (ex. 입문~중급 강의 구성, only 중급 강의 구성)

샘플 크기가 충분하다면 AB 테스트를 진행해 볼 수 있다. 로드맵 썸네일에 '난이도 차이' 정보를 추가한 후, 클릭율이 개선되는지 확인하고자 한다. 가드레일 지표로는 로드맵 수강 전환율을 정의한다. (클릭율 개선의 목적은 로드맵 강의 매출 개선이다.) 클릭율을 개선하되, 수강 전환율이 떨어지면 실험을 중단한다. 가설 검증을 위해 다음과 같은 데이터가 필요하다.

• 필요한 데이터

• 데이터 예시

마무리하며

'로드맵 클릭율 감소' 상황을 가정하여 원인을 분석하고 해결 방안으로 실험 가설을 도출해보았다. 최근에 <데이터 문해력> 책을 다시 읽으면서 배운 내용들을 적용하려 노력해봤으나.. 문제 정의부터 원인을 분석하는 과정에서 여전히 설득력이 부족한 것 같다. 서비스의 유저 분석 사례를 더 찾아보며 공부해야겠다.

참고한 서적

• 카시와기 요시키 지음 / <데이터 문해력> / 강모희 옮김

1. LAG 함수 정의

LAG(expression [,offset][, default_value]) OVER over_clause

• expression : 칼럼명

• offset : 기본값은 1. window frame 상에서 몇 번째 이전 행의 값을 반환할지 결정.
• default_value : 이전 행이 존재하지 않을 때 대체할 값. 기본값으 NULL
• over_clause : PARTITION BY나 ORDER BY 를 Optional하게 사용 가능

over_clause와 window frame 구문에 대한 자세한 설명은 이곳에

2. 목적

사용한 데이터

BigQuery의 공개 데이터 중 "san_francisco" Dataset에서 "bikeshare_trips" Table을 사용했다. 2015-01-01부터 2016-08-31까지 샌프란시스코 지역의 자전거 대여/반납 내역이 기록된 테이블이다.

• 스키마

• 미리보기

목적 1. 지난주 이용량과 이번주 이용량 비교하기

테이블의 칼럼 값이 정렬된 상태에서 LAG함수로 n번 이전 행에 해당하는 값을 가져올 수 있다. 예를 들어 다음과 같은 분석이 가능하다.

• 자전거 이용량의 요일별 패턴 분석
• 월별 이용량이 증가한 요인을 분석할 때, 전년 동기에도 비슷한 현상이 있었는지 확인할 때

다음은 2015년 자전거 이용량의 요일별 패턴을 분석하고자, 지난주 이용량(previous_week)과 이번주 이용량(num_trips)을 비교한 결과다.

-- (1) 일별 이용량 집계
WITH updates AS(
  SELECT
    DATE(start_date) AS trip_date,
    COUNT(*) AS num_trips
  FROM `bigquery-public-data.san_francisco.bikeshare_trips` 
  WHERE EXTRACT(YEAR FROM start_date) = 2015
  GROUP BY 1
)

-- (2) 이번주와 지난주 이용량 비교
SELECT
  trip_date,
  num_trips,
  LAG(num_trips, 7)
    OVER(
      ORDER BY trip_date
      ) AS previous_week
FROM updates
ORDER BY 1

• (1) updates 테이블 : 2015년 데이터만 가져와 일별 자전거 이용량을 집계했다.
• (2) LAG 함수로 7일 전 이용량을 가져왔다. 7일전 날짜 데이터가 없는 경우 NULL값 처리되었다.

목적 2. 결측(Missing Value) 확인

그런데 앞서 작성한 쿼리에는 문제가 있다. trip_date이 연속되지 않을 수 있다. 즉, 자전거 대여 기록이 매일 누락 없이 기록되었으라는 보장은 없다. 데이터를 수집하는 과정에서 얼마든지 결측이 발생했을 수 있다. 이를 확인하기 위해 LAG함수를 사용할 수 있다.

-- (1) 일별 이용량 집계
WITH updates AS(
  SELECT
    DATE(start_date) AS trip_date,
    COUNT(*) AS rows_added
  FROM `bigquery-public-data.san_francisco.bikeshare_trips` 
  WHERE EXTRACT(YEAR FROM start_date) = 2015
  GROUP BY 1
), 
-- (2) 업데이트된 기록 간격 구하기
num_days_update AS(
  SELECT
    trip_date,
    DATE_DIFF(
      trip_date,
      LAG(trip_date, 1)
        OVER(
          ORDER BY trip_date
          ),
      DAY
    ) AS days_since_last_update
  FROM updates
)

-- (3) 결측 날짜 확인
SELECT * FROM num_days_update WHERE days_since_last_update > 1

• (1) updates 테이블 : 일별 이용량 집계
• (2) num_days_update : 업데이트된 기록 간격 구하기. LAG함수로 이전 행과 현재 행의 날짜 간격 계산함.
• (3) days_since_last_update 가 n일 초과인 경우 확인. 임계값 기준 n은 정하기 나름. 예시에선 1일 초과된 경우를 확인했다.

쿼리 결과는 다음과 같다.

2015년 일별 이용량 데이터는 days_since_last_update 칼럼 값이 모두 1이다. (모두 1일 간격으로 업데이트 되었다.)

LAG(num_trips, 7)) 값이 7일 전의 값이 되려면 "num_trips가 하루도 누락없이 매일 기록되었다" 라는 전제가 있어야 한다.

매일 기록되어야 했을 자전거 대여 기록에서 누락이 발견된다면? 이상 징후로 Alert하고, 데이터 계보 그래프를 확인해야한다. 만약 선행 테이블이 있다면 선행 테이블의 기록 과정에서 발생한 문제인지 확인이 필요하다.

3. 예시

2015년 샌프란시스코의 자전거 대여량 추세를 확인한다고 하자. 이를 위해 monthly_average_num_trips을 계산해 시각화하려 한다.

• monthly_average_num_trips : 최근 30일간의 평균 이용량

1단계 : 일별 이용량 집계

WITH updates AS(
  SELECT
    DATE(start_date) AS trip_date,
    COUNT(*) num_trips
  FROM `bigquery-public-data.san_francisco.bikeshare_trips` 
  WHERE EXTRACT(YEAR FROM start_date)=2015
  GROUP BY 1
)

2단계 : 일별 이용량에 누락된 날짜가 있는지 확인

WITH num_days_update AS(
  SELECT
    trip_date,
    DATE_DIFF(
      trip_date,
      LAG(trip_date, 1)
        OVER(
          ORDER BY trip_date
          ),
      DAY
    ) AS days_since_last_update
  FROM updates
)
-- 마지막으로 업데이트 된 기록이 
SELECT * FROM num_days_update WHERE days_since_last_update > 1

• 기록이 누락된 날짜가 없음을 확인

3단계 : 최근 30일간 평균 이용량 구하기

• monthly_average_num_trips : x일 기준으로 최근 30일간 평균 이용량 계산
• next_num_trips : LEAD함수로 (x+1) 일에 해당하는 이용량 가져옴

  SELECT
  trip_date,
  AVG(num_trips)
    OVER(
      ORDER BY trip_date
      ROWS BETWEEN 29 PRECEDING AND
      CURRENT ROW
    ) AS monthly_average_num_trips,
  LEAD(num_trips, 1)
    OVER(
      ORDER BY trip_date
    ) AS next_num_trips
  FROM updates
  ORDER BY 1

*4단계 : 시각화 *

쿼리를 실행하고 나면 쿼리 결과 테이블을 바로 Google Colab으로 가져올 수 있다.

monthly_average_num_trips의 추이를 시각화 한 결과, 2015년 11월 이후로 자전거 이용량이 감소했음을 파악할 수 있다.

최근 30일간 평균 이용량(monthly_average_num_trips, 파랑색)으로 다음날 이용량(next_num_trips, 주황색)을 예측할 수 있을까? 자전거 이용량은 요일별 패턴이 강하다보니 monthly_average_num_trips는 예측 목적으로는 적절하지 않아보인다.

4. 참고한 자료

• BigQuery 공식 문서
• Data Quality Fundamentals

팀원들과 딥러닝 모델을 활용한 이미지 복원 서비스를 개발했던 적이 있습니다. 서비스 이용자가 이미지 편집 도중 느끼는 어려움을 파악하기 위해 설문조사를 실시하고, 이를 기반으로 '이미지에서 물체 지우기', '화질 개선하기', '흔들림 제거하기' 3가지 작업을 수행할 수 있는 서비스를 기획했습니다. (데모 영상을 포함한 깃헙 링크는 이곳에 있습니다.)

제가 맡은 역할 중 하나는 유저 로그를 정의하고 데이터베이스를 구축하는 일이었습니다. 데이터베이스를 구축한 목적은 다음과 같습니다.

• 딥러닝 모델을 활용한 서비스라, 배포 이후에 모델 성능을 개선하는 배치 서빙을 계획했습니다. (가능하다면) 사용자의 입력 데이터와 모델이 추론한 결과를 저장해, 추가 학습을 위한 데이터로 활용하고자 했습니다.
• 딥러닝 모델을 사용하려면 서버 자원이 필요했는데, 실제 배치 서빙을 할 수 있을 만큼 서버 자원을 빌릴 수 있는 기간이 길지 않았습니다. 그래도 배치 서빙을 할 수 있다고 가정하고, 모델 성능 개선이 목적인 데이터베이스를 구축했습니다.

2. 전체적인 흐름

'이미지에서 물체 지우기' 작업의 예시입니다.

1) 사용자가 이미지를 업로드하면 2) Tool을 선택하고 (직사각형 그리기, 자유롭게 그리기 등) 3) 원하는 Inference 종류를 선택한다 (이미지에서 물체 지우기, 화질 개선하기, 흔들림 제거하기 등) 4) Inference 결과가 나오면 다운로드 버튼을 눌러 저장한다. 5) 결과에 대해 평점을 매긴다.

• 앱서버 : Streamlit Cloud
• 데이터베이스 서버 : GCP의 MySQL 인스턴스
• 모델 학습용 이미지 저장 스토리지 : GCP의 Google Cloud Storage

필요에 따라 서버를 각각 스케일업 할 수 있도록 앱서버(Streamlit Cloud Server), 데이터베이스 서버(Cloud SQL), 스토리지(GCS)로 분리하여 설계했습니다.

• 사용자가 이미지를 업로드하고, 원하는 Tool과 Inference를 선택하면
• Streamlit Cloud Server에서 이미지 데이터를 모델에 입력해 추론 결과 이미지가 생성됩니다.
• 추론이 완료될 때마다, Google Cloud Storage에 입력 이미지와 결과 이미지로 구성된 Pair Dataset이 저장됩니다.
• Storage에 이미지 파일이 업로드되면, 이미지 url이 생성됩니다. 입력 이미지 url과 결과 이미지 url을 앱서버에 보내고, inference 작업의 종류(Inference Type)을 함께 데이터베이스 서버에 보내 테이블에 기록했습니다.
  • 상단 우측 그림과 같이 총 4개의 테이블을 정의했습니다.
    • Input : 입력 ID, 입력 이미지 url, 업로드 시간
    • Inference : ID, 입력 ID, 결과 이미지 url, 작업 종류(Inference Type), 결과 이미지가 생성된 시간
    • Mask : 유저가 이미지의 어떤 영역을 지우려고 했는지 기록. 생성 모델의 입력으로 필요.
    • Score : 추론 결과에 대한 유저의 평가점수를 함께 기록.
  • 추후에 이미지 자체를 집계하거나 조회할 필요가 없었으므로 데이터베이스에 저장하지 않고 Storage에 따로 저장했습니다. (이미지를 Byte String으로 변환하면 테이블에도 저장 가능하긴 합니다.)
• 모델을 재학습하는 시점에는 Target Date 기간에 해당하는 데이터를 불러와 배치서빙할 수 있도록 SELECT 문을 작성했습니다.

3. 문제점 혹은 고민 지점

Streamlit 프레임워크를 사용해 빠르게 프로토타입을 만든 후, 직접 테스트하다 보니 몇 가지 문제점을 발견했습니다. 마우스로 일일이 물체를 마스킹하다 보니 시간이 오래 걸렸고, 유저가 물체의 경계를 타이트하게 지울 경우, 모델 추론 결과가 얼룩덜룩한 문제가 있었습니다.

개선 : Segmentation Tool 추가

이 문제를 개선하기 위해, 마우스로 직접 마스킹하는 대신 유저가 지울법한 영역을 Segmentation 모델이 대신 추천해주는 기능을 추가하기로 했습니다. 아래처럼 Segmentation Tool을 사용하면 유저가 이미지에서 지울법한 영역을 제안해주고, 유저는 원하는 영역을 고르기만 하면 되는 식이었습니다.

그런데 프로젝트를 회고하다 보니, 실제로 얼만큼의 개선이 있었는지 확인할 지표가 없었다는 것을 알게 되었습니다. 데이터베이스를 설계한 목적이 '모델의 추가 학습'이었기 때문에, 기능을 추가했을 때 서비스가 개선되었는지 확인할 수 있는 지표, 그리고 지표를 계산하기 위한 유저 로그가 부족하다는 생각이 들었습니다.

프로젝트 이후 프로덕트 분석 기법을 공부하다 '퍼널'이라는 개념을 새로 알게 되었고, 퍼널 개념을 적용하여 유저 로그를 새로 정의해보기로 했습니다.

4. 퍼널 설계

퍼널 분석이란, 유저가 서비스 최초 유입부터 최종 목적지까지 미리 설계한 흐름대로 잘 도착하고 있는지 분석하는 기법입니다. '이미지에서 물체 지우기' 작업의 퍼널은 다음과 같이 정의했습니다.

1. 이미지 업로드
2. Tool 선택
3. Inference 선택
4. 이미지 저장
5. 스코어 입력

퍼널 설계를 바탕으로 테이블을 다시 정의해보았습니다.

5. 테이블 재정의

중복을 피하기 위해 Fact Table과 Dimension Table로 구분해 정의했습니다. Fact Table은 집계에 기반이 되는 테이블이며 시간이 함께 기록됩니다 (Table 1~ Table 4). Dimension Table은 주로 데이터를 분류하기 위한 속성값이 기록되고 상황에 따라 수정될 수 있기 때문에 따로 분리했습니다 (Table 5, Table 6).

Table 1) Input 이미지 : 유저가 이미지 업로드 시 INSERT

• input_id : 입력 ID (입력한 이미지에 해당하는 UUID)
• input_url : 입력 이미지 url
• server_time : 업로드 시각

Table 2) Tool 클릭 : 유저가 Tool 클릭 시 INSERT

• id
• input_id : 입력 ID
• tool_id : Tool ID
• server_time : Tool 클릭 시각

Table 3) Inference 클릭 : 유저가 Inference 클릭 시 INSERT

• id
• input_id : 입력 ID
• inference_id : 추론 작업 ID
• inference_url : 추론 이미지 url
• mask_url : (모델 학습에 필요한) mask 이미지 url
• server_time : Inference 클릭 시각

Table 4) Save 클릭 : 유저가 Save 클릭 시 INSERT

• id
• input_id : 입력 ID
• server_time : Save 클릭 시각

Table 5) Tool 분류 : 마스터 테이블

• tool_id : Tool ID (int)
• tool_name : Tool 이름 (string)
• tool_type : Tool 카테고리 (string)

Table 6) Inference 분류 : 마스터 테이블

• Inference_id : Inference ID (int)
• Inference_name : Inference 이름 (string)
• Inference_type : Inference 카테고리 (string)

6. 분석을 위한 테이블 만들기

데이터를 기록하는 단계에선 위와 같이 Fact Table과 Dimension Table로 분리해두고, 분석하는 단계에서는 분석에 필요한 테이블들을 결합해 비정규화 테이블을 만듭니다.

Segmentation Tool을 추가했을 때, 유저의 작업 시간이 실제로 감소하는지 확인하기 위해 분석을 수행하고자 합니다. Tool 클릭 테이블, Inference 클릭 테이블, Save 클릭 테이블을 결합해 다음과 같은 비정규화 테이블을 생성해보겠습니다.

<예시1>은 입력 이미지마다 Tool을 처음으로 클릭하고, 모델에 입력하고, 추론된 결과 이미지를 저장하기까지의 시간 기록을 가져온 테이블입니다. 이 때 Input ID별로 "제일 처음 Tool을 클릭한 시간"과 "이미지를 저장한 시간"을 구하고, Input ID별로 두 시간의 차이(=총 작업 시간 "Diff Second")을 초단위로 집계할 수 있습니다. <예시2>

기존 서비스와 Segmentation Tool을 새로 추가한 서비스의 Diff Second의 평균을 비교해 유저의 작업 시간이 실제로 감소했는지, 감소했다면 어느정도 감소했는지를 집계할 수 있습니다.

7. 정리하며

과거에 진행했던 프로젝트에서 '기능을 추가하여 문제를 개선했다'라고만 정리하고, 지표로 확인하기 위한 로그 정의를 제대로 하지 않았다는 것을 발견했습니다. 퍼널을 기준으로 로그를 다시 정의했고, 팩트 테이블과 디멘전 테이블로 구분해 테이블을 재정의했습니다.

클릭 이벤트 위주로 아주 간단히 로그를 정의해보았는데, 더 다양한 이벤트 파라미터를 고려해볼 수 있을 것 같습니다. AB테스트를 고려한다면 한 명의 유저가 대조군과 실험군에 동시에 들어가면 안 되기 때문에 유저 로그를 더 상세히 정의해야할 것 같습니다. 이밖에 데이터 QA를 자동화하는 방법에 대해서도 더 공부해야할 것 같습니다...!

8. 참고한 자료

1. 빅데이터를 지탱하는 기술 / 니시다 케이스케 지음 / 정인식 옮김 / 제이펍

그래서 올해에는 '적용'으로 마무리되는 글을 많이 작성하는 것이 목표이다. Towards Data Science 같은 글을 읽을 때도, 예시가 포함된 경우가 더 이해가 잘 되었던 것 같다.

예를 들어 새로 알게된 분석 기법에 관한 글을 작성한다면,

• 활용 가능한 예시를 가정해 데이터를 수집하고
• 적용해서
• '어떤 문제를 해결할 수 있는지'에 대한 글을 작성해보고 싶다.

지난 글또에서 작성했던 글 중, 적용으로 마무리했던 글은 한 개뿐이다. 이번에는 이런 글을 최소한 3개 쓰는 것이 목표다. 분량이 많다면 시리즈로 쪼개는 방법도 있을 것 같다.

데이터 프로덕트를 만들자

최근에 봤던 면접에서 "데이터 분석가는 추출이나 집계하는 요청 업무를 주로 하게 될 수도 있다, 그래도 상관없는지?"라는 질문을 받았는데 면접 복기를 하다가 뜨끔했다. 나는 (빨리 일을 시작해 경험을 쌓고 싶다는 마음이 앞서서) "오히려 재밌을 것 같다. 나는 호기심이 많은 편이라, 오히려 추출과 집계 업무를 하며 서비스를 잘 이해할 수 있을 것 같다"라는 답변을 했다.

그런데 질문의 의도는 '요청 업무가 잘 맞냐 or 맞지 않냐'를 물어본 것이 아니었을 수도 있겠다는 생각이 들었다. 실제로 분석가로 일하시는 분들을 만났을 때 ‘팀에 조인했을 때, 요청 형태로 일을 하다 보니 쿼리와 시각화 머신이 된 듯하다’는 이야기를 많이 들었다. 즉, 이건 분석가로서 한 번쯤은 고민하게 될 문제다. 그런 문제에 대한 해결 방안 고민 없이, 아뇨! 그건 저에게 문제가 아닌데요!라고 하는 건 설득력 없는 답변이었다.

올해 경기가 좋지 않아 취업 기회가 더욱 좁아졌다고는 하나, 최근에 봤던 면접들을 모두 복기해보았을 때 면접에서 떨어졌던 결정적인 이유는 나에게 있다고 생각한다.

나의 문제는,

1. 그 팀이 현재 가장 중요하게 생각하는 문제를 파악하지 못했다. 최근 본 면접에서 '이 팀에 일하면서 어려운 점이 어떤 것이 있는지'에 대해 질문했는데, 답변을 듣고 내가 어떤 역할 또는 시도해 보겠다는 어필을 하지 못하고 나온 것이 아쉬웠다. 이 부분을 보완하려면 면접을 준비하는 과정에서 유사한 분야에서 일하는 분석가를 만나 힌트를 얻을 수도 있겠고, 면접 당시에 면접관에게 '바라는 스킬셋이나 모습이 무엇인지'를 질문해서 유추할 수 있을 것 같다.

2. 나도 나를 몰라서 면접관에게 나를 설명하는 것이 설득력이 없다. 나는 그동안 면접을 준비하며 회사의 서비스와 업무를 이해하기 위해 정보를 찾고 나를 거기에 잘 맞추려고 노력했다. 물론 그것도 중요하겠지만, 정작 내가 이 일을 왜 하고 싶은지 깊게 질문하지 않았다. 어떤 것을 좋아하고 어떤 것을 잘하는지 뾰족하지가 않다. 나는 5년 후에 어떤 커리어를 쌓아나가길 바라지?? (모름.) 나는 어떤 사람이지?? (당황.) 나는 뭘 좋아하고 뭘 싫어하지?? (잘 기억이 안 남.)

이를 바탕으로 새로 잡은 목표는 데이터 프로덕트를 만드는 연습을 하는 것이다. 나는 쿼리 작성하는 건 자신 있다. 잘하는 건 아니지만 부족한 부분을 발견하면 빠르게 보완 가능하다. 그런데 쿼리 작성만 데이터 분석가의 역할일까? 로그 정의, 집계 방식 결정, 분석 환경 세팅 업무를 하게 될 수도 있다. 요청 업무가 반복될 경우, Summary Table 만드는 방법을 고민해야 할 수도 있다.

(아직 협업해 본 적은 없지만) 기획자, 마케터, 디자이너 등 다양한 사람들과 같이 일한다면, 팀원들의 니즈를 해결하기 위해 데이터 프로덕트를 만들어두고 커뮤니케이션하며 조금씩 확장해나가는 일을 하고 싶다. 데이터 프로덕트를 만들기 위해 데이터 엔지니어링 공부가 필요하다고 생각했다. 일단 빠르게 사이클을 한 바퀴 돌려보는 프로젝트를 해야 할 것 같고, 그 과정을 블로그에 작성해야겠다.

마무리하며

작년에 글또를 통해 감사한 기회도 많이 생겼고, 이전보다 작성한 글의 개수도 늘어나서 참여하길 잘했다는 생각이 들었다. 그런데 막상 8기 모집 소식을 듣고 많이 고민했는데, 그 이유는 취준생 입장에서 내가 공유할 수 있는 게 많지 않다는 생각이 들어서이다. 글또 커피챗을 통해 내가 얻은 것은 많지만, 정작 나는 글또를 통해 어떤 기여(?)를 할 수 있을지 구체적으로 그려지지 않았다.

그럼에도 다시 신청한 이유는 '이때에만 할 수 있는 생각이 있고, 이때에만 시도해볼 수 있는 프로젝트가 있을 것이다'라는 생각 때문이다. 고민되지만 일단 해보자, 라고 결론을 낸 데에는 글또 피드백 문화도 있다. 비록 내가 작성한 글은 엉성할지라도 최ㅊ최최최종 글은 분명 나아질 것이라 믿는다.

완주를 향하여~ 🏃‍♀️🏃‍♂️

1. Stack

Stack이란 쌓아 올린 형태의 자료구조를 말한다. Python에서는 연결리스트를 직접 구현할 필요없이 리스트 자료형의 append와 pop 매서드로 Stack을 사용할 수 있다. 박스를 쌓고 꺼내는 것처럼, 스택 자료구조는 가장 마지막에 들어간 데이터가 가장 먼저 나가는 LIFO(Last In First Out) 구조이다.

데이터를 모두 꺼내서 더이상 pop할 수 없으면 스택이 Empty하다, 라고 표현하고 반대로 꽉 차서 더이상 스택에 push를 할 수 없는 상황은 stack overflow가 발생했다고 한다.

박스처럼 생긴 데이터 단위는 노드(Node)라고 한다. 그리고 앞으로 구현할 연결리스트(Linked List)는 노드로 이루어져있다.

노드는 item, pointer 총 2가지의 속성을 가지고 있는데, pointer가 노드와 노드를 "연결"해주는 역할을 한다. 위의 그림을 보면 Node1의 pointer가 Node2를, Node2의 poiner가 Node3를 가리키는 것을 볼 수 있다. Node라는 클래스를 정의하여 이를 구현하면,

2. Node 구현

from typing import Optional


class Node:
    def __init__(self, item, pointer: Optional["Node"] = None):
        self.item = item
        self.pointer = pointer


if __name__ == "__main__":
    # 노드 생성
    node1 = Node(item=11)
    node2 = Node(item=22)
    node3 = Node(item=33)

    # 노드 연결
    node1.pointer = node2
    node2.pointer = node3

생성자 Constructor (__init__ 함수)

• 인스턴스가 생성된 순간 즉시 실행된다. 인스턴스가 생성되는 순간이 메모리에 올라오는 순간.
• self는 인스턴스가 생성되었을 때, 그 인스턴스를 지칭한다.
• item과 pointer 두가지 속성이 있는데
  • item은 노드가 담고 있는 데이터를
  • pointer는 다음 노드를 저장하거나, 아무것도 가리키지 않으면 None을 저장한다.
  • pointer의 디폴트 값은 None이다.
  • pointer의 타입은 Optional("Node"). "Node"이거나 None 이거나.
  • "Node" : 클래스를 typing하는 도중, 자기 자신을 타이핑해야한다면 큰 따옴표를 쓴다.

노드 생성, 연결

• 총 3개의 인스턴스가 생성됨. (node1, node2, node3) 각각의 인스턴스는 서로 독립적이다.
• node1은 node2에 연결되어 있다. 그래서 node1의 pointer에 node2를 저장한다. node3은 맨 마지막 노드이므로 pointer 값은 None이다.

typing

int_var: int = 88
str_var: str = 88 # 오류 안 남

• Python에서 typing은 타입 힌트일뿐, 타입 체크를 하진 않는다.
• 예를 들어, pointer를 Optional("Node")을 사용하여 타이핑했는데, 예상하지 않은 타입을 쓰더라도 실행 시 오류가 나지 않는다. (node1.pointer = 3 를 실행해도 에러가 안 뜬다.)
• 타입 체크를 하려면
  • isinstance(88, int) 함수를 써도 되고, mypy나 pyright 라이브러리를 설치해도 타입 체크 가능
  • ex. mypy hello.py && python hello.py (공식문서 참고)

3. 연결 리스트 LinkedList 구현

구현 내용

• head 속성 : 가장 첫 번째 노드를 head라고 하고, 노드가 없다면 None을 저장.
• length : int 타입. 현재 노드(데이터)의 개수
• print 했을 때 ","로 구분하여 item 출력

class LinkedList:
    def __init__(self):
        self.head: Optional[Node] = None

    @property
    def length(self) -> int:
        if self.head is None:
            return 0
        cur_node = self.head
        count: int = 1
        while cur_node.pointer is not None:
            cur_node = cur_node.pointer
            count += 1
        return count

    def __str__(self) -> str:
        # read
        result: str = ""
        if self.head is None:
            return result
        cur_node = self.head
        result += f"{cur_node.item}"  
        while cur_node.pointer is not None:
            cur_node = cur_node.pointer
            result += f", {cur_node.item}"
        return result

생성자 Constructor (__init__ 함수)

• 첫 번째 노드인 head를 정의한다.
• 타입은 "Node"이거나, None 이므로 Optional("Node")
• 디폴트값은 None으로 저장

length

• 매서드로 구현해도 되고 @property 데코레이터를 붙여서 속성으로 구현해도 됨.
  • @property : 접근(read)은 가능하지만, 업데이트는 불가. (캡슐화)
  • +=1 같은 업데이트하면 set 속성이 없다고 에러남(AttributeError: can't set attribute)
  • 만약 업데이트하려면, @length.setter 데코레이터로 setter 함수 추가해줌.
  • pop, push할 때마다 length를 업데이트하는 방법도 있겠지만 예상하지 못한 상황에서 length가 임의로 업데이트될 가능성이 있으니, length는 접근만 가능하게 하는 것이 나아보임.
• 첫번째 노드인 self.head 가 없다면 0 출력
• 첫번째 노드가 있다면 pointer가 None일 때까지 노드를 카운트

__str__

• Python의 모든 클래스는 Object 클래스의 상속을 받음. (class LinkedList: == class LinkedList(Object):)
• 이 때 Object 클래스에 이미 내장된 매서드들을 Magic Method라고 함. (dir()로 확인 가능 ex. __class__, __init__, __str__)
• print문은 객체를 문자열화하는 함수. print를 쓸 때 __str__ 이 실행됨.
• __str__ 함수를 새로 정의하여 덮어쓰기(Method Overriding) 가능.
• length와 마찬가지로 첫번째 노드가 있는지 확인하고, 있다면 pointer가 None일 때까지 while 문 돌리는 식으로 구현

4. Stack 구현

구현 내용

• LinkedList를 상속받는다.
• push(item) : Stack 자료구조에 item을 받아 Node로 만든 다음 Stack 에 넣는다.
• pop() : Stack 자료구조에서 마지막 Node를 제거하고, 해당 item을 반환한다.

class Stack(LinkedList):
    def push(self, item) -> None:
        new_node: Node = Node(item=item)
        if self.head is None:
            # head가 가리키는 게 아무것도 없을 때
            self.head = new_node
            return  
        cur_node = self.head
        while cur_node.pointer is not None:
            cur_node = cur_node.pointer
        cur_node.pointer = new_node

    def pop(self):
        if self.head is None:
            raise ValueError("stack is empty")
        else:
            cur_node = self.head
        if cur_node.pointer is None:
            self.head = None
            return cur_node.item
        while cur_node.pointer.pointer is not None:  # pointer의 pointer
            cur_node = cur_node.pointer
        result = cur_node.pointer
        cur_node.pointer = None
        return result.item

push(item)

• item 인자가 필요하고 반환하는 값은 없다. (None으로 typing)
• 연결리스트의 가장 마지막 노드에 해당하는 pointer에 new_node를 추가한다.
• head가 가리키는 게 없다면, 첫번째 노드인 self.head에 new_node를 정의한다.
• head가 가리키는 노드가 있다면, 가장 마지막 노드를 찾을 때까지 while문으로 탐색한다.
• 마지막 노드를 찾았다면 cur_node.pointer에 new_node를 연결한다.

pop()

• 인자가 필요 없고 item 값을 반환한다.
• 연결리스트의 가장 마지막 노드를 꺼내곰, 직전 노드의 pointer에는 None을 저장한다.
• head가 가리키는 게 없다면, Stack이 비어있는 상황이므로 ValueError를 일으킨다.
• head가 가리키는 게 있다면, 가장 마지막 노드를 찾을 때까지 while문으로 탐색한다.
• cur_node.pointer.pointer가 None인 마지막 노드를 찾아 item을 반환하고, 그 직전 노드인 cur_node.pointer의 pointer는 None으로 저장한다.

5. Generic Type

위에서 item의 타입은 int, str, bool 등 여러가지가 가능하다. item의 타입은 자유롭되, 한 스택 안에 포함된 노드들은 모두 동일한 타입을 가지도록 구현할 순 없을까? 예를 들어 int와 str이 섞여있는 (1, 2, '3', 4) 와 같은 형태는 허용하지 않는 것이다. 이 때, Generic Type을 사용할 수 있다. Generic Programming은 데이터 형식에 의존하지 않고, 일반성을 유지하며 하나의 값이 여러 다른 데이터 타입들을 가질 수 있는 기술이다.

Generic Type은 위의 예시처럼 item의 타입을 고정할 때도 쓸 수 있고, item과 동일한 타입인 또 다른 변수를 정의할 때도 쓸 수 있다. typing과 마찬가지로 타입 체크가 되진 않지만 코드로 협업할 때 타입 힌트로 유용하다는 장점이 있다.

from typing import Generic, TypeVar

T = TypeVar("T") # Generic Type

위처럼 TypeVar로 타입 변수 T를 만든다. TypeVar("T", int, str)로 타입 후보를 제한해줄 수도 있다. (mypy 0.982 버전에서는 오류가 나서 TypeVar("T")로 수정 했다.)

Node, LinkedList, Stack 클래스에 각각 item을 T로 타이핑한 코드는 다음과 같다. Node의 item을 LinkedList와 Stack에서도 쓰기 때문에 클래스를 정의할 때 아래와 같이 Generic[T]를 넣어줘야한다.

전체코드

from typing import Optional, TypeVar, Generic

T = TypeVar("T")


class Node(Generic[T]):
    def __init__(self, item: T, pointer: Optional["Node"] = None):
        self.item = item
        self.pointer = pointer


class LinkedList(Generic[T]):
    def __init__(self):
        self.head: Optional[Node[T]] = None

    @property
    def length(self) -> int:
        if self.head is None:
            return 0
        cur_node = self.head
        count: int = 1
        while cur_node.pointer is not None:
            cur_node = cur_node.pointer
            count += 1
        return count

    def __str__(self) -> str:
        result: str = ""
        if self.head is None:
            return result
        cur_node = self.head
        result += f"{cur_node.item}"
        while cur_node.pointer is not None:
            cur_node = cur_node.pointer
            result += f", {cur_node.item}"
        return result


class Stack(Generic[T], LinkedList[T]):
    def push(self, item: T) -> None:
        new_node: Node[T] = Node[T](item=item)
        if self.head is None:
            self.head = new_node
            return  
        cur_node = self.head
        while cur_node.pointer is not None:
            cur_node = cur_node.pointer
        cur_node.pointer = new_node

    def pop(self) -> T:
        if self.head is None:
            raise ValueError("stack is empty")
        else:
            cur_node = self.head
        if cur_node.pointer is None:
            self.head = None
            return cur_node.item
        while cur_node.pointer.pointer is not None:  
            cur_node = cur_node.pointer
        result = cur_node.pointer
        cur_node.pointer = None
        return result.item

length 매서드를 구현할 때 self.head를 고정하지 않고 업데이트하는 바람에 초반에 애를 먹었다. 타이핑하며 구현하는게 아직 익숙하지 않아서 (특히 Generic) 좀 더 연습해야할 것 같다.

목표를 이뤘나?

1. 논문 구현 좀 다양한 논문을 구현하고 기록하고 싶었지만 정작 기록은 VAE 하나다. 공부해서 정리하는 일과 달리, 예상 독자를 정하고 독자가 알기 쉽게 정리해서 글을 쓰는 것은 쉽지 않다는 것을 느꼈다. 그래도 VAE 개념을 설명하면서 애매모호했던 개념들이 많이 해소되었다. 뭔가 날잡고 하기보다는 매일 조금씩 꾸준히 작성해봐야겠다.

2. 기술 블로그 공부 기술 블로그를 읽다가 궁금했던 용어와 내용을 정리해서 글을 작성했다. multiclass AB test에 관한 내용이었는데 학부 실험계획법 시간에 배웠던 내용들을 복습할 수 있어서 좋은 기회였던 것 같다. 당초 계획과 달리 데이터 엔지니어링 분야를 정리하는 글을 작성하지는 못해서 아쉽다.

3. 프로젝트 기록 5개월동안 서비스를 구현하고 그 과정을 기록해보는 것이 목표였는데.. 하지 못했다.. 무엇을 해야할까??? 가 아직도 가장 고민이다..

감사했던 기회

글또 7기를 하길 잘했다는 생각이 들만큼 감사한 순간들이 많았다.

1. 글또 오프라인 (커피챗, 글또콘) 슬랙으로만 뵙던 분들과 직접 이야기를 나눌 수 있어 좋았다. 일에 대한 다양한 고민을 옆에서 듣는 것만으로도 소중한 시간이었다. 특히 글또콘을 위해 글또 운영진분들이 굉장히 고생하신 것 같았는데, 이런 자리를 기획해 주시고 진행해 주셔서 감사했다..!
2. 면접 기회 평소 가고 싶었던 기업이 있었는데, 그곳에서 일하는 분이 글또에 있어서(!) 업무에 대해 질문도 할 수 있었고 좋은 면접 기회도 얻었다. 내가 그동안 분석가의 역할을 굉장히 단편적으로 이해하고 있었다는 것을 알게되기도 했다. 비록 면접은 떨어져서 슬펐지만.. 커피챗 하면서 일 이야기를 많이 들려주셔서 너무나 감사했다.

3. 배움의 연속 글또의 최대 장점은 관심있던 분야의 다른 사람의 글을 읽을 수 있다는 것이고, 두번째 장점은 마감이다. 마감때문에 일단 쓰게된다. 평소라면 여러 글감중에서 고르고 고르다 결국 몇 개월동안 아무런 글 마무리도 짓지 못했을 것이다.

마감에 쫒겨 쓰는 과정이 괴로운 날도 많았지만 다른 사람이 올린 글에 동기부여를 받아 글을 일단 쓰게 되고, 정리하고 나면 생각도 정리되고 공부도 됐다. 이미 알고 있다고 생각한 주제임에도 글로 정리하다보니 뭐라 설명하기 어려운 애매한 용어들을 수정할 수 있었다. 덧붙여 취준 기간에 번아웃되기 쉬운데, 글또는 2주마다 마감이 있었던 덕분에(?) 그럴 틈이 없었던 것 같다. 이걸 글로 내놓아도 되나.. 싶은 정도의 퀄리티 글인데도 피드백으로 공부할 키워드를 알려주셔서 감사했음...

4. 글또 이전과 달라진 점? 글또 이전에는 내 글을 누가 읽는다는 상상을 해본적이 없고, 그저 예상 독자를 미래의 나로 가정하여 공부한 내용을 까먹지 않기 위해 글을 작성했다. 그런데 글에 대한 피드백을 받고 다른 분들이 쓴 글을 읽으면서, 내 방식을 바꿔봐야겠다는 생각이 들었다.

그럼 어떻게 글을 작성해야하나? 에 대한 질문에 대해 고민하고 있을 때, 이런 미디움 글 을 발견했다. <개발자의 성장 가능성은 어떻게 측정 가능한가?> 라는 제목의 글인데, 이 글에 따르면 A라는 기능을 이해하는 과정은 이렇다.

• 기존에 어떻게 동작했는가?
• A는 어떤 부분을 해결하였는가?
• A는 어떻게 동작하는가?
• 기존 코드에서 어떻게 A를 사용한 코드로 바꿀 수 있는가?

글이 안 써져서 머리를 쥐어 뜯는 와중에 도움을 받은 글이었다.

마무리

글또를 안 했다면 어땠을까? 싶은 생각이 들만큼 5개월동안 내게 큰 변화가 있었던 것 같다. 그 말은 즉.. 글또가 아니었다면 아마 내 블로그는 텅텅 비어있지 않았을까..? 다음 기수에도 지원할 수 있다면 꼭 참여하고 싶다!

언제 AB 테스트를 쓸까?

• 유저의 클릭율이 높은 썸네일이 뭘까? (ex. 유튜브, 넷플릭스)
• A 기능의 UI를 개선해볼까?
  • 전환율을 높이려면 총 4가지 UI 후보 중 어떤 후보를 선택할까?
  • 전환율이 0.3% 개선되었다면 이게 얼마나 영향이 있는 개선인가?
• B 기능을 추가하면 유저의 구매전환율이 높아질 것 같은데, 실제로 그럴까 or 예상치 못한 불편함을 주진 않을까

위 그림은 당근마켓 블로그 에서 소개한 키워드 알림 버튼의 위치를 변경했던 예시다. 왼쪽이 기존 방식이고, 오늘쪽이 변경된 모습이다. 검색 결과 상단에 키워드 등록, 검색 필터, 거래 완료 안 보기 기능 등이 모여 있는 것이 복잡하다고 판단하여 유저의 탐색에 방해되지 않도록 서비스 UI를 개선하려 했다고 한다.

ABCD 테스트는 어떻게?

위 그림 예시처럼 두 가지 후보 중 하나를 골라야할 때, t-test로 실험을 설계하면 통계적 유의성을 검증하며 더 나은 후보를 선택할 수 있다. 그런데 만약 후보가 3개 이상일 때는 어떻게 실험을 설계할까? 이번 글에서는 AB 테스트의 실험 대상이 A와 B 두 집단만 있는 것이 아니라 A,B,C,D 처럼 여러 여러개의 후보가 있을 때, Muticlass AB Test 실험 설계 과정은 일반적인 AB 테스트와 어떤 차이점이 있는지 작성했다.

1. 예시 : 쿠폰 디자인 개선하기

유저에게 프로모션 쿠폰을 뿌린 다음, 유저가 그 쿠폰을 구매에 이용하는 비율을 쿠폰 환수율(Redemption Rate)이라고 부른다. 쿠폰 환수율을 높이기 위해 디자인 UI를 개선하고자 한다. 다음과 같은 후보가 나왔다.

• 기존 Design
• Design A
• Design B
• Design C

redemption rate을 측정하는 방법은 다음과 같다. 정해진 실험 기간동안 총 4 가지 후보 중 랜덤하게 디자인을 노출하고 각 유저 그룹마다 총 유저수(Target), 쿠폰 사용 수(Redeemed)를 기록한다. 분모를 Target, 그리고 분자를 Redeemed 으로 하여 Redemption Rate을 기록했고 그 결과는 다음과 같다. (이 예시는 이 곳에서 가져왔다.)

• Table 1

2. 실험 설계

실험 목적

• 디자인 UI 를 개선해서 기존보다 쿠폰 환수율(Redemption Rate) 높이기

유의수준 정의

• 유의수준은 귀무가설을 기각할지 여부 결정하는 기준으로, 실험 결과인 p-value가 유의수준보다 작으면 귀무가설을 기각하고, 크면 기각하지 않는다.
• 따라서 유의수준은 p-value를 계산하기 이전에 미리 정한다. 보통은 유의수준을 0.05로 설정한다.

실험1. 모든 디자인에서 쿠폰 환수율이 동일한가?

• 귀무가설 : 모든 디자인에서 쿠폰 환수 비율이 동일하다.
• 대립가설 : 적어도 하나의 디자인의 쿠폰 환수 비율 다르다.

샘플로 수집한 쿠폰 환수 여부 데이터는 categorical 변수이다. (Redeemed / not Redeemed) 따라서 두 개 이상 그룹의 categorical 변수의 분포를 비교하는 테스트인 Chi-Squared Homogeneity Test를 사용한다.

1. (Redeemed, not_Redeemed) 를 컬럼으로 하는 DataFrame 생성

import pandas as pd

target = [8333, 8002, 8251, 8275] # existing, A, B, C
redeemed = [1062, 825, 1289, 1278]

not_redeemed = [] # target - redeemed
for a, b in zip(target, redeemed):
    not_redeemed.append(a-b)

data = pd.DataFrame({'redeemed' : redeemed, 'not_redeemed' : not_redeemed})

2. Chi-Squared Homogeneity Test

from scipy.stats import chi2_contingency
# ref : https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.chi2_contingency.html

stat, p_value, df, expected = chi2_contingency(data)
print(stat, p_value)
#### 결과 : 131.88996393138655 2.117192550458385e-28

테스트에서 사용할 검정통계량은 귀무가설 하에서 Chi-Squared 분포를 따르고, scipy.stats 라이브러리를 통해 검정통계량 값(stat)과 이에 해당하는 p-value 를 구할 수 있다. 결과를 보면 p-value값이 유의수준(0.05)보다 낮다. 따라서 귀무가설이 기각된다.

결론적으로 모든 디자인의 쿠폰 환수율이 같지 않다고 할 수 있다. 적어도 하나의 디자인이 쿠폰 환수율이 다르다고 판단하고 다음 스텝으로 넘어간다.

(만약 이 단계에서 귀무가설이 기각되지 않는다면? 다음 스텝으로 넘어가지 않고, 기존 디자인 UI를 유지하는 결론을 내릴 수 있다.)

실험2. 어떤 디자인의 쿠폰 환수율이 가장 높은가?

쿠폰 환수율이 가장 높은 디자인 UI를 찾기 위해 t-test를 반복적으로 수행한다.

• *언제까지 반복? *
  • 통계적으로 유의한(significant) 결과를 얻기 전까지 반복
• 순서는 어떤 기준으로 정함?
  • Table 1 에서 Design B > Design C > Existing Design > Design A 순으로 쿠폰환수율이 높았다. 실험 목적은 "쿠폰 환수율이 가장 높은 디자인"을 찾는 것이므로, 가장 높은 환수율을 기록했던 B가 C보다 환수율이 높은지부터 테스트한다.

1. "Design B vs Design C" One-tailed t-test

• 귀무가설 : 두 그룹의 쿠폰 환수율이 같다. (Design B = Design C)
• 대립가설 : 디자인 B의 쿠폰 환수율이 더 높다. (Design B > Design C)

비율을 비교하는 테스트이므로 t-test for proportion을 사용한다. 두 그룹의 샘플 사이즈가 충분히 크기 때문에 CLT(중심극한정리)에 의해 z-test for proportion을 사용한다.

from statsmodels.stats.proportion import proportions_ztest

stat, p_value = proportions_ztest([1289, 1228], # redeemed Design B vs Design C
                                  [8251, 8275], # target Design B vs Design C
                                  alternative='larger')
print(p_value)
### 결과 : 0.08079746727160886

검정통계량은 귀무가설 하에 z 분포를 따르고, statsmodels.stats.proportion 라이브러리를 통해 검정통계량 값(stat)을 구하고 이에 해당하는 p-value 를 구할 수 있다. 결과를 보면 p-value값이 유의수준(0.05)보다 높다. 따라서 귀무가설이 기각되지 않는다.

결론적으로 Design B와 Design C의 쿠폰환수율은 비슷한 수준이라고 말할 수 있다. (B가 C보다 쿠폰환수율이 높다고 말할 충분한 근거가 없다.)

(만약 이 단계에서 귀무가설이 기각된다면? Design B가 가장 높은 환수율이라고 결론내릴 수 있으므로 다음 스텝으로 넘어가지 않고 테스트를 마무리한다.)

• 참고 : t 분포 대신 z 분포를 쓸 수 있는 이유

위 그림은 z-분포(초록색)과 자유도(degrees of freedom) 에 따른 t-분포를 그린 결과이다. 자유도는 샘플사이즈에 비례한다. t-분포는 자유도가 커짐에 따라 z-분포에 근사해간다고 알려져있다. 또한 CLT라는 개념이 있는데, 주어진 데이터가 어떤 분포를 따르건, 표본 평균(샘플을 표본이라고 한다)의 분포는 z분포에 근사해간다는 정리(Theorem)이다.

2. "Design BC vs Existing Design" One-tailed t-test

Design B와 Design C를 한 그룹으로 합쳐서 Segment BC라는 새로운 Segment를 만든다. 그리고 B와 C 다음으로 환수율이 컸던 Existing Design 과 비교하는 One-tailed t-test 를 수행한다.

• 귀무가설 : 두 그룹의 쿠폰 환수율이 같다. (Segment BC = Existing Design)
• 대립가설 : Segment BC의 쿠폰 환수율이 더 높다. (Design BC > Existing Design)

# Design B와 Design C를 한 그룹으로 합쳐서 Segment BC 
stat, p_value = proportions_ztest([1289+1228, 1062], # redeemed Segment BC vs Existing Design C
                                  [8251+8275, 8333], # target Segment BC vs Existing Design
                                  alternative='larger')
print(p_value)
### 결과 : 6.795738359244353e-08

p_value가 유의수준(0.05)보다 낮으므로 귀무가설이 기각된다. 통계적으로 유의한(귀무가설 기각됨) 결과가 나왔으니 t-test는 다음 스텝으로 가지 않고 종료한다.

결론적으로 Design B와 Design C는 기존 디자인에서보다 쿠폰 환수율이 높다고 말할 수 있다. 또한 Design B와 Design C의 쿠폰 환수율은 비슷한 수준이다. (=차이가 유의하지 않다.) 따라서 둘 중 무엇을 Best UI로 선택할 것인지는 의사결정권자에게 달려있다.

질문들

여기까지가 간단한 예시를 통해 알아본 Multiclass AB Test 이고, 정리하다가 생긴 몇 가지 질문들을 정리해봤다.

1. 왜 t-test를 여러번 하면 안 되는가? - 실험1

• 귀무가설 : 모든 디자인에서 쿠폰 환수 비율이 동일하다.
• 대립가설 : 적어도 하나의 디자인의 쿠폰 환수 비율 다르다.

예시처럼 디자인 후보가 4개라면, 이중 두가지를 고르는 경우의 수만큼 Multiple t-test를 수행하면 되지 않을까? 결론적으로 그렇게 하지 않는 이유는 테스트를 여러번 할수록 Type 1 Error가 증가하기 때문이다.

Type 1 Error = 귀무가설이 실제로 맞을 때, 귀무가설을 기각할 확률

4개의 그룹 중 2개를 고르는 조합의 수는 4C2=6 이다. 이렇게 총 6번의 t-test를 수행하기로 하고, 각각의 테스트는 서로 독립이며 유의수준은 0.05로 설정했다고 하자. 이 실험의 Type 1 Error를 계산하면 다음과 같다.

*Type 1 Error * $= P$(6번의 테스트에서 귀무가설이 하나라도 기각 |귀무가설이 실제로 맞음) $= 1 - P$(6번의 테스트에서 귀무가설이 모두 기각 안 됨 | 귀무가설이 실제로 맞음) $= 1 - (1-0.05)^6$ $= 0.265$

※ 1번의 테스트에서 $P$( 귀무가설이 기각 안 됨 | 귀무가설이 실제로 맞음) $= 1-0.05$ 이다. 테스트끼리는 서로 독립이므로 테스트 숫자만큼 제곱한다.

하나의 테스트를 수행할 때는 Type 1 Error가 0.05였다. 반면 6번의 테스트를 수행하는 실험에서는 Type 1 Error가 0.265로 높아진다. 귀무가설을 잘못 기각할 확률이 5%에서 26.5%로 높아진다는 말이다. 따라서 실험을 설계할 때는 테스트를 최대한 적게 세팅해야지 Type 1 Error 증가를 방지할 수 있다.

2. 여러 집단을 비교하니까, ANOVA를 쓰면 안 되나? - 실험1

• 귀무가설 : 모든 디자인에서 쿠폰 환수 비율이 동일하다.
• 대립가설 : 적어도 하나의 디자인의 쿠폰 환수 비율 다르다.

실험 1에선 귀무가설과 대립가설을 정의하고 Chi-squared homogeneity test 로 실험 했다. 그런데 ANOVA 역시 여러 집단을 비교하는 통계 테스트 기법이다.

ANOVA : Analysis of Variance

• 2개 이상 그룹의 평균을 비교하는 테스트
• 필요한 가정(Assumption)
  • 정규분포 따라야함. (히스토그램으로 분포 확인 혹은 Q-Qplot 정규성 검증으로 확인)
  • 등분산성 만족
  • 각 관측치는 독립
• SST = SSW + SSB
  • SSW : 그룹 내부의 관측치와 그룹 평균의 차이를 Sum of Square
  • SSB : 그룹 평균과 전체 평균의 차이를 Sum of Square
• 검정통계량 F = {SSB/df_B} / {SSW/df_w} 는 귀무가설 하에, F분포를 따름

Chi-squared homogeneity test와 ANOVA의 차이는 무엇일까?

• 공통점 : 두개 이상의 그룹에서, 특정 변수의 분포가 동일한지 확인하는 테스트
• 차이점 : 그 변수가 Categorical 하다면 Chi-squared Test를, Continuous 변수가 포함되어 있다면 ANOVA 를 쓴다.

간혹가다 데이터 전처리 과정에서 Continuous 변수처럼 보이지만 Categorical 변수인 경우가 있다. 예를 들어, 값이 0 또는 1로 구성되어 있지만 0보다 1이 큰 것이 중요하다는 숫자로서의 의미가 없다면, 해당 변수는 Categorical 변수이다.

마무리하며

1. 가정의 중요성

테스트를 선택하기에 앞서, 테스트의 가정이 맞는지 확인하는 것이 중요한 것 같다. 예를 들어, 특정 기능 도입이후 구매 전환율을 기록했다고 하자.

아래 테이블에서, 구매 전환율은 대조군(Control)은 2%, 실험군(Test)에서 1.7% 로 0.3% 가량 감소했다. 이 0.3% 감소가 통계적으로 유의한 감소인지 확인하기 위해 테스트를 진행하려고 한다.

• Table 2 (출처)

주어진 데이터는 Payers와 Non-Payer 사이의 불균형이 심하다. 이렇게 카테고리가 불균형하거나 특정 그룹의 샘플 사이즈가 매우 작은 경우에는 Chi Square Test를 쓰지 않고 Fisher Exact Test를 쓴다. (Chi Square Test 가정 : 데이터가 불균형하지 않고 샘플 사이즈가 충분히 커야함.)

Python은 라이브러리가 잘 되어 있어서 AB Test를 할 때 검정통계량의 수식이 어떻게 구해지는 지에 대한 내용은 크게 중요하지 않아 보인다. 대신, 사용하려는 테스트의 가정이 주어진 샘플 데이터에서 만족되는지 체크하는 절차가 중요한 것 같다. 위 예시처럼 불균형이 심한 데이터의 경우, Chi Square Test의 가정을 만족하지 못하므로 대안으로 Fisher Exact Test를 써야한다.

2. 실험 목적의 중요성.

Multiclass AB Test에서 실험을 최대한 적게 하려면 실험 목적을 구체적으로 설정하는 것이 중요하다는 것을 알게 되었다. 위의 예시에서 "만일 4가지 디자인의 쿠폰 환수율 순위"를 구하는 것이 목적이었다면, 불필요한 t-test를 추가로 수행하여 Type 1 Error가 높아졌을 것이다.

출처

1. Multiclass AB Testing

2. ANOVA in ABC test

3. Parametric Test vs Non Parametric Test

8월 세미나 주제 '데이터 분석가 채용의 모든 것'

• 데이터리안의 이보민님의 '이력서는 서비스여야 한다'
• 마이리얼트립 양승화님의 '데이터 분석 채용 이야기'
• 데이터 분석가 6인의 질의응답

1. 이력서는 서비스여야 한다

느낀점.

• 이력서를 적어도 한 달에 한번은 지속적으로 업데이트해야겠다
• velog는 분석 툴이 없으니.. 네이버 블로그를 가지고 유입 경로, 유입 검색어 분석을 해봐야겠다.

강연자 : 이보민님(데이터리안 데이터 분석가) 강연 대상 :

• 데이터 역량을 어필하고 싶은 모든 직군
• 이력서 순서가 어려운 구직자
• 분석 프로젝트 데이터를 어디서 얻고 어떻게 진행해야할지 궁금한 사람
• 데이터 분석가로 직무전환할 때 사이드 프로젝트로 어떤 활동을 추천하는지 궁금한 사람

강의 슬라이드는 이곳에 있습니다.

1.1 이력서를 왜 웹서비스로 만들었나요?

이전 직장이 채용 플랫폼이다보니 채용 서비스를 업그레이드하기 위해 다양한 채용 공고와 경로를 찾아보게 되었는데, 사이트별로 이력서를 따로 등록해야하는 것이 구직자 입장에서 귀찮은 일이라고 생각했다.

그래서 노션 웹으로 만들어서 페북으로 공유해봤는데 생각보다 반응이 있어서, oopy로 데이터 분석툴을 연동시켜 데이터를 확인해보기로 했다.

1.2 사람들이 내 이력서를 어떻게 보고 있는지 알고 싶다

이력서 데이터를 보고 개선점을 찾기 위해 사용자 행동 데이터를 확인했다. (ex. 웹사이트 페이지뷰, 스크롤, 클릭 등의 사용자 행동 패턴 파악기)

이력서도 마치 서비스처럼, 사용자들이 내가 설계한 경험 루트에 따라 최종 목적지까지 도달하고 있는지 확인하기 위해 직접 퍼널을 설계하고 퍼널 분석을 수행했다.

• 이 이력서의 목적 : 이 이력서를 보는 사람들이 이직이나 강연을 제안

1.3 분석

다음은 보민님이 설계한 이력서 사이트 퍼널의 분석 결과이다.

퍼널1) 이력서 사이트 접속

Q. 얼마나 많은 사람들이, 어떤 사람들이, 어느 경로로 방문?

• 최근 28일 접속자 추이를 먼저 확인.
• 기기별 사용자 분포를 확인(Desktop:87.1%, Mobile:11.1%, Tablet:1.7%)하니, 모바일쪽 UI는 신경 별로 안 써도 되겠다고 판단.
• 홍보 리소스 대비 유입량 많은 채널 확인 (최근 14일)
  • direct/none 이 가장 많았다. (식별 불가능한 유입)
  • 이외 식별 가능한 채널을 확인했을 때
    • 구글 검색으로 들어오는 트래픽이 가장 많음. (organic : 자연적으로 발생한 유입. 보통 검색으로)
    • datarian 블로그 유입
    • 유튜브를 통해서도 유입됨

퍼널2) 이력서 열람

Q. 스크롤은 어느정도? 세부 내용은 클릭했을까?

• 10% / 50% / 80% 스크롤 기준으로 이벤트 수, 총 사용자, 페이지뷰 대비 전환율을 확인. (최근 14일)
• click 데이터로 페이지뷰 대비 클릭 전환율을 확인하여, 접속자 중에서 상세 내용을 클릭해본 사용자가 얼마나 많은지 확인.

퍼널3) 연락처(email, SNS)클릭

Q. 최종 목적지에 잘 도달하고 있는가?

• 전체적으로 링크드인 클릭수가 가장 높았음. (최근 14일)
• 유입 채널별로 어떻게 다른지도 확인 가능.
• 전환수가 가장 많은 유입경로는 구글 검색.
  • 하지만 전환율(접속자 수 대비 유입 전환 수)은 유튜브 채널이 높았음.

그래서 어떻게 개선하지?

퍼널 단계별 전환율은 위와 같은데.. 어떤 지표를 개선하지?

1. 전환율을 높여보자.

• "이메일 보내기" CTA 버튼 클릭 전환율이 낮았음. 덜 부담스럽게 문구 변경
• 직접 메일 보내는 링크들을 빼고 링크드인으로 일단 일촌 신청 유도하기

2. 이력서 세부사항까지 읽게 해보자.

처음에는 이력서 페이지 이탈을 우려해서 세부사항은 토글로 만들고 이벤트를 심어놓았는데, 많이 클릭하진 않았다. 하지만 이 이력서를 보는 사람이 이런 세부 내용까지 잘 확인했으면 좋겠어서 토글 대신 펼쳐놓기로.

• 이후 모니터링할 지표 : 스크롤 비율에 변화가 있는지

3. 신규 유입경로를 발굴해보자.

유입 경로별 전환율을 확인했을 때, 유튜브가 제일 전환율이 높았다. (이걸 근거로 어떻게 신규 유입 경로를 발굴할 수 있는 건지는 잘 이해가 되지 않았음)

1.4 이력서, 웹서비스처럼 만들어야하는 이유 4가지

1. 보는 사람을 고려해서 내용을 작성하게 된다.
2. 이력서의 실패는 나의 실패가 아니다.
3. 퍼스널 브랜딩을 할 수 있다.
4. 이력서 만드는 과정을 나만의 프로젝트로 만들 수 있다.

이부분에서 인상깊었던 것이, (타겟으로 설정한) 인사담당자의 입장을 고려해서 이력서를 작성할 수 있다는 것이다. 머리로 이해하더라도 그게 쉽지 않기 때문에, 차라리 이력서를 웹서비스처럼 만들다보면 인사담당자 분들이 어떤 식으로 페이지를 읽고 어떤 생각을 할지 조금 감이 잡힐 수도 있다는 것이다.

이력서를 웹서비스처럼 만들면, 내 이력서에 어떤 문제가 있는지 실마리를 찾기가 쉬워질 수도 있다. 이를 위해 이력서를 한 번 업데이트해서 그치는 게 아니라 지속적으로 수정하면서 지표를 확인해야한다.

2. 마이리얼트립 양승화님의 '데이터 분석 채용 이야기'

질답형식으로 이뤄진 시간이었는데 신입 분석가로 지원하는 과정에서 마침 고민하고 있던 내용들이 많았다.

Q. 이력서를 차별화하려면?

채용을 하다보면, 뽑는 사람입장에서 비슷한 이력서와 경험이 많다. 뽑는 입장에서는, 결과물보다는 왜 그런 분석을 했는지, 혹은 왜 그런 교육 과정을 선택했는지가 더 궁금하다. 경력 채용이라면 스킬셋보다는 실제로 어떤 성과를 내고 어떤 임팩트를 만들어봤는지가 중요하다.

최근에 봤던 한 면접에서 내 프로젝트 경험에 대해 '구체적으로 어떤 문제를 풀고자 했는지, 이 결과로 어떤 임팩트를 만들어낼 수 있을지'를 물어보셨다. 나는 '데이터를 들여다보다가 이러이러한 특징을 발견했고, 그걸 활용해 결과(ex. 모델 성능)를 이만큼 개선했다'와 같이 답변했는데, 말하고 보니 질문 의도와 다른 답변이었다.

데이터 분석가에게는 구체적인 숫자보다는, 지표를 어떻게 정의했는지, 왜 그렇게 기준을 잡았는지, 그리고 어떻게 지표를 측정했는지가 더 중요한 것 같다는 느낌을 받았다. 지난 프로젝트들을 회고하면서 이부분을 다시 정리하고 있는데 쉽지 않은 것 같다.

Q. 데이터 분석가 채용 면접에서 특히 중요하게 보는게 있는지, 그걸 검증해보기 위해서 특별히 해보는 질문이 있는지?

• 우선 채용은 (드러나지 않은) 상황이 많이 작용한다고 생각한다. 팀에 필요한 사람을 찾다보니 그렇다.

• 면접 때는 지원자를 움직이게 하는 키워드가 무엇인지를 많이 물어본다. (성장인지, 좋은 동료인지, 특정 카테고리의 서비스인지, 혹은 특정 경험인지..)

• 그래서 이전에 어떤 성과를 냈는지를 많이 보는 것 같다. 이전 회사를 왜 떠나려고 하는지도 질문한다.

• 예를 들어, 시니어 분석가가 있는 곳에서 배우고 싶은 지원자라면. 채용 담당자 입장에선.. 우리 회사에 시니어가 다 사라지면, 떠날 사람인가? 하는 생각이 들 수도 있다. 만약 '시니어가 있으면 이런 임팩트를 더 낼 수도 있을 것 같다.'고 하면 납득 가능한 이유일 것 같음.

이와 비슷하게, '내가 가진 프로젝트 이력이 어필이 가능할까?'는 구직자 입장의 질문이고, '이 프로젝트의 문제들이 회사에서 필요한 문제일까?'는 채용자 입장의 질문인 것 같다. 그래서 내가 지원하는 회사가

• 어떤 데이터를 가지고 있고
• 어떤 문제를 풀고자 하는지

직접 물어보거나, 물어볼 수 없다면 내가 스스로 가정을 해서 내가 이러한 부분을 기여할 수 있다고 말해야겠다.

Q. 공부하는 방식에 대해

공부에도 단계가 있다고 생각한다.

• 1단계 : 책으로 몰랐던 것을 알게됨.
• 2단계 : 배운 것을 써먹어봄. 가능하면 업무에 적용해보기.
• 3단계 : 적용한 것을 기록하고 공유하기.

그래서 공부한 것을 블로그 글로 정리하거나, 세미나로 강의하는 것을 권장하는 편.

책 추천

• 린 분석(엘리스테어 크롤, 벤저민 요스코비츠 저)
• 빅데이터를 활용한 예측마케팅 전략(외머 아튼, 도미니크 레빈 저)
• 틀리지 않는 법(조던 엘렌버그 저)
• 디맨드 (에이드리언 슬라이워츠키, 칼 웨버 저)
• 진화된 마케팅 그로스 해킹 (션 엘리스, 모건 브라운 저)

Q. 마지막으로 데이터 분석가 채용을 하고 계시는 시니어 분들에게, 그리고 지원을 막 해보고 있는 주니어 분들에게 각각 한 말씀 부탁드리면

• (주니어에게 드리고 싶은 말씀은) 데이터 분석은 문제 해결이다. 문제 해결 방법, 더 나아가서 좋은 문제 찾기가 중요하고.. 이 부분에 초점을 맞춰서 이력을 쌓아가고 어필하면 채용에 좋은 결과가 있을 것이라 생각함.
• 완벽하지 않은 환경이라도 주어진 여건에서 최소한 어떤 것을 이루어냈고, 어떤 것을 하려고 시도했는지를 중요하게 본다.
• (시니어분들에게 드리고 싶은 말씀은) 데이터 분석은 뛰어난 개인이 하기에는 한계가 있다고 생각. 그래서 조직이 데이터로 일하는 환경인지, 잘 받아들이는 문화인지가 중요하다고 생각함. 이런 부분을 신경쓰시면 좋을 것 같다.

마무리하며

호기심에 세미나를 신청했는데, 뜻밖의 회고를 할 수 있어 좋은 시간이었던 것 같다. 이전 프로젝트들을 정리하면서 '지금 했다면 무엇을 다르게 했을 것인지' 이전 분석의 문제점을 정리하는 글도 써봐야겠다.

관측치로 하나의 스칼라 값이 들어간 것이 아니라, 마치 dict 타입처럼 저장된 방식이었다. (위 예시에선 totals column처럼)

왜 이러한 형태로 저장하는지, 그리고 totals column에 들어 있는'visits','hits','pageviews' 데이터는 SELECT문으로 어떻게 조회할 수 있을지 정리했다.

글의 순서는 다음과 같다.

1. Nested Data란?
2. Repeated Data란?
3. Nested & Repeated Data란?
4. 데이터를 배열로 저장하는 이유

1. Nested Data

• datatype : RECORD (STRUCT 라고도 표현함)

pets, toys 테이블이 있다고 가정하자.

• pets는 동물 정보가 담긴 테이블이고, toys은 동물이 가지고 노는 장난감 정보가 있다.

이 두 테이블을 오른쪽처럼 하나의 테이블 pets_and_toys로 합칠 수 있다. pets_and_toys의 "Toy" 칼럼안에 Name, Type 필드가 동시에 포함된 형태를 "Nested 되어있다"고 표현한다.

-- "pets_and_toys" 테이블 생성
SELECT
    p.ID,
    p.Name,
    p.Age,
    p.Animal,
    STRUCT(t.Name, t.Type) Toy
FROM
    pets p
    LEFT JOIN toys t ON p.ID = t.Pet_ID

데이터 접근 방법

• Nested Data에 포함된 Name 값은, Toys.Name의 형식으로 접근할 수 있다.
• 예시

2. Repeated Data

• datatype : REPEATED

만약 동물(pets)마다 가지고 있는 장난감(toys)이 여러개라면? Repeated 타입을 쓸 수 있다. pets 테이블과 toys_type 테이블을 합쳐서, 오른쪽 pets_and_toys_type과 같은 테이블을 생성할 수 있다.

-- "pets_and_toys_type" 테이블 생성

--- (1) 임시 테이블 repeated_toys 생성 : repeated column인 Toys 만들기
WITH repeated_toys AS(
    SELECT
        Pet_ID,
        ARRAY_AGG(Type ORDER BY ID) Toys
    FROM
        toys_type
    GROUP BY
        Pet_ID
)

--- (2) LEFT JOIN
SELECT
    p.ID,
    p.Name,
    p.Age,
    p.Animal,
    r.Toys
FROM
    pets p
    LEFT JOIN repeated_toys r ON p.ID = r.Pet_ID

(1) 임시 테이블 repeated_toys 생성 : nested column인 Toys 만들기

• [Frisbee, Bone, Rope] 와 같은 Repeated Data를 생성하기 위해서 ARRAY_AGG(col) 함수를 사용한다.
  • ARRAY_AGG(col)는 ARRAY(배열)을 리턴한다.
  • Repeated 필드인 Toys에 입력된 값들은 ARRAY(배열) 데이터이다.
  • 배열 데이터는 순서가 있고(ordered list), 동일한 datatype으로 구성되어있다.
• Pet_ID를 기준으로 배열 데이터(Repeated Data)를 생성하고자 하므로 GROUP BY Pet_ID 구문이 필요하다.

(2) LEFT JOIN

• pets 테이블과 repeated_toys 테이블을 Pet_ID 를 기준으로 LEFT JOIN 한다.
  

데이터 접근 방법

• Toys 내부의 배열 데이터에 접근하려면, UNNEST 함수(in Bigquery)를 이용한다. (UNNEST 함수는 이어지는 3장에서 정리)
• 예시

3. Nested and Repeated Data

• datatype : RECORD and REPEATED

Nested 되어있으면서 Repeated 형태의 데이터 타입도 가능하다. 오른쪽 more_pets_and_toys 테이블의 Toys 필드는 Nested and Repeated Data이다.

-- "more_pets_and_toys" 테이블 생성
--- (1) 임시테이블 nested_repeated_toys 생성 
WITH nested_repeated_toys AS(
    SELECT
        Pet_ID,
        ARRAY_AGG(
            STRUCT(Name, Type) 
            ORDER BY 
                ID
           ) Toys
    FROM
        more_toys
    GROUP BY
        Pet_ID
)

--- (2) LEFT JOIN
SELECT
    p.ID,
    p.Name,
    p.Age,
    p.Animal,
    n.Toys
FROM
    pets p
    LEFT JOIN nested_repeated_toys n ON p.ID = n.Pet_ID

Toys 칼럼의 datatype은,

• RECORD : Name, Type 값이 Nested 되어있다.
• REPEATED : Toys.Name과 Toys.Type 은 각각 ARRAY이다.

데이터 접근 방법

• 예시

UNNEST(col) 는?

• Repeated 칼럼을 Flatten 하는 함수다.
• 인자로 들어가는 col은 ARRAY 타입이어야한다. ([]로 감싸진 형태)
  • 가능 (O) 예시 : [{'Name':'A', 'Type':1}, {'Name':'B', 'Type':2}]
    • 가능 (X) 예시 : {'Name':['A','B'], 'Type':[1, 2]}
• UNNEST 함수는 FROM 절에서 사용한다.
• Alias를 쓰면 값을 조회하기 편하다.
  • 위 예시에는 Alias를 t로 세팅했고, SELECT 문에서 t.Name, t.Type 형태로 조회했다.

Nested and Repeated Data 예시

WITH nested_repeated_toys AS(
    SELECT
        Pet_ID,
        ARRAY_AGG(
            STRUCT(Name, Type) 
            ORDER BY 
                ID
           ) Toys
    FROM
        more_toys
    GROUP BY
        Pet_ID
)

예시 1: [{'Name':'A', 'Type':1}, {'Name':'B', 'Type':2}] 예시 2: {'Name':['A','B'], 'Type':[1, 2]}

• nested_repeated_toys 테이블의 Toys 칼럼은 <예시 1> 형태다.
• STRUCT 함수와 ARRAY_AGG 함수의 순서에 따라 <예시 1>이 될 수도 있고, <예시 2>가 될 수도 있다.
• Nested and Repeated Data의 예시를 살펴보면 <예시 1>의 형태가 더 많은데, 왜 그럴까?
• (추측으로) <예시 2>라면 조회하기 어려워서 그런 것 같다. <예시 2>는 배열이 두 개 ('Name'과 'Type'에 각각 하나씩) 있기 때문에, 각각의 배열을 Flatten하기 위해 UNNEST 함수를 두 번 써야한다. 반면, <예시 1>은 UNNEST를 한 번만 쓰면 된다.

4. 데이터를 배열로 저장하는 이유

왼쪽 테이블은 Toys 칼럼에 배열을 사용했고, 총 3개 행으로 이루어져 있다. 오른쪽 테이블은 배열을 사용하지 않았고, 총 6개 행으로 이루어져있다.

처음에는 왜 굳이 배열 데이터를 써야하는지 이해가 잘 가지 않았다. 애초에 데이터가 이미 배열 형태로 저장되어있는 경우라면, UNNEST 와 같은 함수를 이용해서 데이터를 조회가능하다는 것은 이해가 갔다.

하지만 데이터를 저장하는 관점에서는, 배열을 사용하는 것이 더 복잡도가 높아질 것이라고 생각했다. (만약 Repeated and Nested and Repeated and Nested, ... 형태라면..? SELECT문으로 조회하려면 굉장히 복잡해질 것 같다..)

<구글 빅쿼리 완벽 가이드> 책에서 관련 내용을 찾아보니, 배열 형태로 데이터를 저장하는 몇 가지 상황을 알게 되었다.

4.1 데이터의 순서가 중요한 경우

분석 작업을 위해 데이터를 가공해 테이블로 저장해두었다고 했을 때, 나중에 그 테이블을 읽을 때 정렬이 유지된다는 보장이 없다. 분석 작업에서 데이터의 순서가 중요하다면, 순서를 저장하기 위해 배열을 사용하기도 한다. (위의 예시의 경우, Toy_Name과 Toy_Type은 순서가 크게 중요하지 않아보인다.)

4.2 반복 가능성 있는 값들을 단일 행에 저장하기

(오른쪽과 달리) 왼쪽 테이블은 pet_ID마다 하나의 행이 보장된다. 배열을 사용하면, 컬럼 간에 일대일 관계를 유지할 수 있다.

단일 행으로 저장하면 JOIN을 사용할 때도 편하다. 위 두 테이블에 각각 새로운 테이블 Snack을 JOIN 한다고 가정해보자. (key값 : Pet_ID)

• Case 1의 경우, 1:N 대응으로 JOIN을 수행할 수 있지만
• Case 2의 경우, N:N 대응으로 JOIN을 수행해야한다. Pet_ID를 기준으로 Snack Name을 매칭한 결과, 행의 개수가 크게 늘어날 것이다.

책에 언급된 또 다른 예시는 아래와 같다.

*A지역에 위치한 기관들의 세금 신고 기록 데이터가 있다고 하자. * 매년 한 번 세금을 신고하는 기관이 있는 반면, 같은 해 여러 번 세금을 신고하는 기관도 있다. 만일 다음 번에 이 테이블을 조회할 때, 같은 해에 여러 번 세금을 신고하는 기관도 있다는 사실을 잊어버리면 문제가 생길 수가 있다.

어떤 문제가 발생할 수 있을까? 다시 Pets,Toys 테이블로 돌아와 간단한 예시를 들어보겠다.

어느날 예기치 못한 사고(?) 로 동물들이 가지고 있던 장난감을 모두 잃어버렸다. 그리고, Toys 정보에 Toys_Onsale 이라는 정보를 추가했다고 하자.

• Toys_Onsale : 장난감이 현재 쇼핑몰에 판매중인지 여부 (구매가능:1, 구매불가:0)

동물들마다 원래 가지고 있던 장난감을 다시 사주려고 한다. 이때, 가지고 있던 장난감이 모두 단종(Toys_Onsale=0)된 동물이 있을까?

배열 사용 (X) 경우

[ 테이블 명: example ]

장난감이 구매불가한 조건은 Toys_Onsale = 0 이다. 간단하게는 다음과 같은 쿼리를 작성할 수 있을 것이다.

SELECT
    DISTINCT Pet_ID
FROM
    example 
-- pets가 가지고 있는 toy가 구매 불가한 경우(Toys_Onsale=0)
WHERE
    Toys_Onsale = 0 

• 결과

하지만 일부 동물은 구매가능한 장난감과 구매불가한 장난감을 동시에 가지고 있기도 하다. (Pet_ID가 1인 동물은 구매가능한 장난감 2개, 구매불가능한 장난감 1개를 가지고 있다.)

"모든 장난감이 구매 불가한 동물"을 찾기 위해서는 어떻게 해야할까? 다음과 같이 배열을 사용해서 확인할 수 있다.

배열 사용 (O) 경우

-- "nested_repeated_toys" : Toys 칼럼에 배열을 사용 
WITH nested_repeated_toys AS (
    SELECT
        Pet_ID,
        ARRAY_AGG(
            STRUCT(Name, Type, On_sale)
            ORDER BY
                ID
        ) Toys
    FROM
        more_toys
    GROUP BY
        Pet_ID
)

-- 장난감이 모두 구매 불가 상태인 Pet_ID 조회
SELECT
    DISTINCT Pet_ID
FROM
    nested_repeated_toys
WHERE
    1 NOT IN (
        SELECT
            On_sale
        FROM
            UNNEST(Toys)
    )

WHERE 절에 있는 서브쿼리 SELECT On_sale FROM UNNEST(Toys) 는 아래와 같다. 여기서 On_sale에 1이 포함되지 않은 Pet_ID는 2뿐이므로 최종 결과는 아래와 같다.

• 결과

5. 마무리하며

요약하면 데이터를 배열로 저장하는 상황은 1)데이터를 순서대로 저장하는 것이 중요한 경우이거나, 2)반복 가능성이 있는 값들을 단일 행에 저장하기 위함이다. 특히 두 번째 이유는 데이터 무결성 개념과도 연결된다고 하니, DB 개념을 더 공부해야할 것 같다..

6. ref

참고한 자료

• Kaggle Advanced SQL course

참고한 서적

• 빌리아파 락쉬마난, 조던 티가니 지음 / <구글 빅쿼리 완벽 가이드> / 변성윤, 장현희 옮김