18화. 플래키를 격리하라 — 불안정 테스트 격리와 실패 원인 자동 분류.

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

 

---

거짓말쟁이 테스트를 길들이는 법: 플래키 테스트 격리와 자동 분류

매번 결과가 바뀌는 테스트 때문에 팀의 신뢰가 흔들린 적 있으신가요?

 

마치 "늑대가 나타났다!"를 외치는 양치기 소년처럼, 때로는 성공하고 때로는 실패하는 변덕스러운 테스트, 즉 플래키 테스트(Flaky Test)를 어떻게 다루어야 할지 알아봅니다.

 

"늑대가 나타났다!" 거짓말쟁이 테스트의 등장

지난 연재에서 우리는 CI/CD 파이프라인의 품질 게이트를 통해 코드의 안전을 확보하는 방법을 살펴보았습니다.

 

마치 공항 검색대처럼 코드를 꼼꼼히 검사하여 문제가 있는 부분을 걸러내는 과정이었죠.

 

그런데 만약 이 검색대가 어떤 날은 위험물을 통과시키고, 어떤 날은 무해한 물건을 위험물로 판단하여 경보를 울린다면 어떨까요?

 

사람들은 이 검색대의 신뢰성을 의심하게 될 것이고, 결국 시스템 전체에 대한 불신으로 이어질 것입니다.

 

소프트웨어 테스트에서도 이와 비슷한 상황이 발생합니다.

 

 

바로 플래키 테스트입니다. 플래키 테스트는 코드 변경 없이도 실행할 때마다 결과가 성공과 실패를 오가는 테스트를 말합니다 [1].

 

마치 "늑대가 나타났다!"고 외쳤다가 아니라고 했다가 하는 양치기 소년처럼, 개발자들은 이 테스트의 결과가 진짜 버그를 알려주는 것인지, 아니면 그저 변덕을 부리는 것인지 알 수 없어 혼란에 빠지게 됩니다.

 

이런 테스트가 많아지면 개발팀은 테스트 결과를 믿지 못하게 되고, 결국 중요한 버그를 놓치거나 불필요한 시간 낭비를 하게 됩니다.

 

왜 테스트는 변덕을 부릴까: 플래키의 원인들

플래키 테스트가 발생하는 이유는 다양합니다.

 

가장 흔한 원인 중 하나는 시간 의존성입니다.

 

예를 들어, 웹 페이지의 특정 요소가 로딩되는 시간을 정확히 예측하지 못하고 테스트가 너무 빨리 다음 단계를 실행해버리는 경우입니다.

 

마치 요리사가 재료가 다 익기도 전에 다음 조리 단계로 넘어가서 음식을 망치는 것과 비슷하죠.

 

네트워크 지연이나 서버 응답 속도 변화 같은 외부 요인도 테스트 결과에 영향을 줄 수 있습니다.

 

또 다른 원인은 실행 순서 의존성입니다.

 

여러 테스트가 서로 영향을 주고받는 경우입니다.

 

한 테스트가 데이터베이스에 특정 데이터를 남겨두었는데, 다음 테스트가 그 데이터를 예상치 못하게 사용하거나 변경하여 실패하는 식입니다.

 

이는 마치 여러 사람이 같은 주방에서 요리하는데, 한 사람이 사용한 도구를 제대로 정리하지 않아 다음 사람이 요리하는 데 방해가 되는 상황과 같습니다.

 

비동기 처리의 복잡성도 플래키 테스트의 주범입니다.

 

요즘 소프트웨어는 여러 작업이 동시에, 그리고 독립적으로 진행되는 경우가 많습니다.

 

테스트가 이런 비동기 작업의 완료를 정확히 기다리지 못하고 결과를 확인하려 하면, 아직 작업이 끝나지 않아 실패로 기록될 수 있습니다.

 

마치 여러 명의 악기 연주자가 동시에 연주를 시작했는데, 지휘자가 모든 악기가 준비되기도 전에 다음 악보로 넘어가 버리는 것과 같습니다.

 

거짓말쟁이 테스트를 길들이는 전략: 격리와 자동 분류

플래키 테스트가 팀의 생산성과 신뢰를 갉아먹는다는 것을 알았으니, 이제 이 변덕스러운 테스트들을 어떻게 다룰지 고민해야 합니다.

 

가장 효과적인 방법 중 하나는 격리(Quarantine)와 자동 분류(Automatic Failure Classification)입니다.

 

문제아 테스트를 따로 모아두는 '격리 병동'

플래키 테스트를 격리한다는 것은, 마치 학교에서 문제 행동을 반복하는 학생을 잠시 특별반으로 보내는 것과 비슷합니다.

 

즉, 메인 CI/CD 파이프라인에서 이 플래키 테스트들을 분리하여 별도의 환경에서 실행하거나, 아예 잠시 실행 대상에서 제외하는 것입니다 [2].

 

이렇게 하면 메인 파이프라인은 신뢰할 수 있는 테스트들로만 구성되어, 개발자들이 테스트 결과를 믿고 빠르게 코드 변경을 반영할 수 있게 됩니다.

 

격리된 플래키 테스트들은 전담 팀이나 개인이 집중적으로 분석하고 수정하여 다시 메인 파이프라인으로 복귀시킬 수 있습니다.

 

격리된 테스트를 관리하는 데는 몇 가지 원칙이 있습니다.

 

첫째, 플래키 테스트 예산(Flakiness Budget)을 설정하는 것입니다.

 

예를 들어, 전체 테스트 중 5% 이상이 플래키 테스트가 되면 안 된다는 기준을 두는 것이죠.

 

둘째, 격리된 테스트에도 소유자(Owner)를 지정하여 누가 이 테스트의 안정화를 책임질지 명확히 합니다.

 

셋째, 격리된 테스트를 무기한 방치하지 않고, 일정 기간 내에 해결하도록 목표를 설정합니다.

 

마치 병원에 입원한 환자에게 퇴원 목표일을 정해주는 것과 같습니다.

 

실패의 원인을 자동으로 찾아주는 'AI 조수'

플래키 테스트를 격리하는 것만으로는 부족합니다.

 

왜 이 테스트가 변덕을 부리는지 원인을 찾아 해결해야 합니다.

 

이때 실패 원인 자동 분류 기술이 큰 도움이 됩니다.

 

이는 AI나 머신러닝 기술을 활용하여 테스트 실패 로그를 분석하고, 어떤 유형의 문제 때문에 실패했는지 자동으로 예측하는 것입니다.

 

예를 들어, "네트워크 타임아웃" 때문에 실패했는지, "UI 요소 로딩 지연" 때문인지, 아니면 "데이터 불일치" 때문인지를 자동으로 알려주는 것이죠.

 

이 기술은 마치 숙련된 의사가 환자의 증상을 듣고 어떤 질병인지 빠르게 진단하는 것과 같습니다.

 

수많은 테스트 실패 로그를 사람이 일일이 분석하는 것은 시간도 오래 걸리고 비효율적입니다.

 

하지만 AI 조수가 실패 원인을 자동으로 분류해주면, 개발자나 테스터는 문제 해결에 필요한 정보를 더 빨리 얻고, 플래키 테스트를 안정화하는 데 집중할 수 있습니다.

 

특히, Trace Viewer와 같은 도구와 연동하여 실패 시점의 화면 녹화나 로그를 함께 제공한다면, 원인 분석은 더욱 쉬워집니다.

 

 

품질 아키텍트의 지혜: 신뢰를 쌓는 테스트 문화

플래키 테스트를 관리하는 것은 단순히 기술적인 문제를 해결하는 것을 넘어, 팀 내 신뢰를 쌓는 테스트 문화를 구축하는 과정입니다.

 

테스트 결과가 일관되고 신뢰할 수 있을 때, 개발자들은 테스트를 두려워하지 않고 적극적으로 활용하게 됩니다.

 

이는 곧 더 빠르고 안정적인 소프트웨어 개발로 이어집니다.

 

 

품질 아키텍트로서 우리는 플래키 테스트를 단순히 제거해야 할 대상으로 보는 것이 아니라, 시스템의 약점을 알려주는 중요한 신호로 받아들여야 합니다.

 

그리고 이 신호를 효과적으로 관리하고 해결할 수 있는 프로세스와 도구를 설계해야 합니다.

 

격리된 테스트를 체계적으로 관리하고, 실패 원인을 자동으로 분류하여 해결 시간을 단축하는 것은, AI 시대에 우리가 만들어갈 더욱 견고하고 신뢰할 수 있는 소프트웨어 품질 시스템의 중요한 기둥이 될 것입니다.

---

참고 자료

[1] Harness.io. "Flaky Tests: How to Find, Fix, and Prevent Them." https://www.harness.io/blog/flaky-tests-the-quiet-killer-of-productivity-in-your-ci-pipeline
[2] QASkills. "Flaky Test Quarantine." https://qaskills.sh/skills/Pramod/flaky-test-quarantine

태그: 플래키 테스트, 테스트 격리, 자동 분류, CI/CD, 품질 아키텍트, 소프트웨어 테스트, 신뢰성, 개발 문화