첫 데이터 로그 설계 실무와 그에 대한 퇴고

데이터 로깅이 필요했던 이유

현재 필자는 에듀테크 스타트업에서 일을 하고 있으며 홀로 데이터 분석일을 전담해서 진행하고 있다.

올해 초, PM에게서 회사 내부 AI가 추천해주는 문제의 난이도가 사용자가 풀기 너무 어렵다는 VOC가 증가하고 있다는 내용을 들었다.
이에 따라 실제 VOC의 내용이 맞는지 분석이 필요한 분석을 요청을 받았다.

우선 본격적으로 데이터를 분석하기 전 우리는 분석에 필요한 데이터가 있는지부터 확인해봐야 한다.

물론 모든 에듀테크 스타트업은 출제된 문제와 풀이한 정답 데이터를 서비스 DB에 저장한다.

다만 문제는 이 서비스 DB는 서비스를 하기위한 필수적인 데이터를 저장하는데 목적이 있지 분석에 필요한 모든 것을 저장하지 않는다는 점이다.

실제로 해당 데이터 분석에 앞서 필요한 데이터는 아래와 같았다.

• 대단원 ID
• 소단원 ID
• 문제 ID
• 유저 ID
• 문제 출제시점
• 문제 풀이시점
• AI가 예상한 문제 정답률 (DB 미입력)
• 문항 난이도 (DB 미입력)
• 사용자 답안
• 정오답 여부

이 중 분석에 가장 필요했던 데이터는 위에 빨간색으로 표기된 두 가지 항목이었지만 DB에 없는 상황이었다.

혹은 어떤 사람들은 이 상황에서 아래와 같은 의문이 들지도 모른다.

 

"그럼 개발자에게 요청해서 관련된 DB에 신규 칼럼 생성을 요청해서 넣어달라면 되는 거 아닌가요?"

 

만약 개발자에게 요청을 한다면 백엔드 개발자는 잠시 고민 후, DB에 추가하는 것 외에 다른 방법을 생각해 보는 게 어떻겠냐는 대답을 할 가능성이 높을 것이다.

이유는 수많은 이유가 있겠지만 필자가 개발자라고 했을 때 떠오르는 중요한 이유 두 가지로 볼 수 있는데,

1. DB에 칼럼을 추가한다는 행위 자체는 라이브 서비스를 닫고, 데이터가 잔뜩 쌓인 테이블을 수정하고 거기에 따른 오류 사항이 없는지 체크를 해야 된다. 상시 필요한 서비스 데이터가 아닌 분석용 데이터를 위해서는 너무 많은 리스크와 리소스가 필요한 작업이다.
   그리고 이러한 요청이 단발에 끝나라는 보장이 없다.
2. 만약 칼럼을 추가했다 하더라도 추가하기 이전의 데이터들은 칼럼 내 값들이 비어있는 상황이 된다. 이런 요청들이 반복될 경우 테이블 여기저기마다 구멍이 비었는 경우가 발생하고 히스토리를 모른다면 관리의 난이도가 급상승하게 된다. 또한 테이블 칼럼이 늘어날수록 RDB 비용이 상승하는 것은 덤으로 따라온다.

실제로 해당 업무를 진행하면서 위의 두 가지 문제도 문제였지만 서비스 DB 내 쌓이는 문제풀이 이력 데이터는 학습 도중 답안을 수정할 경우 수정되기 전 답안 대신 최종 답안만 저장된다는 문제점이 있다거나 특정 데이터의 경우 DB에 데이터를 쌓기 위해서는 백엔드 플로우를 대폭 개선이 필요할 수도 있다는 점 등 많은 문제들이 있었다.

 

관련해서 서버 데이터를 로깅하여 분석하는 방법을 고민하던 중 필자에게 백엔드 개발자 한 분이 반가운 이야기를 해주셨다.

문제 출제 및 문제 풀이 관련하여 이전부터 지속적으로 서버에 로그는 남기도록 개발은 이미 진행이 되어있다는 것이었다.

다만 내가 설계하고자 하는 형태와는 다른 방법으로 데이터가 로깅되고 있다는 점, 여기에도 필요한 데이터 중 일부가 빠져 있다는 점이 문제였다.

아쉬운 점은 있지만 맨땅에 헤딩은 아니라서 다행이다.

사실 필자가 설계를 계획했던 문제 출제 & 풀이 관련 로그의 형태는 아래와 같다.

대단원ID	소단원ID	문제ID	유저ID	문제 출제/풀이 여부	AI 예상 정답률	문항 난이도	사용자 답안	정오답 여부	timestamp
1	10	101	1000	출제	0.37	상	null	null	1711179380
1	10	101	1000	풀이	0.37	상	-1	False	1711179390

위의 데이터 외에도 다양한 데이터가 들어가야 하지만 간단하게 표현해 봤다. 

이렇게 설계할 경우 이후에 해당 이벤트 데이터를 조회할 경우 한 곳에서 문제 별 평균 정답률 및 풀이시간, 난이도 별 출제 현황 등 다양한 데이터를 뽑을 수 있을 것이다.

하지만 필자가 전달받은 형태는 문제 출제와 문제 풀이 이벤트가 분리된 형태였으며 필요한 필드가 없어 추가가 필요한 상태였다.

 

문제 출제 이벤트 로그

대단원ID	소단원ID	문제ID	유저ID (추가 필요)	AI 예상 정답률 (추가 필요)	문항 난이도 (추가 필요)	timestamp
1	10	101	1000	0.37	상	1711179380

 

 문제 풀이 이벤트 로그

대단원ID	소단원ID	문제ID	유저ID (추가 필요)	AI 예상 정답률 (추가 필요)	문항 난이도 (추가 필요)	사용자 답안	정오답 여부	timestamp
1	10	101	1000	0.37	상	-1	False	1711179390

 

기존에 설계한 로그와 비교했을 때 각 이벤트 별로 데이터 스캔비용이 감소된다는 점, 이벤트 trigger 관리 측면에서 장점이 있긴 하지만 결국 관리해야 되는 이벤트가 2개로 늘어나며 풀이시간 집계 등 두 이벤트 모두 조회가 필요한 경우 쿼리 작성의 어려움 등으로 인해 오히려 비용이 상승하게 된다는 단점 또한 존재한다.

그래도 이전에 개발되었던 로깅 부분을 없애고 새로 심기는 어려운 상황이었기 때문에 기존의 로그에 필요한 부분을 추가하여 사용하기로 결정했다.

 

이후 위의 이벤트 외에도 서버에 쌓이는 다른 이벤트 로그들의 존재를 찾아 문서화를 진행하였다.

문서를 진행하면서 다른 회사에서는 어떻게 이벤트 템플릿을 관리하는지 사례를 많이 찾아봤다.

특히 쏘카에 계셨던 변성윤 님의 게시글이 상당히 많이 도움이 됐으며 해당 게시글이 정말로 많은 도움이 되었다.

 

문서화에 있어서 가장 문제가 많이 되었던 용어 통일이 제일 문제였다.

아래는 실제 있었던 사례를 재구성한 대화다.

 

개발자 A : "팡팡님 로그 데이터 문서에 estimatedScore라는 영역 추가 요청해주신 것 맞을까요?"

필자 : "네 맞습니다. 말씀하신 영역은 AI가 예측한 학생의 정답률을 넣어 주시면 됩니다."

개발자A : "잠시만요... 그니까 요청을 주신 게 학생들의 해당 소단원 목표 점수가 아니라 AI 예측 점수라는 거죠?"

필자 : "네, 근데 혹시 소단원 목표 점수와 연관된 게 있나요? 제가 알기로는 전혀 다른 데이터로 알고 있는데요."

개발자 A : "제품 내부에서는 score가 들어간 변수는 원칙적으로 0~100 사이의 소단원 결과 점수를 의미를 해서요. 보통 문제 풀이 결과 관련 변수는 result가 들어가도록 관리하고 있기 때문에 헷갈리네요."

필자 : "그러면 estimatedResult로 영역명을 변경해도 괜찮을까요? 제가 봐도 헷갈릴 수 있을 것 같네요."

 

해당 대화 이후 기존에 만든 영역명과 데이터 타입을 전체 재검수했으며 애매하다 싶은 네이밍은 개발자와의 논의를 통해 문서화를 진행하였다. 만약 해당 작업이 제대로 명확하지 않을 경우 같은 데이터인데도 다른 용어를 쓴다던지 네이밍 케이스 규칙이 없어 어디는 snake case, 어디는 camel case로 쓰는 등 많은 문제를 야기할 수 있기 때문에 문서화 및 설계 단계에서 많은 공을 들여야 된다는 것을 배울 수 있었다.

 

문서화 이후에 문제가 된 부분은 언제 event를 trigger 시키는 시점에 대한 논의가 문제였다.

사실 정확하게는 논의를 하지 않은 것이 문제였다.

때문에 DB에 데이터가 쌓이는 것과 같은 시점에 event가 trigger 될 것이라고 너무나 안이하게 생각하고 있었다.

개발이 완료되고 Data QA를 진행할 때 DB에 쌓인 데이터와 로그 데이터가 쌓이는 것이 다르다는 것을 그때 알아차렸고,

개발자와의 대화를 통해 언제 event가 trigger 되는지 정확하게 파악한 뒤, 로그 데이터 문서에 명확하게 기입했다.

trigger 되는 시점은 DB에 데이터가 쌓이는 시점과 달랐지만 오히려 분석에 필요한 데이터가 잘 쌓일 수 있는 시점이었기에 큰 문제는 없었지만 잘못하면 개발을 2번 해야 될 수 있었기에 다음부터는 반드시 신경을 써서 챙겨야 되겠다고 크게 생각되는 부분이었다.

 

결론.

모든 우여곡절 끝에 데이터 QA까지 마친 후, 무사히 배포가 진행되었고 기존에 데이터 엔지니어와 논의한 프로세스에 맞춰 SQL로 데이터를 확인할 수 있었다.

해당 작업을 통해 배울 수 있는 점은 아래와 같았다.

1. 로그 데이터를 이용한 분석은 DB 내 저장하지 못한 데이터를 분석할 수 있는 방법 중 하나이다.
2. 로그 데이터를 잘 사용하는 방법은 데이터를 쌓기 전부터 관련된 모든 것을 잘 정리하는 것이 베스트다.
3. 모든 일은 커뮤니케이션이 중요하지만 이번 작업은 그 중요성을 다시금 느낄 수 있는 프로젝트였다.

마지막으로 PM이 요청한 데이터 분석 결과를 간단하게 설명하자면 아래와 같다.

• 모든 사용자는 소단원을 공부하기 전 이전 성적을 기반으로 최하~최상 수업 난이도를 가지고 수업에 들어간다.
• 그리고 AI가 추천해 주는 문제는 이전의 문제 풀이 이력 및 현재 수업 난이도 기반으로 문제가 출제된다.
• 데이터 분석 결과 최하~중간 수업 난이도 학생들을 대상으로 어려운 난이도의 문제들이 예상보다 훨씬 높은 비율로 출제되고 있었다.
• 논의한 결과 AI가 추천해주는 문제 n개 중 출제될 문제를 필터링을 하는 부분이 문제로 판단되어 로직을 변경하였다.
• 해당 배포 이후 관련 VOC가 크게 줄어들었다.