13화. 스스로 고치는 테스트, 그리고 그 한계 — 자가 치유와 AI Healer. 셀렉터·DOM 변경에서 75%+ 복구, 그러나 복잡한 로직 버그는 사람 몫.

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 Healer와 자가 치유 테스트는 바로 이 골칫거리를 크게 줄여줍니다.

 

셀렉터나 DOM 변경에서는 75% 이상 자동 복구가 가능하지만, 복잡한 로직 버그는 여전히 사람의 판단이 필요합니다.

 

이 균형을 제대로 아는 것이 AI 시대 품질 아키텍트의 핵심 능력입니다.

 

 

다친 무릎에 반창고를 붙이는 로봇 친구

축구하다 무릎을 살짝 긁혔다고 해 보세요.

 

작은 상처라면 친구가 “반창고 붙여줄게” 하며 금방 도와주지만, 뼈가 부러졌다면 병원에 가서 의사가 제대로 치료해야 합니다.

 

AI Healer도 마찬가지예요.

 

테스트가 깨졌을 때 “아, 이 버튼이 위치만 바뀌었구나”처럼 단순한 상처는 스스로 진단하고 고칩니다.

 

하지만 “로그인 로직 자체가 잘못됐어” 같은 깊은 문제는 AI가 함부로 손대지 못하고, 사람이 개입해야 합니다.

 

 

자가 치유가 가장 잘하는 일, 셀렉터와 DOM 변화

현대 웹은 자주 바뀝니다.

 

개발자가 클래스 이름을 수정하거나, 새로운 컴포넌트를 넣으면 기존 getByRole이나 getByTestId조차 깨지기 쉽죠.

 

여기서 AI Healer(Playwright MCP, Testim, Mabl, 또는 Claude·Cursor 기반 에이전트)가 빛을 발합니다.

• 실패한 테스트의 Trace Viewer 기록을 분석해
• DOM 구조를 비교하고
• 비슷한 역할을 하는 새로운 요소를 자동으로 찾아
• 셀렉터를 업데이트합니다.

실제 경험상 셀렉터·DOM 관련 실패의 75% 이상을 자동 복구할 수 있어요.

 

특히 “로그인 버튼이 안 보인다” 같은 단순 실패는 에이전트가 새로운 getByRole('button', { name: /로그인/ })을 제안하거나 직접 수정까지 시도합니다.

 

이 기능이 작동하면 테스터는 매번 사소한 UI 변경에 끌려다니지 않고, 더 중요한 품질 문제에 집중할 수 있습니다.

 

 

그러나 명확한 한계, 복잡한 로직 버그는 사람 몫

AI가 아무리 똑똑해도 아직은 판단력이 부족합니다.

 

예를 들어 “비밀번호를 5번 틀리면 계정이 잠겨야 하는데, 6번째에도 계속 시도할 수 있다”는 로직 버그를 AI가 스스로 고치려 하면 오히려 더 큰 문제를 만들 수 있어요.

 

비즈니스 규칙, 사용자 경험, 보안 영향도를 종합적으로 고려해야 하는 영역은 AI가 잘 모릅니다.

 

또한 AI Healer가 제안한 ‘치유’가 정말 올바른지 최종 확인하는 건 반드시 사람의 역할입니다.

 

환각으로 엉뚱한 셀렉터를 만들거나, 숨겨진 부작용을 놓치는 경우도 있기 때문이죠.

 

따라서 현실적인 운영 방식은 “AI가 75~80%까지 고치고, 사람은 나머지 중요한 20%를 검토하고 전략적으로 개선한다”입니다.

 

 

실전에서 자가 치유를 활용하는 방법

1. Playwright 테스트에 MCP(Multi-Context Protocol)나 AI 에이전트 기능을 먼저 연결해 보세요.
2. 실패 시 자동으로 Trace를 분석하고 힐링 제안을 받는 흐름을 만듭니다.
3. AI가 수정한 코드는 반드시 사람이 Trace Viewer로 재확인하고, 위험도가 높은 부분은 수동 검증합니다.

이 습관을 들이면 유지보수 비용이 크게 줄고, 테스터의 시간은 진짜 가치 있는 일(전략 설계, 복잡한 시나리오 검증)로 이동합니다.

 

자가 치유의 힘을 알되 그 한계를 명확히 아는 순간, 당신의 테스트 스위트는 단순한 자동화가 아니라 살아 숨쉬는 살아있는 품질 시스템으로 진화합니다.

 

다음 화에서는 MCP를 직접 활용해 통합 검증까지 실습해 보겠습니다.