반복 검증을 AI에 넘긴 뒤, QA에 남는 일
안녕하세요. 저는 엑셈에서 MaxGauge 제품 QA를 담당하고 있는 제품기술연구1팀 정경수입니다.
글의 제목에 사용한 QAI라는 표현은 제가 만들어낸 말입니다. 익숙한 단어처럼 보이지만, 품질보증 업무와 직결된 표현은 아닙니다.
엑셈에 입사하고 QA 업무를 하면서 AI를 자연스럽게 자주 활용하게 되었고, 어느 순간부터 QA도 이제는 AI와 함께 일하는 방식으로 변화해야 한다고 느꼈습니다. 제가 생각하는 QAI에는 다음과 같은 의미가 담겨 있습니다.
∙ Quality Assurance with AI
∙ Quality Automation Intelligence
∙ Quality Assurance Intelligence
기존의 QA가 제품의 품질을 확인하고 보증하는 역할을 해왔다면, 앞으로의 QA는 AI를 활용해 더 빠르고, 더 정확하고, 더 넓은 범위를 검증할 수 있어야 합니다. 그래서 저는 제 업무 방향을 담아낼 단어로 「QAI」를 써보기로 했습니다.
1. 반복 검증에서 시작된 문제의식
제가 AI를 가장 많이 활용한 부분은 반복성이 높고 수작업 부담이 큰 검증 업무였습니다. QA 업무에는 반복적인 확인 과정 속에서도 정확성과 일관성이 요구되는 작업이 많습니다.
여러 데이터를 비교하거나 결과를 정리하는 일처럼, 단순해 보이지만 실제로는 상당한 시간과 집중이 필요한 업무도 적지 않습니다. 수작업 중심의 검증 방식은 아무리 주의를 기울여도 휴먼 에러가 발생할 수 있고, 정해진 기간 안에 모든 항목을 안정적으로 검증하는 데에도 한계가 있었습니다.
이러한 문제를 AI와 자동화를 통해 보다 효율적이고 일관된 방식으로 개선할 수 있지 않을까, 그것이 고민의 시작이었습니다.
2. RTS 에이전트 검증을 자동화 대상으로 고른 이유
입사 초기 OJT 기간 동안 MaxGauge의 RTS 에이전트를 검증하는 업무를 여러 차례 수행했습니다. 그 과정에서 반복되는 검증 작업이 많다는 것을 알게 되었고, 「이 부분을 자동화할 수 있지 않을까?」라는 생각을 하게 되었습니다.
RTS(Real Time Server)는 MaxGauge가 데이터베이스의 성능 데이터를 수집해 전송하는 에이전트입니다. 수집한 데이터가 정확한지, 프로세스와 커맨드가 정상 동작하는지, 화면에 제대로 표시되는지를 모두 확인해야 검증이 끝납니다.
이후 최종 발표를 준비하며 검증 과정을 자동화하는 아이디어를 구체화했습니다.
아래는 자동화 도구를 구상하며 정리했던 아이디어 스케치입니다. Target과 Repository를 몇 초 단위로 맞춰 볼지, 한 번에 몇 건을 모아 비교할지, 화면은 몇 개로 나눌지를 손으로 그려가며 정했습니다.
발표 이후에는 팀에서 실제로 활용할 수 있도록 기능을 고도화했습니다. 현재는 해당 자동화 도구를 팀 검증 업무에 활용하고 있습니다.
이 작업은 제가 기존에 관심을 가져온 자동화 경험을 MaxGauge QA 업무에 직접 연결해볼 수 있는 계기가 되었습니다.
검증은 대상 DB를 준비하는 것부터 시작합니다. 테이블을 만들고 로깅용 잡을 생성한 뒤 로깅이 활성 상태인지 확인하고, 검증이 끝나면 만들어 둔 객체를 삭제합니다. 비교는 STAT과 WAIT 두 계열의 지표를 조회 기간과 함께 지정해 실행합니다.
화면은 같은 시각의 지표를 Target DB와 Repository DB로 나란히 놓고 비교합니다. session logical reads와 DB time처럼 수집 대상 지표를 계열별로 그려, 두 값이 어긋나는 구간을 눈으로 확인할 수 있습니다.
다만 RTS 검증이 이 화면 하나로 끝나는 것은 아닙니다. 확인해야 할 영역이 여러 갈래여서, 어디부터 자동화할지를 먼저 정해야 했습니다.
3. 검증 영역을 3단계로 나눈 기준
RTS 검증 자동화의 목표는 팀에서 반복적으로 수행하는 주요 검증 기준을 단계적으로 자동화하는 것입니다. 한 번에 전체를 붙이는 대신, 영역마다 자동화 난도와 판단 기준이 달라서 순서를 정해 하나씩 채워가는 편이 안전하다고 봤습니다.
현재 자동화 도구는 아래 3가지 검증 영역을 모두 100% 구현했으며, 지금은 세부 보완을 통해 안정성과 정확도를 높이는 단계입니다.
구현 완료한 검증 영역
- 수집 데이터 및 정합성 검증
- RTS 프로세스·커맨드 검증
- 화면 표시·사용성 검증
따라서 이제는 기능을 새로 추가하기보다, 실제 검증 업무에서 같은 조건으로 반복 실행했을 때 결과가 일관되게 나오는지 확인하고 예외 케이스를 보완하는 데 집중하고 있습니다.
이 기능은 Target과 Repository에서 수집한 데이터를 두 가지 방식으로 비교합니다. Delta는 같은 시각의 diff_value를 비교하는 방식이고, Delta Sum은 시간 구간별 데이터를 합산해 비교하는 방식입니다.
Delta 화면에서는 원본 행 수와 고유 시각 수를 함께 표시합니다. 원본 행 수는 실제로 수집된 전체 행의 개수이고, 고유 시각 수는 같은 초의 중복 행을 하나로 계산한 비교 대상 시각의 개수입니다. 예상 시각 수와 고유 시각 수를 비교하면 데이터가 누락되었는지, 같은 시각에 여러 행이 수집되었는지 확인할 수 있습니다.
같은 시각의 diff_value를 비교한 결과는 초 단위 일치율과 불일치 건수로 표시됩니다. 누적 시계열에서는 Target과 Repository의 값 변화를 함께 보여 주어 차이가 발생한 구간을 확인할 수 있습니다. 따라서 이 화면은 수집 건수뿐 아니라 실제 시각별 값이 일치하는지도 함께 검증합니다.
Delta Sum 화면에서는 각 시간 구간의 Target 합계와 Repository 합계를 비교합니다. diff_ratio는 Repository 합계 ÷ Target 합계 × 100으로 계산하며, 현재 기준으로 99~101% 범위이면 합계 기준 정상으로 판단합니다. 동시에 시간 버킷별 불일치 건수와 시간 버킷 일치율도 표시하므로, 전체 합계는 비슷하지만 특정 시간대의 값이 다른 경우도 확인할 수 있습니다.
따라서 이 검증의 정상 여부는 Target의 절댓값과 Repository의 절댓값이 무조건 같은지를 보는 것이 아니라, 동일한 시간 범위와 기준으로 수집된 데이터가 같은 시각과 같은 시간 구간에서 일관되게 비교되는지를 확인하는 방식으로 판단합니다.
4. 자동화 도구도 검증해야 합니다
물론 자동화를 진행하면서 새로운 고민도 생겼습니다. 제품을 검증하기 위해 만든 자동화 도구 역시 검증이 필요했기 때문입니다.
도구가 의도한 대로 동작하는지, 예외 상황에서도 올바르게 판단하는지, 실제 검증 결과를 신뢰할 수 있는지. 이를 확인하는 과정이 반드시 필요했습니다.
처음에는 「자동화 도구를 만들고, 그것을 다시 검증하는 데 드는 리소스가 과연 합리적인가?」 하는 의문이 있었습니다. 하지만 장기적인 관점에서 보면, 지금 투자하는 시간이 이후 반복 업무를 줄이고 검증 품질을 높이는 데 더 큰 효과로 돌아올 것이 분명합니다. 실제로 업무를 진행하면서 그 효과를 조금씩 체감하고 있습니다.
이번 검증은 Target DB에서 실행한 PL/SQL 테스트가 Repository DB에 정상적으로 수집되는지 확인하는 과정입니다. 단순히 데이터 존재 여부만 확인하는 것이 아니라 SQL별 실행 횟수와 실행 시간을 비교해 수집 과정에서 누락이나 차이가 발생했는지 검증합니다.
화면의 Case 1~5는 실행 시간이 서로 다른 테스트 프로시저로 구성됩니다. 실행 시간이 긴 SQL부터 매우 짧게 실행되는 SQL까지 반복 실행하여 실행 시간에 따라 수집 결과가 달라지는지도 함께 확인합니다.
테스트가 완료되면 Target DB의
V$SQL에서 다음 항목을 기준값으로 조회합니다.- SQL_ID
- 실행 횟수
- 전체 실행 시간
- 1회 실행당 평균 실행 시간
이후 같은 SQL_ID를 기준으로 Repository DB에 수집된 결과를 조회하고 Target DB의 기준값과 비교합니다. 실행 횟수가 일치하고 실행 시간과 평균 실행 시간이 일정한 범위 안에 있으면 정상적으로 수집된 것으로 판단할 수 있습니다.
「미수집(<1s)」은 실행 시간이 매우 짧은 SQL이 Repository에서 확인되지 않았을 때 표시됩니다. 이는 짧은 실행 시간으로 인해 수집되지 않았을 가능성을 나타내며, 해당 표시만으로 오류라고 단정할 수는 없습니다. 반대로 실행 시간이 충분한데도 결과가 없거나 실행 횟수가 일치하지 않는다면 수집 시각, 수집 주기 및 Repository 적재 상태를 추가로 확인해야 합니다.
한편, 하단의 데이터 분석 결과에서는 통계 지표별 수집 데이터 포인트와 Target·Repository의 평균값, 평균 차이값을 확인할 수 있습니다.
평균 차이값은 다음과 같이 계산합니다.
평균 차이값 = Target 평균값 - Repository 평균값
차이값이 양수이면 Target 평균이 더 크고, 음수이면 Repository 평균이 더 크다는 의미입니다. 화면의 색상도 차이의 방향을 구분하기 위한 것으로, 색상만으로 정상이나 오류를 판단하지는 않습니다.
Target과 Repository의 값은 수집 시점과 저장 시점의 차이로 인해 완전히 동일하지 않을 수 있습니다. 따라서 특정 값 하나만 보기보다 수집 데이터가 충분한지, 두 환경의 평균값이 유사한 흐름을 보이는지, 특정 시점의 차이가 반복되는지를 함께 확인하는 것이 중요합니다.
결과적으로 이 기능은 Target과 Repository의 값이 완전히 같은지를 확인하는 데 목적이 있는 것이 아니라, 동일한 조건에서 수집된 데이터가 전반적으로 일관되게 비교되는지를 확인하는 데 목적이 있습니다.
5. AI를 코드 생성기가 아니라 설계 파트너로
자동화 도구를 구현하는 과정에서도 AI를 적극 활용했습니다. 로직 설계부터 코드 작성, 예외 상황 검토, 결과 검증 기준 정리까지 AI와 함께 진행하며 완성도를 높여 나갔습니다.
단순히 코드를 생성하는 데 AI를 사용한 것이 아니라, 어떤 항목을 자동화 대상으로 삼을지, 어떤 기준으로 결과를 판단할지 등 설계 단계부터 함께 고민했습니다.
저는 지금도 AI를 활용해 업무 자동화를 진행하고 있습니다. 반복적으로 확인해야 하는 검증 항목을 정리하고, 어떤 데이터를 비교해야 하는지, 어떤 기준으로 정상과 비정상을 판단해야 하는지, 예외 상황은 무엇이 있을 수 있는지를 AI와 함께 구체화하고 있습니다. 이를 바탕으로 자동화 코드와 검증 로직을 구현하고, 실행 결과가 실제 검증 목적에 부합하는지 다시 확인하며 보완하는 과정을 반복하고 있습니다.
같은 팀에서는 이슈 대응 이력을 찾는 시간을 줄이기 위해 QA AI ChatBot도 함께 운영하고 있습니다.
AI를 활용하며 가장 크게 느낀 점은, AI가 단순히 코드를 작성해주는 도구를 넘어 검증 관점을 정리하고 자동화 방향을 함께 설계하는 파트너가 될 수 있다는 점이었습니다.
6. 마치며
결국 제가 생각하는 QAI는 AI가 QA를 대신하는 것이 아닙니다. AI와 자동화를 통해 반복적인 검증은 더 일관되게 수행하고, 사람은 검증 방향을 설계하고 결과를 검토하며 최종 품질을 책임지는 것, 그것이 QAI의 핵심이라고 생각합니다.
자동화의 목적은 단순히 업무 속도를 높이는 것이 아닙니다. 반복 검증에 소요되는 시간과 리소스를 줄이고 휴먼 에러를 최소화함으로써, 확보한 리소스를 우선순위가 높은 검증 업무와 품질 개선 활동에 재투입하기 위한 것입니다. 이를 통해 추가 검증, 결과 분석, 개선 사항 도출처럼 제품 품질을 높이는 활동에 더 집중하고자 합니다.
앞으로도 저는 AI와 자동화를 통해 검증 방식 자체를 개선하고, 더 나은 품질을 만들어가는 QA로 성장하고자 합니다.
데이터베이스 성능관리 MaxGauge를 살펴보세요.
👉🏻 MaxGauge 자세히 살펴보기
함께 보면 좋은 아티클
