분석용 이벤트 로그 점검/정리하기 #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
이렇게 코드 작성을 마친 뒤, 연미님의 코드 리뷰가 진행되었습니다.
Yeonmee의 코드리뷰가 간닷!지그재그에서는 꼭 다른 동료의 코드 리뷰를 거친 뒤 실 서비스에 반영합니다. 코드를 작성한 사람은 자기의 코드를 계속해서 봐왔기 때문에 오히려 놓치는 부분이 생길 수 있습니다. 코드를 작성하지 않은 사람이 새로운 시각으로 코드 리뷰를 진행하면 더욱더 꼼꼼하게 리뷰할 수 있습니다. 지그재그 팀에서는 코드 리뷰를 진행할 때 주로 아래 사항들에 대해 리뷰합니다.
구조/논리적 오류
- 설계와 다르거나 누락된 사항
- 성능 저하(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였습니다. 데이터팀과 앱개발팀이 어떻게 협업하는지에 대해 조금 더 깊게 알 수 있었고, 앱 전체를 구석구석 살펴보며 많은 화면들과 기능에 대해 좀 더 빠르게 이해할 수 있었습니다. 그리고 정말 설계와 리뷰가 중요함을 느꼈습니다. 설계를 하지 않은 경우 생길 수 있는 문제, 어떻게 리뷰를 해야 하는지를 좀 더 잘 알게 되었습니다. 이 글을 쓰는데 많은 도움을 주신 연미님께도 다시 한 번 감사드리고요! :-D
긴 글을 읽어주셔서 감사합니다! ^0^
