QA를 위한 데이터 확인 — SQL·로그·분석 태그

학습 목표

이 모듈 한 줄 요약 — "'정상' 이라고 적을 때 우리가 본 것은 화면뿐이다". "주문 완료" 문구가 떴다고 해서 주문이 한 건만 저장됐는지, 금액에 할인이 반영됐는지, 로그에 오류가 조용히 쌓이고 있지 않은지는 모른다. 화면 뒤의 데이터를 직접 확인하는 법을 다룬다 — 이걸 못 하면 "화면은 멀쩡했다" 가 전부가 된다.

테스트를 마치고 "정상"이라고 적을 때, 우리가 실제로 확인한 것은 대개 화면에 그려진 픽셀 뿐이다. 주문이 완료됐다는 문구가 떴다고 해서 주문 테이블에 행이 하나만 들어갔는지, 금액이 쿠폰 할인을 반영한 값인지, 결제 로그에 예외가 조용히 쌓이고 있지는 않은지, 그 화면에서 마케팅팀이 기대하는 purchase 이벤트가 정말 전송됐는지는 아무도 확인하지 않았을 수 있다. 이 모듈은 그 빈칸을 메운다. 화면 뒤의 세 층 — 데이터베이스, 로그, 분석 수집 —을 QA 가 직접 열어 보는 법 을 다룬다.

첫 두 레슨은 SQL 이다. 모듈 9(레슨 5)에서 SELECT·WHERE·JOIN 을 처음 봤다면, 여기서는 예제 스키마(회원·주문·주문상품·쿠폰)를 하나 정해 놓고 그 위에서 끝까지 간다. 집계와 그룹핑으로 "합계가 맞는가"를 묻고, 조인의 방향을 바꿔 "있어야 할 것이 없는가"를 묻는다. SQL 을 한 줄도 써 본 적 없는 사람도 레슨 1을 순서대로 따라오면 조회할 수 있게 썼다. 대신 처음부터 못을 하나 박는다 — QA 가 운영 데이터베이스에서 하는 일은 읽기뿐 이다. 왜 그런지, 읽기 전용 계정이 무엇을 막아 주는지, 잘못된 조회 하나가 어떻게 운영 장애가 되는지를 같이 다룬다.

다음 두 레슨은 로그다. 로그를 "개발자가 보는 것"으로 남겨 두면 결함 리포트는 영원히 "안 돼요"에서 멈춘다. 애플리케이션 로그·웹 서버 액세스 로그·브라우저 콘솔이 각각 무엇을 알려 주는지, 로그 레벨이 왜 그렇게 나뉘어 있는지, 구조화 로그(JSON)에서 무엇을 뽑아야 하는지를 실제 샘플을 놓고 읽는다. 그리고 그것을 증거 로 바꾼다. 상관 ID(correlation ID)와 타임스탬프와 스택 트레이스 세 가지를 붙인 결함 리포트는 개발자가 받자마자 로그를 검색할 수 있고, 그만큼 빨리 고쳐진다.

마지막 두 레슨은 분석 태그다. 기능은 멀쩡한데 수집이 깨져서 조직 전체가 틀린 숫자로 의사결정하는 일은 흔하고, 그 결함을 찾아낼 자리에 있는 사람은 대개 QA 다. GA4 이벤트와 데이터 레이어(dataLayer)가 설계대로 발사되는지 브라우저 네트워크 탭·GTM 미리보기·GA4 DebugView 로 직접 확인하는 절차 를 익히고, 수집된 데이터 자체의 품질 — 중복·누락·표본비 불일치(SRM) —을 판정하는 데까지 간다.

완료 후 할 수 있는 것

• 예제 스키마에서 SELECT·WHERE·ORDER BY·JOIN·GROUP BY·HAVING 를 조합해 화면에 보이는 값의 근거 데이터를 직접 조회할 수 있다
• NULL 이 비교·집계·조인에서 어떻게 동작하는지 알고, 그 때문에 생기는 "행이 사라지는" 조회 오류를 피할 수 있다
• 경계 조건·중복 행·고아 레코드(부모 없는 자식 행)·합계 불일치를 찾는 정합성 조회를 작성하고, 결과를 결함으로 판정할 수 있다
• QA 가 운영 DB 에서 읽기만 해야 하는 이유를 설명하고, 읽기 전용 계정·트랜잭션 잠금·장시간 조회의 위험을 관리할 수 있다
• 애플리케이션 로그·액세스 로그·브라우저 콘솔을 구분해 읽고, 로그 레벨과 구조화 로그 필드에서 원인 후보를 좁힐 수 있다
• 스택 트레이스에서 "우리 코드의 첫 줄"을 찾아내고 Caused by 사슬을 거슬러 근본 예외를 지목할 수 있다
• 상관 ID·타임스탬프(시간대 포함)·스택 트레이스·요청 본문을 묶어 개발자가 즉시 재현·검색할 수 있는 결함 증거를 만들 수 있다
• GA4 이벤트 설계서(측정 계획)를 읽고, 이벤트 이름·매개변수 규칙과 수집 한도에 비춰 설계 자체의 결함을 지적할 수 있다
• 브라우저 네트워크 탭·GTM 미리보기·GA4 DebugView 세 가지로 태그가 설계대로 발사되는지 교차 검증할 수 있다
• 수집 데이터의 중복·누락·이벤트 순서 이상을 조회로 잡아내고, 카이제곱 검정으로 표본비 불일치(SRM)를 판정해 실험 결과를 보류시킬 수 있다

채용시장에서의 위치

국내 QA 공고에서 이 모듈의 내용은 "SQL 활용 가능", "데이터 검증 경험", "로그 분석 능력", "GA·GTM 이해" 같은 문구로 흩어져 나타난다. 특히 "SQL 활용 가능"은 신입·주니어 공고의 우대사항에서 가장 자주 보이는 항목 이면서, 동시에 지원자 대부분이 "학원에서 배웠습니다" 수준에서 멈추는 항목이다. 변별력은 문법이 아니라 용도에서 갈린다. JOIN 을 쓸 줄 아는 것과 "결제 성공 화면이 떴는데 주문 상세 행이 2건 들어간 것을 조회로 찾아 결함으로 등록했다"는 것은 면접에서 전혀 다른 무게를 갖는다.

로그 읽기는 공고에 잘 안 적히지만 실무에서 가장 빨리 평가가 갈리는 능력이다. 같은 결함을 두고 "로그인이 안 됩니다"라고 쓰는 QA 와 "traceId=8f3c… 요청에서 NullPointerException 이 CouponService.apply() 에서 발생, 쿠폰 만료일이 NULL 인 계정에서만 재현"이라고 쓰는 QA 는 개발팀이 체감하는 가치가 다르다. 이 차이는 경력 1년 차에도 만들 수 있다.

분석 태그 검증은 자리가 비어 있는 영역 이라 기회가 크다. 그로스·프로덕트 조직에서 GA4·GTM 구현은 마케터와 개발자 사이에 끼어 있고, "설계서대로 수집되는지 검증하는 사람"이 정해져 있지 않은 회사가 많다. QA 가 그 자리를 가져가면 프로덕트 애널리스트·프로덕트 QA(모듈 45)로 넘어가는 다리가 생긴다. 데이터 품질 문제를 실제로 잡아낸 경험 — 중복 purchase 이벤트로 매출이 부풀려진 것을 찾았다거나, SRM 때문에 A/B 테스트 결과를 폐기시킨 것 — 은 QA 경력 중에서도 임팩트를 숫자로 말할 수 있는 몇 안 되는 이야기다.