16화. 환각을 거르는 사람 — AI 결과의 환각·오탐을 걸러내는 인간 검증 체계 설계. 직무 특성상 가장 큰 강점이 되는 지점.

Part 0. 오리엔테이션
0화. 30분 데모와 프로덕션 사이의 거리 — 현실 인식과 방향 제시

Part 1. 기초 체력
AI가 짠 코드를 읽고 검증할 수 있는 눈과 웹·API 원리 다지기
1화. AI가 짠 코드를 읽는 눈 — Python 또는 JS/TS 중 하나를 코드 리뷰 가능한 수준까지. 실습: AI가 생성한 테스트 코드의 버그 3개 찾기.
2화. 변경은 diff에서 시작된다 — Git과 PR 기반 협업, 변경 기반 테스트의 첫 단추. 실습: PR diff만 보고 영향 범위 추정해 보기.
3화. 웹은 어떻게 움직이는가 — HTTP, 쿠키·세션의 원리. 실습: 개발자도구로 요청·응답 해부.
4화. 인증의 지도 — OAuth·JWT·RBAC를 테스터 시선으로. 실습: 토큰 만료·권한 우회 시나리오 설계.
5화. API의 두 얼굴 — REST와 GraphQL의 차이와 테스트 관점. 실습: 같은 기능을 두 방식으로 호출·검증.

Part 2. 테스트 자동화
Playwright를 주력으로 깊이 익히기
6화. 왜 Playwright인가 — 도구 선택의 근거와 첫 테스트 작성.
7화. 플래키의 근원, 셀렉터와 대기 — 안정적 셀렉터와 비동기 대기 전략.
8화. 실패를 영상으로 읽는다 — Trace Viewer로 원인 추적.
9화. 계약을 테스트하라 — API·계약 테스트(OpenAPI/GraphQL schema 기반).
10화. 눈에 보이는 회귀, 모두에게 열린 화면 — 시각적 회귀와 접근성 자동 검사. (Selenium·Appium은 레거시·모바일 대응용으로 짧게 짚기)

Part 3. AI 활용·MCP (연재 핵심)
AI를 단순 도구가 아닌 차별화 무기로 만드는 구간
11화. 프롬프트로 테스트를 설계하기 — 명세·PR을 입력해 케이스를 생성·우선순위화하는 패턴 정립.
12화. 에이전트는 무엇을 대신하는가 — 에이전트형 테스트의 개념과 한계(수동 노력 최대 45% 절감 추정).
13화. 스스로 고치는 테스트, 그리고 그 한계 — 자가 치유와 AI Healer. 셀렉터·DOM 변경에서 75%+ 복구, 그러나 복잡한 로직 버그는 사람 몫.
14화. npx playwright init-agents — 첫 MCP 실습 — 접근성 트리 기반 Playwright MCP 시작하기.
15화. MCP로 통합을 검증하다 — MCP 기반 통합 검증 실습.
16화. 환각을 거르는 사람 — AI 결과의 환각·오탐을 걸러내는 인간 검증 체계 설계. 직무 특성상 가장 큰 강점이 되는 지점.

Part 4. 파이프라인·운영
개인기를 조직의 신뢰 시스템으로 연결
17화. 문 앞의 품질 게이트 — CI/CD 품질 게이트 구성.
18화. 플래키를 격리하라 — 불안정 테스트 격리와 실패 원인 자동 분류.
19화. 관측성을 테스트로 환원하기 — 로그·메트릭·트레이스(OpenTelemetry)를 테스트 사고로 끌어오기.
20화. 진짜 같은 가짜 데이터 — 테스트 데이터 합성과 마스킹.

Part 5. 비기능 영역
눈에 보이지 않는 품질 지키기
21화. 무게를 견디는가 — k6/JMeter로 부하·스트레스 테스트.
22화. 손안의 성능 — 모바일 성능 지표(FPS·시작속도·메모리·배터리).
23화. 공격자처럼 생각하기 — OWASP Top 10으로 본 보안 기본기.
24화. 코드를 스캔하는 도구들 — SAST·DAST·SCA(SonarQube·OWASP ZAP·Snyk) 실전.

Part 6. 전략·리더십·표준
아키텍트로서의 설계·운영·리더십
25화. 테스트 가능성을 설계에 심다 — Testability를 기획·개발 단계로 끌어올리기.
26화. 공통 언어로서의 BDD — Gherkin으로 기획·개발·QA를 한 문장에 모으기.
27화. AI를 지휘하는 운영 모델 — 20명 규모 팀을 위한 AI 오케스트레이션 가이드라인과 코칭.
28화. 표준과 AI를 잇다 — KOLAS 인정 요건·품질 표준을 AI 검증 체계로 연결하는 도메인 전문성.
29화. 데모를 프로덕션으로 옮기는 비용 — 30분 데모와 실전의 거리, 사람의 감독이 끝까지 필요한 이유를 균형 있게 정리.
30화. 테스터에서 품질 아키텍트로 

 

---

 

AI가 만든 ‘그럴듯한 거짓’을 인간이 걸러내는 검증 시스템, 테스터의 진짜 무기

 

이 글을 읽으면 AI가 내놓은 테스트 결과 속에서 환각과 오탐을 효과적으로 걸러내는 실전적인 인간 검증 체계를 바로 설계할 수 있습니다.

 

특히 QA 업무에서 가장 큰 차별점이 되는 지점입니다.

 

테스터로 일하다 보면 AI 도구가 갑자기 수많은 테스트 케이스와 결과를 뱉어내는 시대가 됐다.

 

문제는 그중 상당수가 ‘그럴듯하지만 틀린’ 내용이라는 점이다.

 

마치 아이가 상상력을 발휘해 만든 이야기를 어른이 사실 확인하듯, 우리는 AI의 환각(hallucination)과 오탐(false positive)을 가려내야 한다.

 

이 능력이 바로 테스터가 품질 아키텍트로 성장하는 핵심 강점이다.

 

AI가 왜 자꾸 착각하는가, 현실 속 비유로 이해하기

 

상상해 보자. 친구에게 길을 물었는데, 그 친구가 자신감 있게 “저쪽으로 가면 바로 도착해!”라고 말한다.

 

그런데 실제로 가보니 막다른 골목이다.

 

AI도 비슷하다.

 

학습한 방대한 데이터로 그럴듯한 답을 만들지만, 실제 코드나 시스템 맥락을 완벽히 이해하지 못해 잘못된 길을 안내하기 쉽다.

 

특히 Playwright 스크립트나 API 테스트 케이스를 생성할 때 셀렉터가 실제 DOM과 맞지 않거나, 예상치 못한 에지 케이스를 빠뜨리는 경우가 흔하다.

 

이런 착시를 그냥 믿고 넘기면 나중에 큰 비용이 발생한다.

 

반대로, 인간 테스터는 오랜 경험으로 쌓은 ‘현장 감’을 바탕으로 이상 징후를 빠르게 포착한다.

 

이 감을 체계화하는 것이 바로 환각 걸러내기 시스템의 시작이다.

 

 

인간 검증 체계의 기본 뼈대 설계하기

먼저, AI 결과를 ‘1차 초안’으로 명확히 규정하는 문화가 필요하다.

 

마치 출판사에서 원고를 받은 편집자가 1차 교정을 보듯, AI 출력물은 반드시 인간의 2차 검토를 거친다는 원칙을 팀에 정착시킨다.

 

실제 검증 과정에서는 도메인 지식을 가장 앞세운다.

 

예를 들어 은행 앱을 테스트할 때 AI가 “로그인 후 잔액 조회가 성공한다”고 내놓았다면, 실제로는 ‘동시 접속 시 잔액 불일치’나 ‘네트워크 지연 상황’ 같은 현실 조건을 떠올려 추가 시나리오를 만들어 본다.

 

이처럼 AI가 놓치기 쉬운 비즈니스 맥락을 인간이 보완하는 것이다.

 

구체적인 검증 루틴으로는 ‘반대 증거 찾기’ 기법이 효과적이다.

 

AI가 주장하는 대로 테스트가 통과했다면, 의도적으로 조건을 바꿔 실패하게 만들어보는 식이다.

 

마치 탐정이 용의자의 알리바이를 하나씩 깨보는 과정과 같다.

 

이렇게 하면 오탐이 걸러지고 진짜 버그가 드러난다.

 

또 하나 중요한 점은 AI 결과를 ‘단독 증거’가 아닌 ‘참고 자료’로 활용하는 태도다.

 

Trace Viewer로 영상을 돌려보거나, 개발자 도구로 실제 네트워크 요청을 직접 확인하며 AI가 제안한 셀렉터나 대기 전략의 타당성을 검증한다.

 

이 과정에서 테스터의 눈이 빛을 발한다.

 

 

실전에서 환각을 줄이는 작은 습관들

팀 단위로 운영할 때는 AI 출력물에 ‘신뢰 점수’를 매기는 간단한 템플릿을 활용하면 좋다.

 

“이 결과가 실제 환경에서 몇 번 검증됐는가”, “도메인 전문가 의견은 어떤가”, “비슷한 과거 사례와 일치하는가” 같은 질문을 던지는 것이다.

 

처음에는 번거롭게 느껴지지만, 익숙해지면 AI가 가져오는 생산성을 안전하게 끌어올릴 수 있다.

 

특히 복잡한 통합 테스트나 접근성 검사 영역에서는 AI가 더 많은 환각을 일으키기 쉽다.

 

여기서는 페어 검증(pair verification)을 도입해 한 명은 AI 결과를 만들고, 다른 한 명은 이를 비판적으로 검토하는 역할을 나눈다.

 

서로 다른 관점의 충돌이 오히려 품질을 높이는 촉매가 된다.

 

 

테스터가 품질 아키텍트로 거듭나는 순간

결국 AI는 빠른 초안을 제공하는 훌륭한 조수지만, 최종 판단은 인간의 몫이다.

 

이 판단력을 체계적으로 키우고 프로세스로 만들 때, 테스터는 단순한 테스트 실행자가 아니라 시스템 전체의 품질을 설계하는 아키텍트로 성장한다.

 

현장에서 수많은 AI 결과를 다루다 보면, 처음에는 환각에 속아 넘어가는 실수도 있을 것이다.

 

그러나 그 경험을 통해 점점 더 날카로운 검증 눈을 갖게 된다. 그 눈이 바로 30분 데모를 진짜 프로덕션으로 이어주는 든든한 다리가 된다.