개념
도입은 끝났고, 이제 설명과 확산의 문제다
Capgemini·OpenText 등이 2025년 11월 발표한 World Quality Report 2025에 따르면 조사 대상 조직의 약 90%가 품질 엔지니어링에 생성형 AI를 도입하고 있지만, 전사 규모로 정착한 곳은 15% 정도였다. 평균 생산성 향상은 19%였으나 응답자의 3분의 1은 효과가 거의 없었다고 답했고, AI·ML 역량 부족을 꼽은 비율(50%)은 전년과 달라지지 않았다. 설문 기반 보고서라 숫자를 그대로 일반화할 수는 없지만, 방향은 분명하다. 도구를 써 보는 단계는 지났고, 왜 쓰는지 설명하고 조직에 뿌리내리게 하는 단계에서 막혀 있다.
이 모듈의 앞 레슨들은 기술을 다뤘다. 이 레슨은 그 기술을 굴릴 사람과 조직을 다룬다. 세 가지 능력이 중심이다.
| 능력 | 질문 | 이 능력이 없을 때 |
|---|---|---|
| 설명하는 힘 | 왜 이 업무에 AI를 쓰는가, 무엇이 좋아졌는가 | 예산 심사에서 "신기술이니까"밖에 말하지 못한다 |
| 비교하는 힘 | 어떤 모델·모드가 이 업무에 맞는가 | 가장 비싼 설정이나 가장 익숙한 설정을 습관적으로 쓴다 |
| 판정하는 힘 | AI 결과가 맞았는가 | AI 출력이 그대로 산출물이 된다 |
세 번째가 도메인 전문성이다. 앞의 두 능력도 결국 세 번째 위에 선다.
AI를 쓰는 이유를 업무 언어로 설명하기
AI 도입 설명은 흔히 도구 언어로 쓰인다. "에이전트가 MCP로 브라우저를 제어해 케이스를 자동 생성한다." 기술적으로 맞지만, 예산을 정하는 사람에게는 아무 정보가 없다. 같은 내용을 업무 언어 로 바꾸면 이렇다.
| 도구 언어 | 업무 언어 |
|---|---|
| LLM으로 테스트 케이스 자동 생성 | 요구사항 변경 후 회귀 케이스 갱신 시간을 3일에서 1일로 줄인다 |
| AI 실패 분석 에이전트 도입 | 야간 회귀 실패의 원인 파악 시간을 건당 10분에서 3분으로 줄여, 오전 중 결함 등록을 끝낸다 |
| 형태소 분석으로 요구사항 점검 | 개발 착수 전에 모호한 요구를 찾아, 개발 후반 요구 해석 차이로 인한 재작업을 줄인다 |
| 셀프힐링 적용 | UI 변경에 따른 스크립트 유지보수 공수를 줄이되, 결함 은폐를 막는 승인 절차를 둔다 |
업무 언어의 조건은 세 가지다. 어떤 업무 문제인가, 무엇으로 재는가, 지금 기준선은 얼마인가. 여기에 AI 도입 설명에만 필요한 칸이 두 개 더 붙는다. 사람이 맡는 부분과 멈추는 기준이다.
[AI 활용 한 장 설명]
업무 문제: 야간 회귀 실패 분석이 오전을 다 쓴다 (평균 25건 × 10분)
측정 지표: 건당 원인 파악 시간, 정분석률, 개발자 기각률
기준선: 최근 4주 평균 10.2분/건, 수작업 정분석률 측정 안 됨
AI가 맡는 것: 증거 수집, 원인 후보 3개와 근거 제시
사람이 맡는 것: 원인 확정, 결함 등록, 심각도 판정
위험과 통제: 제품 결함을 테스트 결함으로 오분석 → '테스트 결함' 결론은 전수 사람 확인
중단 기준: 4주 시범 후 정분석률 60% 미만 또는 기각률 30% 초과 시 중단중단 기준이 있는 설명이 오히려 신뢰를 얻는다. 모듈 44 레슨 1에서 다룬 비즈니스 케이스처럼, 효과와 함께 효과가 없을 때 어떻게 알고 어떻게 멈추는지 를 말할 수 있어야 한다.
모드별 아웃풋 차이 분석 — 왜 해야 하는가
같은 업무라도 어떤 모델에, 어떤 방식으로 시키느냐에 따라 결과가 크게 다르다. 비교할 축은 대략 네 가지다.
| 축 | 예 | 결과에 미치는 영향 |
|---|---|---|
| 모델 | 대형 모델 vs 소형·사내 모델 | 정확도, 비용, 데이터 반출 가능 여부 |
| 추론 강도 | 추론(생각) 단계 많음 vs 적음 | 복잡한 조건 조합에서 누락 감소, 대신 시간·비용 증가 |
| 계획 모드 | 바로 실행 vs 계획을 먼저 세우고 승인 후 실행 | 큰 작업에서 방향 이탈 감소, 사람 개입 지점 증가 |
| 상호작용 방식 | 일반 채팅(사람이 맥락 붙여 넣기) vs 에이전트(도구로 직접 파일·시스템 조회) | 에이전트는 맥락을 스스로 모으지만 엉뚱한 파일을 근거로 삼을 수도 있다 |
"가장 좋은 모델을 가장 강한 모드로"가 항상 답은 아니다. 단순 분류 작업에 추론 강도를 최대로 걸면 비용과 시간만 늘고 결과는 같다. 반대로 복잡한 결정 테이블을 소형 모델에 빠른 모드로 맡기면 조건 조합을 빠뜨린다. 업무마다 충분한 최소 설정을 찾는 것 이 모드 비교의 목적이다. 그리고 이 판단을 감이 아니라 데이터로 내리는 것이 QA다운 방식이다.
모드 비교 실험 설계
모드 비교는 작은 평가 실험이다. 모듈 38 레슨 3의 판정자 보정, 이 모듈 레슨 5의 설계 에이전트 평가셋과 같은 원리를 쓴다.
1. 과제 고정 실제 업무에서 뽑은 입력 10~20건 (예: 요구사항 문단 → 테스트 조건 목록)
2. 정답 준비 숙련자가 만든 기준 답안, 또는 판정 루브릭
3. 조건 정의 A: 모델X·추론 낮음·채팅 / B: 모델X·추론 높음·채팅 / C: 모델X·계획 모드·에이전트 / D: 모델Y·...
4. 반복 같은 입력을 조건마다 3회 이상 — LLM 출력은 매번 다르다
5. 측정 정확성, 커버리지(기준 답안 대비 재현율), 중복, 근거 인용, 소요 시간, 비용
6. 판정 사람 또는 보정된 판정자. 판정자는 비교 대상과 다른 모델로
7. 결론 업무별 권장 설정 + 근거 표, 재평가 주기결과는 이런 표가 된다(가상의 예).
| 조건 | 커버리지 | 오류 조건 수 | 중복률 | 회당 시간 | 상대 비용 | 판정 |
|---|---|---|---|---|---|---|
| A 추론 낮음·채팅 | 71% | 2.1 | 18% | 20초 | 1 | 단순 문단에만 |
| B 추론 높음·채팅 | 86% | 0.8 | 12% | 70초 | 3 | 결정 테이블형 요구에 권장 |
| C 계획·에이전트 | 88% | 1.4 | 9% | 4분 | 8 | 근거 파일 오인 2건 — 범위 제한 후 재평가 |
C가 커버리지는 가장 높지만 오류 조건이 B보다 많다. 원인을 보니 에이전트가 저장소에서 이전 버전 명세 를 찾아 근거로 삼았다. 이런 발견이 모드 비교의 진짜 가치다. 숫자 순위가 아니라 각 모드가 어떻게 틀리는지 를 알게 된다.
비교 실험의 함정
| 함정 | 모습 | 대응 |
|---|---|---|
| 한 번 돌려 보고 결론 | 우연히 좋은 출력 하나로 모드를 고른다 | 조건당 3회 이상, 편차도 기록 |
| 길이 편향 | 더 길고 자세한 출력을 더 좋다고 판정 | 기준 답안 대비 재현율·정밀도로 잰다 |
| 자기 선호 | 같은 계열 모델이 자기 출력을 높게 판정 | 판정자를 다른 모델이나 사람으로 |
| 입력 유출 | 공개 예제로 평가해 모델이 이미 본 문제 | 사내 실제 입력, 마스킹 후 사용 |
| 버전 표류 | 모델 업데이트 후에도 옛 결론 유지 | 결론에 모델 버전·날짜 기록, 분기별 재평가 |
경력과 도메인 지식이 여전히 중요한 이유
"AI가 테스트를 설계하면 경력자가 덜 필요해지지 않나"라는 질문을 자주 받는다. 이 모듈 전체가 그 반대를 보여 준다.
- 오라클은 도메인에서 온다. 레슨 2에서 "현재 동작이 의도된 요구와 다를 수 있다"고 했다. 둘을 구분하는 것은 업무를 아는 사람이다.
- AI가 못 보는 결함은 업무 규칙에 있다. 레슨 8의 업무 로직 위협, 데이터 정합성 공식은 AI가 일반론으로 대체할 수 없다.
- AI 출력 검토는 전문가 작업이다. 그럴듯한 케이스 50개에서 빠진 3개를 찾으려면 무엇이 있어야 하는지 알아야 한다. 초보자는 그럴듯함에 속는다.
- 위험 판단은 책임과 함께 간다. 출시 여부, 심각도, 중단 기준은 결과에 책임지는 사람이 정한다.
다만 경력의 내용 은 바뀐다. 케이스를 빨리 많이 쓰는 숙련은 가치가 줄고, 업무 규칙을 정확히 아는 것, 기준을 문장으로 쓰는 것, AI 출력의 빈칸을 찾는 것의 가치가 커진다. 10년 차라도 앞쪽 숙련에만 기대 왔다면 다시 배워야 한다.
QA 조직의 역할 재설계
AI 네이티브 QA 조직에서는 역할이 "케이스 작성자·실행자" 중심에서 다음처럼 재편된다. 한 사람이 여러 역할을 겸할 수 있다.
| 역할 | 하는 일 | 연결 레슨 |
|---|---|---|
| 기준 설계자 | test basis 점검, 검증 기준·루브릭 작성 | 레슨 3·4, 모듈 38 레슨 1 |
| AI 파이프라인 운영자 | 설계·실행·분석 에이전트 운영, 게이트·감사 기록 | 레슨 1·7, 모듈 59 |
| 평가셋 관리자 | 에이전트·판정자 평가셋 유지, 모드 비교 실험 | 레슨 5, 이 레슨 |
| 도메인 품질 전문가 | 업무 규칙·위험 판단, AI 출력 최종 검토 | 레슨 2·8 |
| 외부 연동·비기능 전문가 | 서비스 가상화, 보안·성능·데이터 품질 | 레슨 6·8 |
| 품질 코치 | 개발 조직의 AI 활용 품질 기준 확산 | 모듈 38 레슨 2·7 |
ISTQB도 2025년 7월 CT-GenAI(Testing with Generative AI) 전문가 실라버스를 승인했고, 2026년 4월 1.1판을 냈다. 프롬프트 엔지니어링, 생성형 AI 위험 관리, LLM 기반 테스트 솔루션과 함께 테스트 조직에 생성형 AI를 배치·통합하는 전략과 로드맵 을 한 장으로 다룬다. 자격이 역량을 보장하지는 않지만, 조직 내 공통 용어를 맞추는 출발점으로 쓸 수 있다.
채용과 육성 — 사다리를 걷어차지 않기
채용에서는 도구 경험보다 AI 출력을 판정하는 능력 을 본다. 모듈 44 레슨 11의 채용 설계 원칙을 그대로 쓰되 과제를 바꾼다.
[면접 과제 예 — 40분]
요구사항 1쪽 + AI가 만든 테스트 조건 30개를 준다.
1) 틀린 조건, 중복 조건, 빠진 조건을 찾아라
2) 빠진 것 중 가장 위험한 하나를 고르고 이유를 업무 언어로 설명하라
3) 이 업무에 AI를 계속 쓸지, 어떤 지표로 판단할지 제안하라
평가: 빠진 조건 발견 수(도메인 이해), 이유 설명(업무 언어), 지표 제안(설명하는 힘)육성에서 가장 큰 위험은 주니어의 숙련 경로가 사라지는 것 이다. 예전 주니어는 케이스를 직접 쓰고 실행하며 제품과 결함 감각을 익혔다. AI가 그 일을 가져가면 주니어는 검토자가 되는데, 검토할 감각을 기를 기회가 없다. 그래서 의도적인 장치가 필요하다.
- 입사 초기 일정 기간은 AI 없이 같은 과제를 먼저 해 보고, 그다음 AI 결과와 비교한다
- AI 출력 검토를 선배와 짝으로 하며 "왜 이것이 빠졌는지 알았는가"를 말로 설명하게 한다
- 결함 회고에서 "AI가 놓친 결함"을 따로 모아 도메인 학습 자료로 쓴다
- 모드 비교 실험을 주니어 과제로 준다. 평가셋을 만들며 기준 답안을 쓰는 것 자체가 훈련이다
모듈 42 레슨 8에서 AI QA 채용 공고를 레슨으로 매핑했다면, 이 레슨은 그 반대편, 공고를 쓰고 사람을 키우는 쪽 의 시선이다.
실무에서 왜 필요한가
AI 도입이 확산 단계에서 멈추는 가장 큰 이유는 기술이 아니라 설명과 사람이다. 경영진은 효과를 업무 언어로 듣고 싶어 하고, 실무자는 어떤 설정을 언제 써야 할지 모르며, 주니어는 무엇을 배워야 할지 모른다. QA 리더가 이 세 질문에 답하지 못하면 AI 도입은 개인의 취향으로 남고, 효과는 측정되지 않으며, 다음 예산 심사에서 사라진다.
반대로 업무 언어로 설명하고, 모드 비교로 설정을 고르고, 도메인 전문성을 중심에 둔 역할을 설계한 조직은 AI를 쓸수록 QA의 영향력이 커진다. AI가 많이 만들수록 무엇이 맞는지 판정하는 사람 의 가치가 올라가기 때문이다.
채용시장에서의 위치
2025~2026년 QA 리드·테스트 매니저 공고에는 "AI 도입 전략 수립", "AI 활용 효과 측정", "AI 시대 QA 역량 체계 설계" 같은 문구가 늘었다. 면접에서 강한 답은 도구 목록이 아니라 한 장 설명(문제·지표·기준선·중단 기준)과 모드 비교 실험 결과를 보여 주는 것이다.