7화. 플래키의 근원, 셀렉터와 대기 — 안정적 셀렉터와 비동기 대기 전략.

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로 자동화를 시작한 초보 테스터가 가장 먼저 부딪히는 벽이 바로 플래키(flaky) 테스트예요.

 

이번 화에서는 그 불안정한 근원을 파헤치고, 안정적인 셀렉터와 비동기 대기 전략을 이해하기 쉽게 풀어보겠습니다.

 

 

흔들리는 다리와 단단한 기둥

상상해 보세요.

 

학교 체육시간에 줄넘기를 하는데, 줄이 너무 느슨하거나 바람이 불면 계속 실패합니다.

 

반대로 줄이 팽팽하고 타이밍을 잘 맞추면 성공률이 높아지죠.

 

플래키 테스트는 바로 그 느슨한 줄과 같습니다.

 

페이지가 완전히 로드되기 전에 버튼을 클릭하거나, 요소의 위치가 자주 바뀌는 셀렉터를 사용하면 테스트가 “가끔 성공하고 가끔 실패”합니다.

 

이 불안정성은 CI/CD 파이프라인에서 큰 골칫거리가 되고, 결국 팀이 자동화를 포기하게 만드는 주범이 됩니다.

 

 

플래키의 가장 큰 원인, 불안정한 셀렉터

많은 사람들이 XPath나 복잡한 CSS 선택자를 사용합니다.

 

예를 들어 div:nth-child(3) > button처럼 위치에 의존하면, 디자인이 조금만 바뀌어도 테스트가 깨집니다.

 

마치 친구 얼굴을 “세 번째 줄 네 번째 아이”로 기억하는 것과 같아요.

 

친구가 자리를 옮기면 바로 못 찾죠.

 

Playwright에서는 훨씬 단단한 방법을 권장합니다.

 

가장 추천하는 순서

먼저 getByRole()을 사용하세요. 접근성(ARIA) 역할을 기준으로 찾기 때문에 “로그인 버튼”, “검색 입력창”처럼 의미를 가진 요소를 안정적으로 잡아냅니다.

await page.getByRole('button', { name: '로그인' }).click();

 

다음으로 getByTestId()를 활용합니다.

 

개발자에게 “test-id='submit-button'” 같은 속성을 미리 넣어달라고 요청하면, 디자인이나 구조가 바뀌어도 흔들리지 않는 강력한 앵커가 생깁니다.

 

getByLabel(), getByPlaceholder(), getByText()도 유용합니다.

 

이처럼 의미와 의도를 기반으로 요소를 찾는 습관을 들이면, 셀렉터 때문에 실패하는 일이 크게 줄어듭니다.

 

 

비동기 세상의 타이밍, 스마트 대기 전략

현대 웹은 주문하면 바로 오는 게 아니라, 요리사(서버)가 준비할 때까지 기다려야 하는 레스토랑과 같습니다.

 

AJAX 호출, 애니메이션, 동적 로딩 때문에 페이지가 “거의” 로드된 상태에서 테스트가 진행되면 실패하기 십상입니다.

 

Playwright의 가장 큰 강점은 자동 대기(Auto-waiting)입니다.

 

click(), fill(), expect().toBeVisible() 같은 명령을 쓸 때 알아서 필요한 순간까지 기다려줍니다.

 

하지만 가끔 더 명확한 전략이 필요합니다.

• page.waitForLoadState('networkidle') : 네트워크 요청이 잠잠해질 때까지 기다림
  
  
• await expect(page.getByRole('heading')).toBeVisible({ timeout: 10000 }) :
  특정 요소가 나타날 때까지 최대 10초 기다림
  
  
• page.locator().first()이나 filter()를 활용해 조건에 맞는 요소를 정확히 지정

특히 SPA(Single Page Application)에서는 URL 변화나 특정 텍스트 등장까지 기다리는 것이 효과적입니다.

 

 

실전에서 바로 써먹는 안정화 팁

코드 작성할 때 “이 요소가 정말 안정적으로 보일까?”를 항상 자문해 보세요.

 

AI가 생성한 테스트 코드도 이 관점에서 검토하면 많은 플래키를 미리 잡아낼 수 있습니다.

 

Trace Viewer를 활용해 실패한 테스트를 영상처럼 돌려보면, 어느 순간 셀렉터가 실패했는지, 대기가 부족했는지 바로 파악됩니다.

 

처음에는 테스트가 조금 느려지더라도 안정성을 최우선으로 하다 보면, 전체 실행 속도도 오히려 빨라지는 마법을 경험하게 될 거예요.

 

 

플래키를 잡는 습관이 품질 아키텍트의 첫걸음

플래키의 근원을 이해하고 셀렉터와 대기 전략을 제대로 세우는 순간, 자동화 스위트는 단순한 스크립트가 아니라 신뢰할 수 있는 품질 지킴이가 됩니다.

 

이 기본기를 탄탄히 다지면 다음 단계에서 더 복잡한 시나리오도 자신 있게 다룰 수 있어요.

 

불안정한 테스트 하나하나를 잡아나가다 보면, 데모가 아닌 진짜 프로덕션 환경에서도 든든하게 버티는 시스템을 만들 수 있다는 자신감이 생길 겁니다.