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화. 테스터에서 품질 아키텍트로
npx playwright init-agents 한 번으로 AI 에이전트가 테스트 세계에 들어오는 순간
Playwright 자동화에 어느 정도 익숙해졌다면, 이제 AI가 직접 브라우저를 움직이며 테스트를 도와주는 세계로 들어갈 때입니다.
MCP와 Playwright Agents를 처음 만나는 이 실습에서, 접근성 트리를 기반으로 한 지능형 테스트가 어떻게 시작되는지 직접 느껴보세요.
명령어 하나로 에이전트가 준비되고, 테스터는 더 전략적인 일에 집중할 수 있게 됩니다.
화면을 보는 눈, 접근성 트리
친구가 게임을 할 때, 화면을 그냥 보는 게 아니라 “이 버튼은 빨간색, 저건 점프 버튼이야” 하며 의미를 파악하듯 움직입니다.
브라우저도 비슷해요.
시각장애인용 스크린 리더를 위해 접근성 트리(Accessibility Tree)라는 구조화된 정보를 항상 가지고 있습니다.
버튼, 입력창, 제목 등 각 요소의 역할(role), 이름(name), 상태(checked, disabled 등)를 트리 형태로 정리해 두죠.
Playwright MCP(Model Context Protocol)는 이 접근성 트리를 AI 에이전트에게 그대로 전달합니다.
AI가 스크린샷처럼 무거운 이미지를 보는 대신, 가볍고 정확한 구조화된 데이터를 읽으며 브라우저를 조작할 수 있게 되는 거예요.
토큰도 적게 먹고, 더 정확하고 빠릅니다.
첫 MCP 실습, npx playwright init-agents 실행하기
준비는 생각보다 간단합니다. Playwright 프로젝트가 이미 있다면 터미널에서 아래 명령어를 입력해 보세요.
npx playwright init-agents --loop=vscode( VS Code를 사용한다면 --loop=vscode, Claude나 다른 환경이라면 해당 옵션을 선택합니다.)
이 명령어가 하는 일은 다음과 같아요:
- Playwright Test Agents(Planner, Generator, Healer) 설정 파일을 프로젝트에 추가합니다.
- MCP 서버와 연결할 수 있는 에이전트 정의를 생성합니다.
specs/폴더와 seed 파일 등 실습에 필요한 기반을 마련합니다.
명령어가 끝나면 VS Code나 사용 중인 IDE의 AI 채팅창에 Playwright Planner, Generator, Healer 같은 에이전트가 나타납니다.
이제 AI에게 “로그인 화면을 테스트해줘” 같은 목표를 주면 에이전트가 스스로 계획을 세우고 테스트를 만들어줍니다.
접근성 트리로 움직이는 첫 경험
에이전트를 활성화한 상태에서 간단한 목표를 던져보세요.
예를 들어:
“Google 홈페이지에 들어가서 ‘Playwright’를 검색하고, 결과 페이지가 제대로 나오는지 확인하는 테스트 계획을 세워줘.”
Planner 에이전트가 접근성 트리를 읽으며 단계별 계획을 만들어주고, Generator가 실제 Playwright 코드를 작성합니다.
Healer는 나중에 테스트가 깨졌을 때 자동으로 고치려 시도하죠.
이 과정에서 AI는 픽셀이 아니라 접근성 트리를 통해 “검색 입력창(role=textbox, name=검색)”처럼 명확하게 요소를 이해합니다.
그래서 셀렉터가 깨지는 문제도 크게 줄어들고, 접근성 품질까지 자연스럽게 높아지는 효과가 있습니다.
실습하며 느껴보는 작은 팁
처음에는 간단한 페이지부터 시작하세요.
Trace Viewer와 함께 결과를 확인하면서 “AI가 어떤 접근성 정보를 보고 판단했는지”를 분석해 보세요.
프롬프트가 구체적일수록(예: “위험도가 높은 시나리오 위주로”) 더 좋은 결과가 나옵니다.
이 첫 MCP 실습을 통해 에이전트가 어떻게 작동하는지 몸으로 느끼면, 이전에 배운 프롬프트 기법과 자가 치유 기능이 훨씬 더 강력하게 살아납니다.
AI가 단순 도구가 아니라 함께 테스트를 설계하고 실행하는 파트너가 되는 순간을 경험하게 될 거예요.
이제 MCP의 문을 열었으니, 다음 단계에서는 이 에이전트를 활용해 실제 통합 검증까지 이어가 보겠습니다.
한 걸음씩, AI와 함께하는 테스트의 맛을 제대로 느껴보세요.