AI 자동화 · QA

AI 활용 이관 QA 체계 설계 ⬜

Overview

구글 시트와 슬라이드에 사람이 이슈를 하나씩 올리던 QA를, AI 에이전트가 Figma와 현행 사이트를 분석해 테스트 시나리오를 쓰고 새 사이트와 비교해 먼저 판정하는 노션 기반 방식으로 바꿔 플랫폼 이관 QA를 진행하고 있습니다. 약 4주 걸리던 시나리오 작성을 3일로 줄였고, 같은 인원이 하루에 찾는 이슈는 이관 1차 QA의 약 3배가 됐습니다.

Company

오픈패스 · 재직

Role

PM · QA 방식 설계와 기능 검수

Scope

노션 DB 구조 · 사람 확인 규칙 · 어드민 점검표 · AI 에이전트 작업 지시 · 기능 검수 · 개발사 이슈 전달

Team

PM 1(본인) · 기능 검수 1 · 디자인 검수 2 · 외부 개발사

Period

2026-09 ~ 진행 중

문제

구글 시트에 테스트 케이스를 쓰고, 이슈는 사람이 캡처해 구글 슬라이드에 1장씩 올리는 방식, 건당 약 5분
이슈가 슬라이드에 흩어져 수정이 끝난 이슈와 남은 이슈를 확인하고 관리하기 어려움
이관 1차 QA는 4명이 3주 동안 디자인만 보고 이슈 490건, 기능까지 보려면 시나리오 작성에만 몇 주

가설

접근이 쉽고 AI가 직접 읽고 쓸 수 있는 노션에 이슈를 모으면, 새 도구를 배우지 않고도 처리 상태로 관리할 수 있다
AI 에이전트가 Figma와 현행 사이트를 분석해 시나리오를 쓰면, 몇 주 걸리던 작성을 며칠로 줄일 수 있다
AI 에이전트가 새 사이트에서 시나리오를 실행해 원본과 비교하고 이슈를 올리면, 사람은 확인만 해 같은 인원으로 더 빨리 검수할 수 있다

솔루션

지라 같은 이슈 관리 도구 대신 노션 DB 6개로 화면, 케이스, 디자인 체크, 이슈를 연결하고 처리 상태로 집계
AI 에이전트가 Figma 전달본과 현행 사이트, 소스를 분석해 기능 케이스와 디자인 체크를 쓰고 PM이 검수
AI 에이전트가 새 사이트에서 먼저 실행해 다르면 근거와 캡처를 붙여 이슈 후보로 등록, 검수자는 화면을 보고 확인해 확정

검증

이슈 836건을 처리 상태별로 바로 집계, 개발사도 같은 대장에서 상태 변경
시나리오 작성 약 4주 → 3일, 화면 59개 전체에 기능 케이스 646건
같은 인원의 하루 발견 이슈 약 21건 → 64건(약 3배), 그중 92%를 AI 에이전트가 등록

Background

배경

1. 서비스 맥락 및 프로젝트 배경

오픈패스는 자체 플랫폼 openpath.kr을 외부 LMS로 이관하고 있고, 새 사이트는 개발사 솔루션에 기존 기능을 옮겨 담은 구조라 오픈 전에 사용자 화면 전체와 어드민 주요 기능을 다시 검수해야 했습니다. 이관의 계약과 일정은 교육 플랫폼 LMS 이관에서 다루고, 이 페이지는 검수 방식을 바꾼 일만 다룹니다.

2. 기존 QA 방식 (As-Is)

이전 QA는 구글 시트에 테스트 케이스를 적고, 이슈를 찾으면 화면을 캡처해 구글 슬라이드 한 장에 사람이 하나씩 올리는 방식이었습니다.

프로젝트	인원과 기간	방식과 결과
2023 플랫폼 런칭 QA	6~7명, 약 6주	메뉴별 슬라이드 단일 테스트, 오픈 약 4주 전 데스크톱 이슈 420건
2026 이관 1차 퍼블리싱 QA	4명, 23일	체크리스트는 AI가 Figma에서 만들고 실행, 캡처, 이슈 작성은 사람이 맡아 디자인만 검수, 슬라이드 490건 (학습자 포털)

Problem

문제

사람이 하나씩 올리는 이슈, 건당 약 5분

이슈 하나를 올리려면 화면을 보고 창 비율을 바꿔 확인한 뒤 Figma와 대조하고, 캡처해 슬라이드에 올리고, 동영상이 필요하면 드라이브 링크를 붙여야 했습니다. 적게 잡아도 건당 약 5분이 걸려, 검수자의 시간 대부분이 이슈를 보는 일보다 캡처하고 기록하는 일에 쓰였습니다.

수정 여부를 확인하기 어려운 이슈 대장

이슈 1건이 슬라이드 1장이라 이관 1차 QA의 490건은 파일 하나에 105MB로 쌓였고, 검색이나 상태별 집계가 되지 않았습니다. 처리 상태는 슬라이드 위 표에 글로 주고받아 수정이 끝난 이슈와 남은 이슈를 세려면 장마다 열어 봐야 했고, 시트의 버그 목록과 슬라이드 번호를 따로 맞춰 적어야 했습니다.

디자인만 보는 데도 3주 걸린 검수

이관 1차 QA는 4명이 23일 동안 퍼블리싱 디자인만 보고 이슈 490건을 올렸고, 기능 케이스는 작성만 해 둔 채 실행하지 못했습니다. 2023년 런칭 때는 여러 명이 통합 테스트 시나리오를 쓰는 데만 약 4주가 걸렸습니다. 이번에는 같은 인원으로 기능까지 검수해야 해서, 옛 방식이면 시나리오 작성에만 몇 주가 들 상황이었습니다.

Hypothesis

가설과 목표

가설 1 · 접근이 쉽고 AI가 직접 읽고 쓸 수 있는 노션에 이슈를 모으면, 새 도구를 배우지 않고도 이슈를 처리 상태로 세고 개발사와 같은 대장으로 주고받을 수 있다

검증 지표 처리 상태별 이슈 집계, 개발사의 노션 상태 변경
목표 슬라이드에 글로 적던 상태 → 처리 상태로 실시간 집계

가설 2 · AI 에이전트가 Figma와 현행 사이트를 분석해 테스트 시나리오를 쓰면, 몇 주 걸리던 작성을 며칠로 줄이고 화면 전체의 기능까지 덮을 수 있다

검증 지표 시나리오 작성 기간, 기능 케이스 수와 화면 범위
목표 작성 약 4주 → 1주 이내, 이관 1차 기능 케이스 실행 0건 → 화면 59개 전체 작성과 실행

가설 3 · AI 에이전트가 새 사이트에서 시나리오를 실행해 원본과 비교하고 근거와 함께 이슈를 올리면, 사람은 확인만 해 같은 인원으로 더 빨리 검수할 수 있다

검증 지표 하루에 찾는 이슈 수, AI가 등록한 이슈 비율, 사람이 다시 본 AI 판정 일치율, 검수자 확인 건당 시간
목표 이관 1차 하루 약 21건보다 빠르게, 이슈 등록은 AI 에이전트가 맡고 검수자 확인 건당 약 4분 → 1분 이내

Solution

솔루션 작동 방식

케이스와 디자인 체크, 이슈를 모두 노션 DB에 두고, AI 에이전트가 쓰고 먼저 판정하면 사람이 확인해 확정합니다.

화면 목록: 사용자 화면 59개와 현행 주소 102개를 연결하고, 화면마다 검수 순서를 붙여 진행률을 셉니다.
시나리오 작성: AI 에이전트가 Figma 전달본, 현행 사이트, 현행 소스를 분석해 기대 결과와 정답 근거를 적은 기능 케이스와, 요소마다 Figma 값을 적은 디자인 체크를 쓰고, PM이 기대 결과와 근거를 검수합니다.
1차 판정: AI 에이전트가 브라우저로 새 사이트에서 케이스를 실행해 결과와 근거를 남기고, 기대와 다르면 캡처를 붙여 이슈 후보로 등록합니다. 비밀번호 입력과 본인인증, 결제나 신청처럼 운영 서버에 기록이 남는 버튼은 사람이 직접 합니다.
사람 확인: 검수자가 화면을 보며 맞다, 다르다로 답하면 AI 에이전트가 결과를 확정하고 체크하며, 이슈 후보는 검수자가 확인해 이슈 발견으로 올리거나 제외합니다.
개발사 전달: 개발사는 사람이 확인한 이슈만 보고 노션에서 확인과 수정 완료 상태로 바꾸며, 검수자가 다시 확인해 해결로 닫습니다.

노션 DB 6개 구조와 작성부터 재확인까지 5단계 검수 흐름. AI 에이전트, 검수자, 개발사가 맡는 칸을 색으로 구분

QA 이슈 상태별 보드. 이슈 후보, 이슈 발견, 메디 확인(개발사 확인 중), 수정 완료, 해결 순서로 카드가 이동

사용 도구

용도	도구
케이스, 이슈, 진행률	노션 DB 6개
시나리오 작성과 1차 판정	AI 에이전트가 브라우저를 조작하고 Figma 값과 현행 소스를 읽음
디자인 정답	Figma 전달본과 스타일 가이드
기능 정답	현행 사이트 동작과 소스, 새로 만든 화면은 Figma와 설계 문서
모바일 확인	PM이 휴대폰 화면을 녹화하면 AI 에이전트가 장면별로 판독

How

실행 과정

1. 준비 체크리스트와 정답 기준

이관 1차 QA에서 겪은 문제를 준비 체크리스트로 정리하고, 기능의 정답은 현행 사이트 동작, 새로 만든 화면은 Figma와 설계 문서로 정했습니다. 어드민은 새 솔루션에 기존 기능을 끼워 넣은 구조라 케이스 전수 대신 메뉴마다 한 줄씩 점검하는 표로 봤습니다.

2. AI 에이전트로 테스트 시나리오 작성

화면을 공통과 탐색, 커뮤니티, 계정, 결제, 내 클래스, 신청 상품, 새 사이트 전용의 일곱 묶음으로 나누고, 막히지 않는 묶음부터 하나씩 AI 에이전트에게 맡겼습니다. 사흘 동안 기능 케이스 642건과 디자인 체크 375행을 썼고, 기대 결과가 틀리면 잘못된 Fail이 나오므로 기존 기능 케이스마다 현행 사이트에서 기대 결과를 확인한 날짜와 소스 위치를 남기게 하고 PM이 기대 결과와 근거를 검수했습니다.

3. AI 1차 판정과 사람 확인

디자인 검수자의 제안으로 AI 에이전트가 케이스를 먼저 판정하는 단계를 넣었고, 사람이 Pass까지 확인해 확정하는 규칙을 정했습니다. AI가 올린 이슈를 이슈 후보 상태로 두는 방식은 회의에서 디자인 검수자와 함께 정했습니다. 야간에 사람 없이 2시간 19분 동안 299건을 실행해 Pass 53건, Fail 53건을 판정하고 이슈 42건을 올렸으며, 나머지는 테스트 데이터나 계정이 없어 Block으로 남겼습니다.

화면 페이지의 기능 케이스 표(이용약관 화면). 1차 QA 칸에 AI 에이전트의 실행 기록, 사람 확인 칸에 검수자 체크, 이슈 칸에 연결된 이슈

4. 디자인 요소 단위 대조

디자인 체크는 디자인 검수자가 제안한 방식대로 화면마다 요소를 나눠 Figma 값과 새 사이트 값을 표로 대조했습니다. 여러 화면에 반복되는 카드와 버튼도 디자인 검수자 요청에 따라 공통 컴포넌트로 한 번만 검사해 같은 이슈가 화면마다 쌓이지 않게 했습니다.

디자인 이슈 예시(404 오류 페이지 본문). 새 사이트 캡처 아래에 Figma 값과 새 사이트 값을 속성별로 비교한 표

5. 동행 방식으로 검수자 확인 시간 단축

검수자가 노션에서 케이스를 열어 기대 결과를 읽고 결과 칸을 고치는 방식에서는 확인이 첫 이틀에 34건에 그쳐, AI 실행 속도를 따라가지 못했습니다. 검수자는 노션을 거의 열지 않고 화면만 보며 맞다, 다르다로 답하고 체크와 결과 수정, 이슈 작성은 AI 에이전트가 맡는 동행 방식으로 바꿔, 케이스 9건이 담긴 표 한 장을 한마디로 확정할 수 있게 했습니다.

6. 기능 선행 점검

Figma와 현행 어디에도 없이 새 사이트에만 있는 요소가 나올 때마다 디자인 검수가 멈췄습니다. 48분 동안 화면 18개를 Figma, 현행 소스, 새 사이트 세 곳과 대조해 새 사이트에만 있는 요소 20건, 빠진 요소 16건, 동작이 바뀐 곳 21건을 기능 이슈로 정리했습니다.

Decisions

주요 결정

1. 지라 대신 노션 DB로 이슈 관리

슬라이드 방식은 검색과 집계가 안 돼 이슈 관리 도구가 필요했지만, 개발 조직에서 많이 쓰는 지라 같은 전용 이슈 관리 도구는 팀과 개발사가 새로 익히는 데 시간이 들어 이관 일정 안에 자리 잡기 어렵다고 봤습니다. 별도 교육 없이 쓸 수 있고 AI 에이전트가 직접 읽고 쓸 수 있는 노션 DB로 케이스, 디자인 체크, 이슈를 옮겨 처리 상태로 세기로 하고, 개발사가 노션을 꺼리면 시트 목록과 드라이브 캡처로 바꾸는 대안을 두고 시작했습니다.

2. AI 1차 판정의 사람 확정 규칙

AI 에이전트는 Mac 크롬 한 대에서 실행하는데 결과 기준은 국내 사용자가 많은 Windows 크롬과 휴대폰이라, AI의 Pass를 그대로 믿을지 사람이 다시 볼지 정해야 했습니다. 사람이 Pass까지 확인해 체크해야 결과가 확정되게 했고, 이 확인이 병목이 되자 우선순위가 낮은 Pass는 AI 에이전트가 남긴 근거를 읽고 체크하도록 범위를 줄였습니다.

3. 디자인 이슈 전 기능 선행 점검

새 사이트에만 있는 요소를 바로 디자인 이슈로 올리면, 기능상 필요 없는 요소까지 디자인을 맞추는 불필요한 이슈가 생길 수 있었습니다. 디자인 검수 일부가 멈추더라도 해당 요소의 존재 이유와 어드민 제어 여부를 기능 이슈로 먼저 묻기로 하고, 답이 오기 전까지 해당 디자인 98행은 기능 답 대기로 표시했습니다.

Result

검증과 이후 변화

정량적 변화

1차 전수 확인이 진행 중이라 10월 24일 기준 수치이며, 1차 확인을 마친 뒤 갱신합니다.

시나리오 작성

4주 → 3일

2023 런칭 때 여러 명이 약 4주에 걸쳐 쓴 테스트 시나리오를, AI 에이전트가 사흘 동안 화면 59개 전체로 작성

하루 발견 이슈

약 3배

이관 1차 4명이 디자인만 보고 하루 약 21건 → 같은 인원이 기능까지 보며 약 64건

AI 에이전트 이슈 등록

92%

이슈 836건 중 767건을 근거와 캡처를 붙여 등록, 검수자는 확인만

가설 검증

가설 1 · 노션 이슈 대장: 10월 24일 기준 이슈 836건을 처리 상태 8가지로 노션이 바로 집계하고, 개발사가 같은 대장에서 확인과 수정 완료로 상태를 바꾸기 시작함. 도입 초기에는 개발사가 노션을 쓰지 않아 슬랙으로 두 번 요청해 맞춤
가설 2 · 시나리오 작성: AI 에이전트가 사흘 만에 화면 59개 전체의 시나리오를 썼고(2023 런칭 때 통합 테스트 시나리오는 8월 9일부터 9월 6일까지 약 4주), 이관 1차 때 실행 0건이던 기능 케이스는 646건 중 468건(72%)을 AI 에이전트가 먼저 실행. 기능 선행 점검에서 새 사이트에만 있거나 빠진 요소, 바뀐 동작 57건을 디자인 이슈 전에 찾음
가설 3 · 검수 속도: 검수를 시작한 10월 12일부터 13일 동안 이슈 836건을 찾아 하루 약 64건으로, 4명이 23일 동안 디자인만 보고 490건을 찾은 이관 1차(하루 약 21건)의 약 3배. 그중 767건(92%)을 AI 에이전트가 근거와 캡처를 붙여 등록했고, 사람이 다시 본 범위에서 AI 판정은 약 93~95% 일치(112~127건 기준). 동행 방식 뒤 검수자는 표 한 장 9건을 한마디로 확정해 건당 확인 시간이 약 4분에서 1분 이내로 줄어듦 (일지 기준 추정)

QA 이슈 현황판(10월 24일 화면). 처리 상태별 이슈 건수를 노션이 자동으로 집계

구축 전후

항목	이전 (시트와 슬라이드)	이후 (노션과 AI 에이전트)
이슈 대장	이슈 1건이 슬라이드 1장, 상태는 글로 기록	노션 DB, 처리 상태 8가지로 집계
개발사와 주고받기	슬라이드 표에 글로 기록	개발사가 노션에서 상태 변경, 일부 회신은 슬랙
시나리오 작성	여러 명이 약 4주 (2023 런칭)	AI 에이전트가 3일, PM이 검수
기능 검수	이관 1차는 디자인만, 기능 케이스 실행 0건	화면 59개 전체 기능 케이스 작성과 AI 실행
이슈 등록	사람이 캡처해 슬라이드 업로드, 건당 약 5분	AI 에이전트가 근거와 캡처를 붙여 이슈 후보로 등록
판정	사람이 직접	AI 에이전트가 먼저 판정, 사람이 Pass까지 확인해 확정
검수자 확인	노션을 열어 칸을 고침, 건당 약 4분 (추정)	화면을 보고 한마디로 답함, 표 한 장 9건을 한 번에 확정

Retrospective

배운 점

확인 방식을 함께 바꾸지 않으면 쌓이기만 하는 AI 실행 결과

AI 에이전트는 묶음 실행에서 케이스 하나를 30초 안쪽에 처리했지만, 사람이 노션을 열어 칸을 고치는 방식에서는 확인이 첫 이틀에 34건에 그쳤습니다. 사람 확인 방식을 그대로 두면 AI 실행이 빨라도 확인 대기 행만 쌓였고, 실행과 함께 확인 방식도 바꿔야 했습니다.

AI 결과를 따로 남기지 않으면 잴 수 없는 정확도

기능 케이스는 AI 판정과 사람 확정을 다른 칸에 남겨 일치율을 셀 수 있었지만, 디자인 체크는 사람이 AI 판정 칸을 그대로 덮어써 얼마나 뒤집혔는지 셀 수 없었습니다. AI에게 일을 맡길 때는 처음부터 AI 결과와 사람 확정을 따로 기록해야, 정확도를 근거로 맡길 범위를 넓힐 수 있습니다.

다른 프로젝트

AI 활용 · 게임 제작

컨퍼런스 홍보 게임 제작

AI 자동화 · 고객 문의 운영

고객 문의 통합과 AI 답변 초안 도구 개발

AI 자동화 · 뉴스레터

뉴스레터 AI 자동화 도구 개발

안재찬 · asa0677@naver.com