좋은 기회가 생겨 업무를 배우고 있다. 입사 2주 차가 되어 느낀 바로는 주된 업무가 데이터 분석은 아니고, 로그 데이터를 QA 하며 데이터 품질을 효율적으로 관리하는 데 기여할 수 있는 직무 같다.
데이터 관련 업무 경험은 이곳이 처음이라, 입사일을 앞두고 막막함과 경직됨을 느꼈다. 이제까지의 경험을 미루어보았을 때, 나는 보고 듣는 것보다 직접 부딪히고 적용할 때 더 많이 배우는 편이라, 입사 초기에는 무엇이든 부딪히고 해결해 나가며 유연하게 적응하는 것이 목표였다.
2주가 지난 지금은 내가 무언가를 해결한다.. 는 먼 이야기 같고, 대신 나의 역량이 얼마나 부족한가를 매일매일 느끼는 중이다. 2주 차에는 QA 업무를 배우고 조금씩 해보기 시작했는데, 나에게 병목이 발생하면 안 된다는 생각에 급하게 QA를 하다 보니 문득 생각 없이 주어진 일을 하고 있는 내 모습을 발견했다. 내가 그동안 어떻게 QA를 하고 있는지 실수했던 것 위주로 점검해 보고, 앞으로의 수습 3개월 동안의 목표를 세워 보았다.
나의 QA 일지
1. 누락된 로그와 파라미터 점검
사내 제품의 각 퍼널마다 어떤 로그와 파라미터가 남는지 파악 가능한 저장소가 있다. 이를 실시간으로 쌓이는 로그와 비교해 가며 누락된 로그와 파라미터가 있는지, 파라미터값은 예상대로 찍히고 있는지 확인한다. 만약 누락되는 로그가 있거나 파라미터 값이 정의한 대로 기록되지 않는다면, 이어지는 분석 업무에 큰 영향을 줄 수 있으므로 꼼꼼히 확인해야 하는 중요한 작업이다.
2. 순서대로 찍히는지 점검
퍼널마다 순서대로 로그가 찍히고 있는지 확인한다. 예를 들어, 노출 이벤트 다음 클릭 이벤트가 찍혀야 하는데, 로그가 찍힌 순서가 반대라면 문제가 된다. 이때 주의해야 할 점은 정렬 기준인 시간 필드인데, 이게 프로세스 시간인지 이벤트 시간인지 구분해야 한다. 클라이언트 상에서 로그가 생성된 시간을 이벤트 시간이라 하고, 서버가 처리하는 시간을 프로세스 시간이라고 한다. 데이터 분석은 이벤트 시간을 기준으로 하기 때문에, 시간 순서대로 확인하려면 (프로세스 시간이 아니라) 이벤트 시간을 기준으로 정렬해야 한다.
3. 예상된 시나리오대로 찍히고 있는지 점검
처음에는 퍼널을 정의하고, 테스트 기기를 사용해 일반적인 방식으로 퍼널을 타서 로그가 예상대로 찍히는지 확인하면 되는 줄 알았다. 그런데 그게 아니라, 어떤 시나리오로 퍼널을 타는지에 따라 유입 파라미터값이 다를 수 있고 특정 로그가 아예 안 찍힐 수도 있다는 것을 알게 되었다. 그래서 QA하기 전에 미리 여러 가지 가능성을 고려하여 시나리오를 짜고, 실제로 예상대로 로그가 쌓이고 있는지 또는 로그가 중복으로 발생하진 않는지 확인해야한다. 시나리오에 따라 파라미터값이 다르게 찍힐 수도 있기 때문에, QA를 시작하기 전에 시나리오별 파라미터 예상값을 기록해 두는 것이 QA 시간을 줄여준다.
앞으로의 목표
4월 목표 :
-
업무툴(kibana, jira, hue, 사내 툴 등)에 대한 이해를 높이고 그 밖의 새로운 기술에 대한 빠른 학습과 활용 감각 키워나가기.
-
담당 서비스의 퍼널을 파악하고 로그 QA 참여
- 로그와 파라미터가 어떤 목적(ex. 분석, 실험)으로 활용되는지 파악
5월 목표:
- 담당 서비스의 로그 정의
- 로그 정의 후 활용되는 과정 추적
- 로그 정의 단계에서 다른 대안이 없었는지 논의
- QA 진행 중 실수 문서화
- 빠트린 작업이나 실수를 방지하고자 기록
- 로그 모니터링 방식이 상황마다 무엇이 다른지 파악하고, 각 방식의 장단점 설명하기
6월 목표:
- 로그 모니터링 단계에서 병목을 확인하고 효율적으로 개선할 방안 제시
- 로그 관련 사내 툴 개선 아이디어 도출
마무리하며
입사 2주가 지나고 있는데 현재 내가 무슨 일을 하는지, 팀에게 어떤 기여를 할 수 있을지 여전히 명확하지 않은 막막한 상황이다. 아직 업무 이해도 부족하고 경험도 부족하지만, 좌절하고 아무것도 안 하는 것보단 현재 상황을 스냅샷으로 남겨 앞으로 개선해 나가는 것이 나은 선택이라는 생각이 들었다. 입사 3개월이 지난 시점에 오늘 작성한 부분에서 어떤 접근방식이 잘못되었고, 어떻게 개선했는지 회고하는 글을 써야겠다.
