데이터 라벨링 노가다는 이제 그만~!

AWS Community Day는 AWS를 사용하는 개발자 및 고급사용자들이 주축이 되어  AWS 서비스 활용 방법 및 사용 대한 정보를 공유하는 기술 컨퍼런스입니다.

지난 1월 25일, 세종대학교에서 개최된 AWS Community Day – re:Invent특집에서는 지그재그 데이터팀의 성운님이 참석해서 AWS Sagemaker Ground Truth에 대해 소개해주셨습니다.

Ground Truth를 통해 데이터 라벨링 노가다(…)를 어떻게 줄일 수 있었는지, 발표 영상과 그 자세한 내용을 공유드립니다. 영상은 여기서 확인하실 수 있습니다!

 


안녕하세요. 저는 크로키닷컴의 데이터 과학자 소성운이라고 합니다.

저희 크로키닷컴은 여성 쇼핑몰들을 모아서 쉽고 빠르게 보여주는, 개인화된 쇼핑 환경을 제공하는 ‘지그재그’를 운영하고 있습니다. 남자분들에게는 생소할 수 있겠지만 여성 쇼핑 분야에서는 좋은 성과를 보이고 있는 서비스입니다. 1500만 다운로드, MAU 230만, 자체 광고 플랫폼 매출 200억 등 많은 사용자들이 사랑하는 앱으로 자리 잡고 있습니다.

아무래도 쇼핑을 다루는 앱 서비스이다 보니 사용자 데이터 분석, 개인화 추천 등의 분야에 관심을 가지고 있습니다. 자연스럽게 빅데이터 분석을 위한 EMR이나 Glue, 머신러닝을 위한 Sagemaker 같은 서비스에 관심이 많았습니다. 관심을 쫓아가다 보니 현재는 AWS 유저 그룹에서 커뮤니티 활동도 열심히 하고 있습니다.

오늘 함께 나눌 주제는 머신러닝입니다. 보통 머신러닝이라고 하면 모델링 기법이나 최적화에 대한 내용이 주를 이루는데, 이번 세션은 모델 학습에 사용되는 데이터에 대해서 이야기해보겠습니다.

먼저 Amazon Sagemaker라는 서비스를 간략히 소개드리려고 합니다. Sagemaker는 머신러닝 프로세스인 학습과 최적화, 그리고 배포 단계를 서비스 내에 프로세스화한 형태입니다. 모델 학습을 위한 각종 환경 구성을 원클릭으로 설정할 수 있고, 이렇게 구성된 환경에서 자신이 직접 만든 모델로 클라우드 환경에서 학습이 가능하며, 또한 Sagemaker에 내장된 머신러닝 모델 또한 사용이 가능합니다.

개발 경험이 없는 데이터 분석가나 과학자분들은 자신이 공들여 만든 모델을 서비스에 반영하는 게 큰 챌린지인데, Sagemaker에서는 모델의 배포와 API 생성까지 손쉽게 끝낼 수 있습니다. 제가 Sagemaker를 좋아하는 이유이기도 합니다. 일련의 절차들을 모두 자동화하고 프로세스화 하여, 우리가 집중해야 할 좋은 모델을 만들고 검증하는데 많은 시간을 할애할 수 있도록 도와줍니다.

오늘 소개해드릴 Amazon Sagemaker Ground Truth도 같은 맥락의 서비스라고 보시면 됩니다. 별도의 독립적인 서비스는 아닙니다. 기존 Sagemaker 상에 추가된 기능으로, 모델링 이전에 갖춰야 할 학습 데이터의 퀄리티를 어떻게 높일 것인가에 대한 고민의 결과가 만들어낸 산물이라고 생각합니다.

라벨링이라는 작업은 모델 학습에 사용되는 데이터에 정답을 달아놓는 과정입니다. 많이 보셨을 개와 고양이를 분류하는 모델에 비유하자면, 개와 고양이 이미지에 각각 개 혹은 고양이라는 정답을 달아 놓는 작업입니다. 라벨링 작업은 굉장히 힘이 듭니다. 왜 힘들까요? 라벨링 작업은 노가다 작업으로 느껴질 때가 많기 때문입니다. 우스갯소리로 인형에 눈 붙이는 작업이라고도 합니다.

라벨링이 어려운 첫 번째 이유 중 하나는 머신러닝을 위해서는 많은 양의 데이터가 필요하다는 것입니다. 이미지를 분류하기 위해서는 최소 수천, 수만 장의 이미지가 필요합니다.

라벨링이 어려운 두 번째 이유는 사람이 직접 라벨링을 해야 하기 때문입니다. 오른쪽 이미지들은 Image Segmentation을 위한 데이터셋 예제입니다. 단순히 개나 고양이를 분류하는 작업이 아니라 해결하고자 하는 문제가 복잡할수록 필요한 데이터셋도 점점 더 복잡해집니다. 세 번째 이유는 시간을 포함한 많은 비용이 든다는 것입니다. 그리고 무엇보다, 라벨링 작업자가 많아질수록 일관되고 정확한 라벨링 작업이 어려워집니다.

조금 더 이해를 돕기 위해 제가 요즘에 회사에서 고민하는 내용을 간단히 공유 드릴 건데요 여러분들도 같이 생각해봐 주시면 재밌을 것 같습니다.  지그재그에서는 여성 쇼핑몰의 상품들을 손쉽게 검색할 수가 있는데요, 보시는 화면은 저희 앱, 그러니까 검색 기능에서 기본적으로 제공되는 필터 기능입니다. 제가 목도리를 검색하고, 그중에서 파란색 목도리만 보고 싶어서 색상으로 필터를 한 결과인데요. 이 기능이 제공이 되기 위해서는 각 상품마다 색상 정보가 존재해야 합니다. 그렇다면 이 색상 정보는 어떻게 기입을 할까요? 상품의 이미지를 보고 색상 카테고리에 맞게 색상 정보를 기입하면 됩니다. 참 쉽죠?

그런데 지그재그에 3700개의 쇼핑몰이 입점해있고, 하루에만 약 1만 개의 신상품이 업데이트된다는 것을 고려하면 이야기가 달라집니다. 사람이 이렇게 많은 양의 이미지에 일일이 색상 정보를 입력하는 것은 어려운 일입니다. 머신러닝이 이 문제를 해결해 줄 수 있을까요?

처음 시작한 아이디어는 다음과 같았습니다. ‘제품 이미지 상에서 제품의 색상을 RGB로 뽑아내고, 이게 어떤 색상인지 학습시키면 색상을 자동 라벨링 할 수 있는 모델을 만들 수 있지 않을까?’

관련된 내용을 작년 핸즈온 세션에서도 다뤘었는데요. 관심 있으신 분은 아래 링크를 참고해보셔도 좋을 것 같습니다. Https://github.com/yansonz/2018-handson-data-02

이때의 내용을 요약해드리자면, 요즘에는 좋은 Vision API가 워낙 많아서 이미지를 넣으면 위와 같이 대표 색상을 RGB 컬러로 뽑아낼 수가 있다는 겁니다. 그래서 관련된 데이터 셋을 만들어봤습니다. RGB 값과 레이블 필드를 보실 수 있습니다. 그런데 여기서 문제가 있습니다.

RGB 값으로 봤을 때 과연 어디까지를 파란색이라고 볼 수 있을까요?

같은 이미지에 있는 색상이어도 사람마다 기준이 다르기 때문에 어떤 사람은 파란색이라고 하고 어떤 사람은 남색이라고 하겠죠. 라벨링 작업이 일관되게 이루어지기가 굉장히 어려운 상황이 발생합니다. (당시 저희 팀에서 해당 타스크는 저만의 기준을 세워서 혼자 진행했습니다)

이렇게 어렵고, 막막할 수 있는 라벨링 작업이 왜 이렇게 중요한 걸까요?

좋은 머신러닝 모델을 만드는 것은 당연히 좋은 결과를 만들어내는 성공의 열쇠입니다. 그러나 좋은 머신러닝 모델만큼이나 중요한 것은 좋은 학습 데이터 입니다. 좋은 학습 데이터가 좋은 모델을 만드는데 도움이 되기 때문입니다.

장표에 예시로 등장한 데이터셋들은 머신러닝 딥러닝에 관심이 있으신 분이라면 한 번쯤 보았을 것들인데요, 대표적으로 이미지넷 데이터셋을 보았을 때, 총 1400만 개의 이미지를 2만 개가 넘는 카테고리로 라벨링을 해둔 데이터입니다. 다른 것들도 여러 사람이 직접 한 땀 한 땀 라벨링 한, 검증된, 즉 좋은 퀄리티의 데이터셋들입니다. 머신러닝을 공부하실 때는 이런 데이터셋을 바탕으로 만들어진 모델을 리서치하셔서 사용해보거나 그 모델을 바탕으로 자신만의 모델링을 많이 해보시게 됩니다.

그런데 자신만의 비즈니스가 존재할 때는 다양한 문제를 머신러닝으로 실전에서 해결해야 하고, 이 문제들에 맞는 자신만의 데이터셋을 만들어야 할 때가 있습니다. 그때는 지금까지 말했던 많은 문제들에 직면하게 됩니다. 바로 그때 당황하지 마시고 Sagemaker Ground Truth를 써보시면 큰 도움이 됩니다.

왜냐하면 Sagemaker는 이러한 라벨링 작업마저도 머신러닝 프로세스의 일부로 여기고, 이것을 서비스화 시켰기 때문입니다. 또, 아마존이 했기 때문에 기대할 수 있는 것들이 분명 있죠. 완전 관리형, 효율화, 자동화, 확장성 등등 많은 장점들이 있습니다.

Ground Truth에서 제공 가능한 라벨링 작업은 총 5가지입니다. Object Detection에서 사용되는 바운딩 박스 작업, Image Classficiation에 사용되는 형태의 작업, Semantic Segmentation, Text Classifiation 입니다. 여러분들이 람다와 개발코드에 익숙하다면 자신만의 라벨링 작업 환경 또한 직접 구축하실 수 있습니다.

라벨링 작업을 Ground Truth를 통해 하게 되면, 관리 형태의 작업을 할 수 있을 뿐만 아니라 예상치 못한 선물 등의 기능들을 만나보실 수도 있습니다. 예를 들면 액티브 러닝과 오토 라벨링 기능입니다. 우선 간략하게 서비스 데모를 보신 후에 이 기능들에 대해서 이야기해보겠습니다.

작업팀은 라벨링을 다양한 형태로 구성할 수 있는데요. 그 작업팀을 워크포스라 하며, 총 세 가지 형태가 제공됩니다. Public은 간단히 말하면 라벨링 작업을 온라인 프리랜서에게 외주를 주는 것입니다. Private은 데이터의 특수성이나 보안 이슈로 조직 내 팀을 구성하는 형태이고요, Vendor 옵션은 라벨링 전문팀에게 의뢰하는 형태입니다.

데모는 Private 워크포스를 구성하고, 간단한 예제인 개와 고양이의 이미지를 분류하는 모델을 위해 데이터셋을 만든다는 가정에서 진행했습니다. Ground Truth는 아직 서울 리전에 론칭이 되지 않았기 때문에 북미리전으로 진행했습니다.

먼저 Sagemaker 콘솔에 가보시면 상단에 Ground Truth 메뉴가 생긴 것을 확인해 볼 수 있습니다. 작업을 만드는 것은 굉장히 쉽습니다. 메뉴에서 라벨링 잡을 하나 만들면 됩니다.

잡을 만드는 과정입니다. 잡의 이름과 내가 작업할 이미지들이 있는 S3 주소를 넣어줍니다. S3에 이미지 넣어두기 때문에 용량 걱정 없이 수십만 장의 이미지를 넣어두셔도 됩니다. 해당 경로에 이미지가 있으면, 라벨링 작업의 메니페스토라는 json으로 입력값 정리가 됩니다. 마찬가지로 작업의 결과는 지정해둔 아웃풋 s3 경로에 json 형태로 저장이 됩니다. 전에 소개드렸던 라벨링 작업의 형태를 정의할 수 있습니다, 이 데모에서는 바운딩 박스 작업을 해보고자 합니다.

저는 외주작업을 의뢰해서 비용이 많이 나가는 것을 피하고 싶었습니다. 때문에 작업자를 Private으로 지정했고, Private 워크포스 내에는 총 세명의 작업자를 지정해두었습니다. 다음으로 가장 중요한 작업자를 위한 작업환경 페이지 구성인데요. 오른쪽을 보시면 해당 이미지에서 바운딩 박스를 그려야 할 레이블을 명시해두었습니다(여기서는 고양이죠) 그리고 바운딩 박스를 어떻게 그려야 한다는 클리어한 작업설명이 있습니다. 작업설명 부분은 이해하기 쉽고 간결해야 합니다. 때문에 좋은 예와 나쁜 예를 이미지로 보여주는 형태가 가장 효과적이라고 느껴졌습니다.

작업 화면 구성까지가 끝나면 모든 작업환경 구성이 완료가 된 것입니다. 완료가 되고 나면 이와 같이 해당 작업의 상태(전체 이미지 중 어디까지 누가 작업을 진행했는지, 해당 작업의 이미지 정보들이 무엇인지를 볼 수 있는 관리 페이지가 생깁니다.

작업환경 구성이 완료되면 수분 이내에 작업자에게 이메일이 발송됩니다. 이메일에는 작업환경으로 접속할 수 있는 접속 주소, 로그인을 위한 아이디, 비번 정보가 있고, 해당 정보들로 로그인을 하게 되면,

화면에서 과 같이 조금 전에 작업을 구성해둔 페이지 그대로 작업자가 만나볼 수 있습니다. 아래에는 바운딩 박스를 그릴 수 있는 툴이 있으며 할당된 개수의 이미지를 모두 끝낼 때까지 연속적으로 작업 진행이 가능합니다.

작업한 내용은 보시는 것처럼 json 형태로 아웃풋 경로로 지정해둔 S3에 적재되는데, 이 정보들은 원본 이미지와 함께 Sagemaker에서 훈련 데이터셋으로 사용이 가능합니다.

보시는 것과 같이 Ground Truth는 대규모의 라벨링 작업을 수십/수백 명의 작업 자이 무리 없이 진행할 수 있도록, 쉽고 편리한 작업 인터페이스가 제공이 되고 있습니다. 세션 초반에 제품 색상 분류 사례를 소개하면서 여러 작업자들 간의 라벨링의 퀄리티를 어떻게 유지할 수 있을까에 대한 문제를 언급했습니다.

가장 간단하게, 쉽게 떠오르는 방법은 다수결 원칙에 따르는 것입니다. 여러 작업자들 간에 각기 다른 라벨링 결과를 통합할 때를 예로 들어보겠습니다. 왼편의 강아지 사진을 보고 네 명의 작업자 중 세명은 불독, 한 명은 샤페이라고 답했습니다. 그러면 다수결의 원칙에 따라 해당 이미지는 불독으로 분류가 될겁니다. 하지만 이게 최선일까요?

확률 모델을 적용하는 방법도 있습니다. 라벨링 작업을 여러 라운드로 진행하면서, 네 명의 작업자 중 빨간색 작업자의 라벨링의 정확도가 다른 작업자에 비해 높다고 가정해 봅시다. 작업자들의 정확도는 각 사람마다 수치화되어있습니다. 이번 경우에도 이전과 같이 불독, 샤페이, 불독, 불독이라고 대답했습니다. 약간 복잡해 보이는 수식이 나왔지만, 간단히 설명드리면 이 라벨링 작업의 결과가 샤페이일 확률은 불독일 확율보다 10배 높습니다. 그 이유는 작업자의 정확도를 고려하기 때문입니다. 또한 이 라벨링 작업의 결과는 단순히 이 이미지는 불독이다! 샤페이다! 가 아니라 0.9의 Confidence로 샤페이, 0.1의 Confidence로 불독일 것이다라고 분류가 됩니다. 일반적인 다수결 원칙보다 조금 더 합리적이고 나이스 한 결과입니다.

다음으로 말씀드리고 싶은 부분은 액티브 러닝과 오토 라벨링에 대한 부분입니다. 데모 과정에서는 해당 기능을 켜 두진 않았는데요, 작업해야 할 이미지 수가 많은 경우에, 특히 수만 장 이상 이미지를 다뤄야 하는 경우에는 적극적으로 활용해볼 만한 기능입니다.

지금까지 봐왔던 내용들은 작업자를 통해서 라벨링 작업이 이뤄지고 그 결과들을 병합하는 Consolidation 작업까지 이루어진 후에 최종 결과가 산출되는 시나리오였습니다. 도식화된 내용을 설명드리면, Ground Truth에서는 뒷단에 딥러닝으로 학습되는 모델이 존재하고 여러분들의 입력 이미지들을 딥러닝 모델이 자동 분류를 하게 됩니다. 이때 분류의 결과가 지정된 스레드 홀드보다 높은 정확도를 가졌다면 자동으로 라벨링이 되고, 그 이하면 즉 정확도가 낮은 분류라면 사람 작업자에게 보내어 분류가 되도록 워크플로우가 짜여 있습니다. 사람이 분류해낸 결과는 다시 딥러닝 모델의 학습 데이터로 사용되어 라벨링 작업이 진행되면 진행될수록 이 모델의 성능 역시 함께 증가하게 됩니다. 이를 액티브 러닝이라고 하고 사람이 아닌 모델을 통해 자동 분류되는 형태의 라벨링을 오토 라벨링이라고 합니다.

여러분들이 Ground Truth를 이용해서 라벨링 작업을 한다면 별다른 노력 없이 작업 생성하실 때 옵션 체크 유무만으로 이런 베네핏을 모두 가져갈 수 있습니다.

전반적인 성능에 관한 지표들입니다. 범례에 주황색 MTruk는 사람 작업자를 의미하고, 초록색 Auto only는 조금 전에 보신 딥러닝 모델을 통한 오토 라벨링 작업, 파란색 Ground Truth는 이 두 가지 작업을 동시에 이용하는 케이스를 말합니다. 첫 번째 그래프를 보시면 x축을 따라 사람이 진행한 라벨링 수가 증가할수록, 주황색인 사람 작업자의 결과는 그에 맞춰서 선형적으로 증가하는 것을 확인할 수 있습니다. 오토 라벨링의 경우는 처음에 처리되는 라벨링 수가 좋지 못하다가 사람의 작업량이 늘어나면서 모델 학습이 이루어지고 정확도도 증가하면서, 처리되는 작업량도 늘어나는 것을 볼 수 있습니다.

따라서 Ground Truth의 결과는 두 가지 작업의 합산입니다. 동일한 작업 양, 시간 동안 높은 퍼포먼스를 가져갈 수 있다는 것을 확인할 수 있습니다. 바로 아래 그래프는 정확도에 관한 지표입니다. x축을 따라 사람이 라벨링 하는 이미지가 증가할수록 모델의 정확도가 목표한 90% 정확도로 수렴하는 것을 보실 수 있습니다. 오른쪽 상단에 세 번째 그래프는 비용에 관련된 지표인데, 이미지 장당 사람에게 의뢰하는 비용은 5센트로 고정입니다, 모델의 정확도가 증가하면서 실패 확률이 낮아지고 장당 처리되는 비용이 현저히 떨어지는 것을 볼 수 있습니다. 그래서 전반적으로 사람으로 운용되는 라벨링 작업보다 Ground Truth에서 사람과 오토라벨링을 함께 운용하는 것이 비용적인 측면에서도 절감 효과가 있습니다.

아마존 Sagemaker와 신규 서비스인 Ground Truth를 써보면서 느낀 점은 머신러닝을 잘 알건 모르건 간에 일단 시작을 할 수 있게 만들어준다는 것입니다.

여러분들이 머신러닝을 통해서 현실의 문제를 해결하고자 할 때 시작하기도 전에 예상치 못하는 다양한 어려움에 직면하게 됩니다. 작업환경 구축하는 건 너무나 고되고, 모델 학습이나 파라미터 튜닝 과정은 너무 많은 시간이 소요돼서 쉽게 지치기 마련입니다. Sagemaker는 이런 과정들을 프로세스화 했고 쉽게 사용 가능한 툴을 제공함으로써, 자칫 부수적인 작업이라고 느낄 수 있는(흔히 말하는 삽질) 해결하였고, 본래 하고자 했던 더 나은 모델, 정확도가 높은 모델을 만드는데 시간과 노력을 쏟게 해 주었습니다.

신규 서비스인 Groud Truth는 마찬가지로 Sagemaker가 구축해놓은 탄탄하고 유연한 머신러닝 환경 속으로 라벨링 작업을 들여왔고, 퀄리티 있는 대용량의 데이터셋을 구축할 수 있게 해 주었습니다. 여러분들이 자신만의 데이터로 머신러닝 프로젝트를 진행해보고 싶다면 꼭 이용해보시길 바랍니다.

감사합니다.

지그재그 데이터팀과 개발팀에서는 쇼핑 데이터와 관련된 다양한 프로젝트들을 적극적으로 진행하고 있습니다. 지그재그 팀과 함께, 국내에서 가장 많은 패션 데이터를 다뤄보고 싶으신 분들의 지원을 언제나 기다리고 있습니다.

job@zigzag.kr

https://career.zigzag.kr/recruit

지그재그 마케팅팀 채용 공고

현재 팀은 어떻게 구성되어 있나요?

지그재그 마케팅 팀은 CMO 포함 총 5명으로 구성되어 있습니다.

2018년 상반기까지 ‘퍼포먼스’와 ‘브랜드’ 파트로 구분하여 각자 해당 업무만을 담당하였으나, 하반기부터는 파트 구분을 없애고 프로젝트별로 팀을 구성하여 업무를 진행하고 있습니다.

팀에서 중요시하는 가치는

‘임팩트’와 ‘효율화’입니다.

한정된 자원과 시간으로 세상을 변화시키는 것이 스타트업의 숙명이기 때문에 이 두 가지 가치를 우선시합니다.

그리고 이 두 가지 가치를 팀 구성원 모두가 체감할 수 있도록 ‘본질에 집중할 수 있는 업무 환경’을 구축하고자 노력합니다. 중요하지 않은 일이나 왜 해야 하는지 모르는 일 등을 최소화함으로써 확보한 시간을 중장기적 임팩트를 가져올 수 있는 일에 투자하고 있습니다.

그동안 팀이 가졌던 고민과 성장 과정을 소개한다면

Phase 1. 서비스 초기 마케팅어떻게 하지?(2015.6. – )

대개의 스타트업이 으레 겪듯이 자원과 시간은 항상 부족하고 경쟁사는 우리를 뒤쫓아오며 위협합니다. 금전적 자원은 투자를 통해 어느 정도 해결할 수 있지만, 시간은 전적으로 우리의 역량에 달려 있다고 생각했습니다. 지나가버린 시간과 기회는 되돌릴 수가 없기 때문입니다.

그래서 서비스 초기에는 특히 빠른 성장 & 효율적인 마케팅을 중시하였고, 개인적인 선호나 직감에 의존한 마케팅보다는 성과 측정이 가능한 퍼포먼스 마케팅에 집중하였습니다. 다행히 빠르게 성장할 수 있었고 서비스 런칭 6개월 후 100 만 다운로드를 기록하며 첫 번째 투자를 받을 수 있었습니다.

Phase 2. 효율적인 팀 업무 방식은(2016.5. – )

환희님께서 팀에 합류하며 드디어 2인 이상의 팀이 되었습니다. 팀에 다른 색이 추가되어 아이디어 스펙트럼이 넓어졌지만 동시에 업무 협업 방식에 대한 고민 또한 생겼습니다. 과도한 보고 체계나 경직된 위계질서 등으로 인해 ‘1+1 = 2+’가 아닌 ‘1+1 < 2’가 되지 않을까 걱정되었습니다. 효율적인 업무 처리를 위해 가장 기본이 되는 목표와 가이드라인만 제시하고 팀원 개개인에게 권한과 책임을 부여해 스스로 판단하고 진행할 수 있도록 업무 체계를 만들었습니다.

누구의 아이디어 인지보다는 어떤 컨텐츠의 성과가 좋은지를 중요하게 보고자 했습니다. 이와 같은 데이터 기반의 의사결정으로 적은 인력으로도 700만 다운로드라는 긍정적인 성과를 달성할 수 있었지만, 1년 정도가 지난 뒤에는 팀원 간 커뮤니케이션이 줄어드는 부정적인 현상 또한 발생되었습니다.

Phase 3. 관성에서 벗어나기 (2017.11. – )

900만 다운로드 돌파 시점에 브랜드 파트가 신설되며 수진님과 가영님께서 합류하였습니다. 그동안 퍼포먼스 마케팅을 중시하며 효율적인/효과적인 성장을 이뤄왔지만 장기적인 브랜딩을 위해 브랜드 마케팅에 대한 연구와 투자가 필요한 시점이었습니다.

효율적인 업무 및 시간 배분을 위해 (공동 목표 외에) 파트별 목표를 세우고 파트별 회의를 따로 진행하였습니다. 브랜드 파트는 ‘서비스 비전 및 핵심가치 도출, 웹드라마 기획’ 등의 Task를 진행하였고, 퍼포먼스 파트에서는 UA 마케팅을 기존과 같이 진행하였습니다. 각 파트별 진행사항 공유는 팀 주간회의를 통해 이루어졌습니다.

파트별로 어떤 업무가 진행되는지 서로 아는(파악하는) 것에는 문제가 없었습니다. 더불어 파트별 성과 또한 나쁘지 않았습니다. 하지만 각 파트가 왜 그런 결정을 했는지, 프로젝트 진행 과정에서 어떤 레슨을 얻었는지, 상대 파트의 목표를 본인의 목표처럼 중요하게 생각하는지 등에 있어서는 충분히 교감되고 있지 않다는 느낌을 받았습니다.

팀 구조는 브랜드 마케팅으로 확장하였지만 일하는 방식은 효율화‘만’을 우선시했던 기존 관성에 머물러 있다는 것을 깨달았습니다. 이에 저희 팀은 관성에서 벗어나기 위해 팀 구조부터 일하는 방식, 구성원 RnR 등 여러 부분을 토론하며 함께 변화시켜 나갔습니다.

Phase 4. 우리 팀은 서로에게 솔직한가요(2018.6. – )

“지그재그 마케팅 팀은 서로에게 솔직한가요?” 2018년 6월, 혜란님께서 팀에 합류하며 건넨 질문이었습니다.

‘우리 팀은 서로에게 얼마만큼 솔직한가?’

‘일 이외에 감정, 눈치, 계산 등이 없다고 이야기할 수 있는가?’ ‘공동의 목표를 향해 나아가고 있는가?’

일을 오롯이 일로만 바라볼 수 있고 일에 온전히 몰입할 수 있도록, 불필요한 감정과 오해를 털어낼 수 있는 무언가가 필요했습니다. 구성원 모두의 합의하에 1:1 상호 피드백 세션을 가졌습니다. 업무를 하며 상대의 어떤 부분이 좋았고, 어떤 부분이 아쉬웠는지 최대한 솔직하게 나눴습니다. 놀라웠던 부분도 있었고, 부끄러웠던 부분도 있었고, 화가 나는 부분도 있었고, 감사한 부분도 있었습니다.

구성원 모두가 느낀 감정은 저마다 달랐을 테지만 공통적인 생각이 있습니다. 바로 우리는 서로를 신뢰하기 때문에 이 과정 또한 넘어설 수 있다는 점입니다.

“우리 팀은 서로에게 솔직한가요?” 물론 100% 솔직하진 않을 것 같습니다. 불가능하죠. 다만, 솔직한 피드백이 팀 발전에 있어 무엇보다 중요하다는 것은 모두 알게 되었습니다.

앞으로의 포부는

지그재그 마케팅 팀은 그동안 소수 인력 중심으로 효율적인 마케팅을 추구해왔습니다. 그리고 이제는 보다 다양하고 임팩트 있는 마케팅을 위해 팀을 확장하고자 합니다. 다양한 경험과 생각을 지닌 멤버들이 모여 함께 도전하고, 실패를 통해 배우고, 또다시 도전하면서 대한민국 모든 여성이 지그재그를 통해 ‘즐겨. 찾기. 쉬운.’ 쇼핑을 하는 그날까지 함께 성장해나가고 싶습니다.

마지막으로 하고 싶은 말은?

 – 가영: 저희와 다른 당신의 생각과 목소리가 궁금해요. 본인의 생각을 주장하지 않고 설득할 줄 아는 분이라면, 그 생각을 ‘함께’ 실행할 수 있을 거라 믿어요!

 – 정훈: 다양한 경험과 생각, 그리고 자신만의 색을 지닌 구성원들이 모였을 때 더욱더 멋진 일이 일어난다고 믿고 있습니다. 마케팅을 정말 진심 레알 트루 리얼리 좋아하는 마케터라면 주저 말고 지원해주세요. 😀

– 수진: 자신만의 이야기가 있으신 분, 왜?라는 질문을 좋아하시는 분, 마케팅과 지그재그를 좋아하시는 분, 해보고 싶은 게 많은 분. 마케팅 팀에 새로운 색을 더해줄 수 있는 분이라면 모두 모두 환영합니다. 함께 즐겁고 치열하게 지그재그의 다음 이야기를 만들어봐요!

– 혜란: 어떤 멋진 경력보다 언제나 ‘나’보다는 ‘우리’, ‘이 정도까지’보다는 ‘끝까지’, ‘돌려 말하는 눈치’보다는 ‘솔직할 수 있는 용기’가 있는 분이라면 좋겠습니다. 같이 만들어나가요! 파이팅! 많이 지원해주세요!

– 환희: 채용공고를 내면서 ‘어떤 사람과 일하고 싶나?’는 질문에 끊임없이 답해보았습니다. 브랜딩도 잘하고 퍼포먼스도 잘하고… 다 잘하는 마케터!! (사실 그런 분들은 드물지만…) 저희 팀의 욕심이 끝이 없더라고요 하하 네, 생각해보니 저희는 욕심 많은 팀이고 저희 팀에 합류하시는 분도 마케팅에 욕심 많은 분이셨으면 좋겠어요. 어떤 욕심을 가지고 계신지 무엇을 이뤄내고 싶은지 팍팍 어필해주세요. 지그재그 마케팅팀에 새로운 자극을 주고 함께 성 장할 수 있는 분이라면 언제나 환영합니다!!

분석용 이벤트 로그 점검/정리하기 #2

안녕하세요! 저는 개발팀의 오형준입니다. 앞선 글에서 데이터팀의 지형님이 ‘분석용 이벤트 로그 점검/정리하기’라는 Task가 어떤 Task이며, 왜 중요한지에 대해 다루어 주셨는데요. 이번 글에서는 이번 Task의 프로세스, 앱개발팀과 데이터팀 간의 협업 방식, 각 팀의 업무 방식 등에 대해 다루어 보려 합니다!

먼저 간략하게 이 Task가 어떤 프로세스로 진행되었는지 그림으로 나타내면 다음과 같습니다. 각 단계에서 진행한 업무에 대해 차근차근 다루어 보겠습니다 🙂

기존 내용 파악 및 정리

분석용 이벤트 개발 현황을 알지 못한 채로 Task를 진행할 수는 없었기 때문에 가장 먼저 아래와 같이 기존 분석용 이벤트 로그에 대해 파악하고 정리하는 작업을 진행했습니다.

개발팀(형준)

• 개발 현황 파악
– 프로젝트 내 이벤트와 관련된 구조(클래스, 함수 등)에 대해 파악
– 전송 중인 이벤트 파악(이벤트 종류, 이벤트 목록, 전달되는 데이터 등)
– 이벤트 추가/수정/삭제가 앱에 미치는 영향에 대해 파악
• 개발된 상태를 기반으로 문서 정리 : 미반영 이벤트 추가, 미사용 이벤트 제거, 변경된 이벤트 수정

데이터팀(지형)

• 분석용 이벤트 로그 수집 방식 파악
• 전반적인 분석용 이벤트 목록 파악
• 분석용 이벤트 로그의 전처리(추출, 변환, 적재 등) 과정 파악
• 정제된 분석용 데이터의 구조 파악
• 이벤트 로그를 활용한 대시보드 구성 파악
• 이벤트 로그와 관련된 분석 과제 해결 과정 파악

설계 & 설계 리뷰

기존 내용을 파악하고 문서를 정리하고 난 뒤, 본격적으로 이벤트 추가/수정/삭제에 대한 논의를 시작했습니다. 처음에는 사용자 분석에 있어 부족한 이벤트들을 빠짐없이 채워 넣는 데에만 집중했고, 수정/삭제에는 크게 집중하지 않았습니다. 이런 방식으로 이벤트들을 정리한 후 연미님, 인성님과 함께 리뷰를 진행했는데, 각각의 이벤트들이 필요한 이유에 대한 질문에 명확한 답변을 하지 못했습니다. 막무가내로 부족한 이벤트만을 추가하면 안 될 것 같다고 생각한 저희는 이벤트 추가/수정/삭제에 대한 기준을 먼저 설계해 보기로 했습니다.

Task의 목적에 대해 좀 더 깊게 생각해 보며 추가/수정/삭제에 대한 기준을 아래와 같이 설계했고, 설계한 기준에 대해 리뷰하는 시간을 가졌습니다. (어떤 기준을 설정했는지와 기준을 설정하기 위해 고군분투한 이야기는 지형님의 앞선 글에서 더욱 자세히 확인하실 수 있습니다!)

<기준>

– 추가 : 이용자 여정을 파악하는데 유실된 이벤트, 특정 기능의 사용성을 판단하기 위한 이벤트
– 수정 : 기존 이벤트로 명확한 분석이 어려운 경우, 네이밍이 불분명한 경우
– 삭제 : 다른 이벤트를 통해 원하는 분석을 할 수 있는 경우, 이미 분석이 종료된 경우

기준을 명확히 세운 뒤, 다시 기준에 따라 이벤트를 점검했고 5개의 추가, 12개의 수정, 2개의 삭제 이벤트를 일차적으로 결정지었습니다. 이 이벤트들에 대해 다시 데이터팀과 앱개발팀이 함께 모여 불필요한 이벤트들은 없는지, 놓친 부분은 없는지, 개선이 필요할 사항은 없을지, 다른 방향으로 수정이 필요한 것은 없는지 등을 리뷰했습니다. 이 리뷰를 통해 4개의 이벤트를 추가, 10개를 수정, 16개를 삭제하기로 최종 결정했습니다.

저와 지형님 두 명 모두 지그재그팀에 합류한 뒤 처음으로 맡은 Task였기 때문에 시행착오는 피할 수 없을 것이라 생각했지만, “조금 더 잘할 수 있었을 것 같은데..!”라는 아쉬움이 남기도 했습니다. 명확한 기준 설계 없이 바로 이벤트를 살펴보니, 어떤 이벤트를 추가/수정/삭제할 것인지도 모호했고, 추가/수정/삭제가 필요하다고 생각했던 이벤트들도 그 이유를 명확하게 설명하지 못했습니다. 고민의 시간과 깊이를 더하고, 이를 기반으로 기준을 세우고 나니 이벤트를 다시 살펴볼 때 추가/수정/삭제하기가 훨씬 명확해졌습니다.

하지만 그 이후의 다른 Task에서도 아래와 같이 몇 차례의 시행착오를 더 겪었습니다. 설계를 나름 한다고 해보았지만 부족한 점이 발견되기도 했고, 이 Task의 설계 방식과 기능 추가/개선 중심 Task의 설계 방식이 조금 달라 시행착오를 겪은 것도 이유였습니다.

/ case1. 서드파티 라이브러리를 새로운 버전으로 업데이트하는 Task에서, 중요한 예외사항 하나를 파악하지 못했습니다. 개발을 진행하던 중 뒤늦게 예외사항을 파악했고, 이에 따라 시나리오가 변경될 필요가 있었습니다. 시나리오가 변경되면서 개발 구조 역시 변경되어야 했고, 더 많은 리소스가 필요하게 되었습니다.

/ case2. Task 마감 기한이 조금 촉박하다고 느껴, 혼자 설계하고 리뷰 없이 바로 개발에 들어갔던 적이 있었습니다. 분명 꼼꼼히 설계했다고 생각했지만 생각보다 빈틈은 훨씬 많았고, 수정하는 것보다 새롭게 개발을 시작하는 것이 더 빠를 정도였습니다.

몇 차례의 시행착오를 겪으며, 설계와 리뷰가 왜 중요한지에 대해 더 명확히 알게 되었습니다.

• 미리 큰 구조를 설계해 둠으로써 Task의 진행이나 방향에 대해 명확히 할 수 있었습니다. 설계하지 않고 개발을 바로 시작하게 되었을 때, 문제 상황(시나리오 변경, 예외 케이스 등)이 발견되면 당황하는 경우가 많았었는데, 구조를 명확하게 설계하고 개발을 하니 해결 방안을 좀 더 빨리 찾고 좀 더 유연하게 대응할 수 있었습니다.

• 설계에 대해 함께 리뷰하는 과정은 십중팔구 좋은 결과를 가져왔습니다. 아무리 혼자 꼼꼼히 설계했다고 하더라도 함께 리뷰해 보면 놓치는 부분이나 개선 포인트들이 한 두 군데씩 나왔었습니다. 각자 조금씩 다른 관점에서 보다 보니 다양한 경우의 수에 대해 파악이 가능했고, 파악한 내용을 통해 보다 완성도 높은 설계를 할 수 있었습니다.

앱개발팀은 기능을 개선하거나 추가하는 Task에서, 위의 기준 설계와는 조금 다른 방식으로 개발을 위한 설계와 리뷰를 아래와 같이 진행합니다.

1. 시나리오 확인 : 만약 시나리오 중 불명확한 사항이 있으면 PM, 디자이너, 개발자가 함께 논의하여 시나리오를 명확하게 함

2. 기능 스펙 정의 : 시나리오가 확정되면 기능/화면별로 개발 내용들을 정의

3. 개발 계획 & 설계
– 필요한 기술 검토
– 데이터 모델 : 필요한 데이터, 데이터의 값/타입/제약사항, 서버와의 연동, 기존 데이터와의 연관성 등
– 데이터 관리 : 데이터 저장 위치(메모리, 파일, 로컬 DB 등), 데이터 추가/삭제/갱신, UI를 위해 필요한 API 등
– 화면: 적합한 레이아웃 선택, View 배치 등

4. 리뷰
– 요구 사항을 모두 반영하는지
– 구조적, 논리적 오류는 없는지
– 파악된 예외상황에 대해 대응할 수 있는지
– 구조 파악이 용이한지
– 추후 요구사항이 변경되더라도 유연하게 대처할 수 있을지
– 불필요한 오버헤드는 없는지

개발

분석용 이벤트 로그에 대한 설계와 리뷰가 마무리된 후 본격적으로 개발을 시작했습니다.

개발팀

개발팀에서는 아래의 순서에 따라 이벤트를 코드에 반영했습니다.

1. 설계된 내용을 바탕으로 TODO 리스트를 작성
2. TODO 리스트 진행 순서&우선순위를 결정
3. 새로운 Branch를 생성하여 작업
4. 설계 시 확인했던 주의사항에 유의하며 코딩을 시작
5. 개발을 마무리하면 Pull Request

이렇게 코드 작성을 마친 뒤, 연미님의 코드 리뷰가 진행되었습니다.

지그재그에서는 꼭 다른 동료의 코드 리뷰를 거친 뒤 실 서비스에 반영합니다. 코드를 작성한 사람은 자기의 코드를 계속해서 봐왔기 때문에 오히려 놓치는 부분이 생길 수 있습니다. 코드를 작성하지 않은 사람이 새로운 시각으로 코드 리뷰를 진행하면 더욱더 꼼꼼하게 리뷰할 수 있습니다. 지그재그 팀에서는 코드 리뷰를 진행할 때 주로 아래 사항들에 대해 리뷰합니다.

• 구조/논리적 오류
– 설계와 다르거나 누락된 사항
– 성능 저하(CPU, 메모리, 모바일 데이터 등) 발생
– 예외처리 누락
– 코드 실행 순서 오류
– 요구사항 변경 시 유연하게 대처하기 어려운 부분

• UI
– 부적합한 레이아웃 선택
– View 배치 오류/개선 사항
– 디자인된 파일과 개발된 사항 불일치
– 최적화되지 않은 구성
– 화면 크기에 따른 처리

• 코드 개선
– 코드 가독성
– 코딩 컨벤션
– 네이밍
– 불필요한 코드, 리소스

코드 리뷰의 최우선 목적은 버그나 실수를 최소화하는 것과, 좋은 상태의 코드를 유지하는 것입니다. 이뿐만 아니라 설계한 사항이 어떻게 코딩이 되었는지 파악/이해하고, 업무 진행 상황을 파악함으로써, 모든 팀원이 모든 업무를 진행하고 대응할 수 있도록 하는 것도 코드 리뷰를 하는 중요한 이유들 중 하나입니다. 이 코드 리뷰는 양방향으로 이루어집니다. 선배 개발자들만 후배 개발자들의 코드를 리뷰하는 것이 아니라, 후배 개발자들도 선배 개발자들의 코드를 리뷰합니다.

데이터팀

데이터팀에서는 이벤트의 변동 사항을 문서에 반영했고, 변동된 이벤트와 관련된 데이터 ETL 작업을 수정했으며, 데이터와 통계 대시보드 간 연동을 점검했습니다. 데이터 팀에서의 개발과정은 더 정확한 정보 전달을 위해 데이터팀에서 작성해주셨습니다!

—————-

안녕하세요. 지그재그 데이터팀의 박인성입니다.

데이터팀에서는 이벤트 로그의 추가/수정/삭제 내역을 문서에 반영했습니다. 이번 Task에서는 분석용 이벤트 로그 전송에 필요한 개발 요소를 파악하기 위해 개발팀에서 문서 정리 작업을 병행했지만, 현재는 데이터팀에서 데이터 분석에 필요한 로그를 스스로 관리하고 운영할 수 있도록 이벤트 로그 문서를 직접 관리하고 있습니다. 이벤트 로그 문서는 Github Wiki를 활용해 문서 변경 내역의 히스토리를 관리하고 있으며, 이는 개발팀과 데이터팀 간 로그 관련 커뮤니케이션의 기준이 됩니다.

또한 추가/수정된 이벤트의 로그가 실제로 로그 DB와 스토리지에 적재되는 시점에 앞서, 데이터팀의 주요 관리 요소 중 하나인 ‘데이터 ETL 작업’을 점검했습니다. ETL은 Extract, Transform, Load의 각 앞글자를 따온 것이며, 아래의 과정을 포괄하는 개념입니다.

• E : 정제되지 않은(raw) 형태의 로그 데이터를 추출(Extract)하여,
• T : 모니터링이나 분석에 적합한 형태의 데이터로 변환(Transform)하고,
• L : 변환된 데이터를 새로운 DB나 스토리지에 적재(Load)한다.

위와 같은 데이터 ETL 과정을 통해 적재된 데이터는 아래와 같은 용도로 활용할 수 있습니다.

• 비즈니스 의사결정에 필요한 주요 데이터를 빠르게 조회 및 탐색하는 분석 환경을 운영
• 지표 모니터링에 필요한 대시보드를 생성

이번 Task에서 ETL 과정을 수정하는 관점은 아래와 같이 크게 3가지로 나눌 수 있었습니다.

• 새롭게 추가되는 이벤트 로그 중, ETL 과정에 포함할 로그가 있는지?
• ETL 과정에 활용되는 기존 이벤트 로그 중 수정된 항목은 어떤 것이 있는지?
• ETL 과정에 활용되는 기존 이벤트 로그 중 삭제된 항목이 있는지?

이번 Task에서는 정제되지 않은(raw) 형태의 로그 데이터를 추출하는 과정과 데이터를 적재하는 방법에는 변화가 없었기 때문에, 주로 데이터 변환(Transform) 과정을 수정했습니다.

데이터 변환 과정을 수정하면서, 기존의 변환 작업에서 수정이 필요한 영역을 우선 확인했습니다. 그 후 추가/수정이 발생한 이벤트 로그를 중심으로 새로운 변환 작업을 설계했으며, 마지막으로 기존의 변환 작업과 새롭게 설계한 변환 작업을 병합했습니다.

이 모든 과정에서 중요하게 고려한 요소는 변환된 결과 데이터의 구조를 유지하는 것이었습니다. 이는 기존의 변환 데이터와 새로운 변환 데이터를 최대한 동일한 방법(Ex: 동일한 쿼리)으로 조회하고 탐색하기 위함입니다. 이처럼 분석 환경의 변동성을 최소화하고 분석 작업의 효율을 극대화하기 위해, 분석용 이벤트 로그의 추가/수정/삭제 히스토리를 파악하고 관리하는 것은 매우 중요합니다.

이렇게 데이터 ETL 과정의 점검과 수정을 마친 후, 현재 운영되는 통계 대시보드가 새로운 ETL을 거친 데이터를 문제없이 반영하는지 확인했습니다. 또한 새롭게 추가된 이벤트 로그 중 대시보드 생성이 필요한 이벤트를 확인하여 대시보드를 추가했습니다.

—————-

최종 점검&릴리즈

다시 형준으로 돌아와서..! ㅎㅎ 개발이 완료된 뒤에는 최종 점검하는 시간을 가졌습니다. 화면 이동과 앱 내의 기능들을 사용해 보며 정상적으로 이벤트 로그들이 수집되는지 확인했고, 사용자에게 나타날 수 있는 여러 가지 경우의 수(OS, OS 버전, 기종, 이전 버전과의 호환 등)에서 버그는 없는지 꼼꼼히 테스트했습니다. 이렇게 최종 점검을 진행한 후 릴리즈했습니다!

모니터링

릴리즈 후에는 Task의 마지막 단계인 모니터링을 진행했습니다. 실제 유저의 수많은 사용 패턴 안에서 예상하지 못했던 문제나 케이스가 없는지, 반영된 이벤트 로그가 정상적으로 수집되며, 대시보드에 정상적으로 반영되는지 1주일 동안 모니터링했고, 정상 동작함을 확인했습니다!!

이렇게 저희들의 첫 번째 Task가 무사히 끝난 뒤, 연미님과 인성님이 특별한 뒤풀이를 준비해 주셨습니다. 바로 한강 피크닉입니다! 수고했다는 말과 함께 맛있는 음식(+술)을 사주셨습니다. 돗자리를 깔고 치킨도 먹고, 라면도 먹고, 지그재그가 공동 기획한 웹드라마 ‘마이엑스다이어리’도 다 함께 시청하고, 캐치볼도 하고… 맥주(도 마시고 소주도 마시고 또 맥주)도 마시며 훈훈하게 Task를 마무리했습니다.

정말 많은 것을 느낄 수 있었던 첫 번째 Task였습니다. 데이터팀과 앱개발팀이 어떻게 협업하는지에 대해 조금 더 깊게 알 수 있었고, 앱 전체를 구석구석 살펴보며 많은 화면들과 기능에 대해 좀 더 빠르게 이해할 수 있었습니다. 그리고 정말 설계와 리뷰가 중요함을 느꼈습니다. 설계를 하지 않은 경우 생길 수 있는 문제, 어떻게 리뷰를 해야 하는지를 좀 더 잘 알게 되었습니다. 이 글을 쓰는데 많은 도움을 주신 연미님께도 다시 한 번 감사드리고요! 😀

긴 글을 읽어주셔서 감사합니다! ^0^