숫자로 말하는 비즈니스의 얼굴, QA 금융 리포트 테스트

비즈니스 의사결정 오류:
- 잘못된 매출 통계 보고서는, 회사가 유망하지 않은 상품에 투자를 늘리는 등의 치명적인 실수를 하게 만들 수 있습니다.
규제 준수 실패:
- 금융감독원과 같은 감독 기관에 제출하는 보고서의 숫자가 틀릴 경우, 과징금 부과 등 심각한 법적 제재를 받을 수 있습니다.

‘리포트 테스트’는 대상과 목적에 따라 접근법이 달라집니다.

1. 내부 경영 보고서 (BI 리포트):
- 대상: 경영진, 데이터 분석가, 마케팅팀 등
- 핵심: 비즈니스 KPI(핵심 성과 지표)의 정확성을 검증합니다.
- 예: 일일 활성 사용자(DAU), 신규 가입자 수, 총 거래액, 상품별 판매량
2. 규제 기관 보고서 (Regulatory Reports):
- 대상: 금융감독원, 금융위원회, 한국은행 등
- 핵심: 정해진 양식(Layout)과 계산식, 그리고 관련 법규를 100% 준수하는지 여부를 검증합니다.
3. 고객 제공용 보고서 (Customer Reports):
- 대상: 고객
- 핵심: 고객 개인의 거래 내역, 자산 현황 등이 정확하고, 이해하기 쉽게 표현되었는지 여부를 검증합니다.
- 예: 월별 신용카드 이용 명세서, 연말정산용 거래내역서

‘보고서 검증’의 본질은, ‘리포트에 표시된 숫자’와 ‘원본 데이터베이스의 진실’이 완벽하게 일치하는지 확인하는 것입니다.

검증 방법:
- QA는 리포트의 특정 숫자(예: ‘8월 총 이체 성공 금액: 1,520,000,000원’)를 검증하기 위해, 직접 데이터베이스에 접속합니다.그리고 동일한 조건으로 SQL 쿼리를 실행하여, 원본 데이터를 직접 집계합니다.
“8월 한 달간의 성공한 이체 거래 총액을 직접 계산하는 쿼리”
- SELECT SUM(amount)
- FROM transactions
- WHERE type = ‘TRANSFER’
- AND status = ‘SUCCESS’
- AND transaction_date >= ‘2025-08-01’
- AND transaction_date < ‘2025-09-01’;

과거에 ‘일일 사용자 리포트’ 테스트 중 겪었던 문제입니다.

리포트에는 ‘어제 가입한 총 회원 수’가 100명으로 나왔는데, 제가 데이터베이스에서 직접 COUNT를 해보니 105명이었습니다.

근본 원인 분석 결과, 개발자가 리포트 집계 쿼리에 ‘정상 회원’이라는 조건을 빠뜨려, 테스트용으로 생성된 ‘내부 직원 계정’ 5개가 함께 포함되었던 것입니다.

이 경험을 통해, ‘리포트 테스트’는 단순히 숫자가 맞는지만 보는 것이 아니라는 것을 배웠습니다.

그 숫자를 만드는 ‘조건과 필터’가 비즈니스 로직과 100% 일치하는지 반드시 검증해야 한다는 중요한 교훈을 얻었습니다.

‘리포트 테스트’는 회사의 과거를 기록하고, 현재를 진단하며, 미래의 방향을 결정하는 나침반의 눈금을 검증하는 일입니다.

QA는 데이터 탐정이 되어, 숫자의 근원을 추적하고 그 정확성을 보증해야 합니다.

신뢰할 수 있는 리포트는, 팀 전체가 데이터에 기반하여 자신감 있게 의사결정을 내릴 수 있게 하는 가장 튼튼한 기반이 됩니다.