크로키닷컴(주) 입사지원자 개인정보 처리방침

크로키닷컴(주)(이하 “회사”)은 지원자의 개인정보를 안전하게 보호하고 궁금한 사항의 문의나 어려움 해결에 도움을 드리고자 다음과 같은 원칙을 마련하고 있습니다. 또한 저희는 관련 법령이나 회사정책의 변경으로 불가피하게 개인정보 처리방침을 변경해야 하는 경우 웹사이트를 통해 빠르게 알려 드리고 있으니 참고하여 주시기 바랍니다.

 

1.개인정보의 수집 목적 및 방법
가. 회사는 입사전형 진행, 입사 지원자와의 원활한 의사소통, 채용관련 정보 안내, 상시채용 등을 위해 입사지원서에 기재된 개인정보를 수집합니다.
나. 회사는 외부 채용 플랫폼(원티드, 잡코리아, 사람인, 알바몬) 및 회사의 HR 채용 채널(job@zigzag.kr) 을 통해 개인정보를 수집합니다.

2. 수집하는 개인정보 항목
가. 기본필수정보: 성명, 연락처(이메일, 휴대폰번호), 경력사항, 프로젝트 수행이력  등 입사지원시 입사지원자가 이력서, 포트폴리오 등을 통해 제공한 정보 일체
*지원이 자유양식으로 이뤄지므로 그 지원 직군 및 내용에 따라 수집항목이 다를 수 있습니다.
*처우를 산정할 시 처우 산정을 위한 증빙자료를 요청할 수 있습니다.

3. 개인정보의 공유 및 제공(개인정보의 제 3자 제공 등)
회사는 개인정보를 “1. 개인정보의 수집 목적 및 방법’에서 고지한 범위내에서 사용하며, 입사지원자의 개인정보를 제 3자에게 제공하지 않습니다. 그러한 필요가 발생할 경우 입사지원자에게 알리고 사전동의를 받도록 하겠습니다.
단, 다음의 각 호에 해당하는 경우는 예외로 합니다.
가. 개인정보주체로부터 별도의 동의를 받은 경우
나. 다른 법률에 특별한 규정이 있는 경우
다. 수사 목적으로 법령에 정해진 절차와 방법에 따라 수사기관의 요구가 있는 경우

4. 개인정보처리 업무의 위탁
회사는 필요한 경우 및 기타 서비스 제공을 위해서 입사지원자의 개인정보를 외부에 수집·보관·처리·이용·제공·관리·파기 등을 할 수 있도록 아래와 같이 업무를 위탁하여 운영하고 있습니다. 회사는 위탁계약 등을 통하여 서비스제공자의 개인정보보호 관련 지시엄수, 개인정보에 관한 비밀유지, 제3자 제공의 금지 및 사고 시의 책임부담 등을 명확히 규정하고 당해 계약 내용을 서면 또는 전자적으로 보관하여 이용자의 권익을 보호하고 있습니다.
가. 수탁업체:원티드, 잡코리아, 사람인, 알바몬
나. 위탁업무내용 : 입사지원자 모집
다. 개인정보의 보유 및 이용기간: 채용절차 진행기간 동안

5. 개인정보의 보유 및 이용기간, 파기
가. 회사는 상기의 수집 및 이용목적이 달성될 때까지 개인정보를 보유합니다. 다만, 관련 법령의 규정에 의하여 보존할 필요가 있는 경우 회사는 관련 법령에서 정하고 있는 일정한 기간 동안 정보를 보관할 수 있습니다.
나. 종이에 출력된 개인정보는 분쇄기로 분쇄하거나 소각을 통해 파기하며, 전자적 파일형태로 저장된 개인정보는 기록을 재생할 수 없는 기술적 방법을 사용하여 삭제합니다.

6. 정보주체의 권리와 그 행사방법
지원자는 담당자에게 전화 또는 이메일로 연락하여 자신의 정보의 조회, 수정, 처리 정지, 삭제를 요청할 수 있습니다. 다만, 지원서를 통해 받는 정보를 제공받지 못할 경우 회사는 공정한 선발 전형을 진행할 수 없습니다. 또한 개인정보 제공에 동의하지 않을 경우 채용 전형이 제한될 수 있습니다.

7. 개인정보의 안정성 확보 조치
가. 개인정보 처리 담당자의 최소화 및 교육 : 입사지원자의 개인정보를 취급 및 담당하는 직원은 반드시 필요한 인원에 한하여 지정/관리되고 있으며 담당자에 대한 수시 교육을 수행하며, 개인정보보호를 강조하고 있습니다. 이용자의 개인정보에 대한 접근권한은 입사지원자를 직접 상대로 하여 채용 과정을 진행하는 자 등 기타 업무상 개인정보의 취급이 불가피한 자로 제한 하고 있습니다. 또한, 입사지원자의 개인정보를 취급 및 담당하는 직원은 개인정보 접근을 위한 별도의 비밀번호를 부여하여 정기적으로 갱신합니다. 입사시 전 직원의 보안서약서를 통해 사람에 의한 정보유출을 사전에 방지하며, 개인정보 관련 취급자의 업무 인수인계는 보안이 유지된 상태에서 철저하게 이뤄지고 있습니다.
나. 개인정보에 대한 접근 제한: 지원자의 개인정보를 처리하는 데이터베이스시스템에 대한 접근권한의 부여, 변경, 취소 등을 통하여 개인정보에 대한 접근통제를 위한 필요한 조치를 시행하고 있습니다.
다. 보안프로그램 설치 및 주기적 점검/갱신: 해킹이나 컴퓨터 바이러스 등에 의한 개인정보 유출 및 훼손을 막기 위하여 보안 프로그램을 설치하고 주기적으로 갱신/점검하고 있습니다.

8. 개인정보 보호책임자 및 담당자의 연락처
회사의 입사지원 과정에서 발생하는 모든 개인정보보호 관련 민원을 인사 담당자에게 신고하실 수 있으며, 회사는 이용자들의 신고사항에 대해 신속하게 충분한 답변을 드릴 것입니다.
• 개인정보 보호ㆍ관리 책임자
– 이 름 : 윤상민
– 전 화 : 02-1670-8050
– 직 위 : 최고기술책임자
– 전자메일 : support@zigzag.kr
• 입사지원자 개인정보 보호 담당부서
– 부서명 : Relations팀
– 담당자 : 이유진
– 전 화 : 02-1670-8050
– 전자메일 : job@zigzag.kr
기타 개인정보침해에 대한 신고나 상담이 필요하신 경우에는 아래 기관에 문의하시기 바랍니다.
• 개인정보침해신고센터(http://privacy.kisa.or.kr/ / 국번없이 118)
• 대검찰청 사이버범죄수사단(http://spo.go.kr / 국번없이 1301)
• 경찰청 사이버안전국(http://cyberbureau.police.go.kr / 국번없이 182)

9. 개인정보처리방침의 변경
현 개인정보처리방침의 내용 추가, 삭제 및 수정이 있을 시에는 홈페이지 ‘공지사항’을 통해 고지할 것입니다.

분석용 이벤트 로그 점검/정리하기 #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^

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

지그재그는 누적 다운로드 수 1,100만, MAU 200만을 넘어가고 있는 여성 쇼핑몰 모음 앱 서비스입니다. 그렇기 때문에 매일같이 지그재그에 쌓여가는 이용자들의 데이터 로그들도 어마어마하죠.

이와 같은 로그들은 이용자들이 각자 자신에게 맞는 쇼핑몰/상품을 더 쉽게, 편하게 찾을 수 있도록 도와주는 개인화 알고리즘의 핵심 자원이면서, 이용자들이 앱의 각 기능들을 잘 활용하고 있는지 파악하기 위한 사용성 분석에도 필수적입니다. 또한 서비스 운영에 영향을 줄 수 있는 각종 이상 현상을 실시간으로 탐지하며 대응할 수 있게 도와주죠. 이를 위한 지그재그에서는 불필요한 로그/개인정보를 수집하지 않으면서도 앞선 목적에 부합하는 로그만 효율적으로 쌓아나가기 위해 노력하고 있습니다.

실제로 이와 같은 로그 수집을 위해 지그재그 개발팀과 데이터팀이 어떤 노력을 기울이고 있는지, 데이터팀의 지형님과 개발팀의 형준님이 이번 포스트를 준비했습니다 🙂

 

저는 지그재그에 합류한 지 5개월 차 되는, 데이터팀 신입 국지형이라고 합니다. 평소에 데이터가 많은 회사에서 다양한 사람들의 특성을 분석하면서 일하고 싶어 했고, 개인적인 관심사도 계속 데이터 분석 업무와 맞닿아있기 때문에 지그재그에서 커리어를 시작하게 되었습니다. 양질의 좋은 데이터, 다양한 사용자라는 측면에서 지그재그가 제게 가장 알맞은 곳이라고 생각했고 지금도 굉장히 만족하고 있습니다(^^)

지난 4월, ‘분석용 이벤트 로그 전체 점검 및 정리’라는 Task를 개발팀의 형준님과 함께 맡아 수행하게 되었습니다. 처음에는 이 Task에 대해 굉장히 단순하게 생각했었지만 알고 보니 데이터팀의 인성님, 개발팀의 연미님께서 많은 고민 끝에 주신 의미 있는 Task였습니다. 이번 글에서는 대체 이 업무가 왜 이토록 중요했는지, 그리고 이 업무가 개발팀의 신입이었던 형준님과 데이터 팀 신입이었던 제게 시사하는 바가 어떤 점이었는지 기록해보려고 합니다.

아, 그전에 ‘분석용 이벤트 로그’에 대한 설명을 드려야 할 것 같은데요. 분석용 이벤트 로그는 다양한 데이터 분석을 목적으로 수집하는, 지그재그 이용자의 이벤트 로그를 뜻합니다.
– 분석용 : 지그재그 서비스 이용자의 만족을 위해 필요한 의사결정을 지원하는 데이터 분석(ex. 이용자 분석, 행동 패턴 분석 등)
– 이벤트 : 지그재그 이용자들이 앱을 이용하면서 발생시키는 액션 및 화면 이동
– 로그 : 발생한 이벤트들을 데이터로 정리해 데이터베이스에 기록

이 Task는 다음과 같은 방식으로 진행되었습니다.
(1) 형준님과 제가 먼저 어떻게 데이터를 정리하면 좋을지에 대한 기준을 논의하고(60%)
(2) 연미님, 인성님에게 그 방식이나 진행사항들에 대한 피드백을 받고(20%)
(3) 최종적으로 로그들을 정리한 다음 개발에 적용하는 방식(20%)

실제 데이터팀과 개발팀이 함께 나눴던 QnA는 다음과 같았는데요!

인성(데이터팀) : 분석용 이벤트 로그 정리는 왜 따로 태스크로 정리해야 하는 걸까요?
지형(데이터팀) : 아무래도 이용자 분석을 하는 데 있어서 부족한 로그를 추가해야 하니, 이용자들의 세세한 액션들에 대한 로그들을 하나도 빠짐없이 추가해야 하지 않을까요?
연미(개발팀) : 음, 그렇다면 부족한 로그가 있을 때마다 그 모든 것을 로그로 추가하는 것이 가장 최선일까요?
형준(개발팀) : (1차 동공 지진) 없는 것보단 있어야 분석을 할 수 있으니까 가장 최선일 듯 싶습니다.
연미(개발팀) : 지그재그 이용자들의 데이터 사용량을 생각해보신 적이 있나요? 로그가 많을수록 지그재그 이용자들의 데이터 사용량이 어떻게 될까요?
지형(데이터팀), 형준(개발팀) : (2차 멘붕…)


음… 어… 음…..

이후 계속적인 논의, 논의, 논의를 거쳤습니다.

로그에 대한 기본적인 이해 없이는 정리의 시작조차 할 수 없다는 것을 깨달은 저희는 인성님과 연미님이 질문해주신 내용들을 되짚어보기 시작했습니다. 가장 먼저 해야 할 업무는 아래와 같았습니다.

1) 어떤 로그들이 존재하고 있는지 파악하는 것
2) 어떤 타이밍에 이 로그들이 호출되는지 파악하는 것
3) 이 로그들이 어떤 유형으로 분류되어 있고 분류되어야 하는지를 파악하는 것

형준님은 개발팀의 입장에서 ‘기존 로그들을 파악’하는 작업을, 저는 데이터팀의 입장에서 ‘로그 추가, 수정, 삭제 기준’을 정하는데 중심을 두고 본격적으로 함께 정리 작업을 시작했습니다. 저희는 이 작업을 진행하면서 서로에게 계속해서 질문을 던지고 그 해답을 정리하는 방식으로 진행해보았습니다. 저희가 반복적으로 논의하고 고민했던 질문들은 다음과 같으며, 처음부터 로그 정리의 본질적인 필요성에 집중한 것이 도움이 되었습니다.

0. 우리는 왜 분석용 로그를 전반적으로 점검하게 되었는가?

과거, 현재뿐만 아니라 미래에도 지속적으로 추가할 수 있는 로그들에 대해 고려하며 꼭 필요한 로그만 유지하기 위해서 처음부터 차근차근 점검하게 되었다.

1. 우리가 말하는 데이터 분석이란 어떤 것일까?

a. 우리가 말하는 데이터 분석은 ‘이용자 만족을 위해 도움이 되는’ 작업이다.
b. 이 안에는 이용자의 사용 패턴을 파악해 중요 지표(key factor)를 도출하는 것, 이용자가 ‘인지하는 불편함’과 ‘인지하지 못하는 불편함’을 찾아 개선 포인트를 찾아내는 것, 앱의 위험 요소(이탈 포인트)를 찾아 보완하는 것이 포함되어 있다.

2. 분석의 유형에는 어떤 것들이 있을까?

a. 시간의 흐름에 따른 분석(ex. user journey) : 이 안에는 개인화를 통해 고객에게 더 적합한 쇼핑몰 및 상품 제공, 실시간 로그 분석을 통한 이상 탐지 등이 포함된다.
b. 특정 시점에서의 정량적 분석(ex. 탭 클릭률)

3. 분석용 이벤트 로그 정리를 통해 얻고자 하는 바는 무엇인가?

(공통) 앱 내 각종 로그에 대한 파악
(데이터팀) 지그재그의 이용자를 분석하는 데 있어서 부족한 로그를 추가하고 수정하는 것
(개발팀) 이용자의 단말 자원 사용량을 최적화해서 불필요한 자원 낭비를 방지하는 것

4. 3번의 목적에 따른 분석용 이벤트 로그 추가/수정/삭제 기준은 어떻게 설정해야 할까?

a. 로그 추가 기준
– 이용자 여정(user journey)를 파악하는데 유실된 로그가 있어서는 안 된다
– 특정 기능의 사용성을 판단하기 위한 로그를 추가해야 한다
b. 로그 수정 기준
– 기존의 내비게이션 혹은 액션 로그만으로 명확한 분석이 어려울 경우 로그를 수정한다
– 기존의 로그 네이밍이 불분명한 경우 로그를 수정한다
c. 로그 삭제 기준
– 중복된 로그들이 있는 경우 삭제한다.
– 다른 로그를 통해 원하는 결과를 얻을 수 있는 로그인 경우 삭제한다.
– 과거 버전에서 사용되고 현재 사용하지 않는 로그는 삭제한다.
– 이미 분석이 종료되어 더 이상 분석에 이용되지 않는 로그는 삭제한다.

5. 결과적으로 분석용 이벤트에 대해 데이터팀/개발팀이 갖춰야 할 자세는 무엇일까?

(공통) 개발팀과 데이터팀은 분석용 이벤트에 대한 서로의 인식을 공유하고 각 팀이 추구하는 방향성을 존중
(개발팀) 중복되거나 현 버전에는 필요 없는 로그를 정리해 데이터를 효율적으로 운영
(데이터팀) 지그재그 이용자들을 분석하는 데 있어서 부족한 로그는 없는지 꼼꼼히 확인

위와 같은 기준을 세운 다음 인성님, 연미님과 함께 기준 검토 과정을 거쳤습니다.
특히 왜 이 Task를 시작했는지에서부터 선정한 기준, 그 이유를 명확하게 세운 부분에 대해 긍정적인 피드백을 받아 기뻤습니다.

예이! 신난다! 뿌듯!

저희는 본격적으로 로그들을 정리하는 작업을 시작하기에 앞서 본질적인 고민들에 집중을 하면서 첫 단추를 다행히 잘 꿰어나갔다고 생각합니다.

이번 Task를 통해 지그재그라는 서비스 이용자를 위해 노력하는 개발팀, 데이터팀의 깊은 고민을 깨닫게 되었습니다. 하나의 로그를 넣을 때에도 위와 같은 기준을 바탕으로 고민, 검토를 거듭하는 시간이 꼭 필요하다는 것도 느꼈고요. 동시에 지그재그에서 처음으로 업무를 시작한 형준님과 제가, 지그재그에 빠르게 어마어마하게 쌓이는 로그들에 대해 전반적으로 이해를 높일 수 있는 시간이었습니다.

실제로 로그들이 어떻게 정리되었는지, 그리고 그 정리된 로그들이 지그재그 서비스에 어떻게 반영되었는지 등에 대해서는 개발팀의 형준님이 다음 포스트로 찾아뵐 예정입니다. 감사합니다! 😀

To Be Continued….