AI 네이티브 QA — test basis 현행화부터 셀프힐링·재배포까지

학습 목표

이 모듈 한 줄 요약: "AI가 만들고 고치고 다시 배포할수록, QA는 그 근거(test basis)와 판정을 쥔다". AI가 기획하고 개발하고 테스트하고, 실패를 스스로 고친 뒤 다시 배포하는 흐름이 현장에 들어오고 있다. 이 흐름에서 개발 쪽 자동화는 코드와 내부 시스템 안에서 끝나는 경우가 많다. QA는 그렇지 않다. 낡은 요구사항명세서·화면설계서, 부서마다 다른 용어(버그·defect·결함), 결제대행사·본인인증·대외기관 같은 외부 시스템까지 함께 다뤄야 한다.

모듈 18a·18b·18c에서 AI로 테스트하는 법, AI 시스템을 테스트하는 법, AI 산출물을 교차 확인하는 법을 배웠다. 모듈 38에서는 그 검증을 기준·게이트·판정 기록으로 운영하는 법을 배웠다. 이 모듈은 한 걸음 더 나간다. AI가 개발 생명주기 전체를 도는 조직에서 QA 플랫폼을 처음부터 끝까지 어떻게 설계하는가 를 다룬다.

먼저 폐루프 SDLC의 단계마다 AI가 맡을 일과 사람이 판정할 일을 가르고, 셀프힐링이 결함을 덮지 못하게 재배포 게이트를 세운다. 다음으로 test basis를 세운다. 문서가 없는 레거시 산출물에서 기획 문서를 복원하고, 낡은 명세서와 화면설계서를 실제 구현에 맞춰 현행화한다. 그 문장을 형태소 단위로 쪼개 모호어·약한 표현·용어 불일치를 걸러 내고 테스트 조건을 뽑는다. 이렇게 점검한 test basis는 설계 에이전트의 입력이 되고, 에이전트는 평가셋으로 측정하며 자율성을 단계적으로 올린다. 실행 범위는 외부 시스템까지 넓히고, 실패가 나면 분석 에이전트가 근거를 인용해 원인 후보를 낸다. 같은 방식을 보안·부하·성능·데이터 품질로 넓히고, 마지막으로 이 체계를 운영할 조직과 인재를 설계한다.

이 모듈의 관점은 하나다. AI가 내놓은 결과는 그 근거보다 정확할 수 없다. 그래서 AI 시대 QA의 일은 테스트를 덜 하는 것이 아니다. 근거(test basis)를 최신으로 유지하고, 판정의 책임을 지는 쪽으로 옮겨 가는 것이다.

출발점은 AI 기반 검증 플랫폼을 운영하는 QA 리더들의 회의 메모다. 메모에 나온 과제(산출물 역분석, test basis 현행화와 형태소 처리, 외부 시스템 포함 자동화, AI 실패 분석, 비기능 확장, 설계 에이전트 고도화, 모드별 아웃풋 차이 분석, 조직·인재)를 레슨 아홉 개로 나누고, 공개 문서·논문·도구 문서로 확인해 보강했다.

완료 후 할 수 있는 것

• 기획→개발→테스트→셀프힐링→재배포 폐루프의 단계마다 AI의 일과 사람의 판정을 가르고, 재배포 게이트·롤백 조건·감사 기록을 설계할 수 있다
• 셀프힐링이 결함을 테스트 수정으로 덮는 경로를 알아보고, 힐링 예산과 결함 구분 규칙으로 막을 수 있다
• 코드·DB·화면·로그에서 AI가 복원한 기획 문서의 주장마다 근거와 신뢰도를 붙이고, 현재 동작과 의도된 요구를 구분해 도메인 담당자 확인을 받을 수 있다
• 요구사항명세서·화면설계서와 구현의 드리프트를 유형별로 찾아 차이표로 만들고, 문서를 고칠지 구현을 고칠지 판정하는 승인 절차와 추적성 매트릭스를 유지할 수 있다
• 한국어 형태소 분석기로 요구사항 스멜(약한 표현·열린 나열·모호한 수량)을 걸러 내고, 기획·개발·QA 용어 사전을 정렬하고, 동사와 조건절에서 테스트 조건을 뽑을 수 있다
• 설계 기법을 에이전트 지시와 입력·출력 계약으로 옮기고, 평가셋으로 커버리지·중복·오라클 품질을 재서 자율성 단계를 정할 수 있다
• 외부 의존성 지도를 그려 실연동·샌드박스·서비스 가상화·계약 테스트를 나눠 쓰고, AI가 만든 스텁의 함정을 점검할 수 있다
• 실패 분석 에이전트의 입력 묶음과 근거 인용 출력 계약을 설계하고, 오분석 비용에 따라 사람 확인 경계를 정할 수 있다
• 보안·부하·성능·데이터 품질 영역에 AI 보조를 넓히되, 영역마다 AI가 틀리기 쉬운 지점과 사람이 쥘 판정을 구분할 수 있다
• AI를 쓰는 이유를 업무 언어로 설명하고, 같은 업무를 모델·모드별로 돌려 아웃풋 차이를 평가하고, QA 조직의 역할과 채용·육성 계획을 세울 수 있다

채용시장에서의 위치

2025년 말부터 AI 기반 개발을 깊게 들인 기업에서 "AI 검증 플랫폼", "QA 에이전트", "AI 기반 실패 분석", "요구사항 품질 자동 점검"이 들어간 QA 공고가 눈에 띄게 늘었다. 이런 공고는 대개 두 가지를 함께 요구한다. AI·에이전트로 검증을 자동화해 본 경험 과, 요구사항·외부 연동·도메인 규칙처럼 코드 밖에 있는 품질 근거를 다뤄 본 경험 이다.

QA 경력자에게 유리한 쪽은 두 번째다. 낡은 명세서에서 진짜 요구를 가려내는 감각, 결제·인증·대외기관 연동에서 어디가 깨지는지 아는 경험, 용어가 다른 세 부서 사이에서 같은 대상을 가리키게 만드는 능력은 AI 도구를 잘 다루는 개발자에게 드물다. 공백이 되기 쉬운 쪽은 첫 번째다. 특히 에이전트를 평가셋과 지표로 측정 하는 방법과, 셀프힐링·재배포를 게이트와 기록 으로 통제하는 방법이 자주 빈다.

면접에서 힘을 갖는 이야기는 "AI로 테스트 케이스를 만들었다"가 아니다. "AI가 틀린 근거를 무엇으로 찾아냈고, 그 다음 무엇을 바꿨는가" 다. 복원 문서에서 "현재 동작"을 요구로 오인한 항목을 담당자 확인으로 걸러 낸 이야기, 형태소 점검으로 약한 표현을 줄여 설계 에이전트의 중복 케이스가 줄어든 이야기, 분석 에이전트의 오분석률을 재서 사람 확인 경계를 옮긴 이야기가 이 모듈의 성숙도를 보여 준다.