👀 1. 들어가며

1.1. 상황

데이터 분석가는 테이블 명세서를 보고 "아, 이 데이터면 충분하겠군!"이라고 쉽게 생각할 수 있습니다. 하지만 막상 데이터를 들여다보면, 현실은 늘 예상과는 다르죠. 예를 들어, 명세서에 'A' 컬럼에 고객이 구매한 시점이 기록된다고 되어 있다고 생각해보세요.'고객이 구매한 시점'은 언제를 의미할까요? 고객이 구매 버튼을 누른 순간을 의미하는 걸까요? 아니면 결제를 완료한 시점일까요? 이런 것들을 명확히 이해하지 않고 분석하면, 분석 결과는 엉뚱한 곳으로 흘러갈 수밖에 없습니다.

저 역시 처음엔 너무나도 쉽게 생각했어요. "아, 이 테이블 사용하면 바로 분석할 수 있겠군!" 하고 말이죠. 하지만 테이블을 조회하다 보니, 예상과 다른 데이터들이 눈에 띄기 시작했습니다. 그래서 직접 로그를 찍어보며, 어떤 행동에 어떻게 데이터 기록되는지 하나하나 확인해봤죠. 그 과정에서 제가 생각했던 것과는 전혀 다르게 데이터가 쌓이는 경우들을 발견하게 되었습니다.

이후에는 개발자와 직접 소통하며 테이블의 의미와 설계를 이해하려고 노력했습니다. 문제를 해결하기 위해 잘못된 데이터가 쌓이는 것을 수정 요청하기도 했죠. 그때 깨달은 것이 있습니다. 데이터 분석가는 단순히 데이터만 보면 안 된다는 것! 제품을 깊이 이해하고, 데이터를 수집하고 저장하는 방식까지 꼼꼼히 파악해야 한다는 것이죠!

내가 사용하는 데이터를 제대로 모르면, 지표는 정확할 수 없고 이 지표로 하는 의사결정은 제대로 됐다고 볼 수 없습니다! 이 글에서는 제가 믿을 수 있는 지표를 만들기 위해 데이터를 어떻게 깊이 이해하고 검증해 나가는지 공유해드릴게요. 단순한 NULL값 체크나 COUNT 검증을 넘어, 경험적으로 로그 테이블을 어떻게 확인하고 검증하는지를 공유하려고 합니다.

1.2. 예상 독자

• 데이터 분석가 및 데이터 활용 직군: 제품과 데이터의 생성 과정을 깊이 이해하고, 신뢰할 수 있는 지표를 만들고자 하는 분들에게 도움이 될 거예요.
• 데이터 엔지니어 또는 개발자: 분석가와 협업하여 데이터의 정확성을 높이고, 지표 신뢰성을 강화하고자 하는 분들이 참고하실 수 있을 거예요!

🔥2. 로그 데이터 검증 방법

Step 1. 테이블 명세서 확인하고 조회하기

테이블 명세서 확인
분석에 사용될 모든 컬럼 값의 의미를 정확히 이해하는 것이 중요합니다. 테이블 명세서에는 각 컬럼이 기록하는 데이터에 대한 설명이 테이블 설계자의 시각에서 작성되어 있습니다. 먼저 명세서를 꼼꼼히 확인하고 읽어보세요.

데이터 조회
명세서만으로는 데이터 파악이 충분하지 않습니다. 실제 데이터를 조회해보면서 명세서의 컬럼 의미와 조회 결과를 비교해보세요. 이 과정에서 명확하지 않았던 컬럼별 설명을 이해할 수 있을거예요.

만약 명세서가 없다면, 직접 테이블을 조회하여 각 컬럼의 의미를 작성해보고, 이를 바탕으로 테이블을 설계한 분과의 미팅을 통해 자신의 이해가 정확한지 확인하며 테이블 명세서를 만드는 것도 좋은 방법입니다.

Step 2. 데이터 흐름 파악하기

로그 데이터 흐름 파악하기
유저의 행동 로그를 시간 순서대로 정렬하고, 각 행동의 이전과 이후에 어떤 로그가 있는지 비교해보세요. 이 과정에서 예외 케이스나, 내가 모르던 행동 패턴들을 발견할 수 있습니다.

저는 윈도우 함수를 사용하여, 유저의 행동을 시간 순서대로 정렬한 후 이전 행동과 다음 행동을 파악하는데요. 먼저 특정 유저를 대상으로 조회해서, 유저가 어떤 흐름으로 행동했는지 파악합니다.

sql
SELECT user_id,
       event_time,
       event_type,
       LEAD(event_type) OVER (PARTITION BY user_id ORDER BY event_time) AS next_event
FROM user_logs

이때, COUNT를 해보는 것이 도움됩니다. 예를 들어, 유저가 A → B 로 B전에는 무조건 A를 해야하는데, 로그가 B → A 로 남은 경우가 있다면, 문제가 있다는 것입니다. 이렇게 특정 이벤트가 비정상적으로 많이 발생하거나 너무 적게 발생한다면, 테이블에 문제가 있다는 것을 빠르게 파악할 수 있습니다. 이 경우 개발자와 협의하여 로그 수집 로직을 점검하고 수정할 필요가 있습니다.

sql
SELECT event_type
	, next_event
	, count(1) as cnt
FROM
(    

  SELECT user_id,
         , event_time
         , event_type
         , LEAD(event_type) OVER (PARTITION BY user_id ORDER BY event_time) AS next_event
  FROM user_logs
)
GROUP BY 1,2

이 과정을 통해 데이터가 어떤 순서로, 어떤 조건에서 기록되는지 명확히 이해하고, 예상치 못한 문제를 발견합니다! 데이터가 꼬이거나 예상과 다르게 기록되는 상황을 사전에 발견할 수 있어, 더 신뢰할 수 있는 지표를 만드는 데 도움이 됩니다!

Step 3.직접 실험해보기

데이터 분석 과정에서 특정 케이스를 이해하기 어렵다면, 직접 실험해보는 것이 효과적입니다. 특정 이벤트가 발생하는 시점을 파악하기 위해 내가 직접 그 이벤트를 발생시키고, 해당 로그가 테이블에 어떻게 기록되는지 확인하는 건데요. 이 과정에서 데이터가 테이블명세서와 다르게 기록되는지, 또는 내가 파악하지 못한 케이스가 있는지를 확인 할 수 있어요!

특히 이렇게 실험해본 결과는 개발자와 커뮤니케이션할 때 매우 유용해요! 추상적인 설명보다는, 실험을 통해 얻은 케이스를 바탕으로 대화하면 더 명확하고 정확한 논의를 할 수 있습니다. 저는 아래와 같은 순서로 실험하곤 합니다!

• 1. 상황 시뮬레이션 :먼저 미리 발생될 수 있는 케이스나 검증하고 싶은 케이스를 정의하고, 어떻게 남을지 컬럼별로 데이터를 직접 입력해보세요.
• 2. 직접 실험 : 내가 정의한 케이스를 서비스에 접속해서 직접 행동하세요.
• 3. 데이터 확인 : 데이터를 조회하면서, 내가 시뮬레이션한 결과와 이벤트 발생 순서나 로그 시점이 잘 기록됐는지 확인합니다!

step 4. 커뮤니케이션하기

데이터 엔지니어 or 개발자와 커뮤니케이션
데이터를 확인하는 과정에서 실험만으로는 해결하기 어려운 경우나 적재 시점 변경 등의 커뮤니케이션이 필요할 수 있습니다. 미팅일 수도 있고 메시지로 확인 요청을 드릴 수있는데요. 두가지를 꼭 포함시키면 효과적으로 커뮤니케이션할 수 있어요!

데이터 확인 과정에서 실험만으로 해결하기 어려운 부분이 생기거나, 변경 요청사항이 생길 수 있습니다. 이럴 때는 데이터 엔지니어나 개발자와 커뮤니케이션이 필요합니다. 미팅이든 메시지든, 효과적인 소통을 위해 다음 두 가지를 꼭 포함하세요.

1) 목적
내가 데이터를 어떤 목적으로 사용하려는지 명확히 설명하세요! 담당자가 이를 이해하면, 필요한 데이터를 정확히 제공해줄 수 있고 설명해주실 수 있어요.

2) 구체적인 케이스
단순히 "이 테이블이 이상한 것 같아요"라고 말하기보다는, 예를 들어 "이 케이스를 보면 A'로 남고 있는데, A가 남아야 할 것 같아요"처럼 구체적인 상황을 설명하세요. 이렇게 하면 문제를 더 효과적으로 파악하고 해결할 수 있습니다.

발견한 케이스나 히스토리 아카이빙
이렇게 파악한 케이스를 위키 문서에 정리해서 동료들과 공유하세요. 다른 동료들도 업무를 할 때 도움을 받을 수 있고, 동료들도 알고 있는 정보들을 공유하며 더 나은 방향을 도출할 수 있으니까요. 이 과정은 우리 조직이 사용하는 데이터 더 나아가 데이터를 사용하여 도출하는 지표의 신뢰성, 지표를 통해 하는 의사결정의 정확성을 높이는데 기여할 거예요!

🙌 3. 정리하며

데이터 분석은 단순히 숫자와 결과를 다루는 것을 넘어, 데이터가 어떻게 생성되고 처리되는지에 대한 깊이있게 이해해야해요. 신뢰할 수 있는 지표를 만들기 위해서는 제품과 데이터의 생성 과정을 면밀히 이해하고, 이를 바탕으로 데이터의 정합성을 꾸준히 점검해야 합니다.

이번 글에서 다룬 여러 방법들(테이블 명세서의 이해, 로그 데이터 흐름 파악, 직접 실험,케뮤니케이션)을 직접 적용해보세요! "당신의 지표는 믿을 수 있나요?"라는 질문에 자신있게 네!라고 답할 수 있을거예요.