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

지그재그 신입 개발자로 반 년 채우기! :-)

Q. 두 분의 짧은! 자기소개, 업무 소개를 부탁드립니다.

(형준) 안녕하세요, iOS 개발자 오형준이라고 합니다. 지그재그에 입사한지는 6개월 정도 되었습니다. 지그재그에 들어오기 전까지는 여성 쇼핑몰에 전혀 관심이 없었는데 여동생이 강력하게 ‘오빠 여기 대기업 될 거야’라고 말해주어서 확신을 갖고 입사하게 되었습니다. ㅎㅎ 실제로 앱을 실행해봤을 때 모든 개발자들이 꿈꾸는 것처럼 깔끔하고 군더더기 없는 앱이라 더 마음을 굳힐 수 있었고요. 병역특례가 가능한 회사라는 점도 인상적이어서 여러모로 마음에 들었습니다.

(신예) 안녕하세요! 지그재그 입사 8개월 차 백엔드 개발자 송신예라고 합니다. 저는 커머스 쪽에 관심이 많아 관련 서비스에서 일해보고 싶다고 항상 생각했어요. 친한 친구가 여성 쇼핑몰을 직접 운영하고 있었는데 사용자인 저와 쇼핑몰을 운영하는 친구 모두에게 지그재그는 참 편한 서비스였거든요. 이렇게 두 고객군을 모두 만족시키는 서비스라면 미래에도 할 수 있는 일이 많겠다! 싶었습니다. 또, 친구가 중학교 때부터 정말 열심히 쇼핑몰을 운영해왔는데 그런 분들에게 더 많은 기회를 열어주는 서비스라고 생각해서 더 입사하고 싶었습니다.

Q. 형준님은 여동생에게 이야기를 들으면서, 신예님은 본인이 직접 서비스를 이용하며 지그재그를 알게 되신 거네요! 또 인상적이었던 점이 있었나요?

(형준) 동생이나 주변의 여성 분들이 지그재그 앱을 많이 쓰는 게 인상적이었어요. 저는 남자다 보니까 지그재그 유저는 될 수 없잖아요 ㅎㅎ 그런데도 주변에 ‘지그재그 알아? 써봤어?’ 라고 물어보면 거의 모르는 사람이 없었어요. 일단 주변에 많은 사람들이 쓰는 걸 보고 나니까 여성 패션이라는 특수한 산업 분야는 걸림돌로 작용하지 않았어요. 앱의 업력이 생각보다 짧았는데 그에 비해서 쌓아온 성과가 엄청나다는 생각도 했고요. 지그재그에 지원하기 전에는 대표님 인터뷰나 서비스 소개 자료를 많이 살펴봤어요.

(신예) 지그재그의 채용 인터뷰를 보는 과정에서 저와 지그재그가 각자 갖고 있는 생각, 서로 추구하는 가치가 더 큰 시너지를 낼 수 있겠다고 느꼈어요. 인터뷰를 겪으면 겪을 수록 그 생각은 더 깊어졌는데요. 해 WTM 컨퍼런스에서 시니어 개발자이신 연미님과 서영님이 발표를 하셨는데, 그때 많은 분들이 지그재그 개발팀이 신입에게 어떤 역량을 요구하는지 질문하셨거든요. 그때 서영님이 ‘실력은 좋으면 좋을수록 당연히 좋지만 주니어 때라면 열심히 배워나가려는 태도가 가장 중요한 것 같다’고 말씀하셨었어요. 재밌는 건 제가 채용 전형 과정에서 서영님이나 상민님(CTO)과 인터뷰를 진행할 때 ‘아, 이 팀은 정말 태도를 중요시하는구나’라는 게 실제로 느껴졌거든요. 개발에 임하는 제 생각이나 가치관, 주니어로서 개발 공부를 어떻게 하고 있고 어떤 생각을 가지며 코드를 대하는지에 대한 질문을 많이 받았어요. 지그재그의 일관적인 느낌이 인상적이었어요.

 

Q. 채용 과정의 인터뷰 이야기를 빼놓을 수 없죠… 두 분의 인터뷰는 어떠셨어요?

(형준) 전 지그재그의 인터뷰가 CS 기본만 오고 가는 기술면접이 아니었다는 점이 좋았어요. 실제로 어떻게 코드를 짜고 구성 해나가는지에 더 많은 중점을 두시더라고요. 실무적인 업무 방식이나 태도를 중요시한다고 느껴졌던 것 같아요. 제 인터뷰에 참석하셨던 연미님, 상민님이 해주시던 질문도 마찬가지였고… CS 같은 경우에는 따로 공부를 해야 하잖아요. 다른 인터뷰를 준비하기 위해서는 처음부터 CS공부를 다시 리마인드 한다는 느낌이 들었거든요. 그런데 지그재그는 1차 인터뷰 이후 주어졌던 과제도 업무 방식이나 태도와 관련된 과제가 주어져서 재미있게 했어요. 인터뷰나 과제를 진행할 때도 그동안 매일같이 제가 해오던 것들, 그러니까 평소에 개인적으로 앱을 만들고 UI를 짜 왔던 것들을 그대로 드러내면 되는 부분이라 편하게 진행했어요. 심적으로 안정감이 있었다고 해야 하나. 그게 다른 회사의 인터뷰들과 많이 다른 점이었던 것 같아요.

(신예) 구직자, 특히 주니어 개발자 입장에서는 온라인 과제가 주어진다고 하면 일단 무서운 기분이 들거든요. 덜컥! 과제 퀄리티가 낮을까 봐 당연히 부담이 되잖아요. 그런데 상민님과 서영님 두 분 다 ‘신입이니 과제가 엄청 어렵지 않을 거다(ㅎㅎㅎ), 편하고 재미있게 하라’라고 다독여주셔서 즐겁게 과제를 해냈던 것 같아요. ‘할 수 있는 만큼 열심히 해봐라’라는 말이 아직도 기억에 남아요. 저는 할 수 있는 만큼 재미있게 했어요.
아 그리고 일반적인 기술 지식을 묻는 것보다 제가 제출한 포트폴리오나 깃허브를 꼼꼼히 살펴보고 인터뷰에 들어와 주신 게 감사했어요. 포트폴리오와 이력서를 자세히 살펴봐야만 할 수 있는 질문 등을 해주신 것도 좋았고, 제가 포트폴리오에 대한 설명을 해드릴 기회도 많았어요. 내가 어떤 사람인지 알고 싶어 하는 느낌을 많이 받았어요. 어떤 개발자인지를 넘어서서 어떤 사람인지에 대한 질문도 받아서 지그재그는 자신과 핏이 맞는 사람을 찾기 위해 정말 신중하게 인터뷰를 진행하는구나 라고 느꼈고요. 마지막 2차 인터뷰 때 대표님이 제게 ‘왜 이 업계에서 여성 개발자가 적다고 생각하세요?’라고 물어봐주셨는데 이 질문은 최근까지도 곱씹어보는 것 같아요. 인터뷰를 통해서 스스로를 많이 돌아봤어요.

편하고… 재미있는… 과제….

(형준) 저도 ‘과제는 편하고 재밌게 하라’는 이야기를 들었는데, 연미님이 그 말을 하면서 천사같이… 너무 편하게 웃어주셨어요. 연미님의 웃음이… 기억나요. ㅋㅋㅋㅋ
그리고 면접비가 솔직히 가장 인상적이지 않았나… 싶습니다. 면접비를 받을 때 상민님께서 수줍게, ‘면접도 면접이지만 시간을 내서 지그재그가 보내드린 과제까지 수행해주시니까 면접비를 드리는 거’라고 말씀하셨는데 그 부분에서 많은 감동을 받았어요.

(신예) 저도 그게 계속 기억에 남았어요. 자꾸 웃음이 나오는 이유가… 면접비를 주시면서 상민님이 ‘저희도 미국이나 다른 좋은 스타트업 문화를 따라가기로 했다’라고 하셨는데 너나 수줍게 웃으셔서… 그날도 그렇고 그 후에도 계속해서 자꾸자꾸 생각이 났어요. 면접비… 감동이었죠….

(형준) 그리고 입사하니 웰컴 키트가 있었습니다. 팀원 분의 마음이 담긴 카드와 친절한 신규직원 안내서가 담겨있는 웰컴 키트가… 그렇게 지그재그에서의 삶이 시작됐죠. 

Q. 그렇게 두 분이 감사하게도, 지그재그에 조인해주셨죠! 형준님과 신예님은 누구보다도 열심히 지그재그에서 내공을 쌓아가고 계시잖아요. 하루하루의 일상은 어때요?

(형준) 신입 개발자가 지그재그에 와서 하게 되는 일의 방식은 앱 파트와 서버 파트가 약간 달라요. 제가 속한 앱 파트에서는 입사하고 3개월 정도는 우리 앱과 관련된 일을 직접적으로 진행하진 않았습니다. 다른 레포지토리 저장소를 파고 지금의 지그재그 앱을 따라서 만들어보는 등 적응 기간을 거쳤어요. 다른 분들과 상호 피드백도 주고받고 시니어 개발자 분들의 피드백을 받기도 했고요.

(신예) 서버 파트에서는 현재 실력에서 적당히 도전적이면서도 수행할 수 있는 수준의 과제를 기간에 맞춰 부여받았습니다. 저는 CTO이신 상민님이 사수나 다름없었는데요, 어쩜 그렇게 어렵긴 하지만 언젠가는 풀어낼 수 있는 문제를 귀신같이 내주시는지(…) 매번 받는 태스크도 난이도가 조금씩 올라가서 많은 발전이 있었던 것 같아요. 수습기간 동안 얕게나마 서비스 전반적인 것들을 훑어 올라갔기 때문에 계단을 올라가는 기분이었어요.

(형준) 과제들이 점점 양과 질 면에서 깊어지는 걸 느끼면서 제 자신도 성장하는 기분이 든다는 게 참 신기해요. 적당히 고민할 수 있는, 어려운 정도의 과제를 시니어 개발자 분들이 내주시는 것도 그렇고요. 선배들의 리뷰를 확인하면서 내가 잘 몰라왔던 것들에 대해 알아가고 나쁜 습관을 고칠 수 있는 기회를 항상 만나요혼자 업무를 진행하다보면 우선순위를 모르겠는 경우가 많았는데 그때는 솔직하게 질문하면서 문제를 해결해나갔어요.
3개월의 수습기간이 끝난 이후에는 몇 주 간격으로 새로운 태스크들을 받아 진행하고 있어요. 주로 UI와 관련된 태스크들인데, 선배들이 내주는 태스크 하나하나에서 다 의미가 느껴지고, 난이도에서도 고민한 흔적이 보이는 게 주니어 개발자의 입장에선 감동적이었어요. 최근에는 데이터 팀의 신입 데이터 분석가 분과 함께 로그 정리도 도전해봤어요.

(신예) 코드 리뷰 이야기도 하고 싶어요. 일단 팀원들이 코드를 1차적으로 완성하고 나면 Github를 통해 Pull Request를 날리고 다른 팀원들이 코멘트를 달아주세요. 지그재그는 TF방식으로 업무가 분류되어 있는데 속해있는 TF와 관련된 코드라면 같은 TF의 동료가 우선적으로 코멘트를 달아주고, 그렇지 않더라도 팀원들의 코드 Pull Request가 올라오면 수시로 확인하는 편입니다. 다른 분들의 코드를 통해 배우는 것도 많고, 만약 눈에 띄는 개선사항이 보이면 그 부분에 대해서도 코멘트를 달아주세요. CTO이신 상민님은 틈틈이 저희 코드들을 골고루, 적극적으로 모두 체크해주시고 코멘트도 달아주시고요.
주로 코멘트가 달리는 내용들은 ‘설계에서 누락된 기능은 없는지, 오탈자는 없는지, 네이밍은 개선될 부분이 없는지, 보다 더 효율적인 코딩 스킬에는 어떤 것이 있을지’ 등등입니다. 리뷰를 주고받으며 더 나은 코드에 대해 서로 토론을 하기도 하고 코멘트로만 작성하기에 설명이 부족한 부분은 직접 찾아가서 개선점에 대해 제안하기도 합니다. 리뷰는 서로의 감정이 상하지 않게 서로의 입장도 고려하며 코멘트 달도록 노력하고 있습니다.

(형준) 다른 곳에서 근무하는 친구들의 이야기를 근무해도, 이렇게까지 코드리뷰를 하는 팀은 없는 것 같아요. 엄청 꼼꼼하게 진행되는 코드 리뷰를 통해 주니어 레벨에서 보지 못하는 것들을 볼 수 있어서 좋아요. 신예님도 그러실 것 같은데, 같은 자리에서 혼자 여러 번 검토할 땐 나오지 않던 부족한 부분들이 어떻게 그렇게 연미님의 눈에는 쏙쏙 보이는 건지… 실력 향상에 정말 많은 도움이 되고 있습니다.

(신예) 코드리뷰는 지그재그 개발팀이 가진 문화를 드러내는 여러 가지 단면 중의 하나인 것 같아요. 지그재그는 프로젝트 단위별로 업무를 진행하기도 하고, 시니어 분들과도 계속해서 코드리뷰를 주고받다 보니까 늘 모두가 함께 일하는 느낌이 강해요. 그래서 신입의 입장에서 배우기가 정말 좋은 곳이라고 생각해요. 지금까지는 기본적으로 시니어 개발자 분들이 프로젝트를 진행하시면서 다른 팀들과 소통을 하시고 그에 따라 주니어들에게 업무를 나누어주거나 시니어와 함께 해결해나가는 방식을 채택했는데요. 갈수록 제가 할 수 있는 역할이 늘어나고 있는 것도 재미예요. ‘어떤 일이 하고 싶냐, 어떤 것에 흥미 있냐’를 항상 물어봐주시니까 제 관심사에 대해서도 항상 돌아보게 되고 그 관심사를 이야기했을 때 관련 있는 업무를 배정해주시니까 더 좋아요. 

(형준) 앱 파트의 경우에는 코드리뷰뿐만 아니라 업무 배분 등의 이슈에 대해서도 매주 화요일, 목요일 아침에 회의를 진행해요. 다음 주의 업무량과 스케줄링도 같이 진행하고요. 앱 개발팀은 코드 작성 후 리뷰하는 시간도 있지만 코드 작성 전에 스펙 정의나 어떤 식으로 코드를 짜면 좋을지에 대해 설계하는 시간을 가져요. 저 같은 경우는 코드를 짜기 시작할 때 큰 그림을 그리지 못하고 손이 먼저 움직여서 결과적으로 좋지 않은 코드를 산출하게 되는 안 좋은 버릇을 가지고 있었는데, 이 시간을 가지고 난 뒤부터 조금씩 고쳐지고 있는 중인 것 같아요. 먼저 큰 그림을 시니어 분과 함께 그리고 코드를 작성하니 시간도 줄고 시행착오도 줄어들어요.

(신예) 평소에 워낙 이야기를 많이 하다 보니 개발팀 전체적으로 하는 주간회의는 오히려 짧게 마무리되는 것 같아요. 한 명의 팀원이, 그리고 하나의 TF가 어떤 일을 하고 있는지 전체적으로 짧게 공유하고 끝나니까요.

Q. 신예님과 형준님은 앞으로 어떤 개발자가 되고 싶으세요? 

(신예) 개발자가 되기로 결심한 이후 쭉, 장래에 어떤 개발자가 되고 싶은지 고민해왔는데요. 엔지니어링적으로 뛰어난 개발자가 되는 것도 좋지만, 그리고 그렇게 될 수 있도록 노력하고 있지만! 지금으로서는 제가 좋아하는 것들을 오래오래 ‘만들어 나가는 것’에 가치를 두고 싶어요. 따라서 앞으로도 제가 만드는 프로덕트에 꾸준히 애정을 가지고 업무에 임하고자 합니다. 서비스의 성장이 곧 저의 성장이라는 마음으로! 더 많은 사람들에게 사랑받는 지그재그가 될 수 있도록 성장에 기여하고 싶어요. 공부도 열심히 하고, 꾸준히 즐거운 마음으로 일하다 보면 엔지니어로써의 성장도 뒤따라 올 것이라고 생각합니다.

(형준) 생각하는 것을 큰 어려움없이 구현할 수 있는 개발자가 되고 싶습니다. 아직 주니어다보니 생각하고 잇는 것을 구현하려 할 때 iOS, Android만 구현이 가능하고 그 외에 것들은 쉽게 구현해낼 수 없는 것이 아쉬워요. 먼저 지금 하고 있는 iOS와 Android를 능숙하게 구현할 수 있도록 내공을 다지고, 어느 정도 실력이 쌓엿다고 판단되면 서버나 데이터 같은 다른 분야도 공부해보고싶다는 생각이 듭니다. 이렇게 다른 분야도 공부하다보면 언젠가는 생각하는 것을 뚝닥 구현해낼 수 있는 개발자가 될 수 있지 않을까요?

Q. 개인적으로 이게 가장 궁금했는데요. 항상 긍정적인 신예님과 형준님이 지그재그에 가장 아쉬운 점이 있다면? 정말로 리얼 혼또니 쩐더 괜찮으니까 솔직하게 말해주세요!

(신예) 음… relations팀에서 굳이 꼭 얘기해달라고 하셨는데… 사실 생각이 잘 안 나긴 하는데… 굳이 그래도 말씀해달라고 하신다면…

(형준) 신입 개발자 동료가 있으면 좋겠다는 것..!?! relations팀에서 부탁한 말은 절대 아닙니다. ㅎㅎ 심적으로, 그리고 업무적으로 함께 할 신입 개발자가 있으면 좋을 것 같다는 생각을 자주 합니다. 같이 개발 관련 이야기도 많이 할 수 있을 것 같아요. 그런 면에서 선배 개발자 분들도 많이 오셨으면 좋겠어요.

(신예) 초롱초롱하게 개발자 여러분들을 기다리고 있습니다! 여기 아래에서…!

지그재그에서는 안드로이드 개발자, iOS 개발자, 웹 개발자 신입을 활발하게 채용하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 🙂

궁금하신 점은 언제나 job@zigzag.kr 또는 http://facebook.com/zigzagcareer로 연락주세요!

https://career.zigzag.kr/recruit/