10화. 눈에 보이는 회귀, 모두에게 열린 화면 — 시각적 회귀와 접근성 자동 검사. (Selenium·Appium은 레거시·모바일 대응용으로 짧게 짚기)

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화. 테스터에서 품질 아키텍트로 

---

 

눈에 보이는 변화까지 잡아내는 순간, 화면이 모두에게 진짜 열린다

 

Playwright로 UI 자동화에 익숙해진 테스터가 다음으로 부딪히는 벽은 “눈으로 보기엔 괜찮아 보이는데…” 하는 미묘한 변화들입니다.

 

시각적 회귀 테스트와 접근성 자동 검사를 도입하면, 디자인 깨짐은 물론 시각장애인도 편하게 쓸 수 있는 화면을 자동으로 지킬 수 있어요.

 

데모에서 예쁘게 보이던 UI가 실제 사용자에게까지 안정적으로 전달되는 품질을 한 단계 끌어올리는 핵심 기술입니다.

 

 

사진 앨범과 새로 찍은 사진, 시각적 회귀 테스트

중학생 때 가족 사진 앨범을 뒤적이다가 예전 사진과 최근 사진을 비교해 본 적 있나요?

 

“머리 스타일은 비슷한데 색감이 좀 달라졌네”, “배경에 이상한 게 들어갔어” 같은 작은 차이를 바로 알아차리죠.

 

시각적 회귀(Visual Regression) 테스트는 바로 이 과정입니다.

 

이전에 정상이었던 화면 스크린샷을 기준으로 삼아, 새로운 코드 변경 후 화면이 얼마나 달라졌는지 픽셀 단위로 자동 비교합니다.

 

버튼 위치가 2픽셀만 움직여도, 색상이 미세하게 변해도, 레이아웃이 살짝 깨져도 바로 알려줍니다.

 

Playwright에서는 expect(page).toHaveScreenshot('로그인-화면.png') 한 줄로 이 기능을 사용할 수 있어요.

 

테스트를 실행할 때마다 자동으로 스크린샷을 찍고, 기준 이미지와 비교합니다.

 

차이가 허용 범위를 넘으면 테스트가 실패하면서 새로운 이미지를 보여주죠.

 

이때 중요한 건 “의도된 변화”와 “의도하지 않은 깨짐”을 구분하는 감각입니다.

 

Trace Viewer와 함께 사용하면 어떤 변경 때문에 화면이 달라졌는지 빠르게 파악할 수 있어요.

 

 

모두에게 열린 화면, 접근성 자동 검사

학교에서 친구들과 게임을 할 때, 한 친구가 눈이 안 좋아서 화면을 잘 못 보는 상황을 상상해 보세요.

 

색맹 친구는 특정 색상을 구분 못 하고, 키보드만 쓰는 친구는 마우스로만 동작하는 버튼을 못 누르죠.

 

좋은 게임은 이런 친구들도 함께 즐길 수 있게 만들어야 합니다.

 

웹 접근성(Accessibility)도 마찬가지예요.

 

시각장애인용 스크린 리더가 제대로 읽을 수 있는지, 색 대비가 충분한지, 키보드로 모든 기능을 사용할 수 있는지 등을 확인해야 합니다.

 

Playwright는 page.accessibility.snapshot()이나 Axe 같은 접근성 엔진과 쉽게 연동됩니다.

 

테스트 코드 안에 접근성 검사를 넣으면, 자동으로 WCAG 기준을 체크해줍니다.

 

예를 들어 “이미지에 alt 텍스트가 없는가?”, “버튼에 접근 가능한 이름이 있는가?” 같은 문제를 즉시 알려주죠.

 

이 검사를 CI/CD에 포함시키면 매번 코드가 바뀔 때마다 “이 화면은 정말 모두에게 열려 있는가?”를 확인할 수 있습니다.

 

 

레거시와 모바일 대응, Selenium과 Appium은 이렇게

Playwright가 현대 웹에 가장 강력하지만, 오래된 시스템이나 모바일 앱을 다뤄야 할 때는 Selenium과 Appium을 짧게 활용합니다.

 

Selenium은 기존에 많이 쓰이던 도구로, 다양한 브라우저 지원이 장점이지만 자동 대기와 안정성은 Playwright에 밀립니다.

 

Appium은 iOS·Android 앱 테스트에 특화되어 모바일 전용 기능을 다룰 때 유용하죠.

 

새 프로젝트라면 Playwright를 주력으로 하고, 레거시 유지보수나 순수 네이티브 앱에서는 이 도구들을 보조로 쓰는 전략이 현실적입니다.

 

 

실전에서 두 검사를 함께 굴리는 습관

시각적 회귀와 접근성 검사를 처음 도입할 때는 중요한 핵심 화면(로그인, 대시보드, 결제 등)부터 시작하세요.

 

AI가 테스트 코드를 만들어줄 때 “시각적 비교와 접근성 검사도 추가해”라고 프롬프트하면 더 완성도 높은 코드를 얻을 수 있습니다.

 

작은 변화 하나하나를 놓치지 않고 잡아내다 보면, 사용자들이 “화면이 예전보다 더 편해졌어”라고 느끼는 진짜 품질이 쌓입니다.

 

눈에 보이는 부분까지 철저히 지키는 이 습관이 테스터를 시스템 전체 품질을 설계하는 아키텍트로 이끄는 중요한 디딤돌이 됩니다.